On Sun, Jan 4, 2026 at 1:54 PM Daniel Henrique Barboza
<[email protected]> wrote:
>
>
>
> On 1/4/26 4:56 PM, Andrew Pinski wrote:
> > On Sun, Jan 4, 2026 at 11:32 AM Jeffrey Law
> > <[email protected]> wrote:
> >>
> >>
> >>
> >> On 12/30/2025 2:34 PM, Daniel Barboza wrote:
> >>>           PR 102486
> >>>
> >>> gcc/ChangeLog:
> >>>
> >>>            * match.pd (`popcount (X & -X) -> (X & -X) != 0`): New pattern.
> >>>
> >>> gcc/testsuite/ChangeLog:
> >>>
> >>>        * gcc.dg/tree-ssa/pr102486.c: New test.
> >> So isn't it transformed into "X != 0" rather than "(X & -X) != 0)"?
> >> Which means the subject line and ChangeLog entry need minor updates.
> >> I'm not sure why Andrew suggested optimizing to (X & -X) != 0 since the
> >> X & -X is zero when X == 0 and nonzero when X != 0.
> >
> > I don't remember why I suggested optimizing it to `(X & -X) != 0`
> > instead of just `X != 0`. The bug report was filed 4 years ago and I
> > can't find my notes for what I was looking at that time or why 2 years
> > later mentioned `(X&-X) != 0` either. But yes it should be to `X !=
> > 0`.
>
> Do we still care about the extra checks we introduced in v2 w.r.t the result
> of the optional conversion? We have this:
>
> +  (POPCOUNT (convert?@1 (bit_and:c @0 (negate @0))))
> +    (with { tree type0 = TREE_TYPE (@0);
> +           tree type1 = TREE_TYPE (@1); }
> +      (if (INTEGRAL_TYPE_P (type0)
> +          && (TYPE_UNSIGNED (type0)
> +              || TYPE_PRECISION (type1) <= TYPE_PRECISION (type0)))
> +       /* Use an explicit bool conversion to avoid errors when the
> +          POPCOUNT result is assigned to a type (e.g. int) that
> +          will generate a "bogus comparison result type" error.  */
> +       (convert:type
> +         (ne:boolean_type_node @1 { build_zero_cst (type1); })))))
>
>
> I assume that these checks
>
> +          && (TYPE_UNSIGNED (type0)
> +              || TYPE_PRECISION (type1) <= TYPE_PRECISION (type0)))
>
> Are still relevant because the conversion can still add additional ones aside 
> from
> the signal bit if we happen to go from a signed type that is larger.

Yes it is needed still.
Also it is `((type1)a) != 0` is needed rather than a plain `a!=0` as
you need to handle the truncating case.

Thanks,
Andrew


>
>
> Thanks,
>
> Daniel
>
>
> >
> > Thanks,
> > Andrew
> >
> >>
> >> I think Andrew also noted some additional type fixes that were needed in
> >> the new gimple you're generating.   So we probably need a V3 for that.
> >>
> >> Jeff
>

Reply via email to