[PATCH] Fix PR33340, SSA corruption due to FRE

Daniel Berlin dberlin@dberlin.org
Sat Sep 8 22:54:00 GMT 2007


On 9/8/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> On 9/8/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> > On 9/7/07, Richard Guenther <rguenther@suse.de> wrote:
> > >
> > > FRE replaces a load by a SSA_NAME that occurs in an abnormal PHI.
> > > Fixed by not value-numbering anything as such SSA_NAME.
> > >
> > > Danny, does this make sense?
> > >
> >
> > Well, it does have the value of the abnormal ssa name.  It is simply
> > the case that we can't do any replacements with that ssa name.
> >
> > Thus, i'd rather block replacement than value numbering.
>
> I thought about this as well, but for
>
>   b_2 = a_1(ab);
>   c_3 = b_2;
>
> we would then value number c_3 as a_1(ab) and prevent FRE of things
> involving b_2 as well as a_1(ab).  Which is what we see in the testcase
> for the PR.

No it wouldn't, since PRE uses the values, and we could tell it not to
use that leader for replacement purposes.  It would then simply take
the next leader.

Instead, we have hacks all over the place to try to avoid value
numbering things to abnormal SSA names which doesn't work out so well.

>
>   tmp_4 = a_2(ab);
>   store = tmp_4;
>   ...
>   x_2 = store;
>
> with the patch we replace the load by tmp_4, but if we value number tmp_4
> as a_2(ab) we would try to replace it by a_2(ab) instead and thus reject it.
>
> ?
You can make it replace it with tmp_4 as well.
It will generate a value handle as a leader for the value itself, and
just tell it not to add a_2 as an expression that represents it.  It
should then simply choose tmp_4.

>
> Thanks,
> Richard.
>



More information about the Gcc-patches mailing list