Closed Bug 484627 Opened 15 years ago Closed 13 years ago

TM: Generate code for js_CallTree directly on trace as LIR


(Core :: JavaScript Engine, defect)

Not set





(Reporter: gal, Assigned: gal)


(Whiteboard: fixed-in-tracemonkey)


(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

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]

>+    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+
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:
Andreas did another follow-up:

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

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

when I click on the LOGIN button in at this website: (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?
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.