public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Matz <matz@suse.de>
To: Peter Bergner <bergner@vnet.ibm.com>
Cc: Andrew MacLeod <amacleod@redhat.com>,
		gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: Register Allocation
Date: Wed, 23 Nov 2005 14:06:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.58.0511231459110.7673@wotan.suse.de> (raw)
In-Reply-To: <1132687596.7748.32.camel@otta.rchland.ibm.com>

Hi,

On Tue, 22 Nov 2005, Peter Bergner wrote:

> Spill Location Optimizer [page(s) 11]:
>     * The IBM iSeries backend has this optimization.  During spilling,
>       it inserts copies to/from spill pseudos (essentially like another
>       register class) which represent the stores/loads from the stack.
>       These spill pseudos can then be dead code eliminated, coalesced
>       and colored (using an interference graph) just like any other
>       normal pseudo.  Normal Chaitin coloring (using k = infinity) does
>       a good job of minimizing the amount of stack space used for
>       spilled pseudos.

This is btw. also done by the new-ra branch.  Instead of spilling to stack 
directly it spills to special new pseudo regs.  The obvious problem with 
that is a phase ordering problem, namely that if you only have pseudo 
stack locations (the pseudo regs in this case) you don't know the final 
insn sequence (e.g. if the final stack offset happens to be 
unrepresentable so that insns are necessary to actually construct the 
stack address for the load/store).  That's why new-ra leaves the stack 
slots as pseudos only for one round, and then assign real stack positions 
to them (and recolors the possibly new insns and affected pseudos).

> Spill Cost Engine [page(s) 26-29]:
>     * The register allocator should not be estimating the execution
>       frequency of a basic block as 10^nesting level.  That information
>       should be coming from the cfg which comes from profile data or
>       from a good static profile.  The problem with 10^loop nesting
>       level is that we can overestimate the spill costs for some
>       pseudos.  For example:
>     	while (...) {
>     	  <use of "a">
>     	  if (...)
>     	    <use of "b">
>     	  else
>     	    <use of "b"
>     	}
>       In the code above, "b"'s spill cost will be twice that of "a",
>       when they really should have the same spill cost.

Nearly.  "b" _is_ more costly to spill, code size wise.  All else being 
equal it's better to spill "a" in this case.  But the cost is of course 
not twice as large, as you say.  I.e. I agree with you that the metric 
should be based exclusively on the BB frequencies attached to the CFG, not 
any nesting level.  Also like in new-ra ;)


Ciao,
Michael.

  parent reply	other threads:[~2005-11-23 14:06 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-17 16:53 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 [this message]
2005-11-23 20:50     ` Peter Bergner
2005-11-23 17:08   ` Andrew MacLeod
  -- 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-24 20:51 Register Allocation Joern RENNECKE
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=Pine.LNX.4.58.0511231459110.7673@wotan.suse.de \
    --to=matz@suse.de \
    --cc=amacleod@redhat.com \
    --cc=bergner@vnet.ibm.com \
    --cc=gcc@gcc.gnu.org \
    /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).