Hacker News Reader

Comment by vvanders | Hacker News Reader

One of the things I'm really excited about for Rust is restrict semantics are baked right there into the language with &mut/&. I think there were still a few LLVM bugs to flush out(because very little C/C++ code uses restrict by nature of how it subtly explodes when you get it wrong).

In theory when they sort that out Rust should be able to turn on restrict where it applies globally "for free".

View on HN

Propagating "noalias" metadata for LLVM has actually finally been enabled again recently in nightly [0]. However it has already caused some regressions so it is not clear whether we may go through another revert/fix in llvm/reenable cycle [1]. This has happened several times already sadly [2] as, exactly as you say, basically nobody else has forged through these paths in LLVM before.

[0]: https://github.com/rust-lang/rust/pull/82834

[1]: https://github.com/rust-lang/rust/issues/84958

[2]: https://stackoverflow.com/a/57259339

Seriously, this has been years now. Is this understandable, or does this tell us something bad about llvm?

Or something bad about noalias?

This is understandable. Rust really uses restrict semantics in anger compared to any other language I know of. Have you seen restrict used in a c codebase? The LLVM support for restrict just doesn't get exercised much outside of Rust.

I use it in c++ on most signal processing stuff. I think eigen will use it if you don't let it use intrinsics for simd. I also use g++ so I wouldn't have encountered it anyway.

Also there are a lot of fortran compilers using llvm now. Fortran has the information for noalias as well.

I used it extensively in my bc (https://git.yzena.com/gavin/bc) in the math to tell the compiler that the out BigNum is not aliased by any of the in operands. (See https://git.yzena.com/gavin/bc/src/branch/master/src/num.c#L... .)

This is what happens when you're trying to add a hairy feature to a big legacy codebase.

Referring to the LLVM codebase as legacy makes me feel old…

> Is this understandable, or does this tell us something bad about llvm?

LLVM is a large project that's mostly written in pre-modern C++, and "noalias" is a highly non-trivial feature that affects many parts of the compiler in 'cross-cutting' ways. It would be surprising if it did not turn up some initial bugs.

Initial, yes, but this was first uncovered in Oct 2015. That seems like long enough to fix it.

It’s not a single bug, it’s a bunch of different bugs in the interactions between noalias and various analysis and optimisation passes.

Aliasing analysis is a complicated part of the compiler, and it underpins a lot of optimization passes. It’s not an easy thing to bolt on.

TBF the internal API could be designed more pessimistically, as in llvm could drop noalias annotations unless they’re explicitly maintained (/ converted).

This means optimisation phases would need to explicitly opt-in and aliasing optimisations would commonly be missed by default, but it would avoid miscompilations.

Ah damn that's a real shame, something to be said about how rarely restrict is used(I usually only touched it for particle systems or inner loops of components where I knew I was the only iterator).

The other neat thing about Rust is that if you turn on LTO and all of the involved code is Rust, there is no hard ABI. The linker will do all sorts of interesting things with register usage and how to pass data to functions.

Why is that not the case with any other language and LTO?

I think MSVC has some weird things when you call a function and you do this, I don't remember but it had a weird calling convention in the assembly IIRC.

It is. As far as I know, rustc just exposes LLVM’s LTO functionality, without performing any Rust-specific optimizations at link time. So you get the same optimizations as you would with LTO in Clang (C compiler), and indeed you can do cross-language LTO between the two.

Also, even without LTO, LLVM can perform the same ABI optimizations on functions that are local to a single translation unit and not exported to other ones. In Rust that means a function not exported across crate boundaries. In C that means a `static` function.

Besides the sibling comments, this is already highly exploited in JITs for example.

Since only the JIT sees the native code, alongside JIT caches[0] you have basically LTO and PGO data across runs and some call graphs might eventually be collapse into simple basic block, or structs might be reduced to the actual set of fields that are used.

[0] - This includes all modern JVM implementations including the Android cousin, and .NET to certain extent already with usability improvements coming in version 6.

Reply on news.ycombinator.com