https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #25 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Hao Liu from comment #0)
> This problem causes a performance regression in SPEC2017 538.imagick. For
> the following simple case (modified from pr96208):
>
> typedef struct {
> unsigned short m1, m2, m3, m4;
> } the_struct_t;
> typedef struct {
> double m1, m2, m3, m4, m5;
> } the_struct2_t;
>
> double bar1 (the_struct2_t*);
>
> double foo (double* k, unsigned int n, the_struct_t* the_struct) {
> unsigned int u;
> the_struct2_t result;
> for (u=0; u < n; u++, k--) {
> result.m1 += (*k)*the_struct[u].m1;
> result.m2 += (*k)*the_struct[u].m2;
> result.m3 += (*k)*the_struct[u].m3;
> result.m4 += (*k)*the_struct[u].m4;
> }
> return bar1 (&result);
> }
>
In the context of this report the regression should be fixed, however we still
don't vectorize this loop. We ran this and other cases comparing scalar and
vector versions of this loop and it looks like specifically Neoverse N2 does
much better using the scalar version here. So it looks like the cost model is
doing the right thing here for the current codegen of the function.
Note that the vector version:
ldr q31, [x3], 16
ldr q29, [x4], -16
rev64 v31.8h, v31.8h
uxtl v30.4s, v31.4h
uxtl2 v31.4s, v31.8h
sxtl v27.2d, v30.2s
sxtl v28.2d, v31.2s
sxtl2 v30.2d, v30.4s
sxtl2 v31.2d, v31.4s
scvtf v27.2d, v27.2d
scvtf v28.2d, v28.2d
scvtf v30.2d, v30.2d
scvtf v31.2d, v31.2d
fmla v26.2d, v27.2d, v29.d[1]
fmla v24.2d, v30.2d, v29.d[1]
fmla v23.2d, v28.2d, v29.d[0]
fmla v25.2d, v31.2d, v29.d[0]
Is still pretty inefficient due to all the extends. If we generate better code
here this may tip the scale back to vector. But for now, the patch should fix
the regression.
