similar to: [LLVMdev] JIT test cases

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 Feb 23, 2009, at 10:30 AMPST, Aaron Gray wrote: > On Mon, Feb 23, 2009 at 6:22 PM, Aaron Gray <aaronngray.lists at googlemail.com > > wrote: > On Mon, Feb 23, 2009 at 6:09 PM, Dale Johannesen <dalej at apple.com> > wrote: > These benchmarks are not distributed with llvm (which doesn't have the > legal right to distribute Spec, for example). If you have

Dale Johannesen wrote: > On Feb 23, 2009, at 10:30 AMPST, Aaron Gray wrote: > > On Mon, Feb 23, 2009 at 6:22 PM, Aaron Gray <aaronngray.lists at googlemail.com<mailto:aaronngray.lists at googlemail.com>> wrote: > On Mon, Feb 23, 2009 at 6:09 PM, Dale Johannesen <dalej at apple.com<mailto:dalej at apple.com>> wrote: > These benchmarks are not distributed with

>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 Mon, Jun 15, 2009 at 7:08 PM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: >> The documentation of unwind/invoke is quite clear and does exactly >> what I need: unwinding the stack. I don't need it to carry an object >> back. I don't need it to figure out what the type of the object is or >> what catch() blocks it matches. I just need it to unwind

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 >

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

On Mon, Feb 23, 2009 at 6:22 PM, Aaron Gray <aaronngray.lists at googlemail.com > wrote: > On Mon, Feb 23, 2009 at 6:09 PM, Dale Johannesen <dalej at apple.com> wrote: > >> These benchmarks are not distributed with llvm (which doesn't have the >> legal right to distribute Spec, for example). If you have them from >> another source, you need to configure

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

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 Mon, Feb 23, 2009 at 6:09 PM, Dale Johannesen <dalej at apple.com> wrote: > These benchmarks are not distributed with llvm (which doesn't have the > legal right to distribute Spec, for example). If you have them from > another source, you need to configure --with-externals=<path> Okay, thanks. Thre should be better warning/error reporting though. Aaron > >

> The documentation of unwind/invoke is quite clear and does exactly > what I need: unwinding the stack. I don't need it to carry an object > back. I don't need it to figure out what the type of the object is or > what catch() blocks it matches. I just need it to unwind the stack. > The rest is my job as a part of the runtime. Unfortunately, I have > learned that while

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

Nate, Right, okay. I was also planning on looking at what the assembly output generates and "emulating" its output. So I should be able to use the 'test/CodeGen/PowerPC' tests once I have augmented the MachO Writer PowerPC output. Does this seem like the right and sensible approach ? Aaron ----- Original Message ----- From: Nate Begeman To: LLVM Developers Mailing

>Aaron Gray wrote: >> What I am after is to be able to emit line number information for COFF >> (Common Object File Format) object module files, basically it comes down >> to >> paired line numbers and virtual address offsets. >> >> I have not really set out to look at this yet, just feeling ahead, and >> was >> prompted by Saman's question

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

> On Thu, Jul 2, 2009 at 11:46 AM, Aaron > Gray<aaronngray.lists at googlemail.com> wrote: >> Jon, >> >> LLVM seems to be now dependant by default on OCAML and ocamldoc. Can you >> please change this so OCAML is only built and enabled when an >> '--enable-ocaml' flag is set on 'configure'. As I cannot do 'make >> install'

On Sat, Feb 21, 2009 at 9:54 PM, Aaron Gray <aaronngray.lists at googlemail.com > wrote: > On Fri, Feb 20, 2009 at 11:45 PM, Tanya Lattner <tonic at nondot.org> wrote: > >> LLVMers, >> >> The 2.5 pre-release2 is finally available for testing: >> http://llvm.org/prereleases/2.5/ >> >> If you have time, I'd appreciate anyone who can help

> Hi Aaron, > > Aaron Gray <aaronngray.lists <at> googlemail.com> writes: > >> unrecognized option '--enable-runtime-pseudo-relocs' > > Interesting. > Does libCompilerDriver.dll link w/o '--enable-runtime-pseudo-relocs'? I have not tried as of yet. > If I understand correctly, this bug makes it impossible to produce > loadable >