<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 17, 2013, at 9:27 PM, Dimitri Tcaciuc <<a href="mailto:dtcaciuc@gmail.com">dtcaciuc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hey everyone,<br><div style=""><br></div><div style="">I'm looking at the following two C functions:</div><div style=""><br></div><div style=""> <a href="http://pastebin.com/mYWCj6d8">http://pastebin.com/mYWCj6d8</a></div>
<div style=""><br></div><div style="">Second one is about 50% slower than the first one because in the second case d->data[i * 3 + {X, Y, Z}] loads are not moved out of the second loop and are computed every time j increments, even though they don't depend on it. If I move those out manually, the performance of the two is equal.</div>
<div style=""><br></div><div style="">What could be the reason for this behaviour? I looked at LICM logs; the compiler hoists GEPs but stops short of loading the actual values. Does it have something to do with possible aliasing?</div>
</div></blockquote><br></div><div>Yes.</div><div><br></div><div>Almost certainly, the compiler can't tell that the load from the struct (to get the array pointer) doesn't alias with the stores to the array itself. This is exactly the kind of thing that type-based alias analysis (-fstrict-aliasing) can help with. Use with caution, as it can break some type-unsafe idioms.</div><div><br></div><div>--Owen</div><br></body></html>