[llvm-bugs] [Bug 36127] New: _mm256_xor_si256 prefers vxorps over vpxor on integer vectors when out-of-context

[via llvm-bugs]

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

            Bug ID: 36127
           Summary: _mm256_xor_si256 prefers vxorps over vpxor on integer
                    vectors when out-of-context
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: gonzalobg88 at gmail.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org

This code (see it live: https://godbolt.org/g/jJHBMi):

#include <immintrin.h>

__attribute__((__always_inline__, __nodebug__, __target__("avx2")))
__m256i foo(__m256i a, __m256i b) {
    auto c = _mm256_add_epi64(a, b);
    return _mm256_xor_si256(a, c);
}

__attribute__((__always_inline__, __nodebug__, __target__("avx2")))
__m256i bar(__m256i a, __m256i b) {
    return _mm256_xor_si256(a, b);
}

generates this assembly: 

foo(long long __vector(4), long long __vector(4)):                          #
@foo(long long __vector(4), long long __vector(4))
        push    rbp
        mov     rbp, rsp
        and     rsp, -32
        sub     rsp, 32
        vmovdqa ymm0, ymmword ptr [rbp + 16]
        vpaddq  ymm1, ymm0, ymmword ptr [rbp + 48]
        vpxor   ymm0, ymm1, ymm0
        mov     rsp, rbp
        pop     rbp
        ret
bar(long long __vector(4), long long __vector(4)):                          #
@bar(long long __vector(4), long long __vector(4))
        push    rbp
        mov     rbp, rsp
        and     rsp, -32
        sub     rsp, 32
        vmovaps ymm0, ymmword ptr [rbp + 48]
        vxorps  ymm0, ymm0, ymmword ptr [rbp + 16]
        mov     rsp, rbp
        pop     rbp
        ret

So it looks to me that LLVM/clang are choosing `vxorps` by default, and only
`vpxor` if the vectors are being already operated on in the integer domain and
switching domains would increase latency (foo).

However, even though `vxorps` has a smaller encoding, we are operating on
integer vectors here in both cases (foo and bar), and given that `vxorps` and
`vpxor` have the same latency, but that `vpxor` has Nx times the throughput of
`vxorps` (where N is in range [3, 5]), LLVM should be emitting `vpxor` here for
bar as well unless we are optimizing for code-size which the example above
doesn't do. 

Of course, when already operating in the floating point domain, LLVM should
continue to emit `vxorps` to avoid increasing latency by switching domains.

-- 
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/20180128/8e8f5c1f/attachment.html>