Closed Bug 538484 Opened 10 years ago Closed 10 years ago
TM: generating bogus "ov ld1" sequence
This is probably a Nanojit bug, but TM may bear some responsibility too. To reproduce: TMFLAGS=readlir js -j -e "const platform='linux2'; const libdir='/home/njn/moz/ws5/js/src/trace-test/lib/';" -f /home/njn/moz/ws5/js/src/trace-test/lib/prolog.js -f /home/njn/moz/ws5/js/src/trace-test/tests/basic/regexpLastIndex.js The generated code is: 15: ld1 = ld sp[-32] ... 68: ov1 = ov ld1 69: xt3: xt ov1 -> pc=0x937ae40 imacpc=(nil) sp+16 rp+0 (GuardID=011) Prior to optimization, the code is: 15: ld3 = ld sp[-32] ... 76: add2 = add ld3, 0 77: ov2 = ov add2 78: xt3: xt ov2 -> p So the ov/xt should be removed when the 'add X, 0' is removed. The result of the ov check in the optimized code is unpredictable, it depends entirely what code appears beforehand. But it's only a performance bug because if we exit needlessly we just end up taking a slower path. FWIW, this was found with a revamped version of the LIR type-checker (bug 463137) that I'm working on.
The patch works! The ov/xt pair is removed.
Attachment #420637 - Flags: review- → review+
Turns out it was entirely TM's fault. http://hg.mozilla.org/tracemonkey/rev/52f371d2e194 BTW, this was found with a revamped LIR type-checker (see bug 463137).
QA Contact: nanojit → general
Summary: nanojit: generating bogus "ov ld1" sequence → TM: generating bogus "ov ld1" sequence
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.