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

[Hal Finkel via Phabricator via llvm-commits]

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.

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:

  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.

Would your escape analysis tell us this?

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




Repository:
  rL LLVM

https://reviews.llvm.org/D26685