Reload patch v5

[Jeffrey A Law]

  In message <Pine.GSO.4.02A.9809141436460.453-100000@matula.informatik.rwth-aa
chen.de>you write:
  > News in v5:
  >   - Changed the caller-save code to insert the caller-save insns before the
  >     needs are calculated.  This allows them to have reloads again.  After
  >     every iteration except the last one, the old caller-save insns are
  >     deleted and then replaced with fresh ones in the next iteration.
I'm still trying to wrap my head around why you have to delete them each time
and what other side effects this may have.

For example, since space in the stack is allocated via assign_stack_local, aren't
we going to bloat stack usage if we have lots of caller saves?  We may even
get more reloads since some targets have limited displacement capabilities in
reg+d addresses.

One thought would be to never allow new caller saves to be created after the
first pass through.  I think this would involve removing the call clobbered
regs from consideration when we try to reallocate a spilled pseudo which crosses
calls.

So on the first pass we find all the locations where we need to insert save and
restore insns and insert them using the pseudo reg, then let reload operate
normally.

Is there some reason that won't work?

Note that Joern added a couple new reload optimizers recently that'll need
converting to using the new chains and the life info in them instead of
used_spill_regs.  Interesting enough, using the new chains and their life info
may actually make Joern's optimizers more effective :-)

Given the size of the patch, the benchmarking needs, and the knowledge that
Joern also has a mega patch to improve inheritance he's working on, I'm starting
to think we should probably try to phase this in with multiple steps.

Any chance I could get you to extract out the scratch stuff and submit it
separately?  Then once that's approved to do the same for the basic code to
build & use the new chain structure?  Then as the last stage the changes which
actually implement localized spilling?

This way we can get some of the independent changes (SCRATCH) and
infrastructure changes in the compiler now so you're not constantly having
to maintain a huge patch.

It'll also make the benchmarking phase easier.

jeff