Closed Bug 588522 Opened 14 years ago Closed 10 years ago

remove JSOP_ENDINIT

Categories

(Core :: JavaScript Engine, defect)

Other Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla36

People

(Reporter: igor, Assigned: n.nethercote)

References

Details

Attachments

(1 file, 2 obsolete files)

Changes from the bug 572057 makes JSOP_ENDINIT a no-op. We should either remove it or at least make it annotation-only bytecode.
Summary: TM: remove JSOP_ENDITER → TM: remove JSOP_ENDINIT
It is simpler to have an opcode than try to set a srcnote on some other op -- what's the cost? /be
Still a valid non-TM bug?
Igor, ping?
Summary: TM: remove JSOP_ENDINIT → remove JSOP_ENDINIT
Assignee: general → nobody
Here's my analysis of how ENDINIT is currently used. We currently emit ENDINIT in four places: array literals, object literals, and two other cases involving iterators and destructuring. The only one of these that actually gets used meaningfully is the array literal one, in InitArrayElemOperation(). In that function, if we have INITELEM_ARRAY with a hole and the following op is ENDINIT, we set the array length. But AFAICT we'll have already set the array length appropriately from the NEWARRAY that must have occurred earlier. For example, if we have this: > var arr2 = [1, 2, , ]; The bytecode will look like this: > 00025: newarray 3 > 00029: one > 00030: initelem_array 0 > 00034: int8 2 > 00036: initelem_array 1 > 00040: hole > 00041: initelem_array 2 > 00045: endinit The ENDINIT causes us to set the array length to 3, but the NEWARRAY already did that. If the array contains a spread, this ENDINIT case won't apply because INITELEM_ARRAY isn't used after a spread. I added an assertion to check that the existing array length is always the same as what we set it to in the ENDINIT case, and it held in all the jit-tests and regression tests. Therefore, I think ENDINIT is safe to remove.
Attached patch Remove JSOP_ENDINIT (obsolete) (deleted) — Splinter Review
This patch removes JSOP_ENDINIT. It also removes three comments that refer to decompilation, which pleases me greatly.
Attachment #8508157 - Flags: review?(jorendorff)
Assignee: nobody → n.nethercote
Status: NEW → ASSIGNED
Attached patch Remove JSOP_ENDINIT (obsolete) (deleted) — Splinter Review
Let's remove some dead pseudo-JSOps while we're here.
Attachment #8508445 - Flags: review?(jorendorff)
Attachment #8508157 - Attachment is obsolete: true
Attachment #8508157 - Flags: review?(jorendorff)
Comment on attachment 8508445 [details] [diff] [review] Remove JSOP_ENDINIT Review of attachment 8508445 [details] [diff] [review]: ----------------------------------------------------------------- vm/Xdr.h bytecode version needs bumping.
Attached patch Remove JSOP_ENDINIT (deleted) — Splinter Review
You say "heighten the contradictions". I say "increment the subtrahend".
Attachment #8508445 - Attachment is obsolete: true
Attachment #8508445 - Flags: review?(jorendorff)
Comment on attachment 8508460 [details] [diff] [review] Remove JSOP_ENDINIT Review of attachment 8508460 [details] [diff] [review]: ----------------------------------------------------------------- Hmm, actually requesting a review might help.
Attachment #8508460 - Flags: review?(jorendorff)
Comment on attachment 8508460 [details] [diff] [review] Remove JSOP_ENDINIT Review of attachment 8508460 [details] [diff] [review]: ----------------------------------------------------------------- Thank you. ::: js/src/vm/Interpreter-inl.h @@ +576,3 @@ > * SetLengthProperty even if it is not the last element initialiser, > * because it may be followed by JSOP_SPREAD, which will not set the array > * length if nothing is spreaded. Pre-existing nit: the past of "spread" is "spread"; could recast to "if there's nothing to spread".
Attachment #8508460 - Flags: review?(jorendorff) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: