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

Jia Chen via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 21 11:34:08 PDT 2016



>     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?
>
>
> CFL, at least when I ran the numbers, was faster at all pairs than 
> existing analysis.

There could be many reasons for it, e.g. better implementations. Again, 
my point is that cfl-aa is more of an implementation strategy than a 
fundamentally superior approach.
>
>
>     Great! Are they published somewhere? Can the data be shared somehow?
>
>
> No, and sadly, no
:(
> I'm talking about infrastructure wise, nothing in llvm can take 
> advantage because the APIs don't exist.
>
>     . Flow sensitivity is helpful when the optimization pass itself is
>     flow-sensitive (e.g. adce, gvn),
>
>
> 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.

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. 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.

Thank you very much for pointing that out to me.

-- 
Best Regards,

--
Jia Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/8e70c55f/attachment.html>


More information about the llvm-dev mailing list