X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.html;h=76fa06f49c24d0746822bad95173c69840d85dbd;hb=a75ce9f5d2236d93c117e861e60e6f3f748c9555;hp=c028f6bfe52213e69479ad5db54154906aa98d9f;hpb=e6a5ddd0fabfa333c88ded0d7a69074d64758f3c;p=oota-llvm.git diff --git a/docs/LangRef.html b/docs/LangRef.html index c028f6bfe52..76fa06f49c2 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -24,6 +24,8 @@
  1. 'private' Linkage
  2. 'linker_private' Linkage
    3. +
  3. 'linker_private_weak' Linkage
    4. +
  4. 'linker_private_weak_def_auto' Linkage
  5. 'internal' Linkage
  6. 'available_externally' Linkage
  7. 'linkonce' Linkage
    8. @@ -50,6 +52,7 @@
  8. Module-Level Inline Assembly
  9. Data Layout
  10. Pointer Aliasing Rules
    11. +
  11. Volatile Memory Accesses
  • Type System @@ -59,6 +62,7 @@
    1. Integer Type
    2. Floating Point Types
      3. +
    3. X86mmx Type
    4. Void Type
    5. Label Type
    6. Metadata Type
      7. @@ -66,12 +70,16 @@
    7. Derived Types
        -
      1. Array Type
        2. +
      2. Aggregate Types +
          +
        1. Array Type
          2. +
        2. Structure Type
          3. +
        3. Packed Structure Type
          4. +
        4. Vector Type
          5. +
        +
      3. Function Type
      4. Pointer Type
        5. -
      5. Structure Type
        6. -
      6. Packed Structure Type
        7. -
      7. Vector Type
      8. Opaque Type
      8. @@ -84,6 +92,7 @@
    8. Complex Constants
    9. Global Variable and Function Addresses
    10. Undefined Values
      11. +
    11. Trap Values
    12. Addresses of Basic Blocks
    13. Constant Expressions
    @@ -217,7 +226,7 @@
  • 'llvm.stackrestore' Intrinsic
  • 'llvm.prefetch' Intrinsic
  • 'llvm.pcmarker' Intrinsic
    • -
  • llvm.readcyclecounter' Intrinsic
    • +
  • 'llvm.readcyclecounter' Intrinsic
  • Standard C Library Intrinsics @@ -250,6 +259,12 @@
  • 'llvm.umul.with.overflow.* Intrinsics
    • +
  • Half Precision Floating Point Intrinsics +
      +
    1. 'llvm.convert.to.fp16' Intrinsic
      2. +
    2. 'llvm.convert.from.fp16' Intrinsic
      3. +
    +
  • Debugger intrinsics
  • Exception Handling intrinsics
  • Trampoline Intrinsic @@ -356,11 +371,9 @@ what is considered 'well formed'. For example, the following instruction is syntactically okay, but not well formed:

    -
    -
    +
     %x = add i32 1, %x
 
    
-

    because the definition of %x does not dominate all of its uses. The LLVM infrastructure provides a verification pass that may be used to verify @@ -423,29 +436,23 @@

    The easy way:

    -
    -
    +
     %result = mul i32 %X, 8
 
    
-

    After strength reduction:

    -
    -
    +
     %result = shl i32 %X, i8 3
 
    
-

    And the hard way:

    -
    -
    +
     %0 = add i32 %X, %X           ; yields {i32}:%0
 %1 = add i32 %0, %0           ; yields {i32}:%1
 %result = add i32 %1, %1
 
    
-

    This last way of multiplying %X by 8 illustrates several important lexical features of LLVM:

    @@ -484,28 +491,27 @@ 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 *)* 
+; External declaration of the puts function 
+declare i32 @puts(i8*)                                      ; i32 (i8*)*  
 
 ; Definition of main function
-define i32 @main() {                                        ; i32()* 
-  ; Convert [13 x i8]* to i8  *...
-  %cast210 = getelementptr [13 x i8]* @.LC0, i64 0, i64 0   ; i8 *
+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, @@ -533,20 +539,33 @@ define i32 @main() { ; i32()*

    private
    -
    Global values with private linkage are only directly accessible by objects - in the current module. In particular, linking code into a module with an - private global value may cause the private to be renamed as necessary to - avoid collisions. Because the symbol is private to the module, all - references can be updated. This doesn't show up in any symbol table in the - object file.
    +
    Global values with "private" linkage are only directly accessible + by objects in the current module. In particular, linking code into a + module with an private global value may cause the private to be renamed as + necessary to avoid collisions. Because the symbol is private to the + module, all references can be updated. This doesn't show up in any symbol + table in the object file.
    linker_private
    -
    Similar to private, but the symbol is passed through the assembler and - removed by the linker after evaluation. Note that (unlike private - symbols) linker_private symbols are subject to coalescing by the linker: - weak symbols get merged and redefinitions are rejected. However, unlike - normal strong symbols, they are removed by the linker from the final - linked image (executable or dynamic library).
    +
    Similar to private, but the symbol is passed through the + assembler and evaluated by the linker. Unlike normal strong symbols, they + are removed by the linker from the final linked image (executable or + dynamic library).
    + +
    linker_private_weak
    +
    Similar to "linker_private", but the symbol is weak. Note that + linker_private_weak symbols are subject to coalescing by the + linker. The symbols are removed by the linker from the final linked image + (executable or dynamic library).
    + +
    linker_private_weak_def_auto
    +
    Similar to "linker_private_weak", but it's known that the address + of the object is not taken. For instance, functions that had an inline + definition, but the compiler decided not to inline it. Note, + unlike linker_private and linker_private_weak, + linker_private_weak_def_auto may have only default + visibility. The symbols are removed by the linker from the final linked + image (executable or dynamic library).
    internal
    Similar to private, but the value shows as a local symbol @@ -610,8 +629,8 @@ define i32 @main() { ; i32()*
    weak_odr
    Some languages allow differing globals to be merged, such as two functions with different semantics. Other languages, such as C++, ensure - that only equivalent globals are ever merged (the "one definition rule" - - "ODR"). Such languages can use the linkonce_odr + that only equivalent globals are ever merged (the "one definition rule" + — "ODR"). Such languages can use the linkonce_odr and weak_odr linkage types to indicate that the global will only be merged with equivalent globals. These linkage types are otherwise the same as their non-odr versions.
    @@ -686,9 +705,9 @@ define i32 @main() { ; i32()* target, without having to conform to an externally specified ABI (Application Binary Interface). Tail calls can only be optimized - when this convention is used. This calling convention does not - support varargs and requires the prototype of all callees to exactly match - the prototype of the function definition. + when this or the GHC convention is used. This calling convention + does not support varargs and requires the prototype of all callees to + exactly match the prototype of the function definition.
    "coldcc" - The cold calling convention:
    This calling convention attempts to make code in the caller as efficient @@ -698,6 +717,26 @@ define i32 @main() { ; i32()* does not support varargs and requires the prototype of all callees to exactly match the prototype of the function definition.
    +
    "cc 10" - GHC convention:
    +
    This calling convention has been implemented specifically for use by the + Glasgow Haskell Compiler (GHC). + It passes everything in registers, going to extremes to achieve this by + disabling callee save registers. This calling convention should not be + used lightly but only for specific situations such as an alternative to + the register pinning performance technique often used when + implementing functional programming languages.At the moment only X86 + supports this convention and it has the following limitations: +
      +
    • On X86-32 only supports up to 4 bit type parameters. No + floating point types are supported.
      • +
    • On X86-64 only supports up to 10 bit type parameters and + 6 floating point parameters.
      • +
    + This calling convention supports + tail call optimization but + requires both the caller and callee are using it. +
    +
    "cc <n>" - Numbered convention:
    Any calling convention may be specified by number, allowing target-specific calling conventions to be used. Target specific calling @@ -755,14 +794,12 @@ define i32 @main() { ; i32()* 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 + "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, @@ -818,20 +855,22 @@ define i32 @main() { ; i32()*

    LLVM allows an explicit section to be specified for globals. If the target supports it, it will emit globals to the section specified.

    -

    An explicit alignment may be specified for a global. If not present, or if - the alignment is set to zero, the alignment of the global is set by the - target to whatever it feels convenient. If an explicit alignment is - specified, the global is forced to have at least that much alignment. All - alignments must be a power of 2.

    +

    An explicit alignment may be specified for a global, which must be a power + of 2. If not present, or if the alignment is set to zero, the alignment of + the global is set by the target to whatever it feels convenient. If an + explicit alignment is specified, the global is forced to have exactly that + alignment. Targets and optimizers are not allowed to over-align the global + if the global has an assigned section. In this case, the extra alignment + could be observable: for example, code could assume that the globals are + densely packed in their section and try to iterate over them as an array, + alignment padding would break this iteration.

    For example, the following defines a global in a numbered address space with an initializer, section, and alignment:

    -
    -
    +
     @G = addrspace(5) constant float 1.0, section "foo", align 4
 
    
-
    @@ -843,7 +882,7 @@ define i32 @main() { ; i32()*
    -

    LLVM function definitions consist of the "define" keyord, an +

    LLVM function definitions consist of the "define" keyword, an optional linkage type, an optional visibility style, an optional calling convention, a return type, an optional @@ -884,15 +923,13 @@ define i32 @main() { ; i32()* alignments must be a power of 2.

    Syntax:
    -
    -
    +
     define [linkage] [visibility]
        [cconv] [ret attrs]
        <ResultType> @<FunctionName> ([argument list])
        [fn Attrs] [section "name"] [align N]
        [gc] { ... }
 
    
-
    @@ -909,11 +946,9 @@ define [linkage] [visibility] optional visibility style.

    Syntax:
    -
    -
    +
     @<Name> = alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee>
 
    
-
    @@ -925,16 +960,18 @@ define [linkage] [visibility]

    Named metadata is a collection of metadata. Metadata - nodes (but not metadata strings) and null are the only valid operands for + nodes (but not metadata strings) are the only valid operands for a named metadata.

    Syntax:
    -
    -
    +
    +; Some unnamed metadata nodes, which are referenced by the named metadata.
+!0 = metadata !{metadata !"zero"}
 !1 = metadata !{metadata !"one"}
-!name = !{null, !1}
+!2 = metadata !{metadata !"two"}
+; A named metadata.
+!name = !{!0, !1, !2}
 
    
-
    @@ -954,13 +991,11 @@ define [linkage] [visibility] multiple parameter attributes are needed, they are space separated. For example:

    -
    -
    +
     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.

    @@ -986,8 +1021,9 @@ declare signext i8 @returns_signed_char() registers). Use of this attribute is target-specific.
    byval
    -
    This indicates that the pointer parameter should really be passed by value - to the function. The attribute implies that a hidden copy of the pointee +

    This indicates that the pointer parameter should really be passed by + value to the function. The attribute implies that a hidden copy of the + pointee is made between the caller and the callee, so the callee is unable to modify the value in the callee. This attribute is only valid on LLVM pointer arguments. It is generally used to pass structs and arrays by @@ -995,12 +1031,15 @@ declare signext i8 @returns_signed_char() to belong to the caller not the callee (for example, readonly functions should not write to byval parameters). This is not a valid attribute for return - values. The byval attribute also supports specifying an alignment with - the align attribute. This has a target-specific effect on the code - generator that usually indicates a desired alignment for the synthesized - stack slot.

    - -
    sret
    + values.

    + +

    The byval attribute also supports specifying an alignment with + the align attribute. It indicates the alignment of the stack slot to + form and the known alignment of the pointer specified to the call site. If + the alignment is not specified, then the code generator makes a + target-specific assumption.

    + +
    sret
    This indicates that the pointer parameter specifies the address of a structure that is the return value of the function in the source program. This pointer must be guaranteed by the caller to be valid: loads and @@ -1008,22 +1047,34 @@ declare signext i8 @returns_signed_char() may only be applied to the first parameter. This is not a valid attribute for return values.
    -
    noalias
    -
    This indicates that the pointer does not alias any global or any other - parameter. The caller is responsible for ensuring that this is the - case. On a function return value, noalias additionally indicates - that the pointer does not alias any other pointers visible to the - caller. For further details, please see the discussion of the NoAlias - response in - alias - analysis.
    - -
    nocapture
    +
    noalias
    +
    This indicates that pointer values + based on the argument or return + value do not alias pointer values which are not based on it, + ignoring certain "irrelevant" dependencies. + For a call to the parent function, dependencies between memory + references from before or after the call and from those during the call + are "irrelevant" to the noalias keyword for the arguments and + return value used in that call. + The caller shares the responsibility with the callee for ensuring that + these requirements are met. + For further details, please see the discussion of the NoAlias response in + alias analysis.
    +
    + Note that this definition of noalias is intentionally + similar to the definition of restrict in C99 for function + arguments, though it is slightly weaker. +
    + For function return values, C99's restrict is not meaningful, + while LLVM's noalias is. +
    + +
    nocapture
    This indicates that the callee does not make any copies of the pointer that outlive the callee itself. This is not a valid attribute for return values.
    -
    nest
    +
    nest
    This indicates that the pointer parameter can be excised using the trampoline intrinsics. This is not a valid attribute for return values.
    @@ -1041,11 +1092,9 @@ declare signext i8 @returns_signed_char()

    Each function may specify a garbage collector name, which is simply a string:

    -
    -
    +
     define void @f() gc "name" { ... }
 
    
-

    The compiler declares the supported values of name. Specifying a collector which will cause the compiler to alter its output in order to @@ -1068,30 +1117,52 @@ define void @f() gc "name" { ... }

    Function attributes are simple keywords that follow the type specified. If multiple attributes are needed, they are space separated. For example:

    -
    -
    +
     define void @f() noinline { ... }
 define void @f() alwaysinline { ... }
 define void @f() alwaysinline optsize { ... }
 define void @f() optsize { ... }
 
    
-
    +
    alignstack(<n>)
    +
    This attribute indicates that, when emitting the prologue and epilogue, + the backend should forcibly align the stack pointer. Specify the + desired alignment, which must be a power of two, in parentheses. +
    alwaysinline
    This attribute indicates that the inliner should attempt to inline this function into callers whenever possible, ignoring any active inlining size threshold for this caller.
    +
    hotpatch
    +
    This attribute indicates that the function should be 'hotpatchable', + meaning the function can be patched and/or hooked even while it is + loaded into memory. On x86, the function prologue will be preceded + by six bytes of padding and will begin with a two-byte instruction. + Most of the functions in the Windows system DLLs in Windows XP SP2 or + higher were compiled in this fashion.
    + +
    inlinehint
    +
    This attribute indicates that the source code contained a hint that inlining + this function is desirable (such as the "inline" keyword in C/C++). It + is just a hint; it imposes no requirements on the inliner.
    + +
    naked
    +
    This attribute disables prologue / epilogue emission for the function. + This can have very system-specific consequences.
    + +
    noimplicitfloat
    +
    This attributes disables implicit floating point instructions.
    +
    noinline
    This attribute indicates that the inliner should never inline this function in any situation. This attribute may not be used together with the alwaysinline attribute.
    -
    optsize
    -
    This attribute suggests that optimization passes and code generator passes - make choices that keep the code size of this function low, and otherwise - do optimizations specifically to reduce code size.
    +
    noredzone
    +
    This attribute indicates that the code generator should not use a red + zone, even if the target-specific ABI normally permits it.
    noreturn
    This function attribute indicates that the function never returns @@ -1103,6 +1174,11 @@ define void @f() optsize { ... } unwind or exceptional control flow. If the function does unwind, its runtime behavior is undefined.
    +
    optsize
    +
    This attribute suggests that optimization passes and code generator passes + make choices that keep the code size of this function low, and otherwise + do optimizations specifically to reduce code size.
    +
    readnone
    This attribute indicates that the function computes its result (or decides to unwind an exception) based strictly on its arguments, without @@ -1145,17 +1221,6 @@ define void @f() optsize { ... } function that doesn't have an sspreq attribute or which has an ssp attribute, then the resulting function will have an sspreq attribute.
    - -
    noredzone
    -
    This attribute indicates that the code generator should not use a red - zone, even if the target-specific ABI normally permits it.
    - -
    noimplicitfloat
    -
    This attributes disables implicit floating point instructions.
    - -
    naked
    -
    This attribute disables prologue / epilogue emission for the function. - This can have very system-specific consequences.
    @@ -1172,12 +1237,10 @@ define void @f() optsize { ... } concatenated by LLVM and treated as a single unit, but may be separated in the .ll file if desired. The syntax is very simple:

    -
    -
    +
     module asm "inline asm code goes here"
 module asm "more can go here"
 
    
-

    The strings can contain any character by escaping non-printable characters. The escape sequence used is simply "\xx" where "xx" is the two digit hex code @@ -1199,11 +1262,9 @@ module asm "more can go here" data is to be laid out in memory. The syntax for the data layout is simply:

    -
    -
    +
     target datalayout = "layout specification"
 
    
-

    The layout specification consists of a list of specifications separated by the minus sign character ('-'). Each specification starts with @@ -1236,8 +1297,10 @@ target datalayout = "layout specification"

    fsize:abi:pref
    This specifies the alignment for a floating point type of a given bit - size. The value of size must be either 32 (float) or 64 - (double).
    + size. Only values of size that are supported by the target + will work. 32 (float) and 64 (double) are supported on all targets; + 80 or 128 (different flavors of long double) are also supported on some + targets.
    asize:abi:pref
    This specifies the alignment for an aggregate type of a given bit @@ -1256,13 +1319,13 @@ target datalayout = "layout specification"

    When constructing the data layout for a given target, LLVM starts with a - default set of specifications which are then (possibly) overriden by the + default set of specifications which are then (possibly) overridden by the specifications in the datalayout keyword. The default specifications are given in this list:

    + +

    A pointer value is based on another pointer value according + to the following rules:

    + + + +

    Note that this definition of "based" is intentionally + similar to the definition of "based" in C99, though it is + slightly weaker.

    LLVM IR does not associate types with memory. The result type of a load merely indicates the size and alignment of the memory from which to load, as well as the -interpretation of the value. The first operand of a +interpretation of the value. The first operand type of a store similarly only indicates the size and alignment of the store.

    @@ -1352,6 +1427,24 @@ to implement type-based alias analysis.

    + +
    + Volatile Memory Accesses +
    + +
    + +

    Certain memory accesses, such as loads, stores, and llvm.memcpys may be marked volatile. +The optimizers must not change the number of volatile operations or change their +order of execution relative to other volatile operations. The optimizers +may change the order of volatile operations relative to non-volatile +operations. This is not Java's "volatile" and has no cross-thread +synchronization behavior.

    + +
    +
    Type System
    @@ -1404,12 +1497,12 @@ Classifications label, void, floating point, + x86mmx, metadata. derived - integer, - array, + array, function, pointer, structure, @@ -1491,6 +1584,21 @@ Classifications + +
    X86mmx Type
    + +
    + +
    Overview:
    +

    The x86mmx type represents a value held in an MMX register on an x86 machine. The operations allowed on it are quite limited: parameters and return values, load and store, and bitcast. User-specified MMX instructions are represented as intrinsic or asm calls with arguments and/or results of this type. There are no arrays, vectors or constants of this type.

    + +
    Syntax:
    +
    +  x86mmx
+
    + +
    +
    Void Type
    @@ -1551,6 +1659,19 @@ Classifications possible to have a two dimensional array, using an array as the element type of another array.

    + + + + +
    Aggregate Types
    + +
    + +

    Aggregate Types are a subset of derived types that can contain multiple + member types. Arrays, + structs, and vectors are + aggregate types.

    +
    @@ -1619,9 +1740,7 @@ Classifications
    Overview:

    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.

    + function type is a first class type or a void type.

    Syntax:
    @@ -1633,7 +1752,7 @@ Classifications 
    which indicates that the function takes a variable number of arguments.
    Variable argument functions can access their arguments with
    the variable argument handling intrinsic
-   functions.  '<returntype>' is a any type except
+   functions.  '<returntype>' is any type except
    label.
    
 
 
    Examples:
    
@@ -1643,12 +1762,11 @@ Classifications 
     function taking an i32, returning an i32
     
   
-    float (i16 signext, i32 *) *
+    float (i16, i32 *) *
     
     Pointer to a function that takes
-      an i16 that should be sign extended and a
-      pointer to i32, returning
-      float.
+      an i16 and a pointer to i32,
+      returning float.
     
   
     i32 (i8*, ...)
@@ -1749,10 +1867,13 @@ Classifications 
 
    
 
 
    Overview:
    
-
    As in many languages, the pointer type represents a pointer or reference to
-   another object, which must live in memory. Pointer types may have an optional
-   address space attribute defining the target-specific numbered address space
-   where the pointed-to object resides. The default address space is zero.
    
+
    The pointer type is used to specify memory locations.
+   Pointers are commonly used to reference objects in memory.
    
+   
+
    Pointer types may have an optional address space attribute defining the
+   numbered address space where the pointed-to object resides. The default
+   address space is number zero. The semantics of non-zero address
+   spaces are target-specific.
    
 
 
    Note that LLVM does not permit pointers to void (void*) nor does it
    permit pointers to labels (label*).  Use i8* instead.
    
@@ -1770,7 +1891,7 @@ Classifications 
    
                     href="#t_array">array of four i32 values.
   
   
-    i32 (i32 *) *
+    i32 (i32*) *
      A pointer to a function that takes an i32*, returning an
       i32.
@@ -1801,8 +1922,9 @@ Classifications 
   < <# 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 larger than 0; elementtype + may be any integer or floating point type. Vectors of size zero are not + allowed, and pointers are not allowed as the element type.

    Examples:
    @@ -1958,6 +2080,7 @@ Classifications they match the long double format on your target. All hexadecimal formats are big-endian (sign bit at the left).

    +

    There are no constants of type x86mmx.

    @@ -1999,7 +2122,8 @@ Classifications
    Zero initialization
    The string 'zeroinitializer' can be used to zero initialize a - value to zero of any type, including scalar and aggregate types. + value to zero of any type, including scalar and + aggregate types. This is often used to avoid having to print large zero initializers (e.g. for large arrays) and is always exactly equivalent to using explicit zero initializers.
    @@ -2028,13 +2152,11 @@ Classifications have pointer type. For example, the following is a legal LLVM file:

    -
    -
    +
     @X = global i32 17
 @Y = global i32 42
 @Z = global [2 x i32*] [ i32* @X, i32* @Y ]
 
    
-
    @@ -2044,8 +2166,8 @@ Classifications

    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 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 @@ -2053,8 +2175,7 @@ Classifications surprising) transformations that are valid (in pseudo IR):

    -
    -
    +
       %A = add %X, undef
   %B = sub %X, undef
   %C = xor %X, undef
@@ -2063,13 +2184,11 @@ Safe:
   %B = undef
   %C = undef
 
    
-

    This is safe because all of the output bits are affected by the undef bits. -Any output bit can have a zero or one depending on the input bits.

    + Any output bit can have a zero or one depending on the input bits.

    -
    -
    +
       %A = or %X, undef
   %B = and %X, undef
 Safe:
@@ -2079,19 +2198,18 @@ 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.

    - -
    -
    +   For example, if %X has a zero bit, then the output of the
+   'and' operation will always be a zero for that bit, 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
@@ -2104,18 +2222,17 @@ Unsafe:
   %B = undef
   %C = undef
 
    
-
    -

    This set of examples show that undefined select (and conditional branch) -conditions can go "either way" but they have to come from one of the two -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.

    +

    This set of examples shows 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
@@ -2133,57 +2250,158 @@ Safe:
   %E = undef
   %F = undef
 
    
-
    -

    This example points out that two undef operands are not necessarily the same. -This can be surprising to people (and also matches C semantics) where they -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.

    +

    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 undefined. 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. -

    - -
    -
    +  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. Because 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.
    
+
    -

    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.

    + +
    Trap Values
    +
    + +

    Trap values are similar to undef values, however + instead of representing an unspecified bit pattern, they represent the + fact that an instruction or constant expression which cannot evoke side + effects has nevertheless detected a condition which results in undefined + behavior.

    + +

    There is currently no way of representing a trap value in the IR; they + only exist when produced by operations such as + add with the nsw flag.

    + +

    Trap value behavior is defined in terms of value dependence:

    + +
      +
    • Values other than phi nodes depend on + their operands.
      • + +
    • Phi nodes depend on the operand corresponding + to their dynamic predecessor basic block.
      • + +
    • Function arguments depend on the corresponding actual argument values in + the dynamic callers of their functions.
      • + +
    • Call instructions depend on the + ret instructions that dynamically transfer + control back to them.
      • + +
    • Invoke instructions depend on the + ret, unwind, + or exception-throwing call instructions that dynamically transfer control + back to them.
      • + +
    • Non-volatile loads and stores depend on the most recent stores to all of the + referenced memory addresses, following the order in the IR + (including loads and stores implied by intrinsics such as + @llvm.memcpy.)
      • + + + + + +
    • An instruction with externally visible side effects depends on the most + recent preceding instruction with externally visible side effects, following + the order in the IR. (This includes + volatile operations.)
      • + +
    • An instruction control-depends on a + terminator instruction + if the terminator instruction has multiple successors and the instruction + is always executed when control transfers to one of the successors, and + may not be executed when control is transfered to another.
      • + +
    • Dependence is transitive.
      • + +
    + +

    Whenever a trap value is generated, all values which depend on it evaluate + to trap. If they have side effects, the evoke their side effects as if each + operand with a trap value were undef. If they have externally-visible side + effects, the behavior is undefined.

    + +

    Here are some examples:

    + +
    +entry:
+  %trap = sub nuw i32 0, 1           ; Results in a trap value.
+  %still_trap = and i32 %trap, 0     ; Whereas (and i32 undef, 0) would return 0.
+  %trap_yet_again = getelementptr i32* @h, i32 %still_trap
+  store i32 0, i32* %trap_yet_again  ; undefined behavior
+
+  store i32 %trap, i32* @g           ; Trap value conceptually stored to memory.
+  %trap2 = load i32* @g              ; Returns a trap value, not just undef.
+
+  volatile store i32 %trap, i32* @g  ; External observation; undefined behavior.
+
+  %narrowaddr = bitcast i32* @g to i16*
+  %wideaddr = bitcast i32* @g to i64*
+  %trap3 = load 16* %narrowaddr      ; Returns a trap value.
+  %trap4 = load i64* %widaddr        ; Returns a trap value.
+
+  %cmp = icmp i32 slt %trap, 0       ; Returns a trap value.
+  %br i1 %cmp, %true, %end           ; Branch to either destination.
+
+true:
+  volatile store i32 0, i32* @g      ; This is control-dependent on %cmp, so
+                                     ; it has undefined behavior.
+  br label %end
+
+end:
+  %p = phi i32 [ 0, %entry ], [ 1, %true ]
+                                     ; Both edges into this PHI are
+                                     ; control-dependent on %cmp, so this
+                                     ; always results in a trap value.
+
+  volatile store i32 0, i32* @g      ; %end is control-equivalent to %entry
+                                     ; so this is defined (ignoring earlier
+                                     ; undefined behavior in this example).
+
    @@ -2199,18 +2417,17 @@ has undefined behavior.

    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.

    + 'indirectbr' instruction, or for + comparisons against null. Pointer equality tests between labels addresses + results in undefined behavior — though, again, comparison against null + is ok, and no label is equal to the null pointer. This may 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 + instruction.

    -

    Finally, some targets may provide defined semantics when - using the value as the operand to an inline assembly, but that is target - specific. -

    +

    Finally, some targets may provide defined semantics when using the value as + the operand to an inline assembly, but that is target specific.

    @@ -2225,107 +2442,117 @@ has undefined behavior.

    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:

    + supported). The following is the syntax for constant expressions:

    -
    trunc ( CST to TYPE )
    +
    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.
    -
    zext ( CST to TYPE )
    +
    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.
    + smaller than the bit size of TYPE. Both types must be integers. -
    sext ( CST to TYPE )
    +
    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.
    + smaller than the bit size of TYPE. Both types must be integers. -
    fptrunc ( CST to TYPE )
    +
    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.
    -
    fpext ( CST to TYPE )
    +
    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.
    -
    fptoui ( CST to TYPE )
    +
    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.
    -
    fptosi ( CST to TYPE )
    +
    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.
    -
    uitofp ( CST to TYPE )
    +
    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.
    -
    sitofp ( CST to TYPE )
    +
    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.
    -
    ptrtoint ( CST to TYPE )
    +
    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.
    -
    inttoptr ( CST to 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!
    -
    bitcast ( CST to TYPE )
    +
    bitcast (CST to 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, ... )
    +
    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".
    -
    select ( COND, VAL1, VAL2 )
    +
    select (COND, VAL1, VAL2)
    Perform the select operation on constants.
    -
    icmp COND ( VAL1, VAL2 )
    +
    icmp COND (VAL1, VAL2)
    Performs the icmp operation on constants.
    -
    fcmp COND ( VAL1, VAL2 )
    +
    fcmp COND (VAL1, VAL2)
    Performs the fcmp operation on constants.
    -
    extractelement ( VAL, IDX )
    +
    extractelement (VAL, IDX)
    Perform the extractelement operation on constants.
    -
    insertelement ( VAL, ELT, IDX )
    +
    insertelement (VAL, ELT, IDX)
    Perform the insertelement operation on constants.
    -
    shufflevector ( VEC1, VEC2, IDXMASK )
    +
    shufflevector (VEC1, VEC2, IDXMASK)
    Perform the shufflevector operation on constants.
    -
    OPCODE ( LHS, RHS )
    +
    extractvalue (VAL, IDX0, IDX1, ...)
    +
    Perform the extractvalue operation on + constants. The index list is interpreted in a similar manner as indices in + a 'getelementptr' operation. At least one + index value must be specified.
    + +
    insertvalue (VAL, ELT, IDX0, IDX1, ...)
    +
    Perform the insertvalue operation on + constants. The index list is interpreted in a similar manner as indices in + a 'getelementptr' operation. At least one + index value must be specified.
    + +
    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 @@ -2355,31 +2582,25 @@ has undefined behavior.

    containing the asm needs to align its stack conservatively. An example inline assembler expression is:

    -
    -
    +
     i32 (i32) asm "bswap $0", "=r,r"
 
    
-

    Inline assembler expressions may only be used as the callee operand of a call instruction. Thus, typically we have:

    -
    -
    +
     %X = call i32 asm "bswap $0", "=r,r"(i32 %Y)
 
    
-

    Inline asms with side effects not visible in the constraint list must be marked as having side effects. This is done through the use of the 'sideeffect' keyword, like so:

    -
    -
    +
     call void asm sideeffect "eieio", ""()
 
    
-

    In some cases inline asms will contain code that will not work unless the stack is aligned in some way, such as calls or SSE instructions on x86, @@ -2388,11 +2609,9 @@ call void asm sideeffect "eieio", ""() contain and should generate its usual stack alignment code in the prologue if the 'alignstack' keyword is present:

    -
    -
    +
     call void asm alignstack "eieio", ""()
 
    
-

    If both keywords appear the 'sideeffect' keyword must come first.

    @@ -2401,6 +2620,30 @@ call void asm alignstack "eieio", ""() documented here. Constraints on what can be done (e.g. duplication, moving, etc need to be documented). This is probably best done by reference to another document that covers inline asm from a holistic perspective.

    + + +
    +Inline Asm Metadata +
    + +
    + +

    The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode + attached to it that contains a list of constant integers. If present, the + code generator will use the integer as the location cookie value when report + errors through the LLVMContext error reporting mechanisms. This allows a + front-end to correlate backend errors that occur with inline asm back to the + source code that produced it. For example:

    + +
    +call void asm sideeffect "something bad", ""(), !srcloc !42
+...
+!42 = !{ i32 1234567 }
+
    + +

    It is up to the front-end to make sense of the magic numbers it places in the + IR. If the MDNode contains multiple constants, the code generator will use + the one that corresponds to the line of the asm that the error occurs on.

    @@ -2431,6 +2674,19 @@ call void asm alignstack "eieio", ""() metadata nodes, which can be looked up in the module symbol table. For example: "!foo = metadata !{!4, !3}". +

    Metadata can be used as function arguments. Here llvm.dbg.value + function is using two metadata arguments.

    + + 
    +       call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)
+
    + +

    Metadata can be attached with an instruction. Here metadata !21 is + attached with add instruction using !dbg identifier.

    + + 
    +      %indvar.next = add i64 %indvar, 1, !dbg !21
+
    @@ -2505,8 +2761,12 @@ should not be exposed to source languages.

    - -

    TODO: Describe this.

    +
    +%0 = type { i32, void ()* }
+@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }]
+
    +

    The @llvm.global_ctors array contains a list of constructor functions and associated priorities. The functions referenced by this array will be called in ascending order of priority (i.e. lowest first) when the module is loaded. The order of functions with the same priority is not defined. +

    @@ -2516,8 +2776,13 @@ should not be exposed to source languages.

    +
    +%0 = type { i32, void ()* }
+@llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }]
+
    -

    TODO: Describe this.

    +

    The @llvm.global_dtors array contains a list of destructor functions and associated priorities. The functions referenced by this array will be called in descending order of priority (i.e. highest first) when the module is loaded. The order of functions with the same priority is not defined. +

    @@ -2550,7 +2815,7 @@ Instructions control flow, not values (the one exception being the 'invoke' instruction).

    -

    There are six different terminator instructions: the +

    There are seven different terminator instructions: the 'ret' instruction, the 'br' instruction, the 'switch' instruction, the @@ -2798,9 +3063,10 @@ IfUnequal: function to be invoked.

  • 'function args': argument list whose types match the function - signature argument types. If the function signature indicates the - function accepts a variable number of arguments, the extra arguments can - be specified.
    • + signature argument types and parameter attributes. All arguments must be + of first class type. If the function + signature indicates the function accepts a variable number of arguments, + the extra arguments can be specified.
  • 'normal label': the label reached when the called function executes a 'ret' instruction.
    • @@ -2946,7 +3212,8 @@ Instruction

    nuw and nsw stand for "No Unsigned Wrap" and "No Signed Wrap", respectively. If the nuw and/or nsw keywords are present, the result value of the add - is undefined if unsigned and/or signed overflow, respectively, occurs.

    + is a trap value if unsigned and/or signed overflow, + respectively, occurs.

    Example:
    @@ -3026,7 +3293,8 @@ Instruction 
 
    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.
    
+   is a trap value if unsigned and/or signed overflow,
+   respectively, occurs.
    
 
 
    Example:
    
 
    @@ -3112,7 +3380,8 @@ Instruction 
 
    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.
    
+   is a trap value if unsigned and/or signed overflow,
+   respectively, occurs.
    
 
 
    Example:
    
 
    @@ -3217,8 +3486,8 @@ Instruction 
    a 32-bit division of -2147483648 by -1.
    
 
 
    If the exact keyword is present, the result value of the
-   sdiv is undefined if the result would be rounded or if overflow
-   would occur.
    
+   sdiv is a trap value if the result would
+   be rounded.
    
 
 
    Example:
    
 
    @@ -3835,7 +4104,8 @@ Instruction 
 
 
    
 
-
    LLVM supports several instructions for working with aggregate values.
    
+
    LLVM supports several instructions for working with
+  aggregate values.
    
 
 
    
 
@@ -3852,15 +4122,23 @@ Instruction 
 
    
 
 
    Overview:
    
-
    The 'extractvalue' instruction extracts the value of a struct field
-   or array element from an aggregate value.
    
+
    The 'extractvalue' instruction extracts the value of a member field
+   from an aggregate value.
    
 
 
    Arguments:
    
 
    The first operand of an 'extractvalue' instruction is a value
-   of struct or array type.  The
-   operands are constant indices to specify which value to extract in a similar
-   manner as indices in a
+   of struct 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 major differences to getelementptr indexing are:
    
+     
      
+       
    • Since the value being indexed is not a pointer, the first index is
+           omitted and assumed to be zero.
      • 
+       
    • At least one index must be specified.
      • 
+       
    • Not only struct indices but also array indices must be in
+           bounds.
      • 
+     
    
 
 
    Semantics:
    
 
    The result is the value at the position in the aggregate specified by the
@@ -3886,17 +4164,16 @@ Instruction 
 
    
 
 
    Overview:
    
-
    The 'insertvalue' instruction inserts a value into a struct field or
-   array element in an aggregate.
    
-
+
    The 'insertvalue' instruction inserts a value into a member field
+   in an aggregate value.
    
 
 
    Arguments:
    
 
    The first operand of an 'insertvalue' instruction is a value
-   of struct or array type.  The
-   second operand is a first-class value to insert.  The following operands are
-   constant indices indicating the position at which to insert the value in a
-   similar manner as indices in a
-   'getelementptr' instruction.  The
+   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
+   'extractvalue' instruction.  The
    value to insert must have the same type as the value identified by the
    indices.
    
 
@@ -3937,7 +4214,7 @@ Instruction 
 
 
    Syntax:
    
 
    -  <result> = alloca <type>[, i32 <NumElements>][, align <alignment>]     ; yields {type*}:result
+  <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>]     ; yields {type*}:result
 
    
 
 
    Overview:
    
@@ -3987,8 +4264,9 @@ Instruction 
 
 
    Syntax:
    
 
    -  <result> = load <ty>* <pointer>[, align <alignment>]
-  <result> = volatile load <ty>* <pointer>[, align <alignment>]
+  <result> = load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
+  <result> = volatile load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
+  !<index> = !{ i32 1 }
 
    
 
 
    Overview:
    
@@ -3999,18 +4277,25 @@ Instruction 
    from which to load.  The pointer must point to
    a first class type.  If the load is
    marked as volatile, then the optimizer is not allowed to modify the
-   number or order of execution of this load with other
-   volatile load and store
-   instructions. 
    
+   number or order of execution of this load with other volatile operations.
    
 
-
    The optional constant "align" argument specifies the alignment of the
+
    The optional constant align argument specifies the alignment of the
    operation (that is, the alignment of the memory address). A value of 0 or an
-   omitted "align" argument means that the operation has the preferential
+   omitted align argument means that the operation has the preferential
    alignment for the target. It is the responsibility of the code emitter to
    ensure that the alignment information is correct. Overestimating the
-   alignment results in an undefined behavior. Underestimating the alignment may
+   alignment results in undefined behavior. Underestimating the alignment may
    produce less efficient code. An alignment of 1 is always safe.
    
 
+
    The optional !nontemporal metadata must reference a single
+   metatadata name <index> corresponding to a metadata node with
+   one i32 entry of value 1.  The existence of
+   the !nontemporal metatadata on the instruction tells the optimizer
+   and code generator that this load is not expected to be reused in the cache.
+   The code generator may select special instructions to save cache bandwidth,
+   such as the MOVNT instruction on x86.
    
+
 
    Semantics:
    
 
    The location of memory pointed to is loaded.  If the value being loaded is of
    scalar type then the number of bytes read does not exceed the minimum number
@@ -4037,8 +4322,8 @@ Instruction 
 
 
    Syntax:
    
 
    -  store <ty> <value>, <ty>* <pointer>[, align <alignment>]                   ; yields {void}
-  volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>]          ; yields {void}
+  store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]                   ; yields {void}
+  volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]          ; yields {void}
 
    
 
 
    Overview:
    
@@ -4049,11 +4334,10 @@ Instruction 
    and an address at which to store it.  The type of the
    '<pointer>' operand must be a pointer to
    the first class type of the
-   '<value>' operand. If the store is marked
-   as volatile, then the optimizer is not allowed to modify the number
-   or order of execution of this store with other
-   volatile load and store
-   instructions.
    
+   '<value>' operand. If the store is marked as
+   volatile, then the optimizer is not allowed to modify the number or
+   order of execution of this store with other volatile operations.
    
 
 
    The optional constant "align" argument specifies the alignment of the
    operation (that is, the alignment of the memory address). A value of 0 or an
@@ -4063,6 +4347,15 @@ Instruction 
    alignment results in an undefined behavior. Underestimating the alignment may
    produce less efficient code. An alignment of 1 is always safe.
    
 
+
    The optional !nontemporal metadata must reference a single metatadata
+   name <index> corresponding to a metadata node with one i32 entry of
+   value 1.  The existence of the !nontemporal metatadata on the
+   instruction tells the optimizer and code generator that this load is
+   not expected to be reused in the cache.  The code generator may
+   select special instructions to save cache bandwidth, such as the
+   MOVNT instruction on x86.
    
+
+
 
    Semantics:
    
 
    The contents of memory are updated to contain '<value>' at the
    location specified by the '<pointer>' operand.  If
@@ -4097,8 +4390,8 @@ Instruction 
 
 
    Overview:
    
 
    The 'getelementptr' instruction is used to get the address of a
-   subelement of an aggregate data structure. It performs address calculation
-   only and does not access memory.
    
+   subelement of an aggregate data structure.
+   It performs address calculation only and does not access memory.
    
 
 
    Arguments:
    
 
    The first argument is always a pointer, and forms the basis of the
@@ -4108,22 +4401,21 @@ Instruction 
    indexes the pointer value given as the first argument, the second index
    indexes a value of the type pointed to (not necessarily the value directly
    pointed to, since the first index can be non-zero), etc. The first type
-   indexed into must be a pointer value, subsequent types can be arrays, vectors
-   and structs. Note that subsequent types being indexed into can never be
-   pointers, since that would require loading the pointer before continuing
-   calculation.
    
+   indexed into must be a pointer value, subsequent types can be arrays,
+   vectors, and structs. Note that subsequent types being indexed into
+   can never be pointers, since that would require loading the pointer before
+   continuing calculation.
    
 
 
    The type of each index argument depends on the type it is indexing into.
-   When indexing into a (optionally packed) structure, only i32 integer
-   constants are allowed.  When indexing into an array, pointer or
-   vector, integers of any width are allowed, and they are not required to be
+   When indexing into a (optionally packed) structure, only i32
+   integer constants are allowed.  When indexing into an array, pointer
+   or vector, integers of any width are allowed, and they are not required to be
    constant.
    
 
 
    For example, let's consider a C code fragment and how it gets compiled to
    LLVM:
    
 
-
    
-
    +
     struct RT {
   char A;
   int B[10][20];
@@ -4139,12 +4431,10 @@ int *foo(struct ST *s) {
   return &s[1].Z.B[5][13];
 }
 
    
-
    
 
 
    The LLVM code generated by the GCC frontend is:
    
 
-
    
-
    +
     %RT = type { i8 , [10 x [20 x i32]], i8  }
 %ST = type { i32, double, %RT }
 
@@ -4154,7 +4444,6 @@ entry:
   ret i32* %reg
 }
 
    
-
    
 
 
    Semantics:
    
 
    In the example above, the first index is indexing into the '%ST*'
@@ -4183,13 +4472,14 @@ entry:
 
    
 
 
    If the inbounds keyword is present, the result value of the
-   getelementptr is undefined if the base pointer is not an
-   in bounds address of an allocated object, or if any of the addresses
-   that would be formed by successive addition of the offsets implied by the
-   indices to the base address with infinitely precise arithmetic are not an
-   in bounds address of that allocated object.
-   The in bounds addresses for an allocated object are all the addresses
-   that point into the object, plus the address one byte past the end.
    
+   getelementptr is a trap value if the
+   base pointer is not an in bounds address of an allocated object,
+   or if any of the addresses that would be formed by successive addition of
+   the offsets implied by the indices to the base address with infinitely
+   precise arithmetic are not an in bounds address of that allocated
+   object. The in bounds addresses for an allocated object are all
+   the addresses that point into the object, plus the address one byte past
+   the end.
    
 
 
    If the inbounds keyword is not present, the offsets are added to
    the base address with silently-wrapping two's complement arithmetic, and
@@ -4856,7 +5146,7 @@ entry:
       op1 is equal to op2.
 
   
  • ogt: yields true if both operands are not a QNAN and
-      op1 is greather than op2.
    • 
+      op1 is greater than op2.
 
   
  • oge: yields true if both operands are not a QNAN and
       op1 is greater than or equal to op2.
    • 
@@ -5024,15 +5314,18 @@ Loop:       ; Infinite loop that counts from 0 on up...
       a ret instruction.  If the "tail" marker is
       present, the function call is eligible for tail call optimization,
       but might not in fact be
-      optimized into a jump.  As of this writing, the extra requirements for
-      a call to actually be optimized are:
+      optimized into a jump.  The code generator may optimize calls marked
+      "tail" with either 1) automatic 
+      sibling call optimization when the caller and callee have
+      matching signatures, or 2) forced tail call optimization when the
+      following extra requirements are met:
       
      
         
    • Caller and callee both have the calling
             convention fastcc.
      • 
         
    • The call is in tail position (ret immediately follows call and ret
             uses value of call or is void).
      • 
         
    • Option -tailcallopt is enabled,
-            or llvm::PerformTailCallOpt is true.
      • 
+            or llvm::GuaranteedTailCallOpt is true.
         
    • Platform specific
             constraints are met.
      • 
       
    
@@ -5063,10 +5356,10 @@ Loop:       ; Infinite loop that counts from 0 on up...
       to function value.
 
   
  • 'function args': argument list whose types match the function
-      signature argument types. All arguments must be of
-      first class type. If the function signature
-      indicates the function accepts a variable number of arguments, the extra
-      arguments can be specified.
    • 
+      signature argument types and parameter attributes. All arguments must be
+      of first class type. If the function
+      signature indicates the function accepts a variable number of arguments,
+      the extra arguments can be specified.
 
   
  • The optional function attributes list. Only
       'noreturn', 'nounwind', 'readonly' and
@@ -5084,7 +5377,7 @@ Loop:       ; Infinite loop that counts from 0 on up...
 
    Example:
    
 
       %retval = call i32 @test(i32 %argc)
-  call i32 (i8 *, ...)* @printf(i8 * %msg, i32 12, i8 42)      ; yields i32
+  call i32 (i8*, ...)* @printf(i8* %msg, i32 12, i8 42)        ; yields i32
   %X = tail call i32 @foo()                                    ; yields i32
   %Y = tail call fastcc i32 @foo()  ; yields i32
   call void %foo(i8 97 signext)
@@ -5101,7 +5394,7 @@ Loop:       ; Infinite loop that counts from 0 on up...
 standard C99 library as being the C99 library functions, and may perform
 optimizations or generate code for them under that assumption.  This is
 something we'd like to change in the future to provide better support for
-freestanding environments and non-C-based langauges.
    
+freestanding environments and non-C-based languages.
    
 
 
 
@@ -5221,8 +5514,7 @@ freestanding environments and non-C-based langauges.
    
    instruction and the variable argument handling intrinsic functions are
    used.
    
 
-
    
-
    +
     define i32 @test(i32 %X, ...) {
   ; Initialize variable argument processing
   %ap = alloca i8*
@@ -5247,7 +5539,6 @@ declare void @llvm.va_start(i8*)
 declare void @llvm.va_copy(i8*, i8*)
 declare void @llvm.va_end(i8*)
 
    
-
    
 
 
 
@@ -5517,7 +5808,7 @@ LLVM.
    
 
 
    Syntax:
    
 
    -  declare i8 *@llvm.frameaddress(i32 <level>)
+  declare i8* @llvm.frameaddress(i32 <level>)
 
    
 
 
    Overview:
    
@@ -5551,7 +5842,7 @@ LLVM.
    
 
 
    Syntax:
    
 
    -  declare i8 *@llvm.stacksave()
+  declare i8* @llvm.stacksave()
 
    
 
 
    Overview:
    
@@ -5581,7 +5872,7 @@ LLVM.
    
 
 
    Syntax:
    
 
    -  declare void @llvm.stackrestore(i8 * %ptr)
+  declare void @llvm.stackrestore(i8* %ptr)
 
    
 
 
    Overview:
    
@@ -5657,7 +5948,7 @@ LLVM.
    
 
 
    Semantics:
    
 
    This intrinsic does not modify the behavior of the program.  Backends that do
-   not support this intrinisic may ignore it.
    
+   not support this intrinsic may ignore it.
    
 
 
 
@@ -5670,7 +5961,7 @@ LLVM.
    
 
 
    Syntax:
    
 
    -  declare i64 @llvm.readcyclecounter( )
+  declare i64 @llvm.readcyclecounter()
 
    
 
 
    Overview:
    
@@ -5711,17 +6002,14 @@ LLVM.
    
 
 
    Syntax:
    
 
    This is an overloaded intrinsic. You can use llvm.memcpy on any
-   integer bit width. Not all targets support all bit widths however.
    
+   integer bit width and for different address spaces. Not all targets support
+   all bit widths however.
    
 
 
    -  declare void @llvm.memcpy.i8(i8 * <dest>, i8 * <src>,
-                               i8 <len>, i32 <align>)
-  declare void @llvm.memcpy.i16(i8 * <dest>, i8 * <src>,
-                                i16 <len>, i32 <align>)
-  declare void @llvm.memcpy.i32(i8 * <dest>, i8 * <src>,
-                                i32 <len>, i32 <align>)
-  declare void @llvm.memcpy.i64(i8 * <dest>, i8 * <src>,
-                                i64 <len>, i32 <align>)
+  declare void @llvm.memcpy.p0i8.p0i8.i32(i8* <dest>, i8* <src>,
+                                          i32 <len>, i32 <align>, i1 <isvolatile>)
+  declare void @llvm.memcpy.p0i8.p0i8.i64(i8* <dest>, i8* <src>,
+                                          i64 <len>, i32 <align>, i1 <isvolatile>)
 
    
 
 
    Overview:
    
@@ -5729,19 +6017,28 @@ LLVM.
    
    source location to the destination location.
    
 
 
    Note that, unlike the standard libc function, the llvm.memcpy.*
-   intrinsics do not return a value, and takes an extra alignment argument.
    
+   intrinsics do not return a value, takes extra alignment/isvolatile arguments
+   and the pointers can be in specified address spaces.
    
 
 
    Arguments:
    
+
 
    The first argument is a pointer to the destination, the second is a pointer
    to the source.  The third argument is an integer argument specifying the
-   number of bytes to copy, and the fourth argument is the alignment of the
-   source and destination locations.
    
+   number of bytes to copy, the fourth argument is the alignment of the
+   source and destination locations, and the fifth is a boolean indicating a
+   volatile access.
    
 
-
    If the call to this intrinisic has an alignment value that is not 0 or 1,
+
    If the call to this intrinsic has an alignment value that is not 0 or 1,
    then the caller guarantees that both the source and destination pointers are
    aligned to that boundary.
    
 
+
    If the isvolatile parameter is true, the
+   llvm.memcpy call is a volatile operation.
+   The detailed access behavior is not very cleanly specified and it is unwise
+   to depend on it.
    
+
 
    Semantics:
    
+
 
    The 'llvm.memcpy.*' intrinsics copy a block of memory from the
    source location to the destination location, which are not allowed to
    overlap.  It copies "len" bytes of memory over.  If the argument is known to
@@ -5759,17 +6056,14 @@ LLVM.
    
 
 
    Syntax:
    
 
    This is an overloaded intrinsic. You can use llvm.memmove on any integer bit
-   width. Not all targets support all bit widths however.
    
+   width and for different address space. Not all targets support all bit
+   widths however.
    
 
 
    -  declare void @llvm.memmove.i8(i8 * <dest>, i8 * <src>,
-                                i8 <len>, i32 <align>)
-  declare void @llvm.memmove.i16(i8 * <dest>, i8 * <src>,
-                                 i16 <len>, i32 <align>)
-  declare void @llvm.memmove.i32(i8 * <dest>, i8 * <src>,
-                                 i32 <len>, i32 <align>)
-  declare void @llvm.memmove.i64(i8 * <dest>, i8 * <src>,
-                                 i64 <len>, i32 <align>)
+  declare void @llvm.memmove.p0i8.p0i8.i32(i8* <dest>, i8* <src>,
+                                           i32 <len>, i32 <align>, i1 <isvolatile>)
+  declare void @llvm.memmove.p0i8.p0i8.i64(i8* <dest>, i8* <src>,
+                                           i64 <len>, i32 <align>, i1 <isvolatile>)
 
    
 
 
    Overview:
    
@@ -5779,19 +6073,28 @@ LLVM.
    
    overlap.
    
 
 
    Note that, unlike the standard libc function, the llvm.memmove.*
-   intrinsics do not return a value, and takes an extra alignment argument.
    
+   intrinsics do not return a value, takes extra alignment/isvolatile arguments
+   and the pointers can be in specified address spaces.
    
 
 
    Arguments:
    
+
 
    The first argument is a pointer to the destination, the second is a pointer
    to the source.  The third argument is an integer argument specifying the
-   number of bytes to copy, and the fourth argument is the alignment of the
-   source and destination locations.
    
+   number of bytes to copy, the fourth argument is the alignment of the
+   source and destination locations, and the fifth is a boolean indicating a
+   volatile access.
    
 
-
    If the call to this intrinisic has an alignment value that is not 0 or 1,
+
    If the call to this intrinsic has an alignment value that is not 0 or 1,
    then the caller guarantees that the source and destination pointers are
    aligned to that boundary.
    
 
+
    If the isvolatile parameter is true, the
+   llvm.memmove call is a volatile operation.
+   The detailed access behavior is not very cleanly specified and it is unwise
+   to depend on it.
    
+
 
    Semantics:
    
+
 
    The 'llvm.memmove.*' intrinsics copy a block of memory from the
    source location to the destination location, which may overlap.  It copies
    "len" bytes of memory over.  If the argument is known to be aligned to some
@@ -5809,17 +6112,14 @@ LLVM.
    
 
 
    Syntax:
    
 
    This is an overloaded intrinsic. You can use llvm.memset on any integer bit
-   width. Not all targets support all bit widths however.
    
+   width and for different address spaces. However, not all targets support all
+   bit widths.
    
 
 
    -  declare void @llvm.memset.i8(i8 * <dest>, i8 <val>,
-                               i8 <len>, i32 <align>)
-  declare void @llvm.memset.i16(i8 * <dest>, i8 <val>,
-                                i16 <len>, i32 <align>)
-  declare void @llvm.memset.i32(i8 * <dest>, i8 <val>,
-                                i32 <len>, i32 <align>)
-  declare void @llvm.memset.i64(i8 * <dest>, i8 <val>,
-                                i64 <len>, i32 <align>)
+  declare void @llvm.memset.p0i8.i32(i8* <dest>, i8 <val>,
+                                     i32 <len>, i32 <align>, i1 <isvolatile>)
+  declare void @llvm.memset.p0i8.i64(i8* <dest>, i8 <val>,
+                                     i64 <len>, i32 <align>, i1 <isvolatile>)
 
    
 
 
    Overview:
    
@@ -5827,18 +6127,24 @@ LLVM.
    
    particular byte value.
    
 
 
    Note that, unlike the standard libc function, the llvm.memset
-   intrinsic does not return a value, and takes an extra alignment argument.
    
+   intrinsic does not return a value and takes extra alignment/volatile
+   arguments.  Also, the destination can be in an arbitrary address space.
    
 
 
    Arguments:
    
 
    The first argument is a pointer to the destination to fill, the second is the
-   byte value to fill it with, the third argument is an integer argument
+   byte value with which to fill it, the third argument is an integer argument
    specifying the number of bytes to fill, and the fourth argument is the known
-   alignment of destination location.
    
+   alignment of the destination location.
    
 
-
    If the call to this intrinisic has an alignment value that is not 0 or 1,
+
    If the call to this intrinsic has an alignment value that is not 0 or 1,
    then the caller guarantees that the destination pointer is aligned to that
    boundary.
    
 
+
    If the isvolatile parameter is true, the
+   llvm.memset call is a volatile operation.
+   The detailed access behavior is not very cleanly specified and it is unwise
+   to depend on it.
    
+
 
    Semantics:
    
 
    The 'llvm.memset.*' intrinsics fill "len" bytes of memory starting
    at the destination location.  If the argument is known to be aligned to some
@@ -6458,6 +6764,97 @@ LLVM.
    
 
 
 
+
+
    
+  Half Precision Floating Point Intrinsics
+
    
+
+
    
+
+
    Half precision floating point is a storage-only format. This means that it is
+   a dense encoding (in memory) but does not support computation in the
+   format.
    
+   
+
    This means that code must first load the half-precision floating point
+   value as an i16, then convert it to float with llvm.convert.from.fp16.
+   Computation can then be performed on the float value (including extending to
+   double etc).  To store the value back to memory, it is first converted to
+   float if needed, then converted to i16 with
+   llvm.convert.to.fp16, then
+   storing as an i16 value.
    
+
    
+
+
+
    
+  'llvm.convert.to.fp16' Intrinsic
+
    
+
+
    
+
+
    Syntax:
    
+
    +  declare i16 @llvm.convert.to.fp16(f32 %a)
+
    
+
+
    Overview:
    
+
    The 'llvm.convert.to.fp16' intrinsic function performs
+   a conversion from single precision floating point format to half precision
+   floating point format.
    
+
+
    Arguments:
    
+
    The intrinsic function contains single argument - the value to be
+   converted.
    
+
+
    Semantics:
    
+
    The 'llvm.convert.to.fp16' intrinsic function performs
+   a conversion from single precision floating point format to half precision
+   floating point format. The return value is an i16 which
+   contains the converted number.
    
+
+
    Examples:
    
+
    +  %res = call i16 @llvm.convert.to.fp16(f32 %a)
+  store i16 %res, i16* @x, align 2
+
    
+
+
    
+
+
+
    
+ 'llvm.convert.from.fp16' Intrinsic
+
    
+
+
    
+
+
    Syntax:
    
+
    +  declare f32 @llvm.convert.from.fp16(i16 %a)
+
    
+
+
    Overview:
    
+
    The 'llvm.convert.from.fp16' intrinsic function performs
+   a conversion from half precision floating point format to single precision
+   floating point format.
    
+
+
    Arguments:
    
+
    The intrinsic function contains single argument - the value to be
+   converted.
    
+
+
    Semantics:
    
+
    The 'llvm.convert.from.fp16' intrinsic function performs a
+   conversion from half single precision floating point format to single
+   precision floating point format. The input half-float value is represented by
+   an i16 value.
    
+
+
    Examples:
    
+
    +  %a = load i16* @x, align 2
+  %res = call f32 @llvm.convert.from.fp16(i16 %a)
+
    
+
+
    
+
 
 
    
   Debugger Intrinsics
@@ -6494,7 +6891,8 @@ LLVM.
    
 
    
 
 
    This intrinsic makes it possible to excise one parameter, marked with
-   the nest attribute, from a function.  The result is a callable
+   the nest attribute, from a function.
+   The result is a callable
    function pointer lacking the nest parameter - the caller does not need to
    provide a value for it.  Instead, the value to use is stored in advance in a
    "trampoline", a block of memory usually allocated on the stack, which also
@@ -6506,17 +6904,15 @@ LLVM.
    
    pointer has signature i32 (i32, i32)*.  It can be created as
    follows:
    
 
-
    
-
    +
       %tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86
   %tramp1 = getelementptr [10 x i8]* %tramp, i32 0, i32 0
-  %p = call i8* @llvm.init.trampoline( i8* %tramp1, i8* bitcast (i32 (i8* nest , i32, i32)* @f to i8*), i8* %nval )
+  %p = call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8* nest , i32, i32)* @f to i8*), i8* %nval)
   %fp = bitcast i8* %p to i32 (i32, i32)*
 
    
-
    
 
-
    The call %val = call i32 %fp( i32 %x, i32 %y ) is then equivalent
-   to %val = call i32 %f( i8* %nval, i32 %x, i32 %y ).
    
+
    The call %val = call i32 %fp(i32 %x, i32 %y) is then equivalent
+   to %val = call i32 %f(i8* %nval, i32 %x, i32 %y).
    
 
 
    
 
@@ -6596,7 +6992,7 @@ LLVM.
    
 
    
 
    Syntax:
    
 
    -  declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device> )
+  declare void @llvm.memory.barrier(i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device>)
 
    
 
 
    Overview:
    
@@ -6606,7 +7002,7 @@ LLVM.
    
 
    Arguments:
    
 
    The llvm.memory.barrier intrinsic requires five boolean arguments.
    The first four arguments enables a specific barrier as listed below.  The
-   fith argument specifies that the barrier applies to io or device or uncached
+   fifth argument specifies that the barrier applies to io or device or uncached
    memory.
    
 
 
      
@@ -6653,7 +7049,7 @@ LLVM.
      
             store i32 4, %ptr
 
 %result1  = load i32* %ptr      ; yields {i32}:result1 = 4
-            call void @llvm.memory.barrier( i1 false, i1 true, i1 false, i1 false )
+            call void @llvm.memory.barrier(i1 false, i1 true, i1 false, i1 false)
                                 ; guarantee the above finishes
             store i32 8, %ptr   ; before this begins
 
    
@@ -6673,10 +7069,10 @@ LLVM.
    
    support all bit widths however.
    
 
 
    -  declare i8 @llvm.atomic.cmp.swap.i8.p0i8( i8* <ptr>, i8 <cmp>, i8 <val> )
-  declare i16 @llvm.atomic.cmp.swap.i16.p0i16( i16* <ptr>, i16 <cmp>, i16 <val> )
-  declare i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* <ptr>, i32 <cmp>, i32 <val> )
-  declare i64 @llvm.atomic.cmp.swap.i64.p0i64( i64* <ptr>, i64 <cmp>, i64 <val> )
+  declare i8 @llvm.atomic.cmp.swap.i8.p0i8(i8* <ptr>, i8 <cmp>, i8 <val>)
+  declare i16 @llvm.atomic.cmp.swap.i16.p0i16(i16* <ptr>, i16 <cmp>, i16 <val>)
+  declare i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* <ptr>, i32 <cmp>, i32 <val>)
+  declare i64 @llvm.atomic.cmp.swap.i64.p0i64(i64* <ptr>, i64 <cmp>, i64 <val>)
 
    
 
 
    Overview:
    
@@ -6705,13 +7101,13 @@ LLVM.
    
             store i32 4, %ptr
 
 %val1     = add i32 4, 4
-%result1  = call i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* %ptr, i32 4, %val1 )
+%result1  = call i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* %ptr, i32 4, %val1)
                                           ; yields {i32}:result1 = 4
 %stored1  = icmp eq i32 %result1, 4       ; yields {i1}:stored1 = true
 %memval1  = load i32* %ptr                ; yields {i32}:memval1 = 8
 
 %val2     = add i32 1, 1
-%result2  = call i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* %ptr, i32 5, %val2 )
+%result2  = call i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* %ptr, i32 5, %val2)
                                           ; yields {i32}:result2 = 8
 %stored2  = icmp eq i32 %result2, 5       ; yields {i1}:stored2 = false
 
@@ -6731,10 +7127,10 @@ LLVM.
    
    integer bit width. Not all targets support all bit widths however.
    
 
 
    -  declare i8 @llvm.atomic.swap.i8.p0i8( i8* <ptr>, i8 <val> )
-  declare i16 @llvm.atomic.swap.i16.p0i16( i16* <ptr>, i16 <val> )
-  declare i32 @llvm.atomic.swap.i32.p0i32( i32* <ptr>, i32 <val> )
-  declare i64 @llvm.atomic.swap.i64.p0i64( i64* <ptr>, i64 <val> )
+  declare i8 @llvm.atomic.swap.i8.p0i8(i8* <ptr>, i8 <val>)
+  declare i16 @llvm.atomic.swap.i16.p0i16(i16* <ptr>, i16 <val>)
+  declare i32 @llvm.atomic.swap.i32.p0i32(i32* <ptr>, i32 <val>)
+  declare i64 @llvm.atomic.swap.i64.p0i64(i64* <ptr>, i64 <val>)
 
    
 
 
    Overview:
    
@@ -6761,13 +7157,13 @@ LLVM.
    
             store i32 4, %ptr
 
 %val1     = add i32 4, 4
-%result1  = call i32 @llvm.atomic.swap.i32.p0i32( i32* %ptr, i32 %val1 )
+%result1  = call i32 @llvm.atomic.swap.i32.p0i32(i32* %ptr, i32 %val1)
                                         ; yields {i32}:result1 = 4
 %stored1  = icmp eq i32 %result1, 4     ; yields {i1}:stored1 = true
 %memval1  = load i32* %ptr              ; yields {i32}:memval1 = 8
 
 %val2     = add i32 1, 1
-%result2  = call i32 @llvm.atomic.swap.i32.p0i32( i32* %ptr, i32 %val2 )
+%result2  = call i32 @llvm.atomic.swap.i32.p0i32(i32* %ptr, i32 %val2)
                                         ; yields {i32}:result2 = 8
 
 %stored2  = icmp eq i32 %result2, 8     ; yields {i1}:stored2 = true
@@ -6789,10 +7185,10 @@ LLVM.
    
    any integer bit width. Not all targets support all bit widths however.
    
 
 
    -  declare i8 @llvm.atomic.load.add.i8..p0i8( i8* <ptr>, i8 <delta> )
-  declare i16 @llvm.atomic.load.add.i16..p0i16( i16* <ptr>, i16 <delta> )
-  declare i32 @llvm.atomic.load.add.i32..p0i32( i32* <ptr>, i32 <delta> )
-  declare i64 @llvm.atomic.load.add.i64..p0i64( i64* <ptr>, i64 <delta> )
+  declare i8 @llvm.atomic.load.add.i8.p0i8(i8* <ptr>, i8 <delta>)
+  declare i16 @llvm.atomic.load.add.i16.p0i16(i16* <ptr>, i16 <delta>)
+  declare i32 @llvm.atomic.load.add.i32.p0i32(i32* <ptr>, i32 <delta>)
+  declare i64 @llvm.atomic.load.add.i64.p0i64(i64* <ptr>, i64 <delta>)
 
    
 
 
    Overview:
    
@@ -6815,11 +7211,11 @@ LLVM.
    
 %mallocP  = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
 %ptr      = bitcast i8* %mallocP to i32*
             store i32 4, %ptr
-%result1  = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 4 )
+%result1  = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 4)
                                 ; yields {i32}:result1 = 4
-%result2  = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 2 )
+%result2  = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 2)
                                 ; yields {i32}:result2 = 8
-%result3  = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 5 )
+%result3  = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 5)
                                 ; yields {i32}:result3 = 10
 %memval1  = load i32* %ptr      ; yields {i32}:memval1 = 15
    • @@ -6840,10 +7236,10 @@ LLVM.

    support all bit widths however.

    -  declare i8 @llvm.atomic.load.sub.i8.p0i32( i8* <ptr>, i8 <delta> )
-  declare i16 @llvm.atomic.load.sub.i16.p0i32( i16* <ptr>, i16 <delta> )
-  declare i32 @llvm.atomic.load.sub.i32.p0i32( i32* <ptr>, i32 <delta> )
-  declare i64 @llvm.atomic.load.sub.i64.p0i32( i64* <ptr>, i64 <delta> )
+  declare i8 @llvm.atomic.load.sub.i8.p0i32(i8* <ptr>, i8 <delta>)
+  declare i16 @llvm.atomic.load.sub.i16.p0i32(i16* <ptr>, i16 <delta>)
+  declare i32 @llvm.atomic.load.sub.i32.p0i32(i32* <ptr>, i32 <delta>)
+  declare i64 @llvm.atomic.load.sub.i64.p0i32(i64* <ptr>, i64 <delta>)
    Overview:
    @@ -6867,11 +7263,11 @@ LLVM.

    %mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) %ptr = bitcast i8* %mallocP to i32* store i32 8, %ptr -%result1 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 4 ) +%result1 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 4) ; yields {i32}:result1 = 8 -%result2 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 2 ) +%result2 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 2) ; yields {i32}:result2 = 4 -%result3 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 5 ) +%result3 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 5) ; yields {i32}:result3 = 2 %memval1 = load i32* %ptr ; yields {i32}:memval1 = -3 @@ -6896,31 +7292,31 @@ LLVM.

    widths however.

    -  declare i8 @llvm.atomic.load.and.i8.p0i8( i8* <ptr>, i8 <delta> )
-  declare i16 @llvm.atomic.load.and.i16.p0i16( i16* <ptr>, i16 <delta> )
-  declare i32 @llvm.atomic.load.and.i32.p0i32( i32* <ptr>, i32 <delta> )
-  declare i64 @llvm.atomic.load.and.i64.p0i64( i64* <ptr>, i64 <delta> )
+  declare i8 @llvm.atomic.load.and.i8.p0i8(i8* <ptr>, i8 <delta>)
+  declare i16 @llvm.atomic.load.and.i16.p0i16(i16* <ptr>, i16 <delta>)
+  declare i32 @llvm.atomic.load.and.i32.p0i32(i32* <ptr>, i32 <delta>)
+  declare i64 @llvm.atomic.load.and.i64.p0i64(i64* <ptr>, i64 <delta>)
 
    -  declare i8 @llvm.atomic.load.or.i8.p0i8( i8* <ptr>, i8 <delta> )
-  declare i16 @llvm.atomic.load.or.i16.p0i16( i16* <ptr>, i16 <delta> )
-  declare i32 @llvm.atomic.load.or.i32.p0i32( i32* <ptr>, i32 <delta> )
-  declare i64 @llvm.atomic.load.or.i64.p0i64( i64* <ptr>, i64 <delta> )
+  declare i8 @llvm.atomic.load.or.i8.p0i8(i8* <ptr>, i8 <delta>)
+  declare i16 @llvm.atomic.load.or.i16.p0i16(i16* <ptr>, i16 <delta>)
+  declare i32 @llvm.atomic.load.or.i32.p0i32(i32* <ptr>, i32 <delta>)
+  declare i64 @llvm.atomic.load.or.i64.p0i64(i64* <ptr>, i64 <delta>)
 
    -  declare i8 @llvm.atomic.load.nand.i8.p0i32( i8* <ptr>, i8 <delta> )
-  declare i16 @llvm.atomic.load.nand.i16.p0i32( i16* <ptr>, i16 <delta> )
-  declare i32 @llvm.atomic.load.nand.i32.p0i32( i32* <ptr>, i32 <delta> )
-  declare i64 @llvm.atomic.load.nand.i64.p0i32( i64* <ptr>, i64 <delta> )
+  declare i8 @llvm.atomic.load.nand.i8.p0i32(i8* <ptr>, i8 <delta>)
+  declare i16 @llvm.atomic.load.nand.i16.p0i32(i16* <ptr>, i16 <delta>)
+  declare i32 @llvm.atomic.load.nand.i32.p0i32(i32* <ptr>, i32 <delta>)
+  declare i64 @llvm.atomic.load.nand.i64.p0i32(i64* <ptr>, i64 <delta>)
 
    -  declare i8 @llvm.atomic.load.xor.i8.p0i32( i8* <ptr>, i8 <delta> )
-  declare i16 @llvm.atomic.load.xor.i16.p0i32( i16* <ptr>, i16 <delta> )
-  declare i32 @llvm.atomic.load.xor.i32.p0i32( i32* <ptr>, i32 <delta> )
-  declare i64 @llvm.atomic.load.xor.i64.p0i32( i64* <ptr>, i64 <delta> )
+  declare i8 @llvm.atomic.load.xor.i8.p0i32(i8* <ptr>, i8 <delta>)
+  declare i16 @llvm.atomic.load.xor.i16.p0i32(i16* <ptr>, i16 <delta>)
+  declare i32 @llvm.atomic.load.xor.i32.p0i32(i32* <ptr>, i32 <delta>)
+  declare i64 @llvm.atomic.load.xor.i64.p0i32(i64* <ptr>, i64 <delta>)
    Overview:
    @@ -6945,13 +7341,13 @@ LLVM.

    %mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) %ptr = bitcast i8* %mallocP to i32* store i32 0x0F0F, %ptr -%result0 = call i32 @llvm.atomic.load.nand.i32.p0i32( i32* %ptr, i32 0xFF ) +%result0 = call i32 @llvm.atomic.load.nand.i32.p0i32(i32* %ptr, i32 0xFF) ; yields {i32}:result0 = 0x0F0F -%result1 = call i32 @llvm.atomic.load.and.i32.p0i32( i32* %ptr, i32 0xFF ) +%result1 = call i32 @llvm.atomic.load.and.i32.p0i32(i32* %ptr, i32 0xFF) ; yields {i32}:result1 = 0xFFFFFFF0 -%result2 = call i32 @llvm.atomic.load.or.i32.p0i32( i32* %ptr, i32 0F ) +%result2 = call i32 @llvm.atomic.load.or.i32.p0i32(i32* %ptr, i32 0F) ; yields {i32}:result2 = 0xF0 -%result3 = call i32 @llvm.atomic.load.xor.i32.p0i32( i32* %ptr, i32 0F ) +%result3 = call i32 @llvm.atomic.load.xor.i32.p0i32(i32* %ptr, i32 0F) ; yields {i32}:result3 = FF %memval1 = load i32* %ptr ; yields {i32}:memval1 = F0 @@ -6975,31 +7371,31 @@ LLVM.

    address spaces. Not all targets support all bit widths however.

    -  declare i8 @llvm.atomic.load.max.i8.p0i8( i8* <ptr>, i8 <delta> )
-  declare i16 @llvm.atomic.load.max.i16.p0i16( i16* <ptr>, i16 <delta> )
-  declare i32 @llvm.atomic.load.max.i32.p0i32( i32* <ptr>, i32 <delta> )
-  declare i64 @llvm.atomic.load.max.i64.p0i64( i64* <ptr>, i64 <delta> )
+  declare i8 @llvm.atomic.load.max.i8.p0i8(i8* <ptr>, i8 <delta>)
+  declare i16 @llvm.atomic.load.max.i16.p0i16(i16* <ptr>, i16 <delta>)
+  declare i32 @llvm.atomic.load.max.i32.p0i32(i32* <ptr>, i32 <delta>)
+  declare i64 @llvm.atomic.load.max.i64.p0i64(i64* <ptr>, i64 <delta>)
 
    -  declare i8 @llvm.atomic.load.min.i8.p0i8( i8* <ptr>, i8 <delta> )
-  declare i16 @llvm.atomic.load.min.i16.p0i16( i16* <ptr>, i16 <delta> )
-  declare i32 @llvm.atomic.load.min.i32..p0i32( i32* <ptr>, i32 <delta> )
-  declare i64 @llvm.atomic.load.min.i64..p0i64( i64* <ptr>, i64 <delta> )
+  declare i8 @llvm.atomic.load.min.i8.p0i8(i8* <ptr>, i8 <delta>)
+  declare i16 @llvm.atomic.load.min.i16.p0i16(i16* <ptr>, i16 <delta>)
+  declare i32 @llvm.atomic.load.min.i32.p0i32(i32* <ptr>, i32 <delta>)
+  declare i64 @llvm.atomic.load.min.i64.p0i64(i64* <ptr>, i64 <delta>)
 
    -  declare i8 @llvm.atomic.load.umax.i8.p0i8( i8* <ptr>, i8 <delta> )
-  declare i16 @llvm.atomic.load.umax.i16.p0i16( i16* <ptr>, i16 <delta> )
-  declare i32 @llvm.atomic.load.umax.i32.p0i32( i32* <ptr>, i32 <delta> )
-  declare i64 @llvm.atomic.load.umax.i64.p0i64( i64* <ptr>, i64 <delta> )
+  declare i8 @llvm.atomic.load.umax.i8.p0i8(i8* <ptr>, i8 <delta>)
+  declare i16 @llvm.atomic.load.umax.i16.p0i16(i16* <ptr>, i16 <delta>)
+  declare i32 @llvm.atomic.load.umax.i32.p0i32(i32* <ptr>, i32 <delta>)
+  declare i64 @llvm.atomic.load.umax.i64.p0i64(i64* <ptr>, i64 <delta>)
 
    -  declare i8 @llvm.atomic.load.umin.i8..p0i8( i8* <ptr>, i8 <delta> )
-  declare i16 @llvm.atomic.load.umin.i16.p0i16( i16* <ptr>, i16 <delta> )
-  declare i32 @llvm.atomic.load.umin.i32..p0i32( i32* <ptr>, i32 <delta> )
-  declare i64 @llvm.atomic.load.umin.i64..p0i64( i64* <ptr>, i64 <delta> )
+  declare i8 @llvm.atomic.load.umin.i8.p0i8(i8* <ptr>, i8 <delta>)
+  declare i16 @llvm.atomic.load.umin.i16.p0i16(i16* <ptr>, i16 <delta>)
+  declare i32 @llvm.atomic.load.umin.i32.p0i32(i32* <ptr>, i32 <delta>)
+  declare i64 @llvm.atomic.load.umin.i64.p0i64(i64* <ptr>, i64 <delta>)
    Overview:
    @@ -7024,13 +7420,13 @@ LLVM.

    %mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32)) %ptr = bitcast i8* %mallocP to i32* store i32 7, %ptr -%result0 = call i32 @llvm.atomic.load.min.i32.p0i32( i32* %ptr, i32 -2 ) +%result0 = call i32 @llvm.atomic.load.min.i32.p0i32(i32* %ptr, i32 -2) ; yields {i32}:result0 = 7 -%result1 = call i32 @llvm.atomic.load.max.i32.p0i32( i32* %ptr, i32 8 ) +%result1 = call i32 @llvm.atomic.load.max.i32.p0i32(i32* %ptr, i32 8) ; yields {i32}:result1 = -2 -%result2 = call i32 @llvm.atomic.load.umin.i32.p0i32( i32* %ptr, i32 10 ) +%result2 = call i32 @llvm.atomic.load.umin.i32.p0i32(i32* %ptr, i32 10) ; yields {i32}:result2 = 8 -%result3 = call i32 @llvm.atomic.load.umax.i32.p0i32( i32* %ptr, i32 30 ) +%result3 = call i32 @llvm.atomic.load.umax.i32.p0i32(i32* %ptr, i32 30) ; yields {i32}:result3 = 8 %memval1 = load i32* %ptr ; yields {i32}:memval1 = 30 @@ -7118,7 +7514,7 @@ LLVM.

    Syntax:
    -  declare {}* @llvm.invariant.start(i64 <size>, i8* nocapture <ptr>) readonly
+  declare {}* @llvm.invariant.start(i64 <size>, i8* nocapture <ptr>)
    Overview:
    @@ -7185,7 +7581,7 @@ LLVM.

    Syntax:
    -  declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32  <int> )
+  declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32  <int>)
    Overview:
    @@ -7216,11 +7612,11 @@ LLVM.

    any integer bit width.

    -  declare i8 @llvm.annotation.i8(i8 <val>, i8* <str>, i8* <str>, i32  <int> )
-  declare i16 @llvm.annotation.i16(i16 <val>, i8* <str>, i8* <str>, i32  <int> )
-  declare i32 @llvm.annotation.i32(i32 <val>, i8* <str>, i8* <str>, i32  <int> )
-  declare i64 @llvm.annotation.i64(i64 <val>, i8* <str>, i8* <str>, i32  <int> )
-  declare i256 @llvm.annotation.i256(i256 <val>, i8* <str>, i8* <str>, i32  <int> )
+  declare i8 @llvm.annotation.i8(i8 <val>, i8* <str>, i8* <str>, i32  <int>)
+  declare i16 @llvm.annotation.i16(i16 <val>, i8* <str>, i8* <str>, i32  <int>)
+  declare i32 @llvm.annotation.i32(i32 <val>, i8* <str>, i8* <str>, i32  <int>)
+  declare i64 @llvm.annotation.i64(i64 <val>, i8* <str>, i8* <str>, i32  <int>)
+  declare i256 @llvm.annotation.i256(i256 <val>, i8* <str>, i8* <str>, i32  <int>)
    Overview:
    @@ -7274,7 +7670,7 @@ LLVM.

    Syntax:
    -  declare void @llvm.stackprotector( i8* <guard>, i8** <slot> )
+  declare void @llvm.stackprotector(i8* <guard>, i8** <slot>)
    Overview:
    @@ -7293,7 +7689,7 @@ LLVM.

    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 + the guard on the stack is checked against the original guard. If they are different, then the program aborts by calling the __stack_chk_fail() function.

    @@ -7308,30 +7704,29 @@ LLVM.

    Syntax:
    -  declare i32 @llvm.objectsize.i32( i8* <object>, i1 <type> )
-  declare i64 @llvm.objectsize.i64( i8* <object>, i1 <type> )
+  declare i32 @llvm.objectsize.i32(i8* <object>, i1 <type>)
+  declare i64 @llvm.objectsize.i64(i8* <object>, i1 <type>)
    Overview:
    -

    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.objectsize intrinsic is designed to provide information to + the optimizers to determine at compile time whether a) an operation (like + memcpy) will overflow a buffer that corresponds to an object, or b) that a + runtime check for overflow isn't necessary. An object in this context means + an allocation of a specific class, structure, array, or other object.

    Arguments:
    -

    The llvm.objectsize intrinsic takes two arguments. The first +

    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 + is a boolean 0 or 1. This argument determines whether you want the + maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or 1, variables are not allowed.

    Semantics:

    The llvm.objectsize intrinsic is lowered to either a constant - representing the size of the object concerned or i32/i64 -1 or 0 - (depending on the type argument if the size cannot be determined - at compile time.

    + 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.