search for: codeemitter

...own listener can I still get back the (llvm::Function, void* Code, size_t Size)? Ciao. -----Original Message----- From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Monday, November 26, 2012 1:24 PM To: Manny Ko Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC No. It adds a new event, 'NotifyObjectEmitted'. The Intel JIT listener that I mentioned then uses the emitted object to find the functions (which are all emitted together). Because of the way that MCJIT is implemented, it isn't really feasible to reconstruct things...

Thanks Andrew for the update. Does it support NotifyFunctionEmitted? Cheers. -----Original Message----- From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Monday, November 26, 2012 1:06 PM To: Manny Ko Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC The current 3.2 code branch has events being broadcast from the MCJIT engine when a new object is emitted, but the profiling listeners do not do anything with the events (and I don't expect they will before the 3.2 release becomes official). I have implemented some code in tr...

...construct things like the EmittedFunctionDetails in the NotifyFunctionEmitted event. -Andy -----Original Message----- From: Manny Ko [mailto:Manny.Ko at imgtec.com] Sent: Monday, November 26, 2012 1:10 PM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC Thanks Andrew for the update. Does it support NotifyFunctionEmitted? Cheers. -----Original Message----- From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Monday, November 26, 2012 1:06 PM To: Manny Ko Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removi...

...f it is already implemented than it is very good news. Thanks. -----Original Message----- From: Eli Bendersky [mailto:eliben at google.com] Sent: Monday, November 26, 2012 9:25 AM To: Manny Ko Cc: Albert Graef; Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC On Mon, Nov 26, 2012 at 9:18 AM, Manny Ko <Manny.Ko at imgtec.com> wrote: > I know the old JIT pretty well but have only used the MCJIT from the client side. Most of my experience is on the x86backend though. > > Another critical feature missing from MCJIT is the JI...

...may be gone now). -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Manny Ko Sent: Monday, November 26, 2012 9:27 AM To: Eli Bendersky Cc: Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC Sorry for speaking too soon. It is missing from 3.2 which is the version I have been using. If it is already implemented than it is very good news. Thanks. -----Original Message----- From: Eli Bendersky [mailto:eliben at google.com] Sent: Monday, November 26, 2012 9:25 AM To:...

Ops. I meant to say 3.1. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Manny Ko Sent: Monday, November 26, 2012 9:27 AM To: Eli Bendersky Cc: Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC Sorry for speaking too soon. It is missing from 3.2 which is the version I have been using. If it is already implemented than it is very good news. Thanks. -----Original Message----- From: Eli Bendersky [mailto:eliben at google.com] Sent: Monday, November 26, 2012 9:25 AM To:...

On Mon, Nov 26, 2012 at 9:18 AM, Manny Ko <Manny.Ko at imgtec.com> wrote: > I know the old JIT pretty well but have only used the MCJIT from the client side. Most of my experience is on the x86backend though. > > Another critical feature missing from MCJIT is the JITEventListener. This is usually for supporting debuggers and profiling tools. What makes you say it is missing? Eli

...;clattner at apple.com> > >> On Jul 15, 2009, at 9:01 AM, Aaron Gray wrote: >> >>> Chris, >>> >>> If you/we do not like this code, then the alternatives are :- >>> 1) Leave as is, which I would not suggest. >>> 2) Revert to using MachineCodeEmitter like mechanics with virtual >>> extend() method to allow rebuffering with ObjectCodeEmitter providing the >>> memory management. >>> 3) Don't really know of any other alternatives :) >>> >>> 2 maybe the best compromise option. Its easy to code, remov...

...is > > Aaron > > 2009/7/16 Chris Lattner <clattner at apple.com> > On Jul 15, 2009, at 9:01 AM, Aaron Gray wrote: > Chris, > > If you/we do not like this code, then the alternatives are :- > 1) Leave as is, which I would not suggest. > 2) Revert to using MachineCodeEmitter like mechanics with virtual > extend() method to allow rebuffering with ObjectCodeEmitter > providing the memory management. > 3) Don't really know of any other alternatives :) > > 2 maybe the best compromise option. Its easy to code, removes > templating from the CodeEm...

...buggers and profiling tools. Ciao. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Albert Graef Sent: Monday, November 26, 2012 9:05 AM To: Benjamin Kramer Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC On 11/25/2012 11:16 AM, Benjamin Kramer wrote: > It's possible to coexist, but increases the maintenance burden. Ok, I understand. > I can understand your concerns and I wouldn't have proposed this change if the old JIT for ARM and PPC actually worked. When running...

...>>> On Jul 15, 2009, at 9:01 AM, Aaron Gray wrote: >>>> >>>> Chris, >>>> >>>> If you/we do not like this code, then the alternatives are :- >>>> 1) Leave as is, which I would not suggest. >>>> 2) Revert to using MachineCodeEmitter like mechanics with virtual >>>> extend() method to allow rebuffering with ObjectCodeEmitter providing the >>>> memory management. >>>> 3) Don't really know of any other alternatives :) >>>> >>>> 2 maybe the best compromise option. Its...

...at 9:01 AM, Aaron Gray wrote: > >>>> > >>>> Chris, > >>>> > >>>> If you/we do not like this code, then the alternatives are :- > >>>> 1) Leave as is, which I would not suggest. > >>>> 2) Revert to using MachineCodeEmitter like mechanics with virtual > >>>> extend() method to allow rebuffering with ObjectCodeEmitter providing > the > >>>> memory management. > >>>> 3) Don't really know of any other alternatives :) > >>>> > >>>> 2 maybe t...

On Thu, Jul 16, 2009 at 11:43 AM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: > 2009/7/16 Daniel Dunbar <daniel at zuster.org> >> >> On Thu, Jul 16, 2009 at 10:04 AM, Aaron >> Gray<aaronngray.lists at googlemail.com> wrote: >> > 2009/7/16 Chris Lattner <clattner at apple.com> >> >> Whats Daniels approach, does he have any

On 11/24/2012 05:06 PM, Benjamin Kramer wrote: > I'm proposing to remove the JIT code emitters for the ARM and PPC targets now so it's no longer holding back the development of the MC parts for those backends. Why is this holding back MCJIT development? If the old JIT with the x86 backend can coexist with MCJIT, why isn't this possible with the other backends? I have mixed

Thanks for your information. So, do you think it's better working with MCJIT instead of JIT specially for ARM platforms? I'm going to work on .bc files of some benchmarks for ARM platform. And, I decided to work with the JIT. Now, you proposed working with MCJIT. Could I get all the benefits of JIT in MCJIT as well? Regards Negar On Sat, Nov 24, 2012 at 4:06 PM, Benjamin Kramer

...aid before, if you are compelled to, feel free to continue with your > approach of premature optimization. I will fix it later. If you are not too bothered with the memory overhead in the short term then it is probably best to leave the code as it is for meantime. I think the original MachineCodeEmitter with inline emit* functions and for virtual functions like extend() so we can control memory management in sub classes. class MachineCodeEmitter { public: .... inline void emitByte( uint8_t b) { if (freespace()) BufferPtr++ = b; else { extend(); BufferPtr++ = b;...

On 24.11.2012, at 17:53, Negar Mir <nmiralaei at gmail.com> wrote: > Thanks for your information. So, do you think it's better working with MCJIT instead of JIT specially for ARM platforms? I'm going to work on .bc files of some benchmarks for ARM platform. And, I decided to work with the JIT. Now, you proposed working with MCJIT. Could I get all the benefits of JIT in MCJIT as

On Jul 16, 2009, at 10:04 AM, Aaron Gray wrote: > > I understand that you say that, but I can't bring myself to care at > this point. Have you thought about how many cycles are already used > to produce the instructions that lead to the emission of those 10K > bytes? The total percentage of time spent doing these virtual calls > will be tiny compared to the total

Hi all, I have defined an instruction in the InstFormat.td and InstrInfo.td files. I also wrote a CodeEmitter class for that, and now I have a .inc file after compilation that seems like it might be correct, BUT, I would like to see what will be generated when the assembly code is converted to the binary machine code! Is there any command in TableGen or a test class to do so? Cheers, ES -------------- nex...

Hi all, I have implemented AsmParser, CodeEmitter, and ELF object writing. AsmParser and CodeEmitter are tested and working fine, but I would like to see ELF objects build out of a parsed asm file. Is that possible? I tried this commands, but it didn't work corrctly: *llvm-mc -filetype=obj -arch=test file.s -o=a.o* and I think after an obj...