similar to: [LLVMdev] Using multiple ExecutionEngines for better parallelism?

Is is possible since LLVM 2.7 to create multiple ExecutionEngine in the same process. Olivier. On Thu, Oct 7, 2010 at 6:41 PM, George Brewster <g at brewster.org> wrote: > Hi, > I'm working on an application that compiles using LLVM from multiple > threads. Currently, I'm doing this using one ExecutionEngine, but I've > observed that this does not seem to scale

Hello everybody, I'm pretty new to LLVM programming, so if this answer is pretty simple, I apologize in advance. We are working with the released LLVM 1.9. Say you have a class called CompiledProgram which is designed to contain our Module and (potentially) our ExecutionEngine(s). In particular, I would like to have an ExecutionEngine for running our program natively and another for

Hi! ExecutionEngine::addModule seems the method I have to use when I want to dynamically load snippets of code (e.g. containing a function) and execute them. I wonder why ExecutionEngine::create is only available with an initial module. I'd like to create an empty ExecutionEngine (i.e. without module) and then later use addModule. Is it possible do add such a method or can the pointer to

Right now, on X86, creating multiple ExecutionEngines in the same process causes an assertion. If it's supposed to always be a singleton, should there be a way to get the process's ExecutionEngine instance? This would, among other things, allow "lli" to execute bitcode that itself uses the ExecutionEngine.

On Oct 8, 2009, at 9:19 AM, Kenneth Uildriks wrote: > Right now, on X86, creating multiple ExecutionEngines in the same > process causes an assertion. > Yes. This is by design. > If it's supposed to always be a singleton, should there be a way to > get the process's ExecutionEngine instance? > I can't see why. You could make a server to process llvm code. >

Hi all, Sorry for the somewhat off-topic post, but I haven't come up with a good answer to this question yet. MDS did a port of Vorbis to the Philips TriMedia processors. Others have taken that port and extended/fixed it a bit. We provide the code to anyone who asks, but at this point we think it would be better off in some sort of public repository so that patches can be maintained,

Just curious. In the two most recent releases of CentOS 7 AltArch i386 there has not been made available a DVD iso (or the live ones) alongside NetInstall/Minimal/Everything. Any plans to make available the DVD variation for the current or future releases? For older 32-bit hardware, it can be nice to be able to burn a single layer DVD. Thanks for your time, -Brendan

> Now to compare it in detail with the much smaller program I've got and > maybe I'll figure out what's wrong with my call to > ExecutionEngine::create. That call is perfectly valid, actually. It works for me when linked with: g++ -o b b.o `llvm-config --ldflags` `llvm-config --libs engine jit` Cheers, -Mahadevan.

On Tue, 10 Jun 2008 07:07:35 +0530, Mahadevan R wrote: >> Now to compare it in detail with the much smaller program I've got and >> maybe I'll figure out what's wrong with my call to >> ExecutionEngine::create. > > That call is perfectly valid, actually. It works for me when linked > with: > > g++ -o b b.o `llvm-config --ldflags` `llvm-config --libs

Hi There, We want to disable all ExecutionEngine JIT/MCJIT tests (llvm/unittests/ExecutionEngine) for Hexagon. I have been looking into the test framework but haven't quite figured out how to turn them off. We cross compile Hexagon on X86 and are not interested in JIT support. Thanks, Jyotsna -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux

Given: typedef MyClass* (*jit_fn_ptr_type)(); MyClass* set_fn( llvm::Function *fn ) { // create an ExecutionEngine 'exec' ... jit_fn_ptr_type fn_ptr = (jit_fn_ptr_type)exec->getPointerToFunction( fn ); return fn_ptr(); } After I call getPointerToFunction() to obtain the pointer to the JIT'd function and fun the function (that will produce an instance of MyClass on the

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,

What does it mean when ExecutionEngine::create returns 0? Here's a simplified example: #include "llvm/Module.h" #include "llvm/ExecutionEngine/ExecutionEngine.h" main() { llvm::Module * module = new llvm::Module("the module"); llvm::ExecutionEngine *ee = llvm::ExecutionEngine::create(module); fprintf(stdout, "pointer is %x.\n", ee); } I

I wrote a little OS X app to assemble some LLVM (human-readable) code and run it. Unfortunately, my ExecutionEngine won't create. Just comes back NULL. This is the code that builds it: http://pastebin.com/8cexgPj7 This is the code it seems to successfully assemble, but it can't build the ExecutionEngine. You can see I tried several different ways of building it.

Hi Paul, I'm surprised to hear that you aren't seeing any adverse effects. As I understand it, the memory for the function pointer returned by getPointerToFunction is owned by the JITMemoryManager which was used in creating the ExecutionEngine. In the case of the legacy JIT engine, the JITMemoryManager is owned by the JITEmitter which in turn is owned by the JIT ExecutionEngine. In the

Hi Jyotsna, Currently there's a preprocessor trick that prevents llvm/unittests/ExecutionEngine/MCJIT tests from running on architectures and operating systems that are known to fail. Specifically, check out the functions OSSupportsMCJIT() and ArchSupportsMCJIT() functions in unittests/ExecutionEngine/MCJIT/MCJITTestBase.h, and the corresponding macro SKIP_UNSUPPORTED_PLATFORM that is used

Hendrik Boom-2 wrote: > > On Tue, 10 Jun 2008 07:07:35 +0530, Mahadevan R wrote: > >>> Now to compare it in detail with the much smaller program I've got and >>> maybe I'll figure out what's wrong with my call to >>> ExecutionEngine::create. >> >> That call is perfectly valid, actually. It works for me when linked >> with:

On Oct 26, 2012, at 12:59 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > In either case, deleting the ExecutionEngine should result in the JITMemoryManager being deleted and therefore also the memory in which the JITed functions are contained. > > I think it's entirely possible that you just aren't seeing a problem because that memory hasn't been

Dear LLVM-Mailing-List, I'm using the llvm::EngineBuilder to create an instance of the llvm::ExecutionEngine, I then JIT my code, take the addresses I need and delete the llvm::ExecutionEngine. But now I started to wonder, if I could reuse that instance for a new module again? I first tried calling llvm::EngineBuilder without setting a Module, I planned to add it later - but when I do this

On Jan 8, 2013, at 13:55 , "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > You need to include 'llvm/ExecutionEngine/JIT.h' (or 'llvm/ExecutionEngine/JIT.h' if you want that engine) from your main file. Including that file forces the JIT static constructor to be linked into your executable. Without it, the JIT static constructor gets optimized out and