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

[Jason Merrill <jason at redhat dot com>]

On Mon, 17 Mar 2003 13:29:55 -0700, law at redhat dot com wrote:

> 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.

Yes, we've all agreed in the past that this needs to happen at some point.
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.

>   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.

In C++, the second operand is always safe for reevaluation, since this only
occurs for compiler-generated destructor calls.

>   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.

Yep.

>   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.

Yep.

Jason