llvm dev - Feb 2021 - inttoptr->add->ptrtoint capturing pointer?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210218/d69f724a/attachment.html>

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