------- Additional Comments From law at redhat dot com 2004-12-23 18:29 ------- Subject: Re: New: tree-ssa-dom.c has an "if" statement whose condition is probably wrong
On Tue, 2004-12-21 at 05:59 +0000, kazu at cs dot umass dot edu wrote: > tree-ssa-dom.c has the following > > if (!e->flags & EDGE_DFS_BACK) > > which is always 0 because !e->flags is always 0 or 1, and > EDGE_DFS_BACK is 32. As it turns out simply changing it to if (!(e->flags & EDFS_DFS_BACK)) will introduce regressions. Why? Because we fail to thread jumps in some cases which causes us to give bogus uninitialized variable warnings in code like this: if (cond) var = whatever while (cond) use var The fundamental problem this code is trying to avoid is creating jumps into the middle of a loop (which would create an irreducible region). However, I _think_ there are cases where we can allow the jump to be threaded. ie, there are cases where threading the jump is just going to rotate the loop rather than creating a jump into the loop body. ie, in the case above threading the jump would effectively create if (cond) { do { use var } while (cond) } So the question becomes can we identify those cases where jump threading across a loop header is simply going to rotate the loop and if we only thread those cases do we avoid the bogus uninitialized variable warnings. I think the answer is we can do a trivial test to catch the majority of cases we care about. Given an edge E where E->dest is a loop header and E is not a backedge, we can safely thread through E->dest if E is the only incoming edge into E->dest which is not marked with EDGE_DFS_BACK. ie, E represents the only edge which enters the loop. If we redirect that edge to a point inside the loop, then all we have done is change the loop entry point. This could be extended to handle cases where we're threading all incoming non-loop edges to the same block within the loop, but I don't see a need to do that right now. That would require significantly more work in tree-ssa-threadupdate and tree-ssa-dom. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19098