From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9980 invoked by alias); 16 Apr 2002 22:23:53 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 9973 invoked from network); 16 Apr 2002 22:23:51 -0000 Received: from unknown (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sources.redhat.com with SMTP; 16 Apr 2002 22:23:51 -0000 Received: from hiauly1.hia.nrc.ca (localhost [127.0.0.1]) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id g3GMNmFN012417; Tue, 16 Apr 2002 18:23:48 -0400 (EDT) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) id g3GMNlk9012415; Tue, 16 Apr 2002 18:23:47 -0400 (EDT) Message-Id: <200204162223.g3GMNlk9012415@hiauly1.hia.nrc.ca> Subject: Re: gcc-64 on HP-UX 11.00 To: law@redhat.com Date: Tue, 16 Apr 2002 15:25:00 -0000 From: "John David Anglin" Cc: h.m.brand@hccnet.nl, gcc@gcc.gnu.org In-Reply-To: <20377.1018988309@porcupine.cygnus.com> from "law@redhat.com" at Apr 16, 2002 02:18:29 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00747.txt.bz2 > I don't doubt that it worked in the past. My point is that selecting an My point in looking at whether it worked in the past was simply to determine whether this was in fact a regression, and whether a fix could be applied to the 3.1 branch. > FP register to hold an address like this is an exceedingly bad thing to > do. In fact, not assigning the value to a register and instead leaving it > in memory is actually cheaper than assigning it to an FP register. I don't quite follow that logic. Two insns are needed to load the address and the result must end up in a register. You can't load the address directly to memory. It takes a couple of insns to copy the result from the FP register to a general register. Generally, I guess this must be weighed against the cost of freeing up a general general. > In fact, from the fragments, it looks like we did something insanely stupid, > why don't we assign the value to %r28 or %r25? I agree it seems very dumb. We have the following rtl at the end of function after lreg: (insn 3088 3494 3091 (set (reg/i:DI 28 %r28) (reg/f:DI 66)) 119 {*pa.md:3106} (nil) (expr_list:REG_DEAD (reg/f:DI 66) (nil))) DI 66 is set in multiple places. It seems the compiler doesn't recognize opportunities to replace DI 66 with DI 28, and so on. Jeff, I will send you gv.i offline so that you can look at the problem in more detail. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)