<li><a href="#modulestructure">Module Structure</a></li>
<li><a href="#linkage">Linkage Types</a></li>
<li><a href="#callingconv">Calling Conventions</a></li>
+ <li><a href="#namedtypes">Named Types</a></li>
<li><a href="#globalvars">Global Variables</a></li>
<li><a href="#functionstructure">Functions</a></li>
<li><a href="#aliasstructure">Aliases</a></li>
<li><a href="#t_opaque">Opaque Type</a></li>
</ol>
</li>
+ <li><a href="#t_uprefs">Type Up-references</a></li>
</ol>
</li>
<li><a href="#constants">Constants</a>
<li><a href="#int_part_set">'<tt>llvm.part.set.*</tt>' Intrinsic </a></li>
</ol>
</li>
+ <li><a href="#int_overflow">Arithmetic with Overflow Intrinsics</a>
+ <ol>
+ <li><a href="#int_sadd_overflow">'<tt>llvm.sadd.with.overflow.*</tt> Intrinsics</a></li>
+ <li><a href="#int_uadd_overflow">'<tt>llvm.uadd.with.overflow.*</tt> Intrinsics</a></li>
+ <li><a href="#int_ssub_overflow">'<tt>llvm.ssub.with.overflow.*</tt> Intrinsics</a></li>
+ <li><a href="#int_usub_overflow">'<tt>llvm.usub.with.overflow.*</tt> Intrinsics</a></li>
+ <li><a href="#int_smul_overflow">'<tt>llvm.smul.with.overflow.*</tt> Intrinsics</a></li>
+ <li><a href="#int_umul_overflow">'<tt>llvm.umul.with.overflow.*</tt> Intrinsics</a></li>
+ </ol>
+ </li>
<li><a href="#int_debugger">Debugger intrinsics</a></li>
<li><a href="#int_eh">Exception Handling intrinsics</a></li>
<li><a href="#int_trampoline">Trampoline Intrinsic</a>
<i>; Definition of main function</i>
define i32 @main() { <i>; i32()* </i>
- <i>; Convert [13x i8 ]* to i8 *...</i>
+ <i>; Convert [13 x i8]* to i8 *...</i>
%cast210 = <a
- href="#i_getelementptr">getelementptr</a> [13 x i8 ]* @.LC0, i64 0, i64 0 <i>; i8 *</i>
+ href="#i_getelementptr">getelementptr</a> [13 x i8]* @.LC0, i64 0, i64 0 <i>; i8 *</i>
<i>; Call puts function to write out the string to stdout...</i>
<a
<dl>
- <dt><tt><b><a name="linkage_internal">internal</a></b></tt>: </dt>
+ <dt><tt><b><a name="linkage_private">private</a></b></tt>: </dt>
- <dd>Global values with internal linkage are only directly accessible by
+ <dd>Global values with private 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
+ an private global value may cause the private to be renamed as necessary to
+ avoid collisions. Because the symbol is private to the module, all
+ references can be updated. This doesn't show up in any symbol table in the
+ object file.
+ </dd>
+
+ <dt><tt><b><a name="linkage_internal">internal</a></b></tt>: </dt>
+
+ <dd> Similar to private, but the value shows as a local symbol (STB_LOCAL in
+ the case of ELF) in the object file. This corresponds to the notion of the
'<tt>static</tt>' keyword in C.
</dd>
<dd>"<tt>dllimport</tt>" linkage causes the compiler to reference a function
or variable via a global pointer to a pointer that is set up by the DLL
exporting the symbol. On Microsoft Windows targets, the pointer name is
- formed by combining <code>_imp__</code> and the function or variable name.
+ formed by combining <code>__imp_</code> and the function or variable name.
</dd>
<dt><tt><b><a name="linkage_dllexport">dllexport</a></b></tt>: </dt>
<dd>"<tt>dllexport</tt>" linkage causes the compiler to provide a global
pointer to a pointer in a DLL, so that it can be referenced with the
<tt>dllimport</tt> attribute. On Microsoft Windows targets, the pointer
- name is formed by combining <code>_imp__</code> and the function or variable
+ name is formed by combining <code>__imp_</code> and the function or variable
name.
</dd>
</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="namedtypes">Named Types</a>
+</div>
+
+<div class="doc_text">
+
+<p>LLVM IR allows you to specify name aliases for certain types. This can make
+it easier to read the IR and make the IR more condensed (particularly when
+recursive types are involved). An example of a name specification is:
+</p>
+
+<div class="doc_code">
+<pre>
+%mytype = type { %mytype*, i32 }
+</pre>
+</div>
+
+<p>You may give a name to any <a href="#typesystem">type</a> except "<a
+href="t_void">void</a>". Type name aliases may be used anywhere a type is
+expected with the syntax "%mytype".</p>
+
+<p>Note that type names are aliases for the structural type that they indicate,
+and that you can therefore specify multiple names for the same type. This often
+leads to confusing behavior when dumping out a .ll file. Since LLVM IR uses
+structural typing, the name is not part of the type. When printing out LLVM IR,
+the printer will pick <em>one name</em> to render all types of a particular
+shape. This means that if you have code where two different source types end up
+having the same LLVM type, that the dumper will sometimes print the "wrong" or
+unexpected type. This is an important design point and isn't going to
+change.</p>
+
+</div>
+
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="globalvars">Global Variables</a>
<div class="doc_code">
<pre>
-@G = constant float 1.0 addrspace(5), section "foo", align 4
+@G = addrspace(5) constant float 1.0, section "foo", align 4
</pre>
</div>
<div class="doc_code">
<pre>
-declare i32 @printf(i8* noalias , ...)
+declare i32 @printf(i8* noalias nocapture, ...)
declare i32 @atoi(i8 zeroext)
declare signext i8 @returns_signed_char()
</pre>
belong to the caller not the callee (for example,
<tt><a href="#readonly">readonly</a></tt> functions should not write to
<tt>byval</tt> parameters). This is not a valid attribute for return
- values. </dd>
+ values. The byval attribute also supports specifying an alignment with the
+ align attribute. This has a target-specific effect on the code generator
+ that usually indicates a desired alignment for the synthesized stack
+ slot.</dd>
<dt><tt>sret</tt></dt>
<dd>This indicates that the pointer parameter specifies the address of a
parameter. The caller is responsible for ensuring that this is the
case. On a function return value, <tt>noalias</tt> additionally indicates
that the pointer does not alias any other pointers visible to the
- caller. Note that this applies only to pointers that can be used to actually
- load/store a value: NULL, unique pointers from malloc(0), and freed pointers
- are considered to not alias anything.</dd>
+ caller. For further details, please see the discussion of the NoAlias
+ response in
+ <a href="http://llvm.org/docs/AliasAnalysis.html#MustMayNo">alias
+ analysis</a>.</dd>
+
+ <dt><tt>nocapture</tt></dt>
+ <dd>This indicates that the callee does not make any copies of the pointer
+ that outlive the callee itself. This is not a valid attribute for return
+ values.</dd>
<dt><tt>nest</tt></dt>
<dd>This indicates that the pointer parameter can be excised using the
</tr>
</tbody>
</table>
+
+<p>Note that the code generator does not yet support large integer types
+to be used as function return types. The specific limit on how large a
+return type the code generator can currently handle is target-dependent;
+currently it's often 64 bits for 32-bit targets and 128 bits for 64-bit
+targets.</p>
+
</div>
<!-- _______________________________________________________________________ -->
length. This allows implementation of 'pascal style arrays' with the LLVM
type "{ i32, [0 x float]}", for example.</p>
+<p>Note that the code generator does not yet support large aggregate types
+to be used as function return types. The specific limit on how large an
+aggregate return type the code generator can currently handle is
+target-dependent, and also dependent on the aggregate element types.</p>
+
</div>
<!-- _______________________________________________________________________ -->
an <tt>i32</tt>.</td>
</tr>
</table>
+
+<p>Note that the code generator does not yet support large aggregate types
+to be used as function return types. The specific limit on how large an
+aggregate return type the code generator can currently handle is
+target-dependent, and also dependent on the aggregate element types.</p>
+
</div>
<!-- _______________________________________________________________________ -->
an optional address space attribute defining the target-specific numbered
address space where the pointed-to object resides. The default address space is
zero.</p>
+
+<p>Note that LLVM does not permit pointers to void (<tt>void*</tt>) nor does
+it permit pointers to labels (<tt>label*</tt>). Use <tt>i8*</tt> instead.</p>
+
<h5>Syntax:</h5>
<pre> <type> *<br></pre>
<h5>Examples:</h5>
<table class="layout">
<tr class="layout">
- <td class="left"><tt>[4x i32]*</tt></td>
+ <td class="left"><tt>[4 x i32]*</tt></td>
<td class="left">A <a href="#t_pointer">pointer</a> to <a
href="#t_array">array</a> of four <tt>i32</tt> values.</td>
</tr>
<td class="left">Vector of 2 64-bit integer values.</td>
</tr>
</table>
+
+<p>Note that the code generator does not yet support large vector types
+to be used as function return types. The specific limit on how large a
+vector return type codegen can currently handle is target-dependent;
+currently it's often a few times longer than a hardware vector register.</p>
+
</div>
<!-- _______________________________________________________________________ -->
</table>
</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="t_uprefs">Type Up-references</a>
+</div>
+
+<div class="doc_text">
+<h5>Overview:</h5>
+<p>
+An "up reference" allows you to refer to a lexically enclosing type without
+requiring it to have a name. For instance, a structure declaration may contain a
+pointer to any of the types it is lexically a member of. Example of up
+references (with their equivalent as named type declarations) include:</p>
+
+<pre>
+ { \2 * } %x = type { %x* }
+ { \2 }* %y = type { %y }*
+ \1* %z = type %z*
+</pre>
+
+<p>
+An up reference is needed by the asmprinter for printing out cyclic types when
+there is no declared name for a type in the cycle. Because the asmprinter does
+not want to print out an infinite type string, it needs a syntax to handle
+recursive types that have no names (all names are optional in llvm IR).
+</p>
+
+<h5>Syntax:</h5>
+<pre>
+ \<level>
+</pre>
+
+<p>
+The level is the count of the lexical type that is being referred to.
+</p>
+
+<h5>Examples:</h5>
+
+<table class="layout">
+ <tr class="layout">
+ <td class="left"><tt>\1*</tt></td>
+ <td class="left">Self-referential pointer.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>{ { \3*, i8 }, i32 }</tt></td>
+ <td class="left">Recursive structure where the upref refers to the out-most
+ structure.</td>
+ </tr>
+</table>
+</div>
+
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="constants">Constants</a> </div>
</dl>
-<p>The one non-intuitive notation for constants is the optional hexadecimal form
+<p>The one non-intuitive notation for constants is the hexadecimal form
of floating point constants. For example, the form '<tt>double
0x432ff973cafa8000</tt>' is equivalent to (but harder to read than) '<tt>double
4.5e+15</tt>'. The only time hexadecimal floating point constants are required
(and the only time that they are generated by the disassembler) is when a
floating point constant must be emitted but it cannot be represented as a
-decimal floating point number. For example, NaN's, infinities, and other
+decimal floating point number in a reasonable number of digits. For example,
+NaN's, infinities, and other
special values are represented in their IEEE hexadecimal format so that
assembly and disassembly do not cause any bits to change in the constants.</p>
-
+<p>When using the hexadecimal form, constants of types float and double are
+represented using the 16-digit form shown above (which matches the IEEE754
+representation for double); float values must, however, be exactly representable
+as IEE754 single precision.
+Hexadecimal format is always used for long
+double, and there are three forms of long double. The 80-bit
+format used by x86 is represented as <tt>0xK</tt>
+followed by 20 hexadecimal digits.
+The 128-bit format used by PowerPC (two adjacent doubles) is represented
+by <tt>0xM</tt> followed by 32 hexadecimal digits. The IEEE 128-bit
+format is represented
+by <tt>0xL</tt> followed by 32 hexadecimal digits; no currently supported
+target uses this format. Long doubles will only work if they match
+the long double format on your target. All hexadecimal formats are big-endian
+(sign bit at the left).</p>
</div>
<!-- ======================================================================= -->
ret void <i>; Return from a void function</i>
ret { i32, i8 } { i32 4, i8 2 } <i>; Return an aggregate of values 4 and 2</i>
</pre>
+
+<p>Note that the code generator does not yet fully support large
+ return values. The specific sizes that are currently supported are
+ dependent on the target. For integers, on 32-bit targets the limit
+ is often 64 bits, and on 64-bit targets the limit is often 128 bits.
+ For aggregate types, the current limits are dependent on the element
+ types; for example targets are often limited to 2 total integer
+ elements and 2 total floating-point elements.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="i_br">'<tt>br</tt>' Instruction</a> </div>
<pre>
<i>; Emulate a conditional br instruction</i>
%Val = <a href="#i_zext">zext</a> i1 %value to i32
- switch i32 %Val, label %truedest [i32 0, label %falsedest ]
+ switch i32 %Val, label %truedest [ i32 0, label %falsedest ]
<i>; Emulate an unconditional br instruction</i>
switch i32 0, label %dest [ ]
<i>; Implement a jump table:</i>
- switch i32 %val, label %otherwise [ i32 0, label %onzero
- i32 1, label %onone
- i32 2, label %ontwo ]
+ switch i32 %val, label %otherwise [ i32 0, label %onzero
+ i32 1, label %onone
+ i32 2, label %ontwo ]
</pre>
</div>
<p>The value produced is <tt>op1</tt> * 2<sup><tt>op2</tt></sup> mod 2<sup>n</sup>,
where n is the width of the result. If <tt>op2</tt> is (statically or dynamically) negative or
-equal to or larger than the number of bits in <tt>op1</tt>, the result is undefined.</p>
+equal to or larger than the number of bits in <tt>op1</tt>, the result is undefined.
+If the arguments are vectors, each vector element of <tt>op1</tt> is shifted by the
+corresponding shift amount in <tt>op2</tt>.</p>
<h5>Example:</h5><pre>
<result> = shl i32 4, %var <i>; yields {i32}: 4 << %var</i>
<result> = shl i32 4, 2 <i>; yields {i32}: 16</i>
<result> = shl i32 1, 10 <i>; yields {i32}: 1024</i>
<result> = shl i32 1, 32 <i>; undefined</i>
+ <result> = shl <2 x i32> < i32 1, i32 1>, < i32 1, i32 2> <i>; yields: result=<2 x i32> < i32 2, i32 4></i>
</pre>
</div>
<!-- _______________________________________________________________________ -->
<p>This instruction always performs a logical shift right operation. The most
significant bits of the result will be filled with zero bits after the
shift. If <tt>op2</tt> is (statically or dynamically) equal to or larger than
-the number of bits in <tt>op1</tt>, the result is undefined.</p>
+the number of bits in <tt>op1</tt>, the result is undefined. If the arguments are
+vectors, each vector element of <tt>op1</tt> is shifted by the corresponding shift
+amount in <tt>op2</tt>.</p>
<h5>Example:</h5>
<pre>
<result> = lshr i8 4, 3 <i>; yields {i8}:result = 0</i>
<result> = lshr i8 -2, 1 <i>; yields {i8}:result = 0x7FFFFFFF </i>
<result> = lshr i32 1, 32 <i>; undefined</i>
+ <result> = lshr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 2> <i>; yields: result=<2 x i32> < i32 0x7FFFFFFF, i32 1></i>
</pre>
</div>
<p>This instruction always performs an arithmetic shift right operation,
The most significant bits of the result will be filled with the sign bit
of <tt>op1</tt>. If <tt>op2</tt> is (statically or dynamically) equal to or
-larger than the number of bits in <tt>op1</tt>, the result is undefined.
-</p>
+larger than the number of bits in <tt>op1</tt>, the result is undefined. If the
+arguments are vectors, each vector element of <tt>op1</tt> is shifted by the
+corresponding shift amount in <tt>op2</tt>.</p>
<h5>Example:</h5>
<pre>
<result> = ashr i8 4, 3 <i>; yields {i8}:result = 0</i>
<result> = ashr i8 -2, 1 <i>; yields {i8}:result = -1</i>
<result> = ashr i32 1, 32 <i>; undefined</i>
+ <result> = ashr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 3> <i>; yields: result=<2 x i32> < i32 -1, i32 0></i>
</pre>
</div>
<h5>Example:</h5>
<pre>
- %array = malloc [4 x i8 ] <i>; yields {[%4 x i8]*}:array</i>
+ %array = malloc [4 x i8] <i>; yields {[%4 x i8]*}:array</i>
%size = <a href="#i_add">add</a> i32 2, 2 <i>; yields {i32}:size = i32 4</i>
%array1 = malloc i8, i32 4 <i>; yields {i8*}:array1</i>
%array3 = malloc i32, i32 4, align 1024 <i>; yields {i32*}:array3</i>
%array4 = malloc i32, align 1024 <i>; yields {i32*}:array4</i>
</pre>
+
+<p>Note that the code generator does not yet respect the
+ alignment value.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<h5>Syntax:</h5>
<pre>
- free <type> <value> <i>; yields {void}</i>
+ free <type> <value> <i>; yields {void}</i>
</pre>
<h5>Overview:</h5>
<h5>Example:</h5>
<pre>
- %array = <a href="#i_malloc">malloc</a> [4 x i8] <i>; yields {[4 x i8]*}:array</i>
+ %array = <a href="#i_malloc">malloc</a> [4 x i8] <i>; yields {[4 x i8]*}:array</i>
free [4 x i8]* %array
</pre>
</div>
<h5>Example:</h5>
<pre>
- %ptr = alloca i32 <i>; yields {i32*}:ptr</i>
- %ptr = alloca i32, i32 4 <i>; yields {i32*}:ptr</i>
- %ptr = alloca i32, i32 4, align 1024 <i>; yields {i32*}:ptr</i>
- %ptr = alloca i32, align 1024 <i>; yields {i32*}:ptr</i>
+ %ptr = alloca i32 <i>; yields {i32*}:ptr</i>
+ %ptr = alloca i32, i32 4 <i>; yields {i32*}:ptr</i>
+ %ptr = alloca i32, i32 4, align 1024 <i>; yields {i32*}:ptr</i>
+ %ptr = alloca i32, align 1024 <i>; yields {i32*}:ptr</i>
</pre>
</div>
<div class="doc_code">
<pre>
-%RT = type { i8 , [10 x [20 x i32]], i8 }
-%ST = type { i32, double, %RT }
+%RT = <a href="#namedtypes">type</a> { i8 , [10 x [20 x i32]], i8 }
+%ST = <a href="#namedtypes">type</a> { i32, double, %RT }
define i32* %foo(%ST* %s) {
entry:
<result> = icmp ule i16 -4, 5 <i>; yields: result=false</i>
<result> = icmp sge i16 4, 5 <i>; yields: result=false</i>
</pre>
+
+<p>Note that the code generator does not yet support vector types with
+ the <tt>icmp</tt> instruction.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<result> = fcmp olt float 4.0, 5.0 <i>; yields: result=true</i>
<result> = fcmp ueq double 1.0, 2.0 <i>; yields: result=false</i>
</pre>
+
+<p>Note that the code generator does not yet support vector types with
+ the <tt>fcmp</tt> instruction.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<pre>
%X = select i1 true, i8 17, i8 42 <i>; yields i8:17</i>
</pre>
+
+<p>Note that the code generator does not yet support conditions
+ with vector type.</p>
+
</div>
<p>See the <a href="#int_varargs">variable argument processing</a> section.</p>
+<p>Note that the code generator does not yet fully support va_arg
+ on many targets. Also, it does not currently support va_arg with
+ aggregate types on any target.</p>
+
</div>
<!-- *********************************************************************** -->
<p>This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit
width. Not all targets support all bit widths however.</p>
<pre>
- declare i8 @llvm.ctpop.i8 (i8 <src>)
+ declare i8 @llvm.ctpop.i8(i8 <src>)
declare i16 @llvm.ctpop.i16(i16 <src>)
declare i32 @llvm.ctpop.i32(i32 <src>)
declare i64 @llvm.ctpop.i64(i64 <src>)
with the replaced bits.</p>
<h5>Arguments:</h5>
-<p>The first argument, <tt>%val</tt> and the result may be integer types of
-any bit width but they must have the same bit width. <tt>%val</tt> is the value
+<p>The first argument, <tt>%val</tt>, and the result may be integer types of
+any bit width, but they must have the same bit width. <tt>%val</tt> is the value
whose bits will be replaced. The second argument, <tt>%repl</tt> may be an
integer of any bit width. The third and fourth arguments must be <tt>i32</tt>
type since they specify only a bit index.</p>
of operation: forwards and reverse. If <tt>%lo</tt> is greater than
<tt>%hi</tt> then the intrinsic operates in reverse mode. Otherwise it
operates in forward mode.</p>
+
<p>For both modes, the <tt>%repl</tt> value is prepared for use by either
truncating it down to the size of the replacement area or zero extending it
up to that size.</p>
+
<p>In forward mode, the bits between <tt>%lo</tt> and <tt>%hi</tt> (inclusive)
are replaced with corresponding bits from <tt>%repl</tt>. That is the 0th bit
in <tt>%repl</tt> replaces the <tt>%lo</tt>th bit in <tt>%val</tt> and etc. up
to the <tt>%hi</tt>th bit.</p>
+
<p>In reverse mode, a similar computation is made except that the bits are
reversed. That is, the <tt>0</tt>th bit in <tt>%repl</tt> replaces the
<tt>%hi</tt> bit in <tt>%val</tt> and etc. down to the <tt>%lo</tt>th bit.</p>
+
<h5>Examples:</h5>
+
<pre>
llvm.part.set(0xFFFF, 0, 4, 7) -> 0xFF0F
llvm.part.set(0xFFFF, 0, 7, 4) -> 0xFF0F
llvm.part.set(0xFFFF, F, 8, 3) -> 0xFFE7
llvm.part.set(0xFFFF, 0, 3, 8) -> 0xFE07
</pre>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="int_overflow">Arithmetic with Overflow Intrinsics</a>
+</div>
+
+<div class="doc_text">
+<p>
+LLVM provides intrinsics for some arithmetic with overflow operations.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="int_sadd_overflow">'<tt>llvm.sadd.with.overflow.*</tt>' Intrinsics</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+
+<p>This is an overloaded intrinsic. You can use <tt>llvm.sadd.with.overflow</tt>
+on any integer bit width.</p>
+
+<pre>
+ declare {i16, i1} @llvm.sadd.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.sadd.with.overflow.i64(i64 %a, i64 %b)
+</pre>
+
+<h5>Overview:</h5>
+
+<p>The '<tt>llvm.sadd.with.overflow</tt>' family of intrinsic functions perform
+a signed addition of the two arguments, and indicate whether an overflow
+occurred during the signed summation.</p>
+
+<h5>Arguments:</h5>
+
+<p>The arguments (%a and %b) and the first element of the result structure may
+be of integer types of any bit width, but they must have the same bit width. The
+second element of the result structure must be of type <tt>i1</tt>. <tt>%a</tt>
+and <tt>%b</tt> are the two values that will undergo signed addition.</p>
+
+<h5>Semantics:</h5>
+
+<p>The '<tt>llvm.sadd.with.overflow</tt>' family of intrinsic functions perform
+a signed addition of the two variables. They return a structure — the
+first element of which is the signed summation, and the second element of which
+is a bit specifying if the signed summation resulted in an overflow.</p>
+
+<h5>Examples:</h5>
+<pre>
+ %res = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %overflow, label %normal
+</pre>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="int_uadd_overflow">'<tt>llvm.uadd.with.overflow.*</tt>' Intrinsics</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+
+<p>This is an overloaded intrinsic. You can use <tt>llvm.uadd.with.overflow</tt>
+on any integer bit width.</p>
+
+<pre>
+ declare {i16, i1} @llvm.uadd.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.uadd.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.uadd.with.overflow.i64(i64 %a, i64 %b)
+</pre>
+
+<h5>Overview:</h5>
+
+<p>The '<tt>llvm.uadd.with.overflow</tt>' family of intrinsic functions perform
+an unsigned addition of the two arguments, and indicate whether a carry occurred
+during the unsigned summation.</p>
+
+<h5>Arguments:</h5>
+
+<p>The arguments (%a and %b) and the first element of the result structure may
+be of integer types of any bit width, but they must have the same bit width. The
+second element of the result structure must be of type <tt>i1</tt>. <tt>%a</tt>
+and <tt>%b</tt> are the two values that will undergo unsigned addition.</p>
+
+<h5>Semantics:</h5>
+
+<p>The '<tt>llvm.uadd.with.overflow</tt>' family of intrinsic functions perform
+an unsigned addition of the two arguments. They return a structure — the
+first element of which is the sum, and the second element of which is a bit
+specifying if the unsigned summation resulted in a carry.</p>
+
+<h5>Examples:</h5>
+<pre>
+ %res = call {i32, i1} @llvm.uadd.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %carry, label %normal
+</pre>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="int_ssub_overflow">'<tt>llvm.ssub.with.overflow.*</tt>' Intrinsics</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+
+<p>This is an overloaded intrinsic. You can use <tt>llvm.ssub.with.overflow</tt>
+on any integer bit width.</p>
+
+<pre>
+ declare {i16, i1} @llvm.ssub.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.ssub.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.ssub.with.overflow.i64(i64 %a, i64 %b)
+</pre>
+
+<h5>Overview:</h5>
+
+<p>The '<tt>llvm.ssub.with.overflow</tt>' family of intrinsic functions perform
+a signed subtraction of the two arguments, and indicate whether an overflow
+occurred during the signed subtraction.</p>
+
+<h5>Arguments:</h5>
+
+<p>The arguments (%a and %b) and the first element of the result structure may
+be of integer types of any bit width, but they must have the same bit width. The
+second element of the result structure must be of type <tt>i1</tt>. <tt>%a</tt>
+and <tt>%b</tt> are the two values that will undergo signed subtraction.</p>
+
+<h5>Semantics:</h5>
+
+<p>The '<tt>llvm.ssub.with.overflow</tt>' family of intrinsic functions perform
+a signed subtraction of the two arguments. They return a structure — the
+first element of which is the subtraction, and the second element of which is a bit
+specifying if the signed subtraction resulted in an overflow.</p>
+
+<h5>Examples:</h5>
+<pre>
+ %res = call {i32, i1} @llvm.ssub.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %overflow, label %normal
+</pre>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="int_usub_overflow">'<tt>llvm.usub.with.overflow.*</tt>' Intrinsics</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+
+<p>This is an overloaded intrinsic. You can use <tt>llvm.usub.with.overflow</tt>
+on any integer bit width.</p>
+
+<pre>
+ declare {i16, i1} @llvm.usub.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.usub.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.usub.with.overflow.i64(i64 %a, i64 %b)
+</pre>
+
+<h5>Overview:</h5>
+
+<p>The '<tt>llvm.usub.with.overflow</tt>' family of intrinsic functions perform
+an unsigned subtraction of the two arguments, and indicate whether an overflow
+occurred during the unsigned subtraction.</p>
+
+<h5>Arguments:</h5>
+
+<p>The arguments (%a and %b) and the first element of the result structure may
+be of integer types of any bit width, but they must have the same bit width. The
+second element of the result structure must be of type <tt>i1</tt>. <tt>%a</tt>
+and <tt>%b</tt> are the two values that will undergo unsigned subtraction.</p>
+
+<h5>Semantics:</h5>
+
+<p>The '<tt>llvm.usub.with.overflow</tt>' family of intrinsic functions perform
+an unsigned subtraction of the two arguments. They return a structure — the
+first element of which is the subtraction, and the second element of which is a bit
+specifying if the unsigned subtraction resulted in an overflow.</p>
+
+<h5>Examples:</h5>
+<pre>
+ %res = call {i32, i1} @llvm.usub.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %overflow, label %normal
+</pre>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="int_smul_overflow">'<tt>llvm.smul.with.overflow.*</tt>' Intrinsics</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+
+<p>This is an overloaded intrinsic. You can use <tt>llvm.smul.with.overflow</tt>
+on any integer bit width.</p>
+
+<pre>
+ declare {i16, i1} @llvm.smul.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.smul.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.smul.with.overflow.i64(i64 %a, i64 %b)
+</pre>
+
+<h5>Overview:</h5>
+
+<p>The '<tt>llvm.smul.with.overflow</tt>' family of intrinsic functions perform
+a signed multiplication of the two arguments, and indicate whether an overflow
+occurred during the signed multiplication.</p>
+
+<h5>Arguments:</h5>
+
+<p>The arguments (%a and %b) and the first element of the result structure may
+be of integer types of any bit width, but they must have the same bit width. The
+second element of the result structure must be of type <tt>i1</tt>. <tt>%a</tt>
+and <tt>%b</tt> are the two values that will undergo signed multiplication.</p>
+
+<h5>Semantics:</h5>
+
+<p>The '<tt>llvm.smul.with.overflow</tt>' family of intrinsic functions perform
+a signed multiplication of the two arguments. They return a structure —
+the first element of which is the multiplication, and the second element of
+which is a bit specifying if the signed multiplication resulted in an
+overflow.</p>
+
+<h5>Examples:</h5>
+<pre>
+ %res = call {i32, i1} @llvm.smul.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %overflow, label %normal
+</pre>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="int_umul_overflow">'<tt>llvm.umul.with.overflow.*</tt>' Intrinsics</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+
+<p>This is an overloaded intrinsic. You can use <tt>llvm.umul.with.overflow</tt>
+on any integer bit width.</p>
+
+<pre>
+ declare {i16, i1} @llvm.umul.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.umul.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.umul.with.overflow.i64(i64 %a, i64 %b)
+</pre>
+
+<h5>Overview:</h5>
+
+<p><i><b>Warning:</b> '<tt>llvm.umul.with.overflow</tt>' is badly broken. It is
+actively being fixed, but it should not currently be used!</i></p>
+
+<p>The '<tt>llvm.umul.with.overflow</tt>' family of intrinsic functions perform
+a unsigned multiplication of the two arguments, and indicate whether an overflow
+occurred during the unsigned multiplication.</p>
+
+<h5>Arguments:</h5>
+
+<p>The arguments (%a and %b) and the first element of the result structure may
+be of integer types of any bit width, but they must have the same bit width. The
+second element of the result structure must be of type <tt>i1</tt>. <tt>%a</tt>
+and <tt>%b</tt> are the two values that will undergo unsigned
+multiplication.</p>
+
+<h5>Semantics:</h5>
+
+<p>The '<tt>llvm.umul.with.overflow</tt>' family of intrinsic functions perform
+an unsigned multiplication of the two arguments. They return a structure —
+the first element of which is the multiplication, and the second element of
+which is a bit specifying if the unsigned multiplication resulted in an
+overflow.</p>
+
+<h5>Examples:</h5>
+<pre>
+ %res = call {i32, i1} @llvm.umul.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %overflow, label %normal
+</pre>
+
</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>
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" 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-blue" 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>
projects / oota-llvm.git / blobdiff