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

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Sat Mar 26 08:02:33 PDT 2016


With no offense meant, I've been writing solvers for 10+ years.  What you
are suggesting is not just a tweak.  Doing it on a per pointer basis is
neither trivial nor easy to keep sound. If you think it is, I would suggest
taking GCC's implementation and trying to do it. If what you say was true,
production compilers would be doing it.  But they don't.

The other problem you mention is, IMHO, not actually as interesting.  We
already have traditional methods (value profiling, etc) of knowing which
things matter.  Static prediction of this has a long history of over
promise and under delivery.

On Fri, Mar 25, 2016, 9:20 PM Jia Chen <jchen at cs.utexas.edu> wrote:

> On 03/25/2016 08:26 PM, Daniel Berlin wrote:
> >
> > Yeah.
> > It depends entirely on your goal. In reality, often what you really
> > want is something to say "hey, i've got this pointer over here, and i
> > really want to hoist  it up here. Do something, tell me if that is
> > possible".
> >
> And this is one motivation of my current research: how can various
> precision dimensions of a pointer analysis be effectively driven by its
> client.
>
> > (This is actually why i'm a fan of CFL-AA. You can essentially make it
> > as expensive or not expensive as you want, and it still does really
> > well in pracftice in time)
> >
> Again, "making it as expensive or not expensive as you want" is not
> something unique about cfl-aa. With the right tweak one can also do it
> with a traditional solver. The real interesting question here is how to
> find out what locations are most likely to matter and worth making
> expensive.
>
> - Jia
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160326/56cde010/attachment.html>


More information about the llvm-dev mailing list