<div class="gmail_quote">On Thu, Jun 7, 2012 at 4:10 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Jun 07, 2012 at 03:31:06PM -0700, David Sehr wrote:<br>
> Just out of curiosity, how do those x86 platforms handle<br>
> stack-allocated SSE2 variables?  Do they just always use the unaligned<br>
> variants of the instructions?<br>
> This was the reason that the Linux x86 (32 and 64) ABIs now align<br>
> stacks 0mod16, I thought.<br>
<br>
</div>The reason is more that until very recently, GCC just created broken<br>
code that. The only way to do it correctly is by realigning the stack.<br></blockquote><div><br></div><div>Which both GCC and LLVM now do...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

At least we are getting to the point where LLVM handles all cases<br>
correctly. Requiring larger than natural stack alignment for allocar<br>
at the very least adds an additional AND to all functions using dynamic<br>
allocas. That said, unlike malloc and the posix_memalign interface,<br>
expecting anything but natural alignment<br>
for memory returned by alloca seems to be a very strong assumption...<br></blockquote><div><br></div><div>Regardless of how it seems, there is evidence that GCC at least does this, and it seems quite likely that a great deal of code expects equivalent alignment guarantees for 'alloca' and 'malloc'. I think it is a mistake to not provide such alignment. However, it does seem like this should be no more than an 'and' instruction in the worst case (we don't have known alignment of the stack).</div>
</div>