similar to: [LLVMdev] [MCJIT] Why does it allocate function by function?

On Jul 5, 2011, at 6:04 PM, Yuri wrote: > I am implementing ELFObject class for MCJIT to be able to run ELFs on ELF-platforms. > > One thing bothers me: I see that the RTDyldMemoryManager-based allocator is always passed to MCJIT and to RuntimeDyld classes from outside. This enforces the approach that memory will be allocated function by function with startFunctionBody/endFunctionBody.

Mesa (http://www.mesa3d.org/) uses LLVM to compile shaders. These are typically small bits of code (~10KB) and one application can use many of them. Mesa creates an ExecutionEngine with a default JIT memory manager for each shader it compiles, and keeps the engine around as long as the shader code is needed. This results in memory waste of ~1MB for each shader. Half the overhead is in the

I'll try to find out, or get someone to explain, why Mesa selects MCJIT with LLVM 3.1 only and JIT for other LLVM versions. I'm not keen to code a fourth attempt (1: copy JIT code, 2: delegating manger, 3: derive from DefaultJITMemoryManager, 4: copy MCJIT code) but I'll try copying code with MCJIT. Is that the usual route for people who want to delete all LLVM engines, etc. while

Hi Frank, The project really needs to be looking to move away from the old JIT and to MCJIT. LLVM is actively working to kill the old JIT. It’s already unmaintained. MCJIT is the way forward. Can you elaborate on what’s blocking its adoption for Mesa? -Jim On Oct 1, 2013, at 10:44 AM, Frank Henigman <fjhenigman at google.com> wrote: > Mesa (http://www.mesa3d.org/) uses LLVM to compile

On 07/06/2011 08:28, Jim Grosbach wrote: > Hi Yuri, You're correct that the current JITMemoryManager interface > isn't a very good fit for the MCJIT. For the time being though, the > intent is to work with it as much as possible so that the MCJIT can be > a drop-in replacement for the old JIT. If we change the > JITMemoryManager API right off the bat, we'll make it

On 06/24/2011 13:23, Jim Grosbach wrote: >> Any progress with this? >> gitorious page shows the last update on Jul 27, 2010. >> > There's basics for an MC JIT implemented now, but it's not yet full featured enough to replace the old JIT. Have a look at ExecutionEnginer/RuntimeDyld and ExecutionEngine/MCJIT. > > It's usable enough for some things; for

On Jul 6, 2011, at 9:28 AM, Yuri wrote: > On 07/06/2011 08:28, Jim Grosbach wrote: >> Hi Yuri, You're correct that the current JITMemoryManager interface isn't a very good fit for the MCJIT. For the time being though, the intent is to work with it as much as possible so that the MCJIT can be a drop-in replacement for the old JIT. If we change the JITMemoryManager API right off

Here's my problem, which I raised on IRC: JIT::getPointerToFunction gets the address of the start of a function. But how do I find out where the end of the function is? I need this to register the function for profiling. varth said: aph, you need to intercept the "endFunctionBody" call on the memory manager, it will tell you the start pointer and the end pointer But how can I do

On Jun 29, 2011, at 4:36 PM, Yuri wrote: > On 06/24/2011 13:23, Jim Grosbach wrote: >>> Any progress with this? >>> gitorious page shows the last update on Jul 27, 2010. >>> >> There's basics for an MC JIT implemented now, but it's not yet full featured enough to replace the old JIT. Have a look at ExecutionEnginer/RuntimeDyld and

Hi Andrew, Andrew Haley wrote: > Here's my problem, which I raised on IRC: > > JIT::getPointerToFunction gets the address of the start of a function. > But how do I find out where the end of the function is? I need this > to register the function for profiling. > > varth said: aph, you need to intercept the "endFunctionBody" call on > the memory manager, it

Hi, Can you please clarify? We're looking for a way to use LLVM to JIT many modules, assuming that the full list of modules and their content are not available at a time when some of jitted pieces are already in use. Is it feasible to destruct ExecutionEngine but keep jitted code alive? Are jitted binary codes position independent? (or is there a way to relocate) If the solution requires

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Mikhail Lyapunov > Subject: [LLVMdev] Multiple modules JITting > We're looking for a way to use LLVM to JIT many modules, assuming that > the full list of modules and their content are not available at a time > when some of jitted pieces are already in use. We do this in our

On 11/11/13 17:42, Kaylor, Andrew wrote: > I've got a number of problems with this patch. > > First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them. That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine. The direction of LLVM is not something I'm in a position to

I have some vision about Object Caching. A client, which is interested in object caching, will need some help from compiler and LLVM side. The object file, located on disk, should contain information that allows to decide – rebuild or not rebuild. The client (a backend engine, which translates IR to JIT) compares data from object file, found on disk and module IR. The information that object

This sounds interesting, but strikes me as significantly outside the scope of the MCJIT itself. That is, this is the sort of thing a client application or framework would build on top of the MCJIT. -Jim On Jul 30, 2012, at 6:20 AM, "Demikhovsky, Elena" <elena.demikhovsky at intel.com> wrote: > I have some vision about Object Caching. > > A client, which is interested

I've got a number of problems with this patch. First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them. That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine. Second, unless I'm reading it wrong, this relies on static constructors. That causes headaches and is against the

Following up and expanding on an earlier conversation, I'd like to discuss making several non-trivial changes to the MCJIT engine and related objects. There may be some interdependencies between these changes, but I think that they can be logically grouped as follows: * Lazy module compilation * Enhance the JIT memory manager interface to enable section-based memory protection * Clean up

Well, is the attached version better? I've extended the RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. I've also split the original patch up into two parts, to separate the math function fixes from setLastModificationAndAccessTime. The

The various ExecutionEngine pieces may be the only places within LLVM that are using the DynamicLibrary stuff, but there's no telling what various LLVM consumers may be using it for. The "stat" symbols shouldn't be exposed the way they are in the old JIT memory manager location. It's not clear to me why that didn't happen inside getPointerToNamedFunction there. Is

Here's an updated version with more comments. James On 14/11/13 23:06, Kaylor, Andrew wrote: > Oh, I see now. It turns out that even knowing what the end goal was I misunderstood part of what the macros were doing. > > If you could add some comments explaining what the macros are doing then I guess I can live with the patch in this form. I definitely agree that it's better not