<div dir="ltr">The results for aliasing are actually much worse than this, but yeah :)<div>See <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.9722&rep=rep1&type=pdf">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.9722&rep=rep1&type=pdf</a></div><div>and</div><div><a href="http://web.cs.ucla.edu/~palsberg/course/cs232/papers/ramalingam-toplas94.pdf">http://web.cs.ucla.edu/~palsberg/course/cs232/papers/ramalingam-toplas94.pdf</a><br></div><div><br></div><div>(may alias is undecidable, must alias is uncomputable)</div><div><br></div><div>This just means you *must* approximate sometimes (and hence, the thing you want, where you don't approximate, is not buildable).</div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 27, 2016 at 1:40 PM, Jonas Devlieghere <span dir="ltr"><<a href="mailto:jonas@devlieghere.com" target="_blank">jonas@devlieghere.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Tue, Dec 27, 2016 at 10:32 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>> wrote:<br>
><br>
><br>
> On Tue, Dec 27, 2016 at 1:19 PM, Jonas Devlieghere via Phabricator via<br>
> llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
>><br>
>> JDevlieghere added a comment.<br>
>><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>
>> > > |                             | No AA               | Basic AA<br>
>> > > | Advanced AA              |<br>
>> > > | --------------------------- | ------------------- |<br>
>> > > ------------------- | ------------------------ |<br>
>> > > | Current Capture Tracking    | false positives (a) | n/a<br>
>> > > | n/a                      |<br>
>> > > | Optimistic Capture Tracking | false positives (b) | false negatives<br>
>> > > (c) | less false positives (d) |<br>
>> > ><br>
>> > > Right now, only situation **(a)** exists, where we get false positives<br>
>> > > for stores to non-aliasing function arguments and globals, as illustrated by<br>
>> > > the example in the original description of this patch. Optimistic capture<br>
>> > > tracking behaves exactly the same if no AA is provided, so situation **(a)**<br>
>> > > and **(b)** are identical.<br>
>> > ><br>
>> > > The interesting cases are **(c)** and **(d)**, especially in<br>
>> > > combination with the situation you described, where a "value is stored into<br>
>> > > 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<br>
>> > > tracking and it returns a false negative, which in turn causes the<br>
>> > > optimistic capture tracker to return a false negative as well. Returning a<br>
>> > > false negative is less desirable than returning a false positive, i.e.<br>
>> > > situation **(a)**. So I suggest we enforce that this scenario can not occur,<br>
>> > > e.g. with an assert.<br>
>> ><br>
>> ><br>
>> > What would you assert?  That is, what would the assert look like?<br>
>><br>
>><br>
>> Originally I wanted to assert the algorithm used for AA. However, now I<br>
>> understand that unless the AA algorithm is perfect, there will always be a<br>
>> case where this generates a false negative. What I'd need for this to work<br>
>> properly is for AA to provide a guaranteed **must not alias** result.<br>
>> Unfortunately for me, this is inherently incompatible with what we have now.<br>
>> LLVM is (correctly) conservative in saying that something aliases, while I<br>
>> would need an implementation that is conservative in saying that something<br>
>> does not alias.<br>
>><br>
><br>
> This is not statically decidable. You can prove that such a thing can not<br>
> exist.<br>
><br>
<br>
</div></div>II thought so. Intuitively it makes sense, because if you do know what<br>
*does not* alias, you also know what *does* alias.<br>
</blockquote></div><br></div></div>