-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
explicitly set float ABI for all ARM targets #134932
Conversation
r? @chenyukang rustbot has assigned @chenyukang. Use |
These commits modify compiler targets. |
@@ -23,6 +23,7 @@ pub(crate) fn target() -> Target { | |||
data_layout: "e-m:w-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64".into(), | |||
arch: "arm".into(), | |||
options: TargetOptions { | |||
llvm_floatabi: Some(FloatAbi::Hard), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume Windows uses a hardfloat ABI? The abi
field is left empty it seems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
@@ -13,6 +13,7 @@ pub(crate) fn target() -> Target { | |||
data_layout: "e-m:w-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64".into(), | |||
arch: "arm".into(), | |||
options: TargetOptions { | |||
llvm_floatabi: Some(FloatAbi::Hard), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here re: Windows
@@ -105,6 +105,7 @@ pub(crate) fn base( | |||
) -> (TargetOptions, StaticCow<str>, StaticCow<str>) { | |||
let opts = TargetOptions { | |||
abi: abi.target_abi().into(), | |||
llvm_floatabi: Some(FloatAbi::Hard), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume all the Apple targets use a hardfloat ABI? This is about armv7s_apple_ios.rs and armv7k_apple_watchos.rs. Both of these set +neon
in their target features. LLVM switches to hardfloats for (TargetTriple.isOSBinFormatMachO() && TargetTriple.getSubArch() == Triple::ARMSubArch_v7em)
, not sure if that applies here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is my understanding, yeah, and matches what Clang reports when you try to use a different float ABI:
$ touch foo.c
$ xcrun -sdk watchos clang -target armv7k-apple-watchos -S -c foo.c -mfloat-abi=hard # Succeeds
$ xcrun -sdk watchos clang -target armv7k-apple-watchos -S -c foo.c -mfloat-abi=soft # Fails
clang: error: unsupported option '-mfloat-abi=soft' for target 'thumbv7k-apple-watchos'
clang: error: unsupported option '-mfloat-abi=soft' for target 'thumbv7k-apple-watchos'
clang: error: unsupported option '-mfloat-abi=soft' for target 'thumbv7k-apple-watchos'
clang: error: unsupported option '-mfloat-abi=soft' for target 'thumbv7k-apple-watchos'
$ xcrun -sdk watchos clang -target armv7s-apple-watchos -S -c foo.c -mfloat-abi=hard # Succeeds
$ xcrun -sdk watchos clang -target armv7s-apple-watchos -S -c foo.c -mfloat-abi=soft # Fails
clang: error: unsupported option '-mfloat-abi=soft' for target 'thumbv7s-apple-watchos'
clang: error: unsupported option '-mfloat-abi=soft' for target 'thumbv7s-apple-watchos'
clang: error: unsupported option '-mfloat-abi=soft' for target 'thumbv7s-apple-watchos'
clang: error: unsupported option '-mfloat-abi=soft' for target 'thumbv7s-apple-watchos'
Soft, | ||
Hard, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some documentation about what each variant mean would be great ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what to say here other than "use softfloat ABI" vs "use hardfloat ABI", which seems a bit pointless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could hypothetically say something about what "soft float" and "hard float" mean, but I think that is something we should consider as a more general topic.
2b57cdf
to
396c765
Compare
9f134ad
to
bee752c
Compare
bee752c
to
c3189c5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this is fine.
@bors r+ rollup |
…ubilee explicitly set float ABI for all ARM targets We currently always set the `FloatABIType` field in the LLVM target machine to `Default`, which means LLVM infers the ARM float ABI (hard vs soft) from the LLVM target triple. This causes problems such as having to set the LLVM triple to `*-gnueabi` for our `musleabi` targets to ensure they get correctly inferred as soft-float targets. It also means rustc doesn't really know which float ABI ends up being used, which is a blocker for rust-lang#134794. So I think we should stop doing that and instead explicitly control that value. That's what this PR implements. See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fwg-llvm/topic/Softfloat.20ABI.2C.20hardfloat.20instructions) for more context. Best reviewed commit-by-commit. I hope I got all those `llvm_floatabi` values right...
Rollup of 7 pull requests Successful merges: - rust-lang#133461 (Add COPYRIGHT-*.html files to distribution and update `COPYRIGHT`) - rust-lang#134919 (bootstrap: Make `./x test compiler` actually run the compiler unit tests) - rust-lang#134927 (Make slice::as_flattened_mut unstably const) - rust-lang#134930 (ptr docs: make it clear that we are talking only about memory accesses) - rust-lang#134932 (explicitly set float ABI for all ARM targets) - rust-lang#134934 (Fix typos) - rust-lang#134941 (compiler: Add a statement-of-intent to `rustc_abi`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 8 pull requests Successful merges: - rust-lang#134919 (bootstrap: Make `./x test compiler` actually run the compiler unit tests) - rust-lang#134927 (Make slice::as_flattened_mut unstably const) - rust-lang#134930 (ptr docs: make it clear that we are talking only about memory accesses) - rust-lang#134932 (explicitly set float ABI for all ARM targets) - rust-lang#134933 (Make sure we check the future type is `Sized` in `AsyncFn*`) - rust-lang#134934 (Fix typos) - rust-lang#134941 (compiler: Add a statement-of-intent to `rustc_abi`) - rust-lang#134949 (Convert some `Into` impls into `From` impls) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#134932 - RalfJung:arm-float-abi, r=workingjubilee explicitly set float ABI for all ARM targets We currently always set the `FloatABIType` field in the LLVM target machine to `Default`, which means LLVM infers the ARM float ABI (hard vs soft) from the LLVM target triple. This causes problems such as having to set the LLVM triple to `*-gnueabi` for our `musleabi` targets to ensure they get correctly inferred as soft-float targets. It also means rustc doesn't really know which float ABI ends up being used, which is a blocker for rust-lang#134794. So I think we should stop doing that and instead explicitly control that value. That's what this PR implements. See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fwg-llvm/topic/Softfloat.20ABI.2C.20hardfloat.20instructions) for more context. Best reviewed commit-by-commit. I hope I got all those `llvm_floatabi` values right...
We currently always set the
FloatABIType
field in the LLVM target machine toDefault
, which means LLVM infers the ARM float ABI (hard vs soft) from the LLVM target triple. This causes problems such as having to set the LLVM triple to*-gnueabi
for ourmusleabi
targets to ensure they get correctly inferred as soft-float targets. It also means rustc doesn't really know which float ABI ends up being used, which is a blocker for #134794. So I think we should stop doing that and instead explicitly control that value. That's what this PR implements.See Zulip for more context.
Best reviewed commit-by-commit. I hope I got all those
llvm_floatabi
values right...