Re: Bug 14562 : copyrename & PRE

[Andrew MacLeod <amacleod@redhat.com>]

On Mon, 2004-03-15 at 12:58, Daniel Berlin wrote:
> > >
> > > 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
> >
> 
> It looks like we have two occurrences of the expression with copyrename,
> and one without it.
> 
>  EUSE (k_29 * 4) [class:1 phiop:0 bb:1 ]
>  EUSE (k_29 * 4) [class:2 phiop:0 bb:1 ]
>  EUSE () [class:-1 phiop:1 bb:6 ]
>  EUSE () [class:-1 phiop:1 bb:5 ]
> 
> without copyrename:
> 
>  EUSE (T.1_29 * 4) [class:2 phiop:0 bb:1 ]
>  EUSE () [class:-1 phiop:1 bb:4 ]
>  EUSE () [class:-1 phiop:1 bb:3 ]
> 
> 
> PRE is not value based (right now, i'm working on a GVN-PRE algorithm), so
> this is why it picks it up when you have k, but not T (because in one case
> you have one k * 4 expression, and one t * 4 expression, and in the other
> case you have two k * 4 expressions)
> 
> The results of PRE look fine given the code in both cases (in one case,
> the expression we are looking at is modified in between the phi and the
> use, and in the other case, it isn't, because we are picking up the extra
> expression, and that's the one getting optimized).
> 
> Do you see something actually wrong with the code PRE is producing?
> 

No, I was wondering why it triggers. There shouldn't be any more uses of
k_29 than there were of T.1_29. copyrename simply replaces T.1_29 with
k_29. Why do you get two occurrences after the transformation?

whats the 'class' thing? There seems to be a class 1 use of k_29 that
doesnt exist when its T.1_29.

-fno-tree-pre makes it work, for what thats worth, so I figured it might
have something to do with the extra stuff PRE is doing...

Andrew