[llvm-bugs] [Bug 37162] New: __attribute__((force_align_arg_pointer)) produces incorrect stack alignment

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=37162

            Bug ID: 37162
           Summary: __attribute__((force_align_arg_pointer)) produces
                    incorrect stack alignment
           Product: new-bugs
           Version: 6.0
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: henrik at gramner.com
                CC: llvm-bugs at lists.llvm.org

__attribute__((force_align_arg_pointer)) uses a hardcoded alignment value of 16
which breaks when using a stack alignment that's larger than 16.

It should behave the same way as -mstackrealign (which works correctly) except
on a per-function basis.

The use case is a library that makes heavy use of AVX/AVX2 and uses 32-byte
stack alignment to be able to do aligned load/stores of ymm registers from/to
stack buffers without having to realign the stack in every function, in
combination with the force_align_arg_pointer attribute on API entry points.

GCC handles the alignment correctly.


Minimal test case:

void bar(void);
__attribute__((force_align_arg_pointer)) void foo(void)
{
    bar();
}

-mstack-alignment=32:

<foo>:
    push   rbp
    mov    rbp,rsp
    and    rsp,0xfffffffffffffff0
    sub    rsp,0x10
    call   11 <foo+0x11>    d: R_X86_64_PC32        bar-0x4
    mov    rsp,rbp
    pop    rbp
    ret

-mstack-alignment=32 -mstackrealign (with or without force_align_arg_pointer):

<foo>:
    push   rbp
    mov    rbp,rsp
    and    rsp,0xffffffffffffffe0
    sub    rsp,0x20
    call   11 <foo+0x11>    d: R_X86_64_PC32        bar-0x4
    mov    rsp,rbp
    pop    rbp
    ret


(Also the "sub rsp, <alignment>" instructions seems pointless to me. And yes,
they're still there with -O3).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180418/92320140/attachment.html>