<div dir="ltr"><div>Thank you David,<br><br></div>I think based on the statements in the standard, this is undefined behaviour. UBSan certainly seems to think so.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 28, 2016 at 11:27 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 28 Dec 2016, at 09:31, Nemanja Ivanovic via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> The natural alignment of vectors on PPC is 16-bytes. The natural alignment of<br>
> int is 4. When clang is emitting the IR for this, it'll use the alignment of<br>
> the result of the cast on the load. So in this case, the alignment is unduly<br>
> strengthened which can produce incorrect code.<br>
<br>
</span>I think the fix needs to be a little bit more subtle.  The C standard states that it’s undefined behaviour for the result of a cast to be under aligned when derererenced, so in the general case if casting from X* to Y* and then dereferencing the result, the pointer must have the alignment of Y.  In effect, when you cast from int to v4i, you are asserting to the compiler that the alignment is correct.  To get the result that you want, you should be using the alignas attribute or similar on the destination cast.<br>
<br>
That said, it looks as if clang always uses natural alignment when it means C standard (ABI-defined) alignment, which is a bug.  There probably ought to be a hook to allow targets to weaken the alignment guarantees provided by a type.<br>
<br>
Your patch, as is, would cause regressions on a lot of targets.  Casting a char* to an int*, for example, would leave it with 1-byte alignment and if the target doesn’t support unaligned accesses for 4-byte values (e.g. some MIPS, many GPUs) then you’d get much slower code.  Even on targets such as x86, for vectors you’d now be emitting the unaligned variants instead of the aligned ones.<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
<br>
</font></span></blockquote></div><br></div>