Closed Bug 868206 Opened 11 years ago Closed 11 years ago
Assertion failure: !minimal
Interval(interval), at ion/Backtracking Allocator .cpp
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
This testcase WFM on tip. Does it still crash for you?
(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.
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.
Assignee: general → bhackett1024
Attachment #747391 - Flags: review?(jdemooij)
Attachment #747391 - Flags: review?(jdemooij) → review+
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.
Attachment #749498 - Flags: review?(jdemooij)
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?
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.
Attachment #749498 - Flags: review?(jdemooij) → review+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
10 years ago
You need to log in before you can comment on or make changes to this bug.