llvm/docs/LinkTimeOptimization.rst

11 LLVM features powerful intermodular optimizations which can be used at link
14 interface and design between the LTO optimizer and the linker.
26 bitcode files. This tight integration between the linker and LLVM optimizer
28 input allows the optimizer to avoid relying on conservative escape analysis.
36 and clean interface. This example requires a system linker which supports LTO
97   anywhere. This information is used by the LLVM optimizer and it
100 * As soon as ``foo2()`` is removed, the optimizer recognizes that condition ``i
101   < 0`` is always false, which means ``foo3()`` is never used. Hence, the
102   optimizer also removes ``foo3()``.
107 linker. Here, the optimizer can not remove ``foo3()`` without the linker's
113 **Compiler driver invokes link time optimizer separately.**
114     In this model the link time optimizer is not able to take advantage of
116     In the above example, the optimizer can not remove ``foo2()`` without the
118     optimizer from removing ``foo3()``.
128     link time optimizer significantly, which is not necessary. This approach
130     platforms, which is not the main focus of the link time optimizer. Finally,
138 link objects which is more accurate than any information collected by other
142 such as a list of exported symbols. LLVM optimizer collects control flow
144 from the optimizer's point of view. Our goal is to take advantage of tight
145 integration between the linker and the optimizer by sharing this information
178 After symbol resolution, the linker tells the LTO shared object which symbols
182 optimizer and code generators using ``lto_codegen_compile()`` which returns a
206 interprocedural optimizer without exposing details of LLVM's internals. The
208 optimizer continues to evolve. It should even be possible for a completely
217 a file which libLTO can process:
283 which kind of position independence is set with:
303 which returns a pointer to a buffer containing the generated native object file.