Re: hard register reload patch

[Jeffrey A Law <law at cygnus dot com>]

First note, there's no need to send this directly to me *and* cc gcc-patches.
If it goes to gcc-patches, I'll get a copy.  I'd prefer to only get a single
copy :-)

Second note, I'd like Bernd to comment on this code -- he's actually got a
much better understanding of reload than I do (as you also do).


  In message <199911300108.BAA20462@phal.cygnus.co.uk>you write:
  > As discussed before, there are sometimes cases where a hard register is
  > mentioned in an insn, yet it needs to be available for reloads, e.g.
  > the explicit use is an input and we need the same register for an output
  > reload, or vice versa.
Under precisely what circumstances does this happen?  The only case I'm aware
of right now could be considered a bug in combine and or the dependency
analysis to set up LOG_LINKs.


  > This used to work -after a fashion - for SMALL_REGISTER_CLASSES machines
  > before the local spilling patch went in.  If no other hard register was
  > available, an explicitly mentioned one was acceptable for reload.
  > The downside was, of course, that the port had to 'know' what spills could
  > possibly happen, and avoid live hard registers when a spill of their class
  > could be needed.
I wouldn't classify this as working in any sense of the word.  It would
happen to generate the correct code sometimes.  It would generate incorrect
code sometimes.  You could not accurately predict if you could get correct
or incorrect, which made the situation a terrible mess.

  > Now, the local spilling code will not care about registers that are used in
  > some other insn far away, but if the register is mentioned in an insn, it
  > is not available at all for reloads - hence you can easily run out of
  > registers in small registers classes, e.g. FPUL_REGS on the SH - there
  > is only one fpul register.
Again, I'd like to see the series of events which causes this problem.  RTL
examples would be appreciated.


I'm not going to accept or reject the patch right now -- I want to get a
better understanding of why we need to solve this problem in reload.

Thus, my comments below apply if and only if we decide that solving this
problem in reload is the right thing to do.  ALso, I don't want to spend a lot
of time review the patch itself until we're really sure we want to solve this
problem in reload.  So I'm just going to comment on the general issues at hand.


  > As discussed before, I aim to recitify this problem by recording the
  > lifetime of the explicitly mentioned hard regsiters by using special
  > reloads.
That sounds reasonable.  Ultimately, we have to use the same basic concepts
of lifetimes for these explicit hard registers that we use for reloads since
we want to determine what conflicts we have between reloads and explicitly
used hard registers.

  > (I have called them 'hard reload' in the code below).
  > These reloads are emitted after the ordinary reloads, so the trick to keep
  > reload register pressure under control still works for RELOAD_FOR_X_ADDR /
  > RELOAD_FOR_X_ADDR_ADDR combination where there are other RELOAD_FOR_X_ADDRs
  > but none of the others use the RELOAD_FOR_X_ADDR_ADDR, and the all come
  > later> than the RELOAD_FOR_X_ADDR that uses the RELOAD_FOR_X_ADDR_ADDR.
Sorry, I don't follow.  Are you saying that we actually emit code to perform
these reloads?  Or are you saying that *logically* we emit them after all the
other reloads?

Either way, I don't see how to reconcile that with the statement that we use
them to track hard register lifetimes.  The order in which we emit reloads
has a huge impact on the life span of the reload.  So I don't see how you can
claim to be tracking lifetimes, but emit these special reloads last.

  > You can tell a hard reload from an ordinary one because it always has the
  > reg_rtx field set, and it is equal to the in or out field, or to both.
?!? Can't we tell by the reload type?  Or maybe it would be better to have a
flag which indicates that this is a hard reload.  I'd much prefer a simple
obvious test to a blah && foo && somethingelse which are complex and 
non-obvious
tests.

  > Hard reloads have a longer lifetime than ordinary ones; input hard reloads
  > occupy the register before the very first ordinary reloads
  > (RELOAD_FOR_OTHER_ADDRESS) do.  And output hard reloads occupy their
  > register after all ordinary output reloads and their secondary reloads
  > are done.
I sincerely hope you documented this in the code.  One of my biggest issues
with the reload pass is the precise lifetimes of reloads are not documented.
I'd hate to see us continue that terrible habit.


  > This patch is also expected to make reload a bit faster for large programs;
  > instead of using regsets live_before and live_after, which were used
  > in tandem all the time, I use live_throughout and dead_or_set.
  > In a typical instruction, only few registers die or are set, so the latter
  > regset should be pretty quick to process - when it has to be processed;
  > often just processing live_throughout does just fine.
This seems pretty reasonable.  It is probably worth breaking this out into a
separate patch since it appears to be an independent improvement.

jeff