<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christian,<br>
<br>
Thank you so much for the reply! Please see my comments inline.<br>
<br>
<div class="moz-cite-prefix">On 03/21/2016 09:32 AM, Christian
Convey wrote:<br>
</div>
<blockquote
cite="mid:CAPfS4Zy+Jf-pwaQmh=1p-8C_X_efWO+7uqUMR9KfnBAxPg-nVg@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Jia,
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
style="font-size:12.8px">If one looks at existing research
literatures, there are even more algorithm to consider for
doing pointer analysis.</span></blockquote>
<div><br>
</div>
<div>For at least some published AA algorithms, there may be
some uncertainty about software patents and/or copyright. </div>
<div><br>
</div>
<div>At one point I was interested in the status of <a
moz-do-not-send="true"
href="https://dl.acm.org/citation.cfm?id=2466483">this AA
implementation</a> by Lian Li et al. IIRC, when I contacted
Lian to ask if there was any chance of getting it into LLVM,
IIRC she said that her employer wouldn't promise to relinquish
all possible claims it had on that algorithm's IP. So
unfortunately, at least in the U.S., an algorithm being
published in an academic journal doesn't remove all legal risk
associated with using it.</div>
</div>
</blockquote>
This is news to me. Thanks for sharing it.<br>
<blockquote
cite="mid:CAPfS4Zy+Jf-pwaQmh=1p-8C_X_efWO+7uqUMR9KfnBAxPg-nVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Also, speaking from my own experience, even when an AA
algorithm seems to be described in great detail in some piece
of literature (e.g., a phd thesis), there can still be a lot
of details which are glossed over, or which seem clear when
reading the document but which get a lot more confusing when
one tries to actually implement it. </div>
<div><br>
</div>
<div>That can make implementing such an algorithm take far
longer than one would expect based on just reading the
document. (It's also an argument in favor of requiring
academic papers which describe the behavior of a software
implementation to actually include a working copy of the
source code, IMHO.)</div>
</div>
</blockquote>
My personal experience also coincides. And even if the paper does
come with an artifact or source codes, they are usually
proof-of-concept implementations with lots of important real-world
corner cases ignored. <br>
<blockquote
cite="mid:CAPfS4Zy+Jf-pwaQmh=1p-8C_X_efWO+7uqUMR9KfnBAxPg-nVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
style="font-size:12.8px">So my question here is: what
kind(s) of precision really justify the cost and what kinds
do not? Has anybody done any study in the past to evaluate
what kinds of features in pointer analyses will benefit what
kinds of optimization passes?</span><br>
</blockquote>
<div><br>
</div>
<div>At one point I discussed this with Daniel Berlin, but I'm
having trouble find a record of the conversation. IIRC, he
says that he once threw a huge amount of computing power at
doing a <i>full</i> context-sensitive AA on some software,
and the speedup he observed in the resulting program as
underwhelming (10-15%?). <br>
</div>
</div>
</blockquote>
I kind of expect that. As you mentioned later, most optimization
passes work in a context-insensitive manner (i.e. they won't clone a
function and optimize differently on different clones). Context
sensitivity on the pointer analysis side is probably not going to
help a lot if the client cannot fully capitalize on it. In the
settings of compiler optimization, my guess is that flow
sensitivity, field sensitivity, heap model and external library
annotations are the four aspects that are likely to matter. <br>
<br>
I did some preliminary experiments with licm on c programs over the
last weekend. I chose licm because intuitively that's the
optimization that could have the biggest performance impact. The
result suggested that tbaa, cfl-aa, scev-aa and globals-aa yields
very little additional benefits over basic-aa. Again, both the
methodology and benchmark selection are very immature and the
results need to be double-checked, but my hope is that by looking at
how aa algorithms and their clients interact I may be able to get
some hints on what kind of aa a compiler really wants. <br>
<blockquote
cite="mid:CAPfS4Zy+Jf-pwaQmh=1p-8C_X_efWO+7uqUMR9KfnBAxPg-nVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>I can't remember if that was with GCC or LLVM. That result
is a data point, although it may not say much about how much
additional speedup could be realized if the algorithms which
use the AA results were themselves adapted to capitalize on
fully context-sensitive, flow-sensitive,
hula-dancer-on-the-dashboard AA results.</div>
</div>
</blockquote>
<blockquote
cite="mid:CAPfS4Zy+Jf-pwaQmh=1p-8C_X_efWO+7uqUMR9KfnBAxPg-nVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div class="gmail_extra">Cheers,</div>
<div class="gmail_extra">Christian</div>
<div class="gmail_extra"><br>
</div>
</div>
</blockquote>
<br>
-- <br>
Best Regards,<br>
<br>
--<br>
Jia Chen<br>
</body>
</html>