Closed Bug 607864 Opened 14 years ago Closed 14 years ago

TM: systematically annotate bytecode boundaries in LIR dumps

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: n.nethercote, Assigned: n.nethercote)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file)

patch (against TM 56425:6b9f7d6cd601)
3.25 KB, patch
dmandelin
: review+
Details | Diff | Splinter Review 
Bug 607244 added the LIR_comment bytecode, and applied it in a handful of places in TM.  This patch applies it in a much more systematic fashion -- one per bytecode.

Here's an example of the TMFLAGS=recorder output.  Since bug 607555 fixed the bytecode/LIR interleaving the extra comments are redundant:

00094: 155  getlocal 1
    ------------------------------ # JSOP_GETLOCAL
    $stack6 = ldi.sp sp[-32]
    sti.sp sp[0] = $stack6

00097: 155  getlocal 3
    ------------------------------ # JSOP_GETLOCAL
    sti.sp sp[8] = ldi2

00100: 155  getarg 0
    ------------------------------ # JSOP_GETARG
    sti.sp sp[16] = $stack2

00103: 155  int8 2
    ------------------------------ # JSOP_INT8
    sti.sp sp[24] = immi1/*2*/

00105: 155  getlocal 3
    ------------------------------ # JSOP_GETLOCAL
    sti.sp sp[32] = ldi2

00108: 155  mul
    ------------------------------ # JSOP_MUL
    About to try emitting guard_xov code for SideExit=0x8e79044 exitType=OVERFLOW
    sti.sp sp[24] = mulxovi1

00109: 155  one
    ------------------------------ # JSOP_ONE
    immd2 = immd 1
    immi3 = immi 1
    sti.sp sp[32] = immi3/*1*/

00110: 155  add
    ------------------------------ # JSOP_ADD
    About to try emitting guard_xov code for SideExit=0x8e79094 exitType=OVERFLOW
    addxovi1 = addxovi mulxovi1, immi3/*1*/ -> pc=0x8e43b0a imacpc=(nil) sp+40 rp+0 (GuardID=010)
    i2d2 = i2d addxovi1
    sti.sp sp[24] = addxovi1

00111: 155  getelem
    ------------------------------ # JSOP_GETELEM
    capacity3 = ldi.objcapacity $stack2[32]
    ltui4 = ltui addxovi1, capacity3
    xf6: xf ltui4 -> pc=0x8e43b0b imacpc=(nil) sp+32 rp+0 (GuardID=012)
    lshi3 = lshi addxovi1, immi2/*3*/
    slots3 = ldi.objslots $stack2[36]
    addi3 = addi slots3, lshi3
    ldi7 = ldi.slots addi3[4]
    ltui5 = ltui ldi7, JSVAL_TAG_CLEAR/*0xffff0000*/
    xf7: xf ltui5 -> pc=0x8e43b0b imacpc=(nil) sp+32 rp+0 (GuardID=013)
    ldd2 = ldd.slots addi3[0]
    std.sp sp[16] = ldd2



However, the new comments are much more useful in the TMFLAGS=afterdce dumps:

  ------------------------------ # JSOP_GETLOCAL
      $stack6 = ldi.sp sp[-32]
      sti.sp sp[0] = $stack6
  ------------------------------ # JSOP_GETLOCAL
      sti.sp sp[8] = ldi2
  ------------------------------ # JSOP_GETARG
      sti.sp sp[16] = $stack2
  ------------------------------ # JSOP_INT8
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_MUL
      sti.sp sp[24] = mulxovi1
  ------------------------------ # JSOP_ONE
      immi3 = immi 1
      sti.sp sp[32] = immi3/*1*/
  ------------------------------ # JSOP_ADD
      addxovi1 = addxovi mulxovi1, immi3/*1*/ -> pc=0x8e43b0a imacpc=(nil) sp+40 rp+0 (GuardID=010)
      sti.sp sp[24] = addxovi1
  ------------------------------ # JSOP_GETELEM
      capacity3 = ldi.objcapacity $stack2[32]
      ltui4 = ltui addxovi1, capacity3
      xf6: xf ltui4 -> pc=0x8e43b0b imacpc=(nil) sp+32 rp+0 (GuardID=012)
      lshi3 = lshi addxovi1, immi2/*3*/
      slots3 = ldi.objslots $stack2[36]
      addi3 = addi slots3, lshi3
      ldi7 = ldi.slots addi3[4]
      ltui5 = ltui ldi7, JSVAL_TAG_CLEAR/*0xffff0000*/
      xf7: xf ltui5 -> pc=0x8e43b0b imacpc=(nil) sp+32 rp+0 (GuardID=013)
      ldd2 = ldd.slots addi3[0]
      std.sp sp[16] = ldd2


It makes the 'afterdce' dumps as easy to read as the 'recorder' ones, which I think is definitely worth doing even if adds some redundant info in the 'recorder' ones.  It's particularly helpful when bytecodes end up having no LIR due to StackFilter and dead-code-elimination.

I'll stop fiddling with LIR dumps after this bug, I promise :)
Attachment #486549 - Flags: review?(dmandelin)
I was just looking at some Kraken LIR dumps, this is *really* nice.  It particularly gives you a good idea how good the LIR is.  For example, in imaging-darkroom, lots of bytecodes end up translated to a single LIR instruction, which shows that things are working really well.
Brendan asked for an example.  Here is a portion from the hottest loop of imaging-darkroom-data.js, line 77, which contains a lot of double arithmetic:

  ------------------------------ # JSOP_DOUBLE
      immd5 = immd 0.299
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_MUL
      muld4 = muld muld1, immd5/*0.299*/
  ------------------------------ # JSOP_DOUBLE
      immd6 = immd 0.587
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_MUL
      muld5 = muld muld2, immd6/*0.587*/
  ------------------------------ # JSOP_ADD
      addd1 = addd muld4, muld5
  ------------------------------ # JSOP_DOUBLE
      immd7 = immd 0.114
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_MUL
      muld6 = muld muld3, immd7/*0.114*/
  ------------------------------ # JSOP_ADD
      addd2 = addd addd1, muld6
  ------------------------------ # JSOP_SETLOCAL
      std.sp sp[-24] = addd2
  ------------------------------ # JSOP_DOUBLE
      immd8 = immd 0.596
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_MUL
      muld7 = muld muld1, immd8/*0.596*/
  ------------------------------ # JSOP_DOUBLE
      immd9 = immd 0.275
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_MUL
      muld8 = muld muld2, immd9/*0.275*/
  ------------------------------ # JSOP_SUB
      subd1 = subd muld7, muld8
  ------------------------------ # JSOP_DOUBLE
      immd10 = immd 0.321
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_MUL
      muld9 = muld muld3, immd10/*0.321*/
  ------------------------------ # JSOP_SUB
      subd2 = subd subd1, muld9
  ------------------------------ # JSOP_SETLOCAL
  ------------------------------ # JSOP_DOUBLE
      immd11 = immd 0.212
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_MUL
      muld10 = muld muld1, immd11/*0.212*/
  ------------------------------ # JSOP_DOUBLE
      immd12 = immd 0.523
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_MUL
      muld11 = muld muld2, immd12/*0.523*/
  ------------------------------ # JSOP_SUB
      subd3 = subd muld10, muld11
Another example for Brendan, where many JSOPs turn into a single LIR instruction:

  ------------------------------ # JSOP_INT8
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_ADD
  ------------------------------ # JSOP_GETGNAME
  ------------------------------ # JSOP_MUL
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_GETLOCAL
  ------------------------------ # JSOP_ADD
  ------------------------------ # JSOP_ADD
  ------------------------------ # JSOP_MUL
      sti.sp sp[16] = mulxovi2

This is thanks to CSE -- the same expression was computed earlier.
Comment on attachment 486549 [details] [diff] [review]
patch (against TM 56425:6b9f7d6cd601)

It's about time x became op.
Attachment #486549 - Flags: review?(dmandelin) → review+
http://hg.mozilla.org/tracemonkey/rev/e29367700eec
Whiteboard: fixed-in-tracemonkey
http://hg.mozilla.org/mozilla-central/rev/e29367700eec
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: