thread execution pattern under certain parallel execution models.
Transformations that are execution model agnostic may not make the execution
of a convergent operation control dependent on any additional values.
+``inaccessiblememonly``
+ This attribute indicates that the function may only access memory that
+ is not accessible by the module being compiled. This is a weaker form
+ of ``readnone``.
+``inaccessiblemem_or_argmemonly``
+ This attribute indicates that the function may only access memory that is
+ either not accessible by the module being compiled, or is pointed to
+ by its pointer arguments. This is a weaker form of ``argmemonly``
``inlinehint``
This attribute indicates that the source code contained a hint that
inlining this function is desirable (such as the "inline" keyword in
semantically equivalent to composing the caller's deoptimization
continuation after the callee's deoptimization continuation.
+Funclet Operand Bundles
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Funclet operand bundles are characterized by the ``"funclet"``
+operand bundle tag. These operand bundles indicate that a call site
+is within a particular funclet. There can be at most one
+``"funclet"`` operand bundle attached to a call site and it must have
+exactly one bundle operand.
+
.. _moduleasm:
Module-Level Inline Assembly
Executing a ``catchpad`` instruction constitutes "entering" that pad.
The pad may then be "exited" in one of three ways:
+
1) explicitly via a ``catchret`` that consumes it. Executing such a ``catchret``
is undefined behavior if any descendant pads have been entered but not yet
exited.
execution of this ``load`` with other :ref:`volatile
operations <volatile>`.
-If the ``load`` is marked as ``atomic``, it takes an extra
-:ref:`ordering <ordering>` and optional ``singlethread`` argument. The
-``release`` and ``acq_rel`` orderings are not valid on ``load``
-instructions. Atomic loads produce :ref:`defined <memmodel>` results
-when they may see multiple atomic stores. The type of the pointee must
-be an integer type whose bit width is a power of two greater than or
-equal to eight and less than or equal to a target-specific size limit.
-``align`` must be explicitly specified on atomic loads, and the load has
-undefined behavior if the alignment is not set to a value which is at
-least the size in bytes of the pointee. ``!nontemporal`` does not have
-any defined semantics for atomic loads.
+If the ``load`` is marked as ``atomic``, it takes an extra :ref:`ordering
+<ordering>` and optional ``singlethread`` argument. The ``release`` and
+``acq_rel`` orderings are not valid on ``load`` instructions. Atomic loads
+produce :ref:`defined <memmodel>` results when they may see multiple atomic
+stores. The type of the pointee must be an integer, pointer, or floating-point
+type whose bit width is a power of two greater than or equal to eight and less
+than or equal to a target-specific size limit. ``align`` must be explicitly
+specified on atomic loads, and the load has undefined behavior if the alignment
+is not set to a value which is at least the size in bytes of the
+pointee. ``!nontemporal`` does not have any defined semantics for atomic loads.
The optional constant ``align`` argument specifies the alignment of the
operation (that is, the alignment of the memory address). A value of 0
execution of this ``store`` with other :ref:`volatile
operations <volatile>`.
-If the ``store`` is marked as ``atomic``, it takes an extra
-:ref:`ordering <ordering>` and optional ``singlethread`` argument. The
-``acquire`` and ``acq_rel`` orderings aren't valid on ``store``
-instructions. Atomic loads produce :ref:`defined <memmodel>` results
-when they may see multiple atomic stores. The type of the pointee must
-be an integer type whose bit width is a power of two greater than or
-equal to eight and less than or equal to a target-specific size limit.
-``align`` must be explicitly specified on atomic stores, and the store
-has undefined behavior if the alignment is not set to a value which is
-at least the size in bytes of the pointee. ``!nontemporal`` does not
-have any defined semantics for atomic stores.
+If the ``store`` is marked as ``atomic``, it takes an extra :ref:`ordering
+<ordering>` and optional ``singlethread`` argument. The ``acquire`` and
+``acq_rel`` orderings aren't valid on ``store`` instructions. Atomic loads
+produce :ref:`defined <memmodel>` results when they may see multiple atomic
+stores. The type of the pointee must be an integer, pointer, or floating-point
+type whose bit width is a power of two greater than or equal to eight and less
+than or equal to a target-specific size limit. ``align`` must be explicitly
+specified on atomic stores, and the store has undefined behavior if the
+alignment is not set to a value which is at least the size in bytes of the
+pointee. ``!nontemporal`` does not have any defined semantics for atomic stores.
The optional constant ``align`` argument specifies the alignment of the
operation (that is, the alignment of the memory address). A value of 0
::
- <result> = [tail | musttail | notail ] call [cconv] [ret attrs] <ty> [<fnty>*] <fnptrval>(<function args>) [fn attrs]
+ <result> = [tail | musttail | notail ] call [fast-math flags] [cconv] [ret attrs] <ty> [<fnty>*] <fnptrval>(<function args>) [fn attrs]
[ operand bundles ]
Overview:
``tail`` or ``musttail`` markers to the call. It is used to prevent tail
call optimization from being performed on the call.
+#. The optional ``fast-math flags`` marker indicates that the call has one or more
+ :ref:`fast-math flags <fastmath>`, which are optimization hints to enable
+ otherwise unsafe floating-point optimizations. Fast-math flags are only valid
+ for calls that return a floating-point scalar or vector type.
+
#. The optional "cconv" marker indicates which :ref:`calling
convention <callingconv>` the call should use. If none is
specified, the call defaults to using C calling conventions. The
Executing a ``cleanuppad`` instruction constitutes "entering" that pad.
The pad may then be "exited" in one of three ways:
+
1) explicitly via a ``cleanupret`` that consumes it. Executing such a ``cleanupret``
is undefined behavior if any descendant pads have been entered but not yet
exited.
projects / oota-llvm.git / blobdiff