Bug 258302

https://github.com/microsoft/onnxruntime/issues/15644

https://forum.babylonjs.com/t/webassembly-error-havok-project-in-old-ios-device-iphone-6s/40213

https://github.com/emscripten-core/emscripten/issues/19619

Are reporting, possibly related issues.

<rdar://problem/111050621>

I wonder if this is already fixed by https://bugs.webkit.org/show_bug.cgi?id=257842

The description of the fix certainly sounds very similar to the issue encountered. Will this be landing in 16.6 (possibly in the beta)?

(In reply to John Hankinson from comment #4)
> The description of the fix certainly sounds very similar to the issue
> encountered. Will this be landing in 16.6 (possibly in the beta)?

Apple does not comment on the content of future releases.

I checked with a nightly though, and it seems that the bug still reproduces.

Thanks for the links to other issues, this is super helpful!

Is there any chance I can get source for a smaller test case that reproduces this, or source for your site itself? It would be super helpful for bisecting the root cause.

On my end, I have confirmed that in an nightly build, turning off our highest tier fixes this bug: 

```
265333@main % __XPC_JSC_useOMGJIT=0 ./run-webkit-archive
```

setting defaultB3OptLevel=0 or disabling wasm call inlining does not fix the bug.

Next I would like to bisect by function index.

I've emailed you the WAT functions involved, the source is quite long, but I think we can narrow it down to a single function as they all perform similar operations. Interestingly, I have been informed, although cannot verify it myself, that this issue is not present on an M1 mac, which I would have expected to generate the same aarch64 output from codegen as the mobile soc?

Let me know if there is anything I can help with re. the WAT functions or testing.

Are there any updates on progress with this yet?

```__XPC_JSC_validateOptions=1 __XPC_JSC_dumpOMGDisassembly=1 __XPC_JSC_omgAllowlist=/Users/justin_michaud/Downloads/265333@main/allow.txt __XPC_JSC_useWebAssemblyOSR=0 __XPC_JSC_useConcurrentJIT=0 __XPC_JSC_maximumWasmDepthForInlining=0 __XPC_JSC_maximumWasmCalleeSizeForInlining=0 DYLD_FRAMEWORK_PATH=/Volumes/WebKit/ReleaseVersion/OpenSource/WebKitBuild/Release __XPC_DYLD_FAMEWORK_PATH=/Volumes/WebKit/ReleaseVersion/OpenSource/WebKitBuild/Release /Volumes/WebKit/ReleaseVersion/OpenSource/WebKitBuild/Release/Safari.app/Contents/MacOS/Safari -ExtensionsEnabled NO```

with sandbox disabled (see patch) and allow list:
```
12
```

reproduces the issue, producing the attached assembly

Created attachment 466936 [details]
Bad disassembly

Created attachment 466937 [details]
Disable sandbox to load allow list

The culprit:

(call $probe_begin (i32.const 22))
          (call $probe (i64x2.extract_lane 0 (local.get $l25)))
          (call $probe (i64x2.extract_lane 1 (local.get $l25)))
          (call $probe (i64x2.extract_lane 0 (local.get $l63)))
          (call $probe (i64x2.extract_lane 1 (local.get $l63)))
          (call $probe (i64x2.extract_lane 0 (local.get $l42)))
          (call $probe (i64x2.extract_lane 1 (local.get $l42)))
          (call $probe32 (local.get $p0))
          (call $probe (i64x2.extract_lane 0 (v128.load offset=16 (local.get $p0))))
          (call $probe (i64x2.extract_lane 1 (v128.load offset=16 (local.get $p0))))

          (i32.eqz
              (v128.any_true
                (local.get $l42)))
          (local.set $debug32)
          (call $probe32 (local.get $debug32))

          (v128.not
              (local.get $l42)) <---------------------------------------Here is the first difference
          (local.set $debug128)
          (call $probe (i64x2.extract_lane 0 (local.get $debug128)))
          (call $probe (i64x2.extract_lane 1 (local.get $debug128)))
(call $probe_end (i32.const 22))

Pull request: https://github.com/WebKit/WebKit/pull/18827

Committed 269080@main (f9a3a2147af0): <https://commits.webkit.org/269080@main>

Reviewed commits have been landed. Closing PR #18827 and removing active labels.