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
I think the issue will generally be that optimizations consuming alias analysis are wrong. However, they didn't get enough information to noticeably break code until most of the pointers started being marked as noalias which is what happens with Rust if it's done aggressively.
1
1
Most of the complexity where everything can go wrong are the optimizations consuming the information.
Compared to that, the alias analysis deciding whether to answer NoAlias doesn't seem particularly hard to get right. Of course, maybe it's still broken or propagation is broken.
Rust was even hitting lots of these issues just from marking parameters as noalias, not even from applying it aggressively. LLVM happily generates scoped noalias metadata itself when inlining, etc.
LTO + nearly all pointers marked noalias seems inherently prone to finding bugs.
2
1
Also, based on past experience with LLVM, I wonder how much generating a whole bunch of this metadata slows down compilation and increases memory usage.
Not familiar with the current Rust implementation and if they're actually doing it aggressively beyond parameters, etc.
1