<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 21, 2016 at 11:34 AM, Jia Chen <span dir="ltr"><<a href="mailto:jchen@cs.utexas.edu" target="_blank">jchen@cs.utexas.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<br>
<blockquote type="cite">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">It is merely a
demand-driven way of implementing existing analyses, by
extending those algorithms to track additional "pointed-to-by"
information. Laziness may help with the running time of the
cfl analysis when only partial points-to info is needed, but
if the client wants to do a whole-program analysis and require
whole-program points-to info (which is usually true for
optimizing compilers since they will eventually examine and
touch every piece of the codes given to it), should cfl-aa be
no different than traditional whatever-sensitive pointer
analysis?</div>
</blockquote>
<div><br>
</div>
<div>CFL, at least when I ran the numbers, was faster at all pairs
than existing analysis.</div>
</blockquote>
<br></span>
There could be many reasons for it, e.g. better implementations.
</div></blockquote><div><br></div><div>FWIW: the implementations i compared against are completely state of the art and very well engineered (IE not research crap :P).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"> Again, my point is that cfl-aa is more of an implementation strategy
than a fundamentally superior approach. <br></div></blockquote><div><br></div><div>The first part is true, but the second part depends on your definition of "superior approach".</div><div><div><br></div><div> You can solve andersens and steengaards and everything else using standard dataflow solvers, and that's an implementation strategy, but it will be really slow.</div></div><div><br></div><div>Part of the tradeoff is how fast something runs, and approaches that are orders of magnitude faster often change the calculus of what people do. For example, before hardekopf's work, andersens was considered too slow to be practical in a real compiler.</div><div><br></div><div>Now, GCC does it by default. </div><div><br></div><div>So i would call that approach a superior approach :)</div><div><br></div><div>So saying that CFL-AA offers nothing superior in terms of approach, IMHO, misunderstands the nature of the problem. If your goal is to get precision at all costs, then yes, it's not superior. If your goal is to get something into a production compiler, that is understandable, maintainable, can turn on and off field and context sensitivity easily, etc, then it may be a superior approach.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<blockquote type="cite">I'm talking about infrastructure wise, nothing in llvm
can take advantage because the APIs don't exist.
<div><br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">. Flow sensitivity is
helpful when the optimization pass itself is flow-sensitive
(e.g. adce, gvn), </div>
</blockquote>
</div>
<div><br>
</div>
<div>No api exists that they could use right now for this, and
you'd have to change things to understand answers are not valid
over the entire function.</div>
</blockquote>
<br></span>
I see what you are saying now. Sometimes flow/ctx-insensitive alias
queries can benefit from a flow/ctx-sensitive analysis, yet my
intuition is that such cases are likely to be rare. </div></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">I could go ahead
and modify those passes myself to carry on the study, but that
option probably won't be too interesting to the community. <br></div></blockquote><div><br></div><div>Right, because then you aren't testing LLVM, you are testing LLVM with better infrastructure :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Thank you very much for pointing that out to me.</div></blockquote><div><br></div><div>Happy to ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<br>
-- <br>
Best Regards,<br>
<br>
--<br>
Jia Chen
</span></div>
</blockquote></div><br></div></div>