[Bug target/117185] Bootstrap fails with ICE: in operator[], at vec.h:910 with LRA on non-BWX alpha

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117185

Magnus Lindholm <linmag7 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |linmag7 at gmail dot com

--- Comment #9 from Magnus Lindholm <linmag7 at gmail dot com> ---
I have done some testing around this on a native Alpha system.

First, I tested Matt's current Alpha LRA patch stack against a vanilla
GCC build. This comparison does not include my local non-BWX patch, so
it should be read only as a test of Matt's prerequisite/LRA-enablement
patches.

For the gcc testsuite, the patched run looked slightly better at the
summary level:

patched: expected passes        165574
vanilla: expected passes        165457

patched: unexpected failures       151
vanilla: unexpected failures       160

patched: unsupported tests        4068
vanilla: unsupported tests        4132

For the g++ testsuite, the result was also neutral to slightly positive:

patched: expected passes        263257
vanilla: expected passes        263256

patched: unexpected failures        56
vanilla: unexpected failures        57

Most of the individual differences seem to be PASS-vs-UNSUPPORTED
changes, analyzer multiline diagnostic tests, or other diagnostic-output
matching differences. I do not currently see anything that looks like a
broad regression from Matt's patches.

Separately, I have been testing a prototype fix for the non-BWX QI/HI
secondary-reload problem discussed in this PR.

The issue seems to be that, on non-BWX Alpha targets, QI/HI memory
operations need to be implemented using wider load/store sequences and
temporary registers. With LRA, the Alpha secondary reload hook can be
asked to handle a QI/HI pseudo before that pseudo has been materialized
as a spill-slot MEM. The existing reload_in/reload_out expanders assume
they already have a real MEM, so LRA can end up recursively generating
reloads until it hits the reload-insn limit.

The approach I am testing is to represent these LRA pseudo reloads as
delayed internal reload patterns, marked with an UNSPEC so that LRA does
not treat them as ordinary movqi/movhi operations and recursively reload
them again. The delayed patterns are then split after reload, when the
normal Alpha helper code can emit the required non-BWX load/store
sequence.

I have not yet run the full gcc/g++ testsuite with this non-BWX patch
applied, but I have done native compile and runtime smoke testing with
the patch included. 

This is GCC 17.0.0 20260715, target alphaev67-unknown-linux-gnu, with
-mlra enabled by default.

With that compiler, Matt's original testcase:

struct A {};
void f (int i, ...);

int main()
{
f(1, A());
f(1, A());
}

now compiles successfully with -mlra for ev4, ev5, ev56 and ev6 at
-O0, -O1, -O2, -O3 and -Os.

I also built and ran a small QI/HI varargs runtime testcase natively on
Alpha.  It passed for ev4, ev5, ev56 and ev6 at -O0, -O1, -O2, -O3 and
-Os.  For EV4 I checked the generated assembly and verified that it does
not contain BWX byte/word memory instructions such as ldbu, stb, ldwu or
stw.

So the non-BWX patch still needs full testsuite coverage, but the
compile and native runtime smoke testing looks good so far.

The patch is available here:

https://github.com/linmag7/gcc/tree/alpha-lra-ordered-non-bwx