Re: New register allocator branch created

[Daniel Berlin <dberlin at redhat dot com>]

> > Dan,
> >
> > I tried doing a SPEC run with the new branch but none of the SPEC
> > programs build (x86). I'm getting various spill failures and
> > unrecognizable insns.
> >
> > If you want I could provide the specific failures, or if you can
> > give me a couple of pointers into your implementation I can try
> > and hunt them down.
>
> It's unlikely I can fix them before i rip the spill code insertion from
> reload.
Scratch that, the debug output from the register allocator on x86 lead me
to notice i screwed up the calculation of whether we have enough registers
free in each direction for something that is >1 hard reg. Because of how
the code works, the upshot was if register 0 was free (which it frequently
is), and something >1 reg could be placed in it, we'd spill it instead.

Technical details of bug:
Since things that may need > 1 hard reg can block coloring more, they tend
to get allocated first (it really depends on a bunch of factors, i'm
simplifying). So we'd try to say we could put the first thing in register
-1 (preferred register + (numRegs-1)  * direction, prefReg=0,  numRegs=2,
direction = -1 (because it thought that was okay due to the bug)), which
tells the allocator to spill it, then   it'd move on to the  next thing on
the stack to color, which would  inveitably be another > 1 hard reg node,
spill it, etc.
Until you got to something taking up only one hard register.
Fun, no?

This is likely why reload ran out of spill registers on x86 (Since every
piece of code i tested seems to have tons of things needing >1 hard reg)

Still, all bugs so far have been either thinkos (lhs where i meant rhs),
or in the find_reg_given_constraints routine, so that's pretty good.

I still wouldn't quite use the allocator on x86, but it should work better
than it did 3 hours ago.

--Dan