[PATCH] D24022: Update the vectorizer cost model for getVectorInstrCost to reflect actual costs of the operations on Power8/Power9

Kit Barton via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 22 11:51:03 PDT 2016


kbarton added a comment.

Added a few comments to start the discussion of how this should be designed.


================
Comment at: lib/Target/PowerPC/PPCTargetTransformInfo.cpp:315
@@ -314,3 +314,3 @@
 
 int PPCTTIImpl::getVectorInstrCost(unsigned Opcode, Type *Val, unsigned Index) {
   assert(Val->isVectorTy() && "This must be a vector type");
----------------
This seems to be the point where all of the interesting changes are, so I'll add my comments here.

I would recommend that some of these values (i.e, DirectMoveCost be defined somewhere else, either as an enumeration or #define. I expect that these costs will change over time (with the hardware), and it would be good to have a clear and convenient mechanism to represent that as opposed to a bunch of condition checks in this function.

Off the top of my head, I can think of a few general ways to design this:
1. Try to create a generic cost function here, that is "built" based on values defined as constants
2. Create a separate function for each architecture, that needs to be updated with every new hardware (i.e., P8InstrCost, p9InstrCost, ...)
3. Create a class that can be used, with subclasses for new architectures that can override the defaults when values change.

I'm sure there are other possibilities as well.


Repository:
  rL LLVM

https://reviews.llvm.org/D24022





More information about the llvm-commits mailing list