Some -Ctarget-features must be restrained on RISCV

[workingjubilee]

refs:

• Tracking Issue for RISC-V Ratified Extensions Intrinsics #114544
  • Stabilize Ratified RISC-V Target Features #116485 which was massively scaled back due to this open question
• The ABI of float types can be changed by -Ctarget-feature #116344
• mark some target features as 'forbidden' so they cannot be (un)set with -Ctarget-feature #129884
• Figure out which target features affect float ABI #131799
• Always specify llvm_abiname for RISC-V targets #131807

in discussion of the target modifiers RFC¹, Ralf asks this question:

That's actually fine on most targets, e.g. on x86 if you set the soft-float target feature then you can enable x87 and SSE and whatnot and keep using the soft-float ABI. Only aarch64 llvm/llvm-project#110632 (from the targets I checked so far).

The interesting question is what happens on RISC-V when I disable the FP instructions on a target that usually uses the hardfloat ABI. Sadly, what LLVM usually does in that case is silently fall back to the softfloat ABI. But I haven't checked for RISC-V.

cc @beetrees

Footnotes

1. https://github.com/rust-lang/rfcs/pull/3716 ↩

[beetrees]

In summary:

• Targets using any ABI other than ilp32e/lp64e rely on the e feature being disabled.
• Targets using the ilp32f/lp64f ABI rely on the f feature being enabled.
• Targets using the ilp32d/lp64d ABI rely on the d feature being enabled.
• (LLVM doesn't support the q feature yet, but a similar rule will apply with that feature and the lp64q ABI).
• The forced-atomics feature must never be disabled if it is enabled, as the forced-atomics feature changes the ABI of atomic operations (as mentioned in this section of the LLVM atomics documentation).

Notes:

• Currently LLVM will emit a warning and fallback to an inferred-from-target-features ABI if the required target features are disabled (or required-to-be-disabled target features are enabled).
• Enabling the f/d features on targets using softer ABIs is fine, as is disabling the e feature, as all RISC-V targets explicitly state their ABI due to Always specify llvm_abiname for RISC-V targets #131807.
• Disabling the a feature causes atomic operations to be compiled using __atomic_* libcalls instead of native operations, but AFAICT the worst possible outcome here is a linker error if libatomic is not linked - according to the LLVM atomics documentation, __atomic_* libcalls must use a lock-free implementation for all atomic sizes that the compiler can emit native instructions for (which are the only sizes of atomics Rust supports).

[workingjubilee]

cc @coastalwhite (as author of #116485 which got scaled back due to precisely this question!)

[beetrees]

Just realised I missed the e feature from my summary; I've edited my comment above to include it.

[beetrees]

Also I haven't included above the cases where LLVM will emit an error itself due to feature incompatibility. Checking the features mentioned #116485, those are:

• The f and zfinx features are incompatible.
• The d feature is incompatible with the ilp32e ABI.

In both these cases LLVM will already emit a fatal error, but it would definitely be better diagnostic UX for rustc to detect the problem and emit an error itself.

[workingjubilee]

Thanks for the summary! That seems pretty definite in terms of a "yes, we should", yeah.