Figure out which target features are required/incompatible for which ABI

[RalfJung]

The context for this is #116344: some target features change the way floats are passed between functions. Changing those target features is unsound as code compiled for the same target may now use different ABIs.

In #134794, I am adding the infrastructure to have the compiler recognize this. But this infrastructure needs to be fed with information about which ABIs exist (e.g. softfloat/hardfloat), and which target features they require or are incompatible with. This will have to be done for each architecture we support.

• x86 (32bit and 64bit):
  • soft-float can be set to swap the ABI; if unset, a hardfloat ABI is used
  • 32bit: uses float registers if !soft-float && x87 (see here). IOW, hardfloat ABI requires x87.
    • except f16 uses SSE registers so that's extra fun, see x86-32 "f16" ABI needs SSE, incompatible with i586 targets #131819
  • 64bit: floats are passed via SSE registers, so likely !soft-float && sse is the relevant check -- IOW, hardfloat ABI requires sse/sse2.
• arm
  • soft-float can be set to swap the ABI; if unset, a hardfloat ABI is used
  • uses float registers if !soft-float && fpregs (see here), so hardfloat ABI requires fpregs
• aarch64
  • doesn't really have a notion of a softfloat ABI, but we offer a softfloat target anyway...
  • uses float registers if fp-armv8 ; Rust makes -neon imply -fp-armv8 so we have to forbid both -- but neon is stable! See The (stable) neon aarch64 target feature is unsound: it changes the float ABI #131058
• riscv
  • "RISC-V has a similar ABI split. -F/-D/-Q is your softfloat/nofloat, but it also comes with the Zfinx/Zdinx/Zqinx variants where floating-point values are carried in the regular registers and the floating-point register file is deleted. Your float-function-features would be +F,-Zfinx, +D,-Zdinx for riscv64gc-unknown-linux (linux does not permit finx). Although I don't think this is as much of a problem because the platform states that +F,+Zfinx is illegal?" (from here)
  • For RISC-V targets, the float ABI can be specified by the llvm_abiname target option. As long as this happens, f/d can be enabled without changing the ABI (LLVM doesn't support q yet). Disabling target features required by the requested ABI will cause LLVM to ignore the ABI. The zfinx/zdinx features don't affect the ABI.
  • Also see Some -Ctarget-features must be restrained on RISCV #132618
• powerpc
• wasm
• loongarch
• s390x
• sparc
• bpf
• csky
• hexagon
• mips
• m68k
• more?

[RalfJung]

@rust-lang/wg-llvm @bjorn3 @chorman0773 if you happen to know anything that needs to be added to the list, please let me know, or edit the issue. :) I'm mostly focusing on float ABI here; if it turns out there's a ton of architecture-specific ABI-affecting non-float features we might want to split this up into float and non-float.

[chorman0773]

sse should be included for x86-64 and x87 should not be. Floats on 64-bit x86 use xmm registers rather than the x87 stack.

[RalfJung]

Does -x87 not also disable SSE?

[chorman0773]

I would assume not, they're entirely separate instruction sets and units.
In regardless, sse still affects float abi on x86_64.

[beetrees]

• On x86 (32-bit and 64-bit), LLVM lets you disable x87 without disabling SSE.
• On x86 (32-bit and 64-bit), f16 will get returned (and passed on x86-64) in an integer register instead of an SSE register if the sse2 feature is disabled.
• On x86-64, f128 will get passed/returned in integer registers instead of an SSE register if the sse feature is disabled.
• On x86-64, LLVM will error when attempting to pass/return an f64 when sse2 is disabled (a similar error occurs for f32 with the sse feature).
• For RISC-V targets, the float ABI can be specified by the llvm_abiname target option. As long as this happens, f/d can be enabled without changing the ABI (LLVM doesn't support q yet). Disabling target features required by the requested ABI will cause LLVM to ignore the ABI. The zfinx/zdinx features don't affect the ABI.

[beetrees]

• WASM always supports f32 and f64.
• LoongArch works the same way as RISC-V.
• On PowerPC (32-bit and 64-bit), disabling the hard-float feature causes floats to be passed/returned in integer registers.
• On PowerPC (32-bit and 64-bit), disabling the vsx feature causes f128 to be passed/returned in integer registers instead of a vector register (causes f128 symbols on powerpc64 give inaccurate results #125109).

[RalfJung]

On x86 (32-bit and 64-bit), f16 will get passed in an integer register instead of an SSE register if the sse2 feature is disabled.

What is the default register for f16 on x86-32? I would have expected it matches f32 and f64, i.e., it uses an x87 register for returns and gets passed on the stack for arguments? Why is SSE involved at all?

[beetrees]

Oops, I meant returned (passed only applies for x86-64): you're correct that 32-bit x86 always passes arguments on the stack. I've updated my comment. On 32-bit x86, the ABI specifies that f16 gets returned in xmm0, which is what Clang and GCC do (neither Clang nor GCC support _Float16 when SSE2 is disabled).

[RalfJung]

On 32-bit x86, the ABI specifies that f16 gets returned in xmm0, which is what Clang and GCC do (neither Clang nor GCC support _Float16 when SSE2 is disabled).

Oh wow that's Just Great. Probably justifies a separate issue: #131819

[RalfJung]

#130988 lists a bunch of ARM target features we don't support yet. I hope none of them besides fpregs affect ABI?

[taiki-e]

On s390x, the soft-float changes the way of f32/f64 being passed/returned. (f128 is unaffected. f16 is unsupported.)
On 64-bit SPARC, the soft-float changes the way of f16/f32/f64/f128 being passed/returned.

I haven't checked generated asm for 32-bit SPARC (there is no tier 2 32-bit SPARC target), but considering the calling conventions and the behavior on SPARC64, I guess f16/f32/f64 are affected by the same flag.

[RalfJung]

With #134794, the framing for this is changing: all we need now is a full list of

• what are the ABIs on each target (often just softfloat/hardfloat, but e.g. RISC-V has more than that)
• which target features are required for which ABI

for all our architectures.