From e0481048abd33079261c9aa701c0916a52941dc3 Mon Sep 17 00:00:00 2001 From: Craig Topper Date: Thu, 26 Nov 2020 22:31:13 -0800 Subject: [PATCH] [RISCV] Don't remove (and X, 0xffffffff) from inputs when matching RISCVISD::DIVUW/REMUW to 64-bit DIVU/REMU. These patterns are using zexti32 which matches either assertzexti32 or (and X, 0xffffffff). But if we match (and X, 0xffffffff) it will remove the AND and the inputs may no longer have the zero bits needed to guarantee the result has enough zeros. This commit changes the patterns to only match assertzexti32. I'm not sure how to test the broken case since the DIVUW/REMUW nodes are created during type legalization, but type legalization won't create an (and X, 0xfffffffff) directly on the inputs. I've also changed the zexti32 on the root of the pattern to just checking for AND. We were previously also matching assertzexti32, but I doubt that pattern would ever occur. --- llvm/lib/Target/RISCV/RISCVInstrInfoM.td | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/llvm/lib/Target/RISCV/RISCVInstrInfoM.td b/llvm/lib/Target/RISCV/RISCVInstrInfoM.td index 987534a..8cfb903 100644 --- a/llvm/lib/Target/RISCV/RISCVInstrInfoM.td +++ b/llvm/lib/Target/RISCV/RISCVInstrInfoM.td @@ -81,9 +81,11 @@ def : PatGprGpr; // 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))), +def : Pat<(and (riscv_divuw (assertzexti32 GPR:$rs1), + (assertzexti32 GPR:$rs2)), 0xffffffff), (DIVU GPR:$rs1, GPR:$rs2)>; -def : Pat<(zexti32 (riscv_remuw (zexti32 GPR:$rs1), (zexti32 GPR:$rs2))), +def : Pat<(and (riscv_remuw (assertzexti32 GPR:$rs1), + (assertzexti32 GPR:$rs2)), 0xffffffff), (REMU GPR:$rs1, GPR:$rs2)>; // Although the sexti32 operands may not have originated from an i32 srem, -- 2.7.4