[llvm-bugs] [Bug 36127] New: _mm256_xor_si256 prefers vxorps over vpxor on integer vectors when out-of-context
via llvm-bugs
llvm-bugs at lists.llvm.org
Sun Jan 28 11:00:48 PST 2018
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>
More information about the llvm-bugs
mailing list