------- Additional Comments From law at redhat dot com 2004-12-10 20:00 -------
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Fri, 2004-12-10 at 19:08 +0000, kazu at cs dot umass dot edu wrote:
> ------- 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.
BTW, I may have a nice clean way to deal with this problem which doesn't
depend on us not walking the SSA_NAME_VALUE chain.
I'm looking into it 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.
