"``anyregcc``" - Dynamic calling convention for code patching
This is a special convention that supports patching an arbitrary code
sequence in place of a call site. This convention forces the call
- arguments into registers but allows them to be dynamcially
+ arguments into registers but allows them to be dynamically
allocated. This can currently only be used with calls to
llvm.experimental.patchpoint because only this intrinsic records
the location of its arguments in a side table. See :doc:`StackMaps`.
"``preserve_mostcc``" - The `PreserveMost` calling convention
- This calling convention attempts to make the code in the caller as little
- intrusive as possible. This calling convention behaves identical to the `C`
+ This calling convention attempts to make the code in the caller as
+ unintrusive as possible. This convention behaves identically to the `C`
calling convention on how arguments and return values are passed, but it
uses a different set of caller/callee-saved registers. This alleviates the
burden of saving and recovering a large register set before and after the
This indicates that the parameter or return pointer is not null. This
attribute may only be applied to pointer typed parameters. This is not
checked or enforced by LLVM, the caller must ensure that the pointer
- passed in is non-null, or the callee must ensure that the returned pointer
+ passed in is non-null, or the callee must ensure that the returned pointer
is non-null.
``dereferenceable(<n>)``
array), however ``dereferenceable(<n>)`` does imply ``nonnull`` in
``addrspace(0)`` (which is the default address space).
+``dereferenceable_or_null(<n>)``
+ This indicates that the parameter or return value isn't both
+ non-null and non-dereferenceable (up to ``<n>`` bytes) at the same
+ time. All non-null pointers tagged with
+ ``dereferenceable_or_null(<n>)`` are ``dereferenceable(<n>)``.
+ For address space 0 ``dereferenceable_or_null(<n>)`` implies that
+ a pointer is exactly one of ``dereferenceable(<n>)`` or ``null``,
+ and in other address spaces ``dereferenceable_or_null(<n>)``
+ implies that a pointer is at least one of ``dereferenceable(<n>)``
+ or ``null`` (i.e. it may be both ``null`` and
+ ``dereferenceable(<n>)``). This attribute may only be applied to
+ pointer typed parameters.
+
.. _gc:
Garbage Collector Strategy Names
define void @f() gc "name" { ... }
-The supported values of *name* includes those :ref:`built in to LLVM
+The supported values of *name* includes those :ref:`built in to LLVM
<builtin-gc-strategies>` and any provided by loaded plugins. Specifying a GC
-strategy will cause the compiler to alter its output in order to support the
-named garbage collection algorithm. Note that LLVM itself does not contain a
+strategy will cause the compiler to alter its output in order to support the
+named garbage collection algorithm. Note that LLVM itself does not contain a
garbage collector, this functionality is restricted to generating machine code
-which can interoperate with a collector provided externally.
+which can interoperate with a collector provided externally.
.. _prefixdata:
computing edge weights, basic blocks post-dominated by a cold
function call are also considered to be cold; and, thus, given low
weight.
+``convergent``
+ This attribute indicates that the callee is dependent on a convergent
+ thread execution pattern under certain parallel execution models.
+ Transformations that are execution model agnostic may only move or
+ tranform this call if the final location is control equivalent to its
+ original position in the program, where control equivalence is defined as
+ A dominates B and B post-dominates A, or vice versa.
``inlinehint``
This attribute indicates that the source code contained a hint that
inlining this function is desirable (such as the "inline" keyword in
Instead, if specified, the target data layout is required to match what
the ultimate *code generator* expects. This string is used by the
mid-level optimizers to improve code, and this only works if it matches
-what the ultimate code generator uses. If you would like to generate IR
-that does not embed this target-specific detail into the IR, then you
-don't have to specify the string. This will disable some optimizations
-that require precise layout information, but this also prevents those
-optimizations from introducing target specificity into the IR.
+what the ultimate code generator uses. There is no way to generate IR
+that does not embed this target-specific detail into the IR. If you
+don't specify the string, the default specifications will be used to
+generate a Data Layout and the optimization phases will operate
+accordingly and introduce target specificity into the IR with respect to
+these default specifications.
.. _langref_triple:
More information about specific metadata nodes recognized by the
optimizers and code generator is found below.
+.. _specialized-metadata:
+
Specialized Metadata Nodes
^^^^^^^^^^^^^^^^^^^^^^^^^^
These aren't inherently debug info centric, but currently all the specialized
metadata nodes are related to debug info.
-MDCompileUnit
+.. _DICompileUnit:
+
+DICompileUnit
"""""""""""""
-``MDCompileUnit`` nodes represent a compile unit. The ``enums:``,
+``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
.. code-block:: llvm
- !0 = !MDCompileUnit(language: DW_LANG_C99, file: !1, producer: "clang",
+ !0 = !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang",
isOptimized: true, flags: "-O2", runtimeVersion: 2,
splitDebugFilename: "abc.debug", emissionKind: 1,
enums: !2, retainedTypes: !3, subprograms: !4,
globals: !5, imports: !6)
-MDFile
+Compile unit descriptors provide the root scope for objects declared in a
+specific compilation unit. File descriptors are defined using this scope.
+These descriptors are collected by a named metadata ``!llvm.dbg.cu``. They
+keep track of subprograms, global variables, type information, and imported
+entities (declarations and namespaces).
+
+.. _DIFile:
+
+DIFile
""""""
-``MDFile`` nodes represent files. The ``filename:`` can include slashes.
+``DIFile`` nodes represent files. The ``filename:`` can include slashes.
.. code-block:: llvm
- !0 = !MDFile(filename: "path/to/file", directory: "/path/to/dir")
+ !0 = !DIFile(filename: "path/to/file", directory: "/path/to/dir")
+
+Files are sometimes used in ``scope:`` fields, and are the only valid target
+for ``file:`` fields.
-.. _MDLocation:
+.. _DIBasicType:
-MDBasicType
+DIBasicType
"""""""""""
-``MDBasicType`` nodes represent primitive types. ``tag:`` defaults to
-``DW_TAG_base_type``.
+``DIBasicType`` nodes represent primitive types, such as ``int``, ``bool`` and
+``float``. ``tag:`` defaults to ``DW_TAG_base_type``.
.. code-block:: llvm
- !0 = !MDBasicType(name: "unsigned char", size: 8, align: 8,
+ !0 = !DIBasicType(name: "unsigned char", size: 8, align: 8,
encoding: DW_ATE_unsigned_char)
- !1 = !MDBasicType(tag: DW_TAG_unspecified_type, name: "decltype(nullptr)")
+ !1 = !DIBasicType(tag: DW_TAG_unspecified_type, name: "decltype(nullptr)")
-.. _MDSubroutineType:
+The ``encoding:`` describes the details of the type. Usually it's one of the
+following:
-MDSubroutineType
+.. code-block:: llvm
+
+ DW_ATE_address = 1
+ DW_ATE_boolean = 2
+ DW_ATE_float = 4
+ DW_ATE_signed = 5
+ DW_ATE_signed_char = 6
+ DW_ATE_unsigned = 7
+ DW_ATE_unsigned_char = 8
+
+.. _DISubroutineType:
+
+DISubroutineType
""""""""""""""""
-``MDSubroutineType`` nodes represent subroutine types. Their ``types:`` field
+``DISubroutineType`` nodes represent subroutine types. Their ``types:`` field
refers to a tuple; the first operand is the return type, while the rest are the
types of the formal arguments in order. If the first operand is ``null``, that
represents a function with no return value (such as ``void foo() {}`` in C++).
!0 = !BasicType(name: "int", size: 32, align: 32, DW_ATE_signed)
!1 = !BasicType(name: "char", size: 8, align: 8, DW_ATE_signed_char)
- !2 = !MDSubroutineType(types: !{null, !0, !1}) ; void (int, char)
+ !2 = !DISubroutineType(types: !{null, !0, !1}) ; void (int, char)
-MDDerivedType
+.. _DIDerivedType:
+
+DIDerivedType
"""""""""""""
-``MDDerivedType`` nodes represent types derived from other types, such as
+``DIDerivedType`` nodes represent types derived from other types, such as
qualified types.
.. code-block:: llvm
- !0 = !MDBasicType(name: "unsigned char", size: 8, align: 8,
+ !0 = !DIBasicType(name: "unsigned char", size: 8, align: 8,
encoding: DW_ATE_unsigned_char)
- !1 = !MDDerivedType(tag: DW_TAG_pointer_type, baseType: !0, size: 32,
+ !1 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !0, size: 32,
align: 32)
-.. _MDCompositeType:
+The following ``tag:`` values are valid:
+
+.. code-block:: llvm
+
+ DW_TAG_formal_parameter = 5
+ DW_TAG_member = 13
+ DW_TAG_pointer_type = 15
+ DW_TAG_reference_type = 16
+ DW_TAG_typedef = 22
+ DW_TAG_ptr_to_member_type = 31
+ DW_TAG_const_type = 38
+ DW_TAG_volatile_type = 53
+ DW_TAG_restrict_type = 55
+
+``DW_TAG_member`` is used to define a member of a :ref:`composite type
+<DICompositeType>` or :ref:`subprogram <DISubprogram>`. The type of the member
+is the ``baseType:``. The ``offset:`` is the member's bit offset.
+``DW_TAG_formal_parameter`` is used to define a member which is a formal
+argument of a subprogram.
+
+``DW_TAG_typedef`` is used to provide a name for the ``baseType:``.
+
+``DW_TAG_pointer_type``, ``DW_TAG_reference_type``, ``DW_TAG_const_type``,
+``DW_TAG_volatile_type`` and ``DW_TAG_restrict_type`` are used to qualify the
+``baseType:``.
-MDCompositeType
+Note that the ``void *`` type is expressed as a type derived from NULL.
+
+.. _DICompositeType:
+
+DICompositeType
"""""""""""""""
-``MDCompositeType`` nodes represent types composed of other types, like
+``DICompositeType`` nodes represent types composed of other types, like
structures and unions. ``elements:`` points to a tuple of the composed types.
If the source language supports ODR, the ``identifier:`` field gives the unique
.. code-block:: llvm
- !0 = !MDEnumerator(name: "SixKind", value: 7)
- !1 = !MDEnumerator(name: "SevenKind", value: 7)
- !2 = !MDEnumerator(name: "NegEightKind", value: -8)
- !3 = !MDCompositeType(tag: DW_TAG_enumeration_type, name: "Enum", file: !12,
+ !0 = !DIEnumerator(name: "SixKind", value: 7)
+ !1 = !DIEnumerator(name: "SevenKind", value: 7)
+ !2 = !DIEnumerator(name: "NegEightKind", value: -8)
+ !3 = !DICompositeType(tag: DW_TAG_enumeration_type, name: "Enum", file: !12,
line: 2, size: 32, align: 32, identifier: "_M4Enum",
elements: !{!0, !1, !2})
-MDSubrange
+The following ``tag:`` values are valid:
+
+.. code-block:: llvm
+
+ DW_TAG_array_type = 1
+ DW_TAG_class_type = 2
+ DW_TAG_enumeration_type = 4
+ DW_TAG_structure_type = 19
+ DW_TAG_union_type = 23
+ DW_TAG_subroutine_type = 21
+ DW_TAG_inheritance = 28
+
+
+For ``DW_TAG_array_type``, the ``elements:`` should be :ref:`subrange
+descriptors <DISubrange>`, each representing the range of subscripts at that
+level of indexing. The ``DIFlagVector`` flag to ``flags:`` indicates that an
+array type is a native packed vector.
+
+For ``DW_TAG_enumeration_type``, the ``elements:`` should be :ref:`enumerator
+descriptors <DIEnumerator>`, each representing the definition of an enumeration
+value for the set. All enumeration type descriptors are collected in the
+``enums:`` field of the :ref:`compile unit <DICompileUnit>`.
+
+For ``DW_TAG_structure_type``, ``DW_TAG_class_type``, and
+``DW_TAG_union_type``, the ``elements:`` should be :ref:`derived types
+<DIDerivedType>` with ``tag: DW_TAG_member`` or ``tag: DW_TAG_inheritance``.
+
+.. _DISubrange:
+
+DISubrange
""""""""""
-``MDSubrange`` nodes are the elements for ``DW_TAG_array_type`` variants of
-:ref:`MDCompositeType`. ``count: -1`` indicates an empty array.
+``DISubrange`` nodes are the elements for ``DW_TAG_array_type`` variants of
+:ref:`DICompositeType`. ``count: -1`` indicates an empty array.
.. code-block:: llvm
- !0 = !MDSubrange(count: 5, lowerBound: 0) ; array counting from 0
- !1 = !MDSubrange(count: 5, lowerBound: 1) ; array counting from 1
- !2 = !MDSubrange(count: -1) ; empty array.
+ !0 = !DISubrange(count: 5, lowerBound: 0) ; array counting from 0
+ !1 = !DISubrange(count: 5, lowerBound: 1) ; array counting from 1
+ !2 = !DISubrange(count: -1) ; empty array.
-MDEnumerator
+.. _DIEnumerator:
+
+DIEnumerator
""""""""""""
-``MDEnumerator`` nodes are the elements for ``DW_TAG_enumeration_type``
-variants of :ref:`MDCompositeType`.
+``DIEnumerator`` nodes are the elements for ``DW_TAG_enumeration_type``
+variants of :ref:`DICompositeType`.
.. code-block:: llvm
- !0 = !MDEnumerator(name: "SixKind", value: 7)
- !1 = !MDEnumerator(name: "SevenKind", value: 7)
- !2 = !MDEnumerator(name: "NegEightKind", value: -8)
+ !0 = !DIEnumerator(name: "SixKind", value: 7)
+ !1 = !DIEnumerator(name: "SevenKind", value: 7)
+ !2 = !DIEnumerator(name: "NegEightKind", value: -8)
-MDTemplateTypeParameter
+DITemplateTypeParameter
"""""""""""""""""""""""
-``MDTemplateTypeParameter`` nodes represent type parameters to generic source
-language constructs. They are used (optionally) in :ref:`MDCompositeType` and
-:ref:`MDSubprogram` ``templateParams:`` fields.
+``DITemplateTypeParameter`` nodes represent type parameters to generic source
+language constructs. They are used (optionally) in :ref:`DICompositeType` and
+:ref:`DISubprogram` ``templateParams:`` fields.
.. code-block:: llvm
- !0 = !MDTemplateTypeParameter(name: "Ty", type: !1)
+ !0 = !DITemplateTypeParameter(name: "Ty", type: !1)
-MDTemplateValueParameter
+DITemplateValueParameter
""""""""""""""""""""""""
-``MDTemplateValueParameter`` nodes represent value parameters to generic source
+``DITemplateValueParameter`` nodes represent value parameters to generic source
language constructs. ``tag:`` defaults to ``DW_TAG_template_value_parameter``,
but if specified can also be set to ``DW_TAG_GNU_template_template_param`` or
``DW_TAG_GNU_template_param_pack``. They are used (optionally) in
-:ref:`MDCompositeType` and :ref:`MDSubprogram` ``templateParams:`` fields.
+:ref:`DICompositeType` and :ref:`DISubprogram` ``templateParams:`` fields.
.. code-block:: llvm
- !0 = !MDTemplateValueParameter(name: "Ty", type: !1, value: i32 7)
+ !0 = !DITemplateValueParameter(name: "Ty", type: !1, value: i32 7)
-MDNamespace
+DINamespace
"""""""""""
-``MDNamespace`` nodes represent namespaces in the source language.
+``DINamespace`` nodes represent namespaces in the source language.
.. code-block:: llvm
- !0 = !MDNamespace(name: "myawesomeproject", scope: !1, file: !2, line: 7)
+ !0 = !DINamespace(name: "myawesomeproject", scope: !1, file: !2, line: 7)
-MDGlobalVariable
+DIGlobalVariable
""""""""""""""""
-``MDGlobalVariable`` nodes represent global variables in the source language.
+``DIGlobalVariable`` nodes represent global variables in the source language.
.. code-block:: llvm
- !0 = !MDGlobalVariable(name: "foo", linkageName: "foo", scope: !1,
+ !0 = !DIGlobalVariable(name: "foo", linkageName: "foo", scope: !1,
file: !2, line: 7, type: !3, isLocal: true,
isDefinition: false, variable: i32* @foo,
declaration: !4)
-.. _MDSubprogram:
+All global variables should be referenced by the `globals:` field of a
+:ref:`compile unit <DICompileUnit>`.
+
+.. _DISubprogram:
-MDSubprogram
+DISubprogram
""""""""""""
-``MDSubprogram`` nodes represent functions from the source language. The
-``variables:`` field points at :ref:`variables <MDLocalVariable>` that must be
+``DISubprogram`` nodes represent functions from the source language. The
+``variables:`` field points at :ref:`variables <DILocalVariable>` that must be
retained, even if their IR counterparts are optimized out of the IR. The
-``type:`` field must point at an :ref:`MDSubroutineType`.
+``type:`` field must point at an :ref:`DISubroutineType`.
.. code-block:: llvm
- !0 = !MDSubprogram(name: "foo", linkageName: "_Zfoov", scope: !1,
+ !0 = !DISubprogram(name: "foo", linkageName: "_Zfoov", scope: !1,
file: !2, line: 7, type: !3, isLocal: true,
isDefinition: false, scopeLine: 8, containingType: !4,
virtuality: DW_VIRTUALITY_pure_virtual, virtualIndex: 10,
function: void ()* @_Z3foov,
templateParams: !5, declaration: !6, variables: !7)
-.. _MDLexicalBlock:
+.. _DILexicalBlock:
-MDLexicalBlock
+DILexicalBlock
""""""""""""""
-``MDLexicalBlock`` nodes represent lexical blocks in the source language (a
-scope).
+``DILexicalBlock`` nodes describe nested blocks within a :ref:`subprogram
+<DISubprogram>`. The line number and column numbers are used to dinstinguish
+two lexical blocks at same depth. They are valid targets for ``scope:``
+fields.
.. code-block:: llvm
- !0 = !MDLexicalBlock(scope: !1, file: !2, line: 7, column: 35)
+ !0 = distinct !DILexicalBlock(scope: !1, file: !2, line: 7, column: 35)
-.. _MDLexicalBlockFile:
+Usually lexical blocks are ``distinct`` to prevent node merging based on
+operands.
+
+.. _DILexicalBlockFile:
-MDLexicalBlockFile
+DILexicalBlockFile
""""""""""""""""""
-``MDLexicalBlockFile`` nodes are used to discriminate between sections of a
-:ref:`lexical block <MDLexicalBlock>`. The ``file:`` field can be changed to
+``DILexicalBlockFile`` nodes are used to discriminate between sections of a
+:ref:`lexical block <DILexicalBlock>`. The ``file:`` field can be changed to
indicate textual inclusion, or the ``discriminator:`` field can be used to
discriminate between control flow within a single block in the source language.
.. code-block:: llvm
- !0 = !MDLexicalBlock(scope: !3, file: !4, line: 7, column: 35)
- !1 = !MDLexicalBlockFile(scope: !0, file: !4, discriminator: 0)
- !2 = !MDLexicalBlockFile(scope: !0, file: !4, discriminator: 1)
+ !0 = !DILexicalBlock(scope: !3, file: !4, line: 7, column: 35)
+ !1 = !DILexicalBlockFile(scope: !0, file: !4, discriminator: 0)
+ !2 = !DILexicalBlockFile(scope: !0, file: !4, discriminator: 1)
+
+.. _DILocation:
-MDLocation
+DILocation
""""""""""
-``MDLocation`` nodes represent source debug locations. The ``scope:`` field is
-mandatory, and points at an :ref:`MDLexicalBlockFile`, an
-:ref:`MDLexicalBlock`, or an :ref:`MDSubprogram`.
+``DILocation`` nodes represent source debug locations. The ``scope:`` field is
+mandatory, and points at an :ref:`DILexicalBlockFile`, an
+:ref:`DILexicalBlock`, or an :ref:`DISubprogram`.
.. code-block:: llvm
- !0 = !MDLocation(line: 2900, column: 42, scope: !1, inlinedAt: !2)
+ !0 = !DILocation(line: 2900, column: 42, scope: !1, inlinedAt: !2)
-.. _MDLocalVariable:
+.. _DILocalVariable:
-MDLocalVariable
+DILocalVariable
"""""""""""""""
-``MDLocalVariable`` nodes represent local variables in the source language.
+``DILocalVariable`` nodes represent local variables in the source language.
Instead of ``DW_TAG_variable``, they use LLVM-specific fake tags to
discriminate between local variables (``DW_TAG_auto_variable``) and subprogram
arguments (``DW_TAG_arg_variable``). In the latter case, the ``arg:`` field
specifies the argument position, and this variable will be included in the
-``variables:`` field of its :ref:`MDSubprogram`.
-
-If set, the ``inlinedAt:`` field points at an :ref:`MDLocation`, and the
-variable represents an inlined version of a variable (with all other fields
-duplicated from the non-inlined version).
+``variables:`` field of its :ref:`DISubprogram`.
.. code-block:: llvm
- !0 = !MDLocalVariable(tag: DW_TAG_arg_variable, name: "this", arg: 0,
+ !0 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "this", arg: 0,
scope: !3, file: !2, line: 7, type: !3,
- flags: DIFlagArtificial, inlinedAt: !4)
- !1 = !MDLocalVariable(tag: DW_TAG_arg_variable, name: "x", arg: 1,
- scope: !4, file: !2, line: 7, type: !3,
- inlinedAt: !6)
- !1 = !MDLocalVariable(tag: DW_TAG_auto_variable, name: "y",
- scope: !5, file: !2, line: 7, type: !3,
- inlinedAt: !6)
-
-MDExpression
+ flags: DIFlagArtificial)
+ !1 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "x", arg: 1,
+ scope: !4, file: !2, line: 7, type: !3)
+ !1 = !DILocalVariable(tag: DW_TAG_auto_variable, name: "y",
+ scope: !5, file: !2, line: 7, type: !3)
+
+DIExpression
""""""""""""
-``MDExpression`` nodes represent DWARF expression sequences. They are used in
+``DIExpression`` nodes represent DWARF expression sequences. They are used in
:ref:`debug intrinsics<dbg_intrinsics>` (such as ``llvm.dbg.declare``) to
describe how the referenced LLVM variable relates to the source language
variable.
.. code-block:: llvm
- !0 = !MDExpression(DW_OP_deref)
- !1 = !MDExpression(DW_OP_plus, 3)
- !2 = !MDExpression(DW_OP_bit_piece, 3, 7)
- !3 = !MDExpression(DW_OP_deref, DW_OP_plus, 3, DW_OP_bit_piece, 3, 7)
+ !0 = !DIExpression(DW_OP_deref)
+ !1 = !DIExpression(DW_OP_plus, 3)
+ !2 = !DIExpression(DW_OP_bit_piece, 3, 7)
+ !3 = !DIExpression(DW_OP_deref, DW_OP_plus, 3, DW_OP_bit_piece, 3, 7)
-MDObjCProperty
+DIObjCProperty
""""""""""""""
-``MDObjCProperty`` nodes represent Objective-C property nodes.
+``DIObjCProperty`` nodes represent Objective-C property nodes.
.. code-block:: llvm
- !3 = !MDObjCProperty(name: "foo", file: !1, line: 7, setter: "setFoo",
+ !3 = !DIObjCProperty(name: "foo", file: !1, line: 7, setter: "setFoo",
getter: "getFoo", attributes: 7, type: !2)
-MDImportedEntity
+DIImportedEntity
""""""""""""""""
-``MDImportedEntity`` nodes represent entities (such as modules) imported into a
+``DIImportedEntity`` nodes represent entities (such as modules) imported into a
compile unit.
.. code-block:: llvm
- !2 = !MDImportedEntity(tag: DW_TAG_imported_module, name: "foo", scope: !0,
+ !2 = !DIImportedEntity(tag: DW_TAG_imported_module, name: "foo", scope: !0,
entity: !1, line: 7)
'``tbaa``' Metadata
``noalias`` metadata can specifically be specified not to alias with some other
collection of memory access instructions that carry ``alias.scope`` metadata.
Each type of metadata specifies a list of scopes where each scope has an id and
-a domain. When evaluating an aliasing query, if for some some domain, the set
+a domain. When evaluating an aliasing query, if for some domain, the set
of scopes with that domain in one instruction's ``alias.scope`` list is a
subset of (or equal to) the set of scopes for that domain in another
instruction's ``noalias`` list, then the two memory accesses are assumed not to
%2 = load float, float* %c, align 4, !alias.scope !5
store float %2, float* %arrayidx.i2, align 4, !noalias !6
- ; These two instructions don't alias (for domain !0, the set of scopes in
+ ; These two instructions may alias (for domain !0, the set of scopes in
; the !noalias list is not a superset of, or equal to, the scopes in the
; !alias.scope list):
%2 = load float, float* %c, align 4, !alias.scope !6
'``llvm.mem.parallel_loop_access``' Metadata
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The ``llvm.mem.parallel_loop_access`` metadata refers to a loop identifier,
-or metadata containing a list of loop identifiers for nested loops.
-The metadata is attached to memory accessing instructions and denotes that
-no loop carried memory dependence exist between it and other instructions denoted
+The ``llvm.mem.parallel_loop_access`` metadata refers to a loop identifier,
+or metadata containing a list of loop identifiers for nested loops.
+The metadata is attached to memory accessing instructions and denotes that
+no loop carried memory dependence exist between it and other instructions denoted
with the same loop identifier.
-Precisely, given two instructions ``m1`` and ``m2`` that both have the
-``llvm.mem.parallel_loop_access`` metadata, with ``L1`` and ``L2`` being the
-set of loops associated with that metadata, respectively, then there is no loop
-carried dependence between ``m1`` and ``m2`` for loops in both ``L1`` and
+Precisely, given two instructions ``m1`` and ``m2`` that both have the
+``llvm.mem.parallel_loop_access`` metadata, with ``L1`` and ``L2`` being the
+set of loops associated with that metadata, respectively, then there is no loop
+carried dependence between ``m1`` and ``m2`` for loops in both ``L1`` and
``L2``.
-As a special case, if all memory accessing instructions in a loop have
-``llvm.mem.parallel_loop_access`` metadata that refers to that loop, then the
-loop has no loop carried memory dependences and is considered to be a parallel
-loop.
+As a special case, if all memory accessing instructions in a loop have
+``llvm.mem.parallel_loop_access`` metadata that refers to that loop, then the
+loop has no loop carried memory dependences and is considered to be a parallel
+loop.
-Note that if not all memory access instructions have such metadata referring to
-the loop, then the loop is considered not being trivially parallel. Additional
-memory dependence analysis is required to make that determination. As a fail
-safe mechanism, this causes loops that were originally parallel to be considered
-sequential (if optimization passes that are unaware of the parallel semantics
+Note that if not all memory access instructions have such metadata referring to
+the loop, then the loop is considered not being trivially parallel. Additional
+memory dependence analysis is required to make that determination. As a fail
+safe mechanism, this causes loops that were originally parallel to be considered
+sequential (if optimization passes that are unaware of the parallel semantics
insert new memory instructions into the loop body).
Example of a loop that is considered parallel due to its correct use of
The value produced is ``op1`` \* 2\ :sup:`op2` mod 2\ :sup:`n`,
where ``n`` is the width of the result. If ``op2`` is (statically or
-dynamically) negative or equal to or larger than the number of bits in
+dynamically) equal to or larger than the number of bits in
``op1``, the result is undefined. If the arguments are vectors, each
vector element of ``op1`` is shifted by the corresponding shift amount
in ``op2``.
::
- <result> = load [volatile] <ty>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>][, !invariant.load !<index>][, !nonnull !<index>]
+ <result> = load [volatile] <ty>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>][, !invariant.load !<index>][, !nonnull !<index>][, !dereferenceable !<index>][, !dereferenceable_or_null !<index>]
<result> = load atomic [volatile] <ty>* <pointer> [singlethread] <ordering>, align <alignment>
!<index> = !{ i32 1 }
entries. The existence of the ``!invariant.load`` metadata on the
instruction tells the optimizer and code generator that the address
operand to this load points to memory which can be assumed unchanged.
-Being invariant does not imply that a location is dereferenceable,
-but it does imply that once the location is known dereferenceable
-its value is henceforth unchanging.
+Being invariant does not imply that a location is dereferenceable,
+but it does imply that once the location is known dereferenceable
+its value is henceforth unchanging.
The optional ``!nonnull`` metadata must reference a single
metadata name ``<index>`` corresponding to a metadata node with no
entries. The existence of the ``!nonnull`` metadata on the
instruction tells the optimizer that the value loaded is known to
never be null. This is analogous to the ''nonnull'' attribute
-on parameters and return values. This metadata can only be applied
-to loads of a pointer type.
+on parameters and return values. This metadata can only be applied
+to loads of a pointer type.
+
+The optional ``!dereferenceable`` metadata must reference a single
+metadata name ``<index>`` corresponding to a metadata node with one ``i64``
+entry. The existence of the ``!dereferenceable`` metadata on the instruction
+tells the optimizer that the value loaded is known to be dereferenceable.
+The number of bytes known to be dereferenceable is specified by the integer
+value in the metadata node. This is analogous to the ''dereferenceable''
+attribute on parameters and return values. This metadata can only be applied
+to loads of a pointer type.
+
+The optional ``!dereferenceable_or_null`` metadata must reference a single
+metadata name ``<index>`` corresponding to a metadata node with one ``i64``
+entry. The existence of the ``!dereferenceable_or_null`` metadata on the
+instruction tells the optimizer that the value loaded is known to be either
+dereferenceable or null.
+The number of bytes known to be dereferenceable is specified by the integer
+value in the metadata node. This is analogous to the ''dereferenceable_or_null''
+attribute on parameters and return values. This metadata can only be applied
+to loads of a pointer type.
Semantics:
""""""""""
""""""""""
The '``ptrtoint``' instruction takes a ``value`` to cast, which must be
-a a value of type :ref:`pointer <t_pointer>` or a vector of pointers, and a
+a value of type :ref:`pointer <t_pointer>` or a vector of pointers, and a
type to cast it to ``ty2``, which must be an :ref:`integer <t_integer>` or
a vector of integers type.
--------------------------------------
LLVM's support for `Accurate Garbage Collection <GarbageCollection.html>`_
-(GC) requires the frontend to generate code containing appropriate intrinsic
-calls and select an appropriate GC strategy which knows how to lower these
+(GC) requires the frontend to generate code containing appropriate intrinsic
+calls and select an appropriate GC strategy which knows how to lower these
intrinsics in a manner which is appropriate for the target collector.
These intrinsics allow identification of :ref:`GC roots on the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
LLVM provides an second experimental set of intrinsics for describing garbage
-collection safepoints in compiled code. These intrinsics are an alternative
-to the ``llvm.gcroot`` intrinsics, but are compatible with the ones for
-:ref:`read <int_gcread>` and :ref:`write <int_gcwrite>` barriers. The
-differences in approach are covered in the `Garbage Collection with LLVM
-<GarbageCollection.html>`_ documentation. The intrinsics themselves are
+collection safepoints in compiled code. These intrinsics are an alternative
+to the ``llvm.gcroot`` intrinsics, but are compatible with the ones for
+:ref:`read <int_gcread>` and :ref:`write <int_gcwrite>` barriers. The
+differences in approach are covered in the `Garbage Collection with LLVM
+<GarbageCollection.html>`_ documentation. The intrinsics themselves are
described in :doc:`Statepoints`.
.. _int_gcroot:
after performing the required machine specific adjustments. The pointer
returned can then be :ref:`bitcast and executed <int_trampoline>`.
+.. _int_mload_mstore:
+
Masked Vector Load and Store Intrinsics
---------------------------------------
Overview:
"""""""""
-Reads a vector from memory according to the provided mask. The mask holds a bit for each vector lane, and is used to prevent memory accesses to the masked-off lanes. The masked-off lanes in the result vector are taken from the corresponding lanes in the passthru operand.
+Reads a vector from memory according to the provided mask. The mask holds a bit for each vector lane, and is used to prevent memory accesses to the masked-off lanes. The masked-off lanes in the result vector are taken from the corresponding lanes of the '``passthru``' operand.
Arguments:
""""""""""
-The first operand is the base pointer for the load. The second operand is the alignment of the source location. It must be a constant integer value. The third operand, mask, is a vector of boolean 'i1' values with the same number of elements as the return type. The fourth is a pass-through value that is used to fill the masked-off lanes of the result. The return type, underlying type of the base pointer and the type of passthru operand are the same vector types.
+The first operand is the base pointer for the load. The second operand is the alignment of the source location. It must be a constant integer value. The third operand, mask, is a vector of boolean values with the same number of elements as the return type. The fourth is a pass-through value that is used to fill the masked-off lanes of the result. The return type, underlying type of the base pointer and the type of the '``passthru``' operand are the same vector types.
Semantics:
::
%res = call <16 x float> @llvm.masked.load.v16f32 (<16 x float>* %ptr, i32 4, <16 x i1>%mask, <16 x float> %passthru)
-
+
;; The result of the two following instructions is identical aside from potential memory access exception
%loadlal = load <16 x float>, <16 x float>* %ptr, align 4
%res = select <16 x i1> %mask, <16 x float> %loadlal, <16 x float> %passthru
::
call void @llvm.masked.store.v16f32(<16 x float> %value, <16 x float>* %ptr, i32 4, <16 x i1> %mask)
-
+
;; The result of the following instructions is identical aside from potential data races and memory access exceptions
%oldval = load <16 x float>, <16 x float>* %ptr, align 4
%res = select <16 x i1> %mask, <16 x float> %value, <16 x float> %oldval
store <16 x float> %res, <16 x float>* %ptr, align 4
+Masked Vector Gather and Scatter Intrinsics
+-------------------------------------------
+
+LLVM provides intrinsics for vector gather and scatter operations. They are similar to :ref:`Masked Vector Load and Store <int_mload_mstore>`, except they are designed for arbitrary memory accesses, rather than sequential memory accesses. Gather and scatter also employ a mask operand, which holds one bit per vector element, switching the associated vector lane on or off. The memory addresses corresponding to the "off" lanes are not accessed. When all bits are off, no memory is accessed.
+
+.. _int_mgather:
+
+'``llvm.masked.gather.*``' Intrinsics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+This is an overloaded intrinsic. The loaded data are multiple scalar values of any integer or floating point data type gathered together into one vector.
+
+::
+
+ declare <16 x float> @llvm.masked.gather.v16f32 (<16 x float*> <ptrs>, i32 <alignment>, <16 x i1> <mask>, <16 x float> <passthru>)
+ declare <2 x double> @llvm.masked.gather.v2f64 (<2 x double*> <ptrs>, i32 <alignment>, <2 x i1> <mask>, <2 x double> <passthru>)
+
+Overview:
+"""""""""
+
+Reads scalar values from arbitrary memory locations and gathers them into one vector. The memory locations are provided in the vector of pointers '``ptrs``'. The memory is accessed according to the provided mask. The mask holds a bit for each vector lane, and is used to prevent memory accesses to the masked-off lanes. The masked-off lanes in the result vector are taken from the corresponding lanes of the '``passthru``' operand.
+
+
+Arguments:
+""""""""""
+
+The first operand is a vector of pointers which holds all memory addresses to read. The second operand is an alignment of the source addresses. It must be a constant integer value. The third operand, mask, is a vector of boolean values with the same number of elements as the return type. The fourth is a pass-through value that is used to fill the masked-off lanes of the result. The return type, underlying type of the vector of pointers and the type of the '``passthru``' operand are the same vector types.
+
+
+Semantics:
+""""""""""
+
+The '``llvm.masked.gather``' intrinsic is designed for conditional reading of multiple scalar values from arbitrary memory locations in a single IR operation. It is useful for targets that support vector masked gathers and allows vectorizing basic blocks with data and control divergence. Other targets may support this intrinsic differently, for example by lowering it into a sequence of scalar load operations.
+The semantics of this operation are equivalent to a sequence of conditional scalar loads with subsequent gathering all loaded values into a single vector. The mask restricts memory access to certain lanes and facilitates vectorization of predicated basic blocks.
+
+
+::
+
+ %res = call <4 x double> @llvm.masked.gather.v4f64 (<4 x double*> %ptrs, i32 8, <4 x i1>%mask, <4 x double> <true, true, true, true>)
+
+ ;; The gather with all-true mask is equivalent to the following instruction sequence
+ %ptr0 = extractelement <4 x double*> %ptrs, i32 0
+ %ptr1 = extractelement <4 x double*> %ptrs, i32 1
+ %ptr2 = extractelement <4 x double*> %ptrs, i32 2
+ %ptr3 = extractelement <4 x double*> %ptrs, i32 3
+
+ %val0 = load double, double* %ptr0, align 8
+ %val1 = load double, double* %ptr1, align 8
+ %val2 = load double, double* %ptr2, align 8
+ %val3 = load double, double* %ptr3, align 8
+
+ %vec0 = insertelement <4 x double>undef, %val0, 0
+ %vec01 = insertelement <4 x double>%vec0, %val1, 1
+ %vec012 = insertelement <4 x double>%vec01, %val2, 2
+ %vec0123 = insertelement <4 x double>%vec012, %val3, 3
+
+.. _int_mscatter:
+
+'``llvm.masked.scatter.*``' Intrinsics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+This is an overloaded intrinsic. The data stored in memory is a vector of any integer or floating point data type. Each vector element is stored in an arbitrary memory addresses. Scatter with overlapping addresses is guaranteed to be ordered from least-significant to most-significant element.
+
+::
+
+ declare void @llvm.masked.scatter.v8i32 (<8 x i32> <value>, <8 x i32*> <ptrs>, i32 <alignment>, <8 x i1> <mask>)
+ declare void @llvm.masked.scatter.v16f32(<16 x i32> <value>, <16 x i32*> <ptrs>, i32 <alignment>, <16 x i1> <mask>)
+
+Overview:
+"""""""""
+
+Writes each element from the value vector to the corresponding memory address. The memory addresses are represented as a vector of pointers. Writing is done according to the provided mask. The mask holds a bit for each vector lane, and is used to prevent memory accesses to the masked-off lanes.
+
+Arguments:
+""""""""""
+
+The first operand is a vector value to be written to memory. The second operand is a vector of pointers, pointing to where the value elements should be stored. It has the same underlying type as the value operand. The third operand is an alignment of the destination addresses. The fourth operand, mask, is a vector of boolean values. The types of the mask and the value operand must have the same number of vector elements.
+
+
+Semantics:
+""""""""""
+
+The '``llvm.masked.scatter``' intrinsics is designed for writing selected vector elements to arbitrary memory addresses in a single IR operation. The operation may be conditional, when not all bits in the mask are switched on. It is useful for targets that support vector masked scatter and allows vectorizing basic blocks with data and control divergency. Other targets may support this intrinsic differently, for example by lowering it into a sequence of branches that guard scalar store operations.
+
+::
+
+ ;; This instruction unconditionaly stores data vector in multiple addresses
+ call @llvm.masked.scatter.v8i32 (<8 x i32> %value, <8 x i32*> %ptrs, i32 4, <8 x i1> <true, true, .. true>)
+
+ ;; It is equivalent to a list of scalar stores
+ %val0 = extractelement <8 x i32> %value, i32 0
+ %val1 = extractelement <8 x i32> %value, i32 1
+ ..
+ %val7 = extractelement <8 x i32> %value, i32 7
+ %ptr0 = extractelement <8 x i32*> %ptrs, i32 0
+ %ptr1 = extractelement <8 x i32*> %ptrs, i32 1
+ ..
+ %ptr7 = extractelement <8 x i32*> %ptrs, i32 7
+ ;; Note: the order of the following stores is important when they overlap:
+ store i32 %val0, i32* %ptr0, align 4
+ store i32 %val1, i32* %ptr1, align 4
+ ..
+ store i32 %val7, i32* %ptr7, align 4
+
+
Memory Use Markers
------------------
This intrinsic is lowered to the ``val``.
+.. _int_assume:
+
'``llvm.assume``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
projects / oota-llvm.git / blobdiff