Repository navigation
Use wasm-gc to handle pointer casts in wasi #129040
Description
In #128628 I switched the way of handling function pointer casts in emscripten to an approach based on wasm-gc. Unlike the previous approaches this should work on the wasi targets, at least the ones that include wasm-gc. There's some difficulty in that there's no support for the instructions in the clang C front end, nor really in the backend yet. So I'm not sure what is the best way to emit these instructions. We only would need to generate one short function using them though.
@brettcannon WDYT?
Activity
brettcannon commentedon Jan 20, 2025
What's the specific benefit for trying to make the switch for WASI when "there's no support for the instructions in the clang C front end, nor really in the backend yet" as I don't think wasmtime has landed their GC proposal support fully yet? Plus there isn't a WASI trampoline like there is with Emscripten, so I'm not sure where you're suggesting to insert the assembly code, unless you're trying to broaden the trampoline to be WASM-agnostic?
hoodmane commentedon Jan 21, 2025
Right well if wasmtime or your favorite wasi runtime don't support wasm-gc yet then there's no benefit until they do. But wasi has the same function pointer cast problem as emscripten. Once the wasi runtimes all support wasm I think it makes sense to think about how to get a trampoline running. But it is indeed annoying if it's necessary to hand craft an object file. I'll look into what the options are, maybe there's a reasonable way with a
.sfile or inline assembly.brettcannon commentedon Jan 22, 2025
Looks like I misspoke; wasmtime landed support in version 27 in late November.
hoodmane commentedon Jul 10, 2025
WIP towards this:
llvm/llvm-project#147486
hoodmane commentedon Jul 26, 2025
And my builtin is added:
llvm/llvm-project#150201
brettcannon commentedon Oct 2, 2026
@hoodmane time to revisit this?
hoodmane commentedon Oct 2, 2026
I think so. Looks like Wasmtime supports wasm-gc since version 27.0 released Nov 25, 2024 approaching two years ago. There are some less-used wasm runtimes that don't support it so we'll presumably want some way to disable it at build time. I think it would be a pretty simple patch though.
One question is whether it's time to drop support for JavaScript runtimes without wasm-gc support. It looks like the only people who would be negatively affected would be people using old apple devices with Safari version older than 18.2. According to Russell, any iDevice released since 2018 supports this. So I think I'm comfortable with this. (I think I got what you said right @freakboy3742?)
I think if we can do this then we can use the same implementation for both wasi and Emscripten. The current implementation in Emscripten that allows the no-wasm-gc fallback has created a lot of headaches for me downstream so I'd love to see it go away anyways.
hoodmane commentedon Oct 2, 2026
I guess another question for wasi is which releases of clang include
__builtin_wasm_test_function_pointer_signature. It seems to be supported from Clang 22 released February 24, 2026.brettcannon commentedon Oct 2, 2026
Clang 22 has been in the WASI SDK since version 31. That's new enough for Python 3.15 and later according to PEP 11.
hoodmane commentedon Oct 2, 2026
Sounds good I'll open a PR.
hosu3das20s05s commentedon Oct 2, 2026
freakboy3742 commentedon Oct 5, 2026
That's correct. The oldest devices that can run iOS 18 were released in 2018 (e.g., iPhone XR/XS). iOS < 18 usage is currently ~7% of iPhone devices, and ~15% of all iPad devices.
I agree that this dropping support for older runtimes seems reasonable. iOS 17 is no longer receiving security updates; I don't think we need to maintain support for operating systems that aren't supported by the vendor.
brettcannon commentedon Oct 7, 2026
I got clarification that wasm-gc became on by default as of wasmtime 47.
gh-129040: Use wasm-gc to handle pointer casts in wasi (GH-158617)