[all-commits] [llvm/llvm-project] bd4b61: [CostModel] Remove VF from IntrinsicCostAttributes

[David Green via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bd4b61efbdb487124c8bcc3027d628c8c3547c4f
      https://github.com/llvm/llvm-project/commit/bd4b61efbdb487124c8bcc3027d628c8c3547c4f
  Author: David Green <david.green at arm.com>
  Date:   2021-02-23 (Tue, 23 Feb 2021)

  Changed paths:
    M llvm/include/llvm/Analysis/TargetTransformInfo.h
    M llvm/include/llvm/CodeGen/BasicTTIImpl.h
    M llvm/lib/Analysis/TargetTransformInfo.cpp
    M llvm/lib/Target/AMDGPU/AMDGPUTargetTransformInfo.cpp
    M llvm/lib/Target/ARM/ARMTargetTransformInfo.cpp
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
    M llvm/test/Transforms/LoopVectorize/AArch64/intrinsiccost.ll
    M llvm/test/Transforms/LoopVectorize/X86/intrinsiccost.ll
    M llvm/test/Transforms/SLPVectorizer/WebAssembly/no-vectorize-rotate.ll

  Log Message:
  -----------
  [CostModel] Remove VF from IntrinsicCostAttributes

getIntrinsicInstrCost takes a IntrinsicCostAttributes holding various
parameters of the intrinsic being costed. It can either be called with a
scalar intrinsic (RetTy==Scalar, VF==1), with a vector instruction
(RetTy==Vector, VF==1) or from the vectorizer with a scalar type and
vector width (RetTy==Scalar, VF>1). A RetTy==Vector, VF>1 is considered
an error. Both of the vector modes are expected to be treated the same,
but because this is confusing many backends end up getting it wrong.

Instead of trying work with those two values separately this removes the
VF parameter, widening the RetTy/ArgTys by VF used called from the
vectorizer. This keeps things simpler, but does require some other
modifications to keep things consistent.

Most backends look like this will be an improvement (or were not using
getIntrinsicInstrCost). AMDGPU needed the most changes to keep the code
from c230965ccf36af5c88c working. ARM removed the fix in
dfac521da1b90db683, webassembly happens to get a fixup for an SLP cost
issue and both X86 and AArch64 seem to now be using better costs from
the vectorizer.

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


  Commit: dd2dbf7ee2e5cdf4b794b09f8bb92e2a75e9b802
      https://github.com/llvm/llvm-project/commit/dd2dbf7ee2e5cdf4b794b09f8bb92e2a75e9b802
  Author: David Green <david.green at arm.com>
  Date:   2021-02-23 (Tue, 23 Feb 2021)

  Changed paths:
    M llvm/include/llvm/Analysis/TargetTransformInfo.h
    M llvm/include/llvm/Analysis/TargetTransformInfoImpl.h
    M llvm/include/llvm/CodeGen/BasicTTIImpl.h
    M llvm/lib/Analysis/TargetTransformInfo.cpp
    M llvm/lib/Target/AMDGPU/AMDGPUTargetTransformInfo.cpp
    M llvm/lib/Target/ARM/ARMTargetTransformInfo.cpp
    M llvm/lib/Target/Hexagon/HexagonTargetTransformInfo.cpp
    M llvm/lib/Target/Hexagon/HexagonTargetTransformInfo.h
    M llvm/lib/Target/SystemZ/SystemZTargetTransformInfo.cpp
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    A llvm/test/Analysis/CostModel/PowerPC/matrix.ll
    M llvm/test/Transforms/LoopVectorize/AArch64/scalable-call.ll

  Log Message:
  -----------
  [TTI] Change getOperandsScalarizationOverhead to take Type args

As a followup to D95291, getOperandsScalarizationOverhead was still
using a VF as a vector factor if the arguments were scalar, and would
assert on certain matrix intrinsics with differently sized vector
arguments. This patch removes the VF arg, instead passing the Types
through directly. This should allow it to more accurately compute the
cost without having to guess at which operands will be vectorized,
something difficult with more complex intrinsics.

This adjusts one SVE test as it is now calling the wrong intrinsic vs
veccall. Without invalid InstructCosts the cost of the scalarized
intrinsic is too low. This should get fixed when the cost of
scalarization is accounted for with scalable types.

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


Compare: https://github.com/llvm/llvm-project/compare/5bf710b2a500...dd2dbf7ee2e5