[Bug tree-optimization/126372] [17 Regression] 6% slowdown of calculix on Zen2 since r17-2478-g3adb3325954177

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
For -Ofast -g also reproducible on a Zen4 host.  IIRC milc was sensitive to
code layout changes.  Once I throw perf at it the difference vanishes.

There is only

-check_unitarity.c:128:9: optimized: basic block part vectorized using 16 byte
vectors
-check_unitarity.c:145:9: optimized: basic block part vectorized using 16 byte
vectors
+check_unitarity.c:146:5: optimized: basic block part vectorized using 16 byte
vectors
+m_mat_nn.c:88:32: optimized: basic block part vectorized using 16 byte vectors


The m_mat_nn.c (mult_su3_nn) part is us now vectorizing

void mult_su3_nn( su3_matrix *a, su3_matrix *b, su3_matrix *c ){
  int i,j;
  register double t,ar,ai,br,bi,cr,ci;
    for(i=0;i<3;i++)for(j=0;j<3;j++){

        ar=a->e[i][0].real; ai=a->e[i][0].imag;
        br=b->e[0][j].real; bi=b->e[0][j].imag;
        cr=ar*br; t=ai*bi; cr -= t;
        ci=ar*bi; t=ai*br; ci += t;

        ar=a->e[i][1].real; ai=a->e[i][1].imag;
        br=b->e[1][j].real; bi=b->e[1][j].imag;
        t=ar*br; cr += t; t=ai*bi; cr -= t;
        t=ar*bi; ci += t; t=ai*br; ci += t;

        ar=a->e[i][2].real; ai=a->e[i][2].imag;
        br=b->e[2][j].real; bi=b->e[2][j].imag;
        t=ar*br; cr += t; t=ai*bi; cr -= t;  <---  this
        t=ar*bi; ci += t; t=ai*br; ci += t;  <---

        c->e[i][j].real=cr;  <--- in addition to this
        c->e[i][j].imag=ci;
    }
}

vectorizing c->e[1][2].real = <plus reduction>

+  vectp.627_1209 = &b_10(D)->e[2][2];
+  vect_bi_120.628_1210 = MEM <vector(2) double> [(double *)vectp.627_1209];
+  _1213 = BIT_FIELD_REF <vect_bi_120.628_1210, 64, 64>;
+  _1212 = BIT_FIELD_REF <vect_bi_120.628_1210, 64, 0>;
...
+  vectp.630_1214 = &a_7(D)->e[1][2];
+  vectp.630_1225 = vectp.630_1214;
+  vect_ai_323.636_1226 = MEM <vector(2) double> [(double *)vectp.630_1225];
+  vect_ar_71.637_1227 = VEC_PERM_EXPR <vect_ai_323.636_1226,
vect_ai_323.636_1226, { 1, 0 }>;
+  vect_t_611.638_1228 = vect_bi_120.628_1210 * vect_ar_71.637_1227;
...
+  _1229 = .REDUC_PLUS (vect_t_611.638_1228);
+  _1230 = ci_382 + t_370;
+  _1231 = _1230 + t_329;
+  _1232 = _1231 + t_335;
+  _1233 = _1229 + _1232;
+  ci_612 = _1233;

as this has common nodes with the rest it only alters costs slightly,
increasing profitability even:

-m_mat_nn.c:90:17: note: Cost model analysis for part in loop 0:
-  Vector cost: 1804
-  Scalar cost: 2004
+  Vector cost: 1928
+  Scalar cost: 2128

but then it's probably, overall, not a very profitable vectorization
of scalar code.



The check_unitarity.c:check_su3 change looks like a good one, replacing
three separate plus reductions with a combined MAX reduction and vectorized
sqrt.