llvm.org GIT mirror llvm / b627eab
Minor corrections. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36548 91177308-0d34-0410-b5e6-96231b3b80d8 Jeff Cohen 13 years ago
1 changed file(s) with 60 addition(s) and 61 deletion(s). Raw diff Collapse all Expand all
30963096
Example:
30973097

                  
                
30983098 %X = uitofp i32 257 to float ; yields float:257.0
3099 %Y = uitofp i8 -1 to double ; yields double:255.0
3099 %Y = uitofp i8 -1 to double ; yields double:255.0
31003100
31013101
31023102
31283128
Example:
31293129

                  
                
31303130 %X = sitofp i32 257 to float ; yields float:257.0
3131 %Y = sitofp i8 -1 to double ; yields double:-1.0
3131 %Y = sitofp i8 -1 to double ; yields double:-1.0
31323132
31333133
31343134
31583158 truncating or zero extending that value to the size of the integer type. If
31593159 value is smaller than ty2 then a zero extension is done. If
31603160 value is larger than ty2 then a truncation is done. If they
3161 are the same size, then nothing is done (no-op cast).

3161 are the same size, then nothing is done (no-op cast) other than a type
3162 change.

31623163
31633164
Example:
31643165

                  
                
3165 %X = ptrtoint i32* %X to i8 ; yields truncation on 32-bit
3166 %Y = ptrtoint i32* %x to i64 ; yields zero extend on 32-bit
3166 %X = ptrtoint i32* %X to i8 ; yields truncation on 32-bit architecture
3167 %Y = ptrtoint i32* %x to i64 ; yields zero extension on 32-bit architecture
31673168
31683169
31693170
31973198
31983199
Example:
31993200

                  
                
3200 %X = inttoptr i32 255 to i32* ; yields zero extend on 64-bit
3201 %X = inttoptr i32 255 to i32* ; yields no-op on 32-bit
3202 %Y = inttoptr i16 0 to i32* ; yields zero extend on 32-bit
3201 %X = inttoptr i32 255 to i32* ; yields zero extension on 64-bit architecture
3202 %X = inttoptr i32 255 to i32* ; yields no-op on 32-bit architecture
3203 %Y = inttoptr i64 0 to i32* ; yields truncation on 32-bit architecture
32033204
32043205
32053206
32363237
32373238
Example:
32383239

                  
                
3239 %X = bitcast i8 255 to i8 ; yields i8 :-1
3240 %X = bitcast i8 255 to i8 ; yields i8 :-1
32403241 %Y = bitcast i32* %x to sint* ; yields sint*:%x
32413242 %Z = bitcast <2xint> %V to i64; ; yields i64: %V
32423243
32543255
32553256
32563257
Syntax:
3257
  <result> = icmp <cond> <ty> <var1>, <var2>

                  
                
3258 <i>; yields {i1}:result
3258 <pre> <result> = icmp <cond> <ty> <var1>, <var2> <i>; yields {i1}:result
32593259
32603260
Overview:
32613261

The 'icmp' instruction returns a boolean value based on comparison

32623262 of its two integer operands.

32633263
Arguments:
32643264

The 'icmp' instruction takes three operands. The first operand is

3265 the condition code which indicates the kind of comparison to perform. It is not
3266 a value, just a keyword. The possibilities for the condition code are:
3265 the condition code indicating the kind of comparison to perform. It is not
3266 a value, just a keyword. The possible condition code are:
32673267
32683268
  • eq: equal
  • 32693269
  • ne: not equal
  • 33063306 true if var1 is less than or equal to var2.
    33073307
    33083308

    If the operands are pointer typed, the pointer

    3309 values are treated as integers and then compared.

    3309 values are compared as if they were integers.

    33103310
    33113311
    Example:
    33123312
      <result> = icmp eq i32 4, 5          ; yields: result=false
    
                      
                    
    33233323
    33243324
    33253325
    Syntax:
    3326
      <result> = fcmp <cond> <ty> <var1>, <var2>
    
                      
                    
    3327 <i>; yields {i1}:result
    3326 <pre> <result> = fcmp <cond> <ty> <var1>, <var2> <i>; yields {i1}:result
    33283327
    33293328
    Overview:
    33303329

    The 'fcmp' instruction returns a boolean value based on comparison

    33313330 of its floating point operands.

    33323331
    Arguments:
    33333332

    The 'fcmp' instruction takes three operands. The first operand is

    3334 the condition code which indicates the kind of comparison to perform. It is not
    3335 a value, just a keyword. The possibilities for the condition code are:
    3333 the condition code indicating the kind of comparison to perform. It is not
    3334 a value, just a keyword. The possible condition code are:
    33363335
    33373336
  • false: no comparison, always returns false
  • 33383337
  • oeq: ordered and equal
  • 33513350
  • uno: unordered (either nans)
  • 33523351
  • true: no comparison, always returns true
  • 33533352
    3354

    In the preceding, ordered means that neither operand is a QNAN while

    3353

    Ordered means that neither operand is a QNAN while

    33553354 unordered means that either operand may be a QNAN.

    33563355

    The val1 and val2 arguments must be

    33573356 floating point typed. They must have identical
    33583357 types.

    3359

    In the foregoing, ordered means that neither operand is a QNAN and

    3360 unordered means that either operand is a QNAN.

    33613358
    Semantics:
    33623359

    The 'fcmp' compares var1 and var2 according to

    33633360 the condition code given as cond. The comparison performed always
    34113408

    The 'phi' instruction is used to implement the φ node in

    34123409 the SSA graph representing the function.

    34133410
    Arguments:
    3414

    The type of the incoming values are specified with the first type

    3411

    The type of the incoming values is specified with the first type

    34153412 field. After this, the 'phi' instruction takes a list of pairs
    34163413 as arguments, with one pair for each predecessor basic block of the
    34173414 current block. Only values of first class
    34213418 block and the PHI instructions: i.e. PHI instructions must be first in
    34223419 a basic block.

    34233420
    Semantics:
    3424

    At runtime, the 'phi' instruction logically takes on the

    3425 value specified by the parameter, depending on which basic block we
    3426 came from in the last terminator instruction.

    3421

    At runtime, the 'phi' instruction logically takes on the value

    3422 specified by the pair corresponding to the predecessor basic block that executed
    3423 just prior to the current block.

    34273424
    Example:
    34283425
    Loop:       ; Infinite loop that counts from 0 on up...
    %indvar = phi i32 [ 0, %LoopHeader ], [ %nextindvar, %Loop ]
    %nextindvar = add i32 %indvar, 1
    br label %Loop
    34293426
    35383535
    35393536
    
                      
                    
    35403537 %retval = call i32 %test(i32 %argc)
    3541 call i32(i8 *, ...) *%printf(i8 * %msg, i32 12, i8 42);
    3538 call i32(i8 *, ...) *%printf(i8 * %msg, i32 12, i8 42);
    35423539 %X = tail call i32 %foo()
    35433540 %Y = tail call fastcc i32 %foo()
    35443541
    35683565
    35693566

    This instruction takes a va_list* value and the type of

    35703567 the argument. It returns a value of the specified argument type and
    3571 increments the va_list to point to the next argument. Again, the
    3568 increments the va_list to point to the next argument. The
    35723569 actual type of va_list is target specific.

    35733570
    35743571
    Semantics:
    36023599

    LLVM supports the notion of an "intrinsic function". These functions have

    36033600 well known names and semantics and are required to follow certain restrictions.
    36043601 Overall, these intrinsics represent an extension mechanism for the LLVM
    3605 language that does not require changing all of the transformations in LLVM to
    3606 add to the language (or the bytecode reader/writer, the parser,
    3607 etc...).

    3602 language that does not require changing all of the transformations in LLVM when
    3603 adding to the language (or the bytecode reader/writer, the parser, etc...).

    36083604
    36093605

    Intrinsic function names must all start with an "llvm." prefix. This

    3610 prefix is reserved in LLVM for intrinsic names; thus, functions may not be named
    3611 this. Intrinsic functions must always be external functions: you cannot define
    3612 the body of intrinsic functions. Intrinsic functions may only be used in call
    3613 or invoke instructions: it is illegal to take the address of an intrinsic
    3614 function. Additionally, because intrinsic functions are part of the LLVM
    3615 language, it is required that they all be documented here if any are added.

    3616
    3617

    Some intrinsic functions can be overloaded. That is, the intrinsic represents

    3606 prefix is reserved in LLVM for intrinsic names; thus, function names may not
    3607 begin with this prefix. Intrinsic functions must always be external functions:
    3608 you cannot define the body of intrinsic functions. Intrinsic functions may
    3609 only be used in call or invoke instructions: it is illegal to take the address
    3610 of an intrinsic function. Additionally, because intrinsic functions are part
    3611 of the LLVM language, it is required if any are added that they be documented
    3612 here.

    3613
    3614

    Some intrinsic functions can be overloaded, i.e., the intrinsic represents

    36183615 a family of functions that perform the same operation but on different data
    36193616 types. This is most frequent with the integer types. Since LLVM can represent
    36203617 over 8 million different integer types, there is a way to declare an intrinsic
    3621 that can be overloaded based on its arguments. Such intrinsics will have the
    3622 names of the arbitrary types encoded into the intrinsic function name, each
    3618 that can be overloaded based on its arguments. Such an intrinsic will have the
    3619 names of its argument types encoded into its function name, each
    36233620 preceded by a period. For example, the llvm.ctpop function can take an
    36243621 integer of any width. This leads to a family of functions such as
    36253622 i32 @llvm.ctpop.i8(i8 %val) and i32 @llvm.ctpop.i29(i29 %val).
    36473644

    All of these functions operate on arguments that use a

    36483645 target-specific value type "va_list". The LLVM assembly
    36493646 language reference manual does not define what this type is, so all
    3650 transformations should be prepared to handle intrinsics with any type
    3651 used.

    3647 transformations should be prepared to handle these functions regardless of
    3648 the type used.

    36523649
    36533650

    This example shows how the va_arg

    36543651 instruction and the variable argument handling intrinsic functions are
    36573654
    
                      
                    
    36583655 define i32 @test(i32 %X, ...) {
    36593656 ; Initialize variable argument processing
    3660 %ap = alloca i8 *
    3657 %ap = alloca i8*
    36613658 %ap2 = bitcast i8** %ap to i8*
    36623659 call void @llvm.va_start(i8* %ap2)
    36633660
    36643661 ; Read a single integer argument
    3665 %tmp = va_arg i8 ** %ap, i32
    3662 %tmp = va_arg i8** %ap, i32
    36663663
    36673664 ; Demonstrate usage of llvm.va_copy and llvm.va_end
    3668 %aq = alloca i8 *
    3665 %aq = alloca i8*
    36693666 %aq2 = bitcast i8** %aq to i8*
    3670 call void @llvm.va_copy(i8 *%aq2, i8* %ap2)
    3667 call void @llvm.va_copy(i8* %aq2, i8* %ap2)
    36713668 call void @llvm.va_end(i8* %aq2)
    36723669
    36733670 ; Stop processing of arguments.
    37033700
    37043701

    The 'llvm.va_start' intrinsic works just like the va_start

    37053702 macro available in C. In a target-dependent way, it initializes the
    3706 va_list element the argument points to, so that the next call to
    3703 va_list element to which the argument points, so that the next call to
    37073704 va_arg will produce the first variable argument passed to the function.
    37083705 Unlike the C va_start macro, this intrinsic does not need to know the
    3709 last argument of the function, the compiler can figure that out.

    3706 last argument of the function as the compiler can figure that out.

    37103707
    37113708
    37123709
    37203717
      declare void @llvm.va_end(i8* <arglist>)
    37213718
    Overview:
    37223719
    3723

    The 'llvm.va_end' intrinsic destroys <arglist>

    3720

    The 'llvm.va_end' intrinsic destroys *<arglist>,

    37243721 which has been initialized previously with llvm.va_start
    37253722 or llvm.va_copy.

    37263723
    37273724
    Arguments:
    37283725
    3729

    The argument is a va_list to destroy.

    3726

    The argument is a pointer to a va_list to destroy.

    37303727
    37313728
    Semantics:
    37323729
    37333730

    The 'llvm.va_end' intrinsic works just like the va_end

    3734 macro available in C. In a target-dependent way, it destroys the va_list.
    3735 Calls to llvm.va_start and
    3736 href="#int_va_copy">llvm.va_copy must be matched exactly
    3737 with calls to llvm.va_end.

    3731 macro available in C. In a target-dependent way, it destroys the
    3732 va_list element to which the argument points. Calls to
    3733 href="#int_va_start">llvm.va_start and
    3734 llvm.va_copy must be matched exactly with calls to
    3735 llvm.va_end.

    37383736
    37393737
    37403738
    37533751
    37543752
    Overview:
    37553753
    3756

    The 'llvm.va_copy' intrinsic copies the current argument position from

    3757 the source argument list to the destination argument list.

    3754

    The 'llvm.va_copy' intrinsic copies the current argument position

    3755 from the source argument list to the destination argument list.

    37583756
    37593757
    Arguments:
    37603758
    37643762
    37653763
    Semantics:
    37663764
    3767

    The 'llvm.va_copy' intrinsic works just like the va_copy macro

    3768 available in C. In a target-dependent way, it copies the source
    3769 va_list element into the destination list. This intrinsic is necessary
    3770 because the llvm.va_start intrinsic may be
    3771 arbitrarily complex and require memory allocation, for example.>
    3765

    The 'llvm.va_copy' intrinsic works just like the va_copy>

    3766 macro available in C. In a target-dependent way, it copies the source
    3767 va_list element into the destination va_list element. This
    3768 intrinsic is necessary because the
    3769 llvm.va_start intrinsic may be arbitrarily complex and require, for
    3770 example, memory allocation.

    37723771
    37733772
    37743773