X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.html;h=15ecf86d4f86142bf172c97dd2a2abfe53b3218a;hb=4962e6143186f6168f5d0ee979bf047651a13124;hp=4c635d3a5aadc4951faba7f29599b28db2f37125;hpb=1005bc5068345e28826a32cc081dd4667af978ff;p=oota-llvm.git diff --git a/docs/LangRef.html b/docs/LangRef.html index 4c635d3a5aa..15ecf86d4f8 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -25,6 +25,7 @@
  • 'private' Linkage
  • 'linker_private' Linkage
  • 'linker_private_weak' Linkage
  • +
  • 'linker_private_weak_def_auto' Linkage
  • 'internal' Linkage
  • 'available_externally' Linkage
  • 'linkonce' Linkage
  • @@ -61,6 +62,7 @@
    1. Integer Type
    2. Floating Point Types
    3. +
    4. X86mmx Type
    5. Void Type
    6. Label Type
    7. Metadata Type
    8. @@ -73,7 +75,6 @@
    9. Array Type
    10. Structure Type
    11. Packed Structure Type
    12. -
    13. Union Type
    14. Vector Type
    @@ -491,20 +492,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*)* 
    +; 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} @@ -556,6 +558,15 @@ define i32 @main() { ; i32()* 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 (STB_LOCAL in the case of ELF) in the object file. This @@ -788,7 +799,7 @@ define i32 @main() { ; 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, @@ -835,6 +846,13 @@ define i32 @main() { ; i32()* region of memory, and all memory objects in LLVM are accessed through pointers.

    +

    Global variables can be marked with unnamed_addr which indicates + that the address is not significant, only the content. Constants marked + like this can be merged with other constants if they have the same + initializer. Note that a constant with significant address can + be merged with a unnamed_addr constant, the result being a + constant whose address is significant.

    +

    A global variable may be declared to reside in a target-specific numbered address space. For targets that support them, address spaces may affect how optimizations are performed and/or what target instructions are used to @@ -874,7 +892,8 @@ define i32 @main() { ; i32()*

    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 + calling convention, + an optional unnamed_addr attribute, a return type, an optional parameter attribute for the return type, a function name, a (possibly empty) argument list (each with optional parameter attributes), optional @@ -885,7 +904,8 @@ define i32 @main() { ; i32()*

    LLVM function declarations consist of the "declare" keyword, an optional linkage type, an optional visibility style, an optional - calling convention, a return type, an optional + calling convention, + an optional unnamed_addr attribute, a return type, an optional parameter attribute for the return type, a function name, a possibly empty list of arguments, an optional alignment, and an optional garbage collector name.

    @@ -911,6 +931,9 @@ define i32 @main() { ; i32()* specified, the function is forced to have at least that much alignment. All alignments must be a power of 2.

    +

    If the unnamed_addr attribute is given, the address is know to not + be significant and two identical functions can be merged

    . +
    Syntax:
     define [linkage] [visibility]
    @@ -949,15 +972,17 @@ 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:
    -; An unnamed metadata node, which is referenced by the named metadata.
    +; Some unnamed metadata nodes, which are referenced by the named metadata.
    +!0 = metadata !{metadata !"zero"}
     !1 = metadata !{metadata !"one"}
    +!2 = metadata !{metadata !"two"}
     ; A named metadata.
    -!name = !{null, !1}
    +!name = !{!0, !1, !2}
     
    @@ -992,13 +1017,15 @@ declare signext i8 @returns_signed_char()
    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).
    + should be zero-extended to the extent required by the target's ABI (which + is usually 32-bits, but is 8-bits for a i1 on x86-64) by the caller (for a + parameter) or the callee (for a return value).
    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).
    + should be sign-extended to the extent required by the target's ABI (which + is usually 32-bits) by the caller (for a parameter) or the callee (for a + return value).
    inreg
    This indicates that this parameter or return value should be treated in a @@ -1008,8 +1035,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 @@ -1017,10 +1045,13 @@ 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.

    + 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 @@ -1118,6 +1149,14 @@ define void @f() optsize { ... } 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 @@ -1462,7 +1501,6 @@ Classifications pointer, vector, structure, - union, array, label, metadata. @@ -1472,7 +1510,9 @@ Classifications primitive label, void, + integer, floating point, + x86mmx, metadata. @@ -1482,7 +1522,6 @@ Classifications pointer, structure, packed structure, - union, vector, opaque. @@ -1560,6 +1599,21 @@ Classifications + + + +
    + +
    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
    +
    + +
    + @@ -1630,8 +1684,8 @@ Classifications

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

    + structs, and vectors are + aggregate types.

    @@ -1701,9 +1755,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, a struct type, or a union - type. If the return type is a struct type then all struct elements must be - of first class types, and the struct must have at least one element.

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

    Syntax:
    @@ -1824,53 +1876,6 @@ Classifications 
     
     
     
    -
    -
    -
    -
    - -
    Overview:
    -

    A union type describes an object with size and alignment suitable for - an object of any one of a given set of types (also known as an "untagged" - union). It is similar in concept and usage to a - struct, except that all members of the union - have an offset of zero. The elements of a union may be any type that has a - size. Unions must have at least one member - empty unions are not allowed. -

    - -

    The size of the union as a whole will be the size of its largest member, - and the alignment requirements of the union as a whole will be the largest - alignment requirement of any member.

    - -

    Union members are accessed using 'load and - 'store' by getting a pointer to a field with - the 'getelementptr' instruction. - Since all members are at offset zero, the getelementptr instruction does - not affect the address, only the type of the resulting pointer.

    - -
    Syntax:
    -
    -  union { <type list> }
    -
    - -
    Examples:
    - - - - - - - - -
    union { i32, i32*, float }A union of three types: an i32, a pointer to - an i32, and a float.
    - union { float, i32 (i32) * }A union, where the first element is a float and the - second element is a pointer to a - function that takes an i32, returning - an i32.
    - -
    - @@ -1932,8 +1937,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:
    @@ -2089,6 +2095,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.

    @@ -2112,14 +2119,6 @@ Classifications the number and types of elements must match those specified by the type. -
    Union constants
    -
    Union constants are represented with notation similar to a structure with - a single element - that is, a single typed element surrounded - by braces ({})). For example: "{ i32 4 }". The - union type can be initialized with a single-element - struct as long as the type of the struct element matches the type of - one of the union members.
    -
    Array constants
    Array constants are represented with notation similar to array type definitions (a comma separated list of elements, surrounded by square @@ -2182,8 +2181,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 @@ -2202,7 +2201,7 @@ Safe:

    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
    @@ -2216,13 +2215,14 @@ Unsafe:
     

    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
    @@ -2238,13 +2238,14 @@ Unsafe:
       %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
    @@ -2265,16 +2266,17 @@ Safe:
       %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
    @@ -2285,17 +2287,17 @@ 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
    @@ -2305,11 +2307,11 @@ 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.

    @@ -2430,18 +2432,17 @@ end: 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.

    @@ -2456,7 +2457,7 @@ end: 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)
    @@ -2643,8 +2644,8 @@ call void asm alignstack "eieio", ""()

    The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode - attached to it that contains a constant integer. If present, the code - generator will use the integer as the location cookie value when report + 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:

    @@ -2656,7 +2657,8 @@ call void asm sideeffect "something bad", ""(), !srcloc !42

    It is up to the front-end to make sense of the magic numbers it places in the - IR.

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

    @@ -2690,16 +2692,21 @@ call void asm sideeffect "something bad", ""(), !srcloc !42

    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)
    -     
    +
    +
    +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
    -    
    +
    +
    +%indvar.next = add i64 %indvar, 1, !dbg !21
    +
    +
    + @@ -3441,7 +3448,8 @@ Instruction
    Syntax:
    -  <result> = udiv <ty> <op1>, <op2>   ; yields {ty}:result
    +  <result> = udiv <ty> <op1>, <op2>         ; yields {ty}:result
    +  <result> = udiv exact <ty> <op1>, <op2>   ; yields {ty}:result
     
    Overview:
    @@ -3460,6 +3468,11 @@ Instruction

    Division by zero leads to undefined behavior.

    +

    If the exact keyword is present, the result value of the + udiv is a trap value if %op1 is not a + multiple of %op2 (as such, "((a udiv exact b) mul b) == a").

    + +
    Example:
       <result> = udiv i32 4, %var          ; yields {i32}:result = 4 / %var
    @@ -3600,9 +3613,10 @@ Instruction 
     
     
    Semantics:

    This instruction returns the remainder of a division (where the result - has the same sign as the dividend, op1), not the modulo - operator (where the result has the same sign as the divisor, op2) of - a value. For more information about the difference, + is either zero or has the same sign as the dividend, op1), not the + modulo operator (where the result is either zero or has the same sign + as the divisor, op2) of a value. + For more information about the difference, see The Math Forum. For a table of how this is implemented in various languages, please see @@ -3678,7 +3692,10 @@ Instruction

    Syntax:
    -  <result> = shl <ty> <op1>, <op2>   ; yields {ty}:result
    +  <result> = shl <ty> <op1>, <op2>           ; yields {ty}:result
    +  <result> = shl nuw <ty> <op1>, <op2>       ; yields {ty}:result
    +  <result> = shl nsw <ty> <op1>, <op2>       ; yields {ty}:result
    +  <result> = shl nuw nsw <ty> <op1>, <op2>   ; yields {ty}:result
     
    Overview:
    @@ -3698,6 +3715,14 @@ Instruction vectors, each vector element of op1 is shifted by the corresponding shift amount in op2.

    +

    If the nuw keyword is present, then the shift produces a + trap value if it shifts out any non-zero bits. If + the nsw keyword is present, then the shift produces a + trap value if it shifts out any bits that disagree + with the resultant sign bit. As such, NUW/NSW have the same semantics as + they would if the shift were expressed as a mul instruction with the same + nsw/nuw bits in (mul %op1, (shl 1, %op2)).

    +
    Example:
       <result> = shl i32 4, %var   ; yields {i32}: 4 << %var
    @@ -3717,7 +3742,8 @@ Instruction 
     
     
    Syntax:
    -  <result> = lshr <ty> <op1>, <op2>   ; yields {ty}:result
    +  <result> = lshr <ty> <op1>, <op2>         ; yields {ty}:result
    +  <result> = lshr exact <ty> <op1>, <op2>   ; yields {ty}:result
     
    Overview:
    @@ -3737,6 +3763,11 @@ Instruction vectors, each vector element of op1 is shifted by the corresponding shift amount in op2.

    +

    If the exact keyword is present, the result value of the + lshr is a trap value if any of the bits + shifted out are non-zero.

    + +
    Example:
       <result> = lshr i32 4, 1   ; yields {i32}:result = 2
    @@ -3756,7 +3787,8 @@ Instruction 
     
     
    Syntax:
    -  <result> = ashr <ty> <op1>, <op2>   ; yields {ty}:result
    +  <result> = ashr <ty> <op1>, <op2>         ; yields {ty}:result
    +  <result> = ashr exact <ty> <op1>, <op2>   ; yields {ty}:result
     
    Overview:
    @@ -3777,6 +3809,10 @@ Instruction the arguments are vectors, each vector element of op1 is shifted by the corresponding shift amount in op2.

    +

    If the exact keyword is present, the result value of the + ashr is a trap value if any of the bits + shifted out are non-zero.

    +
    Example:
       <result> = ashr i32 4, 1   ; yields {i32}:result = 2
    @@ -4140,10 +4176,18 @@ Instruction 
     
     
    Arguments:

    The first operand of an 'extractvalue' instruction is a value - of struct, union or + 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 @@ -4174,11 +4218,11 @@ Instruction

    Arguments:

    The first operand of an 'insertvalue' instruction is a value - of struct, union or + 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 + 'extractvalue' instruction. The value to insert must have the same type as the value identified by the indices.

    @@ -4407,12 +4451,12 @@ Instruction indexes a value of the type pointed to (not necessarily the value directly pointed to, since the first index can be non-zero), etc. The first type indexed into must be a pointer value, subsequent types can be arrays, - vectors, structs and unions. Note that subsequent types being indexed into + 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 or union, only i32 + 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.

    @@ -4539,12 +4583,12 @@ entry: type ty2.

    Arguments:
    -

    The 'trunc' instruction takes a value to trunc, which must - be an integer type, and a type that specifies the - size and type of the result, which must be - an integer type. The bit size of value must - be larger than the bit size of ty2. Equal sized types are not - allowed.

    +

    The 'trunc' instruction takes a value to trunc, and a type to trunc it to. + Both types must be of integer types, or vectors + of the same number of integers. + The bit size of the value must be larger than + the bit size of the destination type, ty2. + Equal sized types are not allowed.

    Semantics:

    The 'trunc' instruction truncates the high order bits @@ -4554,9 +4598,10 @@ entry:

    Example:
    -  %X = trunc i32 257 to i8              ; yields i8:1
    -  %Y = trunc i32 123 to i1              ; yields i1:true
    -  %Z = trunc i32 122 to i1              ; yields i1:false
    +  %X = trunc i32 257 to i8                        ; yields i8:1
    +  %Y = trunc i32 123 to i1                        ; yields i1:true
    +  %Z = trunc i32 122 to i1                        ; yields i1:false
    +  %W = trunc <2 x i16> <i16 8, i16 7> to <2 x i8> ; yields <i8 8, i8 7>
     
    @@ -4578,10 +4623,11 @@ entry:
    Arguments:
    -

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

    The 'zext' instruction takes a value to cast, and a type to cast it to. + Both types must be of integer types, or vectors + of the same number of integers. + The bit size of the value must be smaller than + the bit size of the destination type, ty2.

    Semantics:
    @@ -4594,6 +4640,7 @@ entry:
       %X = zext i32 257 to i64              ; yields i64:257
       %Y = zext i1 true to i32              ; yields i32:1
    +  %Z = zext <2 x i16> <i16 8, i16 7> to <2 x i32> ; yields <i32 8, i32 7>
     
    @@ -4613,10 +4660,11 @@ entry:

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

    Arguments:
    -

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

    The 'sext' instruction takes a value to cast, and a type to cast it to. + Both types must be of integer types, or vectors + of the same number of integers. + The bit size of the value must be smaller than + the bit size of the destination type, ty2.

    Semantics:
    @@ -4630,6 +4678,7 @@ entry:
       %X = sext i8  -1 to i16              ; yields i16   :65535
       %Y = sext i1 true to i32             ; yields i32:-1
    +  %Z = sext <2 x i16> <i16 8, i16 7> to <2 x i32> ; yields <i32 8, i32 7>
     
    @@ -6117,8 +6166,8 @@ LLVM.

    Syntax:

    This is an overloaded intrinsic. You can use llvm.memset on any integer bit - width and for different address spaces. 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.p0i8.i32(i8* <dest>, i8 <val>,
    @@ -6132,14 +6181,14 @@ LLVM.

    particular byte value.

    Note that, unlike the standard libc function, the llvm.memset - intrinsic does not return a value, takes extra alignment/volatile arguments, - and the destination can be in an arbitrary address space.

    + 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 intrinsic has an alignment value that is not 0 or 1, then the caller guarantees that the destination pointer is aligned to that @@ -7519,7 +7568,7 @@ LLVM.

    Syntax:
    -  declare {}* @llvm.invariant.start(i64 <size>, i8* nocapture <ptr>) readonly
    +  declare {}* @llvm.invariant.start(i64 <size>, i8* nocapture <ptr>)
     
    Overview:
    @@ -7694,7 +7743,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.

    @@ -7714,25 +7763,24 @@ LLVM.

    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.