<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><div>I do not believe the current proposal will solve all of those cases, particularly when the fields are the same type and structures are compatible but they cannot overlap in C/C++ anyway.</div><div><br></div></div></div></div></blockquote><div>One of the threads is titled "<span style="font-size:inherit;font-weight:inherit">[PATCH] D20665: Claim NoAlias if two GEPs index different fields of the same struct"</span></div><div><br></div><div>For example, given<br><span style="font-size:12.8px">struct {</span><br style="font-size:12.8px"><span style="font-size:12.8px">  int arr_a[2];</span><br style="font-size:12.8px"><span style="font-size:12.8px">  int arr_b[2];</span><br style="font-size:12.8px"><span style="font-size:12.8px">};</span></div><div>assume you cannot see the original allocation site.<br></div><div>in llvm ir gep(arr_b,  -1) is legally an access to arr_a[1].</div><div>You can use -1 even though it's going to be a pointer to [2 x i32].</div><div>Thus, you can't even tell that gep(arr_a, 0) and  gep(arr_b, -1) do not overlap without being able to know *something* about the layout of fields in the structure you are talking about.</div><div><br></div><div>I'd start with: It should not require tbaa to determine that loads from geps that arr_a and arr_b cannot overlap.   It is true regardless of the types involved.</div><div><br></div><div>In terms of "who cares", Google definitely compiles with -fno-strict-aliasing (because third party packages are still not clean enough), and last i looked, Apple did the same (but i admittedly have not kept up).</div><div><br></div><div>GCC can definitely disambiguate field accesses (through points-to and otherwise) better than LLVM in a situation where strict aliasing is off.</div><div><br></div><div>As an aside, i also can't build a sane field-sensitive points-to on our current type system, because the types and structures are already meaningless  (and we are busy making it weaker, too).</div><div>I don't think we are going to want to tie field-sensitive points-to to TBAA (you definitely want to be able to run the former without the latter), but right now that is the only metadata you can use.</div><div><br></div><div>Finally, the merging of TBAA is definitely going to be more conservative than the merging of field offset info: If we merge a load of an int and a float, we will, IIRC, go to the nearest common ancestor in TBAA.   The field offset info may actually still be identical between the two, but we will lose it by creating/or going to the common ancestor.</div><div><br></div><div><br></div><div><br></div><div> </div></div><br></div></div>