This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

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.

So in Diego's view

Copy propagating

   a = (*p)_1;
   (*p)_2 = b;
   .
   .
   .
   PHI(..,a,..)

into 

   (void)0;
   (*p)_2 = b;
   .
   .
   .
   PHI(..,(*p)_1,..)

is fine (assuming non-volatile of course), as UNSSA will notice the
overlapping live ranges and assign (*p)_1 and (*p)_2 to different
partitions, create a new temporary for (*p)_1 and voila: it gets rewritten as

   t = *p;   // (*p)_1 is in the same partition as *p on entry
   .
   .
   .
  (void)0;
   *p = b;   // (*p)_2 is the same partition *p on exit
   .
   .
   .
   PHI(..,t,..)

In fact if we can prove that the memory pointed to by p is not live on
access we have potentially eliminated memory from the equation
altogether (at the expense of memory pressure).

So the two phases make SSA do a bit of PRE as a side effect.  So
AFAICS the main problem is that copyprop and the toSSA on the one hand
and UNSSA on the other hand have a different view of the meaning of
the treessa representation. So whether it is a bug in copyprop or a
weakness in UNSSA simply depends on your point of view.

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.

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.

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).

I hope these ramblings from a beginner didn't just confuse things even
more.

Jan

Footnotes: 
[1]  In fact I am wondering whether SSA of expressions (as per SSAPRE) and SSA with one unique temporary per expression (as per Morgan) aren't in fact the same thing.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]