X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FLangRef.rst;h=7f1a97428ee2b6f4b8964ada9a66107d071f2241;hb=1d4e45c1ee080a72bae2693b385071ef33050e6d;hp=cd1fb01c652c9f0c8de5bb31467ad6c4936c84d9;hpb=43be5f580c428d40c794917273256226e8ee391c;p=oota-llvm.git diff --git a/docs/LangRef.rst b/docs/LangRef.rst index cd1fb01c652..7f1a97428ee 100644 --- a/docs/LangRef.rst +++ b/docs/LangRef.rst @@ -406,6 +406,26 @@ added in the future: This calling convention, like the `PreserveMost` calling convention, will be used by a future version of the ObjectiveC runtime and should be considered experimental at this time. +"``cxx_fast_tlscc``" - The `CXX_FAST_TLS` calling convention for access functions + Clang generates an access function to access C++-style TLS. The access + function generally has an entry block, an exit block and an initialization + block that is run at the first time. The entry and exit blocks can access + a few TLS IR variables, each access will be lowered to a platform-specific + sequence. + + This calling convention aims to minimize overhead in the caller by + preserving as many registers as possible (all the registers that are + perserved on the fast path, composed of the entry and exit blocks). + + This calling convention behaves identical to the `C` calling convention on + how arguments and return values are passed, but it uses a different set of + caller/callee-saved registers. + + Given that each platform has its own lowering sequence, hence its own set + of preserved registers, we can't use the existing `PreserveMost`. + + - On X86-64 the callee preserves all general purpose registers, except for + RDI and RAX. "``cc ``" - Numbered convention Any calling convention may be specified by number, allowing target-specific calling conventions to be used. Target specific @@ -1289,9 +1309,9 @@ example: that are recognized by LLVM to handle asynchronous exceptions, such as SEH, will still provide their implementation defined semantics. ``optnone`` - This function attribute indicates that the function is not optimized - by any optimization or code generator passes with the - exception of interprocedural optimization passes. + This function attribute indicates that most optimization passes will skip + this function, with the exception of interprocedural optimization passes. + Code generation defaults to the "fast" instruction selector. This attribute cannot be used together with the ``alwaysinline`` attribute; this attribute is also incompatible with the ``minsize`` attribute and the ``optsize`` attribute. @@ -1457,7 +1477,7 @@ incorrect and will change program semantics. Syntax:: - operand bundle set ::= '[' operand bundle ']' + operand bundle set ::= '[' operand bundle (, operand bundle )* ']' operand bundle ::= tag '(' [ bundle operand ] (, bundle operand )* ')' bundle operand ::= SSA value tag ::= string constant @@ -1493,13 +1513,14 @@ More specific types of operand bundles are described below. Deoptimization Operand Bundles ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Deoptimization operand bundles are characterized by the ``"deopt`` +Deoptimization operand bundles are characterized by the ``"deopt"`` operand bundle tag. These operand bundles represent an alternate "safe" continuation for the call site they're attached to, and can be used by a suitable runtime to deoptimize the compiled frame at the -specified call site. Exact details of deoptimization is out of scope -for the language reference, but it usually involves rewriting a -compiled frame into a set of interpreted frames. +specified call site. There can be at most one ``"deopt"`` operand +bundle attached to a call site. Exact details of deoptimization is +out of scope for the language reference, but it usually involves +rewriting a compiled frame into a set of interpreted frames. From the compiler's perspective, deoptimization operand bundles make the call sites they're attached to at least ``readonly``. They read @@ -3730,9 +3751,9 @@ DICompileUnit """"""""""""" ``DICompileUnit`` nodes represent a compile unit. The ``enums:``, -``retainedTypes:``, ``subprograms:``, ``globals:`` and ``imports:`` fields are -tuples containing the debug info to be emitted along with the compile unit, -regardless of code optimizations (some nodes are only emitted if there are +``retainedTypes:``, ``subprograms:``, ``globals:``, ``imports:`` and ``macros:`` +fields are tuples containing the debug info to be emitted along with the compile +unit, regardless of code optimizations (some nodes are only emitted if there are references to them from instructions). .. code-block:: llvm @@ -3741,7 +3762,7 @@ references to them from instructions). isOptimized: true, flags: "-O2", runtimeVersion: 2, splitDebugFilename: "abc.debug", emissionKind: 1, enums: !2, retainedTypes: !3, subprograms: !4, - globals: !5, imports: !6) + globals: !5, imports: !6, macros: !7, dwoId: 0x0abcd) Compile unit descriptors provide the root scope for objects declared in a specific compilation unit. File descriptors are defined using this scope. @@ -4107,6 +4128,32 @@ compile unit. !2 = !DIImportedEntity(tag: DW_TAG_imported_module, name: "foo", scope: !0, entity: !1, line: 7) +DIMacro +""""""" + +``DIMacro`` nodes represent definition or undefinition of a macro identifiers. +The ``name:`` field is the macro identifier, followed by macro parameters when +definining a function-like macro, and the ``value`` field is the token-string +used to expand the macro identifier. + +.. code-block:: llvm + + !2 = !DIMacro(macinfo: DW_MACINFO_define, line: 7, name: "foo(x)", + value: "((x) + 1)") + !3 = !DIMacro(macinfo: DW_MACINFO_undef, line: 30, name: "foo") + +DIMacroFile +""""""""""" + +``DIMacroFile`` nodes represent inclusion of source files. +The ``nodes:`` field is a list of ``DIMacro`` and ``DIMacroFile`` nodes that +appear in the included source file. + +.. code-block:: llvm + + !2 = !DIMacroFile(macinfo: DW_MACINFO_start_file, line: 7, file: !2, + nodes: !3) + '``tbaa``' Metadata ^^^^^^^^^^^^^^^^^^^ @@ -9336,6 +9383,48 @@ Semantics: See the description for :ref:`llvm.stacksave `. +.. _int_get_dynamic_area_offset: + +'``llvm.get.dynamic.area.offset``' Intrinsic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +:: + + declare i32 @llvm.get.dynamic.area.offset.i32() + declare i64 @llvm.get.dynamic.area.offset.i64() + + Overview: + """"""""" + + The '``llvm.get.dynamic.area.offset.*``' intrinsic family is used to + get the offset from native stack pointer to the address of the most + recent dynamic alloca on the caller's stack. These intrinsics are + intendend for use in combination with + :ref:`llvm.stacksave ` to get a + pointer to the most recent dynamic alloca. This is useful, for example, + for AddressSanitizer's stack unpoisoning routines. + +Semantics: +"""""""""" + + These intrinsics return a non-negative integer value that can be used to + get the address of the most recent dynamic alloca, allocated by :ref:`alloca ` + on the caller's stack. In particular, for targets where stack grows downwards, + adding this offset to the native stack pointer would get the address of the most + recent dynamic alloca. For targets where stack grows upwards, the situation is a bit more + complicated, because substracting this value from stack pointer would get the address + one past the end of the most recent dynamic alloca. + + Although for most targets `llvm.get.dynamic.area.offset ` + returns just a zero, for others, such as PowerPC and PowerPC64, it returns a + compile-time-known constant value. + + The return value type of :ref:`llvm.get.dynamic.area.offset ` + must match the target's generic address space's (address space 0) pointer type. + '``llvm.prefetch``' Intrinsic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^