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

[David Callahan via llvm-commits]

Thanks for the GNU pointer.

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.  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<mailto:dberlin at dberlin.org>>
Date: Monday, December 5, 2016 at 12:33 PM
To: "reviews+D24918+public+0f389072c9f76e8c at reviews.llvm.org<mailto:reviews+D24918+public+0f389072c9f76e8c at reviews.llvm.org>" <reviews+D24918+public+0f389072c9f76e8c at reviews.llvm.org<mailto:reviews+D24918+public+0f389072c9f76e8c at reviews.llvm.org>>
Cc: David Callahan <dcallahan at fb.com<mailto:dcallahan at fb.com>>, David Majnemer <david.majnemer at gmail.com<mailto:david.majnemer at gmail.com>>, "nadav.rotem at me.com<mailto:nadav.rotem at me.com>" <nadav.rotem at me.com<mailto:nadav.rotem at me.com>>, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>>, llvm-commits <llvm-commits at lists.llvm.org<mailto:llvm-commits at lists.llvm.org>>, Kevin Frei <freik at fb.com<mailto:freik at fb.com>>, Taewook Oh <twoh at fb.com<mailto: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<mailto: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/c81f3d1d/attachment.html>