[PATCH] D27585: [CaptureTracking] Add optimistic capture tracker for stores

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D27585#622547, @JDevlieghere wrote:

> In https://reviews.llvm.org/D27585#622381, @hfinkel wrote:
>
> > In https://reviews.llvm.org/D27585#621980, @JDevlieghere wrote:
> >
> > > In https://reviews.llvm.org/D27585#621863, @hfinkel wrote:
> > >
> > > > > Otherwise, it only consider %ptr to escape in the previous example if it is stored to either a global or to one of the arguments of the function.
> > > >
> > > > I suppose this is named "optimistic" because it might return a false negative? If the pointer value is stored into some alloca then read and the read value stored into some global, then the value is captured but your analysis will return false. Is this what you intend?
> > >
> > >
> > > Does the example below cover what you have in mind?
> > >
> > >   @global = external global i32*
> > >  
> > >   define void @sample() {
> > >   entry:
> > >     %ptr = alloca i32
> > >     store i32 1, i32* %ptr
> > >     %ptrtoptr = alloca i32*
> > >     store i32* %ptr, i32** %ptrtoptr
> > >     %deref = load i32*, i32** %ptrtoptr
> > >     store i32* %deref , i32** @global
> > >     ret void
> > >   }
> > >
> > >
> > > If so, the escape of `%ptr` is properly detected by my change. I have a small printer pass for capture tracking which enables me to easily verify this kind of stuff. I will update my diff to include it, we can always remove it again later.
> >
> >
> > Can you please explain how this is detected? The store is to an alloca, and I don't believe that the system does any kind of memory-based data-flow tracking.
>
>
> I don't know enough about AA to make a definitive statement about this. Conceptually, everything makes sense up the `isNoAlias` call. The two pointers do point to the same value, so assuming a perfect AA implementation, the results is not totally unexpected. Maybe the default is very conservative and says that's it can't say for sure that the pointer and the global don't alias. As a result the pointer is considered to be captured. The test case I added for storing to the function argument behaves exactly the same, it reports the pointer being captured as desired. I'll dig deeper into AA, because I want to understand what happens, but for now this is the best explanation I can give.


Yea, we need to figure this out. Do you have BasicAA enabled? What happens if you add -aa-pipeline=basic-aa to the opt command?

> 
> 
>> In any cases, some regression test cases will be necessary.
> 
> I've added 3 tests to illustrate the added merit of this change. Since the printer pass makes it easy to test the current CT implementation, I'm planning on adding more tests for the other parts of the algorithm in a separate differential.




Repository:
  rL LLVM

https://reviews.llvm.org/D27585