arm64: rust: clean Rust 1.85.0 warning using softfloat target
Subsystems (3)
Miguel Ojeda
maintainerPATCH 1/1 arm64: rust: clean Rust 1.85.0 warning using softfloat target
Starting with Rust 1.85.0 (to be released 2025-02-20), rustc warns
[1] about disabling neon in the aarch64 hardfloat target:
warning: target feature neon cannot be toggled with
-Ctarget-feature: unsound on hard-float targets because it changes float ABI
|
= note: this was previously accepted by the compiler but
is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344
<https://github.com/rust-lang/rust/issues/116344>
Thus, instead, use the softfloat target instead.
While trying it out, I found that the kernel sanitizers were not enabled for that built-in target [2]. Upstream Rust agreed to backport the enablement for the current beta so that it is ready for the 1.85.0 release [3] -- thanks!
However, that still means that before Rust 1.85.0, we cannot switch since sanitizers could be in use. Thus conditionally do so.
---
Matthew: if you could please give this a go and confirm that it is fine for Android (with sanitizers enabled, for 1.84.1 and 1.85.0), then a Tested-by tag would be great. Thanks!
I would like to get this one into -rc3 if possible so that by the time the compiler releases we are already clean.
I am sending another patch to introduce rustc-min-version and use it here, but I am doing so after this one rather than before so that this fix can be as simple as possible.
arch/arm64/Makefile | 4 ++++ 1 file changed, 4 insertions(+)
arch/arm64/Makefile +4 -0
@@ -48,7 +48,11 @@ KBUILD_CFLAGS += $(CC_FLAGS_NO_FPU) \ KBUILD_CFLAGS += $(call cc-disable-warning, psabi) KBUILD_AFLAGS += $(compat_vdso) +ifeq ($(call test-ge, $(CONFIG_RUSTC_VERSION), 108500),y) +KBUILD_RUSTFLAGS += --target=aarch64-unknown-none-softfloat +else KBUILD_RUSTFLAGS += --target=aarch64-unknown-none -Ctarget-feature="-neon" +endif KBUILD_CFLAGS += $(call cc-option,-mabi=lp64) KBUILD_AFLAGS += $(call cc-option,-mabi=lp64)
base-commit: a64dcfb451e254085a7daee5fe51bf22959d52d3 --
2.48.1
Will Deacon
maintainerQuoted 35 lines · Miguel Ojeda
Starting with Rust 1.85.0 (to be released 2025-02-20),
rustcwarns
[1] about disabling neon in the aarch64 hardfloat target:warning: target feature
neoncannot be toggled with
-Ctarget-feature: unsound on hard-float targets because it changes float ABI
|
= note: this was previously accepted by the compiler but
is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344
<https://github.com/rust-lang/rust/issues/116344>Thus, instead, use the softfloat target instead.
While trying it out, I found that the kernel sanitizers were not enabled for that built-in target [2]. Upstream Rust agreed to backport the enablement for the current beta so that it is ready for the 1.85.0 release [3] -- thanks!
However, that still means that before Rust 1.85.0, we cannot switch since sanitizers could be in use. Thus conditionally do so.
Cc <[email protected]> # Needed in 6.12.y and 6.13.y only (Rust is pinned in older LTSs).Cc Catalin Marinas <[email protected]>Cc Will Deacon <[email protected]>Cc Matthew Maurer <[email protected]>Cc Alice Ryhl <[email protected]>Cc Ralf Jung <[email protected]>Cc Jubilee Young <[email protected]>Signed-off-by Miguel Ojeda <[email protected]>
Quoted 4 lines
---
Matthew: if you could please give this a go and confirm that it is fine for Android (with sanitizers enabled, for 1.84.1 and 1.85.0), then a Tested-by tag would be great. Thanks!
Patch looks fine to me, but I'll wait for Matthew to confirm that it works for them. I'm also fine with adding the rustc-min-version helper at the same time, tbh -- it's not exactly rocket science, but it would need an Ack from Masahiro.
Will
Quoted 5 lines · Will Deacon
Patch looks fine to me, but I'll wait for Matthew to confirm that it works for them. I'm also fine with adding the rustc-min-version helper at the same time, tbh -- it's not exactly rocket science, but it would need an Ack from Masahiro.
Thanks Will -- happy to take it through the Rust tree for if needed with your Ack, I have to send a couple other bits anyway for -rc3.
And, yeah, I went back and forth on whether to do the helper directly... :)
Cheers,
Miguel
Quoted 24 lines · Miguel Ojeda
Starting with Rust 1.85.0 (to be released 2025-02-20),
rustcwarns
[1] about disabling neon in the aarch64 hardfloat target:warning: target feature
neoncannot be toggled with
-Ctarget-feature: unsound on hard-float targets because it changes float ABI
|
= note: this was previously accepted by the compiler but
is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344
<https://github.com/rust-lang/rust/issues/116344>Thus, instead, use the softfloat target instead.
While trying it out, I found that the kernel sanitizers were not enabled for that built-in target [2]. Upstream Rust agreed to backport the enablement for the current beta so that it is ready for the 1.85.0 release [3] -- thanks!
However, that still means that before Rust 1.85.0, we cannot switch since sanitizers could be in use. Thus conditionally do so.
Quoted 12 lines
Cc <[email protected]> # Needed in 6.12.y and 6.13.y only (Rust is pinned in older LTSs).Cc Catalin Marinas <[email protected]>Cc Will Deacon <[email protected]>Cc Matthew Maurer <[email protected]>Cc Alice Ryhl <[email protected]>Cc Ralf Jung <[email protected]>Cc Jubilee Young <[email protected]>Signed-off-by Miguel Ojeda <[email protected]>
This is consistent with what has been discussed for a while on the Rust side.
Matthew Maurer
Tested-byI successfully booted this on the emulator (with some additional patches to our system unrelated to this issue), so
Quoted 42 lines · Trevor Gross
Quoted 24 lines · Miguel Ojeda
Starting with Rust 1.85.0 (to be released 2025-02-20),
rustcwarns
[1] about disabling neon in the aarch64 hardfloat target:warning: target feature
neoncannot be toggled with
-Ctarget-feature: unsound on hard-float targets because it changes float ABI
|
= note: this was previously accepted by the compiler but
is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344
<https://github.com/rust-lang/rust/issues/116344>Thus, instead, use the softfloat target instead.
While trying it out, I found that the kernel sanitizers were not enabled for that built-in target [2]. Upstream Rust agreed to backport the enablement for the current beta so that it is ready for the 1.85.0 release [3] -- thanks!
However, that still means that before Rust 1.85.0, we cannot switch since sanitizers could be in use. Thus conditionally do so.
Quoted 12 lines
Cc <[email protected]> # Needed in 6.12.y and 6.13.y only (Rust is pinned in older LTSs).Cc Catalin Marinas <[email protected]>Cc Will Deacon <[email protected]>Cc Matthew Maurer <[email protected]>Cc Alice Ryhl <[email protected]>Cc Ralf Jung <[email protected]>Cc Jubilee Young <[email protected]>Signed-off-by Miguel Ojeda <[email protected]>This is consistent with what has been discussed for a while on the Rust side.
Reviewed-by Trevor Gross <[email protected]>
Ralf Jung
Reviewed-byQuoted 38 lines · Trevor Gross
Quoted 24 lines · Miguel Ojeda
Starting with Rust 1.85.0 (to be released 2025-02-20),
rustcwarns
[1] about disabling neon in the aarch64 hardfloat target:warning: target feature
neoncannot be toggled with
-Ctarget-feature: unsound on hard-float targets because it changes float ABI
|
= note: this was previously accepted by the compiler but
is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344
<https://github.com/rust-lang/rust/issues/116344>Thus, instead, use the softfloat target instead.
While trying it out, I found that the kernel sanitizers were not enabled for that built-in target [2]. Upstream Rust agreed to backport the enablement for the current beta so that it is ready for the 1.85.0 release [3] -- thanks!
However, that still means that before Rust 1.85.0, we cannot switch since sanitizers could be in use. Thus conditionally do so.
Quoted 12 lines
Cc <[email protected]> # Needed in 6.12.y and 6.13.y only (Rust is pinned in older LTSs).Cc Catalin Marinas <[email protected]>Cc Will Deacon <[email protected]>Cc Matthew Maurer <[email protected]>Cc Alice Ryhl <[email protected]>Cc Ralf Jung <[email protected]>Cc Jubilee Young <[email protected]>Signed-off-by Miguel Ojeda <[email protected]>
Quoted 3 lines
This is consistent with what has been discussed for a while on the Rust side.
Reviewed-by Trevor Gross <[email protected]>
I don't know the kernel side of this, but from a Rust compiler perspective using the "-softfloat" target is definitely the right call here, at least for now (where none of the crypto/compression code that needs SIMD is written in Rust).
Kind regards,
Ralf
Quoted 24 lines · Miguel Ojeda
Starting with Rust 1.85.0 (to be released 2025-02-20),
rustcwarns
[1] about disabling neon in the aarch64 hardfloat target:warning: target feature
neoncannot be toggled with
-Ctarget-feature: unsound on hard-float targets because it changes float ABI
|
= note: this was previously accepted by the compiler but
is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344
<https://github.com/rust-lang/rust/issues/116344>Thus, instead, use the softfloat target instead.
While trying it out, I found that the kernel sanitizers were not enabled for that built-in target [2]. Upstream Rust agreed to backport the enablement for the current beta so that it is ready for the 1.85.0 release [3] -- thanks!
However, that still means that before Rust 1.85.0, we cannot switch since sanitizers could be in use. Thus conditionally do so.
Quoted 12 lines
Cc <[email protected]> # Needed in 6.12.y and 6.13.y only (Rust is pinned in older LTSs).Cc Catalin Marinas <[email protected]>Cc Will Deacon <[email protected]>Cc Matthew Maurer <[email protected]>Cc Alice Ryhl <[email protected]>Cc Ralf Jung <[email protected]>Cc Jubilee Young <[email protected]>Signed-off-by Miguel Ojeda <[email protected]>
Thanks Matt for boot-testing it.
Quoted 13 lines · Miguel Ojeda
Starting with Rust 1.85.0 (to be released 2025-02-20),
rustcwarns
[1] about disabling neon in the aarch64 hardfloat target:warning: target feature
neoncannot be toggled with
-Ctarget-feature: unsound on hard-float targets because it changes float ABI
|
= note: this was previously accepted by the compiler but
is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344
<https://github.com/rust-lang/rust/issues/116344>
Quoted 1 line
[...]
Applied to arm64 (for-next/fixes), thanks!
[1/1] arm64: rust: clean Rust 1.85.0 warning using softfloat target
https://git.kernel.org/arm64/c/446a8351f160
Cheers,
Signature · 5 lines
Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev
Quoted 14 lines · Miguel Ojeda
Starting with Rust 1.85.0 (to be released 2025-02-20),
rustcwarns
[1] about disabling neon in the aarch64 hardfloat target:warning: target feature
neoncannot be toggled with
-Ctarget-feature: unsound on hard-float targets because it changes float ABI
|
= note: this was previously accepted by the compiler but
is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344
<https://github.com/rust-lang/rust/issues/116344>
Quoted 2 lines
Thus, instead, use the softfloat target instead.
We have to carefully make the distinction here between codegen and ABI.
The arm64 C code in the kernel is built with -mgeneral-regs-only because FP/SIMD registers are not preserved/restored like GPRs, and so they must be used only in carefully controlled circumstances, i.e., in assembler code called under kernel_neon_begin()/kernel_neon_end() [modulo some exceptions related to NEON intrinsics]
This does not impact the ABI, which remains hard-float [this was the only arm64 calling convention that existed until about a year ago]. Any function that takes or returns floats or doubles (or NEON intrinsic types) is simply rejected by the compiler.
Changing this to softfloat for Rust modifies this calling convention, i.e., it will result in floats and doubles being accepted as function parameters and return values, but there is no code in the kernel that actually supports/implements that. Also, it should be clarified whether using a softfloat ABI permits the compiler to use FP/SIMD registers in codegen. We might still need -Ctarget-feature="-neon" here afaict.
Ideally, we'd have a target/target-feature combo that makes this more
explicit: no FP/SIMD codegen at all, without affecting the ABI, therefore making float/double types in function prototypes illegal. AIUI, this change does something different.
Hi all,
Quoted 8 lines
We have to carefully make the distinction here between codegen and ABI.
The arm64 C code in the kernel is built with -mgeneral-regs-only because FP/SIMD registers are not preserved/restored like GPRs, and so they must be used only in carefully controlled circumstances, i.e., in assembler code called under kernel_neon_begin()/kernel_neon_end() [modulo some exceptions related to NEON intrinsics]
Quoted 4 lines
This does not impact the ABI, which remains hard-float [this was the only arm64 calling convention that existed until about a year ago]. Any function that takes or returns floats or doubles (or NEON intrinsic types) is simply rejected by the compiler.
That's how C works. It is not how Rust works. Rust does not reject using floats ever. Instead, Rust offers softfloat targets where you can still use floats, but it won't use float registers. Obviously, that needs to use a different ABI.
As you said, aarch64 does not have an official softfloat ABI, but LLVM implements a de-facto softfloat ABI if you ask it to generate functions that take/return float types while disabling the relevant target features. (Maybe LLVM should just refuse to generate such code, and then Rust may have ended up with a different design. But now this would all be quite tricky to change.)
Quoted 4 lines
Changing this to softfloat for Rust modifies this calling convention, i.e., it will result in floats and doubles being accepted as function parameters and return values, but there is no code in the kernel that actually supports/implements that.
As explained above, f32/f64 were already accepted as function parameters and return values in Rust code before this change. So this patch does not change anything here. (In fact, the ABI used for these functions should be exactly the same before and after this patch.)
Quoted 4 lines
Also, it should be clarified
whether using a softfloat ABI permits the compiler to use FP/SIMD registers in codegen. We might still need -Ctarget-feature="-neon" here afaict.
Rust's softfloat targets do not use FP/SIMD registers by default. Ideally these targets allow selectively using FP/SIMD registers within certain functions; for aarch64, this is not properly supported by LLVM and therefore Rust.
Quoted 4 lines
Ideally, we'd have a target/target-feature combo that makes this more
explicit: no FP/SIMD codegen at all, without affecting the ABI, therefore making float/double types in function prototypes illegal. AIUI, this change does something different.
Having targets without float support would be a significant departure from past language decisions in Rust -- that doesn't mean it's impossible, but it would require a non-trivial effort (starting with an RFC to lay down the motivation and design).
Kind regards,
Ralf
Gary Guo
reviewerQuoted 10 lines · On Thu, 13 Feb 2025 16:46:22 +0100 Ralf Jung <[email protected]> wrote:
Hi all,
Quoted 8 lines
We have to carefully make the distinction here between codegen and ABI.
The arm64 C code in the kernel is built with -mgeneral-regs-only because FP/SIMD registers are not preserved/restored like GPRs, and so they must be used only in carefully controlled circumstances, i.e., in assembler code called under kernel_neon_begin()/kernel_neon_end() [modulo some exceptions related to NEON intrinsics]
Quoted 8 lines
Quoted 4 lines
This does not impact the ABI, which remains hard-float [this was the only arm64 calling convention that existed until about a year ago]. Any function that takes or returns floats or doubles (or NEON intrinsic types) is simply rejected by the compiler.
That's how C works. It is not how Rust works. Rust does not reject using floats ever. Instead, Rust offers softfloat targets where you can still use floats, but it won't use float registers. Obviously, that needs to use a different ABI.
That's today's situation, although we do prefer to be able to turn off floats completely (and also not have to compile parts of libcore that's related to floats).
We mentioned this to the lang team a couple of times, and they do acknolwedge there might be a need for it, although it's not something that today's Rust can handle well (i.e. no feature disabling for libcore).
We have also listed this in
https://github.com/Rust-for-Linux/linux/issues/2 and
https://github.com/Rust-for-Linux/linux/issues/514.
Quoted 39 lines
As you said, aarch64 does not have an official softfloat ABI, but LLVM implements a de-facto softfloat ABI if you ask it to generate functions that take/return float types while disabling the relevant target features. (Maybe LLVM should just refuse to generate such code, and then Rust may have ended up with a different design. But now this would all be quite tricky to change.)
Quoted 4 lines
Changing this to softfloat for Rust modifies this calling convention, i.e., it will result in floats and doubles being accepted as function parameters and return values, but there is no code in the kernel that actually supports/implements that.
As explained above, f32/f64 were already accepted as function parameters and return values in Rust code before this change. So this patch does not change anything here. (In fact, the ABI used for these functions should be exactly the same before and after this patch.)
Quoted 4 lines
Also, it should be clarified
whether using a softfloat ABI permits the compiler to use FP/SIMD registers in codegen. We might still need -Ctarget-feature="-neon" here afaict.Rust's softfloat targets do not use FP/SIMD registers by default. Ideally these targets allow selectively using FP/SIMD registers within certain functions; for aarch64, this is not properly supported by LLVM and therefore Rust.
Quoted 4 lines
Ideally, we'd have a target/target-feature combo that makes this more
explicit: no FP/SIMD codegen at all, without affecting the ABI, therefore making float/double types in function prototypes illegal. AIUI, this change does something different.Having targets without float support would be a significant departure from past language decisions in Rust -- that doesn't mean it's impossible, but it would require a non-trivial effort (starting with an RFC to lay down the motivation and design).
Kind regards,
Ralf
Quoted 30 lines · Ralf Jung
Hi all,
Quoted 8 lines
We have to carefully make the distinction here between codegen and ABI.
The arm64 C code in the kernel is built with -mgeneral-regs-only because FP/SIMD registers are not preserved/restored like GPRs, and so they must be used only in carefully controlled circumstances, i.e., in assembler code called under kernel_neon_begin()/kernel_neon_end() [modulo some exceptions related to NEON intrinsics]
Quoted 4 lines
This does not impact the ABI, which remains hard-float [this was the only arm64 calling convention that existed until about a year ago]. Any function that takes or returns floats or doubles (or NEON intrinsic types) is simply rejected by the compiler.
That's how C works. It is not how Rust works. Rust does not reject using floats ever. Instead, Rust offers softfloat targets where you can still use floats, but it won't use float registers. Obviously, that needs to use a different ABI. As you said, aarch64 does not have an official softfloat ABI, but LLVM implements a de-facto softfloat ABI if you ask it to generate functions that take/return float types while disabling the relevant target features. (Maybe LLVM should just refuse to generate such code, and then Rust may have ended up with a different design. But now this would all be quite tricky to change.)
Quoted 4 lines
Changing this to softfloat for Rust modifies this calling convention, i.e., it will result in floats and doubles being accepted as function parameters and return values, but there is no code in the kernel that actually supports/implements that.
Quoted 5 lines
As explained above, f32/f64 were already accepted as function parameters and return values in Rust code before this change. So this patch does not change anything here. (In fact, the ABI used for these functions should be exactly the same before and after this patch.)
OK, so can I summarize the above as
- Rust calling Rust will work fine and happily use float types without using FP/SIMD registers in codegen;
- Rust calling C or C calling Rust will not support float or double arguments or return values due to the restrictions imposed by the C compiler.
?
Quoted 9 lines
Quoted 4 lines
Also, it should be clarified
whether using a softfloat ABI permits the compiler to use FP/SIMD registers in codegen. We might still need -Ctarget-feature="-neon" here afaict.Rust's softfloat targets do not use FP/SIMD registers by default. Ideally these targets allow selectively using FP/SIMD registers within certain functions; for aarch64, this is not properly supported by LLVM and therefore Rust.
I read this as 'this default behavior might change in the future', and so -Ctarget-feature="-neon" should be added even if it is redundant at this point in time.
Quoted 10 lines
Quoted 4 lines
Ideally, we'd have a target/target-feature combo that makes this more
explicit: no FP/SIMD codegen at all, without affecting the ABI, therefore making float/double types in function prototypes illegal. AIUI, this change does something different.Having targets without float support would be a significant departure from past language decisions in Rust -- that doesn't mean it's impossible, but it would require a non-trivial effort (starting with an RFC to lay down the motivation and design).
Fair enough. The codegen is all that matters, and there are other cases (e.g., spilling) where the compiler may decide to use FP/SIMD registers without any floats or doubles in sight. In fact, there are swaths of non-performance critical floating point code in the AMDGPU driver where it would be useful to have float/double support using softfloat codegen too.
Hi,
Quoted 35 lines
Quoted 27 lines
Quoted 8 lines
We have to carefully make the distinction here between codegen and ABI.
The arm64 C code in the kernel is built with -mgeneral-regs-only because FP/SIMD registers are not preserved/restored like GPRs, and so they must be used only in carefully controlled circumstances, i.e., in assembler code called under kernel_neon_begin()/kernel_neon_end() [modulo some exceptions related to NEON intrinsics]
Quoted 4 lines
This does not impact the ABI, which remains hard-float [this was the only arm64 calling convention that existed until about a year ago]. Any function that takes or returns floats or doubles (or NEON intrinsic types) is simply rejected by the compiler.
That's how C works. It is not how Rust works. Rust does not reject using floats ever. Instead, Rust offers softfloat targets where you can still use floats, but it won't use float registers. Obviously, that needs to use a different ABI. As you said, aarch64 does not have an official softfloat ABI, but LLVM implements a de-facto softfloat ABI if you ask it to generate functions that take/return float types while disabling the relevant target features. (Maybe LLVM should just refuse to generate such code, and then Rust may have ended up with a different design. But now this would all be quite tricky to change.)
Quoted 4 lines
Changing this to softfloat for Rust modifies this calling convention, i.e., it will result in floats and doubles being accepted as function parameters and return values, but there is no code in the kernel that actually supports/implements that.
Quoted 5 lines
As explained above, f32/f64 were already accepted as function parameters and return values in Rust code before this change. So this patch does not change anything here. (In fact, the ABI used for these functions should be exactly the same before and after this patch.)
OK, so can I summarize the above as
Quoted 7 lines
- Rust calling Rust will work fine and happily use float types without using FP/SIMD registers in codegen;
- Rust calling C or C calling Rust will not support float or double arguments or return values due to the restrictions imposed by the C compiler.?
Correct. (I assume the existing Rust kernel code contains no float or SIMD types so this is largely theoretical. But I'm a Rust compiler / upstream dev, not a Rust-for-Linux / kernel dev, so I might be entirely off here.)
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Also, it should be clarified
whether using a softfloat ABI permits the compiler to use FP/SIMD registers in codegen. We might still need -Ctarget-feature="-neon" here afaict.
Quoted 8 lines
Quoted 4 lines
Rust's softfloat targets do not use FP/SIMD registers by default. Ideally these targets allow selectively using FP/SIMD registers within certain functions; for aarch64, this is not properly supported by LLVM and therefore Rust.
I read this as 'this default behavior might change in the future', and so -Ctarget-feature="-neon" should be added even if it is redundant at this point in time.
Personally I think it would be a breaking change to start using neon in the aarch64-softfloat target, for reasons such as what we are discussing. (And this means we won't do it.) We have generally, but implicitly, understood "softfloat" to mean both "uses softfloat ABI" and "does not use any FP/SIMD registers by default". But I don't know whether the Rust compiler team has formally committed to anything here. I can inquire about that if you want.
OTOH I cannot see how adding "-neon" could possibly hurt, either. It's juts a NOP currently.
Kind regards,
Ralf
Quoted 18 lines
Quoted 11 lines
Quoted 5 lines
Ideally, we'd have a target/target-feature combo that makes this more
explicit: no FP/SIMD codegen at all, without affecting the ABI, therefore making float/double types in function prototypes illegal. AIUI, this change does something different.Having targets without float support would be a significant departure from past language decisions in Rust -- that doesn't mean it's impossible, but it would require a non-trivial effort (starting with an RFC to lay down the motivation and design).
Fair enough. The codegen is all that matters, and there are other cases (e.g., spilling) where the compiler may decide to use FP/SIMD registers without any floats or doubles in sight. In fact, there are swaths of non-performance critical floating point code in the AMDGPU driver where it would be useful to have float/double support using softfloat codegen too.