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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits