[llvm-dev] Existing studies on the benefits of pointer analysis

[Chris Lattner via llvm-dev]

On Mar 21, 2016, at 10:00 AM, Jia Chen via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>> So my question here is: what kind(s) of precision really justify the cost and what kinds do not?
>> 
>> Depends entirely on your applications.
>>  
>> Has anybody done any study in the past to evaluate what kinds of features in pointer analyses will benefit what kinds of optimization passes?
>> Yes.
>> Chris did many years ago, and i've done one more recently.
> 
> Great! Are they published somewhere? Can the data be shared somehow?


My results are published here:
http://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html <http://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html>

Sadly, they are over a decade out of date, and some things have changed since then :-)

>> PS2: If no such evaluation exists in the past, I'd happy to do that myself and report back my findings if anyone here is interested.
>> I don't think any of the world is set up to make that valuable.
>> 
>> Nothing takes advantage of context sensitivity, flow sensitivity, etc.
> I agree that nothing takes advantage of context sensitivity. But I would argue against flow sensitivity, field sensitivity, heap model and external function models. Flow sensitivity is helpful when the optimization pass itself is flow-sensitive (e.g. adce, gvn), and field sensitivity is helpful when a struct contains multiple pointers. Heap sensitivity is basically what motivates Chris Lattner's PLDI'07 paper, and external function models are helpful since without them the analysis has to be extremely conservative and concludes everything that external functions touch all may-alias each other. 

I’m still a big fan of context sensitive, flow insensitive, unification based models.  Contrary to your claim, context sensitivity *is* useful for mod-ref analysis, e.g. “can I hoist a load across this call”?  Context sensitivity improves the precision of the mod/ref set of the call.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160325/02c9fd60/attachment.html>