[PATCH] D26685: [Analysis] Add Basic Escape Analysis

[Daniel Berlin via llvm-commits]

On Wed, Dec 7, 2016 at 10:35 AM, Hal Finkel via Phabricator via
llvm-commits <llvm-commits at lists.llvm.org> wrote:

> hfinkel added a comment.
>
> In https://reviews.llvm.org/D26685#614942, @JDevlieghere wrote:
>
> > I ran our local tests against the CaptureTracker and everything is
> properly detected. Most of our cases involve stores and the current
> implementation is very conservative in that it always assumes a store
> captures.
> >
> > The code also contains the following TODO, which I think I might be able
> to address with my implementation.
> >
> >   // TODO: If StoreCaptures is not true, we could do Fancy analysis
> >   // to determine whether this store is not actually an escape point.
> >   // In that case, BasicAliasAnalysis should be updated as well to
> >   // take advantage of this.
> >
> >
> > I only considers a values to be escaped if the it is stored to the
> enclosing function's arguments or to a global. I rely on AliasAnalysis to
> check that the pointer might be an alias to these values. Because
> AliasAnalysis depends on CaptureTracking, I see two possibilities:
> >
> > 1. Keeping the current interface and not using AliasAnalysis, but
> comparing for equality rather than checking for "might alias". This is not
> really conservative, though arguably what you might expect from setting
> `StoreCapture` to false?
> > 2. Adding a new interface where the caller provides alias analysis info,
> like what's currently done for the dominator tree. The AliasAnalysis
> implementation could continue using the current implementation where a
> store is assumed to capture.
> >
> >   What do you guys think?
>
>
> Our current use of capture tracking in AA is not very efficient
> (especially on large basic blocks, although the OrderedBasicBlock cache has
> made this a bit better). Using a pre-computed analysis could be
> significantly better.
>

Note: GCC computes escape analysis using the points-to constraint solver,
and even in interprocedural mode, is both faster and more accurate than
what llvm is doing.


>
> However, I'm not sure that I understand how this would work. Generally,
> the uses in AA care about whether or not a pointer has been captured before
> some point:
>

This is not quite how i'd phrase it, for a reason i'll explain in a second.


>
>   ptr2 = ...;
>   ...
>   ptr1 = foo();
>   x = *ptr1;
>   y = *ptr2; // might *ptr1 and *ptr2 alias here? It might depend on
> whether ptr2 is captured before the call to foo(). If it was, then foo()
> might return the pointer somehow. If not, then we know that ptr2 does not
> alias with ptr1.
>


This is really just flow sensitivity, because you care about knowing facts
at each program point.
You can transform it into a non-flow sensitive problem, sparsely, and with
the same accuracy, by virtualizing the variables and renaming them at each
possible "killing" site, where kills are things that capture (instead of
redefine,like memoryssa).
(This is one way, i'll show what gcc does after)

You can then solve it on that representation very quickly (if you don't
want to keep it around).

See https://arxiv.org/abs/1403.5952

Note we can compute the form you want in linear time, and the actual
capture tracking problem sparsely on it.


The other way is the gcc way, where it computes a whole-program answer at
once using a constraint solver

The *types* of constraints you need to solve capture tracking/etc are the
same as points-to, even if the formulation is not identical.
Whether it makes sense to do this without having a really good constraint
solver (which would take someone a few weeks to write), no idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161208/71572e79/attachment-0001.html>