[PATCH] D104268: [ptr_provenance] Introduce optional ptr_provenance operand to load/store

[Ralf via Phabricator via llvm-commits]

RalfJung added inline comments.


================
Comment at: llvm/docs/LangRef.rst:651-652
+
+Alias analysis can make use of both, the computed pointer value and the
+provenance to come up with alias conclusions.
+
----------------
jeroen.dobbelaere wrote:
> RalfJung wrote:
> > In particular this sounds just wrong, if `ptr_provenance` is merely sugar for a "combine address with provenance" intrinsic: if `ptr_provenance` is present, it would be a bug for alias analysis to make any conclusions based on the provenance of the pointer argument.
> Hmm. The wording seems to allow a misinterpretation. You cannot choose if the 'provenance' is that of the pointer computation or if it is the decoupled one. If the provenance is decoupled, that is what you need to use.
> 
Okay, that makes sense. So the documentation should then clearly state that in the presence of `ptr_provenance`, alias analysis *must not* make any conclusions by checking that the ptr argument is "based on" -- only the integer address of that pointer must be used, no other attached information (such as noalias/getelementptr-induced restrictions).

It is hard to even precisely discuss this without documenting in more detail what the provenance model of LLVM is: that every value of pointer type comes with some extra "ghost state" attached to it, which is how restrictions such as "getelementptr stays in the bounds of its allocations" and `noalias` flow through the program; that that "ghost state" is preserved when the pointer is itself stored to memory and loaded back out of memory; that alias analysis uses this "ghost state" to determine that a certain load/store cannot alias with another. I think documenting this better will also help a lot to avoid issues that the lack of precision around pointer provenance has caused in the past. (This immediately raises some new questions, such as how that provenance of a pointer stored in memory interacts with low-level byte-manipulating memory accesses that read or write some or all of the bytes of that pointer. Over time the LangRef should give answers to all these questions, but even acknowledging these issues would already be a great step forward. I'm happy to share the state of that discussion in Rust in case people are interested; we thought about this quite a bit.)


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

https://reviews.llvm.org/D104268