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

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

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