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

[Quentin Colombet]

================
Comment at: include/llvm/Target/TargetLowering.h:268
@@ +267,3 @@
+  /// in one instruction.
+  bool canCombineStoreAndExtract() const { return CanCombineStoreAndExtract; }
+
----------------
hfinkel wrote:
> 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.
Agreed.
Thanks!

http://reviews.llvm.org/D5921