[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