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

[Shuxin Yang]

Hi, Dan :

    You are absolutely right. Thank you for sharing your insight.
 >But as long as these needs are all kept distinct, all of these 
consumers should be ok with the analysis looking through Phi nodes.

    Arnold and I keep arguing "kept distinct" in order to fend off 
potential confusion and bug ( or the bug
we are not able to imagine at this time); while Nuno tries to convince 
us that his code dose not have problem for now.

On 3/4/13 10:21 AM, Dan Gohman wrote:
> 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 <mailto:aschwaighofer at apple.com>> wrote:
>
>
>     On Mar 4, 2013, at 11:27 AM, Nuno Lopes <nunoplopes at sapo.pt
>     <mailto: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 <mailto:llvm-commits at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
>
> _______________________________________________
> 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/543dcdc9/attachment.html>