1. 09 Dec, 2013 1 commit
    • fpizlo@apple.com's avatar
      Add the notion of ConstantStoragePointer to DFG IR · 9ca951e8
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125395
      
      Reviewed by Oliver Hunt.
              
      This pushes more typed array folding into StrengthReductionPhase, and enables CSE on
      storage pointers. Previously, you might have separate nodes for the same storage
      pointer and this would cause some bad register pressure in the DFG. Note that this
      was really a theoretical problem and not, to my knowledge a practical one - so this
      patch is basically just a clean-up.
      
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::constantStoragePointerCSE):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::convertToConstantStoragePointer):
      (JSC::DFG::Node::hasStoragePointer):
      (JSC::DFG::Node::storagePointer):
      * dfg/DFGNodeType.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileConstantStoragePointer):
      (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
      * dfg/DFGSpeculativeJIT.h:
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGStrengthReductionPhase.cpp:
      (JSC::DFG::StrengthReductionPhase::handleNode):
      (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant):
      (JSC::DFG::StrengthReductionPhase::prepareToFoldTypedArray):
      * dfg/DFGWatchpointCollectionPhase.cpp:
      (JSC::DFG::WatchpointCollectionPhase::handle):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileConstantStoragePointer):
      (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160295 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9ca951e8
  2. 08 Dec, 2013 1 commit
    • fpizlo@apple.com's avatar
      Fold typedArray.length if typedArray is constant · ce995b22
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125252
      
      Source/JavaScriptCore: 
      
      Reviewed by Sam Weinig.
              
      This was meant to be easy. The problem is that there was no good place for putting
      the folding of typedArray.length to a constant. You can't quite do it in the
      bytecode parser because at that point you don't yet know if typedArray is really
      a typed array. You can't do it as part of constant folding because the folder
      assumes that it can opportunistically forward-flow a constant value without changing
      the IR; this doesn't work since we need to first change the IR to register a
      desired watchpoint and only after that can we introduce that constant. We could have
      done it in Fixup but that would have been awkward since Fixup's code for turning a
      GetById of "length" into GetArrayLength is already somewhat complex. We could have
      done it in CSE but CSE is already fairly gnarly and will probably get rewritten.
              
      So I introduced a new phase, called StrengthReduction. This phase should have any
      transformations that don't requite CFA or CSE and that it would be weird to put into
      those other phases.
              
      I also took the opportunity to refactor some of the other folding code.
              
      This also adds a test, but the test couldn't quite be a LayoutTests/js/regress so I
      introduced the notion of JavaScriptCore/tests/stress.
              
      The goal of this patch isn't really to improve performance or anything like that.
      It adds an optimization for completeness, and in doing so it unlocks a bunch of new
      possibilities. The one that I'm most excited about is revealing array length checks
      in DFG IR, which will allow for array bounds check hoisting and elimination.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::tryGetFoldableView):
      (JSC::DFG::Graph::tryGetFoldableViewForChild1):
      * dfg/DFGGraph.h:
      * dfg/DFGNode.h:
      (JSC::DFG::Node::hasTypedArray):
      (JSC::DFG::Node::typedArray):
      * dfg/DFGNodeType.h:
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::compileInThreadImpl):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds):
      (JSC::DFG::SpeculativeJIT::compileConstantIndexedPropertyStorage):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGStrengthReductionPhase.cpp: Added.
      (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase):
      (JSC::DFG::StrengthReductionPhase::run):
      (JSC::DFG::StrengthReductionPhase::handleNode):
      (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant):
      (JSC::DFG::performStrengthReduction):
      * dfg/DFGStrengthReductionPhase.h: Added.
      * dfg/DFGWatchpointCollectionPhase.cpp:
      (JSC::DFG::WatchpointCollectionPhase::handle):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
      (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
      (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
      * jsc.cpp:
      (GlobalObject::finishCreation):
      (functionTransferArrayBuffer):
      * runtime/ArrayBufferView.h:
      * tests/stress: Added.
      * tests/stress/fold-typed-array-properties.js: Added.
      (foo):
      
      Tools: 
      
      Reviewed by Sam Weinig.
              
      Add Source/JavaScriptCore/tests/stress to the set of JS tests. This is where you
      should put tests that run just like JSRegress but don't run as part of LayoutTests.
      Currently I'm using it for tests that require some surgical support from jsc.cpp.
      
      * Scripts/run-javascriptcore-tests:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160292 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ce995b22
  3. 05 Dec, 2013 1 commit
    • fpizlo@apple.com's avatar
      Fold constant typed arrays · ee327c85
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125205
      
      Source/JavaScriptCore: 
      
      Reviewed by Oliver Hunt and Mark Hahnenberg.
              
      If by some other mechanism we have a typed array access on a compile-time constant
      typed array pointer, then fold:
              
      - Array bounds checks. Specifically, fold the load of length.
              
      - Loading the vector.
              
      This needs to install a watchpoint on the array itself because of the possibility of
      neutering. Neutering is ridiculous. We do this without bloating the size of
      ArrayBuffer or JSArrayBufferView in the common case (i.e. the case where you
      allocated an array that didn't end up becoming a compile-time constant). To install
      the watchpoint, we slowDownAndWasteMemory and then create an incoming reference to
      the ArrayBuffer, where that incoming reference is from a watchpoint object. The
      ArrayBuffer already knows about such incoming references and can fire the
      watchpoints that way.
              
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * dfg/DFGDesiredWatchpoints.cpp:
      (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
      (JSC::DFG::DesiredWatchpoints::addLazily):
      * dfg/DFGDesiredWatchpoints.h:
      (JSC::DFG::GenericSetAdaptor::add):
      (JSC::DFG::GenericSetAdaptor::hasBeenInvalidated):
      (JSC::DFG::ArrayBufferViewWatchpointAdaptor::hasBeenInvalidated):
      (JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
      (JSC::DFG::GenericDesiredWatchpoints::areStillValid):
      (JSC::DFG::GenericDesiredWatchpoints::isStillValid):
      (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState):
      (JSC::DFG::DesiredWatchpoints::isStillValid):
      (JSC::DFG::DesiredWatchpoints::shouldAssumeMixedState):
      (JSC::DFG::DesiredWatchpoints::isValidOrMixed):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::tryGetFoldableView):
      * dfg/DFGGraph.h:
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds):
      (JSC::DFG::SpeculativeJIT::emitTypedArrayBoundsCheck):
      (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
      (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
      (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
      (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
      (JSC::DFG::SpeculativeJIT::compileConstantIndexedPropertyStorage):
      (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
      * dfg/DFGSpeculativeJIT.h:
      * dfg/DFGWatchpointCollectionPhase.cpp:
      (JSC::DFG::WatchpointCollectionPhase::handle):
      (JSC::DFG::WatchpointCollectionPhase::addLazily):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
      (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
      (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
      (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
      * runtime/ArrayBuffer.cpp:
      (JSC::ArrayBuffer::transfer):
      * runtime/ArrayBufferNeuteringWatchpoint.cpp: Added.
      (JSC::ArrayBufferNeuteringWatchpoint::ArrayBufferNeuteringWatchpoint):
      (JSC::ArrayBufferNeuteringWatchpoint::~ArrayBufferNeuteringWatchpoint):
      (JSC::ArrayBufferNeuteringWatchpoint::finishCreation):
      (JSC::ArrayBufferNeuteringWatchpoint::destroy):
      (JSC::ArrayBufferNeuteringWatchpoint::create):
      (JSC::ArrayBufferNeuteringWatchpoint::createStructure):
      * runtime/ArrayBufferNeuteringWatchpoint.h: Added.
      (JSC::ArrayBufferNeuteringWatchpoint::set):
      * runtime/VM.cpp:
      (JSC::VM::VM):
      * runtime/VM.h:
      
      LayoutTests: 
      
      Reviewed by Oliver Hunt and Mark Hahnenberg.
      
      * js/regress/fixed-typed-array-storage-expected.txt: Added.
      * js/regress/fixed-typed-array-storage-var-index-expected.txt: Added.
      * js/regress/fixed-typed-array-storage-var-index.html: Added.
      * js/regress/fixed-typed-array-storage.html: Added.
      * js/regress/script-tests/fixed-typed-array-storage-var-index.js: Added.
      (foo):
      * js/regress/script-tests/fixed-typed-array-storage.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160150 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ee327c85
  4. 02 Dec, 2013 1 commit
    • fpizlo@apple.com's avatar
      Instead of watchpointing activation allocation, we should watchpoint entry... · a4ea0663
      fpizlo@apple.com authored
      Instead of watchpointing activation allocation, we should watchpoint entry into functions that have captured variables
      https://bugs.webkit.org/show_bug.cgi?id=125052
      
      Reviewed by Mark Hahnenberg.
              
      This makes us watch function entry rather than activation creation. We only incur the
      costs of doing so for functions that have captured variables, and only on the first two
      entries into the function. This means that closure variable constant inference will
      naturally work even for local uses of the captured variable, like:
              
          (function(){
              var blah = 42;
              ... // stuff
              function () { ... blah /* we can fold this to 42 */ }
              ... blah // we can also fold this to 42.
          })();
              
      Previously, only the nested use would have been foldable.
      
      * bytecode/BytecodeLivenessAnalysis.cpp:
      (JSC::computeUsesForBytecodeOffset):
      (JSC::computeDefsForBytecodeOffset):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpBytecode):
      * bytecode/Opcode.h:
      (JSC::padOpcodeName):
      * bytecode/Watchpoint.h:
      (JSC::WatchpointSet::touch):
      (JSC::InlineWatchpointSet::touch):
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::capabilityLevel):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::hasSymbolTable):
      * dfg/DFGNodeType.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGWatchpointCollectionPhase.cpp:
      (JSC::DFG::WatchpointCollectionPhase::handle):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompileMainPass):
      * jit/JIT.h:
      * jit/JITOpcodes.cpp:
      (JSC::JIT::emit_op_touch_entry):
      * llint/LowLevelInterpreter.asm:
      * runtime/CommonSlowPaths.cpp:
      (JSC::SLOW_PATH_DECL):
      * runtime/CommonSlowPaths.h:
      * runtime/JSActivation.h:
      (JSC::JSActivation::create):
      * runtime/SymbolTable.cpp:
      (JSC::SymbolTable::SymbolTable):
      * runtime/SymbolTable.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159942 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a4ea0663
  5. 28 Nov, 2013 1 commit
    • fpizlo@apple.com's avatar
      Infer one-time scopes · 1a72409c
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124812
      
      Source/JavaScriptCore: 
      
      Reviewed by Oliver Hunt.
              
      This detects JSActivations that are created only once. The JSActivation pointer is then
      baked into the machine code.
              
      This takes advantage of the one-time scope inference to reduce the number of
      indirections needed to get to a closure variable in case where the scope is only
      allocated once. This isn't really a speed-up since in the common case the total number
      of instruction bytes needed to load the scope from the stack is about equal to the
      number of instruction bytes needed to materialize the absolute address of a scoped
      variable. But, this is a necessary prerequisite to
      https://bugs.webkit.org/show_bug.cgi?id=124630, so it's probably a good idea anyway.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpBytecode):
      (JSC::CodeBlock::CodeBlock):
      (JSC::CodeBlock::finalizeUnconditionally):
      * bytecode/Instruction.h:
      * bytecode/Opcode.h:
      (JSC::padOpcodeName):
      * bytecode/Watchpoint.h:
      (JSC::WatchpointSet::notifyWrite):
      (JSC::InlineWatchpointSet::notifyWrite):
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::emitResolveScope):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::scopedVarLoadElimination):
      (JSC::DFG::CSEPhase::scopedVarStoreElimination):
      (JSC::DFG::CSEPhase::getLocalLoadElimination):
      (JSC::DFG::CSEPhase::setLocalStoreElimination):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::tryGetRegisters):
      * dfg/DFGGraph.h:
      * dfg/DFGNode.h:
      (JSC::DFG::Node::varNumber):
      (JSC::DFG::Node::hasSymbolTable):
      (JSC::DFG::Node::symbolTable):
      * dfg/DFGNodeType.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGWatchpointCollectionPhase.cpp:
      (JSC::DFG::WatchpointCollectionPhase::handle):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileGetClosureRegisters):
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      * runtime/JSActivation.h:
      (JSC::JSActivation::create):
      * runtime/JSScope.cpp:
      (JSC::abstractAccess):
      (JSC::JSScope::abstractResolve):
      * runtime/JSScope.h:
      (JSC::ResolveOp::ResolveOp):
      * runtime/JSVariableObject.h:
      (JSC::JSVariableObject::registers):
      * runtime/SymbolTable.cpp:
      (JSC::SymbolTable::SymbolTable):
      * runtime/SymbolTable.h:
      
      LayoutTests: 
      
      Reviewed by Oliver Hunt.
      
      * js/regress/infer-one-time-closure-expected.txt: Added.
      * js/regress/infer-one-time-closure-ten-vars-expected.txt: Added.
      * js/regress/infer-one-time-closure-ten-vars.html: Added.
      * js/regress/infer-one-time-closure-two-vars-expected.txt: Added.
      * js/regress/infer-one-time-closure-two-vars.html: Added.
      * js/regress/infer-one-time-closure.html: Added.
      * js/regress/infer-one-time-deep-closure-expected.txt: Added.
      * js/regress/infer-one-time-deep-closure.html: Added.
      * js/regress/script-tests/infer-one-time-closure-ten-vars.js: Added.
      * js/regress/script-tests/infer-one-time-closure-two-vars.js: Added.
      * js/regress/script-tests/infer-one-time-closure.js: Added.
      * js/regress/script-tests/infer-one-time-deep-closure.js: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159834 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      1a72409c
  6. 27 Nov, 2013 1 commit
    • fpizlo@apple.com's avatar
      Restructure global variable constant inference so that it could work for any... · 8646834a
      fpizlo@apple.com authored
      Restructure global variable constant inference so that it could work for any kind of symbol table variable
      https://bugs.webkit.org/show_bug.cgi?id=124760
      
      Reviewed by Oliver Hunt.
              
      This changes the way global variable constant inference works so that it can be reused
      for closure variable constant inference. Some of the premises that originally motivated
      this patch are somewhat wrong, but it led to some simplifications anyway and I suspect
      that we'll be able to fix those premises in the future. The main point of this patch is
      to make it easy to reuse global variable constant inference for closure variable
      constant inference, and this will be possible provided we can also either (a) infer
      one-shot closures (easy) or (b) infer closure variables that are always assigned prior
      to first use.
              
      One of the things that this patch is meant to enable is constant inference for closure
      variables that may be part of a multi-shot closure. Closure variables may be
      instantiated multiple times, like:
              
          function foo() {
              var WIDTH = 45;
              function bar() {
                  ... use WIDTH ...
              }
              ...
          }
              
      Even if foo() is called many times and WIDTH is assigned to multiple times, that
      doesn't change the fact that it's a constant. The goal of closure variable constant
      inference is to catch any case where a closure variable has been assigned at least once
      and its value has never changed. This patch doesn't implement that, but it does change
      global variable constant inference to have most of the powers needed to do that. Note
      that most likely we will use this functionality only to implement constant inference
      for one-shot closures, but the resulting machinery is still simpler than what we had
      before.
              
      This involves three changes:
              
          - The watchpoint object now contains the inferred value. This involves creating a
            new kind of watchpoint set, the VariableWatchpointSet. We will reuse this object
            for closure variables.
              
          - Writing to a variable that is watchpointed still involves these three states that
            we proceed through monotonically (Uninitialized->Initialized->Invalidated) but
            now, the Initialized->Invalidated state transition only happens if we change the
            variable's value, rather than store to the variable. Repeatedly storing the same
            value won't change the variable's state.
              
          - On 64-bit systems (the only systems on which we do concurrent JIT), you no longer
            need fancy fencing to get a consistent view of the watchpoint in the JIT. The
            state of the VariableWatchpointSet for the purposes of constant folding is
            entirely encapsulated in the VariableWatchpointSet::m_inferredValue. If that is
            JSValue() then you cannot fold (either because the set is uninitialized or
            because it's invalidated - doesn't matter which); on the other hand if the value
            is anything other than JSValue() then you can fold, and that's the value you fold
            to. Simple!
              
      This also changes the way that DFG IR deals with variable watchpoints. It's now
      oblivious to global variables. You install a watchpoint using VariableWatchpoint and
      you notify write using NotifyWrite. Easy!
              
      Note that this will requires some more tweaks because of the fact that op_enter will
      store Undefined into every captured variable. Hence it won't even work for one-shot
      closures. One-shot closures are easily fixed by introducing another state (so we'll
      have Uninitialized->Undefined->Initialized->Invalidated). Multi-shot closures will
      require static analysis. One-shot closures are clearly a higher priority.
      
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/Instruction.h:
      * bytecode/VariableWatchpointSet.h: Added.
      (JSC::VariableWatchpointSet::VariableWatchpointSet):
      (JSC::VariableWatchpointSet::~VariableWatchpointSet):
      (JSC::VariableWatchpointSet::inferredValue):
      (JSC::VariableWatchpointSet::notifyWrite):
      (JSC::VariableWatchpointSet::invalidate):
      (JSC::VariableWatchpointSet::finalizeUnconditionally):
      (JSC::VariableWatchpointSet::addressOfInferredValue):
      * bytecode/Watchpoint.h:
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::hasRegisterPointer):
      (JSC::DFG::Node::hasVariableWatchpointSet):
      (JSC::DFG::Node::variableWatchpointSet):
      * dfg/DFGNodeType.h:
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileArithMod):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGWatchpointCollectionPhase.cpp:
      (JSC::DFG::WatchpointCollectionPhase::handle):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileNotifyWrite):
      * jit/JIT.h:
      * jit/JITOperations.h:
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emitNotifyWrite):
      (JSC::JIT::emitPutGlobalVar):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emitNotifyWrite):
      (JSC::JIT::emitPutGlobalVar):
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::addGlobalVar):
      (JSC::JSGlobalObject::addFunction):
      * runtime/JSGlobalObject.h:
      * runtime/JSScope.h:
      (JSC::ResolveOp::ResolveOp):
      * runtime/JSSymbolTableObject.h:
      (JSC::symbolTablePut):
      (JSC::symbolTablePutWithAttributes):
      * runtime/SymbolTable.cpp:
      (JSC::SymbolTableEntry::inferredValue):
      (JSC::SymbolTableEntry::prepareToWatch):
      (JSC::SymbolTableEntry::addWatchpoint):
      (JSC::SymbolTableEntry::notifyWriteSlow):
      (JSC::SymbolTable::visitChildren):
      (JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup):
      (JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup):
      (JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally):
      * runtime/SymbolTable.h:
      (JSC::SymbolTableEntry::watchpointSet):
      (JSC::SymbolTableEntry::notifyWrite):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159798 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8646834a
  7. 30 Oct, 2013 1 commit
    • fpizlo@apple.com's avatar
      Add InvalidationPoints to the DFG and use them for all watchpoints · d84425d1
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123472
      
      Reviewed by Mark Hahnenberg.
              
      This makes a fundamental change to how watchpoints work in the DFG.
              
      Previously, a watchpoint was an instruction whose execution semantics were something
      like:
              
          if (watchpoint->invalidated)
              exit
              
      We would implement this without any branch by using jump replacement.
              
      This is a very good optimization. But it's a bit awkward once you get a lot of
      watchpoints: semantically we will have lots of these branches in the code, which the
      compiler needs to reason about even though they don't actually result in any emitted
      code.
              
      Separately, we also had a mechanism for jettisoning a CodeBlock. This mechanism would
      be invoked if a CodeBlock exited a lot. It would ensure that a CodeBlock wouldn't be
      called into again, but it would do nothing for CodeBlocks that were already on the
      stack.
              
      This change flips jettisoning and watchpoint invalidation on their heads. Now, the jump
      replacement has nothing to do with watchpoints; instead it's something that happens if
      you ever jettison a CodeBlock. Jump replacement is now an all-or-nothing operation over
      all of the potential call-return safe-exit-points in a CodeBlock. We call these
      "InvalidationPoint"s. A watchpoint instruction is now "lowered" by having the DFG
      collect all of the watchpoint sets that the CodeBlock cares about, and then registering
      a CodeBlockJettisoningWatchpoint with all of them. That is, if the watchpoint fires, it
      jettisons the CodeBlock, which in turn ensures that the CodeBlock can't be called into
      (because the entrypoint now points to baseline code) and can't be returned into
      (because returning exits to baseline before the next bytecode instruction).
              
      This will allow for a sensible lowering of watchpoints to LLVM IR. It will also allow
      for jettison() to be used effectively for things like breakpointing and single-stepping
      in the debugger.
              
      Well, basically, this mechanism just takes us into the HotSpot-style world where anyone
      can, at any time and for any reason, request that an optimized CodeBlock is rendered
      immediately invalid. You can use this for many cool things, I'm sure.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * assembler/AbstractMacroAssembler.h:
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::jettison):
      * bytecode/CodeBlock.h:
      * bytecode/CodeBlockJettisoningWatchpoint.cpp: Added.
      (JSC::CodeBlockJettisoningWatchpoint::fireInternal):
      * bytecode/CodeBlockJettisoningWatchpoint.h: Added.
      (JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint):
      * bytecode/ExitKind.cpp:
      (JSC::exitKindToString):
      * bytecode/ExitKind.h:
      * bytecode/ProfiledCodeBlockJettisoningWatchpoint.cpp: Added.
      (JSC::ProfiledCodeBlockJettisoningWatchpoint::fireInternal):
      * bytecode/ProfiledCodeBlockJettisoningWatchpoint.h: Added.
      (JSC::ProfiledCodeBlockJettisoningWatchpoint::ProfiledCodeBlockJettisoningWatchpoint):
      * dfg/DFGAbstractHeap.h:
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGClobberize.cpp:
      (JSC::DFG::writesOverlap):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      (JSC::DFG::AbstractHeapOverlaps::AbstractHeapOverlaps):
      (JSC::DFG::AbstractHeapOverlaps::operator()):
      (JSC::DFG::AbstractHeapOverlaps::result):
      * dfg/DFGCommonData.cpp:
      (JSC::DFG::CommonData::invalidate):
      * dfg/DFGCommonData.h:
      (JSC::DFG::CommonData::CommonData):
      * dfg/DFGDesiredWatchpoints.cpp:
      (JSC::DFG::DesiredWatchpoints::addLazily):
      (JSC::DFG::DesiredWatchpoints::reallyAdd):
      * dfg/DFGDesiredWatchpoints.h:
      (JSC::DFG::WatchpointForGenericWatchpointSet::WatchpointForGenericWatchpointSet):
      (JSC::DFG::GenericDesiredWatchpoints::addLazily):
      (JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
      (JSC::DFG::GenericDesiredWatchpoints::areStillValid):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGInvalidationPointInjectionPhase.cpp: Added.
      (JSC::DFG::InvalidationPointInjectionPhase::InvalidationPointInjectionPhase):
      (JSC::DFG::InvalidationPointInjectionPhase::run):
      (JSC::DFG::InvalidationPointInjectionPhase::handle):
      (JSC::DFG::InvalidationPointInjectionPhase::insertInvalidationCheck):
      (JSC::DFG::performInvalidationPointInjection):
      * dfg/DFGInvalidationPointInjectionPhase.h: Added.
      * dfg/DFGJITCode.h:
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::linkOSRExits):
      (JSC::DFG::JITCompiler::link):
      * dfg/DFGJITCompiler.h:
      * dfg/DFGJumpReplacement.cpp: Added.
      (JSC::DFG::JumpReplacement::fire):
      * dfg/DFGJumpReplacement.h: Added.
      (JSC::DFG::JumpReplacement::JumpReplacement):
      * dfg/DFGNodeType.h:
      * dfg/DFGOSRExitCompilationInfo.h:
      * dfg/DFGOperations.cpp:
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::compileInThreadImpl):
      (JSC::DFG::Plan::reallyAdd):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
      (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid):
      (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
      (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
      (JSC::DFG::SpeculativeJIT::compileObjectEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
      (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
      (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
      (JSC::DFG::SpeculativeJIT::compileObjectEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
      (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGWatchpointCollectionPhase.cpp: Added.
      (JSC::DFG::WatchpointCollectionPhase::WatchpointCollectionPhase):
      (JSC::DFG::WatchpointCollectionPhase::run):
      (JSC::DFG::WatchpointCollectionPhase::handle):
      (JSC::DFG::WatchpointCollectionPhase::handleEdge):
      (JSC::DFG::WatchpointCollectionPhase::handleMasqueradesAsUndefined):
      (JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal):
      (JSC::DFG::WatchpointCollectionPhase::addLazily):
      (JSC::DFG::WatchpointCollectionPhase::globalObject):
      (JSC::DFG::performWatchpointCollection):
      * dfg/DFGWatchpointCollectionPhase.h: Added.
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint):
      (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
      (JSC::FTL::LowerDFGToLLVM::compileGlobalVarWatchpoint):
      (JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
      (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEqConstant):
      (JSC::FTL::LowerDFGToLLVM::compileInvalidationPoint):
      (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
      (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
      * jit/JITOperations.cpp:
      * jit/JumpReplacementWatchpoint.cpp: Removed.
      * jit/JumpReplacementWatchpoint.h: Removed.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158304 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d84425d1