Aliases act as "second name" for the aliasee value (which can be either - function or global variable or bitcast of global value). Aliases may have an - optional linkage type, and an + function, global variable, another alias or bitcast of global value). Aliases + may have an optional linkage type, and an optional visibility style.
The function type can be thought of as a function signature. It -consists of a return type and a list of formal parameter types. -Function types are usually used to build virtual function tables +consists of a return type and a list of formal parameter types. The +return type of a function type is a scalar type or 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. Function types are usually used to build virtual function tables (which are structures of pointers to functions), for indirect function calls, and when defining a function.
--The return type of a function type cannot be an aggregate type. -
+<returntype> (<parameter list>)+
<returntype list> (<parameter list>)
...where '<parameter list>' is a comma-separated list of type specifiers. Optionally, the parameter list may include a type ..., 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.
+ href="#int_varargs">variable argument handling intrinsic functions. +'<returntype list>' is a comma-separated list of +first class type specifiers.| {i32, i32} (i32) | +A function taking an i32>, returning two + i32 values as an aggregate of type { i32, i32 } + |
ret <type> <value> ; Return a value from a non-void function ret void ; Return from void function + ret <type> <value>, <type> <value> ; Return two values from a non-void function
The 'ret' instruction is used to return control flow (and a @@ -1785,11 +1809,11 @@ value) from a function back to the caller.
returns a value and then causes control flow, and one that just causes control flow to occur.The 'ret' instruction may return any 'first class' type. Notice that a function is -not well formed if there exists a 'ret' -instruction inside of the function that returns a value that does not -match the return type of the function.
+The 'ret' instruction may return one or multiple values. The +type of each return value must be a 'first class' + type. Note that a function is not well formed +if there exists a 'ret' instruction inside of the function that +returns values that do not match the return type of the function.
When the 'ret' instruction is executed, control flow returns back to the calling function's context. If the caller is a "invoke" instruction, execution continues at the beginning of the "normal" destination block. If the instruction returns a value, that value shall set the call or invoke instruction's -return value.
+return value. If the instruction returns multiple values then these +values can only be accessed through a 'getresult +' instruction.ret i32 5 ; Return an integer value of 5 ret void ; Return from a void function + ret i32 4, i8 2 ; Return two values 4 and 2
- <result> = invoke [cconv] <ptr to function ty> %<function ptr val>(<function args>) + <result> = invoke [cconv] <ptr to function ty> <function ptr val>(<function args>) to label <normal label> unwind label <exception label>@@ -1911,7 +1938,9 @@ function, with the possibility of control flow transfer to either the "ret" instruction, control flow will return to the "normal" label. If the callee (or any indirect callees) returns with the "unwind" instruction, control is interrupted and -continued at the dynamically nearest "exception" label. +continued at the dynamically nearest "exception" label. If the callee function +returns multiple values then individual return values are only accessible through +a 'getresult' instruction.
- %retval = invoke i32 %Test(i32 15) to label %Continue
+ %retval = invoke i32 @Test(i32 15) to label %Continue
unwind label %TestCleanup ; {i32}:retval set
- %retval = invoke coldcc i32 %Test(i32 15) to label %Continue
+ %retval = invoke coldcc i32 %Testfnptr(i32 15) to label %Continue
unwind label %TestCleanup ; {i32}:retval set
@@ -2026,11 +2055,10 @@ no-return function cannot be reached, and other facts.
Binary operators are used to do most of the computation in a -program. They require two operands, execute an operation on them, and +program. They require two operands of the same type, execute an operation on them, and produce a single value. The operands might represent multiple data, as is the case with the vector data type. -The result value of a binary operator is not -necessarily the same type as its operands.
+The result value has the same type as its operands.There are several different binary operators:
The value produced is the integer or floating point sum of the two operands.
+If an integer sum has unsigned overflow, the result returned is the +mathematical result modulo 2n, where n is the bit width of +the result.
+Because LLVM integers use a two's complement representation, this +instruction is appropriate for both signed and unsigned integers.
<result> = add i32 4, %var ; yields {i32}:result = 4 + %var
@@ -2075,6 +2108,11 @@ Both arguments must have identical types.
The value produced is the integer or floating point difference of the two operands.
+If an integer difference has unsigned overflow, the result returned is the +mathematical result modulo 2n, where n is the bit width of +the result.
+Because LLVM integers use a two's complement representation, this +instruction is appropriate for both signed and unsigned integers.
<result> = sub i32 4, %var ; yields {i32}:result = 4 - %var
@@ -2100,9 +2138,15 @@ Both arguments must have identical types.
Semantics:
The value produced is the integer or floating point product of the
two operands.
-Because the operands are the same width, the result of an integer
-multiplication is the same whether the operands should be deemed unsigned or
-signed.
+If the result of an integer multiplication has unsigned overflow,
+the result returned is the mathematical result modulo
+2n, where n is the bit width of the result.
+Because LLVM integers use a two's complement representation, and the
+result is the same width as the operands, this instruction returns the
+correct result for both signed and unsigned integers. If a full product
+(e.g. i32xi32->i64) is needed, the operands
+should be sign-extended or zero-extended as appropriate to the
+width of the full product.
Example:
<result> = mul i32 4, %var ; yields {i32}:result = 4 * %var
@@ -2123,9 +2167,10 @@ operands.
types. This instruction can also take vector versions
of the values in which case the elements must be integers.
Semantics:
-The value produced is the unsigned integer quotient of the two operands. This
-instruction always performs an unsigned division operation, regardless of
-whether the arguments are unsigned or not.
+The value produced is the unsigned integer quotient of the two operands.
+Note that unsigned integer division and signed integer division are distinct
+operations; for signed integer division, use 'sdiv'.
+Division by zero leads to undefined behavior.
Example:
<result> = udiv i32 4, %var ; yields {i32}:result = 4 / %var
@@ -2146,9 +2191,12 @@ operands.
types. This instruction can also take vector versions
of the values in which case the elements must be integers.
Semantics:
-The value produced is the signed integer quotient of the two operands. This
-instruction always performs a signed division operation, regardless of whether
-the arguments are signed or not.
+The value produced is the signed integer quotient of the two operands rounded towards zero.
+Note that signed integer division and unsigned integer division are distinct
+operations; for unsigned integer division, use 'udiv'.
+Division by zero leads to undefined behavior. Overflow also leads to
+undefined behavior; this is a rare case, but can occur, for example,
+by doing a 32-bit division of -2147483648 by -1.
Example:
<result> = sdiv i32 4, %var ; yields {i32}:result = 4 / %var
@@ -2191,8 +2239,10 @@ types. This instruction can also take vector versions
of the values in which case the elements must be integers.
Semantics:
This instruction returns the unsigned integer remainder of a division.
-This instruction always performs an unsigned division to get the remainder,
-regardless of whether the arguments are unsigned or not.
+This instruction always performs an unsigned division to get the remainder.
+Note that unsigned integer remainder and signed integer remainder are
+distinct operations; for signed integer remainder, use 'srem'.
+Taking the remainder of a division by zero leads to undefined behavior.
Example:
<result> = urem i32 4, %var ; yields {i32}:result = 4 % %var
@@ -2224,6 +2274,14 @@ a value. For more information about the difference, see . For a table of how this is implemented in various languages,
please see
Wikipedia: modulo operation.
+Note that signed integer remainder and unsigned integer remainder are
+distinct operations; for unsigned integer remainder, use 'urem'.
+Taking the remainder of a division by zero leads to undefined behavior.
+Overflow also leads to undefined behavior; this is a rare case, but can occur,
+for example, by taking the remainder of a 32-bit division of -2147483648 by -1.
+(The remainder doesn't actually overflow, but this rule lets srem be
+implemented using instructions that return both the result of the division
+and the remainder.)
Example:
<result> = srem i32 4, %var ; yields {i32}:result = 4 % %var
@@ -2245,7 +2303,8 @@ division of its two operands.
identical types. This instruction can also take vector
versions of floating point values.
Semantics:
-This instruction returns the remainder of a division.
+This instruction returns the remainder of a division.
+The remainder has the same sign as the dividend.
Example:
<result> = frem float 4.0, %var ; yields {float}:result = 4.0 % %var
@@ -2258,9 +2317,8 @@ Operations
Bitwise binary operators are used to do various forms of
bit-twiddling in a program. They are generally very efficient
instructions and can commonly be strength reduced from other
-instructions. They require two operands, execute an operation on them,
-and produce a single value. The resulting value of the bitwise binary
-operators is always the same type as its first operand.
+instructions. They require two operands of the same type, execute an operation on them,
+and produce a single value. The resulting value is the same type as its operands.
@@ -2283,9 +2341,9 @@ the left a specified number of bits.
Semantics:
-The value produced is var1 * 2var2. If
-var2 is (statically or dynamically) equal to or larger than the number
-of bits in var1, the result is undefined.
+The value produced is var1 * 2var2 mod 2n,
+where n is the width of the result. If var2 is (statically or dynamically) negative or
+equal to or larger than the number of bits in var1, the result is undefined.
Example:
<result> = shl i32 4, %var ; yields {i32}: 4 << %var
@@ -2728,17 +2786,18 @@ address space (address space zero).
sizeof(<type>)*NumElements
bytes of memory from the operating system and returns a pointer of the
appropriate type to the program. If "NumElements" is specified, it is the
-number of elements allocated. If an alignment is specified, the value result
-of the allocation is guaranteed to be aligned to at least that boundary. If
-not specified, or if zero, the target can choose to align the allocation on any
-convenient boundary.
+number of elements allocated, otherwise "NumElements" is defaulted to be one.
+If a constant alignment is specified, the value result of the allocation is guaranteed to
+be aligned to at least that boundary. If not specified, or if zero, the target can
+choose to align the allocation on any convenient boundary.
'type' must be a sized type.
Semantics:
Memory is allocated using the system "malloc" function, and
-a pointer is returned.
+a pointer is returned. Allocating zero bytes is undefined. The result is null
+if there is insufficient memory available.
Example:
@@ -2780,7 +2839,8 @@ instruction.
Semantics:
Access to the memory pointed to by the pointer is no longer defined
-after this instruction executes.
+after this instruction executes. If the pointer is null, the result is
+undefined.
Example:
@@ -2814,11 +2874,11 @@ space (address space zero).
The 'alloca' instruction allocates sizeof(<type>)*NumElements
bytes of memory on the runtime stack, returning a pointer of the
-appropriate type to the program. If "NumElements" is specified, it is the
-number of elements allocated. If an alignment is specified, the value result
-of the allocation is guaranteed to be aligned to at least that boundary. If
-not specified, or if zero, the target can choose to align the allocation on any
-convenient boundary.
+appropriate type to the program. If "NumElements" is specified, it is the
+number of elements allocated, otherwise "NumElements" is defaulted to be one.
+If a constant alignment is specified, the value result of the allocation is guaranteed
+to be aligned to at least that boundary. If not specified, or if zero, the target
+can choose to align the allocation on any convenient boundary.
'type' may be any sized type.
@@ -2829,7 +2889,8 @@ memory is automatically released when the function returns. The 'allocaret or unwind
-instructions), the memory is reclaimed.
+instructions), the memory is reclaimed. Allocating zero bytes
+is legal, but the result is undefined.
Example:
@@ -2858,7 +2919,7 @@ the number or order of execution of this load with other
volatile load and store
instructions.
-The optional "align" argument specifies the alignment of the operation
+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
alignment for the target. It is the responsibility of the code emitter
@@ -2889,13 +2950,14 @@ Instruction
Arguments:
There are two arguments to the 'store' instruction: a value
to store and an address at which to store it. The type of the '<pointer>'
-operand must be a pointer to the type of the '<value>'
+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.
-The optional "align" argument specifies the alignment of the operation
+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
alignment for the target. It is the responsibility of the code emitter
@@ -2985,8 +3047,8 @@ entry:
on the pointer type that is being indexed into. Pointer
and array types can use a 32-bit or 64-bit
integer type but the value will always be sign extended
-to 64-bits. Structure types require i32
-constants.
+to 64-bits. Structure and packed
+structure types require i32 constants.
In the example above, the first index is indexing into the '%ST*'
type, which is a pointer, yielding a '%ST' = '{ i32, double, %RT
@@ -3494,7 +3556,7 @@ instructions, which defy better classification.
Overview:
The 'icmp' instruction returns a boolean value based on comparison
-of its two integer operands.
+of its two integer or pointer operands.
Arguments:
The 'icmp' instruction takes three operands. The first operand is
the condition code indicating the kind of comparison to perform. It is not
@@ -3768,17 +3830,23 @@ transfer to a specified function, with its incoming arguments bound to
the specified values. Upon a 'ret'
instruction in the called function, control flow continues with the
instruction after the function call, and the return value of the
-function is bound to the result argument. This is a simpler case of
-the invoke instruction.
+function is bound to the result argument. If the callee returns multiple
+values then the return values of the function are only accessible through
+the 'getresult' instruction.
Example:
%retval = call i32 @test(i32 %argc)
- call i32 (i8 *, ...)* @printf(i8 * %msg, i32 12, i8 42);
- %X = tail call i32 @foo()
- %Y = tail call fastcc i32 @foo()
- %Z = call void %foo(i8 97 signext)
+ 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)
+
+ %struct.A = type { i32, i8 }
+ %r = call %struct.A @foo() ; yields { 32, i8 }
+ %gr = getresult %struct.A %r, 0 ; yields i32
+ %gr1 = getresult %struct.A %r, 1 ; yields i8
@@ -3831,6 +3899,51 @@ argument.
+
+
+
+
+
+Syntax:
+
+ <resultval> = getresult <type> <retval>, <index>
+
+
+Overview:
+
+ The 'getresult' instruction is used to extract individual values
+from a 'call'
+or 'invoke' instruction that returns multiple
+results.
+
+Arguments:
+
+The 'getresult' instruction takes a call or invoke value as its
+first argument. The value must have structure type.
+The second argument is a constant unsigned index value which must be in range for
+the number of values returned by the call.
+
+Semantics:
+
+The 'getresult' instruction extracts the element identified by
+'index' from the aggregate value.
+
+Example:
+
+
+ %struct.A = type { i32, i8 }
+
+ %r = call %struct.A @foo()
+ %gr = getresult %struct.A %r, 0 ; yields i32:%gr
+ %gr1 = getresult %struct.A %r, 1 ; yields i8:%gr1
+ add i32 %gr, 42
+ add i8 %gr1, 41
+
+
+
+
@@ -4645,7 +4758,9 @@ types however.
The 'llvm.sqrt' intrinsics return the sqrt of the specified operand,
returning the same value as the libm 'sqrt' functions would. Unlike
sqrt in libm, however, llvm.sqrt has undefined behavior for
-negative numbers (which allows for better optimization).
+negative numbers other than -0.0 (which allows for better optimization, because
+there is no need to worry about errno being set). llvm.sqrt(-0.0) is
+defined to return -0.0 like IEEE sqrt.
Arguments:
@@ -5198,6 +5313,277 @@ declare i8* @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <n
+
+
+
+
+
+ These intrinsic functions expand the "universal IR" of LLVM to represent
+ hardware constructs for atomic operations and memory synchronization. This
+ provides an interface to the hardware, not an interface to the programmer. It
+ is aimed at a low enough level to allow any programming models or APIs which
+ need atomic behaviors to map cleanly onto it. It is also modeled primarily on
+ hardware behavior. Just as hardware provides a "universal IR" for source
+ languages, it also provides a starting point for developing a "universal"
+ atomic operation and synchronization IR.
+
+
+ These do not form an API such as high-level threading libraries,
+ software transaction memory systems, atomic primitives, and intrinsic
+ functions as found in BSD, GNU libc, atomic_ops, APR, and other system and
+ application libraries. The hardware interface provided by LLVM should allow
+ a clean implementation of all of these APIs and parallel programming models.
+ No one model or paradigm should be selected above others unless the hardware
+ itself ubiquitously does so.
+
+
+
+
+
+
+
+Syntax:
+
+declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>,
+i1 <device> )
+
+
+Overview:
+
+ The llvm.memory.barrier intrinsic guarantees ordering between
+ specific pairs of memory access types.
+
+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 memory.
+
+
+
+ - ll: load-load barrier
+ - ls: load-store barrier
+ - sl: store-load barrier
+ - ss: store-store barrier
+ - device: barrier applies to device and uncached memory also.
+
+Semantics:
+
+ This intrinsic causes the system to enforce some ordering constraints upon
+ the loads and stores of the program. This barrier does not indicate
+ when any events will occur, it only enforces an order in
+ which they occur. For any of the specified pairs of load and store operations
+ (f.ex. load-load, or store-load), all of the first operations preceding the
+ barrier will complete before any of the second operations succeeding the
+ barrier begin. Specifically the semantics for each pairing is as follows:
+
+
+ - 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
+ store after the barrier begins.
+ - 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
+ load after the barrier begins.
+
+
+ These semantics are applied with a logical "and" behavior when more than one
+ is enabled in a single memory barrier intrinsic.
+
+
+ Backends may implement stronger barriers than those requested when they do not
+ support as fine grained a barrier as requested. Some architectures do not
+ need all types of barriers and on such architectures, these become noops.
+
+Example:
+
+%ptr = malloc i32
+ store i32 4, %ptr
+
+%result1 = load i32* %ptr ; yields {i32}:result1 = 4
+ call void @llvm.memory.barrier( i1 false, i1 true, i1 false, i1 false )
+ ; guarantee the above finishes
+ store i32 8, %ptr ; before this begins
+
+
+
+
+
+
+Syntax:
+
+ This is an overloaded intrinsic. You can use llvm.atomic.lcs on any
+ integer bit width. Not all targets support all bit widths however.
+
+
+declare i8 @llvm.atomic.lcs.i8( i8* <ptr>, i8 <cmp>, i8 <val> )
+declare i16 @llvm.atomic.lcs.i16( i16* <ptr>, i16 <cmp>, i16 <val> )
+declare i32 @llvm.atomic.lcs.i32( i32* <ptr>, i32 <cmp>, i32 <val> )
+declare i64 @llvm.atomic.lcs.i64( i64* <ptr>, i64 <cmp>, i64 <val> )
+
+
+Overview:
+
+ This loads a value in memory and compares it to a given value. If they are
+ equal, it stores a new value into the memory.
+
+Arguments:
+
+ The llvm.atomic.lcs intrinsic takes three arguments. The result as
+ well as both cmp and val must be integer values with the
+ same bit width. The ptr argument must be a pointer to a value of
+ this integer type. While any bit width integer may be used, targets may only
+ lower representations they support in hardware.
+
+
+Semantics:
+
+ This entire intrinsic must be executed atomically. It first loads the value
+ in memory pointed to by ptr and compares it with the value
+ cmp. If they are equal, val is stored into the memory. The
+ loaded value is yielded in all cases. This provides the equivalent of an
+ atomic compare-and-swap operation within the SSA framework.
+
+Examples:
+
+
+%ptr = malloc i32
+ store i32 4, %ptr
+
+%val1 = add i32 4, 4
+%result1 = call i32 @llvm.atomic.lcs.i32( 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.lcs.i32( i32* %ptr, i32 5, %val2 )
+ ; yields {i32}:result2 = 8
+%stored2 = icmp eq i32 %result2, 5 ; yields {i1}:stored2 = false
+
+%memval2 = load i32* %ptr ; yields {i32}:memval2 = 8
+
+
+
+
+
+
+Syntax:
+
+
+ This is an overloaded intrinsic. You can use llvm.atomic.swap on any
+ integer bit width. Not all targets support all bit widths however.
+
+declare i8 @llvm.atomic.swap.i8( i8* <ptr>, i8 <val> )
+declare i16 @llvm.atomic.swap.i16( i16* <ptr>, i16 <val> )
+declare i32 @llvm.atomic.swap.i32( i32* <ptr>, i32 <val> )
+declare i64 @llvm.atomic.swap.i64( i64* <ptr>, i64 <val> )
+
+
+Overview:
+
+ This intrinsic loads the value stored in memory at ptr and yields
+ the value from memory. It then stores the value in val in the memory
+ at ptr.
+
+Arguments:
+
+
+ The llvm.atomic.ls intrinsic takes two arguments. Both the
+ val argument and the result must be integers of the same bit width.
+ The first argument, ptr, must be a pointer to a value of this
+ integer type. The targets may only lower integer representations they
+ support.
+
+Semantics:
+
+ This intrinsic loads the value pointed to by ptr, yields it, and
+ stores val back into ptr atomically. This provides the
+ equivalent of an atomic swap operation within the SSA framework.
+
+
+Examples:
+
+%ptr = malloc i32
+ store i32 4, %ptr
+
+%val1 = add i32 4, 4
+%result1 = call i32 @llvm.atomic.swap.i32( 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( i32* %ptr, i32 %val2 )
+ ; yields {i32}:result2 = 8
+
+%stored2 = icmp eq i32 %result2, 8 ; yields {i1}:stored2 = true
+%memval2 = load i32* %ptr ; yields {i32}:memval2 = 2
+
+
+
+
+
+
+Syntax:
+
+ This is an overloaded intrinsic. You can use llvm.atomic.las on any
+ integer bit width. Not all targets support all bit widths however.
+
+declare i8 @llvm.atomic.las.i8.( i8* <ptr>, i8 <delta> )
+declare i16 @llvm.atomic.las.i16.( i16* <ptr>, i16 <delta> )
+declare i32 @llvm.atomic.las.i32.( i32* <ptr>, i32 <delta> )
+declare i64 @llvm.atomic.las.i64.( i64* <ptr>, i64 <delta> )
+
+
+Overview:
+
+ This intrinsic adds delta to the value stored in memory at
+ ptr. It yields the original value at ptr.
+
+Arguments:
+
+
+ The intrinsic takes two arguments, the first a pointer to an integer value
+ and the second an integer value. The result is also an integer value. These
+ integer types can have any bit width, but they must all have the same bit
+ width. The targets may only lower integer representations they support.
+
+Semantics:
+
+ This intrinsic does a series of operations atomically. It first loads the
+ value stored at ptr. It then adds delta, stores the result
+ to ptr. It yields the original value stored at ptr.
+
+
+Examples:
+
+%ptr = malloc i32
+ store i32 4, %ptr
+%result1 = call i32 @llvm.atomic.las.i32( i32* %ptr, i32 4 )
+ ; yields {i32}:result1 = 4
+%result2 = call i32 @llvm.atomic.las.i32( i32* %ptr, i32 2 )
+ ; yields {i32}:result2 = 8
+%result3 = call i32 @llvm.atomic.las.i32( i32* %ptr, i32 5 )
+ ; yields {i32}:result3 = 10
+%memval = load i32* %ptr ; yields {i32}:memval1 = 15
+
+
+
+
General Intrinsics
@@ -5237,10 +5623,11 @@ file name, and the last argument is the line number.
Semantics:
-This intrinsic allows annotation of local variables with arbitrary strings.
+This intrinsic allows annotation of local variables with arbitrary strings.
This can be useful for special purpose optimizations that want to look for these
- annotations. These have no other defined use, they are ignored by code
- generation and optimization.
+annotations. These have no other defined use, they are ignored by code
+generation and optimization.
+
@@ -5286,6 +5673,39 @@ that want to look for these annotations. These have no other defined use, they
are ignored by code generation and optimization.
+
+
+
+
+
+Syntax:
+
+ declare void @llvm.trap()
+
+
+Overview:
+
+
+The 'llvm.trap' intrinsic
+
+
+Arguments:
+
+
+None
+
+
+Semantics:
+
+
+This intrinsics is lowered to the target dependent trap instruction. If the
+target does not have a trap instruction, this intrinsic will be lowered to the
+call of the abort() function.
+
+
+