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:
""""""""""
::
- <result> = load [volatile] <ty>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>][, !invariant.load !<index>][, !invariant.group !<index>][, !nonnull !<index>][, !dereferenceable !<index>][, !dereferenceable_or_null !<index>]
+ <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:
"""""""""
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``
+The optional ``!dereferenceable`` metadata must reference a single metadata
+name ``<deref_bytes_node>`` 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
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
+metadata name ``<deref_bytes_node>`` 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
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