[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