fourthTier: DFG should support op_in and it should use patching to make it fast
https://bugs.webkit.org/show_bug.cgi?id=117385
Source/JavaScriptCore:
Reviewed by Geoffrey Garen.
Implement op_in in the DFG and give it patching. The code we generate is just
a jump on the hot path, and the slow paths generate stubs and link the jump to
them. I didn't want to bother with patching structures and load offsets and
the like, although I probably could have.
This is a ginormous speed-up on microbenchmarks for "in", obviously.
(JSC::CodeBlock::dumpAssumingJITType):
(JSC::CodeBlock::resetStubInternal):
(JSC::structureStubInfoLessThan):
(JSC):
(JSC::CodeBlock::sortStructureStubInfos):
(CodeBlock):
- bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::deref):
(JSC::StructureStubInfo::visitWeakReferences):
- bytecode/StructureStubInfo.h:
(JSC::isInAccess):
(JSC):
(StructureStubInfo):
(JSC::StructureStubInfo::initInList):
- dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
- dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::CCallHelpers::setupResults):
(JSC::DFG::capabilityLevel):
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::JSValueRegs::payloadOnly):
(JSValueRegs):
(JSC::DFG::JSValueRegs::JSValueRegs):
(JSC::DFG::JSValueRegs::operator!):
(JSC::DFG::JSValueSource::operator!):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::InRecord::InRecord):
(InRecord):
(DFG):
(JITCompiler):
(JSC::DFG::JITCompiler::addIn):
(DFG):
- dfg/DFGOperations.cpp:
- dfg/DFGOperations.h:
- dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
(JSC::DFG::tryRepatchIn):
(DFG):
(JSC::DFG::dfgRepatchIn):
(JSC::DFG::dfgResetIn):
(DFG):
(JSC::DFG::dfgResetIn):
- dfg/DFGSlowPathGenerator.h:
(JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
(JSC::DFG::CallSlowPathGenerator::tearDown):
(JSC::DFG::CallResultAndNoArgumentsSlowPathGenerator::generateInternal):
(JSC::DFG::CallResultAndOneArgumentSlowPathGenerator::generateInternal):
(JSC::DFG::CallResultAndTwoArgumentsSlowPathGenerator::generateInternal):
(JSC::DFG::CallResultAndThreeArgumentsSlowPathGenerator::generateInternal):
(JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::generateInternal):
(JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::generateInternal):
- dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
(DFG):
(JSC::DFG::extractResult):
(DFG):
(SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::callOperation):
(JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult):
(JSC::DFG::SpeculativeJIT::appendCallSetResult):
(JSC::DFG::JSValueOperand::tagGPR):
- dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
- dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::JSValue::dump):
(JSString):
(JSC::JSString::tryGetValueImpl):
(JSC):
(JSC::normalizePrototypeChainForChainAccess):
Source/WTF:
Reviewed by Geoffrey Garen.
Now if you pass a null StringImpl* then something will still get printed instead
of crashing. I figure that this is broadly useful for debug code, and I make use
of it in the JSC portion of this patch.
(WTF::printInternal):
LayoutTests:
Reviewed by Geoffrey Garen.
Test coverage for op_in performance.
- fast/js/regress/in-four-cases-expected.txt: Added.
- fast/js/regress/in-four-cases.html: Added.
- fast/js/regress/in-one-case-false-expected.txt: Added.
- fast/js/regress/in-one-case-false.html: Added.
- fast/js/regress/in-one-case-true-expected.txt: Added.
- fast/js/regress/in-one-case-true.html: Added.
- fast/js/regress/in-two-cases-expected.txt: Added.
- fast/js/regress/in-two-cases.html: Added.
- fast/js/regress/script-tests/in-four-cases.js: Added.
(foo):
(bar):
- fast/js/regress/script-tests/in-one-case-false.js: Added.
(foo):
(bar):
- fast/js/regress/script-tests/in-one-case-true.js: Added.
(foo):
(bar):
- fast/js/regress/script-tests/in-two-cases.js: Added.
(foo):
(bar):