5 ms·

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 LL

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

nathankleyn 5y ago
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 https://github.com/rust-lang/rust/pull/82834 [1]: https://github.com/rust-lang/rust/issues/84958 https://github.com/rust-lang/rust/issues/84958 [2]: https://stackoverflow.com/a/57259339 https://stackoverflow.com/a/57259339
- galangalalgol 5y ago
  Seriously, this has been years now. Is this understandable, or does this tell us something bad about llvm?
  - wnoise 5y ago
    Or something bad about noalias?
  - swsieber 5y ago
    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.
    - galangalalgol 5y ago
      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.
    - galangalalgol 5y ago
      Also there are a lot of fortran compilers using llvm now. Fortran has the information for noalias as well.
    - ghoward 5y ago
      I used it extensively in my bc (https://git.yzena.com/gavin/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#L880 https://git.yzena.com/gavin/bc/src/branch/master/src/num.c#L... .)
  - khuey 5y ago
    This is what happens when you're trying to add a hairy feature to a big legacy codebase.
    - rrdharan 5y ago
      Referring to the LLVM codebase as legacy makes me feel old…
  - zozbot234 5y ago
    > 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.
    - galangalalgol 5y ago
      Initial, yes, but this was first uncovered in Oct 2015. That seems like long enough to fix it.
      - masklinn 5y ago
        It’s not a single bug, it’s a bunch of different bugs in the interactions between noalias and various analysis and optimisation passes.
      - saagarjha 5y ago
        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.
        masklinn 5y ago
        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.
- vvanders 5y ago
  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).
Teknoman117 5y ago
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.
- mhh__ 5y ago
  Why is that not the case with any other language and LTO?
  - donkarma 5y ago
    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.
  - comex 5y ago
    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.
  - pjmlp 5y ago
    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.

nathankleyn 5y ago

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 https://github.com/rust-lang/rust/pull/82834 [1]: https://github.com/rust-lang/rust/issues/84958 https://github.com/rust-lang/rust/issues/84958 [2]: https://stackoverflow.com/a/57259339 https://stackoverflow.com/a/57259339

galangalalgol 5y ago
Seriously, this has been years now. Is this understandable, or does this tell us something bad about llvm?
- wnoise 5y ago
  Or something bad about noalias?
- swsieber 5y ago
  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.
  - galangalalgol 5y ago
    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.
  - galangalalgol 5y ago
    Also there are a lot of fortran compilers using llvm now. Fortran has the information for noalias as well.
  - ghoward 5y ago
    I used it extensively in my bc (https://git.yzena.com/gavin/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#L880 https://git.yzena.com/gavin/bc/src/branch/master/src/num.c#L... .)
- khuey 5y ago
  This is what happens when you're trying to add a hairy feature to a big legacy codebase.
  - rrdharan 5y ago
    Referring to the LLVM codebase as legacy makes me feel old…
- zozbot234 5y ago
  > 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.
  - galangalalgol 5y ago
    Initial, yes, but this was first uncovered in Oct 2015. That seems like long enough to fix it.
    - masklinn 5y ago
      It’s not a single bug, it’s a bunch of different bugs in the interactions between noalias and various analysis and optimisation passes.
    - saagarjha 5y ago
      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.
      - masklinn 5y ago
        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.
vvanders 5y ago
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).

Teknoman117 5y ago

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.

mhh__ 5y ago
Why is that not the case with any other language and LTO?
- donkarma 5y ago
  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.
- comex 5y ago
  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.
- pjmlp 5y ago
  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.