The following testcase asserts on ionmonkey revision a29f6c635516 (run with --ion -n -m --ion-eager): StrictEquality( true, new Boolean(true), false ); function StrictEquality( x, y, expect ) { result = ( x === y ); StrictEquality(y.environment !== Set.environment, true); }

Jan, it looks like the bug is that we're feeding a constant boolean into ToInt32(). It feels like handling that isn't a good fix though. The TypePolicy logic and lowering is kind of squirrelly and I kind of want to just refactor and separate out int32 from boolean specialization. Thoughts?

If TI knows a comparison is like bool === bool we will use specialization Int32 and lower to LCompare. If it's a strict comparison and we know one side is boolean, we use specialization Bool and lower to CompareB (Value === bool). Due to inlining etc, the MIR type may be more precise than what TI tells us, so if we have a Bool specialization we may still get two bool inputs and we want to switch the specialization to Int32 to match the first case (known bool === bool). The bug is that we don't want to return early in this case but want to insert MToInt32.

A testcase for this bug was automatically identified at js/src/jit-test/tests/ion/bug773587.js.