<div dir="ltr">Ownen, thanks for the reply. The above, however, was already compiled with -fstrict-aliasing and -O3; doesn't look like it makes much of a difference in this case.<div><br></div><div style>As with my earlier question, I'm actually using C as a model to create a custom frontend, which I intend to bless with more strict aliasing rules by default. The Array is going to be a language intrinsic so I'm free to make a suitable tbaa tree. The problem is I haven't found a good example of how would such length-aware pointer container structure be annotated so that loads from the data pointer are optimized as though we didn't access it through a struct.</div>
<div style><br></div><div style>The struct IR looks something like</div><div style><br></div><div style>   %struct.Array = type { double*, i64 }</div><div style><br></div><div style>Then we get the GEP to data, followed by a load </div>
<div style><br></div><div style>   %data = getelementptr inbounds %struct.Array* %d, i64 0, i32 0</div><div style>   %0 = load double** %data, align 8, !tbaa !0</div><div style><br></div><div style>where relevant TBAA looks like</div>
<div style><br></div><div style>    !0 = metadata !{metadata !"any pointer", metadata !1}</div><div style>    !1 = metadata !{metadata !"omnipotent char", metadata !2}</div><div style>    !2 = metadata !{metadata !"Simple C/C++ TBAA"}</div>
<div style>    !3 = metadata !{metadata !"double", metadata !1}</div><div style><br></div><div style>So if I understand correctly, because double and any pointer are leafs of omnipotent char, they can easily alias. Thus, having something like</div>
<div style><br></div><div style><div>    !4 = metadata !{metadata !"Array data", metadata !2}</div><div><br></div><div><div>   %0 = load double** %data, align 8, !tbaa !4</div></div><div><br></div><div style>should do the trick?</div>
<div style><br></div></div><div style><br></div><div style>Dimitri.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 17, 2013 at 9:33 PM, Owen Anderson <span dir="ltr"><<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.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><div class="h5"><br><div><div>On Jan 17, 2013, at 9:27 PM, Dimitri Tcaciuc <<a href="mailto:dtcaciuc@gmail.com" target="_blank">dtcaciuc@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Hey everyone,<br><div><br></div><div>I'm looking at the following two C functions:</div><div><br></div><div>    <a href="http://pastebin.com/mYWCj6d8" target="_blank">http://pastebin.com/mYWCj6d8</a></div>

<div><br></div><div>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><br></div><div>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></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>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>--Owen</div><br></font></span></div>
</blockquote></div><br></div>