[LLVMdev] Regalloc Refactoring

[Evan Cheng]

On Apr 18, 2007, at 9:10 AM, David Greene wrote:

> Evan Cheng wrote:
>
>> the given infrastructure? Perhaps. But not without pain. The current
>> data structure is lacking detailed def-use info to properly determine
>> the correct split point. The register allocator even treat
>> "fixed" (i.e. physical register) intervals separately from other
>> active ones.
>>
>> The point is, the current code needs a lot of massaging. If you are
>> interested (after your first rounds of refactoring), please consider
>> a replacement for LiveInterval that keeps more accurate info that can
>> be plugged into the same existing allocator. The next step is to do
>> away with the r2rmap and rep().
>
> This gets back to my questions about what LiveIntervals lacks.
>
> - What "data structure" are you referring to above?

LiveInterval, LiveRange, and friends.

>
> - What specific def-use info is needed that we don't have access
>    to currently?

Quick answer is: You want uses of each virtual registers to make it  
easier to modify if splitting is performed. You want the definition  
instruction in order to do rematerialization. It might also be useful  
to keep track of positions of the copies that are joined as these are  
natural (though non-optimal) split points.

The current LiveInterval value numbering scheme is messy to me. Upon  
joining, I would rather update the registers of all the uses right  
away while keeping the original registers as unique ids (makes it  
easy to go back to when splitting).

>
> - A couple of weeks ago I asked about the comment in
>    LiveIntervalAnalysis referring to "conservative" computation.
>    What's conservative about it?  What information does it lack that
>    a traditional live variable/live range analysis provides?
>
>    The answers I got back said essentially that it's not conservative
>    at all and can't be improved upon.  I'm getting a different sense
>    from you so I'd like to understand this better.

It's not conservative, rather just lacking proper bookkeeping.

Evan

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