After the LTO proposal (http://gcc.gnu.org/projects/lto/lto.pdf) was posted, a fruitful discussion ensued. One of the key topics that arose was the the possibility of using LLVM instead of the TREE-SSA optimizers. Things have quieted down on the public lists since then, but the need for link-time optimization hasn't gone away -- so it's time to get moving!
We have had some very useful discussions with Chris Lattner and other folks at Apple. Our conclusion is that LLVM does indeed have a very clean design and is very promising technology, but that there is still a lot of technical work to do before LLVM could be incorporated into GCC. We also fear that wholesale conversion to LLVM would likely be disruptive, just as introducing TREE-SSA was disruptive. In addition, the copyright issues around LLVM have not yet been resolved, and there is no ETA for that resolution. So, we plan to begin implementation of the LTO proposal. We certainly intend to borrow from LLVM's design and be informed by its strengths. When LLVM licensing issues are resolved, GCC may gradually incorporate bits of LLVM, including generation of LLVM bytecodes for use with the LLVM JIT. Some of the design elements of LLVM are clearly attractive, if not essential, for LTO. For example, having a serializable IR (as does LLVM, and as do many other compilers) is a sine qua non. Complete expression of the input program in the IR (rather than via langhooks or global variables) is at least highly desirable, if not essential. We've now created branches/lto in the GCC repository to start doing LTO work, beginning with: 1. Writing/reading function bodies to disk. 2. Writing/reading declarative entities (as DWARF3) to/from disk. 3. As Diego has previously outlined, cleaning up our IR, with a focus on both memory usage and completeness of representation. Then, we'll work on: 4. Merging entities from distinct translation units. 5. Teaching the driver to re-invoke the compiler at link-time. This is a big project, and we're looking for help! We're planning on working on more detailed designs for the various components, and we'll be looking for feedback as we go. -- David Edelsohn Mark Mitchell Diego Novillo Ian Taylor Kenny Zadeck