public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bernd Schmidt <crux@pool.informatik.rwth-aachen.de>
To: Jeffrey A Law <law@cygnus.com>
Cc: meissner@cygnus.com, toon@moene.indiv.nluug.nl, egcs@cygnus.com
Subject: Re: Reload patch to improve 386 code
Date: Mon, 07 Sep 1998 09:48:00 -0000	[thread overview]
Message-ID: <Pine.GSO.4.02A.9809071547250.23612-100000@matlock.informatik.rwth-aachen.de> (raw)
In-Reply-To: <20388.904979342@hurl.cygnus.com>

>   In message < Pine.GSO.4.02A.9809041107001.19368-100000@matlock.informatik.rwth-aachen.de >you write:
>   > Inheritance doesn't seem to cause problems with my patch; I've never touched
>   > it and did not run into bugs.
> Well, when dealing with reload "it seems to work for me" isn't enough :-)
> 
> The primary issue is that when a reload is inherited its lifetime is
> extended, possibly beyond the original insn where it was used as a
> reload reg.
> 
> So, when we inherit reloads, we have to make sure to note that the
> reloadreg is marked as live for the longer range.
> 
> Then again inheritance happens just before we start emitting the
> reload insns themselves, so maybe it doesn't conflict with your code.

It really shouldn't. Inheritance only looks at the insns that reload is
already done with, and the one currently being processed.  For those
which reload has completed, the register life information calculated by
my patch is never referenced again, so the inheritance code can do
whatever it wants to them.

> 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.

We'd need to be a bit careful about this, since some of these MEMs might be
replaced (for example) in instruction splitting later on, and the special
"this MEM made by reload" alias set must be preserved during such operations.

Bernd


  parent reply	other threads:[~1998-09-07  9:48 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
1998-09-06  1:09             ` Jeffrey A Law
1998-09-07  9:48       ` Bernd Schmidt [this message]
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 Joern Rennecke
  -- strict thread matches above, loose matches on Subject: below --
1997-08-21 16:51 Problems on PowerPC David Edelsohn
1997-08-21 17:37 ` Reload patch to improve 386 code Bernd Schmidt
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 Toon Moene
1997-08-18 14:53 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  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=Pine.GSO.4.02A.9809071547250.23612-100000@matlock.informatik.rwth-aachen.de \
    --to=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).