LTO Branch

[Mark Mitchell <mark at codesourcery dot com>]

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