On Thu, Dec 15, 2011 at 08:32:26AM +0200, Ira Rosen wrote:
> > + cond = build2 (LT_EXPR, boolean_type_node, oprnd0, build_int_cst
> > (itype, 0));
> > + gsi = gsi_for_stmt (last_stmt);
> > + if (rhs_code == TRUNC_DIV_EXPR)
> > + {
> > + tree var = vect_recog_temp_ssa_var (itype, NULL);
> > + def_stmt
> > + = gimple_build_assign_with_ops3 (COND_EXPR, var, cond,
> > + fold_build2 (MINUS_EXPR, itype,
> > + oprnd1,
> > + build_int_cst (itype,
> > + 1)),
> > + build_int_cst (itype, 0));
> > + gsi_insert_before (&gsi, def_stmt, GSI_SAME_STMT);
>
> Hmm, you are inserting pattern stmts. This was causing some mess in the
> past as explained here
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00801.html. Maybe you can use
> STMT_VINFO_PATTERN_DEF_STMT to keep a chain of def_stmts?
Yes, I know, but STMT_VINFO_PATTERN_DEF_STMT contains a single gimple stmt,
while I need here several def stmts. I think it can't cause problems in
this case, the stmts will be easily DCEd. We could turn
STMT_VINFO_PATTERN_DEF_STMT into a gimple_seq perhaps, will try that and see
how invasive that would be.
Jakub
