llvm dev - Mar 2009 - [LLVMdev] MachO and ELF Writers/MachineCodeEmitters arehard-codedinto LLVMTargetMachine

> 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 parallel class to MachineCodeEmitter, 
'MachineCodeWriter' that can be used generically instead of 
MachineCodeEmitter to write to a supplied 'vector<byte>'. This
would not
introduce any overhead to the existing runtime code and would allow inlining 
of writting functions in X86CodeEmitter and other emitters. They would have 
to be templated and the MCE member parameterized.
> LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the
> derived backend TargetMachine implements one of getMachOWriterInfo or
> getELFWriterInfo, and returns a corresponding FileModel enum value.
>
> llc's main function uses the resulting FileModel value to determine
> which of the {AddMachOWriter,AddELFWriter} functions to call.
>
> This is limiting for a number of reasons:
> 1. If a given platform (e.g. x86) may support both MachO and ELF,
> MachO will be selected, as it is checked first. This is bad behaviour,
> it should be up to the user to decide which object format he wants.
> 2. Extension of the object file generation capabilities to include new
> object file formats is difficult, and requires modifications to LLVM
> code (not just a plugin).
>
> I suggest transforming the {getMachOWriterInfo, getELFWriterInfo}
> functions (on TargetMachine) into a single (templated?)
> getObjectFileWriterInfo function. Additionally a addObjectFileWriter
> member should be added  to TargetMachine, taking the place of the
> static {AddMachOWriter, AddELFWriter} functions.
>
> As I need this functionality (custom object file generation) for my
> current target, I'd be happy to make the modifications to the LLVM
> core. Before I do so, I'd like to get feedback on my proposed
> solution.
>
> I've added a bug for this issue:
http://llvm.org/bugs/show_bug.cgi?id=3813
Aaron

>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 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 specifically used for the JIT, it works fine for 
now, I think we should leave this alone !

I did a patch that has not been accepted as of yet that deals with the 
GVStub methods moving them into the JITEmitter class, this made several 
anonomous namespace classes into llvm namespace and also moving the 
JITEmitter class main into a header file. This gave it visibility too. NOTE 
The doxygen API documentation does not show such anonymous namespace 
classes.

I looked into using two MachineCodeEmitter objects in the JITEmitter class 
to deal with the second dealing with stub generation instread but this got 
messy.

Just parameterizing the X86CodeEmitter and others gives us the base level of 
flexability and allows us not to have to disturb the existing JIT code too 
much.

As you probably know ObjectFile emittion is not working at all at present, 
the upper levels have been written out of SVN some time ago.
>At the moment, the Writer and Emitter are declared friend, and the
>encapsulation is all broken anyhow... I'd like to rethink the whole
>model a little...
My inclination is to go down that route theoretically then step back to 
where we are and look at incremental changes that donot disturb the status 
quo too much, otherwise we will not get our patches through.
>In general, I think that a TargetMachine should expose a
>'getObjectFileWriter' method, which could be used to obtain an
object
>file generator. An additional method should be available to allow
>users of the TargetMachine to query which types of Object Files the
>TargetMachine supports.
Okay with that.
>llc could then be simply re-written to use these generic functions
>instead of the hard-coded MachO and ELF ones.
Okay, this give more flexability and usability.

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.
>
> I was looking at making a parallel class to MachineCodeEmitter,
> 'MachineCodeWriter' that can be used generically instead of
> MachineCodeEmitter to write to a supplied 'vector<byte>'.
This would not
> introduce any overhead to the existing runtime code and would allow 
> inlining
> of writting functions in X86CodeEmitter and other emitters. They would 
> have
> to be templated and the MCE member parameterized.
>
>> LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the
>> derived backend TargetMachine implements one of getMachOWriterInfo or
>> getELFWriterInfo, and returns a corresponding FileModel enum value.
>>
>> llc's main function uses the resulting FileModel value to determine
>> which of the {AddMachOWriter,AddELFWriter} functions to call.
>>
>> This is limiting for a number of reasons:
>> 1. If a given platform (e.g. x86) may support both MachO and ELF,
>> MachO will be selected, as it is checked first. This is bad behaviour,
>> it should be up to the user to decide which object format he wants.
>> 2. Extension of the object file generation capabilities to include new
>> object file formats is difficult, and requires modifications to LLVM
>> code (not just a plugin).
>>
>> I suggest transforming the {getMachOWriterInfo, getELFWriterInfo}
>> functions (on TargetMachine) into a single (templated?)
>> getObjectFileWriterInfo function. Additionally a addObjectFileWriter
>> member should be added to TargetMachine, taking the place of the
>> static {AddMachOWriter, AddELFWriter} functions.
>>
>> As I need this functionality (custom object file generation) for my
>> current target, I'd be happy to make the modifications to the LLVM
>> core. Before I do so, I'd like to get feedback on my proposed
>> solution.
>>
>> I've added a bug for this issue: 
>> http://llvm.org/bugs/show_bug.cgi?id=3813
>
> Aaron
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev