Figure out which target features affect float 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 #129884 I am adding the infrastructure to have the compiler recognize this. But this infrastructure needs to be fed with information about which are the "dangerous" target features. This will have to be done for each architecture we support. (Long-term we can maybe switch this around and reject all target features except the ones that are known to be harmless, but that's a looong way off since we've just allowed arbitrary unknown LLVM features to be toggled on stable with -Ctarget-feature since forever.)

• x86 (32bit and 64bit):
  • 32bit: uses float registers if !soft-float && x87 (see here), so toggling either can be unsound
  • 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
• arm
  • uses float registers if !soft-float && fpregs (see here), so toggling either can be unsound
• aarch64
  • 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
• powerpc
• 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)
• 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.