similar to: [LLVMdev] [patch] CodeEmitter Memory Foot Reduction

2009/7/16 Chris Lattner <clattner at apple.com> > > On Jul 16, 2009, at 12:53 AM, Aaron Gray wrote: > > Chris, > > The basic idea of using templates inconjunction with inlining is for > efficiency. > > 6,500 virtual calls outputting bytes out of 10000 calls, and the rest 1,750 > being words to output 10,000 of code does not entice me to use virtual >

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 online documentation or code, do >> you have an email address so I may talk to him. >> >> Take a look at how asmprinters work >> in include/llvm/Target/TargetRegistry.h .

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 online documentation or code, > do > >> you have an email address so I may talk to him. > >> >

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

2009/7/16 Chris Lattner <clattner at apple.com> > > 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

> Sorry, I disagree actually the MachineCodeEmitter or the > 'MachineCodeWritter' does not do any file handling at all. Do look at the > code for the MachineCodeWritter and you will see it only writes to memory > and if it reaches the end of the allotted memory I believe higher ordered > logic reallocates a larget buffer and starts again from scratch. This could > be

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 Mon, Mar 16, 2009 at 3:26 AM, Aaron Gray <aaronngray.lists at googlemail.com > wrote: > On Sun, Mar 15, 2009 at 10:52 PM, Aaron Gray < > aaronngray.lists at googlemail.com> wrote: > >> I like the idea of a generic MachineCodeWriter, although I prefer the >>> name 'ObjectFileWriter'... >>> >> >> Thats much more descriptive of

> Sorry, I disagree actually the MachineCodeEmitter or the > 'MachineCodeWritter' does not do any file handling at all. Do look at the > code for the MachineCodeWritter and you will see it only writes to memory > and if it reaches the end of the allotted memory I believe higher ordered > logic reallocates a larget buffer and starts again from scratch. This could > be

>I like the idea of a generic MachineCodeWriter, although I prefer the >name 'ObjectFileWriter'... Thats much more descriptive of the functionality. >I think we need to take a hard look at which bits of the >Writer/Emitter infrastructure are needed for what tasks (Object File >Emittion, JIT, etc.) and make sure that our abstractions are flexible >enough... I would

Hi, Just realized that ability to generate static object code (e.g. ELF w/o using JIT) is no longer available in 2.7 (at least in release_27 branch). For example > llc -filetype=obj whatever.bc doesn't work in Linux environment anymore (well it wasn't fully implemented before but it worked for simple bytecodes in 2.6). I used to generate code by creating TargetMachine and

On Mar 26, 2010, at 6:24 PM, Peter Shugalev wrote: > Hi, > > Just realized that ability to generate static object code (e.g. ELF w/o > using JIT) is no longer available in 2.7 (at least in release_27 branch). > > For example >> llc -filetype=obj whatever.bc > doesn't work in Linux environment anymore (well it wasn't fully > implemented before but it worked

On Sun, Mar 15, 2009 at 10:52 PM, Aaron Gray < aaronngray.lists at googlemail.com> wrote: > I like the idea of a generic MachineCodeWriter, although I prefer the >> name 'ObjectFileWriter'... >> > > Thats much more descriptive of the functionality. > Sorry, I disagree actually the MachineCodeEmitter or the 'MachineCodeWritter' does not do any file

Chris Lattner wrote: > On Mar 26, 2010, at 6:24 PM, Peter Shugalev wrote: > >> Hi, >> >> Just realized that ability to generate static object code (e.g. ELF w/o >> using JIT) is no longer available in 2.7 (at least in release_27 branch). >> >> For example >>> llc -filetype=obj whatever.bc >> doesn't work in Linux environment anymore

Reid, et.al, I cannot post the JITCodeEmitter efficiency patch for commital yet as it is still dependant upon the newer version of the MachineCodeEmitter being submitted, when it is replaced by the ObjectCodeEmitter. Anyway I have attached the code for you to look at. It is also a endian speedup patch for included. The ObjectCodeEmitter patch should hopefully go in this weekend. There are inline

> Currently, the MachO and ELF Writers and MachineCodeEmitters are > hard-coded into LLVMTargetMachine and llc. I am also interested in working on this area and interested in writting a COFF file backend. > In other words, the 'object file generation' capabilities of the > Common Code Generator are not generic. I was looking at making a parallel class to MachineCodeEmitter,

I like the idea of a generic MachineCodeWriter, although I prefer the name 'ObjectFileWriter'... I think we need to take a hard look at which bits of the Writer/Emitter infrastructure are needed for what tasks (Object File Emittion, JIT, etc.) and make sure that our abstractions are flexible enough... As it stands at the moment, the Writer and Emitter classes could definately be merged

>> Sorry, I disagree actually the MachineCodeEmitter or the >> 'MachineCodeWritter' does not do any file handling at all. Do look at the >> code for the MachineCodeWritter and you will see it only writes to memory >> and if it reaches the end of the allotted memory I believe higher ordered >> logic reallocates a larget buffer and starts again from scratch.

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

> Aaron, I mailed in the same mail twice (by mistake), you answered both > copies. Differently! > > In any case, I've re-read what exists. I'm dumping what I understand > here, so that we can discuss in detail. I'm using MachO as the example > object format, as the ELF code is totally broken and outdated. Lets > use the following as the basis for our discussion?