<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 8, 2014 at 5:04 AM, Karthik Bhat <span dir="ltr"><<a href="mailto:kv.bhat@samsung.com" target="_blank">kv.bhat@samsung.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi majnemer, sunfish, rengolin,<br>
<br>
Hi All,<br>
This patches fixes PR16236 aproblem with TypeBasedAlias Analysis. Below is my understanding please help me review this patch and if i'm thinking in the right direction.<br>
The problem in this case seems to be that in case we have an union like -<br>
  union<br>
  {<br>
    short f0;<br>
    int f1;<br>
  } u, *up = &u;<br>
<br>
f0 and f1 may alias each other. But while constructing AliasSet for these in TypeBasedAlias Analysis during PathAliases we see that both the MDNodes corresponding to (f0 and f1) are not ancestor of each other and have a common root and thus conclude that they will Not alias each other. But in case of union this may not be correct f1 anf f0 may alias each other as thye operate on same underlining memory location.<br>
</blockquote><div><br></div><div>LLVM's approach for solving this problem is to do a BasicAA query first, and if BasicAA says MustAlias or PartialAlias, it doesn't do a TBAA query at all. This represents a kind of "best effort": the optimizer will make its best effort to discover whether the type information is unreliable, but if it doesn't discover a problem, then it assumes that the type information is reliable. As such, it's not safe in all cases, but the C standard's own definition of TBAA is not safe in all cases, and this is an attempt to implement the spirit of what the C standard desired while finding a practical balance with correctness.<br>
</div><div><br>Are you seeing a case where this approach is not sufficient?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In this patch we check that if both correspond to StructTyID type we evaluate it conservatively so that we do not incorrectly conclude that these two types are NoAlias.<br></blockquote><div><br></div><div>This is not safe, since pointers can be bitcasted to pointer types with arbitrary pointees.<br>
</div><div><br></div><div>Dan<br><br></div></div></div></div>