https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #22 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #21)
> loop->nb_iterations_upper_bound exactly is an upper bound on the number of
> latch executions, so maybe I'm missing the point here. When we update it it
> as
> well has to reflect an upper bound on that, whether the last exit (the one
> before the latch) is the IV exit or a vectorized early exit.
Yes, but the issue here is that the bounds limit is coming from an exit other
than the one being chosen as the IV exit.
So the latch iterates X times not X - 1.
>
> But yes, if the last exit is an early one that last iteration might be
> partial
> (so we drop the -1), but that's what we already do?
I don't see where. This code all seems to remove -1 from the iteration count
and assuming the latch iteration count + 1 == nbounds.
I don't really think this is about partial loops at all.
Change
parse_tables_n >>= 9;
parse_tables_n += 11;
to
parse_tables_n >>= 9;
parse_tables_n += 10;
then loop->nb_iterations_upper_bound is 136 and there is no partial iterations
here.
You do 17 full vector iterations with no residuals.
