Ryan Taylor via llvm-dev
2021-Feb-18 19:00 UTC
[llvm-dev] inttoptr->add->ptrtoint capturing pointer?
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>
Juneyoung Lee via llvm-dev
2021-Feb-19 03:36 UTC
[llvm-dev] inttoptr->add->ptrtoint capturing pointer?
Hi, I think what Jeroen says is about the behavior of C programs. In C, an expression can be restrict-qualified, which isn't the case in LLVM IR; there is no 'i8* restrict' type or something like that. I guess noalias intrinsics are inserted to preserve the information when translating restrict pointers in C to IR. To summarize, the return value of inttoptr (which is an IR instruction) itself won't work as a restrict-qualified pointer because there is no restrict qualifier in IR. If it is somehow used by the noalias intrinsics, it should be able to gain the power to work as a restrict pointer.> x = (const float *)((int)x+off2)) > > I'm not sure why this should be capturing the pointer?The reason is that (int)x + off2 may accidentally point into a different object. A possible workaround is to use (const float*)((const char*)x+off2), which is guaranteed to preserve the provenance. clang-tidy has an option to detect integer-to-pointer casts to warn about possible performance degradation: https://clang.llvm.org/extra/clang-tidy/checks/performance-no-int-to-ptr.html Juneyoung On Fri, Feb 19, 2021 at 4:00 AM Ryan Taylor <ryta1203 at gmail.com> wrote:> 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$> >> >>-- Juneyoung Lee Software Foundation Lab, Seoul National University -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210219/39e4b446/attachment.html>