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

[Daniel Berlin via llvm-commits]

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
>
> 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/530d8f5c/attachment.html>