aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorDavid Green <david.green@arm.com>2020-02-14 11:00:16 +0000
committerDavid Green <david.green@arm.com>2020-02-19 09:45:35 +0000
commit51c6e9445cd4d26d0e8243163dfa5a53fbbcbdd4 (patch)
tree1f7fbe4414f454033241206784844a6d04232ab5 /clang/lib/Frontend/CompilerInvocation.cpp
parentc41a1f63b3c02039bb6a05f7084bdf95099d7aa9 (diff)
downloadllvm-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