<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 15, 2013 at 12:49 AM, Arnold Schwaighofer <span dir="ltr"><<a href="mailto:aschwaighofer@apple.com" target="_blank">aschwaighofer@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im">On Feb 14, 2013, at 10:21 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>> wrote:<div>
<blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div>What I meant by saying "understanding independent objects inside a structure<b>"</b> to is that just by looking at an llvm type say for example struct { int A[100]; int B[100]} you and seeing two gep accesses that index into the first and second field of the type you can not necessarily say that the access is not overlapping without fully evaluating the address computation:</div>

</div></blockquote><div><br></div><div>Yes, you need to fully evaluate it, but that's not really related to TBAA :)</div></div></blockquote></div><div><br></div><div><br></div></div><div>I was thinking of type trees that encoded fields giving more guarantees than LLVM IR currently conveys. Admittedly, I have not though this through, whether this could even remotely work for C.</div>
<div><br></div><div>In LLVM IR:</div><div class="im"><div><br></div><div>struct { int A[100]; int B[100]} S;</div><div><br></div></div><div>ptr = gep S, 0, 0, x</div><div>ptr2 = gep S, 0, 1, y</div><div><br></div><div>= load ptr, !tbaa !"structS::A"</div>
<div>= load ptr2, !tbaa !"structS::B"</div><div><br></div><div>using this you could tell that ptr and ptr2 do not alias without knowing about x and y. </div></div></blockquote><div><br></div><div style><br></div>
<div style>you've basically just pushed the problem off into the frontend :)</div><div style>Something needs to know to tag this with structS::A, and not something that combines structS::A and structS::B.</div><div style>
For simple structure accesses (IE not through pointers), this is certainly possible.</div><div style>For any pointer access, it's not possible without pointer analysis.</div><div style>IE a deference of an int (*[100]) could be an access to structS::A, structS::B, or some other random type.</div>
<div style>Note that your TBAA DAG below does not take this into account.</div><div style><br></div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Assuming certain language guarantees, which I don't know we could assume :).</div></div></blockquote><div><br></div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br></div><div>Where the type dag looks something like:</div><div><br></div><div>           /->structS::A <- int</div><div>structS->structS::B <- int</div></div></blockquote>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im"><div><br></div><div><blockquote type="cite"><div>In the case of pointer loops that iterate over your example type, it will properly discover that it overruns into the next field, and properly mark it as pointing-to that field as well.</div>

</blockquote></div><div><br></div></div><div>So for the following example it will conservatively say arrayidx and arrayidx2 alias?</div><div><br></div><div>%struct.anon = type { [256 x i64], i64, [256 x i64] }</div><div>
<br></div><div>define void @foo(i32 %x, i32 %y) {</div><div><div>  %arrayidx = getelementptr inbounds %struct.anon* @Foo, i32 0, i32 0, i32 %x</div><div>  %0 = store i64* %arrayidx, align 8</div><div>  %arrayidx2 = getelementptr inbounds %struct.anon* @Foo, i32 0, i32 2, i32 %y</div>
<div>  %1 = store i64* %arrayidx2, align 8</div><div>}</div></div></div></blockquote><div><br></div><div style><br></div><div style>Yes, when converted to may-alias info, it will.</div><div style><br></div></div></div></div>