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

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 27 13:32:23 PST 2016


On Tue, Dec 27, 2016 at 1:19 PM, Jonas Devlieghere via Phabricator via
llvm-commits <llvm-commits at lists.llvm.org> wrote:

> JDevlieghere added a comment.
>
> In https://reviews.llvm.org/D27585#630030, @sanjoy wrote:
>
> > In https://reviews.llvm.org/D27585#623685, @JDevlieghere wrote:
> >
> > > Let's consider the following table:
> > >
> > > |                             | No AA               | Basic AA
>     | Advanced AA              |
> > > | --------------------------- | ------------------- |
> ------------------- | ------------------------ |
> > > | Current Capture Tracking    | false positives (a) | n/a
>    | n/a                      |
> > > | Optimistic Capture Tracking | false positives (b) | false negatives
> (c) | less false positives (d) |
> > >
> > > Right now, only situation **(a)** exists, where we get false positives
> for stores to non-aliasing function arguments and globals, as illustrated
> by the example in the original description of this patch. Optimistic
> capture tracking behaves exactly the same if no AA is provided, so
> situation **(a)** and **(b)** are identical.
> > >
> > > The interesting cases are **(c)** and **(d)**, especially in
> combination with the situation you described, where a "value is stored into
> some alloca then read and the read value stored into some global".
> > >
> > > - For **(c)**,  basic AA doesn't perform memory-based data-flow
> tracking and it returns a false negative, which in turn causes the
> optimistic capture tracker to return a false negative as well. Returning a
> false negative is less desirable than returning a false positive, i.e.
> situation **(a)**. So I suggest we enforce that this scenario can not
> occur, e.g. with an assert.
> >
> >
> > What would you assert?  That is, what would the assert look like?
>
>
> Originally I wanted to assert the algorithm used for AA. However, now I
> understand that unless the AA algorithm is perfect, there will always be a
> case where this generates a false negative. What I'd need for this to work
> properly is for AA to provide a guaranteed **must not alias** result.
> Unfortunately for me, this is inherently incompatible with what we have
> now. LLVM is (correctly) conservative in saying that something aliases,
> while I would need an implementation that is conservative in saying that
> something does not alias.
>
>
This is not statically decidable. You can prove that such a thing can not
exist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161227/26ee3b47/attachment.html>


More information about the llvm-commits mailing list