similar to: [LLVMdev] Correct way of JITing multiple modules?

Hi, I'm seeing rather high memory usage from LLVM and I'd like to track down what I'm doing to cause it. My application is a simple web application server that compiles web pages with embedded script to bitcode and compiles them with the JIT on demand. I've taken tools/lli.cpp as a starting point and extended it to load additional modules. However, if I load successive pages and

On Fri, Sep 9, 2011 at 1:36 PM, Graham Wakefield <wakefield at mat.ucsb.edu> wrote: > Hi there, > > I'm having trouble getting ExecutionEngine->runStaticConstructorsDestructors(module, true) to actually trigger static destructors in my code. The static constructors however do get called. > > I don't know if this is an LLVM or Clang issue, from looking at the IR (see

Hi there, I'm having trouble getting ExecutionEngine->runStaticConstructorsDestructors(module, true) to actually trigger static destructors in my code. The static constructors however do get called. I don't know if this is an LLVM or Clang issue, from looking at the IR (see below) it looks like the destructor is being tied to cxa_atexit, and I wonder if that is not called by

Thank you Alex, I went and implemented a solution along those lines. It works well. It may be worth mentioning static constructors in the Kaleidoscope tutorial. Cheers, Daniele ________________________________________ From: Alex Denisov [1101.debian at gmail.com] Sent: 15 March 2019 08:07 To: Daniele Vettorel Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Static constructors with ORC

Hi Andy, I added the runStaticConstructorsDestructors and FindFunctionNamed functions. This also required making them virtual in EE.h. I'm not sure about FindFunctionNamed: In addition to searching finalized modules, should it search Added and Loaded modules? If it finds a Function in these, should it compile and finalize it before returning the Function* ? I modified the implementation

Hi all, Is there way to tell the ORC JIT infrastructure to run the static constructors in a module that has just been compiled? I see that the ExecutionEngine class has a runStaticConstructorsDestructors function, is that relevant with ORC and if so, how should it be accessed? Thanks, Daniele -------------- next part -------------- An HTML attachment was scrubbed... URL:

Greetings, LLVM wizards. I am using clang to compile a C++ module, and an ExecutionEngine (MCJIT) to execute a function it defines. That works (or pretends to). However, if I call the module's constructors first: exec_engine->runStaticConstructorsDestructors(false); exec_engine->runFunctionAsMain(function, argvec, NULL); execution still works, but my program crashes when it exits, in

On Alex's advice I am switching from MCJIT to the Orc API to compile and execute functions. Starting from the new clang-interpreter example in the source code (top of the tree!), I am able to execute my functions all right... as long as there are no constructors and destructors to call. My question: is there a simple way, with the Orc API, to run a module's constructors and destructors? I

On May 12, 2008, at 02:58, Mahadevan R wrote: >> Consider the case where a function creates and populates a Module, >> stuffs it in an ExistingModuleProvider for the JIT, then returns >> the ModuleProvider, dropping direct reference to the Module. >> (ModuleProvider takes ownership of the Module.) I presume that your >> Python object is under the impression

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

When OrcMCJITReplacement is given a new module, it asks for the module's constructors, gives them names like $static_ctor.0, $static_ctor.1, etc., and saves the mangled names in a map. Later, to execute them, it uses runViaLayer(), which looks for those symbol names in the given JIT layer. Could one not simply execute the constructors straight away, rather than naming them and looking them up

> Consider the case where a function creates and populates a Module, stuffs it > in an ExistingModuleProvider for the JIT, then returns the ModuleProvider, > dropping direct reference to the Module. (ModuleProvider takes ownership of > the Module.) I presume that your Python object is under the impression it > owns the Module; when that goes out of scope, its refcount goes to zero

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>

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

Hi Yaron, Overall this looks great. There are a couple of remaining holes. Specifically, MCJIT inherits implementations of the FindFunctionNamed and runStaticConstructorsDestructors methods from ExecutionEngine which use the old Modules vector, so you'll need to override these in MCJIT. (The implementations are fairly trivial.) Beyond that I just have a couple of questions. First,

Helps to send to list: On Tue, Nov 2, 2010 at 1:00 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Tue, Nov 2, 2010 at 12:51 PM, Salomon Brys <salomon.brys at gmail.com> wrote: >> Hi everyone ! >> I am very new to LLVM and intent to use it in a research project. >> I have a problem with the interpreter: I have a simple compiler that >> generates LLVM

Many thanks for the sample code, Alex. In the end I did it the same way OrcMCJITReplacement does it. Constructors and destructors are called and, thanks to LocalCXXRuntimeOverrides, the program does not crash on exit! But it does seem like there should be a simpler way; the learning curve is steep... Geoff On Thu, 21 Jun 2018 at 12:28, Alex Denisov <1101.debian at gmail.com> wrote: >

On May 10, 2008, at 05:44, Mahadevan R wrote: > I'd like to announce the availability of Python bindings for LLVM. > > It is built over llvm-c, and currently exposes enough APIs to build > an in-memory IR (and dump it!). It needs LLVM 2.3 latest and Python > 2.5 (2.4 should be sufficient, but I haven't tested). Tested only on > Linux/i386. > > Would love to

The use case is to create a module A, JIT from it, then extend the module with new code (create a new module B and use Linker::LinkModules() to merge into A, and be able to JIT the new symbols). This appears to work ok, except that static constructors are giving me a headache. Generally, I start like this: Create module A (e.g. via Clang, LLVM API etc.) EE->addModule(A);

Hi all, I think there is still too few docs/samples for those, who'd like to write JIT-based interpreters. Today, the real examples to learn from are rather: - lli.cpp - ModuleMaker.cpp - Stacker which is still unfortunatelly not that much about JITing :( Well, what I am going to sell: What about very small JIT-based example similar to ModuleMaker? I mean example, where, say, two