* 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

llvm-svn: 61072
This commit is contained in:
Misha Brukman 2008-12-16 03:07:49 +00:00
parent 129457e460
commit c6aef75cef
2 changed files with 86 additions and 44 deletions

View File

@ -85,7 +85,7 @@ conservative escape analysis.
<li> Input source file <tt>a.c</tt> is compiled into LLVM bitcode form.
<li> Input source file <tt>main.c</tt> is compiled into native object code.
</ul>
<div class="doc_code"><pre>
<pre class="doc_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 # &lt;-- a.o is LLVM bitcode file
$ llvm-gcc -c main.c -o main.o # &lt;-- main.o is native object file
$ llvm-gcc a.o main.o -o main # &lt;-- standard link command without any modifications
</pre></div>
</pre>
<p>In this example, the linker recognizes that <tt>foo2()</tt> 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 # &lt;-- standard link command without any modific
</div>
<div class="doc_text">
<p>A non-native object file is handled via an <tt>lto_module_t</tt>.
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: <pre>
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*)</pre>
If the object file can be processed by libLTO, the linker creates a
<tt>lto_module_t</tt> by using one of <pre>
lto_module_create(const char*)
lto_module_create_from_memory(const void*, size_t)</pre>
and when done, the handle is released via<pre>
lto_module_dispose(lto_module_t)</pre>
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: <pre>
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)</pre>
The attributes of a symbol include the alignment, visibility, and kind.
</p>
<p>A non-native object file is handled via an <tt>lto_module_t</tt>.
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:</p>
<pre class="doc_code">
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*)
</pre>
<p>If the object file can be processed by libLTO, the linker creates a
<tt>lto_module_t</tt> by using one of</p>
<pre class="doc_code">
lto_module_create(const char*)
lto_module_create_from_memory(const void*, size_t)
</pre>
<p>and when done, the handle is released via</p>
<pre class="doc_code">
lto_module_dispose(lto_module_t)
</pre>
<p>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:</p>
<pre class="doc_code">
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)
</pre>
<p>The attributes of a symbol include the alignment, visibility, and kind.</p>
</div>
<!-- ======================================================================= -->
@ -314,27 +330,45 @@ $ llvm-gcc a.o main.o -o main # &lt;-- standard link command without any modific
</div>
<div class="doc_text">
<p>Once the linker has loaded each non-native object files into an
<tt>lto_module_t</tt>, 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:<pre>
lto_codegen_create() </pre>
then each non-native object file is added to the code generator with:<pre>
lto_codegen_add_module(lto_code_gen_t, lto_module_t)</pre>
The linker then has the option of setting some codegen options. Whether
or not to generate DWARF debug info is set with: <pre>
lto_codegen_set_debug_model(lto_code_gen_t) </pre>
Which kind of position independence is set with: <pre>
lto_codegen_set_pic_model(lto_code_gen_t) </pre>
And each symbol that is referenced by a native object file or otherwise
must not be optimized away is set with: <pre>
lto_codegen_add_must_preserve_symbol(lto_code_gen_t, const char*)</pre>
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*)</pre>
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.
<p>Once the linker has loaded each non-native object files into an
<tt>lto_module_t</tt>, 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:</p>
<pre class="doc_code">lto_codegen_create()</pre>
<p>Then, each non-native object file is added to the code generator with:</p>
<pre class="doc_code">
lto_codegen_add_module(lto_code_gen_t, lto_module_t)
</pre>
<p>The linker then has the option of setting some codegen options. Whether or
not to generate DWARF debug info is set with:</p>
<pre class="doc_code">lto_codegen_set_debug_model(lto_code_gen_t)</pre>
<p>Which kind of position independence is set with:</p>
<pre class="doc_code">lto_codegen_set_pic_model(lto_code_gen_t) </pre>
<p>And each symbol that is referenced by a native object file or otherwise must
not be optimized away is set with:</p>
<pre class="doc_code">
lto_codegen_add_must_preserve_symbol(lto_code_gen_t, const char*)
</pre>
<p>After all these settings are done, the linker requests that a native object
file be created from the modules with the settings using:</p>
<pre class="doc_code">lto_codegen_compile(lto_code_gen_t, size*)</pre>
<p>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.</p>
</div>
<!-- *********************************************************************** -->

View File

@ -62,6 +62,7 @@ h3, .doc_subsubsection { margin: 2.0em 0.5em 0.5em 0.5em;
.doc_warning { color: red; font-weight: bold }
/* <div class="doc_code"> would use this class, and <div> 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 <pre class="doc_code"> everywhere instead of the
* <div class="doc_code"><pre>...</ptr></div> construct.
*
* Once all docs use <pre> 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; }