[AUDIO_WORKLET] Add support for MEMORY64 with 2GB and 4GB heap#24732
[AUDIO_WORKLET] Add support for MEMORY64 with 2GB and 4GB heap#24732sbc100 merged 23 commits intoemscripten-core:mainfrom
Conversation
|
These failing size related tests are unrelated to the changes: They don't fail for me with Emscripten 4.0.12 built from The failing |
To successfully rebaseline codesize tests on main you need to first run For pre-existing codesize changes we have a bot that automatically updates them.. I'll trigger it now so that main is up-to-date. |
What's the difference between |
The The easiest way to use any emscripten checkout without emsdk binaries is to do set |
I think it’s a throwback from LLVM fixes we were doing, and it’s stuck. I’ll switch to |
|
Unrelated fails seem Chrome related, same as #24750 for example. (Re-run and passed) |
|
@sbc100 Any chance of a review of this? It's a shorter replacement for the earlier one, discussed here way back when: |
|
(Probably not worth adding a |
The convention for JS library code is to use var for better minification. The use of `void 0` instead of `undefined` I believe is a minor code size optimization, but its somewhat obscure and (as you can see from the fact that the code expectations didn't change) it an optimization that is already performed on the generated code anyway. Split out from emscripten-core#24732
The convention for JS library code is to use var for better minification. The use of `void 0` instead of `undefined` I believe is a minor code size optimization, but its somewhat obscure and (as you can see from the fact that the code expectations didn't change) it an optimization that is already performed on the generated code anyway. Split out from emscripten-core#24732
The convention for JS library code is to use var for better minification. The use of `void 0` instead of `undefined` I believe is a minor code size optimization, but its somewhat obscure and (as you can see from the fact that the code expectations didn't change) it an optimization that is already performed on the generated code anyway. Split out from emscripten-core#24732
The convention for JS library code is to use var for better minification. The use of `void 0` instead of `undefined` I believe is a minor code size optimization, but its somewhat obscure and (as you can see from the fact that the code expectations didn't change) it an optimization that is already performed on the generated code anyway. Split out from emscripten-core#24732
The convention for JS library code is to use var for better minification. The use of `void 0` instead of `undefined` I believe is a minor code size optimization, but its somewhat obscure and (as you can see from the fact that the code expectations didn't change) it an optimization that is already performed on the generated code anyway. Split out from emscripten-core#24732
Tested locally, which helped get this down to a minimum. |
Adding u32 types adds a five more bytes.
|
I’ll follow up with a bit of a tidy once this lands, just to keep the changes from sprawling. There’s a case also to write a test for when constructing the AW with options. |
The convention for JS library code is to use var for better minification. The use of `void 0` instead of `undefined` I believe is a minor code size optimization, but its somewhat obscure and (as you can see from the fact that the code expectations didn't change) it an optimization that is already performed on the generated code anyway. Split out from emscripten-core#24732
…ipten-core#24732) This pulls the changes out of emscripten-core#23508 to add just the `MEMORY64` support. The already merged interactive tests (from emscripten-core#23659) can be run with: ``` test/runner.py interactive_2gb.test_audio_worklet_params_mixing test/runner.py interactive64_4gb.test_audio_worklet_params_mixing ``` The browser tests with wasm64 have been re-enabled. Note: the intention is to add the performance improvements (from last October) once this is merged (which are still relevant and produce the same improvements).
This pulls the changes out of #23508 to add just the
MEMORY64support.The already merged interactive tests (from #23659) can be run with:
The browser tests with wasm64 have been re-enabled.
Note: the intention is to add the performance improvements (from last October) once this is merged (which are still relevant and produce the same improvements).
Will need a once-over when #24734 lands.