https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126053
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed| |2026-07-02
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's interesting that with -fno-signed-zeros we manage to build a 6-lane SLP
graph for all of the virial_* reduction up to the store to *reduction.
But then we eventually run into
namd557_pair_fail.cpp:113:20: note: ==> examining statement: _3 =
*params_121(D).offset_x;
namd557_pair_fail.cpp:113:20: missed: BB vectorization with gaps at the end
of a load is not supported
namd557_pair_fail.cpp:87:39: missed: not vectorized: relevant stmt not
supported: _3 = *params_121(D).offset_x;
namd557_pair_fail.cpp:113:20: note: Building vector operands of 0x2ab54950
from scalars instead
which is overly restrictive (we basically fall back to elementwise accesses).
That would be one thing to improve that might help costing.
In that very subgraph we have also the f_j_170.{x,y} stores. There's still
note: [l*]stmt 5 tmp_z_163 = p_ij_z_150 * force_r_151;
note: [l*]stmt 5 tmp_z_186 = p_ij_z_173 * force_r_174;
but no live stmts we cannot handle with lane extracts.
But, we have
namd557_pair_fail.cpp:113:20: note: Cost model analysis for part in loop 1:
Vector cost: 296
Scalar cost: 272
namd557_pair_fail.cpp:113:20: missed: not vectorized: vectorization is not
profitable.
as we cost stmts in different loops separately. loop 1 is the outer loop
here. Overall we have
namd557_pair_fail.cpp:113:20: note: Cost model analysis for part in loop 0:
Vector cost: 196
Scalar cost: 264
namd557_pair_fail.cpp:113:20: note: Cost model analysis for part in loop 1:
Vector cost: 296
Scalar cost: 272
namd557_pair_fail.cpp:113:20: note: Cost model analysis for part in loop 2:
Vector cost: 324
Scalar cost: 332
namd557_pair_fail.cpp:113:20: note: Cost model analysis for part in loop 3:
Vector cost: 304
Scalar cost: 332
the two inner loops and the function level parts are profitable. But all
only moderately. An enhancement would be to allow inner loop profitability
to override outer loop unprofitabilities, assuming we roll once. In this
case this would be offsetting the 24 extra cost in loop 1 by the win
of 8 and 28 in the inner loops.
A more detailed loop at the costing and whether it's reasonable is appropriate
as well.
Leaves the -fno-signed-zeros requirement to arrive at the SLP
discovery result. This is because when hitting
namd557_pair_fail.cpp:113:20: note: Build SLP for _65 = _64 + virial_xx_246;
namd557_pair_fail.cpp:113:20: note: Build SLP for _67 = _66 + virial_xy_252;
namd557_pair_fail.cpp:113:20: note: Build SLP for _69 = _68 + virial_xz_258;
namd557_pair_fail.cpp:113:20: note: Build SLP for _71 = _70 + virial_yy_264;
namd557_pair_fail.cpp:113:20: note: Build SLP for _73 = _72 + virial_yz_270;
namd557_pair_fail.cpp:113:20: note: Build SLP for _75 = _74 + virial_zz_276;
namd557_pair_fail.cpp:113:20: note: Build SLP for _77 = _76 + 0.0;
namd557_pair_fail.cpp:113:20: note: Build SLP for _79 = _78 + 0.0;
namd557_pair_fail.cpp:113:20: note: Build SLP for _81 = _80 + 0.0;
namd557_pair_fail.cpp:113:20: note: Build SLP for _83 = _82 + 0.0;
namd557_pair_fail.cpp:113:20: note: Build SLP for _85 = _84 + 0.0;
namd557_pair_fail.cpp:113:20: note: Build SLP for _87 = _86 + 0.0;
there is a mix of internal and constant defs for the 2nd operand which
we conclude as fine by promoting that external, stopping discovery.
We do not attempt to split the set of stmts. I think what we should
do here is fork the graph (instead of re-doing discovery after splitting),
possibly at constrained boundaries (so full vectors are on each side, but
possibly with different vector type) and merge with (then zero cost)
VEC_PERM nodes.
I will attempt to create separate bugreports for these separate issues,
possibly leaving the different-loop-cost issue in this bug, because it
requires this complex testcase.
