[PATCH] D24918: [ADCE] Add code to remove dead branches

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 5 14:29:31 PST 2016


On Mon, Dec 5, 2016 at 1:51 PM, David Callahan <dcallahan at fb.com> wrote:

> Thanks for the GNU pointer.
>
> Of course.


> Rather than replacing a “dead” conditional branch with an unconditional
> branch the live post-dominator, the make it unconditional to a preferred
> successor and then remove the other outgoing edges.
>

Right, it implements the morgan textbook algorithm, which is a little less
advanced, but may not matter in practice for most normal CFG's.

(the nearest live post-dominator  is going to be somewhere in the same DFS
tree branch, but maybe not this one)

> The preferred successor is the smallest in an inverted post order
> numbering of the CFG.  This means that PHI nodes get updated only as a side
> effect of removing edges which does seem simpler.
>
> Let me code that and see how it compares.
>
>
> From: Daniel Berlin <dberlin at dberlin.org>
> Date: Monday, December 5, 2016 at 12:33 PM
> To: "reviews+D24918+public+0f389072c9f76e8c at reviews.llvm.org" <
> reviews+D24918+public+0f389072c9f76e8c at reviews.llvm.org>
> Cc: David Callahan <dcallahan at fb.com>, David Majnemer <
> david.majnemer at gmail.com>, "nadav.rotem at me.com" <nadav.rotem at me.com>,
> Mehdi Amini <mehdi.amini at apple.com>, llvm-commits <
> llvm-commits at lists.llvm.org>, Kevin Frei <freik at fb.com>, Taewook Oh <
> twoh at fb.com>
> Subject: Re: [PATCH] D24918: [ADCE] Add code to remove dead branches
>
>
>
> On Mon, Dec 5, 2016 at 10:41 AM, David Callahan via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> david2050 added a comment.
>>
>> Regarding the question of simpler update to the control flow, I reviewed
>> two references from @dberlin:
>>
>> (1)  https://www.clear.rice.edu/comp512/Lectures/10Dead-Clean-SCCP.pdf
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.clear.rice.edu_comp512_Lectures_10Dead-2DClean-2DSCCP.pdf&d=DgMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=lFyiPUrFdOHdaobP7i4hoA&m=a2z_JzEUPXIR8SW8ncviG0QnzTSu5qgwQaVsknCXa5k&s=_LlVFr4CX1Vt9bxHJQIOgbALfcgzVvktMe7lJEiIDdQ&e=>
>>
>> In this work, the PHI nodes contain only references to named definitions
>> and do not include a reference to the predecessor blocks associated with
>> reaching paths from those definitions.
>>
>
> Yup, i'm not sure what the issue is that makes this harder :)
>
>
>
>> (2)  https://github.com/apple/swift/blob/master/lib/SILOptimizer/
>> Transforms/DeadCodeElimination.cpp
>>
>> This swift variant makes no explicit reference to Phi nodes and does
>> neither updates them nor manages explicit predecessors as far as I can tell.
>>
> You keep saying explicit predecessors, but again, i'm not sure what the
> issue there is.
> LLVM does not actually have explicit predecessors.
> The predecessor iterators walk over the users of the basic block (which is
> a Value, and so has Uses/Users) to see which terminator instructions use it.
> It then hands those blocks as predecessors.
>
> So, for example, changing a *use* in a conditional branch updates the
> predecessors for the used block.
>
> It's certainly true that this does not update phi nodes, which store
> explicit references, but that does not seem difficult to handle (since you
> can update them when you change the conditional branch, since at that point
> you know which phi nodes have edges that are about to change).
>
>
>> Does anyone have another pointer to compiler which have SSA-based dead
>> code elimination including control flow which might guide to a similar
>> approach the code here?
>>
>
> GCC has explicit edges, and phi nodes have explicit blocks.
> https://gcc.gnu.org/svn/gcc/trunk/gcc/tree-ssa-dce.c
> (ignore the virtual phi handling, which is memoryssa updating, not regular
> CFG updating).
>
> Note it does not do anything amazingly difficult :)
>
> In any case, this seems like one of those things where if we had a
> whiteboard in person, we could probably just solve  it in 10 minutes.
>
> I don't think this should block the patch right now, since this is not
> heavily used or if you think this is too hard to do, let's just get this in
> and iterate on it in tree.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161205/66a34de2/attachment.html>


More information about the llvm-commits mailing list