Our CI caught regression from e1aa91b36325
that breaks the ANDI by turning -4 into 0x7ffffffc,
but I see that the commmit make sense, try to fix the regression.
Regarding ShrinkDemandedConstant, I am still learning
and willing to learn if there is a better solution.
Details
Details
- Reviewers
craig.topper reames
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
This patch relies on the D153934.
Otherwise, I tried another method:
diff --git a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp index ef9e96b6cca4..9a46455017c6 100644 --- a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp +++ b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp @@ -13020,7 +13020,7 @@ bool RISCVTargetLowering::targetShrinkDemandedConstant( // For the remaining optimizations, we need to be able to make a negative // number through a combination of mask and undemanded bits. - if (!ExpandedMask.isNegative()) + if (!ExpandedMask.isNegative() && Opcode != ISD::AND) return false; // What is the fewest number of bits we need to represent the negative number. @@ -13034,8 +13034,13 @@ bool RISCVTargetLowering::targetShrinkDemandedConstant( NewMask.setBitsFrom(11); else if (!C->isOpaque() && MinSignedBits <= 32 && !ShrunkMask.isSignedIntN(32)) NewMask.setBitsFrom(31); - else - return false; + else { + NewMask.setBitsFrom(31); + if (Opcode == ISD::AND && !C->isOpaque() && MinSignedBits <= 32 && !ShrunkMask.isSignedIntN(32) && NewMask.isSignedIntN(12)) + return UseMask(NewMask); + else + return false; + } // Check that our new mask is a subset of the demanded mask. assert(IsLegalMask(NewMask));
Comment Actions
Just because I saw the word "regression" in my inbox and worried we were generating wrong code, it's probably best to explicitly say you're talking about fixing a performance regression. Or is it a code size regression? I couldn't tell from the link.
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
9378 | I’m not sure this is correct. We used ANY_EXTEND for the value to be shifted. That creates a new unknown sign bit. We can no longer be sure that wrap does not occur relative to that unknown sign. |
Comment Actions
I don't find a better way to implement it, I'll create new patch if I have a better idea, thanks for the review.
I’m not sure this is correct. We used ANY_EXTEND for the value to be shifted. That creates a new unknown sign bit. We can no longer be sure that wrap does not occur relative to that unknown sign.