Conversation

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

Regression: Miscompilation due to bug in "mutable noalias" logic · Issue #84958 · rust-lang/rust

The ring test suite started failing when I tried to upgrade to untrusted 0.8.0. The regression first shipped in nightly-2021-03-23: We were further able to narrow down the regression by bisecting d...

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

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.

Replying to

and

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.

Replying to

and

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.

10:27 PM · May 5, 2021Twitter Web App

Replying to

and

I don't really think that scoped noalias metadata itself is broken but rather *everything* is broken and by giving LLVM so much more alias information to work with you get to enjoy uncovering a vast landscape of different optimization bugs. Combine that with LTO being the norm...