This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reload patch to improve 386 code
- To: crux at pool dot informatik dot rwth-aachen dot de (Bernd Schmidt)
- Subject: Re: Reload patch to improve 386 code
- From: Joern Rennecke <amylaar at cygnus dot co dot uk>
- Date: Sat, 5 Sep 1998 01:07:14 +0100 (BST)
- Cc: law at cygnus dot com, meissner at cygnus dot com, toon at moene dot indiv dot nluug dot nl, egcs at cygnus dot com
> 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.