search for: costanalysi

...m::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...

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

The loop vectorized does not estimate the cost of vectorization by looking at the IR you list below. It does not vectorize and then run the CostAnalysis pass. It estimates the cost itself before it even performs the vectorization. The way it works is that it looks at all the scalar instructions and asks: What is the cost if I execute the scalar instruction as a vector instruction. Therefore, it will not consider any of the insert/extractelement i...

On 4 February 2013 18:25, Arnold Schwaighofer <aschwaighofer at apple.com>wrote: > For cases where this approach breaks really badly we could consider adding > a specialized api or parameters (like the type of a user/use). But we > should do so only as a last resort and backed by actual code that would > benefit from doing so. > Very sensible, more or less what I had in