RPCS3/llvm
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm.git synced 2024-12-03 09:21:02 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Added a bit on slot numbers.

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13756 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Reid Spencer 2004-05-25 15:47:57 +00:00
parent 875510805f
commit 7aa940de94
1 changed files with 38 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
docs/BytecodeFormat.html
View File

@ -19,6 +19,7 @@
<li><a href="#blocks">Blocks</a></li>
<li><a href="#lists">Lists</a></li>
<li><a href="#fields">Fields</a></li>
<li><a href="#slots">Slots</a></li>
<li><a href="#encoding">Encoding Rules</a></li>
<li><a href="#align">Alignment</a></li>
</ol>
@ -120,6 +121,43 @@ sections that follow will provide the details on how these fields are
written and how the bits are to be interpreted.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"><a name="slots">Slots</a> </div>
<div class="doc_text">
<p>The bytecode format uses the notion of a "slot" to reference Types and
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.
Slots are used for this purpose. For example, if one has the following assembly:
</p>
<pre><code>
%MyType = type { int, sbyte };
%MyVar = external global %MyType ;
</code></pre>
<p>there are two definitions. The definition of %MyVar uses %MyType and %MyType
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
ability to store memory addresses. Instead, we compute and write out slot
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
bit rate scheme (see <a href="#encoding">encoding</a> below). This ensures that
low slot numbers are encoded in one byte. Through various bits of magic LLVM
attempts to always keep the slot numbers low. The first attempt is to associate
slot numbers with their "type plane". That is, Values of the same type are
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
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
in such a way that both forward and backward references of the types can be
resolved with a single pass through the type pool. </p>
<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
in the body of a function. For this reason, a compaction table is provided in
the body of a function if its use would make the function body smaller.
Suppose you have a function body that uses just the types "int*" and "{double}"
but uses them thousands of time. Its worthwhile to ensure that the slot number
for these types are low so they can be encoded in a single byte (via vbr).
This is exactly what the compaction table does.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsection"><a name="encoding">Encoding Primitives</a> </div>
<div class="doc_text">
<p>Each field that can be put out is encoded into the file using a small set