The pass creates some state which expects to be cleaned up by
a later instance of the same pass. opt-bisect happens to expose
this not ideal design because calling skipLoop() will result in
this state not being cleaned up at times and an assertion firing
in `doFinalization()`. Chandler tells me the new pass manager will
give us options to avoid these design traps, but until it's not ready,
we need a workaround for the current pass infrastructure. Fix provided
by Andy Kaylor, see the review for a complete discussion.
Differential Revision: https://reviews.llvm.org/D25848
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290427
91177308-0d34-0410-b5e6-
96231b3b80d8
}
bool runOnLoop(Loop *L, LPPassManager &LPM) override {
- if (skipLoop(L))
+ if (skipLoop(L)) {
+ // If we have run LICM on a previous loop but now we are skipping
+ // (because we've hit the opt-bisect limit), we need to clear the
+ // loop alias information.
+ LICM.getLoopToAliasSetMap().clear();
return false;
+ }
auto *SE = getAnalysisIfAvailable<ScalarEvolutionWrapperPass>();
return LICM.runOnLoop(L,
--- /dev/null
+; Make sure we don't crash in LICM.
+; RUN: opt %s -licm -opt-bisect-limit=1
+
+define void @patatino() {
+for.cond1:
+ br label %for.body
+for.body:
+ br label %for.cond5
+for.cond5:
+ br i1 true, label %if.end, label %for.end
+if.end:
+ br label %for.cond5
+for.end:
+ br label %for.body
+}