Closed Bug 484627 Opened 13 years ago Closed 11 years ago

TM: Generate code for js_CallTree directly on trace as LIR

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: gal, Assigned: gal)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file, 1 obsolete file)

This is a 10ms for SS.
Attached patch patch (obsolete) — Splinter Review
Mostly I was curious whether it can be done and whether it makes us faster.
Assignee: general → gal
Attached patch patchSplinter Review
Attachment #368761 - Attachment is obsolete: true
Testcase:

for (var i = 0; i < 10; ++i)
    for (var j = 0; j < 10; ++j)
	for (var k = 0; k < 10; ++k)
	    for (var l = 0; l < 10; ++l)
		for (var m = 0; m < 10; ++m)
		    for (var n = 0; n < 10; ++n)
			for (var o = 0; o < 10; ++o)
			    for (var p = 0; p < 10; ++p)
				for (var q = 0; q < 10; ++q)
				    ;

Without the patch:

whale:src gal$ time ./Darwin_OPT.OBJ/js -j x.js
real	0m3.963s
user	0m3.926s
sys	0m0.023s

With the patch:

whale:src gal$ time ./Darwin_OPT.OBJ/js -j x.js
real	0m3.486s
user	0m3.449s
sys	0m0.026s
Attachment #414166 - Flags: review?(dvander)
Comment on attachment 414166 [details] [diff] [review]
patch

>+    nested->setTarget(lir->ins0(LIR_label));
>+    LIns* done2 = lir->insBranch(LIR_jf,
>+                                 lir->ins_eq0(lir->insLoad(LIR_ldp,
>+                                                           lirbuf->state,
>+                                                           offsetof(InterpState, lastTreeCallGuard))),
>+                                 NULL);

This has to be lir->ins_peq0

r=me with that
Attachment #414166 - Flags: review?(dvander) → review+
http://hg.mozilla.org/tracemonkey/rev/5db68c6f83ab
Whiteboard: fixed-in-tracemonkey
This totally broke the X64 backend, I see 41 failures in trace-tests.
That fixes 64-bit, but now I get lots of i386 failures -- 41 on debug builds, 4 on optimised builds.

I find the testing procedure described below to be very helpful in avoiding this kind of thing:
http://blog.mozilla.com/nnethercote/2009/11/18/nanojit-test-coverage/
Andreas did another follow-up:

http://hg.mozilla.org/tracemonkey/rev/50ba13f9d0f2

It's now working again on both i386 and X64, thanks.
Status: NEW → ASSIGNED
Hi guys.  This patch triggers the nanoassert at Assembler.cpp:231

#ifdef NANOJIT_IA32
        NanoAssert((_allocator.active[FST0] && _fpuStkDepth == -1) ||
            (!_allocator.active[FST0] && _fpuStkDepth == 0));
#endif

when I click on the LOGIN button in at this website:

http://www.optionsxpress.com (top right corner)

Before I attach a backtrace, can you reproduce this?
(32-bit linux moz-central, and debugging code must be turned on, obviously)
I don't know how to interpret the silence.  Is this nanoassert trivial, so it
can be removed?  Can no one reproduce my problem?

I removed the --enable-debug from my .mozconfig so I can get some work done, but
I'd be happy to put it back if anyone needs/wants me to.

BTW, why do the nightly builds no longer have debugging-symbols/crash-reporting 
enabled?  In the 'old days' the crash-reporter actually got the devs to take
notice of a problem. 

True, a nanoassert is not the same as a real crash, but somebody put it there
for a reason.  Maybe the reason is obsolete now?
http://hg.mozilla.org/mozilla-central/rev/50ba13f9d0f2
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.