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 cases, even at -O0. >> >> This JIT compiler does the same as `opt' wrt optimization passes. I'm >> using a LLVM snapshot from approx 4 months ago. > > Yes, the inliner does introduce llvm.lifetime.start... and CodeGen > should eliminate it. Are you using the interpreter?No, I'm not using the interpreter. Is there any condition that prevents CodeGen from removing those intrinsics?> Otherwise, I have no clue how you could trigger that error.Ok, I'll investigate a bit further. Thanks.
Ó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 all my test cases, even at -O0. >>> >>> This JIT compiler does the same as `opt' wrt optimization passes. I'm >>> using a LLVM snapshot from approx 4 months ago. >> >> Yes, the inliner does introduce llvm.lifetime.start... and CodeGen >> should eliminate it. Are you using the interpreter? > > No, I'm not using the interpreter. Is there any condition that prevents > CodeGen from removing those intrinsics? > >> Otherwise, I have no clue how you could trigger that error. > > Ok, I'll investigate a bit further. Thanks.For the record: the cause is that the JIT compiler calls getPointerToFunction for all defined functions on the module before executing the generated code: for (Module::iterator it = M->begin(); it != M->end(); ++it) EE->getPointerToFunction(&*it); Function *mf = M->getFunction("mainf"); EE->runFunction(mf, args); This is done for establishing a clear distinction between compile time and execution time (for benchmarking purposes) and for speeding up the whole process, as it is quite faster to generate all code in advance than to JIT it as it is found (ExecutionEngine::DisableLazyCompilation does not the same thing, as a large part of the code on the real-life applications where this compiler works is reachable only through pointers.)
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 'llvm.lifetime.start' which could not be resolved! >>>> >>>> It happens on almost all my test cases, even at -O0. >>>> >>>> This JIT compiler does the same as `opt' wrt optimization passes. I'm >>>> using a LLVM snapshot from approx 4 months ago. >>> >>> Yes, the inliner does introduce llvm.lifetime.start... and CodeGen >>> should eliminate it. Are you using the interpreter? >> >> No, I'm not using the interpreter. Is there any condition that prevents >> CodeGen from removing those intrinsics? >> >>> Otherwise, I have no clue how you could trigger that error. >> >> Ok, I'll investigate a bit further. Thanks. > > For the record: the cause is that the JIT compiler calls > getPointerToFunction for all defined functions on the moduleIntrinsics 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. Nick before> executing the generated code: > > for (Module::iterator it = M->begin(); it != M->end(); ++it) > EE->getPointerToFunction(&*it); > > Function *mf = M->getFunction("mainf"); > > EE->runFunction(mf, args); > > This is done for establishing a clear distinction between compile time > and execution time (for benchmarking purposes) and for speeding up the > whole process, as it is quite faster to generate all code in advance > than to JIT it as it is found (ExecutionEngine::DisableLazyCompilation > does not the same thing, as a large part of the code on the real-life > applications where this compiler works is reachable only through > pointers.) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev