llvm dev - Mar 2009 - [LLVMdev] MachO and ELFWriters/MachineCodeEmittersarehard-codedinto LLVMTargetMachine

> Aaron, I mailed in the same mail twice (by mistake), you answered both
> copies. Differently!
>
> In any case, I've re-read what exists. I'm dumping what I
understand
> here, so that we can discuss in detail. I'm using MachO as the example
> object format, as the ELF code is totally broken 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).
>
> The runOnMachineFunction for the X86CodeEmitter does:
> - call MachOCodeEmitter::startFunction
> - for each basicblock in function:
>   - call MachOCodeEmitter::StartMachineBasicBlock
>   - for each instruction in basicblock:
>       - emit instruction, using MachineCodeEmitter::emit* functions
> - call MachOCodeEmitter::finishFunction
>
> [This runOnMachineFunction could definitely be generalized, i.e.
> implemented in a base class ('EmitterMachineFunctionPass' or a
better
> name). This base class would then have (abstract) emitInstruction,
> emitOperand, etc... methods. It should also integrate with the
> *GenCodeEmitter emitted by tblgen so that you get automatic code
> emission. When implementing a new target, one would simply need to
> inherit the baseclass, and override the functions necessary to tweak
> output.]
runOnMachineFunction is a standard LLVM message we cannot play around with 
it.

Please read LLVM code more and get a general overview of the standard 
interfaces.

Aaron

> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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

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

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.

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.

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

I don't see any reason that such a pattern would 'break' the LLVM
standard pattern.
> 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.


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


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?


Thanks.
someguy

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

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