add llvm ir bitcode definition file

[oota-llvm.git] / docs / BytecodeFormat.html

diff --git a/docs/BytecodeFormat.html b/docs/BytecodeFormat.html
index b2370eecc4b0c65c4c71f5c94eb047a7b55bd199..56fc0afce9c20a1e16b3f8a04fdbf808c479ec6a 100644 (file)
--- a/docs/BytecodeFormat.html
+++ b/docs/BytecodeFormat.html
@@ -998,7 +998,11 @@ and a an optional initializers for the global var.</p>
         6=DllExport, 7=ExternWeak</td>
     </tr>
     <tr>
-      <td><a href="#bit">bit(5-31)</a></td>
+      <td><a href="#bit">bit(5)</a></td>
+      <td class="td_left">Is Thread Local?</td>
+    </tr>
+    <tr>
+      <td><a href="#bit">bit(6-31)</a></td>
       <td class="td_left">Type slot number of type for the global variable.</td>
     </tr>
   </tbody>
@@ -1275,10 +1279,18 @@ field definitions, based on type:</p>
 <ul>
   <li><b>Bool</b>. This is written as an <a href="#uint32_vbr">uint32_vbr</a> of
   value 1U or 0U.</li>
-  <li><b>Signed Integers (sbyte,short,int,long)</b>. These are written as an 
-  <a href="#int64_vbr">int64_vbr</a> with the corresponding value.</li>
-  <li><b>Unsigned Integers (ubyte,ushort,uint,ulong)</b>. These are written as 
-  an <a href="#uint64_vbr">uint64_vbr</a> with the corresponding value. </li>
+  <li><b>Signed Integers (sbyte,short,int,long) &le; 64 bits</b>. These are 
+  written as an <a href="#int64_vbr">int64_vbr</a> with the corresponding 
+  value.</li>
+  <li><b>Unsigned Integers (ubyte,ushort,uint,ulong) &le; 64 bits</b>. These 
+  are written as an <a href="#uint64_vbr">uint64_vbr</a> with the corresponding
+  value. </li>
+  <li><b>Integers &gt; 64 bits</b>. These are written as a length followed by a
+  series of 64-bit words. The length specifies the number of words that follow.
+  Any zero-valued high order words are elided. Words with the least significant
+  bits are written to the lowest file offsets (little endian). The length is 
+  written as an <a href="#uint32_vbr">uint32_vbr</a>. Each word of the value
+  is written as an <a href="#uint64_vbr">uint64_vbr</a>.</li>
   <li><b>Floating Point</b>. Both the float and double types are written 
   literally in binary format.</li>
   <li><b>Arrays</b>. Arrays are written simply as a list of 
@@ -1575,15 +1587,15 @@ possible. </p>
       <tr><td>Call+FastCC+TailCall</td><td>59</td><td>5</td><td>1.5</td></tr>
       <tr><td>Call+FastCC</td><td>60</td><td>5</td><td>1.5</td></tr>
       <tr><td>Call+CCC+TailCall</td><td>61</td><td>5</td><td>1.5</td></tr>
-      <tr><td>Load+Volatile</td><td>62</td><td>3</td><td>1.3</td></tr>
-      <tr><td>Store+Volatile</td><td>63</td><td>3</td><td>1.3</td></tr>
+      <tr><td>Load+Attributes</td><td>62</td><td>7</td><td>2.0</td></tr>
+      <tr><td>Store+Attributes</td><td>63</td><td>7</td><td>2.0</td></tr>
     </tbody>
   </table>
 
 <p><b><a name="pi_note">* Note: </a></b>
 These aren't really opcodes from an LLVM language perspective. They encode
 information into other opcodes without reserving space for that information. 
-For example, opcode=63 is a Volatile Store. The opcode for this
+For example, opcode=63 is an Attributed Store. The opcode for this
 instruction is 25 (Store) but we encode it as 63 to indicate that is a Volatile
 Store. The same is done for the calling conventions and tail calls.
 In each of these entries in range 56-63, the opcode is documented as the base