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.
@@ -942,7 +934,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.
@@ -1161,14 +1153,6 @@ define void @f() optsize { ... }
function into callers whenever possible, ignoring any active inlining size
threshold for this caller.
- 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.
+ + + @@ -1496,6 +1508,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.)
+ 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, and
-fence) take an ordering parameter
+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. 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
@@ -1638,9 +1664,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,
@@ -1880,9 +1905,6 @@ in signal handlers).
Structures may optionally be "packed" structures, which indicate that the alignment of the struct is one byte, and that there is no padding between - the elements. In non-packed structs, padding between field types is defined - by the target data string to match the underlying processor.
- -Structures can either be "anonymous" or "named". An anonymous structure is - defined inline with other types (e.g. {i32, i32}*) and a named types - are always defined at the top level with a name. Anonmyous types are uniqued - by their contents and can never be recursive since there is no way to write - one. Named types can be recursive. + the elements. In non-packed structs, padding between field types is inserted + as defined by the TargetData string in the module, which is required to match + what the underlying code generator expects.
+ +Structures can either be "literal" or "identified". A literal structure is + defined inline with other types (e.g. {i32, i32}*) whereas identified + types are always defined at the top level with a name. Literal types are + uniqued by their contents and can never be recursive or opaque since there is + no way to write one. Identified types can be recursive, can be opaqued, and are + never uniqued.
- %T1 = type { <type list> } ; Named normal struct type
- %T2 = type <{ <type list> }> ; Named packed struct type
+ %T1 = type { <type list> } ; Identified normal struct type
+ %T2 = type <{ <type list> }> ; Identified packed struct type
The number of elements is a constant integer value larger than 0; elementtype - may be any integer or floating point type. Vectors of size zero are not - allowed, and pointers are not allowed as the element type.
+ may be any integer or floating point type, or a pointer to these types. + Vectors of size zero are not allowed.| <2 x i64> | Vector of 2 64-bit integer values. | +
| <4 x i64*> | +Vector of 4 pointers to 64-bit integer values. | +
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 @@ -2816,23 +2846,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 @@ -2841,7 +2875,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:@@ -2885,7 +2932,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:@@ -2893,6 +2941,87 @@ 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 }
+
+- @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. @@ -2954,13 +3086,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 eight different terminator instructions: the - 'ret' instruction, the - 'br' instruction, the - 'switch' instruction, the - ''indirectbr' Instruction, the - 'invoke' instruction, the - 'unwind' instruction, the - 'resume' instruction, and the - 'unreachable' instruction.
+The terminator instructions are: + 'ret', + 'br', + 'switch', + 'indirectbr', + 'invoke', + 'unwind', + 'resume', and + 'unreachable'.
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 + 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:
@@ -3370,17 +3525,18 @@ that the invoke/unwind semantics are likely to change in future versions. successors.The 'resume' instruction's argument must have the same type as the - result of any 'landingpad' instruction in the same function.
+The 'resume' instruction requires one argument, which must have the + same type as the result of any 'landingpad' instruction in the same + function.
The 'resume' instruction resumes propagation of an existing (in-flight) exception whose unwinding was interrupted with - a landingpad instruction.
+ a landingpad instruction.
- resume { i8*, i32 } %exn
+ resume { i8*, i32 } %exn
@@ -3461,7 +3617,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 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").
@@ -3743,7 +3899,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)).
@@ -4001,7 +4157,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.
@@ -4049,7 +4205,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.
- <result> = load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
- <result> = volatile load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
+ <result> = load [volatile] <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
+ <result> = load atomic [volatile] <ty>* <pointer> [singlethread] <ordering>, align <alignment>
!<index> = !{ i32 1 }
@@ -4573,6 +4729,19 @@ that the invoke/unwind semantics are likely to change in future versions.
number or order of execution of this load with other volatile operations.
+If the load is marked as atomic, it takes an extra
+ ordering and optional singlethread
+ argument. The release and acq_rel orderings are
+ not valid on load instructions. Atomic loads produce defined results when they may see multiple atomic
+ stores. The type of the pointee must be an integer type whose bit width
+ is a power of two greater than or equal to eight and less than or equal
+ to a target-specific size limit. align must be explicitly
+ specified on atomic loads, and the load has undefined behavior if the
+ alignment is not set to a value which is at least the size in bytes of
+ the pointee. !nontemporal does not have any defined semantics
+ for atomic loads.
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 @@ -4616,8 +4785,8 @@ that the invoke/unwind semantics are likely to change in future versions.
- store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] ; yields {void}
- volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] ; yields {void}
+ store [volatile] <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] ; yields {void}
+ store atomic [volatile] <ty> <value>, <ty>* <pointer> [singlethread] <ordering>, align <alignment> ; yields {void}
If the store is marked as atomic, it takes an extra
+ ordering and optional singlethread
+ argument. The acquire and acq_rel orderings aren't
+ valid on store instructions. Atomic loads produce defined results when they may see multiple atomic
+ stores. The type of the pointee must be an integer type whose bit width
+ is a power of two greater than or equal to eight and less than or equal
+ to a target-specific size limit. align must be explicitly
+ specified on atomic stores, and the store has undefined behavior if the
+ alignment is not set to a value which is at least the size in bytes of
+ the pointee. !nontemporal does not have any defined semantics
+ for atomic stores.
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 @@ -4670,10 +4852,11 @@ that the invoke/unwind semantics are likely to change in future versions.
- +@@ -4715,9 +4898,6 @@ operations and/or fences. specifies that the fence only synchronizes with other fences in the same thread. (This is useful for interacting with signal handlers.) -FIXME: This instruction is a work in progress; until it is finished, use - llvm.memory.barrier. -
Example:
fence acquire ; yields {void} @@ -4727,14 +4907,15 @@ thread. (This is useful for interacting with signal handlers.)
- [volatile] cmpxchg <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> ; yields {ty}
+ cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> ; yields {ty}
- [volatile] atomicrmw <operation> <ty>* <pointer>, <ty> <value> [singlethread] <ordering> ; yields {ty}
+ atomicrmw [volatile] <operation> <ty>* <pointer>, <ty> <value> [singlethread] <ordering> ; yields {ty}
<result> = getelementptr <pty>* <ptrval>{, <ty> <idx>}*
<result> = getelementptr inbounds <pty>* <ptrval>{, <ty> <idx>}*
+ <result> = getelementptr <ptr vector> ptrval, <vector index type> idx
The first argument is always a pointer, and forms the basis of the +
The first argument is always a pointer or a vector of pointers, + and forms the basis of the calculation. The remaining arguments are indices that indicate which of the elements of the aggregate object are indexed. The interpretation of each index is dependent on the type being indexed into. The first index always @@ -4913,7 +5097,7 @@ specified by the operation argument:
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. + constant. These integers are treated as signed values where relevant.For example, let's consider a C code fragment and how it gets compiled to LLVM:
@@ -4975,22 +5159,26 @@ entry:If the inbounds keyword is present, the result value of the - getelementptr is a trap value if the + getelementptr is a poison 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.
+ precise signed 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. + In cases where the base is a vector of pointers the inbounds keyword + applies to each of the computations element-wise.If the inbounds keyword is not present, the offsets are added to - the base address with silently-wrapping two's complement arithmetic, and - the result value of the getelementptr may be outside the object - pointed to by the base pointer. The result value may not necessarily be - used to access memory though, even if it happens to point into allocated - storage. See the Pointer Aliasing Rules - section for more information.
+ the base address with silently-wrapping two's complement arithmetic. If the + offsets have a different width from the pointer, they are sign-extended or + truncated to the width of the pointer. The result value of the + getelementptr may be outside the object pointed to by the base + pointer. The result value may not necessarily be used to access memory + though, even if it happens to point into allocated storage. See the + Pointer Aliasing Rules section for more + information.The getelementptr instruction is often confusing. For some more insight into how it works, see the getelementptr FAQ.
@@ -5007,6 +5195,13 @@ entry: %iptr = getelementptr [10 x i32]* @arr, i16 0, i16 0 +In cases where the pointer argument is a vector of pointers, only a + single index may be used, and the number of vector elements has to be + the same. For example:
++ %A = getelementptr <4 x i8*> %ptrs, <4 x i64> %offsets, ++
The 'ptrtoint' instruction converts the pointer value to - the integer type ty2.
+The 'ptrtoint' instruction converts the pointer or a vector of + pointers value to + the integer (or vector of integers) type ty2.
The 'ptrtoint' instruction takes a value to cast, which - must be a pointer value, and a type to cast it to - ty2, which must be an integer type.
+ must be a a value of type pointer or a vector of + pointers, and a type to cast it to + ty2, which must be an integer or a vector + of integers type.The 'ptrtoint' instruction converts value to integer type @@ -5398,8 +5596,9 @@ entry:
- %X = ptrtoint i32* %X to i8 ; yields truncation on 32-bit architecture - %Y = ptrtoint i32* %x to i64 ; yields zero extension on 32-bit architecture + %X = ptrtoint i32* %P to i8 ; yields truncation on 32-bit architecture + %Y = ptrtoint i32* %P to i64 ; yields zero extension on 32-bit architecture + %Z = ptrtoint <4 x i32*> %P to <4 x i64>; yields vector zero extension for a vector of addresses on 32-bit architecture
The 'bitcast' instruction converts value to type ty2. It is always a no-op cast because no bits change with this conversion. The conversion is done as if the value had been - stored to memory and read back as type ty2. Pointer types may only - be converted to other pointer types with this instruction. To convert + stored to memory and read back as type ty2. + Pointer (or vector of pointers) types may only be converted to other pointer + (or vector of pointers) types with this instruction. To convert pointers to other types, use the inttoptr or ptrtoint instructions first.
@@ -5481,7 +5682,8 @@ entry:%X = bitcast i8 255 to i8 ; yields i8 :-1 %Y = bitcast i32* %x to sint* ; yields sint*:%x - %Z = bitcast <2 x int> %V to i64; ; yields i64: %V + %Z = bitcast <2 x int> %V to i64; ; yields i64: %V + %Z = bitcast <2 x i32*> %V to <2 x i64*> ; yields <2 x i64*>@@ -5512,8 +5714,8 @@ entry:
The 'icmp' instruction returns a boolean value or a vector of - boolean values based on comparison of its two integer, integer vector, or - pointer operands.
+ boolean values based on comparison of its two integer, integer vector, + pointer, or pointer vector operands.The 'icmp' instruction takes three operands. The first operand is @@ -5968,6 +6170,87 @@ freestanding environments and non-C-based languages.
+ ++ <resultval> = landingpad <somety> personality <type> <pers_fn> <clause>+ + <resultval> = landingpad <somety> personality <type> <pers_fn> cleanup <clause>* + + <clause> := catch <type> <value> + <clause> := filter <array constant type> <array constant> ++ +
The 'landingpad' instruction is used by + LLVM's exception handling + system to specify that a basic block is a landing pad — one where + the exception lands, and corresponds to the code found in the + catch portion of a try/catch sequence. It + defines values supplied by the personality function (pers_fn) upon + re-entry to the function. The resultval has the + type somety.
+ +This instruction takes a pers_fn value. This is the personality + function associated with the unwinding mechanism. The optional + cleanup flag indicates that the landing pad block is a cleanup.
+ +A clause begins with the clause type — catch + or filter — and contains the global variable representing the + "type" that may be caught or filtered respectively. Unlike the + catch clause, the filter clause takes an array constant as + its argument. Use "[0 x i8**] undef" for a filter which cannot + throw. The 'landingpad' instruction must contain at least + one clause or the cleanup flag.
+ +The 'landingpad' instruction defines the values which are set by the + personality function (pers_fn) upon re-entry to the function, and + therefore the "result type" of the landingpad instruction. As with + calling conventions, how the personality function results are represented in + LLVM IR is target specific.
+ +The clauses are applied in order from top to bottom. If two + landingpad instructions are merged together through inlining, the + clauses from the calling function are appended to the list of clauses.
+ +The landingpad instruction has several restrictions:
+ +
+ ;; A landing pad which can catch an integer.
+ %res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0
+ catch i8** @_ZTIi
+ ;; A landing pad that is a cleanup.
+ %res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0
+ cleanup
+ ;; A landing pad which can catch an integer and can only throw a double.
+ %res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0
+ catch i8** @_ZTIi
+ filter [1 x i8**] [@_ZTId]
+
+
+This function returns the same values as the libm log functions would, and handles error conditions in the same way.
+ + +This intrinsic makes it possible to excise one parameter, marked with +
These intrinsics make it possible to excise one parameter, marked with the nest attribute, from a function. The result is a callable function pointer lacking the nest parameter - the caller does not need to @@ -7561,7 +7847,8 @@ LLVM.
%tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86 %tramp1 = getelementptr [10 x i8]* %tramp, i32 0, i32 0 - %p = call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8* nest , i32, i32)* @f to i8*), i8* %nval) + call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8*, i32, i32)* @f to i8*), i8* %nval) + %p = call i8* @llvm.adjust.trampoline(i8* %tramp1) %fp = bitcast i8* %p to i32 (i32, i32)*@@ -7579,12 +7866,12 @@ LLVM.
- declare i8* @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <nval>) + declare void @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <nval>)
This fills the memory pointed to by tramp with code and returns a - function pointer suitable for executing it.
+This fills the memory pointed to by tramp with executable code, + turning it into a trampoline.
The llvm.init.trampoline intrinsic takes three arguments, all @@ -7598,514 +7885,50 @@ LLVM.
The block of memory pointed to by tramp is filled with target - dependent code, turning it into a function. A pointer to this function is - returned, but needs to be bitcast to an appropriate - function pointer type before being called. The new function's signature - is the same as that of func with any arguments marked with - the nest attribute removed. At most one such nest argument - is allowed, and it must be of pointer type. Calling the new function is - equivalent to calling func with the same argument list, but - with nval used for the missing nest argument. If, after - calling llvm.init.trampoline, the memory pointed to - by tramp is modified, then the effect of any later call to the - returned function pointer is undefined.
- -These intrinsic functions expand the "universal IR" of LLVM to represent - hardware constructs for atomic operations and memory synchronization. This - provides an interface to the hardware, not an interface to the programmer. It - is aimed at a low enough level to allow any programming models or APIs - (Application Programming Interfaces) which need atomic behaviors to map - cleanly onto it. It is also modeled primarily on hardware behavior. Just as - hardware provides a "universal IR" for source languages, it also provides a - starting point for developing a "universal" atomic operation and - synchronization IR.
- -These do not form an API such as high-level threading libraries, - software transaction memory systems, atomic primitives, and intrinsic - functions as found in BSD, GNU libc, atomic_ops, APR, and other system and - application libraries. The hardware interface provided by LLVM should allow - a clean implementation of all of these APIs and parallel programming models. - No one model or paradigm should be selected above others unless the hardware - itself ubiquitously does so.
- - -- declare void @llvm.memory.barrier(i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device>) -- -
The llvm.memory.barrier intrinsic guarantees ordering between - specific pairs of memory access types.
- -The llvm.memory.barrier intrinsic requires five boolean arguments. - The first four arguments enables a specific barrier as listed below. The - fifth argument specifies that the barrier applies to io or device or uncached - memory.
- -This intrinsic causes the system to enforce some ordering constraints upon - the loads and stores of the program. This barrier does not - indicate when any events will occur, it only enforces - an order in which they occur. For any of the specified pairs of load - and store operations (f.ex. load-load, or store-load), all of the first - operations preceding the barrier will complete before any of the second - operations succeeding the barrier begin. Specifically the semantics for each - pairing is as follows:
- -These semantics are applied with a logical "and" behavior when more than one - is enabled in a single memory barrier intrinsic.
- -Backends may implement stronger barriers than those requested when they do - not support as fine grained a barrier as requested. Some architectures do - not need all types of barriers and on such architectures, these become - noops.
- -
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-
-%result1 = load i32* %ptr ; yields {i32}:result1 = 4
- call void @llvm.memory.barrier(i1 false, i1 true, i1 false, i1 false, i1 true)
- ; guarantee the above finishes
- store i32 8, %ptr ; before this begins
-
-
+ dependent code, turning it into a function. Then tramp needs to be
+ passed to llvm.adjust.trampoline to get a pointer
+ which can be bitcast (to a new function) and
+ called. The new function's signature is the same as that of
+ func with any arguments marked with the nest attribute
+ removed. At most one such nest argument is allowed, and it must be of
+ pointer type. Calling the new function is equivalent to calling func
+ with the same argument list, but with nval used for the missing
+ nest argument. If, after calling llvm.init.trampoline, the
+ memory pointed to by tramp is modified, then the effect of any later call
+ to the returned function pointer is undefined.
This is an overloaded intrinsic. You can use llvm.atomic.cmp.swap on - any integer bit width and for different address spaces. Not all targets - support all bit widths however.
- -- declare i8 @llvm.atomic.cmp.swap.i8.p0i8(i8* <ptr>, i8 <cmp>, i8 <val>) - declare i16 @llvm.atomic.cmp.swap.i16.p0i16(i16* <ptr>, i16 <cmp>, i16 <val>) - declare i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* <ptr>, i32 <cmp>, i32 <val>) - declare i64 @llvm.atomic.cmp.swap.i64.p0i64(i64* <ptr>, i64 <cmp>, i64 <val>) -- -
This loads a value in memory and compares it to a given value. If they are - equal, it stores a new value into the memory.
- -The llvm.atomic.cmp.swap intrinsic takes three arguments. The result - as well as both cmp and val must be integer values with the - same bit width. The ptr argument must be a pointer to a value of - this integer type. While any bit width integer may be used, targets may only - lower representations they support in hardware.
- -This entire intrinsic must be executed atomically. It first loads the value - in memory pointed to by ptr and compares it with the - value cmp. If they are equal, val is stored into the - memory. The loaded value is yielded in all cases. This provides the - equivalent of an atomic compare-and-swap operation within the SSA - framework.
- -
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-
-%val1 = add i32 4, 4
-%result1 = call i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* %ptr, i32 4, %val1)
- ; yields {i32}:result1 = 4
-%stored1 = icmp eq i32 %result1, 4 ; yields {i1}:stored1 = true
-%memval1 = load i32* %ptr ; yields {i32}:memval1 = 8
-
-%val2 = add i32 1, 1
-%result2 = call i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* %ptr, i32 5, %val2)
- ; yields {i32}:result2 = 8
-%stored2 = icmp eq i32 %result2, 5 ; yields {i1}:stored2 = false
-
-%memval2 = load i32* %ptr ; yields {i32}:memval2 = 8
-
-
-This is an overloaded intrinsic. You can use llvm.atomic.swap on any - integer bit width. Not all targets support all bit widths however.
- -- declare i8 @llvm.atomic.swap.i8.p0i8(i8* <ptr>, i8 <val>) - declare i16 @llvm.atomic.swap.i16.p0i16(i16* <ptr>, i16 <val>) - declare i32 @llvm.atomic.swap.i32.p0i32(i32* <ptr>, i32 <val>) - declare i64 @llvm.atomic.swap.i64.p0i64(i64* <ptr>, i64 <val>) -- -
This intrinsic loads the value stored in memory at ptr and yields - the value from memory. It then stores the value in val in the memory - at ptr.
- -The llvm.atomic.swap intrinsic takes two arguments. Both - the val argument and the result must be integers of the same bit - width. The first argument, ptr, must be a pointer to a value of this - integer type. The targets may only lower integer representations they - support.
- -This intrinsic loads the value pointed to by ptr, yields it, and - stores val back into ptr atomically. This provides the - equivalent of an atomic swap operation within the SSA framework.
- -
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-
-%val1 = add i32 4, 4
-%result1 = call i32 @llvm.atomic.swap.i32.p0i32(i32* %ptr, i32 %val1)
- ; yields {i32}:result1 = 4
-%stored1 = icmp eq i32 %result1, 4 ; yields {i1}:stored1 = true
-%memval1 = load i32* %ptr ; yields {i32}:memval1 = 8
-
-%val2 = add i32 1, 1
-%result2 = call i32 @llvm.atomic.swap.i32.p0i32(i32* %ptr, i32 %val2)
- ; yields {i32}:result2 = 8
-
-%stored2 = icmp eq i32 %result2, 8 ; yields {i1}:stored2 = true
-%memval2 = load i32* %ptr ; yields {i32}:memval2 = 2
-
-
-This is an overloaded intrinsic. You can use llvm.atomic.load.add on - any integer bit width. Not all targets support all bit widths however.
- -- declare i8 @llvm.atomic.load.add.i8.p0i8(i8* <ptr>, i8 <delta>) - declare i16 @llvm.atomic.load.add.i16.p0i16(i16* <ptr>, i16 <delta>) - declare i32 @llvm.atomic.load.add.i32.p0i32(i32* <ptr>, i32 <delta>) - declare i64 @llvm.atomic.load.add.i64.p0i64(i64* <ptr>, i64 <delta>) -- -
This intrinsic adds delta to the value stored in memory - at ptr. It yields the original value at ptr.
- -The intrinsic takes two arguments, the first a pointer to an integer value - and the second an integer value. The result is also an integer value. These - integer types can have any bit width, but they must all have the same bit - width. The targets may only lower integer representations they support.
- -This intrinsic does a series of operations atomically. It first loads the - value stored at ptr. It then adds delta, stores the result - to ptr. It yields the original value stored at ptr.
- -
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-%result1 = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 4)
- ; yields {i32}:result1 = 4
-%result2 = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 2)
- ; yields {i32}:result2 = 8
-%result3 = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 5)
- ; yields {i32}:result3 = 10
-%memval1 = load i32* %ptr ; yields {i32}:memval1 = 15
-
-
-This is an overloaded intrinsic. You can use llvm.atomic.load.sub on - any integer bit width and for different address spaces. Not all targets - support all bit widths however.
- -- declare i8 @llvm.atomic.load.sub.i8.p0i32(i8* <ptr>, i8 <delta>) - declare i16 @llvm.atomic.load.sub.i16.p0i32(i16* <ptr>, i16 <delta>) - declare i32 @llvm.atomic.load.sub.i32.p0i32(i32* <ptr>, i32 <delta>) - declare i64 @llvm.atomic.load.sub.i64.p0i32(i64* <ptr>, i64 <delta>) -- -
This intrinsic subtracts delta to the value stored in memory at - ptr. It yields the original value at ptr.
- -The intrinsic takes two arguments, the first a pointer to an integer value - and the second an integer value. The result is also an integer value. These - integer types can have any bit width, but they must all have the same bit - width. The targets may only lower integer representations they support.
- -This intrinsic does a series of operations atomically. It first loads the - value stored at ptr. It then subtracts delta, stores the - result to ptr. It yields the original value stored - at ptr.
- -
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 8, %ptr
-%result1 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 4)
- ; yields {i32}:result1 = 8
-%result2 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 2)
- ; yields {i32}:result2 = 4
-%result3 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 5)
- ; yields {i32}:result3 = 2
-%memval1 = load i32* %ptr ; yields {i32}:memval1 = -3
-
-
-These are overloaded intrinsics. You can - use llvm.atomic.load_and, llvm.atomic.load_nand, - llvm.atomic.load_or, and llvm.atomic.load_xor on any integer - bit width and for different address spaces. Not all targets support all bit - widths however.
- -- declare i8 @llvm.atomic.load.and.i8.p0i8(i8* <ptr>, i8 <delta>) - declare i16 @llvm.atomic.load.and.i16.p0i16(i16* <ptr>, i16 <delta>) - declare i32 @llvm.atomic.load.and.i32.p0i32(i32* <ptr>, i32 <delta>) - declare i64 @llvm.atomic.load.and.i64.p0i64(i64* <ptr>, i64 <delta>) -- -
- declare i8 @llvm.atomic.load.or.i8.p0i8(i8* <ptr>, i8 <delta>) - declare i16 @llvm.atomic.load.or.i16.p0i16(i16* <ptr>, i16 <delta>) - declare i32 @llvm.atomic.load.or.i32.p0i32(i32* <ptr>, i32 <delta>) - declare i64 @llvm.atomic.load.or.i64.p0i64(i64* <ptr>, i64 <delta>) -- -
- declare i8 @llvm.atomic.load.nand.i8.p0i32(i8* <ptr>, i8 <delta>) - declare i16 @llvm.atomic.load.nand.i16.p0i32(i16* <ptr>, i16 <delta>) - declare i32 @llvm.atomic.load.nand.i32.p0i32(i32* <ptr>, i32 <delta>) - declare i64 @llvm.atomic.load.nand.i64.p0i32(i64* <ptr>, i64 <delta>) -- -
- declare i8 @llvm.atomic.load.xor.i8.p0i32(i8* <ptr>, i8 <delta>) - declare i16 @llvm.atomic.load.xor.i16.p0i32(i16* <ptr>, i16 <delta>) - declare i32 @llvm.atomic.load.xor.i32.p0i32(i32* <ptr>, i32 <delta>) - declare i64 @llvm.atomic.load.xor.i64.p0i32(i64* <ptr>, i64 <delta>) -- -
These intrinsics bitwise the operation (and, nand, or, xor) delta to - the value stored in memory at ptr. It yields the original value - at ptr.
- -These intrinsics take two arguments, the first a pointer to an integer value - and the second an integer value. The result is also an integer value. These - integer types can have any bit width, but they must all have the same bit - width. The targets may only lower integer representations they support.
- -These intrinsics does a series of operations atomically. They first load the - value stored at ptr. They then do the bitwise - operation delta, store the result to ptr. They yield the - original value stored at ptr.
- -
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 0x0F0F, %ptr
-%result0 = call i32 @llvm.atomic.load.nand.i32.p0i32(i32* %ptr, i32 0xFF)
- ; yields {i32}:result0 = 0x0F0F
-%result1 = call i32 @llvm.atomic.load.and.i32.p0i32(i32* %ptr, i32 0xFF)
- ; yields {i32}:result1 = 0xFFFFFFF0
-%result2 = call i32 @llvm.atomic.load.or.i32.p0i32(i32* %ptr, i32 0F)
- ; yields {i32}:result2 = 0xF0
-%result3 = call i32 @llvm.atomic.load.xor.i32.p0i32(i32* %ptr, i32 0F)
- ; yields {i32}:result3 = FF
-%memval1 = load i32* %ptr ; yields {i32}:memval1 = F0
-
-
-These are overloaded intrinsics. You can use llvm.atomic.load_max, - llvm.atomic.load_min, llvm.atomic.load_umax, and - llvm.atomic.load_umin on any integer bit width and for different - address spaces. Not all targets support all bit widths however.
- -- declare i8 @llvm.atomic.load.max.i8.p0i8(i8* <ptr>, i8 <delta>) - declare i16 @llvm.atomic.load.max.i16.p0i16(i16* <ptr>, i16 <delta>) - declare i32 @llvm.atomic.load.max.i32.p0i32(i32* <ptr>, i32 <delta>) - declare i64 @llvm.atomic.load.max.i64.p0i64(i64* <ptr>, i64 <delta>) -- -
- declare i8 @llvm.atomic.load.min.i8.p0i8(i8* <ptr>, i8 <delta>) - declare i16 @llvm.atomic.load.min.i16.p0i16(i16* <ptr>, i16 <delta>) - declare i32 @llvm.atomic.load.min.i32.p0i32(i32* <ptr>, i32 <delta>) - declare i64 @llvm.atomic.load.min.i64.p0i64(i64* <ptr>, i64 <delta>) -- -
- declare i8 @llvm.atomic.load.umax.i8.p0i8(i8* <ptr>, i8 <delta>) - declare i16 @llvm.atomic.load.umax.i16.p0i16(i16* <ptr>, i16 <delta>) - declare i32 @llvm.atomic.load.umax.i32.p0i32(i32* <ptr>, i32 <delta>) - declare i64 @llvm.atomic.load.umax.i64.p0i64(i64* <ptr>, i64 <delta>) --
- declare i8 @llvm.atomic.load.umin.i8.p0i8(i8* <ptr>, i8 <delta>) - declare i16 @llvm.atomic.load.umin.i16.p0i16(i16* <ptr>, i16 <delta>) - declare i32 @llvm.atomic.load.umin.i32.p0i32(i32* <ptr>, i32 <delta>) - declare i64 @llvm.atomic.load.umin.i64.p0i64(i64* <ptr>, i64 <delta>) + declare i8* @llvm.adjust.trampoline(i8* <tramp>)
These intrinsics takes the signed or unsigned minimum or maximum of - delta and the value stored in memory at ptr. It yields the - original value at ptr.
+This performs any required machine-specific adjustment to the address of a + trampoline (passed as tramp).
These intrinsics take two arguments, the first a pointer to an integer value - and the second an integer value. The result is also an integer value. These - integer types can have any bit width, but they must all have the same bit - width. The targets may only lower integer representations they support.
+tramp must point to a block of memory which already has trampoline code + filled in by a previous call to llvm.init.trampoline + .
These intrinsics does a series of operations atomically. They first load the - value stored at ptr. They then do the signed or unsigned min or - max delta and the value, store the result to ptr. They - yield the original value stored at ptr.
- -
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 7, %ptr
-%result0 = call i32 @llvm.atomic.load.min.i32.p0i32(i32* %ptr, i32 -2)
- ; yields {i32}:result0 = 7
-%result1 = call i32 @llvm.atomic.load.max.i32.p0i32(i32* %ptr, i32 8)
- ; yields {i32}:result1 = -2
-%result2 = call i32 @llvm.atomic.load.umin.i32.p0i32(i32* %ptr, i32 10)
- ; yields {i32}:result2 = 8
-%result3 = call i32 @llvm.atomic.load.umax.i32.p0i32(i32* %ptr, i32 30)
- ; yields {i32}:result3 = 8
-%memval1 = load i32* %ptr ; yields {i32}:memval1 = 30
-
+On some architectures the address of the code to be executed needs to be + different to the address where the trampoline is actually stored. This + intrinsic returns the executable address corresponding to tramp + after performing the required machine specific adjustments. + The pointer returned can then be bitcast and + executed. +
This intrinsic allows annotation of local variables with arbitrary strings. This can be useful for special purpose optimizations that want to look for - these annotations. These have no other defined use, they are ignored by code + these annotations. These have no other defined use; they are ignored by code generation and optimization.
This intrinsic allows annotations to be put on arbitrary expressions with arbitrary strings. This can be useful for special purpose optimizations that - want to look for these annotations. These have no other defined use, they + want to look for these annotations. These have no other defined use; they are ignored by code generation and optimization.
@@ -8404,11 +8227,35 @@ LLVM. compile time. + ++ declare i32 @llvm.expect.i32(i32 <val>, i32 <expected_val>) + declare i64 @llvm.expect.i64(i64 <val>, i64 <expected_val>) ++
The llvm.expect intrinsic provides information about expected (the + most probable) value of val, which can be used by optimizers.
+ +The llvm.expect intrinsic takes two arguments. The first + argument is a value. The second argument is an expected value, this needs to + be a constant value, variables are not allowed.
+ +This intrinsic is lowered to the val.