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

[Jonas Devlieghere via Phabricator via llvm-commits]

JDevlieghere added a comment.

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.
- 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.

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.


Repository:
  rL LLVM

https://reviews.llvm.org/D27585