Re: [PATCH] aarch64: Optimize complemented XOR masked to bit 0

Hello Richard,

I wanted to ping you and check what we decided for this patch.

If https://gcc.gnu.org/pipermail/gcc-patches/2026-August/727701.html
committed, there will a regression at -O1 for aarch64 which is handled
in this patch.

Sorry, in the commit summary I have mention the "currently", it is
wrong, that patch is based on that patch and is committed but being
reviewed by Richard Biener.

If want this patch, I will update it as per your first review.

Best regards,
Shivam

On Mon, Jul 27, 2026 at 10:05 PM Shivam Gupta <[email protected]> wrote:
>
> On Mon, Jul 27, 2026 at 7:56 PM Richard Earnshaw
> <[email protected]> wrote:
> >
> > On 27/07/2026 12:40, Jeffrey Law wrote:
> > >
> > >
> > > On 7/27/2026 3:46 AM, Richard Earnshaw wrote:
> > >>
> > >> Actually, I've just noticed that you said this was at -O1.  If I
> > >> compile with -O2 (which is what we generally recommend for general
> > >> use), we already generate the eon/and sequence, so I don't think we
> > >> need anything more in this case; the problem is just that your
> > >> optimization level is too low.
> > >>
> > >> The issue with having patterns that need later splitting is that it
> > >> can cause combinatorial explosion problems in the machine description
> > >> - we have to start adding yet more patterns to recognize multiple
> > >> combinations.
> > >>
> > >> The compilers heuristics are usually very good at handling this
> > >> complexity by splitting things as soon as possible.  So we try to
> > >> stick closely to the 1 insn, 1 instruction rule and only add 1->2+
> > >> when there is something very critical that can't be handled by other
> > >> optimizations.
> > > I think what got us started down this path was a code quality regression
> > > either with a proposed patch or with something that's gone into the
> > > trunk.  Just one more datapoint for the calculus on whether or not to
> > > chase this kind of issue down.
> > >
> > > Jeff
> >
> > If there's a code quality regression, then having A BZ ticket as a first
> > step is probably warranted.  Then we can know to check what might have
> > regressed (and if need be, what backports might be needed).  I didn't
> > see anything with my build, but I might have been using an older
> > compiler, or just a different set of default options when configuring
> > the compiler, all of which may affect outcomes.
> >
> > R.
>
> For the context, the idea of this patch comes from discussion of patch
> https://gcc.gnu.org/pipermail/gcc-patches/2026-May/718703.html([PATCH]
> match.pd: Simplify XORs of zero_one_valued comparisons) which is
> originally comes while working on
> https://gcc.gnu.org/pipermail/gcc-patches/2026-May/717976.html([PATCH
> v3] match.pd: Simplify (~A & 1) == (~B & 1) at -O1 [PR112533]).
>
> Here Jeff suggested the splitter for arm64 backend -
> https://gcc.gnu.org/pipermail/gcc-patches/2026-May/718788.html([PATCH]
> match.pd: Simplify XORs of zero_one_valued comparisons).
>
> Thanks,
> Shivam