[JSC] Stop eagerly emitting wide32 opcodes #10641
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tadeuzagallo
added
the
JavaScriptCore
|
EWS run on previous version of this PR (hash ddda5b1) |
Constellation
approved these changes
Feb 27, 2023
Comment on lines
1531
to
1532
| OpJneqPtr::emit<OpcodeSize::Wide32>(this, cond, moveLinkTimeConstant(nullptr, LinkTimeConstant::hasOwnPropertyFunction), target.bind(this)); | ||
| // We know that if we replace this with a jump, it'll be a near jump just over | ||
| // an OpEnumeratorHasOwnProperty + variable resolution at most, so there's no | ||
| // need to emit a wide opcode here | ||
| OpJneqPtr::emit(this, cond, moveLinkTimeConstant(nullptr, LinkTimeConstant::hasOwnPropertyFunction), target.bind(this)); | ||
| return m_lastInstruction.offset(); |
There was a problem hiding this comment.
Can you remove this function and write it directly in HasOwnPropertyFunctionCallDotNode::emitBytecode?
Making it a helper function in BytecodeGenerator would accidentally allow the future other users to use it without keeping the above invariant.
There was a problem hiding this comment.
We never emit bytecodes directly from NodesCodegen though, and we wouldn't have access to the last instruction's offset. I can expose all that, but given that this function only works for hasOwnProperty, and that if someone uses it incorrectly we'll catch it in the assertion in finalize, do you think it's a problem? Alternatively, I can move everything into emitEnumeratorHasOwnProperty, maybe that's better?
| OpJmp::emit(&generator, BoundLabel(static_cast<int>(newBranchTarget) - static_cast<int>(branchInstIndex))); | ||
| BoundLabel targetLabel(static_cast<int>(newBranchTarget) - static_cast<int>(branchInstIndex)); | ||
|
|
||
| #ifndef NDEBUG |
tadeuzagallo
force-pushed
the
eng/JSC-Stop-eagerly-emitting-wide32-opcodes
branch
from
ddda5b1
to
74dd1f0
Compare
|
EWS run on current version of this PR (hash 74dd1f0) |
https://bugs.webkit.org/show_bug.cgi?id=252891 rdar://105876002 Reviewed by Yusuke Suzuki. There were 3 cases where we emitted 32-bit wide opcodes: - OpEnumeratorGetByVal and OpEnumeratorInByVal: we might need to de-optimize these into OpGetByVal and OpInByVal respectively, and although the take the same arguments, the metadata ID might overflow whatever size we picked when emitting the original opcode. To address this, we allocate the metadataID upfront and ensure we emit a size that will fit the metadataID. These operators are not super common, and worst case scenario we'll get one extra wide OpGetByVal due to the eagerly allocated metadata. - OpJneqPtr: similar optimization, we can optimize `o.hasOwnProperty(p)` to a no-op if we can guarantee that the iterator hasn't been modified. Here we can guarantee that will always be able to emit a narrow jump, since the jump is only over a OpEnumeratorHasOwnProperty + the value we're iterating over, which is guaranteed to be a variable. Additionally, make the deoptimization a little more precise by not deoptimizing everything in the loop body if we assign to the iterator, but instead only the operations after the assignment. We are still conservative with regards to loops, and if there's any reassignment we'll deoptimize everything after the first loop_hint we encountered. * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitWideJumpIfNotFunctionHasOwnProperty): (JSC::BytecodeGenerator::emitInByVal): (JSC::BytecodeGenerator::emitGetByVal): (JSC::rewriteOp): (JSC::ForInContext::finalize): * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h: (JSC::ForInContext::addGetInst): (JSC::ForInContext::addInInst): Canonical link: https://commits.webkit.org/261125@main
webkit-commit-queue
force-pushed
the
eng/JSC-Stop-eagerly-emitting-wide32-opcodes
branch
from
74dd1f0
to
53e0cdd
Compare
|
Committed 261125@main (53e0cdd): https://commits.webkit.org/261125@main Reviewed commits have been landed. Closing PR #10641 and removing active labels. |
webkit-commit-queue
removed
the
merge-queue
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
53e0cdd
74dd1f0