From 04367bfc20c021c4105abf0c33b86d55f782d1e8 Mon Sep 17 00:00:00 2001 From: Gabor Greif Date: Fri, 6 Jul 2007 22:07:22 +0000 Subject: first pass of nomenclature changes in .html files git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37956 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/LinkTimeOptimization.html | 48 +++++++++++++++++++++--------------------- 1 file changed, 24 insertions(+), 24 deletions(-) (limited to 'docs/LinkTimeOptimization.html') diff --git a/docs/LinkTimeOptimization.html b/docs/LinkTimeOptimization.html index 1084e35..fdae78a 100644 --- a/docs/LinkTimeOptimization.html +++ b/docs/LinkTimeOptimization.html @@ -67,9 +67,9 @@ 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 +treates LLVM bitcode 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 +loaded library, to handle LLVM bitcode 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. @@ -87,7 +87,7 @@ conservative escape analysis. supports LTO through the interface described in this document. Here, llvm-gcc4 transparently invokes system linker. 

@@ -131,12 +131,12 @@ int main() {
 }
 
 --- command lines ---
-$ llvm-gcc4 --emit-llvm -c a.c -o a.o  # <-- a.o is LLVM bytecode file
+$ llvm-gcc4 --emit-llvm -c a.c -o a.o  # <-- a.o is LLVM bitcode 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 + externally visible symbol defined in LLVM bitcode 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 @@ -202,15 +202,15 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

- Phase 1 : Read LLVM Bytecode Files + Phase 1 : Read LLVM Bitcode Files

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 + symbol information. This includes native object files as well as LLVM bitcode + files. In this phase, the linker uses readLLVMObjectFile() to collect symbol - information from each LLVM bytecode files and updates its internal global + information from each LLVM bitcode 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 @@ -228,7 +228,7 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

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 + does not know the exact content of input LLVM bitcode files because it uses symbol information provided by readLLVMObjectFile(). If dead code stripping is enabled then the linker collects the list of live symbols. @@ -237,12 +237,12 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

- Phase 3 : Optimize Bytecode Files + Phase 3 : Optimize Bitcode Files

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 + by LLVM bitcode files appropriately. For example, whether certain LLVM + bitcode 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() @@ -260,12 +260,12 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

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 + LLVM bitcode 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.

+ bitcode files.

@@ -288,10 +288,10 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

The LLVMSymbol class is used to describe the externally visible - functions and global variables, defined in LLVM bytecode files, to the linker. + functions and global variables, defined in LLVM bitcode 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. + defined inside an LLVM bitcode 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 @@ -310,12 +310,12 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

The readLLVMObjectFile() function is used by the linker to read - LLVM bytecode files and collect LLVMSymbol information. This routine also - supplies a list of externally defined symbols that are used by LLVM bytecode + LLVM bitcode files and collect LLVMSymbol information. This routine also + supplies a list of externally defined symbols that are used by LLVM bitcode files. The linker uses this symbol information to do symbol resolution. - Internally, LLVMlto maintains LLVM bytecode modules in + Internally, LLVMlto maintains LLVM bitcode modules in memory. This function also provides a list of external references used by - bytecode files.

+ bitcode files.

@@ -325,7 +325,7 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

The linker invokes optimizeModules to optimize already read - LLVM bytecode files by applying LLVM intermodular optimization techniques. + LLVM bitcode 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.

@@ -338,7 +338,7 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

The linker may use getTargetTriple() to query target architecture - while validating LLVM bytecode file.

+ while validating LLVM bitcode file.

@@ -347,7 +347,7 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi
-

Internally, LLVMlto maintains LLVM bytecode modules in +

Internally, LLVMlto maintains LLVM bitcode modules in memory. The linker may use removeModule() method to remove desired modules from memory.

-- cgit v1.1