[PATCH] D46803: [WebAssembly] Add WebAssemblyExceptionPrepare pass

[Heejin Ahn via Phabricator via llvm-commits]

aheejin added a comment.

@majnemer Continuing the discussion from https://reviews.llvm.org/D44134:

So the background was:
`__clang_call_terminate` is called within a cleanuppad. But cleanuppad does not give you an exception object, which `__clang_call_terminate` takes as an argument. So even if it is a cleanuppad, we added a wasm `catch` instruction there to catch an exception object. But this cleanuppad should be entered even when we catch a foreign (e.g. JavaScript) exception, which we have no exception object to deal with. So in that case we just directly all `std::terminate`.

So, when the clang-generated code is like

  terminate:
    %exn = catch(0)
    call void @__clang_call_terminate(%exn)
    unreachable

`processTerminatePads()` appends one more terminatepad right after this terminatepad, like:

  terminate-catchall:
    catch_all
    call @std::terminate
    unreachable

So the intention was, if we catch a C++ exception we go to `terminate`, and if we catch a foreign exception we end up in `terminate-catchall`. Here I also assumed that the terminatepad is a single BB, but as you noted, it may not be. But because this pass runs even before ExceptinInfo (https://reviews.llvm.org/D44134), this does not have the exception grouping information here.

Do you think I can merge the terminatepad into a single BB in this pass, so this duplication of terminatepad process will be easier? I can't think of a situation in which a terminatepad can have complicated control flows other than a few straight-line BBs. (Actually I can't even imagine what kind of llvm pass is gonna divide a single terminate into two or more, but we can't guarantee that can't happen, so..)

Also, the other thing is, I merge terminate pads if there are more than two of them in `mergeTerminatePads()` here. This is in principle violation of EH scope membership, but this happens after all MachineFunctionPasses and only remaining wasm passes after this are CFGSort and CFGStackify, so I guess it should be OK.


Repository:
  rL LLVM

https://reviews.llvm.org/D46803