-LLVM features powerful intermodular optimization which can be used at link time. -Link Time Optimization is another name of intermodular optimization when it -is done during link stage. This document describes the interface between LLVM -intermodular optimizer and the linker and its design. -
+LLVM features powerful intermodular optimizations which can be used at link +time. Link Time Optimization is another name for intermodular optimization +when performed during the link stage. This document describes the interface +and design between the LLVM intermodular optimizer and the linker.-The LLVM Link Time Optimizer seeks complete transparency, while doing intermodular -optimization, in compiler tool chain. Its main goal is to let developer take -advantage of intermodular optimizer without making any significant changes to -their makefiles or build system. This is achieved through tight integration with -linker. In this model, linker treates LLVM bytecode files like native objects -file and allows mixing and matching among them. The linker uses -LLVMlto, a dynamically loaded library, to handle LLVM bytecode -files. This tight integration between the linker and LLVM optimizer helps to do -optimizations that are not possible in other models. The linker input allows -optimizer to avoid relying on conservative escape analysis. +The LLVM Link Time Optimizer provides complete transparency, while doing +intermodular optimization, in the compiler tool chain. Its main goal is to let +the developer take advantage of intermodular optimizations without making any +significant changes to the developer's makefiles or build system. This is +achieved through tight integration with the linker. In this model, the linker +treates LLVM bytecode files like native object files and allows mixing and +matching among them. The linker uses LLVMlto, a dynamically +loaded library, to handle LLVM bytecode files. This tight integration between +the linker and LLVM optimizer helps to do optimizations that are not possible +in other models. The linker input allows the optimizer to avoid relying on +conservative escape analysis.
Following example illustrates advantage of integrated approach that uses -clean interface. -
+ The following example illustrates the advantages of LTO's integrated
+ approach and clean interface.
+
+ - Input source file a.c is compiled into LLVM byte code form.
+
- Input source file main.c is compiled into native object code.
+
+
--- a.h ---
-
extern int foo1(void);
-
extern void foo2(void);
-
extern void foo4(void);
-
--- a.c ---
-
#include "a.h"
-
-
static signed int i = 0;
-
-
void foo2(void) {
-
i = -1;
-
}
-
-
static int foo3() {
-
foo4();
-
return 10;
-
}
-
-
int foo1(void) {
-
int data = 0;
-
-
if (i < 0) { data = foo3(); }
-
-
data = data + 42;
-
return data;
-
}
-
-
--- main.c ---
-
#include <stdio.h>
-
#include "a.h"
-
-
void foo4(void) {
-
printf ("Hi\n");
-
}
-
-
int main() {
-
return foo1();
-
}
-
-
--- command lines ---
-
$ llvm-gcc4 --emit-llvm -c a.c -o a.o # <-- a.o is LLVM bytecode file
-
$ llvm-gcc4 -c main.c -o main.o # <-- main.o is native object file
-
$ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifications
-
-
--In this example, the linker recognizes that foo2() is a externally visible -symbol defined in LLVM byte code file. This information is collected using - readLLVMObjectFile() . Based on this -information, linker completes its usual symbol resolution pass and finds that -foo2() is not used anywhere. This information is used by LLVM optimizer -and it removes foo2(). As soon as foo2() is removed, optimizer -recognizes that condition i < 0 is always false, which means -foo3() is never used. Hence, optimizer removes foo3() also. -And this in turn, enables linker to remove foo4(). -This example illustrates advantage of tight integration with linker. Here, -optimizer can not remove foo3() without the linker's input. -
+extern int foo1(void); +extern void foo2(void); +extern void foo4(void); +--- a.c --- +#include "a.h" + +static signed int i = 0; + +void foo2(void) { + i = -1; +} + +static int foo3() { +foo4(); +return 10; +} + +int foo1(void) { +int data = 0; + +if (i < 0) { data = foo3(); } + +data = data + 42; +return data; +} + +--- main.c --- +#include <stdio.h> +#include "a.h" + +void foo4(void) { + printf ("Hi\n"); +} + +int main() { + return foo1(); +} + +--- command lines --- +$ llvm-gcc4 --emit-llvm -c a.c -o a.o # <-- a.o is LLVM bytecode file +$ llvm-gcc4 -c main.c -o main.o # <-- main.o is native object file +$ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifications + +In this example, the linker recognizes that foo2() is an + externally visible symbol defined in LLVM byte code file. This information + is collected using readLLVMObjectFile(). + Based on this information, the linker completes its usual symbol resolution + pass and finds that foo2() is not used anywhere. This information + is used by the LLVM optimizer and it removes foo2(). As soon as + foo2() is removed, the optimizer recognizes that condition + i < 0 is always false, which means foo3() is never + used. Hence, the optimizer removes foo3(), also. And this in turn, + enables linker to remove foo4(). This example illustrates the + advantage of tight integration with the linker. Here, the optimizer can not + remove foo3() without the linker's input. +
-
-The linker collects information about symbol defininitions and uses in various -link objects which is more accurate than any information collected by other tools -during typical build cycle. -The linker collects this information by looking at definitions and uses of -symbols in native .o files and using symbol visibility information. The linker -also uses user supplied information, such as list of exported symbol. -LLVM optimizer collects control flow information, data flow information and -knows much more about program structure from optimizer's point of view. Our -goal is to take advantage of tight intergration between the linker and -optimizer by sharing this information during various linking phases. +
The linker collects information about symbol defininitions and uses in + various link objects which is more accurate than any information collected + by other tools during typical build cycles. The linker collects this + information by looking at the definitions and uses of symbols in native .o + files and using symbol visibility information. The linker also uses + user-supplied information, such as a list of exported symbols. LLVM + optimizer collects control flow information, data flow information and knows + much more about program structure from the optimizer's point of view. + Our goal is to take advantage of tight intergration between the linker and + the optimizer by sharing this information during various linking phases.
-The linker first reads all object files in natural order and collects symbol -information. This includes native object files as well as LLVM byte code files. -In this phase, the linker uses readLLVMObjectFile() -to collect symbol information from each LLVM bytecode files and updates its -internal global symbol table accordingly. The intent of this interface is to -avoid overhead in the non LLVM case, where all input object files are native -object files, by putting this code in the error path of the linker. When the -linker sees the first llvm .o file, it dlopen()s the dynamic library. This is -to allow changes to LLVM part without relinking the linker. +
The linker first reads all object files in natural order and collects + symbol information. This includes native object files as well as LLVM byte + code files. In this phase, the linker uses + readLLVMObjectFile() to collect symbol + information from each LLVM bytecode files and updates its internal global + symbol table accordingly. The intent of this interface is to avoid overhead + in the non LLVM case, where all input object files are native object files, + by putting this code in the error path of the linker. When the linker sees + the first llvm .o file, it dlopen()s the dynamic library. This is + to allow changes to the LLVM LTO code without relinking the linker.
-In this stage, the linker resolves symbols using global symbol table information -to report undefined symbol errors, read archive members, resolve weak -symbols etc... The linker is able to do this seamlessly even though it does not -know exact content of input LLVM bytecode files because it uses symbol information -provided by readLLVMObjectFile() . -If dead code stripping is enabled then linker collects list of live symbols. -
+In this stage, the linker resolves symbols using global symbol table + information to report undefined symbol errors, read archive members, resolve + weak symbols, etc. The linker is able to do this seamlessly even though it + does not know the exact content of input LLVM bytecode files because it uses + symbol information provided by + readLLVMObjectFile(). If dead code + stripping is enabled then the linker collects the list of live symbols. +
-After symbol resolution, the linker updates symbol information supplied by LLVM -bytecode files appropriately. For example, whether certain LLVM bytecode -supplied symbols are used or not. In the example above, the linker reports -that foo2() is not used anywhere in the program, including native .o -files. This information is used by LLVM interprocedural optimizer. The -linker uses optimizeModules() and requests -optimized native object file of the LLVM portion of the program. +
After symbol resolution, the linker updates symbol information supplied + by LLVM bytecode files appropriately. For example, whether certain LLVM + bytecode supplied symbols are used or not. In the example above, the linker + reports that foo2() is not used anywhere in the program, including + native .o files. This information is used by the LLVM interprocedural + optimizer. The linker uses optimizeModules() + and requests an optimized native object file of the LLVM portion of the + program.
-In this phase, the linker reads optimized native object file and updates internal
-global symbol table to reflect any changes. Linker also collects information
-about any change in use of external symbols by LLVM bytecode files. In the examle
-above, the linker notes that foo4() is not used any more. If dead code
-striping is enabled then linker refreshes live symbol information appropriately
-and performs dead code stripping.
-
-After this phase, the linker continues linking as if it never saw LLVM bytecode
-files.
-
In this phase, the linker reads optimized a native object file and + updates the internal global symbol table to reflect any changes. The linker + also collects information about any changes in use of external symbols by + LLVM bytecode files. In the examle above, the linker notes that + foo4() is not used any more. If dead code stripping is enabled then + the linker refreshes the live symbol information appropriately and performs + dead code stripping.
+After this phase, the linker continues linking as if it never saw LLVM + bytecode files.
-LLVMlto is a dynamic library that is part of the LLVM tools, and is -intended for use by a linker. LLVMlto provides an abstract C++ interface -to use the LLVM interprocedural optimizer without exposing details of LLVM -internals. The intention is to keep the interface as stable as possible even -when the LLVM optimizer continues to evolve. -
+LLVMlto is a dynamic library that is part of the LLVM tools, and + is intended for use by a linker. LLVMlto provides an abstract C++ + interface to use the LLVM interprocedural optimizer without exposing details + of LLVM's internals. The intention is to keep the interface as stable as + possible even when the LLVM optimizer continues to evolve.
-LLVMSymbol class is used to describe the externally visible functions -and global variables, tdefined in LLVM bytecode files, to linker. -This includes symbol visibility information. This information is used by linker -to do symbol resolution. For example : function foo2() is defined inside -a LLVM bytecode module and it is externally visible symbol. -This helps linker connect use of foo2() in native object file with -future definition of symbol foo2(). The linker will see actual definition -of foo2() when it receives optimized native object file in -Symbol Resolution after optimization phase. If the linker does not find any -use of foo2(), it updates LLVMSymbol visibility information to notify -LLVM intermodular optimizer that it is dead. The LLVM intermodular optimizer -takes advantage of such information to generate better code. -
+The LLVMSymbol class is used to describe the externally visible + functions and global variables, defined in LLVM bytecode files, to the linker. + This includes symbol visibility information. This information is used by + the linker to do symbol resolution. For example: function foo2() is + defined inside an LLVM bytecode module and it is an externally visible symbol. + This helps the linker connect the use of foo2() in native object + files with a future definition of the symbol foo2(). The linker + will see the actual definition of foo2() when it receives the + optimized native object file in + Symbol Resolution after optimization phase. If the + linker does not find any uses of foo2(), it updates LLVMSymbol + visibility information to notify LLVM intermodular optimizer that it is dead. + The LLVM intermodular optimizer takes advantage of such information to + generate better code.
-readLLVMObjectFile() is used by the linker to read LLVM bytecode files
-and collect LLVMSymbol nformation. This routine also
-supplies list of externally defined symbols that are used by LLVM bytecode
-files. Linker uses this symbol information to do symbol resolution. Internally,
-LLVMlto maintains LLVM bytecode modules in memory. This
-function also provides list of external references used by bytecode file.
-
The readLLVMObjectFile() function is used by the linker to read + LLVM bytecode files and collect LLVMSymbol nformation. This routine also + supplies a list of externally defined symbols that are used by LLVM bytecode + files. The linker uses this symbol information to do symbol resolution. + Internally, LLVMlto maintains LLVM bytecode modules in + memory. This function also provides a list of external references used by + bytecode files.
-The linker invokes optimizeModules to optimize already read LLVM -bytecode files by applying LLVM intermodular optimization techniques. This -function runs LLVM intermodular optimizer and generates native object code -as .o file at name and location provided by the linker. -
+The linker invokes optimizeModules to optimize already read + LLVM bytecode files by applying LLVM intermodular optimization techniques. + This function runs the LLVM intermodular optimizer and generates native + object code as .o files at the name and location provided by the + linker.
... incomplete ...
+... To be completed ...