Mans Rullgard <mans.rullg...@linaro.org> wrote:
> static void ps_hybrid_analysis_ileave_c(float (*out)[32][2],
> float L[2][38][64],
> int i, int len)
> {
> int j;
>
> for (; i < 64; i++) {
> for (j = 0; j < len; j++) {
> out[i][j][0] = L[0][j][i];
> out[i][j][1] = L[1][j][i];
> }
> }
> }
>
> While gcc 4.6 does not attempt to vectorise this at all, 4.7 goes crazy
> with a massive slowdown, about 20x slower than non-vectorised with Linaro
> 4.7 and much worse with FSF 4.7.
>
> Let me know if you need more information.
Thanks for the report; I can reproduce the problem.
There's a number of issues with how GCC choses the vectorize this loop
that we can potentially improve upon. However, it would appear that no
matter what, it probably isn't actually helpful to try to vectorize this
loop in the first place.
Fortunately, the vectorizer cost model clearly recognizes this fact (and
will classify this loop as "not vectorized: vector version will never be
profitable").
Unfortunately, it seems that on ARM, the cost model is actually off by
default (it is enabled by default only on i386).
We'll have to enable the cost model on ARM by default as well (and
probably tune it a bit to avoid regresssions on other benchmarks).
However for now, I'd recommend you use -fvect-cost-model when testing
the vectorizer on libav.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
