[llvm-dev] inttoptr->add->ptrtoint capturing pointer?

[Jeroen Dobbelaere via llvm-dev]

Wrt to Hal Finkel patches, as far as I remember, the capture was intentionally. But as mentioned before,
those patches have a number of shortcomings.

- The current top-of-tree has the 'llvm.experimental.noalias.scope.decl', which solves the issue of not knowing
 where a restrict variable was inlined. It does not yet support local restrict variables.
- a more complete version for full restrict is available here: https://reviews.llvm.org/D68484
  (still no rebase to the current top-of-tree though)
- the 'restrict specification' says:
-- 'Note146:  that "based" is defined only for expressions with pointer types.'(See [0]) -> anything can happen
-- it also specifies that 'x = y + off1' triggers undefined behavior, as both x and y are restrict pointers in the same scope.
  (but for this case, the full restrict implementation should be doing the expected thing, as long as 'y' is not dereferenced).

Greetings,

Jeroen Dobbelaere

[0] 6.7.3.1 Formal definition of restrict from n2573.pdf (See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2573.pdf)

> -----Original Message-----
> From: Johannes Doerfert <johannesdoerfert at gmail.com>
> Sent: Thursday, February 18, 2021 18:04
> To: Ryan Taylor <ryta1203 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?
> 
> 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://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/llvm-
> dev__;!!A4F2R9G_pg!I1bWkslVA0HB3sA08gBm2SpDkkuJGo7_BZCl0EhGoAhdaMvJgk6GxED6CUi
> QF9_pVbfOMbQq$