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

View all comments

The context for this is https://github.com/rust-lang/rust/issues/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 https://github.com/rust-lang/rust/pull/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 https://github.com/rust-lang/rust/issues/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 https://github.com/rust-lang/rust/issues/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 https://github.com/rust-lang/rust/issues/132618
• loongarch: see here
• s390x: see here and here
• wasm: https://github.com/rust-lang/rust/pull/157106
• powerpc: https://github.com/rust-lang/rust/pull/157085
• sparc64: https://github.com/rust-lang/rust/issues/157083
• nvptx: https://github.com/rust-lang/rust/issues/157532

Tier 3 only:

• bpf
• csky
• hexagon
• mips
• m68k
• sparc32
• more?

Start with issue #116344 and the compiler infrastructure described in pull request #134794, then review the architecture-specific ABI notes and linked follow-up issues in this issue. Begin with the unchecked nvptx entry and determine which target features and ABI options are required or incompatible. Done means the supported architectures have their ABI requirements recorded and the remaining tier 3 targets are addressed or explicitly scoped.