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

Jonas Devlieghere via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 27 13:40:04 PST 2016


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.


More information about the llvm-commits mailing list