Hi,
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.
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.)
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.)
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.
?
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.)
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.
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
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.
