[llvm-bugs] [Bug 40844] New: Unneeded stack alignment on x86

via llvm-bugs llvm-bugs at lists.llvm.org
Sun Feb 24 09:05:18 PST 2019


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

            Bug ID: 40844
           Summary: Unneeded stack alignment on x86
           Product: libraries
           Version: 7.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: yyc1992 at gmail.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, spatel+llvm at rotateright.com

Ref https://bugs.llvm.org/show_bug.cgi?id=40843. The useless stack operations
are likely caused by a different issue...

Reproducible with C code,

```
typedef double _vdouble __attribute__((vector_size(32)));

typedef struct {
    _vdouble x;
    int y;
} vdouble;

vdouble f(vdouble x, vdouble y)
{
    vdouble res = {x.x + y.x, x.y + y.y};
    return res;
}
```

Compiling with clang with `-mavx` emits very similar code to GCC

```
f:                                      # @f
# %bb.0:
        pushq   %rbp
        movq    %rsp, %rbp
        andq    $-32, %rsp
        subq    $32, %rsp
        vmovapd 16(%rbp), %ymm0
        vaddpd  80(%rbp), %ymm0, %ymm0
        vmovapd %ymm0, (%rdi)
        movl    112(%rbp), %eax
        addl    48(%rbp), %eax
        movl    %eax, 32(%rdi)
        movq    %rdi, %rax
        movq    %rbp, %rsp
        popq    %rbp
        vzeroupper
        retq
```

except that it emits 6 additional instructions for stack realignment without
actually using the stack pointer anywhere else in the function.

Seems to be a x86 backend issue since I can reproduce even without enabling avx
(so nothing in the backend should require 32bit alignment, only the frontend
should) and I can't reproduce on arm or aarch64.

-- 
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/20190224/1a588371/attachment.html>


More information about the llvm-bugs mailing list