Emscripten: Fastcomp cleanup post removal

Created on 11 Aug 2020  路  4Comments  路  Source: emscripten-core/emscripten

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:

  • [x] Remove asmjs validation (#11551).
  • [x] Remove JS in src/ inside !WASM_BACKEND
  • [ ] Remove check_vanilla and is_vanilla cache file, @sbc
  • [x] Remove all Python driver code inside not WASM_BACKEND
  • [x] Remove WASM_BACKEND completely.
  • [x] Remove fastcomp-only settings in settings.js.
  • [ ] Remove dual/split cache (cache/asmjs vs cache/wasm)
  • [ ] Remove fastcomp backend code in emscripten.py.
  • [ ] Remove WASM? (even with -s WASM=0 we set WASM to 1 and set WASM2JS, in verify_settings. so WASM == 1 all the time in tests etc.)

Cleanup PRs should mention "See #11860" (this PR).

help wanted

All 4 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 src/* - ?

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!)

Would removing all of the custom (non-wasm-ld) linking code fall into this, or are there still things to fix for that?

Yes, although sadly we still have at least one customer who wants to do bitcode linking, which currently is not possible with wasm-ld so for now we need to "link-to-bitcode" path to stay alive I think.

Was this page helpful?
0 / 5 - 0 ratings