X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.html;h=1b94ab5a9a705faa034ac9f76a3faac702937e03;hb=83821c8941b7e9e70de9d5e76556b07872ac371b;hp=7cfa05205cead0d9264a0acfdabdf00c95d263c7;hpb=e1d50cd5e4ff7f4d977cc8bda720a58737e7cf8d;p=oota-llvm.git diff --git a/docs/LangRef.html b/docs/LangRef.html index 7cfa05205ce..1b94ab5a9a7 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -255,6 +255,12 @@
  • 'llvm.umul.with.overflow.* Intrinsics
  • +
  • Half Precision Floating Point Intrinsics +
      +
    1. 'llvm.convert.to.fp16' Intrinsic
    2. +
    3. 'llvm.convert.from.fp16' Intrinsic
    4. +
    +
  • Debugger intrinsics
  • Exception Handling intrinsics
  • Trampoline Intrinsic @@ -691,9 +697,9 @@ define i32 @main() { ; i32()* target, without having to conform to an externally specified ABI (Application Binary Interface). Tail calls can only be optimized - when this convention is used. This calling convention does not - support varargs and requires the prototype of all callees to exactly match - the prototype of the function definition. + when this or the GHC convention is used. This calling convention + does not support varargs and requires the prototype of all callees to + exactly match the prototype of the function definition.
    "coldcc" - The cold calling convention:
    This calling convention attempts to make code in the caller as efficient @@ -703,6 +709,26 @@ define i32 @main() { ; i32()* does not support varargs and requires the prototype of all callees to exactly match the prototype of the function definition.
    +
    "cc 10" - GHC convention:
    +
    This calling convention has been implemented specifically for use by the + Glasgow Haskell Compiler (GHC). + It passes everything in registers, going to extremes to achieve this by + disabling callee save registers. This calling convention should not be + used lightly but only for specific situations such as an alternative to + the register pinning performance technique often used when + implementing functional programming languages.At the moment only X86 + supports this convention and it has the following limitations: + + This calling convention supports + tail call optimization but + requires both the caller and callee are using it. +
    +
    "cc <n>" - Numbered convention:
    Any calling convention may be specified by number, allowing target-specific calling conventions to be used. Target specific calling @@ -2490,6 +2516,31 @@ call void asm alignstack "eieio", ""() 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 another document that covers inline asm from a holistic perspective.

    + + + + +
    + +

    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 + errors through the LLVMContext error reporting mechanisms. This allows a + front-end to corrolate backend errors that occur with inline asm back to the + source code that produced it. For example:

    + +
    +
    +call void asm sideeffect "something bad", ""(), !srcloc !42
    +...
    +!42 = !{ i32 1234567 }
    +
    +
    + +

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

    @@ -2656,7 +2707,7 @@ Instructions control flow, not values (the one exception being the 'invoke' instruction).

    -

    There are six different terminator instructions: the +

    There are seven different terminator instructions: the 'ret' instruction, the 'br' instruction, the 'switch' instruction, the @@ -5149,8 +5200,11 @@ Loop: ; Infinite loop that counts from 0 on up... a ret instruction. If the "tail" marker is present, the function call is eligible for tail call optimization, but might not in fact be - optimized into a jump. As of this writing, the extra requirements for - a call to actually be optimized are: + optimized into a jump. The code generator may optimize calls marked + "tail" with either 1) automatic + sibling call optimization when the caller and callee have + matching signatures, or 2) forced tail call optimization when the + following extra requirements are met: