Closed Bug 538484 Opened 10 years ago Closed 10 years ago

TM: generating bogus "ov ld1" sequence

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: njn, Assigned: gal)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file)

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.
Attached patch patchSplinter Review
The patch works!  The ov/xt pair is removed.
Attachment #420637 - Flags: review-
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).
Component: Nanojit → JavaScript Engine
QA Contact: nanojit → general
Summary: nanojit: generating bogus "ov ld1" sequence → TM: generating bogus "ov ld1" sequence
Whiteboard: fixed-in-tracemonkey
http://hg.mozilla.org/mozilla-central/rev/52f371d2e194
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.