[LLVMdev] Pluggable Register Coalescers
Evan Cheng
evan.cheng at apple.com
Wed Jul 11 10:37:55 PDT 2007
Hi all,
Tanya and Reid's ideas are very good. I think we want to go towards
pluggable register coalescers. That said, I don't think the longer
term plan to stop short term progress. To me, it's totally acceptable
for the allocator to directly call the coalescers at this point. I
would love to see a smarter coalescer. That's something we can use
today! :-)
Thanks,
Evan
On Jul 11, 2007, at 10:41 AM, Tanya M. Lattner wrote:
>
>>> Ok, that sounds like a good plan. I'll brush up on how alias
>>> analysis
>>> works and work from there.
>>
>> I've been looking at this and it's become clear to me that we need
>> some kind
>> of abstract coalescing interface similar to what the AliasAnalysis
>> class
>> provides. I think we need the same thing for register allocators.
>>
>> LLVM's existing coalescer is very simple. It just goes and
>> replaces every
>> copy it can. In general, a coalescer will want to query the register
>> allocator about which copies it should remove. For example, Briggs'
>> conservative coalescer will not remove copies that could
>> potentially cause
>> spills. Only the register allocator has the information to make that
>> decision.
>> A coalescing interface needs to provide hooks for the register
>> allocator to
>> invoke it potentially multiple times with a potentially restricted
>> scope. The
>> register allocator needs to provide an interface for the coalescer
>> to ask
>> questions like, "is this copy here to split live ranges?" and, "will
>> coalescing this copy potentially cause a spill?"
>>
>> AI think all this will require is new RegisterCoalescer and
>> RegisterAllocator
>> interface classes that can be multiply-inherited (with
>> MachineFunctionPass)
>> by the various implementations.
>>
>> It's not totally clear to me whether coalescers should even
>> inherit from
>> MachineFunctionPass as they are really invoked by the register
>> allocator,
>> not PassManager. But then again, I can imagine some coalescers
>> (like the
>> existing one) being independent enough to run on their own at any
>> time.
>> Opinions on this are welcome.
>
> I think the coalescer should be flexible enough to be run
> independent of
> the register allocator. For example, you may want to expose the copies
> induced by transforming out of SSA to the scheduler. If the
> scheduler is
> run before register allocation, then you would want the coalescing to
> happen before as well.
>
> -Tanya
> _______________________________________________
> 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