PR 8805: EH vs. CFG

PR 8805: EH vs. CFG

[Mark Mitchell]

This test case ends up generating a function with huge number of
exception handlers.  Essentially, the function looks like:

  try {
    construct ();
    try { 
      construct ();
    } catch (...) {
      destroy ();
    }
  } catch (...) {
    destroy ();
  }

with many, many levels of nesting.

This results in quadratic blow-up in the compiler.  The reason seems
to be that reachable_handlers returns a long list of handlers for each
place that can throw an exception.  That seems weird; why not just
stop after finding the first one?

The cause, in the code, is that reachable_next_level stops when it
finds a RNL_CAUGHT region -- but cleanup handlers are only
RNL_MAYBE_CAUGHT regions.  It seems to me that we should stop after
RNL_MAYBE_CAUGHT regions too, in this case; each cleanup handler
should have an edge to the places it can transfer control to next,
so we don't need them from the original place.

In that case, we could introduce RNL_CLEANUP -- which would be treated
like RNL_MAYBE_CAUGHT in most places, but like RNL_CAUGHT in
reachable_next_level.

Thoughts?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: PR 8805: EH vs. CFG

[Richard Henderson]

On Sun, Feb 23, 2003 at 05:02:08PM -0800, Mark Mitchell wrote:
> The cause, in the code, is that reachable_next_level stops when it
> finds a RNL_CAUGHT region -- but cleanup handlers are only
> RNL_MAYBE_CAUGHT regions.  It seems to me that we should stop after
> RNL_MAYBE_CAUGHT regions too, in this case; each cleanup handler
> should have an edge to the places it can transfer control to next,
> so we don't need them from the original place.

Well, the problem being that the first time around we're 
interested in finding *handlers* that are not reachable.

	struct vector { ~vector(); };

	void foo()
	{
	  try {

	    try {
	      vector x, y, z;
	      throw 0;
	    } catch (int) {
	    }

	  } catch (int) {
	    link_error();
	  }
	}

This is going to have to look backward through three
cleanups back to the actual handlers.  If we stop with
the first cleanup, we'll not be able to see any of this.

Perhaps there's a better way to do what I'm doing though...


r~