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

Reply via email to