Peter Shugalev
2010-Mar-27 18:56 UTC
[LLVMdev] Static code generation - is it gone from LLVM 2.7?
Chris Lattner wrote:> On Mar 27, 2010, at 3:41 AM, Peter Shugalev wrote: > >>>> Now LLVMTargetMachine::addPassesToEmitFile has changed. It adds its own >>>> code emitter and it's always MachOCodeEmitter which of course I don't need. >>>> >>>> Is there a new way to create non-JIT object code in LLVM 2.7? >>> Nope, sorry. This will hopefully be coming in 2.8. Mainline llvm can already do macho quite robustly for x86-32 and x86-64. >>> >>> -Chris >>> >> 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? 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? New method of emitting object code is ok for me. But it is still experimental, isn't it? -- Best Regards Peter Shugalev
Chris Lattner
2010-Mar-27 19:04 UTC
[LLVMdev] Static code generation - is it gone from LLVM 2.7?
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. -Chris
Peter Shugalev
2010-Mar-27 19:49 UTC
[LLVMdev] Static code generation - is it gone from LLVM 2.7?
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
Seemingly Similar Threads
- [LLVMdev] Static code generation - is it gone from LLVM 2.7?
- [LLVMdev] Static code generation - is it gone from LLVM 2.7?
- [LLVMdev] Static code generation - is it gone from LLVM 2.7?
- [LLVMdev] Static code generation - is it gone from LLVM 2.7?
- [LLVMdev] Static code generation - is it gone from LLVM 2.7?