wasm-split support for memory64

[wenhanchong]

Please include the following in your bug report:

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.10 (b7dc6e5747465580df5984e723b9d1f10d8e804b)
clang version 21.0.0git (https:/github.com/llvm/llvm-project 8f7e57485ee73205e108d74abb5565d5c63beaca)
Target: wasm32-unknown-emscripten
Thread model: posix

Failing command line in full:
If this is compile or link-time failure please include the full failing command
along with its entire output.

wasm-split: /home/chongw/binaryen/src/literal.h:288: int32_t wasm::Literal::geti32() const: Assertion `type == Type::i32' failed.
rebuild.sh: line 30:  4052 Aborted                 (core dumped) /home/chongw/binaryen/bin/wasm-split --enable-mutable-globals --export-prefix=% build/main.wasm.orig -o1 build/main.wasm -o2 build/main.deferred.wasm --profile=build/profile.data --enable-memory64 --verbose

Unable to run wasm-split for wasm built with -sMEMORY64=1 even with wasm-split --enable-memory64 flag.
Sample app attached.

wasmsplit_memory64.zip

[wenhanchong]

If I work around the assert by using wasm::Literal::geti64() instead of wasm::Literal::geti32(), wasm-split is able to run but running wasm-opt build/main.wasm --enable-mutable-globals --enable-memory64 on the resulting wasm file throws a validation error:

[wasm-validator error in function 6] i32 != i64: call-indirect call target must match the table index type, on
(call_indirect $0 (type $func.0)
 (i64.add
  (local.get $15)
  (i64.load
   (i64.add
    (i64.load
     (local.get $15)
    )
    (i64.const -24)
   )
  )
 )
 (i32.const 5)
 (i32.const 365)
)
[wasm-validator error in function 13] i32 != i64: call-indirect call target must match the table index type, on
(call_indirect $0 (type $func.0)
 (local.get $9)
 (local.get $8)
 (i32.shr_s
  (i32.shl
   (local.get $11)
   (local.get $12)
  )
  (local.get $12)
 )
 (i32.const 366)
)
...
Fatal: error validating input

[wenhanchong]

@tlively is memory64 supported in wasm-split?

[Mintyboi]

@kripken @sbc100 Any chance of getting some eyes on this?
Or perhaps, could there be anything we can do more to make it easier to identify the issue?

[tlively]

cc @aheejin, do you think you could take a look at this?