[PATCH] D74935: [LangRef][AliasAnalysis] Clarify `noalias` affects only modified objects

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 10 11:27:33 PDT 2020


jdoerfert added a comment.

In D74935#1915311 <https://reviews.llvm.org/D74935#1915311>, @jeroen.dobbelaere wrote:

> In D74935#1909909 <https://reviews.llvm.org/D74935#1909909>, @jdoerfert wrote:
>
> > I would say that once we get modeling for indirect restrict we can adapt the lang ref accordingly. For now there is only have outer level restrict/noalias.
>
>
> Why not try to get right now ? The first reason that you give for the change in wording is
>
> > '1. To match the restrict semantics when we lower it to noalias.'


Right. Match the semantics of what we lower to noalias, not of everything we do not lower yet.

> Currently there is no mechanism to accurately describe nested restrict pointers in LLVM-IR. imho, that means that
>  we should adapt the wording in a more specific way. Something like:

We also have no restrict on nested pointers. Since we only model (=use) restrict on the outermost level I don't see a problem not to talk about the inner levels.
That said, we have to add wording as we add support.

>     This guarantee only holds for memory locations that are *modified*, by any means, during the execution the function.
>   + Note that, just like C99 restrict, in this context, memory locations whose content is used as a pointer value to modify a memory location,
>   + are also considered to modify the former memory locations.
>     The attribute....
>    

The reason is that we need to come up and agree on clear, non-confusing, wording.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74935/new/

https://reviews.llvm.org/D74935





More information about the llvm-commits mailing list