[Bug tree-optimization/19098] tree-ssa-dom.c has an "if" statement whose condition is probably wrong

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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