868206 - Assertion failure: !minimalInterval(interval), at ion/BacktrackingAllocator.cpp

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: stack

Object.getOwnPropertyNames(this);

asserts js debug shell on m-c changeset da429c311864 with --ion-eager --ion-regalloc=backtracking at Assertion failure: !minimalInterval(interval), at ion/BacktrackingAllocator.cpp

Due to its simplicity, this blocks fuzzing with --ion-regalloc=backtracking

Comment 1

[Brian Hackett [Laid off!]]

This testcase WFM on tip.  Does it still crash for you?

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Brian Hackett (:bhackett) from comment #1)
> This testcase WFM on tip.  Does it still crash for you?

Yes, it still reproduces on 64-bit non-threadsafe debug non-deterministic js shell on m-c changeset rev e19d0885977c.

Comment 3

[Brian Hackett [Laid off!]]

Attachment: patch

OK, got this to repro with Gary's configure options from IRC.  The problematic instruction here was a Concat whose inputs were the same, and which it wanted to be in two different fixed registers.  The backtracking allocator didn't know how to satisfy this.

Comment 4

[Brian Hackett [Laid off!]]

Attachment: followup

After fixing this, noticed a couple existing issues where the backtracking allocator was broken.  With these, jit-tests pass with --ion-eager --ion-regalloc=backtracking.

Comment 5

[Jan de Mooij [:jandem]]

Comment on attachment 749498 [details] [diff] [review]
followup

Review of attachment 749498 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/ion/Lowering.cpp
@@ +484,5 @@
>      LFilterArguments *lir = new LFilterArguments(useFixed(string, CallTempReg0),
>                                                   tempFixed(CallTempReg1),
>                                                   tempFixed(CallTempReg2));
>  
> +    return assignSnapshot(lir) && add(lir, ins) && assignSafepoint(lir, ins);

Why does LFilterArguments need a safepoint if it does not use callVM?

Comment 6

[Brian Hackett [Laid off!]]

The bailout in LFilterArguments happens after the call it makes, and holds the inputs to the FilterArguments live even though they might have been clobbered.  Those inputs are inputs to the FilterArguments instruction which the regalloc should be able to put in registers.  Using a safepoint causes an OsiPoint instruction after the FilterArguments to hold the inputs used in the bailout, and since the regalloc can't introduce moves between an instruction and its OsiPoint (as enforced by some nasty code in the allocator) this will force those inputs to be in memory.

Comment 7

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3bfbd1ed214d

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3bfbd1ed214d