https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80634
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-05-05
CC| |rguenth at gcc dot gnu.org
Blocks| |53947
Ever confirmed|0 |1
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. Yet another example where the alingment peeling is confused by the
vectorizer cost model of the target (well -- not entirely so but clearly that's
part of the story).
There's some niter-based cost modeling going on as well that's very
conservative
at the moment:
/* Cost model #2 - if peeling may result in a remaining loop not
iterating enough to be vectorized then do not peel. */
if (do_peeling
&& LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo))
{
unsigned max_peel
= npeel == 0 ? LOOP_VINFO_VECT_FACTOR (loop_vinfo) - 1 : npeel;
if (LOOP_VINFO_INT_NITERS (loop_vinfo)
< LOOP_VINFO_VECT_FACTOR (loop_vinfo) + max_peel)
do_peeling = false;
}
so it just ensures the remaining vector loop would iterate at least once. But
in reality it should use the full cost model, thus looking at the peeling cost,
esp. if we need to add a epilogue. That's not easily possible right now so
some better heuristic is needed here, like pessimizing the case where
niter is a multiple of VF.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
