> > 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.
This sounds fine. > > 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. And this too, of course :) > > >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. And this is major point of my confussion. I allways assumed that there are multiple labels, not that we always land to the innermost landing pad on the way. > > >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. Yes, this is what I was thinking about. In the lowered representation one would actually need to do VRP style dataflow to prove that given EH region is shadowed, while in higher representation we can stick with the current algorithm that is used for CFG buid just without actually building CFG just marking reachability... Honza
