From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10568 invoked by alias); 29 Dec 2002 21:58:18 -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 10561 invoked from network); 29 Dec 2002 21:58:16 -0000 Received: from unknown (HELO goose.mail.pas.earthlink.net) (207.217.120.18) by 209.249.29.67 with SMTP; 29 Dec 2002 21:58:16 -0000 Received: from ilmasc01-55.midwest.net ([209.248.16.65] helo=there) by goose.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18SlRW-0005te-00; Sun, 29 Dec 2002 13:57:58 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Andy Walker To: Daniel Berlin Subject: Re: An unusual Performance approach using Synthetic registers Date: Sun, 29 Dec 2002 22:41:00 -0000 Cc: gcc@gcc.gnu.org References: <64F18281-1B66-11D7-A27D-000393575BCC@dberlin.org> In-Reply-To: <64F18281-1B66-11D7-A27D-000393575BCC@dberlin.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: X-SW-Source: 2002-12/txt/msg01555.txt.bz2 On Sunday 29 December 2002 01:47 pm, Daniel Berlin wrote: > > My approach may allow for an effectively infinite register set. > > Which we have (Chris is wrong, we don't perform optimizations on > physical registers, we perform it on an infinite register set), and the > register allocator simply thunks the infinite number down to the real > number we have on the architecture. umm. This is sort of the point of my whole approach. I didn't call them "virtual", because they are not a simulation of a register, using a lot of instructions to perform a simple operation. I didn't call them "pseudo" because they are not slow memory imitations of a register. Because of the x86 architecture, they may be used with many instructions similar to "real" registers. Because of the narrow way they are defined, they will perform with speed similar to "real" registers. I am adding to the "real" number we have on the architecure. These are Synthetic: artificial duplicates of the originals, with many of the same characteristics. I am specifically not including basing or indexing. > > For each > > subroutine, the compiler figures out how many registers are needed. > > Right > > now, in GCC, the next step after adding up the number of registers is > > to call > > Daniel Berlin's implementation of Color-Graphing. > > First, this is incorrect. > Right now use an ad-hoc register allocator that isn't all that good > unless you specifically use -fnew-ra. Ok. > Second, Michael Matz is responsible for more of the new allocator than > me (i'm just trying to give credit where it's due). Second: I stand corrected. Michael Matz' and Daniel Berlin's Color-Graphing implementation. Credit where it is due, indeed! Many thanks to Michael Matz and Daniel Berlin. Andy