[LangRef] Clarify that inaccessiblememonly functions are allowed noalias returns
authorPhilip Reames <listmail@philipreames.com>
Tue, 18 Jan 2022 22:46:58 +0000 (14:46 -0800)
committerPhilip Reames <listmail@philipreames.com>
Tue, 18 Jan 2022 22:47:46 +0000 (14:47 -0800)
Confusion over this point came up in a couple of recent changes (D117180, e20b32ff3). Current tone of discussion seems to be that we think inaccessiblememonly was always legal on allocation functions, so this change takes the form of a clarification instead of a change.

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

llvm/docs/LangRef.rst

index e4e5c5d..bd99e33 100644 (file)
@@ -1633,9 +1633,15 @@ example:
     on all the hot functions.
 ``inaccessiblememonly``
     This attribute indicates that the function may only access memory that
-    is not accessible by the module being compiled. This is a weaker form
-    of ``readnone``. If the function reads or writes other memory, the
-    behavior is undefined.
+    is not accessible by the module being compiled before return from the
+    function. This is a weaker form of ``readnone``. If the function reads
+    or writes other memory, the behavior is undefined.
+
+    For clarity, note that such functions are allowed to return new memory
+    which is ``noalias`` with respect to memory already accessible from
+    the module.  That is, a function can be both ``inaccessiblememonly`` and
+    have a ``noalias`` return which introduces a new, potentially initialized,
+    allocation.
 ``inaccessiblemem_or_argmemonly``
     This attribute indicates that the function may only access memory that is
     either not accessible by the module being compiled, or is pointed to