public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mark Mitchell <mark@markmitchell.com>
To: law@cygnus.com
Cc: amylaar@cygnus.co.uk, crux@pool.informatik.rwth-aachen.de,
	meissner@cygnus.com, toon@moene.indiv.nluug.nl, egcs@cygnus.com
Subject: Re: Reload patch to improve 386 code
Date: Sun, 06 Sep 1998 01:09:00 -0000	[thread overview]
Message-ID: <199809060428.VAA02085@smtp.earthlink.net> (raw)
In-Reply-To: <23417.905033646@hurl.cygnus.com>

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

    Jeffrey>   In message < 199809052204.XAA14607@phal.cygnus.co.uk >you
    Jeffrey> write:
    >> > We actually have most of the stuff to implement this now.  We
    >> just need > to set the alias set for such MEMs so that they
    >> have a different set > than all the MEMs created before reload.
    >> 
    >> It's not quite that simple.  You also have to know that
    >> different stack slots don't alias each other.

    Jeffrey> By setting the alias set, we disambiguate all the spill
    Jeffrey> slots from all the other pointers in the code.

    Jeffrey> We then let the existing base address tracking code
    Jeffrey> disambiguate the stack slots from each other.

I don't see why the base address tracking code should have to do
anything.  My plan was just to use different alias sets for each spill
register (we have 2^32 of them, after all!).  If you like, you could
reuse these from function to function, so the maximum number of alias
sets used up this was would be the number of spills in any one
function.  My guess is that if that gets close to 4 billion, we have
worse problems.

I'd be happy (delighted, even) to implement this, but I'd like a test
case that someone things will benefit.  (I am in *no* way doubting the
existence of such a thing, but having one would allow me to verify my
work.) 

    Jeffrey> jeff

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

  reply	other threads:[~1998-09-06  1:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.SOL.3.90.970819095143.291G-100000@starsky.informatik.rwth-aachen.de>
1998-09-04  5:03 ` Jeffrey A Law
1998-09-04  5:05   ` Bernd Schmidt
1998-09-04 22:36     ` Joern Rennecke
1998-09-05  4:45     ` Jeffrey A Law
1998-09-05 15:49       ` Joern Rennecke
1998-09-05 15:44         ` Jeffrey A Law
1998-09-06  1:09           ` Mark Mitchell [this message]
1998-09-06  1:09             ` Jeffrey A Law
1998-09-07  9:48       ` Bernd Schmidt
1998-09-07 19:09         ` Jeffrey A Law
1998-09-07 19:09         ` Joern Rennecke
1998-09-07 18:26           ` Jeffrey A Law
1998-09-04 21:38   ` Joern Rennecke
1998-09-04 21:38     ` Jeffrey A Law
1997-08-21 16:51 Problems on PowerPC David Edelsohn
1997-08-21 17:37 ` Reload patch to improve 386 code Bernd Schmidt
  -- strict thread matches above, loose matches on Subject: below --
1997-08-21 16:51 Joern Rennecke
1997-08-21 15:20 egcs repository Joel Sherrill
1997-08-21 15:47 ` Reload patch to improve 386 code Bernd Schmidt
1997-08-19 19:00 Joern Rennecke
1997-08-19  8:50 Jakub Jelinek
1997-08-19  7:36 egcs: A new compiler project to merge the existing GCC forks (fwd) Robert Wilhelm
1997-08-19  8:08 ` Reload patch to improve 386 code Jeffrey A Law
1997-08-19  8:08 ` Bernd Schmidt
1997-08-19  8:08 ` Bernd Schmidt
1997-08-18 20:47 Mike Meissner
1997-08-18 20:46 Joern Rennecke
1997-08-18 18:55 David S. Miller
1997-08-18 19:09 ` Jeffrey A Law
1997-08-18 15:36 Toon Moene
1997-08-18 15:11 meissner
1997-08-18 14:53 Monday morning Philippe Laliberte
1997-08-18 14:54 ` Reload patch to improve 386 code Jeffrey A Law
1997-08-18 14:53 meissner
1997-08-18 14:53 Toon Moene
1997-08-18  8:13 Test result for 970814 on native sparc-sun-solaris2.5.1 Klaus Kaempf
1997-08-18  8:22 ` Reload patch to improve 386 code Bernd Schmidt
1997-08-18 10:11 ` Bernd Schmidt

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=199809060428.VAA02085@smtp.earthlink.net \
    --to=mark@markmitchell.com \
    --cc=amylaar@cygnus.co.uk \
    --cc=crux@pool.informatik.rwth-aachen.de \
    --cc=egcs@cygnus.com \
    --cc=law@cygnus.com \
    --cc=meissner@cygnus.com \
    --cc=toon@moene.indiv.nluug.nl \
    /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).