Re: Notes toward re-implementing EH in gimple

[Richard Henderson <rth@redhat.com>]

On 08/13/2009 06:48 AM, Jan Hubicka wrote:
>> In gimple, the landing pad will be generated as
>>
>> L.N:
>>    exc_ptr.1 = EXC_PTR_EXPR (N);
>>    filter.1 = FILTER_EXPR (N);
>>
>> ie, copied into normal variables for use.  These can be moved
>> about, or deleted, as the optimizer desires.
>>
>> All of this seems much cleaner than what I initially imagined.
>
> This seems quite stramlined representation.  When splitting the edge, we
> do create new landing pad, but will re-use the same (N) value so code
> don't needs to be duplicated/updated, right?

Yes.  Although I'm streamlining things even more now.  I've eliminated
the "global" variables that store the excptr/filter, and instead each
individual use location is asking for what it needs locally.

Further, the actual landing pad itself is *not* generated in gimple.
I had too many problems updating SSA form (in particular PHIs) when
I tried to prevent non-EH edges from using the EH landing pad label.
So now it's really a post-landing-pad label, and the actual landing
pad is still generated in rtl.

However, the CFG is still much improved over the current state.

>  I wanted
> to more note that it seems to make snese to aim towards EH edges
> arbitrarily redirectable without need to modify basic blocks while doing
> so.

This is exactly what I've got now.

> What I still fail to see how this scheme is going to avoid need for
> multiple edges from a call.  I was under impression that code in
> collect_one_action_chain produces dwarf representation as list labels
> and conditionals executed by runtime. So the runtime actually can
> deliever EH from the call to several EH regions and we ought to have
> edges for all of them.

collect_one_action_chain only produces one landing_pad label for
any one call site.  It does not produce multiple edges.

> In fact I was considering going further here and drop the current
> lexical EH tree representation and instead do the lowering to action
> chains very early and do all the transformations later on the lowered
> chains.  It seems a lot easier representation to think of than what we
> have now?

I'm really not sure what you mean by this.  Make the EH region number
associated with each statement be the action chain index?  A possibly
interesting idea, but I'm not sure what it gains you.  Certainly not
ease of optimization when it comes to cleaning up shadowed catch
handlers.

> Note that there are edges from RESX to the outer region, just in mainlie
> not all of them that is more a bug IMO (I run into this issue previously
> too since I tried to change the scheme EH edges are drawn as you
> outlined above). You can easilly verify that there are EH edges out of
> BBs ending with RESX.

I easily verified that there were not edges out of BBs ending with RESX.
Further, I first fixed the bug that prevented them, and then watched the
crited pass die because it doesn't properly handle splitting RESX edges.


r~