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

Peter Shugalev peter at shugalev.com
Sat Mar 27 12:49:44 PDT 2010


Chris Lattner wrote:
> On Mar 27, 2010, at 11:56 AM, Peter Shugalev wrote:
> 
>>>> What exactly is expected to be coming? Will it be the same way MachO is
>>>> currently implemented but with some flexibility to supply my own class
>>>> to do actual object output? Or just a return of old ObjectCodeEmitter?
>>> We're integrating a full assembler into the compiler.  I'm not sure what you mean by "flexibility to supply my own class to do actual object output", but you should be able to implement your own container format, right now even. :)
>> That's great. Any samples, docs?
> 
> No docs, you can look at the macho emitter to see how it works.
> 
>> If it's llvm-mc you are talking about what is the current implementation
>> status? I mean on what target and/or input data is it known to work?
> 
> Two different things here:
> 
> 1) llc -filetype=obj
> 2) llvm-mc: this provides a stand alone assembler (among other things)
> 
> llc -filetype=obj does not support inline assembly yet, but other than that it is believed to be 100% correct on darwin-i386 and very nearly correct on darwin-x86_64.
> 
> llvm-mc has parsers for X86 32/64 that are reasonably solid, but it only accepts the syntax that the compiler produces.  For example, it will currently reject x86 instructions that don't have an b/w/l/q suffix etc.  This clearly needs to be fixed :)  Other than that, it works as well as llc -filetype=obj.
> 
>> 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.

-- 
Best Regards
Peter Shugalev



More information about the llvm-dev mailing list