[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