[llvm-commits] [llvm] r139698 - in /llvm/trunk/lib/CodeGen: SplitKit.cpp SplitKit.h

[Chandler Carruth]

On Wed, Sep 14, 2011 at 10:06 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

>
> On Sep 14, 2011, at 9:50 AM, Chandler Carruth wrote:
>
> On Wed, Sep 14, 2011 at 9:45 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:
>
>> Author: stoklund
>> Date: Wed Sep 14 11:45:39 2011
>> New Revision: 139698
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=139698&view=rev
>> Log:
>> Hoist back-copies to the least busy dominator.
>>
>> When a back-copy is hoisted to the nearest common dominator, keep
>> looking up the dominator tree for a less loopy dominator, and place the
>> back-copy there instead.
>>
>> Don't do this when a single existing back-copy dominates all the others.
>> Assume the client knows what he is doing, and keep the dominating
>> back-copy.
>>
>> This prevents us from hoisting back-copies into loops in most cases.  If
>> a value is defined in a loop with multiple exits, we may still hoist
>> back-copies into that loop.  That is the speed/size tradeoff.
>>
>
> This sounds quite cool; testcase?
>
>
> I should have mentioned that this code only runs with
> -split-spill-mode=size.  It is not enabled by default yet.
>
> It is quite difficult to write good test cases for these register allocator
> tricks.  You need to provide a function that tricks the allocator into
> splitting a variable around a loop with multiple exits.  Then check that the
> back-copies or spills are hoisted above the loop.
>
> It is possible to find such a function, obviously, but the test case won't
> be very stable.  The heuristics used to decide which virtual registers are
> split and spilled can be quite chaotic.  That means small changes in passes
> before regalloc can affect it, causing the test case to fail.
>
> We really need a way of injecting machine code into any pass in the
> pipeline, like opt can do with IR.
>

I wonder if using a more "unit test" approach might work here. You could
probably write some helper C++ routines that build up the various data
structures directly, and immediately feed them into SplitKit and check the
result. Shouldn't be hard to write helper routines to check the output
concisely either.

Still, as Evan said, likely non-trivial, but might be more straightforward
than a fully general injection of machine code. On the other hand, it
wouldn't solve as many different problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110914/c9ebf65a/attachment.html>