mirror of
https://github.com/RPCS3/llvm.git
synced 2024-12-04 17:58:22 +00:00
362 lines
14 KiB
HTML
362 lines
14 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
|
||
|
|
"http://www.w3.org/TR/html4/strict.dtd">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<title>LLVM Link Time Optimization: design and implementation</title>
|
||
|
|
<link rel="stylesheet" href="llvm.css" type="text/css">
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<div class="doc_title">
|
||
|
|
LLVM Link Time Optimization: design and implentation
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#desc">Description</a></li>
|
||
|
|
<li><a href="#design">Design Philosophy</a>
|
||
|
|
<ul>
|
||
|
|
<li><a href="#example1">Example of link time optimization</a></li>
|
||
|
|
<li><a href="#alternative_approaches">Alternative Approaches</a></li>
|
||
|
|
</ul></li>
|
||
|
|
<li><a href="#multiphase">Multi-phase communication between LLVM and linker</a></li>
|
||
|
|
<ul>
|
||
|
|
<li><a href="#phase1">Phase 1 : Read LLVM Bytecode Files</a></li>
|
||
|
|
<li><a href="#phase2">Phase 2 : Symbol Resolution</a></li>
|
||
|
|
<li><a href="#phase3">Phase 3 : Optimize Bytecode Files</a></li>
|
||
|
|
<li><a href="#phase4">Phase 4 : Symbol Resolution after optimization</a></li>
|
||
|
|
</ul></li>
|
||
|
|
<li><a href="#lto">LLVMlto</a></li>
|
||
|
|
<ul>
|
||
|
|
<li><a href="#llvmsymbol">LLVMSymbol</a></li>
|
||
|
|
<li><a href="#readllvmobjectfile">readLLVMObjectFile()</a></li>
|
||
|
|
<li><a href="#optimizemodules">optimizeModules()</a></li>
|
||
|
|
</ul>
|
||
|
|
<li><a href="#debug">Debugging Information</a></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<div class="doc_author">
|
||
|
|
<p>Written by Devang Patel</a></p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- *********************************************************************** -->
|
||
|
|
<div class="doc_section">
|
||
|
|
<a name="desc">Description</a>
|
||
|
|
</div>
|
||
|
|
<!-- *********************************************************************** -->
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
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.
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- *********************************************************************** -->
|
||
|
|
<div class="doc_section">
|
||
|
|
<a name="design">Design Philosophy</a>
|
||
|
|
</div>
|
||
|
|
<!-- *********************************************************************** -->
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
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
|
||
|
|
<a href="#lto">LLVMlto</a>, 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.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<!-- ======================================================================= -->
|
||
|
|
<div class="doc_subsection">
|
||
|
|
<a name="example1">Example of link time optimization</a>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
|
||
|
|
<p>Following example illustrates advantage of integrated approach that uses
|
||
|
|
clean interface.
|
||
|
|
<li> Input source file <tt>a.c</tt> is compiled into LLVM byte code form.
|
||
|
|
<li> Input source file <tt>main.c</tt> is compiled into native object code.
|
||
|
|
<br>
|
||
|
|
<code>
|
||
|
|
<br>--- a.h ---
|
||
|
|
<br>extern int foo1(void);
|
||
|
|
<br>extern void foo2(void);
|
||
|
|
<br>extern void foo4(void);
|
||
|
|
<br>--- a.c ---
|
||
|
|
<br>#include "a.h"
|
||
|
|
<br>
|
||
|
|
<br>static signed int i = 0;
|
||
|
|
<br>
|
||
|
|
<br>void foo2(void) {
|
||
|
|
<br> i = -1;
|
||
|
|
<br>}
|
||
|
|
<br>
|
||
|
|
<br>static int foo3() {
|
||
|
|
<br>foo4();
|
||
|
|
<br>return 10;
|
||
|
|
<br>}
|
||
|
|
<br>
|
||
|
|
<br>int foo1(void) {
|
||
|
|
<br>int data = 0;
|
||
|
|
<br>
|
||
|
|
<br>if (i < 0) { data = foo3(); }
|
||
|
|
<br>
|
||
|
|
<br>data = data + 42;
|
||
|
|
<br>return data;
|
||
|
|
<br>}
|
||
|
|
<br>
|
||
|
|
<br>--- main.c ---
|
||
|
|
<br>#include <stdio.h>
|
||
|
|
<br>#include "a.h"
|
||
|
|
<br>
|
||
|
|
<br>void foo4(void) {
|
||
|
|
<br> printf ("Hi\n");
|
||
|
|
<br>}
|
||
|
|
<br>
|
||
|
|
<br>int main() {
|
||
|
|
<br> return foo1();
|
||
|
|
<br>}
|
||
|
|
<br>
|
||
|
|
<br>--- command lines ---
|
||
|
|
<br> $ llvm-gcc4 --emit-llvm -c a.c -o a.o # <-- a.o is LLVM bytecode file
|
||
|
|
<br> $ llvm-gcc4 -c main.c -o main.o # <-- main.o is native object file
|
||
|
|
<br> $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifications
|
||
|
|
<br>
|
||
|
|
</code>
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
In this example, the linker recognizes that <tt>foo2()</tt> is a externally visible
|
||
|
|
symbol defined in LLVM byte code file. This information is collected using
|
||
|
|
<a href=#lreadllvmbytecodefile> readLLVMByteCodeFile() </a>. Based on this
|
||
|
|
information, linker completes its usual symbol resolution pass and finds that
|
||
|
|
<tt>foo2()</tt> is not used anywhere. This information is used by LLVM optimizer
|
||
|
|
and it removes <tt>foo2()</tt>. As soon as <tt>foo2()</tt> is removed, optimizer
|
||
|
|
recognizes that condition <tt> i < 0 </tt> is always false, which means
|
||
|
|
<tt>foo3()</tt> is never used. Hence, optimizer removes <tt>foo3()</tt> also.
|
||
|
|
And this in turn, enables linker to remove <tt>foo4()</tt>.
|
||
|
|
This example illustrates advantage of tight integration with linker. Here,
|
||
|
|
optimizer can not remove <tt>foo3()</tt> without the linker's input.
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- ======================================================================= -->
|
||
|
|
<div class="doc_subsection">
|
||
|
|
<a name="alternative_approaches">Alternative Approaches</a>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
<li> Compiler driver invokes link time optimizer separately.
|
||
|
|
<br><br>In this model link time optimizer is not able to take advantage of information
|
||
|
|
collected during normal linker's symbol resolution phase. In above example,
|
||
|
|
optimizer can not remove <tt>foo2()</tt> without linker's input because it is
|
||
|
|
externally visible. And this in turn prohibits optimizer from removing <tt>foo3()</tt>.
|
||
|
|
<br><br>
|
||
|
|
<li> Use separate tool to collect symbol information from all object file.
|
||
|
|
<br><br>In this model, this new separate tool or library replicates linker's
|
||
|
|
capabilities to collect information for link time optimizer. Not only such code
|
||
|
|
duplication is difficult to justify but it also has several other disadvantages.
|
||
|
|
For example, the linking semantics and the features provided by linker on
|
||
|
|
various platform are not unique. This means, this new tool needs to support all
|
||
|
|
such features and platforms in one super tool or one new separate tool per
|
||
|
|
platform is required. This increases maintance cost for link time optimizer
|
||
|
|
significantly, which is not necessary. Plus, this approach requires staying
|
||
|
|
synchronized with linker developements on various platforms, which is not the
|
||
|
|
main focus of link time optimizer. Finally, this approach increases end user's build
|
||
|
|
time due to duplicate work done by this separate tool and linker itself.
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- *********************************************************************** -->
|
||
|
|
<div class="doc_section">
|
||
|
|
<a name="multiphase">Multi-phase communication between LLVM and linker</a>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
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.
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- ======================================================================= -->
|
||
|
|
<div class="doc_subsection">
|
||
|
|
<a name="phase1">Phase 1 : Read LLVM Bytecode Files</a>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
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 <a href=#lreadllvmbytecodefile> readLLVMByteCodeFile() </a>
|
||
|
|
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.
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- ======================================================================= -->
|
||
|
|
<div class="doc_subsection">
|
||
|
|
<a name="phase2">Phase 2 : Symbol Resolution</a>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
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 <a href=#lreadllvmbytecodefile> readLLVMByteCodeFile() </a>.
|
||
|
|
If dead code stripping is enabled then linker collects list of live symbols.
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- ======================================================================= -->
|
||
|
|
<div class="doc_subsection">
|
||
|
|
<a name="phase3">Phase 3 : Optimize Bytecode Files</a>
|
||
|
|
</div>
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
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 <tt>foo2()</tt> is not used anywhere in the program, including native .o
|
||
|
|
files. This information is used by LLVM interprocedural optimizer. The
|
||
|
|
linker uses <a href="#optimizemodules"> optimizeModules()</a> and requests
|
||
|
|
optimized native object file of the LLVM portion of the program.
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- ======================================================================= -->
|
||
|
|
<div class="doc_subsection">
|
||
|
|
<a name="phase4">Phase 4 : Symbol Resolution after optimization</a>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
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 <tt>foo4()</tt> is not used any more. If dead code
|
||
|
|
striping is enabled then linker refreshes live symbol information appropriately
|
||
|
|
and performs dead code stripping.
|
||
|
|
<br>
|
||
|
|
After this phase, the linker continues linking as if it never saw LLVM bytecode
|
||
|
|
files.
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- *********************************************************************** -->
|
||
|
|
<div class="doc_section">
|
||
|
|
<a name="lto">LLVMlto</a>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
<tt>LLVMlto</tt> is a dynamic library that is part of the LLVM tools, and is
|
||
|
|
intended for use by a linker. <tt>LLVMlto</tt> 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.
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- ======================================================================= -->
|
||
|
|
<div class="doc_subsection">
|
||
|
|
<a name="llvmsymbol">LLVMSymbol</a>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
<tt>LLVMSymbol</tt> 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 <tt>foo2()</tt> is defined inside
|
||
|
|
a LLVM bytecode module and it is externally visible symbol.
|
||
|
|
This helps linker connect use of <tt>foo2()</tt> in native object file with
|
||
|
|
future definition of symbol <tt>foo2()</tt>. The linker will see actual definition
|
||
|
|
of <tt>foo2()</tt> when it receives optimized native object file in <a href="#phase4">
|
||
|
|
Symbol Resolution after optimization</a> phase. If the linker does not find any
|
||
|
|
use of <tt>foo2()</tt>, 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.
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- ======================================================================= -->
|
||
|
|
<div class="doc_subsection">
|
||
|
|
<a name="readllvmobjectfile">readLLVMObjectFile()</a>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
<tt>readLLVMObjectFile()</tt> 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,
|
||
|
|
<a href="#lto">LLVMlto</a> maintains LLVM bytecode modules in memory. This
|
||
|
|
function also provides list of external references used by bytecode file.<br>
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- ======================================================================= -->
|
||
|
|
<div class="doc_subsection">
|
||
|
|
<a name="optimizemodules">optimizeModules()</a>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
<p>
|
||
|
|
The linker invokes <tt>optimizeModules</tt> 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.
|
||
|
|
</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- *********************************************************************** -->
|
||
|
|
<div class="doc_section">
|
||
|
|
<a name="debug">Debugging Information</a>
|
||
|
|
</div>
|
||
|
|
<!-- *********************************************************************** -->
|
||
|
|
|
||
|
|
<div class="doc_text">
|
||
|
|
|
||
|
|
<p><tt> ... incomplete ... </tt></p>
|
||
|
|
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<!-- *********************************************************************** -->
|
||
|
|
|
||
|
|
<hr>
|
||
|
|
<address>
|
||
|
|
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
|
||
|
|
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
|
||
|
|
<a href="http://validator.w3.org/check/referer"><img
|
||
|
|
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
|
||
|
|
|
||
|
|
Devang Patel</a><br>
|
||
|
|
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
|
||
|
|
Last modified: $Date$
|
||
|
|
</address>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|