From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-121994-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 8415 invoked by alias); 19 Nov 2005 20:20:38 -0000
Received: (qmail 8407 invoked by uid 22791); 19 Nov 2005 20:20:38 -0000
X-Spam-Check-By: sourceware.org
Received: from mail.overta.ru (HELO overta.ru) (217.65.208.5)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 19 Nov 2005 20:20:36 +0000
Received: from [217.65.213.82] (HELO localhost.localdomain)   by overta.ru (CommuniGate Pro SMTP 4.2.9)   with ESMTP id 30256585; Sat, 19 Nov 2005 23:20:33 +0300
To: Ian Lance Taylor <ian@airs.com>
Cc: Andrew MacLeod <amacleod@redhat.com>,  gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: Register Allocation
References: <1132246411.10098.153.camel@localhost.localdomain> 	<m3oe4h6tyr.fsf@gossamer.airs.com>
From: Denis Chertykov <denisc@overta.ru>
Date: Sat, 19 Nov 2005 20:20:00 -0000
In-Reply-To: <m3oe4h6tyr.fsf@gossamer.airs.com>
Message-ID: <d5kwe6gz.fsf@localhost.localdomain>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-IsSubscribed: yes
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2005-11/txt/msg00917.txt.bz2

Ian Lance Taylor <ian@airs.com> writes:

> The current reload pass includes general heuristics to handle
> reloading memory addresses.  This code knows things like "if stack
> pointer plus displacement is not a valid memory address, try loading
> the displacement into a register."  Many targets currently rely on
> those heuristics to generate valid code.  I haven't been able to quite
> pin down where this happens in your proposal.  For example, it's easy
> for an address to use the frame pointer and be valid before reload,
> and then for reload to eliminate the frame pointer (in fact, in your
> scheme, what does frame pointer elimination?) and produce an offset
> from the stack pointer which is invalid.  That is, spill code or frame
> pointer elimination can generate invalid address, and something needs
> to fix them up.  Where does that happen, and how?

The rable.pdf completely miss description of registers elimination.
It's important and difficult part of RA.
(The "old new-ra" also havn't eliminatin)

Denis.