LLVM programs are composed of "Module"s, each of which is a translation unit - of the input programs. Each module consists of functions, global variables, - and symbol table entries. Modules may be combined together with the LLVM - linker, which merges function (and global variable) definitions, resolves - forward declarations, and merges symbol table entries. Here is an example of - the "hello world" module:
+LLVM programs are composed of Modules, each of which is a + translation unit of the input programs. Each module consists of functions, + global variables, and symbol table entries. Modules may be combined together + with the LLVM linker, which merges function (and global variable) + definitions, resolves forward declarations, and merges symbol table + entries. Here is an example of the "hello world" module:
; Declare the string constant as a global constant. -@.LC0 = internal constant [13 x i8] c"hello world\0A\00" ; [13 x i8]* +@.str = private unnamed_addr constant [13 x i8] c"hello world\0A\00" ; External declaration of the puts function -declare i32 @puts(i8*) ; i32 (i8*)* +declare i32 @puts(i8* nocapture) nounwind ; Definition of main function define i32 @main() { ; i32()* ; Convert [13 x i8]* to i8 *... - %cast210 = getelementptr [13 x i8]* @.LC0, i64 0, i64 0 ; i8* + %cast210 = getelementptr [13 x i8]* @.str, i64 0, i64 0 ; Call puts function to write out the string to stdout. - call i32 @puts(i8* %cast210) ; i32 + call i32 @puts(i8* %cast210) ret i32 0 } ; Named metadata -!1 = metadata !{i32 41} +!1 = metadata !{i32 42} !foo = !{!1, null}
This example is made up of a global variable named - ".LC0", an external declaration of the "puts" function, + ".str", an external declaration of the "puts" function, a function definition for "main" and named metadata - "foo".
+ "foo". -In general, a module is made up of a list of global values, where both - functions and global variables are global values. Global values are +
In general, a module is made up of a list of global values (where both + functions and global variables are global values). Global values are represented by a pointer to a memory location (in this case, a pointer to an array of char, and a pointer to a function), and have one of the following linkage types.
@@ -646,7 +644,7 @@ define i32 @main() { ; i32()* be merged with equivalent globals. These linkage types are otherwise the same as their non-odr versions. -It is illegal for a function declaration to have any linkage type - other than "externally visible", dllimport - or extern_weak.
+ other than external, dllimport + or extern_weak.Aliases can have only external, internal, weak or weak_odr linkages.
@@ -943,7 +941,7 @@ define i32 @main() { ; i32()* alignments must be a power of 2.If the unnamed_addr attribute is given, the address is know to not - be significant and two identical functions can be merged
. + be significant and two identical functions can be merged.
@@ -1152,6 +1150,10 @@ define void @f() optsize { ... }
setjmp is an example of such a function. The compiler
+ disables some optimizations (like tail calls) in the caller of these
+ functions.The function of the data layout string may not be what you expect. Notably, + this is not a specification from the frontend of what alignment the code + generator should use.
+ +Instead, if specified, the target data layout is required to match what the + ultimate code generator expects. This string is used by the + mid-level optimizers to + improve code, and this only works if it matches what the ultimate code + generator uses. If you would like to generate IR that does not embed this + target-specific detail into the IR, then you don't have to specify the + string. This will disable some optimizations that require precise layout + information, but this also prevents those optimizations from introducing + target specificity into the IR.
+ + + @@ -1497,6 +1517,9 @@ or to register signal handlers. Nonetheless, there are platform-specific ways to create them, and we define LLVM IR's behavior in their presence. This model is inspired by the C++0x memory model. +For a more informal introduction to this model, see the +LLVM Atomic Instructions and Concurrency Guide. +
We define a happens-before partial order as the least partial order that
Given that definition, Rbyte is defined as follows:
sig_atomic_t in C/C++, and may be used for accesses to
+ addresses which do not behave like normal memory. It does not generally
+ provide cross-thread synchronization.)
+ fence instructions
+check those specs (see spec references in the
+atomics guide).
+fence instructions
treat these orderings somewhat differently since they don't take an address.
See that instruction's documentation for details.
+For a simpler introduction to the ordering constraints, see the +LLVM Atomic Instructions and Concurrency Guide.
+unorderedmonotonic (or stronger) operations on the same address. If an
address is written monotonically by one thread, and other threads
monotonically read that address repeatedly, the other threads must
-eventually see the write. This is intended to model C++'s relaxed atomic
-variables.memory_order_relaxed.acquiremonotonic, if this operation
-reads a value written by a release atomic operation, it
-synchronizes-with that operation.releasemonotonic,
-a synchronizes-with edge may be formed by an acquire
-operation.release
+operation. This is intended to model C++'s memory_order_acquire.
+releasemonotonic, if this operation
+writes a value which is subsequently read by an acquire operation,
+it synchronizes-with that operation. (This isn't a complete
+description; see the C++0x definition of a release sequence.) This corresponds
+to the C++0x/C1x memory_order_release.acq_rel (acquire+release)acquire and release operation on its address.acquire and release operation on its address.
+This corresponds to the C++0x/C1x memory_order_acq_rel.
seq_cst (sequentially consistent)acq_rel
(acquire for an operation which only reads, release
@@ -1637,9 +1673,8 @@ for an operation which only writes), there is a global total order on all
sequentially-consistent operations on all addresses, which is consistent with
the happens-before partial order and with the modification orders of
all the affected addresses. Each sequentially-consistent read sees the last
-preceding write to the same address in this global order. This is intended
-to model C++'s sequentially-consistent atomic variables and Java's volatile
-shared variables.memory_order_seq_cst and Java volatile.If an atomic operation is marked singlethread,
@@ -1683,7 +1718,7 @@ in signal handlers).
| Type | Description | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| half | 16-bit floating point value | |||||||||||||
| float | 32-bit floating point value | |||||||||||||
| double | 64-bit floating point value | |||||||||||||
| fp128 | 128-bit floating point value (112-bit mantissa) |
| <2 x i64> | Vector of 2 64-bit integer values. | +
| <4 x i64*> | +Vector of 4 pointers to 64-bit integer values. | +
When using the hexadecimal form, constants of types float and double are +
When using the hexadecimal form, constants of types half, 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 + representation for double); half and float values must, however, be exactly + representable as IEE754 half and single precision, respectively. + 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).
+ they match the long double format on your target. The IEEE 16-bit format + (half precision) is represented by 0xH followed by 4 hexadecimal + digits. All hexadecimal formats are big-endian (sign bit at the left).There are no constants of type x86mmx.
@@ -2477,22 +2518,21 @@ b: unreachableTrap 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.
+Poison values are similar to undef values, however + they also 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 +
There is currently no way of representing a poison 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:
+Poison value behavior is defined in terms of value dependence:
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.
+Poison Values have the same behavior as undef values, + with the additional affect that any instruction which has a dependence + on a poison value has undefined behavior.
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 + %poison = sub nuw i32 0, 1 ; Results in a poison value. + %still_poison = and i32 %poison, 0 ; 0, but also poison. + %poison_yet_again = getelementptr i32* @h, i32 %still_poison + store i32 0, i32* %poison_yet_again ; memory at @h[0] is poisoned - store i32 %trap, i32* @g ; Trap value conceptually stored to memory. - %trap2 = load i32* @g ; Returns a trap value, not just undef. + store i32 %poison, i32* @g ; Poison value stored to memory. + %poison2 = load i32* @g ; Poison value loaded back from memory. - volatile store i32 %trap, i32* @g ; External observation; undefined behavior. + store volatile i32 %poison, 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. + %poison3 = load i16* %narrowaddr ; Returns a poison value. + %poison4 = load i64* %wideaddr ; Returns a poison value. - %cmp = icmp slt i32 %trap, 0 ; Returns a trap value. - br i1 %cmp, label %true, label %end ; Branch to either destination. + %cmp = icmp slt i32 %poison, 0 ; Returns a poison 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. + store volatile 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. + ; Both edges into this PHI are + ; control-dependent on %cmp, so this + ; always results in a poison 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. + store volatile 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. + ; 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). + store volatile 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 (ignoring earlier undefined + ; behavior in this example).
LLVM supports inline assembler expressions (as opposed - to Module-Level Inline Assembly) through the use of + to Module-Level Inline Assembly) through the use of a special value. This value represents the inline assembler as a string (containing the instructions to emit), a list of operand constraints (stored as a string), a flag that indicates whether or not the inline asm @@ -2819,23 +2858,27 @@ call void asm alignstack "eieio", ""()
If both keywords appear the 'sideeffect' keyword must come first.
+ +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:
+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 @@ -2844,7 +2887,7 @@ 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. If the MDNode contains multiple constants, the code generator will use + 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.
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"".
+ 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 preceded by an - exclamation point). For example: "!{ metadata !"test\00", i32 - 10}". Metadata nodes can have any values as their operand.
+ exclamation point). Metadata nodes can have any values as their operand. For + example: + +
+!{ metadata !"test\00", i32 10}
+
+A named metadata is a collection of metadata nodes, which can be looked up in the module symbol table. For - example: "!foo = metadata !{!4, !3}". + example:
+ +
+!foo = metadata !{!4, !3}
+
+Metadata can be used as function arguments. Here llvm.dbg.value - function is using two metadata arguments.
+ function is using two metadata arguments:@@ -2888,7 +2944,8 @@ 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.
+ attached to the add instruction using the !dbg + identifier:@@ -2896,6 +2953,324 @@ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)
More information about specific metadata nodes recognized by the optimizers + and code generator is found below.
+ + +In LLVM IR, memory does not have types, so LLVM's own type system is not + suitable for doing TBAA. Instead, metadata is added to the IR to describe + a type system of a higher level language. This can be used to implement + typical C/C++ TBAA, but it can also be used to implement custom alias + analysis behavior for other languages.
+ +The current metadata format is very simple. TBAA metadata nodes have up to + three fields, e.g.:
+ +
+!0 = metadata !{ metadata !"an example type tree" }
+!1 = metadata !{ metadata !"int", metadata !0 }
+!2 = metadata !{ metadata !"float", metadata !0 }
+!3 = metadata !{ metadata !"const float", metadata !2, i64 1 }
+
+The first field is an identity field. It can be any value, usually + a metadata string, which uniquely identifies the type. The most important + name in the tree is the name of the root node. Two trees with + different root node names are entirely disjoint, even if they + have leaves with common names.
+ +The second field identifies the type's parent node in the tree, or + is null or omitted for a root node. A type is considered to alias + all of its descendants and all of its ancestors in the tree. Also, + a type is considered to alias all types in other trees, so that + bitcode produced from multiple front-ends is handled conservatively.
+ +If the third field is present, it's an integer which if equal to 1 + indicates that the type is "constant" (meaning + pointsToConstantMemory should return true; see + other useful + AliasAnalysis methods).
+ +fpmath metadata may be attached to any instruction of floating point + type. It can be used to express the maximum acceptable error in the result of + that instruction, in ULPs, thus potentially allowing the compiler to use a + more efficient but less accurate method of computing it. ULP is defined as + follows:
+ ++ ++ +If x is a real number that lies between two finite consecutive + floating-point numbers a and b, without being equal to one + of them, then ulp(x) = |b - a|, otherwise ulp(x) is the + distance between the two non-equal finite floating-point numbers nearest + x. Moreover, ulp(NaN) is NaN.
+ +
The metadata node shall consist of a single positive floating point number + representing the maximum relative error, for example:
+ +
+!0 = metadata !{ float 2.5 } ; maximum acceptable inaccuracy is 2.5 ULPs
+
+range metadata may be attached only to loads of integer types. It + expresses the possible ranges the loaded value is in. The ranges are + represented with a flattened list of integers. The loaded value is known to + be in the union of the ranges defined by each consecutive pair. Each pair + has the following properties:
+Examples:
+
+ %a = load i8* %x, align 1, !range !0 ; Can only be 0 or 1
+ %b = load i8* %y, align 1, !range !1 ; Can only be 255 (-1), 0 or 1
+ %c = load i8* %z, align 1, !range !2 ; Can only be 0, 1, 3, 4 or 5
+...
+!0 = metadata !{ i8 0, i8 2 }
+!1 = metadata !{ i8 255, i8 2 }
+!2 = metadata !{ i8 0, i8 2, i8 3, i8 6 }
+
+Information about the module as a whole is difficult to convey to LLVM's + subsystems. The LLVM IR isn't sufficient to transmit this + information. The llvm.module.flags named metadata exists in order to + facilitate this. These flags are in the form of key / value pairs — + much like a dictionary — making it easy for any subsystem who cares + about a flag to look it up.
+ +The llvm.module.flags metadata contains a list of metadata + triplets. Each triplet has the following form:
+ +When two (or more) modules are merged together, the resulting + llvm.module.flags metadata is the union of the + modules' llvm.module.flags metadata. The only exception being a flag + with the Override behavior, which may override another flag's value + (see below).
+ +The following behaviors are supported:
+ +| Value | +Behavior | +
|---|---|
| 1 | +
+
|
+
| 2 | +
+
|
+
| 3 | +
+
|
+
| 4 | +
+
|
+
An example of module flags:
+ +
+!0 = metadata !{ i32 1, metadata !"foo", i32 1 }
+!1 = metadata !{ i32 4, metadata !"bar", i32 37 }
+!2 = metadata !{ i32 2, metadata !"qux", i32 42 }
+!3 = metadata !{ i32 3, metadata !"qux",
+ metadata !{
+ metadata !"foo", i32 1
+ }
+}
+!llvm.module.flags = !{ !0, !1, !2, !3 }
+
+
+Metadata !0 has the ID !"foo" and the value '1'. The + behavior if two or more !"foo" flags are seen is to emit an + error if their values are not equal.
Metadata !1 has the ID !"bar" and the value '37'. The + behavior if two or more !"bar" flags are seen is to use the + value '37' if their values are not equal.
Metadata !2 has the ID !"qux" and the value '42'. The + behavior if two or more !"qux" flags are seen is to emit a + warning if their values are not equal.
Metadata !3 has the ID !"qux" and the value:
+ +
+metadata !{ metadata !"foo", i32 1 }
+
+
+ The behavior is to emit an error if the llvm.module.flags does + not contain a flag with the ID !"foo" that has the value + '1'. If two or more !"qux" flags exist, then they must have + the same value or an error will be issued.
On the Mach-O platform, Objective-C stores metadata about garbage collection + in a special section called "image info". The metadata consists of a version + number and a bitmask specifying what types of garbage collection are + supported (if any) by the file. If two or more modules are linked together + their garbage collection metadata needs to be merged rather than appended + together.
+ +The Objective-C garbage collection module flags metadata consists of the + following key-value pairs:
+ +| Key | +Value | +
|---|---|
| Objective-C Version | +[Required] — The Objective-C ABI + version. Valid values are 1 and 2. | +
| Objective-C Image Info Version | +[Required] — The version of the image info + section. Currently always 0. | +
| Objective-C Image Info Section | +[Required] — The section to place the + metadata. Valid values are "__OBJC, __image_info, regular" for + Objective-C ABI version 1, and "__DATA,__objc_imageinfo, regular, + no_dead_strip" for Objective-C ABI version 2. | +
| Objective-C Garbage Collection | +[Required] — Specifies whether garbage + collection is supported or not. Valid values are 0, for no garbage + collection, and 2, for garbage collection supported. | +
| Objective-C GC Only | +[Optional] — Specifies that only garbage + collection is supported. If present, its value must be 6. This flag + requires that the Objective-C Garbage Collection flag have the + value 2. | +
Some important flag interactions:
+ +- @X = global i8 4 - @Y = global i32 123 +@X = global i8 4 +@Y = global i32 123 - @llvm.used = appending global [2 x i8*] [ - i8* @X, - i8* bitcast (i32* @Y to i8*) - ], section "llvm.metadata" +@llvm.used = appending global [2 x i8*] [ + i8* @X, + i8* bitcast (i32* @Y to i8*) +], section "llvm.metadata"+
If a global variable appears in the @llvm.used list, then the -compiler, assembler, and linker are required to treat the symbol as if there is -a reference to the global that it cannot see. For example, if a variable has -internal linkage and no references other than that from the @llvm.used -list, it cannot be deleted. This is commonly used to represent references from -inline asms and other things the compiler cannot "see", and corresponds to -"attribute((used))" in GNU C.
+ compiler, assembler, and linker are required to treat the symbol as if there + is a reference to the global that it cannot see. For example, if a variable + has internal linkage and no references other than that from + the @llvm.used list, it cannot be deleted. This is commonly used to + represent references from inline asms and other things the compiler cannot + "see", and corresponds to "attribute((used))" in GNU C.On some targets, the code generator must emit a directive to the assembler or -object file to prevent the assembler and linker from molesting the symbol.
+ object file to prevent the assembler and linker from molesting the + symbol. @@ -2957,13 +3335,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 -touching the symbol. On targets that support it, this allows an intelligent -linker to optimize references to the symbol without being impeded as it would be -by @llvm.used.
+ @llvm.used directive, except that it only prevents the compiler from + touching the symbol. On targets that support it, this allows an intelligent + linker to optimize references to the symbol without being impeded as it would + be by @llvm.used.This is a rare construct that should only be used in rare circumstances, and -should not be exposed to source languages.
+ should not be exposed to source languages.
%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. -
+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 }]
+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. -
+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.
The 'exception' label is a landing pad for the exception. As such, 'exception' label is required to have the "landingpad" instruction, which contains - the information about about the behavior of the program after unwinding + the information about the behavior of the program after unwinding happens, as its first non-PHI instruction. The restrictions on the "landingpad" instruction's tightly couples it to the "invoke" instruction, so that the important information contained @@ -3297,8 +3686,9 @@ IfUnequal:
Note that the code generator does not yet completely support unwind, and -that the invoke/unwind semantics are likely to change in future versions.
-
%retval = invoke i32 @Test(i32 15) to label %Continue
@@ -3332,38 +3719,6 @@ that the invoke/unwind semantics are likely to change in future versions.
unwind label %TestCleanup ; {i32}:retval set
-
-
-
-
-- unwind -- -
The 'unwind' instruction unwinds the stack, continuing control flow - at the first callee in the dynamic call stack which used - an invoke instruction to perform the call. - This is primarily used to implement exception handling.
- -The 'unwind' instruction causes execution of the current function to - immediately halt. The dynamic call stack is then searched for the - first invoke instruction on the call stack. - Once found, execution continues at the "exceptional" destination block - specified by the invoke instruction. If there is no invoke - instruction in the dynamic call chain, undefined behavior results.
- -Note that the code generator does not yet completely support unwind, and -that the invoke/unwind semantics are likely to change in future versions.
-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 a trap value if unsigned and/or signed overflow, + is a poison value if unsigned and/or signed overflow, respectively, occurs.
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 a trap value if unsigned and/or signed overflow, + is a poison value if unsigned and/or signed overflow, respectively, occurs.
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 a trap value if unsigned and/or signed overflow, + is a poison value if unsigned and/or signed overflow, respectively, occurs.
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 + udiv is a poison value if %op1 is not a multiple of %op2 (as such, "((a udiv exact b) mul b) == a").
@@ -3758,7 +4113,7 @@ that the invoke/unwind semantics are likely to change in future versions. a 32-bit division of -2147483648 by -1.If the exact keyword is present, the result value of the - sdiv is a trap value if the result would + sdiv is a poison value if the result would be rounded.
If the nuw keyword is present, then the shift produces a - trap value if it shifts out any non-zero bits. If + poison 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 + poison 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)).
@@ -4016,7 +4371,7 @@ that the invoke/unwind semantics are likely to change in future versions. 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 + lshr is a poison value if any of the bits shifted out are non-zero.
@@ -4064,7 +4419,7 @@ that the invoke/unwind semantics are likely to change in future versions. 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 + ashr is a poison value if any of the bits shifted out are non-zero.
| In0 | -In1 | -Out | +In0 | +In1 | +Out | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | @@ -4167,9 +4522,9 @@ that the invoke/unwind semantics are likely to change in future versions.
| In0 | -In1 | -Out | +In0 | +In1 | +Out | ||
|---|---|---|---|---|---|---|---|
| 0 | @@ -4231,9 +4586,9 @@ that the invoke/unwind semantics are likely to change in future versions.
| In0 | -In1 | -Out | +In0 | +In1 | +Out |
|---|---|---|---|---|---|
| 0 | @@ -4550,8 +4905,12 @@ that the invoke/unwind semantics are likely to change in future versions. 'alloca' instruction is commonly used to represent automatic variables that must have an address available. When the function returns (either with the ret - or unwind instructions), the memory is - reclaimed. Allocating zero bytes is legal, but the result is undefined. + or resume instructions), the memory is + reclaimed. Allocating zero bytes is legal, but the result is undefined. + The order in which memory is allocated (ie., which way the stack grows) is + not specified. + +