Bug 14562 : copyrename & PRE

[Daniel Berlin]

> >
>
> >
> > IE copyrename should improve PRE effectiveness in a lot of cases, at least
> > until we have GVN-PRE.
> >
> Yeah, I noticed in the new version it made things better. TOo bad we're
> doing something wrong :-)
>
> > > > I looked at the code PRE generates for optimizing that expression by eye,
> > > > and it looks okay to me.
> > >
> > > OK, I'll see if I can see anyone else doing something bad then. someone
> > > is getting confused :-)
> >
> > :P
> > It still could be PRE, and i'm just missing it.
> > But i traced the replacements it made by hand, and looked at the resulting
> > code, and it looks like it should be okay.
> >
> OK, I think I have it.
>
> THe incoming definition is:
>
>
>   k<D1063>_29 = k<D1063>_2 - h<D1062>_5;
>   T.2<D1072>_30 = k<D1063>_29 * 4;
>  <...>
>   # T.3<D1073>_23 = PHI <T.3<D1073>_31(0), T.3<D1073>_43(1)>;
>   # k<D1063>_1 = PHI <k<D1063>_29(0), k<D1063>_41(1)>;
>   # k<D1063>_26 = PHI <k<D1063>_2(0), k<D1063>_1(1)>;
> <L0>:;
>   T.6<D1077>_13 = k<D1063>_26 * 4;
>
>
>
> The problem is T.6_13... PRE changes this to:
>
>   k<D1063>_29 = k<D1063>_2 - h<D1062>_5;
>   pretmp.18<D1129>_50 = k<D1063>_29 * 4;
>   T.2<D1072>_30 = pretmp.18<D1129>_50;
>  <...>
>   # T.3<D1073>_23 = PHI <T.3<D1073>_31(3), T.3<D1073>_43(6)>;
>   # k<D1063>_1 = PHI <k<D1063>_29(3), k<D1063>_41(6)>;
>   # k<D1063>_26 = PHI <k<D1063>_2(3), k<D1063>_1(6)>;
>   # pretmp.18<D1129>_48 = PHI <pretmp.18<D1129>_50(3),
> pretmp.18<D1129>_51(6)>;
>   # pretmp.19<D1130>_52 = PHI <pretmp.19<D1130>_54(3),
> pretmp.19<D1130>_55(6)>;
> <L0>:;
>   T.6<D1077>_13 = pretmp.18<D1129>_48;
>
> I think the problem is the entry into the loop from block 0 (or BB 3
> iafter PRE)
>
> the original stmt:
> T.6_13 = k<D1063>_26 * 4;
>
> k_26 is defined as k_2 coming in from block 0 in the original program,
> so T.6_13 would be k_2 * 4.

> So we are getting the wrong value the first time into the loop. we're
> using the wrong k...
>
> Andrew
>
> Am I reading that correctly?

Probably.
That means we didn't translate through the phi properly.
I bet we don't expect two phis for the same variable name in the loop
somewhere.
THat was actually my gut feeling when i first saw what you were doing to
k, but i didn't want to say it and look stupid.
Not that it helped :).

Ah.
Search for

    if (names_match_p (PHI_RESULT (phi), v))

in tree-ssa-pre.c
This is probably the cause.

Try if (PHI_RESULT (phi) == v) instead.

I bet we pick the wrong phi to translate through.
It looked right because of all the damn ks :)