<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 21, 2016 at 12:26 PM, 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"><span><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">
 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.<br>
<br>
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.<br>
<br>
Now, GCC does it by default.<br>
<br>
So i would call that approach a superior approach :)<br>
<br>
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.<br>
<br>
<br>
</blockquote></span>
Apparently "superior approach" is a misnomer on my side. My apologies. </blockquote><div><br></div><div>No worries at all!</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">What I should have said is "an approach with superior precision". Both cfl and Ben Hardekopf's work you mentioned (which improves analysis performance by using SSA transformation as a pre-pass to eliminate easy-to-analyze pointers)</blockquote><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"> can be viewed as optimizations on standard dataflow solver,</blockquote><br class="">Well, not quite. Just to be pedantic:<br><div>It does hash value numbering and CSE and some other things on the constraint graph.  </div><div><br></div><div>CFL is not a dataflow solver at all. It's a graph reachability solver.</div><div>Ben's work is a constraint solver.</div><div>It does not know or care about CFG's, basic blocks, etc.</div><div>Dataflow solvers are like Ryder and Landi's approach</div><div><br></div><div><br></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"> but at the end of the day they do nothing more than that. </blockquote><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">From a client's perspective, they are no different from standard solvers except they are faster.<br></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">
<br>
I do acknowledge that cfl may work better in practice (although I held different opinions about understandability and maintainability). </blockquote><div><br></div><div>Sure. Having implemented tons and tons and tons of these algorithms and things, i'd argue that constraint solving tends to be easier to understand once you get it, but has limitations that are harder to overcome than in CFL land.</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">It's just that I tend to make judgment of pointer analysis based on the need of a client. </blockquote><div><br></div><div>Thinking about individual clients, while useful, is not always the right end game.</div><div><br></div><div>It pretty much  does not matter if i improve GVN if now it just catches cases some other cheap pass does anyway.</div><div>Maybe it does in some ways, but it's often not going to let you remove that other pass, or the expense of improving it is not worth the cost.</div><div><br></div><div>So providing context-sensitive AA to a pass so it can do an amazing job will buy you pretty much nothing if the other passes can do the same job with less info.</div><div><br></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">Again, I meant no offense and I apologize for my inappropriate choice of words.<div><div><br></div></div></blockquote><div><br></div><div>It was neither offensive nor inappropriate :)</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><div>
<br>
-- <br>
Best Regards,<br>
<br>
--<br>
Jia Chen<br>
</div></div></blockquote></div><br></div></div>