Jeroen Dobbelaere via llvm-dev
2021-Feb-18 17:40 UTC
[llvm-dev] inttoptr->add->ptrtoint capturing pointer?
> 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<mailto: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<mailto: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/733b1998/attachment.html>
Johannes Doerfert via llvm-dev
2021-Feb-18 17:44 UTC
[llvm-dev] inttoptr->add->ptrtoint capturing pointer?
On 2/18/21 11:40 AM, Jeroen Dobbelaere 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)I'm very concerned about looking through `int2ptr(ptr2int(x))`. I'd need to go back to our old conversations and examples though. From memory, I would think there can be a problem even if the pattern is as simple as that, e.g., if the ptr2int has more users (which might only be other int2ptr's). This is a very delicate part that has the tendency to break all our "smarts". ~ Johannes> > 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<mailto: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<mailto: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$>
Ryan Taylor via llvm-dev
2021-Feb-18 17:50 UTC
[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/fb03794a/attachment-0001.html>