[llvm] [VectorCombine] Fold vector sign-bit checks (PR #175194)

[Valeriy Savchenko via llvm-commits]

SavchenkoValeriy wrote:

> High level comment. I think this transform can be split into several sub-transforms. I am not expressing an opinion as to whether this change should land before or after such a split, and will leave that up to area reviewers.
> 

Thanks for the comment, I always strive to split desired folds into smaller more general folds (as actually the case here as well).

> Your proposed transform of
> 
> ```
>  icmp pred (reduce.{add,or,and,umax,umin}(lshr X, BitWidth-1)), C
>     ->  icmp slt/sgt (reduce.{or,umax,and,umin}(X)), 0/-1
> ```
> 
> Possible splits:
> 
> (1) `reduce.{or,and,umax,umin}(lshr X, BitWidth-1)) -> lshr (reduce.{or,and,umax,umin} X), BitWidth-1`
> 
> (This generalizes for any logical op. Note that we should already be canonicalizing smin/smax to umin/umax; if not that's another to play with.)
> 
> (2) Your inequality handling is just a transform to convert the inequality form to the equality form (of the source).
> 
> I believe that (1) generalizes for any single bit extract (i.e. and X, 2).

I don't oppose it, but it actually doesn't help with the motivation example that is about reduce.add` that I generalized to this transformation. And I don't quite see how implementation would be simpler because we'll be matching shift of a reduction as opposed to reduction of a shift. All the rest is the same. The only benefit that I see is that we would support "shift of a reduction" cases in addition to what I propose in this patch. However, `reduce.add` should still check for "reduction of a shift", which will make implementation more cumbersome.

Maybe that can be a follow up work?



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