On Sat, 2005-04-09 at 23:23 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
>
> > When we vectorize the store we copy the virtual operands from the
> > original statement to the new vectorized statement via this code:
> >
> > /* Copy the V_MAY_DEFS representing the aliasing of the original array
> > element's definition to the vector's definition then update the
> > defining statement. The original is being deleted so the same
> > SSA_NAMEs can be used. */
> > copy_virtual_operands (*vec_stmt, stmt);
> > v_may_defs = STMT_V_MAY_DEF_OPS (*vec_stmt);
> > nv_may_defs = NUM_V_MAY_DEFS (v_may_defs);
> >
> > for (i = 0; i < nv_may_defs; i++)
> > {
> > tree ssa_name = V_MAY_DEF_RESULT (v_may_defs, i);
> > SSA_NAME_DEF_STMT (ssa_name) = *vec_stmt;
> > }
> >
> > This is safe if and only if the the operand scanning code will compute
> > the same V_MAY_DEFS for the original scalar statement and the new
> > vectorized statement. ie, *D.1470 must have the same aliasing
> > properties as *vect_px.17.
> >
> Right. Both the vectorizer and ivopts have the side-effect of
> refining aliasing information. Therefore, blindly copying
> virtual operands is not correct.
OK. I can live with that.
> Could you try this patch? It fixes your test case and doesn't
> produce new regressions in the vectorizer tests. It's not
> bootstrapped nor tested otherwise.
I've got some other stuff spinning right now, so it'll be later
today before I can do anything significant with it.
> The idea is that we should treat both the vectorized statement
> and the old statement separately. The virtual defs from the old
> statement are going away and the new one is getting brand new
> symbols exposed. That's why we mark them separately.
Understood.
FWIW, you don't need a new testcase -- the one I posted is just
a cut down version of one already in the testsuite.
jeff
