This patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00405.html includes: diff --git a/gcc/config/i386/x86-tune-costs.h b/gcc/config/i386/x86-tune-costs.h index e943d13..8409a5f 100644 --- a/gcc/config/i386/x86-tune-costs.h +++ b/gcc/config/i386/x86-tune-costs.h @@ -1557,7 +1557,7 @@ struct processor_costs skylake_cost = { {4, 4, 4}, /* cost of loading integer registers in QImode, HImode and SImode. Relative to reg-reg move (2). */ - {6, 6, 6}, /* cost of storing integer registers */ + {6, 6, 3}, /* cost of storing integer registers */ 2, /* cost of reg,reg fld/fst */ {6, 6, 8}, /* cost of loading fp registers in SFmode, DFmode and XFmode */ It lowered the cost for SImode store and made it cheaper than SSE<->integer register move. It caused a regression: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90878 Since the cost for SImode store is also used to compute costs of scalar_store RTL expression in ix86_builtin_vectorization_cost, it changed loop costs in void foo (long p2, long *diag, long d, long i) { long k; k = p2 < 3 ? p2 + p2 : p2 + 3; while (i < k) diag[i++] = d; } As the result, the loop is unrolled 4 times with -O3 -march=skylake, instead of 3.
In the latest gcc version(GCC10_20190820), there's no difference in unroll factor when applying this patch. But still there's difference in Profitability threshold which changes from 5 to 4. That means if loop count less than Profitability threshold, it won't trigger vectorization. So if loop count is 4, runtime performance would be different otherwise they will be the same.
@H.J.Lu: Can we close the issue or is it still valid?
Fixed by r274543.