Hi,
We found that the vectorization cost modeling on scalar COND_EXPR is a bit off
on rs6000. One typical case is 548.exchange2_r, -Ofast -mcpu=power9 -mrecip
-fvect-cost-model=unlimited is better than -Ofast -mcpu=power9 -mrecip (the
default is -fvect-cost-model=dynamic) by 1.94%. Scalar COND_EXPR is expanded
into compare + branch or compare + isel normally, either of them should be
priced more than the simple FXU operation. This patch is to add additional
vectorization cost onto scalar COND_EXPR on top of builtin_vectorization_cost.
The idea to use additional cost value 2 instead of the others: 1) try various
possible value candidates from 1 to 5, 2 is the best measured on Power9. 2)
from latency view, compare takes 3 cycles and isel takes 2 on Power9, it's
2.5 times of simple FXU instruction which takes cost 1 in the current
modeling, it's close. 3) get fine SPEC2017 ratio on Power8 as well.
The SPEC2017 performance evaluation on Power9 with explicit unrolling shows
548.exchange2_r +2.35% gains, but 526.blender_r -1.99% degradation, the others
is trivial. By further investigation on 526.blender_r, the assembly of 10
hottest functions are unchanged, the impact should be due to some side effects.
SPECINT geomean +0.16%, SPECFP geomean -0.16% (mainly due to blender_r).
Without explicit unrolling, 548.exchange2_r +1.78% gains and the others are
trivial. SPECINT geomean +0.19%, SPECINT geomean +0.06%.
While the SPEC2017 performance evaluation on Power8 shows 500.perlbench_r
+1.32% gain and 511.povray_r +2.03% gain, the others are trivial. SPECINT
geomean +0.08%, SPECINT geomean +0.18%.
Bootstrapped and regress tested on powerpc64le-linux-gnu.
Is OK for trunk?
BR,
Kewen
---
gcc/ChangeLog
2019-12-11 Kewen Lin <li...@gcc.gnu.org>
* config/rs6000/rs6000.c (adjust_vectorization_cost): New function.
(rs6000_add_stmt_cost): Call adjust_vectorization_cost and update
stmt_cost.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 2995348..5dad3cc 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -5016,6 +5016,29 @@ rs6000_init_cost (struct loop *loop_info)
return data;
}
+/* Adjust vectorization cost after calling rs6000_builtin_vectorization_cost.
+ For some statement, we would like to further fine-grain tweak the cost on
+ top of rs6000_builtin_vectorization_cost handling which doesn't have any
+ information on statement operation codes etc. One typical case here is
+ COND_EXPR, it takes the same cost to simple FXU instruction when evaluating
+ for scalar cost, but it should be priced more whatever transformed to either
+ compare + branch or compare + isel instructions. */
+
+static unsigned
+adjust_vectorization_cost (enum vect_cost_for_stmt kind,
+ struct _stmt_vec_info *stmt_info)
+{
+ if (kind == scalar_stmt && stmt_info && stmt_info->stmt
+ && gimple_code (stmt_info->stmt) == GIMPLE_ASSIGN)
+ {
+ tree_code subcode = gimple_assign_rhs_code (stmt_info->stmt);
+ if (subcode == COND_EXPR)
+ return 2;
+ }
+
+ return 0;
+}
+
/* Implement targetm.vectorize.add_stmt_cost. */
static unsigned
@@ -5031,6 +5054,7 @@ rs6000_add_stmt_cost (void *data, int count, enum
vect_cost_for_stmt kind,
tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;
int stmt_cost = rs6000_builtin_vectorization_cost (kind, vectype,
misalign);
+ stmt_cost += adjust_vectorization_cost (kind, stmt_info);
/* Statements in an inner loop relative to the loop being
vectorized are weighted more heavily. The value here is
arbitrary and could potentially be improved with analysis. */
