Introduction
In order to accommodate link-time optimization, some changes must be made to the internal representation used by GCC. In particular:
- Because the LTO front end can be used with input object files compiled with different programming languages, the meaning of all TREE constructs read in by the LTO reader must be language-independent.
All use of RTL for global variables, function parameters, and so forth, must be delayed (or made redundant) until the compiler begins converting TREE to RTL.
Language-Independent Representation
It is no longer acceptable to have interpretation of TREE depend on front-end variables or front-end hooks. While, at least in theory, it is still acceptable to have the interpretation depend on some back-end variables or hooks, as a single back end will be used for all input object files, it is desirable to make the TREE representation complete. It is not true that all front-end hooks must be removed from GCC. Hooks that are used only during the construction of TREE, but are not required to interpret GIMPLE, may remain.
In the short term, interpretation dependencies on middle-end and back-end hooks (or variables) can be ignored. Instead, the LTO reader will assume that all middle-end and back-end options will have the same values during initial compilation (with -flto) and during link-time optimization.
C Front End Hooks
This section lists all C front end hooks, categorizing them as to whether or not they affect the interpretation of GIMPLE. The set of hooks defined by the C front end can be determined by looking at c-lang.c and c-objc-common.h.
All hooks defined by the C front end should be listed in either the first or second list below. All hooks were originally placed in the first list. If you determine that a particular hook does not affect the interpretation of GIMPLE, please move it to the second list, together with a rationale. If you completely eliminate a hook, then you may simply remove it from the list in which it is defined.
The C front end defines the following hooks which may affect interpretation of GIMPLE:
FINISH
INIT_OPTIONS
INITIALIZE_DIAGNOSTICS
HANDLE_OPTION
MISSING_ARGUMENT
POST_OPTIONS
GET_ALIAS_SET
EXPAND_EXPR
EXPAND_DECL
MARK_ADDRESSABLE
PARSE_FILE
FINISH_INCOMPLETE_DECL
REDUCE_BIT_FIELD_OPERATIONS
NO_BODY_BLOCKS
WARN_UNUSED_GLOBAL_DECL
PRINT_IDENTIFIER TYPES_COMPATIBLE_P
FUNCTION_ENTER_NESTED
FUNCTION_LEAVE_NESTED
FUNCTION_MISSING_NORETURN_OK_P
DUP_LANG_SPECIFIC_DECL
BUILTIN_FUNCTION
COMMON_ATTRIBUTE_TABLE
FORMAT_ATTRIBUTE_TABLE
TREE_INLINING_CANNOT_INLINE_TREE_FN
TREE_INLINING_DISREGARD_INLINE_LIMITS
TREE_INLINING_CONVERT_PARM_FOR_INLINING
TREE_DUMP_DUMP_TREE_FN
CALLGRAPH_EXPAND_FUNCTION
TYPE_FOR_MODE
TYPE_FOR_SIZE
SIGNED_TYPE
SIGNED_OR_UNSIGNED_TYPE
INCOMPLETE_TYPE_ERROR
TYPE_PROMOTES_TO
REGISTER_BUILTIN_TYPE
TO_TARGET_CHARSET
EXPR_TO_DECL
GETDECLS
WRITE_GLOBALS
GIMPLIFY_EXPR
OMP_PREDETERMINED_SHARING
TREE_INLINING_VAR_MOD_TYPE_P
NAME
INIT
The C front end defines the following hooks which do not affect interpretation of GIMPLE:
IDENTIFIER_SIZE
This hook is only use to compute the size to use when allocating an IDENTIFIER_NODE.
STATICP
The only case handled by this hook is COMPOUND_LITERAL_EXPR which is eliminated during before GIMPLE.
Early RTL Generation
Because the compiler used to generate RTL after processing each statement, various parts of the compiler still generate RTL early in the compilation process. The LTO reader is not capable of restoring RTL information. Therefore, all RTL information will be discarded by the LTO writer. In theory, as long as equivalent RTL can be regenerated by the LTO reader (by, for example, invoking make_decl_rtl) the early generation of RTL need not be eliminated. However, it is desirable that the LTO writer be able to assert that all RTL fields it encounters are NULL_RTX, as that will eliminate any mismatches. In addition, early generation of RTL is wasteful.