rustc_target: Add RISC-V atomic-related features

[taiki-e]

This adds the following three target features to unstable riscv_target_feature.

• zaamo (Zaamo Extension 1.0.0): Atomic Memory Operations (amo*.{w,d}{,.aq,.rl,.aqrl})
  (definition in LLVM, available since LLVM 19)
• zabha (Zabha Extension 1.0.0): Byte and Halfword Atomic Memory Operations (amo*.{b,h}{,.aq,.rl,.aqrl})
  (definition in LLVM, available since LLVM 19)
• zalrsc (Zalrsc Extension 1.0.0): Load-Reserved/Store-Conditional Instructions (lr.{w,d}{,.aq,.rl,.aqrl} and sc.{w,d}{,.aq,.rl,.aqrl})
  (definition in LLVM, available since LLVM 19)

(Zacas Extension is not included here because it is still marked as experimental in LLVM 19 llvm/llvm-project@70e7d26 and will become non-experimental in LLVM 20 llvm/llvm-project@614aeda)

a implies zaamo and zalrsc, and zabha implies zaamo:

• After Zaamo and Zalrsc Extensions are frozen, riscv-isa-manual says "The A extension comprises instructions provided by the Zaamo and Zalrsc extensions" (riscv/riscv-isa-manual@e87412e), and a implies zaamo and zalrsc in GCC. However, in LLVM, a does not define them as implying zaamo and zalrsc.
• Zabha and Zaamo are in a similar situation, riscv-isa-manual says "The Zabha extension depends upon the Zaamo standard extension", and zabha implies zaamo in GCC, but does not in LLVM (but enabling zabha without zaamo or a is not allowed).

r? @Amanieu

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

[rustbot]

Some changes occurred in tests/ui/check-cfg

cc @Urgau

[michaelmaitland]

I didn't make a implies zaamo and zalrsc, or zabha implies zaamo for now:

According to d9715c698c4940e65e9bd036e22fb5cab3aa2c6f,

Zabha and Zacas are both documented as depending on Zaamo. I'm
hesitant to make them imply Zaamo instead.

So remove the implication and replace with a check that either
A or Zaamo is enabled.

I think that we still need a check like this?

[taiki-e]

Zabha and Zacas are both documented as depending on Zaamo. I'm
hesitant to make them imply Zaamo instead.
So remove the implication and replace with a check that either
A or Zaamo is enabled.

I think that we still need a check like this?

Thanks for pointing this out. If we go in the same direction as LLVM, we certainly need to do that.
Currently, the LLVM backend will cause an LLVM error (https://godbolt.org/z/a8vb8GxYc), but other backends will probably not.

That said, I'm beginning to think that it is not actually necessary to separate what the ISA states ".. depends upon ..".

[taiki-e]

Updated to make a implies zaamo and zalrsc, and zabha implies zaamo.

[michaelmaitland]

I got some more context on why LLVM is the way it is.

The RISC-V ISA spec is a hardware spec not a toolchain spec, so we must understand this context.

The A extension was later split into Zaamo and Zalrsc. When hardware implements Zaamo and Zalrsc, it implemented A. End of story on the hardware side.

But on the toolchain side, things are a little messy, especially when we are dealing with mixed versions of software in the toolchain. If a is made to imply Zaamo or Zalrsc in the compiler, and we used an older but stable version of binutils that was shipped before a was split, then that stable binutils becomes unusable with the newer compiler, even though the a spec has not changed.

This is the reason why LLVM does not have the implication. GCC + binutils usually ship with the same version, so this incompatibility is less of a worry. This is why the GCC folks were willing to add the implication here. LLVM decided that it would enforce that if you're going to use zacas or zabha, then you better enable a or zaamo, which ensures that we have what is needed without breaking what I talked about above.

I don't want to be the one to say how it should be in rust, but I figured that this context could be valuable for those who are making the decision.

[bors]

☔ The latest upstream changes (presumably #130934) made this pull request unmergeable. Please resolve the merge conflicts.

[Amanieu]

My understanding is that this may cause issues with an old binutils, but I believe newer binutils only warn instead of error when encountering unknown features. In any case, we can revert this and re-evaluate if it causes problems in nightly.

@bors r+

[bors]

📌 Commit 62612af has been approved by Amanieu

It is now in the queue for this repository.