Enable the new LoopInfo algorithm by default.
The primary advantage is that loop optimizations will be applied in a
stable order. This helps debugging and unit test creation. It is also
a better overall implementation without pathologically bad performance
on deep functions.
On large functions (llvm-stress --size=200000 | opt -loops)
Before: 0.1263s
After: 0.0225s
On deep functions (after tweaking llvm-stress, thanks Nadav):
Before: 0.2281s
After: 0.0227s
See r158790 for more comments.
The loop tree is now consistently generated in forward order, but loop
passes are applied in reverse order over the program. If we have a
loop optimization that prefers forward order, that can easily be
achieved by adding a different type of LoopPassManager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159183 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/lib/Analysis/LoopInfo.cpp b/lib/Analysis/LoopInfo.cpp
index c5e5bbe..20c33a3 100644
--- a/lib/Analysis/LoopInfo.cpp
+++ b/lib/Analysis/LoopInfo.cpp
@@ -44,10 +44,6 @@
VerifyLoopInfoX("verify-loop-info", cl::location(VerifyLoopInfo),
cl::desc("Verify loop info (time consuming)"));
-static cl::opt<bool>
-StableLoopInfo("stable-loops", cl::Hidden, cl::init(false),
- cl::desc("Compute a stable loop tree."));
-
char LoopInfo::ID = 0;
INITIALIZE_PASS_BEGIN(LoopInfo, "loops", "Natural Loop Information", true, true)
INITIALIZE_PASS_DEPENDENCY(DominatorTree)
@@ -516,10 +512,7 @@
//
bool LoopInfo::runOnFunction(Function &) {
releaseMemory();
- if (StableLoopInfo)
- LI.Analyze(getAnalysis<DominatorTree>().getBase());
- else
- LI.Calculate(getAnalysis<DominatorTree>().getBase()); // Update
+ LI.Analyze(getAnalysis<DominatorTree>().getBase());
return false;
}
diff --git a/lib/Analysis/LoopPass.cpp b/lib/Analysis/LoopPass.cpp
index aba700a..1540112 100644
--- a/lib/Analysis/LoopPass.cpp
+++ b/lib/Analysis/LoopPass.cpp
@@ -162,7 +162,7 @@
// Recurse through all subloops and all loops into LQ.
static void addLoopIntoQueue(Loop *L, std::deque<Loop *> &LQ) {
LQ.push_back(L);
- for (Loop::iterator I = L->begin(), E = L->end(); I != E; ++I)
+ for (Loop::reverse_iterator I = L->rbegin(), E = L->rend(); I != E; ++I)
addLoopIntoQueue(*I, LQ);
}
@@ -183,8 +183,12 @@
// Collect inherited analysis from Module level pass manager.
populateInheritedAnalysis(TPM->activeStack);
- // Populate Loop Queue
- for (LoopInfo::iterator I = LI->begin(), E = LI->end(); I != E; ++I)
+ // Populate the loop queue in reverse program order. There is no clear need to
+ // process sibling loops in either forward or reverse order. There may be some
+ // advantage in deleting uses in a later loop before optimizing the
+ // definitions in an earlier loop. If we find a clear reason to process in
+ // forward order, then a forward variant of LoopPassManager should be created.
+ for (LoopInfo::reverse_iterator I = LI->rbegin(), E = LI->rend(); I != E; ++I)
addLoopIntoQueue(*I, LQ);
if (LQ.empty()) // No loops, skip calling finalizers