llvm dev - Nov 2021 - [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- at
llvm.noalias-the-tale-of-full-restrict

On Wed, Nov 17, 2021 at 6:17 AM Jeroen Dobbelaere via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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 <https://bugs.llvm.org/show_bug.cgi?id=44313>, 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211118/5f9b7f89/attachment.html>

On Wed, Nov 17, 2021 at 9:17 AM Jeroen Dobbelaere via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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
>
> 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-
at llvm.noalias-the-tale-of-full-restrict
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev