+
+
+
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
@@ -2143,8 +2234,7 @@ Classifications
surprising) transformations that are valid (in pseudo IR):
-
-
+
%A = add %X, undef
%B = sub %X, undef
%C = xor %X, undef
@@ -2153,13 +2243,11 @@ Safe:
%B = undef
%C = undef
-
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
%B = and %X, undef
Safe:
@@ -2169,19 +2257,18 @@ Unsafe:
%A = undef
%B = undef
-
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
%B = select undef, 42, %Y
%C = select %X, %Y, undef
@@ -2194,18 +2281,17 @@ Unsafe:
%B = undef
%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
%B = undef
@@ -2223,64 +2309,190 @@ Safe:
%E = undef
%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
%B = fdiv %X, undef
Safe:
%A = undef
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
b: store %X -> undef
Safe:
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
+ fact that an instruction or constant expression which cannot evoke side
+ effects has nevertheless detected a condition which results in undefined
+ behavior.
+
+
There is currently no way of representing a trap value in the IR; they
+ only exist when produced by operations such as
+ add with the nsw flag.
+
+
Trap value behavior is defined in terms of value dependence:
+
+
+- Values other than phi nodes depend on
+ their operands.
+
+- Phi nodes depend on the operand corresponding
+ to their dynamic predecessor basic block.
+
+- Function arguments depend on the corresponding actual argument values in
+ the dynamic callers of their functions.
+
+- Call instructions depend on the
+ ret instructions that dynamically transfer
+ control back to them.
+
+- Invoke instructions depend on the
+ ret, unwind,
+ or exception-throwing call instructions that dynamically transfer control
+ back to them.
+
+- Non-volatile loads and stores depend on the most recent stores to all of the
+ referenced memory addresses, following the order in the IR
+ (including loads and stores implied by intrinsics such as
+ @llvm.memcpy.)
+
+
+
+
+
+- An instruction with externally visible side effects depends on the most
+ recent preceding instruction with externally visible side effects, following
+ the order in the IR. (This includes
+ volatile operations.)
+
+- An instruction control-depends on a
+ 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 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.
+
+
+
+
Whenever a trap value is generated, all values which depend on it evaluate
+ to trap. If they have side effects, the evoke their side effects as if each
+ operand with a trap value were undef. If they have externally-visible side
+ effects, the behavior is undefined.
+
+
Here are some examples:
+
+
+entry:
+ %trap = sub nuw i32 0, 1 ; Results in a trap value.
+ %still_trap = and i32 %trap, 0 ; Whereas (and i32 undef, 0) would return 0.
+ %trap_yet_again = getelementptr i32* @h, i32 %still_trap
+ store i32 0, i32* %trap_yet_again ; undefined behavior
+
+ store i32 %trap, i32* @g ; Trap value conceptually stored to memory.
+ %trap2 = load i32* @g ; Returns a trap value, not just undef.
+
+ volatile store i32 %trap, i32* @g ; External observation; undefined behavior.
+
+ %narrowaddr = bitcast i32* @g to i16*
+ %wideaddr = bitcast i32* @g to i64*
+ %trap3 = load i16* %narrowaddr ; Returns a trap value.
+ %trap4 = load i64* %wideaddr ; Returns a trap value.
+
+ %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
+ ; it has undefined behavior.
+ br label %end
+
+end:
+ %p = phi i32 [ 0, %entry ], [ 1, %true ]
+ ; Both edges into this PHI are
+ ; control-dependent on %cmp, so this
+ ; always results in a trap value.
+
+ 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)
@@ -2289,133 +2501,143 @@ has undefined behavior.
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 )
+ - trunc (CST to TYPE)
- Truncate a constant to another type. The bit size of CST must be larger
than the bit size of TYPE. Both types must be integers.
- - zext ( CST to TYPE )
+ - zext (CST to TYPE)
- Zero extend a constant to another type. The bit size of CST must be
- smaller or equal to the bit size of TYPE. Both types must be
- integers.
+ smaller than the bit size of TYPE. Both types must be integers.
- - sext ( CST to TYPE )
+ - sext (CST to TYPE)
- Sign extend a constant to another type. The bit size of CST must be
- smaller or equal to the bit size of TYPE. Both types must be
- integers.
+ smaller than the bit size of TYPE. Both types must be integers.
- - fptrunc ( CST to TYPE )
+ - fptrunc (CST to TYPE)
- Truncate a floating point constant to another floating point type. The
size of CST must be larger than the size of TYPE. Both types must be
floating point.
- - fpext ( CST to TYPE )
+ - fpext (CST to TYPE)
- Floating point extend a constant to another type. The size of CST must be
smaller or equal to the size of TYPE. Both types must be floating
point.
- - fptoui ( CST to TYPE )
+ - fptoui (CST to TYPE)
- Convert a floating point constant to the corresponding unsigned integer
constant. TYPE must be a scalar or vector integer type. CST must be of
scalar or vector floating point type. Both CST and TYPE must be scalars,
or vectors of the same number of elements. If the value won't fit in the
integer type, the results are undefined.
- - fptosi ( CST to TYPE )
+ - fptosi (CST to TYPE)
- Convert a floating point constant to the corresponding signed integer
constant. TYPE must be a scalar or vector integer type. CST must be of
scalar or vector floating point type. Both CST and TYPE must be scalars,
or vectors of the same number of elements. If the value won't fit in the
integer type, the results are undefined.
- - uitofp ( CST to TYPE )
+ - uitofp (CST to TYPE)
- Convert an unsigned integer constant to the corresponding floating point
constant. TYPE must be a scalar or vector floating point type. CST must be
of scalar or vector integer type. Both CST and TYPE must be scalars, or
vectors of the same number of elements. If the value won't fit in the
floating point type, the results are undefined.
- - sitofp ( CST to TYPE )
+ - sitofp (CST to TYPE)
- Convert a signed integer constant to the corresponding floating point
constant. TYPE must be a scalar or vector floating point type. CST must be
of scalar or vector integer type. Both CST and TYPE must be scalars, or
vectors of the same number of elements. If the value won't fit in the
floating point type, the results are undefined.
- - ptrtoint ( CST to TYPE )
+ - ptrtoint (CST to TYPE)
- Convert a pointer typed constant to the corresponding integer constant
TYPE must be an integer type. CST must be of pointer
type. The CST value is zero extended, truncated, or unchanged to
make it fit in TYPE.
- - inttoptr ( CST to TYPE )
+ - inttoptr (CST to TYPE)
- Convert a integer constant to a pointer constant. TYPE must be a pointer
type. CST must be of integer type. The CST value is zero extended,
truncated, or unchanged to make it fit in a pointer size. This one is
really dangerous!
- - bitcast ( CST to TYPE )
+ - bitcast (CST to TYPE)
- Convert a constant, CST, to another TYPE. The constraints of the operands
are the same as those for the bitcast
instruction.
- - getelementptr ( CSTPTR, IDX0, IDX1, ... )
- - getelementptr inbounds ( CSTPTR, IDX0, IDX1, ... )
+ - getelementptr (CSTPTR, IDX0, IDX1, ...)
+ - getelementptr inbounds (CSTPTR, IDX0, IDX1, ...)
- Perform the getelementptr operation on
constants. As with the getelementptr
instruction, the index list may have zero or more indexes, which are
required to make sense for the type of "CSTPTR".
- - select ( COND, VAL1, VAL2 )
+ - select (COND, VAL1, VAL2)
- Perform the select operation on constants.
- - icmp COND ( VAL1, VAL2 )
+ - icmp COND (VAL1, VAL2)
- Performs the icmp operation on constants.
- - fcmp COND ( VAL1, VAL2 )
+ - fcmp COND (VAL1, VAL2)
- Performs the fcmp operation on constants.
- - extractelement ( VAL, IDX )
+ - extractelement (VAL, IDX)
- Perform the extractelement operation on
constants.
- - insertelement ( VAL, ELT, IDX )
+ - insertelement (VAL, ELT, IDX)
- Perform the insertelement operation on
constants.
- - shufflevector ( VEC1, VEC2, IDXMASK )
+ - shufflevector (VEC1, VEC2, IDXMASK)
- Perform the shufflevector operation on
constants.
- - OPCODE ( LHS, RHS )
+ - extractvalue (VAL, IDX0, IDX1, ...)
+ - Perform the extractvalue operation on
+ constants. The index list is interpreted in a similar manner as indices in
+ a 'getelementptr' operation. At least one
+ index value must be specified.
+
+ - insertvalue (VAL, ELT, IDX0, IDX1, ...)
+ - Perform the insertvalue operation on
+ constants. The index list is interpreted in a similar manner as indices in
+ a 'getelementptr' operation. At least one
+ index value must be specified.
+
+ - OPCODE (LHS, RHS)
- Perform the specified operation of the LHS and RHS constants. OPCODE may
be any of the binary
or bitwise binary operations. The constraints
@@ -2425,16 +2647,18 @@ has undefined behavior.
+
+
-
+
-
+
-
+
-
+
LLVM supports inline assembler expressions (as opposed
to Module-Level Inline Assembly) through the use of
@@ -2445,31 +2669,25 @@ has undefined behavior.
containing the asm needs to align its stack conservatively. An example
inline assembler expression is:
-
-
+
i32 (i32) asm "bswap $0", "=r,r"
-
Inline assembler expressions may only be used as the callee operand of
a call instruction. Thus, typically we
have:
-
-
+
%X = call i32 asm "bswap $0", "=r,r"(i32 %Y)
-
Inline asms with side effects not visible in the constraint list must be
marked as having side effects. This is done through the use of the
'sideeffect' keyword, like so:
-
-
+
call void asm sideeffect "eieio", ""()
-
In some cases inline asms will contain code that will not work unless the
stack is aligned in some way, such as calls or SSE instructions on x86,
@@ -2478,11 +2696,9 @@ call void asm sideeffect "eieio", ""()
contain and should generate its usual stack alignment code in the prologue
if the 'alignstack' keyword is present:
-
-
+
call void asm alignstack "eieio", ""()
-
If both keywords appear the 'sideeffect' keyword must come
first.
@@ -2492,14 +2708,39 @@ call void asm alignstack "eieio", ""()
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 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:
+
+
+call void asm sideeffect "something bad", ""(), !srcloc !42
+...
+!42 = !{ i32 1234567 }
+
+
+
It is up to the front-end to make sense of the magic numbers it places in the
+ 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
@@ -2521,15 +2762,34 @@ call void asm alignstack "eieio", ""()
metadata nodes, which can be looked up in the module symbol table. For
example: "!foo = metadata !{!4, !3}".
+
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)
+
+
+
+
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
+
+
+
+
-
+
-
+
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
@@ -2537,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
@@ -2572,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
@@ -2590,33 +2852,43 @@ should not be exposed to source languages.
-
-
-
+
-
TODO: Describe this.
+
+
+%0 = type { i32, void ()* }
+@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }]
+
+
The @llvm.global_ctors array contains a list of constructor functions and associated priorities. The functions referenced by this array will be called in ascending order of priority (i.e. lowest first) when the module is loaded. The order of functions with the same priority is not defined.
+
-
+
-
+
+
+%0 = type { i32, void ()* }
+@llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }]
+
-
TODO: Describe this.
+
The @llvm.global_dtors array contains a list of destructor functions and associated priorities. The functions referenced by this array will be called in descending order of priority (i.e. highest first) when the module is loaded. The order of functions with the same priority is not defined.
+
+
-
+
-
+
-
-
+
-
+
As mentioned previously, every basic block
in a program ends with a "Terminator" instruction, which indicates which
@@ -2640,7 +2911,7 @@ Instructions
control flow, not values (the one exception being the
'
invoke' instruction).
-
There are six different terminator instructions: the
+
There are seven different terminator instructions: the
'ret' instruction, the
'br' instruction, the
'switch' instruction, the
@@ -2649,13 +2920,12 @@ Instructions
'
unwind' instruction, and the
'
unreachable' instruction.
-
-
-
+
-
+
Syntax:
@@ -2701,9 +2971,11 @@ Instruction
-
+
-
+
Syntax:
@@ -2742,11 +3014,11 @@ IfUnequal:
-
+
-
+
Syntax:
@@ -2797,11 +3069,11 @@ IfUnequal:
-
+
-
+
Syntax:
@@ -2845,11 +3117,11 @@ IfUnequal:
-
+
-
+
Syntax:
@@ -2888,9 +3160,10 @@ IfUnequal:
function to be invoked.
'function args': argument list whose types match the function
- signature argument types. If the function signature indicates the
- function accepts a variable number of arguments, the extra arguments can
- be specified.
+ signature argument types and parameter attributes. All arguments must be
+ of
first class type. If the function
+ signature indicates the function accepts a variable number of arguments,
+ the extra arguments can be specified.
'normal label': the label reached when the called function
executes a 'ret' instruction.
@@ -2934,10 +3207,11 @@ that the invoke/unwind semantics are likely to change in future versions.
-
+
-
+
Syntax:
@@ -2965,10 +3239,11 @@ that the invoke/unwind semantics are likely to change in future versions.
-
+
-
+
Syntax:
@@ -2986,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
@@ -2999,14 +3278,12 @@ Instruction
There are several different binary operators:
-
-
-
+
-
+
Syntax:
@@ -3036,7 +3313,8 @@ Instruction
nuw and nsw stand for "No Unsigned Wrap"
and "No Signed Wrap", respectively. If the nuw and/or
nsw keywords are present, the result value of the add
- is undefined if unsigned and/or signed overflow, respectively, occurs.
+ is a
trap value if unsigned and/or signed overflow,
+ respectively, occurs.
Example:
@@ -3046,11 +3324,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3076,11 +3354,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3116,7 +3394,8 @@ Instruction
nuw and nsw stand for "No Unsigned Wrap"
and "No Signed Wrap", respectively. If the nuw and/or
nsw keywords are present, the result value of the sub
- is undefined if unsigned and/or signed overflow, respectively, occurs.
+ is a
trap value if unsigned and/or signed overflow,
+ respectively, occurs.
Example:
@@ -3127,11 +3406,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3163,11 +3442,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3202,7 +3481,8 @@ Instruction
nuw and nsw stand for "No Unsigned Wrap"
and "No Signed Wrap", respectively. If the nuw and/or
nsw keywords are present, the result value of the mul
- is undefined if unsigned and/or signed overflow, respectively, occurs.
+ is a
trap value if unsigned and/or signed overflow,
+ respectively, occurs.
Example:
@@ -3212,11 +3492,11 @@ Instruction
+
Syntax:
@@ -3242,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:
@@ -3268,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
@@ -3276,10 +3563,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3307,8 +3595,8 @@ Instruction
a 32-bit division of -2147483648 by -1.
If the exact keyword is present, the result value of the
- sdiv is undefined if the result would be rounded or if overflow
- would occur.
+
sdiv is a
trap value if the result would
+ be rounded.
Example:
@@ -3318,10 +3606,11 @@ Instruction
+
Syntax:
@@ -3347,10 +3636,11 @@ Instruction
+
Syntax:
@@ -3384,11 +3674,11 @@ Instruction
+
Syntax:
@@ -3408,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
@@ -3434,10 +3725,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3464,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
@@ -3476,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:
@@ -3506,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
@@ -3518,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:
@@ -3545,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
@@ -3558,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:
@@ -3585,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
@@ -3598,10 +3917,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3658,9 +3978,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3719,10 +4041,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3782,12 +4105,14 @@ Instruction
+
+
-
+
-
+
LLVM supports several instructions to represent vector operations in a
target-independent manner. These instructions cover the element-access and
@@ -3796,14 +4121,12 @@ Instruction
will want to use target-specific intrinsics to take full advantage of a
specific target.
-
-
-
+
-
+
Syntax:
@@ -3835,11 +4158,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3871,11 +4194,11 @@ Instruction
-
+
-
+
Syntax:
@@ -3918,24 +4241,24 @@ Instruction
+
+
-
+
-
+
LLVM supports several instructions for working with
aggregate values.
-
-
-
+
-
+
Syntax:
@@ -3948,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
@@ -3965,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:
@@ -3982,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.
@@ -3997,37 +4328,37 @@ 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:
- <result> = alloca <type>[, i32 <NumElements>][, align <alignment>] ; yields {type*}:result
+ <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>] ; yields {type*}:result
Overview:
@@ -4070,16 +4401,17 @@ Instruction
-
+
-
+
Syntax:
- <result> = load <ty>* <pointer>[, align <alignment>][, !nontemporal !]
- <result> = volatile load <ty>* <pointer>[, align <alignment>][, !nontemporal !]
- ! = !{ i32 1 }
+ <result> = load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
+ <result> = volatile load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
+ !<index> = !{ i32 1 }
Overview:
@@ -4090,25 +4422,24 @@ Instruction
from which to load. The pointer must point to
a
first class type. If the
load is
marked as
volatile, then the optimizer is not allowed to modify the
- number or order of execution of this
load with other
- volatile
load and
store
- instructions.
+ number or order of execution of this
load with other
volatile operations.
-
The optional constant "align" argument specifies the alignment of the
+
The optional constant align argument specifies the alignment of the
operation (that is, the alignment of the memory address). A value of 0 or an
- omitted "align" argument means that the operation has the preferential
+ omitted align argument means that the operation has the preferential
alignment for the target. It is the responsibility of the code emitter to
ensure that the alignment information is correct. Overestimating the
- alignment results in an undefined behavior. Underestimating the alignment may
+ alignment results in undefined behavior. Underestimating the alignment may
produce less efficient code. An alignment of 1 is always safe.
-
The optional !nontemporal metadata must reference a single metatadata
- name corresponding to a metadata node with one i32 entry of
- value 1. The existance of the !nontemporal metatadata on the
- instruction tells the optimizer and code generator that this load is
- not expected to be reused in the cache. The code generator may
- select special instructions to save cache bandwidth, such as the
- MOVNT intruction on x86.
+
The optional !nontemporal metadata must reference a single
+ metatadata name <index> corresponding to a metadata node with
+ one i32 entry of value 1. The existence of
+ the !nontemporal metatadata on the instruction tells the optimizer
+ and code generator that this load is not expected to be reused in the cache.
+ The code generator may select special instructions to save cache bandwidth,
+ such as the MOVNT instruction on x86.
Semantics:
The location of memory pointed to is loaded. If the value being loaded is of
@@ -4129,15 +4460,16 @@ Instruction
-
+
-
+
Syntax:
- store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !] ; yields {void}
- volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !] ; yields {void}
+ store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] ; yields {void}
+ volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] ; yields {void}
Overview:
@@ -4148,11 +4480,10 @@ Instruction
and an address at which to store it. The type of the
'
<pointer>' operand must be a pointer to
the
first class type of the
- '
<value>' operand. If the
store is marked
- as
volatile, then the optimizer is not allowed to modify the number
- or order of execution of this
store with other
- volatile
load and
store
- instructions.
+ '
<value>' operand. If the
store is marked as
+
volatile, then the optimizer is not allowed to modify the number or
+ order of execution of this
store with other
volatile operations.
The optional constant "align" argument specifies the alignment of the
operation (that is, the alignment of the memory address). A value of 0 or an
@@ -4163,12 +4494,12 @@ Instruction
produce less efficient code. An alignment of 1 is always safe.
The optional !nontemporal metadata must reference a single metatadata
- name corresponding to a metadata node with one i32 entry of
- value 1. The existance of the !nontemporal metatadata on the
+ name <index> corresponding to a metadata node with one i32 entry of
+ value 1. The existence of the !nontemporal metatadata on the
instruction tells the optimizer and code generator that this load is
not expected to be reused in the cache. The code generator may
select special instructions to save cache bandwidth, such as the
- MOVNT intruction on x86.
+ MOVNT instruction on x86.
Semantics:
@@ -4191,11 +4522,11 @@ Instruction
-
+
-
+
Syntax:
@@ -4217,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.
@@ -4230,8 +4561,7 @@ Instruction
For example, let's consider a C code fragment and how it gets compiled to
LLVM:
-
-
+
struct RT {
char A;
int B[10][20];
@@ -4247,12 +4577,10 @@ int *foo(struct ST *s) {
return &s[1].Z.B[5][13];
}
-
The LLVM code generated by the GCC frontend is:
-
-
+
%RT = type { i8 , [10 x [20 x i32]], i8 }
%ST = type { i32, double, %RT }
@@ -4262,7 +4590,6 @@ entry:
ret i32* %reg
}
-
Semantics:
In the example above, the first index is indexing into the '%ST*'
@@ -4291,13 +4618,14 @@ entry:
If the inbounds keyword is present, the result value of the
- getelementptr is undefined if the base pointer is not an
- in bounds address of an allocated object, or if any of the addresses
- that would be formed by successive addition of the offsets implied by the
- indices to the base address with infinitely precise arithmetic are not an
- in bounds address of that allocated object.
- The in bounds addresses for an allocated object are all the addresses
- that point into the object, plus the address one byte past the end.
+
getelementptr is a
trap value if the
+ base pointer is not an
in bounds address of an allocated object,
+ or if any of the addresses that would be formed by successive addition of
+ the offsets implied by the indices to the base address with infinitely
+ precise arithmetic are not an
in bounds address of that allocated
+ object. The
in bounds addresses for an allocated object are all
+ the addresses that point into the object, plus the address one byte past
+ the end.
If the inbounds keyword is not present, the offsets are added to
the base address with silently-wrapping two's complement arithmetic, and
@@ -4324,23 +4652,25 @@ entry: