Re: Notes toward re-implementing EH in gimple

[Jan Hubicka <hubicka at ucw dot cz>]

Hi,
sorry for jumping in late, I had relatively urgent things to work at
and didn't had much time to think this over.

I am still having some problems understanding the plans on critical edge
splitting.

> EXC_PTR_EXPR and FILTER_EXPR will be expanded to take the EH
> region number as a parameter.  Since they no longer need to be
> saved and restored, they will no longer be gimple lvalues.
> 
> 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?
This makes my comment on need for new BB mood. Sure critical edge
splitting involves creating of new BB, but I was concerned about the
fact that BB needs to have { e1, f1 } = EH_LANDING_PAD; in it.  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. Even if critical edge splitting is main use for it, it is IMO better
if EH edges behave regularly like other edges for the compiler if it is
feasible to do so.  Otherwise we would need to keep ABNORMAL flag on
them and end up having specialized code to do CFG transformations we
want (I am not sure how much besides critical edge splitting and EH
cleanup we actually want though, but it seems to me that eventually we
will find more use for it). Situation seems similar here to RTL
non-cfglayout issues, just less evil.

I do understand that at mainline we used to have edges from call to
every possible handler and no resx edges first to allow DCE code to work
out non-trivially inaccessible EH handlers because of type handling
logic in foreach_reachable_handler. I also see that you intend to add EH
edges only to the control flow transitions that really happen at runtime
(that include EH edges from RESX to outer region) that will result in
smaller CFG that is technically correct. Nontrivially dead EH stuff can
be handled by EH clenaup.

If there is only one edge from each EH statement, I see that you can use
the NOP region tree to assign it new destination label instead of
duplicating parts of EH tree to do the same redirection.  (current code
involve no code duplicaiton, just EH tree, so the duplication don't seem
that evil to me since EH trees are small and resulting code won't
change).

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. Otherwise we will get wrong code bug adding
something across the path from innermost possible handler to the outer
handler that won't be executed if the outer handler is delivered by the
runtime dirrectly.

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?

EH regions could be just action lists and we can do hashing of action
lists to catch duplicates as we do redirecting and other operations on
them.

> We *don't* actually have those RESX->outer edges at the moment.
> That's one of the things that I'm trying to fix with my trans-mem
> dominator patch... which I've spent most of the day not working on.  :-P

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.

Honza
> 
> 
> r~