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.