------- Additional Comments From law at redhat dot com 2004-12-10 18:24 -------
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Fri, 2004-12-10 at 00:28 +0000, kazu at cs dot umass dot edu wrote:
> ------- 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.
Hmm, I think you're right.
> I think we should call mark_dfs_back_edges at the beginning of every
> iteration
That might be advisable -- we use EDGE_DFS_BACK to avoid creating
irreducible loops as a result of jump threading IIRC.
> or simply use dominated_by_p, which is not too expensive -
> only a couple of "if" statements, assuming the dominator infomatino is
> available.
EDGE_DFS_BACK would have been more efficient. But I don't think it's
100% safe right now.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
