[LLVMdev] Stack alignment on X86 AVX seems incorrect

[Demikhovsky, Elena]

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>