This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Helping out the Vectorizer
- From: Dorit Nuzman <DORIT at il dot ibm dot com>
- To: Gordan Bobic <gordan at bobich dot net>
- Cc: gcc-help at gcc dot gnu dot org, "Richard Guenther" <richard dot guenther at gmail dot com>
- Date: Wed, 15 Aug 2007 19:53:23 +0300
- Subject: Re: Helping out the Vectorizer
> On Tue, 14 Aug 2007, Dorit Nuzman wrote:
>
> >> In this case, 4.3 will vectorize the loop on 15.
> >>
> >> The others are just too complex of reduction patterns right now, it
> >> looks like.
> >>
> >> Feel free to file a missed optimization bug on it :)
> >
> > Actually there's already a PR for it - PR32824. I'm getting more and
more
> > testcases where this pattern occurs... I hope the generic reduction
> > detection will be ready in the near future...
>
> Another problem seems to be that there seems to be little effort on part
> of GCC to automatically align arrays to a 16-byte boundary - and there's
> no excuse for that in case of static ones. (Unless, of course, I'm
> misinterpreting the vectorizer report "vectorizing unaligned access".)
> Vectorizing operations on unaligned arrays is cosiderably less efficient.
>
we do force the alignment of static arrays (e.g. BestFit in your code
example). The reason we end up generating unaligned accesses to it is that
GCC can't force the alignment of Curve, and since GCC currently doesn't
support vectorization of misaligned stores, what it does is peel a few
iterations from the loop until we reach an aligned address, at which point
we'll enter the loop. While this aligns the store, at the same time it
makes the load from BestFir unaligned... (but vectorizing unaligned loads
is something GCC knows how to do).
> On a separate note, why is (float * float) getting transformed to a
> powf() call (according to the vectorizer report, again), when multiplying
> seems to be faster for low powers?
>
The vectorizer actually detects the power-of-2 pattern and replaces it with
a multiplication:
test.cpp:32: note: pattern recognized: Temp.8_29 * Temp.8_29
(but this is only for the purpose of vectorization; if vectorization
doesn't take place, the pow stays in tact)
> And is there an eta on a vectorizable sinf()?
>
There is initial support to vectorize calls to math functions, given a
vectorized math lib. I'm not sure what's the status of that. Richard may
know.
dorit
> Gordan