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.
Conversation
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.
2
4
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
See doc.rust-lang.org/cargo/referenc. You can turn off LTO completely. ThinLTO isn't very demanding though.
You can also use more codegen units to build the code in smaller chunks, including using more of them than you have files, since it's not tied to that:
doc.rust-lang.org/cargo/referenc
Is that a choice of the crate author or of the person building?
1
The crate author chooses the defaults for different profiles. You can set different options yourself though.
2