[X86][CostModel] Adjust the costs of ZERO_EXTEND/SIGN_EXTEND with less than 128-bit...
authorCraig Topper <craig.topper@intel.com>
Wed, 14 Aug 2019 14:52:39 +0000 (14:52 +0000)
committerCraig Topper <craig.topper@intel.com>
Wed, 14 Aug 2019 14:52:39 +0000 (14:52 +0000)
commit30d3e9c3952096e80c3c82cf61caa545fc678170
tree140acd19654ce67f99d1a80be403b6cd113a8c10
parent8c545168ee4d0b446565c655230c7be2e3d56fe9
[X86][CostModel] Adjust the costs of ZERO_EXTEND/SIGN_EXTEND with less than 128-bit inputs

Now that we legalize by widening, the element types here won't change. Previously these were modeled as the elements being widened and then the instruction might become an AND or SHL/ASHR pair. But now they'll become something like a ZERO_EXTEND_VECTOR_INREG/SIGN_EXTEND_VECTOR_INREG.

For AVX2, when the destination type is legal its clear the cost should be 1 since we have extend instructions that can produce 256 bit vectors from less than 128 bit vectors. I'm a little less sure about AVX1 costs, but I think the ones I changed were definitely too high, but they might still be too high.

Differential Revision: https://reviews.llvm.org/D66169

llvm-svn: 368858
llvm/lib/Target/X86/X86TargetTransformInfo.cpp
llvm/test/Analysis/CostModel/X86/cast.ll
llvm/test/Analysis/CostModel/X86/extend.ll
llvm/test/Analysis/CostModel/X86/min-legal-vector-width.ll
llvm/test/Transforms/SLPVectorizer/X86/cast.ll
llvm/test/Transforms/SLPVectorizer/X86/sext.ll
llvm/test/Transforms/SLPVectorizer/X86/zext.ll