[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