From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-89220-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 14201 invoked by alias); 18 Jan 2004 18:05:19 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 14189 invoked from network); 18 Jan 2004 18:05:17 -0000
Received: from unknown (HELO www.eyesopen.COM) (12.96.199.11)
  by sources.redhat.com with SMTP; 18 Jan 2004 18:05:17 -0000
Received: from localhost (roger@localhost)
	by www.eyesopen.COM (8.11.6/8.11.6) with ESMTP id i0IHIxB28352;
	Sun, 18 Jan 2004 10:18:59 -0700
Date: Sun, 18 Jan 2004 18:05:00 -0000
From: Roger Sayle <roger@eyesopen.com>
To: gcc@gcc.gnu.org, <gcc-patches@gcc.gnu.org>
cc: Joern Rennecke <joern.rennecke@superh.com>,
   Richard Henderson <rth@redhat.com>
Subject: Floating point registers vs. LOAD_EXTEND_OP on alpha
Message-ID: <Pine.LNX.4.44.0401181003080.27690-100000@www.eyesopen.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-SW-Source: 2004-01/txt/msg01175.txt.bz2


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
--