JIT: Inlining introduces intrinsics.

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? Otherwise, I
have no clue how you could trigger that error.

-Eli

Hello Eli.

Eli Friedman <eli.friedman@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@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.)

Óscar Fuentes<ofv@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

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.

Nick

  before

Nick Lewycky <nicholas@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 you suggesting that there should be no problem with this idiom so it
is a LLVM bug?

Óscar Fuentes wrote:

Nick Lewycky<nicholas@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 you suggesting that there should be no problem with this idiom so it
is a LLVM bug?

Yes.