diff options
author | Sanjay Patel <spatel@rotateright.com> | 2018-10-30 15:26:39 +0000 |
---|---|---|
committer | Sanjay Patel <spatel@rotateright.com> | 2018-10-30 15:26:39 +0000 |
commit | b12e410082d4974d930a1e9eb2e2e1c7714c66c7 (patch) | |
tree | f4eb1689a1631bf3ff336866e56782190c8c1142 /clang-tools-extra/test/clang-tidy/cppcoreguidelines-macro-usage-custom.cpp | |
parent | 611b533f1d544b85f1a98afbc9241deeb97d9497 (diff) | |
download | bcm5719-llvm-b12e410082d4974d930a1e9eb2e2e1c7714c66c7.tar.gz bcm5719-llvm-b12e410082d4974d930a1e9eb2e2e1c7714c66c7.zip |
[InstCombine] try to turn shuffle into insertelement
shuffle (insert ?, Scalar, IndexC), V1, Mask --> insert V1, Scalar, IndexC'
The motivating case is at least a couple of steps away: I noticed that
SLPVectorizer does not analyze shuffles as well as sequences of
insert/extract in PR34724:
https://bugs.llvm.org/show_bug.cgi?id=34724
...so SLP may fail to vectorize when source code has shuffles to start
with or instcombine has converted insert/extract to shuffles.
Independent of that, an insertelement is always a simpler op for IR
analysis vs. a shuffle, so we should transform to insert when possible.
I don't think there's any codegen concern here - if a target can't insert
a scalar directly to some fixed element in a vector (x86?), then this
should get expanded to the insert+shuffle that we started with.
Differential Revision: https://reviews.llvm.org/D53507
llvm-svn: 345607
Diffstat (limited to 'clang-tools-extra/test/clang-tidy/cppcoreguidelines-macro-usage-custom.cpp')
0 files changed, 0 insertions, 0 deletions