This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Bug 14562 : copyrename & PRE
On Mon, 2004-03-15 at 13:52, Daniel Berlin wrote:
>
>
> On Mon, 15 Mar 2004, Andrew MacLeod wrote:
>
>
> 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.
Perhaps its because k_29 is defined in block 0, that PRE somehows thinks
thats the reaching definition of 'k', but PRE will calculate this the
first time as pretmp.18_48, which is defined as pretmp.18_50 on the
initial path, which has a value of
pretmp.18_50 = k_29 * 4
which is actually:
pretmp.18_50 = (k_2 - h_5) * 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?
Andrew
Coming in from