[llvm-bugs] [Bug 28343] New: Code pessimization when using typedef-aligned pointers

[via llvm-bugs]

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

            Bug ID: 28343
           Summary: Code pessimization when using typedef-aligned pointers
           Product: clang
           Version: 3.8
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: matt at godbolt.org
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

In clang 3.8, compiling the following two equivalent code snippets reveals an
apparent pessimization in the first case:

--

typedef double __attribute__((aligned(64))) aligned_double;
void maxArray1(aligned_double* __restrict x, aligned_double* __restrict y) {
    for (int i = 0; i < 65536; i++) x[i] = ((y[i] > x[i]) ? y[i] : x[i]);
}

void maxArray2(double* __restrict x, double* __restrict y) {
    x = static_cast<double*>(__builtin_assume_aligned(x, 64));
    y = static_cast<double*>(__builtin_assume_aligned(y, 64));
    for (int i = 0; i < 65536; i++) x[i] = ((y[i] > x[i]) ? y[i] : x[i]);
}

--

(see also https://godbolt.org/g/JmBXhP)

It's my understanding the two code paths should be identical: indeed clang
3.7.1 and all version of GCC I checked treat the code identically in both
cases.

In clang 3.8, the maxArray1 case uses intermediate registers xmm2 and xmm3,
versus reading the values straight into registers:

        movupd  xmm0, xmmword ptr [rsi + 8*rax]
        movupd  xmm1, xmmword ptr [rsi + 8*rax + 16]
        movupd  xmm2, xmmword ptr [rdi + 8*rax]
        movupd  xmm3, xmmword ptr [rdi + 8*rax + 16]
        maxpd   xmm0, xmm2
        maxpd   xmm1, xmm3

vs

        movapd  xmm0, xmmword ptr [rsi + 8*rax]
        movapd  xmm1, xmmword ptr [rsi + 8*rax + 16]
        maxpd   xmm0, xmmword ptr [rdi + 8*rax]
        maxpd   xmm1, xmmword ptr [rdi + 8*rax + 16]

-- 
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/20160628/3aecd871/attachment.html>