search for: defaultjitmemorymanager

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 keeping the generated code? In any case, my points on the difficulty of creating a JITMemoryManager apply equally to JIT or MCJIT. Maybe few people car...

Hi Tanya, glad to see that 2.6 release is coming. :) After doing some testing with valgrind on this release, I have find a little "undefined memory" error in DefaultJITMemoryManager related to the PoisonMemory field. This bug has been corrected in trunk with revision r80192. Attached is a patch which cleanly apply same correction on the release-2.6 branch. Thanks, Olivier. On Sat, Oct 17, 2009 at 8:51 PM, Tanya Lattner <lattner at apple.com> wrote: > LLVMers, &gt...

When JITEmitter is teared down, it also deletes the JITMemoryManager instance. That in turns release the memory of the generated functions. Is this what you are referring to? The DefaultJITMemoryManager is pretty simple. You can obviously write your own memory manager class that maps the memory in a way that's persistent. Then all you have to do is to pass a handle of it to JITEmitter. Evan On May 21, 2008, at 2:48 AM, Nicolas Capens wrote: > Hi all, > > I’m using LLVM to gen...

...wants to use. 2) A new memory manager with less overhead and which also doesn't delete the code when killed by the engine. I've got solution 2 working, but LLVM could make it easier. Deriving from JITMemoryManager seems complicated - there are a lot of methods to implement. Deriving from DefaultJITMemoryManager is not possible because it's in an anonymous namespace. So I made a manager that delegates everything to a shared default memory manager. This eliminates overhead by packing everything into one shared manager, and when a delegating manager gets killed the shared manager persists, so it's...

...new memory manager with less overhead and which also doesn't > delete the code when killed by the engine. > I've got solution 2 working, but LLVM could make it easier. Deriving > from JITMemoryManager seems complicated - there are a lot of methods > to implement. Deriving from DefaultJITMemoryManager is not possible > because it's in an anonymous namespace. So I made a manager that > delegates everything to a shared default memory manager. This > eliminates overhead by packing everything into one shared manager, and > when a delegating manager gets killed the shared manager pe...

Hi all, I'm using LLVM to generate a fairly large number of separate functions at run-time. To minimize the memory overhead, I'd like to delete the IR and everything else that is no longer needed after a function has been generated (I don't use lazy compilation or anything like that). I noticed that deleting the ExecutionEngine deletes everything (Module, Function(s),

...08 20:16 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Deleting order and acquiring generated function When JITEmitter is teared down, it also deletes the JITMemoryManager instance. That in turns release the memory of the generated functions. Is this what you are referring to? The DefaultJITMemoryManager is pretty simple. You can obviously write your own memory manager class that maps the memory in a way that's persistent. Then all you have to do is to pass a handle of it to JITEmitter. Evan On May 21, 2008, at 2:48 AM, Nicolas Capens wrote: Hi all, I'm using LLVM to genera...

...ables are placed into memory block for function, that is first seen using given variable. Besides, during memory allocation for function its size is not considered in any way. Although there exist a code block (in JITEmitter::startFunction), which is able to calculate function size, allocator (in DefaultJITMemoryManager::startFunctionBody) does not consider predicted function size. So lli fails, when a test uses big static array. How would you advise to correct this bug? It is possible to allocate global variables in separate memory block(s) (in my opinion, it is not so good to place variables into executable m...

...e 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 there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? -Andy -----Original Message----- From: James Lyon [mailto:jameslyon0 at gmail.com] Sent: Monday, November 11, 2013 11:13 AM To: Kaylor, Andrew; LLVM Dev Subject: Re: [LLVMdev] Android JIT patch On 11/11/13 17:42, Kaylor, Andrew wrote: > I've got a number of...

...t; > 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 there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? > > -Andy > > -----Original Message----- > From: James Lyon [mailto:jameslyon0 at gmail.com] > Sent: Monday, November 11, 2013 11:13 AM > To: Kaylor, Andrew; LLVM Dev > Subject: Re: [LLVMdev] Android JIT patch > > On 11/11/13 17:42, Kaylor...

...t;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 there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? >>> >>> -Andy >>> >>> -----Original Message----- >>> From: James Lyon [mailto:jameslyon0 at gmail.com] >>> Sent: Monday, November 11, 2013 11:13 AM >>> To: Kaylor, Andrew; LLVM Dev >>> Subject: Re:...

...ables are placed into memory block for function, that is first seen using given variable.  Besides, during memory allocation for function its size is not considered in any way.  Although there exist a code block (in JITEmitter::startFunction), which is able to calculate function size, allocator (in DefaultJITMemoryManager::startFunctionBody) does not consider predicted function size.  So lli fails, when a test uses big static array. According to the documentation I have read, in general it is not possible to predict code size, but from that block of code it seems like it works for someone using a custom memory mana...

...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 there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? >> >> -Andy >> >> -----Original Message----- >> From: James Lyon [mailto:jameslyon0 at gmail.com] >> Sent: Monday, November 11, 2013 11:13 AM >> To: Kaylor, Andrew; LLVM Dev >> Subject: Re: [LLVMdev] Android JIT patch &gt...

...t; > 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 there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? > > -Andy > > -----Original Message----- > From: James Lyon [mailto:jameslyon0 at gmail.com] > Sent: Monday, November 11, 2013 11:13 AM > To: Kaylor, Andrew; LLVM Dev > Subject: Re: [LLVMdev] Android JIT patch > > On 11/11/13 17:42, Kaylor...

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

...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 there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? >> >> -Andy >> >> -----Original Message----- >> From: James Lyon [mailto:jameslyon0 at gmail.com] >> Sent: Monday, November 11, 2013 11:13 AM >> To: Kaylor, Andrew; LLVM Dev >> Subject: Re: [LLVMdev] Android JIT patch &gt...

...t;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 there a reason not to just do this kind of handling in RTDyldMemoryManager/DefaultJITMemoryManager::getPointerToNamedFunction()? >>> >>> -Andy >>> >>> -----Original Message----- >>> From: James Lyon [mailto:jameslyon0 at gmail.com] >>> Sent: Monday, November 11, 2013 11:13 AM >>> To: Kaylor, Andrew; LLVM Dev >>> Subject: Re:...

Hi Frank, I'm not sure I completely understand what your delegating memory manager is doing, but I probably don't need to. If your primary objection is that you can't derive from the DefaultJITMemoryManager then I personally wouldn't object to your submitting a patch to make that accessible as a base class. The future path for JIT and MCJIT is under debate. A few of us would really like to see MCJIT replace JIT entirely, but it can't do that until it meets all of the needs of the people curr...

...TMemoryManager.cpp (working copy) > @@ -256,6 +256,7 @@ > sys::MemoryBlock getNewMemoryBlock(unsigned size); > > std::map<const Function*, MemoryRangeHeader*> FunctionBlocks; > + std::map<const Function*, MemoryRangeHeader*> TableBlocks; > public: > DefaultJITMemoryManager(); > ~DefaultJITMemoryManager(); > @@ -290,6 +291,28 @@ > FreeMemoryList =CurBlock->TrimAllocationToSize(FreeMemoryList, > BlockSize); > } > > + /// startExceptionTable - Use startFunctionBody to allocate > memory for the > + /// function's...

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL: