Closed
Bug 505662
Opened 15 years ago
Closed 15 years ago
nanojit: kill operandCount
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: n.nethercote, Assigned: n.nethercote)
References
Details
(Whiteboard: fixed-in-nanojit, fixed-in-tracemonkey, fixed-in-tamarin)
Attachments
(1 file, 2 obsolete files)
32.17 KB,
patch
|
edwsmith
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•15 years ago
|
||
The patch in bug 502778 gets rid of the worst uses of operandCount[]; after that's landed there'll just be some mopping up.
Depends on: 502778
Assignee | ||
Comment 2•15 years ago
|
||
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[].
Assignee | ||
Comment 3•15 years ago
|
||
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.)
Attachment #413250 -
Flags: review?(graydon)
Assignee | ||
Comment 4•15 years ago
|
||
Attachment #413250 -
Attachment is obsolete: true
Attachment #413251 -
Flags: review?(graydon)
Attachment #413250 -
Flags: review?(graydon)
Comment 5•15 years ago
|
||
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)
Attachment #413251 -
Flags: review?(graydon)
Attachment #413251 -
Flags: review?(edwsmith)
Attachment #413251 -
Flags: review+
Assignee | ||
Comment 6•15 years ago
|
||
Attachment #413251 -
Attachment is obsolete: true
Attachment #413963 -
Flags: review?(edwsmith)
Attachment #413251 -
Flags: review?(edwsmith)
Updated•15 years ago
|
Attachment #413963 -
Flags: review?(edwsmith) → review+
Assignee | ||
Comment 7•15 years ago
|
||
Whiteboard: fixed-in-nanojit
http://hg.mozilla.org/tracemonkey/rev/00d38ab1a157
http://hg.mozilla.org/tamarin-redux/rev/2dc47ba046ee
Whiteboard: fixed-in-nanojit → fixed-in-nanojit, fixed-in-tracemonkey, fixed-in-tamarin
Assignee | ||
Comment 9•15 years ago
|
||
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•15 years ago
|
||
We are working on both tracemonkey and tamarin.
Assignee | ||
Comment 11•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•