<li><a href="#i_br" >'<tt>br</tt>' Instruction</a>
<li><a href="#i_switch">'<tt>switch</tt>' Instruction</a>
<li><a href="#i_invoke">'<tt>invoke</tt>' Instruction</a>
+ <li><a href="#i_unwind" >'<tt>unwind</tt>' Instruction</a>
</ol>
<li><a href="#binaryops">Binary Operations</a>
<ol>
<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>
<li><a href="#i_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a>
<li><a href="#i_va_end" >'<tt>llvm.va_end</tt>' Intrinsic</a>
<li><a href="#i_va_copy" >'<tt>llvm.va_copy</tt>' Intrinsic</a>
- <li><a href="#i_unwind" >'<tt>llvm.unwind</tt>' Intrinsic</a>
</ol>
</ol>
LLVM uses three different forms of identifiers, for different purposes:<p>
<ol>
-<li>Numeric constants are represented as you would expect: 12, -3 123.421, etc. Floating point constants have an optional hexidecimal notation.
-<li>Named values are represented as a string of characters with a '%' prefix. For example, %foo, %DivisionByZero, %a.really.long.identifier. The actual regular expression used is '<tt>%[a-zA-Z$._][a-zA-Z$._0-9]*</tt>'.
-<li>Unnamed values are represented as an unsigned numeric value with a '%' prefix. For example, %12, %2, %44.
+<li>Numeric constants are represented as you would expect: 12, -3 123.421, etc.
+Floating point constants have an optional hexidecimal notation.
+
+<li>Named values are represented as a string of characters with a '%' prefix.
+For example, %foo, %DivisionByZero, %a.really.long.identifier. The actual
+regular expression used is '<tt>%[a-zA-Z$._][a-zA-Z$._0-9]*</tt>'. Identifiers
+which require other characters in their names can be surrounded with quotes. In
+this way, anything except a <tt>"</tt> character can be used in a name.
+
+<li>Unnamed values are represented as an unsigned numeric value with a '%'
+prefix. For example, %12, %2, %44.
</ol><p>
LLVM requires the values start with a '%' sign for two reasons: Compilers don't
<ul>
<table border=0 cellpadding=0 cellspacing=0>
<tr><td><tt>[3 x [4 x int]]</tt></td><td>: 3x4 array integer values.</td></tr>
-<tr><td><tt>[12 x [10 x float]]</tt></td><td>: 2x10 array of single precision floating point values.</td></tr>
+<tr><td><tt>[12 x [10 x float]]</tt></td><td>: 12x10 array of single precision floating point values.</td></tr>
<tr><td><tt>[2 x [3 x [4 x uint]]]</tt></td><td>: 2x3x4 array of unsigned integer values.</td></tr>
</table>
</ul>
Where '<tt><parameter list></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. Note
-that there currently is no way to define a function in LLVM that takes a
-variable number of arguments, but it is possible to <b>call</b> a function that
+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>
<h5>Examples:</h5>
<ul>
<pre>
<i>; Declare the string constant as a global constant...</i>
-<a href="#identifiers">%.LC0</a> = <a href="#linkage_
decl">internal</a> <a href="#globalvars">constant</a> <a href="#t_array">[13 x sbyte]</a> c"hello world\0A\00" <i>; [13 x sbyte]*</i>
+<a href="#identifiers">%.LC0</a> = <a href="#linkage_
internal">internal</a> <a href="#globalvars">constant</a> <a href="#t_array">[13 x sbyte]</a> c"hello world\0A\00" <i>; [13 x sbyte]*</i>
-<i>; Forward declaration of puts</i>
-<a href="#functionstructure">declare</a> int "puts"(sbyte*) <i>; int(sbyte*)* </i>
+<i>; External declaration of the puts function</i>
+<a href="#functionstructure">declare</a> int %puts(sbyte*) <i>; int(sbyte*)* </i>
<i>; Definition of main function</i>
-int "main"() { <i>; int()* </i>
+int %main() { <i>; int()* </i>
<i>; Convert [13x sbyte]* to sbyte *...</i>
%cast210 = <a href="#i_getelementptr">getelementptr</a> [13 x sbyte]* %.LC0, long 0, long 0 <i>; sbyte*</i>
"<tt>.LC0</tt>", an external declaration of the "<tt>puts</tt>" function, and a
<a href="#functionstructure">function definition</a> for "<tt>main</tt>".<p>
-<a name="linkage_decl">
+<a name="linkage">
In general, a module is made up of a list of global values, where both functions
and global variables are global values. Global values are represented by a
pointer to a memory location (in this case, a pointer to an array of char, and a
-pointer to a function), and can be either "internal" or externally accessible
-(which corresponds to the static keyword in C, when used at global scope).<p>
+pointer to a function), and have one of the following linkage types:<p>
+
+<dl>
+<a name="linkage_internal">
+<dt><tt><b>internal</b></tt>
+
+<dd>Global values with internal linkage are only directly accessible by objects
+in the current module. In particular, linking code into a module with an
+internal global value may cause the internal to be renamed as necessary to avoid
+collisions. Because the symbol is internal to the module, all references can be
+updated. This corresponds to the notion of the '<tt>static</tt>' keyword in C,
+or the idea of "anonymous namespaces" in C++.<p>
+
+<a name="linkage_linkonce">
+<dt><tt><b>linkonce</b></tt>:
+
+<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. 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>:
+
+<dd>"<tt>appending</tt>" linkage may only applied to global variables of pointer
+to array type. When two global variables with appending linkage are linked
+together, the two global arrays are appended together. This is the LLVM,
+typesafe, equivalent of having the system linker append together "sections" with
+identical names when .o files are linked.<p>
+
+<a name="linkage_external">
+<dt><tt><b>externally visible</b></tt>:
+
+<dd>If none of the above identifiers are used, the global is externally visible,
+meaning that it participates in linkage and can be used to resolve external
+symbol references.<p>
+
+</dl><p>
+
For example, since the "<tt>.LC0</tt>" variable is defined to be internal, if
another module defined a "<tt>.LC0</tt>" variable and was linked with this one,
one of the two would be renamed, preventing a collision. Since "<tt>main</tt>"
-and "<tt>puts</tt>" are external (i.e., lacking "<tt>internal</tt>"
-declarations), they are accessible outside of the current module. It is illegal
-
for a function declaration to be "<tt>internal</tt>".<p>
+and "<tt>puts</tt>" are external (i.e., lacking any linkage declarations), they
+are accessible outside of the current module. It is illegal for a function
+
<i>declaration</i> to have any linkage type other than "externally visible".<p>
<!-- ======================================================================= -->
<!-- ======================================================================= -->
</ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
<tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
-<a name="functionstructure">Function Structure
+<a name="functionstructure">Functions
</b></font></td></tr></table><ul>
LLVM functions definitions are composed of a (possibly empty) argument list, an
The first basic block in program is special in two ways: it is immediately
executed on entrance to the function, and it is not allowed to have predecessor
basic blocks (i.e. there can not be any branches to the entry block of a
-function).<p>
+function). Because the block can have no predecessors, it also cannot have any
+<a href="#i_phi">PHI nodes</a>.<p>
<!-- *********************************************************************** -->
(the one exception being the '<a href="#i_invoke"><tt>invoke</tt></a>'
instruction).<p>
-There are f
our different terminator instructions: the '<a
+There are f
ive different terminator instructions: the '<a
href="#i_ret"><tt>ret</tt></a>' instruction, the '<a
href="#i_br"><tt>br</tt></a>' instruction, the '<a
-href="#i_switch"><tt>switch</tt></a>' instruction, and the '<a
-href="#i_invoke"><tt>invoke</tt></a>' instruction.<p>
+href="#i_switch"><tt>switch</tt></a>' instruction, the '<a
+href="#i_invoke"><tt>invoke</tt></a>' instruction, and the '<a
+href="#i_unwind"><tt>unwind</tt></a>' instruction.<p>
<!-- _______________________________________________________________________ -->
<h5>Semantics:</h5>
When the '<tt>ret</tt>' instruction is executed, control flow returns back to
-the calling function's context. If the instruction returns a value, that value
-shall be propagated into the calling function's data space.<p>
+the calling function's context. If the caller is a "<a
+href="#i_call"><tt>call</tt></a> instruction, execution continues at the
+instruction after the call. If the caller was an "<a
+href="#i_invoke"><tt>invoke</tt></a>" instruction, execution continues at the
+beginning "normal" of the destination block. If the instruction returns a
+value, that value shall set the call or invoke instruction's return value.<p>
+
<h5>Example:</h5>
<pre>
Upon execution of a conditional '<tt>br</tt>' instruction, the '<tt>bool</tt>'
argument is evaluated. If the value is <tt>true</tt>, control flows to the
-'<tt>iftrue</tt>' '<tt>label</tt>' argument. If "cond" is <tt>false</tt>,
-control flows to the '<tt>iffalse</tt>'
'<tt>label</tt>' argument.<p>
+'<tt>iftrue</tt>' <tt>label</tt> argument. If "cond" is <tt>false</tt>,
+control flows to the '<tt>iffalse</tt>'
<tt>label</tt> argument.<p>
<h5>Example:</h5>
<pre>
<h5>Syntax:</h5>
<pre>
- switch int <value>, label <defaultdest> [ int <val>, label &dest>, ... ]
+ switch uint <value>, label <defaultdest> [ int <val>, label &dest>, ... ]
</pre>
<pre>
<i>; Emulate a conditional br instruction</i>
%Val = <a href="#i_cast">cast</a> bool %value to uint
- switch int %Val, label %truedest [int 0, label %falsedest ]
+ switch uint %Val, label %truedest [int 0, label %falsedest ]
<i>; Emulate an unconditional br instruction</i>
- switch int 0, label %dest [ ]
+ switch uint 0, label %dest [ ]
<i>; Implement a jump table:</i>
- switch int %val, label %otherwise [ int 0, label %onzero,
- int 1, label %onone,
- int 2, label %ontwo ]
+ switch uint %val, label %otherwise [ int 0, label %onzero,
+ int 1, label %onone,
+ int 2, label %ontwo ]
</pre>
The '<tt>invoke</tt>' instruction causes control to transfer to a specified
function, with the possibility of control flow transfer to either the
-'<tt>normal label</tt>' label or the '<tt>exception label</tt>'. If the callee
-function invokes 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)
-calls the "<a href="#i_unwind"><tt>llvm.unwind</tt></a>" intrinsic, control is
-interrupted, and continued at the "except" label.<p>
+'<tt>normal</tt>' <tt>label</tt> label or the '<tt>exception</tt>'
+<tt>label</tt>. If the callee function returns with 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 "except" label.<p>
<h5>Arguments:</h5>
<li>'<tt>normal label</tt>': the label reached when the called function executes
a '<tt><a href="#i_ret">ret</a></tt>' instruction.
-<li>'<tt>exception label</tt>': the label reached when a callee calls the <a
-href="#i_unwind"><tt>llvm.unwind</tt></a> intrinsic.
+<li>'<tt>exception label</tt>': the label reached when a callee returns with the
+<a href="#i_unwind"><tt>unwind</tt></a> instruction.
</ol>
<h5>Semantics:</h5>
except label %TestCleanup <i>; {int}:retval set</i>
</pre>
+<!-- _______________________________________________________________________ -->
+</ul><a name="i_unwind"><h4><hr size=0>'<tt>unwind</tt>' Instruction</h4><ul>
+
+<h5>Syntax:</h5>
+<pre>
+ unwind
+</pre>
+
+<h5>Overview:</h5>
+
+The '<tt>unwind</tt>' instruction unwinds the stack, continuing control flow at
+the first callee in the dynamic call stack which used an <a
+href="#i_invoke"><tt>invoke</tt></a> instruction to perform the call. This is
+primarily used to implement exception handling.
+
+<h5>Semantics:</h5>
+
+The '<tt>unwind</tt>' intrinsic causes execution of the current function to
+immediately halt. The dynamic call stack is then searched for the first <a
+href="#i_invoke"><tt>invoke</tt></a> instruction on the call stack. Once found,
+execution continues at the "exceptional" destination block specified by the
+<tt>invoke</tt> instruction. If there is no <tt>invoke</tt> instruction in the
+dynamic call chain, undefined behavior results.
+
<!-- ======================================================================= -->
Binary operators are used to do most of the computation in a program. They
require two operands, execute an operation on them, and produce a single value.
-The result value of a binary operator is not neccesarily the same type as its
+The result value of a binary operator is not necessarily the same type as its
operands.<p>
There are several different binary operators:<p>
'<tt>label</tt>'s, '<tt>array</tt>'s, '<tt>structure</tt>' or '<tt>void</tt>'
values, etc...). Both arguments must have identical types.<p>
-The '<tt>setlt</tt>', '<tt>setgt</tt>', '<tt>setle</tt>', and '<tt>setge</tt>'
-instructions do not operate on '<tt>bool</tt>' typed arguments.<p>
-
<h5>Semantics:</h5>
The '<tt>seteq</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
<h5>Overview:</h5>
The '<tt>xor</tt>' instruction returns the bitwise logical exclusive or of its
-two operands.<p>
+two operands. The <tt>xor</tt> is used to implement the "one's complement"
+operation, which is the "~" operator in C.<p>
<h5>Arguments:</h5>
<result> = xor int 4, %var <i>; yields {int}:result = 4 ^ %var</i>
<result> = xor int 15, 40 <i>; yields {int}:result = 39</i>
<result> = xor int 4, 8 <i>; yields {int}:result = 12</i>
+ <result> = xor int %V, -1 <i>; yields {int}:result = ~%V</i>
</pre>
<a name="memoryops">Memory Access Operations
</b></font></td></tr></table><ul>
-Accessing memory in SSA form is, well, sticky at best. This section describes how to read, write, allocate and free memory in LLVM.<p>
+A key design point of an SSA-based representation is how it represents memory.
+In LLVM, no memory locations are in SSA form, which makes things very simple.
+This section describes how to read, write, allocate and free memory in LLVM.<p>
<!-- _______________________________________________________________________ -->
second form of the instruction is a shorter version of the first instruction
that defaults to allocating one element.<p>
-'<tt>type</tt>' must be a sized type<p>
+'<tt>type</tt>' must be a sized type
.<p>
<h5>Semantics:</h5>
-Memory is allocated, a pointer is returned.<p>
+
+Memory is allocated using the system "<tt>malloc</tt>" function, and a pointer
+is returned.<p>
<h5>Example:</h5>
<pre>
Memory is allocated, a pointer is returned. '<tt>alloca</tt>'d 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, as well as spilled variables.<p>
+address available. When the function returns (either with the <tt><a
+href="#i_ret">ret</a></tt> or <tt><a href="#i_invoke">invoke</a></tt>
+instructions), the memory is reclaimed.<p>
<h5>Example:</h5>
<pre>
<h5>Syntax:</h5>
<pre>
<result> = load <ty>* <pointer>
+ <result> = volatile load <ty>* <pointer>
</pre>
<h5>Overview:</h5>
<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>
<h5>Syntax:</h5>
<pre>
store <ty> <value>, <ty>* <pointer> <i>; yields {void}</i>
+ volatile store <ty> <value>, <ty>* <pointer> <i>; yields {void}</i>
</pre>
<h5>Overview:</h5>
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><pointer></tt>'
-operand must be a pointer to the type of the '<tt><value></tt>'
-operand.<p>
+operand must be a pointer to the type of the '<tt><value></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><value></tt>' at the location specified by the
<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>
<!-- _______________________________________________________________________ -->
</pre>
<!-- _______________________________________________________________________ -->
-</ul><a name="i_va
_arg"><h4><hr size=0>'<tt>va_arg</tt>' Instruction</h4><ul>
+</ul><a name="i_va
next"><h4><hr size=0>'<tt>vanext</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
- <result> = va_arg <va_list>* <arglist>, <retty>
+ <resultarglist> = vanext <va_list> <arglist>, <argty>
</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>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 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 another <tt>valist</tt>.
<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>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>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>va
next</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>
+ <resultval> = vaarg <va_list> <arglist>, <argty>
+</pre>
+
+<h5>Overview:</h5>
+
+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 <tt>valist</tt> value and the type of the argument. It
+returns a value of the specified argument type.
+
+<h5>Semantics:</h5>
+
+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>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>
</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><stdarg.h></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><stdarg.h></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>
<h5>Syntax:</h5>
<pre>
- call void (va_list*)* %llvm.va_start(<va_list>* <arglist>)
+ call va_list ()* %llvm.va_start()
</pre>
<h5>Overview:</h5>
-The '<tt>llvm.va_start</tt>' intrinsic initializes <tt>*<arglist></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><arglist></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>
<!-- _______________________________________________________________________ -->
<h5>Syntax:</h5>
<pre>
- call void (va_list*)* %llvm.va_end(<va_list>* <arglist>)
+ call void (va_list)* %llvm.va_end(va_list <arglist>)
</pre>
<h5>Overview:</h5>
-The '<tt>llvm.va_end</tt>' intrinsic destroys <tt>*<arglist></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><arglist></tt> which has
+been initialized previously with <tt><a
+href="#i_va_begin">llvm.va_begin</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>
<h5>Syntax:</h5>
<pre>
- call void (va_list*, va_list)* %va_copy(<va_list>* <destarglist>,
- <va_list> <srcarglist>)
+ call va_list (va_list)* %llvm.va_copy(va_list <destarglist>)
</pre>
<h5>Overview:</h5>
<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
+<tt>va_list</tt> element into the returned list. This intrinsic is necessary
because the <tt><a href="i_va_begin">llvm.va_begin</a></tt> intrinsic may be
arbitrarily complex and require memory allocation, for example.<p>
-<!-- _______________________________________________________________________ -->
-</ul><a name="i_unwind"><h4><hr size=0>'<tt>llvm.unwind</tt>' Intrinsic</h4><ul>
-
-<h5>Syntax:</h5>
-<pre>
- call void (void)* %llvm.unwind()
-</pre>
-
-<h5>Overview:</h5>
-
-The '<tt>llvm.unwind</tt>' intrinsic unwinds the stack, continuing control flow
-at the first callee in the dynamic call stack which used an <a
-href="#i_invoke"><tt>invoke</tt></a> instruction to perform the call. This is
-primarily used to implement exception handling.
-
-<h5>Semantics:</h5>
-
-The '<tt>llvm.unwind</tt>' intrinsic causes execution of the current function to
-immediately halt. The dynamic call stack is then searched for the first <a
-href="#i_invoke"><tt>invoke</tt></a> instruction on the call stack. Once found,
-execution continues at the "exceptional" destination block specified by the
-invoke instruction. If there is no <tt>invoke</tt> instruction in the dynamic
-call chain, undefined behavior results.
-
-
-
<!-- *********************************************************************** -->
</ul>
<!-- *********************************************************************** -->
<address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
<!-- Created: Tue Jan 23 15:19:28 CST 2001 -->
<!-- hhmts start -->
-Last modified: Tue Sep 2 18:38:09 CDT 2003
+Last modified: Fri Oct 17 18:28:10 CDT 2003
<!-- hhmts end -->
</font>
</body></html>
projects / oota-llvm.git / blobdiff