``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.
+ Transformations that are execution model agnostic may not make the execution
+ of a convergent operation control dependent on any additional values.
``inlinehint``
This attribute indicates that the source code contained a hint that
inlining this function is desirable (such as the "inline" keyword in
the ELF x86-64 abi, but it can be disabled for some compilation
units.
+
+.. _opbundles:
+
+Operand Bundles
+---------------
+
+Note: operand bundles are a work in progress, and they should be
+considered experimental at this time.
+
+Operand bundles are tagged sets of SSA values that can be associated
+with certain LLVM instructions (currently only ``call`` s and
+``invoke`` s). In a way they are like metadata, but dropping them is
+incorrect and will change program semantics.
+
+Syntax::
+ operand bundle set ::= '[' operand bundle ']'
+ operand bundle ::= tag '(' [ bundle operand ] (, bundle operand )* ')'
+ bundle operand ::= SSA value
+ tag ::= string constant
+
+Operand bundles are **not** part of a function's signature, and a
+given function may be called from multiple places with different kinds
+of operand bundles. This reflects the fact that the operand bundles
+are conceptually a part of the ``call`` (or ``invoke``), not the
+callee being dispatched to.
+
+Operand bundles are a generic mechanism intended to support
+runtime-introspection-like functionality for managed languages. While
+the exact semantics of an operand bundle depend on the bundle tag,
+there are certain limitations to how much the presence of an operand
+bundle can influence the semantics of a program. These restrictions
+are described as the semantics of an "unknown" operand bundle. As
+long as the behavior of an operand bundle is describable within these
+restrictions, LLVM does not need to have special knowledge of the
+operand bundle to not miscompile programs containing it.
+
+ - The bundle operands for an unknown operand bundle escape in unknown
+ ways before control is transferred to the callee or invokee.
+
+ - Calls and invokes with operand bundles have unknown read / write
+ effect on the heap on entry and exit (even if the call target is
+ ``readnone`` or ``readonly``).
+
+ - An operand bundle at a call site cannot change the implementation
+ of the called function. Inter-procedural optimizations work as
+ usual as long as they take into account the first two properties.
+
.. _moduleasm:
Module-Level Inline Assembly
::
<result> = invoke [cconv] [ret attrs] <ptr to function ty> <function ptr val>(<function args>) [fn attrs]
- to label <normal label> unwind label <exception label>
+ [operand bundles] to label <normal label> unwind label <exception label>
Overview:
"""""""""
#. The optional :ref:`function attributes <fnattrs>` list. Only
'``noreturn``', '``nounwind``', '``readonly``' and '``readnone``'
attributes are valid here.
+#. The optional :ref:`operand bundles <opbundles>` list.
Semantics:
""""""""""
""""""""""
The first operand of an '``extractvalue``' instruction is a value of
-:ref:`struct <t_struct>` or :ref:`array <t_array>` type. The operands are
+:ref:`struct <t_struct>` or :ref:`array <t_array>` type. The other operands are
constant indices to specify which value to extract in a similar manner
as indices in a '``getelementptr``' instruction.
::
- <result> = load [volatile] <ty>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>][, !invariant.load !<index>][, !invariant.group !<index>][, !nonnull !<index>][, !dereferenceable !<deref_bytes_node>][, !dereferenceable_or_null !<deref_bytes_node>]
+ <result> = load [volatile] <ty>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>][, !invariant.load !<index>][, !invariant.group !<index>][, !nonnull !<index>][, !dereferenceable !<deref_bytes_node>][, !dereferenceable_or_null !<deref_bytes_node>][, !align !<align_node>]
<result> = load atomic [volatile] <ty>* <pointer> [singlethread] <ordering>, align <alignment> [, !invariant.group !<index>]
!<index> = !{ i32 1 }
!<deref_bytes_node> = !{i64 <dereferenceable_bytes>}
+ !<align_node> = !{ i64 <value_alignment> }
Overview:
"""""""""
attribute on parameters and return values. This metadata can only be applied
to loads of a pointer type.
+The optional ``!align`` metadata must reference a single metadata name
+``<align_node>`` corresponding to a metadata node with one ``i64`` entry.
+The existence of the ``!align`` metadata on the instruction tells the
+optimizer that the value loaded is known to be aligned to a boundary specified
+by the integer value in the metadata node. The alignment must be a power of 2.
+This is analogous to the ''align'' attribute on parameters and return values.
+This metadata can only be applied to loads of a pointer type.
+
Semantics:
""""""""""
::
<result> = [tail | musttail] call [cconv] [ret attrs] <ty> [<fnty>*] <fnptrval>(<function args>) [fn attrs]
+ [ operand bundles ]
Overview:
"""""""""
#. The optional :ref:`function attributes <fnattrs>` list. Only
'``noreturn``', '``nounwind``', '``readonly``' and '``readnone``'
attributes are valid here.
+#. The optional :ref:`operand bundles <opbundles>` list.
Semantics:
""""""""""
Overview:
"""""""""
-The ``llvm.uabsdiff`` intrinsic returns a vector result of the absolute difference of
-the two operands, treating them both as unsigned integers.
+The ``llvm.uabsdiff`` intrinsic returns a vector result of the absolute difference
+of the two operands, treating them both as unsigned integers. The intermediate
+calculations are computed using infinitely precise unsigned arithmetic. The final
+result will be truncated to the given type.
The ``llvm.sabsdiff`` intrinsic returns a vector result of the absolute difference of
-the two operands, treating them both as signed integers.
+the two operands, treating them both as signed integers. If the result overflows, the
+behavior is undefined.
.. note::
These intrinsics are primarily used during the code generation stage of compilation.
- They are generated by compiler passes such as the Loop and SLP vectorizers.it is not
+ They are generated by compiler passes such as the Loop and SLP vectorizers. It is not
recommended for users to create them manually.
Arguments:
is equivalent to::
- %sub = sub <4 x i32> %a, %b
- %ispos = icmp ugt <4 x i32> %sub, <i32 -1, i32 -1, i32 -1, i32 -1>
- %neg = sub <4 x i32> zeroinitializer, %sub
- %1 = select <4 x i1> %ispos, <4 x i32> %sub, <4 x i32> %neg
+ %1 = zext <4 x i32> %a to <4 x i64>
+ %2 = zext <4 x i32> %b to <4 x i64>
+ %sub = sub <4 x i64> %1, %2
+ %trunc = trunc <4 x i64> to <4 x i32>
-Similarly the expression::
+and the expression::
call <4 x i32> @llvm.sabsdiff.v4i32(<4 x i32> %a, <4 x i32> %b)
is equivalent to::
%sub = sub nsw <4 x i32> %a, %b
- %ispos = icmp sgt <4 x i32> %sub, <i32 -1, i32 -1, i32 -1, i32 -1>
+ %ispos = icmp sge <4 x i32> %sub, zeroinitializer
%neg = sub nsw <4 x i32> zeroinitializer, %sub
%1 = select <4 x i1> %ispos, <4 x i32> %sub, <4 x i32> %neg
projects / oota-llvm.git / blobdiff