X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.html;h=6267cf806cc5b9ca4f6b41a836b1bba5aeae8918;hb=17bcde9f9b18e1076a9f20d1dcd3b4a8e9985352;hp=f6895a09ee7e179b2f70456f13b2f78c631cf393;hpb=8c6c72d0bae4f2a2cf28a45fb3bc4bb44e15001f;p=oota-llvm.git diff --git a/docs/LangRef.html b/docs/LangRef.html index f6895a09ee7..6267cf806cc 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -26,19 +26,24 @@
  • Functions
  • Aliases
  • Parameter Attributes
    • +
  • Garbage Collector Names
  • Module-Level Inline Assembly
  • Data Layout
  • Type System
      +
    1. Type Classifications
    2. Primitive Types
        -
      1. Type Classifications
        2. +
      2. Floating Point Types
        3. +
      3. Void Type
        4. +
      4. Label Type
    3. Derived Types
        +
      1. Integer Type
      2. Array Type
      3. Function Type
      4. Pointer Type
        5. @@ -199,14 +204,19 @@
      5. 'llvm.init.trampoline' Intrinsic
      4. +
    4. Atomic intrinsics +
        +
      1. llvm.memory_barrier
        2. +
      +
    5. General intrinsics
      1. llvm.var.annotation' Intrinsic
        2. -
      -
      1. llvm.annotation.*' Intrinsic
        2. +
      2. + llvm.trap' Intrinsic
    @@ -667,6 +677,12 @@ variables always define a pointer to their "content" type because they describe a region of memory, and all memory objects in LLVM are accessed through pointers.

    +

    A global variable may be declared to reside in a target-specifc numbered +address space. For targets that support them, address spaces may affect how +optimizations are performed and/or what target instructions are used to access +the variable. The default address space is zero. The address space qualifier +must precede any other attributes.

    +

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

    @@ -676,12 +692,12 @@ to whatever it feels convenient. If an explicit alignment is specified, the global is forced to have at least that much alignment. All alignments must be a power of 2.

    -

    For example, the following defines a global with an initializer, section, - and alignment:

    +

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

    -@G = constant float 1.0, section "foo", align 4
+@G = constant float 1.0 addrspace(5), section "foo", align 4
    @@ -702,15 +718,16 @@ an optional linkage type, an optional parameter attribute for the return type, a function name, a (possibly empty) argument list (each with optional parameter attributes), an optional section, an -optional alignment, an opening curly brace, a list of basic blocks, and a -closing curly brace. +optional alignment, an optional garbage collector name, an +opening curly brace, a list of basic blocks, and a closing curly brace. 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 parameter attribute for the return type, a function -name, a possibly empty list of arguments, and an optional alignment.

    +name, a possibly empty list of arguments, an optional alignment, and an optional +garbage collector name.

    A function definition contains a list of basic blocks, forming the CFG for the function. Each basic block may optionally start with a label (giving the @@ -764,9 +781,9 @@ a power of 2.

    The return type and each parameter of a function type may have a set of parameter attributes associated with them. Parameter attributes are used to communicate additional information about the result or parameters of - a function. Parameter attributes are considered to be part of the function - type so two functions types that differ only by the parameter attributes - are different function types.

    + a function. Parameter attributes are considered to be part of the function, + not of the function type, so functions with different parameter attributes + can have the same function type.

    Parameter attributes are simple keywords that follow the type specified. If multiple parameter attributes are needed, they are space separated. For @@ -774,49 +791,88 @@ a power of 2.

    -%someFunc = i16 (i8 signext %someParam) zeroext
-%someFunc = i16 (i8 zeroext %someParam) zeroext
+declare i32 @printf(i8* noalias , ...) nounwind
+declare i32 @atoi(i8*) nounwind readonly
    -

    Note that the two function types above are unique because the parameter has - a different attribute (signext in the first one, zeroext in - the second). Also note that the attribute for the function result - (zeroext) comes immediately after the argument list.

    +

    Note that any attributes for the function result (nounwind, + readonly) come immediately after the argument list.

    Currently, only the following parameter attributes are defined:

    zeroext
    This indicates that the parameter should be zero extended just before a call to this function.
    +
    signext
    This indicates that the parameter should be sign extended just before a call to this function.
    +
    inreg
    This indicates that the parameter should be placed in register (if possible) during assembling function call. Support for 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 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 + value, but is also valid on scalars (even though this is silly).
    +
    sret
    This indicates that the parameter specifies the address of a structure that is the return value of the function in the source program.
    +
    noalias
    This indicates that the parameter not alias any other object or any other "noalias" objects during the function call. +
    noreturn
    This function attribute indicates that the function never returns. This indicates to LLVM that every call to this function should be treated as if an unreachable instruction immediately followed the call.
    +
    nounwind
    This function attribute indicates that the function type does not use the unwind instruction and does not allow stack unwinding to propagate through it.
    +
    nest
    This indicates that the parameter can be excised using the trampoline intrinsics.
    +
    readonly
    +
    This function attribute indicates that the function has no side-effects + except for producing a return value or throwing an exception. The value + returned must only depend on the function arguments and/or global variables. + It may use values obtained by dereferencing pointers.
    +
    readnone
    +
    A readnone function has the same restrictions as a readonly + function, but in addition it is not allowed to dereference any pointer arguments + or global variables.
    + +
    + Garbage Collector Names +
    + +
    +

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

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

    The compiler declares the supported values of name. Specifying a +collector which will cause the compiler to alter its output in order to support +the named garbage collection algorithm.

    +
    +
    Module-Level Inline Assembly @@ -941,59 +997,49 @@ three address code representations.

    -
    Primitive Types
    -
    -

    The primitive types are the fundamental building blocks of the LLVM -system. The current set of primitive types is as follows:

    - - - - - - -
    - - - - - - -
    TypeDescription
    voidNo value
    labelBranch destination
    -     		- - - - - - -
    TypeDescription
    float32-bit floating point value
    double64-bit floating point value
    -
    -
    - - -
    Type +
    Type Classifications
    -

    These different primitive types fall into a few useful +

    The types fall into a few useful classifications:

    - + - - + + - + + + + + + +
    ClassificationTypes
    integerinteger i1, i2, i3, ... i8, ... i16, ... i32, ... i64, ...
    floating pointfloat, doublefloating pointfloat, double, x86_fp80, fp128, ppc_fp128
    first classi1, ..., float, double,
    - pointer,vector     +     		integer, + floating point, + pointer, + vector
    primitivelabel, + void, + integer, + floating point.
    derivedinteger, + array, + function, + pointer, + structure, + packed structure, + vector, + opaque. +
    @@ -1004,6 +1050,60 @@ instructions. This means that all structures and arrays must be manipulated either by pointer or by component.

    + +
    Primitive Types
    + +
    +

    The primitive types are the fundamental building blocks of the LLVM +system.

    + +
    + + +
    Floating Point Types
    + +
    + + + + + + + + + +
    TypeDescription
    float32-bit floating point value
    double64-bit floating point value
    fp128128-bit floating point value (112-bit mantissa)
    x86_fp8080-bit floating point value (X87)
    ppc_fp128128-bit floating point value (two 64-bits)
    +
    + + +
    Void Type
    + +
    +
    Overview:
    +

    The void type does not represent any value and has no size.

    + +
    Syntax:
    + +
    +  void
+
    +
    + + +
    Label Type
    + +
    +
    Overview:
    +

    The label type represents code labels.

    + +
    Syntax:
    + +
    +  label
+
    +
    + +
    Derived Types
    @@ -1037,28 +1137,18 @@ value.

    Examples:
    - - - + + + + + + + + + + +
    - i1
    - i4
    - i8
    - i16
    - i32
    - i42
    - i64
    - i1942652
    -     		- A boolean integer of 1 bit
    - A nibble sized integer of 4 bits.
    - A byte sized integer of 8 bits.
    - A half word sized integer of 16 bits.
    - A word sized integer of 32 bits.
    - An integer whose bit width is the answer.
    - A double word sized integer of 64 bits.
    - A really big integer of over 1 million bits.
    -
    i1a single-bit integer.
    i32a 32-bit integer.
    i1942652a really big integer of over 1 million bits.
    @@ -1085,31 +1175,31 @@ be any type with a size.

    Examples:
    - - + + + + + + + + + +
    - [40 x i32 ]
    - [41 x i32 ]
    - [40 x i8]
    -     		- Array of 40 32-bit integer values.
    - Array of 41 32-bit integer values.
    - Array of 40 8-bit integer values.
    -     		[40 x i32]Array of 40 32-bit integer values.
    [41 x i32]Array of 41 32-bit integer values.
    [4 x i8]Array of 4 8-bit integer values.

    Here are some examples of multidimensional arrays:

    - - + + + + + + + + + +
    - [3 x [4 x i32]]
    - [12 x [10 x float]]
    - [2 x [3 x [4 x i16]]]
    -     		- 3x4 array of 32-bit integer values.
    - 12x10 array of single precision floating point values.
    - 2x3x4 array of 16-bit integer values.
    -     		[3 x [4 x i32]]3x4 array of 32-bit integer values.
    [12 x [10 x float]]12x10 array of single precision floating point values.
    [2 x [3 x [4 x i16]]]2x3x4 array of 16-bit integer values.
    @@ -1216,7 +1306,7 @@ instruction.

    < { i32, i32, i32 } > A triple of three i32 values - < { float, i32 (i32) * } > + < { float, i32 (i32)* } > A pair, where the first element is a float and the second element is a pointer to a function that takes an i32, returning @@ -1230,23 +1320,29 @@ instruction.

    Overview:

    As in many languages, the pointer type represents a pointer or -reference to another object, which must live in memory.

    +reference to another object, which must live in memory. Pointer types may have +an optional address space attribute defining the target-specific numbered +address space where the pointed-to object resides. The default address space is +zero.

    Syntax:
      <type> *
    Examples:
    - - + + + + + + i32. + + + +
    - [4x i32]*
    - i32 (i32 *) *
    -     		- A pointer to array of - four i32 values
    - A pointer to a [4x i32]*    		A pointer to array of four i32 values.
    i32 (i32 *) * A pointer to a function that takes an i32*, returning an - i32.
    -
    i32 addrspace(5)*A pointer to an i32 value + that resides in address space #5.
    @@ -1278,16 +1374,16 @@ be any integer or floating point type.

    - - + + + + + + + + + +
    - <4 x i32>
    - <8 x float>
    - <2 x i64>
    -     		- Vector of 4 32-bit integer values.
    - Vector of 8 floating-point values.
    - Vector of 2 64-bit integer values.
    -     		<4 x i32>Vector of 4 32-bit integer values.
    <8 x float>Vector of 8 32-bit floating-point values.
    <2 x i64>Vector of 2 64-bit integer values.
    @@ -1313,12 +1409,8 @@ structure type).

    - - + +
    - opaque - - An opaque type.
    -     		opaqueAn opaque type.
    @@ -1393,8 +1485,8 @@ and smaller aggregate constants.

    Structure constants are represented with notation similar to structure type definitions (a comma separated list of elements, surrounded by braces - ({})). For example: "{ i32 4, float 17.0, i32* %G }", - where "%G" is declared as "@G = external global i32". Structure constants + ({})). For example: "{ i32 4, float 17.0, i32* @G }", + where "@G" is declared as "@G = external global i32". Structure constants must have structure type, and the number and types of elements must match those specified by the type.
    @@ -1502,23 +1594,31 @@ following is the syntax for constant expressions:

    fptoui ( CST to TYPE )
    Convert a floating point constant to the corresponding unsigned integer - constant. TYPE must be an integer type. CST must be floating point. If the - value won't fit in the integer type, the results are undefined.
    + constant. TYPE must be a scalar or vector integer type. CST must be of scalar + or vector floating point type. Both CST and TYPE must be scalars, or vectors + of the same number of elements. If the value won't fit in the integer type, + the results are undefined.
    fptosi ( CST to TYPE )
    Convert a floating point constant to the corresponding signed integer - constant. TYPE must be an integer type. CST must be floating point. If the - value won't fit in the integer type, the results are undefined.
    + constant. TYPE must be a scalar or vector integer type. CST must be of scalar + or vector floating point type. Both CST and TYPE must be scalars, or vectors + of the same number of elements. If the value won't fit in the integer type, + the results are undefined.
    uitofp ( CST to TYPE )
    Convert an unsigned integer constant to the corresponding floating point - constant. TYPE must be floating point. CST must be of integer type. If the - value won't fit in the floating point type, the results are undefined.
    + constant. TYPE must be a scalar or vector floating point type. CST must be of + scalar or vector integer type. Both CST and TYPE must be scalars, or vectors + of the same number of elements. If the value won't fit in the floating point + type, the results are undefined.
    sitofp ( CST to TYPE )
    Convert a signed integer constant to the corresponding floating point - constant. TYPE must be floating point. CST must be of integer type. If the - value won't fit in the floating point type, the results are undefined.
    + constant. TYPE must be a scalar or vector floating point type. CST must be of + scalar or vector integer type. Both CST and TYPE must be scalars, or vectors + of the same number of elements. If the value won't fit in the floating point + type, the results are undefined.
    ptrtoint ( CST to TYPE )
    Convert a pointer typed constant to the corresponding integer constant @@ -1956,6 +2056,11 @@ Both arguments must have identical types.

    Semantics:

    The value produced is the integer or floating point sum of the two operands.

    +

    If an integer sum has unsigned overflow, the result returned is the +mathematical result modulo 2n, where n is the bit width of +the result.

    +

    Because LLVM integers use a two's complement representation, this +instruction is appropriate for both signed and unsigned integers.

    Example:
      <result> = add i32 4, %var          ; yields {i32}:result = 4 + %var
    @@ -1981,6 +2086,11 @@ Both arguments must have identical types.

    Semantics:

    The value produced is the integer or floating point difference of the two operands.

    +

    If an integer difference has unsigned overflow, the result returned is the +mathematical result modulo 2n, where n is the bit width of +the result.

    +

    Because LLVM integers use a two's complement representation, this +instruction is appropriate for both signed and unsigned integers.

    Example:
       <result> = sub i32 4, %var          ; yields {i32}:result = 4 - %var
@@ -2006,9 +2116,15 @@ Both arguments must have identical types.
    
 
    Semantics:
    
 
    The value produced is the integer or floating point product of the
 two operands.
    
-
    Because the operands are the same width, the result of an integer
-multiplication is the same whether the operands should be deemed unsigned or
-signed.
    
+
    If the result of an integer multiplication has unsigned overflow,
+the result returned is the mathematical result modulo 
+2n, where n is the bit width of the result.
    
+
    Because LLVM integers use a two's complement representation, and the
+result is the same width as the operands, this instruction returns the
+correct result for both signed and unsigned integers.  If a full product
+(e.g. i32xi32->i64) is needed, the operands
+should be sign-extended or zero-extended as appropriate to the
+width of the full product.
    
 
    Example:
    
 
      <result> = mul i32 4, %var          ; yields {i32}:result = 4 * %var
 
    
@@ -2029,9 +2145,10 @@ operands.
    
 types. This instruction can also take vector versions 
 of the values in which case the elements must be integers.
    
 
    Semantics:
    
-
    The value produced is the unsigned integer quotient of the two operands. This
-instruction always performs an unsigned division operation, regardless of 
-whether the arguments are unsigned or not.
    
+
    The value produced is the unsigned integer quotient of the two operands.
    
+
    Note that unsigned integer division and signed integer division are distinct
+operations; for signed integer division, use 'sdiv'.
    
+
    Division by zero leads to undefined behavior.
    
 
    Example:
    
 
      <result> = udiv i32 4, %var          ; yields {i32}:result = 4 / %var
 
    
@@ -2052,9 +2169,12 @@ operands.
    
 types. This instruction can also take vector versions 
 of the values in which case the elements must be integers.
    
 
    Semantics:
    
-
    The value produced is the signed integer quotient of the two operands. This
-instruction always performs a signed division operation, regardless of whether
-the arguments are signed or not.
    
+
    The value produced is the signed integer quotient of the two operands.
    
+
    Note that signed integer division and unsigned integer division are distinct
+operations; for unsigned integer division, use 'udiv'.
    
+
    Division by zero leads to undefined behavior. Overflow also leads to
+undefined behavior; this is a rare case, but can occur, for example,
+by doing a 32-bit division of -2147483648 by -1.
    
 
    Example:
    
 
      <result> = sdiv i32 4, %var          ; yields {i32}:result = 4 / %var
 
    
@@ -2093,11 +2213,15 @@ unsigned division of its two arguments.
    
 
    Arguments:
    
 
    The two arguments to the 'urem' instruction must be
 integer values. Both arguments must have identical
-types.
    
+types. This instruction can also take vector versions 
+of the values in which case the elements must be integers.
    
 
    Semantics:
    
 
    This instruction returns the unsigned integer remainder of a division.
 This instruction always performs an unsigned division to get the remainder,
 regardless of whether the arguments are unsigned or not.
    
+
    Note that unsigned integer remainder and signed integer remainder are
+distinct operations; for signed integer remainder, use 'srem'.
    
+
    Taking the remainder of a division by zero leads to undefined behavior.
    
 
    Example:
    
 
      <result> = urem i32 4, %var          ; yields {i32}:result = 4 % %var
 
    
@@ -2112,7 +2236,10 @@ Instruction
    Overview:

    The 'srem' instruction returns the remainder from the -signed division of its two operands.

    +signed division of its two operands. This instruction can also take +vector versions of the values in which case +the elements must be integers.

    +
    Arguments:

    The two arguments to the 'srem' instruction must be integer values. Both arguments must have identical @@ -2126,6 +2253,14 @@ a value. For more information about the difference, see . For a table of how this is implemented in various languages, please see Wikipedia: modulo operation.

    +

    Note that signed integer remainder and unsigned integer remainder are +distinct operations; for unsigned integer remainder, use 'urem'.

    +

    Taking the remainder of a division by zero leads to undefined behavior. +Overflow also leads to undefined behavior; this is a rare case, but can occur, +for example, by taking the remainder of a 32-bit division of -2147483648 by -1. +(The remainder doesn't actually overflow, but this rule lets srem be +implemented using instructions that return both the result of the division +and the remainder.)

    Example:
      <result> = srem i32 4, %var          ; yields {i32}:result = 4 % %var
    @@ -2144,7 +2279,8 @@ division of its two operands.

    Arguments:

    The two arguments to the 'frem' instruction must be floating point values. Both arguments must have -identical types.

    +identical types. This instruction can also take vector +versions of floating point values.

    Semantics:

    This instruction returns the remainder of a division.

    Example:
    @@ -2620,7 +2756,8 @@ allocate, and free memory in LLVM.

    Overview:

    The 'malloc' instruction allocates memory from the system -heap and returns a pointer to it.

    +heap and returns a pointer to it. The object is always allocated in the generic +address space (address space zero).

    Arguments:
    @@ -2628,10 +2765,10 @@ heap and returns a pointer to it.

    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. If an 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.

    +number of elements allocated, otherwise "NumElements" is defaulted to be one. +If an 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.

    'type' must be a sized type.

    @@ -2707,17 +2844,18 @@ after this instruction executes.

    The 'alloca' instruction allocates memory on the stack frame of the currently executing function, to be automatically released when this function -returns to its caller.

    +returns to its caller. The object is always allocated in the generic address +space (address space zero).

    Arguments:

    The 'alloca' instruction allocates sizeof(<type>)*NumElements bytes of memory on the runtime stack, returning a pointer of the -appropriate type to the program. If "NumElements" is specified, it is the -number of elements allocated. If an 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.

    +appropriate type to the program. If "NumElements" is specified, it is the +number of elements allocated, otherwise "NumElements" is defaulted to be one. +If an 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.

    'type' may be any sized type.

    @@ -2756,6 +2894,16 @@ marked as volatile, then the optimizer is not allowed to modify the number or order of execution of this load with other volatile load and store instructions.

    +

    +The optional "align" argument specifies the alignment of the operation +(that is, the alignment of the memory address). A value of 0 or an +omitted "align" argument means that the operation has the preferential +alignment for the target. It is the responsibility of the code emitter +to ensure that the alignment information is correct. Overestimating +the alignment results in an undefined behavior. Underestimating the +alignment may produce less efficient code. An alignment of 1 is always +safe. +

    Semantics:

    The location of memory pointed to is loaded.

    Examples:
    @@ -2783,6 +2931,16 @@ operand. If the store is marked as volatile, then the optimizer is not allowed to modify the number or order of execution of this store with other volatile load and store instructions.

    +

    +The optional "align" argument specifies the alignment of the operation +(that is, the alignment of the memory address). A value of 0 or an +omitted "align" argument means that the operation has the preferential +alignment for the target. It is the responsibility of the code emitter +to ensure that the alignment information is correct. Overestimating +the alignment results in an undefined behavior. Underestimating the +alignment may produce less efficient code. An alignment of 1 is always +safe. +

    Semantics:

    The contents of memory are updated to contain '<value>' at the location specified by the '<pointer>' operand.

    @@ -3122,8 +3280,10 @@ unsigned integer equivalent of type ty2.
    Arguments:

    The 'fptoui' instruction takes a value to cast, which must be a -floating point value, and a type to cast it to, which -must be an integer type.

    +scalar or vector floating point value, and a type +to cast it to ty2, which must be an integer +type. If ty is a vector floating point type, ty2 must be a +vector integer type with the same number of elements as ty

    Semantics:

    The 'fptoui' instruction converts its @@ -3155,11 +3315,12 @@ the results are undefined.

    floating point value to type ty2.

    -
    Arguments:

    The 'fptosi' instruction takes a value to cast, which must be a -floating point value, and a type to cast it to, which -must also be an integer type.

    +scalar or vector floating point value, and a type +to cast it to ty2, which must be an integer +type. If ty is a vector floating point type, ty2 must be a +vector integer type with the same number of elements as ty

    Semantics:

    The 'fptosi' instruction converts its @@ -3190,18 +3351,18 @@ the results are undefined.

    The 'uitofp' instruction regards value as an unsigned integer and converts that value to the ty2 type.

    -
    Arguments:
    -

    The 'uitofp' instruction takes a value to cast, which must be an -integer value, and a type to cast it to, which must -be a floating point type.

    +

    The 'uitofp' instruction takes a value to cast, which must be a +scalar or vector integer value, and a type to cast it +to ty2, which must be an floating point +type. If ty is a vector integer type, ty2 must be a vector +floating point type with the same number of elements as ty

    Semantics:

    The 'uitofp' instruction interprets its operand as an unsigned integer quantity and converts it to the corresponding floating point value. If the value cannot fit in the floating point value, the results are undefined.

    -
    Example:
       %X = uitofp i32 257 to float         ; yields float:257.0
@@ -3225,9 +3386,11 @@ the value cannot fit in the floating point value, the results are undefined.
    
 integer and converts that value to the ty2 type.
    
 
 
    Arguments:
    
-
    The 'sitofp' instruction takes a value to cast, which must be an
-integer value, and a type to cast it to, which must be
-a floating point type.
    
+
    The 'sitofp' instruction takes a value to cast, which must be a
+scalar or vector integer value, and a type to cast it
+to ty2, which must be an floating point 
+type. If ty is a vector integer type, ty2 must be a vector
+floating point type with the same number of elements as ty
    
 
 
    Semantics:
    
 
    The 'sitofp' instruction interprets its operand as a signed
@@ -3916,6 +4079,10 @@ Front-ends for type-safe garbage collected languages should generate these
 intrinsics to make use of the LLVM garbage collectors.  For more details, see Accurate Garbage Collection with LLVM.
 
    
+
+
    The garbage collection intrinsics only operate on objects in the generic 
+	address space (address space zero).
    
+
 
 
 
@@ -3946,8 +4113,9 @@ value address) contains the meta-data to be associated with the root.
    
 
 
    At runtime, a call to this intrinsics stores a null pointer into the "ptrloc"
 location.  At compile-time, the code generator generates information to allow
-the runtime to find the pointer at GC safe points.
-
    
+the runtime to find the pointer at GC safe points. The 'llvm.gcroot'
+intrinsic may only be used in a function which specifies a GC
+algorithm.
    
 
 
 
@@ -3982,7 +4150,9 @@ null).
    
 
 
    The 'llvm.gcread' intrinsic has the same semantics as a load
 instruction, but may be replaced with substantially more complex code by the
-garbage collector runtime, as needed.
    
+garbage collector runtime, as needed. The 'llvm.gcread' intrinsic
+may only be used in a function which specifies a GC
+algorithm.
    
 
 
 
@@ -4017,7 +4187,9 @@ null.
    
 
 
    The 'llvm.gcwrite' intrinsic has the same semantics as a store
 instruction, but may be replaced with substantially more complex code by the
-garbage collector runtime, as needed.
    
+garbage collector runtime, as needed. The 'llvm.gcwrite' intrinsic
+may only be used in a function which specifies a GC
+algorithm.
    
 
 
 
@@ -4397,7 +4569,7 @@ be set to 0 or 1.
 
    
 The 'llvm.memmove.*' intrinsics move a block of memory from the source
 location to the destination location. It is similar to the
-'llvm.memcmp' intrinsic but allows the two memory locations to overlap.
+'llvm.memcpy' intrinsic but allows the two memory locations to overlap.
 
    
 
 
    
@@ -4510,7 +4682,9 @@ types however.
 The 'llvm.sqrt' intrinsics return the sqrt of the specified operand,
 returning the same value as the libm 'sqrt' functions would.  Unlike
 sqrt in libm, however, llvm.sqrt has undefined behavior for
-negative numbers (which allows for better optimization).
+negative numbers other than -0.0 (which allows for better optimization, because
+there is no need to worry about errno being set).  llvm.sqrt(-0.0) is
+defined to return -0.0 like IEEE sqrt.
 
    
 
 
    Arguments:
    
@@ -5063,6 +5237,107 @@ declare i8* @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <n
 
    
 
 
+
+
    
+  Atomic Operations and Synchronization Intrinsics
+
    
+
+
    
+
    
+  These intrinsic functions expand the "universal IR" of LLVM to represent 
+  hardware constructs for atomic operations and memory synchronization.  This 
+  provides an interface to the hardware, not an interface to the programmer. It 
+  is aimed at a low enough level to allow any programming models or APIs which 
+  need atomic behaviors to map cleanly onto it. It is also modeled primarily on 
+  hardware behavior. Just as hardware provides a "universal IR" for source 
+  languages, it also provides a starting point for developing a "universal" 
+  atomic operation and synchronization IR.
+
    
+
    
+  These do not form an API such as high-level threading libraries, 
+  software transaction memory systems, atomic primitives, and intrinsic 
+  functions as found in BSD, GNU libc, atomic_ops, APR, and other system and 
+  application libraries.  The hardware interface provided by LLVM should allow 
+  a clean implementation of all of these APIs and parallel programming models. 
+  No one model or paradigm should be selected above others unless the hardware 
+  itself ubiquitously does so.
+
+
    
+
    
+
+
+
    
+  'llvm.memory.barrier' Intrinsic
+
    
+
    
+
    Syntax:
    
+
    +declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, 
+i1 <device> )
+
+
    
+
    Overview:
    
+
    
+  The llvm.memory.barrier intrinsic guarantees ordering between 
+  specific pairs of memory access types.
+
    
+
    Arguments:
    
+
    
+  The llvm.memory.barrier intrinsic requires five boolean arguments. 
+  The first four arguments enables a specific barrier as listed below.  The fith
+  argument specifies that the barrier applies to io or device or uncached memory.
+
+
    
+  
      
+    
    • ll: load-load barrier
      • 
+    
    • ls: load-store barrier
      • 
+    
    • sl: store-load barrier
      • 
+    
    • ss: store-store barrier
      • 
+    
    • device: barrier applies to device and uncached memory also.
+  
    
+
    Semantics:
    
+
    
+  This intrinsic causes the system to enforce some ordering constraints upon 
+  the loads and stores of the program. This barrier does not indicate 
+  when any events will occur, it only enforces an order in 
+  which they occur. For any of the specified pairs of load and store operations 
+  (f.ex.  load-load, or store-load), all of the first operations preceding the 
+  barrier will complete before any of the second operations succeeding the 
+  barrier begin. Specifically the semantics for each pairing is as follows:
+
    
+  
      
+    
    • 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 
+    store after the barrier begins.
      • 
+    
    • 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 
+    load after the barrier begins.
      • 
+  
    
+
    
+  These semantics are applied with a logical "and" behavior when more than  one 
+  is enabled in a single memory barrier intrinsic.  
+
    
+
    
+  Backends may implement stronger barriers than those requested when they do not
+  support as fine grained a barrier as requested.  Some architectures do not
+  need all types of barriers and on such architectures, these become noops.
+
    
+
    Example:
    
+
    +%ptr      = malloc i32
+            store i32 4, %ptr
+
+%result1  = load i32* %ptr      ; yields {i32}:result1 = 4
+            call void @llvm.memory.barrier( i1 false, i1 true, i1 false, i1 false )
+                                ; guarantee the above finishes
+            store i32 8, %ptr   ; before this begins
+
    
+
    
+
+
 
 
    
   General Intrinsics
@@ -5102,10 +5377,11 @@ file name, and the last argument is the line number.
 
    Semantics:
    
 
 
    
-This intrinsic allows annotation of local variables with arbitrary strings.  
+This intrinsic allows annotation of local variables with arbitrary strings.
 This can be useful for special purpose optimizations that want to look for these
- annotations.  These have no other defined use, they are ignored by code 
- generation and optimization.
+annotations.  These have no other defined use, they are ignored by code
+generation and optimization.
+
    
 
    
 
 
@@ -5151,17 +5427,51 @@ that want to look for these annotations.  These have no other defined use, they
 are ignored by code generation and optimization.
 
 
+
+
    
+  'llvm.trap' Intrinsic
+
    
+
+
    
+
+
    Syntax:
    
+
    +  declare void @llvm.trap()
+
    
+
+
    Overview:
    
+
+
    
+The 'llvm.trap' intrinsic
+
    
+
+
    Arguments:
    
+
+
    
+None
+
    
+
+
    Semantics:
    
+
+
    
+This intrinsics is lowered to the target dependent trap instruction. If the
+target does not have a trap instruction, this intrinsic will be lowered to the
+call of the abort() function.
+
    
+
    
+
 
 
    
 
    
   Valid CSS!
   Valid HTML 4.01!
+  src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!">
 
   Chris Lattner
    
   The LLVM Compiler Infrastructure
    
   Last modified: $Date$
 
    
+