From 07e7c75eef7742c48d5142ec92d1828f03737ad8 Mon Sep 17 00:00:00 2001 From: Chandler Carruth Date: Tue, 1 Aug 2017 06:40:11 +0000 Subject: [PATCH] [PM] Add a comment clarifying what a particular predicate is doing. This came up as a point of confusion while working on a fundamental problem with the combination of CGSCC iteration and the inliner. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309662 91177308-0d34-0410-b5e6-96231b3b80d8 --- lib/Analysis/CGSCCPassManager.cpp | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/lib/Analysis/CGSCCPassManager.cpp b/lib/Analysis/CGSCCPassManager.cpp index 74b5d79ebac..cb6d139c88c 100644 --- a/lib/Analysis/CGSCCPassManager.cpp +++ b/lib/Analysis/CGSCCPassManager.cpp @@ -619,6 +619,14 @@ LazyCallGraph::SCC &llvm::updateCGAndAnalysisManagerForFunctionPass( AM.invalidate(*C, PA); } auto NewSCCIndex = RC->find(*C) - RC->begin(); + // If we have actually moved an SCC to be topologically "below" the current + // one due to merging, we will need to revisit the current SCC after + // visiting those moved SCCs. + // + // It is critical that we *do not* revisit the current SCC unless we + // actually move SCCs in the process of merging because otherwise we may + // form a cycle where an SCC is split apart, merged, split, merged and so + // on infinitely. if (InitialSCCIndex < NewSCCIndex) { // Put our current SCC back onto the worklist as we'll visit other SCCs // that are now definitively ordered prior to the current one in the