Re: [tree-ssa] C++ CFG issue

[law at redhat dot com]

In message <wvly93dzpj7 dot fsf at prospero dot boston dot redhat dot com>, Jason Merrill writes:
 >> Conceptually it seems to me the way to go is to convert/lower the
 >> TRY_FINALLY_EXPR into a TRY_CATCH_EXPR.
 >
 >Yes, we've all agreed in the past that this needs to happen at some point.
I must have missed/ignored that :-)  Good to know, I'll see if I can find
any references to review.

 >The only question is when.  It has seemed to me that it makes sense to do
 >this lowering later in optimization so that we know more about the CFG.
Timing is another can-o-worms :(

Having a CFG (even if it's somewhat inaccurate) helps with this kind of
lowering in that you can find exit edges from a subgraph easier.  But
(of course) the stuff we're talking about can add new blocks and edges
to the CFG meaning we have to do on-the-fly updates or rebuild after
our insertions.  

 >>   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.
 >
 >This is what we do currently.  I think it makes more sense to move the
 >cleanups to the edge destination rather than the source; for one thing,
 >there will be no more jump targets than jumps.
That can't work unless you know that the edge destination is only reachable
from one TRY_CATCH_EXPR.   What we *really* want is to insert this code
on the edge itself, leaving it to the edge insertion code to determine
if it belongs in the caller, callee or in a new block.

The problem is I don't think our current edge insertion code is really
prepared to deal with insertion of an arbitrary subtree on an edge.


 >In C++, the second operand is always safe for reevaluation, since this only
 >occurs for compiler-generated destructor calls.
That's good to know -- even if it's not a general property we want to
rely on, I may rely upon that early in the implementation.  Thanks.

It sounds like I'm at least on the right track.  I'll see where/when it's
going to make the most sense to lower TRY_FINALLY_EXPR into TRY_CATCH_EXPR.

Jeff