[PATCH] D35341: [Dominators] Implement incremental insertions

Jakub Kuderski via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 13 18:10:12 PDT 2017


kuhar marked 2 inline comments as done.
kuhar added inline comments.


================
Comment at: include/llvm/Support/GenericDomTree.h:455
+  /// on the actual CFG. There cannot be any other updates that the dominator
+  /// tree doesn't know about.
+  /// Note that for postdominators it automatically takes care of inserting
----------------
dberlin wrote:
> Will it really work if you do it before the actual cfg change exists?
> (IE without that edge, will you still be able to find the right successors, predecessors?)
> If so, great!
Yes, but only for insertions, not for deletions.

The proof goes like this:
There are 2 cases - insertion from (x -> y) with incoming edges to reachable (a) nodes and unreachable (b) nodes.
a) To notice that the about-to-be inserted edge (x -> y) is missing, the path P mentioned in lemma 2.5 would have to go to back to x. So when we visit x we iterate it's successors to find affected nodes.  y is not there, since there is no edge (yet) from x to y, but it doesn't matter, as we only visit each node once and the algorithm starts by visiting y.
b) In the case when y is unreachable, the algorithm reruns SemiNCA on a subtree starting at y. SemiNCA only processed unreachable nodes and y will be processed first. Then, it performs reachable insertions on the connecting edges it found during the DFS walk. (x -> y) cannot be a connecting edge, as y was unreachable.

So there's no way for the algorithm to notice that there's no edge from x to y.

When it comes to deletions, there are cases when the algorithm needs to rebuild the whole tree -- so the deletion has to happen before, or it'll reconstruct the exact same tree.


https://reviews.llvm.org/D35341





More information about the llvm-commits mailing list