Lines Matching +full:- +full:- +full:native +full:- +full:file

24 treates LLVM bitcode files like native object files and allows mixing and
30 .. _libLTO-example:
33 ---------------------------------
40 * Input source file ``a.c`` is compiled into LLVM bitcode form.
41 * Input source file ``main.c`` is compiled into native object code.
43 .. code-block:: c++
45   --- a.h ---
50   --- a.c ---
56     i = -1;
74   --- main.c ---
88 .. code-block:: console
90   % clang -flto -c a.c -o a.o        # <-- a.o is LLVM bitcode file
91   % clang -c main.c -o main.o        # <-- main.o is native object file
92   % clang -flto a.o main.o -o main   # <-- standard link command with -flto
95   visible symbol defined in LLVM bitcode file. The linker completes its usual
111 ----------------------
134 Multi-phase communication between ``libLTO`` and linker
140 looking at the definitions and uses of symbols in native .o files and using
141 symbol visibility information. The linker also uses user-supplied information,
149 ---------------------------------
152 information. This includes native object files as well as LLVM bitcode files.
153 To minimize the cost to the linker in the case that all .o files are native
155 object file is found to not be a native object file.  If ``lto_module_create()``
156 returns that the file is an LLVM bitcode file, the linker then iterates over the
167 ---------------------------
176 --------------------------------
179 are needed by native object files.  In the example above, the linker reports
180 that only ``foo1()`` is used by native object files using
183 native object file creating by merging the LLVM bitcode files and applying
187 ----------------------------------------------
189 In this phase, the linker reads optimized a native object file and updates the
213 ----------------
215 A non-native object file is handled via an ``lto_module_t``.  The following
216 functions allow the linker to check if a file (on disk or in a memory buffer) is
217 a file which libLTO can process:
219 .. code-block:: c
226 If the object file can be processed by ``libLTO``, the linker creates a
229 .. code-block:: c
236 .. code-block:: c
241 The linker can introspect the non-native object file by getting the number of
244 .. code-block:: c
253 ------------------
255 Once the linker has loaded each non-native object files into an
257 native object file.  This is done in a couple of steps.  First, a code generator
260 .. code-block:: c
264 Then, each non-native object file is added to the code generator with:
266 .. code-block:: c
273 .. code-block:: c
279 .. code-block:: c
283 And each symbol that is referenced by a native object file or otherwise must not
286 .. code-block:: c
290 After all these settings are done, the linker requests that a native object file
293 .. code-block:: c
297 which returns a pointer to a buffer containing the generated native object file.
298 The linker then parses that and links it with the rest of the native object