Mutli-Memories Support in IR (#4811)

This PR removes the single memory restriction in IR, adding support for a single module to reference multiple memories. To support this change, a new memory name field was added to 13 memory instructions in order to identify the memory for the instruction.

It is a goal of this PR to maintain backwards compatibility with existing text and binary wasm modules, so memory indexes remain optional for memory instructions. Similarly, the JS API makes assumptions about which memory is intended when only one memory is present in the module. Another goal of this PR is that existing tests behavior be unaffected. That said, tests must now explicitly define a memory before invoking memory instructions or exporting a memory, and memory names are now printed for each memory instruction in the text format.

There remain quite a few places where a hardcoded reference to the first memory persist (memory flattening, for example, will return early if more than one memory is present in the module). Many of these call-sites, particularly within passes, will require us to rethink how the optimization works in a multi-memories world. Other call-sites may necessitate more invasive code restructuring to fully convert away from relying on a globally available, single memory pointer.

1 files changed, 2 insertions, 1 deletions

diff --git a/src/abi/stack.h b/src/abi/stack.h
index cc678b6e8..93a6e4cc1 100644
--- a/src/abi/stack.h
+++ b/src/abi/stack.h
@@ -50,7 +50,8 @@ getStackSpace(Index local, Function* func, Index size, Module& wasm) {
   }
   // align the size
   size = stackAlign(size);
-  auto pointerType = wasm.memory.indexType;
+  auto pointerType =
+    !wasm.memories.empty() ? wasm.memories[0]->indexType : Type::i32;
   // TODO: find existing stack usage, and add on top of that - carefully
   Builder builder(wasm);
   auto* block = builder.makeBlock();