llvm dev - Mar 2012 - [LLVMdev] Stack alignment on X86 AVX seems incorrect

On Thu, Mar 1, 2012 at 4:29 PM, Evandro Menezes <emenezes at
codeaurora.org>wrote:
...
> Aligning the stack to 32 bytes when there are auto AVX vector variables
> present shouldn't necessarily break the x86-64 ABI, as long as smaller
auto
> variables remain properly aligned.  A similar approach was taken for i386
> in GCC in order to support SSE vectors.
>
> Perhaps you could elaborate where the ABI was violated when your patch is
> applied.
>
Sorry, I confused myself. This was worked out about a year ago, so it's not
in my cache.

You're right. In my last email I wrote "align the stack", when I
should
have written "align the frame when variable sized objects are in
play".
Take main(...) for example, with a few alloca's. If one would like to spill
AVX regs with aligned moves, one must align the frame to 32 bytes to ensure
that the spill slots are aligned correctly, since spill slots are based off
of the frame pointer.

The x86-64 ABI lays out the stack frame as...

...
16(%rbp)  mem arg[0]
8(%rbp)    return address
0(%rbp)    previous %rbp
-8(%rbp)   stack

My patch breaks the ABI since the ABI requires the return address to be
found at 8(%rbp) and mem arg[0] at 16(%rbp). Unfortunately, to align the
frame at runtime, it's sometimes required to insert padding in between the
two.

I'll ask for my company's permission to share my implementation. Until
then, I'll have to bite my tongue.

-Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120301/e9a0be25/attachment.html>

On Thu, Mar 01, 2012 at 05:30:40PM -0500, Cameron McInally
wrote:
> The x86-64 ABI lays out the stack frame as...
> 
> ...
> 16(%rbp)  mem arg[0]
> 8(%rbp)    return address
> 0(%rbp)    previous %rbp
> -8(%rbp)   stack
> 
> My patch breaks the ABI since the ABI requires the return address to be
> found at 8(%rbp) and mem arg[0] at 16(%rbp). Unfortunately, to align the
> frame at runtime, it's sometimes required to insert padding in between
the
> two.
Eh, no. The X86-64 ABI doesn't require the use of a frame pointer, so it
obviously can't require anything relative to %rbp.

Please note that stack realignment is implement unless code requires
dynamic allocas. The conditionals seems to be wrong though as mentioned
in this thread.

Joerg

On Thu, Mar 1, 2012 at 5:30 PM, Cameron McInally
<cameron.mcinally at nyu.edu>wrote:
> Aligning the stack to 32 bytes when there are auto AVX vector variables
>> present shouldn't necessarily break the x86-64 ABI, as long as
smaller auto
>> variables remain properly aligned.  A similar approach was taken for
i386
>> in GCC in order to support SSE vectors.
>>
>>
This topic is starting to come back to me now. The reason the GCC solution
above did not work for us is that we do not build all of the libraries used
with our compiler. For example, some are proprietary compiled object files
and some are GCC compiled object files from other sources. If our object
files called another library, and in turn that library called a function in
our object code, it's not possible to ensure that the frame of the current
function is still aligned to 32 bytes. That was the determining factor in
my implementation.

That is, unless you know something that I don't. I'm pretty new to
compiler
development. :)

-Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120301/02183e07/attachment.html>

On Mar 1, 2012, at 3:04 PM, Cameron McInally <cameron.mcinally at nyu.edu>
wrote:
> On Thu, Mar 1, 2012 at 5:30 PM, Cameron McInally <cameron.mcinally at
nyu.edu> wrote:
> Aligning the stack to 32 bytes when there are auto AVX vector variables
present shouldn't necessarily break the x86-64 ABI, as long as smaller auto
variables remain properly aligned.  A similar approach was taken for i386 in GCC
in order to support SSE vectors.
> 
> 
> This topic is starting to come back to me now. The reason the GCC solution
above did not work for us is that we do not build all of the libraries used with
our compiler. For example, some are proprietary compiled object files and some
are GCC compiled object files from other sources. If our object files called
another library, and in turn that library called a function in our object code,
it's not possible to ensure that the frame of the current function is still
aligned to 32 bytes. That was the determining factor in my implementation.
You can only ever guarantee that code is aligned to the ABI alignment.

-eric

Even if you explicitly specify –stack-alignment=16 the aligned movs are still
generated.
It is not an issue related to ABI.
See my original mail:



./llc -mattr=+avx -stack-alignment=16 < basic.ll | grep movaps | grep ymm |
grep rbp

        vmovaps -176(%rbp), %ymm14

        vmovaps -144(%rbp), %ymm11

        vmovaps -240(%rbp), %ymm13

- Elena
From: Cameron McInally [mailto:cameron.mcinally at nyu.edu]
Sent: Friday, March 02, 2012 01:04
To: Evandro Menezes
Cc: Demikhovsky, Elena; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Stack alignment on X86 AVX seems incorrect

On Thu, Mar 1, 2012 at 5:30 PM, Cameron McInally <cameron.mcinally at
nyu.edu<mailto:cameron.mcinally at nyu.edu>> wrote:
Aligning the stack to 32 bytes when there are auto AVX vector variables present
shouldn't necessarily break the x86-64 ABI, as long as smaller auto
variables remain properly aligned.  A similar approach was taken for i386 in GCC
in order to support SSE vectors.

This topic is starting to come back to me now. The reason the GCC solution above
did not work for us is that we do not build all of the libraries used with our
compiler. For example, some are proprietary compiled object files and some are
GCC compiled object files from other sources. If our object files called another
library, and in turn that library called a function in our object code, it's
not possible to ensure that the frame of the current function is still aligned
to 32 bytes. That was the determining factor in my implementation.

That is, unless you know something that I don't. I'm pretty new to
compiler development. :)

-Cameron
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120301/250477a4/attachment.html>