[llvm-dev] inttoptr->add->ptrtoint capturing pointer?
Ryan Taylor via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 18 11:00:03 PST 2021
Yes, so if you have an int2ptr->add+(non-pointer)->ptr2int that should
retain restrict qualifier, but you are saying it doesn't, or that the new
patches won't support that, correct?
Thanks.
On Thu, Feb 18, 2021 at 1:22 PM Jeroen Dobbelaere <
Jeroen.Dobbelaere at synopsys.com> wrote:
> > Seems like as long as the pointer is based on the restrict pointer (and
> no other pointer)and follows the constraints, it to is restrict qualified?
>
>
>
> as long as the pointer expression is based on a restrict pointer... its
> accesses are associated to that restrict pointer (and assumed to not alias
> with other restrict pointers in the same scope).
>
>
>
> Greetings,
>
>
>
> Jeroen Dobbelaere
>
>
>
>
>
>
>
>
>
> *From:* Ryan Taylor <ryta1203 at gmail.com>
> *Sent:* Thursday, February 18, 2021 19:11
> *To:* Jeroen Dobbelaere <dobbel at synopsys.com>
> *Cc:* Johannes Doerfert <johannesdoerfert at gmail.com>; llvm-dev <
> llvm-dev at lists.llvm.org>; Juneyoung Lee <juneyoung.lee at sf.snu.ac.kr>;
> Philip Reames <listmail at philipreames.com>
> *Subject:* Re: [llvm-dev] inttoptr->add->ptrtoint capturing pointer?
>
>
>
> Ok, just clarifying.
>
>
>
> Am I interrupting 6.7.3.1.4 incorrectly?
>
>
>
> Seems like as long as the pointer is based on the restrict pointer (and no
> other pointer)and follows the constraints, it to is restrict qualified?
>
>
>
> During each execution of B, let L be any lvalue that has &L based on P.
> If L is used to access the value of the object X that it designates, and X
> is also modified (by any means), then the following requirements apply: T
> shall not be const-qualified. Every other lvalue used to access the value
> of X shall also have its address based on P. Every access that modifies X
> shall be considered also to modify P, for the purposes of this subclause.
>
>
>
> Thanks.
>
>
>
>
>
>
>
> On Thu, Feb 18, 2021 at 12:59 PM Jeroen Dobbelaere <
> Jeroen.Dobbelaere at synopsys.com> wrote:
>
> > So if some restrict pointer 'x' is casted to int, adds 1, then casted
> back to pointer, it nullifies the restrict qualifier, despite the results
> having no other uses?
>
> yes.
>
>
>
> int * restrict x = ...;
>
>
>
> bad usage:
>
> *(int*)((int)x + 1) = 42;
>
>
>
> valid usage:
>
> x = (int*)((int)x + 1);
>
> *x = 42;
>
>
>
> Greetings,
>
>
>
> Jeroen Dobbelaere
>
>
>
> *From:* Ryan Taylor <ryta1203 at gmail.com>
> *Sent:* Thursday, February 18, 2021 18:51
> *To:* Jeroen Dobbelaere <dobbel at synopsys.com>
> *Cc:* Johannes Doerfert <johannesdoerfert at gmail.com>; llvm-dev <
> llvm-dev at lists.llvm.org>; Juneyoung Lee <juneyoung.lee at sf.snu.ac.kr>;
> Philip Reames <listmail at philipreames.com>
> *Subject:* Re: [llvm-dev] inttoptr->add->ptrtoint capturing pointer?
>
>
>
> So if some restrict pointer 'x' is casted to int, adds 1, then casted back
> to pointer, it nullifies the restrict qualifier, despite the results having
> no other uses?
>
>
>
> Thanks.
>
>
>
> On Thu, Feb 18, 2021 at 12:41 PM Jeroen Dobbelaere <
> Jeroen.Dobbelaere at synopsys.com> wrote:
>
> > How will inttoptr work with the new restrict patches? Certainly the
> int2ptr capturing shouldn't nullify the restrict qualifier.
>
>
>
> The full restrict patches see through 'inttoptr(ptrtoint( x ) )', Besides
> that, the analysis stops at 'ptr2int(x)' and 'anything can happen'.
>
> Because of this, all other 'inttoptr' usages will never introduce a
> restrict provenance.
>
>
>
> (aka, a restrict pointer converted to an int + some computations and then
> converted back to a pointer will normally not retain the 'restrictness' and
> that can trigger undefined behavior)
>
>
>
> Greetings,
>
>
>
> Jeroen Dobbelaere
>
>
>
> *From:* Ryan Taylor <ryta1203 at gmail.com>
> *Sent:* Thursday, February 18, 2021 18:31
> *To:* Johannes Doerfert <johannesdoerfert at gmail.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>; Jeroen Dobbelaere <
> dobbel at synopsys.com>; Juneyoung Lee <juneyoung.lee at sf.snu.ac.kr>; Philip
> Reames <listmail at philipreames.com>
> *Subject:* Re: [llvm-dev] inttoptr->add->ptrtoint capturing pointer?
>
>
>
> Juneyoung said he hadn't started working on it yet, so I'm going to take a
> look at it also.
>
>
>
> How will inttoptr work with the new restrict patches? Certainly the
> int2ptr capturing shouldn't nullify the restrict qualifier.
>
>
>
> Thanks.
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Feb 18, 2021 at 12:04 PM Johannes Doerfert <
> johannesdoerfert at gmail.com> wrote:
>
> I think you are working with a custom llvm here but I will
> make a few general statements that might help:
>
> - The noalias intrinsic as you've shown it captures, unfortunately.
> We don't have the `nocapture_maybe_returned` attribute in IR yet that
> the Attributor uses for these situations,
> IIRC, Juneyoung is working on making it an LLVM-IR enum attribute
> already.
>
> - int2ptr is assumed to capture in basically every analysis I've seen.
> It doesn't intrinsically but it is really
> hard to get it right. That said, we could allow *very* special
> patterns but I would argue those should be recognized
> in instcombine and replaced there.
>
> - Philip and I are working to define capture better for the lang ref, we
> might want to include some examples and
> rational around int2ptr when we have a coherent model.
>
> I've CC'ed people that might correct me or augment my answer, hope this
> helps :)
>
> ~ Johannes
>
>
> On 2/18/21 9:17 AM, Ryan Taylor via llvm-dev wrote:
> > I have an example:
> >
> > foo(float * restrict y, int off1, int off2) {
> > float * restrict x;
> > for (..) {
> > for (..) {
> > x = y+off1;
> > }
> > x = (const float *)((int)x+off2))
> >
> > I'm not sure why this should be capturing the pointer?
> >
> > For instance, looking at scoped noalias dbg info:
> >
> > SNA: Capture check for B/CSB UO: %54 = inttoptr i32 %add83 to float*,
> > !dbg !101
> > SNA: Pointer %1 = call float* @llvm.noalias.p0_float(float* %0,
> metadata
> > !38), !dbg !41 might be captured!
> >
> > Is this implying that the noalias intrinsic might be capturing the
> pointer?
> > It doesn't look like "noalias" intrinsic has NoCapture property on the
> > pointer:
> >
> > def int_noalias : Intrinsic<[llvm_anyptr_ty],
> > [LLVMMatchType<0>, llvm_metadata_ty],
> > [IntrArgMemOnly, Returned<0>]>;
> >
> > It should though right? From the definition of capture it is returning
> the
> > pointer; however, we know nothing is happening here.
> >
> > I'm on llvm 10 with Hal's restrict patches.
> >
> > Thanks.
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> <https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!A4F2R9G_pg!Pm5BQtdh_gU6pe-WvhApIs2FOjI1V7vJDj6H93m0sNUItsa5T6CbzW5JL1cixruSF_kY7ywW$>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210218/9224bf5c/attachment.html>
More information about the llvm-dev
mailing list