Newer
Older
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>
The '<tt>seteq</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
both operands are equal.<br>
The '<tt>setne</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
both operands are unequal.<br>
The '<tt>setlt</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
the first operand is less than the second operand.<br>
The '<tt>setgt</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
the first operand is greater than the second operand.<br>
The '<tt>setle</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
the first operand is less than or equal to the second operand.<br>
The '<tt>setge</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
the first operand is greater than or equal to the second operand.<p>
<h5>Example:</h5>
<pre>
<result> = seteq int 4, 5 <i>; yields {bool}:result = false</i>
<result> = setne float 4, 5 <i>; yields {bool}:result = true</i>
<result> = setlt uint 4, 5 <i>; yields {bool}:result = true</i>
<result> = setgt sbyte 4, 5 <i>; yields {bool}:result = false</i>
<result> = setle sbyte 4, 5 <i>; yields {bool}:result = true</i>
<result> = setge sbyte 4, 5 <i>; yields {bool}:result = false</i>
</pre>
<!-- ======================================================================= -->
</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="bitwiseops">Bitwise Binary Operations
</b></font></td></tr></table><ul>
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>
<!-- _______________________________________________________________________ -->
</ul><a name="i_and"><h4><hr size=0>'<tt>and</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
<result> = and <ty> <var1>, <var2> <i>; yields {ty}:result</i>
</pre>
<h5>Overview:</h5>
The '<tt>and</tt>' instruction returns the bitwise logical and of its two operands.<p>
<h5>Arguments:</h5>
The two arguments to the '<tt>and</tt>' instruction must be <a
href="#t_integral">integral</a> values. Both arguments must have identical
types.<p>
The truth table used for the '<tt>and</tt>' instruction is:<p>
<center><table border=1 cellspacing=0 cellpadding=4>
<tr><td>In0</td> <td>In1</td> <td>Out</td></tr>
<tr><td>0</td> <td>0</td> <td>0</td></tr>
<tr><td>0</td> <td>1</td> <td>0</td></tr>
<tr><td>1</td> <td>0</td> <td>0</td></tr>
<tr><td>1</td> <td>1</td> <td>1</td></tr>
</table></center><p>
<h5>Example:</h5>
<pre>
<result> = and int 4, %var <i>; yields {int}:result = 4 & %var</i>
<result> = and int 15, 40 <i>; yields {int}:result = 8</i>
<result> = and int 4, 8 <i>; yields {int}:result = 0</i>
</pre>
<!-- _______________________________________________________________________ -->
</ul><a name="i_or"><h4><hr size=0>'<tt>or</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
<result> = or <ty> <var1>, <var2> <i>; yields {ty}:result</i>
</pre>
<h5>Overview:</h5> The '<tt>or</tt>' instruction returns the bitwise logical
inclusive or of its two operands.<p>
The two arguments to the '<tt>or</tt>' instruction must be <a
href="#t_integral">integral</a> values. Both arguments must have identical
types.<p>
The truth table used for the '<tt>or</tt>' instruction is:<p>
<center><table border=1 cellspacing=0 cellpadding=4>
<tr><td>In0</td> <td>In1</td> <td>Out</td></tr>
<tr><td>0</td> <td>0</td> <td>0</td></tr>
<tr><td>0</td> <td>1</td> <td>1</td></tr>
<tr><td>1</td> <td>0</td> <td>1</td></tr>
<tr><td>1</td> <td>1</td> <td>1</td></tr>
</table></center><p>
<h5>Example:</h5>
<pre>
<result> = or int 4, %var <i>; yields {int}:result = 4 | %var</i>
<result> = or int 15, 40 <i>; yields {int}:result = 47</i>
<result> = or int 4, 8 <i>; yields {int}:result = 12</i>
</pre>
<!-- _______________________________________________________________________ -->
</ul><a name="i_xor"><h4><hr size=0>'<tt>xor</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
<result> = xor <ty> <var1>, <var2> <i>; yields {ty}:result</i>
</pre>
<h5>Overview:</h5>
The '<tt>xor</tt>' instruction returns the bitwise logical exclusive or of its
two operands.<p>
The two arguments to the '<tt>xor</tt>' instruction must be <a
href="#t_integral">integral</a> values. Both arguments must have identical
types.<p>
The truth table used for the '<tt>xor</tt>' instruction is:<p>
<center><table border=1 cellspacing=0 cellpadding=4>
<tr><td>In0</td> <td>In1</td> <td>Out</td></tr>
<tr><td>0</td> <td>0</td> <td>0</td></tr>
<tr><td>0</td> <td>1</td> <td>1</td></tr>
<tr><td>1</td> <td>0</td> <td>1</td></tr>
<tr><td>1</td> <td>1</td> <td>0</td></tr>
</table></center><p>
<h5>Example:</h5>
<pre>
<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>
</pre>
<!-- _______________________________________________________________________ -->
</ul><a name="i_shl"><h4><hr size=0>'<tt>shl</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
<result> = shl <ty> <var1>, ubyte <var2> <i>; yields {ty}:result</i>
</pre>
<h5>Overview:</h5>
The '<tt>shl</tt>' instruction returns the first operand shifted to the left a
specified number of bits.
The first argument to the '<tt>shl</tt>' instruction must be an <a
href="#t_integer">integer</a> type. The second argument must be an
'<tt>ubyte</tt>' type.<p>
The value produced is <tt>var1</tt> * 2<sup><tt>var2</tt></sup>.<p>
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
<h5>Example:</h5>
<pre>
<result> = shl int 4, ubyte %var <i>; yields {int}:result = 4 << %var</i>
<result> = shl int 4, ubyte 2 <i>; yields {int}:result = 16</i>
<result> = shl int 1, ubyte 10 <i>; yields {int}:result = 1024</i>
</pre>
<!-- _______________________________________________________________________ -->
</ul><a name="i_shr"><h4><hr size=0>'<tt>shr</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
<result> = shr <ty> <var1>, ubyte <var2> <i>; yields {ty}:result</i>
</pre>
<h5>Overview:</h5>
The '<tt>shr</tt>' instruction returns the first operand shifted to the right a specified number of bits.
<h5>Arguments:</h5>
The first argument to the '<tt>shr</tt>' instruction must be an <a href="#t_integer">integer</a> type. The second argument must be an '<tt>ubyte</tt>' type.<p>
If the first argument is a <a href="#t_signed">signed</a> type, the most
significant bit is duplicated in the newly free'd bit positions. If the first
argument is unsigned, zero bits shall fill the empty positions.<p>
<h5>Example:</h5>
<pre>
<result> = shr int 4, ubyte %var <i>; yields {int}:result = 4 >> %var</i>
<result> = shr int 4, ubyte 1 <i>; yields {int}:result = 2</i>
<result> = shr int 4, ubyte 2 <i>; yields {int}:result = 1</i>
<result> = shr int 4, ubyte 3 <i>; yields {int}:result = 0</i>
</pre>
<!-- ======================================================================= -->
</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="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>
<!-- _______________________________________________________________________ -->
</ul><a name="i_malloc"><h4><hr size=0>'<tt>malloc</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
<result> = malloc <type>, uint <NumElements> <i>; yields {type*}:result</i>
<result> = malloc <type> <i>; yields {type*}:result</i>
</pre>
<h5>Overview:</h5>
The '<tt>malloc</tt>' instruction allocates memory from the system heap and returns a pointer to it.<p>
<h5>Arguments:</h5>
The the '<tt>malloc</tt>' instruction allocates
<tt>sizeof(<type>)*NumElements</tt> bytes of memory from the operating
system, and returns a pointer of the appropriate type to the program. The
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>
<h5>Semantics:</h5>
Memory is allocated, a pointer is returned.<p>
<h5>Example:</h5>
<pre>
%array = malloc [4 x ubyte ] <i>; yields {[%4 x ubyte]*}:array</i>
%size = <a href="#i_add">add</a> uint 2, 2 <i>; yields {uint}:size = uint 4</i>
%array1 = malloc ubyte, uint 4 <i>; yields {ubyte*}:array1</i>
%array2 = malloc [12 x ubyte], uint %size <i>; yields {[12 x ubyte]*}:array2</i>
</pre>
<!-- _______________________________________________________________________ -->
</ul><a name="i_free"><h4><hr size=0>'<tt>free</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
free <type> <value> <i>; yields {void}</i>
</pre>
<h5>Overview:</h5>
The '<tt>free</tt>' instruction returns memory back to the unused memory heap, to be reallocated in the future.<p>
<h5>Arguments:</h5>
'<tt>value</tt>' shall be a pointer value that points to a value that was
allocated with the '<tt><a href="#i_malloc">malloc</a></tt>' instruction.<p>
Access to the memory pointed to by the pointer is not longer defined after this instruction executes.<p>
<h5>Example:</h5>
<pre>
%array = <a href="#i_malloc">malloc</a> [4 x ubyte] <i>; yields {[4 x ubyte]*}:array</i>
free [4 x ubyte]* %array
</pre>
<!-- _______________________________________________________________________ -->
</ul><a name="i_alloca"><h4><hr size=0>'<tt>alloca</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
<result> = alloca <type>, uint <NumElements> <i>; yields {type*}:result</i>
<result> = alloca <type> <i>; yields {type*}:result</i>
The '<tt>alloca</tt>' instruction allocates memory on the current stack frame of
the procedure that is live until the current function returns to its caller.<p>
The the '<tt>alloca</tt>' instruction allocates
<tt>sizeof(<type>)*NumElements</tt> bytes of memory on the runtime stack,
returning a pointer of the appropriate type to the program. The second form of
the instruction is a shorter version of the first that defaults to allocating
one element.<p>
'<tt>type</tt>' may be any sized type.<p>
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>
<h5>Example:</h5>
<pre>
%ptr = alloca int <i>; yields {int*}:ptr</i>
%ptr = alloca int, uint 4 <i>; yields {int*}:ptr</i>
</pre>
<!-- _______________________________________________________________________ -->
</ul><a name="i_load"><h4><hr size=0>'<tt>load</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
<result> = load <ty>* <pointer>
</pre>
<h5>Overview:</h5>
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>
<h5>Semantics:</h5>
The location of memory pointed to is loaded.
<pre>
%ptr = <a href="#i_alloca">alloca</a> int <i>; yields {int*}:ptr</i>
<a href="#i_store">store</a> int 3, int* %ptr <i>; yields {void}</i>
%val = load int* %ptr <i>; yields {int}:val = int 3</i>
<!-- _______________________________________________________________________ -->
</ul><a name="i_store"><h4><hr size=0>'<tt>store</tt>' Instruction</h4><ul>
store <ty> <value>, <ty>* <pointer> <i>; yields {void}</i>
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><pointer></tt>'
operand must be a pointer to the type of the '<tt><value></tt>'
operand.<p>
<h5>Semantics:</h5> The contents of memory are updated to contain
'<tt><value></tt>' at the location specified by the
'<tt><pointer></tt>' operand.<p>
<pre>
%ptr = <a href="#i_alloca">alloca</a> int <i>; yields {int*}:ptr</i>
<a href="#i_store">store</a> int 3, int* %ptr <i>; yields {void}</i>
%val = load int* %ptr <i>; yields {int}:val = int 3</i>
</pre>
<!-- _______________________________________________________________________ -->
</ul><a name="i_getelementptr"><h4><hr size=0>'<tt>getelementptr</tt>' Instruction</h4><ul>
<result> = getelementptr <ty>* <ptrval>{, long <aidx>|, ubyte <sidx>}*
The '<tt>getelementptr</tt>' instruction is used to get the address of a
subelement of an aggregate data structure.<p>
This instruction takes a list of <tt>long</tt> values and <tt>ubyte</tt>
constants that indicate what form of addressing to perform. The actual types of
the arguments provided depend on the type of the first pointer argument. The
'<tt>getelementptr</tt>' instruction is used to index down through the type
levels of a structure.<p>
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
For example, lets consider a C code fragment and how it gets compiled to
LLVM:<p>
<pre>
struct RT {
char A;
int B[10][20];
char C;
};
struct ST {
int X;
double Y;
struct RT Z;
};
int *foo(struct ST *s) {
return &s[1].Z.B[5][13];
}
</pre>
The LLVM code generated by the GCC frontend is:
<pre>
%RT = type { sbyte, [10 x [20 x int]], sbyte }
%ST = type { int, double, %RT }
int* "foo"(%ST* %s) {
%reg = getelementptr %ST* %s, long 1, ubyte 2, ubyte 1, long 5, long 13
ret int* %reg
}
</pre>
The index types specified for the '<tt>getelementptr</tt>' instruction depend on
the pointer type that is being index into. <a href="t_pointer">Pointer</a> and
<a href="t_array">array</a> types require '<tt>long</tt>' values, and <a
href="t_struct">structure</a> types require '<tt>ubyte</tt>'
<b>constants</b>.<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>{ int, double, %RT }</tt>'
type, a structure. The second index indexes into the third element of the
structure, yielding a '<tt>%RT</tt>' = '<tt>{ sbyte, [10 x [20 x int]], sbyte
}</tt>' type, another structure. The third index indexes into the second
element of the structure, yielding a '<tt>[10 x [20 x int]]</tt>' type, an
array. The two dimensions of the array are subscripted into, yielding an
'<tt>int</tt>' type. The '<tt>getelementptr</tt>' instruction return a pointer
to this element, thus yielding a '<tt>int*</tt>' type.<p>
Note that it is perfectly legal to index partially through a structure,
returning a pointer to an inner element. Because of this, the LLVM code for the
given testcase is equivalent to:<p>
<pre>
int* "foo"(%ST* %s) {
%t1 = getelementptr %ST* %s , long 1 <i>; yields %ST*:%t1</i>
%t2 = getelementptr %ST* %t1, long 0, ubyte 2 <i>; yields %RT*:%t2</i>
%t3 = getelementptr %RT* %t2, long 0, ubyte 1 <i>; yields [10 x [20 x int]]*:%t3</i>
%t4 = getelementptr [10 x [20 x int]]* %t3, long 0, long 5 <i>; yields [20 x int]*:%t4</i>
%t5 = getelementptr [20 x int]* %t4, long 0, long 13 <i>; yields int*:%t5</i>
ret int* %t5
}
</pre>
%aptr = getelementptr {int, [12 x ubyte]}* %sptr, long 0, ubyte 1
</pre>
<!-- ======================================================================= -->
</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="otherops">Other Operations
</b></font></td></tr></table><ul>
The instructions in this catagory are the "miscellaneous" functions, that defy better classification.<p>
<!-- _______________________________________________________________________ -->
</ul><a name="i_phi"><h4><hr size=0>'<tt>phi</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
<result> = phi <ty> [ <val0>, <label0>], ...
</pre>
<h5>Overview:</h5>
The '<tt>phi</tt>' instruction is used to implement the φ node in the SSA
graph representing the function.<p>
<h5>Arguments:</h5>
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>
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>
<h5>Semantics:</h5>
At runtime, the '<tt>phi</tt>' instruction logically takes on the value
specified by the parameter, depending on which basic block we came from in the
last <a href="#terminators">terminator</a> instruction.<p>
<h5>Example:</h5>
Loop: ; Infinite loop that counts from 0 on up...
%indvar = phi uint [ 0, %LoopHeader ], [ %nextindvar, %Loop ]
%nextindvar = add uint %indvar, 1
br label %Loop
<!-- _______________________________________________________________________ -->
</ul><a name="i_cast"><h4><hr size=0>'<tt>cast .. to</tt>' Instruction</h4><ul>
<result> = cast <ty> <value> to <ty2> <i>; yields ty2</i>
The '<tt>cast</tt>' instruction is used as the primitive means to convert
integers to floating point, change data type sizes, and break type safety (by
casting pointers).<p>
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>
This instruction follows the C rules for explicit casts when determining how the
data being cast must change to fit in its new container.<p>
When casting to bool, any value that would be considered true in the context of
a C '<tt>if</tt>' condition is converted to the boolean '<tt>true</tt>' values,
all else are '<tt>false</tt>'.<p>
When extending an integral value from a type of one signness to another (for
example '<tt>sbyte</tt>' to '<tt>ulong</tt>'), the value is sign-extended if the
<b>source</b> value is signed, and zero-extended if the source value is
unsigned. <tt>bool</tt> values are always zero extended into either zero or
one.<p>
%X = cast int 257 to ubyte <i>; yields ubyte:1</i>
%Y = cast int 123 to bool <i>; yields bool:true</i>
</pre>
<!-- _______________________________________________________________________ -->
</ul><a name="i_call"><h4><hr size=0>'<tt>call</tt>' Instruction</h4><ul>
<result> = call <ty>* <fnptrval>(<param list>)
The '<tt>call</tt>' instruction represents a simple function call.<p>
This instruction requires several arguments:<p>
<ol>
<li>'<tt>ty</tt>': shall be the signature of the pointer to function value being
invoked. The argument types must match the types implied by this signature.<p>
<li>'<tt>fnptrval</tt>': An LLVM value containing a pointer to a function to be
invoked. In most cases, this is a direct function invocation, but indirect
<tt>call</tt>s are just as possible, calling an arbitrary pointer to function
values.<p>
<li>'<tt>function args</tt>': argument list whose types match the function
signature argument types. If the function signature indicates the function
accepts a variable number of arguments, the extra arguments can be specified.
</ol>
The '<tt>call</tt>' instruction is used to cause control flow to 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>
%retval = call int %test(int %argc)
call int(sbyte*, ...) *%printf(sbyte* %msg, int 12, sbyte 42);
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
<!-- _______________________________________________________________________ -->
</ul><a name="i_va_arg"><h4><hr size=0>'<tt>va_arg</tt>' Instruction</h4><ul>
<h5>Syntax:</h5>
<pre>
<result> = va_arg <va_list>* <arglist>, <retty>
</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
<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>
<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>
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>
<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>
<a name="intrinsics">Intrinsic Functions
<!-- *********************************************************************** -->
LLVM supports the notion of an "intrinsic function". These functions have well
known names and semantics, and are required to follow certain restrictions.
Overall, these instructions represent an extension mechanism for the LLVM
language that does not require changing all of the transformations in LLVM to
add to the language (or the bytecode reader/writer, the parser, etc...).<p>
Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix, this
prefix is reserved in LLVM for intrinsic names, thus functions may not be named
this. Intrinsic functions must always be external functions: you cannot define
the body of intrinsic functions. Intrinsic functions may only be used in call
or invoke instructions: it is illegal to take the address of an intrinsic
function. Additionally, because intrinsic functions are part of the LLVM
language, it is required that they all be documented here if any are added.<p>
Unless an intrinsic function is target-specific, there must be a lowering pass
to eliminate the intrinsic or all backends must support the intrinsic
function.<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="int_varargs">Variable Argument Handling Intrinsics
</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>
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
intrinsics with any type used.<p>
This example shows how the <a href="#i_va_arg"><tt>va_arg</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, int %X)
; Read a single integer argument
%tmp = <a href="#i_va_arg">va_arg</a> 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)
; Stop processing of arguments.
call void %<a href="#i_va_end">llvm.va_end</a>(sbyte** %ap)
ret int %tmp
}
</pre>
<!-- _______________________________________________________________________ -->
</ul><a name="i_va_start"><h4><hr size=0>'<tt>llvm.va_start</tt>' Intrinsic</h4><ul>
<h5>Syntax:</h5>
<pre>
call void (va_list*, ...)* %llvm.va_start(<va_list>* <arglist>, <argument>)
</pre>
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>
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
<h5>Arguments:</h5>
The first argument is a pointer to a <tt>va_list</tt> element to initialize.
The second argument is required to be the last LLVM argument before the
ellipsis. In the future, this restriction may be relaxed (to allow it to be
other arguments).<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 first argument points to, so that the next call to
<tt>va_arg</tt> will produce the first variable argument passed to the
function.<p>
<!-- _______________________________________________________________________ -->
</ul><a name="i_va_end"><h4><hr size=0>'<tt>llvm.va_end</tt>' Intrinsic</h4><ul>
<h5>Syntax:</h5>
<pre>
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>
<h5>Arguments:</h5>
The argument is a pointer to a <tt>va_list</tt> element 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
href="#i_va_copy"><tt>llvm.va_copy</tt></a> must be matched exactly with calls
to <tt>llvm.va_end</tt>.<p>
<!-- _______________________________________________________________________ -->
</ul><a name="i_va_copy"><h4><hr size=0>'<tt>llvm.va_copy</tt>' Intrinsic</h4><ul>
<h5>Syntax:</h5>
<pre>
call void (va_list*, va_list)* %va_copy(<va_list>* <destarglist>,
<va_list> <srcarglist>)
</pre>
<h5>Overview:</h5>
The '<tt>llvm.va_copy</tt>' intrinsic copies the current argument position from
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>
<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
arbitrarily complex and require memory allocation, for example.<p>
<!-- *********************************************************************** -->
</ul>
<!-- *********************************************************************** -->
<hr>
<font size=-1>
<address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
<!-- Created: Tue Jan 23 15:19:28 CST 2001 -->
<!-- hhmts start -->
Last modified: Wed May 7 23:56:16 CDT 2003