[llvm-dev] pointer provenance introduction to load/store instructions

[Jeroen Dobbelaere via 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$