Re: Bug 14562 : copyrename & PRE

[Daniel Berlin <dberlin at dberlin dot org>]

> >  People seemed to agree with this (Richard and Jeff, IIRC), i just never
> >  got around to it.
> >
>
> Yes, I agree it ought to be this way.
> >  Does copyrename make this no longer true somehow?
> Did you ever make adjustments when default_def() was introduced?

Not that i'm aware of :)
> We have
> a situation here where some versions of 'k' have default_dfef() set
> because they are the incoming default value, and are live on entry.

Ah.
This might be the problem then.

> Maybe... I dont think thats this problem. But maybe it is :-)

It's the only reason PRE would touch the PARM_DECL now and not touch it
before.

> >  This is the only place we special case PARM_DECL in all of PRE.
> >
>
> Well, dont you try to reconstruct expressions based on the base variable
> or something at some point?
We translate through PHIs, but this won't be affected by PARM_DECL at all.

>
> We have a case where we have a PARM_DECL 'k', and there are 2 PHI nodes
> in one block for K
> # k<D1063>_1 = PHI <k<D1063>_29(0), k<D1063>_41(1)>;
> # k<D1063>_26 = PHI <k<D1063>_2(0), k<D1063>_39(1)>;
>
> and PRE makes one of them go away... Maybe you ought to take a quick
> look at the test case, its not a very big one, and you understand PRE
> far better than I.

Sure.

> The only transformation difference that matters (I think :-), is that
> copyrename has renamed T.1_29 to be k_29.  It changed the base variable
> for version 29 to 'k'. And PRE decided it should do something to it, and
> appears to do something wrong.
>
> It probably wouldn't take long for you to see what wrong. Either its
> something I did about PARM_DECLs, or an assumption PRE is making, Im not
> sure which.

I'll check it out