wasm-opt --spill-pointers fails with internal error in wasm::ABI::getStackSpace()

[wmaddox]

% wasm-opt --enable-threads --spill-pointers -o myproject.wasm myproject.nogc.wasm
Fatal: getStackSpace: failed to find the stack pointer

Function wasm::ABI::getStackSpace() attempts to obtain the global stack pointer STACKTOP with the following call: GlobalUtils::getGlobalInitializedToImport(wasm, ENV, "STACKTOP"). This attempts to locate a global variable that is initialized to the value of the imported variable env.STACKTOP. It appears that the expected code idiom is no longer used as of #1870. Instead, the initial value of STACKTOP is hardcoded.

[kripken]

Yeah, there isn't a good ABI for this sort of thing I'm afraid. Another issue is that the wasm backend's stack goes downward instead of up. So there isn't a good way atm to access the C stack in binaryen. We'd probably need to add specific flags for specific ABI assumptions.

Btw, I'm curious what's your use case for this pass? I've never been sure if this pass is useful for people or not.

[wmaddox]

We use --spill-pointers to support GC. Our GC is mostly exact, but relies on conservative stack scanning.

It seems to me that wasm-opt might not be the best place to implement this functionality, because lowering to WASM has already eliminated any explicit notion of the linear stack. Before --spill-pointers was implemented, I implemented a similar mechanism as a modification to fastcomp. As I recall, --spill-pointers turned out to be at least as performant, and therefore was preferred going forward, as it was also the upstream solution. The big downside, as I see it, is that spilling really ought to be done after any optimizations that might eliminate or introduce calls (e.g., -Oz) or which would have eliminated the spilled variables, otherwise, unnecessary stores may be retained or optimizations unnecessarily inhibited. This shouldn't be a problem in a fully-native C/C++ to WASM pipeline, but poses a problem for translation via asm.js, since the C++ stack has been lowered already in the translation to asm.js before asm2wasm is run. Nonetheless, asm2wasm seems to be in a better position to handle pointer spilling, as it has access to the symbolic variable names (e.g., "STACKTOP") needed to make the current scheme work.

[kripken]

Yeah, there are multiple considerations here.

Another issue is the number of locals. Doing spilling after locals have been minimized as much as possible may be more efficient, so doing it after binaryen optimizations would be best. Asyncify works that way as it also spills and restores locals.

But yes, we'd need to make the C stack accessible to Binaryen. Currently it just looks for STACKTOP, but we could connect it to the wasm backend's stack with a little more work. That might work by

• In emscripten at least one of stackSave/stackRestore/stackAlloc must be exported, so it is kept alive. That function's body will use the stack pointer, so we can identify it from there.
• In binaryen we can't tell if we are using the wasm backend or not, so we'd need a flag for that (maybe --stack-abi, or maybe just --spill-pointers-wasm-backend). Then it would find that export and identify the stack pointer.

[wmaddox]

Based on Kripken's comment above, I was able to implement a simple fix that restores wasm-opt --spill-pointers functionality sufficient to get my project "back in business". I make no claims for its generality, and don't attempt to address any of the larger ABI issues.