Conversation

Daniel Micay
@DanielMicay
twitter.com/comex/status/1 Noalias optimizations have always been so thoroughly broken in LLVM. It's sad. How many times has Rust tried communicating noalias info to LLVM just to end up needing to disable it? It's broken for restrict in C. Mitigated by no one using that feature...
Quote Tweet
comex
@comex
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… github.com/rust-lang/rust
Twitter Web App
1
Retweet
6
Likes
Daniel Micay
@DanielMicay
Replying to
@DanielMicay
My experience with both Clang and GCC is that both restrict and their type-based alias analysis are horribly broken. The reason people don't care much is that most C and C++ code is full of undefined behavior anyway so the compiler breaking it more isn't taken very seriously.
1
3
Daniel Micay
@DanielMicay
When you ran into these kinds of issues in C, it can take significant effort to determine it isn't the fault of the code. C alias analysis and pointer provenance optimization are based around playing subjective games around vague and unclear wording in a poorly written standard.
1
3
Daniel Micay
@DanielMicay
It's not simply that LLVM and GCC have a bunch of mistakes in their implementations of optimizations and alias analysis... Hitting issues of C being miscompiled leads to needing to figure out if the standard allows the compiler to be broken, which it probably does, so WONTFIX.
2