Removing SimpleRewriter (formerly SimpleSpiller)

Hi all,

Is anyone still using SimpleRewriter (formerly known as
SimpleSpiller)? A quick check with the test suite suggests that it's
badly broken. If it's not being used I'd like to remove it as part of
my tidy-up of the register allocator.

- Lang.

I vote for execution of SimpleRewriter.

Evan

I vote for execution of SimpleRewriter.

Yeah, go ahead and axe it: Off with its head!

-Chris

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".

- Lang.

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.

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

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).

The new framework will definitely be doing both IR modifications and
liveness info updates. Keeping these concerns separate is a good idea,
and I'll do my best, however the primary goal at the moment is
incremental improvement of the current scheme.

- Lang.