Lines Matching +full:- +full:- +full:files

24 treats LLVM bitcode files like native object files and allows mixing and
26 bitcode files. This tight integration between the linker and LLVM optimizer
30 .. _libLTO-example:
33 ---------------------------------
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
111 ----------------------
120 **Use separate tool to collect symbol information from all object files.**
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,
148 Phase 1 : Read LLVM Bitcode Files
149 ---------------------------------
151 The linker first reads all object files in natural order and collects symbol
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
154 object files, the linker only calls ``lto_module_create()`` when a supplied
167 ---------------------------
172 content of input LLVM bitcode files. If dead code stripping is enabled then the
175 Phase 3 : Optimize Bitcode Files
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 ----------------------------------------------
192 files. In the example above, the linker notes that ``foo4()`` is not used any
197 files.
210 their object files and the standard linker tool.
213 ----------------
215 A non-native object file is handled via an ``lto_module_t``. The following
219 .. code-block:: c
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
252 Tools working with object files on Darwin (e.g. lipo) may need to know properties like the CPU type:
254 .. code-block:: c
259 ------------------
261 Once the linker has loaded each non-native object files into an
266 .. code-block:: c
270 Then, each non-native object file is added to the code generator with:
272 .. code-block:: c
279 .. code-block:: c
285 .. code-block:: c
292 .. code-block:: c
299 .. code-block:: c
305 files.