Bug 244188 – [DFG] Usekind of Div result turns to Int32 causing different answer

• Status: NEW
• Component: JavaScriptCore

[Yue Sun]

./path/to/jsc test.js --useConcurrentJIT=0 --forceWeakRandomSeed=1 --jitPolicyScale=0
./path/to/jsc test.js --useConcurrentJIT=0 --forceWeakRandomSeed=1 --jitPolicyScale=0.1

var CreateBaseline = false; 

var debugTestNum = -1; 

var test_values = [-5, 248, 654, -1026];

function rem3(x) {
  x = x | 0;
  return (x | debugTestNum / x + x) % 3 | 0;
}

function testSignedDivStrengthReduction() {
  var i = 0;
  test_values.forEach(function (value) {
    print("Test# " + i + "(" + value + ") :\t\t Found " + rem3(value));
    print("Test# " + i + "(" + value + ") :\t\t Found " + rem3(value));
    ++i;
  });
}

testSignedDivStrengthReduction();

We run the script using options listed above. In this PoC, function rem3() calculate an expression. Since the operand type of operation "or" and "mod" should be Int32, JSC label the usekind of operands as Int32 during the DFG backward propagation phase, which lead to problem. In Low Level Interpreter, when x=-5, JSC would calculate div first, which is 0.2, then plus -5(x) to get -4.8, then turn -4.8 to -4 use truncation, finally calculate -5 | -4. However, in DFG, after div, the 0.2 is first truncate to 0 before adding -5, leading to inconsistent behavior. The PoC below also have this problem.

function f(v) {
  var result;
  result = ((v) % 0 + 1)|0;
  return result;
}
noInline(f);
var x;
for (i = 0; i < 2; ++i) {
  x = f(1);
  print(x);
}

In DFGSpeculativeJIT, when lowering ArithMod, if the demoninator is 0, they directely put 0 as result, instead of NaN. FTL also has the same issue. 

Our suggestion is that, in DFG backward propagation, label the usekind of operation div and mod itself as "use as number". In this case, the ArithAdd following div and mod operation would turn to DoubleAdd, which make sense.

[Radar WebKit Bug Importer]

<rdar://problem/99268137>