[PATCH] D15701: Refactor inline costs analysis by removing the InlineCostAnalysis class

Chandler Carruth via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 22 11:37:11 PST 2015


chandlerc added inline comments.

================
Comment at: lib/Transforms/IPO/InlineSimple.cpp:65
@@ -60,1 +64,3 @@
+private:
+  TargetTransformInfoWrapperPass *TTIWP;
 };
----------------
eraman wrote:
> chandlerc wrote:
> > You can actually make TTI the member instead of the wrapper pass.
> I'm confused. Isn't the returned TTI dependent on the function? If I make TTI a member, how do I get the TTI for the callee in getInlineCost without calling getAnalysis on TTI wrapper pass ?
Quite right. Sorry for the noise!

================
Comment at: lib/Transforms/IPO/InlineSimple.cpp:104-105
@@ -97,3 +103,4 @@
 bool SimpleInliner::runOnSCC(CallGraphSCC &SCC) {
-  ICA = &getAnalysis<InlineCostAnalysis>();
+  if (!TTIWP)
+    TTIWP = &getAnalysis<TargetTransformInfoWrapperPass>();
   return Inliner::runOnSCC(SCC);
----------------
eraman wrote:
> chandlerc wrote:
> > You want to replace this on every run rather than checking it on each run. Look for other places where we cache a TTI pointer. You should also leave it uninitialized in the constructor so we get an MSan error if we reach code without the run call happening first.
> I didn't think about the MSan interaction and it now makes sense to remove the initialization and hence can't do the if (!TTIWP)... . I am curious if there is any other reason to avoid this pattern.
It doesn't happen much in-tree, but the pass manager supports running multiple modules through a single pass instance, and it is conceivable that they would have different TTI wrapper passes. Not likely, and not practically reproducible, but the pattern is designed to handle cases where the analysis might not be valid to cache from run to run.


Repository:
  rL LLVM

http://reviews.llvm.org/D15701





More information about the llvm-commits mailing list