Place intrinsics in individual object files

[tmiasko]

No description provided.

[bjorn3]

I think you will need to add #[inline] to all the functions wrapped by the intrinsics to ensure that they are compiled in the same codegen unit as the intrinsic.

[tmiasko]

The interaction with other attributes is not ideal. I had to disable attribute expansions in win64_128bit_abi_hack, this seems fine now, but could be a footgun in a future.

@bjorn3 So far I didn't found it necessary for release builds (based on nm and objdump -r --disassemble). Is it different for you?

[alexcrichton]

Should we perhaps go ahead and just place all intrinsics in their own codegen unit?

And yes it is not necessary to use #[inline] due to ThinLTO.

[tmiasko]

I added #[inline] on undefined symbols from nm to get similar results regardless of ThinLTO.

I cross-validated partitioning with libgcc.a installed on my system. They match with default features, and there is a small mismatch when c feature is enabled. I don't feel much need to change things further, unless there is some specific target that would like me to test against.

[alexcrichton]

I don't think there's any realistic need for more than one symbol per CGU, even if libgcc does something similar. I also think it would be better to automatically place everything with one-symbol-per-object rather than having to manually annotate each function with a new attribute.

[alexcrichton]

Is the #[inline] necessary here for all these functions? I would say that we should probably avoid adding that if we can, only adding it if we profile at some point and see that LLVM isn't doing great-enough inlining.

[tmiasko]

The #[inline] is necessary to get code that doesn't have large amount of trivial indirections for non-ThinLTO builds. I can drop those changes if you want.

[alexcrichton]

I agree yeah that if ThinLTO is disabled it's a problem, but I think ThinLTO is enabled everywhere, so I'm not sure it's a case we need to worry about?

[tmiasko]

In context of official builds, I would expect this to be the case. Hard to say how it used more generally. In any case, we can revisit this aspect later if necessary. I removed inlining changes for now.

[alexcrichton]

Ok I've published 0.1.27 with this now too

[anforowicz]

Hello everyone! Do you remember if using #[no_mangle] rather than #[rustc_std_internal_symbol] was an explicit decision in this PR? The context for this question is https://crbug.com/477565811#comment36. /cc @zmodem as FYI.

[bjorn3]

#[rustc_std_internal_symbol] would mangle the symbols, but LLVM requires them to be unmangled. Rustc does mark all symbols in compiler-builtins with hidden visibility though, even those which are #[no_mangle]: https://github.com/rust-lang/rust/blob/370143facfb348ad3b29749c0393402d76b280c3/compiler/rustc_codegen_llvm/src/mono_item.rs#L73-L78

[bjorn3]

The issue you are hitting with the missing bti instruction is likely https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/bti.20in.20compiler-builtins'.20aarch64.20outline-atomics for which there is a WIP PR at #1063

[bjorn3]

It may be the case that we are forgetting to set hidden visibility for naked functions in compiler builtins. cc @folkertdev

[nico]

The issue you are hitting with the missing bti instruction is likely https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/bti.20in.20compiler-builtins'.20aarch64.20outline-atomics for which there is a WIP PR at #1063

Thanks! To be clear, we think we have the current thing figured out (it is like you say). We're more looking into the more general piece that we'd like things to link against LLVM's copy of compiler-rt instead of against rust's, given that we have a big mixed C++/Rust codebase :)