[compare_jit] Investigate whether testcase in bug 1279898 can be generated

[nth10sd]

Hannes was wondering whether the testcase for bug 1279898 can be generated, so filing this as a start.

@jruderman, what do you think?

[jruderman]

Here's a variant of the testcase that is very similar to what gen-asm.js can create, and still triggers the bug. In particular, the array views are created in a closure, and the loop is moved outside the function.

function asmModule(heap)
{
    var i32 = new Int32Array(heap);
    var f32 = new Float32Array(heap);

    function f() {
        var b0 = 0.0;
        var b3 = 0.0;

        i32[0] = 1;
        b0 = f32[0];

        i32[0] = 4;
        b3 = f32[0];

        return +b3;
    }

    return f;
}

var f = asmModule(new ArrayBuffer(4096));

for (let i = 0; i < 3; ++i) {
    print(f());
}

Built the version just before the patch using:

~/funfuzz/autobisect-js/autobisect.py --build="--enable-more-deterministic --enable-debug --without-intl-api" -s 46178702a3ca -e 01bfa6d7d561

Tested using:

~/funfuzz/js/compareJIT.py ~/funfuzz/known/mozilla-central/ ~/shell-cache/js-dbg-64-dm-clang-intlDisabled-darwin-46178702a3ca/js-dbg-64-dm-clang-intlDisabled-darwin-46178702a3ca ~/2.js

[jruderman]

jsfunfuzz has become slightly more complex than I can reason about :/

Things that MIGHT help uncover this kind of bug:

• Generate for (let i = 0; i < 3; ++i) { dumpln(f()); }, or its constituent parts, more often
• Generate simple loops within asm.js functions (and perhaps other types of control flow)
• Try to trigger alias analysis more often:
  • In asmJsFunction: generate longer functions (more assignment statements)
  • In asmIndex: return 0 more often
  • Rewrite jsfunfuzz to somehow intercept all internal calls (including asmIndex and doublishMemberExpr) in order to cache and reuse pieces of JavaScript programs. This would help test GVN in addition to alias analysis.
• Rewrite most of jsfunfuzz into something that has more coherent knowledge of types. At least everything whose argument list starts with "(d, b)". This would mean basically rewriting gen-grammar.js and gen-type-aware-code.js.
  • Inward, outward, or some combination?
  • Inward: Decide desired types first, then try to create an expression with that type
    • Problem: must add explicit caching if I want to reuse expressions
  • Outward: Combine expressions with known types into more complex expressions
    • Problem: must keep track of the scope within which each expression is valid, or heavily shadow so the "same" expressions are valid everywhere even though variables refer to different bindings
  • Verify that actual types match expected types?
  • At the top loop, to downgrade entries that don't match
  • Anywhere, when "intentionally create invalid code" is disabled, to issue a warning that there is a bug in the parts of the fuzzer that try to create valid code
  • Add swarming at the same time?
  • Add caching/reuse at the same time?
  • How to square this with also testing JS's type coercion and dynamic types?
  • How to create HOFs that take functions as arguments?
  • How to create HOFs that return functions?

[nth10sd]

During the London meetup, I also mentioned to :bbouvier about jsfunfuzz (incl. the gen-asm.js part) - we might also need to start testing WebAssembly at some point. Our current coverage is only whatever randorderfuzz chooses to pull in from the tests.

This might only be tangentially related though, as I'm not sure how much independently related asm.js/wasm are. Will it be worth noting how wasm would fit in the picture above?