Closed Bug 456833 Opened 17 years ago Closed 16 years ago

TM: aborts on loop edge not returning to header

Categories

(Core :: JavaScript Engine, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla1.9.1

People

(Reporter: bzbarsky, Assigned: gal)

Details

(Keywords: perf)

Attachments

(1 file)

Attached file Testcase
JS shell testcase attached. I'm sorry about all the other stuff going on here; it might be minimizable. With that testcase I get a trace abort: loop edge 148 -> 23, header 1124 Abort recording (line 3, pc 148): Loop edge does not return to header.
Andreas said he'd confirm that this is a dup of bug 456431 or else fix. /be
Assignee: general → gal
Flags: blocking1.9.1?
OS: Mac OS X → All
Hardware: PC → All
Target Milestone: --- → mozilla1.9.1
Looks like a perf edge case rather than a correctness bug, so not going to block... let me know if I'm missing something.
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P2
Keywords: perf
Target Milestone: mozilla1.9.1 → ---
This has been fixed a long time ago. 456431 was a related fix. Marking this fixed.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1
So.... I still get a trace abort on that testcase: Abort recording of tree /Users/bzbarsky/test.js:22@87 at /Users/bzbarsky/test.js:3@23: No compatible inner tree. Should I file a followup bug on that? Or is that sort of expected?
Flags: in-testsuite?
Is that a single abort and we catch it later, or do we fail to construct traces for the test case? The former is expected. We don't find a matching tree, compile one, trace the outer parts again, and everything is happy. If not, file a follow-up bug.
There is a single abort; I'm not sure whether we end up compiling a trace for the outermost loop here... Would there be at least two aborts if we do not?
I would think so, yes.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: