Ryan Taylor via llvm-dev
2021-Feb-18 17:30 UTC
[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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210218/fec892cf/attachment.html>
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>