+%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 @@ -428,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:
@@ -489,28 +490,26 @@ 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 + 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, @@ -538,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 @@ -823,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-
+define [linkage] [visibility] [cconv] [ret attrs] <ResultType> @<FunctionName> ([argument list]) [fn Attrs] [section "name"] [align N] [gc] { ... }-
+@<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 + nodes (but not metadata strings) are the only valid operands for a named metadata.
+
+; Some unnamed metadata nodes, which are referenced by the named metadata.
+!0 = metadata !{metadata !"zero"}
!1 = metadata !{metadata !"one"}
-!name = !{null, !1}
+!2 = metadata !{metadata !"two"}
+; A named metadata.
+!name = !{!0, !1, !2}
-+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.
@@ -1005,7 +1024,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 @@ -1073,14 +1102,12 @@ 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 @@ -1214,11 +1239,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 @@ -1251,8 +1274,10 @@ target datalayout = "layout specification"
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:
@@ -1328,34 +1353,46 @@ is undefined. Pointer values are associated with address ranges according to the following rules: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.
@@ -1367,6 +1404,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.
+ ++@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 @@ -2153,13 +2202,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: @@ -2169,7 +2216,6 @@ 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 @@ -2180,8 +2226,7 @@ optimize the and to 0. Likewise, it is safe to assume that all the bits of the undef operand to the or could be set, allowing the or to be folded to -1.
-+%A = select undef, %X, %Y %B = select undef, 42, %Y %C = select %X, %Y, undef @@ -2194,7 +2239,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 @@ -2204,8 +2248,7 @@ the optimizer is allowed to assume that the undef operand could be the same as %Y, allowing the whole select to be eliminated.
-+%A = xor undef, undef %B = undef @@ -2223,7 +2266,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 @@ -2236,15 +2278,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 @@ -2259,15 +2299,13 @@ 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 @@ -2277,6 +2315,111 @@ 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). ++ +
+i32 (i32) asm "bswap $0", "=r,r"-
Inline assembler expressions may only be used as the callee operand of a call instruction. Thus, typically we have:
-+%X = call i32 asm "bswap $0", "=r,r"(i32 %Y)-
Inline asms with side effects not visible in the constraint list must be marked as having side effects. This is done through the use of the 'sideeffect' keyword, like so:
-+call void asm sideeffect "eieio", ""()-
In some cases inline asms will contain code that will not work unless the stack is aligned in some way, such as calls or SSE instructions on x86, @@ -2478,11 +2625,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.
@@ -2491,6 +2636,29 @@ 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.
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 +@@ -2595,8 +2776,12 @@ should not be exposed to source languages.
TODO: Describe this.
+
+%0 = type { i32, void ()* }
+@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }]
+
+The @llvm.global_ctors array contains a list of constructor functions and associated priorities. The functions referenced by this array will be called in ascending order of priority (i.e. lowest first) when the module is loaded. The order of functions with the same priority is not defined. +
+%0 = type { i32, void ()* }
+@llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }]
+
-TODO: Describe this.
+The @llvm.global_dtors array contains a list of destructor functions and associated priorities. The functions referenced by this array will be called in descending order of priority (i.e. highest first) when the module is loaded. The order of functions with the same priority is not defined. +
There are six different terminator instructions: the +
There are seven different terminator instructions: the 'ret' instruction, the 'br' instruction, the 'switch' instruction, the @@ -2888,9 +3078,10 @@ IfUnequal: function to be invoked.
nuw and nsw stand for "No Unsigned Wrap" and "No Signed Wrap", respectively. If the nuw and/or nsw keywords are present, the result value of the add - is undefined if unsigned and/or signed overflow, respectively, occurs.
+ is a trap value if unsigned and/or signed overflow, + respectively, occurs.@@ -3116,7 +3308,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:
@@ -3202,7 +3395,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:
@@ -3307,8 +3501,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:
@@ -4027,7 +4221,7 @@ InstructionSyntax:
- <result> = alloca <type>[, i32 <NumElements>][, align <alignment>] ; yields {type*}:result + <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>] ; yields {type*}:resultOverview:
@@ -4090,9 +4284,8 @@ 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 operation (that is, the alignment of the memory address). A value of 0 or an @@ -4136,8 +4329,8 @@ Instruction
Syntax:
- store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !] ; yields {void} - volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal ! ] ; yields {void} + store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] ; yields {void} + volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] ; yields {void} Overview:
@@ -4148,11 +4341,10 @@ Instruction and an address at which to store it. The type of the '<pointer>' operand must be a pointer to the first class type of the - '<value>' operand. If the store is marked - as volatile, then the optimizer is not allowed to modify the number - or order of execution of this store with other - volatile load and store - instructions. + '<value>' operand. If the store is marked as + volatile, then the optimizer is not allowed to modify the number or + order of execution of this store with other volatile operations.The optional constant "align" argument specifies the alignment of the operation (that is, the alignment of the memory address). A value of 0 or an @@ -4163,7 +4355,7 @@ Instruction produce less efficient code. An alignment of 1 is always safe.
The optional !nontemporal metadata must reference a single metatadata - name
corresponding to a metadata node with one i32 entry of + 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 @@ -4230,8 +4422,7 @@ Instruction For example, let's consider a C code fragment and how it gets compiled to LLVM:
--+struct RT { char A; int B[10][20]; @@ -4247,12 +4438,10 @@ int *foo(struct ST *s) { return &s[1].Z.B[5][13]; }-The LLVM code generated by the GCC frontend is:
--+%RT = type { i8 , [10 x [20 x i32]], i8 } %ST = type { i32, double, %RT } @@ -4262,7 +4451,6 @@ entry: ret i32* %reg }-Semantics:
In the example above, the first index is indexing into the '%ST*' @@ -4291,13 +4479,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 @@ -5132,8 +5321,11 @@ Loop: ; Infinite loop that counts from 0 on up... 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. As of this writing, the extra requirements for - a call to actually be optimized are: + 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:
%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) @@ -5329,8 +5521,7 @@ freestanding environments and non-C-based languages. instruction and the variable argument handling intrinsic functions are used. --@@ -5625,7 +5815,7 @@ LLVM.+define i32 @test(i32 %X, ...) { ; Initialize variable argument processing %ap = alloca i8* @@ -5355,7 +5546,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:
@@ -5659,7 +5849,7 @@ LLVM.Syntax:
- declare i8 *@llvm.stacksave() + declare i8* @llvm.stacksave()Overview:
@@ -5689,7 +5879,7 @@ LLVM.Syntax:
- declare void @llvm.stackrestore(i8 * %ptr) + declare void @llvm.stackrestore(i8* %ptr)Overview:
@@ -5778,7 +5968,7 @@ LLVM.Syntax:
- declare i64 @llvm.readcyclecounter( ) + declare i64 @llvm.readcyclecounter()Overview:
@@ -5819,17 +6009,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:
@@ -5837,19 +6024,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 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 @@ -5867,17 +6063,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:
@@ -5887,19 +6080,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 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 @@ -5917,17 +6119,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. However, not all targets support all + bit widths.- 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:
@@ -5935,18 +6134,24 @@ 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 and takes extra alignment/volatile + arguments. Also, 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 - byte value to fill it with, the third argument is an integer argument + byte value with which to fill it, the third argument is an integer argument specifying the number of bytes to fill, and the fourth argument is the known - alignment of destination location.
+ alignment of the destination location.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 @@ -6566,6 +6771,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 @@ -6602,7 +6898,8 @@ LLVM.@@ -6704,7 +6999,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 @@ -6614,17 +6911,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:
@@ -6761,7 +7056,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 @@ -6781,10 +7076,10 @@ LLVM. 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> ) + 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:
@@ -6813,13 +7108,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 @@ -6839,10 +7134,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:
@@ -6869,13 +7164,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 @@ -6897,10 +7192,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:
@@ -6923,11 +7218,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 @@ -6948,10 +7243,10 @@ 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:
@@ -6975,11 +7270,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 @@ -7004,31 +7299,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:
@@ -7053,13 +7348,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 @@ -7083,31 +7378,31 @@ 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:
@@ -7132,13 +7427,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 @@ -7293,7 +7588,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:
@@ -7324,11 +7619,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:
@@ -7382,7 +7677,7 @@ LLVM.Syntax:
- declare void @llvm.stackprotector( i8* <guard>, i8** <slot> ) + declare void @llvm.stackprotector(i8* <guard>, i8** <slot>)Overview:
@@ -7416,8 +7711,8 @@ LLVM.Syntax:
- declare i32 @llvm.objectsize.i32( i8* <object>, i1 <type> ) - declare i64 @llvm.objectsize.i64( i8* <object>, i1 <type> ) + declare i32 @llvm.objectsize.i32(i8* <object>, i1 <type>) + declare i64 @llvm.objectsize.i64(i8* <object>, i1 <type>)Overview: