<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 27, 2016 at 1:19 PM, Jonas Devlieghere via Phabricator via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">JDevlieghere added a comment.<br>
<span class=""><br>
In <a href="https://reviews.llvm.org/D27585#630030" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D27585#630030</a>, @sanjoy wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D27585#623685" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D27585#623685</a>, @JDevlieghere wrote:<br>
><br>
> > Let's consider the following table:<br>
> ><br>
</span><span class="">> > |                             | No AA               | Basic AA            | Advanced AA              |<br>
> > | --------------------------- | ------------------- | ------------------- | ------------------------ |<br>
> > | Current Capture Tracking    | false positives (a) | n/a                 | n/a                      |<br>
> > | Optimistic Capture Tracking | false positives (b) | false negatives (c) | less false positives (d) |<br>
> ><br>
> > 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.<br>
> ><br>
> > 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".<br>
> ><br>
> > - 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.<br>
><br>
><br>
> What would you assert?  That is, what would the assert look like?<br>
<br>
<br>
</span>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.<br>
<span class=""><br></span></blockquote><div><br></div><div>This is not statically decidable. You can prove that such a thing can not exist.</div><div><br></div></div></div></div>