llvm dev - Jun 2021 - pointer provenance introduction to load/store instructions

On Mon, Jun 14, 2021 at 6:57 PM Jeroen Dobbelaere via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> as some of you already know, the full restrict patches[0] introduce an
optional 'ptr_provenance' operand
> to LoadInst/StoreInst. In the context of full restrict support, this
operand is used to separate the
> computation of the pointer operand from the possible restrict provenance of
that operand. This was necessary
> so that we could keep all the optimizations working on those pointers,
without being blocked by the noalias intrinsics.
> At the same time we avoided the risk to lose the noalias provenance of the
instruction.
>
> As that separation can also be useful in other situations, there was a
request in the past LLVM Alias Analysis Tech calls[1],
> to split out the pointer provenance changes and propose them as a next step
for inclusion.
>
> Fast forward to today. A lot more discussions about pointer provenance and
related problems are ongoing.
>
> Maybe the provided set of patches[2] and the experience with tracking the
provenance in the full restrict patches can
> be a first step to help solving some of those problems ?
>
> Any feedback is welcome, also during tomorrows AA TechCall[1]
I may not be able to make the call (the call starts as WG14 meetings
are ending), but I wanted to ask whether discussions of pointer
provenance are tracking the draft TS from WG14 on the subject
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2676.pdf)? This is a
work item from the C committee's Memory Object Model study group, and
any feedback we can provide to the SG on the TS would be greatly
appreciated as the committee's expectation is to someday roll this TS
into the C standard (with adjustments from whatever implementation
feedback is generated).

Thanks!

~Aaron
>
> Greetings,
>
> Jeroen Dobbelaere
>
> [0] https://reviews.llvm.org/D68484 [PATCH 01/27] [noalias] LangRef:
noalias intrinsics and ptr_provenance documentation.
> [1]
https://docs.google.com/document/d/17U-WvX8qyKc3S36YUKr3xfF-GHunWyYowXbxEdpHscw/edit?usp=sharing
LLVM AA TechCall
> [2] https://reviews.llvm.org/D104268 [ptr_provenance] Introduce optional
ptr_provenance operand to load/store
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi Aaron,

at the moment we are (were ?) not exactly tracking the N2676 proposal, but we
are keeping it mind.

Wrt to the ptr_provenance support, my current understanding is that this
infrastructure will
make it possible to resolve some optimization issue, together with allowing us
to improve
the alias analysis infrastructure and supporting full restrict. At the same
time, the
infrastructure itself is orthogonal to the 'policy' that we want to use
in llvm/clang.
(aka, what happens to the provenance for a int2ptr, etc.)

This also means that, as far I as see it at this moment, we should be able to
adhere to/implement the
proposal.

Given that, it is a decent large piece of text and I am trying to iterate over
it in order to grasp
everything that is said.

My understanding is that N2686 proposes the PNVI-ae-udi version as object model
for C.

Something that is not clear to me (but I might have missed it in the large body
of text), is what I
means for a storage instance to be exposed: based on p27, the
'pointer_from_integer_1ie.c', can I
conclude that just converting a 'pointer to a storage instance' to a
uintptr_t is enough to
'expose' that instance, even if the value is never used ? (Not sure if
that would lead to a useful
program)

And another observation: at this moment, I am not exactly sure how we would be
able to 'proof' in a
convenient way at compile time that, like in the example
'pointer_from_int_disambiguation_3.c' on p30,
*r=11 would be associated with y (and conclude that r=r-1; *r=12 triggers UB).
My current impression
is that any 'int2ptr' cast (at llvm ir level) would have to result in a
pointer, with a
provenance = the union of all exposed objects. But I don't see yet how to
reduce that set to the
one or two actual possibilities.
 
Thanks,

Jeroen Dobbelaere

> -----Original Message-----
> From: Aaron Ballman <aaron at aaronballman.com>
> Sent: Tuesday, June 15, 2021 14:27
> To: Jeroen Dobbelaere <dobbel at synopsys.com>
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] pointer provenance introduction to load/store
> instructions
> 
> On Mon, Jun 14, 2021 at 6:57 PM Jeroen Dobbelaere via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > Hi all,
> >
> > as some of you already know, the full restrict patches[0] introduce an
> optional 'ptr_provenance' operand
> > to LoadInst/StoreInst. In the context of full restrict support, this
operand
> is used to separate the
> > computation of the pointer operand from the possible restrict
provenance of
> that operand. This was necessary
> > so that we could keep all the optimizations working on those pointers,
> without being blocked by the noalias intrinsics.
> > At the same time we avoided the risk to lose the noalias provenance of
the
> instruction.
> >
> > As that separation can also be useful in other situations, there was a
> request in the past LLVM Alias Analysis Tech calls[1],
> > to split out the pointer provenance changes and propose them as a next
step
> for inclusion.
> >
> > Fast forward to today. A lot more discussions about pointer provenance
and
> related problems are ongoing.
> >
> > Maybe the provided set of patches[2] and the experience with tracking
the
> provenance in the full restrict patches can
> > be a first step to help solving some of those problems ?
> >
> > Any feedback is welcome, also during tomorrows AA TechCall[1]
> 
> I may not be able to make the call (the call starts as WG14 meetings
> are ending), but I wanted to ask whether discussions of pointer
> provenance are tracking the draft TS from WG14 on the subject
> (https://urldefense.com/v3/__http://www.open-
>
std.org/jtc1/sc22/wg14/www/docs/n2676.pdf)?__;!!A4F2R9G_pg!J2GwvsldgvyB5C3tclr
> 6vOIqLDq5jLz6xF5wRWWO-XbSwAfumZis2h7zfb2VFV3GZJm4V8Dn$  This is a
> work item from the C committee's Memory Object Model study group, and
> any feedback we can provide to the SG on the TS would be greatly
> appreciated as the committee's expectation is to someday roll this TS
> into the C standard (with adjustments from whatever implementation
> feedback is generated).
> 
> Thanks!
> 
> ~Aaron
> 
> >
> > Greetings,
> >
> > Jeroen Dobbelaere
> >
> > [0]
>
https://urldefense.com/v3/__https://reviews.llvm.org/D68484__;!!A4F2R9G_pg!J2G
> wvsldgvyB5C3tclr6vOIqLDq5jLz6xF5wRWWO-XbSwAfumZis2h7zfb2VFV3GZIxTZDQP$ 
[PATCH
> 01/27] [noalias] LangRef: noalias intrinsics and ptr_provenance
documentation.
> > [1]
https://urldefense.com/v3/__https://docs.google.com/document/d/17U-
> WvX8qyKc3S36YUKr3xfF-
>
GHunWyYowXbxEdpHscw/edit?usp=sharing__;!!A4F2R9G_pg!J2GwvsldgvyB5C3tclr6vOIqLD
> q5jLz6xF5wRWWO-XbSwAfumZis2h7zfb2VFV3GZK-ywDFU$   LLVM AA TechCall
> > [2]
>
https://urldefense.com/v3/__https://reviews.llvm.org/D104268__;!!A4F2R9G_pg!J2
> GwvsldgvyB5C3tclr6vOIqLDq5jLz6xF5wRWWO-XbSwAfumZis2h7zfb2VFV3GZMbuxUpQ$
> [ptr_provenance] Introduce optional ptr_provenance operand to load/store
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/llvm-
> dev__;!!A4F2R9G_pg!J2GwvsldgvyB5C3tclr6vOIqLDq5jLz6xF5wRWWO-
> XbSwAfumZis2h7zfb2VFV3GZFDoRNLa$