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.
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.
1
1
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
Show replies
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
Show replies