[PATCH] D69387: [ConstantRange] Add toKnownBits() method

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

@nikic

In D69387#1815006 <https://reviews.llvm.org/D69387#1815006>, @lebedev.ri wrote:

> In D69387#1814994 <https://reviews.llvm.org/D69387#1814994>, @nikic wrote:
>
> > In D69387#1814981 <https://reviews.llvm.org/D69387#1814981>, @lebedev.ri wrote:
> >
> > > In D69387#1722346 <https://reviews.llvm.org/D69387#1722346>, @nikic wrote:
> > >
> > > > So, this looks fine, but I'm still not quite clear on the use-case. I thought this might be useful for computing ranges of bit ops, but now that I see the implementation, I don't think that's the case. We just get the known top bits, but lose any information about the low bits (which can still be used, though in an operation-specific manner).
> > > >
> > > > We should probably have some case where we can actually use this before landing.
> > >
> > >
> > > Would we not be better-off using this rather than whatever conservative implementation we currently have for `binaryAnd()`/`binaryOr()`/`binaryXor()`?
> >
> >
> > That's what I initially thought as well, but I don't think it's the case. For example, binaryAnd() currently returns [0, umin(A.umax(), B.umax())]. If we have A unknown and B=[0, 0b0100] then we get as result [0, 0b0100]. If we base this on toKnownBits(), we'd get [0, 0b0111]`, because only the top bit ends up being known.
>
>
> And `binaryXor()`?
>
> > Which is what made me think that toKnownBits() is likely not really a useful primitive, as it looses to much information.





Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69387