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.
@@ -937,7 +938,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.
@@ -1146,6 +1147,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.
+ + + @@ -1491,6 +1514,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
Note that program order does not introduce happens-before edges @@ -1519,14 +1546,19 @@ any write to the same byte, except:
write2, and write2 happens before Rbyte, then Rbyte does not see write1. -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.)
+ Note that in cases where none of the atomic intrinsics are used, this model places only one restriction on IR transformations on top of what is required for single-threaded execution: introducing a store to a byte which might not -otherwise be stored to can introduce undefined behavior. (Specifically, in -the case where another thread might write to and read from an address, -introducing a store can change a load that may see exactly one write into -a load that may see multiple writes.)
+otherwise be stored is not allowed in general. (Specifically, in the case +where another thread might write to and read from an address, introducing a +store can change a load that may see exactly one write into a load that may +see multiple writes.) +Atomic instructions (cmpxchg,
+atomicrmw,
+fence,
+atomic load, and
+atomic store) take an ordering parameter
+that determines which other atomic instructions on the same address they
+synchronize with. These semantics are borrowed from Java and C++0x,
+but are somewhat more colloquial. If these descriptions aren't precise enough,
+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.
+ +unorderedmonotonicunordered, there is a single
+total order for modifications by monotonic operations on each
+address. All modification orders must be compatible with the happens-before
+order. There is no guarantee that the modification orders can be combined to
+a global total order for the whole program (and this often will not be
+possible). The read in an atomic read-modify-write operation
+(cmpxchg and
+atomicrmw)
+reads the value in the modification order immediately before the value it
+writes. If one atomic read happens before another atomic read of the same
+address, the later read must see the same value or a later value in the
+address's modification order. This disallows reordering of
+monotonic (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 corresponds to the C++0x/C1x
+memory_order_relaxed.acquiremonotonic,
+a synchronizes-with edge may be formed with a 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.
+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
+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 corresponds
+to the C++0x/C1x memory_order_seq_cst and Java volatile.If an atomic operation is marked singlethread,
+it only synchronizes with or participates in modification and seq_cst
+total orderings with other operations running in the same thread (for example,
+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 @@ -2391,22 +2514,21 @@ b: unreachable
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.
+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 @@ -2733,23 +2854,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 @@ -2758,7 +2883,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:@@ -2802,7 +2940,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:@@ -2810,6 +2949,281 @@ 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).
+ +fpaccuracy metadata may be attached to any instruction of floating + point type. It expresses the maximum relative error of the result of + that instruction, in ULPs. 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 maximum relative error may be any rational number. The metadata node + shall consist of a pair of unsigned integers respectively representing + the numerator and denominator. For example, 2.5 ULP:
+ +
+!0 = metadata !{ i32 5, i32 2 }
+
+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. @@ -2871,13 +3288,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.
There are seven different terminator instructions: the - 'ret' instruction, the - 'br' instruction, the - 'switch' instruction, the - ''indirectbr' Instruction, the - 'invoke' instruction, the - 'unwind' instruction, and the - 'unreachable' instruction.
+The terminator instructions are: + 'ret', + 'br', + 'switch', + 'indirectbr', + 'invoke', + 'resume', and + 'unreachable'.
- br i1 <cond>, label <iftrue>, label <iffalse>
br label <dest> ; Unconditional branch + br i1 <cond>, label <iftrue>, label <iffalse> + br label <dest> ; Unconditional branch
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 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 + within the "landingpad" instruction can't be lost through normal + code motion.
This instruction requires several arguments:
@@ -3198,8 +3639,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 @@ -3235,35 +3674,37 @@ that the invoke/unwind semantics are likely to change in future versions. - - + +- 'unwind' Instruction + 'resume' Instruction
@@ -3343,7 +3784,7 @@ that the invoke/unwind semantics are likely to change in future versions.Syntax:
- unwind + resume <type> <value>Overview:
-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 'resume' instruction is a terminator instruction that has no + successors.
+ +Arguments:
+The 'resume' instruction requires one argument, which must have the + same type as the result of any 'landingpad' instruction in the same + function.
Semantics:
-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.
+The 'resume' instruction resumes propagation of an existing + (in-flight) exception whose unwinding was interrupted with + a landingpad instruction.
-Note that the code generator does not yet completely support unwind, and -that the invoke/unwind semantics are likely to change in future versions.
+Example:
++ resume { i8*, i32 } %exn +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.
Example:
@@ -3424,7 +3865,7 @@ 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 sub - is a trap value if unsigned and/or signed overflow, + is a poison value if unsigned and/or signed overflow, respectively, occurs.
Example:
@@ -3511,7 +3952,7 @@ 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 mul - is a trap value if unsigned and/or signed overflow, + is a poison value if unsigned and/or signed overflow, respectively, occurs.
Example:
@@ -3581,7 +4022,7 @@ that the invoke/unwind semantics are likely to change in future versions.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").
@@ -3625,7 +4066,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.
Example:
@@ -3834,9 +4275,9 @@ that the invoke/unwind semantics are likely to change in future versions. 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 + 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)).
@@ -3883,7 +4324,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.
@@ -3931,7 +4372,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.
Example:
@@ -3973,9 +4414,9 @@ that the invoke/unwind semantics are likely to change in future versions.
| In0 | -In1 | -Out | +In0 | +In1 | +Out | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | @@ -4034,9 +4475,9 @@ that the invoke/unwind semantics are likely to change in future versions.
| In0 | -In1 | -Out | +In0 | +In1 | +Out | ||
|---|---|---|---|---|---|---|---|
| 0 | @@ -4098,9 +4539,9 @@ that the invoke/unwind semantics are likely to change in future versions.
| In0 | -In1 | -Out | +In0 | +In1 | +Out |
|---|---|---|---|---|---|
| 0 | @@ -4334,7 +4775,7 @@ that the invoke/unwind semantics are likely to change in future versions.