538484 - TM: generating bogus "ov ld1" sequence

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Nicholas Nethercote [inactive]]

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.

Comment 1

[Andreas Gal :gal]

Attachment: patch

Comment 2

[Nicholas Nethercote [inactive]]

The patch works!  The ov/xt pair is removed.

Comment 3

[Nicholas Nethercote [inactive]]

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).

Comment 4

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/52f371d2e194