https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126101
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The fast_{d,c,b,a} are not really reductions, fast_dir might be, but without
-ffast-math we cannot do any FP association. With -ffast-math I see
discovery for
t.ii:60:40: note: _50 = vdw_d_108 * _146;
t.ii:60:40: note: _51 = vdw_c_109 * 2.5e-1;
and
t.ii:61:14: note: _53 = _52 * diffa_98;
t.ii:61:14: note: _54 = vdw_b_110 * 5.0e-1;
and
t.ii:72:41: note: _62 = fast_d_114 * _146;
t.ii:72:41: note: _63 = fast_c_115 * 2.5e-1;
and
t.ii:73:14: note: _65 = _64 * diffa_98;
t.ii:73:14: note: _66 = fast_b_116 * 5.0e-1;
and
t.ii:77:16: note: vdw_d_108 = _34 - _36;
t.ii:77:16: note: fast_d_114 = _57 * kqq_104;
and more. The vectorized SLP portions are not too big though.
How does oneAPI deal with the vdw_* uses in the fast_val computation,
how does it represent fast_{d,c,b,a}? Does it build up / tear down
vectors at those boundaries to scalar code?
