LTO Driver

In order to make use of link-time optimization, some changes must be made to the GCC driver and related programs. This page describes the required changes.

Overview

Consider a simple program with two source files. In ordinary compilation, the build process is:

  1. Compile each source file to obtain the corresponding object files.
  2. Link the object files together to produce an executable.

In LTO mode, the compiler will insert additional information into the object files to permit link-time optimization. Then, at link-time, the compiler must be re-invoked. The compiler will read the various object files, optimize them, and produce a new object file to be used in place of the object file provided as input. So, the build process, when using link-time optimization, would be:

  1. Compile each source file to obtain the corresponding object files.
  2. Compile the object files (together) to produce an optimized object file.
  3. Link the (single) optimized object file.

In addition, for testing purposes, it is useful to perform link-time optimization on a single object file. In other words:

  1. Compile a source file to obtain the corresponding object file.
  2. Compile the object file to produce an optimized object file. That process allows us to test the LTO reader and writer without involving the LTO translation-unit merge mechanisms.

Compilation Options

If the -flto option is present when compiling, the compiler includes LTO information in all generated object files.For example:

generates object files a.o and b.o which include LTO information.

If the LTO "language" is selected (via -x lto) the driver invokes the LTO front-end, passing all non-option arguments (which should be object files) to the front-end. Thus:

generates a new object file c.o containing the (optimized and merged) contents of a.o and b.o.

For convenience when testing, the option -lto-test can be combined with -flto. This option causes the compiler to compile the file and then pass the resulting object file to the LTO front end. Thus,

is approximately equivalent to:

Linking Options

If the -flto option is present when linking, the driver will provide all object files in the link which include LTO information to the link-time optimizer. Then, when invoking the linker, the driver will replace the various object files with the new optimized object file. A GCC design principle is that it should be possible to use GCC with linkers other than the GNU linker. Therefore, the LTO link process should not require the use of the GNU linker. (It is of course acceptable for the link process to work better or to be more efficient when using the GNU linker.) Therefore, the behavior described above will be implemented using collect2, which is already capable of reinvoking the compiler at link-time to implement support for static initialization and destruction and for use of the template repository. When -flto is present, collect2 should perform all of the actions which it presently does (to resolve undefined symbols and to ensure that all necessary object files are available) and then: * Determine the set of object files to be included in the link which include LTO information.

  1. Invoke the driver with the -x lto option to optimize the object files containing LTO information.

  2. Invoke the linker with the optimized object file in place of the first object file including LTO information and with all other object files containing LTO information removed.

The LTO front end ensures that a symbol gnu_lto_v1 is defined in each object file so that collect2 can readily determine which files contain optimization information. However, determining the set of object files to be included in the link which include LTO information is non-trivial when archive files are taken into account. In particular, the rules about exactly which object files are extracted from an archive are complex and vary from system to system. For a first cut, collect2 should just ignore archives. Only actual object files should be examined for LTO information. When using the GNU linker, however, we can do better by adding an option to the GNU linker to print out the set of object files which will be extracted from archives to perform a link. Then, collect2 can add options of the form libfoo.a(bar.o) to the -x lto invocation and the LTO front end can extract these object files from the archive.

None: LTO_Driver (last edited 2008-01-10 19:38:45 by localhost)