9 ms·

Propagating "noalias" metadata for LLVM has actually finally been enabled again recently in nightly [0]. However it has already caused some regressions so it i

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

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