summaryrefslogtreecommitdiffstats
path: root/clang-tools-extra/test/clang-tidy/cppcoreguidelines-macro-usage-custom.cpp
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2018-10-30 15:26:39 +0000
committerSanjay Patel <spatel@rotateright.com>2018-10-30 15:26:39 +0000
commitb12e410082d4974d930a1e9eb2e2e1c7714c66c7 (patch)
treef4eb1689a1631bf3ff336866e56782190c8c1142 /clang-tools-extra/test/clang-tidy/cppcoreguidelines-macro-usage-custom.cpp
parent611b533f1d544b85f1a98afbc9241deeb97d9497 (diff)
downloadbcm5719-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
OpenPOWER on IntegriCloud