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

View all comments

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
s390x: see here and here
wasm: add ABI check logic for wasm #157106
powerpc: powerpc: warn against incorrect values for ABI-relevant target features #157085
sparc64: Missing target feature ABI checks for Sparc64 #157083
nvptx: Missing target feature ABI checks for nvptx #157532

Tier 3 only:

@bjorn3

@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.

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.

Does -x87 not also disable SSE?

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

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.

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).

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?

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).

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

But IIUC that's something that happens to be the case now, but not a promise going forward, so this could still become an issue in the future...

That's how I understand it. But it also very much seems like something there will be put effort into not breaking in practice.

Target features are meant for things you can mix-and-match freely in the same binary. I am slightly concerned that the way the nvptx backend uses them may not be compatible with that. I also don't actually understand these target features so maybe those concerns are unnecessary. ;)

Your concerns are completely justified. A binary will end up with one exact ptx and sm version. From the target docs on nvptx

Although Rust follows LLVM in representing ptx* and sm_* as target features, they should be thought of as having crate granularity, set via (either via -Ctarget-cpu and optionally -Ctarget-feature). While the compiler accepts #[target_feature(enable = "ptx80", enable = "sm_89")], it is not supported, may not behave as intended, and may become erroneous in the future.

I think whats meant with "crate granularity" is really more of a "per binary" granularity

Considering that having control of sm/ptx versions is very important for the nvptx target. Do you have a more suitable way to represent these properties in mind?

This seems like something for which -Ctarget-cpu would make sense. Avr and amdgpu already require specifying a -Ctarget-cpu and maybe deny mixing crates compiled with different -Ctarget-cpu values.

Yeah, maybe we could use the target modifier infrastructure to reject mixing different target-cpu on targets where those are mutually exclusive. Let's move this discussion to #141468

I feel like maybe nvptx went tier 2 a bit too quickly, there are some basic aspects of this target that still need figuring out...

Rollup merge of rust-lang#157085 - RalfJung:powerpc-abi-features, r=p…

Unrolled build for #157085

Rollup merge of rust-lang#150732 - kulst:cpu_is_target_modifier, r=bj…

Unrolled build for #150732

Rollup merge of #150732 - kulst:cpu_is_target_modifier, r=bjorn3

Navigation Menu

Repository navigation

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

24 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

RalfJung commented on Oct 16, 2024

chorman0773 commented on Oct 16, 2024

RalfJung commented on Oct 16, 2024

chorman0773 commented on Oct 16, 2024

beetrees commented on Oct 16, 2024

beetrees commented on Oct 16, 2024

RalfJung commented on Oct 17, 2024

beetrees commented on Oct 17, 2024

RalfJung commented on Oct 17, 2024

24 remaining items

kjetilkjeka commented on Oct 10, 2025

bjorn3 commented on Oct 10, 2025

RalfJung commented on Oct 10, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions