-
Notifications
You must be signed in to change notification settings - Fork 762
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lower WASM exceptions to MVP (or maybe GC) #7179
Comments
So far this hasn't come up because e.g. C++ users can recompile to switch between wasm exceptions and not, but if there are toolchains that only emit exceptions then I agree a lowering pass could make sense here. A contribution of such a pass sounds good in general, as Binaryen does have lowering passes for several other features. |
Is there a lowering pass for the multi-value extension? I guess lowering extensions like reference types or GC are impossible? |
There have been attempts to lower GC in Binaryen. Multi-value is probably also lowerable, but no one has made an attempt yet. (same as exceptions) |
There isn't a full multivalue lowering pass, but TupleOptimization will remove unneeded uses of multivalue inside functions. That leaves multivalue uses between functions, multivalue for exceptions, and a few other things. Lowering GC is possible, but it would just be a lot of work. |
Many C++ libraries require exceptions, like
libriscv
and Binaryen itself. Compiling them to WASI would work (aswasi-sdk
, iirc, supports WASM exceptions), but some WASM parsers (like my fork ofwaffle
) and WASM compilers (likew2c2
) do not.For compatibility with those compilers and parsers, we would need a WASM exception lowering pass. Generically, the only sound option is lowering to GC, however MVP lowering might be required for some usages, where we would redirect exception data to either a seperate memory or an unused segment of the existing one.
As one of the few WASM analysis tools that support exceptions, Binaryen seems fit to contain some exception lowering pass, even if it would be unnecessary for most pure-Binaryen workloads.
The text was updated successfully, but these errors were encountered: