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

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

Together with the ptr_provenance infrastructure, this provides a base infrastructure
that allows us to:

  • provide a fix for PR44313 [3], while still making use of the p==q value equality

I watched your dev meeting talk and discussed it afterwards with Alina. I am very keen to see how these new load & store provenance annotations can resolve PR44313, the conflict between predicate info and LLVM’s alias logic. It has been a longstanding issue. I can’t claim to understand all the details, but I want to express my enthusiastic support for this work.

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 ?

As a Clang community representative to WG14 (the C committee), I
greatly appreciate the aim for full support of C99's `restrict` as
well as investigating the efforts of N2676. I support these efforts!

Thanks!

~Aaron