[llvm-commits] [llvm] r91549 - in /llvm/trunk/lib/CodeGen: LiveIntervalAnalysis.cpp PHIElimination.cpp PHIElimination.h

Jakob Stoklund Olesen stoklund at 2pi.dk
Wed Dec 16 16:45:54 PST 2009


On Dec 16, 2009, at 4:16 PM, Chris Lattner wrote:

> 
> On Dec 16, 2009, at 10:55 AM, Jakob Stoklund Olesen wrote:
> 
>> Author: stoklund
>> Date: Wed Dec 16 12:55:53 2009
>> New Revision: 91549
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=91549&view=rev
>> Log:
>> Reuse lowered phi nodes.
>> 
>> Tail duplication produces lots of identical phi nodes in different basic
>> blocks. Teach PHIElimination to reuse the join registers when lowering a phi
>> node that is identical to an already lowered node. This saves virtual
>> registers, and more importantly it avoids creating copies the the coalescer
>> doesn't know how to eliminate.
> 
> Hi Jakob,
> 
> I don't have any objection to this patch, but would it alternatively (or also) make sense for the SSAUpdate engine in taildupe to reuse PHI nodes when they already exist, instead of always inserting new ones?  Would that help with this issue?

I haven't seen that happen outside weird test cases. With this patch they will share a join register after lowering, so

x<def> = phi ...
y<def> = phi ...

becomes

x<def> = mov j
y<def> = mov j<kill>

This pattern can still cause a bit of coalescer confusion - it sees false interference between x and y, and cannot join them without joining one with j first. I think in most cases it will be fine.

The patch handles a similar issue in the predecessor blocks. If there are multiple phi successors, each would have its own join register:

j1<def> = mov r
j2<def> = mov r<kill>
brind ...

The coalescer could not join j1 and j2 because of false interference. It had to join one with r first, and that was not always possible. With the patch, the successor phis share a join register:

j<def> = mov r<kill>
brind ...

If SSAUpdate produces lots of identical phis in the same block, it would probably be healthy to merge them, but if it is a freak occurence, I don't think it matters much.

/jakob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1929 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20091216/2bb30931/attachment.bin>


More information about the llvm-commits mailing list