[PATCH 2/3] ARM cost model: Address computation in vector mem ops not free

[Nadav Rotem]

The problem is that we decide on the kind of GEP to use only when we vectorize the load/stores.  This happens in vectorizeMemoryInstruction. I think that we need to fix this in LoopVectorizationCostModel::getInstructionCost in the load/store switch cases. We have code for checking if the load/store is wide or if it is scalarized. 

On Feb 1, 2013, at 10:00 AM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote:

> Hi Nadav,
> 
> On Feb 1, 2013, at 11:44 AM, Nadav Rotem <nrotem at apple.com> wrote:
> 
>> The cost model part LGTM.  The Loop Vectorizer does not use the cost model analysis itself because it needs to check the costs of instructions that have not yet been generated. We need to change the loop vectorizer cost model to use this API. It could be a bit tricky because in some cases we don't use the original GEP because we widen the load/store. 
> 
> I am not sure I understand what you mean by:
> 
>> We need to change the loop vectorizer cost model to use this API. 
> 
> Do you mean we need to change the LoopVectorizer to use the new TTI api? In this case, the patch already contains a change to the LoopVectorizer to use the TargetTransformInfo API, passing the vector type.
> 
> --- a/lib/Transforms/Vectorize/LoopVectorize.cpp
> +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp
> @@ -3045,7 +3045,8 @@ LoopVectorizationCostModel::getInstructionCost(Instruction *I, unsigned VF) {
>     // We mark this instruction as zero-cost because scalar GEPs are usually
>     // lowered to the intruction addressing mode. At the moment we don't
>     // generate vector geps.
> -    return 0;
> +    return TTI.getAddressComputationCost(VectorTy);
> +
> 
> I added code to the cost model analysis in order to be able to write succinct unit tests (and for completeness). Maybe this is where the misunderstanding stems from?
> 
> Thanks,
> Arnold