From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22771 invoked by alias); 15 Jul 2004 07:08:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 22757 invoked from network); 15 Jul 2004 07:08:04 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 15 Jul 2004 07:08:04 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6F782e1023441; Thu, 15 Jul 2004 03:08:02 -0400 Received: from localhost (mail@vpnuser2.surrey.redhat.com [172.16.9.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6F781008850; Thu, 15 Jul 2004 03:08:01 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1Bl0LY-0000bc-00; Thu, 15 Jul 2004 08:08:00 +0100 To: Alexandre Oliva Cc: Kazu Hirata , gcc-patches@gcc.gnu.org Subject: Re: add h8sx support to h8300 References: <20040621.102356.74724063.kazu@cs.umass.edu> <87fz83f456.fsf@redhat.com> <87zn6aevpa.fsf@redhat.com> <873c42e8rb.fsf@redhat.com> <87r7rh8hx8.fsf@redhat.com> <874qobvz2a.fsf@redhat.com> <874qoawesn.fsf@redhat.com> From: Richard Sandiford Date: Thu, 15 Jul 2004 17:14:00 -0000 In-Reply-To: (Alexandre Oliva's message of "15 Jul 2004 02:21:47 -0300") Message-ID: <87658pd9yn.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-07/txt/msg01532.txt.bz2 Alexandre Oliva writes: > On Jul 14, 2004, Richard Sandiford wrote: >> The idea is that, if nothing is using er6, there's no reason why it >> can't be allocated for a movmd. > > Right. The trick is to figure out whether something *is* using it. "*is*" (present tense) is exactly right. ;) And regs_ever_live[6] tells you just that. There's no need to look elsewhere. > HFP_REG and FP_REG both refer to er6, although the latter does so by > means of elimination. That's why I thought it might make sense to > test for both. Before HFP_REG and FP_REG were split, when we tested > for FP_REG, we covered both meanings. After the split, in order to > preserve behavior, we had to test both. That was my reasoning. Was > it wrong? Well, as far as I can tell, yes. At least as far as what this code is trying to do. The fact that FP_REG can be eliminated to HFP_REG is pretty much irrelevent here. If we haven't yet committed to an HFP_REG->FP_REG elimination, then er6 will still be available for general register allocation (regs_ever_live[6] == 0). And we want to force the register allocator to use er6 in that case, even if er6 would normally have seemed too expensive. If it later turns out that we _do_ need a hard frame pointer, then obviously the old uses of er6 will have to be reallocated. But that's just normal behaviour when FRAME_POINTER_REGNUM isn't a fixed register. It's not specific to the d/D games. And the same thing was true in the old code too. The fact that {HARD_,}FRAME_POINTER_REGNUM were 6 did not cause regs_ever_live[6] to be true until we knew for certain that the frame pointer couldn't be eliminated. >> The register allocators might normally shy away from that because >> er6 is a call-saved register. "Hey, I've got this call-clobbered >> register sitting free. Why not use that instead of er6?". Even '!' >> wasn't enough to convince them otherwise. > > There's also effects from the REG_ALLOC_ORDER. But getting the > allocator to prefer er6 over any other register would probably end up > getting far worse results if it turns out that we need a frame > pointer. Right. Richard