[llvm] [RISCV] 'Zalrsc' may permit non-base instructions (PR #165042)

[Craig Topper via llvm-commits]

================
@@ -1906,6 +1906,22 @@ def FeatureForcedAtomics : SubtargetFeature<
 def HasAtomicLdSt
     : Predicate<"Subtarget->hasStdExtZalrsc() || Subtarget->hasForcedAtomics()">;
 
+// The RISC-V Unprivileged Architecture defines _constrained_ LR/SC loops:
+//   The dynamic code executed between the LR and SC instructions can only
+//   contain instructions from the base ''I'' instruction set, excluding loads,
+//   stores, backward jumps, taken backward branches, JALR, FENCE, and SYSTEM
+//   instructions. Compressed forms of the aforementioned ''I'' instructions in
+//   the Zca and Zcb extensions are also permitted.
+// LR/SC loops that do not adhere to the above are _unconstrained_ LR/SC loops,
+// and success is implementation specific. For implementations which know that
+// non-base instructions (such as the ''B'' extension) will not violate any
+// forward progress guarantees, using these instructions to reduce the LR/SC
+// sequence length is desirable.
+def FeaturePermissiveZalrsc
+    : SubtargetFeature<
+          "permissive-zalrsc", "HasPermissiveZalrsc", "true",
+          "Implementation permits non-base instructions between LR/SC pairs">;
----------------
topperc wrote:

I'm not sure if a non-extension should imply an extension. That makes it possible to define a CPU that directly uses FeaturePermissiveZalrsc but not FeatureStdExtZalrsc. RISCVTargetParser.inc won't be generated with zalrsc in the default ISA string for that CPU. I'm not sure if that would prevent the frontend from knowing about it and setting the `__riscv_zalrsc` preprocessor define.

https://github.com/llvm/llvm-project/pull/165042