<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br><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></div></div></div></div></blockquote><div><br></div><div>Imagine</div><div>int - offset 4</div><div>float - offset 4</div><div>int - offset 12</div><div><br></div><div>merge(first int field, float) == </div><div>mergeintfloat -no offset info<br></div><div> </div><div>You can no longer disambiguate this against second int field, even though it can't possibly overlap, not for type reasons, but for offset reasons.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div> </div></div><br></div></div>
</blockquote></div><br></div></div>