https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95125
--- Comment #8 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
(In reply to Richard Biener from comment #7)
> (In reply to Uroš Bizjak from comment #6)
> > (In reply to Hongtao.liu from comment #5)
> > > (In reply to Uroš Bizjak from comment #3)
> > > > It turns out that a bunch of patterns have to be renamed (and testcases
> > > > added).
> > > >
> > > > Easyhack, waiting for someone to show some love to conversion patterns
> > > > in
> > > > sse.md.
> > >
> > > expander for floatv4siv4df2, fix_truncv4dfv4si2 already exists.
> > >
> > > if change **float_double fix_double** to
> > > ---
> > > void
> > > float_double (void)
> > > {
> > > d[0] = i[0];
> > > d[1] = i[1];
> > > d[2] = i[2];
> > > d[3] = i[3];
> > > }
> >
> > Hm, the above is vectorized, but the equivalent:
> >
> > void
> > float_double (void)
> > {
> > for (int n = 0; n < 4; n++)
> > d[n] = i[n];
> > }
> >
> > is not?
>
> Yes, we're committing to a too high VF here, likely because we pick the
> "wrong" vector mode too early. We could eventually fix this up in
> the early vectype analysis.
It might be worth investigating VECT_COMPARE_COSTS, which weighs
the cost of different VFs against each other and is how SVE copes
with this. I guess the danger is that it might interfere with
-mprefer-* options (although the first VF listed by
autovectorize_vector_modes wins in a tie).
