[PATCH] D48345: [WebAssembly] Fix unwind destination mismatches in CFG stackify (WIP)

[Heejin Ahn via Phabricator via llvm-commits]

aheejin added a comment.

Continuing the discussion started in the email:

I think it's better not to split this pass as a separate pass. The reasons are:

1. Now CFGStackify pass maintains several internal maps (`ScopeTops`, `BeginToEnd`, `EndToBegin`, `TryToEHPad`, `EHPadToTry`, and `BeginToBottom`) to keep track of start/end markers, and entries are added to these maps and queried both in CFGStackify and namely, FixUnwindMismatch pass. So these maps have to be maintained in both passes, and also, we have to either carry that information using auxiliary data structure or we have to recalculate these maps at the end of FixUnwindMatch, which is more work.

2. Now CFGStackify also has several helper functions (`registerScope()`, `registerTryScope()`, and `unregisterScope()`) that help add and delete entries to various maps I mentioned in 1. We need these utility function in both passes.

3. `rewriteDepthImmediate()` and `fixEndsAtEndOfFunction()` functions run at the end of CFGStackify. But because we change CFG in FixUnwindMatch pass as well, they should rather run at the end of FixUnwindMatch pass now. This looks a bit weird bcause FixUnwindMatch pass should only run for functions that have a personality function (or an EH pad). And also intuitively rewriting depth immediates is not a part of FixUnwindMatch but CFGStackify.

Also, if we can bear with CFGStackify file getting a bit longer, I think the two parts are kind of well divided and factorized into functions.


Repository:
  rL LLVM

https://reviews.llvm.org/D48345