[PATCH] [CodeGenPrepare] Move extractelement close to store if they can be combined.

[hfinkel at anl.gov]

================
Comment at: include/llvm/Target/TargetLowering.h:268
@@ +267,3 @@
+  /// in one instruction.
+  bool canCombineStoreAndExtract() const { return CanCombineStoreAndExtract; }
+
----------------
qcolombet wrote:
> hfinkel wrote:
> > 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);
> > 
> Although I like the direction of this, how do we get the cost of the original sequence?
> In other words, what value do you propose we use to decide whether or not it is worth kicking this optimization given those two parameters?
> 
> Indeed, I expect that we will replace the condition that guards the optimization with something like:
> TLI->getStoreExtractCombineCost(ExtractInst->getType(), ExtractInst->getOperand(1)) < CostOfIndividualStoreAndExtract
> 
> I assume you were thinking "== 0” since you talked about free. Is it what you had in mind?
Thinking about this, the interface I proposed will be difficult to use (because it seems like you'd need to cost-model the entire transformation in order to figure anything out). How about:

  bool canCombineStoreAndExtract(Type *VectorTy, Value *Idx, unsigned &Cost)

where, if true is returned and we move forward with modeling the transformation, we add Cost to VectorCost in isProfitableToPromote. This seems better.

http://reviews.llvm.org/D5921