[tree-ssa] Out of SSA status and issues

[Diego Novillo]

On Tue, 2003-05-13 at 08:49, Andrew MacLeod wrote:
> On Tue, 2003-05-13 at 08:33, Diego Novillo wrote:
> > On Mon, 2003-05-12 at 14:45, Andrew MacLeod wrote:
> > 
> > > ie it would look something like this hacked up example:
> > >  
> > >       #   (*T.6)_13 = VDEF <(*T.6)_7>;
> > >       T.6_12 = T.2_8 + T.5_11;
> > > 
> > >       #   VUSE <T.6_12>;
> > >       i_14 = (*T.6)_13
> > > 
> > >       #   (*T.6)_22 = VDEF <(*T.6)_13>      
> > >       #   VUSE <T.6_12>
> > >       *T.6 = 30;
> > >     };
> > >   #   i_1 = PHI <i_6(0), (*T.6)_13(1)>;
> > > 
> > > Or is there a reason that copyprop would never happen?
> > >
> > Correctness wise?  No, there's no reason.  We can safely do the
> > propagation in this case.
> > 
> > But I wouldn't think it's efficient.  Pointer dereferences are bound to
> > be slower than a straight scalar reference.  The copy propagator in the
> > SSA renamer blocks propagation of INDIRECT_REF nodes.  The stand-alone
> > copy propagator should probably do the same.
> > 
> >
> but this code is rewritten into:
> 
>  T.6 = T.2 + T.5
>  i_14 = *T.6
> *T.6 = 30
>  i_1 = *T.6
> 
> Thats not the same meaning at all....
> 
Drat, I hadn't noticed that *T.6 was aliased.  Yes, in this case
copyprop is doing the wrong thing.  It shouldn't be propagating from
VDEFs into PHIs like that.  Sorry about that.

So, is it copyprop or the copy propagator in the SSA rename pass?  I
don't think the SSA renamer would do this because we specifically block
propagating dereferences.


Diego.