There have been LLVM bugs in how it implements alias analysis, propagation of noalias metadata across functions (inlining in paricular), optimizations wrongly concluding NoAlias response for 2 pointers means they can do something, and just optimizations wrong for other reasons.
Conversation
Since heavily using this enables a lot more optimization in general you are going to find edge case bugs that never came up before because those optimizations got triggered far less optimizations and didn't actually get exercised nearly as much. It's a stress test and it fails.
1
3
Imagine a large C program where 95% of pointers were marked restrict. The markings on all those pointers were all done correctly. Clang and GCC simply don't deal with that kind of code in the real world and the fact that they're thoroughly broken just doesn't come up with C.
1
5
Rust using noalias on &mut T parameters and scoped noalias metadata within functions is only one step towards taking advantage of the information it has available. Using it on &T without interior mutability (Cell, Mutex, etc.) would cover even more references.
1
2
It could output noalias metadata in some other cases too. You know what's really sad? This was first attempted something like 6-7 years ago. I was involved in the initial work on it, back when I was working on Rust. LLVM was broken then, and 100 or so fixes later is still broken.
1
5
It does impact C particularly since the C standard library does mark a few parameters with restrict. LLVM knows how to propagate that into scoped noalias metadata, etc. Using those functions is making a promise. People hardly use it though and it's just not stressed enough.
1
4
Also worth noting that the default for Cargo release builds is ThinLTO within a crate (i.e. all the code within a library or the non-library code an executable).
doc.rust-lang.org/cargo/referenc
In Rust, turning on LTO means enabling cross-crate (cross-library) LTO and non-thin LTO.
2
4
Rust compiler divides up code into codegen units itself for incremental builds / parallelism. If you use 1 codegen unit, then that's essentially fat LTO within the crate. Default is multiple codegen units with ThinLTO to combine them together but not across crates unless you ask.
1
2
Not doing it across crates by default doesn't mean there isn't optimization across crates because plenty of stuff is explicitly marked as #[inline] or uses generics (doesn't imply it has to recompile it entirely from scratch unlike C++ inline/generics):
nnethercote.github.io/perf-book/inli
1
1
Anyway, when you combine much more pervasive inter-procedural optimization with having pervasive noalias metadata all over the place, you get drastically more aggressive optimization than you're typically doing for C++ code and it's a stress test for compiler correctness...
1
LLVM has benefited a lot from all the bugs uncovered by Rust. This latest noalias bug was uncovered in nightly before it got to beta because there's a lot of automated CI, etc. testing things. Also worth noting LLVM isn't even very good at leveraging all the extra metadata yet...
Optimizations don't really bother leveraging alias analysis nearly as much as they could because you have such terrible information available for C. It largely depends on the TBAA and pointer provenance rules compilers invented around the rules for type punning and so on.
1
2
Thanks for such a detailed response! I always wondered how TBAA worked in the presence of type punning, but I never looked into it.
2