------- Comment #24 from ubizjak at gmail dot com  2008-02-07 12:39 -------
It happens that we already have specialization to detect reduction in
rewrite_expr_tree:

--cut here--
     The alternative we try is to see if this is a destructive
     update style statement, which is like:
     b = phi (a, ...)
     a = c + b;
     In that case, we want to use the destructive update form to
     expose the possible vectorizer sum reduction opportunity.
     In that case, the third operand will be the phi node.
--cut here--

We have analysed operands in working and failed case:

(working):

+++ OP1: D.2002_7
op1 rank: 327681
->not phi for stmt
+++ OP2: i_18
op2 rank: 327680
not phi for stmt
+++ OP3: s_17
op3 rank: 327680
 phi for stmt

(failed):
+++ OP1: D.2020_7
op1 rank: 327681
->not phi for stmt
+++ OP2: s_18
op2 rank: 327680
 phi for stmt
+++ OP3: i_17
op3 rank: 327680
not phi for stmt

So, according to this data, following patch should (IMO) solve this mistery:

Index: tree-ssa-reassoc.c
===================================================================
--- tree-ssa-reassoc.c  (revision 132166)
+++ tree-ssa-reassoc.c  (working copy)
@@ -857,6 +857,18 @@ rewrite_expr_tree (tree stmt, unsigned i
          oe1->op = temp.op;
          oe1->rank= temp.rank;
        }
+      else if ((oe1->rank == oe3->rank
+               && oe2->rank != oe3->rank)
+              || (is_phi_for_stmt (stmt, oe2->op)
+                  && !is_phi_for_stmt (stmt, oe1->op)
+                  && !is_phi_for_stmt (stmt, oe3->op)))
+       {
+         struct operand_entry temp = *oe2;
+         oe2->op = oe1->op;
+         oe2->rank = oe1->rank;
+         oe1->op = temp.op;
+         oe1->rank= temp.rank;
+       }
     }

   /* The final recursion case for this function is that you have


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085

Reply via email to