[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

[kazu at cs dot umass dot edu]

------- Additional Comments From kazu at cs dot umass dot edu  2004-12-10 00:28 -------
Subject: Re:  [4.0 regression] loop
 miscompilation at -O1 (-ftree-ch)

Hi Jeff,

> I believe your fast-path check is effectively equivalent to
> 
> if ((e->flags & EDGE_DFS_BACK) == 0)

I see that we call mark_dfs_back_edges at the beginning of
tree_ssa_dominator_optimize.  Now, after we call cleanup_tree_cfg, can
we trust EDGE_DFS_BACK?

No pass in cleanup_tree_cfg really adds an edge.  All we do is either
remove or redirect edges, so the real question is "Do we ever get a
new back edge without a EDGE_DFS_BACK mark as a result of edge
redirection?"  If we have a forwarder block BB flowing into the loop
header, BB's sole successor edge may be marked with a EDGE_DFS_BACK,
but its incoming edges may not be.  When we call
cleanup_forwarder_blocks, the edges that will survive are BB's
incoming edges, not the edge going out of BB, so we may end up with a
back edge without a EDGE_DFS_BACK mark.

I think we should call mark_dfs_back_edges at the beginning of every
iteration or simply use dominated_by_p, which is not too expensive -
only a couple of "if" statements, assuming the dominator infomatino is
available.

Kazu Hirata


-- 


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