------- 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