> The former though is an area of significant divergence between Rust and C++ semantics, and LLVM blindly following C++ semantics.

Ah I must have missed that, I thought you were talking about only one thing (since IIRC the noalias miscompilation is due to loop unrolling?)

FWIW, `noalias`, aka. `__restrict__`, generally works fine but the inliner translates it into `noalias` metadata which is, still, ambiguous and also not handled properly in some cases. Loop unrolling is one of them but that will be fixed with https://reviews.llvm.org/D92887, a general problem is the ambiguity itself.

There is a major effort to revamp the `noalias`/`restrict` handling going on for a while now. It takes quite long because it is hard and complex and we want to get it right.

In case you are interested, here is the new design https://reviews.llvm.org/differential/changeset/?ref=2170825 here the overall code changes currently considered https://reviews.llvm.org/D69542 and here you can find information on our monthly LLVM Alias Analysis call https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL5...

I don't know the root cause of the noalias miscompilation, the thing I was referring to is https://github.com/rust-lang/rust/issues/28728

TL;DR: C++ says that an infinite loop with no side effects is UB, Rust does not. Empty loops in Rust will disappear entirely when they should really loop forever.

(I edited my comment slightly because, re-reading, "blindly" sounds too negative.)

Great point! If anyone is curious about how to write an “empty” loop that is not compiled away, I've seen this common implementation that doesn’t even need the standard library:

loop {

core::sync::atomic::compiler_fence( core::sync::atomic::Ordering::SeqCst);

}

Since https://reviews.llvm.org/D86841, ~ Aug 2020, Clang is able to reason about the forward progress guarantees of the input. For the LLVM-IR handling see https://reviews.llvm.org/D86233. While we are still adding more fine-grained support of different language standards and corner cases, e.g., constant loop condition in C vs. C++, you should be able to tell LLVM a loop is allowed to loop forever w/o side-effect. In fact, that is the new default. That said, LLVM still removes calls to functions without side effect unconditionally. We are working on that, i.a., https://reviews.llvm.org/D94106.