aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2019-06-07 13:17:46 +0000
committerSanjay Patel <spatel@rotateright.com>2019-06-07 13:17:46 +0000
commit6880bceda2df17f68e319c86a78642125086e0b8 (patch)
tree936eca4e86abcdbd7788df22c7cbd579b61b21c0 /llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp
parent0723c659f5838a5f67cd6ef5133f7d0e9464b122 (diff)
downloadllvm-6880bceda2df17f68e319c86a78642125086e0b8.zip
llvm-6880bceda2df17f68e319c86a78642125086e0b8.tar.gz
llvm-6880bceda2df17f68e319c86a78642125086e0b8.tar.bz2
[x86] narrow extract subvector of vector select
This is a potentially large perf win for AVX1 targets because of the way we auto-vectorize to 256-bit but then expect the backend to legalize/optimize for the half-implemented AVX1 ISA. On the motivating example from PR37428 (even though this patch doesn't solve the vector shift issue): https://bugs.llvm.org/show_bug.cgi?id=37428 ...there's a 16% speedup when compiling with "-mavx" (perf tested on Haswell) because we eliminate the remaining 256-bit vblendv ops. I added comments on a couple of tests that require further work. If we have 256-bit logic ops separating the vselect and extract, we should probably narrow everything to 128-bit, but that requires a larger pattern match. Differential Revision: https://reviews.llvm.org/D62969 llvm-svn: 362797
Diffstat (limited to 'llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp')
0 files changed, 0 insertions, 0 deletions