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]

Keeping the SSA form up-to-date


Over the last few weeks we have been discussing ways of keeping the SSA
form up-to-date after transformations that insert or remove
instructions, edges and what not.

There's two extreme approaches for updating the SSA form.  At one
extreme, we can take the whole program out of SSA and rename it back
in.  This is easy to maintain but has obvious compile-time implications
and forces the compiler to drop all the attributes that may have been
stored inside SSA names.

The other approach is to make sure that every change to the program is
done so that the SSA form is preserved and/or patched incrementally. 
The burden now is on each transformation to DTRT.  This has the
potential of making individual passes more complex, but it gives each
pass the opportunity to preserve and, maybe even improve, the attributes
the compiler has collected on each name.

We currently have a hybrid approach in between those two that takes a
subset of SSA names and patches them up to fix the SSA form on them
(rewrite_ssa_into_ssa).  There are currently  few users of this pass
(DOM and the loop-closed-ssa pass come to mind).

Since rewrite_ssa_into_ssa needs to tear down SSA information and build
new names, I would like to discourage using it as much as we can. 
Essentially, the mental model I would like to have is one of evaluating
which approach in the spectrum total rewrite -> incremental update is
better overall.

I don't think there is an easy answer that will be applicable to all
cases.  Some passes are relatively easy to implement using an
incremental approach.  But we may find transformations that are
sufficiently complex that will force us to give up and just re-rename
the function (or a subset).

Jeff is going to be evaluating the various approaches to the jump
threading bits.  I would like to ask the other users of
rewrite_ssa_into_ssa to do the same.  The evaluation involves the usual
factors: compile times and memory usage.  Quality of generated code
should not be an issue.  Although, I could see cases where we generate
worse code if rewrite_ssa_into_ssa doesn't schedule the re-computation
of aliasing and whatever other bits of information we may store in SSA
names.

I don't expect rewrite_ssa_into_ssa to be slow itself.  Rather, the
re-computation of other bits is what may slow us down.

Thoughts?  If someone has a universal solution that doesn't destroy the
SSA form and can be blindly used like the re-renamer, I'd love to hear
it.


Thanks.  Diego.


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