Lines Matching refs:linker

14 interface and design between the LTO optimizer and the linker.
23 achieved through tight integration with the linker. In this model, the linker
25 matching among them. The linker uses `libLTO`_, a shared object, to handle LLVM
26 bitcode files. This tight integration between the linker and LLVM optimizer
27 helps to do optimizations that are not possible in other models. The linker
36 and clean interface. This example requires a system linker which supports LTO
38 invokes system linker.
94 * In this example, the linker recognizes that ``foo2()`` is an externally
95   visible symbol defined in LLVM bitcode file. The linker completes its usual
104 * And this in turn, enables linker to remove ``foo4()``.
107 linker. Here, the optimizer can not remove ``foo3()`` without the linker's
115     information collected during the linker's normal symbol resolution phase.
117     linker's input because it is externally visible. This in turn prohibits the
121     In this model, a new, separate, tool or library replicates the linker's
125     by the linker on various platform are not unique. This means, this new tool
129     also requires staying synchronized with linker developements on various
132     done by this separate tool and the linker itself.
134 Multi-phase communication between ``libLTO`` and linker
137 The linker collects information about symbol definitions and uses in various
139 tools during typical build cycles.  The linker collects this information by
141 symbol visibility information. The linker also uses user-supplied information,
145 integration between the linker and the optimizer by sharing this information
151 The linker first reads all object files in natural order and collects symbol
153 To minimize the cost to the linker in the case that all .o files are native
154 object files, the linker only calls ``lto_module_create()`` when a supplied
156 returns that the file is an LLVM bitcode file, the linker then iterates over the
159 This information is added to the linker's global symbol table.
163 the LLVM LTO code to be updated independently of the linker tool.  On platforms
169 In this stage, the linker resolves symbols using global symbol table.  It may
171 The linker is able to do this seamlessly even though it does not know the exact
173 linker collects the list of live symbols.
178 After symbol resolution, the linker tells the LTO shared object which symbols
179 are needed by native object files.  In the example above, the linker reports
181 ``lto_codegen_add_must_preserve_symbol()``.  Next the linker invokes the LLVM
189 In this phase, the linker reads optimized a native object file and updates the
190 internal global symbol table to reflect any changes. The linker also collects
192 files. In the example above, the linker notes that ``foo4()`` is not used any
193 more. If dead code stripping is enabled then the linker refreshes the live
196 After this phase, the linker continues linking as if it never saw LLVM bitcode
205 for use by a linker. ``libLTO`` provides an abstract C interface to use the LLVM
210 their object files and the standard linker tool.
216 functions allow the linker to check if a file (on disk or in a memory buffer) is
226 If the object file can be processed by ``libLTO``, the linker creates a
241 The linker can introspect the non-native object file by getting the number of
255 Once the linker has loaded each non-native object files into an
270 The linker then has the option of setting some codegen options.  Whether or not
290 After all these settings are done, the linker requests that a native object file
298 The linker then parses that and links it with the rest of the native object