[LLVMdev] Is it possible to use the SimpleRegisterCoalescing pass in an iterative way?

David Greene dag at cray.com
Mon Jan 12 14:00:32 PST 2009


On Friday 09 January 2009 03:36, Roman Levenstein wrote:
> Hi,
>
> I'm implementing some variations of graph-coloring register allocators for
> LLVM. Many of them perform their phases (e.g. coalescing, graph
> simplification, spilling,  color selection) in an iterative way. Since
> LLVM provides an implementation of the coalescing in the
> SimpleRegisterCoalescing class already, I would like to reuse it (even
> though I could of course create my own coalescing implementation). But
> this class is a MachineFunctionPass.
>
> I'm wondering, if it is possible to use this pass from another pass
> (i.e. regalloc) in an iterative way:
> I need to invoke it multiple times for the same MachineFunction at
> certain places in my regalloc pass implementation.
> May be some sort of analysis update can be performed? Or is it
> designed to be used just once per MachineFunction?

Hi Roman,

I did this a while back when implementing iterative register coalescing.  My 
guess is you're trying to do the same with the Generaslized Graph Coloring 
algorithm,.

It's not easy to accomplish within the LLVM framework.  I've made a number of 
structural changes to our code here and it's in a bit of a state of bitrot due 
to upstream changes we haven't merged in yet.

I got some of this work merged upstream in the RegisterCoalescer and 
RegallocQuery interfaces.  RegallocQuery is supposed to be an opaque 
communication conduit between register allocators and coalescers such that 
the allocator can update the coalescer when it makes changes and vice versa.

When I did the full implementation I found I had to make more changes to 
RegallocQuery.  I have not pushed those upstream for various reasons, 
including that at the time the register coalescing code was in a great state 
of flux and it was difficult to track.  It will be a bit of work to get it all 
up-to-date for merging.

Evan is right that coalesceFunction is the primary interface to invoke the 
coalescer.  The iterative coalescer I wrote implements that function.  The 
iterative coalescer is also a FunctionPass which does nothing.  It's simply 
there to fulfill the requirement that the register allocator depends on a 
coalescer.  This way I could use the SimpleRegisterCoalescer or the new 
iterative coalescer in a pluggable manner.  The generalized graph coloring 
allocator holds a reference to the coalescer.  SimpleRegisterCoalescing does 
nothing in its implementation of coalesceFunction.

This is all very far from ideal.  What we really need is a PassManager that 
knows about multually dependent, iterative algorithms.  I thought about this a 
bit back in the day and came up with the idea of a hierarchy of PassManagers.  
A set of iterative passes could live in a PassManager under the top-level 
PassManager and the child PassManager could specify dependencies for all of 
the passes it manages.  I didn't get very far with this so I don't know it 
it's a viable solution.

The iterative coalescer does its own correctness and profitability analysis 
but reuses the code from SimpleRegisterCoalescing to do the actual LLVM IR and 
dataflow updates.  That's non-trivial work.  The code to do this in 
SimpleRegisterCoalescing is a bit...well...convoluted.  :)  I did a 
significant amount of work to separate that code out from the dataflow and 
profitability analysis that determines when to coalesce copies.

This I think is very valuable work and I'd like to push it back.  It's always 
good to separate analyses and updates as much as possible so that things can 
be reused.

But I can't promise that I'll be able to merge all of the work I've  done.  We 
have quite a bit going on here right now and I've been moved to other bits of 
work.  I'll see if I can get some things accomplished out-of-band.

                                                       -Dave



More information about the llvm-dev mailing list