[Bug tree-optimization/126053] GCC trunk vs ICX : Missed SLP vectorization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126053

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
The testcase is now vectorized as profitable with -fno-signed-zeros but when
using -mtune=znver{5,6} which seem to reduce scalar and increase vector costs
(-znver4, +znver5):

-  Vector cost: 316
-  Scalar cost: 336
+  Vector cost: 300
+  Scalar cost: 288
-  Vector cost: 388
-  Scalar cost: 392
+  Vector cost: 340
+  Scalar cost: 288
-  Vector cost: 388
-  Scalar cost: 428
+  Vector cost: 348
+  Scalar cost: 348
-  Vector cost: 368
-  Scalar cost: 428
+  Vector cost: 328
+  Scalar cost: 348

mainly because scalar_stmt now costs 8 instead of 12.  This makes loads +
stores comparatively more expensive.

With -fsigned-zeros PR126080 prevails.  Resolving PR126079 might improve
parts like

  _462 = MEM[(double *)_306];
  _461 = MEM[(double *)_306 + 8B];
  _460 = MEM[(double *)_306 + 16B];
  vect__4.14_457 = {_462, _462, _462, _461};
  vect_p_i_x_122.15_456 = vect__4.14_457 + vect__3.11_464;
  vect__4.57_394 = {_462, _461, _460, _461};
  vect_p_i_x_122.58_393 = vect__4.57_394 + vect__3.54_401;
  vect__6.91_352 = MEM <const vector(2) double> [(double *)_306 + 8B];

there's also the pattern of a partly uniform 4-lane operation:

  vect_cst__465 = {_469, _468, _467, _466}; 
  vect__3.11_464 = VEC_PERM_EXPR <vect_cst__465, vect_cst__465, { 0, 0, 0, 1
}>; 
  vect__4.14_457 = VEC_PERM_EXPR <vect_cst__458, vect_cst__458, { 0, 0, 0, 1
}>;
  vect_p_i_x_122.15_456 = vect__3.11_464 + vect__4.14_457;
  vect__17.18_449 = VEC_PERM_EXPR <vect_cst__450, vect_cst__450, { 0, 0, 0, 1
}>;
  vect_p_ij_x_171.19_448 = vect_p_i_x_122.15_456 - vect__17.18_449;
  _447 = {force_r_174, force_r_174, force_r_174, force_r_174};
  vect_tmp_x_175.20_446 = vect_p_ij_x_171.19_448 * _447;
  vect__21.68_375 = vect_p_ij_x_171.67_376 * vect_tmp_x_175.20_446;

where the chain up to vect_tmp_x_175.20_446 could be handled with
{ 0, 1 } SSE and then spread to { 0, 0, 0, 1 } for the last operation.
Not a huge win uarch wise, but the vector construction operations would
simplify.  Possibly doable at SLP discovery time, similar to splitting.