[LLVMdev] MachO andELFWriters/MachineCodeEmittersarehard-codedinto LLVMTargetMachine

[Aaron Gray]

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

Okay I will read the MachO backend, thanks.

>>> 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.
>>
>> runOnMachineFunction is a standard LLVM message we cannot play around 
>> with
>> it.
>
>I'm well aware that runOnMachineFunction is a standard LLVM meme. My
>suggestion in no way conflicts with its standard meaning.

Okay :)

>All I meant was that we could build a new target-nonspecific 'base
>class', called e.g. ObjectEmitter, which would inherit
>MachineFunctionPass. This base-class should implement
>runOnMachineFunction using the pattern described above, as it seems
>relatively target-nonspecific. In order to emit actual instructions,
>the ObjectEmitter::runOnMachineFunction could call the (abstract)
>ObjectEmitter::emitInstruction method, which _must_ be
>target-specific.

Do we need to abstract targets back to a ObjectEmitter class, can we not 
just implement ELFEmitter and ELFWriter ?

>This emitInstruction method could either be abstract, in which case
>the developer of the target backend must implement it appropriately.
>Alternatively it could be virtual, with the default implementation
>utilizing tblgen generated emission code.

I would prefer not to use virtual methods at this level or at least keep 
them to a minimum. Ideally everything reasonable to be inlined should be 
inlined.

>In either case, the ObjectEmitter would lighten the load on the target
>backend developer, as he would only be required to implement
>target-specific functions (emitInstruction and dependencies).

The

>I don't see any reason that such a pattern would 'break' the LLVM
>standard pattern.

Okay.

>> Please read LLVM code more and get a general overview of the standard
>> interfaces.
>
>Although I am quite new to llvm, I have spent 2 straight weeks reading
>its code. There are many things I have yet to understand, and I
>appreciate your patience. Please do try and point out my
>misunderstandings rather than make generic 'read more code'
>suggestions. I really want to learn, and am more than willing to make
>the effort.

Yeah, its like that. I will have to read the MachO stuff.

>One more thing: the naming of the various classes is a little confusing:
>- ELFWriter - a MachineFunctionPass
>- ELFCodeEmitter - a MachineCodeEmitter
>(Those I can deal with, although ELFWriterPass makes me much happier)
>- X86CodeEmitter - a MachineFunctionPass
>(This is just confusing! Its an emitter, but not a MachineCodeEmitter.
>Perhaps X86CodeGenerator is more appropriate? Or even
>X86CodeGeneratorPass?)

Yeah, but it is how it is and people are familiar with it like that.

>Also, am I right in saying that only the X86CodeEmitter is used for
>JIT, and that a special JIT MachineCodeEmitter is passed to its
>constructor?

Yep, thats the bit I think could be made generic, parameterize the MCE 
variable, and we can pass in our ObjectCodeEmitter class and object. That 
was my plan anyway for the lower level.

Okay I will read the MachO code and hopefully get your perspective.

>BTW: if you want to hash these things out 'live', I'm usually in the
>IRC channel during the day (GMT+1).

I do prefer e-mail :)

Cheers,

Aaron