Conversation

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

May 5, 2021

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

Daniel Micay

@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.

9:58 PM · May 5, 2021Twitter Web App

Replying to

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.

Daniel Micay

@DanielMicay

May 5, 2021

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.