forked from OSchip/llvm-project
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:
parent
660ea5fadb
commit
e7d5ec2b68
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue