Re: Patch to simplify reload register allocation

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    We have two conflicting goals when ordering reloads for allocation.
    Either we put groups ahead to avoid breaking up all possible groups
    while allocating smaller reloads, or we sort strictly by increasing
    register class to avoid selecting all registers in a small class for a
    group reload in a larger class.  

The first is certainly right, but I'm not sure I'd agree that the goal
of sorting by increasing register class is as you describe.

    I think (although I could be wrong, this stuff isn't documented well)
    that the counted_for_{group,nongroup} sets are used to ensure that
    despite the difference in the order in which reload regs are
    allocated, the second pass will still find a valid allocation.  

I think that's correct too.

    It's possible that the current setup avoids the problem I described,
    but if it does it's probably by accident, not by design.  

No, I think it's by design, but that's not a particularly important
distinction at this point.

  walk reloads in computed order
  if we find a single-reg reload in a small class that is already used up
  completely by a multi-reg reload in a larger class, mark the registers
  from the smaller class as undesirable for the earlier group reload, and
  retry from start

What is "computed order"?  I'm not sure I understand exactly what you 
propose.  I think the highest priority is to avoid taking the only
available registers for a group in non-group reloads.