[all-commits] [llvm/llvm-project] 41cedb: [LV][ARM] Tighten up MLA reduction costing

[David Green via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 41cedb1c9a380628ac162bf76148cbd143f41450
      https://github.com/llvm/llvm-project/commit/41cedb1c9a380628ac162bf76148cbd143f41450
  Author: David Green <david.green at arm.com>
  Date:   2021-07-28 (Wed, 28 Jul 2021)

  Changed paths:
    M llvm/lib/Target/ARM/ARMTargetTransformInfo.cpp
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/test/Transforms/LoopVectorize/ARM/mve-reductions.ll

  Log Message:
  -----------
  [LV][ARM] Tighten up MLA reduction costing

This makes a couple of changes to the costing of MLA reduction patterns,
to more accurately cost various patterns that can come up from
vectorization.

 - The Arm implementation of getExtendedAddReductionCost is altered to
   only provide costs for legal or smaller types. Larger than legal types
   need to be split, which currently does not work very well, especially
   for predicated reductions where the predicate may be legal but needs to
   be split. Currently we limit it to legal or smaller input types.
 - The getReductionPatternCost has learnt that reduce(ext(mul(ext, ext))
   is a pattern that can come up, and can be treated the same as
   reduce(mul(ext, ext)) providing the extension types match.
 - And it has been adjusted to not count the ext in reduce(mul(ext, ext))
   as part of a reduce(mul) pattern.

Together these changes help to more accurately cost the mla reductions
in cases such as where the extend types don't match or the extend
opcodes are different, picking better vector factors that don't result
in expanded reductions.

Differential Revision: https://reviews.llvm.org/D106166