search for: henigman

...r I get code that seg faults. The assembly looks plausible at a glance, but I'm not really up to speed on x86 assembly. Is PIC supposed to work with JIT on X86-32? On Sat, Mar 16, 2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com> wrote: > > On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: > >> I derived a class from JITMemoryManager which delegates everything to >> an instance made with CreateDefaultMemManager(). ExecutionEngine >> destroys the wrapper, but I keep the inner instance which did the >> actual work. Wo...

...irection. I have more idealistic hopes for the MCJIT engine, and if you're interested in using it I'd be happy to talk to you about future design directions. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Frank Henigman Sent: Sunday, March 17, 2013 2:18 PM To: Dirkjan Bussink Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation Thanks for the reply, nice to have some validation. I thought of another approach which might be preferable: generate relocatable...

...ic hopes for the MCJIT engine, and if you're interested in using it I'd be happy to talk to you about future design directions. > > -Andy > > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Frank Henigman > Sent: Sunday, March 17, 2013 2:18 PM > To: Dirkjan Bussink > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation > > Thanks for the reply, nice to have some validation. I thought of another approach which might be pre...

...opes for the MCJIT engine, and if you're interested in using it I'd be happy to talk to you about future design directions. > > -Andy > > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Frank Henigman > Sent: Sunday, March 17, 2013 2:18 PM > To: Dirkjan Bussink > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation > > Thanks for the reply, nice to have some validation. I thought of another approach which might be pr...

On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: > I derived a class from JITMemoryManager which delegates everything to > an instance made with CreateDefaultMemManager(). ExecutionEngine > destroys the wrapper, but I keep the inner instance which did the > actual work. Works, but seems a bit...

...ic hopes for the MCJIT engine, and if you're interested in using it I'd be happy to talk to you about future design directions. > > -Andy > > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Frank Henigman > Sent: Sunday, March 17, 2013 2:18 PM > To: Dirkjan Bussink > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation > > Thanks for the reply, nice to have some validation. I thought of another approach which might be pre...

...me explorations in progress to figure out how to deal with these limitations, but nothing is imminent. If these limitations aren't a concern for you, I suggest you give MCJIT a try. It has some nice benefits and is being more actively maintained. -Andy -----Original Message----- From: Frank Henigman [mailto:fjhenigman at google.com] Sent: Wednesday, March 20, 2013 9:14 AM To: Kaylor, Andrew Cc: Dirkjan Bussink; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Memory clean for applications using LLVM for JIT compilation It seems wrong to delegate a dozen or more methods when I only want to chang...

> On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > > > Or maybe would it be possible to have a custom allocator for memory space for the native code that we could provide? With this last option we would be responsible for the clean up ourselves and just provide memory space to LLVM where it can store the results. > > > > Yes, you should be

...e 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 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 f...

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 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 co...

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