Re: Reload patch to improve 386 code

[Jeffrey A Law <law at cygnus dot 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.


  > I just think it's horribly complicated and
  > could be done somewhat cleaner, and more reliable.
It certainly needs better documentation.  Joern has code to make it
find more opportunities, but they're still being cleaned up.  In the
process he has improved the docs a little.

  > 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.
They do similar things, but work in fundamentally different ways.  I
do not see the need to tie them together in one single general
optimization.

In fact, the better reload inheritance works, the better reload cse
will work.

  > 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 wou ld
  > immediately be much more powerful.
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.



jeff