From: Joern Rennecke <amylaar@cygnus.co.uk>
To: crux@pool.informatik.rwth-aachen.de (Bernd Schmidt)
Cc: law@cygnus.com, meissner@cygnus.com, toon@moene.indiv.nluug.nl,
egcs@cygnus.com
Subject: Re: Reload patch to improve 386 code
Date: Fri, 04 Sep 1998 22:36:00 -0000 [thread overview]
Message-ID: <199809050007.BAA17954@phal.cygnus.co.uk> (raw)
In-Reply-To: <Pine.GSO.4.02A.9809041107001.19368-100000@matlock.informatik.rwth-aachen.de>
> Inheritance doesn't seem to cause problems with my patch; I've never touched
> it and did not run into bugs. I just think it's horribly complicated and
> could be done somewhat cleaner, and more reliable. Just a few days ago I ran
> across a piece of code for which reload generated twice as many instructions
> as necessary, just because the inheritance code didn't catch a particular
> case. The reload_cse_regs code and the inheritance code do some very similar
> things, and I think it would be better to have only one piece of code that
> handles everything in a general fashion.
I have patches to make the inheritance perform better and more consistently.
> The only major obstacle I see is that currently the MEMs made by reload for
> spill slots in the stack frame don't get handled very well by the alias code.
> If alias.c knew that these don't alias with other MEMs, reload_cse_regs would
> immediately be much more powerful.
reload_cse_regs can't do register re-assignments, and it doesn't see when
a sequence of instruction loads a register that it has clobbered first.
Actually, it doesn't even begin to understand multi-instruction sequences
that load a value. It is really a weaker concept than reload inheritance.
The only time when it performs better than a good reload inheritance is
when the lifetime of reloads becomes muddled (e.g. when stuff is merged to
RELOAD_OTHER, and there are other reloads for the same insn.
next prev parent reply other threads:[~1998-09-04 22:36 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 [this message]
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
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 Bernd Schmidt
1997-08-19 8:08 ` Bernd Schmidt
1997-08-19 8:08 ` Jeffrey A Law
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=199809050007.BAA17954@phal.cygnus.co.uk \
--to=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).