[LangRef] Allow non-power-of-two assume operand bundle

There has been a lot of confusion on this in the past (see for
example https://reviews.llvm.org/D110634 and earlier revisions),
so let's try to get some clarity here. This patch specifies that
a) specifying a non-constant assumed alignment is explicitly
allowed and b) an invalid (non-power-of-two) alignment is not UB,
but rather converts it into an assumption that the pointer is null.

This change is done for two reasons:
a) Assume operand bundles are specifically used in cases where the
alignment is not known during frontend codegen (otherwise we'd just
use an align attribute), so rejecting this case doesn't make sense.
b) At least for aligned_alloc the C standard specifies that passing
an invalid alignment results in a null pointer, not undefined
behavior.

Differential Revision: https://reviews.llvm.org/D119414

llvm/docs/LangRef.rst

@@ -2428,9 +2428,6 @@ An assume operand bundle has the form:
 
 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:
 
 .. code-block:: llvm
@@ -2450,6 +2447,20 @@ call location is cold and that ``%val`` may not be 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.
 
+While attributes expect constant arguments, assume operand bundles may be
+provided a dynamic value, for example:
+
+.. code-block:: llvm
+
+      call void @llvm.assume(i1 true) ["align"(i32* %val, i32 %align)]
+
+If the operand bundle value violates any requirements on the attribute value,
+the behavior is undefined, unless one of the following exceptions applies:
+
+* ``"assume"`` operand bundles may specify a non-power-of-two alignment
+  (including a zero alignment). If this is the case, then the pointer value
+  must be a null pointer, otherwise the behavior is undefined.
+
 Even if the assumed property can be encoded as a boolean value, like
 ``nonnull``, using operand bundles to express the property can still have
 benefits: