llvm dev - Jun 2009 - [LLVMdev] Removing SimpleRewriter (formerly SimpleSpiller)

On Thursday 04 June 2009 13:57, Lang Hames wrote:
> R.I.P. SimpleRewriter. If anyone needs it resurrected let me know.
>
> This leaves LocalRewriter (the default) and the new TrivialRewriter,
> which is for use only with the new in-place spilling framework. This
> framework appears (if you squint just right) to be basically
> functional now, but it produces awful code. If you want to play with
> it you can invoke it with the magical combination of
> "-join-liveintervals=false -new-spill-framework
-rewriter=trivial".
What's the "new spill framework?"

                               -Dave

The new spilling framework inserts spill code in-place (during
register allocation) rather than deferring it using
VirtRegMap/VirtRegRewriter. The goal is to enable techniques like
iterative splitting to be implemented. It should also be a bit tidier
as it keeps more state in the MachineFunction, rather than in
book-keeping structures like VirtRegMap. The work is in the very early
stages though.

- Lang.

On Thu, Jun 4, 2009 at 1:46 PM, David Greene <dag at cray.com>
wrote:
> On Thursday 04 June 2009 13:57, Lang Hames wrote:
>> R.I.P. SimpleRewriter. If anyone needs it resurrected let me know.
>>
>> This leaves LocalRewriter (the default) and the new TrivialRewriter,
>> which is for use only with the new in-place spilling framework. This
>> framework appears (if you squint just right) to be basically
>> functional now, but it produces awful code. If you want to play with
>> it you can invoke it with the magical combination of
>> "-join-liveintervals=false -new-spill-framework
-rewriter=trivial".
>
> What's the "new spill framework?"
>
>                               -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Thursday 04 June 2009 19:03, Lang Hames wrote:
> The new spilling framework inserts spill code in-place (during
> register allocation) rather than deferring it using
> VirtRegMap/VirtRegRewriter. The goal is to enable techniques like
> iterative splitting to be implemented. It should also be a bit tidier
> as it keeps more state in the MachineFunction, rather than in
> book-keeping structures like VirtRegMap. The work is in the very early
> stages though.
Sounds good.

One thing I would recommend is that the code that does IR
changes be separated from the code (if any) that does dataflow
information updates.  The entanglement of these two functions
is part of the reason that the coalescing code is so complicated.
Separating the actions allows the code to be reused by other
passes (different register allocators, for example).

                               -Dave