[PATCH] D68239: [InstCombine] dropRedundantMaskingOfLeftShiftInput(): propagate undef shift amounts
Roman Lebedev via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sun Oct 6 07:21:26 PDT 2019
lebedev.ri marked 4 inline comments as done.
lebedev.ri added a comment.
In D68239#1696589 <https://reviews.llvm.org/D68239#1696589>, @spatel wrote:
> LGTM
Thank you for the review!
There's second half of the patch in D68470 <https://reviews.llvm.org/D68470>.
I did't post the actual patch adding trunc support yet, tests needed...
================
Comment at: llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp:190-192
+ // If any of these shift amounts are undef, *ext will turn them into
+ // zeros, let's keep undef's by replacing them with some illegal shift
+ // amount.
----------------
spatel wrote:
> lebedev.ri wrote:
> > spatel wrote:
> > > lebedev.ri wrote:
> > > > spatel wrote:
> > > > > Probably worth explaining this more directly, and what if we make it consistent by replacing with -1?
> > > > > // An extend of an undef value becomes zero because the
> > > > > // high bits are never completely unknown. Replace the
> > > > > // the shift amount with -1 to ensure that the value remains
> > > > > // undef when creating the subsequent shift op.
> > > > Good comments are always good :)
> > > > Not with -1 though.
> > > Why is using different variants based on bidwidth better? Or does -1 not work as a poisonous shift amount?
> > In this branch - yes, i think `-1` should work.
> > But in other branch we will negate that shift amount and add innermost shift bitwidth to it.
> > What i'm trying to say is, it is not so much about that the replacement shift amount *here*
> > will still produce `undef`, but it must do so when we actually perform the shift.
> > It seemed consistent to me to end up with same shift-by-bitwidth in both branches.
> >
> > Let me know if that explanation does not make any sense.
> Ok, I see what you mean. It seems like we're missing some analysis that would handle this sort of thing for us cleanly, but I don't see where/how to implement it, so I won't hold this up.
Yeah..
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D68239/new/
https://reviews.llvm.org/D68239
More information about the llvm-commits
mailing list