[llvm] [InstCombine] Improve shamt range calculation (PR #72646)

[via llvm-commits]

goldsteinn wrote:

> > > It looks like this only affects tests using non-splat vectors. I'm usually not willing to accept improvements for non-splat vector support unless they are completely free in terms of complexity. Is there any particular reason why we would want this support?
> > > (I'm not particularly strongly opposed though. If you think it has value I'm okay with it.)
> > 
> > 
> > The impl doesn't seem to go out of ways to handle non-splats, just they are a byproduct.
> 
> Right, I get that the implementation is not specific to non-splat vectors. I'm mainly commenting on what I see in the test coverage.
> 
Are you opposed to the impl, or just to the test coverage we have right now?
> Usually, we use getConstantRangeIncludingKnownBits() in places where accurate handling for non-power-of-two ranges is important, e.g. if we care that `urem 42` has an upper bound of 41, not of 63.
> 
> > Think you could create the same result with `(add (and X, ~Pow2), Pow2 * 3)` where we could get the knownbit but not the range.
> 
> I didn't understand this example.

Just a case we will get info from knownbits not from constantrange.

https://github.com/llvm/llvm-project/pull/72646