Re: Semi-Latent Bug in tree vectorizer

[Jeffrey A Law <law at redhat dot com>]

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