[PATCH] D92205: [RISCV] Remove DIVUW/REMUW patterns that don't seem right

[Craig Topper via Phabricator via llvm-commits]

craig.topper created this revision.
craig.topper added reviewers: asb, lenary, luismarques, frasercrmck, HsiangKai, evandro.
Herald added subscribers: NickHung, apazos, sameer.abuasal, pzheng, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, shiva0217, kito-cheng, niosHD, sabuasal, simoncook, johnrusso, rbar, hiraditya.
Herald added a project: LLVM.
craig.topper requested review of this revision.
Herald added a subscriber: MaskRay.

These patterns are looking for DIVUW/REMUW with inputs zero extended from 32 bits to 64 and the result being zero extended from 32 bits to 64 bits. This is selected to a DIVUW/REMUW instruction.

As far as I can tell DIVUW/REMUW will sign extend bit 31 in the result. So this isel pattern would only work if the pattern guaranteed that bit 31 of the result was zero so that sign extend would produce zeros. I don't believe the input being zero extended from 32 to 64 bits guarantee that.  For example won't (divuw 0xffffffff, 1) produce 0xffffffffffffffff? Similarly won't (remuw 0x80000000, 0xffffffff) produce 0xffffffff80000000?


https://reviews.llvm.org/D92205

Files:
  llvm/lib/Target/RISCV/RISCVInstrInfoM.td
  llvm/test/CodeGen/RISCV/rv64m-exhaustive-w-insts.ll


Index: llvm/test/CodeGen/RISCV/rv64m-exhaustive-w-insts.ll
===================================================================
--- llvm/test/CodeGen/RISCV/rv64m-exhaustive-w-insts.ll
+++ llvm/test/CodeGen/RISCV/rv64m-exhaustive-w-insts.ll
@@ -520,7 +520,9 @@
 define zeroext i32 @zext_divuw_zext_zext(i32 zeroext %a, i32 zeroext %b) nounwind {
 ; RV64IM-LABEL: zext_divuw_zext_zext:
 ; RV64IM:       # %bb.0:
-; RV64IM-NEXT:    divu a0, a0, a1
+; RV64IM-NEXT:    divuw a0, a0, a1
+; RV64IM-NEXT:    slli a0, a0, 32
+; RV64IM-NEXT:    srli a0, a0, 32
 ; RV64IM-NEXT:    ret
   %1 = udiv i32 %a, %b
   ret i32 %1
@@ -1301,7 +1303,9 @@
 define zeroext i32 @zext_remuw_zext_zext(i32 zeroext %a, i32 zeroext %b) nounwind {
 ; RV64IM-LABEL: zext_remuw_zext_zext:
 ; RV64IM:       # %bb.0:
-; RV64IM-NEXT:    remu a0, a0, a1
+; RV64IM-NEXT:    remuw a0, a0, a1
+; RV64IM-NEXT:    slli a0, a0, 32
+; RV64IM-NEXT:    srli a0, a0, 32
 ; RV64IM-NEXT:    ret
   %1 = urem i32 %a, %b
   ret i32 %1
Index: llvm/lib/Target/RISCV/RISCVInstrInfoM.td
===================================================================
--- llvm/lib/Target/RISCV/RISCVInstrInfoM.td
+++ llvm/lib/Target/RISCV/RISCVInstrInfoM.td
@@ -78,14 +78,6 @@
 def : PatGprGpr<riscv_divuw, DIVUW>;
 def : PatGprGpr<riscv_remuw, REMUW>;
 
-// Handle the specific cases where using DIVU/REMU would be correct and result
-// in fewer instructions than emitting DIVUW/REMUW then zero-extending the
-// result.
-def : Pat<(zexti32 (riscv_divuw (zexti32 GPR:$rs1), (zexti32 GPR:$rs2))),
-          (DIVU GPR:$rs1, GPR:$rs2)>;
-def : Pat<(zexti32 (riscv_remuw (zexti32 GPR:$rs1), (zexti32 GPR:$rs2))),
-          (REMU GPR:$rs1, GPR:$rs2)>;
-
 // Although the sexti32 operands may not have originated from an i32 srem,
 // this pattern is safe as it is impossible for two sign extended inputs to
 // produce a result where res[63:32]=0 and res[31]=1.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D92205.307949.patch
Type: text/x-patch
Size: 1894 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201127/2b83c01b/attachment.bin>