484627 - TM: Generate code for js_CallTree directly on trace as LIR

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Andreas Gal :gal]

This is a 10ms for SS.

Comment 1

[Andreas Gal :gal]

Attachment: patch

Mostly I was curious whether it can be done and whether it makes us faster.

Comment 2

[Andreas Gal :gal]

Attachment: patch

Comment 3

[Andreas Gal :gal]

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

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

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

Comment 5

[Andreas Gal :gal]

http://hg.mozilla.org/tracemonkey/rev/5db68c6f83ab

Comment 6

[Nicholas Nethercote [inactive]]

This totally broke the X64 backend, I see 41 failures in trace-tests.

Comment 7

[Andreas Gal :gal]

64-bit fix:

http://hg.mozilla.org/tracemonkey/rev/628a7cee4fa5

Comment 8

[Nicholas Nethercote [inactive]]

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/

Comment 9

[Nicholas Nethercote [inactive]]

Andreas did another follow-up:

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

It's now working again on both i386 and X64, thanks.

Comment 10

[walter sheets]

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)

Comment 11

[walter sheets]

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?

Comment 12

[Chris Leary [:cdleary] (not checking bugmail)]

http://hg.mozilla.org/mozilla-central/rev/50ba13f9d0f2