--spill-pointers not working in version 6

[hughsando]

Please include the following in your bug report:

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 6.0.3-git
clang version 23.0.0git
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/emscripten/6.0.3/libexec/llvm/bin

Failing command line in full:

emcc main.cpp -s BINARYEN_EXTRA_PASSES='--spill-pointers'
Fatal: getStackSpace: failed to find the stack pointer
emcc: error: '/opt/homebrew/Cellar/emscripten/6.0.3/libexec/binaryen/bin/wasm-opt --spill-pointers a.out.wasm -o a.out.wasm --mvp-features --enable-bulk-memory --enable-bulk-memory-opt --enable-call-indirect-overlong --enable-multivalue --enable-mutable-globals --enable-nontrapping-float-to-int --enable-reference-types --enable-sign-ext' failed (returned 1)

#include <stdio.h>
int main(int argc, char **argv)
{
	printf("Hello!\n");
}

[sbc100]

In order to run the --spill-pointers pass binaryen need to know which global is the stack pointer. Prior to WebAssembly/binaryen#8679 binaryen would just guess, that but turned out to be wrong in some cases.

Since WebAssembly/binaryen#8679 binaryen now needs to see the name section to know which global is the stack pointer.

See #26878 for how emscripten deals with this internally.

If we want to support passing --spill-pointers to wasm-opt via BINARYEN_EXTRA_PASSES passes then we could potentially inspect BINARYEN_EXTRA_PASSES during finalize_wasm and set need_name_section if it contains --spill-pointers.

One option to get this to work today would be to add --profiling-funcs to your command. This would then preserve the name section so would need to then run llvm-strip --strip-debug after to remove it.

@kripken is this something we want to support in emscripten? @hughsando what is the reason for running -spill-pointers in this case?

[hughsando]

I am using it for GC (haxe/hxcpp), version 5 is working well. The --profiling-funcs flag fixes the problem and llvm-strip (without the -strip-debug flag) restores the original size.

[kripken]

Nice that we have a solution here. Maybe documenting it is all we need to do, though I'm not sure if the emscripten or binaryen side is best.

[sbc100]

Since this is such a niche use case (I don't think we really want to officially support random BINARYEN_EXTRA_PASSES) I think we can close this here.

BTW @hughsando, if we removd the BINARYEN_EXTRA_PASSES feature completely and asked you do instead do:

1. emcc --profiling-funcs -o app.js
2. wasm-opt app.wasm --spill-pointers --strip-debug

Would that work, or is there some reason why the pass has to happen internally to the emcc command?

[hughsando]

I did actually try this two-pass system, but was missing the --profiling-funcs, so it did not work. But yes, I can make this work.
What would be best of all is having emscripten_scan_registers available at any point in the stack, but I assume there are practical reasons why this is not possible. The GC is conservative, so something like scanning (a copy of) the register memory (pointers or otherwise) would be a very nice alternative to spill-pointers.

[sbc100]

I think emscripten_scan_registers is unlikely to ever work outside of ASYNCIFY, right @kripken ?

[kripken]

Yes, to scan registers we need something like Asyncify that keeps them serialized in a place we can access them. The wasm spec doesn't provide that capability directly.