[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