Some `-Ctarget-feature`s must be restrained on RISCV

[workingjubilee]

refs:

• https://github.com/rust-lang/rust/issues/114544
  • https://github.com/rust-lang/rust/pull/116485 which was massively scaled back due to this open question
• https://github.com/rust-lang/rust/issues/116344
• https://github.com/rust-lang/rust/pull/129884
• https://github.com/rust-lang/rust/issues/131799
• https://github.com/rust-lang/rust/pull/131807

in discussion of the target modifiers RFC^1, 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 https://github.com/llvm/llvm-project/issues/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

[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 https://github.com/rust-lang/rust/pull/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 https://github.com/rust-lang/rust/pull/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 https://github.com/rust-lang/rust/pull/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.