[LLVMdev] [PATCH] Re: Pluggable Register Coalescers

Evan Cheng evan.cheng at apple.com
Wed Jul 18 11:02:42 PDT 2007


On Jul 17, 2007, at 12:21 PM, David Greene wrote:

>
>> Are you designing the coalescer so it always run before  
>> allocation? If so,
>> please keep it simple. :-)
>
> Believe me, I'm trying to keep it as simple as possible.  The  
> coalescer I'm
> working on doesn't run "before" allocation.  It runs in conjunction  
> with it.
> Decisions have to be made here as to whether it gets pushed out  
> into the
> public repository and because of the way it's designed, the general  
> llvm
> community might not be interested in it anyway.  It's more complex  
> due to
> some additional requirements on this end that don't have any relevance
> to the llvm community.

Ok. Then I think it's reasonable for it to be tied to the allocator.  
If there are stuff we want to factor out later. We can do so. Notice  
I said "we", I am hopeful you will consider contributing it to the  
public repository. :-)

>
>> Make it operate on existing live interval  information (perhaps  
>> enhanced if
>> needed)
>
> Yep, it does.  Hence the factoring effort on the current coalescer.
>
>> and the new interference graph class (again, if needed).
>
> As stated above, I'd like to make this an abstract interface to an
> interference graph, due to complexity of my implementation that the  
> llvm
> community doesn't care about.

Sounds good.

>
>> I think as a first step, the coalescer should be as aggressive as  
>> possible
>> (i.e. no concerns for what the allocator would do).
>
> Well, that's the current coalescer, and the whole reason I'm  
> writing a new one
> is that we don't want it to be so aggressive.

Fair enough. I still believe most of the "harms" caused by an over- 
aggressive coalescer can be fixed later by the allocator with the  
help of splitting and rematerialization. But given the current  
implementation doesn't have either, it would be interesting to see  
what a smarter coalescer can do.

> In the end, what I am able to contribute back at this point is the
> infrastructure to make it easy to implement new coalescers.  Due to
> legal and other issues, I can't contribute any concrete  
> implementations
> right now, and it's not likely I'll be able to do so any time  
> soon.  But I do
> want to make sure that the infrastructure works for everyone.

Great. Thanks!

Evan

>
> This is very good feedback.  I'll take it and rework the patch.
>
>                                                     -Dave
> _______________________________________________
> 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