<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Nuno,<br>
<br>
Can you take a look at bug 15540? It seems that this commit result
in 10% GVN pass time regressions. Please let me know if you need
more information. Thank you. <br>
<br>
-Yi<br>
<br>
On 3/19/13, 10:01 AM, Shuxin Yang wrote:<br>
</div>
<blockquote cite="mid:514899E2.30003@gmail.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<br>
<div class="moz-forward-container"><br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0"
cellpadding="0" cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>Re: [llvm] r176408 - recommit r172363 & r171325
(reverted in r172756)</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date:
</th>
<td>Sun, 03 Mar 2013 15:45:00 -0800</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From:
</th>
<td>Shuxin Yang <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:shuxin.llvm@gmail.com"><shuxin.llvm@gmail.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td>Arnold Schwaighofer <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:aschwaighofer@apple.com"><aschwaighofer@apple.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC: </th>
<td>Nuno Lopes <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:nunoplopes@sapo.pt"><nunoplopes@sapo.pt></a>,
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>Hi, Arnold:
You are right. As I put in the report to the pr14988, my concerns
have two parts:
1) in alias analysis context, while Nuno's change dose not seem
correctness problem for what we have today.
It likely has problem in the future, as it deviate the original
meaning of class ObjectSizeOffsetVisitor.
I gave a contrived problem in the previous mail.
What you proposed here is that : if Nuno's change have to be
committed, we can remedy this concern by
coming up another set of functions, each having *CLEAR* meaning,
and semantics.
That is absolutely right, but I don't think it's worth that
trouble.
2) in the context llvm.objectsize related optimization. I'm not
expert of the llvm lang-ref.
However, IMHO, even if it has some loophole in the lang spec,
we should not take this advantage to
code hard to read or maintain.
.
> Shuxin, I think your concern could be addressed by introducing a family of functions that make their semantics very clear:
>
> // Returns the size if there is a set of identified underlying objects
> // and they all share the same size. UnknownSize otherwise.
> getSizeOfUnderlyingObjects()
> // Returns the pointer adjusted size if there is a set of identified underlying objects
> // and the pointer adjusted values all share the same size. UnknownSize otherwise.
> getSizeOfPointerAdjustedUnderlyingObjects()
>
> // Returns the size of an underlying object if the underlying object can
> // be identified as a unique identified underlying object.
> getSizeOfUniqueUnderlyingObject()
> // Returns the size of an pointer adjusted underlying object if the underlying
> // object can be identified as a unique identified underlying object.
> getSizeOfPointerAdjustedUniqueUnderlyingObject()
>
> And the proper usage within our code base.
>
> There remains the concern about the semantics of "llvm.objectsize.i32/i64":
> Which of above functions to you map it to. See my previous email.
>
> (Possibly utility classes like ObjectOffsetVisitor will also have to be renamed to reflect what they do)
>
> Best,
> Arnold
>
</pre>
<br>
</div>
<br>
</blockquote>
<br>
</body>
</html>