[all-commits] [llvm/llvm-project] 42ef57: [SLP] Fix cost model w.r.t. operand properties

[Philip Reames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 42ef5720493e0c9ebc936b918dc13dcb0130e3d6
      https://github.com/llvm/llvm-project/commit/42ef5720493e0c9ebc936b918dc13dcb0130e3d6
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2022-09-23 (Fri, 23 Sep 2022)

  Changed paths:
    M llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp

  Log Message:
  -----------
  [SLP] Fix cost model w.r.t. operand properties

We allow the target to report different costs depending on properties of the operands; given this, we have to make sure we pass the right set of operands and account for the fact that different scalar instructions can have operands with different properties.

As a motivating example, consider a set of multiplies which each multiply by a constant (but not all the same constant). Most of the constants are power of two (but not all).

If the target doesn't have support for non-uniform constant immediates, this will likely require constant materialization and a non-uniform multiply. However, depending on the balance of target costs for constant scalar multiplies vs a single vector multiply, this might or might not be a profitable vectorization.

This ends up basically being a rewrite of the existing code. Normally, I'd scope the change more narrowly, but I kept noticing things which seemed highly suspicious, and none of the existing code appears to have any test coverage at all. I think this is a case where simply throwing out the existing code and starting from scratch is reasonable.

This is a follow on to Alexey's D126885, but also handles the arithmetic instruction case since the existing code appears to have the same problem.

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