X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.html;h=1b94ab5a9a705faa034ac9f76a3faac702937e03;hb=83821c8941b7e9e70de9d5e76556b07872ac371b;hp=73ee31b3245220b1d4e00729c32fa95448090f01;hpb=8d33659b93f8136505b89a34dcbc350c1ac4654d;p=oota-llvm.git diff --git a/docs/LangRef.html b/docs/LangRef.html index 73ee31b3245..1b94ab5a9a7 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -5,7 +5,7 @@ LLVM Assembly Language Reference Manual - @@ -43,6 +43,7 @@
  • Global Variables
  • Functions
  • Aliases
  • +
  • Named Metadata
  • Parameter Attributes
  • Function Attributes
  • Garbage Collector Names
  • @@ -54,7 +55,7 @@
  • Type System
    1. Type Classifications
    2. -
    3. Primitive Types +
    4. Primitive Types
      1. Integer Type
      2. Floating Point Types
      3. @@ -65,12 +66,17 @@
      4. Derived Types
          -
        1. Array Type
        2. +
        3. Aggregate Types +
            +
          1. Array Type
          2. +
          3. Structure Type
          4. +
          5. Packed Structure Type
          6. +
          7. Union Type
          8. +
          9. Vector Type
          10. +
          +
        4. Function Type
        5. Pointer Type
        6. -
        7. Structure Type
        8. -
        9. Packed Structure Type
        10. -
        11. Vector Type
        12. Opaque Type
      5. @@ -83,13 +89,14 @@
      6. Complex Constants
      7. Global Variable and Function Addresses
      8. Undefined Values
      9. +
      10. Addresses of Basic Blocks
      11. Constant Expressions
      12. -
      13. Embedded Metadata
    5. Other Values
      1. Inline Assembler Expressions
      2. +
      3. Metadata Nodes and Metadata Strings
    6. Intrinsic Global Variables @@ -110,6 +117,7 @@
    7. 'ret' Instruction
    8. 'br' Instruction
    9. 'switch' Instruction
    10. +
    11. 'indirectbr' Instruction
    12. 'invoke' Instruction
    13. 'unwind' Instruction
    14. 'unreachable' Instruction
    15. @@ -247,6 +255,12 @@
    16. 'llvm.umul.with.overflow.* Intrinsics
  • +
  • Half Precision Floating Point Intrinsics +
      +
    1. 'llvm.convert.to.fp16' Intrinsic
    2. +
    3. 'llvm.convert.from.fp16' Intrinsic
    4. +
    +
  • Debugger intrinsics
  • Exception Handling intrinsics
  • Trampoline Intrinsic @@ -289,6 +303,8 @@ 'llvm.trap' Intrinsic
  • 'llvm.stackprotector' Intrinsic
  • +
  • + 'llvm.objectsize' Intrinsic
  • @@ -336,7 +352,7 @@ IR's", allowing many source languages to be mapped to them). By providing type information, LLVM can be used as the target of optimizations: for example, through pointer analysis, it can be proven that a C automatic - variable is never accessed outside of the current function... allowing it to + variable is never accessed outside of the current function, allowing it to be promoted to a simple SSA value instead of a memory location.

    @@ -357,12 +373,12 @@ -

    ...because the definition of %x does not dominate all of its - uses. The LLVM infrastructure provides a verification pass that may be used - to verify that an LLVM module is well formed. This pass is automatically run - by the parser after parsing input assembly and by the optimizer before it - outputs bitcode. The violations pointed out by the verifier pass indicate - bugs in transformation passes or input to the parser.

    +

    because the definition of %x does not dominate all of its uses. The + LLVM infrastructure provides a verification pass that may be used to verify + that an LLVM module is well formed. This pass is automatically run by the + parser after parsing input assembly and by the optimizer before it outputs + bitcode. The violations pointed out by the verifier pass indicate bugs in + transformation passes or input to the parser.

    @@ -436,8 +452,8 @@
    -add i32 %X, %X           ; yields {i32}:%0
    -add i32 %0, %0           ; yields {i32}:%1
    +%0 = add i32 %X, %X           ; yields {i32}:%0
    +%1 = add i32 %0, %0           ; yields {i32}:%1
     %result = add i32 %1, %1
     
    @@ -455,7 +471,7 @@
  • Unnamed temporaries are numbered sequentially
  • -

    ...and it also shows a convention that we follow in this document. When +

    It also shows a convention that we follow in this document. When demonstrating instructions, we will follow an instruction with a comment that defines the type and name of value produced. Comments are shown in italic text.

    @@ -480,31 +496,33 @@ the "hello world" module:

    -
    ; Declare the string constant as a global constant...
    -@.LC0 = internal constant [13 x i8] c"hello world\0A\00"          ; [13 x i8]*
    +
    +; Declare the string constant as a global constant.
    +@.LC0 = internal constant [13 x i8] c"hello world\0A\00"    ; [13 x i8]*
     
     ; External declaration of the puts function
    -declare i32 @puts(i8 *)                                           ; i32(i8 *)* 
    +declare i32 @puts(i8 *)                                     ; i32(i8 *)* 
     
     ; Definition of main function
    -define i32 @main() {                                              ; i32()* 
    -        ; Convert [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, and + ".LC0", an external declaration of the "puts" function, a function definition for - "main".

    + "main" and named metadata + "foo".

    In general, a module is made up of a list of global values, where both functions and global variables are global values. Global values are @@ -525,7 +543,7 @@ define i32 @main() { ; i32()*

    -
    private:
    +
    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 @@ -533,7 +551,7 @@ define i32 @main() { ; i32()* -
    linker_private:
    +
    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: @@ -541,12 +559,12 @@ define i32 @main() { ; i32()* -
    internal:
    +
    internal
    Similar to private, but the value shows as a local symbol (STB_LOCAL in the case of ELF) in the object file. This corresponds to the notion of the 'static' keyword in C.
    -
    available_externally:
    +
    available_externally
    Globals with "available_externally" linkage are never emitted into the object file corresponding to the LLVM module. They exist to allow inlining and other optimizations to take place given knowledge of @@ -555,45 +573,52 @@ define i32 @main() { ; i32()* linkonce_odr. This linkage type is only allowed on definitions, not declarations.
    -
    linkonce:
    +
    linkonce
    Globals with "linkonce" linkage are merged with other globals of - the same name when linkage occurs. This is typically used to implement - inline functions, templates, or other code which must be generated in each - translation unit that uses it. Unreferenced linkonce globals are - allowed to be discarded.
    - -
    weak:
    + the same name when linkage occurs. This can be used to implement + some forms of inline functions, templates, or other code which must be + generated in each translation unit that uses it, but where the body may + be overridden with a more definitive definition later. Unreferenced + linkonce globals are allowed to be discarded. Note that + linkonce linkage does not actually allow the optimizer to + inline the body of this function into callers because it doesn't know if + this definition of the function is the definitive definition within the + program or whether it will be overridden by a stronger definition. + To enable inlining and other optimizations, use "linkonce_odr" + linkage. + +
    weak
    "weak" linkage has the same merging semantics as linkonce linkage, except that unreferenced globals with weak linkage may not be discarded. This is used for globals that are declared "weak" in C source code.
    -
    common:
    +
    common
    "common" linkage is most similar to "weak" linkage, but they are used for tentative definitions in C, such as "int X;" at global scope. Symbols with "common" linkage are merged in the same way as weak symbols, and they may not be deleted if unreferenced. common symbols may not have an explicit section, - must have a zero initializer, and may not be marked 'constant'. Functions and aliases may not have common linkage.
    -
    appending:
    +
    appending
    "appending" linkage may only be applied to global variables of pointer to array type. When two global variables with appending linkage are linked together, the two global arrays are appended together. This is the LLVM, typesafe, equivalent of having the system linker append together "sections" with identical names when .o files are linked.
    -
    extern_weak:
    +
    extern_weak
    The semantics of this linkage follow the ELF object file model: the symbol is weak until linked, if not linked, the symbol becomes null instead of being an undefined reference.
    -
    linkonce_odr:
    -
    weak_odr:
    +
    linkonce_odr
    +
    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" - @@ -613,14 +638,14 @@ define i32 @main() { ; i32()*
    -
    dllimport:
    +
    dllimport
    "dllimport" linkage causes the compiler to reference a function or variable via a global pointer to a pointer that is set up by the DLL exporting the symbol. On Microsoft Windows targets, the pointer name is formed by combining __imp_ and the function or variable name.
    -
    dllexport:
    +
    dllexport
    "dllexport" linkage causes the compiler to provide a global pointer to a pointer in a DLL, so that it can be referenced with the dllimport attribute. On Microsoft Windows targets, the pointer @@ -670,11 +695,11 @@ define i32 @main() { ; i32()* tail call - optimization to be supported. This calling convention does not - support varargs and requires the prototype of all callees to exactly match - the prototype of the function definition.
    + (Application Binary Interface). + Tail calls can only be optimized + 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 @@ -684,6 +709,26 @@ define i32 @main() { ; i32()* +
    "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 @@ -829,7 +874,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 @@ -842,7 +887,7 @@ define i32 @main() { ; i32()* LLVM function declarations consist of the "declare" keyword, an optional linkage type, an optional - visibility style, an optional + visibility style, an optional calling convention, a return type, an optional parameter attribute for the return type, a function name, a possibly empty list of arguments, an optional alignment, and an @@ -903,6 +948,27 @@ define [linkage] [visibility] + +

    + +
    + +

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

    + +
    Syntax:
    +
    +
    +!1 = metadata !{metadata !"one"}
    +!name = !{null, !1}
    +
    +
    + +
    + @@ -933,24 +999,24 @@ declare signext i8 @returns_signed_char()

    Currently, only the following parameter attributes are defined:

    -
    zeroext
    +
    zeroext
    This indicates to the code generator that the parameter or return value should be zero-extended to a 32-bit value by the caller (for a parameter) or the callee (for a return value).
    -
    signext
    +
    signext
    This indicates to the code generator that the parameter or return value should be sign-extended to a 32-bit value by the caller (for a parameter) or the callee (for a return value).
    -
    inreg
    +
    inreg
    This indicates that this parameter or return value should be treated in a special target-dependent fashion during while emitting code for a function call or return (usually, by putting it in a register as opposed to memory, though some targets use it to distinguish between two different kinds of registers). Use of this attribute is target-specific.
    -
    byval
    +
    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 is made between the caller and the callee, so the callee is unable to @@ -965,7 +1031,7 @@ declare signext i8 @returns_signed_char() generator that usually indicates a desired alignment for the synthesized stack slot.
    -
    sret
    +
    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 @@ -973,7 +1039,7 @@ declare signext i8 @returns_signed_char() may only be applied to the first parameter. This is not a valid attribute for return values.
    -
    noalias
    +
    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 @@ -983,12 +1049,12 @@ declare signext i8 @returns_signed_char() alias analysis.
    -
    nocapture
    +
    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.
    @@ -1008,7 +1074,7 @@ declare signext i8 @returns_signed_char()
    -define void @f() gc "name" { ...
    +define void @f() gc "name" { ... }
     
    @@ -1038,42 +1104,47 @@ define void @f() gc "name" { ... define void @f() noinline { ... } define void @f() alwaysinline { ... } define void @f() alwaysinline optsize { ... } -define void @f() optsize +define void @f() optsize { ... }
    -
    alwaysinline
    +
    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.
    -
    inlinehint
    +
    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.
    -
    noinline
    +
    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
    +
    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.
    -
    noreturn
    +
    noreturn
    This function attribute indicates that the function never returns normally. This produces undefined behavior at runtime if the function ever does dynamically return.
    -
    nounwind
    +
    nounwind
    This function attribute indicates that the function never returns with an unwind or exceptional control flow. If the function does unwind, its runtime behavior is undefined.
    -
    readnone
    +
    readnone
    This attribute indicates that the function computes its result (or decides to unwind an exception) based strictly on its arguments, without dereferencing any pointer arguments or otherwise accessing any mutable @@ -1084,7 +1155,7 @@ define void @f() optsize exceptions by calling the C++ exception throwing methods, but could use the unwind instruction.
    -
    readonly
    +
    readonly
    This attribute indicates that the function does not write through any pointer arguments (including byval arguments) or otherwise modify any state (e.g. memory, control registers, @@ -1095,7 +1166,7 @@ define void @f() optsize exception by calling the C++ exception throwing methods, but may use the unwind instruction.
    -
    ssp
    +
    ssp
    This attribute indicates that the function should emit a stack smashing protector. It is in the form of a "canary"—a random value placed on the stack before the local variables that's checked upon return from the @@ -1106,7 +1177,7 @@ define void @f() optsize function that doesn't have an ssp attribute, then the resulting function will have an ssp attribute.
    -
    sspreq
    +
    sspreq
    This attribute indicates that the function should always emit a stack smashing protector. This overrides the ssp function attribute.
    @@ -1116,14 +1187,14 @@ define void @f() optsize an ssp attribute, then the resulting function will have an sspreq attribute.
    -
    noredzone
    +
    noredzone
    This attribute indicates that the code generator should not use a red zone, even if the target-specific ABI normally permits it.
    -
    noimplicitfloat
    +
    noimplicitfloat
    This attributes disables implicit floating point instructions.
    -
    naked
    +
    naked
    This attribute disables prologue / epilogue emission for the function. This can have very system-specific consequences.
    @@ -1191,7 +1262,7 @@ target datalayout = "layout specification" location.
    p:size:abi:pref
    -
    This specifies the size of a pointer and its abi and +
    This specifies the size of a pointer and its abi and preferred alignments. All sizes are in bits. Specifying the pref alignment is optional. If omitted, the preceding : should be omitted too.
    @@ -1201,11 +1272,11 @@ target datalayout = "layout specification" size. The value of size must be in the range [1,2^23).
    vsize:abi:pref
    -
    This specifies the alignment for a vector type of a given bit +
    This specifies the alignment for a vector type of a given bit size.
    fsize:abi:pref
    -
    This specifies the alignment for a floating point type of a given bit +
    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).
    @@ -1216,6 +1287,13 @@ target datalayout = "layout specification"
    ssize:abi:pref
    This specifies the alignment for a stack object of a given bit size.
    + +
    nsize1:size2:size3...
    +
    This specifies a set of native integer widths for the target CPU + in bits. For example, it might contain "n32" for 32-bit PowerPC, + "n32:64" for PowerPC 64, or "n8:16:32:64" for X86-64. Elements of + this set are considered to support most general arithmetic + operations efficiently.

    When constructing the data layout for a given target, LLVM starts with a @@ -1225,7 +1303,7 @@ target datalayout = "layout specification"