<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 28, 2016, at 8:26 AM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" class="">dberlin@dberlin.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class=""><span class=""><blockquote type="cite" class=""><br class="">
</blockquote></span>
For the example to work here the CSE pass itself needs to be
flow-sensitive and context-sensitive. I don't think that's how most
optimizations in LLVM work. If it is, then I agree with all you
said. But if it isn't, there's no point in bumping up the context
sensitivity just for the pointer analysis.<br class="">
<br class="">
As Daniel mentioned earlier in this thread, the analysis analysis
framework in LLVM doesn't provide any APIs for flow-sensitive
queries as well as context-sensitive queries. This design choice
almost eliminate any possibilities for a flow-sensitive or
context-sensitive pointer analysis to be useful. Strangely, the set
of APIs does support 1-CFA context-sensitive mod-ref queries (so I
guess one could somehow reap some context-sensitive benefits out of
them after all). To me that design incoherence looks confusing, but
I'm pretty sure you know much better than me why it should work that
way :)</div></blockquote><div class=""> </div><div class="">In general, I would never assume someone sat down and thought *really hard* about the design of an API in a piece of software to get it right for all time. It happens, but it's actually pretty rare. One of the most limited resources most software teams have is time, and they use often use that time to get done what they need, and design APIs based on current and easily predictable future needs.<br class=""></div><div class=""><br class=""></div><div class="">The same thing is true about LLVM's APIs. You shouldn't assume we sat down, thought really hard about AA by meditating upon a mountain, and then designed this API. Instead, some thought was put into it, based on current and easily predicted needs, and then people moved on.</div><div class=""><br class=""></div><div class="">I can't say this was the wrong choice, either, given how long it has been since someone has even come along considering implementing context sensitive or flow-sensitive AA (and having talked to tons of people over the years, this is *not* a chicken and egg problem. Literally nobody has had a *strong* desire). It wouldn't make much sense to try to design an API without any implementations that want to use those API's.</div><div class=""><br class=""></div><div class="">As that changes, i expect the AA API will be redesigned and reworked to accomodate the needs of those things.</div></div></div></div></div></blockquote><br class=""></div><div>FWIW, DS-AA is context sensitive in this way, and LLVM definitely does take advantage of it. Even circa 2005. This is the whole point of chapter 4 of <a href="http://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html" class="">http://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html</a> </div><div><br class=""></div><div>-Chris</div><br class=""></body></html>