search for: machinecodeemitter

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

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

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

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

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

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

...ty. >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 suggest being very familuar with the current code the JIT, and MachineCodeEmitter, and X86 and other CodeEmitter code before jumping in :) > As it stands at the moment, the Writer and Emitter classes >could definately be merged (at least from the perspective of object >file generation). I would not do this, their functionality is distinct. The MachineCodeEmitter is s...

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 :- > > /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! > > To get rid of these easily turned out...

Hi! I'm looking for a way to make the the "llc" tool (or any other tool), directly produce a binary file for some target. The TargetMachine class has a method 'addPassesToEmitMachineCode', that's suitable for that, but that method also requires an instance of MachineCodeEmitter. The existing MachineCodeEmitter derived classes are either debug-only (writing to std::cerr), or for JIT, or for ELF (which is not used anywhere, BTW). Ideally, I'd like to create my own MachineCodeEmitter derived class, load it into llc with the -load option, and then have new option for ...

...roken and outdated. Lets > use the following as the basis for our discussion? 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. > 3. X86CodeEmitter > - a MachineFunctionPass, NOT a MachineCodeEmitter (Could the naming > change perhaps?) Yes, it uses a MachineCodeEmitter in its internals (MCE) and as a constructor argument. > This class receives (during construction) a reference to a > MachineCodeEmitter (e.g. MachOCodeEmitter, which in turn stores a > reference to a MachOWritter)...

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

...bject Files the TargetMachine supports. llc could then be simply re-written to use these generic functions instead of the hard-coded MachO and ELF ones. On Sun, Mar 15, 2009 at 10:39 PM, Aaron Gray <aaronngray.lists at googlemail.com> wrote: >> 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....

...ch 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 "FIXME" and an abort at the beginning of the ELFCodeEmitter::startFunction. This is why I used MachO to 'grok' the concept. > > >> 3. X86CodeEmitter >>   - a MachineFunctionPass, NOT a MachineCodeEmitter (Could the naming >> change perhaps...

...r with functions such as writeByte, writeWord, etc.... the SizeEmitter class implements these function by incrementing a counter. At the end of the pass, the code size of the function is known. > 2) Why not simply add the functionality of allocating emission > buffer of specific size to MachineCodeEmitter instead? > I don't understand. The MachineCodeEmitter class writes directly to a buffer which is remalloc'ed if necessary. I want this buffer to be pre-allocated and of the correct size. Hence I need a pass that runs before emitting code. Nicolas > Thanks, > > Evan >...

...looking for a way to make the the "llc" tool (or any other tool), > directly produce a binary file for some target. ok > The TargetMachine class has a method 'addPassesToEmitMachineCode', that's > suitable for that, but that method also requires an instance of > MachineCodeEmitter. Actually, you probably want to plug into the addPassesToEmitFile API, when FileType is set to ObjectFile. X86TargetMachine::addPassesToEmitFile demonstrates how to do this. > The existing MachineCodeEmitter derived classes are either debug-only > (writing to std::cerr), or for JIT, or f...

...checks to see if CurBufferPtr == BufferEnd at the beginning of the function and not after all relocations have been handled. I have fixed this bug by adding an additional check after all relocations have been completed. In the process of fixing this bug, I happened to look through the code in MachineCodeEmitter.h. The buffer size checks in MachineCodeEmitter.h all suffer from an integer overflow bug. For example in allocateSpace the code reads: // Allocate the space. CurBufferPtr += Size; // Check for buffer overflow. if (CurBufferPtr >= BufferEnd) { This is wrong because Size...

Currently, the MachO and ELF Writers and MachineCodeEmitters are hard-coded into LLVMTargetMachine and llc. In other words, the 'object file generation' capabilities of the Common Code Generator are not generic. LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the derived backend TargetMachine implements one of getMachOWriterInfo o...

...s. I do not have commit privilege. Tom ----- Original Message ----- From: "Evan Cheng" <evan.cheng at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Monday, December 8, 2008 5:39:33 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] MachineCodeEmitter Patch Looks good. Do you have commit privilege? Evan On Nov 22, 2008, at 1:19 PM, Thomas Jablin wrote: > Here is the corrected version. > > Thomas Jablin wrote: >> Actually, there is a problem with the patch. Please delay review. >> >> Thomas Jablin wrote: >> &g...

...emModRMByte and probably others). That's not a problem (I'm thinking bug fixes and improvements, we'll have to handle two duplicated code). Nicolas > Evan > > >> >>> Suppose you have the size, can't you pass the desired buffer size to >>> MachineCodeEmitter and have it do the right thing? >>> >> Sure, that's what I'm doing. The emitter with the SizeEmitter class >> will >> give the accurate size to the MachineCodeEmitter. And the >> MachineCodeEmitter will emit the instructions in the buffer. >>...

...Size(). I'd like to see them standardized (all targets that have JIT support can accurately calculate the function / instruction sizes) and then you can make use of that. > > >> 2) Why not simply add the functionality of allocating emission >> buffer of specific size to MachineCodeEmitter instead? >> > > I don't understand. The MachineCodeEmitter class writes directly to a > buffer which is remalloc'ed if necessary. I want this buffer to be > pre-allocated and of the correct size. Hence I need a pass that runs > before emitting code. Suppose you have th...