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
