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.

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.

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.


Thanks.  Diego.


Index: tree-vect-transform.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-vect-transform.c,v
retrieving revision 2.10
diff -d -u -p -r2.10 tree-vect-transform.c
--- tree-vect-transform.c       9 Apr 2005 01:37:27 -0000       2.10
+++ tree-vect-transform.c       10 Apr 2005 03:20:33 -0000
@@ -855,8 +855,8 @@ vectorizable_store (tree stmt, block_stm
   enum machine_mode vec_mode;
   tree dummy;
   enum dr_alignment_support alignment_support_cheme;
-  v_may_def_optype v_may_defs;
-  int nv_may_defs, i;
+  ssa_op_iter iter;
+  tree def;
 
   /* Is vectorizable store? */
 
@@ -918,15 +918,14 @@ vectorizable_store (tree stmt, block_stm
      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);
+  mark_new_vars_to_rename (*vec_stmt);
            
-  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;
-    }
+  /* The new vectorized statement will have better aliasing
+     information, so some of the virtual definitions of the old
+     statement will likely disappear from the IL.  Mark them to have
+     their SSA form updated.  */
+  FOR_EACH_SSA_TREE_OPERAND (def, stmt, iter, SSA_OP_VMAYDEF)
+    mark_sym_for_renaming (SSA_NAME_VAR (def));
 
   return true;
 }
Index: testsuite/gcc.dg/vect/20050409-1.c
===================================================================
RCS file: testsuite/gcc.dg/vect/20050409-1.c
diff -N testsuite/gcc.dg/vect/20050409-1.c
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ testsuite/gcc.dg/vect/20050409-1.c  10 Apr 2005 03:20:35 -0000
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_float } */
+
+typedef char achar __attribute__ ((__aligned__(16)));
+int main1 ()
+{
+  struct {
+    achar *p;
+    achar *q;
+  } s;
+  int i;
+  achar x[16];
+  achar cb[16];
+  s.p = x;
+  i = 0;
+  do
+    {
+      s.p[i] = cb[i];
+      i++;
+    } while (i < 16);
+
+  if (s.p[0])
+    abort ();
+}

Reply via email to