[LLVMdev] Static code generation - is it gone from LLVM 2.7?

Peter Shugalev peter at shugalev.com
Sat Mar 27 13:50:43 PDT 2010


Chris Lattner wrote:
> On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote:
> 
>>>> New method of emitting object code is ok for me. But it is still
>>>> experimental, isn't it?
>>> Yes.
>> Thank you for answers!
>>
>> Now there is a way to implement what I'd like to. But it would be MUCH
>> better if LLVMTargetMachine::addPassesToEmitFile could take arbitrary
>> MCStreamer as input. Without such a feature when compiling bytecode
>> (i.e. emulating llc -filetype=obj behaviour) I have to emit .s file
>> first, disassemble it and feed to custom MCStreamer. That'll hopely work
>> but it's ugly.
> 
> What are you trying to do?  I don't see why you'd have to do that.

Ok, I'm trying to compile LLVM bytecode into some native object code
format. The thing very close to
> llc -filetype=obj foo.bc

To do so I mimic llc behaviour: create TargetMachine, create
FunctionPassManager, call TargetMachine::addPassesToEmitFile(), add my
own MyObjectCodeWriter pass and run passes.

But since LLVM 2.7 TargetMachine::addPassesToEmitFile (as implemented in
LLVMTargetMachine child class) adds its own final pass (AsmPrinter)
paired with either AsmStreamer, MachOStreamer or NullStreamer. I cannot
pass my own descendant of MCStreamer class. Now we've got predefined set
of final passes instead of free choice.

AFAIK to get object code file I have to feed emitted code through my own
MyMCStreamer class. The only sane option I see is to take assembly
output from AsmStreamer (.s file) then feed it to AsmParser passing
MyMCStreamer in AsmParser's constructor.

Thus we've got
  instructions -> AsmPrinter -> AsmParser -> MyMCStreamer
While ideally it should be only
  instructions -> MyMCStreamer

Maybe I've missed something and this could be done much easier. So I'm
looking forward to advice.


-- 
Best Regards
Peter Shugalev




More information about the llvm-dev mailing list