similar to: [LLVMdev] [PATCH] Set error message if JIT/Interpreter not linked in.

Hello all, 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

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,

Hi, I'm investigating adding LLVM JIT support to a project 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

Óscar Fuentes ha scritto: > Carlo Alberto Ferraris <cafxx at strayorange.com> writes: > >> Hi, >> I'm investigating adding LLVM JIT support to a project 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 >>

Carlo Alberto Ferraris <cafxx at strayorange.com> writes: > Hi, > I'm investigating adding LLVM JIT support to a project 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 =

"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 MinGW. It

On Mon, Jun 22, 2009 at 4:43 PM, Chris Lattner <clattner at apple.com> wrote: > > 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

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>

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 =

Hi folks, The llvm c-api contains LLVMBuildNeg but not LLVMBuildFNeg. I've attached a simple patch which adds LLVMBuildFNeg. I know it's a little late, but it'll be great if this can be added for the 2.6 release. I'm asking because I'd like to add support for FNeg in llvm-py too, and it'll be hard to do that if llvm 2.6 doesn't have it. Regards KS Sreeram

Hello, Thanks for the patch. I applied it on trunk. I suspect it's too late for 2.6 though. Dan On Sep 28, 2009, at 1:38 PM, KS Sreeram wrote: > Hi folks, > > The llvm c-api contains LLVMBuildNeg but not LLVMBuildFNeg. I've > attached a simple patch which adds LLVMBuildFNeg. > > I know it's a little late, but it'll be great if this can be added > for

Hi folks, I've updated LLVM-py to work with the latest LLVM. The patch is available here: http://code.google.com/p/llvm-py/issues/detail?id=25 The patch can be applied with the command: patch -p0 < patchfile Warm Regards KS Sreeram

Hi, Would it be possible to make the following slight change to ExecutionEngine::create()? I would like to be able to disable the automatic enumeration of loaded modules, and the subsequent searching for undefined symbols (using SearchForAddressOfSymbol). I propose adding an extra parameter to the function definition, defaulting to true. static ExecutionEngine *create(ModuleProvider *MP,

On Jul 22, 2009, at 5:23 PM, Chris Lattner wrote: > > On Jul 22, 2009, at 1:32 PM, Dan Gohman wrote: > >>>> >>>> - A null pointer is associated with no addresses. >>>> >>> >>> A null pointer in address space 0. >> >> I'm not fond of weird address-space semantics, but for consistency >> with what the optimizer is

Hi Rob, Can you comment on exactly what the problem is you want to solve? Is it a performance issue with LoadLibraryPermanently, or do you simply not want the external symbols to be resolved from within the JIT? - Daniel On Wed, Jul 22, 2009 at 11:22 PM, Evan Cheng<evan.cheng at apple.com> wrote: > > On Jul 22, 2009, at 9:43 PM, Rob Grapes wrote: > >> Hi, >> >>

On Jul 22, 2009, at 9:43 PM, Rob Grapes wrote: > Hi, > > Would it be possible to make the following slight change to > ExecutionEngine::create()? > > I would like to be able to disable the automatic enumeration of > loaded modules, and the subsequent searching for undefined symbols > (using SearchForAddressOfSymbol). > > I propose adding an extra parameter to

The patch looks good to me. But we cannot allow AllocateGVsWithCode to be initialized to be false yet. Can you add a mechanism to define the behavior when the JIT is created / initialized? Also, I am not crazy about this being moved to JITMemoryManager.h. This seems like implementation detail that should be kept hidden. + // If the PoisonMemory parameter is true, freed memory should be

Hi Daniel, In my case ExecutionEngine::create() loads 40 modules, then each time I try to resolve a symbol that I know is in a DLL that I supply, it looks through all 40 modules first. This is on Windows, so I get the following modules loaded: ntdll.dll, kernel32.dll, USER32.dll, GDI32.dll, SHELL32.dll, ADVAPI32.dll, RPCRT4.dll, Secur32.dll, msvcrt.dll, SHLWAPI.dll, ole32.dll, OLEAUT32.dll,

On Sep 24, 2009, at 11:04 PM, KS Sreeram wrote: > Hi folks, > > I've updated LLVM-py to work with the latest LLVM. > > The patch is available here: > http://code.google.com/p/llvm-py/issues/detail?id=25 > > The patch can be applied with the command: > patch -p0 < patchfile Very nice, but llvm-py is not in the llvm.org svn repo, you'll likely to have to