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

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>

On Thu, Mar 1, 2012 at 6:28 PM, Demikhovsky, Elena <
elena.demikhovsky at intel.com> wrote:
> Even if you explicitly specify –stack-alignment=16 the aligned movs are
> still generated.****
>
> It is not an issue related to ABI.
>
>
>
Right, your issue is triggered by the code I sent out earlier:
> The faulty code can be found in
function X86InstrInfo::storeRegToStackSlot(...) from
> /lib/Target/X86/X86InstrInfo.cpp.
>
>> bool isAligned = (RI.getStackAlignment() >= 16) ||
RI.canRealignStack(MF);
>
In some cases, the stack is assumed to be aligned if it's on a 16 byte or
greater boundary. Your desired alignment is 32 bytes, so aligned 256b moves
are selected which is not correct. At runtime, your stack slots could still
be aligned on a 16 byte boundary. You'll have to either:

1) Always use unaligned moves;
2) Update the code above to handle 32 byte alignment (Is this even possible
at compile time? I wouldn't think so.);
3) Align the frame and stack to 32 bytes, so that AVX spill slots are
always on 32 byte boundaries (This is what I'm proposing.);

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

Hi Elena,

On Thu, Mar 1, 2012 at 8:28 PM, Demikhovsky, Elena
<elena.demikhovsky at intel.com> wrote:
> Even if you explicitly specify –stack-alignment=16 the aligned movs are
> still generated.
>
> It is not an issue related to ABI.
This looks like PR10841, explanation and the way to solve it:
http://llvm.org/bugs/show_bug.cgi?id=10841

Cheers,

-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc

On Fri, Mar 02, 2012 at 12:18:19AM -0300, Bruno Cardoso Lopes
wrote:
> Hi Elena,
> 
> On Thu, Mar 1, 2012 at 8:28 PM, Demikhovsky, Elena
> <elena.demikhovsky at intel.com> wrote:
> > Even if you explicitly specify –stack-alignment=16 the aligned movs
are
> > still generated.
> >
> > It is not an issue related to ABI.
> 
> This looks like PR10841, explanation and the way to solve it:
> http://llvm.org/bugs/show_bug.cgi?id=10841
I was looking at this again today. What about the following approach:

(1) Change AllocaInst to compute the isStaticAlloca once and remember
    it.

(2) Check all functions for
  (a) static allocations with an alignment larger than the default stack
      alignemnt
  (b) dynamic alloca

(3) If (a) is present and not (b), use the frame pointer to address
    arguments and the stack pointer to address local variables.

    If (b) is present and not (a), use the frame pointer to address
    arguments and local variables. Realign the stack pointer to the
    largest alignment needed for dynamic alloca.

    If (a) and (b) are present, adjust the isStatic attribute of all
    allocas with alignment larger than the default stack alignment.
    Deal with the rest like the case before.

At least for 32bit x86 reserving another register as alternative frame
pointer is very heavy. The above would allow normal spill logic to
decide when to keep a reference in register and when not. It also reuses
existing functionality as much as possible.

Joerg