[llvm] [CodeGenPrepare][NFC] Reland: Update the dominator tree instead of rebuilding it (PR #179040)

Nikita Popov via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 3 08:57:45 PST 2026


================
@@ -626,39 +637,41 @@ bool CodeGenPrepare::_run(Function &F) {
   // unconditional branch.
   EverMadeChange |= eliminateMostlyEmptyBlocks(F);
 
-  ModifyDT ModifiedDT = ModifyDT::NotModifyDT;
   if (!DisableBranchOpts)
-    EverMadeChange |= splitBranchCondition(F, ModifiedDT);
+    EverMadeChange |= splitBranchCondition(F);
 
   // Split some critical edges where one of the sources is an indirect branch,
   // to help generate sane code for PHIs involving such edges.
   EverMadeChange |=
       SplitIndirectBrCriticalEdges(F, /*IgnoreBlocksWithoutPHI=*/true);
 
+  // Transformations above may invalidate dominator tree and/or loop info.
+  if (EverMadeChange) {
+    DTU->recalculate(F);
+    LI->releaseMemory();
+    LI->analyze(DTU->getDomTree());
+  }
+
   // If we are optimzing huge function, we need to consider the build time.
   // Because the basic algorithm's complex is near O(N!).
   IsHugeFunc = F.size() > HugeFuncThresholdInCGPP;
 
-  // Transformations above may invalidate dominator tree and/or loop info.
-  DT.reset();
-  LI->releaseMemory();
-  LI->analyze(getDT(F));
-
   bool MadeChange = true;
   bool FuncIterated = false;
   while (MadeChange) {
     MadeChange = false;
 
+    // Flush pending updates as we may delete BasicBlocks in previous iteration
+    // of the current loop.
+    DTU->flush();
----------------
nikic wrote:

Are we doing this just so that the following loop skips the deleted BBs? Can we add a `DTU->isBBPendingDeletion(&BB)` check in the loop instead to avoid this flush?

https://github.com/llvm/llvm-project/pull/179040


More information about the llvm-commits mailing list