[LangRef] Spell out alias attribute/metadata violations are UB.

[fhahn]

Update the documentation for the noalias attribute, !alias.scope and !loop.parallel_accesses metadata to clarify they are UB on voilation the noalias property.

[llvmbot]

@llvm/pr-subscribers-llvm-ir

Author: Florian Hahn (fhahn)

Changes

Update the documentation for the noalias attribute, !alias.scope and !loop.parallel_accesses metadata to clarify they are UB on voilation the noalias property.

---

Full diff: https://github.com/llvm/llvm-project/pull/116220.diff

1 Files Affected:

• (modified) llvm/docs/LangRef.rst (+13-10)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 6fb66ce231e8ab..6183f0f404f446 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -1358,13 +1358,15 @@ Currently, only the following parameter attributes are defined:
     This indicates that memory locations accessed via pointer values
     :ref:`based <pointeraliasing>` on the argument or return value are not also
     accessed, during the execution of the function, via pointer values not
-    *based* on the argument or return value. This guarantee only holds for
+    *based* on the argument or return value.This guarantee only holds for
     memory locations that are *modified*, by any means, during the execution of
-    the function. The attribute on a return value also has additional semantics
-    described below. The caller shares the responsibility with the callee for
-    ensuring that these requirements are met.  For further details, please see
-    the discussion of the NoAlias response in :ref:`alias analysis <Must, May,
-    or No>`.
+    the function. If there are other accesses not based on the argument or
+    return value, the behavior is undefined. The attribute on a return value
+    also has additional semantics described below. The caller shares the
+    responsibility with the callee for described below. The caller shares the
+    responsibility with the callee for ensuring that these requirements are met.
+    For further details, please see the discussion of the NoAlias response in
+    :ref:`alias analysis <Must, May,  or No>`.
 
     Note that this definition of ``noalias`` is intentionally similar
     to the definition of ``restrict`` in C99 for function arguments.
@@ -6936,9 +6938,9 @@ does not carry useful data and need not be preserved.
 noalias memory-access sets. This means that some collection of memory access
 instructions (loads, stores, memory-accessing calls, etc.) that carry
 ``noalias`` metadata can specifically be specified not to alias with some other
-collection of memory access instructions that carry ``alias.scope`` metadata.
-Each type of metadata specifies a list of scopes where each scope has an id and
-a domain.
+collection of memory access instructions that carry ``alias.scope`` metadata. If
+accesses from different collections alias, the behaivor is undefined. Each type
+of metadata specifies a list of scopes where each scope has an id and a domain.
 
 When evaluating an aliasing query, if for some domain, the set
 of scopes with that domain in one instruction's ``alias.scope`` list is a
@@ -7695,7 +7697,8 @@ If all memory-accessing instructions in a loop have
 ``llvm.access.group`` metadata that each refer to one of the access
 groups of a loop's ``llvm.loop.parallel_accesses`` metadata, then the
 loop has no loop carried memory dependencies and is considered to be a
-parallel loop.
+parallel loop. If there is a loop-carried dependency, the behavior is
+undefined.
 
 Note that if not all memory access instructions belong to an access
 group referred to by ``llvm.loop.parallel_accesses``, then the loop must

[nunoplopes]

LGTM

[fhahn]

Just realized that I forgot to update the !tbaa metadata, which probably also should get the same treatment

[nikic]

Trying to remind myself why exactly using "load is poison, store is UB" semantics wouldn't work:

If we have

store v2, p
v = load p

where we have claimed that these are noalias, then the store is well-defined and the load returns poison (due to conflicting store).

If we now move the load above the store (because they don't alias)

v = load p
store v2, p

then load returns a value and store is UB due to conflicting prior store. So we went from poison to UB.

So I believe that for scoped alias metadata only UB semantics can work, as specified here. Presumably a similar argument generalizes to the other metadata.

[nikic]

LGTM, but please wait a bit in case there are more comments.