Handle Win64 builtins ABI change in LLVM 14 by nikic · Pull Request #455 · rust-...
source link: https://github.com/rust-lang/compiler-builtins/pull/455
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
New issue
Handle Win64 builtins ABI change in LLVM 14 #455
Conversation
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.
Doesn't this need to be cfg gated somehow to retain support for older llvms?
@Mark-Simulacrum Possibly. I assumed this doesn't matter for Windows, where distros linking against system LLVM are not a thing.
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?
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.
Copy link
mati865 commented 12 days ago
@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.
changed the title Remove #[unadjusted_on_win64] from __float functions
Handle Win64 builtins ABI change in LLVM 14
// use Win64 ABI rather than unadjusted ABI. Pick the correct ABI based on the
// llvm14-builtins-abi target feature.
#[cfg(target_feature = "llvm14-builtins-abi")]
Should this target feature be behind a feature gate?
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.
@Mark-Simulacrum Is this plus rust-lang/rust@28423ca on the rustc side what you had in mind?
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.
@Mark-Simulacrum From the few I looked at, it looks like direct users of compiler_builtins are due to rustc-dep-of-std.
Also compiler-builtins only supports nightly Rust anyways.
The msvc try build with this compiler-builtins succeeded, so this is ready for review now.
Published in compiler-builtins 0.1.70.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
No one assigned
None yet
No milestone
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK