Lines Matching refs:optimizer

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.
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
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,
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
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