Don't punish vectorized arithmetic instruction whose type will be split to multiple registers

Currently in LLVM's cost model, a vectorized arithmetic instruction will have
high cost if its type is split into multiple registers. However, this
punishment is too heavy and unnecessary. The overhead of the split should not
be on arithmetic instructions but instructions that implement the split. Note
that during vectorization we have calculated the register pressure, and we
only choose proper interleaving factor (and also vectorization factor) so
that we don't use more registers than the maximum number.

Here is a very simple example: if a vadd has the cost 1, and if we double VF
so that we need two registers to perform it, then its cost will become 4 with
the current implementation, which will prevent us to use larger VF.


Differential revision: http://reviews.llvm.org/D15159

llvm-svn: 254671
This commit is contained in:
Cong Hou 2015-12-04 00:36:58 +00:00
parent 402257b84e
commit 94620278a4
2 changed files with 2 additions and 6 deletions

View File

@ -302,12 +302,8 @@ public:
if (TLI->isOperationLegalOrPromote(ISD, LT.second)) {
// The operation is legal. Assume it costs 1.
// If the type is split to multiple registers, assume that there is some
// overhead to this.
// TODO: Once we have extract/insert subvector cost we need to use them.
if (LT.first > 1)
return LT.first * 2 * OpCost;
return LT.first * 1 * OpCost;
return LT.first * OpCost;
}
if (!TLI->isOperationExpand(ISD, LT.second)) {

View File

@ -33,7 +33,7 @@ define fastcc i32 @reduction_cost_int(<8 x i32> %rdx) {
%bin.rdx.3 = add <8 x i32> %bin.rdx.2, %rdx.shuf.3
; CHECK-LABEL: reduction_cost_int
; CHECK: cost of 23 {{.*}} extractelement
; CHECK: cost of 17 {{.*}} extractelement
%r = extractelement <8 x i32> %bin.rdx.3, i32 0
ret i32 %r