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