Re: register allocation vs. scheduling and other stuff

[Brad Lucier <lucier at math dot purdue dot edu>]

> >Since we will have a new register allocator for 3.4 that is based on
> >graph coloring, perhaps one could add a new flag
> >
> >--fuse-all-registers
> >
> >that would not try to use the *minimum* number of colors to color an
> >interference graph, but, if the minimum number is less than the actual
> >number of available registers, it could use the actual numbers of
> >registers to color the graph, perhaps guided by liveness information.
> 
> This is a kludgy solution IMHO.

OK, the special flag might be a kludge.

And it's a known problem after all.

The point I was trying to make that got lost in all the verbiage is
that one might want to try to teach the register allocator a bit
about scheduling rather than trying to teach the scheduler a bit about
register allocation.

For example, one *must* assign different colors to pseudo-registers if their
lifetimes overlap.  However, if one has more than enough registers for
a particular routine, one may want to assign different colors to
pseudo-registers even if their lifetimes are "close", in order to allow
the post-register-allocation scheduler a bit more flexibility.

But Dan Berlin claims that the new register allocator already uses all
the registers available to it, and a quick test on alphaev6 shows this
to indeed be the case (but I'm a bit surprised I can't get the scheduler
to hoist more of the loads to the top of the basic block---perhaps I
have to rebuild my powerpc-darwin compiler to see what happens there again).

Brad