https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 1 Feb 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98848 > > --- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > So what about punting if the lhs of the possible over_widen pattern is a PHI > on > loop header? That would be STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def, elsewhere we now use vect_reassociating_reduction_p, not sure if that woudl apply here, too. > --- gcc/tree-vect-patterns.c.jj 2021-01-04 10:25:38.650235896 +0100 > +++ gcc/tree-vect-patterns.c 2021-02-01 10:13:51.755008757 +0100 > @@ -1579,6 +1579,20 @@ vect_recog_over_widening_pattern (vec_in > tree type = TREE_TYPE (lhs); > tree_code code = gimple_assign_rhs_code (last_stmt); > > + /* Punt if lhs might be used in a reduction. */ > + if (loop_vec_info loop_vinfo = dyn_cast<loop_vec_info> (vinfo)) > + { > + use_operand_p use_p; > + imm_use_iterator iter; > + FOR_EACH_IMM_USE_FAST (use_p, iter, lhs) > + { > + gimple *use_stmt = USE_STMT (use_p); > + if (gimple_code (use_stmt) == GIMPLE_PHI > + && gimple_bb (use_stmt) == LOOP_VINFO_LOOP (loop_vinfo)->header) > + return NULL; > + } > + } > + > /* Keep the first operand of a COND_EXPR as-is: only the other two > operands are interesting. */ > unsigned int first_op = (code == COND_EXPR ? 2 : 1); > > doesn't regress any vect.exp=*over-widen* tests and let's this testcase be > vectorized. > >
