search for: jitctor

I found the following problem when I try to debug "target does not support mc emission" in linux (the same code executes OK in windows): Below is a snippet extracted from this method, if (UseMCJIT && ExecutionEngine::MCJITCtor) { ExecutionEngine *EE = ExecutionEngine::MCJITCtor(M, ErrorStr, JMM, OptLevel, AllocateGVsWithCode, TM); if (EE) return EE; } else if (ExecutionEngine::JITCtor) { ExecutionEngine *EE = ExecutionEngine::JITCtor(M...

...ll, I'm trying to bring an LLVM-based project that is working on Linux up on Win32. I am having problems with llvm::ExecutionEngine::create returning a NULL. I traced it to these lines: // Unless the interpreter was explicitly selected, try making a JIT. if (!ForceInterpreter && JITCtor) EE = JITCtor(MP, ErrorStr); // If we can't make a JIT, make an interpreter instead. if (EE == 0 && InterpCtor) EE = InterpCtor(MP, ErrorStr); JITCtor and InterpCtor are both NULL, so it's obvious why I'm getting back a NULL execution engine. I am pretty sure it...

...of mine, but I'm having issues when trying to compile the Kaleidoscope tutorial* under MSVC 2008. In particular, the problem is that in main() when this line is executed > // Create the JIT. > TheExecutionEngine = ExecutionEngine::create(TheModule); create returns null, because both JITCtor and InterpCtor are null. I found this comment in ExecutionEngine.h > // To avoid having libexecutionengine depend on the JIT and interpreter > // libraries, the JIT and Interpreter set these functions to ctor > pointers > // at startup time if they are linked in. > typedef E...

...utorial* under >> MSVC 2008. >> In particular, the problem is that in main() when this line is executed >> >>> // Create the JIT. >>> TheExecutionEngine = ExecutionEngine::create(TheModule); >>> >> create returns null, because both JITCtor and InterpCtor are null. >> I found this comment in ExecutionEngine.h >> > > Does it work if you add to the link command > /INCLUDE:_X86TargetMachineModule > > ? > > [snip] I tried linking the tutorial adding that command but JITCtor and InterpCtor are still n...

Hi, In ExecutionEngine.cpp, when the JIT or the Interpreter have not been linked in then EngineBuilder::create fails without setting ErrorStr. I've attached a patch to fix this. Warm Regards KS Sreeram -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ee-not-linked-in-msg.diff URL:

...aving issues when trying to compile the Kaleidoscope tutorial* under > MSVC 2008. > In particular, the problem is that in main() when this line is executed >> // Create the JIT. >> TheExecutionEngine = ExecutionEngine::create(TheModule); > create returns null, because both JITCtor and InterpCtor are null. > I found this comment in ExecutionEngine.h Does it work if you add to the link command /INCLUDE:_X86TargetMachineModule ? [snip] -- Oscar

I see very strange behaviour. I am linking to LLVMMCJIT and I #include MCJIT.h. I can see in the debugger that MCJIT::Register is being called. If I break in ExecutionEngine::create, I can see that UseMCJIT is true and ExecutionEngine::MCJITCtor is non-zero. Still at this point (lines after 481): if (UseMCJIT && ExecutionEngine::MCJITCtor) { ExecutionEngine *EE = ExecutionEngine::MCJITCtor(M, ErrorStr, JMM, AllocateGVsWithCode, TheTM.take()); if (EE) return EE; } else...

"Aaron Dwyer" <llvmification at gmail.com> writes: [snip] > JITCtor and InterpCtor are both NULL, so it's obvious why I'm getting > back a NULL execution engine. I am pretty sure it's because I'm > missing a few llvm .lib or .obj files. What is the set of llvm object > files needed at link time for Win32 on X86 JIT? This is what I use on...

...the constructor of the static variable static struct RegisterJIT { RegisterJIT() { JIT::Register(); } } JITRegistrator; in lib/ExecutionEngine/JIT/JIT.cpp is only called if either JIT.h or Interpreter.h is included. When they are not included, JIT::Register() is not called, and ExecutionEngine::JITCtor and ExecutionEngine::InterpCtor are both NULL, and ExecutionEngine::create() returns NULL. This is not caught by (in lli.cpp): if (!EE && !ErrorMsg.empty()) { std::cerr << argv[0] << ":error creating EE: " << ErrorMsg << "\n"; exit(1);...

On Jun 22, 2009, at 2:19 PM, Kasra wrote: > Hi, > > for some reason I could not get the machine code generator for x86 > working. The interpreter is the only thing that works, is there > anything that I am missing here? This recently changed. In your main program, please #include "llvm/ Target/TargetSelect.h" and call InitializeNativeTarget(); before setting up

Hi, for some reason I could not get the machine code generator for x86 working. The interpreter is the only thing that works, is there anything that I am missing here? -- Kasra -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090622/89dca208/attachment.html>

Hola Aaron, Just having that code didn't work since the linker still stripped it out, so I have that function called from the code in the system that actually is being used by our app. Kinda grubby, but I include: #include "llvm/lib/Target/X86/X86TargetMachine.h" Which is in the LLVM lib, not the LLVM inc directory. This little maneuver made our Mac builds really unhappy, so

Thanks for your response Chuck. >From this and the other responses to my question, it looks like I'm including all the right object files, so it must be something with Visual Studio stripping "dead" code. So, given your response Chuck, I have a few questions. First, what exactly is the code that VStudio seems to be stripping? I might be able to figure out how to prevent it

...aration in JIT, and use it in JIT::getPointerToFunction(...), in place of my 2606 mod, to effect the new cross module functionality in this new JIT derived class instance. A simple hack resolution of "resolve these methods" implies leveraging another include file to set ExecutionEngine::JITCtor while simultaneously handling JIT.cpp's static setting of this same variable. A better solution would be to redesign EngineBuilder to use say dlopen/dlload functionality to dynamically pull in the proper JIT derived class library. Anyway this is my 2 cents. > > What do you think ? Any...

Hi Garrison, I finally come back from holidays and take time to watch your patch. I must say that I largely prefer this version over the previous one ! I like the reuse of getLazyFunctionStub, but I don't know if the forceEmitFunctionStub is still needed ? I thought about JIT and modules, and I wonder if we don't need to take it another way. Now we can create multiples JIT. What if we

This is the second version of a patch, which I recently attached to bug 2606, whose original version was modified to reflect the lists comments. Also please note the comment at the end of this email, which basically questions whether this bug is really a bug. 1) To solve the foreign Module GlobalVariable problem, I modified JIT::getOrEmitGlobalVariable(...) to directly attempt to map a found

.../ExecutionEngine.cpp > =================================================================== > --- lib/ExecutionEngine/ExecutionEngine.cpp (revision 46612) > +++ lib/ExecutionEngine/ExecutionEngine.cpp (working copy) > @@ -34,7 +34,9 @@ > > ExecutionEngine::EECtorFn ExecutionEngine::JITCtor = 0; > ExecutionEngine::EECtorFn ExecutionEngine::InterpCtor = 0; > +ExecutionEngine::EERegisterFn > ExecutionEngine::ExceptionTableRegister = 0; > > + > ExecutionEngine::ExecutionEngine(ModuleProvider *P) : > LazyFunctionCreator(0) { > LazyCompilationDisabled = false;...

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL: