[RISCV][MC] Add support for experimental Zawrs extension

[reames]

Summary

This implements the Zawrs extension as specified here: https://github.com/riscv/riscv-zawrs/releases/download/V1.0-rc3/Zawrs.pdf. Despite the 1.0 version name, this does not appear to have been ratified, so putting it under experimental for the moment. I have been told that the current version is near final, and unlikely to change (again), but have nothing to cite on that.

This change adds assembly support, but does not include C language or IR intrinsics. We can decide if we want them, and handle that in a separate patch.

There were two prior attempts at implementing this.

D128235 by @palmer-dabbelt implements a prior version of this extension. Very annoyingly, the specification appears to have changed *without* a change in version number. This patch also didn't make the extension experimental.

D129462 by @sunshaoce implements the current version, but was abandoned due to confusion with the prior. Additionally, it's missing a few tests. I took the .td file change and the valid assembly test from that change.

[jrtc27]

llvm/lib/Target/RISCV/RISCVInstrInfo.td

709

This doesn't really belong here, but a separate RISCVInstrInfoZawrs.td also seems a little overkill... hmm

llvm/lib/Target/RISCV/RISCVSubtarget.h

95

I would say keep these sorted but this seems to be a bit of a mess...

[reames]

llvm/lib/Target/RISCV/RISCVInstrInfo.td

709

I had the same thoughts. I'm happy to defer to reviewers' preference.

llvm/lib/Target/RISCV/RISCVSubtarget.h

95

I'm happy to sort in a separate change if you'd like. Preferably after this lands. :)

[asb]

The change in set of instructions without changing the version number is concerning - do you know anyone involved in that group? It would be good to feedback the difficulties this can cause for us. It's also not clear if there might be changes again during ratification without changing the version number, which wouldn't be ideal (though probably just about livable given it's marked as experimental).

Let's discuss briefly in the meeting tomorrow. Implementation-wise it all seems straightforward.

[reames]

In D133443#3790420, @asb wrote:

The change in set of instructions without changing the version number is concerning - do you know anyone involved in that group? It would be good to feedback the difficulties this can cause for us. It's also not clear if there might be changes again during ratification without changing the version number, which wouldn't be ideal (though probably just about livable given it's marked as experimental).

I agree that the incompatible change is highly sub-optimal. I've asked around a bit on the status here, but nothing I would consider "official" or would want to quote someone on. My overall take is that we probably should take this as experimental, but only with the understanding that it may change in incompatible ways.

Edit: For clarity, the incompatible change was between two -rcN variants of the 1.0 spec. So maybe that's "less bad"? If we include the candidate number, we do have a unique version ID? And maybe we should not be citing release candidates? Anyways, something to discuss tomorrow.

Let's discuss briefly in the meeting tomorrow. Implementation-wise it all seems straightforward.

Definitely.

[asb]

I think the summary of our discussion on this was:

• The versioning confusion is unfortunate - ideally there would be discussion elsewhere at RVI on improving the situation (either ELF attributes to indicate extensions are experimental, or making that unnecessary via never using 1.0 until something is ratified)
• But the above isn't a blocker to merging. As the extension is gated by the experimental flag, even if there are last minute changes the impact on users should be minimal / non-existent.

[reames]

In D133443#3792627, @asb wrote:

I think the summary of our discussion on this was:

• The versioning confusion is unfortunate - ideally there would be discussion elsewhere at RVI on improving the situation (either ELF attributes to indicate extensions are experimental, or making that unnecessary via never using 1.0 until something is ratified)
• But the above isn't a blocker to merging. As the extension is gated by the experimental flag, even if there are last minute changes the impact on users should be minimal / non-existent.

Matches my takeaway. I'm going to rebase this and add in a doc change which clearly notes the release candidate bit.

[reames]

Add docs.

[asb]

Everything that's in this patch looks good to me - it's just missing some simple round-trip tests in the style of rv32zicboz-valid.s (and perhaps an -invalid.s that shows a sensible error message being produced when the instructions have an argument).

In terms of which *.td file to edit - RISCVInstrInfoA.td is another possibility. The plan had been that for the z?foo extensions, the letter after the z indicated which of the top-level extensions it was most relevant to - e.g. the zc* extensions (ztso predated this idea). I don't mind much either way - I'm happy with it in either location.

[reames]

In D133443#3795603, @asb wrote:

Everything that's in this patch looks good to me - it's just missing some simple round-trip tests in the style of rv32zicboz-valid.s (and perhaps an -invalid.s that shows a sensible error message being produced when the instructions have an argument).

You had me very confused at first as I'd written the valid tests - until I realized they'd been lost in the rebase. Updated patch forthcoming.

[asb]

It looks like they're still missing in this updated version of the patch?

[luismarques]

Regarding the overkill of "RISCVInstrInfoZawrs.td", how about having a "RISCVInstrInfoExtra.td" (or "RISCVInstrInfoExt.td") as a grab bag for everything that doesn't merit its own .td file?

I think this is fine regarding the versioning issue. Seems to only be missing the actual instruction tests, otherwise LGTM.

[reames]

In D133443#3801899, @asb wrote:

It looks like they're still missing in this updated version of the patch?

I have no idea what's going wrong here. I had been very careful to make sure the patch contained the new test file, but you're right, the revision in phab didn't.

Since we now had two LGTMs, and the tests had been in the original patch upload, I went ahead and landed. The tests are in the committed patch; if you want any changes, let me know.

clang/test/Preprocessor/riscv-target-features.c

 
 // RUN: %clang -target riscv32 -march=rv32izicbop -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZICBOP-EXT %s
 // RUN: %clang -target riscv64 -march=rv64izicbop -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZICBOP-EXT %s
 // CHECK-ZICBOP-EXT: __riscv_zicbop 1000000{{$}}
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -menable-experimental-extensions \
+// RUN: -march=rv32izawrs1p0 -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZAWRS-EXT %s
+// RUN: %clang -target riscv64-unknown-linux-gnu -menable-experimental-extensions \
+// RUN: -march=rv64izawrs1p0 -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-ZAWRS-EXT %s
+// CHECK-ZAWRS-EXT: __riscv_zawrs 1000000{{$}}
+
+// RUN: %clang -target riscv32-unknown-linux-gnu -menable-experimental-extensions \
 // RUN: -march=rv32iztso0p1 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZTSO-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -menable-experimental-extensions \
 // RUN: -march=rv64iztso0p1 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZTSO-EXT %s
 // CHECK-ZTSO-EXT: __riscv_ztso 1000{{$}}

llvm/docs/RISCVUsage.rst

 
 Experimental Extensions
 =======================
 
 LLVM supports (to various degrees) a number of experimental extensions.  All experimental extensions have ``experimental-`` as a prefix.  There is explicitly no compatibility promised between versions of the toolchain, and regular users are strongly advised *not* to make use of experimental extensions before they reach ratification.
 
 The primary goal of experimental support is to assist in the process of ratification by providing an existence proof of an implementation, and simplifying efforts to validate the value of a proposed extension against large code bases.  Experimental extensions are expected to either transition to ratified status, or be eventually removed.  The decision on whether to accept an experimental extension is currently done on an entirely case by case basis; if you want to propose one, attending the bi-weekly RISC-V sync-up call is strongly advised.
 
+``experimental-zawrs``
+  LLVM implements the `1.0-rc3 draft specification <https://github.com/riscv/riscv-zawrs/releases/download/V1.0-rc3/Zawrs.pdf>`_.  Note that have been backwards incompatible changes made between release candidates for the 1.0 draft.
+
 ``experimental-zbe``, ``experimental-zbf``, ``experimental-zbm``, ``experimental-zbp``, ``experimental-zbr``, ``experimental-zbt``
   LLVM implements the `latest state of the bitmanip working branch <https://github.com/riscv/riscv-bitmanip/tree/main-history>`_, which is largely similar to the 0.93 draft specification but with some instruction naming changes.  These are individual portions of the bitmanip efforts which did *not* get ratified.  Given ratification for these sub-extensions appears stalled; they are a likely candidate for removal in the future.
 
 ``experimental-zca``
   LLVM implements the `0.70 draft specification <https://github.com/riscv/riscv-code-size-reduction/releases/tag/V0.70.1-TOOLCHAIN-DEV>`_.
 
 ``experimental-zihintntl``
   LLVM implements the `0.2 draft specification <https://github.com/riscv/riscv-isa-manual/releases/tag/draft-20220831-bf5a151>`_.

llvm/lib/Support/RISCVISAInfo.cpp

static const RISCVSupportedExtension SupportedExperimentalExtensions[] = {
     {"zbe", RISCVExtensionVersion{0, 93}},
     {"zbf", RISCVExtensionVersion{0, 93}},
     {"zbm", RISCVExtensionVersion{0, 93}},
     {"zbp", RISCVExtensionVersion{0, 93}},
     {"zbr", RISCVExtensionVersion{0, 93}},
     {"zbt", RISCVExtensionVersion{0, 93}},
     {"zca", RISCVExtensionVersion{0, 70}},
     {"zvfh", RISCVExtensionVersion{0, 1}},
+    {"zawrs", RISCVExtensionVersion{1, 0}},
     {"ztso", RISCVExtensionVersion{0, 1}},
 };
 
 static bool stripExperimentalPrefix(StringRef &Ext) {
   return Ext.consume_front("experimental-");
 }
 
 // This function finds the first character that doesn't belong to a version

llvm/lib/Target/RISCV/RISCV.td

 
 def FeatureStdExtZtso
     : SubtargetFeature<"experimental-ztso", "HasStdExtZtso", "true",
                        "'Ztso' (Memory Model - Total Store Order)">;
 def HasStdExtZtso : Predicate<"Subtarget->hasStdExtZTso()">,
                            AssemblerPredicate<(all_of FeatureStdExtZtso),
                            "'Ztso' (Memory Model - Total Store Order)">;
 
+def FeatureStdExtZawrs
+    : SubtargetFeature<"experimental-zawrs", "HasStdExtZawrs", "true",
+                       "'Zawrs' (Wait on Reservation Set)">;
+def HasStdExtZawrs : Predicate<"Subtarget->hasStdExtZawrs()">,
+                           AssemblerPredicate<(all_of FeatureStdExtZawrs),
+                           "'Zawrs' (Wait on Reservation Set)">;
+
 // Feature32Bit exists to mark CPUs that support RV32 to distinquish them from
 // tuning CPU names.
 def Feature32Bit
     : SubtargetFeature<"32bit", "HasRV32", "true", "Implements RV32">;
 def Feature64Bit
     : SubtargetFeature<"64bit", "HasRV64", "true", "Implements RV64">;
 def IsRV64 : Predicate<"Subtarget->is64Bit()">,
                        AssemblerPredicate<(all_of Feature64Bit),

llvm/lib/Target/RISCV/RISCVInstrInfo.td

 // instruction (i.e., it should always trap, if your implementation has invalid
 // instruction traps).
 def UNIMP : RVInstI<0b001, OPC_SYSTEM, (outs), (ins), "unimp", "">,
             Sched<[]> {
   let rs1 = 0;
   let rd = 0;
   let imm12 = 0b110000000000;
 }
+
+let Predicates = [HasStdExtZawrs] in {
+def WRS_NTO : RVInstI<0b000, OPC_SYSTEM, (outs), (ins), "wrs.nto", "">,
+              Sched<[]> {
+  let rs1 = 0;
+  let rd = 0;
+  let imm12 = 0b000000001101;
+}
+
+def WRS_STO : RVInstI<0b000, OPC_SYSTEM, (outs), (ins), "wrs.sto", "">,
+              Sched<[]> {
+  let rs1 = 0;
+  let rd = 0;
+  let imm12 = 0b000000011101;
+}
+} // Predicates = [HasStdExtZawrs]
+
 } // hasSideEffects = 1, mayLoad = 0, mayStore = 0
 
 def CSRRW : CSR_ir<0b001, "csrrw">;
 def CSRRS : CSR_ir<0b010, "csrrs">;
 def CSRRC : CSR_ir<0b011, "csrrc">;
 
 def CSRRWI : CSR_ii<0b101, "csrrwi">;
 def CSRRSI : CSR_ii<0b110, "csrrsi">;

llvm/lib/Target/RISCV/RISCVSubtarget.h

private:
   bool HasStdExtZkn = false;
   bool HasStdExtZks = false;
   bool HasStdExtZkt = false;
   bool HasStdExtZk = false;
   bool HasStdExtZicbom = false;
   bool HasStdExtZicboz = false;
   bool HasStdExtZicbop = false;
   bool HasStdExtZmmul = false;
+  bool HasStdExtZawrs = false;
   bool HasStdExtZtso = false;
   bool HasRV32 = false;
   bool HasRV64 = false;
   bool IsRV32E = false;
   bool EnableLinkerRelax = false;
   bool EnableRVCHintInstrs = true;
   bool EnableDefaultUnroll = true;
   bool EnableSaveRestore = false;
public:
   bool hasStdExtZkne() const { return HasStdExtZkne; }
   bool hasStdExtZknh() const { return HasStdExtZknh; }
   bool hasStdExtZksed() const { return HasStdExtZksed; }
   bool hasStdExtZksh() const { return HasStdExtZksh; }
   bool hasStdExtZkr() const { return HasStdExtZkr; }
   bool hasStdExtZicbom() const { return HasStdExtZicbom; }
   bool hasStdExtZicboz() const { return HasStdExtZicboz; }
   bool hasStdExtZicbop() const { return HasStdExtZicbop; }
+  bool hasStdExtZawrs() const { return HasStdExtZawrs; }
   bool hasStdExtZmmul() const { return HasStdExtZmmul; }
   bool hasStdExtZtso() const { return HasStdExtZtso; }
   bool is64Bit() const { return HasRV64; }
   bool isRV32E() const { return IsRV32E; }
   bool enableLinkerRelax() const { return EnableLinkerRelax; }
   bool enableRVCHintInstrs() const { return EnableRVCHintInstrs; }
   bool enableDefaultUnroll() const { return EnableDefaultUnroll; }
   bool enableSaveRestore() const { return EnableSaveRestore; }

llvm/test/CodeGen/RISCV/attributes.ll

 ; RUN: llc -mtriple=riscv64 -mattr=+zkt %s -o - | FileCheck --check-prefix=RV64ZKT %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zk %s -o - | FileCheck --check-prefix=RV64ZK %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zkn,+zkr,+zkt %s -o - | FileCheck --check-prefix=RV64COMBINEINTOZK %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zbkb,+zbkc,+zbkx,+zkne,+zknd,+zknh %s -o - | FileCheck --check-prefix=RV64COMBINEINTOZKN %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zbkb,+zbkc,+zbkx,+zksed,+zksh %s -o - | FileCheck --check-prefix=RV64COMBINEINTOZKS %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zicbom %s -o - | FileCheck --check-prefix=RV64ZICBOM %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zicboz %s -o - | FileCheck --check-prefix=RV64ZICBOZ %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zicbop %s -o - | FileCheck --check-prefix=RV64ZICBOP %s
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-zawrs %s -o - | FileCheck --check-prefix=RV64ZAWRS %s
 ; RUN: llc -mtriple=riscv64 -mattr=+experimental-ztso %s -o - | FileCheck --check-prefix=RV64ZTSO %s
 
 ; RV32M: .attribute 5, "rv32i2p0_m2p0"
 ; RV32ZMMUL: .attribute 5, "rv32i2p0_zmmul1p0"
 ; RV32MZMMUL: .attribute 5, "rv32i2p0_m2p0_zmmul1p0"
 ; RV32A: .attribute 5, "rv32i2p0_a2p0"
 ; RV32F: .attribute 5, "rv32i2p0_f2p0"
 ; RV32D: .attribute 5, "rv32i2p0_f2p0_d2p0"

 ; RV64ZKS: .attribute 5, "rv64i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zks1p0_zksed1p0_zksh1p0"
 ; RV64ZKT: .attribute 5, "rv64i2p0_zkt1p0"
 ; RV64ZK: .attribute 5, "rv64i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zk1p0_zkn1p0_zknd1p0_zkne1p0_zknh1p0_zkr1p0_zkt1p0"
 ; RV64COMBINEINTOZK: .attribute 5, "rv64i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zk1p0_zkn1p0_zknd1p0_zkne1p0_zknh1p0_zkr1p0_zkt1p0"
 ; RV64COMBINEINTOZKN: .attribute 5, "rv64i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zkn1p0_zknd1p0_zkne1p0_zknh1p0"
 ; RV64COMBINEINTOZKS: .attribute 5, "rv64i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zks1p0_zksed1p0_zksh1p0"
 ; RV64ZICBOM: .attribute 5, "rv64i2p0_zicbom1p0"
 ; RV64ZICBOZ: .attribute 5, "rv64i2p0_zicboz1p0"
+; RV64ZAWRS: .attribute 5, "rv64i2p0_zawrs1p0"
 ; RV64ZICBOP: .attribute 5, "rv64i2p0_zicbop1p0"
 ; RV64ZTSO: .attribute 5, "rv64i2p0_ztso0p1"
 
 define i32 @addi(i32 %a) {
   %1 = add i32 %a, 1
   ret i32 %1
 }

llvm/test/MC/RISCV/Zawrs-valid.s

+# RUN: llvm-mc %s -triple=riscv32 -mattr=+experimental-zawrs -riscv-no-aliases -show-encoding \
+# RUN:     | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc %s -triple=riscv64 -mattr=+experimental-zawrs -riscv-no-aliases -show-encoding \
+# RUN:     | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+experimental-zawrs < %s \
+# RUN:     | llvm-objdump --mattr=+experimental-zawrs -M no-aliases -d -r - \
+# RUN:     | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv64 -mattr=+experimental-zawrs < %s \
+# RUN:     | llvm-objdump --mattr=+experimental-zawrs -M no-aliases -d -r - \
+# RUN:     | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+
+# CHECK-ASM-AND-OBJ: wrs.nto
+# CHECK-ASM: encoding: [0x73,0x00,0xd0,0x00]
+wrs.nto
+
+# CHECK-ASM-AND-OBJ: wrs.sto
+# CHECK-ASM: encoding: [0x73,0x00,0xd0,0x01]
+wrs.sto

llvm/test/MC/RISCV/attribute-arch.s

 # CHECK: attribute      5, "rv32i2p0_c2p0_zihintntl0p2"
 
 .attribute arch, "rv32if_zkt1p0_zve32f1p0_zve32x1p0_zvl32b1p0"
 # CHECK: attribute      5, "rv32i2p0_f2p0_zkt1p0_zve32f1p0_zve32x1p0_zvl32b1p0"
 
 .attribute arch, "rv32izca0p70"
 # CHECK: attribute      5, "rv32i2p0_zca0p70"
 
+.attribute arch, "rv32izawrs1p0"
+# CHECK: attribute      5, "rv32i2p0_zawrs1p0"
+
 .attribute arch, "rv32iztso0p1"
 # CHECK: attribute      5, "rv32i2p0_ztso0p1"