rustc_target: Add more RISC-V atomic-related features

[taiki-e]

This is a continuation of #130877 and adds a few target features, including zacas, which was experimental in LLVM 19 and marked non-experimental in LLVM 20.

This adds the following target features to unstable riscv_target_feature:

• za64rs (Za64rs Extension 1.0): Reservation Set Size of at Most 64 Bytes
  (definition in LLVM, available since LLVM 18)
• za128rs (Za128rs Extension 1.0): Reservation Set Size of at Most 128 Bytes
  (definition in LLVM, available since LLVM 18)
  • IIUC, za*rs can be referenced when implementing helpers to reduce contention in synchronization primitives, like crossbeam_utils::CachePadded. (relevant discussion: What, exactly, does the reservation set size (Za64rs/Za128rs) constrain? riscv/riscv-profiles#79)
• zacas (Zacas Extension 1.0): Atomic Compare-And-Swap Instructions (amocas.{w,d,q}{,.aq,.rl,.aqrl} and amocas.{b,h}{,.aq,.rl,.aqrl} when zabha is also enabled)
  (definition in LLVM, available as non-experimental since LLVM 20)
  • This implies zaamo.
  • This is used to optimize CAS in existing atomics and/or implement 64-bit/128-bit atomics on riscv32/riscv64 (e.g., riscv: Support 128-bit atomics for RV64 and 64-bit atomics for RV32 (Zacas extension) taiki-e/portable-atomic#173).
  • Note that LLVM does not automatically use this instruction for 64-bit/128-bit atomics on riscv32/riscv64 even if this feature is enabled, because doing it changes the ABI. (If the ability to do that is provided by LLVM in the future, it should probably be controlled by another ABI feature similar to forced-atomics.)
• zama16b (Zama16b Extension 1.0): Atomic 16-byte misaligned loads, stores and AMOs
  (definition in LLVM, available since LLVM 19)
  • IIUC, unlike AArch64 FEAT_LSE2 which also makes 16-byte aligned ldp ({i,u}128 load) atomic, this extension only affects instructions that already considered atomic if they were naturally aligned. i.e., fld (f64 load) on riscv32 would not be atomic with or without this extension (relevant QEMU code).
• zawrs (Zawrs Extension 1.0): Wait on Reservation Set (wrs.nto and wrs.sto)
  (definition in LLVM, available as non-experimental since LLVM 17)
  • This is used to optimize synchronization primitives (e.g., Linux uses this for spinlocks (torvalds/linux@b8ddb0d)).

Btw, the question of whether zaamo is implied by zabha or not, which was discussed in #130877, has been resolved in LLVM 20, since LLVM now treats zaamo as implied by zabha/zacas (llvm/llvm-project#115694), just like GCC and rustc.

r? @Amanieu

@rustbot label +O-riscv +A-target-feature

[Amanieu]

@bors r+

[bors]

📌 Commit a343dcb has been approved by Amanieu

It is now in the queue for this repository.

[RalfJung]

Do any of these have ABI concerns? In particular, if I mix code built with and without those features, and those two parts of the program share some memory and use atomics to work on that, will everything still behave correctly? Or do some of these features change the way LLVM lowers atomic operations in such a way that it is no longer compatible with code built without the extension?

[taiki-e]

As far as I know, there are none at this time.

As of the past:

• Zacas had a problem that it was incompatible with the atomic instruction mappings used in earlier LLVMs, and because of this problem it was marked as an experimental feature in LLVM 19 and older, but this has been resolved by adding fences when necessary in LLVM 20 (llvm/llvm-project@614aeda).

• As mentioned in the PR description, if LLVM automatically use Zacas instruction for 64-bit/128-bit atomics on riscv32/riscv64 when Zacas is enabled, it will cause ABI incompatibility because it is not compatible with the existing fallback-based atomics that provided via atomic builtins. However, they are aware of this issue and have stated that they will not do this.

As for others:

• Zawrs adds an instruction to wait for a memory location to be updated, but this is not used in the atomic operation itself and is therefore not relevant for atomic ABI.
• Zama16b relaxes the alignment requirement of atomicity of existing instructions used in atomic operations a bit. Code built for more restrictive existing (i.e., no Zama16b) environments will work fine even with zama16b enabled.
• I guess Za64rs and Za128rs may affect the size of C++ hardware_destructive_interference_size (although not a cache-related feature), but neither LLVM nor GCC guarantee stability on the size of hardware_destructive_interference_size in the first place, stating that it may be changed by CPU tuning flags.

[RalfJung]

Thanks for the detailed list! Please reference that from the tracking issue so it can be found when we consider stabilization. <llvm/llvm-project#101023> sounds like LLVM did change the ABI at some point, so mixing Rust (or C) code built with different versions of LLVM can cause UB. Amazing. But that seems to not depend on target features so it has no bearing on this PR.

[beetrees]

<llvm/llvm-project#101023> sounds like LLVM did change the ABI at some point, so mixing Rust (or C) code built with different versions of LLVM can cause UB. Amazing. But that seems to not depend on target features so it has no bearing on this PR.

AFAICT this shouldn't be an issue, as by default LLVM currently uses the A6S atomic ABI that is compatible with both other ABIs. RISC-V ELF files can be tagged with which atomic ABI is in use, and the linker will issue an error if incompatible objects are linked together. LLVM will emit Tag_RISCV_atomic_abi if the --riscv-abi-attributes argument is passed to LLVM (it is disabled by default due to segfaults in ld.bfd).

[compiler-errors]

@bors rollup