https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91822
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So I belive we can fix this with
Index: gcc/tree-vect-loop.c
===================================================================
--- gcc/tree-vect-loop.c (revision 275972)
+++ gcc/tree-vect-loop.c (working copy)
@@ -6534,9 +6534,10 @@ vectorizable_reduction (stmt_vec_info st
{
/* Only call during the analysis stage, otherwise we'll lose
STMT_VINFO_TYPE. */
- gcc_assert (reduc_index > 0);
+ gcc_assert (nested_cycle || reduc_index > 0);
if (!vec_stmt && !vectorizable_condition (stmt_info, gsi, NULL,
- reduc_index, NULL, cost_vec))
+ nested_cycle ? 0 : reduc_index,
+ NULL, cost_vec))
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
not sure what in the end exposed it but nested cycle vectorization treats
the stmts as regular stmt, not really caring about reduc_index. I'll have to
dig (tomorrow) what we've done with the testcase before but it's indeed
the case that relaxing nested cycle things exposes "interesting" paths in
vectorizable_reduction. One of my goals is to split that out, but I'm doing
baby steps in this code...
