Codegen units break #[inline(always)] at -O0

[alexcrichton]

On the current nightly using multiple codegen units breaks #[inline(always)] in debug mode (as they could show up in different codegen units, preventing inlining). We should still treat #[inline(always)] as inline everywhere!

[alexcrichton]

cc rust-lang/stdarch#108

[alexcrichton]

cc @michaelwoerister

(I can work on this when I get a chance, just wanted to make sure you were aware)

[hanna-kruppe]

Why do we honor inline(always) at -O0 at all? It should be purely an optimization, and I would have hoped we ignore it at -O0 to generate less code faster. While it's useful to have something to override inlining heuristics if optimizations are enabled, I am more than a bit puzzled by any functional change due to it not being honored. Can you explain why stdsimd CI breaks if inline(always) is ignored?

[michaelwoerister]

Yeah, I was thinking that #[inline(always)] functions should be duplicated to all CGU, regardless of other settings. On the other hand, as far as I know, #[inline(always)] is still just a hint to LLVM and does not guarantee inlining either.

[alexcrichton]

@rkruppe sure yeah I can go into some more detail!

So the problem with SIMD is that we actually need these functions to always get inlined to deal with ABI issues. Otherwise we have a function like:

#[target_feature = "+avx"]
unsafe fn foo() {
    let a = i16x16::new(...);
}

So in this case foo is using 256 bit AVX types like i16x16 which means that if i16x16 were actually a function call the return value would be in an AVX register. The i16x16 function, however, is portable and therefore doesn't have a #[target_feature] annotation. Instead we rely on #[inline(always)] to ensure that i16x16::new gets the correct ABI by just using the surrounding function's ABI instead of any one particular ABI.

In essence we rely on #[inline(always)] to erase ABI differences. I've seen this in some other situations where you rely on particular diassembly and whatnot where #[inline(always)] is critical in all modes to work correctly. Other than SIMD though a specific situation isn't coming to mind.

---

As for how we treat this at the LLVM layer, it's actually quite intentional that we always respect #[inline(always)] (otherwise it's not always!). Even with no optimizations we add an always inline pass which mirrors the behavior of clang.

We have said many times before that #[inline] is harmful to compile time and #[inline(always)] is even more harmful. In that sense I wouldn't personally consider it too surprising that #[inline(always)] even has ramifications in debug mode. In general you never need #[inline(always)] unless you're in a SIMD-like situation where the ABI/codegen requires it.

---

@michaelwoerister AFAIK #[inline(always)] truly does always inline it at the LLVM layer whenever it's "reasonable", and the only "unreasonable" situation I've ever encountered is dynamic dispatch where it's impossible to do inlining.

[hanna-kruppe]

@alexcrichton Thanks for elaborating and, ouch, what a nasty problem!