From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11052 invoked by alias); 5 Jan 2003 05:43:45 -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 11033 invoked from network); 5 Jan 2003 05:43:45 -0000 Received: from unknown (HELO conure.mail.pas.earthlink.net) (207.217.120.54) by 209.249.29.67 with SMTP; 5 Jan 2003 05:43:45 -0000 Received: from ilmasc01-56.midwest.net ([209.248.16.66] helo=there) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18V3ZI-0007Gq-00; Sat, 04 Jan 2003 21:43:29 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Andy Walker To: Denis Chertykov Subject: Re: Synthetic register related: consequences of changing Frame layout. Date: Sun, 05 Jan 2003 05:44:00 -0000 Cc: gcc@gcc.gnu.org References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: X-SW-Source: 2003-01/txt/msg00187.txt.bz2 On Saturday 04 January 2003 11:52 am, Denis Chertykov wrote: > Andy Walker writes: > > I am thinking about changing the frame layout for i386, but only when > > Synthetic registers are used. > > > > > > What else am I likely to break in the process? > > So, You want to use part of stack frame for Synthetic Registers (SR). > > ** > I can't found differences between the spilled register (pseudo register > without hard register) and the Synthetic Register. > ** In principle, you are correct. The differences are small. I believe that in many instances, instructions accessing stack slots as spilled registers are six bytes long, not three bytes long as for Synthetic registers. I believe that the compiler does not differentiate between spilled register stack slot memory and any other kind of memory, and so generates unnecessary register content motion between registers and stack slots, under the mistaken idea that this is more efficient. I could be completely mistaken. I will not be sure until I have tried it. Andy > > The current allocator trying to find a hard register for any pseudo > register and if this impossible then allocator spill the pseudo to the > stack frame and trying to use the stack slot as register. > > The new allocator differs from the current only in allocation methods > not in principles. IE both allocators trying to map infinite number of > pseudo registers to limited set of hard regs, both tring to spill > registers to stack frame and both trying to rematerialize values. > > Denis.