<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 September 2013 22:33, Krzysztof Parzyszek <span dir="ltr"><<a href="mailto:kparzysz@codeaurora.org" target="_blank">kparzysz@codeaurora.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A customer has reported a performance problem, which I have eventually tracked down to the following situation:<br>

<br>
Consider this program:<br>
<br>
int foo(int *p, volatile int *q, int n) {<br>
  int i, s = 0;<br>
  for (i = 0; i < n; ++i)<br>
    s += *p + *q;<br>
  return s;<br>
}<br>
<br>
<br>
LLVM's analysis indicates that *p and *q can alias, even though *p is non-volatile whereas *q is volatile.  I don't have the exact section from the C standard, but if I remember correctly, accessing volatile memory via a non-volatile object results in an undefined behavior.  This would suggest that volatiles and non-volatiles may be considered not to alias automatically, even if TBAA would not be able to prove it.<br>

<br></blockquote><div><br><div>Could the problem also be looked at like this:<br></div>1) If *p and *q are aliased, the results of *p is undefined.<br></div><div>2) If *p and *q and not aliased, the results of *p is defined.<br>
</div><div>Surely, in this sort of situation, optimizations should should be done assuming (2), because if the case is (1) the result it undefined, so doing (2) won't change that.<br><br></div><div>Kind Regards<br><br>
James<br><br></div><div><br></div></div><br></div></div>