From: Chris Lattner Date: Tue, 25 May 2004 17:44:58 +0000 (+0000) Subject: Make use of the doc_author and doc_code styles. 'ify llvm names. Minor X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=8dabb50287ce0064be87d0c38f773d982e889773;p=oota-llvm.git Make use of the doc_author and doc_code styles. 'ify llvm names. Minor other edits git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13760 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/BytecodeFormat.html b/docs/BytecodeFormat.html index d77653be0ab..9902ecdf5ed 100644 --- a/docs/BytecodeFormat.html +++ b/docs/BytecodeFormat.html @@ -38,10 +38,9 @@ -
-

Written by Reid Spencer -and Chris Lattner

-

+
+

Written by Reid Spencer +

@@ -128,13 +127,16 @@ Values. Since the bytecode file is a direct 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:

-

-  %MyType = type { int, sbyte };
-  %MyVar = external global %MyType ;
-
-

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 + +

+ %MyType = type { int, sbyte }
+ %MyVar = external global %MyType +
+ +

there are two definitions. The definition of %MyVar uses +%MyType. In the C++ IR this linkage between %MyVar and +%MyType 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 numbers for every type and Value written to the file.

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 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 +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.

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