This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/60510] SLP blocks loop vectorization (with reduction)
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 13 Mar 2014 10:48:29 +0000
- Subject: [Bug tree-optimization/60510] SLP blocks loop vectorization (with reduction)
- Auto-submitted: auto-generated
- References: <bug-60510-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60510
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |53947
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, too late for reassoc to catch it. Only LIM store motion makes it a
scalar reduction, and:
# prephitmp_32 = PHI <pretmp_31(5), _18(8)>
_8 = prephitmp_32;
...
_13 = _12 + _8;
_18 = _13 + _16;
*a_7(D) = _18;
it's already botched after PRE (and before). So reassoc _could_ catch it
and re-associate
_8 = *a_7(D);
_9 = (integer(kind=8)) i_1;
_10 = _9 + -1;
_12 = *x_11(D)[_10];
_15 = *y_14(D)[_10];
_16 = _15 * _12;
_13 = _12 + _8;
_18 = _13 + _16;
*a_7(D) = _18;
so that the store to *a_7(D) is fed by _8 + ...
But that seems to be a bit too much special-casing. There isn't a good
pass before vectorization that could handle this so I think this is
finally a reason to make the vectorizer more properly recognize
reductions ...
(and keep the analysis result recorded somewhere, not try to re-match
stuff during transform phase - that's always flaky)