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