[llvm] r176408 - recommit r172363 & r171325 (reverted in r172756)

Dan Gohman dan433584 at gmail.com
Mon Mar 4 10:21:25 PST 2013


Hello,

I haven't been following this issue closely, but this documentation patch
confuses me.

> The object pointer can also point to several underlying objects.
+If the same same size can be determined, a valid size will be returned.

> +the size of the object (or several underlying objects) concerned. If the
size
> +cannot be determined at compile time, ``llvm.objectsize`` returns
> +``i32/i64 -1 or 0`` (depending on the ``min`` argument).

For the sense of "object" which I believe is being used here (a whole
allocation) pointers never point to several underlying objects at the same
time. Phi nodes and other things allow pointers to point to different
objects each time they are evaluated, but each time they are evaluated,
they only point to (at most) one object. This is true for all instructions
which use pointers, so there's no reason to special case here.

>From scanning the emails, it seems the main source of confusion here is
about the different kinds of information that API consumers want. Some
consumers want to know the maximum distance from the pointer to the end of
the allocation. Some consumers want to know the maximum size of the entire
allocation. Possibly other consumers want other things. But as long as
these needs are all kept distinct, all of these consumers should be ok with
the analysis looking through Phi nodes.

Dan

On Mon, Mar 4, 2013 at 9:42 AM, Arnold Schwaighofer <aschwaighofer at apple.com
> wrote:

>
> On Mar 4, 2013, at 11:27 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote:
> >
> > FYI, the semantics of @llvm.objectsize I've been describing matches
> exactly that of gcc's __bultin_object_size().  If there's a bug somewhere,
> that's in the documentation.
>
> Then we have to update the description in the LangRef to include multiple
> pointed to objects. Otherwise, my interpretation of llvm.objectsize is
> possible. How about the attached patch to the documentation.
>
> We cannot expect people to go looking at what gcc's description says about
> an possibly related intrinsic to find out what LLVM's intrinsic means :).
> The LangRef should be the ultimate specification of an LLVM intrinsic.
>
>
> Best,
> Arnold
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130304/a33db9fb/attachment.html>


More information about the llvm-commits mailing list