[LLVMdev] Regalloc Refactoring
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
>>> 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
> and have them work together well in the same framework. The key to
> 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
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().
>> 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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev