Re: [tree-ssa] Out of SSA status and issues

[Andrew MacLeod <amacleod at redhat dot com>]

On Tue, 2003-05-13 at 09:05, Diego Novillo wrote:
> On Tue, 2003-05-13 at 08:50, Andrew MacLeod wrote:
> > On Tue, 2003-05-13 at 08:42, Diego Novillo wrote:
> > > On Tue, 2003-05-13 at 05:07, Michael Matz wrote:
> > > 
> > > > An indirect reference is not a copy.  I don't know if tree-ssa thinks it
> > > > is, but it definitely shouldn't.
> > > > 
> > > Why?
> > > 
> > >      1. foo()
> > >      2. {
> > >      3.   int i, *p;
> > >      4. 
> > >      5.   p = malloc();
> > >      6.   i = *p;
> > >      7.   return i + 9;
> > >      8. }
> > > 
> > > I see nothing wrong in replacing 'i + 9' with '*p + 9'.  It would
> > > probably not be efficient, but I can't see it being wrong.
> > > 
> > > Not that tree-ssa will do anything with this code, the default
> > > type-based aliasing is too conservative, but PTA may disambiguate this.
> > 
> > There is nothing wrong with it, as long as you know for sure that *p
> > hasn't changed between 'i = *p' and 'i+9'. Copyprop doesnt look for
> > that. All it does is says 'i = *p', I can replace all occurences of i
> > with *p...
> > 

> 
>      1. foo()
>      2. {
>      3.   int *p;
>      4. 
>      5.   p_1 = malloc();
>      6.   p_4 = malloc();
>      7.   return *(p_1)_3 + 9;
>      8. }
> 
> Will the coalescer DTRT here?  Yes, it's a silly transformation, but I'm
> wondering if we don't have a bigger problem here.  I've been toying with

Sure, the coalescer will handle this easily. p_1 and p_4 conflict, so
they will get assigned something like:

p = malloc ()
p.33 = malloc()
return *p + 9


Doesn't make the copy-prop example right tho. If you take the original
case, and use the new format, you'd get:

      #   (*T.6_12)_13 = VDEF <(*T.6)_7>;
      T.6_12 = T.2_8 + T.5_11;

      #   VUSE <T.6_12>;
      i_14 = (*T.6_12)_13       <<<--- This is an issue.... 

      #   (*T.6_12)_22 = VDEF <(*T.6_12)_13>      
      #   VUSE <T.6_12>
      *T.6_12 = 30;
    };
  #   i_1 = PHI <i_6(0), (*T.6_12)_13(1)>;
 

Since the point itself never changes (just the memory), It would still
be written out the same way, and be wrong.

The stmt I flagged with "This is an issue", IMHO should actually be:
  i_14 = *T.6_12

I don't think it should have the _13. And of course, the VUSE shouldn't
be there since T.6_12 is now a real use. In fact, the aliased variable
should be a VUSE... so I think it ought to look like:

   #   VUSE <(*T.6_12)_13>
   i_14 = *T.6_12

I think that is consistant..... Virtual variables used for aliasing,
real variables used for code.

Andrew

> the idea of not bothering with renaming INDIRECT_REFs *at all*.  We
> certainly get little benefit from it because they are often aliased and
> it really is somewhat painful to deal with them.
> 

Well, renaming of indirect refs serves a different purpose.. we dont use
them when we are rewriting out of SSA form, but I suspect anyone who
tries to manipulate loads and stores is going to want them, because they
effectively give versions to loads and stores, allowing you to use SSA
on memory references... 

But I could be imagining things :-)

The above exmaple seems to make it pretty clear that the value of
(*T.6_12) is different when we set *T.6_12 = 30.  Perhaps there is a
better way.   You simply cannot "use" (*T.6_12)_13 any more, because the
memory it refers to has now changed... 

Whats PRE think of all this?

Andrew.