Re: Bug 14562 : copyrename & PRE

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2004-03-15 at 13:27, Daniel Berlin wrote:
> 
> 

> 
> Before the transformation, you have:
>   T.6<D1061>_13 = k<D1047>_26 * 4;
> ...
>   T.2<D1056>_42 = T.1<D1055>_41 * 4;
> 
> one lexical occurrence of k * 4, one lexical occurrence of T.1 * 4.
> 
> after, you have
> <L0>:;
>   T.6<D1061>_13 = k<D1047>_26 * 4;
> ...
>   T.2<D1056>_42 = k<D1047>_41 * 4;
> 
> two lexical occurrences of k * 4.
> 

even tho k_41 has absolutely nothing to do with the 'k' in k_26 eh.

> > whats the 'class' thing?
> 
> ESSA version.
> 
> >There seems to be a class 1 use of k_29 that
> > doesnt exist when its T.1_29.
> That's my point.
> PRE sees another lexical occurrence when you give the variables new names.
> 
> This is one of the problems with the current SSAPRE algorithm, and most
> PRE algorithms, and the reason there is work to unify global value
> numbering and PRE - many more optimization opportunities.
> 
>  >
> > -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...
> >
> So does -fno-tree-dominator-opts, etc.
> :)
> 
> 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 :-)

Thanks.

Andrew