WarpBuilder: fix remaining jit-tests
Categories
(Core :: JavaScript Engine: JIT, task, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox76 | --- | fixed |
People
(Reporter: jandem, Assigned: jandem)
References
Details
Attachments
(6 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
Most of the remaining failures are tests we can easily fix to pass with WarpBuilder, for example debugger tests that now stay in Ion/Warp without bailing out where the Ion backend is optimizing out variables.
Assignee | ||
Comment 1•4 years ago
|
||
The test is checking "a" is being optimized out by the JIT. For this to work, it
needs to still be a loop phi after redundant phi elimination. Without WarpBuilder
we bail out and then OSR into the loop resulting in OSR phis, but WarpBuilder
doesn't bailout and OSR.
Assignee | ||
Comment 2•4 years ago
|
||
Depends on D69335
Assignee | ||
Comment 3•4 years ago
|
||
Depends on D69337
Assignee | ||
Comment 4•4 years ago
|
||
Unfortunately this is failing due to bug 1505387. I looked into fixing that, but
it's not simple.
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
oomAtAllocation throws if the argument is <= 0 so make sure that can't happen by
breaking out of the loop if limit would be set to 0.
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
This fixes the last test failure. The debugger can collect "allocation metadata"
for allocated objects. This test is checking that the objects in the array have
different allocation sites associated with them.
Ion can fail this test because MNewArray is marked as non-effectful so it doesn't
get its own resume point, resulting in the allocation site matching that of the
object literal before it.
We could fix this by making MNewArray* and similar instructions effectful, but
I'm concerned about the perf impact of changing that just for the unlikely event
the memory profiler is being used. Since this is a pre-existing issue, this tweaks
the test to work around it.
Assignee | ||
Updated•4 years ago
|
Pushed by jdemooij@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/cf76864b4063 part 1 - Ensure we have a loop phi in optimized-out-03.js jit-test. r=iain https://hg.mozilla.org/integration/autoland/rev/b38f05345877 part 2 - Fix some jit-tests that rely on variables not being optimized out. r=iain https://hg.mozilla.org/integration/autoland/rev/10eb39d10994 part 3 - Fix some jit-tests to not rely on specific error messages. r=iain https://hg.mozilla.org/integration/autoland/rev/563427cce5fc part 4 - Disable WarpBuilder for bug-1444604-reduced.js. r=iain https://hg.mozilla.org/integration/autoland/rev/13fceb3484de part 5 - Fix array-push-multiple* jit-tests to not call oomAtAllocation(0). r=iain
Comment 8•4 years ago
|
||
bugherder |
Pushed by jdemooij@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a3bc77baa519 part 6 - Tweak Memory-drainAllocationsLog-01.js. r=iain
Assignee | ||
Updated•4 years ago
|
Comment 10•4 years ago
|
||
bugherder |
Description
•