X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;ds=sidebyside;f=docs%2FLangRef.html;h=4c635d3a5aadc4951faba7f29599b28db2f37125;hb=2722dfa75dbf4436197f6fcf9d8cb2391975f1a1;hp=7032a198141f92e7cbf4fd447fb435e904180e6c;hpb=21c346e1714c50b2567de9e1d1a9184783fe5c0a;p=oota-llvm.git diff --git a/docs/LangRef.html b/docs/LangRef.html index 7032a198141..4c635d3a5aa 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -5,7 +5,7 @@
+%x = add i32 1, %x-
because the definition of %x does not dominate all of its uses. The LLVM infrastructure provides a verification pass that may be used to verify @@ -420,29 +435,23 @@
The easy way:
-+%result = mul i32 %X, 8-
After strength reduction:
-+%result = shl i32 %X, i8 3-
And the hard way:
-+%0 = add i32 %X, %X ; yields {i32}:%0 %1 = add i32 %0, %0 ; yields {i32}:%1 %result = add i32 %1, %1-
This last way of multiplying %X by 8 illustrates several important lexical features of LLVM:
@@ -481,29 +490,32 @@ 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]* ; External declaration of the puts function -declare i32 @puts(i8 *) ; i32(i8 *)* +declare i32 @puts(i8*) ; i32 (i8*)* ; 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]* @.LC0, i64 0, i64 0 ; i8* ; Call puts function to write out the string to stdout. - call i32 @puts(i8 * %cast210) ; i32 - ret i32 0-
}
+ call i32 @puts(i8* %cast210) ; i32 + ret i32 0
} + +; Named metadata +!1 = metadata !{i32 41} +!foo = !{!1, null}
This example is made up of a global variable named - ".LC0", an external declaration of the "puts" function, and + ".LC0", an external declaration of the "puts" function, a function definition for - "main".
+ "main" and named metadata + "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 @@ -525,20 +537,24 @@ define i32 @main() { ; i32()*
+%mytype = type { %mytype*, i32 }-
You may give a name to any type except "void". Type name aliases may be used anywhere a type @@ -803,20 +844,22 @@ define i32 @main() { ; i32()*
LLVM allows an explicit section to be specified for globals. If the target supports it, it will emit globals to the section specified.
-An explicit alignment may be specified for a global. If not present, or if - the alignment is set to zero, the alignment of the global is set by the - target to whatever it feels convenient. If an explicit alignment is - specified, the global is forced to have at least that much alignment. All - alignments must be a power of 2.
+An explicit alignment may be specified for a global, which must be a power + of 2. If not present, or if the alignment is set to zero, the alignment of + the global is set by the target to whatever it feels convenient. If an + explicit alignment is specified, the global is forced to have exactly that + alignment. Targets and optimizers are not allowed to over-align the global + if the global has an assigned section. In this case, the extra alignment + could be observable: for example, code could assume that the globals are + densely packed in their section and try to iterate over them as an array, + alignment padding would break this iteration.
For example, the following defines a global in a numbered address space with an initializer, section, and alignment:
-+@G = addrspace(5) constant float 1.0, section "foo", align 4-
LLVM function definitions consist of the "define" keyord, an +
LLVM function definitions consist of the "define" keyword, an optional linkage type, an optional visibility style, an optional calling convention, a return type, an optional @@ -841,7 +884,7 @@ define i32 @main() { ; i32()*
LLVM function declarations consist of the "declare" keyword, an optional linkage type, an optional - visibility style, an optional + visibility style, an optional calling convention, a return type, an optional parameter attribute for the return type, a function name, a possibly empty list of arguments, an optional alignment, and an @@ -869,15 +912,13 @@ define i32 @main() { ; i32()* alignments must be a power of 2.
+@<Name> = alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee>+ +
Named metadata is a collection of metadata. Metadata + nodes (but not metadata strings) and null are the only valid operands for + a named metadata.
+ ++; An unnamed metadata node, which is referenced by the named metadata. +!1 = metadata !{metadata !"one"} +; A named metadata. +!name = !{null, !1} ++
+declare i32 @printf(i8* noalias nocapture, ...) declare i32 @atoi(i8 zeroext) declare signext i8 @returns_signed_char()-
Note that any attributes for the function result (nounwind, readonly) come immediately after the argument list.
@@ -964,7 +1022,7 @@ declare signext i8 @returns_signed_char() generator that usually indicates a desired alignment for the synthesized stack slot.Each function may specify a garbage collector name, which is simply a string:
-+define void @f() gc "name" { ... }-
The compiler declares the supported values of name. Specifying a collector which will cause the compiler to alter its output in order to @@ -1032,16 +1100,19 @@ define void @f() gc "name" { ... }
Function attributes are simple keywords that follow the type specified. If multiple attributes are needed, they are space separated. For example:
-+define void @f() noinline { ... } define void @f() alwaysinline { ... } define void @f() alwaysinline optsize { ... } define void @f() optsize { ... }-
+module asm "inline asm code goes here" module asm "more can go here"-
The strings can contain any character by escaping non-printable characters. The escape sequence used is simply "\xx" where "xx" is the two digit hex code @@ -1168,11 +1237,9 @@ module asm "more can go here" data is to be laid out in memory. The syntax for the data layout is simply:
-+target datalayout = "layout specification"-
The layout specification consists of a list of specifications separated by the minus sign character ('-'). Each specification starts with @@ -1190,7 +1257,7 @@ target datalayout = "layout specification" location.
When constructing the data layout for a given target, LLVM starts with a - default set of specifications which are then (possibly) overriden by the + default set of specifications which are then (possibly) overridden by the specifications in the datalayout keyword. The default specifications are given in this list:
A pointer value is based on another pointer value according + to the following rules:
+ +Note that this definition of "based" is intentionally + similar to the definition of "based" in C99, though it is + slightly weaker.
LLVM IR does not associate types with memory. The result type of a load merely indicates the size and alignment of the memory from which to load, as well as the -interpretation of the value. The first operand of a +interpretation of the value. The first operand type of a store similarly only indicates the size and alignment of the store.
@@ -1314,6 +1402,24 @@ to implement type-based alias analysis. + + + +Certain memory accesses, such as loads, stores, and llvm.memcpys may be marked volatile. +The optimizers must not change the number of volatile operations or change their +order of execution relative to other volatile operations. The optimizers +may change the order of volatile operations relative to non-volatile +operations. This is not Java's "volatile" and has no cross-thread +synchronization behavior.
+ +Note that the code generator does not yet support large integer types to be - used as function return types. The specific limit on how large a return type - the code generator can currently handle is target-dependent; currently it's - often 64 bits for 32-bit targets and 128 bits for 64-bit targets.
- @@ -1518,6 +1620,19 @@ Classifications possible to have a two dimensional array, using an array as the element type of another array. + + + + + + +Aggregate Types are a subset of derived types that can contain multiple + member types. Arrays, + structs, vectors and + unions are aggregate types.
+Note that 'variable sized arrays' can be implemented in LLVM with a zero - length array. Normally, accesses past the end of an array are undefined in - LLVM (e.g. it is illegal to access the 5th element of a 3 element array). As - a special case, however, zero length arrays are recognized to be variable - length. This allows implementation of 'pascal style arrays' with the LLVM - type "{ i32, [0 x float]}", for example.
- -Note that the code generator does not yet support large aggregate types to be - used as function return types. The specific limit on how large an aggregate - return type the code generator can currently handle is target-dependent, and - also dependent on the aggregate element types.
+There is no restriction on indexing beyond the end of the array implied by + a static type (though there are restrictions on indexing beyond the bounds + of an allocated object in some cases). This means that single-dimension + 'variable sized array' addressing can be implemented in LLVM with a zero + length array type. An implementation of 'pascal style arrays' in LLVM could + use the type "{ i32, [0 x float]}", for example.
@@ -1591,9 +1701,9 @@ ClassificationsThe function type can be thought of as a function signature. It consists of a return type and a list of formal parameter types. The return type of a - function type is a scalar type, a void type, or a struct type. If the return - type is a struct type then all struct elements must be of first class types, - and the struct must have at least one element.
+ function type is a scalar type, a void type, a struct type, or a union + type. If the return type is a struct type then all struct elements must be + of first class types, and the struct must have at least one element.@@ -1605,7 +1715,7 @@ Classifications which indicates that the function takes a variable number of arguments. Variable argument functions can access their arguments with the variable argument handling intrinsic - functions. '<returntype>' is a any type except + functions. '<returntype>' is any type except label.Examples:
@@ -1615,18 +1725,17 @@ Classificationsfunction taking an i32, returning an i32 - float (i16 signext, i32 *) * + float (i16, i32 *) * -Pointer to a function that takes - an i16 that should be sign extended and a - pointer to i32, returning - float. + Pointer to a function that takes + an i16 and a pointer to i32, + returning float. i32 (i8*, ...) -A vararg function that takes at least one - pointer to i8 (char in C), - which returns an integer. This is the signature for printf in + A vararg function that takes at least one + pointer to i8 (char in C), + which returns an integer. This is the signature for printf in LLVM. @@ -1650,10 +1759,12 @@ Classifications underlying processor. The elements of a structure may be any type that has a size. - -Structures are accessed using 'load and - 'store' by getting a pointer to a field with - the 'getelementptr' instruction.
- +Structures in memory are accessed using 'load' + and 'store' by getting a pointer to a field + with the 'getelementptr' instruction. + Structures in registers are accessed using the + 'extractvalue' and + 'insertvalue' instructions.
Syntax:
{ <type list> } @@ -1673,11 +1784,6 @@ ClassificationsNote that the code generator does not yet support large aggregate types to be - used as function return types. The specific limit on how large an aggregate - return type the code generator can currently handle is target-dependent, and - also dependent on the aggregate element types.
- @@ -1718,16 +1824,66 @@ Classifications + + + ++ ++Overview:
+A union type describes an object with size and alignment suitable for + an object of any one of a given set of types (also known as an "untagged" + union). It is similar in concept and usage to a + struct, except that all members of the union + have an offset of zero. The elements of a union may be any type that has a + size. Unions must have at least one member - empty unions are not allowed. +
+ +The size of the union as a whole will be the size of its largest member, + and the alignment requirements of the union as a whole will be the largest + alignment requirement of any member.
+ +Union members are accessed using 'load and + 'store' by getting a pointer to a field with + the 'getelementptr' instruction. + Since all members are at offset zero, the getelementptr instruction does + not affect the address, only the type of the resulting pointer.
+ +Syntax:
++ union { <type list> } ++ +Examples:
++
+ ++ union { i32, i32*, float } +A union of three types: an i32, a pointer to + an i32, and a float. ++ ++ union { float, i32 (i32) * } +A union, where the first element is a float and the + second element is a pointer to a + function that takes an i32, returning + an i32. +href="#t_array">array of four i32 values.Overview:
-As in many languages, the pointer type represents a pointer or reference to - another object, which must live in memory. Pointer types may have an optional - address space attribute defining the target-specific numbered address space - where the pointed-to object resides. The default address space is zero.
+The pointer type is used to specify memory locations. + Pointers are commonly used to reference objects in memory.
+ +Pointer types may have an optional address space attribute defining the + numbered address space where the pointed-to object resides. The default + address space is number zero. The semantics of non-zero address + spaces are target-specific.
Note that LLVM does not permit pointers to void (void*) nor does it permit pointers to labels (label*). Use i8* instead.
@@ -1745,7 +1901,7 @@ Classifications- -i32 (i32 *) * +i32 (i32*) * A pointer to a function that takes an i32*, returning an i32. @@ -1768,8 +1924,7 @@ ClassificationsA vector type is a simple derived type that represents a vector of elements. Vector types are used when multiple primitive data are operated in parallel using a single instruction (SIMD). A vector type requires a size (number of - elements) and an underlying primitive data type. Vectors must have a power - of two length (1, 2, 4, 8, 16 ...). Vector types are considered + elements) and an underlying primitive data type. Vector types are considered first class.
Syntax:
@@ -1796,11 +1951,6 @@ ClassificationsNote that the code generator does not yet support large vector types to be - used as function return types. The specific limit on how large a vector - return type codegen can currently handle is target-dependent; currently it's - often a few times longer than a hardware vector register.
- @@ -1962,6 +2112,14 @@ Classifications the number and types of elements must match those specified by the type. +
+@X = global i32 17 @Y = global i32 42 @Z = global [2 x i32*] [ i32* @X, i32* @Y ]-
+%A = add %X, undef %B = sub %X, undef %C = xor %X, undef @@ -2044,13 +2200,11 @@ Safe: %B = undef %C = undef-
This is safe because all of the output bits are affected by the undef bits. Any output bit can have a zero or one depending on the input bits.
-+%A = or %X, undef %B = and %X, undef Safe: @@ -2060,19 +2214,17 @@ Unsafe: %A = undef %B = undef-
These logical operations have bits that are not always affected by the input. For example, if "%X" has a zero bit, then the output of the 'and' operation will always be a zero, no matter what the corresponding bit from the undef is. As such, it is unsafe to optimize or assume that the result of the and is undef. -However, it is safe to assume that all bits of the undef could be 0, and -optimize the and to 0. Likewise, it is safe to assume that all the bits of -the undef operand to the or could be set, allowing the or to be folded to +However, it is safe to assume that all bits of the undef could be 0, and +optimize the and to 0. Likewise, it is safe to assume that all the bits of +the undef operand to the or could be set, allowing the or to be folded to -1.
-+%A = select undef, %X, %Y %B = select undef, 42, %Y %C = select %X, %Y, undef @@ -2085,7 +2237,6 @@ Unsafe: %B = undef %C = undef-
This set of examples show that undefined select (and conditional branch) conditions can go "either way" but they have to come from one of the two @@ -2095,10 +2246,9 @@ the optimizer is allowed to assume that the undef operand could be the same as %Y, allowing the whole select to be eliminated.
-+%A = xor undef, undef - + %B = undef %C = xor %B, %B @@ -2114,7 +2264,6 @@ Safe: %E = undef %F = undef-
This example points out that two undef operands are not necessarily the same. This can be surprising to people (and also matches C semantics) where they @@ -2127,15 +2276,13 @@ so the value is not necessarily consistent over time. In fact, %A and %C need to have the same semantics or the core LLVM "replace all uses with" concept would not hold.
-+%A = fdiv undef, %X %B = fdiv %X, undef Safe: %A = undef b: unreachable-
These examples show the crucial difference between an undefined value and undefined behavior. An undefined value (like undef) is @@ -2149,25 +2296,128 @@ does not execute at all. This allows us to delete the divide and all code after it: since the undefined operation "can't happen", the optimizer can assume that it occurs in dead code.
- -+ +a: store undef -> %X b: store %X -> undef Safe: a: <deleted> b: unreachable-
These examples reiterate the fdiv example: a store "of" an undefined value -can be assumed to not have any effect: we can assume that the value is +can be assumed to not have any effect: we can assume that the value is overwritten with bits that happen to match what was already there. However, a store "to" an undefined location could clobber arbitrary memory, therefore, it has undefined behavior.
+ + +Trap values are similar to undef values, however + instead of representing an unspecified bit pattern, they represent the + fact that an instruction or constant expression which cannot evoke side + effects has nevertheless detected a condition which results in undefined + behavior.
+ +There is currently no way of representing a trap value in the IR; they + only exist when produced by operations such as + add with the nsw flag.
+ +Trap value behavior is defined in terms of value dependence:
+ +Whenever a trap value is generated, all values which depend on it evaluate + to trap. If they have side effects, the evoke their side effects as if each + operand with a trap value were undef. If they have externally-visible side + effects, the behavior is undefined.
+ +Here are some examples:
+ ++entry: + %trap = sub nuw i32 0, 1 ; Results in a trap value. + %still_trap = and i32 %trap, 0 ; Whereas (and i32 undef, 0) would return 0. + %trap_yet_again = getelementptr i32* @h, i32 %still_trap + store i32 0, i32* %trap_yet_again ; undefined behavior + + store i32 %trap, i32* @g ; Trap value conceptually stored to memory. + %trap2 = load i32* @g ; Returns a trap value, not just undef. + + volatile store i32 %trap, i32* @g ; External observation; undefined behavior. + + %narrowaddr = bitcast i32* @g to i16* + %wideaddr = bitcast i32* @g to i64* + %trap3 = load 16* %narrowaddr ; Returns a trap value. + %trap4 = load i64* %widaddr ; Returns a trap value. + + %cmp = icmp i32 slt %trap, 0 ; Returns a trap value. + %br i1 %cmp, %true, %end ; Branch to either destination. + +true: + volatile store i32 0, i32* @g ; This is control-dependent on %cmp, so + ; it has undefined behavior. + br label %end + +end: + %p = phi i32 [ 0, %entry ], [ 1, %true ] + ; Both edges into this PHI are + ; control-dependent on %cmp, so this + ; always results in a trap value. + + volatile store i32 0, i32* @g ; %end is control-equivalent to %entry + ; so this is defined (ignoring earlier + ; undefined behavior in this example). ++ +
The 'blockaddress' constant computes the address of the specified basic block in the specified function, and always has an i8* type. Taking the address of the entry block is illegal.
- +This value only has defined behavior when used as an operand to the 'indirectbr' instruction or for comparisons against null. Pointer equality tests between labels addresses is undefined @@ -2187,7 +2437,7 @@ has undefined behavior.
pointer sized value as long as the bits are not inspected. This allows ptrtoint and arithmetic to be performed on these values so long as the original value is reconstituted before the indirectbr. - +Finally, some targets may provide defined semantics when using the value as the operand to an inline assembly, but that is target specific. @@ -2209,104 +2459,114 @@ has undefined behavior.
supported). The following is the syntax for constant expressions:Embedded metadata provides a way to attach arbitrary data to the instruction - stream without affecting the behaviour of the program. There are two - metadata primitives, strings and nodes. All metadata has the - metadata type and is identified in syntax by a preceding exclamation - point ('!').
- -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"".
- -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}".
- -A metadata node will attempt to track changes to the values it holds. In the - event that a value is deleted, it will be replaced with a typeless - "null", such as "metadata !{null, i32 10}".
- -Optimizations may rely on metadata to provide additional information about - the program that isn't available in the instructions, or that isn't easily - computable. Similarly, the code generator may expect a certain metadata - format to be used to express debugging information.
- -+i32 (i32) asm "bswap $0", "=r,r"-
Inline assembler expressions may only be used as the callee operand of a call instruction. Thus, typically we have:
-+%X = call i32 asm "bswap $0", "=r,r"(i32 %Y)-
Inline asms with side effects not visible in the constraint list must be marked as having side effects. This is done through the use of the 'sideeffect' keyword, like so:
-+call void asm sideeffect "eieio", ""()-
In some cases inline asms will contain code that will not work unless the stack is aligned in some way, such as calls or SSE instructions on x86, @@ -2401,11 +2623,9 @@ call void asm sideeffect "eieio", ""() contain and should generate its usual stack alignment code in the prologue if the 'alignstack' keyword is present:
-+call void asm alignstack "eieio", ""()-
If both keywords appear the 'sideeffect' keyword must come first.
@@ -2414,7 +2634,72 @@ call void asm alignstack "eieio", ""() documented here. Constraints on what can be done (e.g. duplication, moving, etc need to be documented). This is probably best done by reference to another document that covers inline asm from a holistic perspective. + + + +The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode + attached to it that contains a constant integer. If present, the code + generator will use the integer as the location cookie value when report + errors through the LLVMContext error reporting mechanisms. This allows a + front-end to correlate backend errors that occur with inline asm back to the + source code that produced it. For example:
+ ++call void asm sideeffect "something bad", ""(), !srcloc !42 +... +!42 = !{ i32 1234567 } ++ +
It is up to the front-end to make sense of the magic numbers it places in the + IR.
+ +LLVM IR allows metadata to be attached to instructions in the program that + can convey extra information about the code to the optimizers and code + generator. One example application of metadata is source-level debug + information. There are two metadata primitives: strings and nodes. All + metadata has the metadata type and is identified in syntax by a + preceding exclamation point ('!').
+ +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"".
+ +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.
+ +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}". + +
Metadata can be used as function arguments. Here llvm.dbg.value + function is using two metadata arguments.
+ ++ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25) ++ +
Metadata can be attached with an instruction. Here metadata !21 is + attached with add instruction using !dbg identifier.
+ ++ %indvar.next = add i64 %indvar, 1, !dbg !21 +
TODO: Describe this.
++%0 = type { i32, void ()* } +@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }] ++
The @llvm.global_ctors array contains a list of constructor functions and associated priorities. The functions referenced by this array will be called in ascending order of priority (i.e. lowest first) when the module is loaded. The order of functions with the same priority is not defined. +
+%0 = type { i32, void ()* } +@llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }] +-
TODO: Describe this.
+The @llvm.global_dtors array contains a list of destructor functions and associated priorities. The functions referenced by this array will be called in descending order of priority (i.e. highest first) when the module is loaded. The order of functions with the same priority is not defined. +
There are six different terminator instructions: the +
There are seven different terminator instructions: the 'ret' instruction, the 'br' instruction, the 'switch' instruction, the @@ -2593,14 +2887,6 @@ Instruction ret { i32, i8 } { i32 4, i8 2 } ; Return a struct of values 4 and 2 -
Note that the code generator does not yet fully support large - return values. The specific sizes that are currently supported are - dependent on the target. For integers, on 32-bit targets the limit - is often 64 bits, and on 64-bit targets the limit is often 128 bits. - For aggregate types, the current limits are dependent on the element - types; for example targets are often limited to 2 total integer - elements and 2 total floating-point elements.
- @@ -2723,7 +3009,7 @@ IfUnequal: rest of the arguments indicate the full set of possible destinations that the address may point to. Blocks are allowed to occur multiple times in the destination list, though this isn't particularly useful. - +This destination list is required so that dataflow analysis has an accurate understanding of the CFG.
@@ -2790,9 +3076,10 @@ IfUnequal: function to be invoked.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 @@ -2857,6 +3147,9 @@ Instruction 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.
+ @@ -2932,7 +3225,8 @@ Instructionnuw and nsw stand for "No Unsigned Wrap" and "No Signed Wrap", respectively. If the nuw and/or nsw keywords are present, the result value of the add - is undefined if unsigned and/or signed overflow, respectively, occurs.
+ is a trap value if unsigned and/or signed overflow, + respectively, occurs.Example:
@@ -3012,7 +3306,8 @@ Instructionnuw and nsw stand for "No Unsigned Wrap" and "No Signed Wrap", respectively. If the nuw and/or nsw keywords are present, the result value of the sub - is undefined if unsigned and/or signed overflow, respectively, occurs.
+ is a trap value if unsigned and/or signed overflow, + respectively, occurs.Example:
@@ -3080,7 +3375,7 @@ InstructionThe two arguments to the 'mul' instruction must be integer or vector of integer values. Both arguments must have identical types.
- +Semantics:
The value produced is the integer product of the two operands.
@@ -3098,7 +3393,8 @@ Instructionnuw and nsw stand for "No Unsigned Wrap" and "No Signed Wrap", respectively. If the nuw and/or nsw keywords are present, the result value of the mul - is undefined if unsigned and/or signed overflow, respectively, occurs.
+ is a trap value if unsigned and/or signed overflow, + respectively, occurs.Example:
@@ -3152,7 +3448,7 @@ InstructionThe 'udiv' instruction returns the quotient of its two operands.
Arguments:
-The two arguments to the 'udiv' instruction must be +
The two arguments to the 'udiv' instruction must be integer or vector of integer values. Both arguments must have identical types.
@@ -3187,7 +3483,7 @@ InstructionThe 'sdiv' instruction returns the quotient of its two operands.
Arguments:
-The two arguments to the 'sdiv' instruction must be +
The two arguments to the 'sdiv' instruction must be integer or vector of integer values. Both arguments must have identical types.
@@ -3203,8 +3499,8 @@ Instruction a 32-bit division of -2147483648 by -1.If the exact keyword is present, the result value of the - sdiv is undefined if the result would be rounded or if overflow - would occur.
+ sdiv is a trap value if the result would + be rounded.Example:
@@ -3258,7 +3554,7 @@ Instruction division of its two arguments.Arguments:
-The two arguments to the 'urem' instruction must be +
The two arguments to the 'urem' instruction must be integer or vector of integer values. Both arguments must have identical types.
@@ -3298,7 +3594,7 @@ Instruction elements must be integers.Arguments:
-The two arguments to the 'srem' instruction must be +
The two arguments to the 'srem' instruction must be integer or vector of integer values. Both arguments must have identical types.
@@ -3393,7 +3689,7 @@ InstructionBoth arguments to the 'shl' instruction must be the same integer or vector of integer type. 'op2' is treated as an unsigned value.
- +Semantics:
The value produced is op1 * 2op2 mod 2n, where n is the width of the result. If op2 @@ -3429,7 +3725,7 @@ Instruction operand shifted to the right a specified number of bits with zero fill.
Arguments:
-Both arguments to the 'lshr' instruction must be the same +
Both arguments to the 'lshr' instruction must be the same integer or vector of integer type. 'op2' is treated as an unsigned value.
@@ -3469,7 +3765,7 @@ Instruction extension.Arguments:
-Both arguments to the 'ashr' instruction must be the same +
Both arguments to the 'ashr' instruction must be the same integer or vector of integer type. 'op2' is treated as an unsigned value.
@@ -3509,7 +3805,7 @@ Instruction operands.Arguments:
-The two arguments to the 'and' instruction must be +
The two arguments to the 'and' instruction must be integer or vector of integer values. Both arguments must have identical types.
@@ -3568,7 +3864,7 @@ Instruction two operands.Arguments:
-The two arguments to the 'or' instruction must be +
The two arguments to the 'or' instruction must be integer or vector of integer values. Both arguments must have identical types.
@@ -3631,7 +3927,7 @@ Instruction complement" operation, which is the "~" operator in C.Arguments:
-The two arguments to the 'xor' instruction must be +
The two arguments to the 'xor' instruction must be integer or vector of integer values. Both arguments must have identical types.
@@ -3679,7 +3975,7 @@ Instruction -+ @@ -3802,26 +4098,27 @@ InstructionExample:
- <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2, + <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2, <4 x i32> <i32 0, i32 4, i32 1, i32 5> ; yields <4 x i32> - <result> = shufflevector <4 x i32> %v1, <4 x i32> undef, + <result> = shufflevector <4 x i32> %v1, <4 x i32> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 3> ; yields <4 x i32> - Identity shuffle. - <result> = shufflevector <8 x i32> %v1, <8 x i32> undef, + <result> = shufflevector <8 x i32> %v1, <8 x i32> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 3> ; yields <4 x i32> - <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2, + <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2, <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 > ; yields <8 x i32>-+-@@ -3838,14 +4135,14 @@ InstructionLLVM supports several instructions for working with aggregate values.
+LLVM supports several instructions for working with + aggregate values.
Overview:
-The 'extractvalue' instruction extracts the value of a struct field - or array element from an aggregate value.
+The 'extractvalue' instruction extracts the value of a member field + from an aggregate value.
Arguments:
The first operand of an 'extractvalue' instruction is a value - of struct or array type. The - operands are constant indices to specify which value to extract in a similar - manner as indices in a + of struct, union or + array type. The operands are constant indices to + specify which value to extract in a similar manner as indices in a 'getelementptr' instruction.
Semantics:
@@ -3868,20 +4165,19 @@ InstructionSyntax:
- <result> = insertvalue <aggregate type> <val>, <ty> <val>, <idx> ; yields <n x <ty>> + <result> = insertvalue <aggregate type> <val>, <ty> <elt>, <idx> ; yields <aggregate type>Overview:
-The 'insertvalue' instruction inserts a value into a struct field or - array element in an aggregate.
- +The 'insertvalue' instruction inserts a value into a member field + in an aggregate value.
Arguments:
The first operand of an 'insertvalue' instruction is a value - of struct or array type. The - second operand is a first-class value to insert. The following operands are - constant indices indicating the position at which to insert the value in a - similar manner as indices in a + of struct, union or + array type. The second operand is a first-class + value to insert. The following operands are constant indices indicating + the position at which to insert the value in a similar manner as indices in a 'getelementptr' instruction. The value to insert must have the same type as the value identified by the indices.
@@ -3893,14 +4189,15 @@ InstructionExample:
- <result> = insertvalue {i32, float} %agg, i32 1, 0 ; yields {i32, float} + %agg1 = insertvalue {i32, float} undef, i32 1, 0 ; yields {i32 1, float undef} + %agg2 = insertvalue {i32, float} %agg1, float %val, 1 ; yields {i32 1, float %val}-+ @@ -3922,7 +4219,7 @@ InstructionSyntax:
- <result> = alloca <type>[, i32 <NumElements>][, align <alignment>] ; yields {type*}:result + <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>] ; yields {type*}:resultOverview:
@@ -3972,8 +4269,9 @@ InstructionSyntax:
- <result> = load <ty>* <pointer>[, align <alignment>] - <result> = volatile load <ty>* <pointer>[, align <alignment>] + <result> = load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] + <result> = volatile load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] + !<index> = !{ i32 1 }Overview:
@@ -3984,18 +4282,25 @@ Instruction from which to load. The pointer must point to a first class type. If the load is marked as volatile, then the optimizer is not allowed to modify the - number or order of execution of this load with other - volatile load and store - instructions. + number or order of execution of this load with other volatile operations. -The optional constant "align" argument specifies the alignment of the +
The optional constant align argument specifies the alignment of the operation (that is, the alignment of the memory address). A value of 0 or an - omitted "align" argument means that the operation has the preferential + omitted align argument means that the operation has the preferential alignment for the target. It is the responsibility of the code emitter to ensure that the alignment information is correct. Overestimating the - alignment results in an undefined behavior. Underestimating the alignment may + alignment results in undefined behavior. Underestimating the alignment may produce less efficient code. An alignment of 1 is always safe.
+The optional !nontemporal metadata must reference a single + metatadata name <index> corresponding to a metadata node with + one i32 entry of value 1. The existence of + the !nontemporal metatadata on the instruction tells the optimizer + and code generator that this load is not expected to be reused in the cache. + The code generator may select special instructions to save cache bandwidth, + such as the MOVNT instruction on x86.
+Semantics:
The location of memory pointed to is loaded. If the value being loaded is of scalar type then the number of bytes read does not exceed the minimum number @@ -4022,8 +4327,8 @@ Instruction
Syntax:
- store <ty> <value>, <ty>* <pointer>[, align <alignment>] ; yields {void} - volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>] ; yields {void} + store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] ; yields {void} + volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] ; yields {void}Overview:
@@ -4034,11 +4339,10 @@ Instruction and an address at which to store it. The type of the '<pointer>' operand must be a pointer to the first class type of the - '<value>' operand. If the store is marked - as volatile, then the optimizer is not allowed to modify the number - or order of execution of this store with other - volatile load and store - instructions. + '<value>' operand. If the store is marked as + volatile, then the optimizer is not allowed to modify the number or + order of execution of this store with other volatile operations.The optional constant "align" argument specifies the alignment of the operation (that is, the alignment of the memory address). A value of 0 or an @@ -4048,6 +4352,15 @@ Instruction alignment results in an undefined behavior. Underestimating the alignment may produce less efficient code. An alignment of 1 is always safe.
+The optional !nontemporal metadata must reference a single metatadata + name <index> corresponding to a metadata node with one i32 entry of + value 1. The existence of the !nontemporal metatadata on the + instruction tells the optimizer and code generator that this load is + not expected to be reused in the cache. The code generator may + select special instructions to save cache bandwidth, such as the + MOVNT instruction on x86.
+ +Semantics:
The contents of memory are updated to contain '<value>' at the location specified by the '<pointer>' operand. If @@ -4082,8 +4395,8 @@ Instruction
Overview:
The 'getelementptr' instruction is used to get the address of a - subelement of an aggregate data structure. It performs address calculation - only and does not access memory.
+ subelement of an aggregate data structure. + It performs address calculation only and does not access memory.Arguments:
The first argument is always a pointer, and forms the basis of the @@ -4093,22 +4406,21 @@ Instruction indexes the pointer value given as the first argument, the second index indexes a value of the type pointed to (not necessarily the value directly pointed to, since the first index can be non-zero), etc. The first type - indexed into must be a pointer value, subsequent types can be arrays, vectors - and structs. Note that subsequent types being indexed into can never be - pointers, since that would require loading the pointer before continuing - calculation.
+ indexed into must be a pointer value, subsequent types can be arrays, + vectors, structs and unions. Note that subsequent types being indexed into + can never be pointers, since that would require loading the pointer before + continuing calculation.The type of each index argument depends on the type it is indexing into. - When indexing into a (optionally packed) structure, 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 + When indexing into a (optionally packed) structure or union, 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.
For example, let's consider a C code fragment and how it gets compiled to LLVM:
--+struct RT { char A; int B[10][20]; @@ -4124,12 +4436,10 @@ int *foo(struct ST *s) { return &s[1].Z.B[5][13]; }-The LLVM code generated by the GCC frontend is:
--+%RT = type { i8 , [10 x [20 x i32]], i8 } %ST = type { i32, double, %RT } @@ -4139,7 +4449,6 @@ entry: ret i32* %reg }-Semantics:
In the example above, the first index is indexing into the '%ST*' @@ -4168,13 +4477,14 @@ entry:
If the inbounds keyword is present, the result value of the - getelementptr is undefined if the base pointer is not an - in bounds address of an allocated object, or if any of the addresses - that would be formed by successive addition of the offsets implied by the - indices to the base address with infinitely precise arithmetic are not an - in bounds address of that allocated object. - The in bounds addresses for an allocated object are all the addresses - that point into the object, plus the address one byte past the end.
+ getelementptr is a trap value if the + base pointer is not an in bounds address of an allocated object, + or if any of the addresses that would be formed by successive addition of + the offsets implied by the indices to the base address with infinitely + precise arithmetic are not an in bounds address of that allocated + object. The in bounds addresses for an allocated object are all + the addresses that point into the object, plus the address one byte past + the end.If the inbounds keyword is not present, the offsets are added to the base address with silently-wrapping two's complement arithmetic, and @@ -4263,15 +4573,15 @@ entry:
Overview:
-The 'zext' instruction zero extends its operand to type +
The 'zext' instruction zero extends its operand to type ty2.
Arguments:
-The 'zext' instruction takes a value to cast, which must be of +
The 'zext' instruction takes a value to cast, which must be of integer type, and a type to cast it to, which must also be of integer type. The bit size of the - value must be smaller than the bit size of the destination type, + value must be smaller than the bit size of the destination type, ty2.
Semantics:
@@ -4303,10 +4613,10 @@ entry:The 'sext' sign extends value to the type ty2.
Arguments:
-The 'sext' instruction takes a value to cast, which must be of +
The 'sext' instruction takes a value to cast, which must be of integer type, and a type to cast it to, which must also be of integer type. The bit size of the - value must be smaller than the bit size of the destination type, + value must be smaller than the bit size of the destination type, ty2.
Semantics:
@@ -4344,12 +4654,12 @@ entry:The 'fptrunc' instruction takes a floating point value to cast and a floating point type to cast it to. The size of value must be larger than the size of - ty2. This implies that fptrunc cannot be used to make a + ty2. This implies that fptrunc cannot be used to make a no-op cast.
Semantics:
The 'fptrunc' instruction truncates a value from a larger - floating point type to a smaller + floating point type to a smaller floating point type. If the value cannot fit within the destination type, ty2, then the results are undefined.
@@ -4378,7 +4688,7 @@ entry: floating point value.Arguments:
-The 'fpext' instruction takes a +
The 'fpext' instruction takes a floating point value to cast, and a floating point type to cast it to. The source type must be smaller than the destination type.
@@ -4421,7 +4731,7 @@ entry: vector integer type with the same number of elements as tySemantics:
-The 'fptoui' instruction converts its +
The 'fptoui' instruction converts its floating point operand into the nearest (rounding towards zero) unsigned integer value. If the value cannot fit in ty2, the results are undefined.
@@ -4447,7 +4757,7 @@ entry:Overview:
-The 'fptosi' instruction converts +
The 'fptosi' instruction converts floating point value to type ty2.
@@ -4459,7 +4769,7 @@ entry: vector integer type with the same number of elements as tySemantics:
-The 'fptosi' instruction converts its +
The 'fptosi' instruction converts its floating point operand into the nearest (rounding towards zero) signed integer value. If the value cannot fit in ty2, the results are undefined.
@@ -4656,7 +4966,7 @@ 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@@ -4716,11 +5026,11 @@ entry: result, as follows:-
- eq: yields true if the operands are equal, +
- eq: yields true if the operands are equal, false otherwise. No sign interpretation is necessary or performed.
-- ne: yields true if the operands are unequal, +
- ne: yields true if the operands are unequal, false otherwise. No sign interpretation is necessary or performed.
@@ -4837,42 +5147,42 @@ entry:
- false: always yields false, regardless of operands.
-- oeq: yields true if both operands are not a QNAN and +
- oeq: yields true if both operands are not a QNAN and op1 is equal to op2.
- ogt: yields true if both operands are not a QNAN and - op1 is greather than op2.
+ op1 is greater than op2. -- oge: yields true if both operands are not a QNAN and +
- oge: yields true if both operands are not a QNAN and op1 is greater than or equal to op2.
-- olt: yields true if both operands are not a QNAN and +
- olt: yields true if both operands are not a QNAN and op1 is less than op2.
-- ole: yields true if both operands are not a QNAN and +
- ole: yields true if both operands are not a QNAN and op1 is less than or equal to op2.
-- one: yields true if both operands are not a QNAN and +
- one: yields true if both operands are not a QNAN and op1 is not equal to op2.
- ord: yields true if both operands are not a QNAN.
-- ueq: yields true if either operand is a QNAN or +
- ueq: yields true if either operand is a QNAN or op1 is equal to op2.
-- ugt: yields true if either operand is a QNAN or +
- ugt: yields true if either operand is a QNAN or op1 is greater than op2.
-- uge: yields true if either operand is a QNAN or +
- uge: yields true if either operand is a QNAN or op1 is greater than or equal to op2.
-- ult: yields true if either operand is a QNAN or +
- ult: yields true if either operand is a QNAN or op1 is less than op2.
-- ule: yields true if either operand is a QNAN or +
- ule: yields true if either operand is a QNAN or op1 is less than or equal to op2.
-- une: yields true if either operand is a QNAN or +
- une: yields true if either operand is a QNAN or op1 is not equal to op2.
- uno: yields true if either operand is a QNAN.
@@ -5003,15 +5313,34 @@ Loop: ; Infinite loop that counts from 0 on up...This instruction requires several arguments:
-
- The optional "tail" marker indicates whether the callee function accesses - any allocas or varargs in the caller. If the "tail" marker is present, - the function call is eligible for tail call optimization. Note that calls - may be marked "tail" even if they do not occur before - a ret instruction.
+- The optional "tail" marker indicates that the callee function does not + access any allocas or varargs in the caller. Note that calls may be + marked "tail" even if they do not occur before + a ret instruction. If the "tail" marker is + present, the function call is eligible for tail call optimization, + but might not in fact be + optimized into a jump. The code generator may optimize calls marked + "tail" with either 1) automatic + sibling call optimization when the caller and callee have + matching signatures, or 2) forced tail call optimization when the + following extra requirements are met: +
+
+- Caller and callee both have the calling + convention fastcc.
+- The call is in tail position (ret immediately follows call and ret + uses value of call or is void).
+- Option -tailcallopt is enabled, + or
+llvm::GuaranteedTailCallOpt
istrue
.- Platform specific + constraints are met.
+- The optional "cconv" marker indicates which calling convention the call should use. If none is specified, the call - defaults to using C calling conventions.
+ defaults to using C calling conventions. The calling convention of the + call must match the calling convention of the target function, or else the + behavior is undefined.- The optional Parameter Attributes list for return values. Only 'zeroext', 'signext', and @@ -5032,10 +5361,10 @@ Loop: ; Infinite loop that counts from 0 on up... to function value.
- 'function args': argument list whose types match the function - signature argument types. All arguments must be of - first class type. If the function signature - indicates the function accepts a variable number of arguments, the extra - arguments can be specified.
+ signature argument types and parameter attributes. All arguments must be + of first class type. If the function + signature indicates the function accepts a variable number of arguments, + the extra arguments can be specified.- The optional function attributes list. Only 'noreturn', 'nounwind', 'readonly' and @@ -5053,7 +5382,7 @@ Loop: ; Infinite loop that counts from 0 on up...
Example:
%retval = call i32 @test(i32 %argc) - call i32 (i8 *, ...)* @printf(i8 * %msg, i32 12, i8 42) ; yields i32 + call i32 (i8*, ...)* @printf(i8* %msg, i32 12, i8 42) ; yields i32 %X = tail call i32 @foo() ; yields i32 %Y = tail call fastcc i32 @foo() ; yields i32 call void %foo(i8 97 signext) @@ -5070,7 +5399,7 @@ Loop: ; Infinite loop that counts from 0 on up... standard C99 library as being the C99 library functions, and may perform optimizations or generate code for them under that assumption. This is something we'd like to change in the future to provide better support for -freestanding environments and non-C-based langauges. +freestanding environments and non-C-based languages. @@ -5164,7 +5493,7 @@ freestanding environments and non-C-based langauges. suffix is required. Because the argument's type is matched against the return type, it does not require its own name suffix. -To learn how to add an intrinsic function, please see the +
To learn how to add an intrinsic function, please see the Extending LLVM Guide.
@@ -5190,8 +5519,7 @@ freestanding environments and non-C-based langauges. instruction and the variable argument handling intrinsic functions are used. --@@ -5486,7 +5813,7 @@ LLVM.+define i32 @test(i32 %X, ...) { ; Initialize variable argument processing %ap = alloca i8* @@ -5216,7 +5544,6 @@ declare void @llvm.va_start(i8*) declare void @llvm.va_copy(i8*, i8*) declare void @llvm.va_end(i8*)-Syntax:
- declare i8 *@llvm.frameaddress(i32 <level>) + declare i8* @llvm.frameaddress(i32 <level>)Overview:
@@ -5520,7 +5847,7 @@ LLVM.Syntax:
- declare i8 *@llvm.stacksave() + declare i8* @llvm.stacksave()Overview:
@@ -5550,7 +5877,7 @@ LLVM.Syntax:
- declare void @llvm.stackrestore(i8 * %ptr) + declare void @llvm.stackrestore(i8* %ptr)Overview:
@@ -5626,7 +5953,7 @@ LLVM.Semantics:
This intrinsic does not modify the behavior of the program. Backends that do - not support this intrinisic may ignore it.
+ not support this intrinsic may ignore it. @@ -5639,7 +5966,7 @@ LLVM.Syntax:
- declare i64 @llvm.readcyclecounter( ) + declare i64 @llvm.readcyclecounter()Overview:
@@ -5680,17 +6007,14 @@ LLVM.Syntax:
This is an overloaded intrinsic. You can use llvm.memcpy on any - integer bit width. Not all targets support all bit widths however.
+ integer bit width and for different address spaces. Not all targets support + all bit widths however.- declare void @llvm.memcpy.i8(i8 * <dest>, i8 * <src>, - i8 <len>, i32 <align>) - declare void @llvm.memcpy.i16(i8 * <dest>, i8 * <src>, - i16 <len>, i32 <align>) - declare void @llvm.memcpy.i32(i8 * <dest>, i8 * <src>, - i32 <len>, i32 <align>) - declare void @llvm.memcpy.i64(i8 * <dest>, i8 * <src>, - i64 <len>, i32 <align>) + declare void @llvm.memcpy.p0i8.p0i8.i32(i8* <dest>, i8* <src>, + i32 <len>, i32 <align>, i1 <isvolatile>) + declare void @llvm.memcpy.p0i8.p0i8.i64(i8* <dest>, i8* <src>, + i64 <len>, i32 <align>, i1 <isvolatile>)Overview:
@@ -5698,19 +6022,28 @@ LLVM. source location to the destination location.Note that, unlike the standard libc function, the llvm.memcpy.* - intrinsics do not return a value, and takes an extra alignment argument.
+ intrinsics do not return a value, takes extra alignment/isvolatile arguments + and the pointers can be in specified address spaces.Arguments:
+The first argument is a pointer to the destination, the second is a pointer to the source. The third argument is an integer argument specifying the - number of bytes to copy, and the fourth argument is the alignment of the - source and destination locations.
+ number of bytes to copy, the fourth argument is the alignment of the + source and destination locations, and the fifth is a boolean indicating a + volatile access. -If the call to this intrinisic has an alignment value that is not 0 or 1, +
If the call to this intrinsic has an alignment value that is not 0 or 1, then the caller guarantees that both the source and destination pointers are aligned to that boundary.
+If the isvolatile parameter is true, the + llvm.memcpy call is a volatile operation. + The detailed access behavior is not very cleanly specified and it is unwise + to depend on it.
+Semantics:
+The 'llvm.memcpy.*' intrinsics copy a block of memory from the source location to the destination location, which are not allowed to overlap. It copies "len" bytes of memory over. If the argument is known to @@ -5728,17 +6061,14 @@ LLVM.
Syntax:
This is an overloaded intrinsic. You can use llvm.memmove on any integer bit - width. Not all targets support all bit widths however.
+ width and for different address space. Not all targets support all bit + widths however.- declare void @llvm.memmove.i8(i8 * <dest>, i8 * <src>, - i8 <len>, i32 <align>) - declare void @llvm.memmove.i16(i8 * <dest>, i8 * <src>, - i16 <len>, i32 <align>) - declare void @llvm.memmove.i32(i8 * <dest>, i8 * <src>, - i32 <len>, i32 <align>) - declare void @llvm.memmove.i64(i8 * <dest>, i8 * <src>, - i64 <len>, i32 <align>) + declare void @llvm.memmove.p0i8.p0i8.i32(i8* <dest>, i8* <src>, + i32 <len>, i32 <align>, i1 <isvolatile>) + declare void @llvm.memmove.p0i8.p0i8.i64(i8* <dest>, i8* <src>, + i64 <len>, i32 <align>, i1 <isvolatile>)Overview:
@@ -5748,19 +6078,28 @@ LLVM. overlap.Note that, unlike the standard libc function, the llvm.memmove.* - intrinsics do not return a value, and takes an extra alignment argument.
+ intrinsics do not return a value, takes extra alignment/isvolatile arguments + and the pointers can be in specified address spaces.Arguments:
+The first argument is a pointer to the destination, the second is a pointer to the source. The third argument is an integer argument specifying the - number of bytes to copy, and the fourth argument is the alignment of the - source and destination locations.
+ number of bytes to copy, the fourth argument is the alignment of the + source and destination locations, and the fifth is a boolean indicating a + volatile access. -If the call to this intrinisic has an alignment value that is not 0 or 1, +
If the call to this intrinsic has an alignment value that is not 0 or 1, then the caller guarantees that the source and destination pointers are aligned to that boundary.
+If the isvolatile parameter is true, the + llvm.memmove call is a volatile operation. + The detailed access behavior is not very cleanly specified and it is unwise + to depend on it.
+Semantics:
+The 'llvm.memmove.*' intrinsics copy a block of memory from the source location to the destination location, which may overlap. It copies "len" bytes of memory over. If the argument is known to be aligned to some @@ -5778,17 +6117,14 @@ LLVM.
Syntax:
This is an overloaded intrinsic. You can use llvm.memset on any integer bit - width. Not all targets support all bit widths however.
+ width and for different address spaces. Not all targets support all bit + widths however.- declare void @llvm.memset.i8(i8 * <dest>, i8 <val>, - i8 <len>, i32 <align>) - declare void @llvm.memset.i16(i8 * <dest>, i8 <val>, - i16 <len>, i32 <align>) - declare void @llvm.memset.i32(i8 * <dest>, i8 <val>, - i32 <len>, i32 <align>) - declare void @llvm.memset.i64(i8 * <dest>, i8 <val>, - i64 <len>, i32 <align>) + declare void @llvm.memset.p0i8.i32(i8* <dest>, i8 <val>, + i32 <len>, i32 <align>, i1 <isvolatile>) + declare void @llvm.memset.p0i8.i64(i8* <dest>, i8 <val>, + i64 <len>, i32 <align>, i1 <isvolatile>)Overview:
@@ -5796,7 +6132,8 @@ LLVM. particular byte value.Note that, unlike the standard libc function, the llvm.memset - intrinsic does not return a value, and takes an extra alignment argument.
+ intrinsic does not return a value, takes extra alignment/volatile arguments, + and the destination can be in an arbitrary address space.Arguments:
The first argument is a pointer to the destination to fill, the second is the @@ -5804,10 +6141,15 @@ LLVM.
specifying the number of bytes to fill, and the fourth argument is the known alignment of destination location. -If the call to this intrinisic has an alignment value that is not 0 or 1, +
If the call to this intrinsic has an alignment value that is not 0 or 1, then the caller guarantees that the destination pointer is aligned to that boundary.
+If the isvolatile parameter is true, the + llvm.memset call is a volatile operation. + The detailed access behavior is not very cleanly specified and it is unwise + to depend on it.
+Semantics:
The 'llvm.memset.*' intrinsics fill "len" bytes of memory starting at the destination location. If the argument is known to be aligned to some @@ -6427,6 +6769,97 @@ LLVM.
+ + + ++ ++ + + + +Half precision floating point is a storage-only format. This means that it is + a dense encoding (in memory) but does not support computation in the + format.
+ +This means that code must first load the half-precision floating point + value as an i16, then convert it to float with llvm.convert.from.fp16. + Computation can then be performed on the float value (including extending to + double etc). To store the value back to memory, it is first converted to + float if needed, then converted to i16 with + llvm.convert.to.fp16, then + storing as an i16 value.
++ ++ + + + +Syntax:
++ declare i16 @llvm.convert.to.fp16(f32 %a) ++ +Overview:
+The 'llvm.convert.to.fp16' intrinsic function performs + a conversion from single precision floating point format to half precision + floating point format.
+ +Arguments:
+The intrinsic function contains single argument - the value to be + converted.
+ +Semantics:
+The 'llvm.convert.to.fp16' intrinsic function performs + a conversion from single precision floating point format to half precision + floating point format. The return value is an i16 which + contains the converted number.
+ +Examples:
++ %res = call i16 @llvm.convert.to.fp16(f32 %a) + store i16 %res, i16* @x, align 2 ++ ++ ++Syntax:
++ declare f32 @llvm.convert.from.fp16(i16 %a) ++ +Overview:
+The 'llvm.convert.from.fp16' intrinsic function performs + a conversion from half precision floating point format to single precision + floating point format.
+ +Arguments:
+The intrinsic function contains single argument - the value to be + converted.
+ +Semantics:
+The 'llvm.convert.from.fp16' intrinsic function performs a + conversion from half single precision floating point format to single + precision floating point format. The input half-float value is represented by + an i16 value.
+ +Examples:
++ %a = load i16* @x, align 2 + %res = call f32 @llvm.convert.from.fp16(i16 %a) ++ +Debugger Intrinsics @@ -6463,7 +6896,8 @@ LLVM.@@ -6565,7 +6997,7 @@ LLVM.This intrinsic makes it possible to excise one parameter, marked with - the nest attribute, from a function. The result is a callable + the nest attribute, from a function. + The result is a callable function pointer lacking the nest parameter - the caller does not need to provide a value for it. Instead, the value to use is stored in advance in a "trampoline", a block of memory usually allocated on the stack, which also @@ -6475,17 +6909,15 @@ LLVM.
pointer has signature i32 (i32, i32)*. It can be created as follows: ---+%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 ) + %p = call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8* nest , i32, i32)* @f to i8*), i8* %nval) %fp = bitcast i8* %p to i32 (i32, i32)*-The call %val = call i32 %fp( i32 %x, i32 %y ) is then equivalent - to %val = call i32 %f( i8* %nval, i32 %x, i32 %y ).
+The call %val = call i32 %fp(i32 %x, i32 %y) is then equivalent + to %val = call i32 %f(i8* %nval, i32 %x, i32 %y).
+ + + +Syntax:
- declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device> ) + declare void @llvm.memory.barrier(i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device>)Overview:
@@ -6575,7 +7007,7 @@ LLVM.Arguments:
The llvm.memory.barrier intrinsic requires five boolean arguments. The first four arguments enables a specific barrier as listed below. The - fith argument specifies that the barrier applies to io or device or uncached + fifth argument specifies that the barrier applies to io or device or uncached memory.
@@ -6599,11 +7031,11 @@ LLVM.
@@ -6622,7 +7054,7 @@ LLVM. 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 ) + call void @llvm.memory.barrier(i1 false, i1 true, i1 false, i1 false) ; guarantee the above finishes store i32 8, %ptr ; before this begins @@ -6642,10 +7074,10 @@ LLVM. support all bit widths however.
- ll: All loads before the barrier must complete before any load after the barrier begins.
-- ls: All loads before the barrier must complete before any +
- ls: All loads before the barrier must complete before any store after the barrier begins.
-- ss: All stores before the barrier must complete before any +
- ss: All stores before the barrier must complete before any store after the barrier begins.
-- sl: All stores before the barrier must complete before any +
- sl: All stores before the barrier must complete before any load after the barrier begins.
- 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> ) + 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>)Overview:
@@ -6674,13 +7106,13 @@ LLVM. store i32 4, %ptr %val1 = add i32 4, 4 -%result1 = call i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* %ptr, i32 4, %val1 ) +%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 ) +%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 @@ -6700,10 +7132,10 @@ LLVM. 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> ) + 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>)Overview:
@@ -6730,13 +7162,13 @@ LLVM. store i32 4, %ptr %val1 = add i32 4, 4 -%result1 = call i32 @llvm.atomic.swap.i32.p0i32( i32* %ptr, i32 %val1 ) +%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 ) +%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 @@ -6758,10 +7190,10 @@ LLVM. 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> ) + 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>)Overview:
@@ -6784,11 +7216,11 @@ LLVM. %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 ) +%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 ) +%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 ) +%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 @@ -6809,14 +7241,14 @@ LLVM. 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> ) + 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>)Overview:
-This intrinsic subtracts delta to the value stored in memory at +
This intrinsic subtracts delta to the value stored in memory at ptr. It yields the original value at ptr.
Arguments:
@@ -6836,11 +7268,11 @@ LLVM. %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 ) +%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 ) +%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 ) +%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 @@ -6865,31 +7297,31 @@ LLVM. 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.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.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.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> ) + 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>)Overview:
@@ -6914,13 +7346,13 @@ LLVM. %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 ) +%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 ) +%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 ) +%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 ) +%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 @@ -6944,35 +7376,35 @@ LLVM. 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.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.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.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.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>)Overview:
-These intrinsics takes the signed or unsigned minimum or maximum of +
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.
@@ -6993,13 +7425,13 @@ LLVM. %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 ) +%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 ) +%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 ) +%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 ) +%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 @@ -7154,7 +7586,7 @@ LLVM.Syntax:
- declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32 <int> ) + declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32 <int>)Overview:
@@ -7185,11 +7617,11 @@ LLVM. any integer bit width.- declare i8 @llvm.annotation.i8(i8 <val>, i8* <str>, i8* <str>, i32 <int> ) - declare i16 @llvm.annotation.i16(i16 <val>, i8* <str>, i8* <str>, i32 <int> ) - declare i32 @llvm.annotation.i32(i32 <val>, i8* <str>, i8* <str>, i32 <int> ) - declare i64 @llvm.annotation.i64(i64 <val>, i8* <str>, i8* <str>, i32 <int> ) - declare i256 @llvm.annotation.i256(i256 <val>, i8* <str>, i8* <str>, i32 <int> ) + declare i8 @llvm.annotation.i8(i8 <val>, i8* <str>, i8* <str>, i32 <int>) + declare i16 @llvm.annotation.i16(i16 <val>, i8* <str>, i8* <str>, i32 <int>) + declare i32 @llvm.annotation.i32(i32 <val>, i8* <str>, i8* <str>, i32 <int>) + declare i64 @llvm.annotation.i64(i64 <val>, i8* <str>, i8* <str>, i32 <int>) + declare i256 @llvm.annotation.i256(i256 <val>, i8* <str>, i8* <str>, i32 <int>)Overview:
@@ -7243,7 +7675,7 @@ LLVM.Syntax:
- declare void @llvm.stackprotector( i8* <guard>, i8** <slot> ) + declare void @llvm.stackprotector(i8* <guard>, i8** <slot>)Overview:
@@ -7268,6 +7700,42 @@ LLVM.+ ++Syntax:
++ declare i32 @llvm.objectsize.i32(i8* <object>, i1 <type>) + declare i64 @llvm.objectsize.i64(i8* <object>, i1 <type>) ++ +Overview:
+The llvm.objectsize intrinsic is designed to provide information + to the optimizers to discover at compile time either a) when an + operation like memcpy will either overflow a buffer that corresponds to + an object, or b) to determine that a runtime check for overflow isn't + necessary. An object in this context means an allocation of a + specific class, structure, array, or other object.
+ +Arguments:
+The llvm.objectsize intrinsic takes two arguments. The first + argument is a pointer to or into the object. The second argument + is a boolean 0 or 1. This argument determines whether you want the + maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or + 1, variables are not allowed.
+ +Semantics:
+The llvm.objectsize intrinsic is lowered to either a constant + representing the size of the object concerned or i32/i64 -1 or 0 + (depending on the type argument if the size cannot be determined + at compile time.
+ +