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

[Philip Reames via llvm-commits]

On 12/06/2016 12:57 PM, Jonas Devlieghere via Phabricator wrote:
> JDevlieghere added a comment.
>
> 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.
Before going down the road of *how* to implement the optimistic 
analysis, let's talk about whether doing so is worthwhile.  Do you have 
examples of transforms which could happen with such an analysis and 
don't happen today?  In practice, the iterative nature of the optimizer 
makes the simple capture tracking we do today very effective.  The only 
concrete example I know of where it doesn't work are connected 
sub-graphs of newly allocated objects.  e.g.
p1 = allocate();
p2 = allocate();
p1.next = p2;
p2.prev = p1;

I haven't seen enough examples of such cases to make the more elaborate 
analysis worthwhile yet.  Do you have motivating examples in your workloads?

(You may stumble across some pass ordering issues as well, but anything 
which can be tackled via repeat application of -O2 can be addressed 
without a new analysis.)

>
> 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.
Let me rephrase to make sure I understand: you're proposing an 
optimistic algorithm which starts with all objects assumed to be 
unescaped, a set of escaping facts from arguments/globals, and then 
iterates to a fixed point?
> 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?
Your second suggestion sounds like a reasonable starting place.  We 
might evolve the interface over time, but that's normal.
>
> PS: I'm not entirely sure what is meant by the last sentence in the TODO though, so I might be missing something. I'm doing my best to get a better understanding of how all of this works in LLVM, so please don't hesitate to point out if anything I mentioned doesn't make sense.
Today, BasicAA is using the conservative form of capture tracking. If we 
had an optimistic form which didn't itself rely on BasicAA, we could use 
that analysis for better precision in BasicAA.
>
>
> Repository:
>    rL LLVM
>
> https://reviews.llvm.org/D26685
>
>
>