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

Wed Jun 16 11:28:11 PDT 2021

On Wed, Jun 16, 2021 at 10:20 AM Jeroen Dobbelaere
<Jeroen.Dobbelaere at synopsys.com> wrote:
>
> Hi Aaron,
>
> at the moment we are (were ?) not exactly tracking the N2676 proposal, but we are keeping it mind.

Fantastic, I really appreciate that!

> 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.

That's great to hear!

> 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.

Sure -- to help with this, I've CCed Peter Sewell who is the chair of
the Memory Object Model study group and an author of the TS. Peter may
not be able to respond immediately (we're in WG14 meetings this week),
but hopefully he can chime in or CC someone who can, especially if I'm
misstating something.

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

Correct.

> 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)

That's a good question that I don't feel super confident in my answer
to, but I believe that converting the pointer to a storage instance to
uintptr_t does expose that instance without requiring further analysis
as to whether the value is actually used. But again, I could be Very
Wrong here. Hopefully Peter can chime in!

> 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.

That's good feedback! I think you're correct that int2ptr would need
to track the union of all exposed objects. I assume this is
potentially really expensive because that union could be quite large?

Thanks!

~Aaron

>
> 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$