diff options
author | David Green <david.green@arm.com> | 2020-02-14 11:00:16 +0000 |
---|---|---|
committer | David Green <david.green@arm.com> | 2020-02-19 09:45:35 +0000 |
commit | 51c6e9445cd4d26d0e8243163dfa5a53fbbcbdd4 (patch) | |
tree | 1f7fbe4414f454033241206784844a6d04232ab5 /clang/lib/Frontend/CompilerInvocation.cpp | |
parent | c41a1f63b3c02039bb6a05f7084bdf95099d7aa9 (diff) | |
download | llvm-51c6e9445cd4d26d0e8243163dfa5a53fbbcbdd4.zip llvm-51c6e9445cd4d26d0e8243163dfa5a53fbbcbdd4.tar.gz llvm-51c6e9445cd4d26d0e8243163dfa5a53fbbcbdd4.tar.bz2 |
[ARM] Extra MVE VADDV reduction patterns
We already make use of the VADDV vector reduction instruction for cases
where the input and the output start out at the same type. The MVE
instruction however will sum into an i32, so if we are summing a v16i8
into an i32, we can still use the same instructions. In terms of IR,
this looks like a sext of a legal type (v16i8) into a very illegal type
(v16i32) and a vecreduce.add of that into the result. This means we have
to catch the pattern early in a DAG combine, producing a target VADDVs/u
node, where the signedness is now important.
This is the first part, handling VADDV and VADDVA. There are also
VADDVL/VADDVLA instructions, which are interesting because they sum into
a 64bit value. And VMLAV and VMLALV, which are interesting because they
also do a multiply of two values. It may look a little odd in places as
a result.
On it's own this will probably not do very much, as the vectorizer will
not produce this IR yet.
Differential Revision: https://reviews.llvm.org/D74218
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions