Well, to be honest, -array-checks and -trace are gone, too. :-)
[oota-llvm.git] / docs / LangRef.html
index 59f9dafb761cda330fab6522726690657571a5bd..03235ecaa40733b7a67825827695ed25d94594d7 100644 (file)
@@ -72,7 +72,8 @@
           <li><a href="#i_phi"  >'<tt>phi</tt>'   Instruction</a>
           <li><a href="#i_cast">'<tt>cast .. to</tt>' Instruction</a>
           <li><a href="#i_call" >'<tt>call</tt>'  Instruction</a>
-          <li><a href="#i_va_arg">'<tt>va_arg</tt>' Instruction</a>
+          <li><a href="#i_vanext">'<tt>vanext</tt>' Instruction</a>
+          <li><a href="#i_vaarg" >'<tt>vaarg</tt>'  Instruction</a>
         </ol>
     </ol>
   <li><a href="#intrinsics">Intrinsic Functions</a>
@@ -310,8 +311,11 @@ These different primitive types fall into a few useful classifications:<p>
 <tr><td><a name="t_firstclass">first class</td><td><tt>bool, ubyte, sbyte, ushort, short,<br> uint, int, ulong, long, float, double, <a href="#t_pointer">pointer</a></tt></td></tr>
 </table><p>
 
-
-
+The <a href="#t_firstclass">first class</a> types are perhaps the most
+important.  Values of these types are the only ones which can be produced by
+instructions, passed as arguments, or used as operands to instructions.  This
+means that all structures and arrays must be manipulated either by pointer or by
+component.<p>
 
 
 <!-- ======================================================================= -->
@@ -541,7 +545,15 @@ or the idea of "anonymous namespaces" in C++.<p>
 <dd>"<tt>linkonce</tt>" linkage is similar to <tt>internal</tt> linkage, with
 the twist that linking together two modules defining the same <tt>linkonce</tt>
 globals will cause one of the globals to be discarded.  This is typically used
-to implement inline functions.<p>
+to implement inline functions.  Unreferenced <tt>linkonce</tt> globals are
+allowed to be discarded.<p>
+
+<a name="linkage_weak">
+<dt><tt><b>weak</b></tt>:
+
+<dd>"<tt>weak</tt>" linkage is exactly the same as <tt>linkonce</tt> linkage,
+except that unreferenced <tt>weak</tt> globals may not be discarded.  This is
+used to implement constructs in C such as "<tt>int X;</tt>" at global scope.<p>
 
 <a name="linkage_appending">
 <dt><tt><b>appending</b></tt>:
@@ -1044,10 +1056,10 @@ Forum</a>.<p>
 boolean value based on a comparison of their two operands.<p>
 
 <h5>Arguments:</h5> The two arguments to the '<tt>set<i>cc</i></tt>'
-instructions must be of <a href="#t_firstclass">first class</a> or <a
-href="#t_pointer">pointer</a> type (it is not possible to compare
-'<tt>label</tt>'s, '<tt>array</tt>'s, '<tt>structure</tt>' or '<tt>void</tt>'
-values, etc...).  Both arguments must have identical types.<p>
+instructions must be of <a href="#t_firstclass">first class</a> type (it is not
+possible to compare '<tt>label</tt>'s, '<tt>array</tt>'s, '<tt>structure</tt>'
+or '<tt>void</tt>' values, etc...).  Both arguments must have identical
+types.<p>
 
 <h5>Semantics:</h5>
 
@@ -1405,6 +1417,7 @@ instructions), the memory is reclaimed.<p>
 <h5>Syntax:</h5>
 <pre>
   &lt;result&gt; = load &lt;ty&gt;* &lt;pointer&gt;
+  &lt;result&gt; = volatile load &lt;ty&gt;* &lt;pointer&gt;
 </pre>
 
 <h5>Overview:</h5>
@@ -1412,7 +1425,12 @@ The '<tt>load</tt>' instruction is used to read from memory.<p>
 
 <h5>Arguments:</h5>
 
-The argument to the '<tt>load</tt>' instruction specifies the memory address to load from.  The pointer must point to a <a href="t_firstclass">first class</a> type.<p>
+The argument to the '<tt>load</tt>' instruction specifies the memory address to
+load from.  The pointer must point to a <a href="t_firstclass">first class</a>
+type.  If the <tt>load</tt> is 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>
 
 <h5>Semantics:</h5>
 
@@ -1434,6 +1452,7 @@ The location of memory pointed to is loaded.
 <h5>Syntax:</h5>
 <pre>
   store &lt;ty&gt; &lt;value&gt;, &lt;ty&gt;* &lt;pointer&gt;                   <i>; yields {void}</i>
+  volatile store &lt;ty&gt; &lt;value&gt;, &lt;ty&gt;* &lt;pointer&gt;                   <i>; yields {void}</i>
 </pre>
 
 <h5>Overview:</h5>
@@ -1443,8 +1462,11 @@ The '<tt>store</tt>' instruction is used to write to memory.<p>
 
 There are two arguments to the '<tt>store</tt>' instruction: a value to store
 and an address to store it into.  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.<p>
+operand must be a pointer to the 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>
 
 <h5>Semantics:</h5> The contents of memory are updated to contain
 '<tt>&lt;value&gt;</tt>' at the location specified by the
@@ -1562,7 +1584,7 @@ int* "foo"(%ST* %s) {
 <a name="otherops">Other Operations
 </b></font></td></tr></table><ul>
 
-The instructions in this catagory are the "miscellaneous" functions, that defy better classification.<p>
+The instructions in this catagory are the "miscellaneous" instructions, which defy better classification.<p>
 
 
 <!-- _______________________________________________________________________ -->
@@ -1582,7 +1604,9 @@ graph representing the function.<p>
 
 The type of the incoming values are specified with the first type field.  After
 this, the '<tt>phi</tt>' instruction takes a list of pairs as arguments, with
-one pair for each predecessor basic block of the current block.<p>
+one pair for each predecessor basic block of the current block.  Only values of
+<a href="#t_firstclass">first class</a> type may be used as the value arguments
+to the PHI node.  Only labels may be used as the label arguments.<p>
 
 There must be no non-phi instructions between the start of a basic block and the
 PHI instructions: i.e. PHI instructions must be first in a basic block.<p>
@@ -1620,7 +1644,8 @@ casting pointers).<p>
 <h5>Arguments:</h5>
 
 The '<tt>cast</tt>' instruction takes a value to cast, which must be a first
-class value, and a type to cast it to, which must also be a first class type.<p>
+class value, and a type to cast it to, which must also be a <a
+href="#t_firstclass">first class</a> type.<p>
 
 <h5>Semantics:</h5>
 
@@ -1692,44 +1717,87 @@ case of the <a href="#i_invoke">invoke</a> instruction.<p>
 </pre>
 
 <!-- _______________________________________________________________________ -->
-</ul><a name="i_va_arg"><h4><hr size=0>'<tt>va_arg</tt>' Instruction</h4><ul>
+</ul><a name="i_vanext"><h4><hr size=0>'<tt>vanext</tt>' Instruction</h4><ul>
+
+<h5>Syntax:</h5>
+<pre>
+  &lt;resultarglist&gt; = vanext &lt;va_list&gt; &lt;arglist&gt;, &lt;argty&gt;
+</pre>
+
+<h5>Overview:</h5>
+
+The '<tt>vanext</tt>' instruction is used to access arguments passed through
+the "variable argument" area of a function call.  It is used to implement the
+<tt>va_arg</tt> macro in C.<p>
+
+<h5>Arguments:</h5>
+
+This instruction takes a <tt>valist</tt> value and the type of the argument.  It
+returns another <tt>valist</tt>.
+
+<h5>Semantics:</h5>
+
+The '<tt>vanext</tt>' instruction advances the specified <tt>valist</tt> past
+an argument of the specified type.  In conjunction with the <a
+href="#i_vaarg"><tt>vaarg</tt></a> instruction, it is used to implement the
+<tt>va_arg</tt> macro available in C.  For more information, see the variable
+argument handling <a href="#int_varargs">Intrinsic Functions</a>.<p>
+
+It is legal for this instruction to be called in a function which does not take
+a variable number of arguments, for example, the <tt>vfprintf</tt> function.<p>
+
+<tt>vanext</tt> is an LLVM instruction instead of an <a
+href="#intrinsics">intrinsic function</a> because it takes an type as an
+argument.</p>
+
+<h5>Example:</h5>
+
+See the <a href="#int_varargs">variable argument processing</a> section.<p>
+
+
+
+<!-- _______________________________________________________________________ -->
+</ul><a name="i_vaarg"><h4><hr size=0>'<tt>vaarg</tt>' Instruction</h4><ul>
 
 <h5>Syntax:</h5>
 <pre>
-  &lt;result&gt; = va_arg &lt;va_list&gt;* &lt;arglist&gt;, &lt;retty&gt;
+  &lt;resultval&gt; = vaarg &lt;va_list&gt; &lt;arglist&gt;, &lt;argty&gt;
 </pre>
 
 <h5>Overview:</h5>
 
-The '<tt>va_arg</tt>' instruction is used to access arguments passed through the
-"variable argument" area of a function call.  It corresponds directly to the
+The '<tt>vaarg</tt>' instruction is used to access arguments passed through
+the "variable argument" area of a function call.  It is used to implement the
 <tt>va_arg</tt> macro in C.<p>
 
 <h5>Arguments:</h5>
 
-This instruction takes a pointer to a <tt>valist</tt> value to read a new
-argument from.  The return type of the instruction is defined by the second
-argument, a type.<p>
+This instruction takes a <tt>valist</tt> value and the type of the argument.  It
+returns a value of the specified argument type.
 
 <h5>Semantics:</h5>
 
-The '<tt>va_arg</tt>' instruction works just like the <tt>va_arg</tt> macro
-available in C.  In a target-dependent way, it reads the argument indicated by
-the value the arglist points to, updates the arglist, then returns a value of
-the specified type.  This instruction should be used in conjunction with the
-variable argument handling <a href="#int_varargs">Intrinsic Functions</a>.<p>
+The '<tt>vaarg</tt>' instruction loads an argument of the specified type from
+the specified <tt>va_list</tt>.  In conjunction with the <a
+href="#i_vanext"><tt>vanext</tt></a> instruction, it is used to implement the
+<tt>va_arg</tt> macro available in C.  For more information, see the variable
+argument handling <a href="#int_varargs">Intrinsic Functions</a>.<p>
 
 It is legal for this instruction to be called in a function which does not take
 a variable number of arguments, for example, the <tt>vfprintf</tt> function.<p>
 
-<tt>va_arg</tt> is an LLVM instruction instead of an <a
-href="#intrinsics">intrinsic function</a> because the return type depends on an
-argument.<p>
+<tt>vaarg</tt> is an LLVM instruction instead of an <a
+href="#intrinsics">intrinsic function</a> because it takes an type as an
+argument.</p>
 
 <h5>Example:</h5>
 
 See the <a href="#int_varargs">variable argument processing</a> section.<p>
 
+
+
+
+
 <!-- *********************************************************************** -->
 </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
 <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
@@ -1763,37 +1831,35 @@ function.<p>
 </b></font></td></tr></table><ul>
 
 Variable argument support is defined in LLVM with the <a
-href="#i_va_arg"><tt>va_arg</tt></a> instruction and these three intrinsic
-functions.  These function correspond almost directly to the similarly named
-macros defined in the <tt>&lt;stdarg.h&gt;</tt> header file.<p>
+href="#i_vanext"><tt>vanext</tt></a> instruction and these three intrinsic
+functions.  These functions are related to the similarly named macros defined in
+the <tt>&lt;stdarg.h&gt;</tt> header file.<p>
 
-All of these functions operate on arguments that use a target-specific type
-"<tt>va_list</tt>".  The LLVM assembly language reference manual does not define
-what this type is, so all transformations should be prepared to handle
+All of these functions operate on arguments that use a target-specific value
+type "<tt>va_list</tt>".  The LLVM assembly language reference manual does not
+define what this type is, so all transformations should be prepared to handle
 intrinsics with any type used.<p>
 
-This example shows how the <a href="#i_va_arg"><tt>va_arg</tt></a> instruction
+This example shows how the <a href="#i_vanext"><tt>vanext</tt></a> instruction
 and the variable argument handling intrinsic functions are used.<p>
 
 <pre>
 int %test(int %X, ...) {
-  ; Allocate two va_list items.  On this target, va_list is of type sbyte*
-  %ap = alloca sbyte*
-  %aq = alloca sbyte*
-
   ; Initialize variable argument processing
-  call void (sbyte**)* %<a href="#i_va_start">llvm.va_start</a>(sbyte** %ap)
+  %ap = call sbyte*()* %<a href="#i_va_start">llvm.va_start</a>()
 
   ; Read a single integer argument
-  %tmp = <a href="#i_va_arg">va_arg</a> sbyte** %ap, int 
+  %tmp = vaarg sbyte* %ap, int
+
+  ; Advance to the next argument
+  %ap2 = vanext sbyte* %ap, int
 
-  ; Demonstrate usage of llvm.va_copy and llvm_va_end
-  %apv = load sbyte** %ap
-  call void %<a href="#i_va_copy">llvm.va_copy</a>(sbyte** %aq, sbyte* %apv)
-  call void %<a href="#i_va_end">llvm.va_end</a>(sbyte** %aq)
+  ; Demonstrate usage of llvm.va_copy and llvm.va_end
+  %aq = call sbyte* (sbyte*)* %<a href="#i_va_copy">llvm.va_copy</a>(sbyte* %ap2)
+  call void %<a href="#i_va_end">llvm.va_end</a>(sbyte* %aq)
 
   ; Stop processing of arguments.
-  call void %<a href="#i_va_end">llvm.va_end</a>(sbyte** %ap)
+  call void %<a href="#i_va_end">llvm.va_end</a>(sbyte* %ap2)
   ret int %tmp
 }
 </pre>
@@ -1803,28 +1869,25 @@ int %test(int %X, ...) {
 
 <h5>Syntax:</h5>
 <pre>
-  call void (va_list*)* %llvm.va_start(&lt;va_list&gt;* &lt;arglist&gt;)
+  call va_list ()* %llvm.va_start()
 </pre>
 
 <h5>Overview:</h5>
 
-The '<tt>llvm.va_start</tt>' intrinsic initializes <tt>*&lt;arglist&gt;</tt> for
-subsequent use by <tt><a href="#i_va_arg">va_arg</a></tt> and <tt><a
-href="#i_va_end">llvm.va_end</a></tt>, and must be called before either are
-invoked.<p>
-
-<h5>Arguments:</h5>
-
-The argument is a pointer to a <tt>va_list</tt> element to initialize.<p>
+The '<tt>llvm.va_start</tt>' intrinsic returns a new <tt>&lt;arglist&gt;</tt>
+for subsequent use by the variable argument intrinsics.<p>
 
 <h5>Semantics:</h5>
 
 The '<tt>llvm.va_start</tt>' intrinsic works just like the <tt>va_start</tt>
-macro available in C.  In a target-dependent way, it initializes the
-<tt>va_list</tt> element the argument points to, so that the next call to
-<tt>va_arg</tt> will produce the first variable argument passed to the function.
-Unlike the C <tt>va_start</tt> macro, this intrinsic does not need to know the
-last argument of the function, the compiler can figure that out.<p>
+macro available in C.  In a target-dependent way, it initializes and returns a
+<tt>va_list</tt> element, so that the next <tt>vaarg</tt> will produce the first
+variable argument passed to the function.  Unlike the C <tt>va_start</tt> macro,
+this intrinsic does not need to know the last argument of the function, the
+compiler can figure that out.<p>
+
+Note that this intrinsic function is only legal to be called from within the
+body of a variable argument function.<p>
 
 
 <!-- _______________________________________________________________________ -->
@@ -1832,25 +1895,25 @@ last argument of the function, the compiler can figure that out.<p>
 
 <h5>Syntax:</h5>
 <pre>
-  call void (va_list*)* %llvm.va_end(&lt;va_list&gt;* &lt;arglist&gt;)
+  call void (va_list)* %llvm.va_end(va_list &lt;arglist&gt;)
 </pre>
 
 <h5>Overview:</h5>
 
-The '<tt>llvm.va_end</tt>' intrinsic destroys <tt>*&lt;arglist&gt;</tt> which
-has been initialized previously with <tt><a
-href="#i_va_begin">llvm.va_begin</a></tt>.<p>
+The '<tt>llvm.va_end</tt>' intrinsic destroys <tt>&lt;arglist&gt;</tt> which has
+been initialized previously with <tt><a
+href="#i_va_start">llvm.va_start</a></tt> or <tt><a
+href="#i_va_copy">llvm.va_copy</a></tt>.<p>
 
 <h5>Arguments:</h5>
 
-The argument is a pointer to a <tt>va_list</tt> element to destroy.<p>
+The argument is a <tt>va_list</tt> to destroy.<p>
 
 <h5>Semantics:</h5>
 
 The '<tt>llvm.va_end</tt>' intrinsic works just like the <tt>va_end</tt> macro
-available in C.  In a target-dependent way, it destroys the <tt>va_list</tt>
-that the argument points to.  Calls to <a
-href="#i_va_start"><tt>llvm.va_start</tt></a> and <a
+available in C.  In a target-dependent way, it destroys the <tt>va_list</tt>.
+Calls to <a href="#i_va_start"><tt>llvm.va_start</tt></a> and <a
 href="#i_va_copy"><tt>llvm.va_copy</tt></a> must be matched exactly with calls
 to <tt>llvm.va_end</tt>.<p>
 
@@ -1861,8 +1924,7 @@ to <tt>llvm.va_end</tt>.<p>
 
 <h5>Syntax:</h5>
 <pre>
-  call void (va_list*, va_list)* %va_copy(&lt;va_list&gt;* &lt;destarglist&gt;,
-                                          &lt;va_list&gt; &lt;srcarglist&gt;)
+  call va_list (va_list)* %llvm.va_copy(va_list &lt;destarglist&gt;)
 </pre>
 
 <h5>Overview:</h5>
@@ -1872,16 +1934,14 @@ the source argument list to the destination argument list.<p>
 
 <h5>Arguments:</h5>
 
-The first argument is a pointer to a <tt>va_list</tt> element to initialize.
-The second argument is a <tt>va_list</tt> element to copy from.<p>
-
+The argument is the <tt>va_list</tt> to copy.
 
 <h5>Semantics:</h5>
 
 The '<tt>llvm.va_copy</tt>' intrinsic works just like the <tt>va_copy</tt> macro
 available in C.  In a target-dependent way, it copies the source
-<tt>va_list</tt> element into the destination list.  This intrinsic is necessary
-because the <tt><a href="i_va_begin">llvm.va_begin</a></tt> intrinsic may be
+<tt>va_list</tt> element into the returned list.  This intrinsic is necessary
+because the <tt><a href="i_va_start">llvm.va_start</a></tt> intrinsic may be
 arbitrarily complex and require memory allocation, for example.<p>
 
 
@@ -1893,9 +1953,11 @@ arbitrarily complex and require memory allocation, for example.<p>
 <hr>
 <font size=-1>
 <address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
+<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+<br>
 <!-- Created: Tue Jan 23 15:19:28 CST 2001 -->
 <!-- hhmts start -->
-Last modified: Tue Sep  2 19:41:01 CDT 2003
+Last modified: Wed Oct 29 19:30:46 CST 2003
 <!-- hhmts end -->
 </font>
 </body></html>