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

[law at redhat dot com]

In message <20030317214606 dot GD14350 at redhat dot com>, Richard Henderson writes:
 >On Mon, Mar 17, 2003 at 02:27:46PM -0700, law at redhat dot com wrote:
 >> Understood.  This brings another issue to the surface.  Namely, is except.c
 >> going to be able to decipher this stuff.   Ugh.
 >
 >Yes, because except.c doesn't "decipher" anything.  It is
 >explicitly given a set of calls to expand_eh_region_start
 >and friends.
except.c would need to decipher any changes we make, particularly
to TRY_FINALLY_EXPRs.

except.c would need to know about the special handling of copied
CATCH_BLOCKs at the exit points of the TRY_BLOCK if we go that
direction.

If we go the route of vectoring all the exit points from the TRY block
into the CATCH block, then have the CATCH block jump to the ultimate target,
then we seem to confuse the hell out of except.c as well causing it to
leave RESX expressions in the RTL chain.

In fact, the interactions between the simplified TRY_FINALLY_EXPRs
and what except.c expects to see are the biggest problem I've run
into so far.


 >> 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.
 >
 >The struct eh_region tree should map 1-1 with the tree structure
 >that you're looking at...
True, but there's little in the way of figuring out how that corresponds
to the RTL we generate or the flow graph we build, or even good mappings
in terms of how struct eh_region is built.  

Jeff