public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dberlin@dberlin.org>
To: Peter Bergner <peter@bergner.org>
Cc: Bernd Schmidt <bernds_cb1@t-online.de>,
	Steven Bosscher <stevenb@suse.de>,
	 gcc@gcc.gnu.org, Andreas Krebbel <krebbel1@de.ibm.com>,
	James E Wilson <wilson@specifixinc.com>,
	David Edelsohn <dje@watson.ibm.com>
Subject: Re: Problem with the special live analyzer in global alloc
Date: Wed, 24 Aug 2005 07:47:00 -0000	[thread overview]
Message-ID: <1124856461.7123.85.camel@linux.site> (raw)
In-Reply-To: <1124853038.4518.75.camel@localhost.localdomain>

On Tue, 2005-08-23 at 22:10 -0500, Peter Bergner wrote:
> On Tue, 2005-08-23 at 21:26 +0200, Bernd Schmidt wrote:
> > As Jim points out, we may have to do that for IA64 anyway, so we could 
> > consider doing it on all targets.  Dan is correct that this can 
> > introduce new code that won't be eliminated.  One question is how often 
> > this is going to occur in practice.
> 
> The IBM iSeries (aka AS/400) compiler actually inserts definitions
> on edges where a pseudo/register is undefined.  However, unlike the
> discussion here, our "pseudo" definitions never lead to generated
> code
I listed that as a possible option, the problem is that you have to know
that they are pseudo definitions, and teach other things this too.
This is the part i alluded to being probably uglier than partial
liveness analysis itself.
> .  Our pseudo definitions were added to simplify some analysis
> phases in the compiler (eg, liveness can be simplified down to LIVE
> rather than LIVE & AVAL).  Note that we needed to handle these pseudo
> definitions specially in some cases so they don't reduce optimization
> opportunities. 
Like this :)

Is LIVE & AVAIL really that much slower these days for most programs?

I imagine if you have 300k bb's or 1.5 million live pseudos to consider,
it probably makes a real difference, but that's not *too* common in our
supported languages (30k bb's/150k pseudos is probably the practical
upper limit of what we see, though i'm sure someone is going to say
they've seen larger :P)


> I know we used to have a white paper describing the internals of the
> iSeries compiler (titled "The AS/400 Optimizing Translator"), but all
> of the links I can find are stale.  However, I did come across their
> patent (5,761,514) describing the idea: "Register allocation method
> and apparatus for truncating runaway lifetimes of program variables
> in a computer system".  I have no idea whether this was one of the
> patents made available by IBM for use by the OSS community or not.

Just FYI, I've read this patent, and regardless of whether you think
this is something should have patented, etc, the claims are broad enough
to cover any way as long as you are doing liveness analysis and then
inserting something into the instruction stream to truncate the ranges
(real, fake, whatever) .

However, if this is what you guys want to do, please don't let that stop
you.  Let me know if you want to go this route, and we'll work on
getting IBM to release it.

--Dan

  reply	other threads:[~2005-08-24  4:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-16 13:52 Andreas Krebbel
2005-08-16 14:14 ` Daniel Berlin
2005-08-23 14:44   ` Andreas Krebbel
2005-08-23 14:57     ` Bernd Schmidt
2005-08-23 15:08       ` Daniel Berlin
2005-08-23 15:13         ` Bernd Schmidt
2005-08-23 15:40           ` Steven Bosscher
2005-08-23 19:32             ` Bernd Schmidt
2005-08-24  4:10               ` Peter Bergner
2005-08-24  7:47                 ` Daniel Berlin [this message]
2005-08-24 13:49                   ` Peter Bergner
2005-08-24 14:31                     ` Daniel Berlin
2005-08-23 15:44           ` Daniel Berlin
2005-08-23 18:15       ` James E Wilson
2005-09-23 13:55 ` Andreas Krebbel
2005-09-23 14:06   ` Daniel Berlin
2005-10-13 11:51     ` [RFC] Don't emit REG_DEAD for clobbers if reg stays live Andreas Krebbel
2005-10-14 11:41       ` [RFC] Flow: Handle CLOBBERs like SETs if the " Andreas Krebbel

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=1124856461.7123.85.camel@linux.site \
    --to=dberlin@dberlin.org \
    --cc=bernds_cb1@t-online.de \
    --cc=dje@watson.ibm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=krebbel1@de.ibm.com \
    --cc=peter@bergner.org \
    --cc=stevenb@suse.de \
    --cc=wilson@specifixinc.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).