<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Daniel Berlin" <dberlin@dberlin.org><br><b>To: </b>"Hal J. Finkel" <hfinkel@anl.gov><br><b>Cc: </b>"Eli Friedman" <eli.friedman@gmail.com>, "llvm-dev" <llvm-dev@lists.llvm.org>, "Richard Smith" <richard-llvm@metafoo.co.uk><br><b>Sent: </b>Monday, July 25, 2016 6:58:27 PM<br><b>Subject: </b>Re: [llvm-dev] Alias Analysis with inbound GEPs<br><br><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><div><div><div class="gmail-h5"><div>></div>
<div>> It is actually undefined behavior. This is explicitly called out in Annex J.2: "An array subscript is out of range, even if an object is apparently accessible with the given subscript (as in the lvalue expression a[1][7] given the declaration int a[4][5])
". If you break it apart into separate steps, the interesting bit is that the implicit array-to-pointer conversion is not equivalent to a cast; "int* b = (int*)a;" is not equivalent to "int* b = *a;", even though the expressions have the same type and value.</div>
<div>></div>
<div>> There currently isn't any way to model the aliasing behavior of the address-of operator or array-to-pointer decay in LLVM IR. See also
<a href="http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html</a> .</div>
<div><br>
</div>
</div></div><div>It seems like we might we able to use TBAA metadata with struct field information to get this then.</div>
<div><br></div></div></div></blockquote><div><br></div><div id="DWT41910">Kinda, but the validity of this info does not (and should not) depend on TBAA being enabled or not.</div></div></div></div></blockquote>Makes sense. For whatever metadata we use to indicate this, ideally its emission should not be tied to whether -fno-strict-aliasing is passed (even if it does use the TBAA metadata infrastructure).<br><br> -Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div><div>
</div>
<div>-Hal</div>
<div><br>
</div>
<div>></div>
<div>> -Eli</div>
</div>
</div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>