Handle Win64 builtins ABI change in LLVM 14

[nikic]

As of https://reviews.llvm.org/D110413, these no longer use the unadjusted ABI (and use normal C ABI instead, passing i128 indirectly and returning it as <2 x i64>).

To support both LLVM 14 and older versions, rustc will expose a "llvm14-builtins-abi" target feature, based on which compiler-builtins can chose the appropriate ABI.

This is needed for rust-lang/rust#93577.

[Mark-Simulacrum]

Doesn't this need to be cfg gated somehow to retain support for older llvms?

[nikic]

@Mark-Simulacrum Possibly. I assumed this doesn't matter for Windows, where distros linking against system LLVM are not a thing.

[nikic]

If we want this gated on LLVM version, would it be acceptable to call $RUSTC -vV from build.rs and parse the LLVM version from there?

[Mark-Simulacrum]

Hm. Probably not, unfortunately. The RUSTC available to build scripts may differ from that used to actually compile the code, particularly for std dependencies (since build scripts link to std themselves, we have to be a little fancy there).

We could expose an unstable target feature like "float-abi-llvm-14" or something that is used here, though, from rustc? Presumably if we cfg_attr on that, then we get the right behavior without needing build script hacks or similar, but also not exposing any new stable surface area from rustc. Once we bump min LLVM to 14, it could be dropped.

[mati865]

@Mark-Simulacrum Possibly. I assumed this doesn't matter for Windows, where distros linking against system LLVM are not a thing.

It's niche but does exist, at MSYS2 we link to LLVM 13 right now but plan to move to LLVM 14 as soon as it's released.
Another use case I can think of is cross compiling, Fedora does build multiple targets (including mingw-w64) for their system Rust package.

[bjorn3]

Should this target feature be behind a feature gate?

[nikic]

Apparently, we don't feature-gate #[cfg(target_feature)] (though we do gate #[target_feature]). cfg(target_feature) exposes all unstable target features on nightly builds.

[nikic]

@Mark-Simulacrum Is this plus rust-lang/rust@28423ca on the rustc side what you had in mind?

[Mark-Simulacrum]

Yeah, this seems to match my expectation.

One thought I do have: since out-of-tree users of compiler-builtins (https://crates.io/crates/compiler_builtins/reverse_dependencies, at least) are using this crate directly, there's an unfortunate situation where we're basically forced to leave this cfg gate in indefinitely unless we bump the MSRV for the crate to a new enough rustc -- I'm not sure what our policies there look like.

[nikic]

@Mark-Simulacrum From the few I looked at, it looks like direct users of compiler_builtins are due to rustc-dep-of-std.

[Amanieu]

Also compiler-builtins only supports nightly Rust anyways.

[nikic]

The msvc try build with this compiler-builtins succeeded, so this is ready for review now.

[Amanieu]

Published in compiler-builtins 0.1.70.