search for: setpoisonmemori

Displaying 9 results from an estimated 9 matches for "setpoisonmemori".

Did you mean: setpoisonmemory
2013 Oct 01
2
[LLVMdev] JITMemoryManager
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
2013 Oct 02
0
[LLVMdev] JITMemoryManager
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
2009 Jul 03
0
[LLVMdev] JIT allocates global data in function body memory
On Thu, Jul 2, 2009 at 3:09 PM, Evan Cheng<evan.cheng at apple.com> wrote: > The patch looks good to me. But we cannot allow AllocateGVsWithCode to > be initialized to be false yet. Can you add a mechanism to define the > behavior when the JIT is created / initialized? That makes four optional arguments to ExecutionEngine::create. Do you mind if I go ahead and add an
2013 Oct 02
3
[LLVMdev] JITMemoryManager
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
2009 Jul 02
2
[LLVMdev] JIT allocates global data in function body memory
The patch looks good to me. But we cannot allow AllocateGVsWithCode to be initialized to be false yet. Can you add a mechanism to define the behavior when the JIT is created / initialized? Also, I am not crazy about this being moved to JITMemoryManager.h. This seems like implementation detail that should be kept hidden. + // If the PoisonMemory parameter is true, freed memory should be
2009 Jul 06
2
[LLVMdev] JIT allocates global data in function body memory
On Jul 2, 2009, at 5:20 PM, Reid Kleckner wrote: > On Thu, Jul 2, 2009 at 3:09 PM, Evan Cheng<evan.cheng at apple.com> > wrote: >> The patch looks good to me. But we cannot allow AllocateGVsWithCode >> to >> be initialized to be false yet. Can you add a mechanism to define the >> behavior when the JIT is created / initialized? > > That makes four
2012 Sep 24
0
[LLVMdev] [llvm-commits] Fwd: Re: [PATCH] Fix for bug in JIT exception table allocation
Pinging again, more loudly :-) Michael Muller wrote: > > Ping. (looking for someone to review or commit this, thanks) > > Michael Muller wrote: > > > > Thanks, Duncan - > > > > > Hi Michael, > > > > > > > --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 163478) > > > > +++ lib/ExecutionEngine/JIT/JITEmitter.cpp
2012 Aug 22
1
[LLVMdev] [PATCH] Fix for bug in JIT exception table allocation (no test yet)
On Aug 21, 2012, at 2:12 PM, Michael Muller <mmuller at enduden.com> wrote: > > Hi, I found a bug in the code that generates exception tables, I've attached > what I think is the correct fix. > > When you run out of space writing to a buffer, the buffer management code > simply stops writing at the end of the buffer. It is the responsibility of > the caller to
2012 Aug 23
0
[LLVMdev] [PATCH] Fix for bug in JIT exception table allocation (no test yet)
Eric Christopher wrote: > > On Aug 21, 2012, at 2:12 PM, Michael Muller <mmuller at enduden.com> wrote: > > > > > Hi, I found a bug in the code that generates exception tables, I've attached > > what I think is the correct fix. > > > > When you run out of space writing to a buffer, the buffer management code > > simply stops writing at the