Introduction

The LTO writer emits information required for link-time optimization in object files compiled with the -flto option. The LTO reader reads this information from object files compiled with this option.

The writer is part of the "middle end" of the compiler. Although the LTO project is focused initially on the C programming language, the writer is a language-independent component. As such, it does not rely on any data visible only to the C front end. The reader is part of the LTO front end.

Contents

  1. Introduction
  2. Storage Formats
  3. Global Entity Tasks
    1. Type and Declaration Attributes
      1. Type Information
      2. Declaration Information
    2. Variable Initializers
    3. Symbol-Table Construction

Storage Formats

In broad terms, information required for link-time optimization can be divided into two categories:

  1. Declarations for global entities
  2. Function bodies

The global-entities category includes all types (including types declared within a function), function declarations (including nested functions), and global variable declarations (including all variables at file scope and local variables declared with the "static" keyword in C). The function-body category includes all executable statements and expressions.

Much of the required information about global entities (including the names of objects, their sizes, types, and so forth) is available in the debugging information the compiler generates with -g. Therefore, global entity information is encoded in the DWARF 3 format, with extensions as necessary to represent information that is not normally useful to a debugger.

Function bodies are encoded using a special-purpose format well-suite to compactly encoding GCC's TREE format. The LTO writer never writes out RTL information; function bodies are always encodings of TREE.

Global Entity Tasks

Type and Declaration Attributes

GCC's DWARF generator does not presently encode all necessary information about global entities. For example, semantic GNU attributes (e.g., __attribute__((X))) where X is something that can affect the behavior of the program, are not encoded. Other information stored in various flags associated with TREE nodes is also not encoded. Therefore:

  1. DWARF extensions must be specified for all such information.
  2. The DWARF generator must be modified to encode this information.
  3. The LTO reader must be modified to restore this information.

Type Information

The following are not already present in the DWARF information for types:

At present, the LTO reader uses layout_type to recreate certain flags on types. Instead, all necessary information should be restored from the stored DWARF information.

Declaration Information

The following are not already present in the DWARF information for variables and functions:

It is not the case that we should just blindly create DWARF attributes for all of these fields. For example, the right way to represent DECL_INIT_PRIORITY is probably a DWARF attribute for that field, but the right way to represent DECL_HAS_INIT_PRIORITY is probably by the presence of absence of the DWARF attribute for DECL_INIT_PRIORITY rather than a separate bit. As another example, it may be possible to compute DECL_SECTION_NAME by looking at the ELF symbol table.

Variable Initializers

Initializers for variables with static storage duration are not represented in DWARF information because a debugger does not generally need this information. However, the information is of course present in object files. The information is represented as a combination of literal bytes (in the data section containing the variable, or, in the case of zero-initialized data, implicitly by the placement of the variable in an appropriate section) and relocations. The LTO reader must be modified to recover the initializers from data stored in object files. The reader must include processor-specific relocation processing. This processing can be provided via a back-end hook.

In order to locate variable initializers, the LTO reader will need to read the ELF symbol table. This information may also be useful in determining whether or not a function and/or variable is defined in the translation unit being read.

Symbol-Table Construction

DWARF information is a tree of nodes, beginning with a root node corresponding to an entire translation until. At present, the LTO front end makes a single depth-first pass over the DWARF tree. However, DWARF nodes may contain references to other nodes elsewhere in the tree which have not yet been encountered. Therefore, the LTO front end attempts to skip around in the tree processing nodes out of order. This approach is error-prone as parent nodes are required to provide appropriate context.

Therefore, the LTO front end should be modified to use a two-pass algorithm. The first pass will construct (incomplete) nodes for all global entities and enter them in the symbol table. The second pass will fill in the incomplete nodes. For example, on the first pass, when a DW_TAG_subprogram node is encountered:

  1. If the function has node already been declared, a new FUNCTION_DECL node is created, and its DECL_ASSEMBLER_NAME set appropriately. Other fields remain NULL_TREE.

  2. The child nodes of the DW_TAG_subprogram are walked.

On the second pass, when the same DW_TAG_subprogram node is encountered, all fields not already set are filled in.

None: LTO_Reader/Writer (last edited 2008-01-10 19:38:43 by localhost)