Patch to simplify reload register allocation

[Bernd Schmidt]

>   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"?

The one computed by reload_reg_class_lower.  This order is as follows:
1. All reloads for classes that contain only a single register (we have no
   choice for those).
2. Reloads sorted by decreasing number of required registers.  Among reloads
   that require the same amount of registers, sort by increasing register
   class.
(3. Optional reloads, sorted just like the mandatory ones)

> 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.

That is automatically guaranteed by the ordering above.  The only remaining
problem as far as I can see is the one I described in the first mail, where
you have group reloads for a large register class using up all registers in
a smaller class, which would later cause a failure to allocate a nongroup
reload in that smaller class.  I'm not sure it can happen with the existing
ports, but if it does, it should be possible to fix it by detecting the
situation where a smaller reload needs regs from a lower class than a bigger
reload, and marking all regs from the smaller class so that they get used
only if no other regs are available anymore, no matter how cheap it would be
to use them.

Bernd