Last updated: 03-Oct-2009

Status

The branch has been merged to trunk and is now closed.

Final merge announcement: http://gcc.gnu.org/ml/gcc/2009-10/msg00060.html

Background

Link Time Optimization (LTO) gives GCC the capability of dumping its internal representation (GIMPLE) to disk, so that all the different compilation units that make up a single executable can be optimized as a single module. This expands the scope of inter-procedural optimizations to encompass the whole program (or, rather, everything that is visible at link time).

This page contains information for this project, including design, implementation plan, status and TODO items. If you are interested in collaborating, please see the list of TODO items at the end of this page.

The project is being implemented in the lto SVN branch. To get the latest version:

$ svn co svn://gcc.gnu.org/svn/gcc/branches/lto

The usual rules for contributing to branches apply to this branch:

Messages and patches to the lists should have their subject prefixed with [lto]. ChangeLog entries should be written to ChangeLog.lto .

Requirements

The fundamental mechanism used by the compiler to delay optimization until link time is to write the GIMPLE representation of the program on special sections in the output file. For the initial implementation on the branch, ELF was chosen as the container format for these sections, but in GCC-4.6 support has been added on the trunk for PE-COFF and Mach-O. In order to use LTO the target must support one of these binary formats.

For PE-COFF and Mach-O a minimal binary reader/writer is implemented in GCC itself. For ELF, we are using libelf v0.8.12, but any relatively recent libelf implementation should work. Note that ELF is only required as the container format for GIMPLE, this does not mean that ELF must be used as the final executable format.

Despite the "link time" name, LTO does not need to use any special linker features. The basic mechanism needed is the detection of GIMPLE sections inside object files. This is currently implemented in collect2 . Therefore, LTO will work on any linker already supported by GCC.

As an added feature, LTO will take advantage of the plugin feature in gold. This allows the compiler to pick up object files that may have been stored in library archives. To use this feature, you must be using gold as the linker and enable the use of the plugin by compiling with gcc -fuse-linker-plugin . This will shift the responsibility of driving the final stages of compilation from collect2 to gold via the linker plugin.

Design

The following are some of the design documents and discussions for the basic functionality and cleanups:

Using LTO

Building the branch

To build the branch, make sure that you have libelf v0.8.12 installed.

$ svn co svn://gcc.gnu.org/svn/gcc/branches/lto $ mkdir bld && cd bld $ ../lto/configure --enable-lto && make

If you have libelf installed in a non-system directory, you also need to add --with-libelf=<path> to the configure line.

Using LTO

There are two main flags that enable LTO functionality.

-flto : This uses the main LTO features. When given several source files on the command line, it will write out the IL for each of them and then launch lto1 to load every function in every file. The reconstructed cgraph is then optimized as usual. $ gcc -flto -c f1.c $ gcc -flto -c f2.c $ gcc -flto -o f f1.o f2.o or $ gcc -flto -o f f1.c f2.c

-fwhopr : This is similar to -flto but it splits compilation to achieve scalability. It is intended to handle extremely large programs whose call graphs do not fit in memory. See the design document for details.

Issues left to address (TODO list)

If you are interested in working on any of these issues, please add your name to the item you are interested in and send mail to the list.