@tlively Sorry for the delay in getting back to you, its been a busy couple weeks at work!

Currently the exception handling primitives we use are target-specific. More precisely, non-Windows platforms we use invoke and landingpad, whereas for Windows we use invoke, catchpad, catchret, etc. This was largely due to the recommendation in the docs to use the non-SEH operations for efficiency reasons outside of Windows, but we're not strictly tied to one or the other.

Great, thanks! I asked because right now WebAssembly's exceptions proposal is implemented in LLVM in terms of the Windows SEH intrinsics. If you're already using those for Windows, I would hope it wouldn't be a large burden to use them for WebAssembly as well.

Yeah I actually already have the code in place to use SEH-style exception instrinsics for WebAssembly, we just don't have the entire codegen pipeline implemented for WebAssembly yet.

One other thing I forgot to mention is that as part of this, we also rely on the StackMaps feature, which is not implemented for WebAssembly AFAICT, but I'm curious if you think such a thing can even be implemented on top of WebAssembly's backend in LLVM.

I'm not familiar with the StackMaps feature, but perhaps @aheejin knows?

I mispoke, we're not actually using StackMaps in relation to exception handling, so its not really related to the original topic. I'm primarily using it right now to track live values on the stack across GC statepoints. It's of interest though, since its an LLVM feature that is quite useful for compilers for GC'd languages, I'd go so far as to say critical for those building precise GCs, but is not supported for the WebAssembly target.

I think the main obstacle around supporting it though is the ability to link call sites to StackMap entries, which in general is done via return address for other targets, but in WebAssembly would need to be something else more opaque, but roughly equivalent.

Oh gotcha. After reading a bit about it, my best guess is that stackmaps could be supported today by spilling the preserved values to the in-memory stack and writing out the stack maps themselves as data. In the future, my guess is that a faster implementation could use the stack walking / stack inspection proposal.

Sorry I'm not very familiar with Lumen compiler. Does Lumen compiler have both separate frontend and backend that it generates source code to wasm directly?

If so, does it use LLVM in both? Can it use the WebAssembly backend instead?

@aheejin Lumen has a frontend which generates a high-level IR, that in turn is lowered to MLIR and ultimately, LLVM IR. We don't generate WebAssembly directly, we rely on LLVM to take care of that for us.

Oh, I see. Then I guess there should be no problem to use the wasm EH implementation in our LLVM backend if you generate Windows IR from the frontend for all platforms..

Per Dec 9 standup, this issue has been converted to a Discussion.