On 5/14/2012 10:28 AM, Jim Grosbach wrote:> > On May 14, 2012, at 10:21 AM, Ashok Nalkund<ashoknn at qualcomm.com> wrote: > >> On 5/14/2012 9:51 AM, Jim Grosbach wrote: >>> >>>>> >>>>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>>>> >>>> >>>> Do I need to enable anything at configure, my configure looks like this: >>>>> ../llvm/configure --enable-libffi --enable-targets=host-only --prefix=/local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/build/bin >>>> >>>> I added the enable-libffi when trying to figure out resolving external libs. >>>> >>> >>> >>> No, selecting MCJIT vs. the old JIT is done in the EngineBuilder. If you're using lli, you can pass -use-mcjit on the command line. If you're using your own driver, you can use the lli.cpp for a reference. >>> >>> -Jim >> >> Thats what I was pointed to earlier, and following that I set the flag in EngineBuilder.setUseMCJIT(true). I looked at the code of EngineBuilder, it saves the flag but the flag doesnt seem to be used anywhere. Am I missing something? > > 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? > > -Jimlli.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. thanks, ashok
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. 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 targetI add back the call to InitializeNativeTargetAsmParser() in lli.cpp, but compilation fails:> 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 statusSo 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 selectiondagCompiles 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__14coutEwhich seems to be cout from the std lib. tia, ashok
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?> 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