Update emsdk version from 098d1f95 to 7eb65927

[emscripten-bot]

This is an automatic change generated by tools/maint/rebaseline_tests.py --update-emsdk.

emsdk version updated: 098d1f95 => 7eb65927

The following revisions were included in this update:

- 7eb65927 Roll llvm-project from 104f644ddbd3 to 74a53743efe6 (52 revisions)
- 39822e1a Roll emscripten from 4e659979b4e0 to 25c255b66fe5 (1 revision)
- 62334b94 Roll emscripten from 096a3e7b1755 to 4e659979b4e0 (1 revision)
- 16174439 Roll binaryen from f4510a6a04aa to d00111222996 (3 revisions)
- 8dca00d6 Roll llvm-project from d4afeda893d3 to 104f644ddbd3 (61 revisions)
- df7348cb Roll v8 from 954902295c9a to 36de2a2334c9 (34 revisions)
- a5a30d6f Roll binaryen from d2c23335def7 to f4510a6a04aa (1 revision)
- a0987217 Roll emscripten from b6f4364e625d to 096a3e7b1755 (2 revisions)
- 75f07ddc Roll llvm-project from 3bd7ee0215b7 to d4afeda893d3 (75 revisions)
- a77eb082 Roll binaryen from 6c97a76b08ee to d2c23335def7 (2 revisions)
- 5cab49fa Roll emscripten from c5cab1bbc123 to b6f4364e625d (1 revision)
- b42656da Roll llvm-project from 75225e049964 to 3bd7ee0215b7 (47 revisions)
- 81cc8c3e Roll llvm-project from 7f8640b7bdab to 75225e049964 (28 revisions)

Full log: https://chromium.googlesource.com/emscripten-releases/+log/098d1f95..7eb65927

The following (2) test expectation files were updated by
running the tests with --rebaseline:

codesize/test_codesize_files_wasmfs.json: 63087 => 54647 [-8440 bytes / -13.38%]
codesize/test_codesize_hello_dylink_all.json: 858711 => 858653 [-58 bytes / -0.01%]

Average change: -6.69% (-13.38% - -0.01%)

[sbc100]

This is quite big improvement for test_codesize_files_wasmfs.json.. i'm curious where it comes from

[sbc100]

According the gemini the imrprovement came from a binaryen change:

Root Cause

In Binaryen's inliner (src/passes/Inlining.cpp), functions with multiple
callers (refs > 1) that are larger than flexibleInlineMaxSize (5
instructions) but within the -O3 maxSize threshold (30 instructions) are
only eligible for inlining if they have no calls and no loops (!hasCalls && !hasLoops).

Previously, FunctionInfoScanner only set hasCalls = true on direct Call
instructions and omitted CallIndirect and CallRef.

Why test_codesize_files_wasmfs shrank by 8,440 bytes (-13.38%)

One function was added to the symbol list in
test/codesize/test_codesize_files_wasmfs.json:

+    "$\"std::__2::__shared_weak_count::__release_weak()",

In single-threaded builds, std::__2::__shared_weak_count::__release_weak()
compiles to ~17 Binaryen IR nodes with no loops and no direct calls—
only a virtual destructor dispatch via call_indirect:

 (func $"std::__2::__shared_weak_count::__release_weak()" (param $0 i32)
  (local $1 i32)
  (block $block
   (if
    (local.tee $1
     (i32.load offset=8
      (local.get $0)
     )
    )
    (then
     (i32.store offset=8
      (local.get $0)
      (i32.sub
       (local.get $1)
       (i32.const 1)
      )
     )
     (br_if $block
      (local.get $1)
     )
    )
   )
   (call_indirect (type $0)
    (local.get $0)
    (i32.load offset=16
     (i32.load
      (local.get $0)
     )
    )
   )
  )
 )

1. Because WasmFS uses std::shared_ptr heavily across file descriptors,
   directory entries, and backends,
   std::__2::__shared_weak_count::__release_weak() is called 235 times in
   test_codesize_files_wasmfs.
2. Before d00111222, Binaryen's -O3 inliner treated __release_weak()
   as a leaf function (hasCalls == false) despite the call_indirect, and
   inlined its body into all 235 call sites (235 × ~36 bytes ≈ 8,440 bytes).
3. After d00111222, visitCallIndirect sets hasCalls = true, preventing
   __release_weak() from being inlined across those 235 call sites.
   Similarly, $__fclose_ca (which indirectly calls f->close(f)) is kept
   outlined in test/codesize/test_codesize_hello_dylink_all.json, saving 58
   bytes.

[sbc100]

See WebAssembly/binaryen#9146

[kripken]

There is some risk of speed regressions from that change, but hopefully not. We didn't see issues on the emscripten benchmark suite.

[sbc100]

The old behaviour certainly seems like it was wrong though. 235 call sites should never yield hasCalls == false ! That seems like it was just a bad inlining decision.

[kripken]

Well, hasCalls intentionally meant "has direct calls", as mentioned in the comment removed in that PR,

https://github.com/WebAssembly/binaryen/pull/9146/changes#diff-c2f8b3972bf7e18138c2a8fd6ffb653a15d0dc6132b7dff1c2dccf009e9f2ddeL226-L232

The idea was that inlining code with a direct call can lead to recursion in the inliner (it's not clear when to stop). Indirect calls never cause that issue, and it is actually good to inline code with them, as it increases the chance that they get optimized into direct calls.

But in general it seems better to do things otherwise...