[all-commits] [llvm/llvm-project] 51c6e9: [ARM] Extra MVE VADDV reduction patterns

David Green via All-commits all-commits at lists.llvm.org
Wed Feb 19 01:45:49 PST 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 51c6e9445cd4d26d0e8243163dfa5a53fbbcbdd4
      https://github.com/llvm/llvm-project/commit/51c6e9445cd4d26d0e8243163dfa5a53fbbcbdd4
  Author: David Green <david.green at arm.com>
  Date:   2020-02-19 (Wed, 19 Feb 2020)

  Changed paths:
    M llvm/lib/Target/ARM/ARMISelLowering.cpp
    M llvm/lib/Target/ARM/ARMISelLowering.h
    M llvm/lib/Target/ARM/ARMInstrMVE.td
    M llvm/test/CodeGen/Thumb2/mve-vecreduce-add.ll

  Log Message:
  -----------
  [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




More information about the All-commits mailing list