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

[Andrew MacLeod <amacleod at redhat dot com>]

On Tue, 2003-05-13 at 13:29, Jan Vroonhof wrote:
> 
> I have a distinct feeling you guys are talking past each other. Feel
> free to flame me to bits if I am missing to point.
> 

Yes, we sorted it out eventually :-)

> If I understand things correctly:
> 
> Diego seems to think that in the tree-ssa IR memory locations (INDIRECT_REFs)
> are treated on equal footing with normal temporaries. (I believe this
> is partly what in the Morgan book is called tags). SSA renaming will
> take care of aliasing issues etc. 
> Whereas you have the more typical view that memory loads are normal
> expressions.
> 
> In Diego's definition then loads are simply a copy and they can be
> propagated. I would think that also would mean that the UNSSA phase
> also has to treat INDIRECT_REFs as temporaries and do proper live
> range analysis on them.
> 

The confusing part is that only objects which have no alaises that were
treated that way. They were represented by a Virtual DEF, and by real
USES. As soon as that same dereference was alaised with something, they
became virtual USES, and the real USES became dereference of the actual
pointer. 

When the INDIRECT_REF variables were treated as real uses, SSA->Normal
in that case requires a little twisting. It had to replace the
INDIRECT_REF temporary with a dereference of the correct pointer.
 
  The inconsistancy is what was bothering me. (Not to mention the extra
work :-)



> 
> Whether this partitioning of memory locations actually is doable I do
> not know. For instance I would think that the partitioner needs to
> make sure that there are partitions for (*p)_onentry and (*p)_onexit
> (if the memory is live) and assign those *p as a location otherwise
> the loads and stores will never happen and that is wrong. For
> non-volatiles one can remove all but 1-load and 1-store.

Part of the problem was that there was never a real definition of the
INDIRECT_REF variable. It was a virtual definition when the value of the
pointer was set.

> 
> However, Not treating this as a PRE problem might have the tendency to
> move the load towards entry and the store towards exit too much,
> increasing register pressure and putting loads and stores in codepaths
> that previously didn't have them. This seems to suggest leaving it to PRE.
> 

I think this is where we are finally headed :-)

> On the other hand the SSAPRE as far as i understand (which is very
> little) simply would SSA rename it as an expression and then UNSSA
> it doing essentially the same thing.[1] So in the end the copy versus
> expression distinction is rahter weak (when SSAPRE is enabled).

By PRE would put hings into real temporaries, and then UNSSA doesn't
have to go looking for special cases... it just does a direct
partitioning and rewrite.

Andrew