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

["kazu at cs dot umass dot edu" <gcc-bugzilla@gcc.gnu.org>]

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

Hi Jeff,

> Note that recording tmp_1 = next_2 isn't particularly good either since 
> tmp_1 really isn't equivalent to next_2.  It's equivalent to the
> previous valueof n next_2, which was next_3.  ugh.  Anyway, I'll verify
> that Kazu's patch handles this correctly.

I think so. :-)

What thread_across_edge is really trying to do is "What would these
statements in E->dest look like if they appeared at the end of
E->src?"  Then the question is reduced to whether each statement in
E->dest is translated correctly.  To do the translation, we use
SSA_NAME_VALUE, but note that we don't use it iteratively.  In other
words, given a SSA_NAME variable VAR, we don't do this

  while (TREE_CODE (var) == SSA_NAME
	 && SSA_NAME_VALUE (var) != NULL_TREE)
    var = SSA_NAME_VALUE (var);

because SSA_NAME_VALUE is supposed to be closed so that you won't need
to iterate.  So when we follow "copy-of" relation from tmp_1 to next_2
using SSA_NAME_VALUE, we don't follow next_2 to something else.

Note also that lookup_avail_expr does not translate the expression in
hash table using SSA_NAME_VALUE.  What we translate is the expression
that we look up.

p.s.
By the way, I am now wondering how many times we succeed in threading
a back edge.

Kazu Hirata


-- 


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.