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

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


The results for aliasing are actually much worse than this, but yeah :)
See
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.9722&rep=rep1&type=pdf
and
http://web.cs.ucla.edu/~palsberg/course/cs232/papers/ramalingam-toplas94.pdf

(may alias is undecidable, must alias is uncomputable)

This just means you *must* approximate sometimes (and hence, the thing you
want, where you don't approximate, is not buildable).


On Tue, Dec 27, 2016 at 1:40 PM, Jonas Devlieghere <jonas at devlieghere.com>
wrote:

> On Tue, Dec 27, 2016 at 10:32 PM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
> >
> >
> > 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.
> >
>
> II thought so. Intuitively it makes sense, because if you do know what
> *does not* alias, you also know what *does* alias.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161227/3772622e/attachment.html>


More information about the llvm-commits mailing list