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