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