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
• loongarch: see here
• powerpc
• s390x
• wasm
• 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?