This is the mail archive of the gcc-patches@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: [patch] Lno branch merge part 3 -- ssa form updatingimprovements


On Tue, 2004-06-15 at 10:02, Zdenek Dvorak wrote:

> you may use rewrite_ssa_into_ssa for this, as well as incremental
> updating and often in an easier way.  So I don't really see what you
> protest against (so far you have provided no reason except for your
> personal dislike of the concept, sorry).
> 
The approach you took is too heavy handed.  It is duplicating fields
from var_ann_d, replicating most of the SSA renamer, treating SSA_NAMEs
as not really unique definitions and forcing another scan over the IL
when all the optimization is doing are just local changes.

Let me go through what I think is the problem that you are trying to
solve.  We have some loop:

	|
	v
   +->START
   |	|
   |	+--------> END
   |	|
   |	v
   |  BODY
   |	|
   +----+

which we want to convert into

	|
	v
      START
   	|
   	+--------> END
   	|           ^
   	v           |
   +->BODY          |
   |	|           |
   |	v           |
   |  START' -------+
   |    |
   +----+

Is that correct?

I'm assuming that we will have built a loop-closed form by inserting
EXIT_COPY nodes at END (new tree nodes) before going into SSA.  I could
give you a patch for this in LNO soonish.

For this particular problem, we could do the following algorithm:

     1. Replicate all the PHI nodes in START in the first block of
        BODY.  Remove the SSA_NAMEs from all the operands and make new
        SSA_NAMEs for the LHS of each node.
     2. Delete the back edge BODY->START.  That will convert the PHI
        nodes into assignments.
     3. Create START' and attach it as shown above.
     4. Copy statements from START in START'.  Create new SSA_NAMEs for
        every assignment found.
     5. Do a dominator walk of loop body beginning at START keeping
        track of current definitions and repairing USE/V_USE operands
        that don't match up.

We need to wrap step #2 in a generic API call, if we don't have it
already.  Step #5 could also be wrapped in a generic API.


Thoughts?  Diego.


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