[PATCH] D98684: [LangRef] state that align assume op bundle may take an extra argument

[Juneyoung Lee via Phabricator via llvm-commits]

aqjune updated this revision to Diff 331143.
aqjune added a comment.

update


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98684/new/

https://reviews.llvm.org/D98684

Files:
  llvm/docs/LangRef.rst


Index: llvm/docs/LangRef.rst
===================================================================
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2242,37 +2242,50 @@
 
 ::
 
-      "<tag>"([ <holds for value> [, <attribute argument>] ])
+      "<tag>"()
+      "<tag>"(<ty> <holds for value>{, <ty> <attribute argument>}*)
 
 * The tag of the operand bundle is usually the name of attribute that can be
   assumed to hold. It can also be `ignore`, this tag doesn't contain any
   information and should be ignored.
 * The first argument if present is the value for which the attribute hold.
-* The second argument if present is an argument of the attribute.
+  If there are no arguments the attribute is a property of the call location.
+* The following arguments in the operand bundle, if present, specify
+  arguments of the attribute.
 
-If there are no arguments the attribute is a property of the call location.
-
-If the represented attribute expects a constant argument, the argument provided
-to the operand bundle should be a constant as well.
-
-For example:
+Just like for the argument of :ref:`llvm.assume <int_assume>`, if any of the
+provided guarantees are violated at runtime the behavior is undefined.
+This also applies to attributes whose violation in a function call is defined
+to yield poison, such as ``"nonnull"`` and ``"align"``.
+For example,
 
 .. code-block:: llvm
 
       call void @llvm.assume(i1 true) ["align"(i32* %val, i32 8)]
 
 allows the optimizer to assume that at location of call to
-:ref:`llvm.assume <int_assume>` ``%val`` has an alignment of at least 8.
+:ref:`llvm.assume <int_assume>` ``%val`` has an alignment of at least 8
+because it is otherwise undefined behavior.
+
+The :ref:`llvm.assume <int_assume>` condition retains its original effect even
+if operand bundles exist. For example,
 
 .. code-block:: llvm
 
       call void @llvm.assume(i1 %cond) ["cold"(), "nonnull"(i64* %val)]
 
-allows the optimizer to assume that the :ref:`llvm.assume <int_assume>`
-call location is cold and that ``%val`` may not be null.
+allows the optimizer to assume that ``%cond`` is true,
+the :ref:`llvm.assume <int_assume>` call location is cold, and ``%val`` is not
+null.
 
-Just like for the argument of :ref:`llvm.assume <int_assume>`, if any of the
-provided guarantees are violated at runtime the behavior is undefined.
+The ``"align"`` operand bundle optionally takes a third argument.
+``"align"(i8* ptr, i64 a, i64 ofs)`` is equivalent to GCC's
+``__builtin_assume_aligned(ptr, a, ofs)`` and states that ``ptr - ofs`` is
+``a``-bytes aligned.
+
+If the represented attribute expects a constant argument, the argument provided
+to the operand bundle should be a constant as well.
+For example, ``"align"`` can only take constant(s) as its alignment value.
 
 Even if the assumed property can be encoded as a boolean value, like
 ``nonnull``, using operand bundles to express the property can still have


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D98684.331143.patch
Type: text/x-patch
Size: 2957 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210317/5a8c5434/attachment.bin>