505662 - nanojit: kill operandCount

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Nicholas Nethercote [inactive]]

operandCount[] is a rich source of confusion and bugs.  See bug 495158 and bug 504705 for examples.

The first problem is that the meaning of operandCount isn't obvious, as LIR instructions can contain fields that you might think are "operands" but aren't really "operands", eg. GuardRecords in guards.

The second problem is that in functions that use operandCount[], some of the opcodes are named explicitly, but some are handled implicitly via the operandCount[].  This means that a lot of the operandCounts in LIRopcode.tbl are never actually used, and so there's no way of testing if they're correct.  Also, the mix of explicit/implicit handling makes it very easy to get things wrong when introducing new opcodes or changing existing ones.

Where operandCount[] is currently used -- LInsHashSet::hashcode(), LInshHashSet::equals() and LiveTable::live() are the important places, the rest are just assertions that specific operandCount[] values are sensible -- I propose changing the switches to just use opcode names explicitly.  The switches will be longer, but operandCount[] and the operandCount field in LIRopcode.tbl will be removed.  And the switches will be much less error-prone.

Comment 1

[Nicholas Nethercote [inactive]]

The patch in bug 502778 gets rid of the worst uses of operandCount[];  after that's landed there'll just be some mopping up.

Comment 2

[Nicholas Nethercote [inactive]]

assemble_general() in lirasm is another offender.  It can be fixed by handling all opcodes directly in the big switch in assembleFragment(), instead of handling some directly and some via operandCount[].

Comment 3

[Nicholas Nethercote [inactive]]

Attachment: patch

assemble_general() was fixed elsewhere.

This patch cleans up the remaining uses.

- It removes the now-unused 'operands' argument from LIRopcode.tbl and all
  the OPDEF macros.

- It removes operandCount[].

- It uses a big switch in live() instead of operandCount[].  There are no
  performance concerns as live() is debug printing code.

- It removes the now-defunct assertions about operand counts in CseFilter::ins*().

- Since this touched every opcode line in LIRopcode.tbl, I took the chance
  to make some other minor modifications to that file that made it easier to
  apply consistent whitespace formatting:

  - Renamed OPDEF64 and OPD64, which is the same length as OPDEF.  (Bug
    504507 will merge them anyway.)
    
  - Used short names like "__3" and "__24_64" instead of the longer "unused3"
    and "unused24_64" for unused opcodes.

I tested the code by comparing the output of TMFLAGS=liveness before and
after the patch was applied on some big programs.  The output was the same.
(This required the tweak discussed in bug 528857.)

Comment 4

[Nicholas Nethercote [inactive]]

Attachment: patch, v2

Comment 5

[Graydon Hoare :graydon]

Comment on attachment 413251 [details] [diff] [review]
patch, v2

I'm fine with it, but it seems a little more than a superficial change, tagging edwin to approve also.

(Also needs a trivial lirasm hunk)

Comment 6

[Nicholas Nethercote [inactive]]

Attachment: patch v3, includes required lirasm change

Comment 7

[Nicholas Nethercote [inactive]]

http://hg.mozilla.org/projects/nanojit-central/rev/ab7d225a3c8b

Comment 8

[Leon Sha]

http://hg.mozilla.org/tracemonkey/rev/00d38ab1a157
http://hg.mozilla.org/tamarin-redux/rev/2dc47ba046ee

Comment 9

[Nicholas Nethercote [inactive]]

Tamarin needs an additional patch for a single use of OPDEF/OPDEF64 in CodegenLIR.cpp.  So Tamarin is currently broken.  It's a good idea to test before committing a change.  Generally Mozilla people merge NJ to TM, and Adobe people merge to TR;  I'm not sure where Sun people fit in there...

Comment 10

[Leon Sha]

We are working on both tracemonkey and tamarin.

Comment 11

[Nicholas Nethercote [inactive]]

http://hg.mozilla.org/mozilla-central/rev/00d38ab1a157