similar to: [LLVMdev] JIT: Inlining introduces intrinsics.

Hello Eli. Eli Friedman <eli.friedman at gmail.com> writes: >> If I activate the Inliner pass: >> >>    Builder.Inliner = createFunctionInliningPass(Threshold); >> >> this is the result: >> >> LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! >> >> It happens on almost all my test

Óscar Fuentes <ofv at wanadoo.es> writes: >>> If I activate the Inliner pass: >>> >>>    Builder.Inliner = createFunctionInliningPass(Threshold); >>> >>> this is the result: >>> >>> LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! >>> >>> It happens on almost

On Tue, Nov 22, 2011 at 8:26 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > If I activate the Inliner pass: > >    Builder.Inliner = createFunctionInliningPass(Threshold); > > this is the result: > > LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! > > It happens on almost all my test cases, even at -O0. >

On 11/24/2011 05:52 PM, Óscar Fuentes wrote: > Óscar Fuentes<ofv at wanadoo.es> writes: > >>>> If I activate the Inliner pass: >>>> >>>> Builder.Inliner = createFunctionInliningPass(Threshold); >>>> >>>> this is the result: >>>> >>>> LLVM ERROR: Program used external function

Is there a way to set how aggressive the inliner pass (createFunctionInliningPass) without going through the command line interface? Is there any reason InlineLimit isn't an argument to the createFunctionInliningPass function? Thanks, Robert

On Mon, 7 Jan 2008, Robert Zeh wrote: > Is there a way to set how aggressive the inliner pass > (createFunctionInliningPass) without going through the command line > interface? Nope. Well, you could call cl::ParseCommandLine yourself (passing in a static array) like llvm-gcc does, but other than that "no". > Is there any reason InlineLimit isn't an argument to the

Hi! My llvm version is 3.0 release. I have a module generated by clang. When I optimize it, I first add an inlining pass (llvm::createFunctionInliningPass), then these passes: - own FunctionPass - llvm::createPromoteMemoryToRegisterPass - llvm::createInstructionCombiningPass - llvm::createDeadInstEliminationPass - llvm::createDeadStoreEliminationPass - new llvm::DominatorTree() - new

Hi, We want to apply the deepest possible inlining to the target code. Looks like builder.Inliner = createFunctionInliningPass(2000); does the sufficient inlining, but what would be the best value for threshold here? Apparently, builder.Inliner = createFunctionInliningPass(numeric_limits<int>::max()); gives less inlining, that 2000. Thanks, - D.

Nick Lewycky <nicholas at mxc.ca> writes: >> For the record: the cause is that the JIT compiler calls >> getPointerToFunction for all defined functions on the module > > Intrinsics are only declared, they have no definition. The JIT may > codegen functions which call those intrinsics, but that shouldn't > cause any problems, as codegen should handle them. Are

Hi Jochen, > My llvm version is 3.0 release. > I have a module generated by clang. When I optimize it, I first add an > inlining pass (llvm::createFunctionInliningPass), then these passes: > - own FunctionPass > - llvm::createPromoteMemoryToRegisterPass > - llvm::createInstructionCombiningPass > - llvm::createDeadInstEliminationPass > - llvm::createDeadStoreEliminationPass

Hi! I'm using clang/llvm 3.0 release and I have a module that is generated by clang with some functions declared as inline. after inlining (llvm::createFunctionInliningPass) I'd like to remove the functions that were inlined. how can this be done? surprisingly they are removed if a print pass (llvm::createPrintModulePass) is present. is there an explanation for this? -Jochen

I think this will do the trick: -------------- next part -------------- A non-text attachment was scrubbed... Name: inliner.patch Type: application/octet-stream Size: 2654 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080111/18fad7e6/attachment.obj> -------------- next part -------------- Robert On Jan 8, 2008, at 3:26 PM, Chris Lattner wrote:

The existing lifetime start/end is not very well defined (by spec, or by code) in what it means, so you could have nested lifetime markers if you wanted. If you made the spec well-defined, they would be meaningful (for loops, etc). There are a number of open bugs/complaints about lifetime markers and the fact that the scope is not well defined (the spec says "This intrinsic indicates that

Chris added alloca merging in the inliner a looooong time ago, 2009. The reason he added it was because at the time we didn't do stack coloring and without it we had serious stack size problems in LLVM. Since then, a few rather important things have changed: - We have reasonably powerful stack coloring support in the backend based on lifetime markers - Clang (the primary frontend I'm

Hi, I'm Ryo Ota. I'm using LLVM 3.8.1. I have a quesion about inlining function in C++ API. I'd like to inline some functions in a module in the same way as `opt -inline` command. But my C++ code didn't work what I want to do. For example, by using `opt -inline` command,`main.ll` is converted into the `inlined.ll`(`opt` command worked what I want to do) [main.ll (Not inlined)]

Hello, I trying TSAN on Darwin on LLVM itself (sanitizing multi-threaded ThinLTO link). However I see two main issues on my debug build: 1) Statistics: the pre/post increment is not safe, it seems to be acknowledge in the code itself: // FIXME: This function and all those that follow carefully use an // atomic operation to update the value safely in the presence of // concurrent

RFC: Inlining Report Motivation Making good inlining choices while optimizing an application is often key to achieving optimal performance. While the compiler's default inlining heuristics sometimes provide great out-of-box results, optimal performance is sometimes achieved only after varying the settings of certain compiler options related to inlining or adding "always_inline" or

Sanitizer passes really should not run before the inliner. For example, ASan moves all allocas into a "mega-alloca" to obtain fixed frame layout for reporting purposes. It also inserts a fake stack check in the function prologue which will get duplicated (but will probably still work) after inlining. MSan removes readnone/readonly from all functions because they all update shadow which

Ok, well, I seem to have pinpointed the cause of the problem more accurately. I'm running some optimization passes on my module after I compile each function in my scripting language (functions can be compiled at various times, when scripts are loaded). Now it seems these optimization passes will prune some of the native C++ functions I'm registering in my module (the functions that

Nyx wrote: > Ok, well, I seem to have pinpointed the cause of the problem more accurately. > I'm running some optimization passes on my module after I compile each > function in my scripting language (functions can be compiled at various > times, when scripts are loaded). Now it seems these optimization passes will > prune some of the native C++ functions I'm registering in