llvm dev - Aug 2007 - [LLVMdev] [patch] Pluggable Coalescers

On Monday 27 August 2007 19:02, Evan Cheng wrote:
> > interfere() isn't sufficient because the allocation algorithm may
> > place other
> > constraints on coalescing.  George and Appel's iterated register
> > coalescing
> > is a prime example.  It wants to "freeze" copies that should
not be
> > coalesced
> > because doing so might cause spilling.  You don't want the
coalescer
> > touching
> > these because if it does the data structures will be inconsistent.
>
> Ok. But that means this method doesn't belong to the InterferenceData
> class. Shouldn't the allocator query the coalescer instead?
No, it's the other way around.  The coalescer needs to decide whether it can
coalesce something.  It must ask the allocator if it's ok.

This is part of InterferenceData to decouple the coalescer from the allocator
so the coalescer doesn't have to keep a pointer to the allocator.  In my
current implementation, InterferenceData for the graph coloring allocator
has references to all of the necessary information to return an answer to
this question.

                                                       -Dave

On Aug 28, 2007, at 8:59 AM, David Greene wrote:
> On Monday 27 August 2007 19:02, Evan Cheng wrote:
>
>>> interfere() isn't sufficient because the allocation algorithm
may
>>> place other
>>> constraints on coalescing.  George and Appel's iterated
register
>>> coalescing
>>> is a prime example.  It wants to "freeze" copies that
should not be
>>> coalesced
>>> because doing so might cause spilling.  You don't want the
coalescer
>>> touching
>>> these because if it does the data structures will be inconsistent.
>>
>> Ok. But that means this method doesn't belong to the
InterferenceData
>> class. Shouldn't the allocator query the coalescer instead?
>
> No, it's the other way around.  The coalescer needs to decide  
> whether it can
> coalesce something.  It must ask the allocator if it's ok.
>
> This is part of InterferenceData to decouple the coalescer from the  
> allocator
> so the coalescer doesn't have to keep a pointer to the allocator.   
> In my
> current implementation, InterferenceData for the graph coloring  
> allocator
> has references to all of the necessary information to return an  
> answer to
> this question.
Ok. This means InterferenceData contains more than interference  
information. Perhaps you can choose a better name? Or add another  
data structure to store this information.

Evan
>
>                                                        -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Wednesday 29 August 2007 12:51, Evan Cheng wrote:
> Ok. This means InterferenceData contains more than interference
> information. Perhaps you can choose a better name?
Fair enough.  :)

                                         -Dave