search for: getinlinecost

...pt -lm -o llvm_parser [197.parser]$ opt -inline -inline-threshold=200 < llvm_parser.bc | llc -march=c > parser_inline.c llc: bytecode didn't read correctly. Does opt call Transform/IPO/InlineSimple to do inlining ? as I added instrumentation into it, I found: 1) getInlineCost() is called when doing llvm-gcc (without the -disable* flags) 2) getInlineCost() is not called when doing opt does the .bc code emitted by llvm-gcc carry inlining cost info ? otherwise, how does opt do inlining without the cost info ? thanks, --Long Misha Brukman wrote: On Thu, Jul 07, 2005 a...

...inline.c llc: bytecode didn't read > correctly. This should work, what does opt print? Can you send me [off list] the llvm_parser.bc file? > Does opt call Transform/IPO/InlineSimple to do inlining? Yes. > as I added instrumentation into it, I found: > 1) getInlineCost() is called when doing llvm-gcc (without the -disable* > flags) Yes, by default llvm-gcc does optimization, including inlining. > 2) getInlineCost() is not called when doing opt I assume that this is because opt is crashing or something (which is why LLC complains). Please send me the ....

I am using llvm for source-to-source inlining. So I did: % llvm-gcc file_a.c file_b.c ... file_n.c -o file % opt -inline -inline-threshold=1000 < file.bc | llc -march=c > outfile.c Can anyone tell me how llvm determines if a function should be inlined, and what roll does "inline-threshold" play ? (Does the example mean that if the function body has fewer than 1000 instructions,

...The LLVM inliner structure is implemented in llvm/lib/Transforms/IPO/Inliner.cpp which is a base implementation. There, you can see that -inline-threshold is a switch that provides value to InlineLimit which is used to initialize InlineThreshold member variable. This is compared with the output of getInlineCost() which is a virtual function. Currently, the inliner implemented in LLVM is InlineSimple.cpp in the same directory, which adds cost to functions if they have recursive calls, allocas, and other features, but at the end, you'll notice that it weighs each instruction as 5 with each basic block...

...uency information in inliner. As of now, it seems that inliner can exploit the information only when profile data is available. However, instructions such as __builtin_expect may set branch weight metadata as well, which is useful for inliner. I think this problem can be addressed by letting llvm::getInlineCost function to use BlockFrequencyAnalysis regardless of availability of profile data, and making CallAnalyzer::updateThreshold to use callsite frequency instead of callsite count. Is there a reason that we allow inliner to use block frequency information only when profile data is given? Thanks, Taewo...

...ating the driver code. > > Again, this is a trivial amount of code. I don't agree. > Giving passes the ability to modify the heuristics used by the > inliner would significantly dwarf this in both amount of code and > complexity. Again, I don't agree. I looked at the getInlineCost(const CallSite& CS) function. It has a dozen or more embedded constants in it. If those used symbolic constant indexes into a cost table, any tool could influence the heuristics simply by changing the values in the table, which (it seems to me) would be simple and intuitive. > &gt...

Long Fei wrote: > > I am investigating some inlining issue, so I did > > llvm-gcc aaa.c bbb.c ... nnn.c -o output > opt -inline -inline-threshold=xxx < output.bc | llc -march=c > > output_inline.c I am unsure of whether the LLVM GCC frontend does any inlining. However, I do know that your methods above run the LLVM inlining pass, albeit indirectly. If you use

...ial amount of code. > > > I don't agree. > > >> Giving passes the ability to modify the heuristics used by the >> inliner would significantly dwarf this in both amount of code and >> complexity. > > > Again, I don't agree. I looked at the getInlineCost(const CallSite& > CS) function. It has a dozen or more embedded constants in it. If > those used symbolic constant indexes into a cost table, any tool could > influence the heuristics simply by changing the values in the table, > which (it seems to me) would be simple and...

I am investigating some inlining issue, so I did llvm-gcc aaa.c bbb.c ... nnn.c -o output opt -inline -inline-threshold=xxx < output.bc | llc -march=c > output_inline.c 1) I noticed that even if I set xxx to 0 or even a very small negative number, many functions are eliminated. I am wondering if these functions are inlined by the frontend, or identified as deadcode. For instance,

Hi Alastair, > Forgive my confusion, but I can't help notice that LangRef states: > > Globals with "linkonce" linkage are merged with other globals of the same name when linkage occurs. This is typically used to implement inline functions, templates, or other code which must be generated in each translation unit that uses it. Unreferenced linkonce globals are allowed to be

Hi Duncan- Forgive my confusion, but I can't help notice that LangRef states: Globals with "linkonce" linkage are merged with other globals of the same name when linkage occurs. This is typically used to implement inline functions, templates, or other code which must be generated in each translation unit that uses it. Unreferenced linkonce globals are allowed to be discarded. Why

On Wed, 15 Mar 2006, Vikram S. Adve wrote: >> Why can't the compiler pass just call InlineFunction(CallSite) on the >> callsite it wants inlined? The only way that can fail is if LLVM cannot >> ever inline the call (e.g. it uses varargs). > In some cases, that would be fine. But in other cases: > (1) It cannot "un-inline" any function that was previously

...>> >> I don't agree. >> >> >>> Giving passes the ability to modify the heuristics used by the inliner >>> would significantly dwarf this in both amount of code and complexity. >> >> >> Again, I don't agree. I looked at the getInlineCost(const CallSite& CS) >> function. It has a dozen or more embedded constants in it. If those used >> symbolic constant indexes into a cost table, any tool could influence the >> heuristics simply by changing the values in the table, which (it seems to >> me) woul...

On Mar 15, 2006, at 10:04 AM, Chris Lattner wrote: > On Wed, 15 Mar 2006, Vikram S. Adve wrote: >> [I've changed the subject to make this a new thread.] >> >> While all of this makes sense to me, note that Markus and John >> were asking about different situations. Markus was asking about >> user-written source code. John was asking about a compiler pass

...llee) that will be examined for inlining has a corresponding InlineReportFunction in the map. (The map MCS is also updated in a similar way, but only when a Function is actually inlined.) The Inliner determines if a CallSite should be inlined by first calling Inliner::ShouldInline(). This calls getInlineCost() which returns an InlineCost, which now includes the reason the call site should or should not be inlined. This reason, as well and costs and threshold from the InlineCost are stored in the InlineReportCallSite for the CallSite. Then Inliner calls the static function InlineCallPossible(). If the...

...this is a trivial amount of code. >> I don't agree. >>> Giving passes the ability to modify the heuristics used by the >>> inliner would significantly dwarf this in both amount of code >>> and complexity. >> Again, I don't agree. I looked at the getInlineCost(const >> CallSite& CS) function. It has a dozen or more embedded >> constants in it. If those used symbolic constant indexes into a >> cost table, any tool could influence the heuristics simply by >> changing the values in the table, which (it seems to me)...

...neFunction(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 can itself > contain calls to the runtime functions. So, at this step,...

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