-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Fastcomp cleanup post removal #11860
Comments
I agree deletion PRs are a good starting point. That's low-risk, and enables more stuff later. I don't think we should try to make backporting easier, as there seems little benefit. (If backporting is important to someone, would be good to hear about that, and how we can work together on it.) I think we should coordinate those deletion PRs in this issue, to avoid stepping on each others' toes and getting lots of merge conflicts. For example: I can start with the JS code |
Sounds good. Why don't we all work on the list above and put your name on a list item if you are going to start work on it? I am personally going to try to avoid the temptation to just do all of them right away :) (Mostly since I think it could suck all my time for the next month!) |
After removing it, things are always in DOUBLE_MODE == 1 basically (that is, doubles are normal doubles, no asm.js weirdness). See #11860
This has been a no-op on wasm, and this PR keeps it that way (we do duplicate function elimination in binaryen automatically). See #11860
…scripten.py fastcomp code around it. See #11860
This is no longer in use since fastcomp removal. See: #11860
These are no longer used or usefull since fastcomp removal. See: #11860
Also remove functions and modules that were only used by this code. See: #11860
Also remove functions and modules that were only used by this code. See: #11860
This was only used in fastcomp builds. AFAICT the llvm backend uses binaryen passes to do this stuff. See: #11860
Also remove functions and modules that were only used by this code. See: #11860
These are no longer used or usefull since fastcomp removal. See: #11860
This was only used in fastcomp builds. AFAICT the llvm backend uses binaryen passes to do this stuff. See: #11860
These are no longer used or usefull since fastcomp removal. See: #11860
These are no longer used or useful since fastcomp removal. See: #11860
These used to make sense when we had static allocations in JS. We'd use the "bump" to track the total size, which was increased by the JS compiler, and at runtime we'd have STATIC_BASE and STATICTOP. Now that we disallow static allocations from the JS compiler, we don't need them. Note that we do still track "staticBump" in the metadata from finalize. That is the total size of static memory from lld, which never changes. We use it to compute where the stack begins (which determines the rest of memory layout). As a followup we may be able to use a link map or other mechanism to just read that info instead of computing it in emscripten.py See #11860
This removes some TODOs from wasm2js where we thought about running more of the old passes. I think that's not a good idea - they will not run as our wasm2js output gets less and less like asm.js anyhow. We'll need to write new acorn passes there, if we want to. This removes safeHeap which we should be running (see #12410 (comment)), but as it would be the only thing we use the js optimizer for from emcc.py, and that isn't a recent regression, remove that too and I'll rewrite it for acorn. See #11860
This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant. |
As a followup to #11319 we have a lot of potential cleanup of emscripten to do now that fastcomp is no more.
One thing to consider: do we want to make backporting/cherrying picking easy(er) for while). Should we hold off large refactors for a while for this reason? It seem like there will be enough pure-deletion PRs to keep us going for while :)
List of cleanup work:
src/
inside!WASM_BACKEND
not WASM_BACKEND
WASM_BACKEND
completely.WASM
? (even with-s WASM=0
we setWASM
to 1 and setWASM2JS
, inverify_settings
. soWASM == 1
all the time in tests etc.)Cleanup PRs should mention "See #11860" (this PR).
The text was updated successfully, but these errors were encountered: