Fix phi backedge detection in backprop (PR85989)
This PR is a nasty wrong code bug due to my fluffing a test for a backedge in gimple-ssa-backprop.c. Backedges are supposed to be from definitions in the statement we're visiting to uses in statements that we haven't visited yet. However, the check failed to account for PHIs in the current block that had already been processed, so if two PHIs in the same block referenced each other, we'd treat both references as backedges. In more detail: The first phase of the pass goes through all statements in an arbitrary order, making optimistic assumptions about any statements that haven't been visited yet. The second phase then calculates a correct (supposedly maximal) fixed point. Although the first phase order is arbitrary in principle, we still use the CFG rpo to cut down on the backedges. This means that the only thing that's truly arbitrary is the order that we process the PHIs in a block. Any order should be OK and should eventually give the same results. But we have to follow whatever order we pick, and the pass wasn't doing that. 2018-06-01 Richard Sandiford <richard.sandiford@linaro.org> gcc/ PR tree-optimization/85989 * gimple-ssa-backprop.c (backprop::m_visited_phis): New member variable. (backprop::intersect_uses): Check it when deciding whether this is a backedge reference. (backprop::process_block): Add each phi to m_visited_phis after visiting it, then clear it at the end. gcc/testsuite/ PR tree-optimization/85989 * gcc.dg/torture/pr85989.c: New test. From-SVN: r261064
Showing
gcc/testsuite/gcc.dg/torture/pr85989.c
0 → 100644
Please
register
or
sign in
to comment