[LLVMdev] Pluggable Register Coalescers

Tanya M. Lattner tonic at nondot.org
Wed Jul 11 10:41:26 PDT 2007


>> Ok, that sounds like a good plan.  I'll brush up on how alias analysis
>> works and work from there.
>
> I've been looking at this and it's become clear to me that we need some kind
> of abstract coalescing interface similar to what the AliasAnalysis class
> provides.  I think we need the same thing for register allocators.
>
> LLVM's existing coalescer is very simple.  It just goes and replaces every
> copy it can.  In general, a coalescer will want to query the register
> allocator about which copies it should remove.  For example, Briggs'
> conservative coalescer will not remove copies that could potentially cause
> spills.  Only the register allocator has the information to make that
> decision.
> A coalescing interface needs to provide hooks for the register allocator to
> invoke it potentially multiple times with a potentially restricted scope.  The
> register allocator needs to provide an interface for the coalescer to ask
> questions like, "is this copy here to split live ranges?" and, "will
> coalescing this copy potentially cause a spill?"
>
> AI think all this will require is new RegisterCoalescer and RegisterAllocator
> interface classes that can be multiply-inherited (with  MachineFunctionPass)
> by the various implementations.
>
> It's not totally clear to me whether coalescers should even inherit from
> MachineFunctionPass as they are really invoked by the register allocator,
> not PassManager.  But then again, I can imagine some coalescers (like the
> existing one) being independent enough to run on their own at any time.
> Opinions on this are welcome.

I think the coalescer should be flexible enough to be run independent of 
the register allocator. For example, you may want to expose the copies 
induced by transforming out of SSA to the scheduler. If the scheduler is 
run before register allocation, then you would want the coalescing to 
happen before as well.

-Tanya



More information about the llvm-dev mailing list