Bugzilla

This has a simplified test case derived from the original, and some very minor tweaks to Ion and arm64 lowering to reproduce the original problem in a controlled setting using only 32-bit operands.  Basically, we disable constant folding for MulI and force the lowering of MulI to useRegisterAtStart for both its input operands.

To use this, apply the patch, then make a build with --enable-debug --enable-simulator=arm64 (or run natively on arm64 hardware), then run the shell as `.../js --wasm-compiler=ion .../jit-test/tests/wasm/regress/bug1707774.js`.  The assert should be triggered.  Running with IONFLAGS=regalloc it will be possible to observe the confused register use in the MulI instruction: both inputs, which are distinct, use the same register.

I believe there is *nothing* special about using MulI here or about being on arm64, it is just a clean and localized way to demonstrate the problem, and meshes with the discussion earlier on the bug.

This has a simplified test case derived from the original, and some very minor tweaks to Ion and arm64 lowering to reproduce the original problem in a controlled setting using only 32-bit operands.  Basically, we disable constant folding for MulI and force the lowering of MulI to useRegisterAtStart for both its input operands.

To use this, apply the patch, then make a build with --enable-debug --enable-simulator=arm64 (or run natively on arm64 hardware), then run the shell as `.../js --wasm-compiler=ion .../jit-test/tests/wasm/regress/bug1707774.js`.  The assert should be triggered.  Running with IONFLAGS=regalloc it will be possible to observe the confused register use in the MulI instruction: both inputs, which are distinct, use the same register.

I believe there is *nothing* special about using MulI here or about being on arm64 or indeed about using wasm code, it is just a clean and localized way to demonstrate the problem, and meshes with the discussion earlier on the bug.