[PATCH] [CodeGenPrepare] Move extractelement close to store if they can be combined.
hfinkel at anl.gov
hfinkel at anl.gov
Thu Oct 23 14:11:09 PDT 2014
================
Comment at: include/llvm/Target/TargetLowering.h:268
@@ +267,3 @@
+ /// in one instruction.
+ bool canCombineStoreAndExtract() const { return CanCombineStoreAndExtract; }
+
----------------
I would really like this to be a callback that passes the type and the extraction index. For PowerPC, for example, I can make this free for some types, but only for index 0. For other indices, I can do it with a shuffle (which obviously has some extra cost, although not much as the load/store-based domain crossing).
IMHO, a great interface for this could be:
int getStoreExtractCombineCost(Type *VectorTy, Value *Idx);
================
Comment at: lib/CodeGen/CodeGenPrepare.cpp:3264
@@ +3263,3 @@
+ // scalar to vector.
+ // The vector chain does not.
+ unsigned ScalarCost =
----------------
You should add: because the target has asserted that it can combine the extract with the store (for free).
================
Comment at: lib/CodeGen/CodeGenPrepare.cpp:3314
@@ +3313,3 @@
+ if (!isa<ConstantInt>(Val) && !isa<UndefValue>(Val)) {
+ if (isa<ConstantFP>(Val))
+ DEBUG(dbgs() << "Constant FP: could have handle that.\n");
----------------
What is the complication to handling this case?
If you really can't test this on ARM, please explicitly note this as FIXME.
================
Comment at: lib/CodeGen/CodeGenPrepare.cpp:3324
@@ +3323,3 @@
+ return TLI.isOperationLegalOrCustom(ISDOpcode,
+ EVT::getEVT(getTransitionType(), true));
+ }
----------------
You also need to exclude division (because introducing a division by undef is a bad idea), or make sure that if you do this for division, then the other fields are set to some non-zero quantity.
http://reviews.llvm.org/D5921
More information about the llvm-commits
mailing list