similar to: [LLVMdev] JITCodeEmitter patch - up for comments

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

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

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

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

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. Here is the correct version. ----- Original Message ----- From: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Friday, December 5, 2008 1:08:57 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] MachineCodeEmitter Patch Evan, Here are the modifications you asked for. I have, for the

On Mon, 24 Oct 2005, Vladimir A. Merzliakov wrote: > I have some problems with build current CVS version LLVM using GCC 4.1.0 (GCC > CVS mainline version). Thanks! > 1) Build terminate with error: > > llvm[3]: Compiling SparcV8CodeEmitter.cpp for Debug build > /usr/home/wanderer/pkg/build/llvm/obj/lib/Target/SparcV8/SparcV8GenCodeEmitter.inc:11: > error: definition of

Evan, Here are the modifications you asked for. I have, for the most part, not changed intptr_t to uintptr_t inside the JITInfo classes, because the pointer arithmetic there can sometimes legitimately yield negative numbers. Tom ----- Original Message ----- From: "Evan Cheng" <evan.cheng at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>

>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

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

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 >

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

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

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

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 .

> 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