Hacker News Reader

Comment by Blikkentrekker | Hacker News Reader

Is a great deal of actual Rust behavior not fairly intimately tied to LLVM? As far as I know it leaks various LLVM details and much of the documentation about various functions documents them as being little more than a thin wrapper to various LLVM internals.

View on HN

IMHO, "great deal" is overemphasizing it. There are some things, yes, but they are mostly smaller, more niche details that are even probably things we'd choose ourselves in many cases.

That being said, there's also cases where Rust does not have LLVM semantics, and that can cause bugs. Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias.

> Some famous examples being the loop optimization miscompilation, and &mut T currently not being marked noalias.

I don't think that's a case where Rust "doesn't have LLVM semantics" since the miscompilation was reproduced in standard C. Rather that rust is actively and ubiquitously leveraging otherwise rarely-exercised LLVM features, revealing a bunch of bugs (either leftovers or breakages) in them.

The latter, you're right, I did make a mistake here. I was thinking of it as "Rust doesn't just do whatever LLVM does, see, we have semantics and LLVM compiles them wrong, so this is an example of that" but I forgot that actually, we do specify "this follows what LLVM does" currently, and the miscompilation is just a plain bug. Extra embarrassing because IIRC I was the one who made the PR saying that.

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

> 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?)

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.

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

Notice that in C and C++ loops that might not terminate are UB, while in Rust they are just infinite loops.

So there is a significant difference in semantics between Rust and C/C++ here.

C and C++ actually differ in semantics here; C allows infinite loops that are controlled by a constant expression.

Generally, yes. Though, as always, these things are hard to summarize in one sentence and depend on the standard version (pre/post C++11). This post might shed some light on the options we are considering for Clang right now: https://reviews.llvm.org/D94367#2489090

Just what is gained by failing to loop forever? It seems like a really low-value optimization. Nearly always, the optimization would violate the programmer's intent or it would change an ordinary bug into a confusing bug. An infinite loop is not very many bytes on any processor.

The standard may allow the generation of insane code, but a decent-quality compiler does not do so. The standard ought to be fixed.

The infinite loop being UB was added because it prevents some important code motion optimizations and makes it hard to reason about the memory model. You can find the details on the papers leading to the C++11 memory model.

Uh, so what?

Letting the compiler assume that a "switch" without a default will never go there is a great optimization too. Why not put that in the standard?

Actually, this is worse. Letting the loop be UB is like letting a true "if" be UB. Just never mind the code actually written; surely it doesn't mean what it says.

> Letting the compiler assume that a "switch" without a default will never go there is a great optimization too. Why not put that in the standard?

that's actually the case already. A missing default is UB if the switch condition does not match any of the cases. And C compilers already optimize accordingly.

> The infinite loop being UB was added because it prevents some important code motion optimizations

Which ones?

If this optimizations are so important, how come Rust was designed in such a way to make them impossible? Also, how does this fit, e.g., the benchmark game results which show that Rust is faster than C for all benchmarks considered there ?

Store sinking for example, which is unsafe unless the loop is guaranteed to terminate.

C does not have this guarantee (at least not in all cases). Also rust is compiled with the llvm backend, so my understanding is that in practice rust assumes that loops terminate. See:

https://github.com/rust-lang/rust/issues/28728

There are llvm directives that can be added to prevent the optimization, but they are rejected by the rust maintainers exactly because they would cause performance regressions.

Loops that do nothing and don't terminate.

If your loop infinitely writes the number 70 to an atomic int, it's fine.

If by "nothing" you mean "nothing but looping", then yes, you are right. Any loop that "just loops" is doing something by definition: looping.

It depends on your perspective. Normally when I talk about what a loop "does", I am talking purely about the contents of the loop.

Potentially but there are alternative backends like cranelift so it's unlikely anything major is tied to just LLVM anymore

I'd find that very surprising and interesting - I can't imagine which semantics could leak from LLVM into a language specification. Can you give some examples?

For instance `std::ptr::offset` which is apparently a trivial wrapper around some LLVM internal: https://llvm.org/docs/LangRef.html#getelementptr-instruction

I'm not sure as to what capacity GCC has a similar instruction but I heard that LLVM's using of signed integers here is apparently nonstandard and what lead to Rust's decisions for vectors to be limited to a certain size: https://doc.rust-lang.org/nomicon/vec-alloc.html

I don’t know why you’re italicizing LLVM, gcc, and Rust, but I (and perhaps others) find it relatively jarring as my brain automatically parses it as emphasis even though it clearly isn’t intended to be.

I only bring it up because it pretty drastically harms readability (for me at least, and to a degree I frankly find surprising). Just thought you may want to know.

Looking at their commenting history, they have a habit of italicising really often, so it's not specific to this topic. It does indeed make a lot of their comments annoying to read without obviously adding any value.

> It does indeed make a lot of their comments annoying to read without obviously adding any value

I’m going to assume that you mean that the italics don’t add value, and not their comments as a whole. I think your comment could be read either way. Anyways, even so others have since pointed out reasons why the might be used to doing so.

This is common nomenclature to enhance readability in fields that have a large number of neologisms and proper nouns, such as some technical domains, medicine, investment banking, and so on. It's particularly useful when names are in the same language as the base language (e.g. in English "Peter" is easily recognized as a name, but "better fish" means something in the language, but can also be used as a proper noun, so using italics for proper nouns serves to disambiguate the intended meaning).

Maybe he is used to writing in MLA style which calls for the titles of software to be italicized just as books, movies, etc are.

This is indeed a point of contention among different styles of whether software titles should be italicized. Though the position that they should uniformly be is the minority one, it is certainly used by some outlets with considerable weight, and I believe it to be the consistent one if titles of books and films are too.

Some style guides make the even more inconsistent distinction that only titles of video games be italicized, but titles of “application software” not be.

I suppose that on H.N., where such software is frequently mentioned, it does stand out more.

The video games example seems consistent to me; we regularly italicize the names of plays (for example) but not the names of tools and businesses.

Because tools and businesses are not titles that qualify for intellectual property, a piece of software is.

I do not italicize Google the company either, but I do that of Google the search engine.

The titles of scientific research papers are also typically italicized.

Glibc malloc also limits the maximum according to ptrdiff_t, which is effectively the same as Rust isize.

getelementptr is just some pointer arithmetic - all backends can do that.

And using signed integers is unusual yes, but again all backends (obviously) also support signed integers.

IMHO, "Just some pointer arithmetic" is selling it a bit short. There's a lot of stuff there around provenance that matters, that is, there's a reason this is an intrinsic and not just a subtraction after casting both to an int.

(I agree on the signed integer thing though.)

I don't think much of the stable functionality exposes llvm internals. Part of stabilizing is removing the llvm leaks into the language.

Reply on news.ycombinator.com