X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.html;h=45f6f38f598fc9c34bc7b9ce70feb8905d7b2f40;hb=9e6d1d1f5034347d237941f1bf08fba5c1583cd3;hp=1b1655e42fddb2e7423c041bfe41ab04557518af;hpb=8040cd3cfd7b87661c08ca916daf355593dd8ffa;p=oota-llvm.git diff --git a/docs/LangRef.html b/docs/LangRef.html index 1b1655e42fd..45f6f38f598 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -5,7 +5,7 @@ LLVM Assembly Language Reference Manual - @@ -54,7 +54,7 @@
  • Type System
    1. Type Classifications
    2. -
    3. Primitive Types +
    4. Primitive Types
      1. Integer Type
      2. Floating Point Types
      3. @@ -83,6 +83,7 @@
      4. Complex Constants
      5. Global Variable and Function Addresses
      6. Undefined Values
      7. +
      8. Addresses of Basic Blocks
      9. Constant Expressions
      10. Embedded Metadata
      @@ -110,6 +111,7 @@
    5. 'ret' Instruction
    6. 'br' Instruction
    7. 'switch' Instruction
    8. +
    9. 'indirectbr' Instruction
    10. 'invoke' Instruction
    11. 'unwind' Instruction
    12. 'unreachable' Instruction
    13. @@ -156,8 +158,6 @@
    14. Memory Access and Addressing Operations
        -
      1. 'malloc' Instruction
      2. -
      3. 'free' Instruction
      4. 'alloca' Instruction
      5. 'load' Instruction
      6. 'store' Instruction
      7. @@ -273,6 +273,14 @@
      8. llvm.atomic.load.umin
    15. +
    16. Memory Use Markers +
        +
      1. llvm.lifetime.start
      2. +
      3. llvm.lifetime.end
      4. +
      5. llvm.invariant.start
      6. +
      7. llvm.invariant.end
      8. +
      +
    17. General intrinsics
      1. @@ -283,6 +291,8 @@ 'llvm.trap' Intrinsic
      2. 'llvm.stackprotector' Intrinsic
      3. +
      4. + 'llvm.objectsize' Intrinsic
    @@ -330,7 +340,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.

    @@ -351,12 +361,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.

    @@ -430,8 +440,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
     
    @@ -449,7 +459,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.

    @@ -474,24 +484,21 @@ 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
    }
    @@ -519,7 +526,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 @@ -527,7 +534,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: @@ -535,12 +542,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 @@ -549,45 +556,45 @@ 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:
    +
    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" - @@ -607,14 +614,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 @@ -836,7 +843,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 @@ -927,24 +934,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 @@ -959,7 +966,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 @@ -967,7 +974,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 @@ -977,12 +984,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.
    @@ -1002,7 +1009,7 @@ declare signext i8 @returns_signed_char()
    -define void @f() gc "name" { ...
    +define void @f() gc "name" { ... }
     
    @@ -1032,42 +1039,42 @@ 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
    +
    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 @@ -1078,7 +1085,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, @@ -1089,7 +1096,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 @@ -1100,7 +1107,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.
    @@ -1110,14 +1117,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.
    @@ -1185,7 +1192,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.
    @@ -1195,11 +1202,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).
    @@ -1210,6 +1217,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 @@ -1428,11 +1442,6 @@ Classifications -

    Note that the code generator does not yet support large integer types to be - used as function return types. The specific limit on how large a return type - the code generator can currently handle is target-dependent; currently it's - often 64 bits for 32-bit targets and 128 bits for 64-bit targets.

    - @@ -1564,17 +1573,12 @@ Classifications -

    Note that 'variable sized arrays' can be implemented in LLVM with a zero - length array. Normally, accesses past the end of an array are undefined in - LLVM (e.g. it is illegal to access the 5th element of a 3 element array). As - a special case, however, zero length arrays are recognized to be variable - length. This allows implementation of 'pascal style arrays' with the LLVM - type "{ i32, [0 x float]}", for example.

    - -

    Note that the code generator does not yet support large aggregate types to be - used as function return types. The specific limit on how large an aggregate - return type the code generator can currently handle is target-dependent, and - also dependent on the aggregate element types.

    +

    There is no restriction on indexing beyond the end of the array implied by + a static type (though there are restrictions on indexing beyond the bounds + of an allocated object in some cases). This means that single-dimension + 'variable sized array' addressing can be implemented in LLVM with a zero + length array type. An implementation of 'pascal style arrays' in LLVM could + use the type "{ i32, [0 x float]}", for example.

    @@ -1612,16 +1616,16 @@ Classifications float (i16 signext, i32 *) * - Pointer to a function that takes - an i16 that should be sign extended and a - pointer to i32, returning + Pointer to a function that takes + an i16 that should be sign extended and a + pointer to i32, returning float. i32 (i8*, ...) - A vararg function that takes at least one - pointer to i8 (char in C), - which returns an integer. This is the signature for printf in + A vararg function that takes at least one + pointer to i8 (char in C), + which returns an integer. This is the signature for printf in LLVM. @@ -1668,11 +1672,6 @@ Classifications -

    Note that the code generator does not yet support large aggregate types to be - used as function return types. The specific limit on how large an aggregate - return type the code generator can currently handle is target-dependent, and - also dependent on the aggregate element types.

    - @@ -1763,8 +1762,7 @@ Classifications

    A vector type is a simple derived type that represents a vector of elements. Vector types are used when multiple primitive data are operated in parallel using a single instruction (SIMD). A vector type requires a size (number of - elements) and an underlying primitive data type. Vectors must have a power - of two length (1, 2, 4, 8, 16 ...). Vector types are considered + elements) and an underlying primitive data type. Vector types are considered first class.

    Syntax:
    @@ -1791,11 +1789,6 @@ Classifications -

    Note that the code generator does not yet support large vector types to be - used as function return types. The specific limit on how large a vector - return type codegen can currently handle is target-dependent; currently it's - often a few times longer than a hardware vector register.

    - @@ -2061,9 +2054,9 @@ Unsafe: 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 +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.

    @@ -2093,7 +2086,7 @@ the optimizer is allowed to assume that the undef operand could be the same as
       %A = xor undef, undef
    -  
    +
       %B = undef
       %C = xor %B, %B
     
    @@ -2144,7 +2137,7 @@ does not execute at all.  This allows us to delete the divide and all code after
     it: since the undefined operation "can't happen", the optimizer can assume that
     it occurs in dead code.
     

    - +
     a:  store undef -> %X
    @@ -2156,13 +2149,41 @@ 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 +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.

    + + +
    + +

    blockaddress(@function, %block)

    + +

    The 'blockaddress' constant computes the address of the specified + basic block in the specified function, and always has an i8* type. Taking + the address of the entry block is illegal.

    + +

    This value only has defined behavior when used as an operand to the + 'indirectbr' instruction or for comparisons + against null. Pointer equality tests between labels addresses is undefined + behavior - though, again, comparison against null is ok, and no label is + equal to the null pointer. This may also be passed around as an opaque + pointer sized value as long as the bits are not inspected. This allows + ptrtoint and arithmetic to be performed on these values so long as + the original value is reconstituted before the indirectbr.

    + +

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

    + +
    + + @@ -2330,8 +2351,10 @@ has undefined behavior.

    to Module-Level Inline Assembly) through the use of a special value. This value represents the inline assembler as a string (containing the instructions to emit), a list of operand constraints (stored - as a string), and a flag that indicates whether or not the inline asm - expression has side effects. An example inline assembler expression is:

    + as a string), a flag that indicates whether or not the inline asm + expression has side effects, and a flag indicating whether the function + containing the asm needs to align its stack conservatively. An example + inline assembler expression is:

    @@ -2359,6 +2382,22 @@ call void asm sideeffect "eieio", ""()
     
    +

    In some cases inline asms will contain code that will not work unless the + stack is aligned in some way, such as calls or SSE instructions on x86, + yet will not contain code that does that alignment within the asm. + The compiler should make conservative assumptions about what the asm might + contain and should generate its usual stack alignment code in the prologue + if the 'alignstack' keyword is present:

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

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

    +

    TODO: The format of the asm and constraints string still need to be documented here. Constraints on what can be done (e.g. duplication, moving, etc need to be documented). This is probably best done by reference to @@ -2487,6 +2526,7 @@ Instructions

    'ret' instruction, the 'br' instruction, the 'switch' instruction, the + ''indirectbr' Instruction, the 'invoke' instruction, the 'unwind' instruction, and the 'unreachable' instruction.

    @@ -2541,14 +2581,6 @@ Instruction ret { i32, i8 } { i32 4, i8 2 } ; Return a struct of values 4 and 2 -

    Note that the code generator does not yet fully support large - return values. The specific sizes that are currently supported are - dependent on the target. For integers, on 32-bit targets the limit - is often 64 bits, and on 64-bit targets the limit is often 128 bits. - For aggregate types, the current limits are dependent on the element - types; for example targets are often limited to 2 total integer - elements and 2 total floating-point elements.

    - @@ -2645,6 +2677,55 @@ IfUnequal: + + + + +
    + +
    Syntax:
    +
    +  indirectbr <somety>* <address>, [ label <dest1>, label <dest2>, ... ]
    +
    + +
    Overview:
    + +

    The 'indirectbr' instruction implements an indirect branch to a label + within the current function, whose address is specified by + "address". Address must be derived from a blockaddress constant.

    + +
    Arguments:
    + +

    The 'address' argument is the address of the label to jump to. The + rest of the arguments indicate the full set of possible destinations that the + address may point to. Blocks are allowed to occur multiple times in the + destination list, though this isn't particularly useful.

    + +

    This destination list is required so that dataflow analysis has an accurate + understanding of the CFG.

    + +
    Semantics:
    + +

    Control transfers to the block specified in the address argument. All + possible destination blocks must be listed in the label list, otherwise this + instruction has undefined behavior. This implies that jumps to labels + defined in other functions have undefined behavior as well.

    + +
    Implementation:
    + +

    This is typically implemented with a jump through a register.

    + +
    Example:
    +
    + indirectbr i8* %Addr, [ label %bb1, label %bb2, label %bb3 ]
    +
    + +
    + +
    'invoke' Instruction @@ -2979,7 +3060,7 @@ Instruction

    The two arguments to the 'mul' instruction must be integer or vector of integer values. Both arguments must have identical types.

    - +
    Semantics:

    The value produced is the integer product of the two operands.

    @@ -3051,7 +3132,7 @@ Instruction

    The 'udiv' instruction returns the quotient of its two operands.

    Arguments:
    -

    The two arguments to the 'udiv' instruction must be +

    The two arguments to the 'udiv' instruction must be integer or vector of integer values. Both arguments must have identical types.

    @@ -3086,7 +3167,7 @@ Instruction

    The 'sdiv' instruction returns the quotient of its two operands.

    Arguments:
    -

    The two arguments to the 'sdiv' instruction must be +

    The two arguments to the 'sdiv' instruction must be integer or vector of integer values. Both arguments must have identical types.

    @@ -3157,7 +3238,7 @@ Instruction division of its two arguments.

    Arguments:
    -

    The two arguments to the 'urem' instruction must be +

    The two arguments to the 'urem' instruction must be integer or vector of integer values. Both arguments must have identical types.

    @@ -3197,7 +3278,7 @@ Instruction elements must be integers.

    Arguments:
    -

    The two arguments to the 'srem' instruction must be +

    The two arguments to the 'srem' instruction must be integer or vector of integer values. Both arguments must have identical types.

    @@ -3292,7 +3373,7 @@ Instruction

    Both arguments to the 'shl' instruction must be the same integer or vector of integer type. 'op2' is treated as an unsigned value.

    - +
    Semantics:

    The value produced is op1 * 2op2 mod 2n, where n is the width of the result. If op2 @@ -3328,7 +3409,7 @@ Instruction operand shifted to the right a specified number of bits with zero fill.

    Arguments:
    -

    Both arguments to the 'lshr' instruction must be the same +

    Both arguments to the 'lshr' instruction must be the same integer or vector of integer type. 'op2' is treated as an unsigned value.

    @@ -3368,7 +3449,7 @@ Instruction extension.

    Arguments:
    -

    Both arguments to the 'ashr' instruction must be the same +

    Both arguments to the 'ashr' instruction must be the same integer or vector of integer type. 'op2' is treated as an unsigned value.

    @@ -3408,7 +3489,7 @@ Instruction operands.

    Arguments:
    -

    The two arguments to the 'and' instruction must be +

    The two arguments to the 'and' instruction must be integer or vector of integer values. Both arguments must have identical types.

    @@ -3467,7 +3548,7 @@ Instruction two operands.

    Arguments:
    -

    The two arguments to the 'or' instruction must be +

    The two arguments to the 'or' instruction must be integer or vector of integer values. Both arguments must have identical types.

    @@ -3530,7 +3611,7 @@ Instruction complement" operation, which is the "~" operator in C.

    Arguments:
    -

    The two arguments to the 'xor' instruction must be +

    The two arguments to the 'xor' instruction must be integer or vector of integer values. Both arguments must have identical types.

    @@ -3578,7 +3659,7 @@ Instruction -
    + @@ -3624,7 +3705,7 @@ Instruction
    Example:
    -  %result = extractelement <4 x i32> %vec, i32 0    ; yields i32
    +  <result> = extractelement <4 x i32> %vec, i32 0    ; yields i32
     
    @@ -3660,7 +3741,7 @@ Instruction
    Example:
    -  %result = insertelement <4 x i32> %vec, i32 1, i32 0    ; yields <4 x i32>
    +  <result> = insertelement <4 x i32> %vec, i32 1, i32 0    ; yields <4 x i32>
     
    @@ -3701,20 +3782,20 @@ Instruction
    Example:
    -  %result = shufflevector <4 x i32> %v1, <4 x i32> %v2, 
    +  <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2,
                               <4 x i32> <i32 0, i32 4, i32 1, i32 5>  ; yields <4 x i32>
    -  %result = shufflevector <4 x i32> %v1, <4 x i32> undef, 
    +  <result> = shufflevector <4 x i32> %v1, <4 x i32> undef,
                               <4 x i32> <i32 0, i32 1, i32 2, i32 3>  ; yields <4 x i32> - Identity shuffle.
    -  %result = shufflevector <8 x i32> %v1, <8 x i32> undef, 
    +  <result> = shufflevector <8 x i32> %v1, <8 x i32> undef,
                               <4 x i32> <i32 0, i32 1, i32 2, i32 3>  ; yields <4 x i32>
    -  %result = shufflevector <4 x i32> %v1, <4 x i32> %v2, 
    +  <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2,
                               <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 >  ; yields <8 x i32>
     
    -
    + @@ -3753,7 +3834,7 @@ Instruction
    Example:
    -  %result = extractvalue {i32, float} %agg, 0    ; yields i32
    +  <result> = extractvalue {i32, float} %agg, 0    ; yields i32
     
    @@ -3792,14 +3873,14 @@ Instruction
    Example:
    -  %result = insertvalue {i32, float} %agg, i32 1, 0    ; yields {i32, float}
    +  <result> = insertvalue {i32, float} %agg, i32 1, 0    ; yields {i32, float}
     
    -
    + @@ -3807,93 +3888,11 @@ Instruction

    A key design point of an SSA-based representation is how it represents memory. In LLVM, no memory locations are in SSA form, which makes things - very simple. This section describes how to read, write, allocate, and free + very simple. This section describes how to read, write, and allocate memory in LLVM.

    - - - -
    - -
    Syntax:
    -
    -  <result> = malloc <type>[, i32 <NumElements>][, align <alignment>]     ; yields {type*}:result
    -
    - -
    Overview:
    -

    The 'malloc' instruction allocates memory from the system heap and - returns a pointer to it. The object is always allocated in the generic - address space (address space zero).

    - -
    Arguments:
    -

    The 'malloc' instruction allocates - sizeof(<type>)*NumElements bytes of memory from the operating - system and returns a pointer of the appropriate type to the program. If - "NumElements" is specified, it is the number of elements allocated, otherwise - "NumElements" is defaulted to be one. If a constant alignment is specified, - the value result of the allocation is guaranteed to be aligned to at least - that boundary. If not specified, or if zero, the target can choose to align - the allocation on any convenient boundary compatible with the type.

    - -

    'type' must be a sized type.

    - -
    Semantics:
    -

    Memory is allocated using the system "malloc" function, and a - pointer is returned. The result of a zero byte allocation is undefined. The - result is null if there is insufficient memory available.

    - -
    Example:
    -
    -  %array  = malloc [4 x i8]                     ; yields {[%4 x i8]*}:array
    -
    -  %size   = add i32 2, 2                        ; yields {i32}:size = i32 4
    -  %array1 = malloc i8, i32 4                    ; yields {i8*}:array1
    -  %array2 = malloc [12 x i8], i32 %size         ; yields {[12 x i8]*}:array2
    -  %array3 = malloc i32, i32 4, align 1024       ; yields {i32*}:array3
    -  %array4 = malloc i32, align 1024              ; yields {i32*}:array4
    -
    - -

    Note that the code generator does not yet respect the alignment value.

    - -
    - - - - -
    - -
    Syntax:
    -
    -  free <type> <value>                           ; yields {void}
    -
    - -
    Overview:
    -

    The 'free' instruction returns memory back to the unused memory heap - to be reallocated in the future.

    - -
    Arguments:
    -

    'value' shall be a pointer value that points to a value that was - allocated with the 'malloc' instruction.

    - -
    Semantics:
    -

    Access to the memory pointed to by the pointer is no longer defined after - this instruction executes. If the pointer is null, the operation is a - noop.

    - -
    Example:
    -
    -  %array  = malloc [4 x i8]                     ; yields {[4 x i8]*}:array
    -            free   [4 x i8]* %array
    -
    - -
    -
    'alloca' Instruction @@ -4227,7 +4226,7 @@ entry:
       %X = trunc i32 257 to i8              ; yields i8:1
       %Y = trunc i32 123 to i1              ; yields i1:true
    -  %Y = trunc i32 122 to i1              ; yields i1:false
    +  %Z = trunc i32 122 to i1              ; yields i1:false
     
    @@ -4244,15 +4243,15 @@ entry:
    Overview:
    -

    The 'zext' instruction zero extends its operand to type +

    The 'zext' instruction zero extends its operand to type ty2.

    Arguments:
    -

    The 'zext' instruction takes a value to cast, which must be of +

    The 'zext' instruction takes a value to cast, which must be of integer type, and a type to cast it to, which must also be of integer type. The bit size of the - value must be smaller than the bit size of the destination type, + value must be smaller than the bit size of the destination type, ty2.

    Semantics:
    @@ -4284,10 +4283,10 @@ entry:

    The 'sext' sign extends value to the type ty2.

    Arguments:
    -

    The 'sext' instruction takes a value to cast, which must be of +

    The 'sext' instruction takes a value to cast, which must be of integer type, and a type to cast it to, which must also be of integer type. The bit size of the - value must be smaller than the bit size of the destination type, + value must be smaller than the bit size of the destination type, ty2.

    Semantics:
    @@ -4325,12 +4324,12 @@ entry:

    The 'fptrunc' instruction takes a floating point value to cast and a floating point type to cast it to. The size of value must be larger than the size of - ty2. This implies that fptrunc cannot be used to make a + ty2. This implies that fptrunc cannot be used to make a no-op cast.

    Semantics:

    The 'fptrunc' instruction truncates a value from a larger - floating point type to a smaller + floating point type to a smaller floating point type. If the value cannot fit within the destination type, ty2, then the results are undefined.

    @@ -4359,7 +4358,7 @@ entry: floating point value.

    Arguments:
    -

    The 'fpext' instruction takes a +

    The 'fpext' instruction takes a floating point value to cast, and a floating point type to cast it to. The source type must be smaller than the destination type.

    @@ -4402,7 +4401,7 @@ entry: vector integer type with the same number of elements as ty

    Semantics:
    -

    The 'fptoui' instruction converts its +

    The 'fptoui' instruction converts its floating point operand into the nearest (rounding towards zero) unsigned integer value. If the value cannot fit in ty2, the results are undefined.

    @@ -4411,7 +4410,7 @@ entry:
       %X = fptoui double 123.0 to i32      ; yields i32:123
       %Y = fptoui float 1.0E+300 to i1     ; yields undefined:1
    -  %X = fptoui float 1.04E+17 to i8     ; yields undefined:1
    +  %Z = fptoui float 1.04E+17 to i8     ; yields undefined:1
     
    @@ -4428,7 +4427,7 @@ entry:
    Overview:
    -

    The 'fptosi' instruction converts +

    The 'fptosi' instruction converts floating point value to type ty2.

    @@ -4440,7 +4439,7 @@ entry: vector integer type with the same number of elements as ty

    Semantics:
    -

    The 'fptosi' instruction converts its +

    The 'fptosi' instruction converts its floating point operand into the nearest (rounding towards zero) signed integer value. If the value cannot fit in ty2, the results are undefined.

    @@ -4449,7 +4448,7 @@ entry:
       %X = fptosi double -123.0 to i32      ; yields i32:-123
       %Y = fptosi float 1.0E-247 to i1      ; yields undefined:1
    -  %X = fptosi float 1.04E+17 to i8      ; yields undefined:1
    +  %Z = fptosi float 1.04E+17 to i8      ; yields undefined:1
     
    @@ -4593,8 +4592,8 @@ entry:
    Example:
       %X = inttoptr i32 255 to i32*          ; yields zero extension on 64-bit architecture
    -  %X = inttoptr i32 255 to i32*          ; yields no-op on 32-bit architecture
    -  %Y = inttoptr i64 0 to i32*            ; yields truncation on 32-bit architecture
    +  %Y = inttoptr i32 255 to i32*          ; yields no-op on 32-bit architecture
    +  %Z = inttoptr i64 0 to i32*            ; yields truncation on 32-bit architecture
     
    @@ -4637,7 +4636,7 @@ entry:
       %X = bitcast i8 255 to i8              ; yields i8 :-1
       %Y = bitcast i32* %x to sint*          ; yields sint*:%x
    -  %Z = bitcast <2 x int> %V to i64;      ; yields i64: %V   
    +  %Z = bitcast <2 x int> %V to i64;      ; yields i64: %V
     
    @@ -4697,11 +4696,11 @@ entry: result, as follows:

      -
    1. eq: yields true if the operands are equal, +
    2. eq: yields true if the operands are equal, false otherwise. No sign interpretation is necessary or performed.
    3. -
    4. ne: yields true if the operands are unequal, +
    5. ne: yields true if the operands are unequal, false otherwise. No sign interpretation is necessary or performed.
    6. @@ -4818,42 +4817,42 @@ entry:
      1. false: always yields false, regardless of operands.
      2. -
      3. oeq: yields true if both operands are not a QNAN and +
      4. oeq: yields true if both operands are not a QNAN and op1 is equal to op2.
      5. ogt: yields true if both operands are not a QNAN and op1 is greather than op2.
      6. -
      7. oge: yields true if both operands are not a QNAN and +
      8. oge: yields true if both operands are not a QNAN and op1 is greater than or equal to op2.
      9. -
      10. olt: yields true if both operands are not a QNAN and +
      11. olt: yields true if both operands are not a QNAN and op1 is less than op2.
      12. -
      13. ole: yields true if both operands are not a QNAN and +
      14. ole: yields true if both operands are not a QNAN and op1 is less than or equal to op2.
      15. -
      16. one: yields true if both operands are not a QNAN and +
      17. one: yields true if both operands are not a QNAN and op1 is not equal to op2.
      18. ord: yields true if both operands are not a QNAN.
      19. -
      20. ueq: yields true if either operand is a QNAN or +
      21. ueq: yields true if either operand is a QNAN or op1 is equal to op2.
      22. -
      23. ugt: yields true if either operand is a QNAN or +
      24. ugt: yields true if either operand is a QNAN or op1 is greater than op2.
      25. -
      26. uge: yields true if either operand is a QNAN or +
      27. uge: yields true if either operand is a QNAN or op1 is greater than or equal to op2.
      28. -
      29. ult: yields true if either operand is a QNAN or +
      30. ult: yields true if either operand is a QNAN or op1 is less than op2.
      31. -
      32. ule: yields true if either operand is a QNAN or +
      33. ule: yields true if either operand is a QNAN or op1 is less than or equal to op2.
      34. -
      35. une: yields true if either operand is a QNAN or +
      36. une: yields true if either operand is a QNAN or op1 is not equal to op2.
      37. uno: yields true if either operand is a QNAN.
      38. @@ -5145,7 +5144,7 @@ freestanding environments and non-C-based langauges.

        suffix is required. Because the argument's type is matched against the return type, it does not require its own name suffix.

        -

        To learn how to add an intrinsic function, please see the +

        To learn how to add an intrinsic function, please see the Extending LLVM Guide.

        @@ -6580,11 +6579,11 @@ LLVM.

        • ll: All loads before the barrier must complete before any load after the barrier begins.
        • -
        • ls: All loads before the barrier must complete before any +
        • ls: All loads before the barrier must complete before any store after the barrier begins.
        • -
        • ss: All stores before the barrier must complete before any +
        • ss: All stores before the barrier must complete before any store after the barrier begins.
        • -
        • sl: All stores before the barrier must complete before any +
        • sl: All stores before the barrier must complete before any load after the barrier begins.
        @@ -6598,7 +6597,8 @@ LLVM.

        Example:
        -%ptr      = malloc i32
        +%mallocP  = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
        +%ptr      = bitcast i8* %mallocP to i32*
                     store i32 4, %ptr
         
         %result1  = load i32* %ptr      ; yields {i32}:result1 = 4
        @@ -6649,7 +6649,8 @@ LLVM.

        Examples:
        -%ptr      = malloc i32
        +%mallocP  = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
        +%ptr      = bitcast i8* %mallocP to i32*
                     store i32 4, %ptr
         
         %val1     = add i32 4, 4
        @@ -6704,7 +6705,8 @@ LLVM.

        Examples:
        -%ptr      = malloc i32
        +%mallocP  = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
        +%ptr      = bitcast i8* %mallocP to i32*
                     store i32 4, %ptr
         
         %val1     = add i32 4, 4
        @@ -6759,8 +6761,9 @@ LLVM.

        Examples:
        -%ptr      = malloc i32
        -        store i32 4, %ptr
        +%mallocP  = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
        +%ptr      = bitcast i8* %mallocP to i32*
        +            store i32 4, %ptr
         %result1  = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 4 )
                                         ; yields {i32}:result1 = 4
         %result2  = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 2 )
        @@ -6793,7 +6796,7 @@ LLVM.

        Overview:
        -

        This intrinsic subtracts delta to the value stored in memory at +

        This intrinsic subtracts delta to the value stored in memory at ptr. It yields the original value at ptr.

        Arguments:
        @@ -6810,8 +6813,9 @@ LLVM.

        Examples:
        -%ptr      = malloc i32
        -        store i32 8, %ptr
        +%mallocP  = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
        +%ptr      = bitcast i8* %mallocP to i32*
        +            store i32 8, %ptr
         %result1  = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 4 )
                                         ; yields {i32}:result1 = 8
         %result2  = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 2 )
        @@ -6887,8 +6891,9 @@ LLVM.

        Examples:
        -%ptr      = malloc i32
        -        store i32 0x0F0F, %ptr
        +%mallocP  = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
        +%ptr      = bitcast i8* %mallocP to i32*
        +            store i32 0x0F0F, %ptr
         %result0  = call i32 @llvm.atomic.load.nand.i32.p0i32( i32* %ptr, i32 0xFF )
                                         ; yields {i32}:result0 = 0x0F0F
         %result1  = call i32 @llvm.atomic.load.and.i32.p0i32( i32* %ptr, i32 0xFF )
        @@ -6947,7 +6952,7 @@ LLVM.

        Overview:
        -

        These intrinsics takes the signed or unsigned minimum or maximum of +

        These intrinsics takes the signed or unsigned minimum or maximum of delta and the value stored in memory at ptr. It yields the original value at ptr.

        @@ -6965,8 +6970,9 @@ LLVM.

        Examples:
        -%ptr      = malloc i32
        -        store i32 7, %ptr
        +%mallocP  = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
        +%ptr      = bitcast i8* %mallocP to i32*
        +            store i32 7, %ptr
         %result0  = call i32 @llvm.atomic.load.min.i32.p0i32( i32* %ptr, i32 -2 )
                                         ; yields {i32}:result0 = 7
         %result1  = call i32 @llvm.atomic.load.max.i32.p0i32( i32* %ptr, i32 8 )
        @@ -6980,6 +6986,133 @@ LLVM.

        + + + + +
        + +

        This class of intrinsics exists to information about the lifetime of memory + objects and ranges where variables are immutable.

        + +
        + + + + +
        + +
        Syntax:
        +
        +  declare void @llvm.lifetime.start(i64 <size>, i8* nocapture <ptr>)
        +
        + +
        Overview:
        +

        The 'llvm.lifetime.start' intrinsic specifies the start of a memory + object's lifetime.

        + +
        Arguments:
        +

        The first argument is a constant integer representing the size of the + object, or -1 if it is variable sized. The second argument is a pointer to + the object.

        + +
        Semantics:
        +

        This intrinsic indicates that before this point in the code, the value of the + memory pointed to by ptr is dead. This means that it is known to + never be used and has an undefined value. A load from the pointer that + precedes this intrinsic can be replaced with + 'undef'.

        + +
        + + + + +
        + +
        Syntax:
        +
        +  declare void @llvm.lifetime.end(i64 <size>, i8* nocapture <ptr>)
        +
        + +
        Overview:
        +

        The 'llvm.lifetime.end' intrinsic specifies the end of a memory + object's lifetime.

        + +
        Arguments:
        +

        The first argument is a constant integer representing the size of the + object, or -1 if it is variable sized. The second argument is a pointer to + the object.

        + +
        Semantics:
        +

        This intrinsic indicates that after this point in the code, the value of the + memory pointed to by ptr is dead. This means that it is known to + never be used and has an undefined value. Any stores into the memory object + following this intrinsic may be removed as dead. + +

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

        The 'llvm.invariant.start' intrinsic specifies that the contents of + a memory object will not change.

        + +
        Arguments:
        +

        The first argument is a constant integer representing the size of the + object, or -1 if it is variable sized. The second argument is a pointer to + the object.

        + +
        Semantics:
        +

        This intrinsic indicates that until an llvm.invariant.end that uses + the return value, the referenced memory location is constant and + unchanging.

        + +
        + + + + +
        + +
        Syntax:
        +
        +  declare void @llvm.invariant.end({}* <start>, i64 <size>, i8* nocapture <ptr>)
        +
        + +
        Overview:
        +

        The 'llvm.invariant.end' intrinsic specifies that the contents of + a memory object are mutable.

        + +
        Arguments:
        +

        The first argument is the matching llvm.invariant.start intrinsic. + The second argument is a constant integer representing the size of the + object, or -1 if it is variable sized and the third argument is a pointer + to the object.

        + +
        Semantics:
        +

        This intrinsic indicates that the memory is mutable again.

        + +
        +
        General Intrinsics @@ -7115,6 +7248,61 @@ LLVM.

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

        The llvm.objectsize intrinsic is designed to provide information + to the optimizers to either 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 type.

        + +
        Arguments:
        +

        The llvm.objectsize intrinsic takes two arguments. The first + argument is a pointer to the object ptr. The second argument + is an integer type which ranges from 0 to 3. The first bit in + the type corresponds to a return value based on whole objects, + and the second bit whether or not we return the maximum or minimum + remaining bytes computed.

        + + + + + + + + + + + + + + + + + +
        00whole object, maximum number of bytes
        01partial object, maximum number of bytes
        10whole object, minimum number of bytes
        11partial object, minimum number of bytes
        + +
        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.

        + +
        +