[LLVMdev] Pluggable Register Coalescers

Evan Cheng evan.cheng at apple.com
Wed Jul 11 10:37:55 PDT 2007


Hi all,

Tanya and Reid's ideas are very good. I think we want to go towards  
pluggable register coalescers. That said, I don't think the longer  
term plan to stop short term progress. To me, it's totally acceptable  
for the allocator to directly call the coalescers at this point. I  
would love to see a smarter coalescer. That's something we can use  
today! :-)

Thanks,

Evan

On Jul 11, 2007, at 10:41 AM, Tanya M. Lattner wrote:

>
>>> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list