[llvm-bugs] [Bug 26491] New: _mm_movehl_ps pesimised to movaps/shufpd instead of movhlps

[via llvm-bugs]

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

            Bug ID: 26491
           Summary: _mm_movehl_ps pesimised to movaps/shufpd instead of
                    movhlps
           Product: clang
           Version: 3.7
          Hardware: PC
                OS: Linux
            Status: NEW
          Keywords: performance
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: peter at cordes.ca
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

clang sometimes uses a different instruction that the "normal" one for the
intrinsic.  Usually it gets an improvement, but not in this case where it ends
up wasting a movaps and using a bigger instruction.

float hsum_ps(__m128 v) {
    __m128 tmp  = _mm_movehdup_ps(v);     // dest of MOVSHDUP is write-only
    __m128 sums = _mm_add_ps(v, tmp);
    tmp         = _mm_movehl_ps(tmp, sums);
    sums        = _mm_add_ss(sums, tmp);
    return  _mm_cvtss_f32(sums);
}

compiles to: clang 3.7.1 -O3 -march=core2

        movshdup        xmm1, xmm0      # xmm1 = xmm0[1,1,3,3]
        addps   xmm1, xmm0
        movaps  xmm0, xmm1
        shufpd  xmm0, xmm0, 1           # xmm0 = xmm0[1,0]
        addss   xmm0, xmm1
        ret

movhlps is very compact: OF 12 /r,  vs. shufpd being a 5 byte insn.  At least
it doesn't use shufps, which is slow on Core2.  A similar sequence after a loop
produced a movaps/unpckhpd instead of the movhlps.


What I was hoping for (and which gcc produces) is the obvious literal
translation from intrinsics to instructions:

        movshdup xmm1, xmm0
        addps   xmm0, xmm1
        movhlps xmm1, xmm0
        addss   xmm0, xmm1
        ret

I used movshdup first because its destination is write-only.  I can avoid a
movaps without needing the compiler to keep some other variable live so I can
movhlps into it.  (And so I could put it in a function that only takes one
parameter.)  I can't use _mm_undefined_ps() without risk of denormals or NaN
slowdowns.

-- 
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/20160205/0e5f121a/attachment.html>