Floating point registers vs. LOAD_EXTEND_OP on alpha

[Roger Sayle <roger@eyesopen.com>]

I believe I've managed to diagnose the cause of the current mainline
bootstrap failure on alphaev67-dec-osf5.1 and presumably all alpha
targets.

The failure was triggered by Joern's recent patch to postreload.c:

> 2004-01-16  J"orn Rennecke <joern.rennecke@superh.com>
>
>       PR 11864
>       * postreload.c (reload_cse_simplify_operands): Don't remove
>       implicit extension from LOAD_EXTEND_OP.

which causes a miscompilation of the garbage collection preprocessors,
such that gt-emit-rtl.h generated during stage2 contains garbage, such
that building emit-rtl.o in stage2 fails, terminating the bootstrap.

Running the regression tests from a non-bootstrapped compiler, and
comparing the results to a compiler with the appove patch reverted,
shows five new regressions, all gcc.c-torture/execute/memcpy-bi.c at
different optimization levels.

Comparing the assembly output of compiling memcpy-bi.c at -O3 shows
the following differences:

594a595
>       cvtlq $f2,$f2
716a718
>       cvtlq $f3,$f3
846a849
>       cvtlq $f4,$f4


The patch has eliminated the sign extensions of an integer value held
in the alpha's floating point registers.  Clearly there's some poor
interaction between LOAD_EXTEND_OP and loading integer values into FP
registers.

I'm guesing that in the sequence:

        lds $f2,40($10)
	cvtlq $f2,$f2
	sts $f2,40($9)

the "cvtlq" is actually doing something useful, such that the alpha
backend's definition of LOAD_EXTEND_OP depends upon register allocation?


Hopefully, this analysis is enough for an alpha maintainer to determine
whether Joern needs an additional check in his post-reload patch or if
the alpha backend's LOAD_EXTEND_OP should claim to be extending in these
modes.

Roger
--