[RISCV] Allocate Feature Bits for Zilsd/Zclsd/Zcmp

[lenary]

As proposed in riscv-non-isa/riscv-c-api-doc#104

No real compiler-rt implementation, as these are not exposed by Linux.

[llvmbot]

@llvm/pr-subscribers-backend-risc-v

Author: Sam Elliott (lenary)

Changes

As proposed in riscv-non-isa/riscv-c-api-doc#104

No real compiler-rt implementation, as these are not exposed by Linux.

---

Full diff: https://github.com/llvm/llvm-project/pull/135197.diff

2 Files Affected:

• (modified) compiler-rt/lib/builtins/cpu_model/riscv.c (+6)
• (modified) llvm/lib/Target/RISCV/RISCVFeatures.td (+6-3)

diff --git a/compiler-rt/lib/builtins/cpu_model/riscv.c b/compiler-rt/lib/builtins/cpu_model/riscv.c
index 6879c2ad48264..4d0fda473c87e 100644
--- a/compiler-rt/lib/builtins/cpu_model/riscv.c
+++ b/compiler-rt/lib/builtins/cpu_model/riscv.c
@@ -128,6 +128,12 @@ struct {
 #define ZCMOP_BITMASK (1ULL << 6)
 #define ZAWRS_GROUPID 1
 #define ZAWRS_BITMASK (1ULL << 7)
+#define ZILSD_GROUPID 1
+#define ZILSD_BITMASK (1ULL << 8)
+#define ZCLSD_GROUPID 1
+#define ZCLSD_BITMASK (1ULL << 9)
+#define ZCMP_GROUPID 1
+#define ZCMP_BITMASK (1ULL << 10)
 
 #if defined(__linux__)
 
diff --git a/llvm/lib/Target/RISCV/RISCVFeatures.td b/llvm/lib/Target/RISCV/RISCVFeatures.td
index 60d3c0f397371..b3def7c437a2d 100644
--- a/llvm/lib/Target/RISCV/RISCVFeatures.td
+++ b/llvm/lib/Target/RISCV/RISCVFeatures.td
@@ -178,7 +178,8 @@ def NoHasStdExtZicfiss : Predicate<"!Subtarget->hasStdExtZicfiss()">;
 
 def FeatureStdExtZilsd
     : RISCVExtension<1, 0,
-                     "Load/Store Pair Instructions">;
+                     "Load/Store Pair Instructions">,
+      RISCVExtensionBitmask<1, 8>;
 def HasStdExtZilsd : Predicate<"Subtarget->hasStdExtZilsd()">,
                        AssemblerPredicate<(all_of FeatureStdExtZilsd),
                                           "'Zilsd' (Load/Store pair instructions)">;
@@ -411,7 +412,8 @@ def FeatureStdExtZcf
 def FeatureStdExtZclsd
     : RISCVExtension<1, 0,
                      "Compressed Load/Store Pair Instructions",
-                     [FeatureStdExtZilsd, FeatureStdExtZca]>;
+                     [FeatureStdExtZilsd, FeatureStdExtZca]>,
+      RISCVExtensionBitmask<1, 9>;
 def HasStdExtZclsd : Predicate<"Subtarget->hasStdExtZclsd()">,
                     AssemblerPredicate<(all_of FeatureStdExtZclsd),
                         "'Zclsd' (Compressed Load/Store pair instructions)">;
@@ -419,7 +421,8 @@ def HasStdExtZclsd : Predicate<"Subtarget->hasStdExtZclsd()">,
 def FeatureStdExtZcmp
     : RISCVExtension<1, 0,
                      "sequenced instructions for code-size reduction",
-                     [FeatureStdExtZca]>;
+                     [FeatureStdExtZca]>,
+      RISCVExtensionBitmask<1, 10>;
 def HasStdExtZcmp : Predicate<"Subtarget->hasStdExtZcmp() && !Subtarget->hasStdExtC()">,
                     AssemblerPredicate<(all_of FeatureStdExtZcmp),
                         "'Zcmp' (sequenced instructions for code-size reduction)">;

[wangpc-pp]

LGTM but is it right to land this before kernel supports?

[lenary]

is it right to land this before kernel supports?

To provide some context I provided on the toolchains call, with assistance from Kito:

• Zilsd/Zclsd are 32-bit only, so may take some time to appear in linux, if they ever do.
• Zcmp is incompatible with Zcd, so may not appear in linux hwcaps if linux focuses on rv64gc (or the profiles that include C+D, which implicitly have Zcd)

These bitmaps have been proposed because the Hazard3 core wants to skip any heavyweight capabilites spec, and just directly implement the C API's bitmap layout in hardware. This core implements these three extensions, and it is perfectly possible for a SDK to expose something compatible with the C API without it being linux.

LLVM/GCC implementations are a prerequisite for allocating these bits in the C API, which is why we have this implementation.

[wangpc-pp]

is it right to land this before kernel supports?

To provide some context I provided on the toolchains call, with assistance from Kito:

• Zilsd/Zclsd are 32-bit only, so may take some time to appear in linux, if they ever do.
• Zcmp is incompatible with Zcd, so may not appear in linux hwcaps if linux focuses on rv64gc (or the profiles that include C+D, which implicitly have Zcd)

These bitmaps have been proposed because the Hazard3 core wants to skip any heavyweight capabilites spec, and just directly implement the C API's bitmap layout in hardware. This core implements these three extensions, and it is perfectly possible for a SDK to expose something compatible with the C API without it being linux.

LLVM/GCC implementations are a prerequisite for allocating these bits in the C API, which is why we have this implementation.

Got it! Then I am OK with this, please go ahead!

[BeMg]

Should we update here as well, or wait until the real implementation in FMV/compiler-rt?

llvm-project/llvm/lib/TargetParser/RISCVISAInfo.cpp

Line 1029 in a2994de

constexpr static RISCVExtBit RISCVBitPositions[] = {

It will make Clang raise a warning and ignore the FMV if target_clones/target_version uses an extension not in this list.

[wangpc-pp]

Should we update here as well, or wait until the real implementation in FMV/compiler-rt?

llvm-project/llvm/lib/TargetParser/RISCVISAInfo.cpp

Line 1029 in a2994de

constexpr static RISCVExtBit RISCVBitPositions[] = {

It will make Clang raise a warning and ignore the FMV if target_clones/target_version uses an extension not in this list.

Why is this table not generated by TableGen?

[BeMg]

Should we update here as well, or wait until the real implementation in FMV/compiler-rt?

llvm-project/llvm/lib/TargetParser/RISCVISAInfo.cpp

Line 1029 in a2994de

constexpr static RISCVExtBit RISCVBitPositions[] = {

It will make Clang raise a warning and ignore the FMV if target_clones/target_version uses an extension not in this list.

Why is this table not generated by TableGen?

In my opinion, it should be generated by TableGen. It is a standalone table according to #99700 (comment).

[lenary]

That table explains why I couldn't find uses of the structures generated from tablegen that I was expecting to find. Yes I shall update it. Yes all the info in that table is now available in tablegen and we should generate it.

[wangpc-pp]

That table explains why I couldn't find uses of the structures generated from tablegen that I was expecting to find. Yes I shall update it. Yes all the info in that table is now available in tablegen and we should generate it.

#135600

[lenary]

I don't think we need to wait for a "real" implementation in compiler-rt, because we don't expect linux HW_CAPS to come for these extensions for quite some time. The question remains as to whether anything else is needed for this change, maybe a test? I'm not sure.

[BeMg]

LGTM.

[wangpc-pp]

LGTM. I think we can go ahead with current version. I have no idea how this can be tested so I'd just let it go.