Dominator tree side effect or intentional

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.

Is it safe to assume that this always happens? If you look at dominator theory only, then D can just as well come before C, since they are on the same level, namely, as children of A.
Has the topological order been taken into account such that iterating through children of a dominator tree node, visits children first that would be strictly before other children in topological order?

Hope my question is clear enough.

Kind regards,
Guus Leijsten

Hi Guus,

In (Post)DominatorTree children (of the same parent) are unordered. The thing you observed is the result of the initial DFS walk on the CFG that uses the successors and predecessors functions.

There is no strong guarantee of the order of children in a freshly constructed (post)dom tree, and it was in fact changed for postdominators a few months ago without any breakage that I know of. What’s more, the order can be changed during a domtree update.

On top of that, you have to keep in mind that the LLVM’s implementation of the DominatorTree doesn’t store nodes (forward) unreachable basic blocks, and it claims that every node dominates a (forward) unreachable node.

Wouldn’t a BFS RPO perhaps work in your case?

Hope that this makes things a bit more clear,
Kuba

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.

Hi Kuba,

Thanks for clearing that up.

After some time, I can contradict the above statement (that I wrote in Oktober) with a yuv2rgb benchmark and the children of a dominator tree or the successors of a basic block are indeed unordered like you said already.

Kind regards,
Guus Leijsten