[llvm] c95daac - [LangRef] Spell out alias attribute/metadata violations are UB. (#116220)
via llvm-commits
llvm-commits at lists.llvm.org
Sat Nov 16 05:39:06 PST 2024
Author: Florian Hahn
Date: 2024-11-16T13:38:58Z
New Revision: c95daac4c19fe54eeeb4d0ec5ca23f2673d1de71
URL: https://github.com/llvm/llvm-project/commit/c95daac4c19fe54eeeb4d0ec5ca23f2673d1de71
DIFF: https://github.com/llvm/llvm-project/commit/c95daac4c19fe54eeeb4d0ec5ca23f2673d1de71.diff
LOG: [LangRef] Spell out alias attribute/metadata violations are UB. (#116220)
Update the documentation for the noalias attribute, !alias.scope and
!loop.parallel_accesses metadata to clarify they are UB on voilation the
noalias property.
PR: https://github.com/llvm/llvm-project/pull/116220
---------
Co-authored-by: Nuno Lopes <nuno.lopes at tecnico.ulisboa.pt>
Added:
Modified:
llvm/docs/LangRef.rst
Removed:
################################################################################
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index c81abb38c6981f..99f3ec20e1dad3 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -1360,11 +1360,13 @@ Currently, only the following parameter attributes are defined:
accessed, during the execution of the function, via pointer values not
*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.
@@ -6816,7 +6818,9 @@ tuples this way:
A memory access with an access tag ``(BaseTy1, AccessTy1, Offset1)``
aliases a memory access with an access tag ``(BaseTy2, AccessTy2,
Offset2)`` if either ``(BaseTy1, Offset1)`` is reachable from ``(Base2,
-Offset2)`` via the ``Parent`` relation or vice versa.
+Offset2)`` via the ``Parent`` relation or vice versa. If memory accesses
+alias even though they are noalias according to ``!tbaa`` metadata, the
+behavior is undefined.
As a concrete example, the type descriptor graph for the following program
@@ -6936,9 +6940,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
diff erent collections alias, the behavior 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 +7699,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
More information about the llvm-commits
mailing list