[PATCH] D69542: Full Restrict Support - single patch

[Ralf via Phabricator via llvm-commits]

RalfJung added inline comments.


================
Comment at: llvm/docs/LangRef.rst:9966-9971
+The optional ``ptr_provenance`` argument specifies the noalias chain of the
+pointer operand. It has the same type as the pointer operand. Together with the
+``!noalias`` metadata on the instruction, and the ``llvm.provenance.noalias``,
+``llvm.noalias.arg.guard`` intrinsics in the chain, this is used to deduce if
+two load/store instructions may or may not alias. (See `Scoped NoAlias Related
+Intrinsics`_)
----------------
Rust and C also have a notion of "pointer provenance", but it is subtly difference: provenance in those languages is something that flows with pointer values. IOW, a value of pointer type consists of some address in memory, plus some "provenance" metadata. LLVM also has that kind of provenance, it is needed e.g. to explain some of the behavior of `getelementptr`. (A pointer returned by `getelementptr` without inbounds can go out-of-bounds but must not be used to access memory outside the bounds of the allocation it started with. In other words, the pointer "remembers" the allocation it is associated with in some way that is separate from the integer address it points to.)

Is it a good idea to use the same term for this slightly different concept? A `load` operation already receives provenance from its pointer argument, and now with this patchset it *also* receives something else, but also called provenance, via a separate argument.


================
Comment at: llvm/docs/LangRef.rst:23372
 
+Scoped NoAlias Related Intrinsics
+---------------------------------
----------------
>From what I was able to see (but maybe I missed something), the docs do not say what exactly happens when these aliasing requirements are violated. I would expect that this results in immediate UB. During some [recent discussion](https://discourse.llvm.org/t/interaction-of-noalias-and-dereferenceable/66979), it was suggested that noalias-violating loads might return poison instead of causing UB, but [I think that proposal has problems](https://discourse.llvm.org/t/interaction-of-noalias-and-dereferenceable/66979/14). Either way though the docs should clearly state what the behavior is in that case.


================
Comment at: llvm/docs/LangRef.rst:23401
+
+A detailed description of these intrinsics and how the work is explained in
+::doc::`Restrict and NoAlias Information in LLVM <NoAliasInfo>`
----------------
should probably be: how "they" work


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

https://reviews.llvm.org/D69542