[LLVMdev] Regalloc Refactoring

Evan Cheng evan.cheng at apple.com
Tue Apr 17 15:35:06 PDT 2007


On Apr 17, 2007, at 2:24 PM, Chris Lattner wrote:

> On Tue, 17 Apr 2007, David Greene wrote:
>> Evan Cheng wrote:
>>> Obviously, smart heuristics can make a big difference here  
>>> (estimated
>>> register pressures, etc.) But the more important thing is how the
>>> passes down stream can recover from the earlier mistakes. By  
>>> this, we
>>> mean live range splitting and re-materialization.
>>
>> Can you explain this a little more?  Do you mean that neither live
>> range splitting nor rematerialization are practically possible
>> with LLVM right now?
>
> Anything is possible. :)
>
> In practice, there are good ways and bad ways to build things.  For
> example, Evan recently implemented a really simple form of remat that
> works on instructions that have no register inputs (e.g. things like
> "load immediate").
>
> That said, we want to implement the full generality of remat and  
> splitting
> and have them work together well in the same framework.  The key to  
> this
> is getting the right data structure.
>
>> If that's the case, what are the primary issues?
>
> Evan is the best to respond to this at this point :)

There are a lot of implementation details. Many of which I don't have  
clear understanding yet. Take splitting for example.  The allocator  
needs to pick a point and recompute conflicts. Can we do that with  
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().

Thanks,

Evan

>
>> These are things I will definitely have to do here so I'm quite
>> interested in how this will all work.  I'm more than happy to do
>> a bunch of heavy lifting getting things into shape.
>
> Great!
>
> -Chris
>
> -- 
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> 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