[PATCH] D107658: [RISCV] Teach isel to select ADDW/SUBW/MULW/SLLIW when only the lower 32-bits are used.

Jessica Clarke via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 18 05:08:03 PDT 2021


jrtc27 added a comment.

In D107658#2951152 <https://reviews.llvm.org/D107658#2951152>, @craig.topper wrote:

> In D107658#2951066 <https://reviews.llvm.org/D107658#2951066>, @jrtc27 wrote:
>
>> What's the reasoning behind the current set of opcodes? E.g. are there cases where div[u]w/rem[u]w or sra[i]w/srl[i]w are worth using?
>
> These are the only opcodes that are type legalized by any_extend because the result in the lower 32 bits doesn't depend on the upper 32 bits after promotion. The other binary operators use RISCVISD::*W ISD opcodes or require a sign_extend_inreg/zero_extend_inreg because the upper 32 bits can effect the lower 32 bits. These are also the only opcodes used in an isel pattern that starts with sext_inreg.
>
> I'm probably going to explain the rest of this poorly, but I'll try.
>
> div[u]w/remuw are converted to their own special ISD opcode during type legalization. I believe there was a subtle issue with pattern matching ISD::DIV/UDIV/UREM and zext_inreg/sext_inreg to the W instructions. We can only pattern match ISD::SREM+sext_inreg to REMW.
>
> sraiw/srliw are type legalized by inserting a sext_inreg or zext_inreg. We select SRAIW/SRLIW based on the inputs being a sext_inreg/zext_inreg(or the equivalent computeKnownBits/computeNumSignBits) and the immediate fitting in 5 bits. We can't select SRAIW/SRLIW based on how the result is used. We need to know that sign bits or 0 are supposed to be shifted into bit 31.
>
> sraw/srlw are type legalized using their own RISCVISD::SRAW/SRLW nodes. Since we can't see the shift amount, we need these ISD opcodes in order to know that it was UB for the shift amount to be more than 5 bits. Default type legalization would insert a sext_inreg/zext_inreg, but we can't pattern match that if we don't know sure that it came from a type legalized i32 shift and an i64 shift that happened to have a sext_inreg/zext_inreg input. If it came from an i64 shift we might incorrectly ignore bit 5 of the shift amount by turning it into a W instruction.

Thanks, that makes sense.



================
Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoM.td:74
 
+def mulw : PatFrag<(ops node:$lhs, node:$rhs),
+                   (mul node:$lhs, node:$rhs), [{
----------------
You can use your new class here too


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107658/new/

https://reviews.llvm.org/D107658



More information about the llvm-commits mailing list