Re: Notes toward re-implementing EH in gimple

[Jan Hubicka <hubicka at ucw dot cz>]

> On 08/10/2009 08:20 AM, Michael Matz wrote:
> >It's not that they _create_ side-effects, but they depend on some.
> 
> Ah, fair enough.  I hadn't actually thought that all through.
> 
> >Btw, it's really wonderful that someone tackles EH-on-gimple ;-)
> 
> I hadn't been planning on it, but my trans-mem branch is stalled
> on the dominator-breaking representation we have in gimple atm.
> 
> I tried fixing that, but ran quite afoul of Honza's critical edge
> splitting pass.  There's absolutely no way to split a resx edge
> in the current representation, and we're saved only by the fact
> that resx statements don't have edges at the moment.  Though you

You should be able to split it by copying the regions and I was
definitly dealing with RESX edges when working on the redirection patch.
(we no longer require RESX region number to match region number of
exception we are just serving).

make_edges do call make_eh_edges for resx:
         case GIMPLE_RESX:
                  make_eh_edges (last);
and make_eh_edges will create them for you.
and I do get them in i.e. tramp3d dumps:

  save_filt.98_8 = [filter_expr] <<<filter object>>>;
  save_eptr.97_9 = [exc_ptr_expr] <<<exception object>>>;
  std::allocator<int>::~allocator (&D.99154);
  <<<exception object>>> = save_eptr.97_9;
  <<<filter object>>> = save_filt.98_8;
  resx 4
  # SUCC: 7 [100.0%]  (eh)

So perhaps you get the edges purged? But that is using can_throw_internal 
that also handles the edges.

> wouldn't know it by looking at the code.  Lots of places seem to
> think resx should have edges.  But deep down in the middle you'd
> find that resx doesn't satisfy stmt_could_throw_p, which stops
> the eh edge creation right in its tracks.
> 
> So it seems there's nothing to do but rewrite it all.  ;-)

If it helps in short term, I can try to fix this if you send me your
patch fixing the missing edges problem.

Honza
> 
> 
> r~