It is illegal for a function declaration -to have any linkage type other than "externally visible", dllimport, +to have any linkage type other than "externally visible", dllimport or extern_weak.
-Aliases can have only external, internal and weak -linkages.
+Aliases can have only external, internal, weak +or weak_odr linkages.
@@ -884,7 +918,7 @@ define [linkage] [visibility]-declare i32 @printf(i8* noalias , ...) +declare i32 @printf(i8* noalias nocapture, ...) declare i32 @atoi(i8 zeroext) declare signext i8 @returns_signed_char()@@ -922,7 +956,10 @@ declare signext i8 @returns_signed_char() belong to the caller not the callee (for example, readonly functions should not write to byval parameters). This is not a valid attribute for return - values. + 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.
If a function that has an ssp attribute is inlined into a function
+
If a function that has an ssp attribute is inlined into a function
that doesn't have an ssp attribute, then the resulting function will
-have an ssp attribute.
If a function that has an sspreq attribute is inlined into a +If a function that has an sspreq attribute is inlined into a function that doesn't have an sspreq attribute or which has an ssp attribute, then the resulting function will have -an sspreq attribute.
When constructing the data layout for a given target, LLVM starts with a default set of specifications which are then (possibly) overriden by the @@ -1152,6 +1204,7 @@ are given in this list:
When LLVM is determining the alignment for a given type, it uses the following rules:
@@ -1214,14 +1267,16 @@ classifications: vector, structure, array, - label. + label, + metadata.The metadata type represents embedded metadata. The only derived type that +may contain metadata is metadata* or a function type that returns or +takes metadata typed parameters, but not pointer to metadata types.
+ ++ metadata ++
| i1 | -a single-bit integer. | -
| i32 | -a 32-bit integer. | -
| i1942652 | -a really big integer of over 1 million bits. | +
| i1 | +a single-bit integer. | +
| i32 | +a 32-bit integer. | +
| i1942652 | +a really big integer of over 1 million bits. |
Note that the code generator does not yet support large integer types @@ -1549,6 +1620,10 @@ reference to another object, which must live in memory. Pointer types may have an optional address space attribute defining the target-specific numbered address space where the pointed-to object resides. The default address space is zero.
+ +Note that LLVM does not permit pointers to void (void*) nor does +it permit pointers to labels (label*). Use i8* instead.
+<type> *
- { \2 * } %x = type { %t* }
+ { \2 * } %x = type { %x* }
{ \2 }* %y = type { %y }*
\1* %z = type %z*
@@ -1743,25 +1818,42 @@ them all and their syntax.
-The one non-intuitive notation for constants is the optional hexadecimal form +
The one non-intuitive notation for constants is the hexadecimal form of floating point constants. For example, the form 'double 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double 4.5e+15'. 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.
- +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 0xK +followed by 20 hexadecimal digits. +The 128-bit format used by PowerPC (two adjacent doubles) is represented +by 0xM followed by 32 hexadecimal digits. The IEEE 128-bit +format is represented +by 0xL 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).
-Aggregate constants arise from aggregation of simple constants -and smaller aggregate constants.
+Complex constants are a (potentially recursive) combination of simple +constants and smaller complex constants.
Embedded metadata provides a way to attach arbitrary data to the +instruction stream without affecting the behaviour of the program. There are +two metadata primitives, strings and nodes. All metadata has the +metadata type and is identified in syntax by a preceding exclamation +point ('!'). +
+ +A metadata string is a string surrounded by double quotes. It can contain +any character by escaping non-printable characters with "\xx" where "xx" is +the two digit hex code. For example: "!"test\00"". +
+ +Metadata nodes are represented with notation similar to structure constants +(a comma separated list of elements, surrounded by braces and preceeded by an +exclamation point). For example: "!{ metadata !"test\00", i32 10}". +
+ +A metadata node will attempt to track changes to the values it holds. In +the event that a value is deleted, it will be replaced with a typeless +"null", such as "metadata !{null, i32 10}".
+ +Optimizations may rely on metadata to provide additional information about +the program that isn't available in the instructions, or that isn't easily +computable. Similarly, the code generator may expect a certain metadata format +to be used to express debugging information.
+
ret i32 5 ; Return an integer value of 5
ret void ; Return from a void function
- ret { i32, i8 } { i32 4, i8 2 } ; Return an aggregate of values 4 and 2
+ ret { i32, i8 } { i32 4, i8 2 } ; Return a struct of values 4 and 2
Note that the code generator does not yet fully support large @@ -2147,7 +2270,7 @@ argument is evaluated. If the value is true, control flows to the 'iftrue' label argument. If "cond" is false, control flows to the 'iffalse' label argument.
Test:@@ -2286,6 +2409,11 @@ cleanup is performed in the case of either a longjmp or a thrown exception. Additionally, this is important for implementation of 'catch' clauses in high-level languages that support them. +
%cond = icmp eq, i32 %a, %b
br i1 %cond, label %IfEqual, label %IfUnequal
IfEqual:
Test:
%cond = icmp eq i32 %a, %b
br i1 %cond, label %IfEqual, label %IfUnequal
IfEqual:
ret i32 1
IfUnequal:
ret i32 0
For the purposes of the SSA form, the definition of the value +returned by the 'invoke' instruction is deemed to occur on +the edge from the current block to the "normal" label. If the callee +unwinds then no return value is available.
+%retval = invoke i32 @Test(i32 15) to label %Continue @@ -2381,16 +2509,15 @@ The result value has the same type as its operands.+ + +Arguments:
The two arguments to the 'add' instruction must be integer, floating point, or - vector values. Both arguments must have identical - types.
+ href="#t_integer">integer or + vector of integer values. Both arguments must + have identical types.Semantics:
-The value produced is the integer or floating point sum of the two -operands.
+The value produced is the integer sum of the two operands.
-If an integer sum has unsigned overflow, the result returned is the +
If the sum has unsigned overflow, the result returned is the mathematical result modulo 2n, where n is the bit width of the result.
@@ -2404,6 +2531,39 @@ instruction is appropriate for both signed and unsigned integers.
+ <result> = fadd <ty> <op1>, <op2> ; yields {ty}:result
+
+
+The 'fadd' instruction returns the sum of its two operands.
+ +The two arguments to the 'fadd' instruction must be +floating point or vector of +floating point values. Both arguments must have identical types.
+ +The value produced is the floating point sum of the two operands.
+ +
+ <result> = fadd float 4.0, %var ; yields {float}:result = 4.0 + %var
+
+The two arguments to the 'sub' instruction must be integer, floating point, - or vector values. Both arguments must have identical - types.
+ href="#t_integer">integer or vector of + integer values. Both arguments must have identical types.The value produced is the integer or floating point difference of -the two operands.
+The value produced is the integer difference of the two operands.
-If an integer difference has unsigned overflow, the result returned is the +
If the difference has unsigned overflow, the result returned is the mathematical result modulo 2n, where n is the bit width of the result.
@@ -2451,6 +2609,45 @@ instruction is appropriate for both signed and unsigned integers. + + + +
+ <result> = fsub <ty> <op1>, <op2> ; yields {ty}:result
+
+
+The 'fsub' instruction returns the difference of its two +operands.
+ +Note that the 'fsub' instruction is used to represent the +'fneg' instruction present in most other intermediate +representations.
+ +The two arguments to the 'fsub' instruction must be floating point or vector + of floating point values. Both arguments must have identical types.
+ +The value produced is the floating point difference of the two operands.
+ +
+ <result> = fsub float 4.0, %var ; yields {float}:result = 4.0 - %var
+ <result> = fsub float -0.0, %val ; yields {float}:result = -%var
+
+The two arguments to the 'mul' instruction must be integer, floating point, -or vector values. Both arguments must have identical -types.
+href="#t_integer">integer or vector of integer +values. Both arguments must have identical types.The value produced is the integer or floating point product of the -two operands.
+The value produced is the integer product of the two operands.
-If the result of an integer multiplication has unsigned overflow, +
If the result of the multiplication has unsigned overflow, the result returned is the mathematical result modulo 2n, where n is the bit width of the result.
Because LLVM integers use a two's complement representation, and the @@ -2491,6 +2686,35 @@ width of the full product.
<result> = fmul <ty> <op1>, <op2> ; yields {ty}:result
+
+The 'fmul' instruction returns the product of its two +operands.
+ +The two arguments to the 'fmul' instruction must be +floating point or vector +of floating point values. Both arguments must have identical types.
+ +The value produced is the floating point product of the two operands.
+ + <result> = fmul float 4.0, %var ; yields {float}:result = 4.0 * %var
+
+'type' must be a sized type.
@@ -3391,15 +3616,16 @@ space (address space zero). bytes of memory on the runtime stack, returning a pointer of the appropriate type to the program. If "NumElements" is specified, it is the number of elements allocated, otherwise "NumElements" is defaulted to be one. -If a constant alignment is specified, the value result of the allocation is guaranteed -to be aligned to at least that boundary. If not specified, or if zero, the target -can choose to align the allocation on any convenient boundary. +If a constant alignment is specified, the value result of the allocation is +guaranteed to be aligned to at least that boundary. If not specified, or if +zero, the target can choose to align the allocation on any convenient boundary +compatible with the type.'type' may be any sized type.
Memory is allocated; a pointer is returned. The operation is undefiend if +
Memory is allocated; a pointer is returned. The operation is undefined if there is insufficient stack space for the allocation. 'alloca'd memory is automatically released when the function returns. The 'alloca' instruction is commonly used to represent automatic variables that must @@ -3445,7 +3671,13 @@ alignment may produce less efficient code. An alignment of 1 is always safe.
The location of memory pointed to is loaded.
+The location of memory pointed to is loaded. If the value being loaded +is of scalar type then the number of bytes read does not exceed the minimum +number of bytes needed to hold all bits of the type. For example, loading an +i24 reads at most three bytes. When loading a value of a type like +i20 with a size that is not an integral number of bytes, the result +is undefined if the value was not originally written using a store of the +same type.
%ptr = alloca i32 ; yields {i32*}:ptr@@ -4252,109 +4494,6 @@ always yields an i1 result, as follows: - - -Semantics:
The contents of memory are updated to contain '<value>' -at the location specified by the '<pointer>' operand.
+at the location specified by the '<pointer>' operand. +If '<value>' is of scalar type then the number of bytes +written does not exceed the minimum number of bytes needed to hold all +bits of the type. For example, storing an i24 writes at most +three bytes. When writing a value of a type like i20 with a +size that is not an integral number of bytes, it is unspecified what +happens to the extra bits that do not belong to the type, but they will +typically be overwritten.Example:
%ptr = alloca i32 ; yields {i32*}:ptr store i32 3, i32* %ptr ; yields {void} @@ -3526,8 +3765,7 @@ the pointer before continuing calculation.-The type of each index argument depends on the type it is indexing into. When indexing into a (packed) structure, only i32 integer constants are allowed. When indexing into an array, pointer or vector, -only integers of 32 or 64 bits are allowed (also non-constants). 32-bit values -will be sign extended to 64-bits if required.
+integers of any width are allowed (also non-constants).For example, let's consider a C code fragment and how it gets compiled to LLVM:
@@ -3593,11 +3831,13 @@ the LLVM code for the given testcase is equivalent to: }Note that it is undefined to access an array out of bounds: array and -pointer indexes must always be within the defined bounds of the array type. -The one exception for this rule is zero length arrays. These arrays are -defined to be accessible as variable length arrays, which requires access -beyond the zero'th element.
+Note that it is undefined to access an array out of bounds: array +and pointer indexes must always be within the defined bounds of the +array type when accessed with an instruction that dereferences the +pointer (e.g. a load or store instruction). The one exception for +this rule is zero length arrays. These arrays are defined to be +accessible as variable length arrays, which requires access beyond the +zero'th element.
The getelementptr instruction is often confusing. For some more insight into how it works, see the getelementptr @@ -3612,6 +3852,8 @@ FAQ.
%vptr = getelementptr {i32, <2 x i8>}* %svptr, i64 0, i32 1, i32 1 ; yields i8*:eptr %eptr = getelementptr [12 x i8]* %aptr, i64 0, i32 1 + ; yields i32*:iptr + %iptr = getelementptr [10 x i32]* @arr, i16 0, i16 0
<result> = vicmp <cond> <ty> <op1>, <op2> ; yields {ty}:result
-
-The 'vicmp' instruction returns an integer vector value based on -element-wise comparison of its two integer vector operands.
-The 'vicmp' instruction takes three operands. The first operand is -the condition code indicating the kind of comparison to perform. It is not -a value, just a keyword. The possible condition code are:
-The remaining two arguments must be vector or -integer typed. They must also be identical types.
-The 'vicmp' instruction compares op1 and op2 -according to the condition code given as cond. The comparison yields a -vector of integer result, of -identical type as the values being compared. The most significant bit in each -element is 1 if the element-wise comparison evaluates to true, and is 0 -otherwise. All other bits of the result are undefined. The condition codes -are evaluated identically to the 'icmp' -instruction.
- -- <result> = vicmp eq <2 x i32> < i32 4, i32 0>, < i32 5, i32 0> ; yields: result=<2 x i32> < i32 0, i32 -1 > - <result> = vicmp ult <2 x i8 > < i8 1, i8 2>, < i8 2, i8 2 > ; yields: result=<2 x i8> < i8 -1, i8 0 > --
<result> = vfcmp <cond> <ty> <op1>, <op2>-
The 'vfcmp' instruction returns an integer vector value based on -element-wise comparison of its two floating point vector operands. The output -elements have the same width as the input elements.
-The 'vfcmp' instruction takes three operands. The first operand is -the condition code indicating the kind of comparison to perform. It is not -a value, just a keyword. The possible condition code are:
-The remaining two arguments must be vector of -floating point typed. They must also be identical -types.
-The 'vfcmp' instruction compares op1 and op2 -according to the condition code given as cond. The comparison yields a -vector of integer result, with -an identical number of elements as the values being compared, and each element -having identical with to the width of the floating point elements. The most -significant bit in each element is 1 if the element-wise comparison evaluates to -true, and is 0 otherwise. All other bits of the result are undefined. The -condition codes are evaluated identically to the -'fcmp' instruction.
- -- ; yields: result=<2 x i32> < i32 0, i32 -1 > - <result> = vfcmp oeq <2 x float> < float 4, float 0 >, < float 5, float 0 > - - ; yields: result=<2 x i64> < i64 -1, i64 0 > - <result> = vfcmp ult <2 x double> < double 1, double 2 >, < double 2, double 2> --
For the purposes of the SSA form, the use of each incoming value is +deemed to occur on the edge from the corresponding predecessor block +to the current block (but after any definition of an 'invoke' +instruction's return value on the same edge).
+At runtime, the 'phi' instruction logically takes on the value @@ -5684,7 +5828,7 @@ additional even-byte lengths (6 bytes, 8 bytes and more, respectively).
This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit width. Not all targets support all bit widths however.
- 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>) @@ -5796,103 +5940,308 @@ of src. For example, llvm.cttz(2) = 1.
+LLVM provides intrinsics for some arithmetic with overflow operations. +
+ +This is an overloaded intrinsic. You can use llvm.part.select + +
This is an overloaded intrinsic. You can use llvm.sadd.with.overflow on any integer bit width.
+
- declare i17 @llvm.part.select.i17 (i17 %val, i32 %loBit, i32 %hiBit)
- declare i29 @llvm.part.select.i29 (i29 %val, i32 %loBit, i32 %hiBit)
+ 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)
The 'llvm.part.select' family of intrinsic functions selects a -range of bits from an integer value and returns them in the same bit width as -the original value.
+ +The 'llvm.sadd.with.overflow' family of intrinsic functions perform +a signed addition of the two arguments, and indicate whether an overflow +occurred during the signed summation.
The first argument, %val and the result may be integer types of -any bit width but they must have the same bit width. The second and third -arguments must be i32 type since they specify only a bit index.
+ +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 i1. %a +and %b are the two values that will undergo signed addition.
The operation of the 'llvm.part.select' intrinsic has two modes -of operation: forwards and reverse. If %loBit is greater than -%hiBits then the intrinsic operates in reverse mode. Otherwise it -operates in forward mode.
-In forward mode, this intrinsic is the equivalent of shifting %val -right by %loBit bits and then ANDing it with a mask with -only the %hiBit - %loBit bits set, as follows:
-In reverse mode, a similar computation is made except that the bits are -returned in the reverse order. So, for example, if X has the value -i16 0x0ACF (101011001111) and we apply -part.select(i16 X, 8, 3) to it, we get back the value -i16 0x0026 (000000100110).
+ +The 'llvm.sadd.with.overflow' 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.
+ +
+ %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
+
+
+This is an overloaded intrinsic. You can use llvm.uadd.with.overflow +on any integer bit width.
+ +
+ 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)
+
+
+The 'llvm.uadd.with.overflow' family of intrinsic functions perform +an unsigned addition of the two arguments, and indicate whether a carry occurred +during the unsigned summation.
+ +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 i1. %a +and %b are the two values that will undergo unsigned addition.
+ +The 'llvm.uadd.with.overflow' 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.
+ +
+ %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
+
+
+This is an overloaded intrinsic. You can use llvm.ssub.with.overflow +on any integer bit width.
+ +
+ 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)
+
+
+The 'llvm.ssub.with.overflow' family of intrinsic functions perform +a signed subtraction of the two arguments, and indicate whether an overflow +occurred during the signed subtraction.
+ +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 i1. %a +and %b are the two values that will undergo signed subtraction.
+ +The 'llvm.ssub.with.overflow' 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.
+ +
+ %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
+
+
This is an overloaded intrinsic. You can use llvm.part.set + +
This is an overloaded intrinsic. You can use llvm.usub.with.overflow on any integer bit width.
+
- declare i17 @llvm.part.set.i17.i9 (i17 %val, i9 %repl, i32 %lo, i32 %hi)
- declare i29 @llvm.part.set.i29.i9 (i29 %val, i9 %repl, i32 %lo, i32 %hi)
+ 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)
The 'llvm.part.set' family of intrinsic functions replaces a range -of bits in an integer value with another integer value. It returns the integer -with the replaced bits.
+ +The 'llvm.usub.with.overflow' family of intrinsic functions perform +an unsigned subtraction of the two arguments, and indicate whether an overflow +occurred during the unsigned subtraction.
The first argument, %val and the result may be integer types of -any bit width but they must have the same bit width. %val is the value -whose bits will be replaced. The second argument, %repl may be an -integer of any bit width. The third and fourth arguments must be i32 -type since they specify only a bit index.
+ +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 i1. %a +and %b are the two values that will undergo unsigned subtraction.
The operation of the 'llvm.part.set' intrinsic has two modes -of operation: forwards and reverse. If %lo is greater than -%hi then the intrinsic operates in reverse mode. Otherwise it -operates in forward mode.
-For both modes, the %repl 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.
-In forward mode, the bits between %lo and %hi (inclusive) -are replaced with corresponding bits from %repl. That is the 0th bit -in %repl replaces the %loth bit in %val and etc. up -to the %hith bit.
-In reverse mode, a similar computation is made except that the bits are -reversed. That is, the 0th bit in %repl replaces the -%hi bit in %val and etc. down to the %loth bit.
+ +The 'llvm.usub.with.overflow' 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.
+
- llvm.part.set(0xFFFF, 0, 4, 7) -> 0xFF0F
- llvm.part.set(0xFFFF, 0, 7, 4) -> 0xFF0F
- llvm.part.set(0xFFFF, 1, 7, 4) -> 0xFF8F
- llvm.part.set(0xFFFF, F, 8, 3) -> 0xFFE7
- llvm.part.set(0xFFFF, 0, 3, 8) -> 0xFE07
+ %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
+
+
+This is an overloaded intrinsic. You can use llvm.smul.with.overflow +on any integer bit width.
+ +
+ 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)
+
+The 'llvm.smul.with.overflow' family of intrinsic functions perform +a signed multiplication of the two arguments, and indicate whether an overflow +occurred during the signed multiplication.
+ +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 i1. %a +and %b are the two values that will undergo signed multiplication.
+ +The 'llvm.smul.with.overflow' 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.
+ +
+ %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
+
+
+This is an overloaded intrinsic. You can use llvm.umul.with.overflow +on any integer bit width.
+ +
+ 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)
+
+
+The 'llvm.umul.with.overflow' family of intrinsic functions perform +a unsigned multiplication of the two arguments, and indicate whether an overflow +occurred during the unsigned multiplication.
+ +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 i1. %a +and %b are the two values that will undergo unsigned +multiplication.
+ +The 'llvm.umul.with.overflow' 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.
+ +
+ %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
+
+