[llvm] [Uniformity] Remove dependence on CycleInfo in old pass manager (PR #76011)

Matt Arsenault via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 21 23:13:42 PST 2023


================
@@ -152,26 +152,34 @@ UniformityInfoWrapperPass::UniformityInfoWrapperPass() : FunctionPass(ID) {
 INITIALIZE_PASS_BEGIN(UniformityInfoWrapperPass, "uniformity",
                       "Uniformity Analysis", true, true)
 INITIALIZE_PASS_DEPENDENCY(DominatorTreeWrapperPass)
-INITIALIZE_PASS_DEPENDENCY(CycleInfoWrapperPass)
 INITIALIZE_PASS_DEPENDENCY(TargetTransformInfoWrapperPass)
 INITIALIZE_PASS_END(UniformityInfoWrapperPass, "uniformity",
                     "Uniformity Analysis", true, true)
 
 void UniformityInfoWrapperPass::getAnalysisUsage(AnalysisUsage &AU) const {
   AU.setPreservesAll();
   AU.addRequired<DominatorTreeWrapperPass>();
-  AU.addRequiredTransitive<CycleInfoWrapperPass>();
   AU.addRequired<TargetTransformInfoWrapperPass>();
 }
 
 bool UniformityInfoWrapperPass::runOnFunction(Function &F) {
-  auto &cycleInfo = getAnalysis<CycleInfoWrapperPass>().getResult();
   auto &domTree = getAnalysis<DominatorTreeWrapperPass>().getDomTree();
   auto &targetTransformInfo =
       getAnalysis<TargetTransformInfoWrapperPass>().getTTI(F);
 
   m_function = &F;
-  m_uniformityInfo = UniformityInfo{domTree, cycleInfo, &targetTransformInfo};
+
+  // FIXME: CycleInfo is a transitive dependency for UniformityInfo, and we
+  // would have liked to say that CycleInfo is also preserved whenever
+  // UniformityInfo is preserved. But some passes like
+  // AMDGPUUnifyDivergentExitNodes do not update cycle membership and lists of
+  // cycle exits, since that facility is not available. The end result is that
+  // we cannot declare CycleInfo as a transitive depedency for UniformityInfo.
+  // Instead we recompute CycleInfo on demand. This is OK because it is rarely
+  // needed, and only affects the old pass manager.
+  m_cycleInfo.clear();
+  m_cycleInfo.compute(F);
+  m_uniformityInfo = UniformityInfo{domTree, m_cycleInfo, &targetTransformInfo};
----------------
arsenm wrote:

I'd expect the same sort of CFG transforms to invalidate both, so intuitively to me it makes sense they would always be paired 

https://github.com/llvm/llvm-project/pull/76011


More information about the llvm-commits mailing list