Re: [PATCH 1/2] match.pd: recognise A > B ? A - B : B - A as abs (A - B) [PR50856]

On Wed, 19 Aug 2026 at 09:10, Richard Biener <[email protected]> wrote:

> On Tue, 18 Aug 2026, Andrea Pinski wrote:
>
> > On Tue, Aug 18, 2026 at 12:55 PM Dominic P <[email protected]> wrote:
> > >
> > > The absolute-difference idiom is already folded to abs (A - B) when the
> > > comparison is written against the subtraction itself, e.g.
> > > (A - B) > 0 ? (A - B) : (B - A).  The very common alternative spelling
> that
> > > compares the operands directly, A > B ? A - B : B - A, was not
> recognised, so
> > > phiopt kept two independent subtractions which the backend
> if-converted into a
> > > compare plus two predicated subtracts (three instructions on Arm)
> instead of
> > > the two-instruction "subs; rsb<cc>" abs sequence.
> > >
> > > For a signed, non-wrapping integer type A > B is equivalent to A - B >
> 0, so the
> > > idiom (and its >=, < and <= variants) folds to [-]abs (A - B).  Add
> the two
> > > simplifications next to the existing (A - B) cmp 0 family, guarded on
> > > !TYPE_OVERFLOW_WRAPS so that -fwrapv does not trigger the fold.
> > >
> > > As a two-patch series with the following widened-operand extension,
> > > bootstrapped on x86_64-pc-linux-gnu with the stage2/stage3 comparison
> > > successful, and regtested there with gcc.dg/dg.exp and
> > > gcc.dg/tree-ssa/tree-ssa.exp: no unexpected results.
> >
> > Couple of things. First Eikansh posted a patch less than a month ago
> > for this which was under review too:
> >
> https://inbox.sourceware.org/gcc-patches/[email protected]/T/#m31fbbf878192412099d1c0c9ae066bccc519fb44
> >
> > >
> > > Assisted-by: Claude Opus 5 (Anthropic)
> >
> > Second I think GCC really should have a policy of rejecting patches
> > using LLMs for easy issues. LLVM already has a similar policy. So this
> > should not be so controversial. The main reason is these easy issues
> > are here for learning GCC code base.
>
> True, though I somewhat lean towards progress is better than having
> (easy) bugs.  Even with using LLMs this can be a learning process - it
> really depends what "Assisted-by: Claude Opus 5" actually means
> and I'd welcome some more elaboration on such annotations from
> contributors.
>
> This is a difficult subject and I'm very new here. I've been using gcc for
a number of years now and have been doing arm assembly since last century.
I've regularly been looking at the output of the compiler and wanting more.
I have spent many weeks being paid to optimise code for embedded systems,
every byte here counts so any savings are worth it.   With the advent of
Claude I found a few months ago I could actually make real progress
on improving gcc which is clearly better long term solution than hand
optimising functions. I have a number of patches to improve the code for
arm1176 and of course others. Most of the work was optimisations I would
have done by hand if I was doing assembly, nothing rocket science ,  No big
loop transforms etc. I would chat to Claude about the optimization and
how to generalise the optimisation. Claude would sometimes push back until
we had a solid solution.  In total the arm1176 Linux kernel is now 1/2Mbyte
smaller, this is important as the CPU has a very small instruction cache
and then you get a speedup for free. One of my bare metal projects which
wasn't used to find possible optimisations is now 10.5% faster another is
about 10% smaller, millage of course varies.

I thought I'd try and start to upstream some of the smaller patches and do
a few bug fixes to get an idea of the process and hopefully not take up too
much maintainer time while I learn what is required.

One patch is 133 lines but it isn't really new work. AArch64 has this
transform and the 32bit version was derived form it. I would like somehow
to get it up streamed as it is very effective at reducing code size.

It is nice to have easy bugs for new people to do but I think the bug list
is growing and some of them have been around for around for a long time.
Some bugs I think can just be closed as as they are already fixed and have
test cases : PR97872, PR97906, PR98435, PR96939, PR97323,PR91614.

I think Claude and I could produce some useful work together for other ARM
cores if there is an appetite for it.

Dominic