[wasm-split] Add an option for recording profile data in memory (#4120)

To avoid requiring a static memory allocation, wasm-split's instrumentation
defaults to recording profile data in Wasm globals. This causes problems for
multithreaded applications because the globals are thread-local, but it is not
always feasible to arrange for a separate profile to be dumped on each thread.
To simplify the profiling of such multithreaded applications, add a new
instrumentation mode that stores the profiling data in shared memory instead of
in globals. This allows a single profile to be written that correctly reflects
the called functions on all threads.

This new mode is not on by default because it requires users to ensure that the
program will not trample the in-memory profiling data. The data is stored
beginning at address zero and occupies one byte per declared function in the
instrumented module. Emscripten can be told to leave this memory free using the
GLOBAL_BASE option.

1 files changed, 13 insertions, 0 deletions

diff --git a/src/tools/wasm-split/split-options.cpp b/src/tools/wasm-split/split-options.cpp
index 419555f45..8de08d5a1 100644
--- a/src/tools/wasm-split/split-options.cpp
+++ b/src/tools/wasm-split/split-options.cpp
@@ -197,6 +197,19 @@ WasmSplitOptions::WasmSplitOptions()
            profileExport = argument;
          })
     .add(
+      "--in-memory",
+      "",
+      "Store profile information in memory (starting at address 0 and taking "
+      "one byte per function) rather than globals (the default) so that "
+      "it can be shared between multiple threads. Users are responsible for "
+      "ensuring that the module does not use the initial memory region for "
+      "anything else.",
+      {Mode::Instrument},
+      Options::Arguments::Zero,
+      [&](Options* o, const std::string& argument) {
+        storageKind = StorageKind::InMemory;
+      })
+    .add(
       "--emit-module-names",
       "",
       "Emit module names, even if not emitting the rest of the names section. "