On Sat, Aug 15, 2026 at 3:25 PM Odysseas Georgoudis <[email protected]> wrote: > > Thanks for pointing me to Eikansh's earlier patch and the SME issue. > > Would delaying the canonicalization until after inlining be an > acceptable way to handle it? This keeps the target builtins visible > while AArch64 IPA records their PSTATE.SM requirements, after which > they can be converted to IFN_AVG_FLOOR or IFN_AVG_CEIL > > The attached v2 retains both the signed and unsigned canonicalizations > and implements that approach. I also added a focused SME regression > test for the unsigned rounding-add path. > > Tested with an aarch64-linux-gnu cross compiler. The targeted PR > tests, the new SME test, and the existing arm_neon_1.c, > arm_neon_2.c, and arm_neon_3.c tests pass.
I am ok with the addition of the after inlining check. Let's see if the other aarch64 maintainers are ok with adding the after inlining check too. Thanks, Andrea > > Thanks > Odysseas > > ________________________________ > From: Andrea Pinski <[email protected]> > Sent: 15 August 2026 02:52 > To: Odysseas Georgoudis <[email protected]> > Cc: [email protected] <[email protected]> > Subject: Re: [PATCH] aarch64: Canonicalize halving-add builtins [PR122715] > > On Fri, Aug 14, 2026 at 5:33 PM Odysseas Georgoudis <[email protected]> > wrote: > > > > The first two patches for PR122715 have been committed. This patch > > handles the remaining AArch64 case. > > > > Advanced SIMD halving-add intrinsics remain target builtins in GIMPLE, > > preventing generic average simplifications from seeing them. Canonicalize > > SHADD and UHADD to IFN_AVG_FLOOR, and SRHADD and URHADD to > > IFN_AVG_CEIL. > > > > This allows equal operands to be folded by the existing match.pd rule > > while retaining optab-based instruction selection for other operands. > > > > Tested with an aarch64-linux-gnu cross compiler. The targeted tests > > pass. > > This does not fully work. > In fact is is the same as Eikansh's patch (except adding the signed ones): > https://inbox.sourceware.org/gcc-patches/[email protected]/ > > The reason why it does not work is mentioned here: > https://inbox.sourceware.org/gcc-patches/CALvbMcAPZu5dupGfA=3gts8avmzzpscymy8srrrqxtqhakh...@mail.gmail.com/ > Basically gcc.target/aarch64/sme/arm_neon_1.c is no longer rejected > when it should be. > > Eikansh was still looking into how to fix the issue mentioned but has > not yet come up with a patch. He has been busy working on other > things. > If you want to look into how to resolve that issue that would be nice. > > Note the compile farm has a few aarch64 machines which you can use to > do a bootstrap test. > See https://gcc.gnu.org/wiki/CompileFarm on how to sign up (this is > seperate from GCC but is used by many GCC developers and had been > associated with GCC development for a long time now). > > Thanks, > Andrea > > > > > > Thanks, > > Odysseas > >
