[all-commits] [llvm/llvm-project] 9b7616: [Support] Introduce a new InstructionCost class

[david-arm via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9b76160e53f67008ff21095098129a2949595a06
      https://github.com/llvm/llvm-project/commit/9b76160e53f67008ff21095098129a2949595a06
  Author: David Sherwood <david.sherwood at arm.com>
  Date:   2020-12-11 (Fri, 11 Dec 2020)

  Changed paths:
    M llvm/include/llvm/Analysis/TargetTransformInfo.h
    M llvm/include/llvm/IR/DiagnosticInfo.h
    A llvm/include/llvm/Support/InstructionCost.h
    M llvm/lib/Analysis/CostModel.cpp
    M llvm/lib/CodeGen/InterleavedLoadCombinePass.cpp
    M llvm/lib/IR/DiagnosticInfo.cpp
    M llvm/lib/Support/CMakeLists.txt
    A llvm/lib/Support/InstructionCost.cpp
    M llvm/lib/Transforms/IPO/HotColdSplitting.cpp
    M llvm/lib/Transforms/Scalar/CallSiteSplitting.cpp
    M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
    M llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
    M llvm/unittests/Support/CMakeLists.txt
    A llvm/unittests/Support/InstructionCostTest.cpp

  Log Message:
  -----------
  [Support] Introduce a new InstructionCost class

This is the first in a series of patches that attempts to migrate
existing cost instructions to return a new InstructionCost class
in place of a simple integer. This new class is intended to be
as light-weight and simple as possible, with a full range of
arithmetic and comparison operators that largely mirror the same
sets of operations on basic types, such as integers. The main
advantage to using an InstructionCost is that it can encode a
particular cost state in addition to a value. The initial
implementation only has two states - Normal and Invalid - but these
could be expanded over time if necessary. An invalid state can
be used to represent an unknown cost or an instruction that is
prohibitively expensive.

This patch adds the new class and changes the getInstructionCost
interface to return the new class. Other cost functions, such as
getUserCost, etc., will be migrated in future patches as I believe
this to be less disruptive. One benefit of this new class is that
it provides a way to unify many of the magic costs in the codebase
where the cost is set to a deliberately high number to prevent
optimisations taking place, e.g. vectorization. It also provides
a route to represent the extremely high, and unknown, cost of
scalarization of scalable vectors, which is not currently supported.

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