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

Jonas Devlieghere via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 8 00:28:24 PST 2016


JDevlieghere added a comment.

In reply to @reames e-mail: I don't know what particular transformation would benefit from this change, but I can hardly imagine that making it more accurate is a bad thing. Consider the following example:

  define void @sample() {
  entry:
    %ptr = alloca i32
    store i32 1, i32* %ptr
    %ptrtoptr = alloca i32*
    store i32* %ptr, i32** %ptrtoptr
    ret void
  }

The current implementation of CaptureTracking says that `%ptr` escapes because it's the operand of the second store. What I propose is to only consider `%ptr` to escape if it's stored to either a global or to one of the arguments of the function. Neither is the case in the example, so it would not be considered escaped. So why do we need AliasAnalysis? Because `%ptr` might be stored to another pointer that's aliasing a function argument or global. With option (2), AA would continue working as it does today (considering any store to capture), but other passes that rely on AA anyway, could choose to use the more optimistic implementation.

Since I don't think that option (2) adds much code, I'll create a new differential to show what I mean exactly. Once we agree on whether this is a good idea or not we can look into the other improvements you guys mentioned such as the lazy caching and making the optimistic algorithm context-sensitive. I think it would be good to split those in separate changes anyway.


Repository:
  rL LLVM

https://reviews.llvm.org/D26685





More information about the llvm-commits mailing list