Re: [PATCH] alpha: add -mlra and enable LRA by default on BWX targets

On 8/3/2026 10:24 AM, Matt Turner wrote:
> On Mon, Jul 20, 2026 at 12:26 PM Matt Turner <[email protected]> wrote:
>> Alpha is one of the last targets still forcing TARGET_LRA_P to false, and
>> reload is slated for removal (PR113932).  Add a transitional -mlra option,
>> following the hppa pattern (r16-5534), so that -mno-lra remains available as
>> an escape hatch until reload is deleted.
>>
>> LRA is enabled by default only on BWX targets.  On non-BWX targets a QImode or
>> HImode pseudo that has to be spilled reaches the target's reload_in<mode> /
>> reload_out<mode> secondary-reload path, which LRA does not yet drive correctly
>> (PR117185: LRA either loops generating reload insns or passes a pseudo where
>> get_unaligned_address expects a MEM).  BWX has real byte/word memory
>> instructions and does not need that path, so it is unaffected.  Gating the
>> default on TARGET_BWX enables LRA where it is known good and leaves non-BWX on
>> reload until PR117185 is resolved.  -mlra / -mno-lra override the default in
>> either direction.
>>
>> The default is resolved in alpha_option_override once TARGET_BWX is final, so
>> it tracks -mcpu (e.g. -mcpu=ev4 selects reload, -mcpu=ev56 selects LRA) rather
>> than only the configured default CPU.
>>
>> Tested with an alpha-linux-gnu cross (both ev4/non-BWX and --with-cpu=ev56/BWX,
>> --enable-checking=yes,rtl): libgcc, libgomp and libstdc++ build cleanly under
>> LRA, and gcc.c-torture/execute under qemu-alpha at -O0 and -O2 gives identical
>> results with -mlra and -mno-lra on both configurations (3380 results each, no
>> differences).  A native ev56 bootstrap with c,c++,m2 completes and, comparing a
>> full make check-gcc/check-g++ at the default (LRA) against --target_board
>> unix/-mno-lra (reload), LRA shows no correctness regressions: gcc unexpected
>> failures drop from 626 to 541 and g++ from 57 to 56, with the only LRA-only
>> differences being debug-info-quality (gcc.dg/guality) shifts in LRA's favor.
>> The prerequisite middle-end fix for the BWX m2 miscompile is PR117184.
>>
>> gcc/
>>          * config/alpha/alpha.opt (mlra): New option.
>>          * config/alpha/alpha.cc (alpha_option_override): Default alpha_lra_p
>>          to TARGET_BWX when not set explicitly.
>>          (alpha_use_lra_p): New function.
>>          (TARGET_LRA_P): Define to it instead of hook_bool_void_false.
>> ---
> Hi Vlad and Peter,
>
> I could really use your review on this patch as well as your feedback
> on the questions in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117185#c8
So at a high level, do we want to have LRA depend on subtarget 
capabilities.   I don't think we've ever done that, though I can 
understand the motivation here.  We don't have an active alpha 
maintainer, so I'm happy to go when general consensus here.

I haven't gotten a clean bootstrap & regression on alpha in about a 
month and my tester only runs in the default mode, so I don't think it's 
really going to exercise this meaningfully or give us any sense of LRA 
on alpha state going forward.  Given it's a dead architecture one 
possibility that we should at least consider is deprecating the non-BWX 
variants at which point we could convert to LRA and having 
bootstrap/regression testing in place.

For reference Matt, I have an alpha native root filesystem with enough 
components to bootstrap GCC.  My tester chroots into that RFS using user 
mode QEMU emulation.  So it looks native, but doesn't have as much 
overhead as full system emulation.  A bootstrap and regression test 
takes 16-19 hours on my builders.

Jeff