Add an optimization: We don't store personality function address and LSDA
address at non-top-level landing pads (landing pads that are dominated by
another landing pad), because they have already been stored before.

I didn't close it explicitly. I just committed the change. I don't know why my CLs do not say "closed by commit rxxxx" like other CLs...

@dschuff I can restore it, and maybe I should, but I don't know how it would make a difference in preserving stack traces. Even if I will change __cxa_rethrow's implementation to use rethrow, only thing that changes is VM will get the argument (thrown object) from a separate storage reserved for rethrow rather than get it from the top of Wasm value stack. __cxa_rethrow does not reallocate exception object no matter which instruction (throw or rethrow) it uses.

Hmm. I somehow thought it's not possible to implement __cxa_rethrow using rethrow instruction, but to think about it, it might be actually possible. I guess I can't restore them within this CL and should open another one...?

wasm_landingpad_context -> wasm_lpad_context

typo

add a line in the test

delete a stray line

Just saw this hasn't been landed. Are you waiting from @dblaikie ?

I don't have enough context or knowledge on this code base. Sorry!

Looks OK to me, but I haven't worked on this part of code either, so I think someone else should approve it.

@dschuff PTAL

Made atomic memcpy/memmove intrinsics as unsupported for now. And also made the comments consistent with the up-to-date intrinsic names.

Uploaded LLVM side patch: https://reviews.llvm.org/D34826

Reverted non-relevant changes

This revision was created just for the record and was not intended for landing.

@dschuff: Oh, and this does not implement the special treatment of terminate.lpad.

I didn't manually close this one. This one was automatically closed when I committed the revision.

Address comments

Oh, TargetPassConfig::addPassesToHandleExceptions() is not virtual, so it can't be overriden anyway.

In that case, because addPassesToHandleExceptions always runs, createUnreachableBlockEliminationPass() will always run even if neither EH nor SjLj is enabled. And I think this may affect other tests in case there are unreachable blocks in other tests. Shouldn't it be

if (!EnableEmException && EnableEmSjLj) {
  addPass(createLowerInvokePass());
  addPass(createCFGSimplificationPass());
}

As I did in this patch?

Then should I also add SjLj to that addPassesToHandleException? Currently SjLj does not expect any invokes to exist in the module.
I guess we have to, because anyway EH and SjLj are in the same pass.

The reason for the test failure in the previous commit was this part:
In lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp

Delete a blank line

Address comments

Address comments & fix some typos

Address comments

• Add a test case for SjLj handling
• Modify the type of THREW from i1 to i32 (sjlj requires it to be i32)

WIll add a test case soon.

Does it work?

address comments

Address comments

Member variable initialization

Shorten Builder to IRB

Address comments

Address comments

Remove the test case for cxx-exceptions-whitelist option

Removed the cxx-exceptions-whitelist option from this CL

Add a test case for -emscripten-cxx-exceptions-whitelist option & Fix a bug

Address comments

clang-format

Addressed comments

Fix typos

Revert vimrc that was uploaded by mistake.

Re-add .clang-format and revert all changes. I didn't know this file was already in the repo.

Delete .clang-format that was uploaded by a mistake