Bugzilla

Would also be extremely weird if that patch - in the masm - caused a problem in the move resolver (ignoring the fact about simd not being enabled at all and the patch being simd-only).  Also the test case should not run with !simd, so should not be at fault.

Possibly relevant, it is possible for privileged extensions to use SIMD, this facilitates the Bergamot extension.  So there's a variable there around that.  Jit-tests should not normally be affected: they should continue to see !simd, unless something went wrong with the prefs.  But startup code could be affected because it is privileged and the predicate tests isSystemOrAddonPrinicipal().  There is some logic around this in XPCJSContext.cpp that changes between early and late beta (search for useWasmSimdWormhole) but I don't see how this matters apart from a possible C++ compiler bug.

All that said, there should be no SIMD code in the self-hosted code, so no obvious trigger.  Maybe worth investigating with some asserts, just to rule out.

Would also be extremely weird if that patch - in the masm - caused a problem in the move resolver (ignoring the fact about simd not being enabled at all and the patch being simd-only).  Also the test case should not run with !simd, so should not be at fault.

Possibly relevant, it is possible for privileged extensions to use SIMD in FF88, this facilitates the Bergamot extension.  So there's a variable there around that.  Jit-tests should not normally be affected: they should continue to see !simd, unless something went wrong with the prefs.  But startup code could be affected because it is privileged and the predicate tests isSystemOrAddonPrinicipal().  There is some logic around this in XPCJSContext.cpp that changes between early and late beta (search for useWasmSimdWormhole) but I don't see how this matters apart from a possible C++ compiler bug.

All that said, there should be no SIMD code in the self-hosted code, so no obvious trigger.  Maybe worth investigating with some asserts, just to rule out.