<p>The possible operand encodings are:</p>
-<ul>
-<li>1 — Fixed — The field should be emitted as
+<ol>
+<li value="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
+<li value="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
+<li value="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
+<li value="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>
+<li value="5">Blob: This field is emitted as a vbr6, followed by padding to a
+ 32-bit boundary (for alignment) and an array of 8-bit objects. The array of
+ bytes is further followed by tail padding to ensure that its total length is
+ a multiple of 4 bytes. This makes it very efficient for the reader to
+ decode the data without having to make a copy of it: it can use a pointer to
+ the data in the mapped in file and poke directly at it. A blob may only
+ occur as the last operand of an abbreviation.</li>
+</ol>
<p>
For example, target triples in LLVM modules are encoded as a record of the
</p>
<div class="doc_code">
-<pre>
-[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>]
-</pre>
+<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>
</div>
<p>These values are:</p>
<pre>
[SETBID (#1), blockid]
[DEFINE_ABBREV, ...]
+[BLOCKNAME, ...name...]
+[SETRECORDNAME, RecordID, ...name...]
</pre>
</div>
in <tt><a href="#DEFINE_ABBREV">DEFINE_ABBREV</a></tt>.
</p>
+<p>The <tt>BLOCKNAME</tt> can optionally occur in this block. The elements of
+the record are the bytes for the string name of the block. llvm-bcanalyzer uses
+this to dump out bitcode files symbolically.</p>
+
+<p>The <tt>SETRECORDNAME</tt> record can optionally occur in this block. The
+first entry is a record ID number and the rest of the elements of the record are
+the bytes for the string name of the record. llvm-bcanalyzer uses
+this to dump out bitcode files symbolically.</p>
+
<p>
Note that although the data in <tt>BLOCKINFO</tt> blocks is described as
"metadata," the abbreviations they contain are essential for parsing records
</p>
<div class="doc_code">
-<pre>
-[Magic<sub>32</sub>, Version<sub>32</sub>, Offset<sub>32</sub>, Size<sub>32</sub>, CPUType<sub>32</sub>]
-</pre>
+<p>
+<tt>[Magic<sub>32</sub>, Version<sub>32</sub>, Offset<sub>32</sub>,
+Size<sub>32</sub>, CPUType<sub>32</sub>]</tt>
+</p>
</div>
<p>
</p>
<div class="doc_code">
-<pre>
-[0x0<sub>4</sub>, 0xC<sub>4</sub>, 0xE<sub>4</sub>, 0xD<sub>4</sub>]
-</pre>
+<p>
+<tt>[0x0<sub>4</sub>, 0xC<sub>4</sub>, 0xE<sub>4</sub>, 0xD<sub>4</sub>]</tt>
+</p>
</div>
<p>