+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"><a name="DEFINE_ABBREV">DEFINE_ABBREV
+ Encoding</a></div>
+
+<div class="doc_text">
+
+<p><tt>[DEFINE_ABBREV, numabbrevops<sub>vbr5</sub>, abbrevop0, abbrevop1,
+ ...]</tt></p>
+
+<p>A DEFINE_ABBREV record adds an abbreviation to the list of currently
+defined abbreviations in the scope of this block. This definition only
+exists inside this immediate block -- it is not visible in subblocks or
+enclosing blocks.
+Abbreviations are implicitly assigned IDs
+sequentially starting from 4 (the first application-defined abbreviation ID).
+Any abbreviations defined in a BLOCKINFO record receive IDs first, in order,
+followed by any abbreviations defined within the block itself.
+Abbreviated data records reference this ID to indicate what abbreviation
+they are invoking.</p>
+
+<p>An abbreviation definition consists of the DEFINE_ABBREV abbrevid followed
+by a VBR that specifies the number of abbrev operands, then the abbrev
+operands themselves. Abbreviation operands come in three forms. They all start
+with a single bit that indicates whether the abbrev operand is a literal operand
+(when the bit is 1) or an encoding operand (when the bit is 0).</p>
+
+<ol>
+<li>Literal operands - <tt>[1<sub>1</sub>, litvalue<sub>vbr8</sub>]</tt> -
+Literal operands specify that the value in the result
+is always a single specific value. This specific value is emitted as a vbr8
+after the bit indicating that it is a literal operand.</li>
+<li>Encoding info without data - <tt>[0<sub>1</sub>, encoding<sub>3</sub>]</tt>
+ - Operand encodings that do not have extra data are just emitted as their code.
+</li>
+<li>Encoding info with data - <tt>[0<sub>1</sub>, encoding<sub>3</sub>,
+value<sub>vbr5</sub>]</tt> - Operand encodings that do have extra data are
+emitted as their code, followed by the extra data.
+</li>
+</ol>
+
+<p>The possible operand encodings are:</p>
+
+<ul>
+<li>1 - Fixed - The field should be emitted as a <a
+ href="#fixedwidth">fixed-width value</a>, whose width
+ is specified by the operand's extra data.</li>
+<li>2 - VBR - The field should be emitted as a <a
+ href="#variablewidth">variable-width value</a>, whose width
+ is specified by the operand's extra data.</li>
+<li>3 - Array - This field is an array of values. The array operand has no
+ extra data, but expects another operand to follow it which indicates the
+ element type of the array. When reading an array in an abbreviated record,
+ the first integer is a vbr6 that indicates the array length, followed by
+ the encoded elements of the array. An array may only occur as the last
+ operand of an abbreviation (except for the one final operand that gives
+ the array's type).</li>
+<li>4 - Char6 - This field should be emitted as a <a href="#char6">char6-encoded
+ value</a>. This operand type takes no extra data.</li>
+</ul>
+
+<p>For example, target triples in LLVM modules are encoded as a record of the
+form <tt>[TRIPLE, 'a', 'b', 'c', 'd']</tt>. Consider if the bitstream emitted
+the following abbrev entry:</p>
+
+<ul>
+<li><tt>[0, Fixed, 4]</tt></li>
+<li><tt>[0, Array]</tt></li>
+<li><tt>[0, Char6]</tt></li>
+</ul>
+
+<p>When emitting a record with this abbreviation, the above entry would be
+emitted as:</p>
+
+<p><tt>[4<sub>abbrevwidth</sub>, 2<sub>4</sub>, 4<sub>vbr6</sub>,
+ 0<sub>6</sub>, 1<sub>6</sub>, 2<sub>6</sub>, 3<sub>6</sub>]</tt></p>
+
+<p>These values are:</p>
+
+<ol>
+<li>The first value, 4, is the abbreviation ID for this abbreviation.</li>
+<li>The second value, 2, is the code for TRIPLE in LLVM IR files.</li>
+<li>The third value, 4, is the length of the array.</li>
+<li>The rest of the values are the char6 encoded values for "abcd".</li>
+</ol>
+
+<p>With this abbreviation, the triple is emitted with only 37 bits (assuming a
+abbrev id width of 3). Without the abbreviation, significantly more space would
+be required to emit the target triple. Also, since the TRIPLE value is not
+emitted as a literal in the abbreviation, the abbreviation can also be used for
+any other string value.
+</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="stdblocks">Standard Blocks</a>
+</div>
+
+<div class="doc_text">
+
+<p>
+In addition to the basic block structure and record encodings, the bitstream
+also defines specific builtin block types. These block types specify how the
+stream is to be decoded or other metadata. In the future, new standard blocks
+may be added. Block IDs 0-7 are reserved for standard blocks.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"><a name="BLOCKINFO">#0 - BLOCKINFO
+Block</a></div>
+
+<div class="doc_text">
+
+<p>The BLOCKINFO block allows the description of metadata for other blocks. The
+ currently specified records are:</p>
+
+<ul>
+<li><tt>[SETBID (#1), blockid]</tt></li>
+<li><tt>[DEFINE_ABBREV, ...]</tt></li>
+</ul>
+
+<p>
+The SETBID record indicates which block ID is being described. SETBID
+records can occur multiple times throughout the block to change which
+block ID is being described. There must be a SETBID record prior to
+any other records.
+</p>
+
+<p>
+Standard DEFINE_ABBREV records can occur inside BLOCKINFO blocks, but unlike
+their occurrence in normal blocks, the abbreviation is defined for blocks
+matching the block ID we are describing, <i>not</i> the BLOCKINFO block itself.
+The abbreviations defined in BLOCKINFO blocks receive abbreviation ids
+as described in <a href="#DEFINE_ABBREV">DEFINE_ABBREV</a>.
+</p>
+
+<p>
+Note that although the data in BLOCKINFO blocks is described as "metadata," the
+abbreviations they contain are essential for parsing records from the
+corresponding blocks. It is not safe to skip them.
+</p>
+
+</div>