On Thu, Oct 25, 2012 at 5:32 PM, Krzysztof Parzyszek <span dir="ltr"><<a href="mailto:kparzysz@codeaurora.org" target="_blank">kparzysz@codeaurora.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 10/25/2012 5:36 PM, Dan Gohman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
First, yes, it is wrong for AliasAnalysis implementations to trust LLVM<br>
IR types, for the most part. There's nothing in LLVM IR which would<br>
prevent you from having two myStruct instances which overlap here,<br>
sharing 4 bytes. Because of that, next really could be equal to &prev.<br>
<br>
In theory, you could help this situation by using TBAA; you could give<br>
next and prev fields different TBAA tags to say that a store to a next<br>
field never stores to a prev field.<br>
</blockquote>
<br></div>
In practice this is impossible to guarantee.  The only safe way of disambiguating the two objects is to prove that the pointers are different.<span class="HOEnZb"><font color="#888888"></font></span><br></blockquote><div>
<br>It may be impossible to guarantee if the input language is C (depending on how you interpret it).<br><br>However, the point of LLVM's TBAA system is to let front-ends make statements about aliasing that are difficult or impossible to prove from the IR alone. Front-ends for more restrictive source languages may actually be able to make guarantees about how linked list pointers are used. LLVM's TBAA tags are a way for them to describe at least some of those guarantees to optimizers.<br>
<br>Unless you're objecting to the fact that while LLVM says that metadata *may* be stripped at any time, there are no rules for when it *must* be stripped, and that arbitrary valid transformations can theoretically cause valid TBAA and other metadata to become invalid. This is true. This is an area where LLVM's preference for practicality over absolute correctness may be observed.<br>
<br>Dan<br><br></div></div>