[llvm-dev] Dominator tree side effect or intentional

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 27 08:48:05 PDT 2017


On Fri, Oct 27, 2017 at 5:03 AM, Leijsten, G.H.P. via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hello,
>
> I was wondering whether or not some behaviour that I am seeing is expected
> behaviour and that it has been designed like this, or not.
>
> A dominator relation is given by "if A dominates B", then all paths to B
> go through A.
>
> For example, take the CFG below (which is a directed graph (couldn’t make
> the arrow heads but ok.):
>    A
>  /   \
> B     C
>  \   /
>    D
>    |
>    E
>
> We can construct the following dominator tree for the CFG above, DomTree:
>     A
>  /  |  \
> B   D   C
>     |
>     E
>
> I want my pass to do a top-down traversal on the basic blocks in a
> function. I now have an approach where you start at the root of the
> dominator tree and build a work list by visiting all children, similar or
> the same as in MachineCSE. Now I see the following behaviour: when I visit
> the nodes of the root (A in this case), its children have the nice property
> that B and C come before D. This is actually what I want, but is this on
> purpose, or not? It is kind of hard to proof that B and C come before D
> when iterating through the children of the root in this dominator tree.
>

No, the only way to guarantee this is a reverse postorder traversal.

NewGVN actually sorts the siblings of the dominator tree into RPO order
(since the parent-child relationship is already an RPO) so it can just walk
the dominator tree.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171027/d459eb49/attachment.html>


More information about the llvm-dev mailing list