https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126384
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |17.0
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Thanks for the analysis, this is a -ffast-math artifact. I expect we'll want
to adjust x86 costing for vectorized SLP reductions, esp. with two lanes and
short
sequences like this.
int foo (float x2, int a, int b)
{
int a1 = a * 170;
int b1 = b % 30323;
float tem1 = a1 * 3.29782669723e-5f;
float tem2 = b1 * 3.3037100365e-5f;
return x2 + tem1 + tem2;
}
for this testcase we vectorize with generic tuning, not with zen2 tuning but
again with zen4 tuning. generic tuning shows:
t.c:7:20: note: Cost model analysis for part in loop 0:
Vector cost: 100
Scalar cost: 104
t.c:7:20: note: Basic block will be vectorized using SLP
but I think that for two-lane vectorization we should raise the bar to require
at least, say, 50% throughput improvement because we'll get a latency hit
from tieing the lanes together assuming we can issue the scalar uops in
parallel with enough execution units in the two-lane case.
