similar to: [LLVMdev] JITCodeEmitter plans

This is the JITCodeEmitter patch, this is to facilitate cordening off the JIT code from the future direct object emission code (i) supporting the upcoming ObjectCodeEmitter class, on the X86, ARM, Alpha, and PowerPC platforms. This involves generic parameterization of backend code emitters to allow code emission to allotted class types, JITCodeEmitter and ObjectCodeEmitter.

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.

> 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

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

I'll look at these. First scan looks good. Are you able to run some tests? Evan On Feb 28, 2009, at 9:36 AM, Aaron Gray wrote: > I have done a possible cleanup patch for the MachineCodeEmitter, > ELFWriter, and MachOWriter classes. It removes the two > startGVStub(), and finishGVStub() JIT specific methods. > > You may remember the following comments :- > >

I have done a possible cleanup patch for the MachineCodeEmitter, ELFWriter, and MachOWriter classes. It removes the two startGVStub(), and finishGVStub() JIT specific methods. You may remember the following comments :- /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! To get rid of these easily turned out to be a semicomplex modification because of the JITInfo classes dependance on

>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

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 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 calls. I understand that you say that, but I can't bring myself

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

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

Hi Gaël, I'm not familiar enough with the details of the old JIT engine and its event interface to comment on whether or not your changes are appropriate, but I'm not sure anyone is so the patch is probably OK as is. I don't see any obvious problems with it. However, your description of the changes raises a bigger issue in my mind. I'm not sure if you are aware of this, but

Hi Andy, We had previous discussions about this, I'd like to state more exactly what features would make MCJIT a replacement for the JIT. After putting significant effort trying to move to MCJIT, I'm currently back with the JIT. This is in a REPL environment where functions are added and removed dynamically and response time is important. The issue is the legacy JIT provides great

> I've never looked at the MachO code as I do not have such a platform nor do > I know the file format. > > Could we concentrate on the ELF backend, please. I don't mind using the ELF backend as our test case, it just seems that the ELFWriter/ELFCodeEmitter don't even use the BufferBegin/BufferEnd/CurBufferPtr system exposed by the base MachineCodeEmitter. There is a big

Hi Andy, I have been following Julia with interest, as it's a type-optional language designed to be as nice as dynamic languages but run at the speed of compiled C++ programs. They achieve this by deducing as many types at compile time and JITing code for the unknown types at runtime when they are known. That's a smart use of a JIT. In C++ terms it's analog to instantiating templates

Hi Yaron, I think a lot of what I said in my reply to Gaël also applies to your situation. In particular, I think that it's probably best for your code to manager the function stubs and replacement. I talked last week with a developer who works on the Julia language (which shares a lot of features your situation) and it's my understanding that the Julia runtime handles function stubs