This document is a reference manual for the LLVM assembly language. -LLVM is a Static Single Assignment (SSA) based representation that provides -type safety, low-level operations, flexibility, and the capability of -representing 'all' high-level languages cleanly. It is the common code -representation used throughout all phases of the LLVM compilation -strategy.
+ +This document is a reference manual for the LLVM assembly language. LLVM is + a Static Single Assignment (SSA) based representation that provides type + safety, low-level operations, flexibility, and the capability of representing + 'all' high-level languages cleanly. It is the common code representation + used throughout all phases of the LLVM compilation strategy.
+The LLVM code representation is designed to be used in three -different forms: as an in-memory compiler IR, as an on-disk bitcode -representation (suitable for fast loading by a Just-In-Time compiler), -and as a human readable assembly language representation. This allows -LLVM to provide a powerful intermediate representation for efficient -compiler transformations and analysis, while providing a natural means -to debug and visualize the transformations. The three different forms -of LLVM are all equivalent. This document describes the human readable -representation and notation.
+The LLVM code representation is designed to be used in three different forms: + as an in-memory compiler IR, as an on-disk bitcode representation (suitable + for fast loading by a Just-In-Time compiler), and as a human readable + assembly language representation. This allows LLVM to provide a powerful + intermediate representation for efficient compiler transformations and + analysis, while providing a natural means to debug and visualize the + transformations. The three different forms of LLVM are all equivalent. This + document describes the human readable representation and notation.
-The LLVM representation aims to be light-weight and low-level -while being expressive, typed, and extensible at the same time. It -aims to be a "universal IR" of sorts, by being at a low enough level -that high-level ideas may be cleanly mapped to it (similar to how -microprocessors are "universal IR's", allowing many source languages to -be mapped to them). By providing type information, LLVM can be used as -the target of optimizations: for example, through pointer analysis, it -can be proven that a C automatic variable is never accessed outside of -the current function... allowing it to be promoted to a simple SSA -value instead of a memory location.
+The LLVM representation aims to be light-weight and low-level while being + expressive, typed, and extensible at the same time. It aims to be a + "universal IR" of sorts, by being at a low enough level that high-level ideas + may be cleanly mapped to it (similar to how microprocessors are "universal + IR's", allowing many source languages to be mapped to them). By providing + type information, LLVM can be used as the target of optimizations: for + example, through pointer analysis, it can be proven that a C automatic + variable is never accessed outside of the current function, allowing it to + be promoted to a simple SSA value instead of a memory location.
It is important to note that this document describes 'well formed' -LLVM assembly language. There is a difference between what the parser -accepts and what is considered 'well formed'. For example, the -following instruction is syntactically okay, but not well formed:
+It is important to note that this document describes 'well formed' LLVM + assembly language. There is a difference between what the parser accepts and + what is considered 'well formed'. For example, the following instruction is + syntactically okay, but not well formed:
@@ -310,13 +367,13 @@ following instruction is syntactically okay, but not well formed:
...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 that an LLVM module is well formed. This pass is -automatically run by the parser after parsing input assembly and by -the optimizer before it outputs bitcode. The violations pointed out -by the verifier pass indicate bugs in transformation passes or input to -the parser.
+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 + that an LLVM module is well formed. This pass is automatically run by the + parser after parsing input assembly and by the optimizer before it outputs + bitcode. The violations pointed out by the verifier pass indicate bugs in + transformation passes or input to the parser.
+LLVM identifiers come in two basic types: global and local. Global - identifiers (functions, global variables) begin with the @ character. Local - identifiers (register names, types) begin with the % character. Additionally, - there are three different formats for identifiers, for different purposes:
+LLVM identifiers come in two basic types: global and local. Global + identifiers (functions, global variables) begin with the '@' + character. Local identifiers (register names, types) begin with + the '%' character. Additionally, there are three different formats + for identifiers, for different purposes:
LLVM requires that values start with a prefix for two reasons: Compilers -don't need to worry about name clashes with reserved words, and the set of -reserved words may be expanded in the future without penalty. Additionally, -unnamed identifiers allow a compiler to quickly come up with a temporary -variable without having to avoid symbol table conflicts.
+ don't need to worry about name clashes with reserved words, and the set of + reserved words may be expanded in the future without penalty. Additionally, + unnamed identifiers allow a compiler to quickly come up with a temporary + variable without having to avoid symbol table conflicts.Reserved words in LLVM are very similar to reserved words in other -languages. There are keywords for different opcodes -('add', - 'bitcast', - 'ret', etc...), for primitive type names ('void', 'i32', etc...), -and others. These reserved words cannot conflict with variable names, because -none of them start with a prefix character ('%' or '@').
+ languages. There are keywords for different opcodes + ('add', + 'bitcast', + 'ret', etc...), for primitive type names + ('void', + 'i32', etc...), and others. These + reserved words cannot conflict with variable names, because none of them + start with a prefix character ('%' or '@').Here is an example of LLVM code to multiply the integer variable -'%X' by 8:
+ '%X' by 8:The easy way:
@@ -386,31 +446,29 @@ none of them start with a prefix character ('%' or '@').-add i32 %X, %X ; yields {i32}:%0 -add i32 %0, %0 ; yields {i32}:%1 +%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:
+This last way of multiplying %X by 8 illustrates several important + lexical features of LLVM:
...and it also shows a convention that we follow in this document. When -demonstrating instructions, we will follow an instruction with a comment that -defines the type and name of value produced. Comments are shown in italic -text.
+It also shows a convention that we follow in this document. When + demonstrating instructions, we will follow an instruction with a comment that + defines the type and name of value produced. Comments are shown in italic + text.
LLVM programs are composed of "Module"s, each of which is a -translation unit of the input programs. Each module consists of -functions, global variables, and symbol table entries. Modules may be -combined together with the LLVM linker, which merges function (and -global variable) definitions, resolves forward declarations, and merges -symbol table entries. Here is an example of the "hello world" module:
+LLVM programs are composed of "Module"s, each of which is a translation unit + of the input programs. Each module consists of functions, global variables, + and symbol table entries. Modules may be combined together with the LLVM + linker, which merges function (and global variable) definitions, resolves + 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]* ++; 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 [13x i8 ]* to i8 *... - %cast210 = getelementptr [13 x i8 ]* @.LC0, i64 0, i64 0 ; i8 * +define i32 @main() { ; i32()* + ; Convert [13 x i8]* to 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 puts function to write out the string to stdout. + 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 a function definition -for "main".
+This example is made up of a global variable named + ".LC0", an external declaration of the "puts" function, + a function definition for + "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 -represented by a pointer to a memory location (in this case, a pointer to an -array of char, and a pointer to a function), and have one of the following linkage types.
+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 + represented by a pointer to a memory location (in this case, a pointer to an + array of char, and a pointer to a function), and have one of the + following linkage types.
-All Global Variables and Functions have one of the following types of linkage: -
+All Global Variables and Functions have one of the following types of + linkage:
- The next two types of linkage are targeted for Microsoft Windows platform - only. They are designed to support importing (exporting) symbols from (to) - DLLs (Dynamic Link Libraries). -
- -The next two types of linkage are targeted for Microsoft Windows platform + only. They are designed to support importing (exporting) symbols from (to) + DLLs (Dynamic Link Libraries).
+_imp__ and the function or variable name.
- __imp_ and the function or variable
+ name.
+ _imp__ and the function or variable
- name.
- __imp_ and the function or
+ variable name.
For example, since the ".LC0" -variable is defined to be internal, if another module defined a ".LC0" -variable and was linked with this one, one of the two would be renamed, -preventing a collision. Since "main" and "puts" are -external (i.e., lacking any linkage declarations), they are accessible -outside of the current module.
-It is illegal for a function declaration -to have any linkage type other than "externally visible", dllimport, -or extern_weak.
-Aliases can have only external, internal and weak -linkages.
+For example, since the ".LC0" variable is defined to be internal, if + another module defined a ".LC0" variable and was linked with this + one, one of the two would be renamed, preventing a collision. Since + "main" and "puts" are external (i.e., lacking any linkage + declarations), they are accessible outside of the current module.
+ +It is illegal for a function declaration to have any linkage type + other than "externally visible", dllimport + or extern_weak.
+ +Aliases can have only external, internal, weak + or weak_odr linkages.
+LLVM functions, calls -and invokes can all have an optional calling convention -specified for the call. The calling convention of any pair of dynamic -caller/callee must match, or the behavior of the program is undefined. The -following calling conventions are supported by LLVM, and more may be added in -the future:
+ and invokes can all have an optional calling + convention specified for the call. The calling convention of any pair of + dynamic caller/callee must match, or the behavior of the program is + undefined. The following calling conventions are supported by LLVM, and more + may be added in the future:More calling conventions can be added/defined on an as-needed basis, to -support pascal conventions or any other well-known target-independent -convention.
+ support Pascal conventions or any other well-known target-independent + convention.-All Global Variables and Functions have one of the following visibility styles: -
+All Global Variables and Functions have one of the following visibility + styles:
Global variables define regions of memory allocated at compilation time -instead of run-time. Global variables may optionally be initialized, may have -an explicit section to be placed in, and may have an optional explicit alignment -specified. A variable may be defined as "thread_local", which means that it -will not be shared by threads (each thread will have a separated copy of the -variable). A variable may be defined as a global "constant," which indicates -that the contents of the variable will never be modified (enabling better -optimization, allowing the global data to be placed in the read-only section of -an executable, etc). Note that variables that need runtime initialization -cannot be marked "constant" as there is a store to the variable.
- --LLVM explicitly allows declarations of global variables to be marked -constant, even if the final definition of the global is not. This capability -can be used to enable slightly better optimization of the program, but requires -the language definition to guarantee that optimizations based on the -'constantness' are valid for the translation units that do not include the -definition. -
+LLVM IR allows you to specify name aliases for certain types. This can make + it easier to read the IR and make the IR more condensed (particularly when + recursive types are involved). An example of a name specification is:
+ +
+%mytype = type { %mytype*, i32 }
+
+You may give a name to any type except + "void". Type name aliases may be used anywhere a type + is expected with the syntax "%mytype".
+ +Note that type names are aliases for the structural type that they indicate, + and that you can therefore specify multiple names for the same type. This + often leads to confusing behavior when dumping out a .ll file. Since LLVM IR + uses structural typing, the name is not part of the type. When printing out + LLVM IR, the printer will pick one name to render all types of a + particular shape. This means that if you have code where two different + source types end up having the same LLVM type, that the dumper will sometimes + print the "wrong" or unexpected type. This is an important design point and + isn't going to change.
+ +As SSA values, global variables define pointer values that are in -scope (i.e. they dominate) all basic blocks in the program. Global -variables always define a pointer to their "content" type because they -describe a region of memory, and all memory objects in LLVM are -accessed through pointers.
+A global variable may be declared to reside in a target-specifc numbered -address space. For targets that support them, address spaces may affect how -optimizations are performed and/or what target instructions are used to access -the variable. The default address space is zero. The address space qualifier -must precede any other attributes.
+Global variables define regions of memory allocated at compilation time + instead of run-time. Global variables may optionally be initialized, may + have an explicit section to be placed in, and may have an optional explicit + alignment specified. A variable may be defined as "thread_local", which + means that it will not be shared by threads (each thread will have a + separated copy of the variable). A variable may be defined as a global + "constant," which indicates that the contents of the variable + will never be modified (enabling better optimization, allowing the + global data to be placed in the read-only section of an executable, etc). + Note that variables that need runtime initialization cannot be marked + "constant" as there is a store to the variable.
+ +LLVM explicitly allows declarations of global variables to be marked + constant, even if the final definition of the global is not. This capability + can be used to enable slightly better optimization of the program, but + requires the language definition to guarantee that optimizations based on the + 'constantness' are valid for the translation units that do not include the + definition.
+ +As SSA values, global variables define pointer values that are in scope + (i.e. they dominate) all basic blocks in the program. Global variables + always define a pointer to their "content" type because they describe a + region of memory, and all memory objects in LLVM are accessed through + pointers.
+ +A global variable may be declared to reside in a target-specific numbered + address space. For targets that support them, address spaces may affect how + optimizations are performed and/or what target instructions are used to + access the variable. The default address space is zero. The address space + qualifier must precede any other attributes.
LLVM allows an explicit section to be specified for globals. If the target -supports it, it will emit globals to the section specified.
+ 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.
+ 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. -For example, the following defines a global in a numbered address space with -an initializer, section, and alignment:
+For example, the following defines a global in a numbered address space with + an initializer, section, and alignment:
-@G = constant float 1.0 addrspace(5), section "foo", align 4 +@G = addrspace(5) constant float 1.0, section "foo", align 4
LLVM function definitions consist of the "define" keyord, -an optional linkage type, 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) argument list (each with optional -parameter attributes), optional -function attributes, an optional section, -an optional alignment, an optional garbage collector name, -an opening curly brace, a list of basic blocks, and a closing curly brace. +
LLVM function definitions consist of the "define" keyord, an + optional linkage type, 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) argument list (each with optional + parameter attributes), optional + function attributes, an optional section, an optional + alignment, an optional garbage collector name, an opening + curly brace, a list of basic blocks, and a closing curly brace.
-LLVM function declarations consist of the "declare" keyword, an -optional linkage type, 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 optional -garbage collector name. +LLVM function declarations consist of the "declare" keyword, an + optional linkage type, 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 + optional garbage collector name.
A function definition contains a list of basic blocks, forming the CFG -(Control Flow Graph) for -the function. Each basic block may optionally start with a label (giving the -basic block a symbol table entry), contains a list of instructions, and ends -with a terminator instruction (such as a branch or -function return).
+ (Control Flow Graph) for the function. Each basic block may optionally start + with a label (giving the basic block a symbol table entry), contains a list + of instructions, and ends with a terminator + instruction (such as a branch or function return).The first basic block in a function is special in two ways: it is immediately -executed on entrance to the function, and it is not allowed to have predecessor -basic blocks (i.e. there can not be any branches to the entry block of a -function). Because the block can have no predecessors, it also cannot have any -PHI nodes.
+ executed on entrance to the function, and it is not allowed to have + predecessor basic blocks (i.e. there can not be any branches to the entry + block of a function). Because the block can have no predecessors, it also + cannot have any PHI nodes.LLVM allows an explicit section to be specified for functions. If the target -supports it, it will emit functions to the section specified.
+ supports it, it will emit functions to the section specified.An explicit alignment may be specified for a function. If not present, or if -the alignment is set to zero, the alignment of the function is set by the target -to whatever it feels convenient. If an explicit alignment is specified, the -function is forced to have at least that much alignment. All alignments must be -a power of 2.
- -Aliases act as "second name" for the aliasee value (which can be either - function, global variable, another alias or bitcast of global value). Aliases - may have an optional linkage type, and an - optional visibility style.
-Aliases act as "second name" for the aliasee value (which can be either + function, global variable, another alias or bitcast of global value). Aliases + may have an optional linkage type, and an + optional visibility style.
+@<Name> = alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee> @@ -823,83 +922,117 @@ define [linkage] [visibility]
Named metadata is a collection of metadata. Metadata + nodes (but not metadata strings) and null are the only valid operands for + a named metadata.
+
+!1 = metadata !{metadata !"one"}
+!name = !{null, !1}
+
+The return type and each parameter of a function type may have a set of - parameter attributes associated with them. Parameter attributes are - used to communicate additional information about the result or parameters of - a function. Parameter attributes are considered to be part of the function, - not of the function type, so functions with different parameter attributes - can have the same function type.
-Parameter attributes are simple keywords that follow the type specified. If - multiple parameter attributes are needed, they are space separated. For - example:
+The return type and each parameter of a function type may have a set of + parameter attributes associated with them. Parameter attributes are + used to communicate additional information about the result or parameters of + a function. Parameter attributes are considered to be part of the function, + not of the function type, so functions with different parameter attributes + can have the same function type.
+ +Parameter attributes are simple keywords that follow the type specified. If + multiple parameter attributes are needed, they are space separated. For + example:
-declare i32 @printf(i8* noalias , ...) +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.
- -Currently, only the following parameter attributes are defined:
-Note that any attributes for the function result (nounwind, + readonly) come immediately after the argument list.
+ +Currently, only the following parameter attributes are defined:
+ +Each function may specify a garbage collector name, which is simply a -string.
+ string: -define void @f() gc "name" { ...
+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 support -the named garbage collection algorithm.
+ collector which will cause the compiler to alter its output in order to + support the named garbage collection algorithm. +Function attributes are set to communicate additional information about - a function. Function attributes are considered to be part of the function, - not of the function type, so functions with different parameter attributes - can have the same function type.
+Function attributes are set to communicate additional information about a + function. Function attributes are considered to be part of the function, not + of the function type, so functions with different parameter attributes can + have the same function type.
-Function attributes are simple keywords that follow the type specified. If - multiple attributes are needed, they are space separated. For - example:
+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
+define void @f() optsize { ... }
-Modules may contain "module-level inline asm" blocks, which corresponds to the -GCC "file scope inline asm" blocks. These blocks are internally concatenated by -LLVM and treated as a single unit, but may be separated in the .ll file if -desired. The syntax is very simple: -
+ +Modules may contain "module-level inline asm" blocks, which corresponds to + the GCC "file scope inline asm" blocks. These blocks are internally + concatenated by LLVM and treated as a single unit, but may be separated in + the .ll file if desired. The syntax is very simple:
@@ -1025,13 +1196,11 @@ 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 - for the number. -
+ for the number. + +The inline asm code is simply printed to the machine code .s file when + assembly code is generated.
-- The inline asm code is simply printed to the machine code .s file when - assembly code is generated. -
A module may specify a target specific data layout string that specifies how -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 a -letter and may include other information after the letter to define some -aspect of the data layout. The specifications accepted are as follows:
+ 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 + a letter and may include other information after the letter to define some + aspect of the data layout. The specifications accepted are as follows:
+When constructing the data layout for a given target, LLVM starts with a -default set of specifications which are then (possibly) overriden by the -specifications in the datalayout keyword. The default specifications -are given in this list:
+ default set of specifications which are then (possibly) overriden by the + specifications in the datalayout keyword. The default specifications + are given in this list: +When LLVM is determining the alignment for a given type, it uses the -following rules:
+ +When LLVM is determining the alignment for a given type, it uses the + following rules:
+Any memory access must be done through a pointer value associated +with an address range of the memory access, otherwise the behavior +is undefined. Pointer values are associated with address ranges +according to the following rules:
+ +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 +store similarly only indicates the size +and alignment of the store.
+ +Consequently, type-based alias analysis, aka TBAA, aka +-fstrict-aliasing, is not applicable to general unadorned +LLVM IR. Metadata may be used to encode +additional information which specialized optimization passes may use +to implement type-based alias analysis.
+The LLVM type system is one of the most important features of the -intermediate representation. Being typed enables a number of -optimizations to be performed on the intermediate representation directly, -without having to do -extra analyses on the side before the transformation. A strong type -system makes it easier to read the generated code and enables novel -analyses and transformations that are not feasible to perform on normal -three address code representations.
+ intermediate representation. Being typed enables a number of optimizations + to be performed on the intermediate representation directly, without having + to do extra analyses on the side before the transformation. A strong type + system makes it easier to read the generated code and enables novel analyses + and transformations that are not feasible to perform on normal three address + code representations.The types fall into a few useful -classifications:
+ +The types fall into a few useful classifications:
| primitive | label, void, - floating point. | + floating point, + metadata.|
| derived | -integer, - array, + | array, function, pointer, structure, packed structure, + union, vector, opaque. | @@ -1177,18 +1437,55 @@ classifications:
The first class types are perhaps the -most important. Values of these types are the only ones which can be -produced by instructions, passed as arguments, or used as operands to -instructions.
+The first class types are perhaps the most + important. Values of these types are the only ones which can be produced by + instructions.
+The primitive types are the fundamental building blocks of the LLVM -system.
+ system. + +The integer type is a very simple type that simply specifies an arbitrary + bit width for the integer type desired. Any bit width from 1 bit to + 223-1 (about 8 million) can be specified.
+ ++ iN ++ +
The number of bits the integer will occupy is specified by the N + value.
+ +| i1 | +a single-bit integer. | +
| i32 | +a 32-bit integer. | +
| i1942652 | +a really big integer of over 1 million bits. | +
| Type | Description |
|---|---|
| float | 32-bit floating point value |
| double | 64-bit floating point value |
| fp128 | 128-bit floating point value (112-bit mantissa) |
| x86_fp80 | 80-bit floating point value (X87) |
| ppc_fp128 | 128-bit floating point value (two 64-bits) |
| Type | Description |
|---|---|
| float | 32-bit floating point value |
| double | 64-bit floating point value |
| fp128 | 128-bit floating point value (112-bit mantissa) |
| x86_fp80 | 80-bit floating point value (X87) |
| ppc_fp128 | 128-bit floating point value (two 64-bits) |
The void type does not represent any value and has no size.
void+
The label type represents code labels.
label+ +
The metadata type represents embedded metadata. No derived types may be + created from metadata except for function + arguments. + +
+ metadata ++
The real power in LLVM comes from the derived types in the system. -This is what allows a programmer to represent arrays, functions, -pointers, and other useful types. Note that these derived types may be -recursive: For example, it is possible to have a two dimensional array.
+The real power in LLVM comes from the derived types in the system. This is + what allows a programmer to represent arrays, functions, pointers, and other + useful types. Each of these types contain one or more element types which + may be a primitive type, or another derived type. For example, it is + possible to have a two dimensional array, using an array as the element type + of another array.
+The integer type is a very simple derived type that simply specifies an -arbitrary bit width for the integer type desired. Any bit width from 1 bit to -2^23-1 (about 8 million) can be specified.
- -- iN -+
Aggregate Types are a subset of derived types that can contain multiple + member types. Arrays, + structs, vectors and + unions are aggregate types.
-The number of bits the integer will occupy is specified by the N -value.
+| i1 | -a single-bit integer. | -
| i32 | -a 32-bit integer. | -
| i1942652 | -a really big integer of over 1 million bits. | -
The array type is a very simple derived type that arranges elements -sequentially in memory. The array type requires a size (number of -elements) and an underlying data type.
+ sequentially in memory. The array type requires a size (number of elements) + and an underlying data type.[<# elements> x <elementtype>]-
The number of elements is a constant integer value; elementtype may -be any type with a size.
+The number of elements is a constant integer value; elementtype may + be any type with a size.
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.
+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.
The 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.
+The 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, 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.
- <returntype list> (<parameter list>) + <returntype> (<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. -'<returntype list>' is a comma-separated list of -first class type specifiers.
+ 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. '<returntype>' is a any type except + label.The structure type is used to represent a collection of data members -together in memory. The packing of the field types is defined to match -the ABI of the 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.
+The structure type is used to represent a collection of data members together + in memory. The packing of the field types is defined to match the ABI of the + underlying processor. The elements of a structure may be any type that has a + size.
+ +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.
{ <type list> }
+
+ { <type list> }
+
+
The packed structure type is used to represent a collection of data members -together in memory. There is no padding between fields. Further, the alignment -of a packed structure is 1 byte. The elements of a packed 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.
+ together in memory. There is no padding between fields. Further, the + alignment of a packed structure is 1 byte. The elements of a packed + 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.
+ < { <type list> } >
+
+ < { <type list> } >
+
+
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.
+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.
+<type> *+
+ union { <type list> }
+
+
| [4x i32]* | -A pointer to array of four i32 values. | -||
| i32 (i32 *) * | -A pointer to a function that takes an i32*, returning an - i32. | -||
| i32 addrspace(5)* | -A pointer to an i32 value - that resides in address space #5. | +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. |
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.
-A 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 first class.
+Note that LLVM does not permit pointers to void (void*) nor does it + permit pointers to labels (label*). Use i8* instead.
+ <type> * ++ +
| [4 x i32]* | +A pointer to array of four i32 values. | +
| i32 (i32 *) * | +A pointer to a function that takes an i32*, returning an + i32. | +
| i32 addrspace(5)* | +A pointer to an i32 value + that resides in address space #5. | +
A 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. Vector types are considered + first class.
+ +< <# elements> x <elementtype> >-
The number of elements is a constant integer value; elementtype may -be any integer or floating point type.
+The number of elements is a constant integer value; elementtype may be any + integer or floating point type.
| <4 x i32> | @@ -1532,6 +1900,7 @@ be any integer or floating point type.Vector of 2 64-bit integer values. |
Opaque types are used to represent unknown types in the system. This -corresponds (for example) to the C notion of a forward declared structure type. -In LLVM, opaque types can eventually be resolved to any type (not just a -structure type).
+ corresponds (for example) to the C notion of a forward declared structure + type. In LLVM, opaque types can eventually be resolved to any type (not just + a structure type).opaque
| opaque | An opaque type. |
An "up reference" allows you to refer to a lexically enclosing type without + requiring it to have a name. For instance, a structure declaration may + contain a pointer to any of the types it is lexically a member of. Example + of up references (with their equivalent as named type declarations) + include:
+ +
+ { \2 * } %x = type { %x* }
+ { \2 }* %y = type { %y }*
+ \1* %z = type %z*
+
+
+An up reference is needed by the asmprinter for printing out cyclic types + when there is no declared name for a type in the cycle. Because the + asmprinter does not want to print out an infinite type string, it needs a + syntax to handle recursive types that have no names (all names are optional + in llvm IR).
+ ++ \<level> ++ +
The level is the count of the lexical type that is being referred to.
+ +| \1* | +Self-referential pointer. | +
| { { \3*, i8 }, i32 } | +Recursive structure where the upref refers to the out-most + structure. | +
LLVM has several different basic types of constants. This section describes -them all and their syntax.
+ them all and their syntax.The one non-intuitive notation for constants is the optional hexadecimal form -of floating point constants. For example, the form 'double -0x432ff973cafa8000' is equivalent to (but harder to read than) 'double -4.5e+15'. The only time hexadecimal floating point constants are required -(and the only time that they are generated by the disassembler) is when a -floating point constant must be emitted but it cannot be represented as a -decimal floating point number. For example, NaN's, infinities, and other -special values are represented in their IEEE hexadecimal format so that -assembly and disassembly do not cause any bits to change in the constants.
+The one non-intuitive notation for constants is the hexadecimal form of + floating point constants. For example, the form 'double + 0x432ff973cafa8000' is equivalent to (but harder to read than) + 'double 4.5e+15'. The only time hexadecimal floating point + constants are required (and the only time that they are generated by the + disassembler) is when a floating point constant must be emitted but it cannot + be represented as a decimal floating point number in a reasonable number of + digits. For example, NaN's, infinities, and other special values are + represented in their IEEE hexadecimal format so that assembly and disassembly + do not cause any bits to change in the constants.
+ +When using the hexadecimal form, constants of types float and double are + represented using the 16-digit form shown above (which matches the IEEE754 + representation for double); float values must, however, be exactly + representable as IEE754 single precision. Hexadecimal format is always used + for long double, and there are three forms of long double. The 80-bit format + used by x86 is represented as 0xK followed by 20 hexadecimal digits. + The 128-bit format used by PowerPC (two adjacent doubles) is represented + by 0xM followed by 32 hexadecimal digits. The IEEE 128-bit format + is represented by 0xL followed by 32 hexadecimal digits; no + currently supported target uses this format. Long doubles will only work if + they match the long double format on your target. All hexadecimal formats + are big-endian (sign bit at the left).
-Aggregate constants arise from aggregation of simple constants -and smaller aggregate constants.
+ +Complex constants are a (potentially recursive) combination of simple + constants and smaller complex constants.
The addresses of global variables and functions are always implicitly valid (link-time) -constants. These constants are explicitly referenced when the identifier for the global is used and always have pointer type. For example, the following is a legal LLVM -file:
+The addresses of global variables + and functions are always implicitly valid + (link-time) constants. These constants are explicitly referenced when + the identifier for the global is used and always + have pointer type. For example, the following is a + legal LLVM file:
@@ -1697,15 +2131,180 @@ file:-+ + + +The string 'undef' is recognized as a type-less constant that has - no specific value. Undefined values may be of any type and be used anywhere - a constant is permitted.
-Undefined values indicate to the compiler that the program is well defined - no matter what value is used, giving the compiler more freedom to optimize. -
+The string 'undef' can be used anywhere a constant is expected, and + indicates that the user of the value may receive an unspecified bit-pattern. + Undefined values may be of any type (other than label or void) and be used + anywhere a constant is permitted.
+ +Undefined values are useful because they indicate to the compiler that the + program is well defined no matter what value is used. This gives the + compiler more freedom to optimize. Here are some examples of (potentially + surprising) transformations that are valid (in pseudo IR):
+ + +++ ++ %A = add %X, undef + %B = sub %X, undef + %C = xor %X, undef +Safe: + %A = undef + %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: + %A = -1 + %B = 0 +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 +-1.
+ +++ ++ %A = select undef, %X, %Y + %B = select undef, 42, %Y + %C = select %X, %Y, undef +Safe: + %A = %X (or %Y) + %B = 42 (or %Y) + %C = %Y +Unsafe: + %A = undef + %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 +operands. In the %A example, if %X and %Y were both known to have a clear low +bit, then %A would have to have a cleared low bit. However, in the %C example, +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 + + %D = undef + %E = icmp lt %D, 4 + %F = icmp gte %D, 4 + +Safe: + %A = undef + %B = undef + %C = undef + %D = undef + %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 +assume that "X^X" is always zero, even if X is undef. This isn't true for a +number of reasons, but the short answer is that an undef "variable" can +arbitrarily change its value over its "live range". This is true because the +"variable" doesn't actually have a live range. Instead, the value is +logically read from arbitrary registers that happen to be around when needed, +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 +allowed to have an arbitrary bit-pattern. This means that the %A operation +can be constant folded to undef because the undef could be an SNaN, and fdiv is +not (currently) defined on SNaN's. However, in the second example, we can make +a more aggressive assumption: because the undef is allowed to be an arbitrary +value, we are allowed to assume that it could be zero. Since a divide by zero +has undefined behavior, we are allowed to assume that the operation +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 +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.
+ ++ ++ @@ -1713,93 +2312,90 @@ file:blockaddress(@function, %block)
+ +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 + behavior - though, again, comparison against null is ok, and no label is + equal to the null pointer. This may also be passed around as an opaque + 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. +
+@@ -1850,14 +2436,14 @@ following is the syntax for constant expressions:Constant expressions are used to allow expressions involving other constants -to be used as constants. Constant expressions may be of any first class type and may involve any LLVM operation -that does not have side effects (e.g. load and call are not supported). The -following is the syntax for constant expressions:
+ to be used as constants. Constant expressions may be of + any first class type and may involve any LLVM + operation that does not have side effects (e.g. load and call are not + supported). The following is the syntax for constant expressions:+
- trunc ( CST to TYPE )
-- Truncate a constant to another type. The bit size of CST must be larger - than the bit size of TYPE. Both types must be integers.
+- Truncate a constant to another type. The bit size of CST must be larger + than the bit size of TYPE. Both types must be integers.
- zext ( CST to TYPE )
-- Zero extend a constant to another type. The bit size of CST must be - smaller or equal to the bit size of TYPE. Both types must be integers.
+- Zero extend a constant to another type. The bit size of CST must be + smaller or equal to the bit size of TYPE. Both types must be + integers.
- sext ( CST to TYPE )
-- Sign extend a constant to another type. The bit size of CST must be - smaller or equal to the bit size of TYPE. Both types must be integers.
+- Sign extend a constant to another type. The bit size of CST must be + smaller or equal to the bit size of TYPE. Both types must be + integers.
- fptrunc ( CST to TYPE )
-- Truncate a floating point constant to another floating point type. The - size of CST must be larger than the size of TYPE. Both types must be - floating point.
+- Truncate a floating point constant to another floating point type. The + size of CST must be larger than the size of TYPE. Both types must be + floating point.
- fpext ( CST to TYPE )
-- Floating point extend a constant to another type. The size of CST must be - smaller or equal to the size of TYPE. Both types must be floating point.
+- Floating point extend a constant to another type. The size of CST must be + smaller or equal to the size of TYPE. Both types must be floating + point.
- fptoui ( CST to TYPE )
- Convert a floating point constant to the corresponding unsigned integer - constant. TYPE must be a scalar or vector integer type. CST must be of scalar - or vector floating point type. Both CST and TYPE must be scalars, or vectors - of the same number of elements. If the value won't fit in the integer type, - the results are undefined.
+ constant. TYPE must be a scalar or vector integer type. CST must be of + scalar or vector floating point type. Both CST and TYPE must be scalars, + or vectors of the same number of elements. If the value won't fit in the + integer type, the results are undefined.- fptosi ( CST to TYPE )
- Convert a floating point constant to the corresponding signed integer - constant. TYPE must be a scalar or vector integer type. CST must be of scalar - or vector floating point type. Both CST and TYPE must be scalars, or vectors - of the same number of elements. If the value won't fit in the integer type, - the results are undefined.
+ constant. TYPE must be a scalar or vector integer type. CST must be of + scalar or vector floating point type. Both CST and TYPE must be scalars, + or vectors of the same number of elements. If the value won't fit in the + integer type, the results are undefined.- uitofp ( CST to TYPE )
- Convert an unsigned integer constant to the corresponding floating point - constant. TYPE must be a scalar or vector floating point type. CST must be of - scalar or vector integer type. Both CST and TYPE must be scalars, or vectors - of the same number of elements. If the value won't fit in the floating point - type, the results are undefined.
+ constant. TYPE must be a scalar or vector floating point type. CST must be + of scalar or vector integer type. Both CST and TYPE must be scalars, or + vectors of the same number of elements. If the value won't fit in the + floating point type, the results are undefined.- sitofp ( CST to TYPE )
- Convert a signed integer constant to the corresponding floating point - constant. TYPE must be a scalar or vector floating point type. CST must be of - scalar or vector integer type. Both CST and TYPE must be scalars, or vectors - of the same number of elements. If the value won't fit in the floating point - type, the results are undefined.
+ constant. TYPE must be a scalar or vector floating point type. CST must be + of scalar or vector integer type. Both CST and TYPE must be scalars, or + vectors of the same number of elements. If the value won't fit in the + floating point type, the results are undefined.- ptrtoint ( CST to TYPE )
- Convert a pointer typed constant to the corresponding integer constant - TYPE must be an integer type. CST must be of pointer type. The CST value is - zero extended, truncated, or unchanged to make it fit in TYPE.
+ TYPE must be an integer type. CST must be of pointer + type. The CST value is zero extended, truncated, or unchanged to + make it fit in TYPE.- inttoptr ( CST to TYPE )
-- Convert a integer constant to a pointer constant. TYPE must be a - pointer type. CST must be of integer type. The CST value is zero extended, - truncated, or unchanged to make it fit in a pointer size. This one is - really dangerous!
+- Convert a integer constant to a pointer constant. TYPE must be a pointer + type. CST must be of integer type. The CST value is zero extended, + truncated, or unchanged to make it fit in a pointer size. This one is + really dangerous!
- bitcast ( CST to TYPE )
-- Convert a constant, CST, to another TYPE. The size of CST and TYPE must be - identical (same number of bits). The conversion is done as if the CST value - was stored to memory and read back as TYPE. In other words, no bits change - with this operator, just the type. This can be used for conversion of - vector types to any other type, as long as they have the same bit width. For - pointers it is only valid to cast to another pointer type. It is not valid - to bitcast to or from an aggregate type. -
+- Convert a constant, CST, to another TYPE. The constraints of the operands + are the same as those for the bitcast + instruction.
- getelementptr ( CSTPTR, IDX0, IDX1, ... )
- +- getelementptr inbounds ( CSTPTR, IDX0, IDX1, ... )
- Perform the getelementptr operation on - constants. As with the getelementptr - instruction, the index list may have zero or more indexes, which are required - to make sense for the type of "CSTPTR".
+ constants. As with the getelementptr + instruction, the index list may have zero or more indexes, which are + required to make sense for the type of "CSTPTR".- select ( COND, VAL1, VAL2 )
- -- Perform the select operation on - constants.
+- Perform the select operation on constants.
- icmp COND ( VAL1, VAL2 )
- Performs the icmp operation on constants.
@@ -1807,36 +2403,26 @@ following is the syntax for constant expressions:- fcmp COND ( VAL1, VAL2 )
- Performs the fcmp operation on constants.
-- vicmp COND ( VAL1, VAL2 )
-- Performs the vicmp operation on constants.
- -- vfcmp COND ( VAL1, VAL2 )
-- Performs the vfcmp operation on constants.
-- extractelement ( VAL, IDX )
- -- Perform the extractelement - operation on constants.
+- Perform the extractelement operation on + constants.
- insertelement ( VAL, ELT, IDX )
- -- Perform the insertelement - operation on constants.
- +- Perform the insertelement operation on + constants.
- shufflevector ( VEC1, VEC2, IDXMASK )
- -- Perform the shufflevector - operation on constants.
+- Perform the shufflevector operation on + constants.
- OPCODE ( LHS, RHS )
- -- Perform the specified operation of the LHS and RHS constants. OPCODE may - be any of the binary or bitwise - binary operations. The constraints on operands are the same as those for - the corresponding instruction (e.g. no bitwise operations on floating point - values are allowed).
+- Perform the specified operation of the LHS and RHS constants. OPCODE may + be any of the binary + or bitwise binary operations. The constraints + on operands are the same as those for the corresponding instruction + (e.g. no bitwise operations on floating point values are allowed).
-+ + + + +-LLVM supports inline assembler expressions (as opposed to -Module-Level Inline Assembly) through the use of a special value. This -value represents the inline assembler as a string (containing the instructions -to emit), a list of operand constraints (stored as a string), and a flag that -indicates whether or not the inline asm expression has side effects. An example -inline assembler expression is: -
+LLVM supports inline assembler expressions (as opposed + to Module-Level Inline Assembly) through the use of + a special value. This value represents the inline assembler as a string + (containing the instructions to emit), a list of operand constraints (stored + as a string), a flag that indicates whether or not the inline asm + expression has side effects, and a flag indicating whether the function + containing the asm needs to align its stack conservatively. An example + inline assembler expression is:
-@@ -1865,10 +2451,9 @@ 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: -
+Inline assembler expressions may only be used as the callee operand of + a call instruction. Thus, typically we + have:
-@@ -1876,11 +2461,9 @@ a call instruction. Thus, typically we have:-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: -
+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:
+@@ -1888,26 +2471,159 @@ 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, + yet will not contain code that does that alignment within the asm. + The compiler should make conservative assumptions about what the asm might + 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.
+TODO: The format of the asm and constraints string still need to be -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. -
+ 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. + ++ ++ + + + + + +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}". + +
LLVM has a number of "magic" global variables that contain data that affect +code generation or other IR semantics. These are documented here. All globals +of this sort should have a section specified as "llvm.metadata". This +section and all globals that start with "llvm." are reserved for use +by LLVM.
+ + + + ++ ++ + + + +The @llvm.used global is an array with i8* element type which has appending linkage. This array contains a list of +pointers to global variables and functions which may optionally have a pointer +cast formed of bitcast or getelementptr. For example, a legal use of it is:
+ ++ @X = global i8 4 + @Y = global i32 123 + + @llvm.used = appending global [2 x i8*] [ + i8* @X, + i8* bitcast (i32* @Y to i8*) + ], section "llvm.metadata" ++ +If a global variable appears in the @llvm.used list, then the +compiler, assembler, and linker are required to treat the symbol as if there is +a reference to the global that it cannot see. For example, if a variable has +internal linkage and no references other than that from the @llvm.used +list, it cannot be deleted. This is commonly used to represent references from +inline asms and other things the compiler cannot "see", and corresponds to +"attribute((used))" in GNU C.
+ +On some targets, the code generator must emit a directive to the assembler or +object file to prevent the assembler and linker from molesting the symbol.
+ ++ ++ + + + +The @llvm.compiler.used directive is the same as the +@llvm.used directive, except that it only prevents the compiler from +touching the symbol. On targets that support it, this allows an intelligent +linker to optimize references to the symbol without being impeded as it would be +by @llvm.used.
+ +This is a rare construct that should only be used in rare circumstances, and +should not be exposed to source languages.
+ ++ ++ + + + +TODO: Describe this.
+ ++ ++TODO: Describe this.
-@@ -1917,25 +2633,30 @@ InstructionsThe LLVM instruction set consists of several different -classifications of instructions: terminator -instructions, binary instructions, -bitwise binary instructions, memory instructions, and other -instructions.
+The LLVM instruction set consists of several different classifications of + instructions: terminator + instructions, binary instructions, + bitwise binary instructions, + memory instructions, and + other instructions.
As mentioned previously, every -basic block in a program ends with a "Terminator" instruction, which -indicates which block should be executed after the current block is -finished. These terminator instructions typically yield a 'void' -value: they produce control flow, not values (the one exception being -the 'invoke' instruction).
-There are six different terminator instructions: the 'ret' instruction, the 'br' -instruction, the 'switch' instruction, -the 'invoke' instruction, the 'unwind' instruction, and the 'unreachable' instruction.
+As mentioned previously, every basic block + in a program ends with a "Terminator" instruction, which indicates which + block should be executed after the current block is finished. These + terminator instructions typically yield a 'void' value: they produce + control flow, not values (the one exception being the + 'invoke' instruction).
+ +There are six different terminator instructions: the + 'ret' instruction, the + 'br' instruction, the + 'switch' instruction, the + ''indirectbr' Instruction, the + 'invoke' instruction, the + 'unwind' instruction, and the + 'unreachable' instruction.
ret <type> <value> ; Return a value from a non-void function @@ -1943,204 +2664,263 @@ Instruction
The 'ret' instruction is used to return control flow (and optionally + a value) from a function back to the caller.
-The 'ret' instruction is used to return control flow (and -optionally a value) from a function back to the caller.
-There are two forms of the 'ret' instruction: one that -returns a value and then causes control flow, and one that just causes -control flow to occur.
+There are two forms of the 'ret' instruction: one that returns a + value and then causes control flow, and one that just causes control flow to + occur.
The 'ret' instruction optionally accepts a single argument, the + return value. The type of the return value must be a + 'first class' type.
-The 'ret' instruction optionally accepts a single argument, -the return value. The type of the return value must be a -'first class' type.
- -A function is not well formed if -it it has a non-void return type and contains a 'ret' -instruction with no return value or a return value with a type that -does not match its type, or if it has a void return type and contains -a 'ret' instruction with a return value.
+A function is not well formed if it it has a + non-void return type and contains a 'ret' instruction with no return + value or a return value with a type that does not match its type, or if it + has a void return type and contains a 'ret' instruction with a + return value.
When the 'ret' instruction is executed, control flow -returns back to the calling function's context. If the caller is a "call" instruction, execution continues at -the instruction after the call. If the caller was an "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.
+When the 'ret' instruction is executed, control flow returns back to + the calling function's context. If the caller is a + "call" instruction, execution continues at the + instruction after the call. If the caller was an + "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.
ret i32 5 ; Return an integer value of 5
ret void ; Return from a void function
- ret { i32, i8 } { i32 4, i8 2 } ; Return an aggregate of values 4 and 2
+ ret { i32, i8 } { i32 4, i8 2 } ; Return a struct of values 4 and 2
+
br i1 <cond>, label <iftrue>, label <iffalse>
br label <dest> ; Unconditional branch ++ br i1 <cond>, label <iftrue>, label <iffalse>+
br label <dest> ; Unconditional branchOverview:
-The 'br' instruction is used to cause control flow to -transfer to a different basic block in the current function. There are -two forms of this instruction, corresponding to a conditional branch -and an unconditional branch.
+The 'br' instruction is used to cause control flow to transfer to a + different basic block in the current function. There are two forms of this + instruction, corresponding to a conditional branch and an unconditional + branch.
+Arguments:
-The conditional branch form of the 'br' instruction takes a -single 'i1' value and two 'label' values. The -unconditional form of the 'br' instruction takes a single -'label' value as a target.
+The conditional branch form of the 'br' instruction takes a single + 'i1' value and two 'label' values. The unconditional form + of the 'br' instruction takes a single 'label' value as a + target.
+Semantics:
Upon execution of a conditional 'br' instruction, the 'i1' -argument is evaluated. If the value is true, control flows -to the 'iftrue' label argument. If "cond" is false, -control flows to the 'iffalse' label argument.
+ argument is evaluated. If the value is true, control flows to the + 'iftrue' label argument. If "cond" is false, + control flows to the 'iffalse' label argument. +Example:
-Test:+
%cond = icmp eq, i32 %a, %b
br i1 %cond, label %IfEqual, label %IfUnequal
IfEqual:
ret i32 1
IfUnequal:
ret i32 0+Test: + %cond = icmp eq i32 %a, %b + br i1 %cond, label %IfEqual, label %IfUnequal +IfEqual: + ret i32 1 +IfUnequal: + ret i32 0 ++
switch <intty> <value>, label <defaultdest> [ <intty> <val>, label <dest> ... ]
The 'switch' instruction is used to transfer control flow to one of -several different places. It is a generalization of the 'br' -instruction, allowing a branch to occur to one of many possible -destinations.
- + several different places. It is a generalization of the 'br' + instruction, allowing a branch to occur to one of many possible + destinations.The 'switch' instruction uses three parameters: an integer -comparison value 'value', a default 'label' destination, and -an array of pairs of comparison value constants and 'label's. The -table is not allowed to contain duplicate constant entries.
+ comparison value 'value', a default 'label' destination, + and an array of pairs of comparison value constants and 'label's. + The table is not allowed to contain duplicate constant entries.The switch instruction specifies a table of values and -destinations. When the 'switch' instruction is executed, this -table is searched for the given value. If the value is found, control flow is -transfered to the corresponding destination; otherwise, control flow is -transfered to the default destination.
+ destinations. When the 'switch' instruction is executed, this table + is searched for the given value. If the value is found, control flow is + transferred to the corresponding destination; otherwise, control flow is + transferred to the default destination.Depending on properties of the target machine and the particular -switch instruction, this instruction may be code generated in different -ways. For example, it could be generated as a series of chained conditional -branches or with a lookup table.
+ switch instruction, this instruction may be code generated in + different ways. For example, it could be generated as a series of chained + conditional branches or with a lookup table.; Emulate a conditional br instruction %Val = zext i1 %value to i32 - switch i32 %Val, label %truedest [i32 0, label %falsedest ] + switch i32 %Val, label %truedest [ i32 0, label %falsedest ] ; Emulate an unconditional br instruction switch i32 0, label %dest [ ] ; Implement a jump table: - switch i32 %val, label %otherwise [ i32 0, label %onzero - i32 1, label %onone - i32 2, label %ontwo ] + switch i32 %val, label %otherwise [ i32 0, label %onzero + i32 1, label %onone + i32 2, label %ontwo ]+
+ indirectbr <somety>* <address>, [ label <dest1>, label <dest2>, ... ] ++ +
The 'indirectbr' instruction implements an indirect branch to a label + within the current function, whose address is specified by + "address". Address must be derived from a blockaddress constant.
+ +The 'address' argument is the address of the label to jump to. The + 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.
+Control transfers to the block specified in the address argument. All + possible destination blocks must be listed in the label list, otherwise this + instruction has undefined behavior. This implies that jumps to labels + defined in other functions have undefined behavior as well.
+ +This is typically implemented with a jump through a register.
+ ++ indirectbr i8* %Addr, [ label %bb1, label %bb2, label %bb3 ] ++ +
<result> = invoke [cconv] [ret attrs] <ptr to function ty> <function ptr val>(<function args>) [fn attrs] to label <normal label> unwind label <exception label>
The 'invoke' instruction causes control to transfer to a specified -function, with the possibility of control flow transfer to either the -'normal' label or the -'exception' label. If the callee function returns with 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.
+ function, with the possibility of control flow transfer to either the + 'normal' label or the 'exception' label. If the callee + function returns with 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.This instruction requires several arguments:
This instruction is designed to operate as a standard 'call' instruction in most regards. The primary -difference is that it establishes an association with a label, which is used by -the runtime library to unwind the stack.
+This instruction is designed to operate as a standard + 'call' instruction in most regards. The + primary difference is that it establishes an association with a label, which + is used by the runtime library to unwind the stack.
This instruction is used in languages with destructors to ensure that proper -cleanup is performed in the case of either a longjmp or a thrown -exception. Additionally, this is important for implementation of -'catch' clauses in high-level languages that support them.
+ cleanup is performed in the case of either a longjmp or a thrown + exception. Additionally, this is important for implementation of + 'catch' clauses in high-level languages that support them. + +For the purposes of the SSA form, the definition of the value returned by the + 'invoke' instruction is deemed to occur on the edge from the current + block to the "normal" label. If the callee unwinds then no return value is + available.
+ +Note that the code generator does not yet completely support unwind, and +that the invoke/unwind semantics are likely to change in future versions.
@@ -2149,8 +2929,8 @@ exception. Additionally, this is important for implementation of %retval = invoke coldcc i32 %Testfnptr(i32 15) to label %Continue unwind label %TestCleanup ; {i32}:retval set-
The 'unwind' instruction unwinds the stack, continuing control flow -at the first callee in the dynamic call stack which used an invoke instruction to perform the call. This is -primarily used to implement exception handling.
+ at the first callee in the dynamic call stack which used + an invoke instruction to perform the call. + This is primarily used to implement exception handling.The 'unwind' instruction causes execution of the current function to -immediately halt. The dynamic call stack is then searched for the first invoke instruction on the call stack. Once found, -execution continues at the "exceptional" destination block specified by the -invoke instruction. If there is no invoke instruction in the -dynamic call chain, undefined behavior results.
+ immediately halt. The dynamic call stack is then searched for the + first invoke instruction on the call stack. + Once found, execution continues at the "exceptional" destination block + specified by the invoke instruction. If there is no invoke + instruction in the dynamic call chain, undefined behavior results. + +Note that the code generator does not yet completely support unwind, and +that the invoke/unwind semantics are likely to change in future versions.
+ @@ -2194,272 +2976,413 @@ InstructionThe 'unreachable' instruction has no defined semantics. This + instruction is used to inform the optimizer that a particular portion of the + code is not reachable. This can be used to indicate that the code after a + no-return function cannot be reached, and other facts.
+ +The 'unreachable' instruction has no defined semantics.
+ + + + + + +Binary operators are used to do most of the computation in a 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 + has the same type as its operands.
+ +There are several different binary operators:
+ +
+ <result> = add <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = add nuw <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = add nsw <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = add nuw nsw <ty> <op1>, <op2> ; yields {ty}:result
+
+
+The 'add' instruction returns the sum of its two operands.
+ +The two arguments to the 'add' instruction must + be integer or vector of + integer values. Both arguments must have identical types.
+ +The value produced is the integer sum of the two operands.
+ +If the 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.
+ +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.
+ +
+ <result> = add i32 4, %var ; yields {i32}:result = 4 + %var
+
+
+
+ <result> = fadd <ty> <op1>, <op2> ; yields {ty}:result
+
+
+The 'fadd' instruction returns the sum of its two operands.
+ +The two arguments to the 'fadd' instruction must be + floating point or vector of + floating point values. Both arguments must have identical types.
+ +The value produced is the floating point sum of the two operands.
+ +
+ <result> = fadd float 4.0, %var ; yields {float}:result = 4.0 + %var
+
+
+
+ <result> = sub <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = sub nuw <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = sub nsw <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = sub nuw nsw <ty> <op1>, <op2> ; yields {ty}:result
+
+
+The 'sub' instruction returns the difference of its two + operands.
-The 'unreachable' instruction has no defined semantics. This -instruction is used to inform the optimizer that a particular portion of the -code is not reachable. This can be used to indicate that the code after a -no-return function cannot be reached, and other facts.
+Note that the 'sub' instruction is used to represent the + 'neg' instruction present in most other intermediate + representations.
+ +The two arguments to the 'sub' instruction must + be integer or vector of + integer values. Both arguments must have identical types.
The value produced is the integer difference of the two operands.
-The 'unreachable' instruction has no defined semantics.
-If the 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.
+nuw and nsw stand for "No Unsigned Wrap" + and "No Signed Wrap", respectively. If the nuw and/or + nsw keywords are present, the result value of the sub + is undefined if unsigned and/or signed overflow, respectively, occurs.
+ +
+ <result> = sub i32 4, %var ; yields {i32}:result = 4 - %var
+ <result> = sub i32 0, %val ; yields {i32}:result = -%var
+
-
-
-Binary operators are used to do most of the computation in a -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 has the same type as its operands.
-There are several different binary operators:
- <result> = add <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = fsub <ty> <op1>, <op2> ; yields {ty}:result
The 'fsub' instruction returns the difference of its two + operands.
-The 'add' instruction returns the sum of its two operands.
+Note that the 'fsub' instruction is used to represent the + 'fneg' instruction present in most other intermediate + representations.
The two arguments to the 'add' instruction must be integer, floating point, or - vector values. Both arguments must have identical - types.
+The two arguments to the 'fsub' instruction must be + floating point or vector of + floating point values. Both arguments must have identical types.
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.
+The value produced is the floating point difference of the two operands.
- <result> = add i32 4, %var ; yields {i32}:result = 4 + %var
+ <result> = fsub float 4.0, %var ; yields {float}:result = 4.0 - %var
+ <result> = fsub float -0.0, %val ; yields {float}:result = -%var
+
- <result> = sub <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = mul <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = mul nuw <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = mul nsw <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = mul nuw nsw <ty> <op1>, <op2> ; yields {ty}:result
The 'sub' instruction returns the difference of its two -operands.
- -Note that the 'sub' instruction is used to represent the -'neg' instruction present in most other intermediate -representations.
+The 'mul' instruction returns the product of its two operands.
The two arguments to the 'sub' instruction must be integer, floating point, - or vector values. Both arguments must have identical - types.
+The two arguments to the 'mul' instruction must + be integer or vector of + integer values. Both arguments must have identical types.
The value produced is the integer product of the two operands.
-The value produced is the integer or floating point difference of -the two operands.
+If the result of the multiplication has unsigned overflow, the result + returned is the mathematical result modulo 2n, where n is the bit + width of the result.
-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, 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.
-Because LLVM integers use a two's complement representation, this -instruction is appropriate for both signed and unsigned integers.
+nuw and nsw stand for "No Unsigned Wrap" + and "No Signed Wrap", respectively. If the nuw and/or + nsw keywords are present, the result value of the mul + is undefined if unsigned and/or signed overflow, respectively, occurs.
- <result> = sub i32 4, %var ; yields {i32}:result = 4 - %var
- <result> = sub i32 0, %val ; yields {i32}:result = -%var
+ <result> = mul i32 4, %var ; yields {i32}:result = 4 * %var
+
<result> = mul <ty> <op1>, <op2> ; yields {ty}:result
+
+ <result> = fmul <ty> <op1>, <op2> ; yields {ty}:result
+
Overview:
-The 'mul' instruction returns the product of its two
-operands.
+The 'fmul' instruction returns the product of its two operands.
Arguments:
+The two arguments to the 'fmul' instruction must be
+ floating point or vector of
+ floating point values. Both arguments must have identical types.
-The two arguments to the 'mul' instruction must be integer, floating point,
-or vector values. Both arguments must have identical
-types.
-
Semantics:
+The value produced is the floating point product of the two operands.
-The value produced is the integer or floating point product of the
-two operands.
-
-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
+
+ <result> = fmul float 4.0, %var ; yields {float}:result = 4.0 * %var
+
<result> = udiv <ty> <op1>, <op2> ; yields {ty}:result
+
+ <result> = udiv <ty> <op1>, <op2> ; yields {ty}:result
+
Overview:
-The 'udiv' instruction returns the quotient of its two
-operands.
+The 'udiv' instruction returns the quotient of its two operands.
Arguments:
-
-The two arguments to the 'udiv' instruction must be
-integer or vector of integer
-values. Both arguments must have identical types.
+The two arguments to the 'udiv' instruction must be
+ integer or vector of integer
+ values. Both arguments must have identical types.
Semantics:
-
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'.
+ 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
+
+ <result> = udiv i32 4, %var ; yields {i32}:result = 4 / %var
+
- <result> = sdiv <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = sdiv <ty> <op1>, <op2> ; yields {ty}:result
+ <result> = sdiv exact <ty> <op1>, <op2> ; yields {ty}:result
The 'sdiv' instruction returns the quotient of its two -operands.
+The 'sdiv' instruction returns the quotient of its two operands.
The two arguments to the 'sdiv' instruction must be -integer or vector of integer -values. Both arguments must have identical types.
+The two arguments to the 'sdiv' instruction must be + integer or vector of integer + values. Both arguments must have identical types.
The value produced is the signed integer quotient of the two operands rounded towards zero.
+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'.
+ 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.
+ undefined behavior; this is a rare case, but can occur, for example, by doing + 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.
+ <result> = sdiv i32 4, %var ; yields {i32}:result = 4 / %var
+
+ <result> = sdiv i32 4, %var ; yields {i32}:result = 4 / %var
+
<result> = fdiv <ty> <op1>, <op2> ; yields {ty}:result
-The 'fdiv' instruction returns the quotient of its two -operands.
+The 'fdiv' instruction returns the quotient of its two operands.
The two arguments to the 'fdiv' instruction must be -floating point or vector -of floating point values. Both arguments must have identical types.
+ floating point or vector of + floating point values. Both arguments must have identical types.The value produced is the floating point quotient of the two operands.
<result> = fdiv float 4.0, %var ; yields {float}:result = 4.0 / %var
+
<result> = urem <ty> <op1>, <op2> ; yields {ty}:result
+
+ <result> = urem <ty> <op1>, <op2> ; yields {ty}:result
+
Overview:
-The 'urem' instruction returns the remainder from the
-unsigned division of its two arguments.
+The 'urem' instruction returns the remainder from the unsigned
+ division of its two arguments.
+
Arguments:
-The two arguments to the 'urem' instruction must be
-integer or vector of integer
-values. Both arguments must have identical types.
+The two arguments to the 'urem' instruction must be
+ integer or vector of integer
+ values. Both arguments must have identical types.
+
Semantics:
This instruction returns the unsigned integer remainder of a division.
-This instruction always performs an unsigned division to get the remainder.
+ 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'.
+ 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
+
+ <result> = urem i32 4, %var ; yields {i32}:result = 4 % %var
<result> = srem <ty> <op1>, <op2> ; yields {ty}:result
The 'srem' instruction returns the remainder from the -signed division of its two operands. This instruction can also take -vector versions of the values in which case -the elements must be integers.
+The 'srem' instruction returns the remainder from the signed + division of its two operands. This instruction can also take + vector versions of the values in which case the + elements must be integers.
The two arguments to the 'srem' instruction must be -integer or vector of integer -values. Both arguments must have identical types.
+The two arguments to the 'srem' instruction must be + integer or vector of integer + values. Both arguments must have identical types.
This instruction returns the remainder of a division (where the result -has the same sign as the dividend, op1), not the modulo -operator (where the result has the same sign as the divisor, op2) of -a value. For more information about the difference, see The -Math Forum. For a table of how this is implemented in various languages, -please see -Wikipedia: modulo operation.
+ has the same sign as the dividend, op1), not the modulo + operator (where the result has the same sign as the divisor, op2) of + a value. For more information about the difference, + see The + Math Forum. 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'.
+ 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.)
+ 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.) + <result> = srem i32 4, %var ; yields {i32}:result = 4 % %var
+
+ <result> = srem i32 4, %var ; yields {i32}:result = 4 % %var
<result> = frem <ty> <op1>, <op2> ; yields {ty}:result
+
+ <result> = frem <ty> <op1>, <op2> ; yields {ty}:result
+
Overview:
-The 'frem' instruction returns the remainder from the
-division of its two operands.
+The 'frem' instruction returns the remainder from the division of
+ its two operands.
+
Arguments:
The two arguments to the 'frem' instruction must be
-floating point or vector
-of floating point values. Both arguments must have identical types.
+ floating point or vector of
+ floating point values. Both arguments must have identical types.
Semantics:
-
-This instruction returns the remainder of a division.
-The remainder has the same sign as the dividend.
+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
+
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 of the same type, execute an operation on them, -and produce a single value. The resulting value is the same type as its operands.
+ +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 of the + same type, execute an operation on them, and produce a single value. The + resulting value is the same type as its operands.
+ <result> = shl <ty> <op1>, <op2> ; yields {ty}:result
+
+ <result> = shl <ty> <op1>, <op2> ; yields {ty}:result
Overview:
-
-The 'shl' instruction returns the first operand shifted to
-the left a specified number of bits.
+The 'shl' instruction returns the first operand shifted to the left
+ a specified number of bits.
Arguments:
+Both arguments to the 'shl' instruction must be the
+ same integer or vector of
+ integer type. 'op2' is treated as an unsigned value.
-Both 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
+ is (statically or dynamically) negative or equal to or larger than the number
+ of bits in op1, the result is undefined. If the arguments are
+ vectors, each vector element of op1 is shifted by the corresponding
+ shift amount in op2.
-The value produced is op1 * 2op2 mod 2n,
-where n is the width of the result. If op2 is (statically or dynamically) negative or
-equal to or larger than the number of bits in op1, the result is undefined.
-
-Example:
+Example:
+
<result> = shl i32 4, %var ; yields {i32}: 4 << %var
<result> = shl i32 4, 2 ; yields {i32}: 16
<result> = shl i32 1, 10 ; yields {i32}: 1024
<result> = shl i32 1, 32 ; undefined
+ <result> = shl <2 x i32> < i32 1, i32 1>, < i32 1, i32 2> ; yields: result=<2 x i32> < i32 2, i32 4>
+
<result> = lshr <ty> <op1>, <op2> ; yields {ty}:result
+
+ <result> = lshr <ty> <op1>, <op2> ; yields {ty}:result
Overview:
-The 'lshr' instruction (logical shift right) returns the first
-operand shifted to the right a specified number of bits with zero fill.
+The 'lshr' instruction (logical shift right) returns the first
+ operand shifted to the right a specified number of bits with zero fill.
Arguments:
-Both arguments to the 'lshr' instruction must be the same
-integer or vector of integer
-type. 'op2' is treated as an unsigned value.
+Both arguments to the 'lshr' instruction must be the same
+ integer or vector of integer
+ type. 'op2' is treated as an unsigned value.
Semantics:
-
This instruction always performs a logical shift right operation. The most
-significant bits of the result will be filled with zero bits after the
-shift. If op2 is (statically or dynamically) equal to or larger than
-the number of bits in op1, the result is undefined.
+ significant bits of the result will be filled with zero bits after the shift.
+ If op2 is (statically or dynamically) equal to or larger than the
+ number of bits in op1, the result is undefined. If the arguments are
+ vectors, each vector element of op1 is shifted by the corresponding
+ shift amount in op2.
Example:
@@ -2612,7 +3552,9 @@ the number of bits in op1, the result is undefined.
<result> = lshr i8 4, 3 ; yields {i8}:result = 0
<result> = lshr i8 -2, 1 ; yields {i8}:result = 0x7FFFFFFF
<result> = lshr i32 1, 32 ; undefined
+ <result> = lshr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 2> ; yields: result=<2 x i32> < i32 0x7FFFFFFF, i32 1>
+
<result> = ashr <ty> <op1>, <op2> ; yields {ty}:result
+
+ <result> = ashr <ty> <op1>, <op2> ; yields {ty}:result
Overview:
-The 'ashr' instruction (arithmetic shift right) returns the first
-operand shifted to the right a specified number of bits with sign extension.
+The 'ashr' instruction (arithmetic shift right) returns the first
+ operand shifted to the right a specified number of bits with sign
+ extension.
Arguments:
-Both arguments to the 'ashr' instruction must be the same
-integer or vector of integer
-type. 'op2' is treated as an unsigned value.
+Both arguments to the 'ashr' instruction must be the same
+ integer or vector of integer
+ type. 'op2' is treated as an unsigned value.
Semantics:
-This instruction always performs an arithmetic shift right operation,
-The most significant bits of the result will be filled with the sign bit
-of op1. If op2 is (statically or dynamically) equal to or
-larger than the number of bits in op1, the result is undefined.
-
+This instruction always performs an arithmetic shift right operation, The
+ most significant bits of the result will be filled with the sign bit
+ of op1. If op2 is (statically or dynamically) equal to or
+ larger than the number of bits in op1, the result is undefined. If
+ the arguments are vectors, each vector element of op1 is shifted by
+ the corresponding shift amount in op2.
Example:
@@ -2647,7 +3592,9 @@ larger than the number of bits in op1, the result is undefined.
<result> = ashr i8 4, 3 ; yields {i8}:result = 0
<result> = ashr i8 -2, 1 ; yields {i8}:result = -1
<result> = ashr i32 1, 32 ; undefined
+ <result> = ashr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 3> ; yields: result=<2 x i32> < i32 -1, i32 0>
+
<result> = and <ty> <op1>, <op2> ; yields {ty}:result
The 'and' instruction returns the bitwise logical and of -its two operands.
+The 'and' instruction returns the bitwise logical and of its two + operands.
The two arguments to the 'and' instruction must be -integer or vector of integer -values. Both arguments must have identical types.
+The two arguments to the 'and' instruction must be + integer or vector of integer + values. Both arguments must have identical types.
The truth table used for the 'and' instruction is:
--
<result> = and i32 4, %var ; yields {i32}:result = 4 & %var
@@ -2716,22 +3659,26 @@ values. Both arguments must have identical types.
<result> = or <ty> <op1>, <op2> ; yields {ty}:result
+
+ <result> = or <ty> <op1>, <op2> ; yields {ty}:result
+
Overview:
-The 'or' instruction returns the bitwise logical inclusive
-or of its two operands.
+The 'or' instruction returns the bitwise logical inclusive or of its
+ two operands.
+
Arguments:
+The two arguments to the 'or' instruction must be
+ integer or vector of integer
+ values. Both arguments must have identical types.
-The two arguments to the 'or' instruction must be
-integer or vector of integer
-values. Both arguments must have identical types.
Semantics:
The truth table used for the 'or' instruction is:
-
-
+
@@ -2761,34 +3708,40 @@ values. Both arguments must have identical types.
-
+
Example:
- <result> = or i32 4, %var ; yields {i32}:result = 4 | %var
+
+ <result> = or i32 4, %var ; yields {i32}:result = 4 | %var
<result> = or i32 15, 40 ; yields {i32}:result = 47
<result> = or i32 4, 8 ; yields {i32}:result = 12
+
<result> = xor <ty> <op1>, <op2> ; yields {ty}:result
+
+ <result> = xor <ty> <op1>, <op2> ; yields {ty}:result
+
Overview:
-The 'xor' instruction returns the bitwise logical exclusive
-or of its two operands. The xor is used to implement the
-"one's complement" operation, which is the "~" operator in C.
+The 'xor' instruction returns the bitwise logical exclusive or of
+ its two operands. The xor is used to implement the "one's
+ complement" operation, which is the "~" operator in C.
+
Arguments:
-The two arguments to the 'xor' instruction must be
-integer or vector of integer
-values. Both arguments must have identical types.
+The two arguments to the 'xor' instruction must be
+ integer or vector of integer
+ values. Both arguments must have identical types.
Semantics:
-
The truth table used for the 'xor' instruction is:
-
-
+
@@ -2818,29 +3771,30 @@ values. Both arguments must have identical types.
-
-
+
Example:
- <result> = xor i32 4, %var ; yields {i32}:result = 4 ^ %var
+
+ <result> = xor i32 4, %var ; yields {i32}:result = 4 ^ %var
<result> = xor i32 15, 40 ; yields {i32}:result = 39
<result> = xor i32 4, 8 ; yields {i32}:result = 12
<result> = xor i32 %V, -1 ; yields {i32}:result = ~%V
+
LLVM supports several instructions to represent vector operations in a -target-independent manner. These instructions cover the element-access and -vector-specific operations needed to process vectors effectively. While LLVM -does directly support these vector operations, many sophisticated algorithms -will want to use target-specific intrinsics to take full advantage of a specific -target.
+ target-independent manner. These instructions cover the element-access and + vector-specific operations needed to process vectors effectively. While LLVM + does directly support these vector operations, many sophisticated algorithms + will want to use target-specific intrinsics to take full advantage of a + specific target.<result> = extractelement <n x <ty>> <val>, i32 <idx> ; yields <ty>
-The 'extractelement' instruction extracts a single scalar -element from a vector at a specified index. -
+The 'extractelement' instruction extracts a single scalar element + from a vector at a specified index.
-The first operand of an 'extractelement' instruction is a -value of vector type. The second operand is -an index indicating the position from which to extract the element. -The index may be a variable.
+The first operand of an 'extractelement' instruction is a value + of vector type. The second operand is an index + indicating the position from which to extract the element. The index may be + a variable.
-The result is a scalar of the same type as the element type of -val. Its value is the value at position idx of -val. If idx exceeds the length of val, the -results are undefined. -
+The result is a scalar of the same type as the element type of + val. Its value is the value at position idx of + val. If idx exceeds the length of val, the + results are undefined.
- %result = extractelement <4 x i32> %vec, i32 0 ; yields i32 + <result> = extractelement <4 x i32> %vec, i32 0 ; yields i32-
<result> = insertelement <n x <ty>> <val>, <ty> <elt>, i32 <idx> ; yields <n x <ty>>
-The 'insertelement' instruction inserts a scalar -element into a vector at a specified index. -
- +The 'insertelement' instruction inserts a scalar element into a + vector at a specified index.
-The first operand of an 'insertelement' instruction is a -value of vector type. The second operand is a -scalar value whose type must equal the element type of the first -operand. The third operand is an index indicating the position at -which to insert the value. The index may be a variable.
+The first operand of an 'insertelement' instruction is a value + of vector type. The second operand is a scalar value + whose type must equal the element type of the first operand. The third + operand is an index indicating the position at which to insert the value. + The index may be a variable.
-The result is a vector of the same type as val. Its -element values are those of val except at position -idx, where it gets the value elt. If idx -exceeds the length of val, the results are undefined. -
+The result is a vector of the same type as val. Its element values + are those of val except at position idx, where it gets the + value elt. If idx exceeds the length of val, the + results are undefined.
- %result = insertelement <4 x i32> %vec, i32 1, i32 0 ; yields <4 x i32> + <result> = insertelement <4 x i32> %vec, i32 1, i32 0 ; yields <4 x i32>+
<result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <m x i32> <mask> ; yields <m x <ty>>
-The 'shufflevector' instruction constructs a permutation of elements -from two input vectors, returning a vector with the same element type as -the input and length that is the same as the shuffle mask. -
+The 'shufflevector' instruction constructs a permutation of elements + from two input vectors, returning a vector with the same element type as the + input and length that is the same as the shuffle mask.
The first two operands of a 'shufflevector' instruction are vectors + with types that match each other. The third argument is a shuffle mask whose + element type is always 'i32'. The result of the instruction is a vector + whose length is the same as the shuffle mask and whose element type is the + same as the element type of the first two operands.
--The first two operands of a 'shufflevector' instruction are vectors -with types that match each other. The third argument is a shuffle mask whose -element type is always 'i32'. The result of the instruction is a vector whose -length is the same as the shuffle mask and whose element type is the same as -the element type of the first two operands. -
- --The shuffle mask operand is required to be a constant vector with either -constant integer or undef values. -
+The shuffle mask operand is required to be a constant vector with either + constant integer or undef values.
-The elements of the two input vectors are numbered from left to right across -both of the vectors. The shuffle mask operand specifies, for each element of -the result vector, which element of the two input vectors the result element -gets. The element selector may be undef (meaning "don't care") and the second -operand may be undef if performing a shuffle from only one vector. -
+The elements of the two input vectors are numbered from left to right across + both of the vectors. The shuffle mask operand specifies, for each element of + the result vector, which element of the two input vectors the result element + gets. The element selector may be undef (meaning "don't care") and the + second operand may be undef if performing a shuffle from only one vector.
- %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,
- <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,
- <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,
- <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 > ; yields <8 x i32>
-
-LLVM supports several instructions for working with aggregate values. -
- -
- <result> = extractvalue <aggregate type> <val>, <idx>{, <idx>}*
-
-
--The 'extractvalue' instruction extracts the value of a struct field -or array element from an aggregate value. -
- - --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 -'getelementptr' instruction. -
- --The result is the value at the position in the aggregate specified by -the index operands. -
- -
- %result = extractvalue {i32, float} %agg, 0 ; yields i32
-
-- <result> = insertvalue <aggregate type> <val>, <ty> <val>, <idx> ; yields <n x <ty>> -- -
-The 'insertvalue' instruction inserts a value -into a struct field or array element in an aggregate. -
- - --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 -'getelementptr' instruction. -The value to insert must have the same type as the value identified -by the indices. -
- --The result is an aggregate of the same type as val. Its -value is that of val except that the value at the position -specified by the indices is that of elt. -
- -
- %result = insertvalue {i32, float} %agg, i32 1, 0 ; yields {i32, float}
+ <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,
+ <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,
+ <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 > ; yields <8 x i32>
-A key design point of an SSA-based representation is how it -represents memory. In LLVM, no memory locations are in SSA form, which -makes things very simple. This section describes how to read, write, -allocate, and free memory in LLVM.
+LLVM supports several instructions for working with + aggregate values.
- <result> = malloc <type>[, i32 <NumElements>][, align <alignment>] ; yields {type*}:result
+ <result> = extractvalue <aggregate type> <val>, <idx>{, <idx>}*
The 'malloc' instruction allocates memory from the system -heap and returns a pointer to it. The object is always allocated in the generic -address space (address space zero).
+The 'extractvalue' instruction extracts the value of a member field + from an aggregate value.
The 'malloc' instruction allocates -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, 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.
+The first operand of an 'extractvalue' instruction is a value + 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.
Memory is allocated using the system "malloc" function, and -a pointer is returned. The result of a zero byte allocattion is undefined. The -result is null if there is insufficient memory available.
+The result is the value at the position in the aggregate specified by the + index operands.
- %array = malloc [4 x i8 ] ; yields {[%4 x i8]*}:array
-
- %size = add i32 2, 2 ; yields {i32}:size = i32 4
- %array1 = malloc i8, i32 4 ; yields {i8*}:array1
- %array2 = malloc [12 x i8], i32 %size ; yields {[12 x i8]*}:array2
- %array3 = malloc i32, i32 4, align 1024 ; yields {i32*}:array3
- %array4 = malloc i32, align 1024 ; yields {i32*}:array4
+ <result> = extractvalue {i32, float} %agg, 0 ; yields i32
+
- free <type> <value> ; yields {void}
+ <result> = insertvalue <aggregate type> <val>, <ty> <elt>, <idx> ; yields <aggregate type>
The 'free' instruction returns memory back to the unused -memory heap to be reallocated in the future.
+The 'insertvalue' instruction inserts a value into a member field + in an aggregate value.
'value' shall be a pointer value that points to a value -that was allocated with the 'malloc' -instruction.
+The first operand of an 'insertvalue' instruction is a value + 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.
Access to the memory pointed to by the pointer is no longer defined -after this instruction executes. If the pointer is null, the operation -is a noop.
+The result is an aggregate of the same type as val. Its value is + that of val except that the value at the position specified by the + indices is that of elt.
- %array = malloc [4 x i8] ; yields {[4 x i8]*}:array - free [4 x i8]* %array + %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}+ +
A key design point of an SSA-based representation is how it represents + memory. In LLVM, no memory locations are in SSA form, which makes things + very simple. This section describes how to read, write, and allocate + memory in LLVM.
+
<result> = alloca <type>[, i32 <NumElements>][, align <alignment>] ; yields {type*}:result
The 'alloca' instruction allocates memory on the stack frame of the -currently executing function, to be automatically released when this function -returns to its caller. The object is always allocated in the generic address -space (address space zero).
+ currently executing function, to be automatically released when this function + returns to its caller. The object is always allocated in the generic address + 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, 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.
+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, + 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 compatible with the + type.
'type' may be any sized type.
Memory is allocated; a pointer is returned. The operation is undefiend if -there is insufficient stack space for the allocation. 'alloca'd -memory is automatically released when the function returns. The 'alloca' -instruction is commonly used to represent automatic variables that must -have an address available. When the function returns (either with the ret or unwind -instructions), the memory is reclaimed. Allocating zero bytes -is legal, but the result is undefined.
+Memory is allocated; a pointer is returned. The operation is undefined if + there is insufficient stack space for the allocation. 'alloca'd + memory is automatically released when the function returns. The + 'alloca' instruction is commonly used to represent automatic + variables that must have an address available. When the function returns + (either with the ret + or unwind instructions), the memory is + reclaimed. Allocating zero bytes is legal, but the result is undefined.
- %ptr = alloca i32 ; yields {i32*}:ptr
- %ptr = alloca i32, i32 4 ; yields {i32*}:ptr
- %ptr = alloca i32, i32 4, align 1024 ; yields {i32*}:ptr
- %ptr = alloca i32, align 1024 ; yields {i32*}:ptr
+ %ptr = alloca i32 ; yields {i32*}:ptr
+ %ptr = alloca i32, i32 4 ; yields {i32*}:ptr
+ %ptr = alloca i32, i32 4, align 1024 ; yields {i32*}:ptr
+ %ptr = alloca i32, align 1024 ; yields {i32*}:ptr
+
<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 }
+
+
The 'load' instruction is used to read from memory.
+The argument to the 'load' instruction specifies the memory -address 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.
--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 -to ensure that the alignment information is correct. Overestimating -the alignment results in an undefined behavior. Underestimating the -alignment may produce less efficient code. An alignment of 1 is always -safe. -
+The argument to the 'load' instruction specifies the memory address + 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.
+ +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 to + ensure that the alignment information is correct. Overestimating the + 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 existance 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 intruction on x86.
+The location of memory pointed to is loaded.
+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 + of bytes needed to hold all bits of the type. For example, loading an + i24 reads at most three bytes. When loading a value of a type like + i20 with a size that is not an integral number of bytes, the result + is undefined if the value was not originally written using a store of the + same type.
+%ptr = alloca i32 ; yields {i32*}:ptr - store i32 3, i32* %ptr ; yields {void} ++ %ptr = alloca i32 ; yields {i32*}:ptr + store i32 3, i32* %ptr ; yields {void} %val = load i32* %ptr ; yields {i32}:val = i32 3+
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 !] ; yields {void}
+ volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !] ; yields {void}
+
Overview:
The 'store' instruction is used to write to memory.
+
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 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 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
-to ensure that the alignment information is correct. Overestimating
-the alignment results in an undefined behavior. Underestimating the
-alignment may produce less efficient code. An alignment of 1 is always
-safe.
-
+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 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 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 to
+ ensure that the alignment information is correct. Overestimating the
+ 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 corresponding to a metadata node with one i32 entry of
+ value 1. The existance 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 intruction on x86.
+
+
Semantics:
-The contents of memory are updated to contain '<value>'
-at the location specified by the '<pointer>' operand.
+The contents of memory are updated to contain '<value>' at the
+ location specified by the '<pointer>' operand. If
+ '<value>' is of scalar type then the number of bytes written
+ does not exceed the minimum number of bytes needed to hold all bits of the
+ type. For example, storing an i24 writes at most three bytes. When
+ writing a value of a type like i20 with a size that is not an
+ integral number of bytes, it is unspecified what happens to the extra bits
+ that do not belong to the type, but they will typically be overwritten.
+
Example:
- %ptr = alloca i32 ; yields {i32*}:ptr
+
+ %ptr = alloca i32 ; yields {i32*}:ptr
store i32 3, i32* %ptr ; yields {void}
%val = load i32* %ptr ; yields {i32}:val = i32 3
+
<result> = getelementptr <pty>* <ptrval>{, <ty> <idx>}*
+ <result> = getelementptr inbounds <pty>* <ptrval>{, <ty> <idx>}*
-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.
+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.
The first argument is always a pointer, and forms the basis of the -calculation. The remaining arguments are indices, that indicate which of the -elements of the aggregate object are indexed. The interpretation of each index -is dependent on the type being indexed into. The first index always 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.
+ calculation. The remaining arguments are indices that indicate which of the + elements of the aggregate object are indexed. The interpretation of each + index is dependent on the type being indexed into. The first index always + 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, 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 (packed) structure, only i32 integer -constants are allowed. When indexing into an array, pointer or vector, -only integers of 32 or 64 bits are allowed (also non-constants). 32-bit values -will be sign extended to 64-bits if required.
+ 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:
+For example, let's consider a C code fragment and how it gets compiled to + LLVM:
@@ -3399,10 +4253,10 @@ int *foo(struct ST *s) {
-%RT = type { i8 , [10 x [20 x i32]], i8 }
-%ST = type { i32, double, %RT }
+%RT = type { i8 , [10 x [20 x i32]], i8 }
+%ST = type { i32, double, %RT }
-define i32* %foo(%ST* %s) {
+define i32* @foo(%ST* %s) {
entry:
%reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13
ret i32* %reg
@@ -3411,23 +4265,22 @@ entry:
Semantics:
-
In the example above, the first index is indexing into the '%ST*'
-type, which is a pointer, yielding a '%ST' = '{ i32, double, %RT
-}' type, a structure. The second index indexes into the third element of
-the structure, yielding a '%RT' = '{ i8 , [10 x [20 x i32]],
-i8 }' type, another structure. The third index indexes into the second
-element of the structure, yielding a '[10 x [20 x i32]]' type, an
-array. The two dimensions of the array are subscripted into, yielding an
-'i32' type. The 'getelementptr' instruction returns a pointer
-to this element, thus computing a value of 'i32*' type.
+ type, which is a pointer, yielding a '%ST' = '{ i32, double, %RT
+ }' type, a structure. The second index indexes into the third element
+ of the structure, yielding a '%RT' = '{ i8 , [10 x [20 x i32]],
+ i8 }' type, another structure. The third index indexes into the second
+ element of the structure, yielding a '[10 x [20 x i32]]' type, an
+ array. The two dimensions of the array are subscripted into, yielding an
+ 'i32' type. The 'getelementptr' instruction returns a
+ pointer to this element, thus computing a value of 'i32*' type.
-Note that it is perfectly legal to index partially through a
-structure, returning a pointer to an inner element. Because of this,
-the LLVM code for the given testcase is equivalent to:
+Note that it is perfectly legal to index partially through a structure,
+ returning a pointer to an inner element. Because of this, the LLVM code for
+ the given testcase is equivalent to:
- define i32* %foo(%ST* %s) {
+ define i32* @foo(%ST* %s) {
%t1 = getelementptr %ST* %s, i32 1 ; yields %ST*:%t1
%t2 = getelementptr %ST* %t1, i32 0, i32 2 ; yields %RT*:%t2
%t3 = getelementptr %RT* %t2, i32 0, i32 1 ; yields [10 x [20 x i32]]*:%t3
@@ -3437,18 +4290,27 @@ the LLVM code for the given testcase is equivalent to:
}
-Note that it is undefined to access an array out of bounds: array and
-pointer indexes must always be within the defined bounds of the array type.
-The one exception for this rule is zero length arrays. These arrays are
-defined to be accessible as variable length arrays, which requires access
-beyond the zero'th element.
+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.
-The getelementptr instruction is often confusing. For some more insight
-into how it works, see the getelementptr
-FAQ.
+If the inbounds keyword is not present, the offsets are added to
+ the base address with silently-wrapping two's complement arithmetic, and
+ the result value of the getelementptr may be outside the object
+ pointed to by the base pointer. The result value may not necessarily be
+ used to access memory though, even if it happens to point into allocated
+ storage. See the Pointer Aliasing Rules
+ section for more information.
-Example:
+The getelementptr instruction is often confusing. For some more insight into
+ how it works, see the getelementptr FAQ.
+Example:
; yields [12 x i8]*:aptr
%aptr = getelementptr {i32, [12 x i8]}* %saptr, i64 0, i32 1
@@ -3456,16 +4318,22 @@ FAQ.
%vptr = getelementptr {i32, <2 x i8>}* %svptr, i64 0, i32 1, i32 1
; yields i8*:eptr
%eptr = getelementptr [12 x i8]* %aptr, i64 0, i32 1
+ ; yields i32*:iptr
+ %iptr = getelementptr [10 x i32]* @arr, i16 0, i16 0
+
The instructions in this category are the conversion instructions (casting) -which all take a single operand and a type. They perform various bit conversions -on the operand.
+ which all take a single operand and a type. They perform various bit + conversions on the operand. +-The 'trunc' instruction truncates its operand to the type ty2. -
+The 'trunc' instruction truncates its operand to the + type ty2.
-The 'trunc' instruction takes a value to trunc, which must -be an integer type, and a type that specifies the size -and type of the result, which must be an integer -type. The bit size of value must be larger than the bit size of -ty2. Equal sized types are not allowed.
+The 'trunc' instruction takes a value to trunc, which must + be an integer type, and a type that specifies the + size and type of the result, which must be + an integer type. The bit size of value must + be larger than the bit size of ty2. Equal sized types are not + allowed.
-The 'trunc' instruction truncates the high order bits in value -and converts the remaining bits to ty2. Since the source size must be -larger than the destination size, trunc cannot be a no-op cast. -It will always truncate bits.
+The 'trunc' instruction truncates the high order bits + in value and converts the remaining bits to ty2. Since the + source size must be larger than the destination size, trunc cannot + be a no-op cast. It will always truncate bits.
%X = trunc i32 257 to i8 ; yields i8:1 %Y = trunc i32 123 to i1 ; yields i1:true - %Y = trunc i32 122 to i1 ; yields i1:false + %Z = trunc i32 122 to i1 ; yields i1:false+
The 'zext' instruction zero extends its operand to type -ty2.
+The 'zext' instruction zero extends its operand to type + ty2.
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, -ty2.
+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, + ty2.
The zext fills the high order bits of the value with zero -bits until it reaches the size of the destination type, ty2.
+ bits until it reaches the size of the destination type, ty2.When zero extending from i1, the result will always be either 0 or 1.
@@ -3541,6 +4408,7 @@ bits until it reaches the size of the destination type, ty2. %X = zext i32 257 to i64 ; yields i64:257 %Y = zext i1 true to i32 ; yields i32:1 + @@ -3558,18 +4426,16 @@ bits until it reaches the size of the destination type, ty2.The 'sext' sign extends value to the type ty2.
-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, -ty2.
+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, + ty2.
-The 'sext' instruction performs a sign extension by copying the sign -bit (highest order bit) of the value until it reaches the bit size of -the type ty2.
+The 'sext' instruction performs a sign extension by copying the sign + bit (highest order bit) of the value until it reaches the bit size + of the type ty2.
When sign extending from i1, the extension always results in -1 or 0.
@@ -3578,6 +4444,7 @@ the type ty2. %X = sext i8 -1 to i16 ; yields i16 :65535 %Y = sext i1 true to i32 ; yields i32:-1 + @@ -3588,34 +4455,34 @@ the type ty2.<result> = fptrunc <ty> <value> to <ty2> ; yields ty2
The 'fptrunc' instruction truncates value to type -ty2.
- + ty2.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 -no-op cast.
+ 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 + no-op cast.The 'fptrunc' instruction truncates a value from a larger -floating point type to a smaller -floating point type. If the value cannot fit within -the destination type, ty2, then the results are undefined.
+The 'fptrunc' instruction truncates a value from a larger + floating point type to a smaller + floating point type. If the value cannot fit + within the destination type, ty2, then the results are + undefined.
%X = fptrunc double 123.0 to float ; yields float:123.0 %Y = fptrunc double 1.0E+300 to float ; yields undefined+
The 'fpext' extends a floating point value to a larger -floating point value.
+ floating point value.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.
+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.
The 'fpext' instruction extends the value from a smaller -floating point type to a larger -floating point type. The fpext cannot be -used to make a no-op cast because it always changes bits. Use -bitcast to make a no-op cast for a floating point cast.
+ floating point type to a larger + floating point type. The fpext cannot be + used to make a no-op cast because it always changes bits. Use + bitcast to make a no-op cast for a floating point cast.%X = fpext float 3.1415 to double ; yields double:3.1415 %Y = fpext float 1.0 to float ; yields float:1.0 (no-op)+ @@ -3666,28 +4534,28 @@ used to make a no-op cast because it always changes bits. Use
The 'fptoui' converts a floating point value to its -unsigned integer equivalent of type ty2. -
+ unsigned integer equivalent of type ty2.The 'fptoui' instruction takes a value to cast, which must be a -scalar or vector floating point value, and a type -to cast it to ty2, which must be an integer -type. If ty is a vector floating point type, ty2 must be a -vector integer type with the same number of elements as ty
+The 'fptoui' instruction takes a value to cast, which must be a + scalar or vector floating point value, and a type + to cast it to ty2, which must be an integer + type. If ty is a vector floating point type, ty2 must be a + vector integer type with the same number of elements as ty
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.
+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.
%X = fptoui double 123.0 to i32 ; yields i32:123 %Y = fptoui float 1.0E+300 to i1 ; yields undefined:1 - %X = fptoui float 1.04E+17 to i8 ; yields undefined:1 + %Z = fptoui float 1.04E+17 to i8 ; yields undefined:1+ @@ -3702,29 +4570,30 @@ the results are undefined.
The 'fptosi' instruction converts -floating point value to type ty2. -
+The 'fptosi' instruction converts + floating point value to + type ty2.
The 'fptosi' instruction takes a value to cast, which must be a -scalar or vector floating point value, and a type -to cast it to ty2, which must be an integer -type. If ty is a vector floating point type, ty2 must be a -vector integer type with the same number of elements as ty
+The 'fptosi' instruction takes a value to cast, which must be a + scalar or vector floating point value, and a type + to cast it to ty2, which must be an integer + type. If ty is a vector floating point type, ty2 must be a + vector integer type with the same number of elements as ty
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.
+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.
%X = fptosi double -123.0 to i32 ; yields i32:-123 %Y = fptosi float 1.0E-247 to i1 ; yields undefined:1 - %X = fptosi float 1.04E+17 to i8 ; yields undefined:1 + %Z = fptosi float 1.04E+17 to i8 ; yields undefined:1+ @@ -3740,25 +4609,27 @@ the results are undefined.
The 'uitofp' instruction regards value as an unsigned -integer and converts that value to the ty2 type.
+ integer and converts that value to the ty2 type.The 'uitofp' instruction takes a value to cast, which must be a -scalar or vector integer value, and a type to cast it -to ty2, which must be an floating point -type. If ty is a vector integer type, ty2 must be a vector -floating point type with the same number of elements as ty
+ scalar or vector integer value, and a type to cast + it to ty2, which must be an floating point + type. If ty is a vector integer type, ty2 must be a vector + floating point type with the same number of elements as tyThe 'uitofp' instruction interprets its operand as an unsigned -integer quantity and converts it to the corresponding floating point value. If -the value cannot fit in the floating point value, the results are undefined.
+ integer quantity and converts it to the corresponding floating point + value. If the value cannot fit in the floating point value, the results are + undefined.%X = uitofp i32 257 to float ; yields float:257.0 %Y = uitofp i8 -1 to double ; yields double:255.0+ @@ -3773,26 +4644,27 @@ the value cannot fit in the floating point value, the results are undefined.
The 'sitofp' instruction regards value as a signed -integer and converts that value to the ty2 type.
+The 'sitofp' instruction regards value as a signed integer + and converts that value to the ty2 type.
The 'sitofp' instruction takes a value to cast, which must be a -scalar or vector integer value, and a type to cast it -to ty2, which must be an floating point -type. If ty is a vector integer type, ty2 must be a vector -floating point type with the same number of elements as ty
+ scalar or vector integer value, and a type to cast + it to ty2, which must be an floating point + type. If ty is a vector integer type, ty2 must be a vector + floating point type with the same number of elements as tyThe 'sitofp' instruction interprets its operand as a signed -integer quantity and converts it to the corresponding floating point value. If -the value cannot fit in the floating point value, the results are undefined.
+The 'sitofp' instruction interprets its operand as a signed integer + quantity and converts it to the corresponding floating point value. If the + value cannot fit in the floating point value, the results are undefined.
%X = sitofp i32 257 to float ; yields float:257.0 %Y = sitofp i8 -1 to double ; yields double:-1.0+ @@ -3807,28 +4679,29 @@ the value cannot fit in the floating point value, the results are undefined.
The 'ptrtoint' instruction converts the pointer value to -the integer type ty2.
+The 'ptrtoint' instruction converts the pointer value to + the integer type ty2.
The 'ptrtoint' instruction takes a value to cast, which -must be a pointer value, and a type to cast it to -ty2, which must be an integer type.
+The 'ptrtoint' instruction takes a value to cast, which + must be a pointer value, and a type to cast it to + ty2, which must be an integer type.
The 'ptrtoint' instruction converts value to integer type -ty2 by interpreting the pointer value as an integer and either -truncating or zero extending that value to the size of the integer type. If -value is smaller than ty2 then a zero extension is done. If -value is larger than ty2 then a truncation is done. If they -are the same size, then nothing is done (no-op cast) other than a type -change.
+ ty2 by interpreting the pointer value as an integer and either + truncating or zero extending that value to the size of the integer type. If + value is smaller than ty2 then a zero extension is done. If + value is larger than ty2 then a truncation is done. If they + are the same size, then nothing is done (no-op cast) other than a type + change.%X = ptrtoint i32* %X to i8 ; yields truncation on 32-bit architecture %Y = ptrtoint i32* %x to i64 ; yields zero extension on 32-bit architecture+ @@ -3843,28 +4716,29 @@ change.
The 'inttoptr' instruction converts an integer value to -a pointer type, ty2.
+The 'inttoptr' instruction converts an integer value to a + pointer type, ty2.
The 'inttoptr' instruction takes an integer -value to cast, and a type to cast it to, which must be a -pointer type.
+ value to cast, and a type to cast it to, which must be a + pointer type.The 'inttoptr' instruction converts value to type -ty2 by applying either a zero extension or a truncation depending on -the size of the integer value. If value is larger than the -size of a pointer then a truncation is done. If value is smaller than -the size of a pointer then a zero extension is done. If they are the same size, -nothing is done (no-op cast).
+ ty2 by applying either a zero extension or a truncation depending on + the size of the integer value. If value is larger than the + size of a pointer then a truncation is done. If value is smaller + than the size of a pointer then a zero extension is done. If they are the + same size, nothing is done (no-op cast).%X = inttoptr i32 255 to i32* ; yields zero extension on 64-bit architecture - %X = inttoptr i32 255 to i32* ; yields no-op on 32-bit architecture - %Y = inttoptr i64 0 to i32* ; yields truncation on 32-bit architecture + %Y = inttoptr i32 255 to i32* ; yields no-op on 32-bit architecture + %Z = inttoptr i64 0 to i32* ; yields truncation on 32-bit architecture+ @@ -3879,61 +4753,68 @@ nothing is done (no-op cast).
The 'bitcast' instruction converts value to type -ty2 without changing any bits.
+ ty2 without changing any bits.The 'bitcast' instruction takes a value to cast, which must be -a non-aggregate first class value, and a type to cast it to, which must also be -a non-aggregate first class type. The bit sizes of -value -and the destination type, ty2, must be identical. If the source -type is a pointer, the destination type must also be a pointer. This -instruction supports bitwise conversion of vectors to integers and to vectors -of other types (as long as they have the same size).
+The 'bitcast' instruction takes a value to cast, which must be a + non-aggregate first class value, and a type to cast it to, which must also be + a non-aggregate first class type. The bit sizes + of value and the destination type, ty2, must be + identical. If the source type is a pointer, the destination type must also be + a pointer. This instruction supports bitwise conversion of vectors to + integers and to vectors of other types (as long as they have the same + size).
The 'bitcast' instruction converts value to type -ty2. It is always a no-op cast because no bits change with -this conversion. The conversion is done as if the value had been -stored to memory and read back as type ty2. Pointer types may only be -converted to other pointer types with this instruction. To convert pointers to -other types, use the inttoptr or -ptrtoint instructions first.
+ ty2. It is always a no-op cast because no bits change with + this conversion. The conversion is done as if the value had been + stored to memory and read back as type ty2. Pointer types may only + be converted to other pointer types with this instruction. To convert + pointers to other types, use the inttoptr or + ptrtoint instructions first.%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+ +
The instructions in this category are the "miscellaneous" -instructions, which defy better classification.
+ +The instructions in this category are the "miscellaneous" instructions, which + defy better classification.
+ <result> = icmp <cond> <ty> <op1>, <op2> ; yields {i1} or {<N x i1>}:result
+
+ <result> = icmp <cond> <ty> <op1>, <op2> ; yields {i1} or {<N x i1>}:result
+
Overview:
-The 'icmp' instruction returns a boolean value or
-a vector of boolean values based on comparison
-of its two integer, integer vector, or pointer operands.
+The 'icmp' instruction returns a boolean value or a vector of
+ boolean values based on comparison of its two integer, integer vector, or
+ pointer operands.
+
Arguments:
The 'icmp' instruction takes three operands. The first operand is
-the condition code indicating the kind of comparison to perform. It is not
-a value, just a keyword. The possible condition code are:
-
+ the condition code indicating the kind of comparison to perform. It is not a
+ value, just a keyword. The possible condition code are:
+
- eq: equal
- ne: not equal
@@ -3946,78 +4827,102 @@ a value, just a keyword. The possible condition code are:
- slt: signed less than
- sle: signed less or equal
+
The remaining two arguments must be integer or
-pointer
-or integer vector typed.
-They must also be identical types.
+ pointer or integer vector
+ typed. They must also be identical types.
+
Semantics:
-The 'icmp' compares op1 and op2 according to
-the condition code given as cond. The comparison performed always
-yields either an i1 or vector of i1 result, as follows:
-
+The 'icmp' compares op1 and op2 according to the
+ condition code given as cond. The comparison performed always yields
+ either an i1 or vector of i1
+ result, as follows:
+
- - 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,
- false otherwise. No sign interpretation is necessary or performed.
+ - 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,
+ false otherwise. No sign interpretation is necessary or
+ performed.
+
- ugt: interprets the operands as unsigned values and yields
- true if op1 is greater than op2.
+ true if op1 is greater than op2.
+
- uge: interprets the operands as unsigned values and yields
- true if op1 is greater than or equal to op2.
+ true if op1 is greater than or equal
+ to op2.
+
- ult: interprets the operands as unsigned values and yields
- true if op1 is less than op2.
+ true if op1 is less than op2.
+
- ule: interprets the operands as unsigned values and yields
- true if op1 is less than or equal to op2.
+ true if op1 is less than or equal to op2.
+
- sgt: interprets the operands as signed values and yields
- true if op1 is greater than op2.
+ true if op1 is greater than op2.
+
- sge: interprets the operands as signed values and yields
- true if op1 is greater than or equal to op2.
+ true if op1 is greater than or equal
+ to op2.
+
- slt: interprets the operands as signed values and yields
- true if op1 is less than op2.
+ true if op1 is less than op2.
+
- sle: interprets the operands as signed values and yields
- true if op1 is less than or equal to op2.
+ true if op1 is less than or equal to op2.
+
If the operands are pointer typed, the pointer
-values are compared as if they were integers.
-If the operands are integer vectors, then they are compared
-element by element. The result is an i1 vector with
-the same number of elements as the values being compared.
-Otherwise, the result is an i1.
-
+ values are compared as if they were integers.
+
+If the operands are integer vectors, then they are compared element by
+ element. The result is an i1 vector with the same number of elements
+ as the values being compared. Otherwise, the result is an i1.
Example:
- <result> = icmp eq i32 4, 5 ; yields: result=false
+
+ <result> = icmp eq i32 4, 5 ; yields: result=false
<result> = icmp ne float* %X, %X ; yields: result=false
<result> = icmp ult i16 4, 5 ; yields: result=true
<result> = icmp sgt i16 4, 5 ; yields: result=false
<result> = icmp ule i16 -4, 5 ; yields: result=false
<result> = icmp sge i16 4, 5 ; yields: result=false
+
+Note that the code generator does not yet support vector types with
+ the icmp instruction.
+
<result> = fcmp <cond> <ty> <op1>, <op2> ; yields {i1} or {<N x i1>}:result
+
+ <result> = fcmp <cond> <ty> <op1>, <op2> ; yields {i1} or {<N x i1>}:result
+
Overview:
-The 'fcmp' instruction returns a boolean value
-or vector of boolean values based on comparison
-of its operands.
-
-If the operands are floating point scalars, then the result
-type is a boolean (i1).
-
-If the operands are floating point vectors, then the result type
-is a vector of boolean with the same number of elements as the
-operands being compared.
+The 'fcmp' instruction returns a boolean value or vector of boolean
+ values based on comparison of its operands.
+
+If the operands are floating point scalars, then the result type is a boolean
+(i1).
+
+If the operands are floating point vectors, then the result type is a vector
+ of boolean with the same number of elements as the operands being
+ compared.
+
Arguments:
The 'fcmp' instruction takes three operands. The first operand is
-the condition code indicating the kind of comparison to perform. It is not
-a value, just a keyword. The possible condition code are:
+ the condition code indicating the kind of comparison to perform. It is not a
+ value, just a keyword. The possible condition code are:
+
- false: no comparison, always returns false
- oeq: ordered and equal
@@ -4036,159 +4941,79 @@ a value, just a keyword. The possible condition code are:
- uno: unordered (either nans)
- true: no comparison, always returns true
+
Ordered means that neither operand is a QNAN while
-unordered means that either operand may be a QNAN.
-Each of val1 and val2 arguments must be
-either a floating point type
-or a vector of floating point type.
-They must have identical types.
+ unordered means that either operand may be a QNAN.
+
+Each of val1 and val2 arguments must be either
+ a floating point type or
+ a vector of floating point type. They must have
+ identical types.
+
Semantics:
The 'fcmp' instruction compares op1 and op2
-according to the condition code given as cond.
-If the operands are vectors, then the vectors are compared
-element by element.
-Each comparison performed
-always yields an i1 result, as follows:
+ according to the condition code given as cond. If the operands are
+ vectors, then the vectors are compared element by element. Each comparison
+ performed always yields an i1 result, as
+ follows:
+
- false: always yields false, regardless of operands.
- - oeq: yields true if both operands are not a QNAN and
- op1 is equal to op2.
+
+ - 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.
- - 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
- op1 is less than op2.
- - 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
- op1 is not equal to op2.
+ op1 is greather than op2.
+
+ - 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
+ op1 is less than op2.
+
+ - 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
+ 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
- op1 is equal to op2.
- - 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
- op1 is greater than or equal to op2.
- - 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
- op1 is less than or equal to op2.
- - une: yields true if either operand is a QNAN or
- op1 is not equal to op2.
+
+ - 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
+ op1 is greater than op2.
+
+ - 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
+ op1 is less than op2.
+
+ - 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
+ op1 is not equal to op2.
+
- uno: yields true if either operand is a QNAN.
+
- true: always yields true, regardless of operands.
Example:
- <result> = fcmp oeq float 4.0, 5.0 ; yields: result=false
+
+ <result> = fcmp oeq float 4.0, 5.0 ; yields: result=false
<result> = fcmp one float 4.0, 5.0 ; yields: result=true
<result> = fcmp olt float 4.0, 5.0 ; yields: result=true
<result> = fcmp ueq double 1.0, 2.0 ; yields: result=false
-
<result> = vicmp <cond> <ty> <op1>, <op2> ; yields {ty}:result
-
-The 'vicmp' instruction returns an integer vector value based on -element-wise comparison of its two integer vector operands.
-The 'vicmp' instruction takes three operands. The first operand is -the condition code indicating the kind of comparison to perform. It is not -a value, just a keyword. The possible condition code are:
-The remaining two arguments must be vector or -integer typed. They must also be identical types.
-The 'vicmp' instruction compares op1 and op2 -according to the condition code given as cond. The comparison yields a -vector of integer result, of -identical type as the values being compared. The most significant bit in each -element is 1 if the element-wise comparison evaluates to true, and is 0 -otherwise. All other bits of the result are undefined. The condition codes -are evaluated identically to the 'icmp' -instruction.
- -- <result> = vicmp eq <2 x i32> < i32 4, i32 0>, < i32 5, i32 0> ; yields: result=<2 x i32> < i32 0, i32 -1 > - <result> = vicmp ult <2 x i8 > < i8 1, i8 2>, < i8 2, i8 2 > ; yields: result=<2 x i8> < i8 -1, i8 0 > --
<result> = vfcmp <cond> <ty> <op1>, <op2>-
The 'vfcmp' instruction returns an integer vector value based on -element-wise comparison of its two floating point vector operands. The output -elements have the same width as the input elements.
-The 'vfcmp' instruction takes three operands. The first operand is -the condition code indicating the kind of comparison to perform. It is not -a value, just a keyword. The possible condition code are:
-The remaining two arguments must be vector of -floating point typed. They must also be identical -types.
-The 'vfcmp' instruction compares op1 and op2 -according to the condition code given as cond. The comparison yields a -vector of integer result, with -an identical number of elements as the values being compared, and each element -having identical with to the width of the floating point elements. The most -significant bit in each element is 1 if the element-wise comparison evaluates to -true, and is 0 otherwise. All other bits of the result are undefined. The -condition codes are evaluated identically to the -'fcmp' instruction.
+Note that the code generator does not yet support vector types with + the fcmp instruction.
-- ; yields: result=<2 x i32> < i32 0, i32 -1 > - <result> = vfcmp oeq <2 x float> < float 4, float 0 >, < float 5, float 0 > - - ; yields: result=<2 x i64> < i64 -1, i64 0 > - <result> = vfcmp ult <2 x double> < double 1, double 2 >, < double 2, double 2> -
+ <result> = phi <ty> [ <val0>, <label0>], ... +-
<result> = phi <ty> [ <val0>, <label0>], ...
The 'phi' instruction is used to implement the φ node in -the SSA graph representing the function.
-The type of the incoming values is specified with the first type -field. After this, the 'phi' instruction takes a list of pairs -as arguments, with one pair for each predecessor basic block of the -current block. Only values of first class -type may be used as the value arguments to the PHI node. Only labels -may be used as the label arguments.
+The 'phi' instruction is used to implement the φ node in the + SSA graph representing the function.
-There must be no non-phi instructions between the start of a basic -block and the PHI instructions: i.e. PHI instructions must be first in -a basic block.
+The type of the incoming values is specified with the first type field. After + this, the 'phi' instruction takes a list of pairs as arguments, with + one pair for each predecessor basic block of the current block. Only values + of first class type may be used as the value + arguments to the PHI node. Only labels may be used as the label + arguments.
+ +There must be no non-phi instructions between the start of a basic block and + the PHI instructions: i.e. PHI instructions must be first in a basic + block.
+ +For the purposes of the SSA form, the use of each incoming value is deemed to + occur on the edge from the corresponding predecessor block to the current + block (but after any definition of an 'invoke' instruction's return + value on the same edge).
At runtime, the 'phi' instruction logically takes on the value -specified by the pair corresponding to the predecessor basic block that executed -just prior to the current block.
+ specified by the pair corresponding to the predecessor basic block that + executed just prior to the current block.@@ -4230,6 +5061,7 @@ Loop: ; Infinite loop that counts from 0 on up... %nextindvar = add i32 %indvar, 1 br label %Loop+
<result> = select selty <cond>, <ty> <val1>, <ty> <val2> ; yields ty @@ -4248,43 +5079,33 @@ Loop: ; Infinite loop that counts from 0 on up...
-The 'select' instruction is used to choose one value based on a -condition, without branching. -
+The 'select' instruction is used to choose one value based on a + condition, without branching.
-The 'select' instruction requires an 'i1' value or -a vector of 'i1' values indicating the -condition, and two values of the same first class -type. If the val1/val2 are vectors and -the condition is a scalar, then entire vectors are selected, not -individual elements. -
+The 'select' instruction requires an 'i1' value or a vector of 'i1' + values indicating the condition, and two values of the + same first class type. If the val1/val2 are + vectors and the condition is a scalar, then entire vectors are selected, not + individual elements.
If the condition is an i1 and it evaluates to 1, the instruction returns the + first value argument; otherwise, it returns the second value argument.
--If the condition is an i1 and it evaluates to 1, the instruction returns the first -value argument; otherwise, it returns the second value argument. -
--If the condition is a vector of i1, then the value arguments must -be vectors of the same size, and the selection is done element -by element. -
+If the condition is a vector of i1, then the value arguments must be vectors + of the same size, and the selection is done element by element.
%X = select i1 true, i8 17, i8 42 ; yields i8:17-
Note that the code generator does not yet support conditions + with vector type.
+ +The 'call' instruction represents a simple function call.
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 "cconv" marker indicates which calling - convention the call should use. If none is specified, the call defaults - to using C calling conventions.
+llvm::PerformTailCallOpt is true.The optional Parameter Attributes list for - return values. Only 'zeroext', 'signext', - and 'inreg' attributes are valid here.
-'ty': the type of the call instruction itself which is also - the type of the return value. Functions that return no value are marked - void.
-'fnty': shall be the signature of the pointer to function - value being invoked. The argument types must match the types implied by - this signature. This type can be omitted if the function is not varargs - and if the function type does not return a pointer to a function.
-'fnptrval': An LLVM value containing a pointer to a function to - be invoked. In most cases, this is a direct function invocation, but - indirect calls are just as possible, calling an arbitrary pointer - 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.
-The optional function attributes list. Only - 'noreturn', 'nounwind', 'readonly' and - 'readnone' attributes are valid here.
-The 'call' instruction is used to cause control flow to -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.
+The 'call' instruction is used to cause control flow to 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.
%retval = call i32 @test(i32 %argc) call i32 (i8 *, ...)* @printf(i8 * %msg, i32 12, i8 42) ; yields i32 @@ -4383,6 +5205,12 @@ function is bound to the result argument. %ZZ = call zeroext i32 @bar() ; Return value is %zero extended+
llvm treats calls to some functions with names and arguments that match the +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.
+<resultval> = va_arg <va_list*> <arglist>, <argty>
The 'va_arg' instruction is used to access arguments passed through -the "variable argument" area of a function call. It is used to implement the -va_arg macro in C.
+ the "variable argument" area of a function call. It is used to implement the + va_arg macro in C.This instruction takes a va_list* value and the type of -the argument. It returns a value of the specified argument type and -increments the va_list to point to the next argument. The -actual type of va_list is target specific.
+This instruction takes a va_list* value and the type of the + argument. It returns a value of the specified argument type and increments + the va_list to point to the next argument. The actual type + of va_list is target specific.
The 'va_arg' instruction loads an argument of the specified -type from the specified va_list and causes the -va_list to point to the next argument. For more information, -see the variable argument handling Intrinsic -Functions.
+The 'va_arg' instruction loads an argument of the specified type + from the specified va_list and causes the va_list to point + to the next argument. For more information, see the variable argument + handling Intrinsic Functions.
It is legal for this instruction to be called in a function which does not -take a variable number of arguments, for example, the vfprintf -function.
+ take a variable number of arguments, for example, the vfprintf + function. -va_arg is an LLVM instruction instead of an intrinsic function because it takes a type as an -argument.
+va_arg is an LLVM instruction instead of + an intrinsic function because it takes a type as an + argument.
See the variable argument processing section.
+Note that the code generator does not yet fully support va_arg on many + targets. Also, it does not currently support va_arg with aggregate types on + any target.
+LLVM supports the notion of an "intrinsic function". These functions have -well known names and semantics and are required to follow certain restrictions. -Overall, these intrinsics represent an extension mechanism for the LLVM -language that does not require changing all of the transformations in LLVM when -adding to the language (or the bitcode reader/writer, the parser, etc...).
+ well known names and semantics and are required to follow certain + restrictions. Overall, these intrinsics represent an extension mechanism for + the LLVM language that does not require changing all of the transformations + in LLVM when adding to the language (or the bitcode reader/writer, the + parser, etc...).Intrinsic function names must all start with an "llvm." prefix. This -prefix is reserved in LLVM for intrinsic names; thus, function names may not -begin with this prefix. Intrinsic functions must always be external functions: -you cannot define the body of intrinsic functions. Intrinsic functions may -only be used in call or invoke instructions: it is illegal to take the address -of an intrinsic function. Additionally, because intrinsic functions are part -of the LLVM language, it is required if any are added that they be documented -here.
- -Some intrinsic functions can be overloaded, i.e., the intrinsic represents -a family of functions that perform the same operation but on different data -types. Because LLVM can represent over 8 million different integer types, -overloading is used commonly to allow an intrinsic function to operate on any -integer type. One or more of the argument types or the result type can be -overloaded to accept any integer type. Argument types may also be defined as -exactly matching a previous argument's type or the result type. This allows an -intrinsic function which accepts multiple arguments, but needs all of them to -be of the same type, to only be overloaded with respect to a single argument or -the result.
- -Overloaded intrinsics will have the names of its overloaded argument types -encoded into its function name, each preceded by a period. Only those types -which are overloaded result in a name suffix. Arguments whose type is matched -against another type do not. For example, the llvm.ctpop function can -take an integer of any width and returns an integer of exactly the same integer -width. This leads to a family of functions such as -i8 @llvm.ctpop.i8(i8 %val) and i29 @llvm.ctpop.i29(i29 %val). -Only one type, the return type, is overloaded, and only one type 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 -Extending LLVM Guide. -
+ prefix is reserved in LLVM for intrinsic names; thus, function names may not + begin with this prefix. Intrinsic functions must always be external + functions: you cannot define the body of intrinsic functions. Intrinsic + functions may only be used in call or invoke instructions: it is illegal to + take the address of an intrinsic function. Additionally, because intrinsic + functions are part of the LLVM language, it is required if any are added that + they be documented here. + +Some intrinsic functions can be overloaded, i.e., the intrinsic represents a + family of functions that perform the same operation but on different data + types. Because LLVM can represent over 8 million different integer types, + overloading is used commonly to allow an intrinsic function to operate on any + integer type. One or more of the argument types or the result type can be + overloaded to accept any integer type. Argument types may also be defined as + exactly matching a previous argument's type or the result type. This allows + an intrinsic function which accepts multiple arguments, but needs all of them + to be of the same type, to only be overloaded with respect to a single + argument or the result.
+ +Overloaded intrinsics will have the names of its overloaded argument types + encoded into its function name, each preceded by a period. Only those types + which are overloaded result in a name suffix. Arguments whose type is matched + against another type do not. For example, the llvm.ctpop function + can take an integer of any width and returns an integer of exactly the same + integer width. This leads to a family of functions such as + i8 @llvm.ctpop.i8(i8 %val) and i29 @llvm.ctpop.i29(i29 + %val). Only one type, the return type, is overloaded, and only one type + 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 + Extending LLVM Guide.
Variable argument support is defined in LLVM with the va_arg instruction and these three -intrinsic functions. These functions are related to the similarly -named macros defined in the <stdarg.h> header file.
+Variable argument support is defined in LLVM with + the va_arg instruction and these three + intrinsic functions. These functions are related to the similarly named + macros defined in the <stdarg.h> header file.
-All of these functions operate on arguments that use a -target-specific value type "va_list". The LLVM assembly -language reference manual does not define what this type is, so all -transformations should be prepared to handle these functions regardless of -the type used.
+All of these functions operate on arguments that use a target-specific value + type "va_list". The LLVM assembly language reference manual does + not define what this type is, so all transformations should be prepared to + handle these functions regardless of the type used.
This example shows how the va_arg -instruction and the variable argument handling intrinsic functions are -used.
+ instruction and the variable argument handling intrinsic functions are + used.@@ -4541,25 +5366,27 @@ declare void @llvm.va_end(i8*)+@@ -4569,26 +5396,28 @@ last argument of the function as the compiler can figure that out.Syntax:
-declare void %llvm.va_start(i8* <arglist>)++ declare void %llvm.va_start(i8* <arglist>) ++Overview:
-The 'llvm.va_start' intrinsic initializes -*<arglist> for subsequent use by va_arg.
+The 'llvm.va_start' intrinsic initializes *<arglist> + for subsequent use by va_arg.
Arguments:
-The argument is a pointer to a va_list element to initialize.
Semantics:
-The 'llvm.va_start' intrinsic works just like the va_start -macro available in C. In a target-dependent way, it initializes the -va_list element to which the argument points, so that the next call to -va_arg will produce the first variable argument passed to the function. -Unlike the C va_start macro, this intrinsic does not need to know the -last argument of the function as the compiler can figure that out.
+ macro available in C. In a target-dependent way, it initializes + the va_list element to which the argument points, so that the next + call to va_arg will produce the first variable argument passed to + the function. Unlike the C va_start macro, this intrinsic does not + need to know the last argument of the function as the compiler can figure + that out.
declare void @llvm.va_end(i8* <arglist>)-
+ declare void @llvm.va_end(i8* <arglist>) ++
The 'llvm.va_end' intrinsic destroys *<arglist>, -which has been initialized previously with llvm.va_start -or llvm.va_copy.
+ which has been initialized previously + with llvm.va_start + or llvm.va_copy.The argument is a pointer to a va_list to destroy.
The 'llvm.va_end' intrinsic works just like the va_end -macro available in C. In a target-dependent way, it destroys the -va_list element to which the argument points. Calls to llvm.va_start and -llvm.va_copy must be matched exactly with calls to -llvm.va_end.
+ macro available in C. In a target-dependent way, it destroys + the va_list element to which the argument points. Calls + to llvm.va_start + and llvm.va_copy must be matched exactly + with calls to llvm.va_end.declare void @llvm.va_copy(i8* <destarglist>, i8* <srcarglist>)
The 'llvm.va_copy' intrinsic copies the current argument position -from the source argument list to the destination argument list.
+ from the source argument list to the destination argument list.The first argument is a pointer to a va_list element to initialize. -The second argument is a pointer to a va_list element to copy from.
- + The second argument is a pointer to a va_list element to copy + from.The 'llvm.va_copy' intrinsic works just like the va_copy -macro available in C. In a target-dependent way, it copies the source -va_list element into the destination va_list element. This -intrinsic is necessary because the -llvm.va_start intrinsic may be arbitrarily complex and require, for -example, memory allocation.
+ macro available in C. In a target-dependent way, it copies the + source va_list element into the destination va_list + element. This intrinsic is necessary because + the llvm.va_start intrinsic may be + arbitrarily complex and require, for example, memory allocation.
-LLVM support for Accurate Garbage
+ LLVM support for Accurate Garbage
Collection (GC) requires the implementation and generation of these
-intrinsics.
-These intrinsics allow identification of GC roots on the
-stack, as well as garbage collector implementations that require read and write barriers.
-Front-ends for type-safe garbage collected languages should generate these
-intrinsics to make use of the LLVM garbage collectors. For more details, see Accurate Garbage Collection with LLVM.
-
The garbage collection intrinsics only operate on objects in the generic - address space (address space zero).
+The garbage collection intrinsics only operate on objects in the generic + address space (address space zero).
declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata)
The 'llvm.gcroot' intrinsic declares the existence of a GC root to -the code generator, and allows some metadata to be associated with it.
+ the code generator, and allows some metadata to be associated with it.The first argument specifies the address of a stack object that contains the -root pointer. The second pointer (which must be either a constant or a global -value address) contains the meta-data to be associated with the root.
+ root pointer. The second pointer (which must be either a constant or a + global value address) contains the meta-data to be associated with the + root.At runtime, a call to this intrinsic stores a null pointer into the "ptrloc" -location. At compile-time, the code generator generates information to allow -the runtime to find the pointer at GC safe points. The 'llvm.gcroot' -intrinsic may only be used in a function which specifies a GC -algorithm.
+ location. At compile-time, the code generator generates information to allow + the runtime to find the pointer at GC safe points. The 'llvm.gcroot' + intrinsic may only be used in a function which specifies a GC + algorithm.declare i8* @llvm.gcread(i8* %ObjPtr, i8** %Ptr)
The 'llvm.gcread' intrinsic identifies reads of references from heap -locations, allowing garbage collector implementations that require read -barriers.
+ locations, allowing garbage collector implementations that require read + barriers.The second argument is the address to read from, which should be an address -allocated from the garbage collector. The first object is a pointer to the -start of the referenced object, if needed by the language runtime (otherwise -null).
+ allocated from the garbage collector. The first object is a pointer to the + start of the referenced object, if needed by the language runtime (otherwise + null).The 'llvm.gcread' intrinsic has the same semantics as a load -instruction, but may be replaced with substantially more complex code by the -garbage collector runtime, as needed. The 'llvm.gcread' intrinsic -may only be used in a function which specifies a GC -algorithm.
+ instruction, but may be replaced with substantially more complex code by the + garbage collector runtime, as needed. The 'llvm.gcread' intrinsic + may only be used in a function which specifies a GC + algorithm.declare void @llvm.gcwrite(i8* %P1, i8* %Obj, i8** %P2)
The 'llvm.gcwrite' intrinsic identifies writes of references to heap -locations, allowing garbage collector implementations that require write -barriers (such as generational or reference counting collectors).
+ locations, allowing garbage collector implementations that require write + barriers (such as generational or reference counting collectors).The first argument is the reference to store, the second is the start of the -object to store it to, and the third is the address of the field of Obj to -store to. If the runtime does not require a pointer to the object, Obj may be -null.
+ object to store it to, and the third is the address of the field of Obj to + store to. If the runtime does not require a pointer to the object, Obj may + be null.The 'llvm.gcwrite' intrinsic has the same semantics as a store -instruction, but may be replaced with substantially more complex code by the -garbage collector runtime, as needed. The 'llvm.gcwrite' intrinsic -may only be used in a function which specifies a GC -algorithm.
+ instruction, but may be replaced with substantially more complex code by the + garbage collector runtime, as needed. The 'llvm.gcwrite' intrinsic + may only be used in a function which specifies a GC + algorithm.-These intrinsics are provided by LLVM to expose special features that may only -be implemented with code generator support. -
+ +These intrinsics are provided by LLVM to expose special features that may + only be implemented with code generator support.
-The 'llvm.returnaddress' intrinsic attempts to compute a -target-specific value indicating the return address of the current function -or one of its callers. -
+The 'llvm.returnaddress' intrinsic attempts to compute a + target-specific value indicating the return address of the current function + or one of its callers.
-The argument to this intrinsic indicates which function to return the address -for. Zero indicates the calling function, one indicates its caller, etc. The -argument is required to be a constant integer value. -
+The argument to this intrinsic indicates which function to return the address + for. Zero indicates the calling function, one indicates its caller, etc. + The argument is required to be a constant integer value.
The 'llvm.returnaddress' intrinsic either returns a pointer + indicating the return address of the specified call frame, or zero if it + cannot be identified. The value returned by this intrinsic is likely to be + incorrect or 0 for arguments other than zero, so it should only be used for + debugging purposes.
--The 'llvm.returnaddress' intrinsic either returns a pointer indicating -the return address of the specified call frame, or zero if it cannot be -identified. The value returned by this intrinsic is likely to be incorrect or 0 -for arguments other than zero, so it should only be used for debugging purposes. -
+Note that calling this intrinsic does not prevent function inlining or other + aggressive transformations, so the value returned may not be that of the + obvious source-language caller.
--Note that calling this intrinsic does not prevent function inlining or other -aggressive transformations, so the value returned may not be that of the obvious -source-language caller. -
-The 'llvm.frameaddress' intrinsic attempts to return the -target-specific frame pointer value for the specified stack frame. -
+The 'llvm.frameaddress' intrinsic attempts to return the + target-specific frame pointer value for the specified stack frame.
-The argument to this intrinsic indicates which function to return the frame -pointer for. Zero indicates the calling function, one indicates its caller, -etc. The argument is required to be a constant integer value. -
+The argument to this intrinsic indicates which function to return the frame + pointer for. Zero indicates the calling function, one indicates its caller, + etc. The argument is required to be a constant integer value.
The 'llvm.frameaddress' intrinsic either returns a pointer + indicating the frame address of the specified call frame, or zero if it + cannot be identified. The value returned by this intrinsic is likely to be + incorrect or 0 for arguments other than zero, so it should only be used for + debugging purposes.
--The 'llvm.frameaddress' intrinsic either returns a pointer indicating -the frame address of the specified call frame, or zero if it cannot be -identified. The value returned by this intrinsic is likely to be incorrect or 0 -for arguments other than zero, so it should only be used for debugging purposes. -
+Note that calling this intrinsic does not prevent function inlining or other + aggressive transformations, so the value returned may not be that of the + obvious source-language caller.
--Note that calling this intrinsic does not prevent function inlining or other -aggressive transformations, so the value returned may not be that of the obvious -source-language caller. -
-The 'llvm.stacksave' intrinsic is used to remember the current state of -the function stack, for use with -llvm.stackrestore. This is useful for implementing language -features like scoped automatic variable sized arrays in C99. -
+The 'llvm.stacksave' intrinsic is used to remember the current state + of the function stack, for use + with llvm.stackrestore. This is + useful for implementing language features like scoped automatic variable + sized arrays in C99.
-This intrinsic returns a opaque pointer value that can be passed to llvm.stackrestore. When an -llvm.stackrestore intrinsic is executed with a value saved from -llvm.stacksave, it effectively restores the state of the stack to the -state it was in when the llvm.stacksave intrinsic executed. In -practice, this pops any alloca blocks from the stack -that were allocated after the llvm.stacksave was executed. -
+This intrinsic returns a opaque pointer value that can be passed + to llvm.stackrestore. When + an llvm.stackrestore intrinsic is executed with a value saved + from llvm.stacksave, it effectively restores the state of the stack + to the state it was in when the llvm.stacksave intrinsic executed. + In practice, this pops any alloca blocks from the + stack that were allocated after the llvm.stacksave was executed.
-The 'llvm.stackrestore' intrinsic is used to restore the state of -the function stack to the state it was in when the corresponding llvm.stacksave intrinsic executed. This is -useful for implementing language features like scoped automatic variable sized -arrays in C99. -
+The 'llvm.stackrestore' intrinsic is used to restore the state of + the function stack to the state it was in when the + corresponding llvm.stacksave intrinsic + executed. This is useful for implementing language features like scoped + automatic variable sized arrays in C99.
-See the description for llvm.stacksave. -
+See the description + for llvm.stacksave.
-The 'llvm.prefetch' intrinsic is a hint to the code generator to insert -a prefetch instruction if supported; otherwise, it is a noop. Prefetches have -no -effect on the behavior of the program but can change its performance -characteristics. -
+The 'llvm.prefetch' intrinsic is a hint to the code generator to + insert a prefetch instruction if supported; otherwise, it is a noop. + Prefetches have no effect on the behavior of the program but can change its + performance characteristics.
-address is the address to be prefetched, rw is the specifier -determining if the fetch should be for a read (0) or write (1), and -locality is a temporal locality specifier ranging from (0) - no -locality, to (3) - extremely local keep in cache. The rw and -locality arguments must be constant integers. -
+address is the address to be prefetched, rw is the + specifier determining if the fetch should be for a read (0) or write (1), + and locality is a temporal locality specifier ranging from (0) - no + locality, to (3) - extremely local keep in cache. The rw + and locality arguments must be constant integers.
-This intrinsic does not modify the behavior of the program. In particular, -prefetches cannot trap and do not produce a value. On targets that support this -intrinsic, the prefetch can provide hints to the processor cache for better -performance. -
+This intrinsic does not modify the behavior of the program. In particular, + prefetches cannot trap and do not produce a value. On targets that support + this intrinsic, the prefetch can provide hints to the processor cache for + better performance.
-The 'llvm.pcmarker' intrinsic is a method to export a Program Counter -(PC) in a region of -code to simulators and other tools. The method is target specific, but it is -expected that the marker will use exported symbols to transmit the PC of the -marker. -The marker makes no guarantees that it will remain with any specific instruction -after optimizations. It is possible that the presence of a marker will inhibit -optimizations. The intended use is to be inserted after optimizations to allow -correlations of simulation runs. -
+The 'llvm.pcmarker' intrinsic is a method to export a Program + Counter (PC) in a region of code to simulators and other tools. The method + is target specific, but it is expected that the marker will use exported + symbols to transmit the PC of the marker. The marker makes no guarantees + that it will remain with any specific instruction after optimizations. It is + possible that the presence of a marker will inhibit optimizations. The + intended use is to be inserted after optimizations to allow correlations of + simulation runs.
-id is a numerical id identifying the marker. -
+id is a numerical id identifying the marker.
-This intrinsic does not modify the behavior of the program. Backends that do not -support this intrinisic may ignore it. -
+This intrinsic does not modify the behavior of the program. Backends that do + not support this intrinisic may ignore it.
@@ -5027,23 +5782,17 @@ support this intrinisic may ignore it.-The 'llvm.readcyclecounter' intrinsic provides access to the cycle -counter register (or similar low latency, high accuracy clocks) on those targets -that support it. On X86, it should map to RDTSC. On Alpha, it should map to RPCC. -As the backing counters overflow quickly (on the order of 9 seconds on alpha), this -should only be used for small timings. -
+The 'llvm.readcyclecounter' intrinsic provides access to the cycle + counter register (or similar low latency, high accuracy clocks) on those + targets that support it. On X86, it should map to RDTSC. On Alpha, it + should map to RPCC. As the backing counters overflow quickly (on the order + of 9 seconds on alpha), this should only be used for small timings.
-When directly supported, reading the cycle counter should not modify any memory. -Implementations are allowed to either return a application specific value or a -system wide value. On backends without support, this is lowered to a constant 0. -
+When directly supported, reading the cycle counter should not modify any + memory. Implementations are allowed to either return a application specific + value or a system wide value. On backends without support, this is lowered + to a constant 0.
@@ -5053,12 +5802,11 @@ system wide value. On backends without support, this is lowered to a constant 0-LLVM provides intrinsics for a few important standard C library functions. -These intrinsics allow source-language front-ends to pass information about the -alignment of the pointer arguments to the code generator, providing opportunity -for more efficient code generation. -
+ +LLVM provides intrinsics for a few important standard C library functions. + These intrinsics allow source-language front-ends to pass information about + the alignment of the pointer arguments to the code generator, providing + opportunity for more efficient code generation.
This is an overloaded intrinsic. You can use llvm.memcpy on any + integer bit width. 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>,
@@ -5078,44 +5833,31 @@ for more efficient code generation.
The 'llvm.memcpy.*' intrinsics copy a block of memory from the + source location to the destination location.
--The 'llvm.memcpy.*' intrinsics copy a block of memory from the 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. -
+Note that, unlike the standard libc function, the llvm.memcpy.* + intrinsics do not return a value, and takes an extra alignment argument.
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.
--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. -
- --If the call to this intrinisic 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 call to this intrinisic 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.
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 + be aligned to some boundary, this can be specified as the fourth argument, + otherwise it should be set to 0 or 1.
--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 be aligned to -some boundary, this can be specified as the fourth argument, otherwise it should -be set to 0 or 1. -
This is an overloaded intrinsic. You can use llvm.memmove on any integer bit + width. 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>,
@@ -5132,45 +5881,33 @@ be set to 0 or 1.
The 'llvm.memmove.*' intrinsics move a block of memory from the + source location to the destination location. It is similar to the + 'llvm.memcpy' intrinsic but allows the two memory locations to + overlap.
--The 'llvm.memmove.*' intrinsics move a block of memory from the source -location to the destination location. It is similar to the -'llvm.memcpy' intrinsic but allows the two memory locations to overlap. -
- --Note that, unlike the standard libc function, the llvm.memmove.* -intrinsics do not return a value, and takes an extra alignment argument. -
+Note that, unlike the standard libc function, the llvm.memmove.* + intrinsics do not return a value, and takes an extra alignment argument.
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.
--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. -
- --If the call to this intrinisic 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 call to this intrinisic 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.
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 + boundary, this can be specified as the fourth argument, otherwise it should + be set to 0 or 1.
--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 boundary, this can be specified as the fourth argument, otherwise it should -be set to 0 or 1. -
This is an overloaded intrinsic. You can use llvm.memset on any integer bit + width. 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>,
@@ -5187,43 +5931,30 @@ be set to 0 or 1.
The 'llvm.memset.*' intrinsics fill a block of memory with a + particular byte value.
--The 'llvm.memset.*' intrinsics fill a block of memory with a 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. -
+Note that, unlike the standard libc function, the llvm.memset + intrinsic does not return a value, and takes an extra alignment argument.
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 + specifying the number of bytes to fill, and the fourth argument is the known + alignment of destination location.
--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 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, then -the caller guarantees that the destination pointer is aligned to that boundary. -
+If the call to this intrinisic has an alignment value that is not 0 or 1, + then the caller guarantees that the destination pointer is aligned to that + boundary.
The 'llvm.memset.*' intrinsics fill "len" bytes of memory starting + at the destination location. If the argument is known to be aligned to some + boundary, this can be specified as the fourth argument, otherwise it should + be set to 0 or 1.
--The 'llvm.memset.*' intrinsics fill "len" bytes of memory starting at -the -destination location. If the argument is known to be aligned to some boundary, -this can be specified as the fourth argument, otherwise it should be set to 0 or -1. -
This is an overloaded intrinsic. You can use llvm.sqrt on any -floating point or vector of floating point type. Not all targets support all -types however.
+This is an overloaded intrinsic. You can use llvm.sqrt on any + floating point or vector of floating point type. Not all targets support all + types however.
+declare float @llvm.sqrt.f32(float %Val) declare double @llvm.sqrt.f64(double %Val) @@ -5244,28 +5976,21 @@ 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 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. -
+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 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.
-The argument and return value are floating point numbers of the same type. -
+The argument and return value are floating point numbers of the same + type.
This function returns the sqrt of the specified operand if it is a + nonnegative floating point number.
--This function returns the sqrt of the specified operand if it is a nonnegative -floating point number. -
This is an overloaded intrinsic. You can use llvm.powi on any -floating point or vector of floating point type. Not all targets support all -types however.
+This is an overloaded intrinsic. You can use llvm.powi on any + floating point or vector of floating point type. Not all targets support all + types however.
+declare float @llvm.powi.f32(float %Val, i32 %power) declare double @llvm.powi.f64(double %Val, i32 %power) @@ -5288,26 +6014,19 @@ types however.
-The 'llvm.powi.*' intrinsics return the first operand raised to the -specified (positive or negative) power. The order of evaluation of -multiplications is not defined. When a vector of floating point type is -used, the second argument remains a scalar integer value. -
+The 'llvm.powi.*' intrinsics return the first operand raised to the + specified (positive or negative) power. The order of evaluation of + multiplications is not defined. When a vector of floating point type is + used, the second argument remains a scalar integer value.
-The second argument is an integer power, and the first is a value to raise to -that power. -
+The second argument is an integer power, and the first is a value to raise to + that power.
This function returns the first value raised to the second power with an + unspecified sequence of rounding operations.
--This function returns the first value raised to the second power with an -unspecified sequence of rounding operations.
This is an overloaded intrinsic. You can use llvm.sin on any -floating point or vector of floating point type. Not all targets support all -types however.
+This is an overloaded intrinsic. You can use llvm.sin on any + floating point or vector of floating point type. Not all targets support all + types however.
+declare float @llvm.sin.f32(float %Val) declare double @llvm.sin.f64(double %Val) @@ -5330,23 +6050,17 @@ types however.
-The 'llvm.sin.*' intrinsics return the sine of the operand. -
+The 'llvm.sin.*' intrinsics return the sine of the operand.
-The argument and return value are floating point numbers of the same type. -
+The argument and return value are floating point numbers of the same + type.
This function returns the sine of the specified operand, returning the same + values as the libm sin functions would, and handles error conditions + in the same way.
--This function returns the sine of the specified operand, returning the -same values as the libm sin functions would, and handles error -conditions in the same way.
This is an overloaded intrinsic. You can use llvm.cos on any -floating point or vector of floating point type. Not all targets support all -types however.
+This is an overloaded intrinsic. You can use llvm.cos on any + floating point or vector of floating point type. Not all targets support all + types however.
+declare float @llvm.cos.f32(float %Val) declare double @llvm.cos.f64(double %Val) @@ -5369,23 +6084,17 @@ types however.
-The 'llvm.cos.*' intrinsics return the cosine of the operand. -
+The 'llvm.cos.*' intrinsics return the cosine of the operand.
-The argument and return value are floating point numbers of the same type. -
+The argument and return value are floating point numbers of the same + type.
This function returns the cosine of the specified operand, returning the same + values as the libm cos functions would, and handles error conditions + in the same way.
--This function returns the cosine of the specified operand, returning the -same values as the libm cos functions would, and handles error -conditions in the same way.
This is an overloaded intrinsic. You can use llvm.pow on any -floating point or vector of floating point type. Not all targets support all -types however.
+This is an overloaded intrinsic. You can use llvm.pow on any + floating point or vector of floating point type. Not all targets support all + types however.
+declare float @llvm.pow.f32(float %Val, float %Power) declare double @llvm.pow.f64(double %Val, double %Power) @@ -5408,39 +6118,29 @@ types however.
-The 'llvm.pow.*' intrinsics return the first operand raised to the -specified (positive or negative) power. -
+The 'llvm.pow.*' intrinsics return the first operand raised to the + specified (positive or negative) power.
-The second argument is a floating point power, and the first is a value to -raise to that power. -
+The second argument is a floating point power, and the first is a value to + raise to that power.
This function returns the first value raised to the second power, returning + the same values as the libm pow functions would, and handles error + conditions in the same way.
--This function returns the first value raised to the second power, -returning the -same values as the libm pow functions would, and handles error -conditions in the same way.
-LLVM provides intrinsics for a few important bit manipulation operations. -These allow efficient code generation for some algorithms. -
+ +LLVM provides intrinsics for a few important bit manipulation operations. + These allow efficient code generation for some algorithms.
This is an overloaded intrinsic function. You can use bswap on any integer -type that is an even number of bytes (i.e. BitWidth % 16 == 0).
+ type that is an even number of bytes (i.e. BitWidth % 16 == 0). +declare i16 @llvm.bswap.i16(i16 <id>) declare i32 @llvm.bswap.i32(i32 <id>) @@ -5461,25 +6162,20 @@ type that is an even number of bytes (i.e. BitWidth % 16 == 0).
-The 'llvm.bswap' family of intrinsics is used to byte swap integer -values with an even number of bytes (positive multiple of 16 bits). These are -useful for performing operations on data that is not in the target's native -byte order. -
+The 'llvm.bswap' family of intrinsics is used to byte swap integer + values with an even number of bytes (positive multiple of 16 bits). These + are useful for performing operations on data that is not in the target's + native byte order.
-The llvm.bswap.i16 intrinsic returns an i16 value that has the high -and low byte of the input i16 swapped. Similarly, the llvm.bswap.i32 -intrinsic returns an i32 value that has the four bytes of the input i32 -swapped, so that if the input bytes are numbered 0, 1, 2, 3 then the returned -i32 will have its bytes in 3, 2, 1, 0 order. The llvm.bswap.i48, -llvm.bswap.i64 and other intrinsics extend this concept to -additional even-byte lengths (6 bytes, 8 bytes and more, respectively). -
+The llvm.bswap.i16 intrinsic returns an i16 value that has the high + and low byte of the input i16 swapped. Similarly, + the llvm.bswap.i32 intrinsic returns an i32 value that has the four + bytes of the input i32 swapped, so that if the input bytes are numbered 0, 1, + 2, 3 then the returned i32 will have its bytes in 3, 2, 1, 0 order. + The llvm.bswap.i48, llvm.bswap.i64 and other intrinsics + extend this concept to additional even-byte lengths (6 bytes, 8 bytes and + more, respectively).
This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit -width. Not all targets support all bit widths however.
+ width. Not all targets support all bit widths however. +- declare i8 @llvm.ctpop.i8 (i8 <src>) + declare i8 @llvm.ctpop.i8(i8 <src>) declare i16 @llvm.ctpop.i16(i16 <src>) declare i32 @llvm.ctpop.i32(i32 <src>) declare i64 @llvm.ctpop.i64(i64 <src>) @@ -5502,24 +6199,16 @@ width. Not all targets support all bit widths however.
-The 'llvm.ctpop' family of intrinsics counts the number of bits set in a -value. -
+The 'llvm.ctpop' family of intrinsics counts the number of bits set + in a value.
-The only argument is the value to be counted. The argument may be of any -integer type. The return type must match the argument type. -
+The only argument is the value to be counted. The argument may be of any + integer type. The return type must match the argument type.
The 'llvm.ctpop' intrinsic counts the 1's in a variable.
--The 'llvm.ctpop' intrinsic counts the 1's in a variable. -
This is an overloaded intrinsic. You can use llvm.ctlz on any -integer bit width. Not all targets support all bit widths however.
+This is an overloaded intrinsic. You can use llvm.ctlz on any + integer bit width. Not all targets support all bit widths however.
+declare i8 @llvm.ctlz.i8 (i8 <src>) declare i16 @llvm.ctlz.i16(i16 <src>) @@ -5541,30 +6231,20 @@ integer bit width. Not all targets support all bit widths however.
-The 'llvm.ctlz' family of intrinsic functions counts the number of -leading zeros in a variable. -
+The 'llvm.ctlz' family of intrinsic functions counts the number of + leading zeros in a variable.
-The only argument is the value to be counted. The argument may be of any -integer type. The return type must match the argument type. -
+The only argument is the value to be counted. The argument may be of any + integer type. The return type must match the argument type.
The 'llvm.ctlz' intrinsic counts the leading (most significant) + zeros in a variable. If the src == 0 then the result is the size in bits of + the type of src. For example, llvm.ctlz(i32 2) = 30.
--The 'llvm.ctlz' intrinsic counts the leading (most significant) zeros -in a variable. If the src == 0 then the result is the size in bits of the type -of src. For example, llvm.ctlz(i32 2) = 30. -
This is an overloaded intrinsic. You can use llvm.cttz on any -integer bit width. Not all targets support all bit widths however.
+This is an overloaded intrinsic. You can use llvm.cttz on any + integer bit width. Not all targets support all bit widths however.
+declare i8 @llvm.cttz.i8 (i8 <src>) declare i16 @llvm.cttz.i16(i16 <src>) @@ -5584,125 +6265,305 @@ integer bit width. Not all targets support all bit widths however.
The 'llvm.cttz' family of intrinsic functions counts the number of + trailing zeros.
--The 'llvm.cttz' family of intrinsic functions counts the number of -trailing zeros. -
+The only argument is the value to be counted. The argument may be of any + integer type. The return type must match the argument type.
+ +The 'llvm.cttz' intrinsic counts the trailing (least significant) + zeros in a variable. If the src == 0 then the result is the size in bits of + the type of src. For example, llvm.cttz(2) = 1.
+ +LLVM provides intrinsics for some arithmetic with overflow operations.
+ +This is an overloaded intrinsic. You can use llvm.sadd.with.overflow + on any integer bit width.
+ +
+ declare {i16, i1} @llvm.sadd.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.sadd.with.overflow.i64(i64 %a, i64 %b)
+
+
+The 'llvm.sadd.with.overflow' family of intrinsic functions perform + a signed addition of the two arguments, and indicate whether an overflow + occurred during the signed summation.
The arguments (%a and %b) and the first element of the result structure may + be of integer types of any bit width, but they must have the same bit + width. The second element of the result structure must be of + type i1. %a and %b are the two values that will + undergo signed addition.
--The only argument is the value to be counted. The argument may be of any -integer type. The return type must match the argument type. -
+The 'llvm.sadd.with.overflow' family of intrinsic functions perform + a signed addition of the two variables. They return a structure — the + first element of which is the signed summation, and the second element of + which is a bit specifying if the signed summation resulted in an + overflow.
+ +
+ %res = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %overflow, label %normal
+
+
+This is an overloaded intrinsic. You can use llvm.uadd.with.overflow + on any integer bit width.
+ +
+ declare {i16, i1} @llvm.uadd.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.uadd.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.uadd.with.overflow.i64(i64 %a, i64 %b)
+
+
+The 'llvm.uadd.with.overflow' family of intrinsic functions perform + an unsigned addition of the two arguments, and indicate whether a carry + occurred during the unsigned summation.
+ +The arguments (%a and %b) and the first element of the result structure may + be of integer types of any bit width, but they must have the same bit + width. The second element of the result structure must be of + type i1. %a and %b are the two values that will + undergo unsigned addition.
+ +The 'llvm.uadd.with.overflow' family of intrinsic functions perform + an unsigned addition of the two arguments. They return a structure — + the first element of which is the sum, and the second element of which is a + bit specifying if the unsigned summation resulted in a carry.
+ +
+ %res = call {i32, i1} @llvm.uadd.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %carry, label %normal
+
+
+This is an overloaded intrinsic. You can use llvm.ssub.with.overflow + on any integer bit width.
+ +
+ declare {i16, i1} @llvm.ssub.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.ssub.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.ssub.with.overflow.i64(i64 %a, i64 %b)
+
+
+The 'llvm.ssub.with.overflow' family of intrinsic functions perform + a signed subtraction of the two arguments, and indicate whether an overflow + occurred during the signed subtraction.
+ +The arguments (%a and %b) and the first element of the result structure may + be of integer types of any bit width, but they must have the same bit + width. The second element of the result structure must be of + type i1. %a and %b are the two values that will + undergo signed subtraction.
+ +The 'llvm.ssub.with.overflow' family of intrinsic functions perform + a signed subtraction of the two arguments. They return a structure — + the first element of which is the subtraction, and the second element of + which is a bit specifying if the signed subtraction resulted in an + overflow.
+ +
+ %res = call {i32, i1} @llvm.ssub.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %overflow, label %normal
+
+
+This is an overloaded intrinsic. You can use llvm.usub.with.overflow + on any integer bit width.
+ +
+ declare {i16, i1} @llvm.usub.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.usub.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.usub.with.overflow.i64(i64 %a, i64 %b)
+
+
+The 'llvm.usub.with.overflow' family of intrinsic functions perform + an unsigned subtraction of the two arguments, and indicate whether an + overflow occurred during the unsigned subtraction.
+ +The arguments (%a and %b) and the first element of the result structure may + be of integer types of any bit width, but they must have the same bit + width. The second element of the result structure must be of + type i1. %a and %b are the two values that will + undergo unsigned subtraction.
The 'llvm.usub.with.overflow' family of intrinsic functions perform + an unsigned subtraction of the two arguments. They return a structure — + the first element of which is the subtraction, and the second element of + which is a bit specifying if the unsigned subtraction resulted in an + overflow.
+ +
+ %res = call {i32, i1} @llvm.usub.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %overflow, label %normal
+
--The 'llvm.cttz' intrinsic counts the trailing (least significant) zeros -in a variable. If the src == 0 then the result is the size in bits of the type -of src. For example, llvm.cttz(2) = 1. -
This is an overloaded intrinsic. You can use llvm.part.select -on any integer bit width.
+This is an overloaded intrinsic. You can use llvm.smul.with.overflow + on any integer bit width.
+
- declare i17 @llvm.part.select.i17 (i17 %val, i32 %loBit, i32 %hiBit)
- declare i29 @llvm.part.select.i29 (i29 %val, i32 %loBit, i32 %hiBit)
+ declare {i16, i1} @llvm.smul.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.smul.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.smul.with.overflow.i64(i64 %a, i64 %b)
The 'llvm.part.select' family of intrinsic functions selects a -range of bits from an integer value and returns them in the same bit width as -the original value.
+ +The 'llvm.smul.with.overflow' family of intrinsic functions perform + a signed multiplication of the two arguments, and indicate whether an + overflow occurred during the signed multiplication.
The first argument, %val and the result may be integer types of -any bit width but they must have the same bit width. The second and third -arguments must be i32 type since they specify only a bit index.
+The arguments (%a and %b) and the first element of the result structure may + be of integer types of any bit width, but they must have the same bit + width. The second element of the result structure must be of + type i1. %a and %b are the two values that will + undergo signed multiplication.
The operation of the 'llvm.part.select' intrinsic has two modes -of operation: forwards and reverse. If %loBit is greater than -%hiBits then the intrinsic operates in reverse mode. Otherwise it -operates in forward mode.
-In forward mode, this intrinsic is the equivalent of shifting %val -right by %loBit bits and then ANDing it with a mask with -only the %hiBit - %loBit bits set, as follows:
-In reverse mode, a similar computation is made except that the bits are -returned in the reverse order. So, for example, if X has the value -i16 0x0ACF (101011001111) and we apply -part.select(i16 X, 8, 3) to it, we get back the value -i16 0x0026 (000000100110).
+The 'llvm.smul.with.overflow' family of intrinsic functions perform + a signed multiplication of the two arguments. They return a structure — + the first element of which is the multiplication, and the second element of + which is a bit specifying if the signed multiplication resulted in an + overflow.
+ +
+ %res = call {i32, i1} @llvm.smul.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %overflow, label %normal
+
+
This is an overloaded intrinsic. You can use llvm.part.set -on any integer bit width.
+This is an overloaded intrinsic. You can use llvm.umul.with.overflow + on any integer bit width.
+
- declare i17 @llvm.part.set.i17.i9 (i17 %val, i9 %repl, i32 %lo, i32 %hi)
- declare i29 @llvm.part.set.i29.i9 (i29 %val, i9 %repl, i32 %lo, i32 %hi)
+ declare {i16, i1} @llvm.umul.with.overflow.i16(i16 %a, i16 %b)
+ declare {i32, i1} @llvm.umul.with.overflow.i32(i32 %a, i32 %b)
+ declare {i64, i1} @llvm.umul.with.overflow.i64(i64 %a, i64 %b)
The 'llvm.part.set' family of intrinsic functions replaces a range -of bits in an integer value with another integer value. It returns the integer -with the replaced bits.
+The 'llvm.umul.with.overflow' family of intrinsic functions perform + a unsigned multiplication of the two arguments, and indicate whether an + overflow occurred during the unsigned multiplication.
The first argument, %val and the result may be integer types of -any bit width but they must have the same bit width. %val is the value -whose bits will be replaced. The second argument, %repl may be an -integer of any bit width. The third and fourth arguments must be i32 -type since they specify only a bit index.
+The arguments (%a and %b) and the first element of the result structure may + be of integer types of any bit width, but they must have the same bit + width. The second element of the result structure must be of + type i1. %a and %b are the two values that will + undergo unsigned multiplication.
The operation of the 'llvm.part.set' intrinsic has two modes -of operation: forwards and reverse. If %lo is greater than -%hi then the intrinsic operates in reverse mode. Otherwise it -operates in forward mode.
-For both modes, the %repl value is prepared for use by either -truncating it down to the size of the replacement area or zero extending it -up to that size.
-In forward mode, the bits between %lo and %hi (inclusive) -are replaced with corresponding bits from %repl. That is the 0th bit -in %repl replaces the %loth bit in %val and etc. up -to the %hith bit.
-In reverse mode, a similar computation is made except that the bits are -reversed. That is, the 0th bit in %repl replaces the -%hi bit in %val and etc. down to the %loth bit.
+The 'llvm.umul.with.overflow' family of intrinsic functions perform + an unsigned multiplication of the two arguments. They return a structure + — the first element of which is the multiplication, and the second + element of which is a bit specifying if the unsigned multiplication resulted + in an overflow.
+
- llvm.part.set(0xFFFF, 0, 4, 7) -> 0xFF0F
- llvm.part.set(0xFFFF, 0, 7, 4) -> 0xFF0F
- llvm.part.set(0xFFFF, 1, 7, 4) -> 0xFF8F
- llvm.part.set(0xFFFF, F, 8, 3) -> 0xFFE7
- llvm.part.set(0xFFFF, 0, 3, 8) -> 0xFE07
+ %res = call {i32, i1} @llvm.umul.with.overflow.i32(i32 %a, i32 %b)
+ %sum = extractvalue {i32, i1} %res, 0
+ %obit = extractvalue {i32, i1} %res, 1
+ br i1 %obit, label %overflow, label %normal
+
-The LLVM debugger intrinsics (which all start with llvm.dbg. prefix), -are described in the LLVM Source Level -Debugging document. -
-The LLVM debugger intrinsics (which all start with llvm.dbg. + prefix), are described in + the LLVM Source + Level Debugging document.
+ +The LLVM exception handling intrinsics (which all start with -llvm.eh. prefix), are described in the LLVM Exception -Handling document.
+ +The LLVM exception handling intrinsics (which all start with + llvm.eh. prefix), are described in + the LLVM Exception + Handling document.
+- This intrinsic makes it possible to excise one parameter, marked with - the nest attribute, from a function. The result is a callable - function pointer lacking the nest parameter - the caller does not need - to 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 contains code to splice the nest value into the - argument list. This is used to implement the GCC nested function address - extension. -
-- For example, if the function is - i32 f(i8* nest %c, i32 %x, i32 %y) then the resulting function - pointer has signature i32 (i32, i32)*. It can be created as follows:
+ +This intrinsic makes it possible to excise one parameter, marked with + the nest attribute, from a function. The result is a callable + function pointer lacking the nest parameter - the caller does not need to + 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 + contains code to splice the nest value into the argument list. This is used + to implement the GCC nested function address extension.
+ +For example, if the function is + i32 f(i8* nest %c, i32 %x, i32 %y) then the resulting function + 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 ) %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 ).
+-declare i8* @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <nval>) + declare i8* @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <nval>)+
- This fills the memory pointed to by tramp with code - and returns a function pointer suitable for executing it. -
+This fills the memory pointed to by tramp with code and returns a + function pointer suitable for executing it.
+- The llvm.init.trampoline intrinsic takes three arguments, all - pointers. The tramp argument must point to a sufficiently large - and sufficiently aligned block of memory; this memory is written to by the - intrinsic. Note that the size and the alignment are target-specific - LLVM - currently provides no portable way of determining them, so a front-end that - generates this intrinsic needs to have some target-specific knowledge. - The func argument must hold a function bitcast to an i8*. -
+The llvm.init.trampoline intrinsic takes three arguments, all + pointers. The tramp argument must point to a sufficiently large and + sufficiently aligned block of memory; this memory is written to by the + intrinsic. Note that the size and the alignment are target-specific - LLVM + currently provides no portable way of determining them, so a front-end that + generates this intrinsic needs to have some target-specific knowledge. + The func argument must hold a function bitcast to + an i8*.
+- The block of memory pointed to by tramp is filled with target - dependent code, turning it into a function. A pointer to this function is - returned, but needs to be bitcast to an - appropriate function pointer type - before being called. The new function's signature is the same as that of - func with any arguments marked with the nest attribute - removed. At most one such nest argument is allowed, and it must be - of pointer type. Calling the new function is equivalent to calling - func with the same argument list, but with nval used for the - missing nest argument. If, after calling - llvm.init.trampoline, the memory pointed to by tramp is - modified, then the effect of any later call to the returned function pointer is - undefined. -
+The block of memory pointed to by tramp is filled with target + dependent code, turning it into a function. A pointer to this function is + returned, but needs to be bitcast to an appropriate + function pointer type before being called. The new function's signature + is the same as that of func with any arguments marked with + the nest attribute removed. At most one such nest argument + is allowed, and it must be of pointer type. Calling the new function is + equivalent to calling func with the same argument list, but + with nval used for the missing nest argument. If, after + calling llvm.init.trampoline, the memory pointed to + by tramp is modified, then the effect of any later call to the + returned function pointer is undefined.
+- These intrinsic functions expand the "universal IR" of LLVM to represent - hardware constructs for atomic operations and memory synchronization. This - provides an interface to the hardware, not an interface to the programmer. It - is aimed at a low enough level to allow any programming models or APIs - (Application Programming Interfaces) which - need atomic behaviors to map cleanly onto it. It is also modeled primarily on - hardware behavior. Just as hardware provides a "universal IR" for source - languages, it also provides a starting point for developing a "universal" - atomic operation and synchronization IR. -
-- These do not form an API such as high-level threading libraries, - software transaction memory systems, atomic primitives, and intrinsic - functions as found in BSD, GNU libc, atomic_ops, APR, and other system and - application libraries. The hardware interface provided by LLVM should allow - a clean implementation of all of these APIs and parallel programming models. - No one model or paradigm should be selected above others unless the hardware - itself ubiquitously does so. -
+These intrinsic functions expand the "universal IR" of LLVM to represent + hardware constructs for atomic operations and memory synchronization. This + provides an interface to the hardware, not an interface to the programmer. It + is aimed at a low enough level to allow any programming models or APIs + (Application Programming Interfaces) which need atomic behaviors to map + cleanly onto it. It is also modeled primarily on hardware behavior. Just as + hardware provides a "universal IR" for source languages, it also provides a + starting point for developing a "universal" atomic operation and + synchronization IR.
+ +These do not form an API such as high-level threading libraries, + software transaction memory systems, atomic primitives, and intrinsic + functions as found in BSD, GNU libc, atomic_ops, APR, and other system and + application libraries. The hardware interface provided by LLVM should allow + a clean implementation of all of these APIs and parallel programming models. + No one model or paradigm should be selected above others unless the hardware + itself ubiquitously does so.
+-declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, -i1 <device> ) - + declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device> )+
- The llvm.memory.barrier intrinsic guarantees ordering between - specific pairs of memory access types. -
+The llvm.memory.barrier intrinsic guarantees ordering between + specific pairs of memory access types.
+- The llvm.memory.barrier intrinsic requires five boolean arguments. - The first four arguments enables a specific barrier as listed below. The fith - argument specifies that the barrier applies to io or device or uncached memory. +
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.
+ +- This intrinsic causes the system to enforce some ordering constraints upon - the loads and stores of the program. This barrier does not indicate - when any events will occur, it only enforces an order in - which they occur. For any of the specified pairs of load and store operations - (f.ex. load-load, or store-load), all of the first operations preceding the - barrier will complete before any of the second operations succeeding the - barrier begin. Specifically the semantics for each pairing is as follows: -
-- These semantics are applied with a logical "and" behavior when more than one - is enabled in a single memory barrier intrinsic. -
-- Backends may implement stronger barriers than those requested when they do not - support as fine grained a barrier as requested. Some architectures do not - need all types of barriers and on such architectures, these become noops. -
+This intrinsic causes the system to enforce some ordering constraints upon + the loads and stores of the program. This barrier does not + indicate when any events will occur, it only enforces + an order in which they occur. For any of the specified pairs of load + and store operations (f.ex. load-load, or store-load), all of the first + operations preceding the barrier will complete before any of the second + operations succeeding the barrier begin. Specifically the semantics for each + pairing is as follows:
+ +These semantics are applied with a logical "and" behavior when more than one + is enabled in a single memory barrier intrinsic.
+ +Backends may implement stronger barriers than those requested when they do + not support as fine grained a barrier as requested. Some architectures do + not need all types of barriers and on such architectures, these become + noops.
+
-%ptr = malloc i32
+%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
+%ptr = bitcast i8* %mallocP to i32*
store i32 4, %ptr
%result1 = load i32* %ptr ; yields {i32}:result1 = 4
@@ -5903,52 +6765,51 @@ i1 <device> )
; guarantee the above finishes
store i32 8, %ptr ; before this begins
+
- This is an overloaded intrinsic. You can use llvm.atomic.cmp.swap on - any integer bit width and for different address spaces. Not all targets - support all bit widths however.
+This is an overloaded intrinsic. You can use llvm.atomic.cmp.swap on + any integer bit width and for different address spaces. Not all targets + support all bit widths however.
-declare i8 @llvm.atomic.cmp.swap.i8.p0i8( i8* <ptr>, i8 <cmp>, i8 <val> ) -declare i16 @llvm.atomic.cmp.swap.i16.p0i16( i16* <ptr>, i16 <cmp>, i16 <val> ) -declare i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* <ptr>, i32 <cmp>, i32 <val> ) -declare i64 @llvm.atomic.cmp.swap.i64.p0i64( i64* <ptr>, i64 <cmp>, i64 <val> ) - + declare i8 @llvm.atomic.cmp.swap.i8.p0i8( i8* <ptr>, i8 <cmp>, i8 <val> ) + declare i16 @llvm.atomic.cmp.swap.i16.p0i16( i16* <ptr>, i16 <cmp>, i16 <val> ) + declare i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* <ptr>, i32 <cmp>, i32 <val> ) + declare i64 @llvm.atomic.cmp.swap.i64.p0i64( i64* <ptr>, i64 <cmp>, i64 <val> )+
- This loads a value in memory and compares it to a given value. If they are - equal, it stores a new value into the memory. -
+This loads a value in memory and compares it to a given value. If they are + equal, it stores a new value into the memory.
+- The llvm.atomic.cmp.swap intrinsic takes three arguments. The result as - well as both cmp and val must be integer values with the - same bit width. The ptr argument must be a pointer to a value of - this integer type. While any bit width integer may be used, targets may only - lower representations they support in hardware. +
The llvm.atomic.cmp.swap intrinsic takes three arguments. The result + as well as both cmp and val must be integer values with the + same bit width. The ptr argument must be a pointer to a value of + this integer type. While any bit width integer may be used, targets may only + lower representations they support in hardware.
-- This entire intrinsic must be executed atomically. It first loads the value - in memory pointed to by ptr and compares it with the value - cmp. If they are equal, val is stored into the memory. The - loaded value is yielded in all cases. This provides the equivalent of an - atomic compare-and-swap operation within the SSA framework. -
-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.
+
-%ptr = malloc i32
+%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
+%ptr = bitcast i8* %mallocP to i32*
store i32 4, %ptr
%val1 = add i32 4, 4
@@ -5964,6 +6825,7 @@ declare i64 @llvm.atomic.cmp.swap.i64.p0i64( i64* <ptr>, i64 <cmp>,
%memval2 = load i32* %ptr ; yields {i32}:memval2 = 8
+
- This is an overloaded intrinsic. You can use llvm.atomic.swap on any - integer bit width. Not all targets support all bit widths however.
--declare i8 @llvm.atomic.swap.i8.p0i8( i8* <ptr>, i8 <val> ) -declare i16 @llvm.atomic.swap.i16.p0i16( i16* <ptr>, i16 <val> ) -declare i32 @llvm.atomic.swap.i32.p0i32( i32* <ptr>, i32 <val> ) -declare i64 @llvm.atomic.swap.i64.p0i64( i64* <ptr>, i64 <val> ) +This is an overloaded intrinsic. You can use llvm.atomic.swap on any + integer bit width. Not all targets support all bit widths however.
++ declare i8 @llvm.atomic.swap.i8.p0i8( i8* <ptr>, i8 <val> ) + declare i16 @llvm.atomic.swap.i16.p0i16( i16* <ptr>, i16 <val> ) + declare i32 @llvm.atomic.swap.i32.p0i32( i32* <ptr>, i32 <val> ) + declare i64 @llvm.atomic.swap.i64.p0i64( i64* <ptr>, i64 <val> )+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. -
+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.swap intrinsic takes two arguments. Both + the val argument and the result must be integers of the same bit + width. The first argument, ptr, must be a pointer to a value of this + integer type. The targets may only lower integer representations they + support.
-- The llvm.atomic.swap intrinsic takes two arguments. Both the - val argument and the result must be integers of the same bit width. - The first argument, ptr, must be a pointer to a value of this - integer type. The targets may only lower integer representations they - support. -
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. +
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 +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* store i32 4, %ptr %val1 = add i32 4, 4 @@ -6023,6 +6881,7 @@ declare i64 @llvm.atomic.swap.i64.p0i64( i64* <ptr>, i64 <val> ) %stored2 = icmp eq i32 %result2, 8 ; yields {i1}:stored2 = true %memval2 = load i32* %ptr ; yields {i32}:memval2 = 2+
- This is an overloaded intrinsic. You can use llvm.atomic.load.add on any - integer bit width. Not all targets support all bit widths however.
--declare i8 @llvm.atomic.load.add.i8..p0i8( i8* <ptr>, i8 <delta> ) -declare i16 @llvm.atomic.load.add.i16..p0i16( i16* <ptr>, i16 <delta> ) -declare i32 @llvm.atomic.load.add.i32..p0i32( i32* <ptr>, i32 <delta> ) -declare i64 @llvm.atomic.load.add.i64..p0i64( i64* <ptr>, i64 <delta> ) +This is an overloaded intrinsic. You can use llvm.atomic.load.add on + any integer bit width. Not all targets support all bit widths however.
++ declare i8 @llvm.atomic.load.add.i8..p0i8( i8* <ptr>, i8 <delta> ) + declare i16 @llvm.atomic.load.add.i16..p0i16( i16* <ptr>, i16 <delta> ) + declare i32 @llvm.atomic.load.add.i32..p0i32( i32* <ptr>, i32 <delta> ) + declare i64 @llvm.atomic.load.add.i64..p0i64( i64* <ptr>, i64 <delta> )+Overview:
-- This intrinsic adds delta to the value stored in memory at - ptr. It yields the original value at ptr. -
+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.
- 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. -
+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 +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* + store i32 4, %ptr %result1 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 4 ) ; yields {i32}:result1 = 4 %result2 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 2 ) @@ -6074,6 +6931,7 @@ declare i64 @llvm.atomic.load.add.i64..p0i64( i64* <ptr>, i64 <delta> ; yields {i32}:result3 = 10 %memval1 = load i32* %ptr ; yields {i32}:memval1 = 15+
- This is an overloaded intrinsic. You can use llvm.atomic.load.sub on - any integer bit width and for different address spaces. Not all targets - support all bit widths however.
--declare i8 @llvm.atomic.load.sub.i8.p0i32( i8* <ptr>, i8 <delta> ) -declare i16 @llvm.atomic.load.sub.i16.p0i32( i16* <ptr>, i16 <delta> ) -declare i32 @llvm.atomic.load.sub.i32.p0i32( i32* <ptr>, i32 <delta> ) -declare i64 @llvm.atomic.load.sub.i64.p0i32( i64* <ptr>, i64 <delta> ) +This is an overloaded intrinsic. You can use llvm.atomic.load.sub on + any integer bit width and for different address spaces. Not all targets + support all bit widths however.
++ declare i8 @llvm.atomic.load.sub.i8.p0i32( i8* <ptr>, i8 <delta> ) + declare i16 @llvm.atomic.load.sub.i16.p0i32( i16* <ptr>, i16 <delta> ) + declare i32 @llvm.atomic.load.sub.i32.p0i32( i32* <ptr>, i32 <delta> ) + declare i64 @llvm.atomic.load.sub.i64.p0i32( i64* <ptr>, i64 <delta> )+Overview:
-- This intrinsic subtracts delta to the value stored in memory at - ptr. It yields the original value at ptr. -
+This intrinsic subtracts 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.
- 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 subtracts delta, stores the - result to ptr. It yields the original value stored at ptr. -
+This intrinsic does a series of operations atomically. It first loads the + value stored at ptr. It then subtracts delta, stores the + result to ptr. It yields the original value stored + at ptr.
Examples:
-%ptr = malloc i32 - store i32 8, %ptr +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* + store i32 8, %ptr %result1 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 4 ) ; yields {i32}:result1 = 8 %result2 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 2 ) @@ -6126,6 +6983,7 @@ declare i64 @llvm.atomic.load.sub.i64.p0i32( i64* <ptr>, i64 <delta> ; yields {i32}:result3 = 2 %memval1 = load i32* %ptr ; yields {i32}:memval1 = -3+
- These are overloaded intrinsics. You can use llvm.atomic.load_and, - llvm.atomic.load_nand, llvm.atomic.load_or, and - llvm.atomic.load_xor on any integer bit width and for different - address spaces. Not all targets support all bit widths however.
--declare i8 @llvm.atomic.load.and.i8.p0i8( i8* <ptr>, i8 <delta> ) -declare i16 @llvm.atomic.load.and.i16.p0i16( i16* <ptr>, i16 <delta> ) -declare i32 @llvm.atomic.load.and.i32.p0i32( i32* <ptr>, i32 <delta> ) -declare i64 @llvm.atomic.load.and.i64.p0i64( i64* <ptr>, i64 <delta> ) +These are overloaded intrinsics. You can + use llvm.atomic.load_and, llvm.atomic.load_nand, + llvm.atomic.load_or, and llvm.atomic.load_xor on any integer + bit width and for different address spaces. Not all targets support all bit + widths however.
++ declare i8 @llvm.atomic.load.and.i8.p0i8( i8* <ptr>, i8 <delta> ) + declare i16 @llvm.atomic.load.and.i16.p0i16( i16* <ptr>, i16 <delta> ) + declare i32 @llvm.atomic.load.and.i32.p0i32( i32* <ptr>, i32 <delta> ) + declare i64 @llvm.atomic.load.and.i64.p0i64( i64* <ptr>, i64 <delta> )-declare i8 @llvm.atomic.load.or.i8.p0i8( i8* <ptr>, i8 <delta> ) -declare i16 @llvm.atomic.load.or.i16.p0i16( i16* <ptr>, i16 <delta> ) -declare i32 @llvm.atomic.load.or.i32.p0i32( i32* <ptr>, i32 <delta> ) -declare i64 @llvm.atomic.load.or.i64.p0i64( i64* <ptr>, i64 <delta> ) - + declare i8 @llvm.atomic.load.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:
-- These intrinsics bitwise the operation (and, nand, or, xor) delta to - the value stored in memory at ptr. It yields the original value - at ptr. -
+These intrinsics bitwise the operation (and, nand, or, xor) delta to + the value stored in memory at ptr. It yields the original value + at ptr.
+Arguments:
-+
These intrinsics take two arguments, the first a pointer to an integer value + and the second an integer value. The result is also an integer value. These + integer types can have any bit width, but they must all have the same bit + width. The targets may only lower integer representations they support.
- These intrinsics take two arguments, the first a pointer to an integer value - and the second an integer value. The result is also an integer value. These - integer types can have any bit width, but they must all have the same bit - width. The targets may only lower integer representations they support. -Semantics:
-- These intrinsics does a series of operations atomically. They first load the - value stored at ptr. They then do the bitwise operation - delta, store the result to ptr. They yield the original - value stored at ptr. -
+These intrinsics does a series of operations atomically. They first load the + value stored at ptr. They then do the bitwise + operation delta, store the result to ptr. They yield the + original value stored at ptr.
Examples:
-%ptr = malloc i32 - store i32 0x0F0F, %ptr +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* + store i32 0x0F0F, %ptr %result0 = call i32 @llvm.atomic.load.nand.i32.p0i32( i32* %ptr, i32 0xFF ) ; yields {i32}:result0 = 0x0F0F %result1 = call i32 @llvm.atomic.load.and.i32.p0i32( i32* %ptr, i32 0xFF ) @@ -6210,8 +7063,8 @@ declare i64 @llvm.atomic.load.xor.i64.p0i32( i64* <ptr>, i64 <delta> ; yields {i32}:result3 = FF %memval1 = load i32* %ptr ; yields {i32}:memval1 = F0-
- These are overloaded intrinsics. You can use llvm.atomic.load_max, - llvm.atomic.load_min, llvm.atomic.load_umax, and - llvm.atomic.load_umin on any integer bit width and for different - address spaces. Not all targets - support all bit widths however.
--declare i8 @llvm.atomic.load.max.i8.p0i8( i8* <ptr>, i8 <delta> ) -declare i16 @llvm.atomic.load.max.i16.p0i16( i16* <ptr>, i16 <delta> ) -declare i32 @llvm.atomic.load.max.i32.p0i32( i32* <ptr>, i32 <delta> ) -declare i64 @llvm.atomic.load.max.i64.p0i64( i64* <ptr>, i64 <delta> ) +These are overloaded intrinsics. You can use llvm.atomic.load_max, + llvm.atomic.load_min, llvm.atomic.load_umax, and + llvm.atomic.load_umin on any integer bit width and for different + address spaces. Not all targets support all bit widths however.
++ declare i8 @llvm.atomic.load.max.i8.p0i8( i8* <ptr>, i8 <delta> ) + declare i16 @llvm.atomic.load.max.i16.p0i16( i16* <ptr>, i16 <delta> ) + declare i32 @llvm.atomic.load.max.i32.p0i32( i32* <ptr>, i32 <delta> ) + declare i64 @llvm.atomic.load.max.i64.p0i64( i64* <ptr>, i64 <delta> )-declare i8 @llvm.atomic.load.min.i8.p0i8( i8* <ptr>, i8 <delta> ) -declare i16 @llvm.atomic.load.min.i16.p0i16( i16* <ptr>, i16 <delta> ) -declare i32 @llvm.atomic.load.min.i32..p0i32( i32* <ptr>, i32 <delta> ) -declare i64 @llvm.atomic.load.min.i64..p0i64( i64* <ptr>, i64 <delta> ) - + declare i8 @llvm.atomic.load.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 - delta and the value stored in memory at ptr. It yields the - original value at ptr. -
+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.
+Arguments:
-+
These intrinsics take two arguments, the first a pointer to an integer value + and the second an integer value. The result is also an integer value. These + integer types can have any bit width, but they must all have the same bit + width. The targets may only lower integer representations they support.
- These intrinsics take two arguments, the first a pointer to an integer value - and the second an integer value. The result is also an integer value. These - integer types can have any bit width, but they must all have the same bit - width. The targets may only lower integer representations they support. -Semantics:
-- These intrinsics does a series of operations atomically. They first load the - value stored at ptr. They then do the signed or unsigned min or max - delta and the value, store the result to ptr. They yield - the original value stored at ptr. -
+These intrinsics does a series of operations atomically. They first load the + value stored at ptr. They then do the signed or unsigned min or + max delta and the value, store the result to ptr. They + yield the original value stored at ptr.
Examples:
-%ptr = malloc i32 - store i32 7, %ptr +%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) +%ptr = bitcast i8* %mallocP to i32* + store i32 7, %ptr %result0 = call i32 @llvm.atomic.load.min.i32.p0i32( i32* %ptr, i32 -2 ) ; yields {i32}:result0 = 7 %result1 = call i32 @llvm.atomic.load.max.i32.p0i32( i32* %ptr, i32 8 ) @@ -6296,6 +7142,134 @@ declare i64 @llvm.atomic.load.umin.i64..p0i64( i64* <ptr>, i64 <delta&g ; yields {i32}:result3 = 8 %memval1 = load i32* %ptr ; yields {i32}:memval1 = 30+ +
This class of intrinsics exists to information about the lifetime of memory + objects and ranges where variables are immutable.
+ ++ declare void @llvm.lifetime.start(i64 <size>, i8* nocapture <ptr>) ++ +
The 'llvm.lifetime.start' intrinsic specifies the start of a memory + object's lifetime.
+ +The first argument is a constant integer representing the size of the + object, or -1 if it is variable sized. The second argument is a pointer to + the object.
+ +This intrinsic indicates that before this point in the code, the value of the + memory pointed to by ptr is dead. This means that it is known to + never be used and has an undefined value. A load from the pointer that + precedes this intrinsic can be replaced with + 'undef'.
+ ++ declare void @llvm.lifetime.end(i64 <size>, i8* nocapture <ptr>) ++ +
The 'llvm.lifetime.end' intrinsic specifies the end of a memory + object's lifetime.
+ +The first argument is a constant integer representing the size of the + object, or -1 if it is variable sized. The second argument is a pointer to + the object.
+ +This intrinsic indicates that after this point in the code, the value of the + memory pointed to by ptr is dead. This means that it is known to + never be used and has an undefined value. Any stores into the memory object + following this intrinsic may be removed as dead. + +
+ declare {}* @llvm.invariant.start(i64 <size>, i8* nocapture <ptr>) readonly
+
+
+The 'llvm.invariant.start' intrinsic specifies that the contents of + a memory object will not change.
+ +The first argument is a constant integer representing the size of the + object, or -1 if it is variable sized. The second argument is a pointer to + the object.
+ +This intrinsic indicates that until an llvm.invariant.end that uses + the return value, the referenced memory location is constant and + unchanging.
+ +
+ declare void @llvm.invariant.end({}* <start>, i64 <size>, i8* nocapture <ptr>)
+
+
+The 'llvm.invariant.end' intrinsic specifies that the contents of + a memory object are mutable.
+ +The first argument is the matching llvm.invariant.start intrinsic. + The second argument is a constant integer representing the size of the + object, or -1 if it is variable sized and the third argument is a pointer + to the object.
+ +This intrinsic indicates that the memory is mutable again.
+This class of intrinsics is designed to be generic and has -no specific purpose.
+ +This class of intrinsics is designed to be generic and has no specific + purpose.
+-The 'llvm.var.annotation' intrinsic -
+The 'llvm.var.annotation' intrinsic.
-The first argument is a pointer to a value, the second is a pointer to a -global string, the third is a pointer to a global string which is the source -file name, and the last argument is the line number. -
+The first argument is a pointer to a value, the second is a pointer to a + global string, the third is a pointer to a global string which is the source + file name, and the last argument is the line number.
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.
--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. -
@@ -6352,9 +7320,9 @@ generation and optimization.This is an overloaded intrinsic. You can use 'llvm.annotation' on -any integer bit width. -
+This is an overloaded intrinsic. You can use 'llvm.annotation' on + 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> ) @@ -6364,28 +7332,20 @@ any integer bit width.
-The 'llvm.annotation' intrinsic. -
+The 'llvm.annotation' intrinsic.
-The first argument is an integer value (result of some expression), -the second is a pointer to a global string, the third is a pointer to a global -string which is the source file name, and the last argument is the line number. -It returns the value of the first argument. -
+The first argument is an integer value (result of some expression), the + second is a pointer to a global string, the third is a pointer to a global + string which is the source file name, and the last argument is the line + number. It returns the value of the first argument.
This intrinsic allows annotations to be put on arbitrary expressions with + arbitrary strings. This can be useful for special purpose optimizations that + want to look for these annotations. These have no other defined use, they + are ignored by code generation and optimization.
--This intrinsic allows annotations to be put on arbitrary expressions -with arbitrary strings. This can be useful for special purpose optimizations -that want to look for these annotations. These have no other defined use, they -are ignored by code generation and optimization. -
-The 'llvm.trap' intrinsic -
+The 'llvm.trap' intrinsic.
-None -
+None.
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.
--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. -
+-declare void @llvm.stackprotector( i8* <guard>, i8** <slot> ) + declare void @llvm.stackprotector( i8* <guard>, i8** <slot> ) ++ +
The llvm.stackprotector intrinsic takes the guard and + stores it onto the stack at slot. The stack slot is adjusted to + ensure that it is placed on the stack before local variables.
+ +The llvm.stackprotector intrinsic requires two pointer + arguments. The first argument is the value loaded from the stack + guard @__stack_chk_guard. The second variable is an alloca + that has enough space to hold the value of the guard.
+ +This intrinsic causes the prologue/epilogue inserter to force the position of + the AllocaInst stack slot to be before local variables on the + stack. This is to ensure that if a local variable on the stack is + overwritten, it will destroy the value of the guard. When the function exits, + the guard on the stack is checked against the original guard. If they're + different, then the program aborts by calling the __stack_chk_fail() + function.
++ declare i32 @llvm.objectsize.i32( i8* <object>, i1 <type> ) + declare i64 @llvm.objectsize.i64( i8* <object>, i1 <type> )+
- The llvm.stackprotector intrinsic takes the guard and stores - it onto the stack at slot. The stack slot is adjusted to ensure that - it is placed on the stack before local variables. -
+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.
+- The llvm.stackprotector intrinsic requires two pointer arguments. The - first argument is the value loaded from the stack guard - @__stack_chk_guard. The second variable is an alloca that - has enough space to hold the value of the guard. -
+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.
+- This intrinsic causes the prologue/epilogue inserter to force the position of - the AllocaInst stack slot to be before local variables on the - stack. This is to ensure that if a local variable on the stack is overwritten, - it will destroy the value of the guard. When the function exits, the guard on - the stack is checked against the original guard. If they're different, then - the program aborts by calling the __stack_chk_fail() function. -
+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.
+
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS">