<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi, Dan :<br>
    <br>
       You are absolutely right. Thank you for sharing your insight. <br>
    >But as long as these needs are all kept distinct, all of these
    consumers should be ok with the analysis looking through Phi nodes.<br>
     <br>
       Arnold and I keep arguing "kept distinct" in order to fend off
    potential confusion and bug ( or the bug <br>
    we are not able to imagine at this time); while Nuno tries to
    convince us that his code dose not have problem for now. <br>
    <br>
    <div class="moz-cite-prefix">On 3/4/13 10:21 AM, Dan Gohman wrote:<br>
    </div>
    <blockquote
cite="mid:CAF4K+2jwPNseAdGcU6d8YxTMNFKcUT9_tKJG13etPSqK=k1fbA@mail.gmail.com"
      type="cite">
      <div>Hello,</div>
      <div><br>
      </div>
      <div>I haven't been following this issue closely, but this
        documentation patch confuses me.</div>
      <div><br>
      </div>
      > The object pointer can also point to several underlying
      objects.
      <div>
        +If the same same size can be determined, a valid size will be
        returned.</div>
      <div><br>
      </div>
      <div>
        <div>> +the size of the object (or several underlying
          objects) concerned. If the size</div>
        <div>> +cannot be determined at compile time,
          ``llvm.objectsize`` returns</div>
        <div>> +``i32/i64 -1 or 0`` (depending on the ``min``
          argument).</div>
      </div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>Dan</div>
      <br>
      <div class="gmail_quote">On Mon, Mar 4, 2013 at 9:42 AM, Arnold
        Schwaighofer <span dir="ltr"><<a moz-do-not-send="true"
            href="mailto:aschwaighofer@apple.com" target="_blank">aschwaighofer@apple.com</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div class="im"><br>
            On Mar 4, 2013, at 11:27 AM, Nuno Lopes <<a
              moz-do-not-send="true" href="mailto:nunoplopes@sapo.pt">nunoplopes@sapo.pt</a>>
            wrote:<br>
            ><br>
            > 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.<br>
            <br>
          </div>
          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.<br>
          <br>
          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.<br>
          <br>
          <br>
          Best,<br>
          Arnold<br>
          <br>
          <br>
          _______________________________________________<br>
          llvm-commits mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
          <a moz-do-not-send="true"
            href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits"
            target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
          <br>
        </blockquote>
      </div>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>