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

[law at redhat dot com]

In message <wvlof49zoc1 dot fsf at prospero dot boston dot redhat dot com>, Jason Merrill writes:
 >On Mon, 17 Mar 2003 14:05:45 -0700, law at redhat dot com wrote:
 >
 >>  >>   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.
 >
 >You would need to split the destination label to deal with multiple
 >incoming edges, but I think that's a pretty standard code motion technique.
Which is precisely why we'd like to use edge insertions -- they deal with
critical edges, which are what cause most of the difficulties in this space.

 >> 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.
 >
 >One thing you'll need to deal with if you add the cleanup code before the
 >jump is fixup regions (search for fixup in except.c); throwing from the
 >cleanup should not run the cleanup again.
Understood.  This brings another issue to the surface.  Namely, is except.c
going to be able to decipher this stuff.   Ugh.


FWIW, I haven't found the code in except.c very useful, mostly because
it's not clear how most of that code maps back to what I'm seeing at the
tree level.  Maybe some of that clarity will happen as I get further into
the implementation of this stuff.

Jeff