[llvm] [AMDGPU] Fix decoder for BF16 inline constants (PR #82276)

Stanislav Mekhanoshin via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 20 00:28:37 PST 2024


================
@@ -1108,24 +1108,34 @@ class RegOrImmOperand <RegisterClass RegClass, string OperandTypeName>
     let ParserMatchClass = RegImmMatcher<!subst("_Deferred", "", NAME)>;
 }
 
+// Should be in sync with the OperandSematics defined in SIDefines.h
+def OperandSematics {
+  int INT = 0;
+  int FP16 = 1;
+  int BF16 = 2;
+  int FP32 = 3;
+  int FP64 = 4;
+}
+
 //===----------------------------------------------------------------------===//
 //  SSrc_* Operands with an SGPR or a 32-bit immediate
 //===----------------------------------------------------------------------===//
 
 class SrcRegOrImm9<RegisterClass regClass, string opWidth, string operandType,
-                   int immWidth> : RegOrImmOperand<regClass, operandType> {
+                   int immWidth, int OperandSematics>
+    : RegOrImmOperand<regClass, operandType> {
   let DecoderMethod = "decodeSrcRegOrImm9<AMDGPUDisassembler::" # opWidth #
-                      ", " # immWidth # ">";
+                      ", " # immWidth # ", " # OperandSematics # ">";
 }
 
-def SSrc_b16 : SrcRegOrImm9 <SReg_32, "OPW32", "OPERAND_REG_IMM_INT16", 16>;
-def SSrc_bf16: SrcRegOrImm9 <SReg_32, "OPW32", "OPERAND_REG_IMM_BF16", 16>;
-def SSrc_f16 : SrcRegOrImm9 <SReg_32, "OPW32", "OPERAND_REG_IMM_FP16", 16>;
-def SSrc_b32 : SrcRegOrImm9 <SReg_32, "OPW32", "OPERAND_REG_IMM_INT32", 32>;
-def SSrc_f32 : SrcRegOrImm9 <SReg_32, "OPW32", "OPERAND_REG_IMM_FP32", 32>;
-def SSrc_b64 : SrcRegOrImm9 <SReg_64, "OPW64", "OPERAND_REG_IMM_INT64", 64>;
+def SSrc_b16 : SrcRegOrImm9 <SReg_32, "OPW32", "OPERAND_REG_IMM_INT16", 16, OperandSematics.INT>;
----------------
rampitec wrote:

That said it may have sense to drop immwidth and the rest, and keep only OperandSemantics, extending it to all scalar types, possibly renaming the whole thing. I didn't explore it, but I guess it may have its pluses and minuses. It is a little iffy when it goes beyond scalar types. This would be really a different change.

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


More information about the llvm-commits mailing list