Re: Patch to delete scratch allocation in local-alloc

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

  In message <199810021613.RAA20773@phal.cygnus.co.uk>you write:
  > In article <Pine.SOL.3.90.981002151523.14944J-100000.cygnus.egcs.patches@je
  > nnifer.informatik.rwth-aachen.de> you wrote:
  > ...
  > : The code in reload always works, and allocates exactly the scratch regist
  > ers
  > : which are necessary.  The code in local-alloc only guesses; it can't know
  > : which alternative is going to be selected by reload.  Worse, global can't
  > : override the choices of local-alloc when they turn out to be wrong, which
  > : may lead to suboptimal register allocation.
  > 
  > The same is true for the entire local register allocation.  So why do you
  > single out scratch allocation?
scratch allocations are only live for a single insn and can not conflict with
any allocations other than those in the single insn.  This makes them trivially
easy to allocate during global/reload.

In most other cases local allocation can do a better job than global allocation.

  > IMHO the real problem is global / reload can't revise a number of decisions
  > that local-alloc does - the most glaring one is, of course, the inability t
  > re-allocate locally allocated registers that get spilled.
This is no longer true.  We can re-allocate registers originally allocated by
local which get spilled.

jeff