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

[Sanjoy Das via Phabricator via llvm-commits]

sanjoy added a comment.

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?

> - For **(d)**, it properly detects that the two variables might alias, and we reduce the set of false positives generated by stores to globals and function argument. The lit tests verify this.

Which lit test?

In any case we can't rely on the AA being smart or advanced for correctness.  That is, a less aggressive / more conservative AA should not cause us to miscompile code.

> The net result is that we ether end up in **(a)** or **(c)** which is in my opinion more desirable than what we currently have.

Optimizations based on (c) will generally be incorrect and so (a) or (c) is less desirable than (a).  That is, (a) == "always correct", (a) or (c) == "sometimes wrong".

I think Hal's question was more of the tune of: do you have optimizations that will be correct even with false negatives?  That is, even if the optimization thinks a value did not escape when it actually did, the transform it does will be be correct?  If so, that is interestingly different from what LLVM does today, and worth discussion _before_ we add this new capture tracker to LLVM.


Repository:
  rL LLVM

https://reviews.llvm.org/D27585