From: Philip Reames Date: Tue, 18 Jan 2022 22:46:58 +0000 (-0800) Subject: [LangRef] Clarify that inaccessiblememonly functions are allowed noalias returns X-Git-Tag: upstream/15.0.7~20024 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=17beee44e19ba3d3ccb6a5a4f4429662db7e70c8;p=platform%2Fupstream%2Fllvm.git [LangRef] Clarify that inaccessiblememonly functions are allowed noalias returns 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 --- diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index e4e5c5d..bd99e33 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -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