Skip to content

Bring pack spill-pointers #4566

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

Closed
ChrisJefferson opened this issue Apr 1, 2022 · 5 comments
Closed

Bring pack spill-pointers #4566

ChrisJefferson opened this issue Apr 1, 2022 · 5 comments

Comments

@ChrisJefferson
Copy link

wasm-opt used to contain an option --spill-pointers, which would spill things to the C stack which could be pointers, to help with C systems that used stack scanning for GC.

This option was added in b5ee16f , and removed in c61cb6f (when it was removed, it was non-functional).

I was using this option to build GAP ( www.github.com/gap-system/gap ). I was not keeping up to date (I was using enscripten 1.38, binaryen 1.37 for many years).

I'm not familiar enough with the internals of binaryen to know how easy this would be to bring back, but the commit message from @sbc100 mentioned bringing it back if anyone cared, so I wanted to mention I care! (that doesn't mean I'm expecting anyone to do the work to bring it back, but I thought I would register my interest).

@kripken
Copy link
Member

kripken commented Apr 1, 2022

Reverting the removal is easy enough, I found:

#4570

But as @sbc100 points out in the removal PR, the pass was incorrect for the LLVM wasm backend since the stack direction is down there, and we didn't have the testing to catch that, which is my worry. We should only restore the pass if we can properly test it.

How are you using the pass @ChrisJefferson ? I tried to search in your repo for it but had no luck.

@ChrisJefferson
Copy link
Author

ChrisJefferson commented Apr 1, 2022

src/gasman.c is a conservative garbage collector. The function GetStackFuncBags walks along the stack, calling a function for every possible "pointerish" object, if we find something which looks like a pointer into an allocated object, we don't GC it.

If I understand the issue (the stack went in a "non-standard direction?"), because gap (and gasman) were designed to support many very old machines , the function actually supports both stacks that go down, and stacks which go up, so this would have worked either way.

GAP itself is far too big for testing such a thing, but I'd be happy, inspired by GAP, to write some small test functions which test the principles of a conservative stack walker, writing some pointers to then stack and then going to look for them later.

@ChrisJefferson
Copy link
Author

If you were looking for a build system which worked with emscripten, I have a private branch where I build GAP using emscripten, but at the moment it is a huge pile of hacks and dodgyness (partially as GAP isn't designed for cross-compiling, so I have to partially build a linux build, then do some hacks to build an emscripten version). I also needed to hack around problems building libgmp.

@sbc100
Copy link
Member

sbc100 commented Apr 13, 2022

Since this pass only ever worked with upward growing stacks I assume you never got it working with the llvm backend? (only fastcomp, right?).

Re-landing this with the stack direction corrected seems doable. Is it conservative enough to catch all possible pointer usages in locals? Is som won't it be rather expensive to use?

@kripken
Copy link
Member

kripken commented Jun 9, 2022

This was done in #4570

@kripken kripken closed this as completed Jun 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants