<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 25, 2014 at 7:34 PM, Arthur O'Dwyer <span dir="ltr"><<a href="mailto:arthur.j.odwyer@gmail.com" target="_blank">arthur.j.odwyer@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wed, Jun 25, 2014 at 3:26 PM, Sanjin Sijaric <<a href="mailto:ssijaric@codeaurora.org" target="_blank">ssijaric@codeaurora.org</a>> wrote:<br>


><br>
>>     int *p;<br>
>>     typedef struct {<br>
>>       char a;<br>
>>       char b[100];<br>
>>       char c;<br>
>>     } S;<br>
>><br>
>>     S x;<br>
>><br>
>>     void func1 (char d) {<br>
>>       for (int i = 0; i < 100; i++) {<br>
>>         x.b[i] += 1;<br>
>>         d = *p;<br>
>>         x.a += d;<br>
>>       }<br>
>>     }<br>
>><br>
>> It seems like you want the compiler to hoist the read of `*p` above the write to `x.b[i]`.<br>
>> But that isn't generally possible, is it? because the caller might have executed<br>
>><br>
>>    p = &x.b[3];<br>
>><br>
>> before the call to func1.<br>
><br>
</div><div>> Here, "p" is a pointer to int, whereas b is a char array.  Wouldn't "p = &x.b[3];" break ansi aliasing rules?<br>
<br>
</div>I was under the impression that that was the entire point of "omnipotent char"!<br></blockquote><div><br></div><div>I think that's backwards from the intent: if you swap over 'int' and 'char' in the example, we cannot do the reordering, because p could point to (some byte of) one of the ints.</div>

<div><br></div><div>With the test as-is, we *can* reorder the *p load (and even move it out of the loop):</div><div>  -- *p cannot alias x.b[i], because if 'x.b[i] += 1' has defined behavior, then x is an object of type S and x.b is an object of type char[100] and 0 <= i < 100, and therefore there is no int object aliased by that store</div>

<div>  -- *p cannot alias x.a, because if 'x.a += d' has defined behavior, then x is an object of type S, so a store to S::a cannot alias any int object.</div><div><br></div><div>I think this kind of analysis should probably be covered by -fstruct-path-tbaa, not enabled by default, though. (I'm a little surprised that -fstruct-path-tbaa doesn't get this right today...)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

See lines 106-108 in the very file you're changing:<br>
<br>
00106     // Character types are special and can alias anything.<br>
00107     // In C++, this technically only includes "char" and "unsigned char",<br>
00108     // and not "signed char". In C, it includes all three. For now,<br>
00109     // the risk of exploiting this detail in C++ seems likely to outweigh<br>
00110     // the benefit.<br>
<br>
Source: <a href="http://clang.llvm.org/doxygen/CodeGenTBAA_8cpp_source.html" target="_blank">http://clang.llvm.org/doxygen/CodeGenTBAA_8cpp_source.html</a><br>
<span><font color="#888888"><br>
–Arthur<br>
</font></span><div><div><br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div></div>