[llvm] r296535 - Fix PR 24415 (at least), by making our post-dominator tree behavior sane.

[Daniel Berlin via llvm-commits]

>
> Just to expand on one part:

>
>
> Just to get what you are aiming for. Would a post-dominator tree of the
> form:
>
> [1]  <<exit node>>
>   [2] %bb35
>     [3] %bb35.loopexit3
>     [3] %entry
>       [4] %bb3.i
>
> be something you would be happy with?
>
>
> No.
> Because i do not believe  it is not correct in any arguable sense :)
> It implies that bb35 post-dominates bb3.i, but it does not.
> In fact, *zero* paths from bb3.i to program exit go through bb35,
> Your argument seems to be  is "bb3.i doesn't exit so it doesn't matter".
> But the fact that it's not a child of the virtual exit implies such a path
> *does exist*.
>

To expand on this, in order for x to be a parent of y in the Dom/pdom tree,
there must be a path (in the walk direction) from x to y.  This is a
guaranteed property of Dom tree (in fact, it's a defining property)  See
https://arxiv.org/pdf/1604.02711 lemma 2.1 and theorem 2.2. As mentioned,
algorithms depend on this for correctness
 Your suggestion breaks this. The only way to guarantee this invariant if
you include infinite loops and  noreturn functions is to connect them to a
virtual exit.
(Yes, I'm aware it mentions reachable paths, but unless you want to argue
even further that any path not exiting should be not in the pdt, it is
definitely virtually reachable.

If we avoid paths not exiting in the pdt, we will not be able to correctly
determine control dependence or legal sink points. The answers we get will
simply be wrong because they will assume any infinite loop has no effect,
as I demonstrated in the review.  This is not a thing we should do by
default, as it makes the tree useless for every case other than yours)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170302/b7a81015/attachment.html>