aboutsummaryrefslogtreecommitdiff
path: root/clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
diff options
context:
space:
mode:
authorDavid Green <david.green@arm.com>2020-06-29 13:53:19 +0100
committerDavid Green <david.green@arm.com>2020-06-29 16:04:13 +0100
commitdeb72ce29860f61fe91ddcf97e89abfc9544cf42 (patch)
treedf8c729d1dac41aba58d3e7fd0fc8721163759e5 /clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
parent5447e5d973bfccb5a32d3ca9cb0105340f178b85 (diff)
downloadllvm-deb72ce29860f61fe91ddcf97e89abfc9544cf42.zip
llvm-deb72ce29860f61fe91ddcf97e89abfc9544cf42.tar.gz
llvm-deb72ce29860f61fe91ddcf97e89abfc9544cf42.tar.bz2
[ARM] Better reductions
MVE has native reductions for integer add and min/max. The others need to be expanded to a series of extract's and scalar operators to reduce the vector into a single scalar. The default codegen for that expands the reduction into a series of in-order operations. This modifies that to something more suitable for MVE. The basic idea is to use vector operations until there are 4 remaining items then switch to pairwise operations. For example a v8f16 fadd reduction would become: Y = VREV X Z = ADD(X, Y) z0 = Z[0] + Z[1] z1 = Z[2] + Z[3] return z0 + z1 The awkwardness (there is always some) comes in from something like a v4f16, which is first legalized by adding identity values to the extra lanes of the reduction, and which can then not be optimized away through the vrev; fadd combo, the inserts remain. I've made sure they custom lower so that we can produce the pairwise additions before the extra values are added. Differential Revision: https://reviews.llvm.org/D81397
Diffstat (limited to 'clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp')
0 files changed, 0 insertions, 0 deletions