jdoerfert added a comment. Drive by, I haven't read the entire history.
In D79744#2040208 <https://reviews.llvm.org/D79744#2040208>, @rjmccall wrote: > I don't understand why `noalias` is even a concern if the whole buffer passed > to the kernel is read-only. `noalias` is primarily about proving > non-interference, but if you can tell IR that the buffer is read-only, that's > a much more powerful statement. The problem is that it is a "per-pointer" attribute and not "per-object". Given two argument pointers, where one is marked `readonly`, may still alias. Similarly, an access to a global, indirect accesses, ... can write the "readonly" memory. Hence, the `readonly` is pretty useless *in the callee* if other accesses can write the memory. The `readonly` is useful in the caller though, usually if we have basically `noalias` information there (e.g., it is an alloca). `Noalias` is useful in the callee regardless of `readonly` but even better with. > Regardless, if you do need `noalias`, you should be able to emit the same IR > that we'd emit if pointers to all the fields were assigned into `restrict` > local variables and then only those variables were subsequently used. We are still debating the local restrict pointer support. Once we merge that in it should be usable here. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79744/new/ https://reviews.llvm.org/D79744 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
