Use correct name for method in comment.
[oota-llvm.git] / docs / LangRef.html
index 86f1ee3b51bba0657d23657816d7f6d72e52d846..09903f1016be76acc2decca4a81db68375ee86be 100644 (file)
   </li>
   <li><a href="#typesystem">Type System</a>
     <ol>
+      <li><a href="#t_classifications">Type Classifications</a></li>
       <li><a href="#t_primitive">Primitive Types</a>    
         <ol>
-          <li><a href="#t_classifications">Type Classifications</a></li>
+          <li><a href="#t_floating">Floating Point Types</a></li>
+          <li><a href="#t_void">Void Type</a></li>
+          <li><a href="#t_label">Label Type</a></li>
         </ol>
       </li>
       <li><a href="#t_derived">Derived Types</a>
           <li><a href="#i_select">'<tt>select</tt>' Instruction</a></li>
           <li><a href="#i_call">'<tt>call</tt>'  Instruction</a></li>
           <li><a href="#i_va_arg">'<tt>va_arg</tt>'  Instruction</a></li>
+          <li><a href="#i_getresult">'<tt>getresult</tt>'  Instruction</a></li>
         </ol>
       </li>
     </ol>
           <li><a href="#int_it">'<tt>llvm.init.trampoline</tt>' Intrinsic</a></li>
         </ol>
       </li>
+          <li><a href="#int_atomics">Atomic intrinsics</a>
+            <ol>
+              <li><a href="#int_memory_barrier"><tt>llvm.memory_barrier</tt></a></li>
+              <li><a href="#int_atomic_lcs"><tt>llvm.atomic.lcs</tt></a></li>
+              <li><a href="#int_atomic_las"><tt>llvm.atomic.las</tt></a></li>
+              <li><a href="#int_atomic_swap"><tt>llvm.atomic.swap</tt></a></li>
+            </ol>
+          </li>
       <li><a href="#int_general">General intrinsics</a>
         <ol>
           <li><a href="#int_var_annotation">
             <tt>llvm.var.annotation</tt>' Intrinsic</a></li>
-        </ol>
-        <ol>
           <li><a href="#int_annotation">
             <tt>llvm.annotation.*</tt>' Intrinsic</a></li>
+          <li><a href="#int_trap">
+            <tt>llvm.trap</tt>' Intrinsic</a></li>
         </ol>
       </li>
     </ol>
@@ -751,8 +763,8 @@ a power of 2.</p>
 </div>
 <div class="doc_text">
   <p>Aliases act as "second name" for the aliasee value (which can be either
-  function or global variable or bitcast of global value). Aliases may have an
-  optional <a href="#linkage">linkage type</a>, and an
+  function, global variable, another alias or bitcast of global value). Aliases
+  may have an optional <a href="#linkage">linkage type</a>, and an
   optional <a href="#visibility">visibility style</a>.</p>
 
   <h5>Syntax:</h5>
@@ -796,27 +808,46 @@ declare i32 @atoi(i8*) nounwind readonly
     <dt><tt>zeroext</tt></dt>
     <dd>This indicates that the parameter should be zero extended just before
     a call to this function.</dd>
+
     <dt><tt>signext</tt></dt>
     <dd>This indicates that the parameter should be sign extended just before
     a call to this function.</dd>
+
     <dt><tt>inreg</tt></dt>
     <dd>This indicates that the parameter should be placed in register (if
     possible) during assembling function call. Support for this attribute is
     target-specific</dd>
+
+    <dt><tt>byval</tt></dt>
+    <dd>This indicates that the pointer parameter should really be passed by
+    value to the function.  The attribute implies that a hidden copy of the
+    pointee is made between the caller and the callee, so the callee is unable
+    to modify the value in the callee.  This attribute is only valid on llvm
+    pointer arguments.  It is generally used to pass structs and arrays by
+    value, but is also valid on scalars (even though this is silly).</dd>
+
     <dt><tt>sret</tt></dt>
-    <dd>This indicates that the parameter specifies the address of a structure
-    that is the return value of the function in the source program.</dd>
+    <dd>This indicates that the pointer parameter specifies the address of a
+    structure that is the return value of the function in the source program.
+    Loads and stores to the structure are assumed not to trap.
+    May only be applied to the first parameter.</dd>
+
     <dt><tt>noalias</tt></dt>
-    <dd>This indicates that the parameter not alias any other object or any 
-    other "noalias" objects during the function call.
+    <dd>This indicates that the parameter does not alias any global or any other
+    parameter.  The caller is responsible for ensuring that this is the case,
+    usually by placing the value in a stack allocation.</dd>
+
     <dt><tt>noreturn</tt></dt>
     <dd>This function attribute indicates that the function never returns. This
     indicates to LLVM that every call to this function should be treated as if
     an <tt>unreachable</tt> instruction immediately followed the call.</dd> 
+
     <dt><tt>nounwind</tt></dt>
-    <dd>This function attribute indicates that the function type does not use
-    the unwind instruction and does not allow stack unwinding to propagate
-    through it.</dd>
+    <dd>This function attribute indicates that no exceptions unwind out of the
+    function.  Usually this is because the function makes no use of exceptions,
+    but it may also be that the function catches any exceptions thrown when
+    executing it.</dd>
+
     <dt><tt>nest</tt></dt>
     <dd>This indicates that the parameter can be excised using the
     <a href="#int_trampoline">trampoline intrinsics</a>.</dd>
@@ -974,59 +1005,49 @@ three address code representations.</p>
 </div>
 
 <!-- ======================================================================= -->
-<div class="doc_subsection"> <a name="t_primitive">Primitive Types</a> </div>
-<div class="doc_text">
-<p>The primitive types are the fundamental building blocks of the LLVM
-system. The current set of primitive types is as follows:</p>
-
-<table class="layout">
-  <tr class="layout">
-    <td class="left">
-      <table>
-        <tbody>
-        <tr><th>Type</th><th>Description</th></tr>
-        <tr><td><tt><a name="t_void">void</a></tt></td><td>No value</td></tr>
-        <tr><td><tt>label</tt></td><td>Branch destination</td></tr>
-        </tbody>
-      </table>
-    </td>
-    <td class="right">
-      <table>
-        <tbody>
-          <tr><th>Type</th><th>Description</th></tr>
-          <tr><td><tt>float</tt></td><td>32-bit floating point value</td></tr>
-         <tr><td><tt>double</tt></td><td>64-bit floating point value</td></tr>
-        </tbody>
-      </table>
-    </td>
-  </tr>
-</table>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_classifications">Type
+<div class="doc_subsection"> <a name="t_classifications">Type
 Classifications</a> </div>
 <div class="doc_text">
-<p>These different primitive types fall into a few useful
+<p>The types fall into a few useful
 classifications:</p>
 
 <table border="1" cellspacing="0" cellpadding="4">
   <tbody>
     <tr><th>Classification</th><th>Types</th></tr>
     <tr>
-      <td><a name="t_integer">integer</a></td>
+      <td><a href="#t_integer">integer</a></td>
       <td><tt>i1, i2, i3, ... i8, ... i16, ... i32, ... i64, ... </tt></td>
     </tr>
     <tr>
-      <td><a name="t_floating">floating point</a></td>
-      <td><tt>float, double</tt></td>
+      <td><a href="#t_floating">floating point</a></td>
+      <td><tt>float, double, x86_fp80, fp128, ppc_fp128</tt></td>
     </tr>
     <tr>
       <td><a name="t_firstclass">first class</a></td>
-      <td><tt>i1, ..., float, double, <br/>
-          <a href="#t_pointer">pointer</a>,<a href="#t_vector">vector</a></tt>
+      <td><a href="#t_integer">integer</a>,
+          <a href="#t_floating">floating point</a>,
+          <a href="#t_pointer">pointer</a>,
+          <a href="#t_vector">vector</a>
       </td>
     </tr>
+    <tr>
+      <td><a href="#t_primitive">primitive</a></td>
+      <td><a href="#t_label">label</a>,
+          <a href="#t_void">void</a>,
+          <a href="#t_integer">integer</a>,
+          <a href="#t_floating">floating point</a>.</td>
+    </tr>
+    <tr>
+      <td><a href="#t_derived">derived</a></td>
+      <td><a href="#t_integer">integer</a>,
+          <a href="#t_array">array</a>,
+          <a href="#t_function">function</a>,
+          <a href="#t_pointer">pointer</a>,
+          <a href="#t_struct">structure</a>,
+          <a href="#t_pstruct">packed structure</a>,
+          <a href="#t_vector">vector</a>,
+          <a href="#t_opaque">opaque</a>.
+    </tr>
   </tbody>
 </table>
 
@@ -1037,6 +1058,60 @@ instructions.  This means that all structures and arrays must be
 manipulated either by pointer or by component.</p>
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection"> <a name="t_primitive">Primitive Types</a> </div>
+
+<div class="doc_text">
+<p>The primitive types are the fundamental building blocks of the LLVM
+system.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"> <a name="t_floating">Floating Point Types</a> </div>
+
+<div class="doc_text">
+      <table>
+        <tbody>
+          <tr><th>Type</th><th>Description</th></tr>
+          <tr><td><tt>float</tt></td><td>32-bit floating point value</td></tr>
+          <tr><td><tt>double</tt></td><td>64-bit floating point value</td></tr>
+          <tr><td><tt>fp128</tt></td><td>128-bit floating point value (112-bit mantissa)</td></tr>
+          <tr><td><tt>x86_fp80</tt></td><td>80-bit floating point value (X87)</td></tr>
+          <tr><td><tt>ppc_fp128</tt></td><td>128-bit floating point value (two 64-bits)</td></tr>
+        </tbody>
+      </table>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"> <a name="t_void">Void Type</a> </div>
+
+<div class="doc_text">
+<h5>Overview:</h5>
+<p>The void type does not represent any value and has no size.</p>
+
+<h5>Syntax:</h5>
+
+<pre>
+  void
+</pre>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"> <a name="t_label">Label Type</a> </div>
+
+<div class="doc_text">
+<h5>Overview:</h5>
+<p>The label type represents code labels.</p>
+
+<h5>Syntax:</h5>
+
+<pre>
+  label
+</pre>
+</div>
+
+
 <!-- ======================================================================= -->
 <div class="doc_subsection"> <a name="t_derived">Derived Types</a> </div>
 
@@ -1150,20 +1225,22 @@ type "{ i32, [0 x float]}", for example.</p>
 <div class="doc_text">
 <h5>Overview:</h5>
 <p>The function type can be thought of as a function signature.  It
-consists of a return type and a list of formal parameter types. 
-Function types are usually used to build virtual function tables
+consists of a return type and a list of formal parameter types. The
+return type of a function type is a scalar type or a void type or a struct type. 
+If the return type is a struct type then all struct elements must be of first 
+class types. Function types are usually used to build virtual function tables
 (which are structures of pointers to functions), for indirect function
 calls, and when defining a function.</p>
-<p>
-The return type of a function type cannot be an aggregate type.
-</p>
+
 <h5>Syntax:</h5>
-<pre>  &lt;returntype&gt; (&lt;parameter list&gt;)<br></pre>
+<pre>  &lt;returntype list&gt; (&lt;parameter list&gt;)<br></pre>
 <p>...where '<tt>&lt;parameter list&gt;</tt>' is a comma-separated list of type
 specifiers.  Optionally, the parameter list may include a type <tt>...</tt>,
 which indicates that the function takes a variable number of arguments.
 Variable argument functions can access their arguments with the <a
- href="#int_varargs">variable argument handling intrinsic</a> functions.</p>
+ href="#int_varargs">variable argument handling intrinsic</a> functions.
+'<tt>&lt;returntype list&gt;</tt>' is a comma-separated list of
+<a href="#t_firstclass">first class</a> type specifiers.</p>
 <h5>Examples:</h5>
 <table class="layout">
   <tr class="layout">
@@ -1185,6 +1262,11 @@ Variable argument functions can access their arguments with the <a
       which returns an integer.  This is the signature for <tt>printf</tt> in 
       LLVM.
     </td>
+  </tr><tr class="layout">
+    <td class="left"><tt>{i32, i32} (i32)</tt></td>
+    <td class="left">A function taking an <tt>i32></tt>, returning two 
+        <tt> i32 </tt> values as an aggregate of type <tt>{ i32, i32 }</tt>
+    </td>
   </tr>
 </table>
 
@@ -1383,8 +1465,10 @@ them all and their syntax.</p>
 
   <dd>Floating point constants use standard decimal notation (e.g. 123.421),
   exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal
-  notation (see below).  Floating point constants must have a <a
-  href="#t_floating">floating point</a> type. </dd>
+  notation (see below).  The assembler requires the exact decimal value of
+  a floating-point constant.  For example, the assembler accepts 1.25 but
+  rejects 1.3 because 1.3 is a repeating decimal in binary.  Floating point
+  constants must have a <a href="#t_floating">floating point</a> type. </dd>
 
   <dt><b>Null pointer constants</b></dt>
 
@@ -1418,8 +1502,8 @@ and smaller aggregate constants.</p>
 
   <dd>Structure constants are represented with notation similar to structure
   type definitions (a comma separated list of elements, surrounded by braces
-  (<tt>{}</tt>)).  For example: "<tt>{ i32 4, float 17.0, i32* %G }</tt>",
-  where "<tt>%G</tt>" is declared as "<tt>@G = external global i32</tt>".  Structure constants
+  (<tt>{}</tt>)).  For example: "<tt>{ i32 4, float 17.0, i32* @G }</tt>",
+  where "<tt>@G</tt>" is declared as "<tt>@G = external global i32</tt>".  Structure constants
   must have <a href="#t_struct">structure type</a>, and the number and
   types of elements must match those specified by the type.
   </dd>
@@ -1716,6 +1800,7 @@ Instruction</a> </div>
 <h5>Syntax:</h5>
 <pre>  ret &lt;type&gt; &lt;value&gt;       <i>; Return a value from a non-void function</i>
   ret void                 <i>; Return from void function</i>
+  ret &lt;type&gt; &lt;value&gt;, &lt;type&gt; &lt;value&gt;  <i>; Return two values from a non-void function </i>
 </pre>
 <h5>Overview:</h5>
 <p>The '<tt>ret</tt>' instruction is used to return control flow (and a
@@ -1724,11 +1809,11 @@ value) from a function back to the caller.</p>
 returns a value and then causes control flow, and one that just causes
 control flow to occur.</p>
 <h5>Arguments:</h5>
-<p>The '<tt>ret</tt>' instruction may return any '<a
- href="#t_firstclass">first class</a>' type.  Notice that a function is
-not <a href="#wellformed">well formed</a> if there exists a '<tt>ret</tt>'
-instruction inside of the function that returns a value that does not
-match the return type of the function.</p>
+<p>The '<tt>ret</tt>' instruction may return one or multiple values. The
+type of each return value must be a '<a href="#t_firstclass">first class</a>'
+ type.  Note that a function is not <a href="#wellformed">well formed</a> 
+if there exists a '<tt>ret</tt>' instruction inside of the function that 
+returns values that do not match the return type of the function.</p>
 <h5>Semantics:</h5>
 <p>When the '<tt>ret</tt>' instruction is executed, control flow
 returns back to the calling function's context.  If the caller is a "<a
@@ -1737,10 +1822,13 @@ the instruction after the call.  If the caller was an "<a
  href="#i_invoke"><tt>invoke</tt></a>" instruction, execution continues
 at the beginning of the "normal" destination block.  If the instruction
 returns a value, that value shall set the call or invoke instruction's
-return value.</p>
+return value. If the instruction returns multiple values then these 
+values can only be accessed through a '<a href="#i_getresult"><tt>getresult</tt>
+</a>' instruction.</p>
 <h5>Example:</h5>
 <pre>  ret i32 5                       <i>; Return an integer value of 5</i>
   ret void                        <i>; Return from a void function</i>
+  ret i32 4, i8 2                 <i>; Return two values 4 and 2 </i> 
 </pre>
 </div>
 <!-- _______________________________________________________________________ -->
@@ -1837,7 +1925,7 @@ branches or with a lookup table.</p>
 <h5>Syntax:</h5>
 
 <pre>
-  &lt;result&gt; = invoke [<a href="#callingconv">cconv</a>] &lt;ptr to function ty&gt; %&lt;function ptr val&gt;(&lt;function args&gt;) 
+  &lt;result&gt; = invoke [<a href="#callingconv">cconv</a>] &lt;ptr to function ty&gt; &lt;function ptr val&gt;(&lt;function args&gt;) 
                 to label &lt;normal label&gt; unwind label &lt;exception label&gt;
 </pre>
 
@@ -1850,7 +1938,9 @@ function, with the possibility of control flow transfer to either the
 "<tt><a href="#i_ret">ret</a></tt>" instruction, control flow will return to the
 "normal" label.  If the callee (or any indirect callees) returns with the "<a
 href="#i_unwind"><tt>unwind</tt></a>" instruction, control is interrupted and
-continued at the dynamically nearest "exception" label.</p>
+continued at the dynamically nearest "exception" label. If the callee function 
+returns multiple values then individual return values are only accessible through 
+a '<tt><a href="#i_getresult">getresult</a></tt>' instruction.</p>
 
 <h5>Arguments:</h5>
 
@@ -1898,9 +1988,9 @@ exception.  Additionally, this is important for implementation of
 
 <h5>Example:</h5>
 <pre>
-  %retval = invoke i32 %Test(i32 15) to label %Continue
+  %retval = invoke i32 @Test(i32 15) to label %Continue
               unwind label %TestCleanup              <i>; {i32}:retval set</i>
-  %retval = invoke <a href="#callingconv">coldcc</a> i32 %Test(i32 15) to label %Continue
+  %retval = invoke <a href="#callingconv">coldcc</a> i32 %Testfnptr(i32 15) to label %Continue
               unwind label %TestCleanup              <i>; {i32}:retval set</i>
 </pre>
 </div>
@@ -1965,11 +2055,10 @@ no-return function cannot be reached, and other facts.</p>
 <div class="doc_subsection"> <a name="binaryops">Binary Operations</a> </div>
 <div class="doc_text">
 <p>Binary operators are used to do most of the computation in a
-program.  They require two operands, execute an operation on them, and
+program.  They require two operands of the same type, execute an operation on them, and
 produce a single value.  The operands might represent 
 multiple data, as is the case with the <a href="#t_vector">vector</a> data type. 
-The result value of a binary operator is not
-necessarily the same type as its operands.</p>
+The result value has the same type as its operands.</p>
 <p>There are several different binary operators:</p>
 </div>
 <!-- _______________________________________________________________________ -->
@@ -1989,6 +2078,11 @@ Both arguments must have identical types.</p>
 <h5>Semantics:</h5>
 <p>The value produced is the integer or floating point sum of the two
 operands.</p>
+<p>If an integer sum has unsigned overflow, the result returned is the
+mathematical result modulo 2<sup>n</sup>, where n is the bit width of
+the result.</p>
+<p>Because LLVM integers use a two's complement representation, this
+instruction is appropriate for both signed and unsigned integers.</p>
 <h5>Example:</h5>
 <pre>  &lt;result&gt; = add i32 4, %var          <i>; yields {i32}:result = 4 + %var</i>
 </pre>
@@ -2014,6 +2108,11 @@ Both arguments must have identical types.</p>
 <h5>Semantics:</h5>
 <p>The value produced is the integer or floating point difference of
 the two operands.</p>
+<p>If an integer difference has unsigned overflow, the result returned is the
+mathematical result modulo 2<sup>n</sup>, where n is the bit width of
+the result.</p>
+<p>Because LLVM integers use a two's complement representation, this
+instruction is appropriate for both signed and unsigned integers.</p>
 <h5>Example:</h5>
 <pre>
   &lt;result&gt; = sub i32 4, %var          <i>; yields {i32}:result = 4 - %var</i>
@@ -2039,9 +2138,15 @@ Both arguments must have identical types.</p>
 <h5>Semantics:</h5>
 <p>The value produced is the integer or floating point product of the
 two operands.</p>
-<p>Because the operands are the same width, the result of an integer
-multiplication is the same whether the operands should be deemed unsigned or
-signed.</p>
+<p>If the result of an integer multiplication has unsigned overflow,
+the result returned is the mathematical result modulo 
+2<sup>n</sup>, where n is the bit width of the result.</p>
+<p>Because LLVM integers use a two's complement representation, and the
+result is the same width as the operands, this instruction returns the
+correct result for both signed and unsigned integers.  If a full product
+(e.g. <tt>i32</tt>x<tt>i32</tt>-><tt>i64</tt>) is needed, the operands
+should be sign-extended or zero-extended as appropriate to the
+width of the full product.</p>
 <h5>Example:</h5>
 <pre>  &lt;result&gt; = mul i32 4, %var          <i>; yields {i32}:result = 4 * %var</i>
 </pre>
@@ -2062,9 +2167,10 @@ operands.</p>
 types. This instruction can also take <a href="#t_vector">vector</a> versions 
 of the values in which case the elements must be integers.</p>
 <h5>Semantics:</h5>
-<p>The value produced is the unsigned integer quotient of the two operands. This
-instruction always performs an unsigned division operation, regardless of 
-whether the arguments are unsigned or not.</p>
+<p>The value produced is the unsigned integer quotient of the two operands.</p>
+<p>Note that unsigned integer division and signed integer division are distinct
+operations; for signed integer division, use '<tt>sdiv</tt>'.</p>
+<p>Division by zero leads to undefined behavior.</p>
 <h5>Example:</h5>
 <pre>  &lt;result&gt; = udiv i32 4, %var          <i>; yields {i32}:result = 4 / %var</i>
 </pre>
@@ -2085,9 +2191,12 @@ operands.</p>
 types. This instruction can also take <a href="#t_vector">vector</a> versions 
 of the values in which case the elements must be integers.</p>
 <h5>Semantics:</h5>
-<p>The value produced is the signed integer quotient of the two operands. This
-instruction always performs a signed division operation, regardless of whether
-the arguments are signed or not.</p>
+<p>The value produced is the signed integer quotient of the two operands rounded towards zero.</p>
+<p>Note that signed integer division and unsigned integer division are distinct
+operations; for unsigned integer division, use '<tt>udiv</tt>'.</p>
+<p>Division by zero leads to undefined behavior. Overflow also leads to
+undefined behavior; this is a rare case, but can occur, for example,
+by doing a 32-bit division of -2147483648 by -1.</p>
 <h5>Example:</h5>
 <pre>  &lt;result&gt; = sdiv i32 4, %var          <i>; yields {i32}:result = 4 / %var</i>
 </pre>
@@ -2130,8 +2239,10 @@ types. This instruction can also take <a href="#t_vector">vector</a> versions
 of the values in which case the elements must be integers.</p>
 <h5>Semantics:</h5>
 <p>This instruction returns the unsigned integer <i>remainder</i> of a division.
-This instruction always performs an unsigned division to get the remainder,
-regardless of whether the arguments are unsigned or not.</p>
+This instruction always performs an unsigned division to get the remainder.</p>
+<p>Note that unsigned integer remainder and signed integer remainder are
+distinct operations; for signed integer remainder, use '<tt>srem</tt>'.</p>
+<p>Taking the remainder of a division by zero leads to undefined behavior.</p>
 <h5>Example:</h5>
 <pre>  &lt;result&gt; = urem i32 4, %var          <i>; yields {i32}:result = 4 % %var</i>
 </pre>
@@ -2149,7 +2260,7 @@ Instruction</a> </div>
 signed division of its two operands. This instruction can also take
 <a href="#t_vector">vector</a> versions of the values in which case
 the elements must be integers.</p>
-</p>
+
 <h5>Arguments:</h5>
 <p>The two arguments to the '<tt>srem</tt>' instruction must be 
 <a href="#t_integer">integer</a> values.  Both arguments must have identical 
@@ -2163,6 +2274,14 @@ a value.  For more information about the difference, see <a
 Math Forum</a>. For a table of how this is implemented in various languages,
 please see <a href="http://en.wikipedia.org/wiki/Modulo_operation">
 Wikipedia: modulo operation</a>.</p>
+<p>Note that signed integer remainder and unsigned integer remainder are
+distinct operations; for unsigned integer remainder, use '<tt>urem</tt>'.</p>
+<p>Taking the remainder of a division by zero leads to undefined behavior.
+Overflow also leads to undefined behavior; this is a rare case, but can occur,
+for example, by taking the remainder of a 32-bit division of -2147483648 by -1.
+(The remainder doesn't actually overflow, but this rule lets srem be 
+implemented using instructions that return both the result of the division
+and the remainder.)</p>
 <h5>Example:</h5>
 <pre>  &lt;result&gt; = srem i32 4, %var          <i>; yields {i32}:result = 4 % %var</i>
 </pre>
@@ -2184,7 +2303,8 @@ division of its two operands.</p>
 identical types.  This instruction can also take <a href="#t_vector">vector</a>
 versions of floating point values.</p>
 <h5>Semantics:</h5>
-<p>This instruction returns the <i>remainder</i> of a division.</p>
+<p>This instruction returns the <i>remainder</i> of a division.
+The remainder has the same sign as the dividend.</p>
 <h5>Example:</h5>
 <pre>  &lt;result&gt; = frem float 4.0, %var          <i>; yields {float}:result = 4.0 % %var</i>
 </pre>
@@ -2197,9 +2317,8 @@ Operations</a> </div>
 <p>Bitwise binary operators are used to do various forms of
 bit-twiddling in a program.  They are generally very efficient
 instructions and can commonly be strength reduced from other
-instructions.  They require two operands, execute an operation on them,
-and produce a single value.  The resulting value of the bitwise binary
-operators is always the same type as its first operand.</p>
+instructions.  They require two operands of the same type, execute an operation on them,
+and produce a single value.  The resulting value is the same type as its operands.</p>
 </div>
 
 <!-- _______________________________________________________________________ -->
@@ -2222,9 +2341,9 @@ the left a specified number of bits.</p>
  
 <h5>Semantics:</h5>
 
-<p>The value produced is <tt>var1</tt> * 2<sup><tt>var2</tt></sup>.  If
-<tt>var2</tt> is (statically or dynamically) equal to or larger than the number
-of bits in <tt>var1</tt>, the result is undefined.</p>
+<p>The value produced is <tt>var1</tt> * 2<sup><tt>var2</tt></sup> mod 2<sup>n</sup>,
+where n is the width of the result.  If <tt>var2</tt> is (statically or dynamically) negative or
+equal to or larger than the number of bits in <tt>var1</tt>, the result is undefined.</p>
 
 <h5>Example:</h5><pre>
   &lt;result&gt; = shl i32 4, %var   <i>; yields {i32}: 4 &lt;&lt; %var</i>
@@ -2667,17 +2786,18 @@ address space (address space zero).</p>
 <tt>sizeof(&lt;type&gt;)*NumElements</tt>
 bytes of memory from the operating system and returns a pointer of the
 appropriate type to the program.  If "NumElements" is specified, it is the
-number of elements allocated.  If an alignment is specified, the value result
-of the allocation is guaranteed to be aligned to at least that boundary.  If
-not specified, or if zero, the target can choose to align the allocation on any
-convenient boundary.</p>
+number of elements allocated, otherwise "NumElements" is defaulted to be one.
+If a constant alignment is specified, the value result of the allocation is guaranteed to
+be aligned to at least that boundary.  If not specified, or if zero, the target can
+choose to align the allocation on any convenient boundary.</p>
 
 <p>'<tt>type</tt>' must be a sized type.</p>
 
 <h5>Semantics:</h5>
 
 <p>Memory is allocated using the system "<tt>malloc</tt>" function, and
-a pointer is returned.</p>
+a pointer is returned.  Allocating zero bytes is undefined.  The result is null
+if there is insufficient memory available.</p>
 
 <h5>Example:</h5>
 
@@ -2719,7 +2839,8 @@ instruction.</p>
 <h5>Semantics:</h5>
 
 <p>Access to the memory pointed to by the pointer is no longer defined
-after this instruction executes.</p>
+after this instruction executes.  If the pointer is null, the result is
+undefined.</p>
 
 <h5>Example:</h5>
 
@@ -2753,11 +2874,11 @@ space (address space zero).</p>
 
 <p>The '<tt>alloca</tt>' instruction allocates <tt>sizeof(&lt;type&gt;)*NumElements</tt>
 bytes of memory on the runtime stack, returning a pointer of the
-appropriate type to the program.    If "NumElements" is specified, it is the
-number of elements allocated.  If an alignment is specified, the value result
-of the allocation is guaranteed to be aligned to at least that boundary.  If
-not specified, or if zero, the target can choose to align the allocation on any
-convenient boundary.</p>
+appropriate type to the program.  If "NumElements" is specified, it is the
+number of elements allocated, otherwise "NumElements" is defaulted to be one.
+If a constant alignment is specified, the value result of the allocation is guaranteed
+to be aligned to at least that boundary.  If not specified, or if zero, the target
+can choose to align the allocation on any convenient boundary.</p>
 
 <p>'<tt>type</tt>' may be any sized type.</p>
 
@@ -2768,7 +2889,8 @@ memory is automatically released when the function returns.  The '<tt>alloca</tt
 instruction is commonly used to represent automatic variables that must
 have an address available.  When the function returns (either with the <tt><a
  href="#i_ret">ret</a></tt> or <tt><a href="#i_unwind">unwind</a></tt>
-instructions), the memory is reclaimed.</p>
+instructions), the memory is reclaimed.  Allocating zero bytes
+is legal, but the result is undefined.</p>
 
 <h5>Example:</h5>
 
@@ -2796,6 +2918,16 @@ marked as <tt>volatile</tt>, then the optimizer is not allowed to modify
 the number or order of execution of this <tt>load</tt> with other
 volatile <tt>load</tt> and <tt><a href="#i_store">store</a></tt>
 instructions. </p>
+<p>
+The optional constant "align" argument specifies the alignment of the operation
+(that is, the alignment of the memory address). A value of 0 or an
+omitted "align" argument means that the operation has the preferential
+alignment for the target. It is the responsibility of the code emitter
+to ensure that the alignment information is correct. Overestimating
+the alignment results in an undefined behavior. Underestimating the
+alignment may produce less efficient code. An alignment of 1 is always
+safe.
+</p>
 <h5>Semantics:</h5>
 <p>The location of memory pointed to is loaded.</p>
 <h5>Examples:</h5>
@@ -2818,11 +2950,22 @@ Instruction</a> </div>
 <h5>Arguments:</h5>
 <p>There are two arguments to the '<tt>store</tt>' instruction: a value
 to store and an address at which to store it.  The type of the '<tt>&lt;pointer&gt;</tt>'
-operand must be a pointer to the type of the '<tt>&lt;value&gt;</tt>'
+operand must be a pointer to the <a href="#t_firstclass">first class</a> type
+of the '<tt>&lt;value&gt;</tt>'
 operand. If the <tt>store</tt> is marked as <tt>volatile</tt>, then the
 optimizer is not allowed to modify the number or order of execution of
 this <tt>store</tt> with other volatile <tt>load</tt> and <tt><a
  href="#i_store">store</a></tt> instructions.</p>
+<p>
+The optional constant "align" argument specifies the alignment of the operation
+(that is, the alignment of the memory address). A value of 0 or an
+omitted "align" argument means that the operation has the preferential
+alignment for the target. It is the responsibility of the code emitter
+to ensure that the alignment information is correct. Overestimating
+the alignment results in an undefined behavior. Underestimating the
+alignment may produce less efficient code. An alignment of 1 is always
+safe.
+</p>
 <h5>Semantics:</h5>
 <p>The contents of memory are updated to contain '<tt>&lt;value&gt;</tt>'
 at the location specified by the '<tt>&lt;pointer&gt;</tt>' operand.</p>
@@ -2904,8 +3047,8 @@ entry:
 on the pointer type that is being indexed into. <a href="#t_pointer">Pointer</a>
 and <a href="#t_array">array</a> types can use a 32-bit or 64-bit
 <a href="#t_integer">integer</a> type but the value will always be sign extended
-to 64-bits.  <a href="#t_struct">Structure</a> types require <tt>i32</tt>
-<b>constants</b>.</p>
+to 64-bits.  <a href="#t_struct">Structure</a> and <a href="#t_pstruct">packed
+structure</a> types require <tt>i32</tt> <b>constants</b>.</p>
 
 <p>In the example above, the first index is indexing into the '<tt>%ST*</tt>'
 type, which is a pointer, yielding a '<tt>%ST</tt>' = '<tt>{ i32, double, %RT
@@ -3413,7 +3556,7 @@ instructions, which defy better classification.</p>
 </pre>
 <h5>Overview:</h5>
 <p>The '<tt>icmp</tt>' instruction returns a boolean value based on comparison
-of its two integer operands.</p>
+of its two integer or pointer operands.</p>
 <h5>Arguments:</h5>
 <p>The '<tt>icmp</tt>' instruction takes three operands. The first operand is
 the condition code indicating the kind of comparison to perform. It is not
@@ -3687,17 +3830,23 @@ transfer to a specified function, with its incoming arguments bound to
 the specified values. Upon a '<tt><a href="#i_ret">ret</a></tt>'
 instruction in the called function, control flow continues with the
 instruction after the function call, and the return value of the
-function is bound to the result argument.  This is a simpler case of
-the <a href="#i_invoke">invoke</a> instruction.</p>
+function is bound to the result argument.  If the callee returns multiple 
+values then the return values of the function are only accessible through 
+the '<tt><a href="#i_getresult">getresult</a></tt>' instruction.</p>
 
 <h5>Example:</h5>
 
 <pre>
   %retval = call i32 @test(i32 %argc)
-  call i32 (i8 *, ...)* @printf(i8 * %msg, i32 12, i8 42);
-  %X = tail call i32 @foo()
-  %Y = tail call <a href="#callingconv">fastcc</a> i32 @foo()
-  %Z = call void %foo(i8 97 signext)
+  call i32 (i8 *, ...)* @printf(i8 * %msg, i32 12, i8 42)      <i>; yields i32</i>
+  %X = tail call i32 @foo()                                    <i>; yields i32</i>
+  %Y = tail call <a href="#callingconv">fastcc</a> i32 @foo()  <i>; yields i32</i>
+  call void %foo(i8 97 signext)
+
+  %struct.A = type { i32, i8 }
+  %r = call %struct.A @foo()                     <i>; yields { 32, i8 }</i>
+  %gr = getresult %struct.A %r, 0                <i>; yields i32</i>
+  %gr1 = getresult %struct.A %r, 1               <i>; yields i8</i>
 </pre>
 
 </div>
@@ -3750,6 +3899,51 @@ argument.</p>
 
 </div>
 
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="i_getresult">'<tt>getresult</tt>' Instruction</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+<pre>
+  &lt;resultval&gt; = getresult &lt;type&gt; &lt;retval&gt;, &lt;index&gt;
+</pre>
+
+<h5>Overview:</h5>
+
+<p> The '<tt>getresult</tt>' instruction is used to extract individual values
+from a '<tt><a href="#i_call">call</a></tt>' 
+or '<tt><a href="#i_invoke">invoke</a></tt>' instruction that returns multiple
+results.</p>
+
+<h5>Arguments:</h5>
+
+<p>The '<tt>getresult</tt>' instruction takes a call or invoke value as its 
+first argument.  The value must have <a href="#t_struct">structure type</a>. 
+The second argument is a constant unsigned index value which must be in range for
+the number of values returned by the call.</p>
+
+<h5>Semantics:</h5>
+
+<p>The '<tt>getresult</tt>' instruction extracts the element identified by
+'<tt>index</tt>' from the aggregate value.</p>
+
+<h5>Example:</h5>
+
+<pre>
+  %struct.A = type { i32, i8 }
+
+  %r = call %struct.A @foo()
+  %gr = getresult %struct.A %r, 0    <i>; yields i32:%gr</i>
+  %gr1 = getresult %struct.A %r, 1   <i>; yields i8:%gr1</i>
+  add i32 %gr, 42
+  add i8 %gr1, 41
+</pre>
+
+</div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section"> <a name="intrinsics">Intrinsic Functions</a> </div>
 <!-- *********************************************************************** -->
@@ -3995,8 +4189,9 @@ value address) contains the meta-data to be associated with the root.</p>
 
 <p>At runtime, a call to this intrinsics stores a null pointer into the "ptrloc"
 location.  At compile-time, the code generator generates information to allow
-the runtime to find the pointer at GC safe points.
-</p>
+the runtime to find the pointer at GC safe points. The '<tt>llvm.gcroot</tt>'
+intrinsic may only be used in a function which <a href="#gc">specifies a GC
+algorithm</a>.</p>
 
 </div>
 
@@ -4031,7 +4226,9 @@ null).</p>
 
 <p>The '<tt>llvm.gcread</tt>' intrinsic has the same semantics as a load
 instruction, but may be replaced with substantially more complex code by the
-garbage collector runtime, as needed.</p>
+garbage collector runtime, as needed. The '<tt>llvm.gcread</tt>' intrinsic
+may only be used in a function which <a href="#gc">specifies a GC
+algorithm</a>.</p>
 
 </div>
 
@@ -4066,7 +4263,9 @@ null.</p>
 
 <p>The '<tt>llvm.gcwrite</tt>' intrinsic has the same semantics as a store
 instruction, but may be replaced with substantially more complex code by the
-garbage collector runtime, as needed.</p>
+garbage collector runtime, as needed. The '<tt>llvm.gcwrite</tt>' intrinsic
+may only be used in a function which <a href="#gc">specifies a GC
+algorithm</a>.</p>
 
 </div>
 
@@ -4446,7 +4645,7 @@ be set to 0 or 1.
 <p>
 The '<tt>llvm.memmove.*</tt>' intrinsics move a block of memory from the source
 location to the destination location. It is similar to the
-'<tt>llvm.memcmp</tt>' intrinsic but allows the two memory locations to overlap.
+'<tt>llvm.memcpy</tt>' intrinsic but allows the two memory locations to overlap.
 </p>
 
 <p>
@@ -4559,7 +4758,9 @@ types however.
 The '<tt>llvm.sqrt</tt>' intrinsics return the sqrt of the specified operand,
 returning the same value as the libm '<tt>sqrt</tt>' functions would.  Unlike
 <tt>sqrt</tt> in libm, however, <tt>llvm.sqrt</tt> has undefined behavior for
-negative numbers (which allows for better optimization).
+negative numbers other than -0.0 (which allows for better optimization, because
+there is no need to worry about errno being set).  <tt>llvm.sqrt(-0.0)</tt> is
+defined to return -0.0 like IEEE sqrt.
 </p>
 
 <h5>Arguments:</h5>
@@ -5112,6 +5313,277 @@ declare i8* @llvm.init.trampoline(i8* &lt;tramp&gt;, i8* &lt;func&gt;, i8* &lt;n
 </p>
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="int_atomics">Atomic Operations and Synchronization Intrinsics</a>
+</div>
+
+<div class="doc_text">
+<p>
+  These intrinsic functions expand the "universal IR" of LLVM to represent 
+  hardware constructs for atomic operations and memory synchronization.  This 
+  provides an interface to the hardware, not an interface to the programmer. It 
+  is aimed at a low enough level to allow any programming models or APIs which 
+  need atomic behaviors to map cleanly onto it. It is also modeled primarily on 
+  hardware behavior. Just as hardware provides a "universal IR" for source 
+  languages, it also provides a starting point for developing a "universal" 
+  atomic operation and synchronization IR.
+</p>
+<p>
+  These do <em>not</em> form an API such as high-level threading libraries, 
+  software transaction memory systems, atomic primitives, and intrinsic 
+  functions as found in BSD, GNU libc, atomic_ops, APR, and other system and 
+  application libraries.  The hardware interface provided by LLVM should allow 
+  a clean implementation of all of these APIs and parallel programming models. 
+  No one model or paradigm should be selected above others unless the hardware 
+  itself ubiquitously does so.
+
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="int_memory_barrier">'<tt>llvm.memory.barrier</tt>' Intrinsic</a>
+</div>
+<div class="doc_text">
+<h5>Syntax:</h5>
+<pre>
+declare void @llvm.memory.barrier( i1 &lt;ll&gt;, i1 &lt;ls&gt;, i1 &lt;sl&gt;, i1 &lt;ss&gt;, 
+i1 &lt;device&gt; )
+
+</pre>
+<h5>Overview:</h5>
+<p>
+  The <tt>llvm.memory.barrier</tt> intrinsic guarantees ordering between 
+  specific pairs of memory access types.
+</p>
+<h5>Arguments:</h5>
+<p>
+  The <tt>llvm.memory.barrier</tt> intrinsic requires five boolean arguments. 
+  The first four arguments enables a specific barrier as listed below.  The fith
+  argument specifies that the barrier applies to io or device or uncached memory.
+
+</p>
+  <ul>
+    <li><tt>ll</tt>: load-load barrier</li>
+    <li><tt>ls</tt>: load-store barrier</li>
+    <li><tt>sl</tt>: store-load barrier</li>
+    <li><tt>ss</tt>: store-store barrier</li>
+    <li><tt>device</tt>: barrier applies to device and uncached memory also.
+  </ul>
+<h5>Semantics:</h5>
+<p>
+  This intrinsic causes the system to enforce some ordering constraints upon 
+  the loads and stores of the program. This barrier does not indicate 
+  <em>when</em> any events will occur, it only enforces an <em>order</em> in 
+  which they occur. For any of the specified pairs of load and store operations 
+  (f.ex.  load-load, or store-load), all of the first operations preceding the 
+  barrier will complete before any of the second operations succeeding the 
+  barrier begin. Specifically the semantics for each pairing is as follows:
+</p>
+  <ul>
+    <li><tt>ll</tt>: All loads before the barrier must complete before any load 
+    after the barrier begins.</li>
+
+    <li><tt>ls</tt>: All loads before the barrier must complete before any 
+    store after the barrier begins.</li>
+    <li><tt>ss</tt>: All stores before the barrier must complete before any 
+    store after the barrier begins.</li>
+    <li><tt>sl</tt>: All stores before the barrier must complete before any 
+    load after the barrier begins.</li>
+  </ul>
+<p>
+  These semantics are applied with a logical "and" behavior when more than  one 
+  is enabled in a single memory barrier intrinsic.  
+</p>
+<p>
+  Backends may implement stronger barriers than those requested when they do not
+  support as fine grained a barrier as requested.  Some architectures do not
+  need all types of barriers and on such architectures, these become noops.
+</p>
+<h5>Example:</h5>
+<pre>
+%ptr      = malloc i32
+            store i32 4, %ptr
+
+%result1  = load i32* %ptr      <i>; yields {i32}:result1 = 4</i>
+            call void @llvm.memory.barrier( i1 false, i1 true, i1 false, i1 false )
+                                <i>; guarantee the above finishes</i>
+            store i32 8, %ptr   <i>; before this begins</i>
+</pre>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="int_atomic_lcs">'<tt>llvm.atomic.lcs.*</tt>' Intrinsic</a>
+</div>
+<div class="doc_text">
+<h5>Syntax:</h5>
+<p>
+  This is an overloaded intrinsic. You can use <tt>llvm.atomic.lcs</tt> on any 
+  integer bit width. Not all targets support all bit widths however.</p>
+
+<pre>
+declare i8 @llvm.atomic.lcs.i8( i8* &lt;ptr&gt;, i8 &lt;cmp&gt;, i8 &lt;val&gt; )
+declare i16 @llvm.atomic.lcs.i16( i16* &lt;ptr&gt;, i16 &lt;cmp&gt;, i16 &lt;val&gt; )
+declare i32 @llvm.atomic.lcs.i32( i32* &lt;ptr&gt;, i32 &lt;cmp&gt;, i32 &lt;val&gt; )
+declare i64 @llvm.atomic.lcs.i64( i64* &lt;ptr&gt;, i64 &lt;cmp&gt;, i64 &lt;val&gt; )
+
+</pre>
+<h5>Overview:</h5>
+<p>
+  This loads a value in memory and compares it to a given value. If they are 
+  equal, it stores a new value into the memory.
+</p>
+<h5>Arguments:</h5>
+<p>
+  The <tt>llvm.atomic.lcs</tt> intrinsic takes three arguments. The result as 
+  well as both <tt>cmp</tt> and <tt>val</tt> must be integer values with the 
+  same bit width. The <tt>ptr</tt> argument must be a pointer to a value of 
+  this integer type. While any bit width integer may be used, targets may only 
+  lower representations they support in hardware.
+
+</p>
+<h5>Semantics:</h5>
+<p>
+  This entire intrinsic must be executed atomically. It first loads the value 
+  in memory pointed to by <tt>ptr</tt> and compares it with the value 
+  <tt>cmp</tt>. If they are equal, <tt>val</tt> is stored into the memory. The 
+  loaded value is yielded in all cases. This provides the equivalent of an 
+  atomic compare-and-swap operation within the SSA framework.
+</p>
+<h5>Examples:</h5>
+
+<pre>
+%ptr      = malloc i32
+            store i32 4, %ptr
+
+%val1     = add i32 4, 4
+%result1  = call i32 @llvm.atomic.lcs.i32( i32* %ptr, i32 4, %val1 )
+                                          <i>; yields {i32}:result1 = 4</i>
+%stored1  = icmp eq i32 %result1, 4       <i>; yields {i1}:stored1 = true</i>
+%memval1  = load i32* %ptr                <i>; yields {i32}:memval1 = 8</i>
+
+%val2     = add i32 1, 1
+%result2  = call i32 @llvm.atomic.lcs.i32( i32* %ptr, i32 5, %val2 )
+                                          <i>; yields {i32}:result2 = 8</i>
+%stored2  = icmp eq i32 %result2, 5       <i>; yields {i1}:stored2 = false</i>
+
+%memval2  = load i32* %ptr                <i>; yields {i32}:memval2 = 8</i>
+</pre>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="int_atomic_swap">'<tt>llvm.atomic.swap.*</tt>' Intrinsic</a>
+</div>
+<div class="doc_text">
+<h5>Syntax:</h5>
+
+<p>
+  This is an overloaded intrinsic. You can use <tt>llvm.atomic.swap</tt> on any 
+  integer bit width. Not all targets support all bit widths however.</p>
+<pre>
+declare i8 @llvm.atomic.swap.i8( i8* &lt;ptr&gt;, i8 &lt;val&gt; )
+declare i16 @llvm.atomic.swap.i16( i16* &lt;ptr&gt;, i16 &lt;val&gt; )
+declare i32 @llvm.atomic.swap.i32( i32* &lt;ptr&gt;, i32 &lt;val&gt; )
+declare i64 @llvm.atomic.swap.i64( i64* &lt;ptr&gt;, i64 &lt;val&gt; )
+
+</pre>
+<h5>Overview:</h5>
+<p>
+  This intrinsic loads the value stored in memory at <tt>ptr</tt> and yields 
+  the value from memory. It then stores the value in <tt>val</tt> in the memory 
+  at <tt>ptr</tt>.
+</p>
+<h5>Arguments:</h5>
+
+<p>
+  The <tt>llvm.atomic.ls</tt> intrinsic takes two arguments. Both the 
+  <tt>val</tt> argument and the result must be integers of the same bit width. 
+  The first argument, <tt>ptr</tt>, must be a pointer to a value of this 
+  integer type. The targets may only lower integer representations they 
+  support.
+</p>
+<h5>Semantics:</h5>
+<p>
+  This intrinsic loads the value pointed to by <tt>ptr</tt>, yields it, and 
+  stores <tt>val</tt> back into <tt>ptr</tt> atomically. This provides the 
+  equivalent of an atomic swap operation within the SSA framework.
+
+</p>
+<h5>Examples:</h5>
+<pre>
+%ptr      = malloc i32
+            store i32 4, %ptr
+
+%val1     = add i32 4, 4
+%result1  = call i32 @llvm.atomic.swap.i32( i32* %ptr, i32 %val1 )
+                                        <i>; yields {i32}:result1 = 4</i>
+%stored1  = icmp eq i32 %result1, 4     <i>; yields {i1}:stored1 = true</i>
+%memval1  = load i32* %ptr              <i>; yields {i32}:memval1 = 8</i>
+
+%val2     = add i32 1, 1
+%result2  = call i32 @llvm.atomic.swap.i32( i32* %ptr, i32 %val2 )
+                                        <i>; yields {i32}:result2 = 8</i>
+
+%stored2  = icmp eq i32 %result2, 8     <i>; yields {i1}:stored2 = true</i>
+%memval2  = load i32* %ptr              <i>; yields {i32}:memval2 = 2</i>
+</pre>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="int_atomic_las">'<tt>llvm.atomic.las.*</tt>' Intrinsic</a>
+
+</div>
+<div class="doc_text">
+<h5>Syntax:</h5>
+<p>
+  This is an overloaded intrinsic. You can use <tt>llvm.atomic.las</tt> on any 
+  integer bit width. Not all targets support all bit widths however.</p>
+<pre>
+declare i8 @llvm.atomic.las.i8.( i8* &lt;ptr&gt;, i8 &lt;delta&gt; )
+declare i16 @llvm.atomic.las.i16.( i16* &lt;ptr&gt;, i16 &lt;delta&gt; )
+declare i32 @llvm.atomic.las.i32.( i32* &lt;ptr&gt;, i32 &lt;delta&gt; )
+declare i64 @llvm.atomic.las.i64.( i64* &lt;ptr&gt;, i64 &lt;delta&gt; )
+
+</pre>
+<h5>Overview:</h5>
+<p>
+  This intrinsic adds <tt>delta</tt> to the value stored in memory at 
+  <tt>ptr</tt>. It yields the original value at <tt>ptr</tt>.
+</p>
+<h5>Arguments:</h5>
+<p>
+
+  The intrinsic takes two arguments, the first a pointer to an integer value 
+  and the second an integer value. The result is also an integer value. These 
+  integer types can have any bit width, but they must all have the same bit 
+  width. The targets may only lower integer representations they support.
+</p>
+<h5>Semantics:</h5>
+<p>
+  This intrinsic does a series of operations atomically. It first loads the 
+  value stored at <tt>ptr</tt>. It then adds <tt>delta</tt>, stores the result 
+  to <tt>ptr</tt>. It yields the original value stored at <tt>ptr</tt>.
+</p>
+
+<h5>Examples:</h5>
+<pre>
+%ptr      = malloc i32
+        store i32 4, %ptr
+%result1  = call i32 @llvm.atomic.las.i32( i32* %ptr, i32 4 )
+                                <i>; yields {i32}:result1 = 4</i>
+%result2  = call i32 @llvm.atomic.las.i32( i32* %ptr, i32 2 )
+                                <i>; yields {i32}:result2 = 8</i>
+%result3  = call i32 @llvm.atomic.las.i32( i32* %ptr, i32 5 )
+                                <i>; yields {i32}:result3 = 10</i>
+%memval   = load i32* %ptr      <i>; yields {i32}:memval1 = 15</i>
+</pre>
+</div>
+
+
 <!-- ======================================================================= -->
 <div class="doc_subsection">
   <a name="int_general">General Intrinsics</a>
@@ -5151,10 +5623,11 @@ file name, and the last argument is the line number.
 <h5>Semantics:</h5>
 
 <p>
-This intrinsic allows annotation of local variables with arbitrary strings.  
+This intrinsic allows annotation of local variables with arbitrary strings.
 This can be useful for special purpose optimizations that want to look for these
- annotations.  These have no other defined use, they are ignored by code 
- generation and optimization.
+annotations.  These have no other defined use, they are ignored by code
+generation and optimization.
+</p>
 </div>
 
 <!-- _______________________________________________________________________ -->
@@ -5200,17 +5673,51 @@ that want to look for these annotations.  These have no other defined use, they
 are ignored by code generation and optimization.
 </div>
 
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+  <a name="int_trap">'<tt>llvm.trap</tt>' Intrinsic</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+<pre>
+  declare void @llvm.trap()
+</pre>
+
+<h5>Overview:</h5>
+
+<p>
+The '<tt>llvm.trap</tt>' intrinsic
+</p>
+
+<h5>Arguments:</h5>
+
+<p>
+None
+</p>
+
+<h5>Semantics:</h5>
+
+<p>
+This intrinsics is lowered to the target dependent trap instruction. If the
+target does not have a trap instruction, this intrinsic will be lowered to the
+call of the abort() function.
+</p>
+</div>
+
 <!-- *********************************************************************** -->
 <hr>
 <address>
   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
   src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
   <a href="http://validator.w3.org/check/referer"><img
-  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
+  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
 
   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
   <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
   Last modified: $Date$
 </address>
+
 </body>
 </html>