From 64722e5163785da17ab581364c9655071b566180 Mon Sep 17 00:00:00 2001 From: Misha Brukman Date: Tue, 16 Dec 2008 03:07:49 +0000 Subject: [PATCH] * 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 +++++++++++++++++++++------------ docs/llvm.css | 10 ++- 2 files changed, 86 insertions(+), 44 deletions(-) diff --git a/docs/LinkTimeOptimization.html b/docs/LinkTimeOptimization.html index 83c774d09ba..4bc92b24424 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.

    +
    diff --git a/docs/llvm.css b/docs/llvm.css index e48f0a1a7c9..84af679f2e5 100644 --- a/docs/llvm.css +++ b/docs/llvm.css @@ -62,6 +62,7 @@ h3, .doc_subsubsection { margin: 2.0em 0.5em 0.5em 0.5em; .doc_warning { color: red; font-weight: bold } +/*
    would use this class, and
    adds more padding */ .doc_code, .literal-block { border: solid 1px gray; background: #eeeeee; margin: 0 1em 0 1em; @@ -69,6 +70,14 @@ h3, .doc_subsubsection { margin: 2.0em 0.5em 0.5em 0.5em; display: table; } +/* It is preferrable to use 
     everywhere instead of the
+ * 
    ...
     construct.
+ * 
+ * Once all docs use 
     for code regions, this style can  be merged with the
+ * one above, and we can drop the [pre] qualifier.
+ */
+pre.doc_code, .literal-block { padding: 1em 2em 1em 1em }
+
 .doc_notes      { background: #fafafa; border: 1px solid #cecece;
                   padding: 0.1em }
 
@@ -88,5 +97,4 @@ th.layout       { border: none; font-weight: bold; font-size: 105%;
 .title { margin-top: 0 }
 #contents { display: none }
 div.contents ul { list-style-type: decimal }
-.literal-block { padding: 1em 2em 1em 1em }
 .toc-backref    { color: black; text-decoration: none; }
-- 
2.34.1