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 <n>``" - Numbered convention
Any calling convention may be specified by number, allowing
target-specific calling conventions to be used. Target specific
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.
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
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
"""""""""""""
``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
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.
!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
^^^^^^^^^^^^^^^^^^^
See the description for :ref:`llvm.stacksave <int_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 <int_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 <i_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 <int_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 <int_get_dynamic_area_offset>`
+ must match the target's generic address space's (address space 0) pointer type.
+
'``llvm.prefetch``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
projects / oota-llvm.git / blobdiff