[PATCH] match: (X >> C) NE/EQ 0 -> X LT/GE 0

[Jeffrey Law]

On 1/13/2026 11:39 AM, Pengxuan Zheng wrote:
>
>
>     >
>     > +/* Fold (X >> C) != 0 into X < 0 if C is one less than the width
>     > +   of X.  Similarly fold (X >> C) == 0 into X >= 0.  */
>     > +(for neeq (ne eq)
>     > +     ltge (lt ge)
>     > + (simplify
>     > +  (neeq
>     > +   (rshift@2 @0 INTEGER_CST@1)
>     > +   integer_zerop)
>     > +  (with { tree itype = signed_type_for (TREE_TYPE (@0)); }
>     > +   /* Make sure to transform vector compares only to supported
>     > +      ones or from unsupported ones and check that only after
>     > +      IPA so offloaded code is handled correctly in this
>     regard.  */
>     > +   (if (wi::to_wide (@1) == element_precision (itype) - 1
>     > +     && (!VECTOR_TYPE_P (itype)
>     > +         || (cfun
>     > +             && cfun->after_inlining
>     > +             && VECTOR_BOOLEAN_TYPE_P (type)
>     > +             && (expand_vec_cmp_expr_p (itype, type, ltge)
>     > +                 || !expand_vec_cmp_expr_p (TREE_TYPE (@2),
>     > +                                            type, neeq)))))
>     > +    (ltge (convert:itype @0) { build_zero_cst (itype); })))))
>     > +
>     So in the PR Richi said the condition ought to be
>     canonicalize_math_after_vectorization_p; this seems to check
>     something
>     meaningfully different (after_inlining).  Can you explain why you
>     ended
>     up using the after_inlining test rather than the
>     after_vectorization test?
>
>
> Yes, Jeff, Richard initially suggested to use 
> canonicalize_math_after_vectorization_p,
> but in his latest patch he changed the checks to after_inlining instead
> (https://gcc.gnu.org/cgit/gcc/commit/?id=ae0cdb01b08fb4929ef17c534f86cd9fae78e799).
> Therefore, I updated the checks here to align with Richard's latest 
> implementation.
Ah, perfect.   In that case this is OK for the trunk, go ahead and push it.

Thanks!
jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20260113/0dd18bc2/attachment-0001.htm>