aboutsummaryrefslogtreecommitdiff
path: root/lldb/packages/Python/lldbsuite/test/lldbtest.py
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2019-06-16 14:04:49 +0000
committerSanjay Patel <spatel@rotateright.com>2019-06-16 14:04:49 +0000
commitd14389c0a5504f428f73185121ff5e0380f12ab4 (patch)
tree6a1ea603f1dc9561520a8cfdcf26d581a6accffd /lldb/packages/Python/lldbsuite/test/lldbtest.py
parentfcffc2faccf1c1a8edc6b2cbb32db80b23b49a3f (diff)
downloadllvm-d14389c0a5504f428f73185121ff5e0380f12ab4.zip
llvm-d14389c0a5504f428f73185121ff5e0380f12ab4.tar.gz
llvm-d14389c0a5504f428f73185121ff5e0380f12ab4.tar.bz2
[x86] split 256-bit vector selects if operands are vector concats
This is similar logic/motivation to the select splitting in D62969. In D63233, the pattern changes so that we no longer have an extract_subvector of vselect, but the operands of the select are still being concatenated. The closest case is represented in either the first or last test diffs here - we have an extra instruction, but we converted 3-4 ymm instructions into 4-5 xmm instructions. I think that's the right trade-off for most AVX1 targets. In the example based on PR37428: https://bugs.llvm.org/show_bug.cgi?id=37428 ...this makes the loop about 30% faster (tested on Haswell by compiling with -mavx). Differential Revision: https://reviews.llvm.org/D63364 llvm-svn: 363508
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/lldbtest.py')
0 files changed, 0 insertions, 0 deletions