[Dominators] Teach LoopDeletion to use the new incremental API

[kuhar]

Summary

This patch makes LoopDeletion use the incremental DominatorTree API.

We modify LoopDeletion to perform the deletion in 5 steps:

1. Create a new dummy edge from the preheader to the exit, by adding a conditional branch.
2. Inform the DomTree about the new edge.
3. Remove the conditional branch and replace it with an unconditional edge to the exit. This removes the edge to the loop header, making it unreachable.
4. Inform the DomTree about the deleted edge.
5. Remove the unreachable block from the function.

Creating the dummy conditional branch is necessary to perform incremental DomTree update.
We should consider using the batch updater when it's ready.

[kuhar]

Add a comment explaining the special logic here.

[kuhar]

Make the edited for loop more concise.

[grosser]

Nice work! This mostly looks good to me, but I have some minor question. I mark this as request changes to be notified by Phabricator in case you reply. It seems some of the email notifications don't really work at the moment.

lib/Transforms/Scalar/LoopDeletion.cpp

285

preheader

290

I think it would be great to document this behavior in deleteEdge() and reference this behavior there! Also, do we happen to have a test case that documents this bulk removal of nodes in DT. I think this is an interesting, but not totally expected use of the deleteEdge API and it would be great if this has good test coverage.

Thanks again for working on this,

[kuhar]

I think that I came up better guidelines on chaining updates. I included explanations for that in the comments and I added two new unittests illustrating them.

I misunderstood how LoopDeletion changes CFG and the previous explanation was incorrect because of that. Please tell me if this one is clear enough.

[kuhar]

Zhendong and Qirun were able to generate a CFG that broke the previous update chained logic. It turns out, that it's not legal to chain a deletion and an insertion when there's irreducible control flow that appears in the temporarily deleted subtree. I added a regression test for that.

I think that this shows that the current incremental API is tricky to use when CFG and DomTree updates are not performed in lockstep, and we *really* need a proper batch update API.

[kuhar]

@grosser, @dberlin, @davide

Ping.
(This patch doesn't depend on the postdominator changes in review or on the batch updater.)

[• dberlin]

This looks fine to me.
I think it may make sense to try to add a few simple cfg drawings to show what machinations are really happening here, but if others undersrtand them just from the text descriptions, awesome.

[grosser]

Hi @kuhar,

thank you for updating the comment. I found a couple of minor typos. The code likely looks good, but I don't see any reference to the irreducible control flow issues you mentioned. I assume you are now connecting the loop header to its exit to avoid the PDT update issue before. It might make sense to briefly explain why first deleting and then adding a new edge will break.

In any case, these are at most minor issues. Feel free to commit.

Best,
Tobias

include/llvm/Support/GenericDomTree.h

492 ↗

(On Diff #108541)

That looks good to me.

lib/Transforms/Scalar/LoopDeletion.cpp

249

THE dominator tree update

255

Could you maybe move the " DT.insertEdge(Preheader, ExitBlock);" this makes clear that the DT update comes right after the CFG change. Now it is hidden after the PHI update.

279–295

dominator

unittests/IR/DominatorTreeTest.cpp

538 ↗

(On Diff #108541)

Remove "a"

539 ↗

(On Diff #108541)

Remove "the"
Remove "of them"

[kuhar]

Address Daniel's and Tobias' comments.

[grosser]

Amazing. Now this reads really nice.

unittests/IR/DominatorTreeTest.cpp

538 ↗

(On Diff #108541)

Still an "a" too much.

lib/Transforms/Scalar/LoopDeletion.cpp

static void deleteDeadLoop(Loop *L, DominatorTree &DT, ScalarEvolution &SE,
   assert(ExitBlock && "Should have a unique exit block!");
 
   assert(L->hasDedicatedExits() && "Loop should have dedicated exits!");
 
   // Connect the preheader directly to the exit block.
   // Even when the loop is never executed, we cannot remove the edge from the
   // source block to the exit block. Consider the case where the unexecuted loop
   // branches back to an outer loop. If we deleted the loop and removed the edge
   // coming to this inner loop, this will break the outer loop structure (by
   // deleting the backedge of the outer loop). If the outer loop is indeed a
   // non-loop, it will be deleted in a future iteration of loop deletion pass.
   Preheader->getTerminator()->replaceUsesOfWith(L->getHeader(), ExitBlock);
 
   // Rewrite phis in the exit block to get their inputs from the Preheader
   // instead of the exiting block.
   BasicBlock::iterator BI = ExitBlock->begin();
   while (PHINode *P = dyn_cast<PHINode>(BI)) {
     // Set the zero'th element of Phi to be from the preheader and remove all
     // other incoming values. Given the loop has dedicated exits, all other
     // incoming values must be from the exiting blocks.
     int PredIndex = 0;
     P->setIncomingBlock(PredIndex, Preheader);
     // Removes all incoming values from all other exiting blocks (including
     // duplicate values from an exiting block).
     // Nuke all entries except the zero'th entry which is the preheader entry.
     // NOTE! We need to remove Incoming Values in the reverse order as done
     // below, to keep the indices valid for deletion (removeIncomingValues
     // updates getNumIncomingValues and shifts all values down into the operand
     // being deleted).
     for (unsigned i = 0, e = P->getNumIncomingValues() - 1; i != e; ++i)
       P->removeIncomingValue(e-i, false);
 
     assert((P->getNumIncomingValues() == 1 &&
             P->getIncomingBlock(PredIndex) == Preheader) &&
            "Should have exactly one value and that's from the preheader!");
     ++BI;
   }
 
-  // Update the dominator tree and remove the instructions and blocks that will
-  // be deleted from the reference counting scheme.
-  SmallVector<DomTreeNode*, 8> ChildNodes;
-  for (Loop::block_iterator LI = L->block_begin(), LE = L->block_end();
-       LI != LE; ++LI) {
-    // Move all of the block's children to be children of the Preheader, which
-    // allows us to remove the domtree entry for the block.
-    ChildNodes.insert(ChildNodes.begin(), DT[*LI]->begin(), DT[*LI]->end());
-    for (DomTreeNode *ChildNode : ChildNodes) {
-      DT.changeImmediateDominator(ChildNode, DT[Preheader]);
-    }
-
-    ChildNodes.clear();
-    DT.eraseNode(*LI);
+  // Update the dominator tree. Disconnect the loop by bypassing the loop body.
+  //
+  // This is a special use of the incremental API.
+  // We know that all of the loop nodes are dominated by the loop preheader.
+  // Instead of telling the DT of deleting and inserting edges as we go, we
+  // defer it until here. We tell the DT that we delete the edge from the
+  // preaheader to the header and the incremental algorithm will automatically
+  // disconnect the rest of the loop.
+  // When we tell the DT to insert an edge from the preheader to the exit, we
+  // are back in sync with the changes that happened to the CFG.
+  DT.deleteEdge(Preheader, L->getHeader());
+  DT.insertEdge(Preheader, ExitBlock);
 
-    // Remove the block from the reference counting scheme, so that we can
-    // delete it freely later.
-    (*LI)->dropAllReferences();
-  }
+  for (auto *Block : L->blocks())
+    Block->dropAllReferences();
 
   // Erase the instructions and the blocks without having to worry
   // about ordering because we already dropped the references.
   // NOTE: This iteration is safe because erasing the block does not remove its
   // entry from the loop's block list.  We do that in the next section.
   for (Loop::block_iterator LI = L->block_begin(), LE = L->block_end();
        LI != LE; ++LI)
     (*LI)->eraseFromParent();