(``STB_LOCAL`` in the case of ELF) in the object file. This
corresponds to the notion of the '``static``' keyword in C.
``available_externally``
- Globals with "``available_externally``" linkage are never emitted
- into the object file corresponding to the LLVM module. They exist to
- allow inlining and other optimizations to take place given knowledge
- of the definition of the global, which is known to be somewhere
- outside the module. Globals with ``available_externally`` linkage
- are allowed to be discarded at will, and are otherwise the same as
- ``linkonce_odr``. This linkage type is only allowed on definitions,
- not declarations.
+ Globals with "``available_externally``" linkage are never emitted into
+ the object file corresponding to the LLVM module. From the linker's
+ perspective, an ``available_externally`` global is equivalent to
+ an external declaration. They exist to allow inlining and other
+ optimizations to take place given knowledge of the definition of the
+ global, which is known to be somewhere outside the module. Globals
+ with ``available_externally`` linkage are allowed to be discarded at
+ will, and allow inlining and other optimizations. This linkage type is
+ only allowed on definitions, not declarations.
``linkonce``
Globals with "``linkonce``" linkage are merged with other globals of
the same name when linkage occurs. This can be used to implement
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
':ref:`resume <i_resume>`', ':ref:`catchswitch <i_catchswitch>`',
':ref:`catchret <i_catchret>`',
':ref:`cleanupret <i_cleanupret>`',
-':ref:`terminatepad <i_terminatepad>`',
and ':ref:`unreachable <i_unreachable>`'.
.. _i_ret:
this operand may be the token ``none``.
The ``default`` argument is the label of another basic block beginning with a
-"pad" instruction, one of ``cleanuppad``, ``terminatepad``, or
-``catchswitch``.
+"pad" instruction, one of ``cleanuppad`` or ``catchswitch``.
The ``handlers`` are a list of successor blocks that each begin with a
:ref:`catchpad <i_catchpad>` instruction.
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.
2) implicitly via a call (which unwinds all the way to the current function's caller),
- or via a ``catchswitch``, ``cleanupret``, or ``terminatepad`` that unwinds to caller.
+ or via a ``catchswitch`` or a ``cleanupret`` that unwinds to caller.
3) implicitly via an unwind edge whose destination EH pad isn't a descendant of
the ``catchpad``. When the ``catchpad`` is exited in this manner, it is
undefined behavior if the destination EH pad has a parent which is not an
cleanupret from %cleanup unwind to caller
cleanupret from %cleanup unwind label %continue
-.. _i_terminatepad:
-
-'``terminatepad``' Instruction
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Syntax:
-"""""""
-
-::
-
- terminatepad within <token> [<args>*] unwind label <exception label>
- terminatepad within <token> [<args>*] unwind to caller
-
-Overview:
-"""""""""
-
-The '``terminatepad``' instruction is used by `LLVM's exception handling
-system <ExceptionHandling.html#overview>`_ to specify that a basic block
-is a terminate block --- one where a personality routine may decide to
-terminate the program.
-The ``args`` correspond to whatever information the personality
-routine requires to know if this is an appropriate place to terminate the
-program. Control is transferred to the ``exception`` label if the
-personality routine decides not to terminate the program for the
-in-flight exception.
-
-Arguments:
-""""""""""
-
-The instruction takes a list of arbitrary values which are interpreted
-by the :ref:`personality function <personalityfn>`.
-
-The ``terminatepad`` may be given an ``exception`` label to
-transfer control to if the in-flight exception matches the ``args``.
-
-Semantics:
-""""""""""
-
-When the call stack is being unwound due to an exception being thrown,
-the exception is compared against the ``args``. If it matches,
-then control is transfered to the ``exception`` basic block. Otherwise,
-the program is terminated via personality-specific means. Typically,
-the first argument to ``terminatepad`` specifies what function the
-personality should defer to in order to terminate the program.
-
-The ``terminatepad`` instruction is both a terminator and a "pad" instruction,
-meaning that is always the only non-phi instruction in the basic block.
-
-Example:
-""""""""
-
-.. code-block:: llvm
-
- ;; A terminate block which only permits integers.
- terminatepad within none [i8** @_ZTIi] unwind label %continue
-
.. _i_unreachable:
'``unreachable``' Instruction
``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.
+be an integer 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
``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.
+be an integer 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.
2) implicitly via a call (which unwinds all the way to the current function's caller),
- or via a ``catchswitch``, ``cleanupret``, or ``terminatepad`` that unwinds to caller.
+ or via a ``catchswitch`` or a ``cleanupret`` that unwinds to caller.
3) implicitly via an unwind edge whose destination EH pad isn't a descendant of
the ``cleanuppad``. When the ``cleanuppad`` is exited in this manner, it is
undefined behavior if the destination EH pad has a parent which is not an
projects / oota-llvm.git / blobdiff