Hi all,
Good news, I wrote the RTL optimization code snippet in
simplify-rtx.cc right before the simplify_associative_operation call:
```
if (INTEGRAL_MODE_P (mode))
{
if (GET_CODE (op0) == NEG && rtx_equal_p (XEXP (op0, 0), op1))
return simplify_gen_unary (ABS, mode, op1, mode);
else if (GET_CODE (op1) == NEG && rtx_equal_p (XEXP (op1, 0), op0))
return simplify_gen_unary (ABS, mode, op0, mode);
}
```
and compiled the GIMPLE code from the bugzilla page with:
```
../../objdir-contrib-arm/gcc/xgcc -B../../objdir-contrib-arm/gcc/ \
-fgimple -S -O2 -march=armv9.5-a \
RTL-smax-optimization.c -o RTL-smax-optimization.asm
```
using the original statement:
_3 = __MAX (t_2, a_1(D));
and also compiled with the __MAX operands reversed so I
can test the code for the second case and they both emitted:
```
.LFB0:
.cfi_startproc
abs w0, w0
ret
.cfi_endproc
```
This is the result we wanted, right? If so, is my next step to
apply for access to the cfarm and get assigned a machine
and a directory on it for me to work in, so I can do the usual
full bootstrap GCC build targeting aarch64, with and without
my changes, run the full testsuite with both and compare results
to ensure I didn't introduce any regressions, then send the patch?
On Tue, Sep 22, 2026 at 4:57 PM Alfie Richards <[email protected]> wrote:
>
> On 22/09/2026 14:49, Kevin Stefanov wrote:
> > Thanks Alfie, that was really helpful.
> >
> > I reran the make command and the error was trivial
> > to spot that time. I then ran "make -j$(nproc) all-gcc"
> > and the built GCC was finally able to compile my
> > GIMPLE code and emit the arm assembly code
> > show on the bugzilla page. I can get to adding the
> > RTL optimization now.
>
> Ah fab!
>
> >
> > For a full aarch64 bootstrap setup when I get to
> > the stage of running the testsuite, I'll still have to
> > get on a cfarm machine and test my patch on it?
>
> Yes (mostly). It's a lot easier for setting up a bootstrap build, but
> also parts of the testsuite require the ability to compile then run
> code. You can setup emulators for that, but all together its normally
> significantly easier to use a native environment if you can get one.
>
> You can use the cfarm (https://portal.cfarm.net/users/new/)
>
> Or you can use software like QEMU to emulate an entire aarch64 linux VM
> on your x68_64 machine which is normally surprisingly performant (in my
> opinion).
>
> Kind regards,
> Alfie
>
> >
> > On Tue, Sep 22, 2026 at 2:27 PM Alfie Richards <[email protected]>
> > wrote:
> >>
> >> On 22/09/2026 11:20, Kevin Stefanov wrote:
> >>> Hi Alfie, thank you for the suggestion.
> >>>
> >>> I added --disable-bootstrap to the configure command
> >>> but "make" ended with an error again:
> >>> make: *** [Makefile:1109: all] Error 2
> >>>
> >>> I scrolled up for a while but couldn't spot any actual error
> >>> message that says what went wrong.
> >>
> >> Ah yes, would definitely be helpful to find, from my experience there
> >> will be one somewhere, but often not trivial to find.
> >> If you try running the command again (without changing anything) it is
> >> often easier, as all the previous successful jobs will be skipped so the
> >> log will be shorter and often just contain the failure. Especially if
> >> you use -j 1.
> >>
> >> Regardless, for this situation, I would suggest using
> >> `make -j$(nproc) all-gcc`
> >>
> >> As this will avoid building runtime libraries and will likely be enough
> >> for what you need.
> >>
> >> It is likely you don't have a working aarch64 assembler, linker, and
> >> libc. To successfully compiler runtime libs (which is part of `make
> >> all`) you would need those. (But I think you likely don't need to do
> >> `make all`)
> >>
> >> Hope this helps,
> >> Alfie
> >>>
> >>> Yes, so far for my patches I've always done my testsuite results
> >>> comparison on a native x86_64 bootstrapped GCC build with:
> >>>
>
