haikuwebkit/Source/JavaScriptCore/jit/JITSubGenerator.h

75 lines
2.7 KiB
C
Raw Permalink Normal View History

Factoring out op_sub baseline code generation into JITSubGenerator. https://bugs.webkit.org/show_bug.cgi?id=149600 Reviewed by Geoffrey Garen. We're going to factor out baseline code generation into snippet generators so that we can later use them in the DFG and FTL to emit code for to perform the JS operations where the operand types are predicted to be polymorphic. We are starting in this patch with the implementation of op_sub. What was done in this patch: 1. Created JITSubGenerator based on the baseline implementation of op_sub as expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase(). I did not attempt to do write a more optimal version of op_sub. I'll leave that to a later patch. 2. Convert the 32-bit op_sub baseline implementation to use the same JITSubGenerator which was based on the 64-bit implementation. The pre-existing 32-bit baseline op_sub had handling for more optimization cases. However, a benchmark run shows that simply going with the 64-bit version (foregoing those extra optimizations) did not change the performance. Also, previously, the 32-bit version was able to move double results directly into the result location on the stack directly. By using JITSubGenerator, we now always move that result into a pair of GPRs before storing it into the stack location. 3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs. * JavaScriptCore.xcodeproj/project.pbxproj: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::boxDouble): (JSC::AssemblyHelpers::unboxDouble): (JSC::AssemblyHelpers::boxBooleanPayload): * jit/JIT.h: (JSC::JIT::linkDummySlowCase): * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_sub): Deleted. (JSC::JIT::emitSub32Constant): Deleted. (JSC::JIT::emitSlow_op_sub): Deleted. * jit/JITInlines.h: (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::linkAllSlowCasesForBytecodeOffset): (JSC::JIT::addSlowCase): (JSC::JIT::emitLoad): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitPutVirtualRegister): * jit/JITSubGenerator.h: Added. (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::generateFastPath): (JSC::JITSubGenerator::slowPathJumpList): Canonical link: https://commits.webkit.org/167994@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@190649 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-06 22:29:27 +00:00
/*
Polymorphic operands in operators coerces downstream values to double. https://bugs.webkit.org/show_bug.cgi?id=151793 Reviewed by Mark Lam. Source/JavaScriptCore: Previously if an object flowed into arithmetic, the prediction propagation phase would either assume that the output of the arithmetic had to be double or sometimes it would assume that it couldn't be double. We want it to only assume that the output is double if it actually had been. The first part of this patch is to roll out http://trac.webkit.org/changeset/200502. That removed some of the machinery that we had in place to detect whether the output of an operation is int or double. That changeset claimed that the machinery was "fundamentally broken". It actually wasn't. The reason why it didn't work was that ByteCodeParser was ignoring it if likelyToTakeSlowCase was false. I think this was a complete goof-up: the code in ByteCodeParser::makeSafe was structured in a way that made it non-obvious that the method is a no-op if !likelyToTakeSlowCase. So, this change rolls out r200502 and makes ResultProfile do its job by reshaping how makeSafe processes it. This also makes two other changes to shore up ResultProfile: - OSR exit can now refine a ResultProfile the same way that it refines ValueProfile. - Baseline JIT slow paths now set bits in ResultProfile. Based on this stuff, the DFG now predicts int/double/string in op_add/op_sub/op_mul based on ResultProfiles. To be conservative, we still only use the ResultProfiles if the incoming prediction is not number-or-boolean. This ensures that we exactly retain our old behavior in those cases for which it was tuned. But I hope to remove this soon. I believe that ResultProfile is already strictly better than what prediction propagation was doing before. This can be an enormous win. This patch adds some simple microbenchmarks that demonstrate the problem of assuming that arithmetic on objects returns double. The most extreme of these speeds up 8x with this change (object-int-add-array). * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.h: (JSC::CodeBlock::addFrequentExitSite): (JSC::CodeBlock::hasExitSite): * bytecode/DFGExitProfile.cpp: (JSC::DFG::FrequentExitSite::dump): (JSC::DFG::ExitProfile::ExitProfile): (JSC::DFG::ExitProfile::~ExitProfile): (JSC::DFG::ExitProfile::add): * bytecode/DFGExitProfile.h: (JSC::DFG::FrequentExitSite::isHashTableDeletedValue): * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::fromLazyOperand): (JSC::MethodOfGettingAValueProfile::emitReportValue): (JSC::MethodOfGettingAValueProfile::getSpecFailBucket): Deleted. * bytecode/MethodOfGettingAValueProfile.h: (JSC::MethodOfGettingAValueProfile::MethodOfGettingAValueProfile): (JSC::MethodOfGettingAValueProfile::operator bool): (JSC::MethodOfGettingAValueProfile::operator!): Deleted. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generateImpl): * bytecode/ValueProfile.cpp: (JSC::ResultProfile::emitDetectBitsLight): (JSC::ResultProfile::emitSetDouble): (JSC::ResultProfile::emitSetNonNumber): (WTF::printInternal): * bytecode/ValueProfile.h: (JSC::ResultProfile::ResultProfile): (JSC::ResultProfile::bytecodeOffset): (JSC::ResultProfile::specialFastPathCount): (JSC::ResultProfile::didObserveNonInt32): (JSC::ResultProfile::didObserveDouble): (JSC::ResultProfile::didObserveNonNegZeroDouble): (JSC::ResultProfile::didObserveNegZeroDouble): (JSC::ResultProfile::didObserveNonNumber): (JSC::ResultProfile::didObserveInt32Overflow): (JSC::ResultProfile::didObserveInt52Overflow): (JSC::ResultProfile::setObservedNonNegZeroDouble): (JSC::ResultProfile::setObservedNegZeroDouble): (JSC::ResultProfile::setObservedNonNumber): (JSC::ResultProfile::setObservedInt32Overflow): (JSC::ResultProfile::addressOfFlags): (JSC::ResultProfile::addressOfSpecialFastPathCount): (JSC::ResultProfile::detectBitsLight): (JSC::ResultProfile::hasBits): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeSafe): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::ensureNaturalLoops): (JSC::DFG::Graph::methodOfGettingAValueProfileFor): (JSC::DFG::Graph::valueProfileFor): Deleted. * dfg/DFGGraph.h: (JSC::DFG::Graph::hasExitSite): (JSC::DFG::Graph::numBlocks): * dfg/DFGNode.h: (JSC::DFG::Node::arithNodeFlags): (JSC::DFG::Node::mayHaveNonIntResult): (JSC::DFG::Node::mayHaveDoubleResult): (JSC::DFG::Node::mayHaveNonNumberResult): (JSC::DFG::Node::hasConstantBuffer): * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): * dfg/DFGNodeFlags.h: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchIfEqual): (JSC::AssemblyHelpers::branchIfNotCell): (JSC::AssemblyHelpers::branchIfNotNumber): (JSC::AssemblyHelpers::branchIfNotDoubleKnownNotInt32): (JSC::AssemblyHelpers::branchIfBoolean): (JSC::AssemblyHelpers::branchIfEmpty): (JSC::AssemblyHelpers::branchStructure): * jit/CCallHelpers.h: (JSC::CCallHelpers::CCallHelpers): (JSC::CCallHelpers::setupArguments): (JSC::CCallHelpers::setupArgumentsWithExecState): * jit/IntrinsicEmitter.cpp: (JSC::AccessCase::emitIntrinsicGetter): * jit/JIT.h: * jit/JITAddGenerator.cpp: (JSC::JITAddGenerator::generateFastPath): * jit/JITAddGenerator.h: (JSC::JITAddGenerator::JITAddGenerator): * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_add): (JSC::JIT::emitSlow_op_add): (JSC::JIT::emit_op_div): (JSC::JIT::emit_op_mul): (JSC::JIT::emitSlow_op_mul): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITInlines.h: (JSC::JIT::callOperation): (JSC::JIT::callOperationNoExceptionCheck): * jit/JITMulGenerator.cpp: (JSC::JITMulGenerator::generateFastPath): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITSubGenerator.cpp: (JSC::JITSubGenerator::generateFastPath): * jit/JITSubGenerator.h: (JSC::JITSubGenerator::JITSubGenerator): * jit/TagRegistersMode.cpp: Added. (WTF::printInternal): * jit/TagRegistersMode.h: Added. * runtime/CommonSlowPaths.cpp: (JSC::updateResultProfileForBinaryArithOp): LayoutTests: * js/regress/object-int-add-array-expected.txt: Added. * js/regress/object-int-add-array.html: Added. * js/regress/object-int-add-expected.txt: Added. * js/regress/object-int-add.html: Added. * js/regress/object-int-mul-array-expected.txt: Added. * js/regress/object-int-mul-array.html: Added. * js/regress/object-int-sub-array-expected.txt: Added. * js/regress/object-int-sub-array.html: Added. * js/regress/object-int-sub-expected.txt: Added. * js/regress/object-int-sub.html: Added. * js/regress/script-tests/object-int-add-array.js: Added. (i.o.valueOf): * js/regress/script-tests/object-int-add.js: Added. (i.o.valueOf): * js/regress/script-tests/object-int-mul-array.js: Added. (i.o.valueOf): * js/regress/script-tests/object-int-sub-array.js: Added. (i.o.valueOf): * js/regress/script-tests/object-int-sub.js: Added. (i.o.valueOf): Canonical link: https://commits.webkit.org/175637@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@200606 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-05-10 02:01:28 +00:00
* Copyright (C) 2015-2016 Apple Inc. All rights reserved.
Factoring out op_sub baseline code generation into JITSubGenerator. https://bugs.webkit.org/show_bug.cgi?id=149600 Reviewed by Geoffrey Garen. We're going to factor out baseline code generation into snippet generators so that we can later use them in the DFG and FTL to emit code for to perform the JS operations where the operand types are predicted to be polymorphic. We are starting in this patch with the implementation of op_sub. What was done in this patch: 1. Created JITSubGenerator based on the baseline implementation of op_sub as expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase(). I did not attempt to do write a more optimal version of op_sub. I'll leave that to a later patch. 2. Convert the 32-bit op_sub baseline implementation to use the same JITSubGenerator which was based on the 64-bit implementation. The pre-existing 32-bit baseline op_sub had handling for more optimization cases. However, a benchmark run shows that simply going with the 64-bit version (foregoing those extra optimizations) did not change the performance. Also, previously, the 32-bit version was able to move double results directly into the result location on the stack directly. By using JITSubGenerator, we now always move that result into a pair of GPRs before storing it into the stack location. 3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs. * JavaScriptCore.xcodeproj/project.pbxproj: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::boxDouble): (JSC::AssemblyHelpers::unboxDouble): (JSC::AssemblyHelpers::boxBooleanPayload): * jit/JIT.h: (JSC::JIT::linkDummySlowCase): * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_sub): Deleted. (JSC::JIT::emitSub32Constant): Deleted. (JSC::JIT::emitSlow_op_sub): Deleted. * jit/JITInlines.h: (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::linkAllSlowCasesForBytecodeOffset): (JSC::JIT::addSlowCase): (JSC::JIT::emitLoad): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitPutVirtualRegister): * jit/JITSubGenerator.h: Added. (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::generateFastPath): (JSC::JITSubGenerator::slowPathJumpList): Canonical link: https://commits.webkit.org/167994@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@190649 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-06 22:29:27 +00:00
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY APPLE INC. ``AS IS'' AND ANY
* EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE INC. OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
* OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#pragma once
Factoring out op_sub baseline code generation into JITSubGenerator. https://bugs.webkit.org/show_bug.cgi?id=149600 Reviewed by Geoffrey Garen. We're going to factor out baseline code generation into snippet generators so that we can later use them in the DFG and FTL to emit code for to perform the JS operations where the operand types are predicted to be polymorphic. We are starting in this patch with the implementation of op_sub. What was done in this patch: 1. Created JITSubGenerator based on the baseline implementation of op_sub as expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase(). I did not attempt to do write a more optimal version of op_sub. I'll leave that to a later patch. 2. Convert the 32-bit op_sub baseline implementation to use the same JITSubGenerator which was based on the 64-bit implementation. The pre-existing 32-bit baseline op_sub had handling for more optimization cases. However, a benchmark run shows that simply going with the 64-bit version (foregoing those extra optimizations) did not change the performance. Also, previously, the 32-bit version was able to move double results directly into the result location on the stack directly. By using JITSubGenerator, we now always move that result into a pair of GPRs before storing it into the stack location. 3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs. * JavaScriptCore.xcodeproj/project.pbxproj: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::boxDouble): (JSC::AssemblyHelpers::unboxDouble): (JSC::AssemblyHelpers::boxBooleanPayload): * jit/JIT.h: (JSC::JIT::linkDummySlowCase): * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_sub): Deleted. (JSC::JIT::emitSub32Constant): Deleted. (JSC::JIT::emitSlow_op_sub): Deleted. * jit/JITInlines.h: (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::linkAllSlowCasesForBytecodeOffset): (JSC::JIT::addSlowCase): (JSC::JIT::emitLoad): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitPutVirtualRegister): * jit/JITSubGenerator.h: Added. (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::generateFastPath): (JSC::JITSubGenerator::slowPathJumpList): Canonical link: https://commits.webkit.org/167994@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@190649 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-06 22:29:27 +00:00
#if ENABLE(JIT)
Factoring out op_sub baseline code generation into JITSubGenerator. https://bugs.webkit.org/show_bug.cgi?id=149600 Reviewed by Geoffrey Garen. We're going to factor out baseline code generation into snippet generators so that we can later use them in the DFG and FTL to emit code for to perform the JS operations where the operand types are predicted to be polymorphic. We are starting in this patch with the implementation of op_sub. What was done in this patch: 1. Created JITSubGenerator based on the baseline implementation of op_sub as expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase(). I did not attempt to do write a more optimal version of op_sub. I'll leave that to a later patch. 2. Convert the 32-bit op_sub baseline implementation to use the same JITSubGenerator which was based on the 64-bit implementation. The pre-existing 32-bit baseline op_sub had handling for more optimization cases. However, a benchmark run shows that simply going with the 64-bit version (foregoing those extra optimizations) did not change the performance. Also, previously, the 32-bit version was able to move double results directly into the result location on the stack directly. By using JITSubGenerator, we now always move that result into a pair of GPRs before storing it into the stack location. 3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs. * JavaScriptCore.xcodeproj/project.pbxproj: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::boxDouble): (JSC::AssemblyHelpers::unboxDouble): (JSC::AssemblyHelpers::boxBooleanPayload): * jit/JIT.h: (JSC::JIT::linkDummySlowCase): * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_sub): Deleted. (JSC::JIT::emitSub32Constant): Deleted. (JSC::JIT::emitSlow_op_sub): Deleted. * jit/JITInlines.h: (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::linkAllSlowCasesForBytecodeOffset): (JSC::JIT::addSlowCase): (JSC::JIT::emitLoad): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitPutVirtualRegister): * jit/JITSubGenerator.h: Added. (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::generateFastPath): (JSC::JITSubGenerator::slowPathJumpList): Canonical link: https://commits.webkit.org/167994@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@190649 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-06 22:29:27 +00:00
#include "CCallHelpers.h"
Sub should be a Math IC https://bugs.webkit.org/show_bug.cgi?id=160270 Reviewed by Mark Lam. This makes Sub an IC like Mul and Add. I'm seeing the following improvements of average Sub size on Unity and JetStream: | JetStream | Unity 3D | ------| -------------|-------------- Old | 202 bytes | 205 bytes | ------| -------------|-------------- New | 134 bytes | 134 bytes | ------------------------------------ * bytecode/CodeBlock.cpp: (JSC::CodeBlock::addJITMulIC): (JSC::CodeBlock::addJITSubIC): (JSC::CodeBlock::findStubInfo): (JSC::CodeBlock::dumpMathICStats): * bytecode/CodeBlock.h: (JSC::CodeBlock::stubInfoBegin): (JSC::CodeBlock::stubInfoEnd): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithSub): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub): * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): (JSC::JIT::emit_op_pow): * jit/JITMathIC.h: * jit/JITMathICForwards.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITSubGenerator.cpp: (JSC::JITSubGenerator::generateInline): (JSC::JITSubGenerator::generateFastPath): * jit/JITSubGenerator.h: (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::isLeftOperandValidConstant): (JSC::JITSubGenerator::isRightOperandValidConstant): (JSC::JITSubGenerator::arithProfile): (JSC::JITSubGenerator::didEmitFastPath): Deleted. (JSC::JITSubGenerator::endJumpList): Deleted. (JSC::JITSubGenerator::slowPathJumpList): Deleted. Canonical link: https://commits.webkit.org/178551@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@203979 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-08-01 18:48:14 +00:00
#include "JITMathICInlineResult.h"
#include "SnippetOperand.h"
Factoring out op_sub baseline code generation into JITSubGenerator. https://bugs.webkit.org/show_bug.cgi?id=149600 Reviewed by Geoffrey Garen. We're going to factor out baseline code generation into snippet generators so that we can later use them in the DFG and FTL to emit code for to perform the JS operations where the operand types are predicted to be polymorphic. We are starting in this patch with the implementation of op_sub. What was done in this patch: 1. Created JITSubGenerator based on the baseline implementation of op_sub as expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase(). I did not attempt to do write a more optimal version of op_sub. I'll leave that to a later patch. 2. Convert the 32-bit op_sub baseline implementation to use the same JITSubGenerator which was based on the 64-bit implementation. The pre-existing 32-bit baseline op_sub had handling for more optimization cases. However, a benchmark run shows that simply going with the 64-bit version (foregoing those extra optimizations) did not change the performance. Also, previously, the 32-bit version was able to move double results directly into the result location on the stack directly. By using JITSubGenerator, we now always move that result into a pair of GPRs before storing it into the stack location. 3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs. * JavaScriptCore.xcodeproj/project.pbxproj: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::boxDouble): (JSC::AssemblyHelpers::unboxDouble): (JSC::AssemblyHelpers::boxBooleanPayload): * jit/JIT.h: (JSC::JIT::linkDummySlowCase): * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_sub): Deleted. (JSC::JIT::emitSub32Constant): Deleted. (JSC::JIT::emitSlow_op_sub): Deleted. * jit/JITInlines.h: (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::linkAllSlowCasesForBytecodeOffset): (JSC::JIT::addSlowCase): (JSC::JIT::emitLoad): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitPutVirtualRegister): * jit/JITSubGenerator.h: Added. (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::generateFastPath): (JSC::JITSubGenerator::slowPathJumpList): Canonical link: https://commits.webkit.org/167994@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@190649 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-06 22:29:27 +00:00
namespace JSC {
Update FTL to support UntypedUse operands for op_sub. https://bugs.webkit.org/show_bug.cgi?id=150562 Reviewed by Geoffrey Garen. Source/JavaScriptCore: * assembler/MacroAssemblerARM64.h: - make the dataTempRegister and memoryTempRegister public so that we can move input registers out of them if needed. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): - We can now compile ArithSub. * ftl/FTLCompile.cpp: - Added BinaryArithGenerationContext to shuffle registers into a state that is expected by the baseline snippet generator. This includes: 1. Making sure that the input and output registers are not in the tag or scratch registers. 2. Loading the tag registers with expected values. 3. Restoring the registers to their original value on return. - Added code to implement the ArithSub inline cache. * ftl/FTLInlineCacheDescriptor.h: (JSC::FTL::ArithSubDescriptor::ArithSubDescriptor): (JSC::FTL::ArithSubDescriptor::leftType): (JSC::FTL::ArithSubDescriptor::rightType): * ftl/FTLInlineCacheSize.cpp: (JSC::FTL::sizeOfArithSub): * ftl/FTLInlineCacheSize.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub): - Added handling for UnusedType for the ArithSub case. * ftl/FTLState.h: * jit/GPRInfo.h: (JSC::GPRInfo::reservedRegisters): * jit/JITSubGenerator.h: (JSC::JITSubGenerator::generateFastPath): - When the result is in the same as one of the input registers, we'll end up corrupting the input in fast path even if we determine that we need to go to the slow path. We now move the input into the scratch register and operate on that instead and only move the result into the result register only after the fast path has succeeded. * tests/stress/op_sub.js: (o1.valueOf): (runTest): - Added some debugging tools: flags for verbose logging, and eager abort on fail. LayoutTests: * js/regress/ftl-sub-expected.txt: Added. * js/regress/ftl-sub.html: Added. * js/regress/script-tests/ftl-sub.js: Added. (o1.valueOf): (o2.valueOf): (foo): Canonical link: https://commits.webkit.org/168792@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@191683 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-28 18:36:02 +00:00
Sub should be a Math IC https://bugs.webkit.org/show_bug.cgi?id=160270 Reviewed by Mark Lam. This makes Sub an IC like Mul and Add. I'm seeing the following improvements of average Sub size on Unity and JetStream: | JetStream | Unity 3D | ------| -------------|-------------- Old | 202 bytes | 205 bytes | ------| -------------|-------------- New | 134 bytes | 134 bytes | ------------------------------------ * bytecode/CodeBlock.cpp: (JSC::CodeBlock::addJITMulIC): (JSC::CodeBlock::addJITSubIC): (JSC::CodeBlock::findStubInfo): (JSC::CodeBlock::dumpMathICStats): * bytecode/CodeBlock.h: (JSC::CodeBlock::stubInfoBegin): (JSC::CodeBlock::stubInfoEnd): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithSub): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub): * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): (JSC::JIT::emit_op_pow): * jit/JITMathIC.h: * jit/JITMathICForwards.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITSubGenerator.cpp: (JSC::JITSubGenerator::generateInline): (JSC::JITSubGenerator::generateFastPath): * jit/JITSubGenerator.h: (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::isLeftOperandValidConstant): (JSC::JITSubGenerator::isRightOperandValidConstant): (JSC::JITSubGenerator::arithProfile): (JSC::JITSubGenerator::didEmitFastPath): Deleted. (JSC::JITSubGenerator::endJumpList): Deleted. (JSC::JITSubGenerator::slowPathJumpList): Deleted. Canonical link: https://commits.webkit.org/178551@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@203979 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-08-01 18:48:14 +00:00
struct MathICGenerationState;
Factoring out op_sub baseline code generation into JITSubGenerator. https://bugs.webkit.org/show_bug.cgi?id=149600 Reviewed by Geoffrey Garen. We're going to factor out baseline code generation into snippet generators so that we can later use them in the DFG and FTL to emit code for to perform the JS operations where the operand types are predicted to be polymorphic. We are starting in this patch with the implementation of op_sub. What was done in this patch: 1. Created JITSubGenerator based on the baseline implementation of op_sub as expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase(). I did not attempt to do write a more optimal version of op_sub. I'll leave that to a later patch. 2. Convert the 32-bit op_sub baseline implementation to use the same JITSubGenerator which was based on the 64-bit implementation. The pre-existing 32-bit baseline op_sub had handling for more optimization cases. However, a benchmark run shows that simply going with the 64-bit version (foregoing those extra optimizations) did not change the performance. Also, previously, the 32-bit version was able to move double results directly into the result location on the stack directly. By using JITSubGenerator, we now always move that result into a pair of GPRs before storing it into the stack location. 3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs. * JavaScriptCore.xcodeproj/project.pbxproj: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::boxDouble): (JSC::AssemblyHelpers::unboxDouble): (JSC::AssemblyHelpers::boxBooleanPayload): * jit/JIT.h: (JSC::JIT::linkDummySlowCase): * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_sub): Deleted. (JSC::JIT::emitSub32Constant): Deleted. (JSC::JIT::emitSlow_op_sub): Deleted. * jit/JITInlines.h: (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::linkAllSlowCasesForBytecodeOffset): (JSC::JIT::addSlowCase): (JSC::JIT::emitLoad): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitPutVirtualRegister): * jit/JITSubGenerator.h: Added. (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::generateFastPath): (JSC::JITSubGenerator::slowPathJumpList): Canonical link: https://commits.webkit.org/167994@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@190649 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-06 22:29:27 +00:00
class JITSubGenerator {
public:
Sub should be a Math IC https://bugs.webkit.org/show_bug.cgi?id=160270 Reviewed by Mark Lam. This makes Sub an IC like Mul and Add. I'm seeing the following improvements of average Sub size on Unity and JetStream: | JetStream | Unity 3D | ------| -------------|-------------- Old | 202 bytes | 205 bytes | ------| -------------|-------------- New | 134 bytes | 134 bytes | ------------------------------------ * bytecode/CodeBlock.cpp: (JSC::CodeBlock::addJITMulIC): (JSC::CodeBlock::addJITSubIC): (JSC::CodeBlock::findStubInfo): (JSC::CodeBlock::dumpMathICStats): * bytecode/CodeBlock.h: (JSC::CodeBlock::stubInfoBegin): (JSC::CodeBlock::stubInfoEnd): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithSub): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub): * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): (JSC::JIT::emit_op_pow): * jit/JITMathIC.h: * jit/JITMathICForwards.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITSubGenerator.cpp: (JSC::JITSubGenerator::generateInline): (JSC::JITSubGenerator::generateFastPath): * jit/JITSubGenerator.h: (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::isLeftOperandValidConstant): (JSC::JITSubGenerator::isRightOperandValidConstant): (JSC::JITSubGenerator::arithProfile): (JSC::JITSubGenerator::didEmitFastPath): Deleted. (JSC::JITSubGenerator::endJumpList): Deleted. (JSC::JITSubGenerator::slowPathJumpList): Deleted. Canonical link: https://commits.webkit.org/178551@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@203979 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-08-01 18:48:14 +00:00
JITSubGenerator() { }
JITSubGenerator(SnippetOperand leftOperand, SnippetOperand rightOperand,
JSValueRegs result, JSValueRegs left, JSValueRegs right,
[JSC] Simplify moveIntsToDouble https://bugs.webkit.org/show_bug.cgi?id=229351 Reviewed by Saam Barati. MacroAssembler::moveIntsToDouble required scratch FPRReg. But it was only required for MacroAssemblerX86, and it is already removed. This means that we no longer need this scratch FPRReg. This change makes a lot of IC code, property access code simpler. This patch removes that scratch FPRReg, and removed scratch FPRReg of many arithmetic ICs. This patch is important for PutByVal modern IC since some of property access requires FPRReg because of MacroAssembler::moveIntsToDouble, and it requires adding new m_scratch2FPR to AccessCase. But after this simplification, this is no longer necessary. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::moveIntsToDouble): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::moveIntsToDouble): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileDoubleRep): (JSC::DFG::SpeculativeJIT::emitUntypedOrBigIntRightShiftBitOp): (JSC::DFG::SpeculativeJIT::compileValueAdd): (JSC::DFG::SpeculativeJIT::compileValueSub): (JSC::DFG::SpeculativeJIT::compileMathIC): (JSC::DFG::SpeculativeJIT::compileValueNegate): (JSC::DFG::SpeculativeJIT::compileValueMul): (JSC::DFG::SpeculativeJIT::speculateRealNumber): (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::unboxDouble): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitConvertValueToBoolean): (JSC::AssemblyHelpers::branchIfValue): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::unboxDoubleNonDestructive): (JSC::AssemblyHelpers::unboxDouble): * jit/JITAddGenerator.cpp: (JSC::JITAddGenerator::generateFastPath): * jit/JITAddGenerator.h: (JSC::JITAddGenerator::JITAddGenerator): * jit/JITArithmetic.cpp: (JSC::JIT::emitRightShiftFastPath): (JSC::JIT::emitMathICFast): * jit/JITDivGenerator.cpp: (JSC::JITDivGenerator::loadOperand): * jit/JITMulGenerator.cpp: (JSC::JITMulGenerator::generateInline): (JSC::JITMulGenerator::generateFastPath): * jit/JITMulGenerator.h: (JSC::JITMulGenerator::JITMulGenerator): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitFloatTypedArrayPutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitGenericContiguousPutByVal): * jit/JITRightShiftGenerator.cpp: (JSC::JITRightShiftGenerator::generateFastPath): * jit/JITRightShiftGenerator.h: (JSC::JITRightShiftGenerator::JITRightShiftGenerator): * jit/JITSubGenerator.cpp: (JSC::JITSubGenerator::generateInline): (JSC::JITSubGenerator::generateFastPath): * jit/JITSubGenerator.h: (JSC::JITSubGenerator::JITSubGenerator): Canonical link: https://commits.webkit.org/240770@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@281355 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2021-08-21 00:54:50 +00:00
FPRReg leftFPR, FPRReg rightFPR, GPRReg scratchGPR)
: m_leftOperand(leftOperand)
, m_rightOperand(rightOperand)
, m_result(result)
Factoring out op_sub baseline code generation into JITSubGenerator. https://bugs.webkit.org/show_bug.cgi?id=149600 Reviewed by Geoffrey Garen. We're going to factor out baseline code generation into snippet generators so that we can later use them in the DFG and FTL to emit code for to perform the JS operations where the operand types are predicted to be polymorphic. We are starting in this patch with the implementation of op_sub. What was done in this patch: 1. Created JITSubGenerator based on the baseline implementation of op_sub as expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase(). I did not attempt to do write a more optimal version of op_sub. I'll leave that to a later patch. 2. Convert the 32-bit op_sub baseline implementation to use the same JITSubGenerator which was based on the 64-bit implementation. The pre-existing 32-bit baseline op_sub had handling for more optimization cases. However, a benchmark run shows that simply going with the 64-bit version (foregoing those extra optimizations) did not change the performance. Also, previously, the 32-bit version was able to move double results directly into the result location on the stack directly. By using JITSubGenerator, we now always move that result into a pair of GPRs before storing it into the stack location. 3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs. * JavaScriptCore.xcodeproj/project.pbxproj: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::boxDouble): (JSC::AssemblyHelpers::unboxDouble): (JSC::AssemblyHelpers::boxBooleanPayload): * jit/JIT.h: (JSC::JIT::linkDummySlowCase): * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_sub): Deleted. (JSC::JIT::emitSub32Constant): Deleted. (JSC::JIT::emitSlow_op_sub): Deleted. * jit/JITInlines.h: (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::linkAllSlowCasesForBytecodeOffset): (JSC::JIT::addSlowCase): (JSC::JIT::emitLoad): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitPutVirtualRegister): * jit/JITSubGenerator.h: Added. (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::generateFastPath): (JSC::JITSubGenerator::slowPathJumpList): Canonical link: https://commits.webkit.org/167994@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@190649 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-06 22:29:27 +00:00
, m_left(left)
, m_right(right)
, m_leftFPR(leftFPR)
, m_rightFPR(rightFPR)
, m_scratchGPR(scratchGPR)
{ }
Split ArithProfile into a Unary and a Binary version https://bugs.webkit.org/show_bug.cgi?id=202832 <rdar://problem/56266847> Reviewed by Keith Miller. JSTests: The new test (kindly provided by Mark Lam) catches the metadata corruption that used to happen in the previous version of this patch. * stress/regress-57020338.js: Added. Source/JavaScriptCore: ArithProfile was for a long time only used for add/sub/mul/div, but recently it started being used for negate. And it will soon also have to be used for inc and dec due to BigInt. So in this patch I make a separate version that only has the data for a single argument, and thus takes half as much memory. After discussing this change with Phil I realized that the ResultType(s) that were taking space in ArithProfile are not needed: they never change and a copy is already in the bytecode instruction itself. Removing them allowed shrinking both kinds of ArithProfile to fit in 16 bits (9 and 13 respectively). I kept the two kinds separate because they may shrink or grow independently in the future. This also required adding the "orh" instruction to the offline assembler, to set bits in the ArithProfile. This in turn motivated the addition of "storeh", as on RISC platforms "orh" on a memory location is actually loadh -> orh -> storeh. Finally it required adding support for or16(TrustedImm32, AbsoluteAddress) in the MacroAssembler for the ICs. Instead of directly calling it (like we used to do with or32), I introduced ArithProfile::emitUnconditionalSet, so that if either ArithProfile ever changes in size again we'll have fewer places to change. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::or16): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::or16): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::or16): * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::or16): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::or16): * assembler/testmasm.cpp: (JSC::testOrImmMem): (JSC::run): * bytecode/ArithProfile.cpp: (JSC::ArithProfile<BitfieldType>::emitObserveResult): (JSC::ArithProfile<BitfieldType>::shouldEmitSetDouble const): (JSC::ArithProfile<BitfieldType>::emitSetDouble const): (JSC::ArithProfile<BitfieldType>::shouldEmitSetNonNumeric const): (JSC::ArithProfile<BitfieldType>::emitSetNonNumeric const): (JSC::ArithProfile<BitfieldType>::shouldEmitSetBigInt const): (JSC::ArithProfile<BitfieldType>::emitSetBigInt const): (JSC::ArithProfile<BitfieldType>::emitUnconditionalSet const): (WTF::printInternal): * bytecode/ArithProfile.h: (JSC::ArithProfile::didObserveNonInt32 const): (JSC::ArithProfile::didObserveDouble const): (JSC::ArithProfile::didObserveNonNegZeroDouble const): (JSC::ArithProfile::didObserveNegZeroDouble const): (JSC::ArithProfile::didObserveNonNumeric const): (JSC::ArithProfile::didObserveBigInt const): (JSC::ArithProfile::didObserveInt32Overflow const): (JSC::ArithProfile::didObserveInt52Overflow const): (JSC::ArithProfile::setObservedNonNegZeroDouble): (JSC::ArithProfile::setObservedNegZeroDouble): (JSC::ArithProfile::setObservedNonNumeric): (JSC::ArithProfile::setObservedBigInt): (JSC::ArithProfile::setObservedInt32Overflow): (JSC::ArithProfile::setObservedInt52Overflow): (JSC::ArithProfile::observeResult): (JSC::ArithProfile::addressOfBits const): (JSC::ArithProfile::bits const): (JSC::ArithProfile::ArithProfile): (JSC::ArithProfile::hasBits const): (JSC::ArithProfile::setBit): (JSC::UnaryArithProfile::UnaryArithProfile): (JSC::UnaryArithProfile::observedIntBits): (JSC::UnaryArithProfile::observedNumberBits): (JSC::UnaryArithProfile::argObservedType const): (JSC::UnaryArithProfile::setArgObservedType): (JSC::UnaryArithProfile::argSawInt32): (JSC::UnaryArithProfile::argSawNumber): (JSC::UnaryArithProfile::argSawNonNumber): (JSC::UnaryArithProfile::observeArg): (JSC::UnaryArithProfile::isObservedTypeEmpty): (JSC::BinaryArithProfile::BinaryArithProfile): (JSC::BinaryArithProfile::observedIntIntBits): (JSC::BinaryArithProfile::observedNumberIntBits): (JSC::BinaryArithProfile::observedIntNumberBits): (JSC::BinaryArithProfile::observedNumberNumberBits): (JSC::BinaryArithProfile::setLhsObservedType): (JSC::BinaryArithProfile::setRhsObservedType): (JSC::BinaryArithProfile::observeLHS): (JSC::BinaryArithProfile::observeLHSAndRHS): (JSC::BinaryArithProfile::isObservedTypeEmpty): * bytecode/BytecodeList.rb: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::addJITAddIC): (JSC::CodeBlock::addJITMulIC): (JSC::CodeBlock::addJITSubIC): (JSC::CodeBlock::addJITNegIC): (JSC::CodeBlock::binaryArithProfileForBytecodeIndex): (JSC::CodeBlock::unaryArithProfileForBytecodeIndex): (JSC::CodeBlock::binaryArithProfileForPC): (JSC::CodeBlock::unaryArithProfileForPC): (JSC::CodeBlock::couldTakeSpecialArithFastCase): * bytecode/CodeBlock.h: (JSC::CodeBlock::addMathIC): * bytecode/Fits.h: * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::emitReportValue const): (JSC::MethodOfGettingAValueProfile::reportValue): * bytecode/MethodOfGettingAValueProfile.h: (JSC::MethodOfGettingAValueProfile::MethodOfGettingAValueProfile): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitUnaryOp): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::UnaryOpNode::emitBytecode): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeSafe): (JSC::DFG::ByteCodeParser::makeDivSafe): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::methodOfGettingAValueProfileFor): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueAdd): (JSC::DFG::SpeculativeJIT::compileValueSub): (JSC::DFG::SpeculativeJIT::compileValueNegate): (JSC::DFG::SpeculativeJIT::compileValueMul): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd): (JSC::FTL::DFG::LowerDFGToB3::compileValueSub): (JSC::FTL::DFG::LowerDFGToB3::compileValueMul): (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub): (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate): * jit/JIT.h: * jit/JITAddGenerator.cpp: (JSC::JITAddGenerator::generateInline): (JSC::JITAddGenerator::generateFastPath): * jit/JITAddGenerator.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_negate): (JSC::JIT::emit_op_add): (JSC::JIT::emitMathICFast): (JSC::JIT::emitMathICSlow): (JSC::JIT::emit_op_div): (JSC::JIT::emit_op_mul): (JSC::JIT::emit_op_sub): * jit/JITDivGenerator.cpp: (JSC::JITDivGenerator::generateFastPath): * jit/JITDivGenerator.h: (JSC::JITDivGenerator::JITDivGenerator): * jit/JITInlines.h: (JSC::JIT::copiedArithProfile): * jit/JITMathIC.h: (JSC::JITMathIC::JITMathIC): (JSC::JITMathIC::generateInline): (JSC::JITMathIC::arithProfile const): (JSC::JITBinaryMathIC::JITBinaryMathIC): (JSC::JITUnaryMathIC::JITUnaryMathIC): * jit/JITMulGenerator.cpp: (JSC::JITMulGenerator::generateInline): (JSC::JITMulGenerator::generateFastPath): * jit/JITMulGenerator.h: * jit/JITNegGenerator.cpp: (JSC::JITNegGenerator::generateInline): (JSC::JITNegGenerator::generateFastPath): * jit/JITNegGenerator.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITSubGenerator.cpp: (JSC::JITSubGenerator::generateInline): (JSC::JITSubGenerator::generateFastPath): * jit/JITSubGenerator.h: * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntOffsetsExtractor.cpp: (JSC::LLIntOffsetsExtractor::dummy): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm.rb: * offlineasm/arm64.rb: * offlineasm/cloop.rb: * offlineasm/instructions.rb: * offlineasm/mips.rb: * offlineasm/risc.rb: * offlineasm/x86.rb: * parser/ResultType.h: (JSC::ResultType::ResultType): * runtime/CommonSlowPaths.cpp: (JSC::updateArithProfileForUnaryArithOp): (JSC::updateArithProfileForBinaryArithOp): (JSC::SLOW_PATH_DECL): Canonical link: https://commits.webkit.org/217465@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@252422 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2019-11-13 20:07:29 +00:00
JITMathICInlineResult generateInline(CCallHelpers&, MathICGenerationState&, const BinaryArithProfile*);
bool generateFastPath(CCallHelpers&, CCallHelpers::JumpList& endJumpList, CCallHelpers::JumpList& slowPathJumpList, const BinaryArithProfile*, bool shouldEmitProfiling);
Factoring out op_sub baseline code generation into JITSubGenerator. https://bugs.webkit.org/show_bug.cgi?id=149600 Reviewed by Geoffrey Garen. We're going to factor out baseline code generation into snippet generators so that we can later use them in the DFG and FTL to emit code for to perform the JS operations where the operand types are predicted to be polymorphic. We are starting in this patch with the implementation of op_sub. What was done in this patch: 1. Created JITSubGenerator based on the baseline implementation of op_sub as expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase(). I did not attempt to do write a more optimal version of op_sub. I'll leave that to a later patch. 2. Convert the 32-bit op_sub baseline implementation to use the same JITSubGenerator which was based on the 64-bit implementation. The pre-existing 32-bit baseline op_sub had handling for more optimization cases. However, a benchmark run shows that simply going with the 64-bit version (foregoing those extra optimizations) did not change the performance. Also, previously, the 32-bit version was able to move double results directly into the result location on the stack directly. By using JITSubGenerator, we now always move that result into a pair of GPRs before storing it into the stack location. 3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs. * JavaScriptCore.xcodeproj/project.pbxproj: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::boxDouble): (JSC::AssemblyHelpers::unboxDouble): (JSC::AssemblyHelpers::boxBooleanPayload): * jit/JIT.h: (JSC::JIT::linkDummySlowCase): * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_sub): Deleted. (JSC::JIT::emitSub32Constant): Deleted. (JSC::JIT::emitSlow_op_sub): Deleted. * jit/JITInlines.h: (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::linkAllSlowCasesForBytecodeOffset): (JSC::JIT::addSlowCase): (JSC::JIT::emitLoad): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitPutVirtualRegister): * jit/JITSubGenerator.h: Added. (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::generateFastPath): (JSC::JITSubGenerator::slowPathJumpList): Canonical link: https://commits.webkit.org/167994@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@190649 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-06 22:29:27 +00:00
Register usage optimization in mathIC when LHS and RHS are constants isn't configured correctly https://bugs.webkit.org/show_bug.cgi?id=160802 Patch by Caio Lima <ticaiolima@gmail.com> on 2016-09-02 Reviewed by Saam Barati. This patch is fixing a broken mechanism of MathIC that avoids allocate a register to LHS or RHS if one of these operands are proven as valid constant for JIT*Generator. In previous implementation, even if the JIT*Generator was not using an operand register because it was proven as a constant, compileMathIC and emitICFast were allocating a register for it. This was broken because mathIC->isLeftOperandValidConstant and mathIC->isLeftOperandValidConstant were being called before its Generator be properly initialized. We changed this mechanism to enable Generators write their validConstant rules using static methods isLeftOperandValidConstant(SnippetOperand) and isRightOperandValidConstant(SnippetOperand). * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileMathIC): * jit/JITAddGenerator.h: (JSC::JITAddGenerator::JITAddGenerator): (JSC::JITAddGenerator::isLeftOperandValidConstant): (JSC::JITAddGenerator::isRightOperandValidConstant): * jit/JITArithmetic.cpp: (JSC::JIT::emitMathICFast): * jit/JITMathIC.h: * jit/JITMulGenerator.h: (JSC::JITMulGenerator::JITMulGenerator): (JSC::JITMulGenerator::isLeftOperandValidConstant): (JSC::JITMulGenerator::isRightOperandValidConstant): * jit/JITSubGenerator.h: (JSC::JITSubGenerator::isLeftOperandValidConstant): (JSC::JITSubGenerator::isRightOperandValidConstant): Canonical link: https://commits.webkit.org/179696@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@205364 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-09-02 19:49:09 +00:00
static bool isLeftOperandValidConstant(SnippetOperand) { return false; }
static bool isRightOperandValidConstant(SnippetOperand) { return false; }
Factoring out op_sub baseline code generation into JITSubGenerator. https://bugs.webkit.org/show_bug.cgi?id=149600 Reviewed by Geoffrey Garen. We're going to factor out baseline code generation into snippet generators so that we can later use them in the DFG and FTL to emit code for to perform the JS operations where the operand types are predicted to be polymorphic. We are starting in this patch with the implementation of op_sub. What was done in this patch: 1. Created JITSubGenerator based on the baseline implementation of op_sub as expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase(). I did not attempt to do write a more optimal version of op_sub. I'll leave that to a later patch. 2. Convert the 32-bit op_sub baseline implementation to use the same JITSubGenerator which was based on the 64-bit implementation. The pre-existing 32-bit baseline op_sub had handling for more optimization cases. However, a benchmark run shows that simply going with the 64-bit version (foregoing those extra optimizations) did not change the performance. Also, previously, the 32-bit version was able to move double results directly into the result location on the stack directly. By using JITSubGenerator, we now always move that result into a pair of GPRs before storing it into the stack location. 3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs. * JavaScriptCore.xcodeproj/project.pbxproj: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::boxDouble): (JSC::AssemblyHelpers::unboxDouble): (JSC::AssemblyHelpers::boxBooleanPayload): * jit/JIT.h: (JSC::JIT::linkDummySlowCase): * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_sub): Deleted. (JSC::JIT::emitSub32Constant): Deleted. (JSC::JIT::emitSlow_op_sub): Deleted. * jit/JITInlines.h: (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::linkAllSlowCasesForBytecodeOffset): (JSC::JIT::addSlowCase): (JSC::JIT::emitLoad): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitPutVirtualRegister): * jit/JITSubGenerator.h: Added. (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::generateFastPath): (JSC::JITSubGenerator::slowPathJumpList): Canonical link: https://commits.webkit.org/167994@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@190649 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-06 22:29:27 +00:00
private:
SnippetOperand m_leftOperand;
SnippetOperand m_rightOperand;
Factoring out op_sub baseline code generation into JITSubGenerator. https://bugs.webkit.org/show_bug.cgi?id=149600 Reviewed by Geoffrey Garen. We're going to factor out baseline code generation into snippet generators so that we can later use them in the DFG and FTL to emit code for to perform the JS operations where the operand types are predicted to be polymorphic. We are starting in this patch with the implementation of op_sub. What was done in this patch: 1. Created JITSubGenerator based on the baseline implementation of op_sub as expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase(). I did not attempt to do write a more optimal version of op_sub. I'll leave that to a later patch. 2. Convert the 32-bit op_sub baseline implementation to use the same JITSubGenerator which was based on the 64-bit implementation. The pre-existing 32-bit baseline op_sub had handling for more optimization cases. However, a benchmark run shows that simply going with the 64-bit version (foregoing those extra optimizations) did not change the performance. Also, previously, the 32-bit version was able to move double results directly into the result location on the stack directly. By using JITSubGenerator, we now always move that result into a pair of GPRs before storing it into the stack location. 3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs. * JavaScriptCore.xcodeproj/project.pbxproj: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::boxDouble): (JSC::AssemblyHelpers::unboxDouble): (JSC::AssemblyHelpers::boxBooleanPayload): * jit/JIT.h: (JSC::JIT::linkDummySlowCase): * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_sub): Deleted. (JSC::JIT::emitSub32Constant): Deleted. (JSC::JIT::emitSlow_op_sub): Deleted. * jit/JITInlines.h: (JSC::JIT::linkSlowCaseIfNotJSCell): (JSC::JIT::linkAllSlowCasesForBytecodeOffset): (JSC::JIT::addSlowCase): (JSC::JIT::emitLoad): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitPutVirtualRegister): * jit/JITSubGenerator.h: Added. (JSC::JITSubGenerator::JITSubGenerator): (JSC::JITSubGenerator::generateFastPath): (JSC::JITSubGenerator::slowPathJumpList): Canonical link: https://commits.webkit.org/167994@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@190649 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2015-10-06 22:29:27 +00:00
JSValueRegs m_result;
JSValueRegs m_left;
JSValueRegs m_right;
FPRReg m_leftFPR;
FPRReg m_rightFPR;
GPRReg m_scratchGPR;
};
} // namespace JSC
#endif // ENABLE(JIT)