This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] WHOPR - A whole program optimizer framework for GCC


On Dec 19, 2007, at 2:19 PM, Tim Josling wrote:


...
 http://gcc.gnu.org/projects/lto/lto.pdf
...

Was there any more about this?


I have restarted work on my COBOL front end. Based on my previous
experiences writing a GCC front end I want to have as little code as
possible in the same process as the GCC back end.

This means passing over a file. So I would like to understand how to
avoid getting into political/legal trouble when doing this.

While it is possible to make this work once LTO is finished, it seems unlikely that it will be pleasant. Doing so will basically mean reimplementing a 'writer' for the LTO format to interoperate with the GCC code. This seems to be a hard task, as there is no document on the structure and contents of the LTO file. OTOH, you can get this by reverse engineering the code to find out what it does. Further, it has been publicly stated that the format will evolve and is not going to be stable (though I don't recall where). Unless you want to fight to keep up with the format, this sounds like a major pain.


You might be interested in checking out LLVM: http://llvm.org/ which has a well defined and well specified file formats (one text and one binary), and preserves backwards compatibility with them across major release (i.e. 1.0 -> 1.9 and 2.0 -> 2.x). http://llvm.org/docs/ LangRef.html

I'd be interested to hear if keeping the LTO format stable is something the GCC community plans to do,

-Chris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]