[llvm-commits] CVS: llvm/docs/BytecodeFormat.html

[Chris Lattner]

Changes in directory llvm/docs:

BytecodeFormat.html updated: 1.44 -> 1.45
---
Log message:

enumerate non-standard argument encoding cases, such as alignment info for
allocations


---
Diffs of the changes:  (+35 -11)

 BytecodeFormat.html |   46 +++++++++++++++++++++++++++++++++++-----------
 1 files changed, 35 insertions(+), 11 deletions(-)


Index: llvm/docs/BytecodeFormat.html
diff -u llvm/docs/BytecodeFormat.html:1.44 llvm/docs/BytecodeFormat.html:1.45
--- llvm/docs/BytecodeFormat.html:1.44	Sat Nov  5 16:20:06 2005
+++ llvm/docs/BytecodeFormat.html	Sat Nov  5 16:32:06 2005
@@ -1371,8 +1371,8 @@
 <p>Instructions are written out one at a time as distinct units.  Each
 instruction
 record contains at least an <a href="#opcodes">opcode</a> and a type field, 
-and may contain a list of operands (whose interpretation depends on the opcode).
-Based on the number of operands, the
+and may contain a <a href="#instoperands">list of operands</a> (whose
+interpretation depends on the opcode). Based on the number of operands, the
 <a href="#instencode">instruction is encoded</a> in a
 dense format that tries to encoded each instruction into 32-bits if 
 possible. </p>
@@ -1477,6 +1477,36 @@
 </dl>
 </div>
 
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"><a name="instoperands">Instruction
+Operands</a></div>
+
+<div class="doc_text">
+<p>
+Based on the instruction opcode and type, the bytecode format implicitly (to 
+save space) specifies the interpretation of the operand list.  For most
+instructions, the type of each operand is implicit from the type of the 
+instruction itself (e.g. the type of operands of a binary operator must match
+the type of the instruction).  As such, the bytecode format generally only 
+encodes the value number of the operand, not the type.</p>
+
+<p>In some cases, however, this is not sufficient.  This section enumerates
+those cases:</p>
+
+<ul>
+<li>getelementptr: the slot numbers for sequential type indexes are shifted up
+two bits.  This allows the low order bits will encode the type of index used,
+as follows: 0=uint, 1=int, 2=ulong, 3=long.</li>
+<li>cast: the result type number is encoded as the second operand.</li>
+<li>alloca/malloc: If the allocation has an explicit alignment, the log2 of the
+    alignment is encoded as the second operand.</li>
+<li>call: If the tail marker and calling convention cannot be <a 
+    href="#pi_note">encoded into the opcode</a> of the call, it is passed as an
+    additional operand.  The low bit of the operand is a flag indicating whether
+    the call is a tail call.  The rest of the bits contain the calling 
+    convention number (shifted left by one bit).</li>
+</ul>
+</div>
 
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsubsection"><a name="instencode">Instruction 
@@ -1518,17 +1548,11 @@
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a>+</td>
       <td class="td_left">The slot number of the value(s) for the operand(s).
-        <sup>1</sup></td>
+      </td>
     </tr>
   </tbody>
 </table>
-Notes:
-<ol>
-  <li>Note that if the instruction is a getelementptr and the type of
-the operand is a sequential type (array or pointer) then the slot
-number is shifted up two bits and the low order bits will encode the
-type of index used, as follows: 0=uint, 1=int, 2=ulong, 3=long.</li>
-</ol>
+
 <p><b>Instruction Format 1</b></p>
 <p>This format encodes the opcode, type and a single operand into a
 single <a href="#uint32_vbr">uint32_vbr</a> as follows:</p>
@@ -1955,7 +1979,7 @@
 <a href="mailto:rspencer at x10sys.com">Reid Spencer</a> and <a
  href="mailto:sabre at nondot.org">Chris Lattner</a><br>
 <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
-Last modified: $Date: 2005/11/05 22:20:06 $
+Last modified: $Date: 2005/11/05 22:32:06 $
 </address>
 </body>
 </html>