Re: [tree-ssa] unSSA questions and missing reference.

[law at redhat dot com]

In message <871y1g3dzl dot fsf at petteflet dot ntlworld dot com>, Jan Vroonhof writes:
 >Unless I am mistaken treessa.c implements the semi-pruned form
 >introduced therein.
Not exactly.  tree-ssa.c will select fully-pruned or semi-pruned based on
some heuristics meant to provide better overall performance and keep
PHI node insertion from blowing up.

 >Secondly, are there any non-obvious reasons why the unssa phase has
 >been left incomplete, i.e. Are there subtle gcc specific reasons why
 >introducing the appropriate temporaries is hard, or has it simply been
 >a lack of time? Is the current back-end able to coalesce the
 >temporaries where possible? The few papers and books I have looked at
 >all assume a coalescing graph-colouring register allocator will take
 >care of that.
We just haven't gotten to it yet.  I was hoping to get to it a while ago,
but I've instead been dealing with some serious performance issues in the
existing code, random bugs and the like.  Diego seems to be getting close
to looking at un-ssa pass.  Clearly un-ssa is the single biggest hunk of
infrastructure we're missing.


 >Which algorithm do you envision being used for the unSSA phase?
 >
 >1. Edge-split the SSA-form and then insert temporaries in each predecessor.
 >2. The more complex algorithm introduced in the above paper that also
 >works on critical edges. Briggs e.a. seem to not want to create new edges
 >because they do the unSSA at a very late stage in the compilation.
 >However that argument doesn't seem apply to treessa.
 >3. Something else. As I said I am not exactly widely read in this
 >area.
Unsure at this point.

jeff