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