Ignore:
Timestamp:
Dec 8, 2015, 1:44:12 PM (10 years ago)
Author:
[email protected]
Message:

Polymorphic operand types for DFG and FTL div.
https://bugs.webkit.org/show_bug.cgi?id=151747

Reviewed by Geoffrey Garen.

Source/JavaScriptCore:

Perf on benchmarks is neutral. The new JSRegress ftl-object-div test shows
a speed up not from the div operator itself, but from the fact that the
polymorphic operand types support now allow the test function to run without OSR
exiting, thereby realizing the DFG and FTL's speed up on other work that the test
function does.

This patch has passed the layout tests on x86_64 with a debug build.
It passed the JSC tests with x86 and x86_64 debug builds.

  • dfg/DFGAbstractInterpreterInlines.h:

(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

  • dfg/DFGClobberize.h:

(JSC::DFG::clobberize):

  • dfg/DFGFixupPhase.cpp:

(JSC::DFG::FixupPhase::fixupNode):

  • dfg/DFGOperations.cpp:
  • dfg/DFGOperations.h:
  • dfg/DFGPredictionPropagationPhase.cpp:

(JSC::DFG::PredictionPropagationPhase::propagate):

  • dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::SpeculativeJIT::compileArithDiv):

  • ftl/FTLCompileBinaryOp.cpp:

(JSC::FTL::generateBinaryArithOpFastPath):
(JSC::FTL::generateBinaryOpFastPath):

  • ftl/FTLInlineCacheDescriptor.h:
  • ftl/FTLInlineCacheDescriptorInlines.h:

(JSC::FTL::ArithDivDescriptor::ArithDivDescriptor):
(JSC::FTL::ArithDivDescriptor::icSize):

  • ftl/FTLInlineCacheSize.cpp:

(JSC::FTL::sizeOfArithDiv):

  • ftl/FTLInlineCacheSize.h:
  • ftl/FTLLowerDFGToLLVM.cpp:

(JSC::FTL::DFG::LowerDFGToLLVM::lower):
(JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):

  • Fixed a cut-paste bug where the op_mul IC was using the op_sub IC size. This bug is benign because the op_sub IC size turns out to be larger than op_mul needs.

(JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):

  • jit/JITArithmetic.cpp:

(JSC::JIT::emit_op_div):

  • Fixed a bug where the scratchFPR was not allocated for the 64bit port. This bug is benign because the scratchFPR is only needed if we are using scratchGPR register (used for branchConvertDoubleToInt32()) is

    X86Registers::r8. Since we're always using regT2 for the scratchT2,

    the scratchFPR is never needed. However, we should fix this anyway to be correct.
  • tests/stress/op_div.js:
  • Fixed some test values.

LayoutTests:

  • js/regress/ftl-object-div-expected.txt: Added.
  • js/regress/ftl-object-div.html: Added.
  • js/regress/script-tests/ftl-object-div.js: Added.

(o1.valueOf):
(foo):

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/JavaScriptCore/dfg/DFGPredictionPropagationPhase.cpp

    r193766 r193781  
    355355           
    356356            if (left && right) {
    357                 if (Node::shouldSpeculateInt32OrBooleanForArithmetic(node->child1().node(), node->child2().node())
    358                     && node->canSpeculateInt32(m_pass))
    359                     changed |= mergePrediction(SpecInt32);
    360                 else
    361                     changed |= mergePrediction(SpecBytecodeDouble);
     357                if (isFullNumberOrBooleanSpeculationExpectingDefined(left)
     358                    && isFullNumberOrBooleanSpeculationExpectingDefined(right)) {
     359                    if (Node::shouldSpeculateInt32OrBooleanForArithmetic(node->child1().node(), node->child2().node())
     360                        && node->canSpeculateInt32(m_pass))
     361                        changed |= mergePrediction(SpecInt32);
     362                    else
     363                        changed |= mergePrediction(SpecBytecodeDouble);
     364                } else
     365                    changed |= mergePrediction(SpecInt32 | SpecBytecodeDouble);
    362366            }
    363367            break;
Note: See TracChangeset for help on using the changeset viewer.