public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joern RENNECKE <joern.rennecke@st.com>
To: Ian Lance Taylor <ian@airs.com>, Andrew MacLeod <amacleod@redhat.com>
Cc: gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: Register Allocation
Date: Thu, 24 Nov 2005 20:51:00 -0000	[thread overview]
Message-ID: <438627D3.1050209@st.com> (raw)

In http://gcc.gnu.org/ml/gcc/2005-11/msg01163.html, Ian Lance Taylor wrote:

> Either way, register elimination can cause addresses which were valid
> to become invalid, typically because valid offsets from the frame
> pointer become invalid offsets from the stack pointer.  So that needs
> to be cleaned up somewhere.

This is not just about some requiring some cleanup somewhere.  Register
elimination and stack slot allocation determine the exact addresses that
are used, which in turn determine what reload inheritance is possible for
address reloads that are for stack slots which are close together on the
stack.  Getting this right is essential to avoid performance degradation on
some platforms.  These targets typically use LEGITIMIZE_RELOAD_ADDRESS to
split out-of-range addresses into a normal form with a base address load
and a memory access using this base with a small offset.

On the other hand, the hard register spills appear to offer a new
opportunity: we have talked about shrink-wrapping code in the past, but
have never implemented this in gcc.
I think that register saves/restores can be considered
special cases of hard register spills.  In order to do this efficiently,
there would have to be some interface with the target to exploit insn
sequences that can save/restore multiple registers more efficiently in
bulk, .e.g load/store multiple, or auto-increment use on targets that
are otherwise ACCUMULATE_OUTGOING_ARGS.  On the other hand, these
techniques can also help when we need to spill multiple hard registers
around a tight loop.




             reply	other threads:[~2005-11-24 20:51 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-24 20:51 Joern RENNECKE [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-12-23  8:13 register allocation roy rosen
2010-12-23 16:48 ` Vladimir Makarov
2010-12-23 17:22   ` Jeff Law
2010-12-27 15:43   ` roy rosen
2011-01-03 15:41     ` Jeff Law
2011-01-05 14:44       ` roy rosen
2011-01-05 15:26         ` Jeff Law
2011-01-11 16:11         ` Vladimir Makarov
2011-01-11 15:53       ` Vladimir Makarov
2005-11-17 16:53 Register Allocation Andrew MacLeod
2005-11-18  2:55 ` Mark Mitchell
2005-11-18  3:27 ` Daniel Jacobowitz
2005-11-18  9:53 ` Giovanni Bajo
2005-11-18 15:28   ` Andrew MacLeod
2005-11-19 19:31 ` Ian Lance Taylor
2005-11-19 20:20   ` Denis Chertykov
2005-11-20  0:20   ` Giovanni Bajo
2005-11-23 17:07   ` Andrew MacLeod
2005-11-23 20:43     ` Ian Lance Taylor
2005-11-20  0:37 ` Steven Bosscher
2005-11-23 17:08   ` Andrew MacLeod
2005-11-22 19:26 ` Peter Bergner
2005-11-22 21:55   ` Steven Bosscher
     [not found]   ` <200511222256.13823.>
2005-11-22 22:58     ` Peter Bergner
2005-11-23 14:06   ` Michael Matz
2005-11-23 20:50     ` Peter Bergner
2005-11-23 17:08   ` Andrew MacLeod
2004-09-22  1:21 Adrian Strätling
2004-09-22  5:22 ` tm_gccmail
2004-10-04 14:13   ` Nick Ing-Simmons
2004-05-02 13:27 register allocation Qiong Cai
2004-05-02 16:56 ` Daniel Berlin
2004-05-03  7:07 ` Michael Matz
2004-03-26 22:21 Register Allocation John Lu
2004-03-26 22:21 ` Vladimir N. Makarov
2004-03-26 22:26   ` Andrew MacLeod
2004-03-27 18:22     ` Andi Kleen
2002-03-12  6:21 register Allocation Danish Samad
1997-10-14  5:51 Register allocation Thomas Koenig
1998-12-21 22:38 ` Jeffrey A Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=438627D3.1050209@st.com \
    --to=joern.rennecke@st.com \
    --cc=amacleod@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=ian@airs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).