[llvm-commits] [llvm] r166642 - in /llvm/trunk: include/llvm/Target/TargetLowering.h include/llvm/Target/TargetTransformImpl.h lib/Target/TargetTransformImpl.cpp lib/Transforms/IPO/PassManagerBuilder.cpp lib/Transforms/Vectorize/LoopVectorize.cpp test/Transforms/LoopVectorize/cost-model.ll

[Hal Finkel]

----- Original Message -----
> From: "Nadav Rotem" <nrotem at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvm-commits at cs.uiuc.edu
> Sent: Wednesday, October 24, 2012 11:41:30 PM
> Subject: Re: [llvm-commits] [llvm] r166642 - in /llvm/trunk: include/llvm/Target/TargetLowering.h
> include/llvm/Target/TargetTransformImpl.h lib/Target/TargetTransformImpl.cpp
> lib/Transforms/IPO/PassManagerBuilder.cpp lib/Transforms/Vectorize/LoopVectorize.cpp
> test/Transforms/LoopVectorize/cost-model.ll
> 
> 
> 
> 
> On Oct 24, 2012, at 8:27 PM, Hal Finkel < hfinkel at anl.gov > wrote:
> 
> 
> This should correspond to an ADD + MUL? Given that we have a
> vectorized GEP, I'd think that we certainly don't want this to be
> zero.
> 
> 
> 
> FWIW, I think that vector-geps are only a good idea for
> scatter/gather instructions (such as the one MIC has). The reason is
> that scalar GEPs can be implemented as part of the addressing mode.
> 
> 
> So, I think that we should not emit vector-geps unless we have a
> really good reason.

Fair enough. Nevertheless, this does not seem like an argument for giving them a zero cost. Is it? I'd think that we'd want to give them some cost by default, and then lower that cost on targets where that makes sense. Also, should we add something like:
bool useVectorGEP(), which by default returns false, so that we can only emit these on targets where it makes sense. That, combined with the cost information, will allow us to reason about creating vector GEPs for MIC, etc.

Thanks again,
Hal

> 

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory