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

On Mar 26, 2010, at 6:24 PM, Peter Shugalev wrote: > Hi, > > Just realized that ability to generate static object code (e.g. ELF w/o > using JIT) is no longer available in 2.7 (at least in release_27 branch). > > For example >> llc -filetype=obj whatever.bc > doesn't work in Linux environment anymore (well it wasn't fully > implemented before but it worked

Chris Lattner wrote: > On Mar 26, 2010, at 6:24 PM, Peter Shugalev wrote: > >> Hi, >> >> Just realized that ability to generate static object code (e.g. ELF w/o >> using JIT) is no longer available in 2.7 (at least in release_27 branch). >> >> For example >>> llc -filetype=obj whatever.bc >> doesn't work in Linux environment anymore

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.

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

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

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

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

On Mar 27, 2010, at 1:50 PM, Peter Shugalev wrote: > 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

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

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? There are 3 classes which

>> Sorry, I disagree actually the MachineCodeEmitter or the >> 'MachineCodeWritter' does not do any file handling at all. Do look at the >> code for the MachineCodeWritter and you will see it only writes to memory >> and if it reaches the end of the allotted memory I believe higher ordered >> logic reallocates a larget buffer and starts again from scratch.

> Currently, the MachO and ELF Writers and MachineCodeEmitters are > hard-coded into LLVMTargetMachine and llc. I am also interested in working on this area and interested in writting a COFF file backend. > In other words, the 'object file generation' capabilities of the > Common Code Generator are not generic. I was looking at making a parallel class to MachineCodeEmitter,

I like the idea of a generic MachineCodeWriter, although I prefer the name 'ObjectFileWriter'... I think we need to take a hard look at which bits of the Writer/Emitter infrastructure are needed for what tasks (Object File Emittion, JIT, etc.) and make sure that our abstractions are flexible enough... As it stands at the moment, the Writer and Emitter classes could definately be merged

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

On Tuesday 30 March 2010 17:45:16 David Greene wrote: > On Tuesday 30 March 2010 16:09:03 Tanya Lattner wrote: > > Please take a look at all release blockers: > > http://llvm.org/bugs/show_bug.cgi?id=6586 > > 5893 is not release-critical according to Doug. > > 6640 appears to be a test system problem with a patch available (one of the > ones you're working on?)

On Mar 30, 2010, at 4:04 PM, David Greene wrote: > On Tuesday 30 March 2010 17:45:16 David Greene wrote: >> On Tuesday 30 March 2010 16:09:03 Tanya Lattner wrote: >>> Please take a look at all release blockers: >>> http://llvm.org/bugs/show_bug.cgi?id=6586 >> >> 5893 is not release-critical according to Doug. >> >> 6640 appears to be a test

The 2. 7 release branch is created. If you want to check it out, you can issue the following commands: svn co https://llvm.org/svn/llvm-project/llvm/branches/release_27 svn co https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_27 svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_27 svn co https://llvm.org/svn/llvm-project/cfe/branches/release_27 The pre-release

Currently, the MachO and ELF Writers and MachineCodeEmitters are hard-coded into LLVMTargetMachine and llc. In other words, the 'object file generation' capabilities of the Common Code Generator are not generic. LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the derived backend TargetMachine implements one of getMachOWriterInfo or getELFWriterInfo, and returns a

On Tuesday 30 March 2010 16:09:03 Tanya Lattner wrote: > Please take a look at all release blockers: > http://llvm.org/bugs/show_bug.cgi?id=6586 5893 is not release-critical according to Doug. 6640 appears to be a test system problem with a patch available (one of the ones you're working on?) Which bugs do you have patches for? I don't want to start looking at something if

We process very large programs and it is not unusual for the IR for some compilation unit to exceed system memory. With some hacking in LLVM 2.5 I was able to coax LLVM to generate asm for each functioin as it was processed and then completely forget about it (i.e. delete it) and move on to the next function. This required a bit of hackery. I had to create two pass managers, one for the module