[comp.compilers] A question about subsumption in register allocators

johnsson@cs.chalmers.se (Thomas Johnsson) (04/08/91)

A have a question about the use of register subsumtion in practical
graph coloring register allocators.

Before the actual coloring, subsumption is normally done, to remove
unnecessary copy operations, and to make the graph to be coloured
smaller.

No the question is: What do register allocators out there do if there
is more than one way of doing the subsumption, and they are mutually
incompatible?

	{ define a }
	if ... then
		x := a
		 ...
	else
		y := a
		 ...
	fi
	{ use x, y }

Assuming there is no conflict between x and a, or y and a, but there
is a conflict between x and y, then we have a choice in merging either x
and a, or y and a.
So how do register allocators out there make the choice?

-- Thomas Johnsson
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.

preston@ariel.rice.edu (Preston Briggs) (04/13/91)

Thomas Johnsson <johnsson@cs.chalmers.se> writes:
>Before the actual coloring, subsumption is normally done, to remove
>unnecessary copy operations, and to make the graph to be coloured
>smaller.
>
>Now the question is: What do register allocators out there do if there
>is more than one way of doing the subsumption, and they are mutually
>incompatible?

One of two things:

	Start at the top of the routine and head toward the bottom,
	coalescing as you go.

or

	Find the loop structure (need for spill costs anyway)
	and examine the most deeply nested loops first.

There's very little cost difference between the two.
I don't know about the payoff.

Preston Briggs
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.