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~
