[llvm-dev] [RFC] Introduction of the 'unknown_provenance' LLVM-IR constant

[Jeroen Dobbelaere via llvm-dev]

Hi all,

In the context of introducing the 'ptr_provenance' infrastructure (See [0], [1]),
I am also introducing a new LLVM-IR constant: 'unknown_provenance' (See [2]).

In [2], David (xbolva00) asked for a RFC. To be sure that the community is aware
of those additions, I am posting this here.

The 'unknown_provenance' constant is only to be used on the ptr_provenance path.
It indicates that the actual provenance is unknown (and could be any valid object).

Together with the ptr_provenance infrastructure, this provides a base infrastructure
that allows us to:
- implement the full restrict support[1]
- provide a fix for PR44313 [3], while still making use of the p==q value equality
- provide an implementation of N2676[4]

Another reason for the new constant is that using any other value (null, undef, poison, 42, ...)
would be ambiguous in some situation.

On Thursday, I also give a talk[5] about the infrastructure needed for 'Full Restrict' support.
That gives some extra rationale behind the need for the ptr_provenance related changes.

Any thoughts ?

Jeroen Dobbelaere

[0] https://lists.llvm.org/pipermail/llvm-dev/2021-June/151152.html [llvm-dev] pointer provenance introduction to load/store instructions
[1] https://reviews.llvm.org/D68484 [PATCH 01/27] [noalias] LangRef: noalias intrinsics and ptr_provenance documentation.
[2] https://reviews.llvm.org/D111160 [UnknownProvenance] Add LLVM-IR support for unknown_provenance
[3] https://bugs.llvm.org/show_bug.cgi?id=44313
[4] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2676.pdf A provenance aware memory object model for C
[5] https://llvm.swoogo.com/2021DevMtg/session/705670/ptr_provenance-and-@llvm.noalias-the-tale-of-full-restrict