search for: objectcodeemitt

...that for the MachineCodeWriter, or whether we write out own code output > stream/buffering ? > > I still think this is where the crux of the problem lies the upper logic is > relatively simple compared to this buy looking at what you say it is > important to get it right. > 'ObjectCodeEmitter' looks like the right description to parallel the MachineCodeEmitter. Its emitting object code to a data stream (which is an object file section) and not direct to a file. I will knock to gether an ObjectCodeEmitter that is call compatible with the MachineCodeEmitter and wtites to a std::vec...

...we the emitter runs out of space, finishFunction returns a failure, causing the whole process to occur again. This is icky. It would be far better if the underlying buffer would grow automatically (with an allocation method in the base class, as you suggested), as code is emitted to it. > 'ObjectCodeEmitter' looks like the right description to parallel the > MachineCodeEmitter. Its emitting object code to a data stream (which > is an object file section) and not direct to a file. I can live with that. Before you implement anything, can we try and define the responsibilities of the various...

...we the emitter runs out of space, finishFunction returns a failure, causing the whole process to occur again. This is icky. It would be far better if the underlying buffer would grow automatically (with an allocation method in the base class, as you suggested), as code is emitted to it. > 'ObjectCodeEmitter' looks like the right description to parallel the > MachineCodeEmitter. Its emitting object code to a data stream (which > is an object file section) and not direct to a file. I can live with that. Before you implement anything, can we try and define the responsibilities of the various...

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. include/llvm/CodeGen/MachineCodeEmitter.h * untouched until ObjectCodeEmitter t...

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

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 raw*emit mehods, these and the reserveBytes method are intended on being used by the cpu *CodeEmitters so they ju...

...would grow > automatically (with an allocation method in the base class, as you > suggested), as code is emitted to it. I think we leave the JITEmitter and MachineCodeEmitter alone as they work and its a pritty difficult thing to replace them without causing any regressions. >> 'ObjectCodeEmitter' looks like the right description to parallel the >> MachineCodeEmitter. Its emitting object code to a data stream (which >> is an object file section) and not direct to a file. > > I can live with that. Before you implement anything, can we try and > define the responsib...

>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

...anagement in sub classes. class MachineCodeEmitter { public: .... inline void emitByte( uint8_t b) { if (freespace()) BufferPtr++ = b; else { extend(); BufferPtr++ = b; } } protected: void virtual extend() = 0 }; so extend is overriden in JITCodeEmitter and ObjectCodeEmitter and is called moving emitted code to a bigger buffer if we run out of memory, then emission continues. This gives the lowest overhead and flexability. If ObjectCodeEmitter and JITEmitter manage memory then the design is transparent to the higher levels of DOE and JIT. The old design was the bes...

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

...2.8. Mainline llvm can already do macho quite robustly for x86-32 and x86-64. > > -Chris > What exactly is expected to be coming? Will it be the same way MachO is currently implemented but with some flexibility to supply my own class to do actual object output? Or just a return of old ObjectCodeEmitter? -- Best Regards Peter Shugalev

...robustly for x86-32 and x86-64. >>> >>> -Chris >>> >> What exactly is expected to be coming? Will it be the same way MachO is >> currently implemented but with some flexibility to supply my own class >> to do actual object output? Or just a return of old ObjectCodeEmitter? > > We're integrating a full assembler into the compiler. I'm not sure what you mean by "flexibility to supply my own class to do actual object output", but you should be able to implement your own container format, right now even. :) That's great. Any samples, doc...

...do macho quite robustly for x86-32 and x86-64. >> >> -Chris >> > > What exactly is expected to be coming? Will it be the same way MachO is > currently implemented but with some flexibility to supply my own class > to do actual object output? Or just a return of old ObjectCodeEmitter? We're integrating a full assembler into the compiler. I'm not sure what you mean by "flexibility to supply my own class to do actual object output", but you should be able to implement your own container format, right now even. :) -Chris

On Mar 27, 2010, at 11:56 AM, Peter Shugalev wrote: >>> What exactly is expected to be coming? Will it be the same way MachO is >>> currently implemented but with some flexibility to supply my own class >>> to do actual object output? Or just a return of old ObjectCodeEmitter? >> >> We're integrating a full assembler into the compiler. I'm not sure what you mean by "flexibility to supply my own class to do actual object output", but you should be able to implement your own container format, right now even. :) > > That's great...

...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 CodeEmitters, and is virtually transparent to > our other DOE work. The only thing it does not...

...; >>> 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 CodeEmitters, and is virtually transparent to our other DOE wor...

..., >>>> >>>> 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 CodeEmitters, and is virtually transparent...

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

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

...gt; >>>> 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 CodeEmit...