[tree-ssa] C++ CFG issue

[law at redhat dot com]

So I'm sitting here looking at how to deal with TRY_FINALLY_EXPR ann
I've got an interesting issue I'd like some feedback on.

As has been mentioned, there are clearly two approaches for dealing with
TRY_FINALLY_EXPR nodes.

The first involves copying the second operand to all the points where
the first operand jumps out of the subgraph.  The other would revector
all the exit paths from the first operand to the second operand.  In
that case the second operand would have to do an indirect jump or 
something similar to make sure that when we left the second operand 
that we went to the right place.

I suspect that we'll have to implement both (much like the tree->rtl
expanders already do).  Ugh.

It seems to me that we need to implement all this as part of the
gimplification process.  Otherwise we have a situation where the
function tree doesn't really match the CFG we need to build.  ie,
we can't just wire up edges in the CFG, we must update the underlying
tree structure as well.

Conceptually it seems to me the way to go is to convert/lower the
TRY_FINALLY_EXPR into a TRY_CATCH_EXPR.

  If the second operand is simple enough and safe for reevaluation,
  then a copy of the second operand would be inserted before any jumps
  out of the subtree in the first operand.

  If the second operand is ugly or not safe for reevaluation, then
  jumps in the first operand would be revectored to the second
  operand.  We'd also have to arrange to modify the second operand
  so that its last tree node was an indirect jump (or switch statement
  with jumps as its case nodes) so that the second transferred control
  to right target.

  We also change the code from TRY_FINALLY_EXPR to TRY_CATCH_EXPR.  That
  would cause the tree-cfg code to wire up any abnormal edges at call
  sites that may throw in the first operand to transfer control to the
  second operand.


Thoughts, comments or suggestions?

jeff