On Mon, Jun 18, 2018 at 4:54 PM Richard Sandiford <richard.sandif...@arm.com> wrote: > > vectorizable_call stubs out the original scalar statement with > a dummy assignment to the same lhs, so that we don't leave any bogus > scalar calls around. If the call is actually a pattern statement, > the code rightly took the lhs of the original bb statement: > > if (is_pattern_stmt_p (stmt_info)) > lhs = gimple_call_lhs (STMT_VINFO_RELATED_STMT (stmt_info)); > else > lhs = gimple_call_lhs (stmt); > > But it then associated the new statement with the stmt_vec_info of the > pattern statement rather than the bb statement, which meant we had two > stmt_vec_infos assigning to the same lhs. This seems to be latent at > the moment but caused problems further into the series. > > Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
OK. Richard. > Richard > > > 2018-06-18 Richard Sandiford <richard.sandif...@arm.com> > > gcc/ > * tree-vect-stmts.c (vectorizable_call): Make sure that we > use the stmt_vec_info of the original bb statement for the > new zero assignment, even if the call is part of a pattern. > > Index: gcc/tree-vect-stmts.c > =================================================================== > --- gcc/tree-vect-stmts.c 2018-06-18 15:24:21.005379580 +0100 > +++ gcc/tree-vect-stmts.c 2018-06-18 15:24:35.165254737 +0100 > @@ -3611,13 +3611,12 @@ vectorizable_call (gimple *gs, gimple_st > > type = TREE_TYPE (scalar_dest); > if (is_pattern_stmt_p (stmt_info)) > - lhs = gimple_call_lhs (STMT_VINFO_RELATED_STMT (stmt_info)); > - else > - lhs = gimple_call_lhs (stmt); > + stmt_info = vinfo_for_stmt (STMT_VINFO_RELATED_STMT (stmt_info)); > + lhs = gimple_get_lhs (stmt_info->stmt); > > new_stmt = gimple_build_assign (lhs, build_zero_cst (type)); > set_vinfo_for_stmt (new_stmt, stmt_info); > - set_vinfo_for_stmt (stmt, NULL); > + set_vinfo_for_stmt (stmt_info->stmt, NULL); > STMT_VINFO_STMT (stmt_info) = new_stmt; > gsi_replace (gsi, new_stmt, false); >
