https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125937
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=119902
Status|UNCONFIRMED |NEW
Last reconfirmed| |2026-06-30
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
All testcases use gather/scatter. Without compare-costs we use
tsvc.c:63:27: optimized: loop vectorized using 16 byte vectors and unroll
factor 4
and with we do
tsvc.c:63:27: optimized: loop vectorized using 8 byte vectors and unroll factor
2
V16QImode costs:
tsvc.c:63:27: note: Cost model analysis:
Vector inside of loop cost: 232
Vector prologue cost: 4
Vector epilogue cost: 16
Scalar iteration cost: 60
Scalar outside cost: 0
Vector outside cost: 20
prologue iterations: 0
epilogue iterations: 0
Calculated minimum iters for profitability: 11
V8QImode:
tsvc.c:63:27: note: Cost model analysis:
Vector inside of loop cost: 96
Vector prologue cost: 4
Vector epilogue cost: 28
Scalar iteration cost: 60
Scalar outside cost: 0
Vector outside cost: 32
prologue iterations: 0
epilogue iterations: 0
Calculated minimum iters for profitability: 3
which is clearly better.
I think this is a duplicate of / the same as PR119902. We are accounting
for a vector load and decomposing ip[] for b[ip[i]], but forwprop will
later improve that to do N scalar loads instead.
Note that replacing deconstruct cost with scalar load costs might not help
here. We have 20 + 60 vs. 4 * 12. So the actual issue is that we
pessimize gather/scatter vector construction cost with an additional
factor based on the number of lanes. Doing N scalar loads would still
get us what the comment indicates:
/* If we do elementwise loads into a vector then we are bound by
latency and execution resources for the many scalar loads
(AGU and load ports). Try to account for this by scaling the
construction cost by the number of elements involved. */
but in the end such pessimizing should only start after some minimum
number of lanes. We do
stmt_cost *= (GET_MODE_BITSIZE (TYPE_MODE (ls_type))
/ GET_MODE_BITSIZE (TYPE_MODE (ls_eltype)) + 1);
so even for a single lane we scale by two.
