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

[nikic]

Summary

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.

[jdoerfert]

Would work for me, others?

[nikic]

Any other thoughts on this?

I believe the proposed semantics would match what the proposed allocalign attribute specifies in https://reviews.llvm.org/D117921.

[spatel]

I haven't followed the details in the source-level construct, but if this makes it easier to nail down the behavior in LLVM, that's good for me.

[nikic]

ping

[jyknight]

Being consistent with allocalign's proposed semantics sounds good to me.

llvm/docs/LangRef.rst

 * 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.
 
-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
 
       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.
 
 .. 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.
 
 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:
 
 * Attributes that can be expressed via operand bundles are directly the
   property that the optimizer uses and cares about. Encoding attributes as
   operand bundles removes the need for an instruction sequence that represents
   the property (e.g., `icmp ne i32* %p, null` for `nonnull`) and for the