916770 - Odinmonkey: ARM constant pool failures

Status: RESOLVED WORKSFORME

(Core :: JavaScript: WebAssembly, defect)

Description

[Douglas Crosher [:dougc]]

There are some jit-test failures that appear to be caused by issues with the constant
pools on the ARM backend. They fail on JS_ASSERT(label->used()) but the label use
was skipped due to an OOM being flagged by a bail-out from a constant pool failure.

    --ion-eager --ion-check-range-analysis tests/jaeger/testSetTypedFloatArray.js
    --ion-eager tests/jaeger/testSetTypedIntArray.js
    --ion-eager --ion-check-range-analysis tests/jaeger/testSetTypedIntArray.js

[Pools] [0] Inserting instruction(5692) caused a spill
[Pools] [0] Attempting to dump the pool
[Pools] [0] Dumping 36 bytes
[Pools] [0] Pushing entry 0 in pool 0 into the backwards section.
[Pools] [0] Entry 0 in pool 1 is before the pool.
[Pools] [0] Fixing offset to 288
[Pools] [0] Pushing entry 1 in pool 1 into the backwards section.
[Pools] [0] Pushing entry 2 in pool 1 into the backwards section.
[Pools] [0] Pushing entry 3 in pool 1 into the backwards section.
[Pools] [0] Pushing entry 4 in pool 1 into the backwards section.
[Pools] [0] Pushing entry 5 in pool 1 into the backwards section.
[Pools] [0] Finishing pool 0
[Pools] [0] Linking entry 5 in pool 1
[Pools] [0] Fixing offset to -2520
[Pools] [0] Linking entry 4 in pool 1
[Pools] [0] Fixing offset to -1540
[Pools] [0] Linking entry 3 in pool 1
[Pools] [0] Fixing offset to -1528
[Pools] [0] Linking entry 2 in pool 1
[Pools] [0] Fixing offset to -1520
[Pools] [0] Linking entry 1 in pool 1
[Pools] [0] Fixing offset to -584
[Pools] [0] Linking entry 0 in pool 0
[Pools] [0] Fixing offset to -1788
[Pools] [0]***Offset was still out of range!***
[Pools] [0] Too complicated; bailingp


    --ion-eager --ion-check-range-analysis tests/collections/Map-get.js

[Pools] [0] Inserting instruction(36804) caused a spill
[Pools] [0] Attempting to dump the pool
[Pools] [0] Dumping 60 bytes
[Pools] [0] Pushing entry 0 in pool 0 into the backwards section.
[Pools] [0] Pushing entry 1 in pool 0 into the backwards section.
[Pools] [0] Pushing entry 2 in pool 0 into the backwards section.
[Pools] [0] Pushing entry 3 in pool 0 into the backwards section.
[Pools] [0] Pushing entry 4 in pool 0 into the backwards section.
[Pools] [0] Pushing entry 5 in pool 0 into the backwards section.
[Pools] [0] Entry 0 in pool 1 is before the pool.
[Pools] [0] Fixing offset to 936
[Pools] [0] Finishing pool 5
[Pools] [0] Linking entry 5 in pool 0
[Pools] [0] Fixing offset to -2524
[Pools] [0]***Offset was still out of range!***
[Pools] [0] Too complicated; bailingp

There is a hack patch to address a corner case in bug 906964, but the errors
seen here are not just corner cases, and appear to be a long way out of range.

Comment 1

[Douglas Crosher [:dougc]]

A reduced failing test:

testSetTypedFloatArray.js:

function testSetTypedFloat64Array(k) {
    var ar = new Float64Array(8);
    ar[k] = 1;
    ar[k+2] = "3";
}

for (var i = 0; i <= 10; i++) {
    testSetTypedFloat64Array(0);
}


js --ion-eager --ion-check-range-analysis  -f testSetTypedFloatArray.js

Comment 2

[Douglas Crosher [:dougc]]

The reduced test in comment 1 was no longer crashing here, but the
original testSetTypedFloatArray.js jit-test did.  There is an alternative
reduced test:

testSetTypedIntArray.js:

function testSetTypedUint32Array(k) {
    var ar = new Uint32Array(8);
    ar[5] = { };
    ar[6] = ar;
    ar[4] = 800 * 800 * 800 * 800 * 800;
    var t = k + 555;
    var L = ar[k+7] = t + 5;
    ar[0] = 12.3;
    ar[8] = 500;
    ar[k+8] = 1200;
    ar[k+1] = 1;
    ar[k+3] = 1;
    assertEq(ar[0], 12);
    assertEq(ar[1], 1);
    assertEq(ar[3], 1);
    assertEq(ar[4], 4060086272);
    assertEq(ar[8], undefined);
}

for (var i = 0; i <= 1; i++) {
    testSetTypedUint32Array(0);
}

js --ion-eager -f testSetTypedIntArray.js

The IONFLAGS=pools output:
[Pools] [0] Linking entry 8 in pool 1
[Pools] [0] Fixing offset to -352
[Pools] [0] Linking entry 7 in pool 1
[Pools] [0] Fixing offset to -336
[Pools] [0] Linking entry 6 in pool 1
[Pools] [0] Fixing offset to -312
[Pools] [0] Linking entry 5 in pool 1
[Pools] [0] Fixing offset to -272
[Pools] [0] Linking entry 4 in pool 1
[Pools] [0] Fixing offset to -260
[Pools] [0] Linking entry 3 in pool 1
[Pools] [0] Fixing offset to -252
[Pools] [0] Linking entry 2 in pool 1
[Pools] [0] Fixing offset to -236
[Pools] [0] Linking entry 1 in pool 1
[Pools] [0] Fixing offset to -184
[Pools] [0] Linking entry 2 in pool 0
[Pools] [0] Fixing offset to -1032
[Pools] [0]***Offset was still out of range!***
[Pools] [0] Too complicated; bailingp

Comment 3

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.

Comment 4

[Benjamin Bouvier [:bbouvier] (inactive)]

We now test Spidermonkey on real and simulated ARM devices in automation, so this would now fail hard during testing (I hope!). Also I recall we fixed some ARM constant pools bugs a few years ago, so we should be fine. Closing.