[LLVMdev] MCJIT

[Daniel Dunbar]

On Mon, May 14, 2012 at 12:25 PM, Jim Grosbach <grosbach at apple.com> wrote:
>
> On May 14, 2012, at 11:12 AM, Ashok Nalkund <ashoknn at qualcomm.com> wrote:
>
>> On 5/14/2012 10:40 AM, Ashok Nalkund wrote:
>>>>
>>>> Hm. OK, that's odd. It should change which constructor gets called in EngineBuilder::create()  (which is in lib/ExecutionEngine/ExecutionEngine.cpp). Are you perhaps calling setUseMCJIT(true) after having already called create()? Can you step through EngineBuilder::create() and see what's happening there?
>>>>
>>>> -Jim
>>>
>>> lli.cpp instantiates the builder, sets options/flags etc and then calls
>>> create(). In my driver, I have:
>>>> llvm::EngineBuilder(m_LLVMMod).setErrorStr(&engErr).setUseMCJIT(true).create();
>>>
>>> which is what you mentioned. I'll step through create() and check whats
>>> happening.
>>
>> My bad about MCJIT flag not being used (must have the code before I switched to trunk). It *IS* used and the MCJIT constructor is being invoked.
>>
>
> OK, cool. That's good news.
>
>> So I reverted my changes, and recompiled and ran lli, but it gives the error:
>>> LLVM ERROR: Inline asm not supported by this streamer because we don't have an asm parser for this target
>>
>> I add back the call to InitializeNativeTargetAsmParser() in lli.cpp, but compilation fails:
>
> Makes sense.
>
>>> make[4]: Leaving directory `/local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/build/tools/clang/tools/arcmt-test'
>>> /local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/build/tools/lli/Debug+Asserts/lli.o: In function `llvm::InitializeNativeTargetAsmParser()':
>>> /local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/llvm/include/llvm/Support/TargetSelect.h:149: undefined reference to `LLVMInitializeX86AsmParser'
>>> collect2: ld returned 1 exit status
>>
>> So I add back to lli/CMakeLists.txt:
>> < set(LLVM_LINK_COMPONENTS mcjit jit interpreter nativecodegen bitreader asmparser selectiondag)
>>> set(LLVM_LINK_COMPONENTS ${LLVM_TARGETS_TO_BUILD} mcjit jit interpreter nativecodegen bitreader asmparser selectiondag)
>>
>> lli/Makefile (a simple make invocation didnt seem to regenerate the Makefile):
>> <LINK_COMPONENTS := mcjit jit interpreter nativecodegen bitreader asmparser selectiondag
>>> LINK_COMPONENTS := all-targets mcjit jit interpreter nativecodegen bitreader asmparser selectiondag
>>
>
> It seems odd to me that this is required, but I'm not an expert on LLVM's build system, so that doesn't mean much. Daniel, what do you think?

Right, this shouldn't be required. The nativecodegen component is the
one which is supposed to make sure that X86 gets linked in.

 - Daniel

>
>
>> Compiles and runs till lli is unable to resolve an external symbol.
>>
>> In short, tools/lli/[lli.cpp,CMakeLists.txt] will need to be modified for MCJIT to be used in lli. No need to comment out the code in lib/Target/X86/X86CodeEmitter.cpp.
>>
>> Thanks for correcting me. Any hints on the external symbol resolution:
>>> LLVM ERROR: Could not resolve external global address: _ZNSt3__14coutE
>> which seems to be cout from the std lib.
>
> That's interesting. I would have expected a second leading underscore on that symbol. Perhaps not on your target? I suggest checking to see where that symbol (with or without the second '_') is defined and finding out which is expected. That'll give more information about whether this is failing because the symbol lookup isn't looking in the right places or because it's looking for the wrong thing.
>
> -Jim
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev