<div dir="ltr">Juneyoung said he hadn't started working on it yet, so I'm going to take a look at it also.<div><br></div><div>How will inttoptr work with the new restrict patches?  Certainly the int2ptr capturing shouldn't nullify the restrict qualifier.</div><div><br></div><div>Thanks.<br><div><div><br></div><div><br></div><div><div><br></div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 18, 2021 at 12:04 PM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think you are working with a custom llvm here but I will<br>
make a few general statements that might help:<br>
<br>
- The noalias intrinsic as you've shown it captures, unfortunately.<br>
   We don't have the `nocapture_maybe_returned` attribute in IR yet that <br>
the Attributor uses for these situations,<br>
   IIRC, Juneyoung is working on making it an LLVM-IR enum attribute <br>
already.<br>
<br>
- int2ptr is assumed to capture in basically every analysis I've seen. <br>
It doesn't intrinsically but it is really<br>
   hard to get it right. That said, we could allow *very* special <br>
patterns but I would argue those should be recognized<br>
   in instcombine and replaced there.<br>
<br>
- Philip and I are working to define capture better for the lang ref, we <br>
might want to include some examples and<br>
   rational around int2ptr when we have a coherent model.<br>
<br>
I've CC'ed people that might correct me or augment my answer, hope this <br>
helps :)<br>
<br>
~ Johannes<br>
<br>
<br>
On 2/18/21 9:17 AM, Ryan Taylor via llvm-dev wrote:<br>
> I have an example:<br>
><br>
> foo(float * restrict y, int off1, int off2) {<br>
>    float * restrict x;<br>
>    for (..) {<br>
>      for (..) {<br>
>        x = y+off1;<br>
>      }<br>
>      x = (const float *)((int)x+off2))<br>
><br>
> I'm not sure why this should be capturing the pointer?<br>
><br>
> For instance, looking at scoped noalias dbg info:<br>
><br>
> SNA: Capture check for B/CSB UO:   %54 = inttoptr i32 %add83 to float*,<br>
> !dbg !101<br>
> SNA: Pointer   %1 = call float* @llvm.noalias.p0_float(float* %0, metadata<br>
> !38), !dbg !41 might be captured!<br>
><br>
> Is this implying that the noalias intrinsic might be capturing the pointer?<br>
> It doesn't look like "noalias" intrinsic has NoCapture property on the<br>
> pointer:<br>
><br>
> def int_noalias       : Intrinsic<[llvm_anyptr_ty],<br>
>                                    [LLVMMatchType<0>, llvm_metadata_ty],<br>
>                                    [IntrArgMemOnly, Returned<0>]>;<br>
><br>
> It should though right? From the definition of capture it is returning the<br>
> pointer; however, we know nothing is happening here.<br>
><br>
> I'm on llvm 10 with Hal's restrict patches.<br>
><br>
> Thanks.<br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>