If a loop is flattened, the inner loop is removed and the LPM should be informed of this fact, so it can invalidate associated analyses. To support this, we relax an assertion in LPMUpdater to allow invalidating non-top-level loops when running in LoopNestMode, as the pass does not know how exactly it will get scheduled.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
if we have a loop nest pass in one pass manager delete a loop without invalidating its analyses, then another loop pass in a different pass manager allocate a loop at the same address I think we could still see invalid cached analyses
LoopAnalysisManagerFunctionProxy::Result::invalidate() may walk through LoopInfo to get a list of loops to clear analyses, and if we delete a loop, we won't clear the corresponding cached analyses. We can always blow away the entire LoopAnalysisManagerFunctionProxy, but always properly invalidating seems cleaner and there's less chance of things silently going wrong.