llvm dev - Mar 2009 - [LLVMdev] MachO and ELF Writers/MachineCodeEmitters are hard-coded into LLVMTargetMachine

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

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

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 (at least from the perspective of object
file generation).

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

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.

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