[RISCV] Accept [-128,255] instead of [0, 255] for pli.b

[topperc]

pli.h and pli.w both accept signed immediates, so pli.b should too. But unlike those instructions, pli.b doesn't do any extension so its ok to accept an unsigned immediate as well.

[llvmbot]

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

Author: Craig Topper (topperc)

Changes

This is more consistent with pli.h and pli.w which use sign extension to turn their 10 bit immediate into 16 or 32 bits. For pli.b no extension occurs.

This also matches the prototype binutils patch here https://github.com/ruyisdk/riscv-binutils/commits/p-dev/

---

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

6 Files Affected:

• (modified) llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp (+4)
• (modified) llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h (+1)
• (modified) llvm/lib/Target/RISCV/RISCVInstrInfoP.td (+5-4)
• (modified) llvm/test/MC/RISCV/rv32p-invalid.s (+1-1)
• (modified) llvm/test/MC/RISCV/rv32p-valid.s (+3)
• (modified) llvm/test/MC/RISCV/rv64p-valid.s (+3)

diff --git a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
index d71c42c0a5fc1..4afc0b3d447d8 100644
--- a/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
+++ b/llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
@@ -808,6 +808,7 @@ struct RISCVOperand final : public MCParsedAsmOperand {
 
   bool isSImm5() const { return isSImm<5>(); }
   bool isSImm6() const { return isSImm<6>(); }
+  bool isSImm8() const { return isSImm<8>(); }
   bool isSImm10() const { return isSImm<10>(); }
   bool isSImm11() const { return isSImm<11>(); }
   bool isSImm16() const { return isSImm<16>(); }
@@ -1547,6 +1548,9 @@ bool RISCVAsmParser::matchAndEmitInstruction(SMLoc IDLoc, unsigned &Opcode,
     return generateImmOutOfRangeError(
         Operands, ErrorInfo, 0, (1 << 9) - 8,
         "immediate must be a multiple of 8 bytes in the range");
+  case Match_InvalidSImm8:
+    return generateImmOutOfRangeError(Operands, ErrorInfo, -(1 << 7),
+                                      (1 << 7) - 1);
   case Match_InvalidSImm10:
     return generateImmOutOfRangeError(Operands, ErrorInfo, -(1 << 9),
                                       (1 << 9) - 1);
diff --git a/llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h b/llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
index 9d26fc01bf379..083ac056ac72c 100644
--- a/llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
+++ b/llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
@@ -346,6 +346,7 @@ enum OperandType : unsigned {
   OPERAND_SIMM5_PLUS1,
   OPERAND_SIMM6,
   OPERAND_SIMM6_NONZERO,
+  OPERAND_SIMM8,
   OPERAND_SIMM10,
   OPERAND_SIMM10_LSB0000_NONZERO,
   OPERAND_SIMM11,
diff --git a/llvm/lib/Target/RISCV/RISCVInstrInfoP.td b/llvm/lib/Target/RISCV/RISCVInstrInfoP.td
index e67417035963a..84f7e3f588fbc 100644
--- a/llvm/lib/Target/RISCV/RISCVInstrInfoP.td
+++ b/llvm/lib/Target/RISCV/RISCVInstrInfoP.td
@@ -18,7 +18,8 @@
 // Operand and SDNode transformation definitions.
 //===----------------------------------------------------------------------===//
 
-def simm10 : RISCVSImmLeafOp<10>;
+def simm8 : RISCVSImmOp<8>;
+def simm10 : RISCVSImmOp<10>;
 
 def SImm10UnsignedAsmOperand : SImmAsmOperand<10, "Unsigned"> {
   let RenderMethod = "addSImm10UnsignedOperands";
@@ -75,13 +76,13 @@ class PLUI_i<bits<7> funct7, string opcodestr>
 
 let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in
 class PLI_B_i<bits<8> funct8, string opcodestr>
-    : RVInst<(outs GPR:$rd), (ins uimm8:$uimm8), opcodestr, "$rd, $uimm8", [],
+    : RVInst<(outs GPR:$rd), (ins simm8:$imm8), opcodestr, "$rd, $imm8", [],
              InstFormatOther> {
-  bits<8> uimm8;
+  bits<8> imm8;
   bits<5> rd;
 
   let Inst{31-24} = funct8;
-  let Inst{23-16} = uimm8;
+  let Inst{23-16} = imm8;
   let Inst{15}    = 0b0;
   let Inst{14-12} = 0b010;
   let Inst{11-7} = rd;
diff --git a/llvm/test/MC/RISCV/rv32p-invalid.s b/llvm/test/MC/RISCV/rv32p-invalid.s
index 7dd73d077bf3a..bc3110937ef8f 100644
--- a/llvm/test/MC/RISCV/rv32p-invalid.s
+++ b/llvm/test/MC/RISCV/rv32p-invalid.s
@@ -4,7 +4,7 @@
 # Imm overflow
 pli.h a0, 0x400 # CHECK: :[[@LINE]]:11: error: immediate must be an integer in the range [-512, 511]
 plui.h a1, 0x400 # CHECK: :[[@LINE]]:12: error: immediate must be an integer in the range [-512, 1023]
-pli.b a0, 0x200 # CHECK: :[[@LINE]]:11: error: immediate must be an integer in the range [0, 255]
+pli.b a0, 0x200 # CHECK: :[[@LINE]]:11: error: immediate must be an integer in the range [-128, 127]
 
 pslli.b a6, a7, 100 # CHECK: :[[@LINE]]:17: error: immediate must be an integer in the range [0, 7]
 pslli.h ra, sp, 100 # CHECK: :[[@LINE]]:17: error: immediate must be an integer in the range [0, 15]
diff --git a/llvm/test/MC/RISCV/rv32p-valid.s b/llvm/test/MC/RISCV/rv32p-valid.s
index 0383e4ec1ea62..d5e8299131f10 100644
--- a/llvm/test/MC/RISCV/rv32p-valid.s
+++ b/llvm/test/MC/RISCV/rv32p-valid.s
@@ -61,6 +61,9 @@ pli.h a5, 16
 # CHECK-ASM-AND-OBJ: pli.b a6, 16
 # CHECK-ASM: encoding: [0x1b,0x28,0x10,0xb4]
 pli.b a6, 16
+# CHECK-ASM-AND-OBJ: pli.b a6, -128
+# CHECK-ASM: encoding: [0x1b,0x28,0x80,0xb4]
+pli.b a6, -128
 # CHECK-ASM-AND-OBJ: psext.h.b a7, a0
 # CHECK-ASM: encoding: [0x9b,0x28,0x45,0xe0]
 psext.h.b a7, a0
diff --git a/llvm/test/MC/RISCV/rv64p-valid.s b/llvm/test/MC/RISCV/rv64p-valid.s
index 5e0b22759abf4..99bb4372aebab 100644
--- a/llvm/test/MC/RISCV/rv64p-valid.s
+++ b/llvm/test/MC/RISCV/rv64p-valid.s
@@ -79,6 +79,9 @@ pli.w a5, 5
 # CHECK-ASM-AND-OBJ: pli.b a6, 6
 # CHECK-ASM: encoding: [0x1b,0x28,0x06,0xb4]
 pli.b a6, 6
+# CHECK-ASM-AND-OBJ: pli.b a6, -1
+# CHECK-ASM: encoding: [0x1b,0x28,0xff,0xb4]
+pli.b a6, -1
 # CHECK-ASM-AND-OBJ: psext.h.b t3, a2
 # CHECK-ASM: encoding: [0x1b,0x2e,0x46,0xe0]
 psext.h.b t3, a2

[lenary]

If there's no extension, why not accept either signed or unsigned (i.e. [-127, 255])? That still leaves the problem of what to print, but that's not a huge problem, as I think we've mostly settled on signed for those cases.

[lenary]

We could also end up with a terrible "fix immediate" hack, but I'm not sure. I just worry about people writing 0xff because that's clearer for their usecase, and it being rejected.

[lenary]

LGTM