similar to: Memory usage with MCJit

+Lang for JIT things. On Sun, Jul 24, 2016 at 8:50 AM koffie drinker via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > I'm building a runtime that can jit and execute code. I've followed the > kaleidoscope tutorial and had a couple of questions. Basically I have a > pre-compiler that compiles the code to cache objects. These cached objects > are

Hi Koffie, I'd highly recommend switching to ORC from MCJIT. It is much more flexible when it comes to memory-management. 1. I took the approach of 1 execution engine with multiple modules (I'm not > removing modules once they have been added). During profiling, I noticed > that the memory usage is high with a lot of code. How can I reduce the > memory usage? Is one execution

I'm on llvm 3.8.1 and was wondering if there's a memory leak in the removeModule impl of mcjit. In the tutorial http://llvm.org/releases/3.8.1/docs/tutorial/LangImpl4.html a module is removed from the Jit by invoking removeModule. According to the tutorial: "Its API is very simple:: addModule adds an LLVM IR module to the JIT, making its functions available for execution;

Hi Kevin, Koffie, We will start migrating to ORC for next release, but for now, this release > invoke delete after remove right? MCJIT's removeModule method does not delete the module. You'll need to do that manually. OrcMCJITReplacement is a bug-for-bug compatible implementation of MCJIT using ORC components, so it does not free the memory either. Does this mean MCJIT is

Hi, I'm trying to speed up the JIT time with llvm (3.9.1). So far i've implemented the object cache, used FastISel and disabled optimizations. Jit time is still too slow for my purpose (I do have a lot of code to Jit). http://llvm.org/docs/ProgrammersManual.html#threads-and-the-jit states that we can invoke ExecutionEngine::getPointerToFunction() concurrently. This function was replaced

Hi, What other options do I have to reduce JIT time for large amount of code? - setting optimization level to none helps a lot - enabling FastISel doesn't seem to help much Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160812/f05d51fb/attachment.html>

HI Dibyendu, A single MCJIT instance can notionally manage multiple modules, but there are caveats (which I'm afraid I don't remember off the top of my head) that make it unattractive in practice. I believe most clients opt for something like the ExecutionEngine-per-Module model used in the Kaleidoscope tutorials. As Dave mentioned, I'm also working on some new JIT APIs (Orc) that

Hi Bjoern, CC'ing Lang hames For questions, 1. In short yes, you can replace the memory manager, default one provided is section memory manager. 2. If you mean by " address of already compiled code", yes you can do that. Like this JITDylib.define(absoluteSymbols, ( Your_own_symbol , JITTargetAddress(Address of function))), now ORC can resolve all the references to Your_own_symbol

Nice! Let me try to answer some questions, Before that I have to mention this is ORC version 2 APIs and this is where the project is moving forward. JITDylib is the symbol table, basically for a JIT Symbol it have an associated materializers, (you can think of it like an entity that generate the address for that symbol), Example: compiler are materializers. So to add symbols to your own JIT you

Hi all, I have the following code: [use llvm to generate ir_func() ] in side the ir_func() there's a call to a native cpp function that throws an exception. (Just imagine changing the fibonacci example and calling a native c++ func that throws inside the fibonacci body) I can't seem to catch "foreign" exception or any exception using the following pseudo code: try { // cast

Turns out llvm initializes memory before the constructor is invoked. Visual studio has /sdl by default on, and the __autoclassinit2 will zero the memory before the constructor is reached causing all the setters to be default zero. which clears the hashungoff var and causing the delete to flow in wrong part. When /sdl is enabled, the compiler generates code to perform these checks at run time: —

I found the root cause, but I don't know what's the best approach to fix it. Under windows, 64 bit, when a function is created the void *User::operator new(size_t Size) operator allocates space + Use*. In the Use* the HasHungOffUses is set to true. So the ptr to the use* is returned as new object. This ptr is NOT the ptr that was allocated by the system. For that ptr you need ptr - word

Hi, For a new language I am developing (in the very early stages, nothing public posted yet) I would like to able to use a JIT for several purposes: 1) Create a functional REPL as is done is done with in the Kaleidoscope tutorial. 2) Be able to interpret my language in addition to compiling. 3) While compiling, be able to execute arbitrary code at compile time. The simple case will be to

I made the llvm::Function() constructor public (for testing purpose) and used the non-overloaded new. auto func = ::new llvm::Function(...) if (func) func->eraseFromParent(); And the heap corruption is gone! Did something changed in llvm::User::new between 3.7.1 and 3.8.0 ? I found a bug in llvm ? On Thu, Feb 25, 2016 at 12:10 PM, koffie drinker <gekkekoe at gmail.com> wrote: > I

Hi, I am building a new JIT compiler for Lua (actually a derivative of Lua), and am planning to use LLVM for this. I have trying out some basic functions using LLVM 3.5.1. I have been puzzled by one aspect of the MCJIT versions of the Kaleidoscope sample, and would hugely appreciate some insight. Can a single MCJIT instance be used to manage several modules? Why is a separate MCJIT instance

Hello LLVM-Mailing list, in the past I was using the MCJIT (if I understand it correctly) to load IR modules, compile them and execute them. The speciality of this JIT was, that it was writing the compiled code into a shared memory - for a different process to execute them. For that task the JIT used a 'custom' memory manager, memory mapping and also resolved undefined references itself.

Thanks! Currently using MCJIT. But migration to ORC is on my TODO list. - Paweł On Thu, May 12, 2016 at 8:30 PM Lang Hames <lhames at gmail.com> wrote: > Hi Pawel, > > Option (1) and (3) are very similar, but using custom resolution (option > 3) guarantees that JIT'd code can't accidentally end up depending on > functions in your JIT that you didn't mean to

Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and

Hi LLVM, Lang. I'm looking for a advice here. And I truly understand very little what the relocations are and how they work. The problem I want to solve is the case where a jitted code has to call back the host application to query additional data. I can think of 3 possible solutions: 1. Use built-in relocation resolver (in default memory manager?) and allow the JIT to find the

On Tue, Apr 21, 2015 at 7:26 AM, Per Mildner <Per.Mildner at sics.se> wrote: > Charlie Turner <charlesturner7c5 <at> gmail.com> writes: > > > I was planning on committing these changes with the corresponding > > changes to the Kaleidoscope tutorial walk-through. Might be a bit of a > > surprise to have no explanation of what MCJITHelper and friends is