So you know how Rust recently re-enabled LLVM noalias (i.e. optimizing based on no-aliasing assumptions), after having it disabled due to longstanding bugs in LLVM?
Well…
Conversation
Replying to
I wonder which of these is the case?
- noalias means something in LLVM, but not what rustc wants it to mean
- noalias means something in LLVM, but then LLVM internally gets a transformation wrong
- noalias (or some corner case of it) doesn't have a coherent semantics in LLVM
2
11
restrict, type punning, pointer provenance, etc. are poorly defined for C so LLVM ends up with semantics based around how they felt like interpreting the C standard. It's not really expected to work and be fully well defined. Rust has much different expectations from LLVM.
2
2
LLVM doesn't take the issue of them compiling code incorrectly particularly seriously. This is going to be really hard for Rust to enable because it enables much more aggressive optimizations in general, and so much of how optimization works seems broken. Look at all the fixes.
They already fixed so many different things to get this working and it still doesn't work. It's pretty bad. Yet, for C, this was and is considered completely acceptable. You hit a weird heisenbug and work around it. It's probably your fault. It would be WONTFIXed either way.
1
1
I don't really think that scoped noalias metadata itself is broken but rather *everything* is broken and by giving LLVM so much more alias information to work with you get to enjoy uncovering a vast landscape of different optimization bugs. Combine that with LTO being the norm...