https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2024-01-29
Ever confirmed|0 |1
--- Comment #27 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
So this loop shouldn't have been vectorized.
It is indeed a dup of the same problem as in PR113588.
The issue is that this loop contains a memory access to an unknown sized array
in the BB containing the loop CFG latch.
My initial patch here analyzed all loads but during review we thought that was
too restrictive, that we only need to analyze the loads in blocks which contain
an early exit and the loads reachable from the COND in the destination block.
The reasoning was that if you were to pass all the early exits the loads in the
final block would only be reached if you didn't take the exit. This is then
the same as normal vectorization and the loads are safe to issue after the
bounds check.
What it doesn't take into account is that if you pick a different exit the
latch then shifts as we discussed before.
The reason Richi's change worked before is that it forced the loop back upright
which then made the analysis correctly block it.
The bug is a sneaky one, but essentially vect_analyze_data_ref_dependence needs
to also keep in mind which exit is the main exit as determined by
vec_init_loop_exit_info.
In other words, it needs to use the vectorizer's chosen exit and not the loop
infrastructure.
Mine.
