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

Jeroen Dobbelaere via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 24 10:26:55 PST 2022


jeroen.dobbelaere added a comment.

In D104268#3266800 <https://reviews.llvm.org/D104268#3266800>, @nikic wrote:

> It's been a while since I looked at this, so please excuse the stupid question...
>
> Why do we model provenance as an additional value on the load/store? Naively, I would think that it would be preferable to have an intrinsic like `p' = llvm.with.provenance(p, provenance)`, because that would work with any use of the pointer -- the ptr_provenance operand is limited to loads and stores, but not with memory-accessing calls or captured pointers, and I don't think it can really be extended in that direction.

Hi Nikita,

my talk on the 2021 LLVM Dev Conference explains this. See https://www.youtube.com/watch?v=08XwXB3GHck 2021 LLVM Dev Mtg “ptr_provenance and @llvm.noalias: The Tale of Full Restrict”

In short:

- there is the `llvm.with.provenance(p, provenance)` equivalent intrinsic: it is called `llvm.experimental.ptr.provenance` (see D107355 <https://reviews.llvm.org/D107355>)
- load/store instructions are handled differently, mostly to make the process more efficient and to make the new support easier to integrate with existing optimization passes. Those that just replace the pointer computation won't influence the provenance (once that is set).


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

https://reviews.llvm.org/D104268



More information about the llvm-commits mailing list