The string 'undef' can be used anywhere a constant is expected, and
indicates that the user of the value may receive an unspecified bit-pattern.
- Undefined values may be of any type (other than label or void) and be used
- anywhere a constant is permitted.
+ Undefined values may be of any type (other than '
label'
+ or '
void') and be used anywhere a constant is permitted.
Undefined values are useful because they indicate to the compiler that the
program is well defined no matter what value is used. This gives the
@@ -2202,7 +2245,7 @@ Safe:
This is safe because all of the output bits are affected by the undef bits.
-Any output bit can have a zero or one depending on the input bits.
+ Any output bit can have a zero or one depending on the input bits.
%A = or %X, undef
@@ -2216,13 +2259,14 @@ Unsafe:
These logical operations have bits that are not always affected by the input.
-For example, if "%X" has a zero bit, then the output of the 'and' operation will
-always be a zero, no matter what the corresponding bit from the undef is. As
-such, it is unsafe to optimize or assume that the result of the and is undef.
-However, it is safe to assume that all bits of the undef could be 0, and
-optimize the and to 0. Likewise, it is safe to assume that all the bits of
-the undef operand to the or could be set, allowing the or to be folded to
--1.
+ For example, if
%X has a zero bit, then the output of the
+ '
and' operation will always be a zero for that bit, no matter what
+ the corresponding bit from the '
undef' is. As such, it is unsafe to
+ optimize or assume that the result of the '
and' is '
undef'.
+ However, it is safe to assume that all bits of the '
undef' could be
+ 0, and optimize the '
and' to 0. Likewise, it is safe to assume that
+ all the bits of the '
undef' operand to the '
or' could be
+ set, allowing the '
or' to be folded to -1.
%A = select undef, %X, %Y
@@ -2238,13 +2282,14 @@ Unsafe:
%C = undef
-
This set of examples show that undefined select (and conditional branch)
-conditions can go "either way" but they have to come from one of the two
-operands. In the %A example, if %X and %Y were both known to have a clear low
-bit, then %A would have to have a cleared low bit. However, in the %C example,
-the optimizer is allowed to assume that the undef operand could be the same as
-%Y, allowing the whole select to be eliminated.
-
+
This set of examples shows that undefined 'select' (and conditional
+ branch) conditions can go either way, but they have to come from one
+ of the two operands. In the %A example, if %X and
+ %Y were both known to have a clear low bit, then %A would
+ have to have a cleared low bit. However, in the %C example, the
+ optimizer is allowed to assume that the 'undef' operand could be the
+ same as %Y, allowing the whole 'select' to be
+ eliminated.
%A = xor undef, undef
@@ -2265,16 +2310,17 @@ Safe:
%F = undef
-
This example points out that two undef operands are not necessarily the same.
-This can be surprising to people (and also matches C semantics) where they
-assume that "X^X" is always zero, even if X is undef. This isn't true for a
-number of reasons, but the short answer is that an undef "variable" can
-arbitrarily change its value over its "live range". This is true because the
-"variable" doesn't actually have a live range. Instead, the value is
-logically read from arbitrary registers that happen to be around when needed,
-so the value is not necessarily consistent over time. In fact, %A and %C need
-to have the same semantics or the core LLVM "replace all uses with" concept
-would not hold.
+
This example points out that two 'undef' operands are not
+ necessarily the same. This can be surprising to people (and also matches C
+ semantics) where they assume that "X^X" is always zero, even
+ if X is undefined. This isn't true for a number of reasons, but the
+ short answer is that an 'undef' "variable" can arbitrarily change
+ its value over its "live range". This is true because the variable doesn't
+ actually have a live range. Instead, the value is logically read
+ from arbitrary registers that happen to be around when needed, so the value
+ is not necessarily consistent over time. In fact, %A and %C
+ need to have the same semantics or the core LLVM "replace all uses with"
+ concept would not hold.
%A = fdiv undef, %X
@@ -2285,17 +2331,17 @@ b: unreachable
These examples show the crucial difference between an undefined
-value and undefined behavior. An undefined value (like undef) is
-allowed to have an arbitrary bit-pattern. This means that the %A operation
-can be constant folded to undef because the undef could be an SNaN, and fdiv is
-not (currently) defined on SNaN's. However, in the second example, we can make
-a more aggressive assumption: because the undef is allowed to be an arbitrary
-value, we are allowed to assume that it could be zero. Since a divide by zero
-has undefined behavior, we are allowed to assume that the operation
-does not execute at all. This allows us to delete the divide and all code after
-it: since the undefined operation "can't happen", the optimizer can assume that
-it occurs in dead code.
-
+ value and
undefined behavior. An undefined value (like
+ '
undef') is allowed to have an arbitrary bit-pattern. This means that
+ the
%A operation can be constant folded to '
undef', because
+ the '
undef' could be an SNaN, and
fdiv is not (currently)
+ defined on SNaN's. However, in the second example, we can make a more
+ aggressive assumption: because the
undef is allowed to be an
+ arbitrary value, we are allowed to assume that it could be zero. Since a
+ divide by zero has
undefined behavior, we are allowed to assume that
+ the operation does not execute at all. This allows us to delete the divide and
+ all code after it. Because the undefined operation "can't happen", the
+ optimizer can assume that it occurs in dead code.
a: store undef -> %X
@@ -2305,17 +2351,20 @@ a: <deleted>
b: unreachable
-
These examples reiterate the fdiv example: a store "of" an undefined value
-can be assumed to not have any effect: we can assume that the value is
-overwritten with bits that happen to match what was already there. However, a
-store "to" an undefined location could clobber arbitrary memory, therefore, it
-has undefined behavior.
+
These examples reiterate the fdiv example: a store of an
+ undefined value can be assumed to not have any effect; we can assume that the
+ value is overwritten with bits that happen to match what was already there.
+ However, a store to an undefined location could clobber arbitrary
+ memory, therefore, it has undefined behavior.
+
+
+
Trap values are similar to undef values, however
instead of representing an unspecified bit pattern, they represent the
@@ -2367,7 +2416,12 @@ has undefined behavior.
terminator instruction
if the terminator instruction has multiple successors and the instruction
is always executed when control transfers to one of the successors, and
- may not be executed when control is transfered to another.
+ may not be executed when control is transferred to another.
+
+
Additionally, an instruction also control-depends on a terminator
+ instruction if the set of instructions it otherwise depends on would be
+ different if the terminator had transferred control to a different
+ successor.
Dependence is transitive.
@@ -2394,11 +2448,11 @@ entry:
%narrowaddr = bitcast i32* @g to i16*
%wideaddr = bitcast i32* @g to i64*
- %trap3 = load 16* %narrowaddr ; Returns a trap value.
- %trap4 = load i64* %widaddr ; Returns a trap value.
+ %trap3 = load i16* %narrowaddr ; Returns a trap value.
+ %trap4 = load i64* %wideaddr ; Returns a trap value.
- %cmp = icmp i32 slt %trap, 0 ; Returns a trap value.
- %br i1 %cmp, %true, %end ; Branch to either destination.
+ %cmp = icmp slt i32 %trap, 0 ; Returns a trap value.
+ br i1 %cmp, label %true, label %end ; Branch to either destination.
true:
volatile store i32 0, i32* @g ; This is control-dependent on %cmp, so
@@ -2411,17 +2465,34 @@ end:
; control-dependent on %cmp, so this
; always results in a trap value.
- volatile store i32 0, i32* @g ; %end is control-equivalent to %entry
- ; so this is defined (ignoring earlier
+ volatile store i32 0, i32* @g ; This would depend on the store in %true
+ ; if %cmp is true, or the store in %entry
+ ; otherwise, so this is undefined behavior.
+
+ br i1 %cmp, label %second_true, label %second_end
+ ; The same branch again, but this time the
+ ; true block doesn't have side effects.
+
+second_true:
+ ; No side effects!
+ ret void
+
+second_end:
+ volatile store i32 0, i32* @g ; This time, the instruction always depends
+ ; on the store in %end. Also, it is
+ ; control-equivalent to %end, so this is
+ ; well-defined (again, ignoring earlier
; undefined behavior in this example).
-
-
+
+
+
blockaddress(@function, %block)
@@ -2430,33 +2501,33 @@ end:
the address of the entry block is illegal.
This value only has defined behavior when used as an operand to the
- 'indirectbr' instruction or for comparisons
- against null. Pointer equality tests between labels addresses is undefined
- behavior - though, again, comparison against null is ok, and no label is
- equal to the null pointer. This may also be passed around as an opaque
- pointer sized value as long as the bits are not inspected. This allows
- ptrtoint and arithmetic to be performed on these values so long as
- the original value is reconstituted before the indirectbr.
+ '
indirectbr' instruction, or for
+ comparisons against null. Pointer equality tests between labels addresses
+ results in undefined behavior — though, again, comparison against null
+ is ok, and no label is equal to the null pointer. This may be passed around
+ as an opaque pointer sized value as long as the bits are not inspected. This
+ allows
ptrtoint and arithmetic to be performed on these values so
+ long as the original value is reconstituted before the
indirectbr
+ instruction.
-
Finally, some targets may provide defined semantics when
- using the value as the operand to an inline assembly, but that is target
- specific.
-
+
Finally, some targets may provide defined semantics when using the value as
+ the operand to an inline assembly, but that is target specific.
-
+
-
+
Constant expressions are used to allow expressions involving other constants
to be used as constants. Constant expressions may be of
any first class type and may involve any LLVM
operation that does not have side effects (e.g. load and call are not
- supported). The following is the syntax for constant expressions:
+ supported). The following is the syntax for constant expressions:
- trunc (CST to TYPE)
@@ -2576,16 +2647,18 @@ end:
+
+
-
+
-
+
-
+
-
+
LLVM supports inline assembler expressions (as opposed
to Module-Level Inline Assembly) through the use of
@@ -2634,17 +2707,16 @@ call void asm alignstack "eieio", ""()
documented here. Constraints on what can be done (e.g. duplication, moving,
etc need to be documented). This is probably best done by reference to
another document that covers inline asm from a holistic perspective.
-
-
+
-
+
The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode
- attached to it that contains a constant integer. If present, the code
- generator will use the integer as the location cookie value when report
+ attached to it that contains a list of constant integers. If present, the
+ code generator will use the integer as the location cookie value when report
errors through the LLVMContext error reporting mechanisms. This allows a
front-end to correlate backend errors that occur with inline asm back to the
source code that produced it. For example:
@@ -2656,16 +2728,19 @@ call void asm sideeffect "something bad", ""()
, !srcloc !42
It is up to the front-end to make sense of the magic numbers it places in the
- IR.
+ IR. If the MDNode contains multiple constants, the code generator will use
+ the one that corresponds to the line of the asm that the error occurs on.
-
-
-
+
+
+
+
LLVM IR allows metadata to be attached to instructions in the program that
can convey extra information about the code to the optimizers and code
@@ -2690,25 +2765,31 @@ call void asm sideeffect "something bad", ""(), !srcloc !42
Metadata can be used as function arguments. Here llvm.dbg.value
function is using two metadata arguments.
-
- call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)
-
+
+
+call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)
+
+
Metadata can be attached with an instruction. Here metadata !21 is
attached with add instruction using !dbg identifier.
-
- %indvar.next = add i64 %indvar, 1, !dbg !21
-
+
+
+%indvar.next = add i64 %indvar, 1, !dbg !21
+
+
+
+
-
+
-
+
LLVM has a number of "magic" global variables that contain data that affect
code generation or other IR semantics. These are documented here. All globals
of this sort should have a section specified as "llvm.metadata". This
@@ -2716,11 +2797,11 @@ section and all globals that start with "llvm." are reserved for use
by LLVM.
-
+
-
+
The @llvm.used global is an array with i8* element type which has appending linkage. This array contains a list of
@@ -2751,11 +2832,13 @@ object file to prevent the assembler and linker from molesting the symbol.
-
+
-
+
The @llvm.compiler.used directive is the same as the
@llvm.used directive, except that it only prevents the compiler from
@@ -2769,11 +2852,11 @@ should not be exposed to source languages.
-
+
-
+
%0 = type { i32, void ()* }
@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }]
@@ -2784,11 +2867,11 @@ should not be exposed to source languages.
-
+
-
+
%0 = type { i32, void ()* }
@llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }]
@@ -2799,12 +2882,13 @@ should not be exposed to source languages.
+
-
+
-
+
-
-
+
-
+
As mentioned previously, every basic block
in a program ends with a "Terminator" instruction, which indicates which
@@ -2837,13 +2920,12 @@ Instructions
'
unwind' instruction, and the
'
unreachable' instruction.
-
-
-
+
-
+
Syntax:
@@ -2889,9 +2971,11 @@ Instruction
-
+
-
+
Syntax:
@@ -2930,11 +3014,11 @@ IfUnequal:
-
+
-
+
Syntax:
@@ -2985,11 +3069,11 @@ IfUnequal:
-
+
-
+
Syntax:
@@ -3033,11 +3117,11 @@ IfUnequal:
-
+
-
+
Syntax:
@@ -3123,10 +3207,11 @@ that the invoke/unwind semantics are likely to change in future versions.
-
+
-
+
Syntax:
@@ -3154,10 +3239,11 @@ that the invoke/unwind semantics are likely to change in future versions.
-
+
-
+
Syntax:
@@ -3175,10 +3261,14 @@ Instruction
+
-
+
-
+
Binary operators are used to do most of the computation in a program. They
require two operands of the same type, execute an operation on them, and
@@ -3188,14 +3278,12 @@ Instruction
There are several different binary operators:
-
-
-
+
-
+
Syntax:
@@ -3236,11 +3324,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3266,11 +3354,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3318,11 +3406,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3354,11 +3442,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3404,11 +3492,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3434,14 +3522,16 @@ Instruction
-
+
-
+
Syntax:
- <result> = udiv <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = udiv <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = udiv exact <ty> <op1>, <op2> ; yields {ty}:result
Overview:
@@ -3460,6 +3550,11 @@ Instruction
Division by zero leads to undefined behavior.
+
If the exact keyword is present, the result value of the
+ udiv is a trap value if %op1 is not a
+ multiple of %op2 (as such, "((a udiv exact b) mul b) == a").
+
+
Example:
<result> = udiv i32 4, %var ; yields {i32}:result = 4 / %var
@@ -3468,10 +3563,11 @@ Instruction
+
Syntax:
@@ -3510,10 +3606,11 @@ Instruction
+
Syntax:
@@ -3539,10 +3636,11 @@ Instruction
+
Syntax:
@@ -3576,11 +3674,11 @@ Instruction
+
Syntax:
@@ -3600,9 +3698,10 @@ Instruction
Semantics:
This instruction returns the remainder of a division (where the result
- has the same sign as the dividend, op1), not the modulo
- operator (where the result has the same sign as the divisor, op2) of
- a value. For more information about the difference,
+ is either zero or has the same sign as the dividend, op1), not the
+ modulo operator (where the result is either zero or has the same sign
+ as the divisor, op2) of a value.
+ For more information about the difference,
see The
Math Forum. For a table of how this is implemented in various languages,
please see
@@ -3626,10 +3725,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3656,11 +3756,14 @@ Instruction
+
+
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
@@ -3668,17 +3771,19 @@ Operations
same type, execute an operation on them, and produce a single value. The
resulting value is the same type as its operands.
-
+
Syntax:
- <result> = shl <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = shl <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = shl nuw <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = shl nsw <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = shl nuw nsw <ty> <op1>, <op2> ; yields {ty}:result
Overview:
@@ -3698,6 +3803,14 @@ Instruction
vectors, each vector element of
op1 is shifted by the corresponding
shift amount in
op2.
+
If the nuw keyword is present, then the shift produces a
+ trap value if it shifts out any non-zero bits. If
+ the nsw keyword is present, then the shift produces a
+ trap value if it shifts out any bits that disagree
+ with the resultant sign bit. As such, NUW/NSW have the same semantics as
+ they would if the shift were expressed as a mul instruction with the same
+ nsw/nuw bits in (mul %op1, (shl 1, %op2)).
+
Example:
<result> = shl i32 4, %var ; yields {i32}: 4 << %var
@@ -3710,14 +3823,16 @@ Instruction
-
+
-
+
Syntax:
- <result> = lshr <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = lshr <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = lshr exact <ty> <op1>, <op2> ; yields {ty}:result
Overview:
@@ -3737,6 +3852,11 @@ Instruction
vectors, each vector element of
op1 is shifted by the corresponding
shift amount in
op2.
+
If the exact keyword is present, the result value of the
+ lshr is a trap value if any of the bits
+ shifted out are non-zero.
+
+
Example:
<result> = lshr i32 4, 1 ; yields {i32}:result = 2
@@ -3750,13 +3870,16 @@ Instruction
+
+
+
Syntax:
- <result> = ashr <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = ashr <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = ashr exact <ty> <op1>, <op2> ; yields {ty}:result
Overview:
@@ -3777,6 +3900,10 @@ Instruction
the arguments are vectors, each vector element of
op1 is shifted by
the corresponding shift amount in
op2.
+
If the exact keyword is present, the result value of the
+ ashr is a trap value if any of the bits
+ shifted out are non-zero.
+
Example:
<result> = ashr i32 4, 1 ; yields {i32}:result = 2
@@ -3790,10 +3917,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3850,9 +3978,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3911,10 +4041,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3974,12 +4105,14 @@ Instruction
+
+
-
+
-
+
LLVM supports several instructions to represent vector operations in a
target-independent manner. These instructions cover the element-access and
@@ -3988,14 +4121,12 @@ Instruction
will want to use target-specific intrinsics to take full advantage of a
specific target.
-
-
-
+
-
+
Syntax:
@@ -4027,11 +4158,11 @@ Instruction
-
+
-
+
Syntax:
@@ -4063,11 +4194,11 @@ Instruction
-
+
-
+
Syntax:
@@ -4110,24 +4241,24 @@ Instruction
+
+
-
+
-
+
LLVM supports several instructions for working with
aggregate values.
-
-
-
+
-
+
Syntax:
@@ -4140,10 +4271,18 @@ Instruction
Arguments:
The first operand of an 'extractvalue' instruction is a value
- of struct, union or
+ of struct or
array type. The operands are constant indices to
specify which value to extract in a similar manner as indices in a
'getelementptr' instruction.
+
The major differences to getelementptr indexing are:
+
+ - Since the value being indexed is not a pointer, the first index is
+ omitted and assumed to be zero.
+ - At least one index must be specified.
+ - Not only struct indices but also array indices must be in
+ bounds.
+
Semantics:
The result is the value at the position in the aggregate specified by the
@@ -4157,15 +4296,15 @@ Instruction
-
+
-
+
Syntax:
- <result> = insertvalue <aggregate type> <val>, <ty> <elt>, <idx> ; yields <aggregate type>
+ <result> = insertvalue <aggregate type> <val>, <ty> <elt>, <idx>{, }* ; yields <aggregate type>
Overview:
@@ -4174,11 +4313,11 @@ Instruction
Arguments:
The first operand of an 'insertvalue' instruction is a value
- of struct, union or
+ of struct or
array type. The second operand is a first-class
value to insert. The following operands are constant indices indicating
the position at which to insert the value in a similar manner as indices in a
- 'getelementptr' instruction. The
+ 'extractvalue' instruction. The
value to insert must have the same type as the value identified by the
indices.
@@ -4189,33 +4328,33 @@ Instruction
Example:
- %agg1 = insertvalue {i32, float} undef, i32 1, 0 ; yields {i32 1, float undef}
- %agg2 = insertvalue {i32, float} %agg1, float %val, 1 ; yields {i32 1, float %val}
+ %agg1 = insertvalue {i32, float} undef, i32 1, 0 ; yields {i32 1, float undef}
+ %agg2 = insertvalue {i32, float} %agg1, float %val, 1 ; yields {i32 1, float %val}
+ %agg3 = insertvalue {i32, {float}} %agg1, float %val, 1, 0 ; yields {i32 1, float %val}
+
-
+
-
+
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, and allocate
memory in LLVM.
-
-
-
+
-
+
Syntax:
@@ -4262,10 +4401,11 @@ Instruction
-
+
-
+
Syntax:
@@ -4320,10 +4460,11 @@ Instruction
-
+
-
+
Syntax:
@@ -4381,11 +4522,11 @@ Instruction
-
+
-
+
Syntax:
@@ -4407,12 +4548,12 @@ Instruction
indexes a value of the type pointed to (not necessarily the value directly
pointed to, since the first index can be non-zero), etc. The first type
indexed into must be a pointer value, subsequent types can be arrays,
- vectors, structs and unions. Note that subsequent types being indexed into
+ vectors, and structs. Note that subsequent types being indexed into
can never be pointers, since that would require loading the pointer before
continuing calculation.
The type of each index argument depends on the type it is indexing into.
- When indexing into a (optionally packed) structure or union, only i32
+ When indexing into a (optionally packed) structure, only i32
integer constants are allowed. When indexing into an array, pointer
or vector, integers of any width are allowed, and they are not required to be
constant.
@@ -4511,23 +4652,25 @@ entry:
-
-
-
+
+
+
+
The instructions in this category are the conversion instructions (casting)
which all take a single operand and a type. They perform various bit
conversions on the operand.
-
-
-
-
+
+
+
Syntax:
@@ -4539,12 +4682,12 @@ entry:
type ty2.
Arguments:
-The 'trunc' instruction takes a value to trunc, which must
- be an integer type, and a type that specifies the
- size and type of the result, which must be
- an integer type. The bit size of value must
- be larger than the bit size of ty2. Equal sized types are not
- allowed.
+The 'trunc' instruction takes a value to trunc, and a type to trunc it to.
+ Both types must be of integer types, or vectors
+ of the same number of integers.
+ The bit size of the value must be larger than
+ the bit size of the destination type, ty2.
+ Equal sized types are not allowed.
Semantics:
The 'trunc' instruction truncates the high order bits
@@ -4554,18 +4697,20 @@ entry:
Example:
- %X = trunc i32 257 to i8 ; yields i8:1
- %Y = trunc i32 123 to i1 ; yields i1:true
- %Z = trunc i32 122 to i1 ; yields i1:false
+ %X = trunc i32 257 to i8 ; yields i8:1
+ %Y = trunc i32 123 to i1 ; yields i1:true
+ %Z = trunc i32 122 to i1 ; yields i1:false
+ %W = trunc <2 x i16> <i16 8, i16 7> to <2 x i8> ; yields <i8 8, i8 7>
-
-
+
+
+
Syntax:
@@ -4578,10 +4723,11 @@ entry:
Arguments:
-The 'zext' instruction takes a value to cast, which must be of
- integer type, and a type to cast it to, which must
- also be of integer type. The bit size of the
- value must be smaller than the bit size of the destination type,
+
The 'zext' instruction takes a value to cast, and a type to cast it to.
+ Both types must be of integer types, or vectors
+ of the same number of integers.
+ The bit size of the value must be smaller than
+ the bit size of the destination type,
ty2.
Semantics:
@@ -4594,15 +4740,17 @@ entry:
%X = zext i32 257 to i64 ; yields i64:257
%Y = zext i1 true to i32 ; yields i32:1
+ %Z = zext <2 x i16> <i16 8, i16 7> to <2 x i32> ; yields <i32 8, i32 7>
-
-
+
+
+
Syntax:
@@ -4613,10 +4761,11 @@ entry:
The 'sext' sign extends value to the type ty2.
Arguments:
-The 'sext' instruction takes a value to cast, which must be of
- integer type, and a type to cast it to, which must
- also be of integer type. The bit size of the
- value must be smaller than the bit size of the destination type,
+
The 'sext' instruction takes a value to cast, and a type to cast it to.
+ Both types must be of integer types, or vectors
+ of the same number of integers.
+ The bit size of the value must be smaller than
+ the bit size of the destination type,
ty2.
Semantics:
@@ -4630,16 +4779,17 @@ entry:
%X = sext i8 -1 to i16 ; yields i16 :65535
%Y = sext i1 true to i32 ; yields i32:-1
+ %Z = sext <2 x i16> <i16 8, i16 7> to <2 x i32> ; yields <i32 8, i32 7>
-
+
-
+
Syntax:
@@ -4673,10 +4823,11 @@ entry:
-
-
+
+
+
Syntax:
@@ -4702,17 +4853,18 @@ entry:
Example:
- %X = fpext float 3.1415 to double ; yields double:3.1415
- %Y = fpext float 1.0 to float ; yields float:1.0 (no-op)
+ %X = fpext float 3.125 to double ; yields double:3.125000e+00
+ %Y = fpext double %X to fp128 ; yields fp128:0xL00000000000000004000900000000000
-
-
+
+
+
Syntax:
@@ -4746,10 +4898,11 @@ entry:
-
-
+
+
+
Syntax:
@@ -4784,10 +4937,11 @@ entry:
-
-
+
+
+
Syntax:
@@ -4820,10 +4974,11 @@ entry:
-
-
+
+
+
Syntax:
@@ -4855,10 +5010,11 @@ entry:
-
-
+
+
+
Syntax:
@@ -4892,10 +5048,11 @@ entry:
-
-
+
+
+
Syntax:
@@ -4929,10 +5086,11 @@ entry:
-
-
+
+
+
Syntax:
@@ -4971,21 +5129,24 @@ entry:
+
+
-
+
-
+
The instructions in this category are the "miscellaneous" instructions, which
defy better classification.
-
-
-
+
-
+
Syntax:
@@ -5084,10 +5245,11 @@ entry:
-
+
-
+
Syntax:
@@ -5204,11 +5366,11 @@ entry:
-
+
-
+
Syntax:
@@ -5252,11 +5414,11 @@ Loop: ; Infinite loop that counts from 0 on up...
-
+
-
+
Syntax:
@@ -5295,11 +5457,11 @@ Loop: ; Infinite loop that counts from 0 on up...
-
+
-
+
Syntax:
@@ -5404,11 +5566,11 @@ freestanding environments and non-C-based languages.
-
+
-
+
Syntax:
@@ -5449,11 +5611,15 @@ freestanding environments and non-C-based languages.
+
+
+
+
-
+
-
+
LLVM supports the notion of an "intrinsic function". These functions have
well known names and semantics and are required to follow certain
@@ -5496,14 +5662,12 @@ freestanding environments and non-C-based languages.
To learn how to add an intrinsic function, please see the
Extending LLVM Guide.
-
-
-
+
-
+
Variable argument support is defined in LLVM with
the va_arg instruction and these three
@@ -5545,15 +5709,13 @@ declare void @llvm.va_copy(i8*, i8*)
declare void @llvm.va_end(i8*)
-
-
-
+
-
+
Syntax:
@@ -5579,11 +5741,11 @@ declare void @llvm.va_end(i8*)
-
+
-
+
Syntax:
@@ -5610,11 +5772,11 @@ declare void @llvm.va_end(i8*)
-
+
-
+
Syntax:
@@ -5640,12 +5802,14 @@ declare void @llvm.va_end(i8*)
+
+
-
+
-
+
LLVM support for Accurate Garbage
Collection (GC) requires the implementation and generation of these
@@ -5660,14 +5824,12 @@ LLVM.
The garbage collection intrinsics only operate on objects in the generic
address space (address space zero).
-
-
-
+
-
+
Syntax:
@@ -5694,11 +5856,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -5726,11 +5888,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -5757,24 +5919,24 @@ LLVM.
+
+
-
+
-
+
These intrinsics are provided by LLVM to expose special features that may
only be implemented with code generator support.
-
-
-
+
-
+
Syntax:
@@ -5805,11 +5967,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -5839,11 +6001,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -5869,11 +6031,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -5894,11 +6056,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -5927,11 +6089,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -5958,11 +6120,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -5984,26 +6146,26 @@ LLVM.
+
+
-
+
-
+
LLVM provides intrinsics for a few important standard C library functions.
These intrinsics allow source-language front-ends to pass information about
the alignment of the pointer arguments to the code generator, providing
opportunity for more efficient code generation.
-
-
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.memcpy on any
@@ -6053,11 +6215,11 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.memmove on any integer bit
@@ -6109,16 +6271,16 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.memset on any integer bit
- width and for different address spaces. Not all targets support all bit
- widths however.
+ width and for different address spaces. However, not all targets support all
+ bit widths.
declare void @llvm.memset.p0i8.i32(i8* <dest>, i8 <val>,
@@ -6132,14 +6294,14 @@ LLVM.
particular byte value.
Note that, unlike the standard libc function, the llvm.memset
- intrinsic does not return a value, takes extra alignment/volatile arguments,
- and the destination can be in an arbitrary address space.
+ intrinsic does not return a value and takes extra alignment/volatile
+ arguments. Also, the destination can be in an arbitrary address space.
Arguments:
The first argument is a pointer to the destination to fill, the second is the
- byte value to fill it with, the third argument is an integer argument
+ byte value with which to fill it, the third argument is an integer argument
specifying the number of bytes to fill, and the fourth argument is the known
- alignment of destination location.
+ alignment of the destination location.
If the call to this intrinsic has an alignment value that is not 0 or 1,
then the caller guarantees that the destination pointer is aligned to that
@@ -6159,11 +6321,11 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.sqrt on any
@@ -6197,11 +6359,11 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.powi on any
@@ -6233,11 +6395,11 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.sin on any
@@ -6267,11 +6429,11 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.cos on any
@@ -6301,11 +6463,11 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.pow on any
@@ -6335,24 +6497,90 @@ LLVM.
+
+
+
+
+
+
+
+
Syntax:
+
This is an overloaded intrinsic. You can use llvm.exp on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.
+
+
+ declare float @llvm.exp.f32(float %Val)
+ declare double @llvm.exp.f64(double %Val)
+ declare x86_fp80 @llvm.exp.f80(x86_fp80 %Val)
+ declare fp128 @llvm.exp.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.exp.ppcf128(ppc_fp128 %Val)
+
+
+
Overview:
+
The 'llvm.exp.*' intrinsics perform the exp function.
+
+
Arguments:
+
The argument and return value are floating point numbers of the same
+ type.
+
+
Semantics:
+
This function returns the same values as the libm exp functions
+ would, and handles error conditions in the same way.
+
+
+
+
+
+
+
+
+
Syntax:
+
This is an overloaded intrinsic. You can use llvm.log on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.
+
+
+ declare float @llvm.log.f32(float %Val)
+ declare double @llvm.log.f64(double %Val)
+ declare x86_fp80 @llvm.log.f80(x86_fp80 %Val)
+ declare fp128 @llvm.log.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.log.ppcf128(ppc_fp128 %Val)
+
+
+
Overview:
+
The 'llvm.log.*' intrinsics perform the log function.
+
+
Arguments:
+
The argument and return value are floating point numbers of the same
+ type.
+
+
Semantics:
+
This function returns the same values as the libm log functions
+ would, and handles error conditions in the same way.
+
+
+
-
+
-
+
LLVM provides intrinsics for a few important bit manipulation operations.
These allow efficient code generation for some algorithms.
-
-
-
+
-
+
Syntax:
This is an overloaded intrinsic function. You can use bswap on any integer
@@ -6383,11 +6611,11 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit
@@ -6415,11 +6643,11 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.ctlz on any
@@ -6449,11 +6677,11 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.cttz on any
@@ -6482,23 +6710,25 @@ LLVM.
+
+
-
+
-
+
LLVM provides intrinsics for some arithmetic with overflow operations.
-
-
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.sadd.with.overflow
@@ -6540,11 +6770,13 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.uadd.with.overflow
@@ -6585,11 +6817,13 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.ssub.with.overflow
@@ -6631,11 +6865,13 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.usub.with.overflow
@@ -6677,11 +6913,13 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.smul.with.overflow
@@ -6724,11 +6962,13 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.umul.with.overflow
@@ -6769,12 +7009,14 @@ LLVM.
+
+
-
+
-
+
Half precision floating point is a storage-only format. This means that it is
a dense encoding (in memory) but does not support computation in the
@@ -6788,14 +7030,15 @@ LLVM.
float if needed, then converted to i16 with
llvm.convert.to.fp16, then
storing as an i16 value.
-
-
+
-
+
Syntax:
@@ -6826,11 +7069,13 @@ LLVM.
-
+
-
+
Syntax:
@@ -6860,12 +7105,14 @@ LLVM.
+
+
-
+
-
+
The LLVM debugger intrinsics (which all start with llvm.dbg.
prefix), are described in
@@ -6875,11 +7122,11 @@ LLVM.
-
+
-
+
The LLVM exception handling intrinsics (which all start with
llvm.eh. prefix), are described in
@@ -6889,11 +7136,11 @@ LLVM.
-
+
-
+
This intrinsic makes it possible to excise one parameter, marked with
the nest attribute, from a function.
@@ -6919,14 +7166,14 @@ LLVM.
The call %val = call i32 %fp(i32 %x, i32 %y) is then equivalent
to %val = call i32 %f(i8* %nval, i32 %x, i32 %y).
-
-
-
+
-
+
Syntax:
@@ -6963,12 +7210,14 @@ LLVM.
+
+
-
+
-
+
These intrinsic functions expand the "universal IR" of LLVM to represent
hardware constructs for atomic operations and memory synchronization. This
@@ -6988,13 +7237,12 @@ LLVM.
No one model or paradigm should be selected above others unless the hardware
itself ubiquitously does so.
-
-
-
-
+
+
+
Syntax:
declare void @llvm.memory.barrier(i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device>)
@@ -7062,11 +7310,11 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.atomic.cmp.swap on
@@ -7122,10 +7370,11 @@ LLVM.
-
-
+
+
+
Syntax:
This is an overloaded intrinsic. You can use llvm.atomic.swap on any
@@ -7178,12 +7427,11 @@ LLVM.
-
-
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.atomic.load.add on
@@ -7228,12 +7476,11 @@ LLVM.
-
-
-
+
Syntax:
This is an overloaded intrinsic. You can use llvm.atomic.load.sub on
@@ -7280,14 +7527,25 @@ LLVM.
-
-
-
+
+
+
Syntax:
These are overloaded intrinsics. You can
@@ -7360,14 +7618,25 @@ LLVM.
-
-
-
+
+
+
Syntax:
These are overloaded intrinsics. You can use llvm.atomic.load_max,
@@ -7438,25 +7707,24 @@ LLVM.
+
-
+
-
+
This class of intrinsics exists to information about the lifetime of memory
objects and ranges where variables are immutable.
-
-
-
+
-
+
Syntax:
@@ -7482,11 +7750,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -7511,15 +7779,15 @@ LLVM.
-
+
-
+
Syntax:
- declare {}* @llvm.invariant.start(i64 <size>, i8* nocapture <ptr>) readonly
+ declare {}* @llvm.invariant.start(i64 <size>, i8* nocapture <ptr>)
Overview:
@@ -7539,11 +7807,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -7565,24 +7833,24 @@ LLVM.
+
+
-
+
-
+
This class of intrinsics is designed to be generic and has no specific
purpose.
-
-
-
+
-
+
Syntax:
@@ -7606,11 +7874,11 @@ LLVM.
-
+
-
+
Syntax:
This is an overloaded intrinsic. You can use 'llvm.annotation' on
@@ -7642,11 +7910,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -7667,11 +7935,11 @@ LLVM.
-
+
-
+
Syntax:
@@ -7694,18 +7962,18 @@ LLVM.
the AllocaInst stack slot to be before local variables on the
stack. This is to ensure that if a local variable on the stack is
overwritten, it will destroy the value of the guard. When the function exits,
- the guard on the stack is checked against the original guard. If they're
+ the guard on the stack is checked against the original guard. If they are
different, then the program aborts by calling the __stack_chk_fail()
function.
-
+
-
+
Syntax:
@@ -7714,25 +7982,28 @@ LLVM.
Overview:
-
The llvm.objectsize intrinsic is designed to provide information
- to the optimizers to discover at compile time either a) when an
- operation like memcpy will either overflow a buffer that corresponds to
- an object, or b) to determine that a runtime check for overflow isn't
- necessary. An object in this context means an allocation of a
- specific class, structure, array, or other object.
+
The llvm.objectsize intrinsic is designed to provide information to
+ the optimizers to determine at compile time whether a) an operation (like
+ memcpy) will overflow a buffer that corresponds to an object, or b) that a
+ runtime check for overflow isn't necessary. An object in this context means
+ an allocation of a specific class, structure, array, or other object.
Arguments:
-
The llvm.objectsize intrinsic takes two arguments. The first
+
The llvm.objectsize intrinsic takes two arguments. The first
argument is a pointer to or into the object. The second argument
- is a boolean 0 or 1. This argument determines whether you want the
- maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or
+ is a boolean 0 or 1. This argument determines whether you want the
+ maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or
1, variables are not allowed.
Semantics:
The llvm.objectsize intrinsic is lowered to either a constant
- representing the size of the object concerned or i32/i64 -1 or 0
- (depending on the type argument if the size cannot be determined
- at compile time.
+ representing the size of the object concerned, or
i32/i64 -1 or 0,
+ depending on the
type argument, if the size cannot be determined at
+ compile time.
+
+
+
+
@@ -7745,7 +8016,7 @@ LLVM.
src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01">
Chris Lattner
-
The LLVM Compiler Infrastructure
+
The LLVM Compiler Infrastructure
Last modified: $Date$