[Webkit-unassigned] [Bug 244188] New: [DFG] Usekind of Div result turns to Int32 causing different answer

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=244188

            Bug ID: 244188
           Summary: [DFG] Usekind of Div result turns to Int32 causing
                    different answer
           Product: WebKit
           Version: WebKit Local Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sunyue20z at ict.ac.cn

./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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220822/1ee2c665/attachment.htm>