search for: inlinecostanalysis

Hi, After r256521 - which removes InlineCostAnalysis class - I think there is no strong reason for InlineCost.cpp to be part of the Analysis library. Is it fine to make it part of TransformUtils? I submitted r266477 (which has now been reverted) that made Analysis depend on ProfileData in order to obtain ProfileSummary for the module, but there is...

...quot; >> <listmail at philipreames.com>, "David Li" <davidxl at google.com> >> Sent: Monday, April 18, 2016 2:39:49 PM >> Subject: Move InlineCost.cpp out of Analysis? >> >> >> Hi, >> >> >> After r256521 - which removes InlineCostAnalysis class - I think >> there is no strong reason for InlineCost.cpp to be part of the >> Analysis library. Is it fine to make it part of TransformUtils? >> > > Given that InlineCost is not really an analysis any longer, I think this is fine. Isn't it? It is not a pass, bu...

...quot; <davidxl at google.com> >> >> Sent: Monday, April 18, 2016 2:39:49 PM >> >> Subject: Move InlineCost.cpp out of Analysis? >> >> >> >> >> >> Hi, >> >> >> >> >> >> After r256521 - which removes InlineCostAnalysis class - I think >> >> there is no strong reason for InlineCost.cpp to be part of the >> >> Analysis library. Is it fine to make it part of TransformUtils? >> >> >> > >> > Given that InlineCost is not really an analysis any longer, I think >&g...

...llvm::InlineFunctionInfo ifi(0); > bool isInlined = llvm::InlineFunction(call, ifi, false); > Changed |= isInlined; > > Or, if you don't want to always inline the code, you can guard the > inlining after having used the inline analysis pass: > llvm::InlineCostAnalysis costAnalysis; > llvm::InlineCost cost = costAnalysis.getInlineCost(call, 42); /* 42 > is the threshold */ > if(cost.isAlways()) || (!cost.isNever() && (cost))) { > /* inlining goes here */ > } > > After this step, you have a problem. The inlined function...

...gt; >>> >> Sent: Monday, April 18, 2016 2:39:49 PM >>> >> Subject: Move InlineCost.cpp out of Analysis? >>> >> >>> >> >>> >> Hi, >>> >> >>> >> >>> >> After r256521 - which removes InlineCostAnalysis class - I think >>> >> there is no strong reason for InlineCost.cpp to be part of the >>> >> Analysis library. Is it fine to make it part of TransformUtils? >>> >> >>> > >>> > Given that InlineCost is not really an analysis any lo...

Thanks for the pointers. Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions? -- lg On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would say that the incompatibility is by design. Not

...gt; > >> > > > > > > > > > > >> Hi, > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> After r256521 - which removes InlineCostAnalysis class - I > > > > >> think > > > > > > > > > > >> there is no strong reason for InlineCost.cpp to be part of > > > > >> the > > > > > > > > > > >> Analysis library. Is it fine to make i...

TLDR - I have a runtime which expects to be able to inspect certain arguments to a function even if that argument isn't used within the callee itself. DeadArgumentElimination doesn't respect this today. I want to add an argument that records an argument to a call as live even if the value is known to be not used in the callee. My use case ----------------- What my runtime is doing

On Mon, Apr 18, 2016 at 3:20 PM Easwaran Raman <eraman at google.com> wrote: > On Mon, Apr 18, 2016 at 3:00 PM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <hfinkel at anl.gov> wrote: >> >>> >>> >>> ------------------------------ >>> >>>

...vision 187135) +++ lib/Transforms/IPO/InlineSimple.cpp (working copy) @@ -72,6 +72,10 @@ return new SimpleInliner(Threshold); } +Pass *llvm::createTinyFuncInliningPass() { + return new SimpleInliner(40); +} + bool SimpleInliner::runOnSCC(CallGraphSCC &SCC) { ICA = &getAnalysis<InlineCostAnalysis>(); return Inliner::runOnSCC(SCC); -------------- next part -------------- Index: include/clang/Frontend/CodeGenOptions.def =================================================================== --- include/clang/Frontend/CodeGenOptions.def (revision 187135) +++ include/clang/Frontend/CodeGenOpt...

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only