This is the mail archive of the
mailing list for the GCC project.
Floating point registers vs. LOAD_EXTEND_OP on alpha
- From: Roger Sayle <roger at eyesopen dot com>
- To: gcc at gcc dot gnu dot org, <gcc-patches at gcc dot gnu dot org>
- Cc: Joern Rennecke <joern dot rennecke at superh dot com>, Richard Henderson <rth at redhat dot com>
- Date: Sun, 18 Jan 2004 10:18:59 -0700 (MST)
- Subject: Floating point registers vs. LOAD_EXTEND_OP on alpha
I believe I've managed to diagnose the cause of the current mainline
bootstrap failure on alphaev67-dec-osf5.1 and presumably all alpha
The failure was triggered by Joern's recent patch to postreload.c:
> 2004-01-16 J"orn Rennecke <email@example.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:
> cvtlq $f2,$f2
> cvtlq $f3,$f3
> 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
I'm guesing that in the sequence:
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