From 64722e5163785da17ab581364c9655071b566180 Mon Sep 17 00:00:00 2001 From: Misha Brukman Date: Tue, 16 Dec 2008 03:07:49 +0000 Subject: * Comply with HTML 4.01 Strict * Added code-region markings to code sections to make them stand out * Added pre.doc_code class to llvm.css to simplify marking code regions git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61072 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/LinkTimeOptimization.html | 120 ++++++++++++++++++++++++++--------------- 1 file changed, 77 insertions(+), 43 deletions(-) (limited to 'docs/LinkTimeOptimization.html') diff --git a/docs/LinkTimeOptimization.html b/docs/LinkTimeOptimization.html index 83c774d..4bc92b2 100644 --- a/docs/LinkTimeOptimization.html +++ b/docs/LinkTimeOptimization.html @@ -85,7 +85,7 @@ conservative escape analysis.
  • Input source file a.c is compiled into LLVM bitcode form.
  • Input source file main.c is compiled into native object code. -
    +
     --- a.h ---
 extern int foo1(void);
 extern void foo2(void);
@@ -129,7 +129,7 @@ int main() {
 $ llvm-gcc --emit-llvm -c a.c -o a.o  # <-- a.o is LLVM bitcode file
 $ llvm-gcc -c main.c -o main.o # <-- main.o is native object file
 $ llvm-gcc 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 bitcode file. The linker completes its usual symbol resolution @@ -286,26 +286,42 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific

    -

    A non-native object file is handled via an lto_module_t. - The following functions allow the linker to check if a file (on disk - or in a memory buffer) is a file which libLTO can process: 

    -   lto_module_is_object_file(const char*)
-   lto_module_is_object_file_for_target(const char*, const char*)
-   lto_module_is_object_file_in_memory(const void*, size_t)
-   lto_module_is_object_file_in_memory_for_target(const void*, size_t, const char*)
    - If the object file can be processed by libLTO, the linker creates a - lto_module_t by using one of 
    -   lto_module_create(const char*)
-   lto_module_create_from_memory(const void*, size_t)
    - and when done, the handle is released via
    -   lto_module_dispose(lto_module_t)
    - The linker can introspect the non-native object file by getting the number - of symbols and getting the name and attributes of each symbol via: 
    -   lto_module_get_num_symbols(lto_module_t)
-   lto_module_get_symbol_name(lto_module_t, unsigned int)
-   lto_module_get_symbol_attribute(lto_module_t, unsigned int)
    - The attributes of a symbol include the alignment, visibility, and kind. -

    + +

    A non-native object file is handled via an lto_module_t. +The following functions allow the linker to check if a file (on disk +or in a memory buffer) is a file which libLTO can process:

    + +
    +lto_module_is_object_file(const char*)
+lto_module_is_object_file_for_target(const char*, const char*)
+lto_module_is_object_file_in_memory(const void*, size_t)
+lto_module_is_object_file_in_memory_for_target(const void*, size_t, const char*)
+
    + +

    If the object file can be processed by libLTO, the linker creates a +lto_module_t by using one of

    + +
    +lto_module_create(const char*)
+lto_module_create_from_memory(const void*, size_t)
+
    + +

    and when done, the handle is released via

    + +
    +lto_module_dispose(lto_module_t)
+
    + +

    The linker can introspect the non-native object file by getting the number of +symbols and getting the name and attributes of each symbol via:

    + +
    +lto_module_get_num_symbols(lto_module_t)
+lto_module_get_symbol_name(lto_module_t, unsigned int)
+lto_module_get_symbol_attribute(lto_module_t, unsigned int)
+
    + +

    The attributes of a symbol include the alignment, visibility, and kind.

    @@ -314,27 +330,45 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
    -

    Once the linker has loaded each non-native object files into an - lto_module_t, it can request libLTO to process them all and - generate a native object file. This is done in a couple of steps. - First a code generator is created with:

    -    lto_codegen_create()
    - then each non-native object file is added to the code generator with:
    -    lto_codegen_add_module(lto_code_gen_t, lto_module_t)
    - The linker then has the option of setting some codegen options. Whether - or not to generate DWARF debug info is set with: 
    -    lto_codegen_set_debug_model(lto_code_gen_t)
    - Which kind of position independence is set with: 
    -    lto_codegen_set_pic_model(lto_code_gen_t)
    - And each symbol that is referenced by a native object file or otherwise - must not be optimized away is set with: 
    -    lto_codegen_add_must_preserve_symbol(lto_code_gen_t, const char*)
    - After all these settings are done, the linker requests that a native - object file be created from the modules with the settings using: - lto_codegen_compile(lto_code_gen_t, size*) - which returns a pointer to a buffer containing the generated native - object file. The linker then parses that and links it with the rest - of the native object files. + +

    Once the linker has loaded each non-native object files into an +lto_module_t, it can request libLTO to process them all and +generate a native object file. This is done in a couple of steps. +First, a code generator is created with:

    + +
    lto_codegen_create()
    + +

    Then, each non-native object file is added to the code generator with:

    + +
    +lto_codegen_add_module(lto_code_gen_t, lto_module_t)
+
    + +

    The linker then has the option of setting some codegen options. Whether or +not to generate DWARF debug info is set with:

    + +
    lto_codegen_set_debug_model(lto_code_gen_t)
    + +

    Which kind of position independence is set with:

    + +
    lto_codegen_set_pic_model(lto_code_gen_t)
    + +

    And each symbol that is referenced by a native object file or otherwise must +not be optimized away is set with:

    + +
    +lto_codegen_add_must_preserve_symbol(lto_code_gen_t, const char*)
+
    + +

    After all these settings are done, the linker requests that a native object +file be created from the modules with the settings using:

    + +
    lto_codegen_compile(lto_code_gen_t, size*)
    + +

    which returns a pointer to a buffer containing the generated native +object file. The linker then parses that and links it with the rest +of the native object files.

    +
    -- cgit v1.1