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

[Jakob Stoklund Olesen]

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.

Suggestions welcome.

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110914/c3a468c4/attachment.html>