Add Asyncify mode that uses "native" stack

[RReverser]

Something I mentioned in personal discussions with @kripken, posting here for tracking.

Low-level Asyncify API is flexible enough to support arbitrary suspend/resume use-cases, including coroutines. However, many applications don't really care about those and want to only suspend/resume the whole app on an external I/O.

For such cases, it could be nice to avoid having to allocate a separate "scratch space" for Asyncify, and instead push values directly onto the shadow stack behind __stack_pointer as defined by Tool Conventions. Semantically, those stored values are the spilled stack, so it only makes sense to store them there.

This would, in particular, simplify integrations like https://github.com/GoogleChromeLabs/asyncify, which currently have to make guesses about a free space area in a Wasm file where they could store Asyncify data, and would centralise stack size management for both Asyncify and regular stack in a single place.

[tlively]

I forget, do we have a way of telling Binaryen where the __stack_pointer is stored?

[RReverser]

I wanted to reply that it's exported, but, apparently, unlike other useful __-prefixed variables (like __heap_base / __data_end), it's not...

Now that I remember previous discussions around this, exporting it was blocked on mutable globals proposal (since __stack_pointer is, indeed, a mutable global). Now that it's stable and implemented everywhere, even in Safari (https://webassembly.org/roadmap/), I think this should no longer be a blocker and we could export it from LLVM as well?

[sbc100]

The normal way to access and manipulate __stack_pointer is via stackSave/stackAlloc/stackRestore:
https://github.com/emscripten-core/emscripten/blob/fcb8d588f630dbb715c93067c678cc9db8818f0b/system/lib/compiler-rt/stack_ops.s#L10

Is there some reason we can't use those in this case?

[RReverser]

Yes, in this case I want to use the stack pointer from an external JS wrapper - https://github.com/GoogleChromeLabs/asyncify.

The only way to allow it such access is to re-export the __stack_pointer externally.

[sbc100]

Sorry I still don't understand :( What can you do with the __stack_pointer export that you can't already do with by exporting stackSave, stackAlloc, and stackRestore? Don't those functions give you full control over the stack pointer? This is how the rest of our JS code manipulates the stack pointer.

Having said all that we should support its direct export too at least when mutable-globals are enabled.

[RReverser]

Those functions are Emscripten-specific and available only from Emscripten; Asyncify transform and the above JS wrapper are not and can be used on arbitrary Wasm (hence the issue on Binaryen repo, not Emscripten one).

Having said all that we should support its direct export too at least when mutable-globals are enabled.

Sounds like we agree :)

[sbc100]

Sorry for the misunderstanding.. I finally got it!

[sbc100]

OK as of https://reviews.llvm.org/D88506 you should now be able to --export=__stack_pointer

[RReverser]

@sbc100 Ah, interesting, thanks. I actually didn't realise that it requires change to LLVM / wasm-ld. And then wasm-opt will preserve the export as well when mutable globals are enabled?

[sbc100]

I don't think wasm-opt will add or remove exports.. but it might reject the binary if mutable globals are not enabled I think