X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.html;h=71f8d999106ebebdf5a5f9a6c56b82b4babe882b;hb=211244aa520e158dc2c31bea7277dea475105fa9;hp=651426c67f13054562b7be8b9fa5d926a1f1c9f0;hpb=fe47aae6a8132af400139612f9ee5aec220c4385;p=oota-llvm.git diff --git a/docs/LangRef.html b/docs/LangRef.html index 651426c67f1..71f8d999106 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -24,6 +24,7 @@
  1. 'private' Linkage
  2. 'linker_private' Linkage
    3. +
  3. 'linker_private_weak' Linkage
  4. 'internal' Linkage
  5. 'available_externally' Linkage
  6. 'linkonce' Linkage
    7. @@ -546,20 +547,24 @@ 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).
    internal
    Similar to private, but the value shows as a local symbol @@ -623,8 +628,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.
    @@ -1037,7 +1042,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 @@ -1045,22 +1050,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.
    @@ -1130,15 +1147,21 @@ define void @f() optsize { ... } 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 @@ -1150,6 +1173,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 @@ -1192,17 +1220,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.
    @@ -1283,8 +1300,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 @@ -1360,34 +1379,46 @@ is undefined. Pointer values are associated with address ranges according to the following rules:

      -
    • A pointer value formed from a - getelementptr instruction - is associated with the addresses associated with the first operand - of the getelementptr.
      • +
    • A pointer value is associated with the addresses associated with + any value it is based on.
    • An address of a global variable is associated with the address range of the variable's storage.
    • The result value of an allocation instruction is associated with the address range of the allocated storage.
    • A null pointer in the default address-space is associated with no address.
      • -
    • A pointer value formed by an - inttoptr is associated with all - address ranges of all pointer values that contribute (directly or - indirectly) to the computation of the pointer's value.
      • -
    • The result value of a - bitcast is associated with all - addresses associated with the operand of the bitcast.
    • An integer constant other than zero or a pointer value returned from a function not defined within LLVM may be associated with address ranges allocated through mechanisms other than those provided by LLVM. Such ranges shall not overlap with any ranges of addresses allocated by mechanisms provided by LLVM.
      • -
    + + +

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

    + +
      +
    • A pointer value formed from a + getelementptr operation + is based on the first operand of the getelementptr.
      • +
    • The result value of a + bitcast is based on the operand + of the bitcast.
      • +
    • A pointer value formed by an + inttoptr is based on all + pointer values that contribute (directly or indirectly) to the + computation of the pointer's value.
      • +
    • The "based on" relationship is transitive.
      • +
    + +

    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.

    @@ -2374,7 +2405,8 @@ has undefined behavior.

  7. 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 loads and stores.)
    8. + the order in the IR. (This includes + volatile operations.)
  8. An instruction control-depends on a terminator instruction @@ -2572,6 +2604,18 @@ end:
    Perform the shufflevector operation on constants.
    +
    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 @@ -6922,7 +6966,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