Meta tags:
description=LTO Overview (GNU Compiler Collection (GCC) Internals);
keywords=LTO Overview (GNU Compiler Collection (GCC) Internals);

Headings (most frequently used words):

25, design, overview, lto, modes, of, operation,

Text of the page (most frequently used words):
the (73), lto (27), and (22), this (14), object (10), compilation (10), program (9), which (9), for (9), into (8), files (8), gcc (8), file (7), whopr (7), whole (6), link (6), support (6), mode (5), during (5), wpa (5), stage (5), compiler (5), are (5), time (5), executes (5), call (5), graph (5), optimization (5), with (5), that (5), when (4), partitioned (4), partitions (4), main (4), parallel (4), memory (4), local (4), all (4), phase (4), implemented (4), code (4), generated (4), not (4), pass (4), function (4), sections (4), representation (4), gimple (4), objects (4), callgraph (3), ltrans (3), most (3), single (3), been (3), decisions (3), global (3), intermediate (3), information (3), both (3), two (3), set (3), bytecode (3), overview (3), next (2), index (2), contents (2), layout (2), given (2), number (2), same (2), advantage (2), allow (2), execution (2), stages (2), can (2), has (2), read (2), final (2), performed (2), analysis (2), makes (2), contain (2), language (2), every (2), splits (2), cpus (2), distributed (2), large (2), different (2), optimized (2), source (2), level (2), unit (2), one (2), infrastructure (2), modes (2), half (2), reader (2), front (2), end (2), enabled (2), lto1 (2), flto (2), elf (2), streamer (2), out (2), passes (2), currently (2), could (2), plugin (2), fat (2), used (2), slim (2), tools (2), systems (2), web (2), org (2), gnu (2), sep (2), compiling, split, roughly, size, tries, minimize, references, cross, partition, boundaries, consuming, part, process, additionally, avoids, need, load, seen, extension, usual, executed, within, after, transformations, made, locally, each, optimizations, cannot, decided, efficiently, may, sequentially, procedure, transformation, facilitate, results, stored, new, expressed, generation, lgen, compiled, packaged, together, summary, three, designed, utilize, multiple, environment, quickly, applications, stands, optimizer, confused, semantics, aggregated, from, many, distributes, sub, graphs, note, yet, but, since, parallelism, facilitated, via, generating, would, easy, implement, makefile, fwhole, similar, way, were, goals, was, effective, programs, reason, implements, operation, second, detects, invokes, reads, aggregates, them, translation, entry, point, lto_main, collect2, takes, image, built, previous, encodes, corresponding, produce_asm_for_decls, pass_ipa_lto_finish_out, traverses, encoding, reachable, declaration, type, generates, described, below, lto_output, pass_ipa_lto_gimple_out, manager, composed, ipa, all_lto_gen_passes, highest, first, writer, produces, streaming, internal, data, structures, needed, optimize, generate, includes, declarations, types, bodies, also, saved, alongside, option, passed, detected, configured, larger, than, regular, format, allows, ship, development, production, builds, perhaps, surprising, side, effect, feature, any, mistake, toolchain, leads, being, older, calling, directly, system, more, robust, disadvantage, user, informed, disabled, libtool, ffat, default, only, such, called, they, require, like, understand, symbol, tables, targets, these, have, extended, use, consisting, alone, emitted, special, based, well, darwin, cygwin, mingw, design, wayback, machine, http, archive, 20220818183345, https, onlinedocs, gccint, html, timestamps, about, capture, fail, success, 2023, 2022, 2021, aug, jul, jan, 2013, 2026, 132, captures, collection, internals,

Text of the page (random words):
lto overview gnu compiler collection gcc internals 132 captures 15 jan 2013 17 sep 2026 jul aug sep 18 2021 2022 2023 success fail about this capture timestamps the wayback machine http web archive org web 20220818183345 https gcc gnu org onlinedocs gccint lto overview html next lto object file layout up lto contents index 25 1 design overview link time optimization is implemented as a gcc front end for a bytecode representation of gimple that is emitted in special sections of o files currently lto support is enabled in most elf based systems as well as darwin cygwin and mingw systems by default object files generated with lto support contain only gimple bytecode such objects are called slim and they require that tools like ar and nm understand symbol tables of lto sections for most targets these tools have been extended to use the plugin infrastructure so gcc can support slim objects consisting of the intermediate code alone gimple bytecode could also be saved alongside final object code if the ffat lto objects option is passed or if no plugin support is detected for ar and nm when gcc is configured it makes the object files generated with lto support larger than regular object files this fat object format allows to ship one set of fat objects which could be used both for development and the production of optimized builds a perhaps surprising side effect of this feature is that any mistake in the toolchain leads to lto information not being used e g an older libtool calling ld directly this is both an advantage as the system is more robust and a disadvantage as the user is not informed that the optimization has been disabled at the highest level lto splits the compiler in two the first half the writer produces a streaming representation of all the internal data structures needed to optimize and generate code this includes declarations types the callgraph and the gimple representation of function bodies when flto is given during compilation of a source file the pass manager executes all the passes in all_lto_gen_passes currently this phase is composed of two ipa passes pass_ipa_lto_gimple_out this pass executes the function lto_output in lto streamer out cc which traverses the call graph encoding every reachable declaration type and function this generates a memory representation of all the file sections described below pass_ipa_lto_finish_out this pass executes the function produce_asm_for_decls in lto streamer out cc which takes the memory image built in the previous pass and encodes it in the corresponding elf file sections the second half of lto support is the reader this is implemented as the gcc front end lto1 in lto lto cc when collect2 detects a link set of o a files with lto information and the flto is enabled it invokes lto1 which reads the set of files and aggregates them into a single translation unit for optimization the main entry point for the reader is lto lto cc lto_main 25 1 1 lto modes of operation one of the main goals of the gcc link time infrastructure was to allow effective compilation of large programs for this reason gcc implements two link time compilation modes lto mode in which the whole program is read into the compiler at link time and optimized in a similar way as if it were a single source level compilation unit whopr or partitioned mode designed to utilize multiple cpus and or a distributed compilation environment to quickly link large applications whopr stands for whole program optimizer not to be confused with the semantics of fwhole program it partitions the aggregated callgraph from many different o files and distributes the compilation of the sub graphs to different cpus note that distributed compilation is not implemented yet but since the parallelism is facilitated via generating a makefile it would be easy to implement whopr splits lto into three main stages local generation lgen this stage executes in parallel every file in the program is compiled into the intermediate language and packaged together with the local call graph and summary information this stage is the same for both the lto and whopr compilation mode whole program analysis wpa wpa is performed sequentially the global call graph is generated and a global analysis procedure makes transformation decisions the global call graph is partitioned to facilitate parallel optimization during phase 3 the results of the wpa stage are stored into new object files which contain the partitions of program expressed in the intermediate language and the optimization decisions local transformations ltrans this stage executes in parallel all the decisions made during phase 2 are implemented locally in each partitioned object file and the final object code is generated optimizations which cannot be decided efficiently during the phase 2 may be performed on the local call graph partitions whopr can be seen as an extension of the usual lto mode of compilation in lto wpa and ltrans are executed within a single execution of the compiler after the whole program has been read into memory when compiling in whopr mode the callgraph is partitioned during the wpa stage the whole program is split into a given number of partitions of roughly the same size the compiler tries to minimize the number of references which cross partition boundaries the main advantage of whopr is to allow the parallel execution of ltrans stages which are the most time consuming part of the compilation process additionally it avoids the need to load the whole program into memory next lto object file layout up lto contents index