Closed Bug 484627 Opened 13 years ago Closed 11 years ago
TM: Generate code for js
_Call Tree directly on trace as LIR
This is a 10ms for SS.
Mostly I was curious whether it can be done and whether it makes us faster.
Assignee: general → 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 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+
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?
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.