Make use of the doc_author and doc_code styles. <tt>'ify llvm names. Minor

other edits

llvm-svn: 13760
This commit is contained in:
Chris Lattner 2004-05-25 17:44:58 +00:00
parent 660ea5fadb
commit e7d5ec2b68
1 changed files with 14 additions and 12 deletions

View File

@ -38,10 +38,9 @@
</ol> </ol>
</li> </li>
</ol> </ol>
<div class="doc_text"> <div class="doc_author">
<p><b>Written by <a href="mailto:rspencer@x10sys.com">Reid Spencer</a> <p>Written by <a href="mailto:rspencer@x10sys.com">Reid Spencer</a>
and <a href="mailto:sabre@nondot.org">Chris Lattner</a></b></p> </p>
<p> </p>
</div> </div>
<!-- *********************************************************************** --> <!-- *********************************************************************** -->
<div class="doc_section"> <a name="abstract">Abstract </a></div> <div class="doc_section"> <a name="abstract">Abstract </a></div>
@ -128,13 +127,16 @@ Values. Since the bytecode file is a <em>direct</em> representation of LLVM's
intermediate representation, there is a need to represent pointers in the file. intermediate representation, there is a need to represent pointers in the file.
Slots are used for this purpose. For example, if one has the following assembly: Slots are used for this purpose. For example, if one has the following assembly:
</p> </p>
<pre><code>
%MyType = type { int, sbyte }; <div class="doc_code">
%MyVar = external global %MyType ; %MyType = type { int, sbyte }<br>
</code></pre> %MyVar = external global %MyType
<p>there are two definitions. The definition of %MyVar uses %MyType and %MyType </div>
is used by %MyVar. In the C++ IR this linkage between %MyVar and %MyType is
made explicitly by the use of C++ pointers. In bytecode, however, there's no <p>there are two definitions. The definition of <tt>%MyVar</tt> uses
<tt>%MyType</tt>. In the C++ IR this linkage between <tt>%MyVar</tt> and
<tt>%MyType</tt> is
explicit through the use of C++ pointers. In bytecode, however, there's no
ability to store memory addresses. Instead, we compute and write out slot ability to store memory addresses. Instead, we compute and write out slot
numbers for every type and Value written to the file.</p> numbers for every type and Value written to the file.</p>
<p>A slot number is simply an unsigned 32-bit integer encoded in the variable <p>A slot number is simply an unsigned 32-bit integer encoded in the variable
@ -146,7 +148,7 @@ written to the bytecode file in a list (sequentially). Their order in that list
determines their slot number. This means that slot #1 doesn't mean anything determines their slot number. This means that slot #1 doesn't mean anything
unless you also specify for which type you want slot #1. Types are handled unless you also specify for which type you want slot #1. Types are handled
specially and are always written to the file first (in the Global Type Pool) and specially and are always written to the file first (in the Global Type Pool) and
in such a way that both forward and backward references of the types can be in such a way that both forward and backward references of the types can often be
resolved with a single pass through the type pool. </p> resolved with a single pass through the type pool. </p>
<p>Slot numbers are also kept small by rearranging their order. Because of the <p>Slot numbers are also kept small by rearranging their order. Because of the
structure of LLVM, certain values are much more likely to be used frequently structure of LLVM, certain values are much more likely to be used frequently