[PATCH] D49179: [InstCombine] Fold x & (-1 >> y) == x to x u<= (-1 >> y)

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In https://reviews.llvm.org/D49179#1159036, @spatel wrote:

> In https://reviews.llvm.org/D49179#1159024, @lebedev.ri wrote:
>
> > In https://reviews.llvm.org/D49179#1158957, @lebedev.ri wrote:
> >
> > > In https://reviews.llvm.org/D49179#1158930, @spatel wrote:
> > >
> > > > LGTM.
> > >
> > >
> > > Thank you for such speedy review!
> > >
> > > I'm wondering, what about the signed case?
> > >  https://godbolt.org/g/WvWX13
> > >  https://godbolt.org/g/DM7XA4
> > >  https://rise4fun.com/Alive/Qslx (check that 25 high bits are either all-ones, or all-zeros)
> > >
> > > Can we do this in instcombine?
> > >  Or not, given that we were disabling some bit-fiddling transforms lately?
> >
> >
> > Actually, not sure that is any better, will leave that for now.
> >  Though the reverse transform might be a good thing for dagcombine.
>
>
> It's a good question, but probably better asked on the dev list than here. I think we prefer to canonicalize to the form with less instructions even if that means we lose information from the eliminated ops.


For future reference, here is a more straight-forward fold https://rise4fun.com/Alive/XuW, that will afterwards fold back into and+icmp https://godbolt.org/g/bm3yZu
But any such fold will clearly need dagcombine work, since the 'naive' version with shifts seems to produce optimal assembly already.
So after all i'm not sure i'm motivated to look into the 'signed truncation pattern' right now..
F6668611: x86-signed-truncation-check.ll <https://reviews.llvm.org/F6668611> F6668610: aarch64-signed-truncation-check.ll <https://reviews.llvm.org/F6668610>


Repository:
  rL LLVM

https://reviews.llvm.org/D49179