LLVM has to translate them to the new scope when it does inlining, including converting noalias markers on function parameters to scoped metadata. This was yet another bug in how that kind of thing gets handled. It's complex and has to handle all the details / interactions right.
Conversation
Rust has uncovered a bunch of these LLVM bugs. It has consistently been caused by issues in LLVM rather than in rustc. It also definitely impacts C but restrict isn't widely used. Most references in Rust should be marked noalias. It means no memory dependencies between them.
1
6
LLVM NoAlias means that two pointers do not have memory dependencies between them, i.e. there aren't writes made through one of the pointers that are visible through the other. Rust guarantees that while an &mut reference is active/usable, nothing else reads/writes that data.
1
2
It could also be marking most &T references as NoAlias too because it means immutable in the absence of interior mutability which is something that the type system understands. Means Rust could mark vast majority of references as NoAlias and get much more aggressive optimization.
1
1
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.
1
1
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.
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
Show replies
Is there any way to just turn LTO off globally, both to avoid these bugs and so that you can compile stuff without 16GB of ram? I.e. to just use standard object files.
2
Show replies