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
Conversation
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.
1
1
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
I looked quickly at the uses of NoAlias in llvm-project/llvm/lib, it's not that broadly used, I doubt the number of misuses is anything close to vast
1
1
if there are bad optimizations that are giving performance wins, then that's the hard case to get fixed
1
1
we're still working on UB-related bugs we found like seven years ago because they fire ubiquitously and matter, and getting the same wins in other ways isn't so straightforward. this could be like that...
1
2
I really liked the infinite loop / infinite recursion example that's now finally fixed. It was a pretty shocking bug in a language like Java or Rust. In C, no one cares. The code is already wrong and horribly broken anyway. Just needs to go fast and appear to still mostly work.
2
2
It's really hard to convince someone to care about that issue for C. It's not like stack overflow is well defined as trapping and that's the main way for it to cause a correctness issue. It's harder to hit in the real world from an infinite loop. Easy in trivial test cases.