search for: fjhenigman

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 ugly. Did you...

> 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

...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. Works, but seems...

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

...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. Works, but see...

...n 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 change the behavior in a...

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

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

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

..., 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 compiles, and kee...

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

After changing from 2.x to 3.0 I get these messages: rpc_server/srv_util.c:get_domain_user_groups(376) get_domain_user_groups: primary gid of user [fred] is not a Domain group ! get_domain_user_groups: You should fix it, NT doesn't like that I understand why this is: fred's group needs to be mapped like so net groupmap modify ntgroup="Domain Users" unixgroup=<fred's