On Wed, Jul 29, 2026 at 6:38 PM Jeffrey Law
<[email protected]> wrote:
> > I also included some whitespace changes in some comments. Please let me know
> > if they should be a separate change.
> In general formatting fixes should be distinct changes unless they're
> directly in the space you're working. These cases touch independent
> patterns so an independent patch would be better. This policy is mostly
> to make it easier to review by avoiding unnecessary diffs. It's also
> the case that many formatting changes can go in without review under our
> trivial/obvious guidelines. But I don't think it's worth splitting
> these out this time. This is mostly a note for future contributions.
Understood, I will keep that in mind. Thanks
> It would initially seem this is redundant with this pattern earlier in
> match.pd:
>
> |/* (X | Y) == Y becomes (X & ~Y) == 0. */ (simplify (cmp:c (bit_ior:c
> @0 @1) @1) (cmp (bit_and @0 (bit_not! @1)) { build_zero_cst (TREE_TYPE
> (@0)); }))|
>
>
> So the main question/concern I have is why didn't the existing earlier
> rule in match.pd fire? Presumably the "!" modifier on the bit_not is
> rejecting the rewritten pattern?
>
> Overall it looks good, I just want to make sure we're not utilizing the
> more general pattern for a good reason.
>
> jeff
The existing rule does not fire for this case. Consider these examples:
_Bool f1(unsigned len) {
unsigned newlen = len | 4;
return newlen == len;
}
_Bool f2(unsigned len) {
return (len | 5) == 5;
}
_Bool f3(unsigned x, unsigned y){
return (x | y) == y;
}
_Bool f4(unsigned x, unsigned y){
return (x | ~y) == ~y;
}
The capture bind @1 to whatever appears on the both side of the
comparision. The replacemnet in the existing rule needs bit_not! @1,
so a match is rejected unless ~@1 simplifies. For constant (5 as in
f2) or already negated value (~y as in f4) the rule fires. But fails
when @1 is a plain variable.
Removing ! would produce (4 & ~len) == 0 in f1, this is 3 ops. The new
pattern produces (len & 4) == 0, which avoids NOT entirely.
I would also note that the comment in the existing rule may be
slightly misleading, since readers will expect every form of (X | Y)
== Y to become (X & ~Y) == 0, which is not the case. I can put the
clarification as a follow-up.
