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.
