[LLVMdev] MachO and ELFWriters/MachineCodeEmittersarehard-codedinto LLVMTargetMachine

someguy just.s0m3.guy+llvmdev at gmail.com
Mon Mar 16 11:26:47 PDT 2009


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




More information about the llvm-dev mailing list