[llvm-dev] Return on nocapture pointer

Piotr Padlewski via llvm-dev llvm-dev at lists.llvm.org
Fri Apr 28 09:58:34 PDT 2017


2017-04-28 18:45 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>:

> Hi Piotr,
>
> On Fri, Apr 28, 2017 at 9:18 AM, Piotr Padlewski via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Thanks guys.
> > Do you it make sense to extend the definition in LangRef?
>
> If you're asking if it makes sense to allow nocapture on returned
> arguments, then I don't think it make sense.  Right now we assume a
> pointer that only has nocapture uses is not captured.  That will not
> be true with the spec change you're proposing.
>
> No, I was making sure if I could mark invariant.group.barrier as
nocapture, but since barrier returns the pointer it takes, I can't do it.

Piotr


> -- Sanjoy
>
> > If so I will be
> > happy to upload a patch.
> >
> > Piotr
> >
> > 2017-04-28 17:58 GMT+02:00 Hal Finkel <hfinkel at anl.gov>:
> >>
> >>
> >>
> >> On 04/28/2017 10:22 AM, Piotr Padlewski via llvm-dev wrote:
> >>
> >> Hi,
> >> I have a question about semantics of nocapture attribute:
> >> "This indicates that the callee does not make any copies of the pointer
> >> that outlive the callee itself. "
> >> Is returing a pointer considered outliving callee? For example is this
> >> code valid:
> >>
> >>
> >> Yes, it includes returning the pointer. The code below is invalid. The
> >> return value outlives the callee itself.
> >>
> >>
> >> define i8* @foo(i8* nocapture %p)
> >>   ret i8* %p
> >> }
> >>
> >> The documentation also mention that " This is not a valid attribute for
> >> return values.", but I interpret that it is is about this case:
> >>
> >> declare i8* nocapture @bar(i8* %p)
> >>
> >>
> >> Correct.
> >>
> >>  -Hal
> >>
> >>
> >> Piotr
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >>
> >> --
> >> Hal Finkel
> >> Lead, Compiler Technology and Programming Languages
> >> Leadership Computing Facility
> >> Argonne National Laboratory
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://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/20170428/d7336c6d/attachment.html>


More information about the llvm-dev mailing list