[AUDIO_WORKLET] Add support for MEMORY64 with 2GB and 4GB heap

[cwoffenden]

This pulls the changes out of #23508 to add just the MEMORY64 support.

The already merged interactive tests (from #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).

Will need a once-over when #24734 lands.

[cwoffenden]

These failing size related tests are unrelated to the changes:

test_minimal_runtime_code_size_hello_webgl_wasm2js
test_minimal_runtime_code_size_hello_webgl_wasm
test_minimal_runtime_code_size_hello_webgl2_wasm2js
test_minimal_runtime_code_size_hello_webgl2_wasm

They don't fail for me with Emscripten 4.0.12 built from sdk-main-64bit.

The failing test_codesize_hello_dylink_all is fixed in #24742.

[sbc100]

These failing size related tests are unrelated to the changes:

test_minimal_runtime_code_size_hello_webgl_wasm2js
test_minimal_runtime_code_size_hello_webgl_wasm
test_minimal_runtime_code_size_hello_webgl2_wasm2js
test_minimal_runtime_code_size_hello_webgl2_wasm

They don't fail for me with Emscripten 4.0.12 built from sdk-main-64bit.

The failing test_codesize_hello_dylink_all is fixed in #24742.

To successfully rebaseline codesize tests on main you need to first run emsdk install tot to ensure you have the very latest llvm + binaryen running.

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.

[cwoffenden]

To successfully rebaseline codesize tests on main you need to first run emsdk install tot to ensure you have the very latest llvm + binaryen running.

What's the difference between tot and sdk-main-64bit? I've always used sdk-main-64bit because I can quickly switch between Emscripten's origin (main in the repo) and my own remote's branch.

[sbc100]

To successfully rebaseline codesize tests on main you need to first run emsdk install tot to ensure you have the very latest llvm + binaryen running.

What's the difference between tot and sdk-main-64bit? I've always used sdk-main-64bit because I can quickly switch between Emscripten's origin (main in the repo) and my own remote's branch.

tot is like 4.0.10 in that installs pre-built binaries from our build servers (https://ci.chromium.org/p/emscripten-releases/g/main/console)

sdk-main-64bit is not used my many folks, it builds everything from source (which most ppl don't want to do). I think it updates the main branch each time its run but I don't remember for sure.

The tot binaries are what the emscripten CI tests run against.

The easiest way to use any emscripten checkout without emsdk binaries is to do set EM_CONFIG=/path/to/emsdk/.emscripten. Then you can do a git checkout of emscripten and run ./emcc ... and the emscripten checkout will use llvm and binaryen binaries from emsdk. See https://emscripten.org/docs/tools_reference/emsdk.html#how-do-i-use-my-own-emscripten-fork-with-the-sdk

[cwoffenden]

sdk-main-64bit is not used my many folks, it builds everything from source (which most ppl don't want to do).

I think it’s a throwback from LLVM fixes we were doing, and it’s stuck. I’ll switch to tot.

[cwoffenden]

Unrelated fails seem Chrome related, same as #24750 for example.

(Re-run and passed)