Optimization idea: Constant propagation across Wasm<->JS language boundaries?

[juj]

Here is something that I have been pondering on/off if might be possible with some suitable magic..

Given

a.c

void foo(int x);
int main() {
   foo(42);
}

liba.js

mergeInto(LibraryManager.library, {
  foo: function(x) {
    console.log(x);
  }
});

Is there some kind of compiler codegen magic we could do, to recognize when a JS function is called with only a constant literal value, that we'd transform the literal over to JS side, and let Closure compiler optimize the resulting code?

I.e. the above code would effectively get optimized into a form:

void foo(void);
int main() {
   foo();
}

liba.js

mergeInto(LibraryManager.library, {
  foo: function() {
    console.log(42);
  }
});

This example is maybe a bit silly and contrived. Expanding, maybe in the case of strings, one might have:

a.c

void log(const char *str);
int main() {
   log("hello");
}

liba.js

mergeInto(LibraryManager.library, {
  log: function(str) {
    console.log(UTF8ToString(str));
  }
});

possibly optimized into
a.c

void log(void);
int main() {
   log();
}

liba.js

mergeInto(LibraryManager.library, {
  log: function() {
    console.log('hello');
  }
});

to avoid having to run the UTF8ToString() marshalling over the language boundary.

If multiple string literals were used, e.g.

a.c

void log(const char *str);
int main() {
   log("hello");
   log("world");
}

liba.js

mergeInto(LibraryManager.library, {
  log: function(str) {
    console.log(UTF8ToString(str));
  }
});

this could theoretically become

a.c

void log(int case);
int main() {
   log(0);
   log(1);
}

liba.js

mergeInto(LibraryManager.library, {
  log: function(case) {
    console.log(['hello', 'world'][case]);
  }
});

if a suitably intelligent constant propagation would be able to track the multiple values.

I have been writing a toy JSON serializer/deserializer utility to experiment if I could completely replace C/C++ JSON libraries with a mechanism that would reuse JavaScript's JSON capabilities, and there I find that I am doing quite a lot of small string marshalling from Wasm -> JS, where the marshalled strings are all commonly literals, e.g.

std::vector<BufferView> views;
if (json_has_member_array(obj, 'bufferViews'))
  for(auto &b : json_get_member_array(obj, 'bufferViews'))
  {
    BufferView v;
    v.buffer = json_get_int(b, 'buffer');
    v.byteOffset = json_get_int(b, 'byteOffset');
    v.byteLength = json_get_int(b, 'byteLength');
    v.byteStride = json_get_int(b, 'byteStride');
    bufferViews.push_back(v);
  }

to marshal a struct with some integer fields.

In this scenario, there can be thousands to tens of thousands of such calls to json_get_*(json_object obj, const char *member_field), where member_field is generally a compile-time literal.. this results in a massive number of runtime UTF8ToString() calls.

And given that this is general purpose JSON deserializer code, I cannot hardcode these strings to JS side either.

So if we had a pass that recognized constants (and constant strings?) in Wasm side, and was able to move those to the JS side (and then remove the wasm side strings from the static data), that would improve this kind of use case.

There are also other use cases in e.g. https://github.com/juj/wasm_webgpu struct marshalling, that might be interesting for this.

Any thoughts if this kind of Wasm-JS boundary optimization might be feasible somehow? CC @kripken, @dschuff, @sbc100, @tlively

[sbc100]

Nice idea!

I think moving string constants from wasm to JS (when they are only needed by JS) is a really nice idea. However, I think it might depend on relocation information being understood by binaryan. As of today binaryen cannot actually ever remove data from within a data segment (since it cannot move data around in memory after wasm-ld has placed it). Even if we link with without segment merging and each string is in its own segment, all binaryen can do is delete the segment, it cannot compress the memory or reclaim the addresses used for the string data.

My guess is that that solution is to link with -emit-relocs so that binaryen can re-write / move wasm memory.

[kripken]

Yes, for simple constants this could be an extension of metadce (track not only uses across the wasm/js boundary, but also parameters and results), but for strings, we'd need relocation support in general.

Or, if we want something less general, in theory a pass could be aware that the API is reading a string, and if the pointer is constant and below the global data region's end, assume it can read a string there... perhaps.

[sbc100]

Yes, I assuming the less general thing would also basically end up duplicating the string? i.e. the string would be extracted into JS but would still having around in the wasm memory unused?

We do something very simply like we do for EM_ASM constants.

e.g.:

KNOWN_STRING_CONSTS = {
   0x234: "hello world\n",
}

Then whenever JS knows a string is bring received from native code it could first check the KNOWN_STRING_CONSTS.

This would probably depend on binaryen at least knowing where the .rodata ends and the .data begins.

[sbc100]

Maybe even simpler would be to do something like this:

function UTF8ToString(ptr) {
   if (ptr < RODATA_END) {
       str = getFromCache(ptr):
       if (str) return str;
   }
   
   ... decode UTF8 data.
   
   if (ptr < RODATA_END) {
       addToCache(ptr, str);
   }
   return str;
}