From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9208 invoked by alias); 15 Jul 2004 05:22:00 -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 8958 invoked from network); 15 Jul 2004 05:21:58 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 15 Jul 2004 05:21:58 -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 i6F5Lse1031917; Thu, 15 Jul 2004 01:21:54 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6F5Ls021888; Thu, 15 Jul 2004 01:21:54 -0400 Received: from livre.redhat.lsd.ic.unicamp.br (vpn64-10.boston.redhat.com [172.16.66.10]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i6F5LrZD019811; Thu, 15 Jul 2004 01:21:54 -0400 Received: from livre.redhat.lsd.ic.unicamp.br (livre.redhat.lsd.ic.unicamp.br [127.0.0.1]) by livre.redhat.lsd.ic.unicamp.br (8.13.0/8.13.0) with ESMTP id i6F5LmFl024745; Thu, 15 Jul 2004 02:21:48 -0300 Received: (from aoliva@localhost) by livre.redhat.lsd.ic.unicamp.br (8.13.0/8.13.0/Submit) id i6F5Ll7n024742; Thu, 15 Jul 2004 02:21:47 -0300 To: Richard Sandiford 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: Alexandre Oliva Organization: Red Hat Global Engineering Services Compiler Team Date: Thu, 15 Jul 2004 16:25:00 -0000 In-Reply-To: <874qoawesn.fsf@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-07/txt/msg01526.txt.bz2 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. 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? > 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. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}