> You free dominator info in cleanup_empty_eh () which is called per BB,
> does it get re-computed anywhere? If not consider unconditionally
> freeing it outside of the loop calling cleanup_empty_eh please.
I can free it outside, yes.
> I am concerned about the compile-time complexity of
> can_be_reached_by_runtime and its callers - it looks O(N^3) (in the
> number of MUST_NOT_THROW regions and eh tree depth) - can you convince
> me otherwise?
Function is O(N^2) because we start walk of subhandlers of
MUST_NOT_THROW handlers only and stop diving into MUST_NOT_THROWS
contained so the outer loop of can_be_reached_by_runtime sees every
region at most once per invocation of reamove_unreachable_handlers.
The inner loop might visit every node several times as we unwind, but we
would have same number of edges in CFG and do precisely same walk every
during CFG build and every time we update or verify EH edges, so this
would not be the part of compiler where we will spend noticeable time
anyway. So the pass is definitly O(n) in size of CFG, that should be
EH trees tends to be quite large (over 3000 nodes in tramp3d's main on
pretty-ipa) but they are wide, not deep.
> Btw, your patches contain lots of whitespace oddities (spaces vs.
> tabs) and seemingly long lines. Your favorite text editior should
> be able to lend you a hand in automatically cleaning this up.
> Other than that the patch looks ok if you for now only retain the first
> pass invocation.
OK, thanks, I will reindent the new code and remove the extra calls.