Wasm table is not optimized away if not used

[juj]

STR:

emcc tests\minimal_hello.c -o a.html -s MINIMAL_RUNTIME=1 -s ENVIRONMENT=web -s SUPPORT_ERRNO=0 -s MINIFY_HTML=0 -s TEXTDECODER=2 -O3 -g1 --closure 1 --profiling-funcs

generates

(module
 (type $none_=>_none (func))
 (type $i32_=>_none (func (param i32)))
 (type $i32_i32_=>_i32 (func (param i32 i32) (result i32)))
 (import "a" "a" (memory $1 256 256))
 (data (i32.const 1024) "(char* str)<::>{ console.log(UTF8ToString(str)); }\00minimal hello!")
 (import "a" "b" (func $console_log (param i32)))
 (table $0 1 1 funcref)
 (export "c" (table $0))
 (export "d" (func $__wasm_call_ctors))
 (export "e" (func $main))
 (func $main (; 1 ;) (param $0 i32) (param $1 i32) (result i32)
  (call $console_log
   (i32.const 1075)
  )
  (i32.const 0)
 )
 (func $__wasm_call_ctors (; 2 ;)
  (nop)
 )
)

var c;
c || (c = Module);
var d = new TextDecoder("utf8");
function e(a) {
  if (!a) {
    return "";
  }
  for (var k = a + NaN, b = a; !(b >= k) && f[b];) {
    ++b;
  }
  return d.decode(f.subarray(a, b));
}
var g = new WebAssembly.Memory({initial:256, maximum:256}), f = new Uint8Array(g.buffer), h;
WebAssembly.instantiate(c.wasm, {a:{b:function(a) {
  console.log(e(a));
}, a:g}}).then(function(a) {
  a = a.instance.exports;
  h = a.e;
  a.d();
  h();
});

In the Wasm module there are

(table $0 1 1 funcref)
(export "c" (table $0))

but those are not used for anything in the generated program, and the export c goes unused in the output, so they could both have been optimized out from the wasm module.

[sbc100]

I guess the problem is that we tell the linker that we (the JS embedded) needs access to that table.

It is possible to still use the table from JS, grow it, and add elements to it using addFunction. I see a few options:

1. Have wasm-ld recognize that no call_indirect relocations exist and in that case don't generate __indirect_function_table at all. Probably not enough because we want wasm-opt to able to that GC the table.

2. Have wasm-emscripten-finalize or wasm-opt remove the table based on some heuristic or some specific pass. e.g. if it has no elements of if there are no call_indirect instructions then remove it completely.

3. Determine at JS compile time if we can safely remove the table export (e.g. if we can determine there are no dynCalls and/or no calls to addFunction/removeFunction). This should massivly reduce the codesize of the JS in the above example.

I think (2) is probably the easiest path forward to fix the immediate issue. Perhaps a binaryen pass called strip-empty-table that removes an empty table even if it is exported (which is not normally a safe thing to do because the embedder might actually want to use the table for their own purposes right?).

BTW, the same thing is going to be true of the memory too... the above program also happens to not use memory, and I'm hoping to move the memory to be exported-from-wasm soon too: #12323.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.