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

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 14 08:57:34 PDT 2017


On Tue, Mar 14, 2017 at 6:31 AM, Michael Kruse <llvm-commits at meinersbur.de>
wrote:

> 2017-03-13 20:43 GMT+01:00 Daniel Berlin via llvm-commits
> <llvm-commits at lists.llvm.org>:
> > As another analysis example, this will break the linear time reverse IDF
> > calculation. It already does (and adce tries to work around that now),
> but
> > it will so even more :)
>
> How can that be?


The linear time IDF calculation relies on the level numbering, which in
turn, relies on the parent property.


> All Tobias' suggestion does it adding a phantom edge.
>

Yes, as does mine.


> The most number of edges it could add is the number of blocks.  If IDF
> is linear, let's say in the number of edges, then this would just add
> a constant per additional edge, or something linear in the number of
> blocks.


This is not the part that breaks.
As mentioned, you can see *it already* breaks and ADCE is already trying to
work around it.

The part that breaks is that it assumes the level number is also
representative of paths that can exist in the CFG when computing IDF.
That is, the proof of correctness of stopping after processing a given
level relies on the paths in the CFG vs the paths in the dominator tree.
In Tobias's representation, this does not work, because he has broken the
normal parent property of dominator trees.

Imagine the following CFG;

  a
 /  \
b   c
     |
    exit

where b is a self-loop.

The post-dom tree, in tobias's representation will be

  virtual exit
     |
 exit
     |
    c
   /  \
b     a

In mine, it will be:
virtual exit
 |  |  \
 |  |   exit
 |  |       \
a b       c


One of the two normal invariants of the dominator/post-dominator tree is
that if y is a descendant of x in the tree, there must exist a path from x
to y.
This is in fact, one of the *only* two things that makes a thing a
dominator tree, and is a necessary precondition. See
https://arxiv.org/abs/1604.02711 for proof[1].

In Tobias's representation, b is a child of c, but no path from c to b
exists, breaking that invariant. The IDF calculator will believe that once
it has finished processing c, at level 1, that it must already also have
calculated a correct answer b for at level 2.
This is wrong.
In my representation, because they are the same level, it will continue
processing, as it should.


[1]
Since post-dom is not actually defined for reverse-unreachable blocks, the
actual dom/post-dom tree invariant is that if y is  reachable vertex, ....
Hence the disagreement tobias and I have. In my view, the whole point of
adding reverse-unreachable blocks to the post-dom tree is to give them the
same invariants the existing blocks have.  There's no point in having them
in a post-dom tree if they don't meet the other invariants of the post-dom
tree.  It's useless.  This is why literally every compiler attaches it to
the exit block.





> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170314/acbfb9e5/attachment.html>


More information about the llvm-commits mailing list