Re: Bug 14562 : copyrename & PRE

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2004-03-15 at 14:59, Daniel Berlin wrote:

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

Yeah, that does seem to fix it. We aren't going to run into similar
problems anywhere else are we? I see other places where names_match_p()
is used that its not clear to me won't result in similar things. but
then, i dont know PRE very well.

THis also showed one of the potential pitfalls of copyrenaming. In this
particular case, it worked out worse for us because there were 2 k's
live in the loop dependant on each other, so we ended up with an extra
copy due to SSA->normal:
<L8>:;
  k.22<D1133> = k.21<D1132>;
  k.21<D1132> = k<D1063>;
  k<D1063> = k.22<D1133>;
  goto <bb 1> (<L0>);

instead of the original:

<L8>:;
  k<D1063> = T.1<D1071>;
  T.1<D1071> = T.20<D1131>;
  goto <bb 1> (<L0>);

blah. Well, we win more than we lose. 

I was wondering if I ought to stash away the "original" variable, and
then undo the copyrename if it is found to be unprofitable during
SSA->normal. Determining that its unprofitable is the trick now isn't
it. Hmm. perhaps its unlikely to be profitable if it results in more
than one PHI node the same variable as a RESULT... that should almost
always cause a new temproary to be created anyway.  Perhaps I'll fool
with that for a bit.

Anyway, yeah, it looks like that the PRE problem in this bug.


Andrew