Workaround LLVM optimizer bug by not marking &mut pointers as noalias #31545
Conversation
|
r? @jroesch (rust_highfive has picked a reviewer for you, use r? to override) |
| @@ -265,7 +265,7 @@ pub fn from_fn_type<'a, 'tcx>(ccx: &CrateContext<'a, 'tcx>, fn_type: ty::Ty<'tcx | |||
| // on memory dependencies rather than pointer equality | |||
| let interior_unsafe = mt.ty.type_contents(ccx.tcx()).interior_unsafe(); | |||
|
|
|||
| if mt.mutbl == hir::MutMutable || !interior_unsafe { | |||
| if mt.mutbl != hir::MutMutable && !interior_unsafe { | |||
There was a problem hiding this comment.
I may not quite be understanding what's going on here, but doesn't this mean that &usize will have the noalias attribute applied?
There was a problem hiding this comment.
Yes, and that's intentional. The change is supposed to only affect &mut references (and '&' ones with unsafe interiors), because those are the ones that could have stores that would expose this bug.
There was a problem hiding this comment.
Oh, also note that WRT &usize this is not a change, those pointers got the noalias attribute before as well (the || got changed into a &&). As the comment above this change says, noalias is about memory dependencies rather than plain pointer equality.
|
Looks like the travis failure is legit in that a codegen test needs to be udpated. |
LLVM's memory dependence analysis doesn't properly account for calls that could unwind and thus effectively act as a branching point. This can lead to stores that are only visible when the call unwinds being removed, possibly leading to calls to drop() functions with b0rked memory contents. As there is no fix for this in LLVM yet and we want to keep compatibility to current LLVM versions anyways, we have to workaround this bug by omitting the noalias attribute on &mut function arguments. Benchmarks suggest that the performance loss by this change is very small. Thanks to @RalfJung for pushing me towards not removing too many noalias annotations and @alexcrichton for helping out with the test for this bug. Fixes rust-lang#29485
|
Updated the codegen test, completely forgot about those and only ran the new test before opening the PR |
LLVM's memory dependence analysis doesn't properly account for calls that could unwind and thus effectively act as a branching point. This can lead to stores that are only visible when the call unwinds being removed, possibly leading to calls to drop() functions with b0rked memory contents. As there is no fix for this in LLVM yet and we want to keep compatibility to current LLVM versions anyways, we have to workaround this bug by omitting the noalias attribute on &mut function arguments. Benchmarks suggest that the performance loss by this change is very small. Thanks to @RalfJung for pushing me towards not removing too many noalias annotations and @alexcrichton for helping out with the test for this bug. Fixes #29485
|
This seems like a horrible performance loss. Can you post the benchmarks? |
|
Well, I haven't benchmarked this change, but in my experience, disabling noalias in GCC gave bad performance. |
|
@ticki what exactly do you mean by "disabling noalias in GCC"? Making it ignore the |
|
|
|
That option disables TBAA, which rust does not use at all. The scope of -fno-strict-aliasing, that is. — |
LLVM's memory dependence analysis doesn't properly account for calls
that could unwind and thus effectively act as a branching point. This
can lead to stores that are only visible when the call unwinds being
removed, possibly leading to calls to drop() functions with b0rked
memory contents.
As there is no fix for this in LLVM yet and we want to keep
compatibility to current LLVM versions anyways, we have to workaround
this bug by omitting the noalias attribute on &mut function arguments.
Benchmarks suggest that the performance loss by this change is very
small.
Thanks to @RalfJung for pushing me towards not removing too many
noalias annotations and @alexcrichton for helping out with the test for
this bug.
Fixes #29485