1. 02 Jan, 2014 1 commit
    • fpizlo@apple.com's avatar
      Rationalize DFG DCE · 9775655d
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125523
      
      Reviewed by Mark Hahnenberg.
              
      Adds the ability to DCE more things. It's now the case that if a node is completely
      pure, we clear NodeMustGenerate and the node becomes a DCE candidate.
      
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGDCEPhase.cpp:
      (JSC::DFG::DCEPhase::cleanVariables):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::clobbersWorld):
      * dfg/DFGNodeType.h:
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileAdd):
      * dfg/DFGSpeculativeJIT.h:
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@161218 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9775655d
  2. 29 Dec, 2013 1 commit
    • fpizlo@apple.com's avatar
      Get rid of DFG forward exiting · 9df7fef8
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125531
      
      Reviewed by Oliver Hunt.
              
      This finally gets rid of forward exiting. Forward exiting was always a fragile concept
      since it involved the compiler trying to figure out how to "roll forward" the
      execution from some DFG node to the next bytecode index. It was always easy to find
      counterexamples where it broke, and it has always served as an obstacle to adding
      compiler improvements - the latest being http://webkit.org/b/125523, which tried to
      make DCE work for more things.
              
      This change finishes the work of removing forward exiting. A lot of forward exiting
      was already removed in some other bugs, but SetLocal still did forward exits. SetLocal
      is in many ways the hardest to remove, since the forward exiting of SetLocal also
      implied that any conversion nodes inserted before the SetLocal would then also be
      marked as forward-exiting. Hence SetLocal's forward-exiting made a bunch of other
      things also forward-exiting, and this was always a source of weirdo bugs.
              
      SetLocal must be able to exit in case it performs a hoisted type speculation. Nodes
      inserted just before SetLocal must also be able to exit - for example type check
      hoisting may insert a CheckStructure, or fixup phase may insert something like
      Int32ToDouble. But if any of those nodes tried to backward exit, then this could lead
      to the reexecution of a side-effecting operation, for example:
              
          a: Call(...)
          b: SetLocal(@a, r1)
              
      For a long time it seemed like SetLocal *had* to exit forward because of this. But
      this change side-steps the problem by changing the ByteCodeParser to always emit a
      kind of "two-phase commit" for stores to local variables. Now when the ByteCodeParser
      wishes to store to a local, it first emits a MovHint and then enqueues a SetLocal.
      The SetLocal isn't actually emitted until the beginning of the next bytecode
      instruction (which the exception of op_enter and op_ret, which emit theirs immediately
      since it's always safe to reexecute those bytecode instructions and since deferring
      SetLocals would be weird there - op_enter has many SetLocals and op_ret is a set
      followed by a jump in case of inlining, so we'd have to emit the SetLocal "after" the
      jump and that would be awkward). This means that the above IR snippet would look
      something like:
              
          a: Call(..., bc#42)
          b: MovHint(@a, r1, bc#42)
          c: SetLocal(@a, r1, bc#47)
              
      Where the SetLocal exits "backwards" but appears at the beginning of the next bytecode
      instruction. This means that by the time we get to that SetLocal, the OSR exit
      analysis already knows that r1 is associated with @a, and it means that the SetLocal
      or anything hoisted above it can exit backwards as normal.
              
      This change also means that the "forward rewiring" can be killed. Previously, we might
      have inserted a conversion node on SetLocal and then the SetLocal died (i.e. turned
      into a MovHint) and the conversion node either died completely or had its lifetime
      truncated to be less than the actual value's bytecode lifetime. This no longer happens
      since conversion nodes are only inserted at SetLocals.
              
      More precisely, this change introduces two laws that we were basically already
      following anyway:
              
      1) A MovHint's child should never be changed except if all other uses of that child
         are also replaced. Specifically, this prohibits insertion of conversion nodes at
         MovHints.
              
      2) Anytime any child is replaced with something else, and all other uses aren't also
         replaced, we must insert a Phantom use of the original child.
      
      This is a slight compile-time regression but has no effect on code-gen. It unlocks a
      bunch of optimization opportunities so I think it's worth it.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpAssumingJITType):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::instructionCount):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
      * dfg/DFGArgumentsSimplificationPhase.cpp:
      (JSC::DFG::ArgumentsSimplificationPhase::run):
      * dfg/DFGArrayifySlowPathGenerator.h:
      (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
      * dfg/DFGBackwardsPropagationPhase.cpp:
      (JSC::DFG::BackwardsPropagationPhase::propagate):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::setDirect):
      (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal):
      (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute):
      (JSC::DFG::ByteCodeParser::handleInlining):
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::eliminate):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGCommon.h:
      * dfg/DFGConstantFoldingPhase.cpp:
      (JSC::DFG::ConstantFoldingPhase::foldConstants):
      * dfg/DFGDCEPhase.cpp:
      (JSC::DFG::DCEPhase::run):
      (JSC::DFG::DCEPhase::fixupBlock):
      (JSC::DFG::DCEPhase::cleanVariables):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      (JSC::DFG::FixupPhase::fixEdge):
      (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
      * dfg/DFGLICMPhase.cpp:
      (JSC::DFG::LICMPhase::run):
      (JSC::DFG::LICMPhase::attemptHoist):
      * dfg/DFGMinifiedNode.cpp:
      (JSC::DFG::MinifiedNode::fromNode):
      * dfg/DFGMinifiedNode.h:
      (JSC::DFG::belongsInMinifiedGraph):
      (JSC::DFG::MinifiedNode::constantNumber):
      (JSC::DFG::MinifiedNode::weakConstant):
      * dfg/DFGNode.cpp:
      (JSC::DFG::Node::hasVariableAccessData):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::convertToPhantom):
      (JSC::DFG::Node::convertToPhantomUnchecked):
      (JSC::DFG::Node::convertToIdentity):
      (JSC::DFG::Node::containsMovHint):
      (JSC::DFG::Node::hasUnlinkedLocal):
      (JSC::DFG::Node::willHaveCodeGenOrOSR):
      * dfg/DFGNodeFlags.cpp:
      (JSC::DFG::dumpNodeFlags):
      * dfg/DFGNodeFlags.h:
      * dfg/DFGNodeType.h:
      * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
      (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
      * dfg/DFGOSREntrypointCreationPhase.cpp:
      (JSC::DFG::OSREntrypointCreationPhase::run):
      * dfg/DFGOSRExit.cpp:
      * dfg/DFGOSRExit.h:
      * dfg/DFGOSRExitBase.cpp:
      * dfg/DFGOSRExitBase.h:
      (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
      * dfg/DFGSSAConversionPhase.cpp:
      (JSC::DFG::SSAConversionPhase::run):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::speculationCheck):
      (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
      (JSC::DFG::SpeculativeJIT::typeCheck):
      (JSC::DFG::SpeculativeJIT::compileMovHint):
      (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
      (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
      (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
      (JSC::DFG::SpeculativeJIT::needsTypeCheck):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGTypeCheckHoistingPhase.cpp:
      (JSC::DFG::TypeCheckHoistingPhase::run):
      (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
      (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
      * dfg/DFGValidate.cpp:
      (JSC::DFG::Validate::validateCPS):
      * dfg/DFGVariableAccessData.h:
      (JSC::DFG::VariableAccessData::VariableAccessData):
      * dfg/DFGVariableEventStream.cpp:
      (JSC::DFG::VariableEventStream::reconstruct):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileGetArgument):
      (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
      (JSC::FTL::LowerDFGToLLVM::compileMovHint):
      (JSC::FTL::LowerDFGToLLVM::compileZombieHint):
      (JSC::FTL::LowerDFGToLLVM::compileInt32ToDouble):
      (JSC::FTL::LowerDFGToLLVM::speculate):
      (JSC::FTL::LowerDFGToLLVM::typeCheck):
      (JSC::FTL::LowerDFGToLLVM::appendTypeCheck):
      (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
      (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
      * ftl/FTLOSRExit.cpp:
      * ftl/FTLOSRExit.h:
      * tests/stress/dead-int32-to-double.js: Added.
      (foo):
      * tests/stress/dead-uint32-to-number.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@161126 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9df7fef8
  3. 18 Dec, 2013 1 commit
    • mhahnenberg@apple.com's avatar
      DFG should have a separate StoreBarrier node · 4968e1a3
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125530
      
      Reviewed by Filip Pizlo.
      
      Source/JavaScriptCore: 
      
      This is in preparation for GenGC. We use a separate StoreBarrier node instead of making them implicitly 
      part of other nodes so that it's easier to run analyses on them, e.g. for the StoreBarrierElisionPhase. 
      They are inserted during the fixup phase. Initially they do not generate any code.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * dfg/DFGAbstractHeap.h:
      * dfg/DFGAbstractInterpreter.h:
      (JSC::DFG::AbstractInterpreter::isKnownNotCell):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberizeForAllocation):
      (JSC::DFG::clobberize):
      * dfg/DFGConstantFoldingPhase.cpp:
      (JSC::DFG::ConstantFoldingPhase::foldConstants): Whenever we insert new nodes that require StoreBarriers,
      we have to add those new StoreBarriers too. It's important to note that AllocatePropertyStorage and 
      ReallocatePropertyStorage nodes require their StoreBarriers to come after them since they allocate first,
      which could cause a GC, and then store the resulting buffer into their JSCell, which requires the barrier.
      If we ever require that write barriers occur before stores, we'll have to split these nodes into 
      AllocatePropertyStorage + StoreBarrier + PutPropertyStorage.
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      (JSC::DFG::FixupPhase::insertStoreBarrier):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::isStoreBarrier):
      * dfg/DFGNodeType.h:
      * dfg/DFGOSRExitCompiler32_64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGOSRExitCompiler64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * 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::compileAllocatePropertyStorage):
      (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
      (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
      (JSC::DFG::SpeculativeJIT::genericWriteBarrier): The fast path write barrier check. It loads the 
      byte that contains the mark bit of the object. 
      (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): If the fast path check fails we try to store the 
      cell in the WriteBarrierBuffer so as to avoid frequently flushing all registers in order to make a C call.
      (JSC::DFG::SpeculativeJIT::writeBarrier):
      (JSC::DFG::SpeculativeJIT::osrWriteBarrier): More barebones version of the write barrier to be executed 
      during an OSR exit into baseline code. We must do this so that the baseline JIT object and array profiles 
      are properly cleared during GC.
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::cachedPutById):
      (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
      (JSC::DFG::SpeculativeJIT::compile):
      (JSC::DFG::SpeculativeJIT::writeBarrier):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::cachedPutById):
      (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
      (JSC::DFG::SpeculativeJIT::compile):
      (JSC::DFG::SpeculativeJIT::writeBarrier):
      * dfg/DFGStoreBarrierElisionPhase.cpp: Added. New DFG phase that does block-local elision of redundant
      StoreBarriers. Every time a StoreBarrier on a particular object is executed, a bit is set indicating that 
      that object doesn't need any more StoreBarriers. 
      (JSC::DFG::StoreBarrierElisionPhase::StoreBarrierElisionPhase):
      (JSC::DFG::StoreBarrierElisionPhase::couldCauseGC): Nodes that could cause a GC reset the bits for all of the 
      objects known in the current block. 
      (JSC::DFG::StoreBarrierElisionPhase::allocatesFreshObject): A node that creates a new object automatically 
      sets the bit for that object since if a GC occurred as the result of that object's allocation then that 
      object would not need a barrier since it would be guaranteed to be a young generation object until the 
      next GC point.
      (JSC::DFG::StoreBarrierElisionPhase::noticeFreshObject):
      (JSC::DFG::StoreBarrierElisionPhase::getBaseOfStore):
      (JSC::DFG::StoreBarrierElisionPhase::shouldBeElided):
      (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
      (JSC::DFG::StoreBarrierElisionPhase::handleNode):
      (JSC::DFG::StoreBarrierElisionPhase::handleBlock):
      (JSC::DFG::StoreBarrierElisionPhase::run):
      (JSC::DFG::performStoreBarrierElision):
      * dfg/DFGStoreBarrierElisionPhase.h: Added.
      * heap/Heap.cpp:
      (JSC::Heap::Heap):
      (JSC::Heap::flushWriteBarrierBuffer):
      * heap/Heap.h:
      (JSC::Heap::writeBarrier):
      * heap/MarkedBlock.h:
      (JSC::MarkedBlock::offsetOfMarks):
      * heap/WriteBarrierBuffer.cpp: Added. The WriteBarrierBuffer buffers a set of JSCells that are awaiting 
      a pending WriteBarrier. This buffer is used by the DFG to avoid the overhead of calling out to C repeatedly
      to invoke a write barrier on a single JSCell. Instead the DFG has inline code to fill the WriteBarrier buffer
      until its full, and then to call out to C to flush it. The WriteBarrierBuffer will also be flushed prior to 
      each EdenCollection.
      (JSC::WriteBarrierBuffer::WriteBarrierBuffer):
      (JSC::WriteBarrierBuffer::~WriteBarrierBuffer):
      (JSC::WriteBarrierBuffer::flush):
      (JSC::WriteBarrierBuffer::reset):
      (JSC::WriteBarrierBuffer::add):
      * heap/WriteBarrierBuffer.h: Added.
      (JSC::WriteBarrierBuffer::currentIndexOffset):
      (JSC::WriteBarrierBuffer::capacityOffset):
      (JSC::WriteBarrierBuffer::bufferOffset):
      * jit/JITOperations.cpp:
      * jit/JITOperations.h:
      * runtime/VM.h:
      
      Source/WTF: 
      
      * wtf/Platform.h: Added an #define for ENABLE(GGC) which will be used for landing things related to GenGC.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160796 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4968e1a3
  4. 14 Dec, 2013 1 commit
    • fpizlo@apple.com's avatar
      Get rid of forward exit on UInt32ToNumber by adding an op_unsigned bytecode instruction · 9089acbe
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125553
      
      Reviewed by Oliver Hunt.
              
      UInt32ToNumber was a super complicated node because it had to do a speculation, but it
      would do it after we already had computed the urshift. It couldn't just back to the
      beginning of the urshift because the inputs to the urshift weren't necessarily live
      anymore. We couldn't jump forward to the beginning of the next instruction because the
      result of the urshift was not yet unsigned-converted.
              
      For a while we solved this by forward-exiting in UInt32ToNumber. But that's really
      gross and I want to get rid of all forward exits. They cause a lot of bugs.
              
      We could also have turned UInt32ToNumber to a backwards exit by forcing the inputs to
      the urshift to be live. I figure that this might be a bit too extreme.
              
      So, I just created a new place that we can exit to: I split op_urshift into op_urshift
      followed by op_unsigned. op_unsigned is an "unsigned cast" along the lines of what
      UInt32ToNumber does. This allows me to get rid of all of the nastyness in the DFG for
      forward exiting in UInt32ToNumber.
              
      This patch enables massive code carnage in the DFG and FTL, and brings us closer to
      eliminating one of the DFG's most confusing concepts. On the flipside, it does make the
      bytecode slightly more complex (one new instruction). This is a profitable trade. We
      want the DFG and FTL to trend towards simplicity, since they are both currently too
      complicated.
      
      * bytecode/BytecodeUseDef.h:
      (JSC::computeUsesForBytecodeOffset):
      (JSC::computeDefsForBytecodeOffset):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpBytecode):
      * bytecode/Opcode.h:
      (JSC::padOpcodeName):
      * bytecode/ValueRecovery.cpp:
      (JSC::ValueRecovery::dumpInContext):
      * bytecode/ValueRecovery.h:
      (JSC::ValueRecovery::gpr):
      * bytecompiler/NodesCodegen.cpp:
      (JSC::BinaryOpNode::emitBytecode):
      (JSC::emitReadModifyAssignment):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::toInt32):
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGNodeType.h:
      * dfg/DFGOSRExitCompiler32_64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGOSRExitCompiler64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileMovHint):
      (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
      * dfg/DFGSpeculativeJIT.h:
      * dfg/DFGSpeculativeJIT32_64.cpp:
      * dfg/DFGSpeculativeJIT64.cpp:
      * dfg/DFGStrengthReductionPhase.cpp:
      (JSC::DFG::StrengthReductionPhase::handleNode):
      (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
      (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild1):
      (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild2):
      * ftl/FTLFormattedValue.h:
      (JSC::FTL::int32Value):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
      * ftl/FTLValueFormat.cpp:
      (JSC::FTL::reboxAccordingToFormat):
      (WTF::printInternal):
      * ftl/FTLValueFormat.h:
      * jit/JIT.cpp:
      (JSC::JIT::privateCompileMainPass):
      (JSC::JIT::privateCompileSlowCases):
      * jit/JIT.h:
      * jit/JITArithmetic.cpp:
      (JSC::JIT::emit_op_urshift):
      (JSC::JIT::emitSlow_op_urshift):
      (JSC::JIT::emit_op_unsigned):
      (JSC::JIT::emitSlow_op_unsigned):
      * jit/JITArithmetic32_64.cpp:
      (JSC::JIT::emitRightShift):
      (JSC::JIT::emitRightShiftSlowCase):
      (JSC::JIT::emit_op_unsigned):
      (JSC::JIT::emitSlow_op_unsigned):
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      * runtime/CommonSlowPaths.cpp:
      (JSC::SLOW_PATH_DECL):
      * runtime/CommonSlowPaths.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160587 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9089acbe
  5. 11 Dec, 2013 1 commit
    • fpizlo@apple.com's avatar
      Get rid of forward exit on DoubleAsInt32 · 5120492e
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125552
      
      PerformanceTests/SunSpider: 
      
      Reviewed by Oliver Hunt.
              
      Use SunSpider as a kind of spot-check for the
      no-architecture-specific-optimization paths in the compiler.
      
      * no-architecture-specific-optimizations.yaml: Added.
      
      Source/JavaScriptCore: 
      
      Reviewed by Oliver Hunt.
              
      The forward exit was just there so that we wouldn't have to keep the inputs alive up to
      the DoubleAsInt32. That's dumb. Forward exits are a complicated piece of machinery and
      we shouldn't have it just for a bit of liveness micro-optimization.
              
      Also add a bunch of machinery to test this case on X86.
      
      * assembler/AbstractMacroAssembler.h:
      (JSC::optimizeForARMv7s):
      (JSC::optimizeForARM64):
      (JSC::optimizeForX86):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNodeType.h:
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
      * runtime/Options.h:
      * tests/stress/double-as-int32.js: Added.
      (foo):
      (test):
      
      Tools: 
      
      Reviewed by Oliver Hunt.
              
      Add some support for testing the generic (non-X86) paths on X86 by disabling
      architecture-specific optimizations (ASO's).
      
      * Scripts/run-javascriptcore-tests:
      * Scripts/run-jsc-stress-tests:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160411 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5120492e
  6. 10 Dec, 2013 1 commit
    • fpizlo@apple.com's avatar
      Reveal array bounds checks in DFG IR · 8624c4b8
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125253
      
      Reviewed by Oliver Hunt and Mark Hahnenberg.
              
      In SSA mode, this reveals array bounds checks and the load of array length in DFG IR,
      making this a candidate for LICM.
      
      This also fixes a long-standing performance bug where the JSObject slow paths would
      always create contiguous storage, rather than type-specialized storage, when doing a
      "storage creating" storage, like:
              
          var o = {};
          o[0] = 42;
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/ExitKind.cpp:
      (JSC::exitKindToString):
      (JSC::exitKindIsCountable):
      * bytecode/ExitKind.h:
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGArrayMode.cpp:
      (JSC::DFG::permitsBoundsCheckLowering):
      (JSC::DFG::ArrayMode::permitsBoundsCheckLowering):
      * dfg/DFGArrayMode.h:
      (JSC::DFG::ArrayMode::lengthNeedsStorage):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGConstantFoldingPhase.cpp:
      (JSC::DFG::ConstantFoldingPhase::foldConstants):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNodeType.h:
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::compileInThreadImpl):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSSALoweringPhase.cpp: Added.
      (JSC::DFG::SSALoweringPhase::SSALoweringPhase):
      (JSC::DFG::SSALoweringPhase::run):
      (JSC::DFG::SSALoweringPhase::handleNode):
      (JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
      (JSC::DFG::performSSALowering):
      * dfg/DFGSSALoweringPhase.h: Added.
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileCheckInBounds):
      (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
      (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
      (JSC::FTL::LowerDFGToLLVM::contiguousPutByValOutOfBounds):
      * runtime/JSObject.cpp:
      (JSC::JSObject::convertUndecidedForValue):
      (JSC::JSObject::createInitialForValueAndSet):
      (JSC::JSObject::putByIndexBeyondVectorLength):
      (JSC::JSObject::putDirectIndexBeyondVectorLength):
      * runtime/JSObject.h:
      * tests/stress/float32array-out-of-bounds.js: Added.
      (make):
      (foo):
      (test):
      * tests/stress/int32-object-out-of-bounds.js: Added.
      (make):
      (foo):
      (test):
      * tests/stress/int32-out-of-bounds.js: Added.
      (foo):
      (test):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160347 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8624c4b8
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 20 Nov, 2013 1 commit
    • fpizlo@apple.com's avatar
      Infer constant global variables · 33961712
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124464
      
      Source/JavaScriptCore: 
      
      Reviewed by Sam Weinig.
              
      All global variables that are candidates for watchpoint-based constant inference (i.e.
      not 'const' variables) will now have WatchpointSet's associated with them and those
      are used to drive the inference by tracking three states of each variable:
              
      Uninitialized: the variable's value is Undefined and the WatchpointSet state is
          ClearWatchpoint.
              
      Initialized: the variable's value was set to something (could even be explicitly set
          to Undefined) and the WatchpointSet state is IsWatching.
              
      Invalidated: the variable's value was set to something else (could even be the same
          thing as before but the point is that a put operation did execute again) and the
          WatchpointSet is IsInvalidated.
              
      If the compiler tries to compile a GetGlobalVar and the WatchpointSet state is
      IsWatching, then the current value of the variable can be folded in place of the get,
      and a watchpoint on the variable can be registered.
              
      We handle race conditions between the mutator and compiler by mandating that:
              
      - The mutator changes the WatchpointSet state after executing the put.
              
      - There is no opportunity to install code or call functions between when the mutator
        executes a put and changes the WatchpointSet state.
              
      - The compiler checks the WatchpointSet state prior to reading the value.
              
      The concrete algorithm used by the mutator is:
              
          1. Store the new value into the variable.
          --- Execute a store-store fence.
          2. Bump the state (ClearWatchpoing becomes IsWatching, IsWatching becomes
             IsInvalidated); the IsWatching->IsInvalidated transition may end up firing
             watchpoints.
              
      The concrete algorithm that the compiler uses is:
              
          1. Load the state. If it's *not* IsWatching, then give up on constant inference.
          --- Execute a load-load fence.
          2. Load the value of the variable and use that for folding, while also registering
             a DesiredWatchpoint. The various parts of this step can be done in any order.
              
      The desired watchpoint registration will fail if the watchpoint set is already
      invalidated. Now consider the following interesting interleavings:
              
      Uninitialized->M1->M2->C1->C2: Compiler sees IsWatching because of the mutator's store
          operation, and the variable is folded. The fencing ensures that C2 sees the value
          stored in M1 - i.e. we fold on the value that will actually be watchpointed. If
          before the compilation is installed the mutator executes another store then we
          will be sure that it will be a complete sequence of M1+M2 since compilations get
          installed at safepoints and never "in the middle" of a put_to_scope. Hence that
          compilation installation will be invalidated. If the M1+M2 sequence happens after
          the code is installed, then the code will be invalidated by triggering a jettison.
              
      Uninitialized->M1->C1->C2->M2: Compiler sees Uninitialized and will not fold. This is
          a sensible outcome since if the compiler read the variable's value, it would have
          seen Undefined.
              
      Uninitialized->C1->C2->M1->M2: Compiler sees Uninitialized and will not fold.
      Uninitialized->C1->M1->C2->M2: Compiler sees Uninitialized and will not fold.
      Uninitialized->C1->M1->M2->C2: Compiler sees Uninitialized and will not fold.
      Uninitialized->M1->C1->M2->C2: Compiler sees Uninitialized and will not fold.
              
      IsWatched->M1->M2->C1->C2: Compiler sees IsInvalidated and will not fold.
              
      IsWatched->M1->C1->C2->M2: Compiler will fold, but will also register a desired
          watchpoint, and that watchpoint will get invalidated before the code is installed.
              
      IsWatched->M1->C1->M2->C2: As above, will fold but the code will get invalidated.
      IsWatched->C1->C2->M1->M2: As above, will fold but the code will get invalidated.
      IsWatched->C1->M1->C2->M2: As above, will fold but the code will get invalidated.
      IsWatched->C1->M1->M2->C2: As above, will fold but the code will get invalidated.
              
      Note that this kind of reasoning shows why having the mutator first bump the state and
      then store the new value would be wrong. If we had done that (M1 = bump state, M2 =
      execute put) then we could have the following deadly interleavings:
              
      Uninitialized->M1->C1->C2->M2:
      Uninitialized->M1->C1->M2->C2: Mutator bumps the state to IsWatched and then the
          compiler folds Undefined, since M2 hasn't executed yet. Although C2 will set the
          watchpoint, M1 didn't notify it - it mearly initiated watching. M2 then stores a
          value other than Undefined, and you're toast.
              
      You could fix this sort of thing by making the Desired Watchpoints machinery more
      sophisticated, for example having it track the value that was folded; if the global
      variable's value was later found to be different then we could invalidate the
      compilation. You could also fix it by having the compiler also check that the value of
      the variable is not Undefined before folding. While those all sound great, I decided
      to instead just use the right interleaving since that results in less code and feels
      more intuitive.
              
      This is a 0.5% speed-up on SunSpider, mostly due to a 20% speed-up on math-cordic.
      It's a 0.6% slow-down on LongSpider, mostly due to a 25% slow-down on 3d-cube. This is
      because 3d-cube takes global variable assignment slow paths very often. Note that this
      3d-cube slow-down doesn't manifest as much in SunSpider (only 6% there). This patch is
      also a 1.5% speed-up on V8v7 and a 2.8% speed-up on Octane v1, mostly due to deltablue
      (3.7%), richards (4%), and mandreel (26%). This is a 2% speed-up on Kraken, mostly due
      to a 17.5% speed-up on imaging-gaussian-blur. Something that really illustrates the
      slam-dunk-itude of this patch is the wide range of speed-ups on JSRegress. Casual JS
      programming often leads to global-var-based idioms and those variables tend to be
      assigned once, leading to excellent constant folding opportunities in an optimizing
      JIT. This is very evident in the speed-ups on JSRegress.
      
      * assembler/ARM64Assembler.h:
      (JSC::ARM64Assembler::dmbSY):
      * assembler/ARMv7Assembler.h:
      (JSC::ARMv7Assembler::dmbSY):
      * assembler/MacroAssemblerARM64.h:
      (JSC::MacroAssemblerARM64::memfence):
      * assembler/MacroAssemblerARMv7.h:
      (JSC::MacroAssemblerARMv7::load8):
      (JSC::MacroAssemblerARMv7::memfence):
      * assembler/MacroAssemblerX86.h:
      (JSC::MacroAssemblerX86::load8):
      (JSC::MacroAssemblerX86::store8):
      * assembler/MacroAssemblerX86Common.h:
      (JSC::MacroAssemblerX86Common::getUnusedRegister):
      (JSC::MacroAssemblerX86Common::store8):
      (JSC::MacroAssemblerX86Common::memoryFence):
      * assembler/MacroAssemblerX86_64.h:
      (JSC::MacroAssemblerX86_64::load8):
      (JSC::MacroAssemblerX86_64::store8):
      * assembler/X86Assembler.h:
      (JSC::X86Assembler::movb_rm):
      (JSC::X86Assembler::movzbl_mr):
      (JSC::X86Assembler::mfence):
      (JSC::X86Assembler::X86InstructionFormatter::threeByteOp):
      (JSC::X86Assembler::X86InstructionFormatter::oneByteOp8):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
      * bytecode/Watchpoint.cpp:
      (JSC::WatchpointSet::WatchpointSet):
      (JSC::WatchpointSet::add):
      (JSC::WatchpointSet::notifyWriteSlow):
      * bytecode/Watchpoint.h:
      (JSC::WatchpointSet::state):
      (JSC::WatchpointSet::isStillValid):
      (JSC::WatchpointSet::addressOfSetIsNotEmpty):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::getJSConstantForValue):
      (JSC::DFG::ByteCodeParser::getJSConstant):
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::isStronglyProvedConstantIn):
      (JSC::DFG::Node::hasIdentifierNumberForCheck):
      (JSC::DFG::Node::hasRegisterPointer):
      * dfg/DFGNodeFlags.h:
      * 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::compileNotifyPutGlobalVar):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * ftl/FTLAbbreviatedTypes.h:
      * ftl/FTLAbbreviations.h:
      (JSC::FTL::buildFence):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLIntrinsicRepository.h:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileNotifyPutGlobalVar):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::fence):
      * jit/JIT.h:
      * jit/JITOperations.h:
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emitPutGlobalVar):
      (JSC::JIT::emit_op_put_to_scope):
      (JSC::JIT::emitSlow_op_put_to_scope):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emitPutGlobalVar):
      (JSC::JIT::emit_op_put_to_scope):
      (JSC::JIT::emitSlow_op_put_to_scope):
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      * llvm/LLVMAPIFunctions.h:
      * offlineasm/arm.rb:
      * offlineasm/arm64.rb:
      * offlineasm/cloop.rb:
      * offlineasm/instructions.rb:
      * offlineasm/x86.rb:
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::addGlobalVar):
      (JSC::JSGlobalObject::addFunction):
      * runtime/JSGlobalObject.h:
      (JSC::JSGlobalObject::addVar):
      (JSC::JSGlobalObject::addConst):
      * runtime/JSScope.cpp:
      (JSC::abstractAccess):
      * runtime/JSSymbolTableObject.h:
      (JSC::symbolTablePut):
      (JSC::symbolTablePutWithAttributes):
      * runtime/SymbolTable.cpp:
      (JSC::SymbolTableEntry::couldBeWatched):
      (JSC::SymbolTableEntry::prepareToWatch):
      (JSC::SymbolTableEntry::notifyWriteSlow):
      * runtime/SymbolTable.h:
      
      LayoutTests: 
      
      Reviewed by Sam Weinig.
      
      * js/regress/global-var-const-infer-expected.txt: Added.
      * js/regress/global-var-const-infer-fire-from-opt-expected.txt: Added.
      * js/regress/global-var-const-infer-fire-from-opt.html: Added.
      * js/regress/global-var-const-infer.html: Added.
      * js/regress/script-tests/global-var-const-infer-fire-from-opt.js: Added.
      (foo):
      (setA):
      (setB):
      (check):
      * js/regress/script-tests/global-var-const-infer.js: Added.
      (foo):
      (check):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159545 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      33961712
  13. 31 Oct, 2013 1 commit
    • fpizlo@apple.com's avatar
      Remove CachedTranscendentalFunction because caching math functions is an ugly idea · b3336c7b
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123574
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Hahnenberg.
              
      This is performance-neutral because I also make Math.cos/sin intrinsic. This means that
      we gain the "overhead" of actually computing sin and cos but we lose the overhead of
      going through the native call thunks.
              
      Caching transcendental functions is a really ugly idea. It works for SunSpider because
      that benchmark makes very predictable calls into Math.sin. But I don't believe that this
      is representative of any kind of reality, and so for sensible uses of Math.sin/cos all
      that this was doing was adding more call overhead and some hashing overhead.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGBackwardsPropagationPhase.cpp:
      (JSC::DFG::BackwardsPropagationPhase::propagate):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::handleIntrinsic):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNodeType.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * jit/JITOperations.h:
      * runtime/CachedTranscendentalFunction.h: Removed.
      * runtime/DateInstanceCache.h:
      * runtime/Intrinsic.h:
      * runtime/MathObject.cpp:
      (JSC::MathObject::finishCreation):
      (JSC::mathProtoFuncCos):
      (JSC::mathProtoFuncSin):
      * runtime/VM.h:
      
      Tools: 
      
      Reviewed by Mark Hahnenberg.
      
      Make it easier to see that a test doesn't have an -expected file.
      
      * Scripts/run-jsc-stress-tests:
      
      LayoutTests: 
      
      Reviewed by Mark Hahnenberg.
      
      * js/dfg-cos-constant-expected.txt: Added.
      * js/dfg-cos-constant.html: Added.
      * js/dfg-sin-constant-expected.txt: Added.
      * js/dfg-sin-constant.html: Added.
      * js/script-tests/dfg-cos-constant.js: Added.
      (foo):
      * js/script-tests/dfg-sin-constant.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158384 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b3336c7b
  14. 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
  15. 28 Oct, 2013 1 commit
    • fpizlo@apple.com's avatar
      Get rid of InlineStart so that I don't have to implement it in FTL · f5be8c90
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123302
      
      Reviewed by Geoffrey Garen.
              
      InlineStart was a special instruction that we would insert at the top of inlined code,
      so that the backend could capture the OSR state of arguments to an inlined call. It used
      to be that only the backend had this information, so this instruction was sort of an ugly
      callback from the backend for filling in some data structures.
              
      But in the time since when that code was written (two years ago?), we rationalized how
      variables work. It's now the case that variables that the runtime must know about are
      treated specially in IR (they are "flushed") and we know how we will represent them even
      before we get to the backend. The last place that makes changes to their representation
      is the StackLayoutPhase.
              
      So, this patch gets rid of InlineStart, but keeps around the special meta-data that the
      instruction had. Instead of handling the bookkeeping in the backend, we handle it in
      StackLayoutPhase. This means that the DFG and FTL can share code for handling this
      bookkeeping. This also means that now the FTL can compile code blocks that had inlining.
              
      Of course, giving the FTL the ability to handle code blocks that had inlining means that
      we're going to have new bugs. Sure enough, the FTL's linker didn't handle inline call
      frames. This patch also fixes that.
      
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::handleInlining):
      (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGGraph.h:
      * dfg/DFGNode.h:
      * dfg/DFGNodeType.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      * dfg/DFGSpeculativeJIT.h:
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGStackLayoutPhase.cpp:
      (JSC::DFG::StackLayoutPhase::run):
      * ftl/FTLLink.cpp:
      (JSC::FTL::link):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@158116 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      f5be8c90
  16. 19 Oct, 2013 1 commit
    • oliver@apple.com's avatar
      Spread operator should be performing direct "puts" and not triggering setters · e050d642
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123047
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore:
      
      Add a new opcode -- op_put_by_val_directue -- and make use of it in the spread
      to array construct.  This required a new PutByValDirect node to be introduced to
      the DFG.  The current implementation simply changes the slow path function that
      is called, but in future this could be made faster as it does not need to check
      the prototype chain.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpBytecode):
      (JSC::CodeBlock::CodeBlock):
      * bytecode/Opcode.h:
      (JSC::padOpcodeName):
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::emitDirectPutByVal):
      * bytecompiler/BytecodeGenerator.h:
      * bytecompiler/NodesCodegen.cpp:
      (JSC::ArrayNode::emitBytecode):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGBackwardsPropagationPhase.cpp:
      (JSC::DFG::BackwardsPropagationPhase::propagate):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::getArrayLengthElimination):
      (JSC::DFG::CSEPhase::getByValLoadElimination):
      (JSC::DFG::CSEPhase::checkStructureElimination):
      (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
      (JSC::DFG::CSEPhase::getByOffsetLoadElimination):
      (JSC::DFG::CSEPhase::putByOffsetStoreElimination):
      (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::capabilityLevel):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::clobbersWorld):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::hasArrayMode):
      * dfg/DFGNodeType.h:
      * dfg/DFGOperations.cpp:
      (JSC::DFG::putByVal):
      (JSC::DFG::operationPutByValInternal):
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGTypeCheckHoistingPhase.cpp:
      (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
      (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompileMainPass):
      (JSC::JIT::privateCompileSlowCases):
      * jit/JIT.h:
      (JSC::JIT::compileDirectPutByVal):
      * jit/JITOperations.cpp:
      * jit/JITOperations.h:
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emitSlow_op_put_by_val):
      (JSC::JIT::privateCompilePutByVal):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emitSlow_op_put_by_val):
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::LLINT_SLOW_PATH_DECL):
      * llint/LLIntSlowPaths.h:
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      
      LayoutTests:
      
      Add a new testcase for the setter case.  run-javascriptcore-tests hits this with
      the llint, baseline, and dfg.
      
      * js/basic-spread-expected.txt:
      * js/script-tests/basic-spread.js:
      (Array):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157656 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e050d642
  17. 28 Sep, 2013 1 commit
    • fpizlo@apple.com's avatar
      Get rid of SetMyScope/SetCallee; use normal variables for the scope and callee... · 48cdafdc
      fpizlo@apple.com authored
      Get rid of SetMyScope/SetCallee; use normal variables for the scope and callee of inlined call frames of closures
      https://bugs.webkit.org/show_bug.cgi?id=122047
      
      Reviewed by Oliver Hunt.
              
      Currently we have the DFG reserve space for inline call frames at exactly the same stack
      offsets that you would have gotten if the baseline interpreter/JIT had made the calls.
      We need to get rid of that. One of the weirder parts of this is that we have special DFG
      operations for accessing these inlined call frame headers. It's really hard for any
      analysis of DFG IR to see what the liveness of any of those frame header "variables" is;
      the liveness behaves like flushed arguments (it's all live until end of the inlinee) but
      we don't have anything like a Flush node for those special variables.
              
      This patch gets rid of the special operations for accessing inline call frame headers.
      GetMyScope and GetCallee still remain, and are only for accessing the machine call
      frame's scope/callee entries. The inline call frame's scope/callee now behave like
      normal variables, and have Flush behavior just like inline arguments.
      
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::getDirect):
      (JSC::DFG::ByteCodeParser::get):
      (JSC::DFG::ByteCodeParser::setDirect):
      (JSC::DFG::ByteCodeParser::set):
      (JSC::DFG::ByteCodeParser::setLocal):
      (JSC::DFG::ByteCodeParser::setArgument):
      (JSC::DFG::ByteCodeParser::flush):
      (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand):
      (JSC::DFG::ByteCodeParser::handleInlining):
      (JSC::DFG::ByteCodeParser::getScope):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::getCalleeLoadElimination):
      (JSC::DFG::CSEPhase::getMyScopeLoadElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * 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):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@156594 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      48cdafdc
  18. 18 Sep, 2013 3 commits
    • fpizlo@apple.com's avatar
      DFG should support Int52 for local variables · 6921b29b
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=121064
      
      Source/JavaScriptCore: 
      
      Reviewed by Oliver Hunt.
              
      This adds Int52 support for local variables to the DFG and FTL. It's a speed-up on
      programs that have local int32 overflows but where a larger int representation can
      prevent us from having to convert all the way up to double.
              
      It's a small speed-up for now. But we're just supporting Int52 for a handful of
      operations (add, sub, mul, neg, compare, bitops, typed array access) and this lays
      the groundwork for adding Int52 to JSValue, which will probably be a bigger
      speed-up.
              
      The basic approach is:
              
      - We have a notion of Int52 in our typesystem. Int52 doesn't belong to BytecodeTop
        or HeapTop - i.e. it doesn't arise from JSValues.
              
      - DFG treats Int52 as being part of its FullTop and will treat it as being a
        subtype of double unless instructed otherwise.
              
      - Prediction propagator creates Int52s whenever we have a node going doubly but due
        to large values rather than fractional values, and that node is known to be able
        to produce Int52 natively in the DFG backend.
              
      - Fixup phase converts edges to MachineIntUses in nodes that are known to be able
        to deal with Int52, and where we have a subtype of Int32|Int52 as the predicted
        input.
              
      - The DFG backend and FTL LLVM IR lowering have two notions of Int52s - ones that
        are left-shifted by 16 (great for overflow checks) and ones that are
        sign-extended. Both backends know how to convert between Int52s and the other
        representations.
      
      * assembler/MacroAssemblerX86_64.h:
      (JSC::MacroAssemblerX86_64::rshift64):
      (JSC::MacroAssemblerX86_64::mul64):
      (JSC::MacroAssemblerX86_64::branchMul64):
      (JSC::MacroAssemblerX86_64::branchNeg64):
      (JSC::MacroAssemblerX86_64::convertInt64ToDouble):
      * assembler/X86Assembler.h:
      (JSC::X86Assembler::imulq_rr):
      (JSC::X86Assembler::cvtsi2sdq_rr):
      * bytecode/DataFormat.h:
      (JSC::dataFormatToString):
      * bytecode/ExitKind.cpp:
      (JSC::exitKindToString):
      * bytecode/ExitKind.h:
      * bytecode/OperandsInlines.h:
      (JSC::::dumpInContext):
      * bytecode/SpeculatedType.cpp:
      (JSC::dumpSpeculation):
      (JSC::speculationToAbbreviatedString):
      (JSC::speculationFromValue):
      * bytecode/SpeculatedType.h:
      (JSC::isInt32SpeculationForArithmetic):
      (JSC::isInt52Speculation):
      (JSC::isMachineIntSpeculationForArithmetic):
      (JSC::isInt52AsDoubleSpeculation):
      (JSC::isBytecodeRealNumberSpeculation):
      (JSC::isFullRealNumberSpeculation):
      (JSC::isBytecodeNumberSpeculation):
      (JSC::isFullNumberSpeculation):
      (JSC::isBytecodeNumberSpeculationExpectingDefined):
      (JSC::isFullNumberSpeculationExpectingDefined):
      * bytecode/ValueRecovery.h:
      (JSC::ValueRecovery::alreadyInJSStackAsUnboxedInt52):
      (JSC::ValueRecovery::inGPR):
      (JSC::ValueRecovery::displacedInJSStack):
      (JSC::ValueRecovery::isAlreadyInJSStack):
      (JSC::ValueRecovery::gpr):
      (JSC::ValueRecovery::virtualRegister):
      (JSC::ValueRecovery::dumpInContext):
      * dfg/DFGAbstractInterpreter.h:
      (JSC::DFG::AbstractInterpreter::needsTypeCheck):
      (JSC::DFG::AbstractInterpreter::filterByType):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGAbstractValue.cpp:
      (JSC::DFG::AbstractValue::set):
      (JSC::DFG::AbstractValue::checkConsistency):
      * dfg/DFGAbstractValue.h:
      (JSC::DFG::AbstractValue::couldBeType):
      (JSC::DFG::AbstractValue::isType):
      (JSC::DFG::AbstractValue::checkConsistency):
      (JSC::DFG::AbstractValue::validateType):
      * dfg/DFGArrayMode.cpp:
      (JSC::DFG::ArrayMode::refine):
      * dfg/DFGAssemblyHelpers.h:
      (JSC::DFG::AssemblyHelpers::boxInt52):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::makeSafe):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::pureCSE):
      (JSC::DFG::CSEPhase::getByValLoadElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGCommon.h:
      (JSC::DFG::enableInt52):
      * dfg/DFGDCEPhase.cpp:
      (JSC::DFG::DCEPhase::fixupBlock):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::run):
      (JSC::DFG::FixupPhase::fixupNode):
      (JSC::DFG::FixupPhase::fixupSetLocalsInBlock):
      (JSC::DFG::FixupPhase::fixupUntypedSetLocalsInBlock):
      (JSC::DFG::FixupPhase::observeUseKindOnNode):
      (JSC::DFG::FixupPhase::fixEdge):
      (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
      (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
      * dfg/DFGFlushFormat.cpp:
      (WTF::printInternal):
      * dfg/DFGFlushFormat.h:
      (JSC::DFG::resultFor):
      (JSC::DFG::useKindFor):
      * dfg/DFGGenerationInfo.h:
      (JSC::DFG::GenerationInfo::initInt52):
      (JSC::DFG::GenerationInfo::initStrictInt52):
      (JSC::DFG::GenerationInfo::isFormat):
      (JSC::DFG::GenerationInfo::isInt52):
      (JSC::DFG::GenerationInfo::isStrictInt52):
      (JSC::DFG::GenerationInfo::fillInt52):
      (JSC::DFG::GenerationInfo::fillStrictInt52):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::addShouldSpeculateMachineInt):
      (JSC::DFG::Graph::mulShouldSpeculateMachineInt):
      (JSC::DFG::Graph::negateShouldSpeculateMachineInt):
      * dfg/DFGInPlaceAbstractState.cpp:
      (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
      * dfg/DFGJITCode.cpp:
      (JSC::DFG::JITCode::reconstruct):
      * dfg/DFGJITCompiler.h:
      (JSC::DFG::JITCompiler::noticeOSREntry):
      * dfg/DFGMinifiedNode.h:
      (JSC::DFG::belongsInMinifiedGraph):
      (JSC::DFG::MinifiedNode::hasChild):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::shouldSpeculateNumber):
      (JSC::DFG::Node::shouldSpeculateNumberExpectingDefined):
      (JSC::DFG::Node::canSpeculateInt52):
      * dfg/DFGNodeFlags.h:
      (JSC::DFG::nodeCanSpeculateInt52):
      * dfg/DFGNodeType.h:
      (JSC::DFG::permitsOSRBackwardRewiring):
      (JSC::DFG::forwardRewiringSelectionScore):
      * dfg/DFGOSREntry.cpp:
      (JSC::DFG::prepareOSREntry):
      * dfg/DFGOSREntry.h:
      * dfg/DFGOSRExitCompiler.cpp:
      * dfg/DFGOSRExitCompiler64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPrediction):
      (JSC::DFG::PredictionPropagationPhase::propagate):
      (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::SafeToExecuteEdge::operator()):
      (JSC::DFG::safeToExecute):
      * dfg/DFGSilentRegisterSavePlan.h:
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
      (JSC::DFG::SpeculativeJIT::silentFill):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
      (JSC::DFG::SpeculativeJIT::compileInlineStart):
      (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
      (JSC::DFG::SpeculativeJIT::compileValueToInt32):
      (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
      (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
      (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
      (JSC::DFG::SpeculativeJIT::compileAdd):
      (JSC::DFG::SpeculativeJIT::compileArithSub):
      (JSC::DFG::SpeculativeJIT::compileArithNegate):
      (JSC::DFG::SpeculativeJIT::compileArithMul):
      (JSC::DFG::SpeculativeJIT::compare):
      (JSC::DFG::SpeculativeJIT::compileStrictEq):
      (JSC::DFG::SpeculativeJIT::speculateMachineInt):
      (JSC::DFG::SpeculativeJIT::speculateNumber):
      (JSC::DFG::SpeculativeJIT::speculateRealNumber):
      (JSC::DFG::SpeculativeJIT::speculate):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::canReuse):
      (JSC::DFG::SpeculativeJIT::isFilled):
      (JSC::DFG::SpeculativeJIT::isFilledDouble):
      (JSC::DFG::SpeculativeJIT::use):
      (JSC::DFG::SpeculativeJIT::isKnownInteger):
      (JSC::DFG::SpeculativeJIT::isKnownCell):
      (JSC::DFG::SpeculativeJIT::isKnownNotNumber):
      (JSC::DFG::SpeculativeJIT::int52Result):
      (JSC::DFG::SpeculativeJIT::strictInt52Result):
      (JSC::DFG::SpeculativeJIT::initConstantInfo):
      (JSC::DFG::SpeculativeJIT::isInteger):
      (JSC::DFG::SpeculativeJIT::betterUseStrictInt52):
      (JSC::DFG::SpeculativeJIT::generationInfo):
      (JSC::DFG::SpeculateInt52Operand::SpeculateInt52Operand):
      (JSC::DFG::SpeculateInt52Operand::~SpeculateInt52Operand):
      (JSC::DFG::SpeculateInt52Operand::edge):
      (JSC::DFG::SpeculateInt52Operand::node):
      (JSC::DFG::SpeculateInt52Operand::gpr):
      (JSC::DFG::SpeculateInt52Operand::use):
      (JSC::DFG::SpeculateStrictInt52Operand::SpeculateStrictInt52Operand):
      (JSC::DFG::SpeculateStrictInt52Operand::~SpeculateStrictInt52Operand):
      (JSC::DFG::SpeculateStrictInt52Operand::edge):
      (JSC::DFG::SpeculateStrictInt52Operand::node):
      (JSC::DFG::SpeculateStrictInt52Operand::gpr):
      (JSC::DFG::SpeculateStrictInt52Operand::use):
      (JSC::DFG::SpeculateWhicheverInt52Operand::SpeculateWhicheverInt52Operand):
      (JSC::DFG::SpeculateWhicheverInt52Operand::~SpeculateWhicheverInt52Operand):
      (JSC::DFG::SpeculateWhicheverInt52Operand::edge):
      (JSC::DFG::SpeculateWhicheverInt52Operand::node):
      (JSC::DFG::SpeculateWhicheverInt52Operand::gpr):
      (JSC::DFG::SpeculateWhicheverInt52Operand::use):
      (JSC::DFG::SpeculateWhicheverInt52Operand::format):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::boxInt52):
      (JSC::DFG::SpeculativeJIT::fillJSValue):
      (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
      (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
      (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
      (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
      (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
      (JSC::DFG::SpeculativeJIT::compileInt52Compare):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleInt52Branch):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGUseKind.cpp:
      (WTF::printInternal):
      * dfg/DFGUseKind.h:
      (JSC::DFG::typeFilterFor):
      (JSC::DFG::isNumerical):
      * dfg/DFGValueSource.cpp:
      (JSC::DFG::ValueSource::dump):
      * dfg/DFGValueSource.h:
      (JSC::DFG::dataFormatToValueSourceKind):
      (JSC::DFG::valueSourceKindToDataFormat):
      (JSC::DFG::ValueSource::forFlushFormat):
      (JSC::DFG::ValueSource::valueRecovery):
      * dfg/DFGVariableAccessData.h:
      (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote):
      (JSC::DFG::VariableAccessData::flushFormat):
      * ftl/FTLCArgumentGetter.cpp:
      (JSC::FTL::CArgumentGetter::loadNextAndBox):
      * ftl/FTLCArgumentGetter.h:
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLExitValue.cpp:
      (JSC::FTL::ExitValue::dumpInContext):
      * ftl/FTLExitValue.h:
      (JSC::FTL::ExitValue::inJSStackAsInt52):
      * ftl/FTLIntrinsicRepository.h:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::createPhiVariables):
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileUpsilon):
      (JSC::FTL::LowerDFGToLLVM::compilePhi):
      (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
      (JSC::FTL::LowerDFGToLLVM::compileAdd):
      (JSC::FTL::LowerDFGToLLVM::compileArithSub):
      (JSC::FTL::LowerDFGToLLVM::compileArithMul):
      (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
      (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
      (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
      (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareGreater):
      (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq):
      (JSC::FTL::LowerDFGToLLVM::lowInt32):
      (JSC::FTL::LowerDFGToLLVM::lowInt52):
      (JSC::FTL::LowerDFGToLLVM::lowStrictInt52):
      (JSC::FTL::LowerDFGToLLVM::betterUseStrictInt52):
      (JSC::FTL::LowerDFGToLLVM::bestInt52Kind):
      (JSC::FTL::LowerDFGToLLVM::opposite):
      (JSC::FTL::LowerDFGToLLVM::lowWhicheverInt52):
      (JSC::FTL::LowerDFGToLLVM::lowCell):
      (JSC::FTL::LowerDFGToLLVM::lowBoolean):
      (JSC::FTL::LowerDFGToLLVM::lowDouble):
      (JSC::FTL::LowerDFGToLLVM::lowJSValue):
      (JSC::FTL::LowerDFGToLLVM::strictInt52ToInt32):
      (JSC::FTL::LowerDFGToLLVM::strictInt52ToDouble):
      (JSC::FTL::LowerDFGToLLVM::strictInt52ToJSValue):
      (JSC::FTL::LowerDFGToLLVM::setInt52WithStrictValue):
      (JSC::FTL::LowerDFGToLLVM::strictInt52ToInt52):
      (JSC::FTL::LowerDFGToLLVM::int52ToStrictInt52):
      (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
      (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
      (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
      (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
      (JSC::FTL::LowerDFGToLLVM::setInt52):
      (JSC::FTL::LowerDFGToLLVM::setStrictInt52):
      * ftl/FTLOSRExitCompiler.cpp:
      (JSC::FTL::compileStub):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::addWithOverflow64):
      (JSC::FTL::Output::subWithOverflow64):
      (JSC::FTL::Output::mulWithOverflow64):
      * ftl/FTLValueFormat.cpp:
      (WTF::printInternal):
      * ftl/FTLValueFormat.h:
      * ftl/FTLValueSource.cpp:
      (JSC::FTL::ValueSource::dump):
      * ftl/FTLValueSource.h:
      * interpreter/Register.h:
      (JSC::Register::unboxedInt52):
      * runtime/Arguments.cpp:
      (JSC::Arguments::tearOffForInlineCallFrame):
      * runtime/IndexingType.cpp:
      (JSC::leastUpperBoundOfIndexingTypeAndType):
      * runtime/JSCJSValue.h:
      * runtime/JSCJSValueInlines.h:
      (JSC::JSValue::isMachineInt):
      (JSC::JSValue::asMachineInt):
      
      Source/WTF: 
      
      Reviewed by Oliver Hunt.
      
      * wtf/PrintStream.h:
      (WTF::ValueIgnoringContext::ValueIgnoringContext):
      (WTF::ValueIgnoringContext::dump):
      (WTF::ignoringContext):
      
      Tools: 
      
      Reviewed by Oliver Hunt.
      
      * Scripts/run-jsc-stress-tests:
      
      LayoutTests: 
      
      Reviewed by Oliver Hunt.
      
      * js/dfg-int-overflow-large-constants-in-a-line-expected.txt:
      * js/regress/large-int-captured-expected.txt: Added.
      * js/regress/large-int-captured.html: Added.
      * js/regress/large-int-expected.txt: Added.
      * js/regress/large-int-neg-expected.txt: Added.
      * js/regress/large-int-neg.html: Added.
      * js/regress/large-int.html: Added.
      * js/regress/marsaglia-larger-ints-expected.txt: Added.
      * js/regress/marsaglia-larger-ints.html: Added.
      * js/regress/script-tests/large-int-captured.js: Added.
      (.bar):
      (foo):
      * js/regress/script-tests/large-int-neg.js: Added.
      (foo):
      * js/regress/script-tests/large-int.js: Added.
      (foo):
      * js/regress/script-tests/marsaglia-larger-ints.js: Added.
      (uint):
      (marsaglia):
      * js/script-tests/dfg-int-overflow-large-constants-in-a-line.js:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@156047 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6921b29b
    • commit-queue@webkit.org's avatar
      Unreviewed, rolling out r156019 and r156020. · 92c67000
      commit-queue@webkit.org authored
      http://trac.webkit.org/changeset/156019
      http://trac.webkit.org/changeset/156020
      https://bugs.webkit.org/show_bug.cgi?id=121540
      
      Broke tests (Requested by ap on #webkit).
      
      Source/JavaScriptCore:
      
      * assembler/MacroAssemblerX86_64.h:
      * assembler/X86Assembler.h:
      * bytecode/DataFormat.h:
      (JSC::dataFormatToString):
      * bytecode/ExitKind.cpp:
      (JSC::exitKindToString):
      * bytecode/ExitKind.h:
      * bytecode/OperandsInlines.h:
      (JSC::::dumpInContext):
      * bytecode/SpeculatedType.cpp:
      (JSC::dumpSpeculation):
      (JSC::speculationToAbbreviatedString):
      (JSC::speculationFromValue):
      * bytecode/SpeculatedType.h:
      (JSC::isInt32SpeculationForArithmetic):
      (JSC::isInt48Speculation):
      (JSC::isMachineIntSpeculationForArithmetic):
      (JSC::isInt48AsDoubleSpeculation):
      (JSC::isRealNumberSpeculation):
      (JSC::isNumberSpeculation):
      (JSC::isNumberSpeculationExpectingDefined):
      * bytecode/ValueRecovery.h:
      (JSC::ValueRecovery::inGPR):
      (JSC::ValueRecovery::displacedInJSStack):
      (JSC::ValueRecovery::isAlreadyInJSStack):
      (JSC::ValueRecovery::gpr):
      (JSC::ValueRecovery::virtualRegister):
      (JSC::ValueRecovery::dumpInContext):
      * dfg/DFGAbstractInterpreter.h:
      (JSC::DFG::AbstractInterpreter::needsTypeCheck):
      (JSC::DFG::AbstractInterpreter::filterByType):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGAbstractValue.cpp:
      (JSC::DFG::AbstractValue::set):
      (JSC::DFG::AbstractValue::checkConsistency):
      * dfg/DFGAbstractValue.h:
      (JSC::DFG::AbstractValue::validateType):
      * dfg/DFGArrayMode.cpp:
      (JSC::DFG::ArrayMode::refine):
      * dfg/DFGAssemblyHelpers.h:
      (JSC::DFG::AssemblyHelpers::unboxDouble):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::makeSafe):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::canonicalize):
      (JSC::DFG::CSEPhase::pureCSE):
      (JSC::DFG::CSEPhase::getByValLoadElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGCommon.h:
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::run):
      (JSC::DFG::FixupPhase::fixupNode):
      (JSC::DFG::FixupPhase::fixupSetLocalsInBlock):
      (JSC::DFG::FixupPhase::observeUseKindOnNode):
      (JSC::DFG::FixupPhase::fixEdge):
      (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
      (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
      * dfg/DFGFlushFormat.cpp:
      (WTF::printInternal):
      * dfg/DFGFlushFormat.h:
      (JSC::DFG::resultFor):
      (JSC::DFG::useKindFor):
      * dfg/DFGGenerationInfo.h:
      (JSC::DFG::GenerationInfo::initInt32):
      (JSC::DFG::GenerationInfo::fillInt32):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::addShouldSpeculateMachineInt):
      (JSC::DFG::Graph::mulShouldSpeculateMachineInt):
      (JSC::DFG::Graph::negateShouldSpeculateMachineInt):
      * dfg/DFGInPlaceAbstractState.cpp:
      (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
      * dfg/DFGJITCode.cpp:
      (JSC::DFG::JITCode::reconstruct):
      * dfg/DFGMinifiedNode.h:
      (JSC::DFG::belongsInMinifiedGraph):
      (JSC::DFG::MinifiedNode::hasChild):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::shouldSpeculateNumber):
      (JSC::DFG::Node::shouldSpeculateNumberExpectingDefined):
      (JSC::DFG::Node::canSpeculateInt48):
      * dfg/DFGNodeFlags.h:
      (JSC::DFG::nodeCanSpeculateInt48):
      * dfg/DFGNodeType.h:
      (JSC::DFG::forwardRewiringSelectionScore):
      * dfg/DFGOSRExitCompiler.cpp:
      (JSC::DFG::shortOperandsDump):
      * dfg/DFGOSRExitCompiler64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPrediction):
      (JSC::DFG::PredictionPropagationPhase::propagate):
      (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::SafeToExecuteEdge::operator()):
      (JSC::DFG::safeToExecute):
      * dfg/DFGSilentRegisterSavePlan.h:
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
      (JSC::DFG::SpeculativeJIT::silentFill):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
      (JSC::DFG::SpeculativeJIT::compileInlineStart):
      (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
      (JSC::DFG::SpeculativeJIT::compileValueToInt32):
      (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
      (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
      (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
      (JSC::DFG::SpeculativeJIT::compileAdd):
      (JSC::DFG::SpeculativeJIT::compileArithSub):
      (JSC::DFG::SpeculativeJIT::compileArithNegate):
      (JSC::DFG::SpeculativeJIT::compileArithMul):
      (JSC::DFG::SpeculativeJIT::compare):
      (JSC::DFG::SpeculativeJIT::compileStrictEq):
      (JSC::DFG::SpeculativeJIT::speculateNumber):
      (JSC::DFG::SpeculativeJIT::speculateRealNumber):
      (JSC::DFG::SpeculativeJIT::speculate):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::canReuse):
      (JSC::DFG::SpeculativeJIT::isFilled):
      (JSC::DFG::SpeculativeJIT::isFilledDouble):
      (JSC::DFG::SpeculativeJIT::use):
      (JSC::DFG::SpeculativeJIT::boxDouble):
      (JSC::DFG::SpeculativeJIT::isKnownInteger):
      (JSC::DFG::SpeculativeJIT::isKnownCell):
      (JSC::DFG::SpeculativeJIT::isKnownNotNumber):
      (JSC::DFG::SpeculativeJIT::int32Result):
      (JSC::DFG::SpeculativeJIT::initConstantInfo):
      (JSC::DFG::SpeculativeJIT::isInteger):
      (JSC::DFG::SpeculativeJIT::generationInfoFromVirtualRegister):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::fillJSValue):
      (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
      (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
      (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
      (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGUseKind.cpp:
      (WTF::printInternal):
      * dfg/DFGUseKind.h:
      (JSC::DFG::typeFilterFor):
      (JSC::DFG::isNumerical):
      * dfg/DFGValueSource.cpp:
      (JSC::DFG::ValueSource::dump):
      * dfg/DFGValueSource.h:
      (JSC::DFG::dataFormatToValueSourceKind):
      (JSC::DFG::valueSourceKindToDataFormat):
      (JSC::DFG::ValueSource::forFlushFormat):
      (JSC::DFG::ValueSource::valueRecovery):
      * dfg/DFGVariableAccessData.h:
      (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote):
      (JSC::DFG::VariableAccessData::flushFormat):
      * ftl/FTLCArgumentGetter.cpp:
      (JSC::FTL::CArgumentGetter::loadNextAndBox):
      * ftl/FTLCArgumentGetter.h:
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLExitValue.cpp:
      (JSC::FTL::ExitValue::dumpInContext):
      * ftl/FTLExitValue.h:
      * ftl/FTLIntrinsicRepository.h:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::createPhiVariables):
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileUpsilon):
      (JSC::FTL::LowerDFGToLLVM::compilePhi):
      (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
      (JSC::FTL::LowerDFGToLLVM::compileAdd):
      (JSC::FTL::LowerDFGToLLVM::compileArithSub):
      (JSC::FTL::LowerDFGToLLVM::compileArithMul):
      (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
      (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
      (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
      (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareGreater):
      (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq):
      (JSC::FTL::LowerDFGToLLVM::lowInt32):
      (JSC::FTL::LowerDFGToLLVM::lowCell):
      (JSC::FTL::LowerDFGToLLVM::lowBoolean):
      (JSC::FTL::LowerDFGToLLVM::lowDouble):
      (JSC::FTL::LowerDFGToLLVM::lowJSValue):
      (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
      (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
      (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
      (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
      (JSC::FTL::LowerDFGToLLVM::setInt32):
      * ftl/FTLOSRExitCompiler.cpp:
      (JSC::FTL::compileStub):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::mulWithOverflow32):
      * ftl/FTLValueFormat.cpp:
      (WTF::printInternal):
      * ftl/FTLValueFormat.h:
      * ftl/FTLValueSource.cpp:
      (JSC::FTL::ValueSource::dump):
      * ftl/FTLValueSource.h:
      * interpreter/Register.h:
      * runtime/Arguments.cpp:
      (JSC::Arguments::tearOffForInlineCallFrame):
      * runtime/IndexingType.cpp:
      (JSC::leastUpperBoundOfIndexingTypeAndType):
      * runtime/JSCJSValue.h:
      * runtime/JSCJSValueInlines.h:
      
      Source/WTF:
      
      * wtf/PrintStream.h:
      
      Tools:
      
      * Scripts/run-jsc-stress-tests:
      
      LayoutTests:
      
      * js/regress/large-int-captured-expected.txt: Removed.
      * js/regress/large-int-captured.html: Removed.
      * js/regress/large-int-expected.txt: Removed.
      * js/regress/large-int-neg-expected.txt: Removed.
      * js/regress/large-int-neg.html: Removed.
      * js/regress/large-int.html: Removed.
      * js/regress/marsaglia-larger-ints-expected.txt: Removed.
      * js/regress/marsaglia-larger-ints.html: Removed.
      * js/regress/script-tests/large-int-captured.js: Removed.
      * js/regress/script-tests/large-int-neg.js: Removed.
      * js/regress/script-tests/large-int.js: Removed.
      * js/regress/script-tests/marsaglia-larger-ints.js: Removed.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@156029 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      92c67000
    • fpizlo@apple.com's avatar
      DFG should support Int52 for local variables · 4c466ec6
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=121064
      
      Source/JavaScriptCore: 
      
      Reviewed by Oliver Hunt.
              
      This adds Int52 support for local variables to the DFG and FTL. It's a speed-up on
      programs that have local int32 overflows but where a larger int representation can
      prevent us from having to convert all the way up to double.
              
      It's a small speed-up for now. But we're just supporting Int52 for a handful of
      operations (add, sub, mul, neg, compare, bitops, typed array access) and this lays
      the groundwork for adding Int52 to JSValue, which will probably be a bigger
      speed-up.
              
      The basic approach is:
              
      - We have a notion of Int52 in our typesystem. Int52 doesn't belong to BytecodeTop
        or HeapTop - i.e. it doesn't arise from JSValues.
              
      - DFG treats Int52 as being part of its FullTop and will treat it as being a
        subtype of double unless instructed otherwise.
              
      - Prediction propagator creates Int52s whenever we have a node going doubly but due
        to large values rather than fractional values, and that node is known to be able
        to produce Int52 natively in the DFG backend.
              
      - Fixup phase converts edges to MachineIntUses in nodes that are known to be able
        to deal with Int52, and where we have a subtype of Int32|Int52 as the predicted
        input.
              
      - The DFG backend and FTL LLVM IR lowering have two notions of Int52s - ones that
        are left-shifted by 16 (great for overflow checks) and ones that are
        sign-extended. Both backends know how to convert between Int52s and the other
        representations.
      
      * assembler/MacroAssemblerX86_64.h:
      (JSC::MacroAssemblerX86_64::rshift64):
      (JSC::MacroAssemblerX86_64::mul64):
      (JSC::MacroAssemblerX86_64::branchMul64):
      (JSC::MacroAssemblerX86_64::branchNeg64):
      (JSC::MacroAssemblerX86_64::convertInt64ToDouble):
      * assembler/X86Assembler.h:
      (JSC::X86Assembler::imulq_rr):
      (JSC::X86Assembler::cvtsi2sdq_rr):
      * bytecode/DataFormat.h:
      (JSC::dataFormatToString):
      * bytecode/OperandsInlines.h:
      (JSC::::dumpInContext):
      * bytecode/SpeculatedType.cpp:
      (JSC::dumpSpeculation):
      (JSC::speculationToAbbreviatedString):
      (JSC::speculationFromValue):
      * bytecode/SpeculatedType.h:
      (JSC::isInt32SpeculationForArithmetic):
      (JSC::isMachineIntSpeculationForArithmetic):
      (JSC::isBytecodeRealNumberSpeculation):
      (JSC::isFullRealNumberSpeculation):
      (JSC::isBytecodeNumberSpeculation):
      (JSC::isFullNumberSpeculation):
      (JSC::isBytecodeNumberSpeculationExpectingDefined):
      (JSC::isFullNumberSpeculationExpectingDefined):
      * bytecode/ValueRecovery.h:
      (JSC::ValueRecovery::alreadyInJSStackAsUnboxedInt52):
      (JSC::ValueRecovery::inGPR):
      (JSC::ValueRecovery::displacedInJSStack):
      (JSC::ValueRecovery::isAlreadyInJSStack):
      (JSC::ValueRecovery::gpr):
      (JSC::ValueRecovery::virtualRegister):
      (JSC::ValueRecovery::dumpInContext):
      * dfg/DFGAbstractInterpreter.h:
      (JSC::DFG::AbstractInterpreter::needsTypeCheck):
      (JSC::DFG::AbstractInterpreter::filterByType):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGAbstractValue.cpp:
      (JSC::DFG::AbstractValue::set):
      (JSC::DFG::AbstractValue::checkConsistency):
      * dfg/DFGAbstractValue.h:
      (JSC::DFG::AbstractValue::couldBeType):
      (JSC::DFG::AbstractValue::isType):
      (JSC::DFG::AbstractValue::checkConsistency):
      (JSC::DFG::AbstractValue::validateType):
      * dfg/DFGArrayMode.cpp:
      (JSC::DFG::ArrayMode::refine):
      * dfg/DFGAssemblyHelpers.h:
      (JSC::DFG::AssemblyHelpers::boxInt52):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::pureCSE):
      (JSC::DFG::CSEPhase::getByValLoadElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGCommon.h:
      (JSC::DFG::enableInt52):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::run):
      (JSC::DFG::FixupPhase::fixupNode):
      (JSC::DFG::FixupPhase::fixupSetLocalsInBlock):
      (JSC::DFG::FixupPhase::fixupUntypedSetLocalsInBlock):
      (JSC::DFG::FixupPhase::observeUseKindOnNode):
      (JSC::DFG::FixupPhase::fixEdge):
      (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
      (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
      * dfg/DFGFlushFormat.cpp:
      (WTF::printInternal):
      * dfg/DFGFlushFormat.h:
      (JSC::DFG::resultFor):
      (JSC::DFG::useKindFor):
      * dfg/DFGGenerationInfo.h:
      (JSC::DFG::GenerationInfo::initInt52):
      (JSC::DFG::GenerationInfo::initStrictInt52):
      (JSC::DFG::GenerationInfo::isFormat):
      (JSC::DFG::GenerationInfo::isInt52):
      (JSC::DFG::GenerationInfo::isStrictInt52):
      (JSC::DFG::GenerationInfo::fillInt52):
      (JSC::DFG::GenerationInfo::fillStrictInt52):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::addShouldSpeculateMachineInt):
      (JSC::DFG::Graph::mulShouldSpeculateMachineInt):
      (JSC::DFG::Graph::negateShouldSpeculateMachineInt):
      * dfg/DFGInPlaceAbstractState.cpp:
      (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
      * dfg/DFGJITCode.cpp:
      (JSC::DFG::JITCode::reconstruct):
      * dfg/DFGMinifiedNode.h:
      (JSC::DFG::belongsInMinifiedGraph):
      (JSC::DFG::MinifiedNode::hasChild):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::shouldSpeculateNumber):
      (JSC::DFG::Node::shouldSpeculateNumberExpectingDefined):
      * dfg/DFGNodeFlags.h:
      * dfg/DFGNodeType.h:
      (JSC::DFG::forwardRewiringSelectionScore):
      * dfg/DFGOSRExitCompiler.cpp:
      * dfg/DFGOSRExitCompiler64.cpp:
      (JSC::DFG::OSRExitCompiler::compileExit):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPrediction):
      (JSC::DFG::PredictionPropagationPhase::propagate):
      (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::SafeToExecuteEdge::operator()):
      (JSC::DFG::safeToExecute):
      * dfg/DFGSilentRegisterSavePlan.h:
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
      (JSC::DFG::SpeculativeJIT::silentFill):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
      (JSC::DFG::SpeculativeJIT::compileInlineStart):
      (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
      (JSC::DFG::SpeculativeJIT::compileValueToInt32):
      (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
      (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
      (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
      (JSC::DFG::SpeculativeJIT::compileAdd):
      (JSC::DFG::SpeculativeJIT::compileArithSub):
      (JSC::DFG::SpeculativeJIT::compileArithNegate):
      (JSC::DFG::SpeculativeJIT::compileArithMul):
      (JSC::DFG::SpeculativeJIT::compare):
      (JSC::DFG::SpeculativeJIT::compileStrictEq):
      (JSC::DFG::SpeculativeJIT::speculateMachineInt):
      (JSC::DFG::SpeculativeJIT::speculateNumber):
      (JSC::DFG::SpeculativeJIT::speculateRealNumber):
      (JSC::DFG::SpeculativeJIT::speculate):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::canReuse):
      (JSC::DFG::SpeculativeJIT::isFilled):
      (JSC::DFG::SpeculativeJIT::isFilledDouble):
      (JSC::DFG::SpeculativeJIT::use):
      (JSC::DFG::SpeculativeJIT::isKnownInteger):
      (JSC::DFG::SpeculativeJIT::isKnownCell):
      (JSC::DFG::SpeculativeJIT::isKnownNotNumber):
      (JSC::DFG::SpeculativeJIT::int52Result):
      (JSC::DFG::SpeculativeJIT::strictInt52Result):
      (JSC::DFG::SpeculativeJIT::initConstantInfo):
      (JSC::DFG::SpeculativeJIT::isInteger):
      (JSC::DFG::SpeculativeJIT::betterUseStrictInt52):
      (JSC::DFG::SpeculativeJIT::generationInfo):
      (JSC::DFG::SpeculateInt52Operand::SpeculateInt52Operand):
      (JSC::DFG::SpeculateInt52Operand::~SpeculateInt52Operand):
      (JSC::DFG::SpeculateInt52Operand::edge):
      (JSC::DFG::SpeculateInt52Operand::node):
      (JSC::DFG::SpeculateInt52Operand::gpr):
      (JSC::DFG::SpeculateInt52Operand::use):
      (JSC::DFG::SpeculateStrictInt52Operand::SpeculateStrictInt52Operand):
      (JSC::DFG::SpeculateStrictInt52Operand::~SpeculateStrictInt52Operand):
      (JSC::DFG::SpeculateStrictInt52Operand::edge):
      (JSC::DFG::SpeculateStrictInt52Operand::node):
      (JSC::DFG::SpeculateStrictInt52Operand::gpr):
      (JSC::DFG::SpeculateStrictInt52Operand::use):
      (JSC::DFG::SpeculateWhicheverInt52Operand::SpeculateWhicheverInt52Operand):
      (JSC::DFG::SpeculateWhicheverInt52Operand::~SpeculateWhicheverInt52Operand):
      (JSC::DFG::SpeculateWhicheverInt52Operand::edge):
      (JSC::DFG::SpeculateWhicheverInt52Operand::node):
      (JSC::DFG::SpeculateWhicheverInt52Operand::gpr):
      (JSC::DFG::SpeculateWhicheverInt52Operand::use):
      (JSC::DFG::SpeculateWhicheverInt52Operand::format):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::boxInt52):
      (JSC::DFG::SpeculativeJIT::fillJSValue):
      (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
      (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
      (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
      (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
      (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
      (JSC::DFG::SpeculativeJIT::compileInt52Compare):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleInt52Branch):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGUseKind.cpp:
      (WTF::printInternal):
      * dfg/DFGUseKind.h:
      (JSC::DFG::typeFilterFor):
      (JSC::DFG::isNumerical):
      * dfg/DFGValueSource.cpp:
      (JSC::DFG::ValueSource::dump):
      * dfg/DFGValueSource.h:
      (JSC::DFG::dataFormatToValueSourceKind):
      (JSC::DFG::valueSourceKindToDataFormat):
      (JSC::DFG::ValueSource::forFlushFormat):
      (JSC::DFG::ValueSource::valueRecovery):
      * dfg/DFGVariableAccessData.h:
      (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote):
      (JSC::DFG::VariableAccessData::flushFormat):
      * ftl/FTLCArgumentGetter.cpp:
      (JSC::FTL::CArgumentGetter::loadNextAndBox):
      * ftl/FTLCArgumentGetter.h:
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLExitValue.cpp:
      (JSC::FTL::ExitValue::dumpInContext):
      * ftl/FTLExitValue.h:
      (JSC::FTL::ExitValue::inJSStackAsInt52):
      * ftl/FTLIntrinsicRepository.h:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::createPhiVariables):
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileUpsilon):
      (JSC::FTL::LowerDFGToLLVM::compilePhi):
      (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
      (JSC::FTL::LowerDFGToLLVM::compileAdd):
      (JSC::FTL::LowerDFGToLLVM::compileArithSub):
      (JSC::FTL::LowerDFGToLLVM::compileArithMul):
      (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
      (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
      (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
      (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareGreater):
      (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq):
      (JSC::FTL::LowerDFGToLLVM::lowInt32):
      (JSC::FTL::LowerDFGToLLVM::lowInt52):
      (JSC::FTL::LowerDFGToLLVM::lowStrictInt52):
      (JSC::FTL::LowerDFGToLLVM::betterUseStrictInt52):
      (JSC::FTL::LowerDFGToLLVM::bestInt52Kind):
      (JSC::FTL::LowerDFGToLLVM::opposite):
      (JSC::FTL::LowerDFGToLLVM::Int52s::operator[]):
      (JSC::FTL::LowerDFGToLLVM::lowWhicheverInt52):
      (JSC::FTL::LowerDFGToLLVM::lowWhicheverInt52s):
      (JSC::FTL::LowerDFGToLLVM::lowOpposingInt52s):
      (JSC::FTL::LowerDFGToLLVM::lowCell):
      (JSC::FTL::LowerDFGToLLVM::lowBoolean):
      (JSC::FTL::LowerDFGToLLVM::lowDouble):
      (JSC::FTL::LowerDFGToLLVM::lowJSValue):
      (JSC::FTL::LowerDFGToLLVM::strictInt52ToInt32):
      (JSC::FTL::LowerDFGToLLVM::strictInt52ToDouble):
      (JSC::FTL::LowerDFGToLLVM::strictInt52ToJSValue):
      (JSC::FTL::LowerDFGToLLVM::setInt52WithStrictValue):
      (JSC::FTL::LowerDFGToLLVM::strictInt52ToInt52):
      (JSC::FTL::LowerDFGToLLVM::int52ToStrictInt52):
      (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
      (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
      (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
      (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
      (JSC::FTL::LowerDFGToLLVM::setInt52):
      (JSC::FTL::LowerDFGToLLVM::setStrictInt52):
      * ftl/FTLOSRExitCompiler.cpp:
      (JSC::FTL::compileStub):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::addWithOverflow64):
      (JSC::FTL::Output::subWithOverflow64):
      (JSC::FTL::Output::mulWithOverflow64):
      * ftl/FTLValueFormat.cpp:
      (WTF::printInternal):
      * ftl/FTLValueFormat.h:
      * ftl/FTLValueSource.cpp:
      (JSC::FTL::ValueSource::dump):
      * ftl/FTLValueSource.h:
      * interpreter/Register.h:
      (JSC::Register::unboxedInt52):
      * runtime/Arguments.cpp:
      (JSC::Arguments::tearOffForInlineCallFrame):
      * runtime/IndexingType.cpp:
      (JSC::leastUpperBoundOfIndexingTypeAndType):
      * runtime/JSCJSValue.h:
      * runtime/JSCJSValueInlines.h:
      (JSC::JSValue::isMachineInt):
      (JSC::JSValue::asMachineInt):
      
      Source/WTF: 
      
      Reviewed by Oliver Hunt.
      
      * wtf/PrintStream.h:
      (WTF::ValueIgnoringContext::ValueIgnoringContext):
      (WTF::ValueIgnoringContext::dump):
      (WTF::ignoringContext):
      
      Tools: 
      
      Reviewed by Oliver Hunt.
      
      * Scripts/run-jsc-stress-tests:
      
      LayoutTests: 
      
      Reviewed by Oliver Hunt.
      
      * js/regress/large-int-captured-expected.txt: Added.
      * js/regress/large-int-captured.html: Added.
      * js/regress/large-int-expected.txt: Added.
      * js/regress/large-int-neg-expected.txt: Added.
      * js/regress/large-int-neg.html: Added.
      * js/regress/large-int.html: Added.
      * js/regress/marsaglia-larger-ints-expected.txt: Added.
      * js/regress/marsaglia-larger-ints.html: Added.
      * js/regress/script-tests/large-int-captured.js: Added.
      (.bar):
      (foo):
      * js/regress/script-tests/large-int-neg.js: Added.
      (foo):
      * js/regress/script-tests/large-int.js: Added.
      (foo):
      * js/regress/script-tests/marsaglia-larger-ints.js: Added.
      (uint):
      (marsaglia):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@156019 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4c466ec6
  19. 15 Sep, 2013 1 commit
    • fpizlo@apple.com's avatar
      It should be easy to add new nodes that do OSR forward rewiring in both DFG and FTL · fdd18f14
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=121371
      
      Reviewed by Sam Weinig.
              
      Forward rewiring is a tricky part of OSR that handles the following:
              
          a: Something(...)
             SetLocal(@a, locX)
          b: Int32ToDouble(@a)
          c: SomethingThatExits(@b)
             <no further uses of @a or @b>
      
      Note that at @c, OSR will think that locX->@a, but @a will be dead. So it must be
      smart enough to find @b, which contains an equivalent value. It must do this for
      any identity functions we support. Currently we support four such functions.
              
      Currently the code for doing this is basically duplicated between the DFG and the
      FTL. Also both versions of the code have some really weirdly written logic for
      picking the "best" identity function to use.
              
      We should fix this by simply having a way to ask "is this node an identity
      function, and if so, then how good is it?"  Then both the DFG and FTL could use
      this and have no hard-wired knowledge of those identity functions.
              
      While we're at it, this also changes some terminology because I found the use of
      the word "needs" confusing. Note that this retains the somewhat confusing behavior
      that we don't search all possible forward/backward uses. We only search one step
      in each direction. This is because we only need to handle cases that FixupPhase
      and the parser insert. All other code that tries to insert intermediate conversion
      nodes should ensure to Phantom the original node. For example, the following
      transformation is illegal:
              
      Before:
          x: SomethingThatExits(@a)
              
      After:
          w: Conversion(@a)
          x: SomethingThatExits(@w)
              
      The correct form of that transformation is one of these:
              
      Correct #1:
              
          v: DoAllChecks(@a) // exit here
          w: Conversion(@a)
          x: Something(@w) // no exit
              
      Correct #2:
              
          w: Conversion(@a)
          x: SomethingThatExits(@w)
          y: Phantom(@a)
              
      Correct #3:
              
          w: Conversion(@a)
          x: SomethingThatExits(@w, @a)
              
      Note that we use #3 for some heap accesses, but of course it requires that the
      node you're using has an extra slot for a "dummy" use child.
              
      Broadly speaking though, such transformations should be relegated to something
      below DFG IR, like LLVM IR.
      
      * dfg/DFGNodeType.h:
      (JSC::DFG::forwardRewiringSelectionScore):
      (JSC::DFG::needsOSRForwardRewiring):
      * dfg/DFGVariableEventStream.cpp:
      (JSC::DFG::VariableEventStream::reconstruct):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155793 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      fdd18f14
  20. 04 Sep, 2013 1 commit
    • fpizlo@apple.com's avatar
      The DFG should be able to tier-up and OSR enter into the FTL · 532f1e51
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112838
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Hahnenberg.
              
      This adds the ability for the DFG to tier-up into the FTL. This works in both
      of the expected tier-up modes:
              
      Replacement: frequently called functions eventually have their entrypoint
      replaced with one that goes into FTL-compiled code. Note, this will be a
      slow-down for now since we don't yet have LLVM calling convention integration.
              
      OSR entry: code stuck in hot loops gets OSR'd into the FTL from the DFG.
              
      This means that if the DFG detects that a function is an FTL candidate, it
      inserts execution counting code similar to the kind that the baseline JIT
      would use. If you trip on a loop count in a loop header that is an OSR
      candidate (it's not an inlined loop), we do OSR; otherwise we do replacement.
      OSR almost always also implies future replacement.
              
      OSR entry into the FTL is really cool. It uses a specialized FTL compile of
      the code, where early in the DFG pipeline we replace the original root block
      with an OSR entrypoint block that jumps to the pre-header of the hot loop.
      The OSR entrypoint loads all live state at the loop pre-header using loads
      from a scratch buffer, which gets populated by the runtime's OSR entry
      preparation code (FTL::prepareOSREntry()). This approach appears to work well
      with all of our subsequent optimizations, including prediction propagation,
      CFA, and LICM. LLVM seems happy with it, too. Best of all, it works naturally
      with concurrent compilation: when we hit the tier-up trigger we spawn a
      compilation plan at the bytecode index from which we triggered; once the
      compilation finishes the next trigger will try to enter, at that bytecode
      index. If it can't - for example because the code has moved on to another
      loop - then we just try again. Loops that get hot enough for OSR entry (about
      25,000 iterations) will probably still be running when a concurrent compile
      finishes, so this doesn't appear to be a big problem.
              
      This immediately gives us a 70% speed-up on imaging-gaussian-blur. We could
      get a bigger speed-up by adding some more intelligence and tweaking LLVM to
      compile code faster. Those things will happen eventually but this is a good
      start. Probably this code will see more tuning as we get more coverage in the
      FTL JIT, but I'll worry about that in future patches.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * Target.pri:
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
      (JSC::CodeBlock::hasOptimizedReplacement):
      (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
      * bytecode/CodeBlock.h:
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      (JSC::DFG::ByteCodeParser::parse):
      * dfg/DFGCFGSimplificationPhase.cpp:
      (JSC::DFG::CFGSimplificationPhase::run):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGDriver.cpp:
      (JSC::DFG::compileImpl):
      (JSC::DFG::compile):
      * dfg/DFGDriver.h:
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      (JSC::DFG::Graph::killBlockAndItsContents):
      (JSC::DFG::Graph::killUnreachableBlocks):
      * dfg/DFGGraph.h:
      * dfg/DFGInPlaceAbstractState.cpp:
      (JSC::DFG::InPlaceAbstractState::initialize):
      * dfg/DFGJITCode.cpp:
      (JSC::DFG::JITCode::reconstruct):
      (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
      (JSC::DFG::JITCode::optimizeNextInvocation):
      (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
      (JSC::DFG::JITCode::optimizeAfterWarmUp):
      (JSC::DFG::JITCode::optimizeSoon):
      (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
      (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
      * dfg/DFGJITCode.h:
      * dfg/DFGJITFinalizer.cpp:
      (JSC::DFG::JITFinalizer::finalize):
      (JSC::DFG::JITFinalizer::finalizeFunction):
      (JSC::DFG::JITFinalizer::finalizeCommon):
      * dfg/DFGLoopPreHeaderCreationPhase.cpp:
      (JSC::DFG::createPreHeader):
      (JSC::DFG::LoopPreHeaderCreationPhase::run):
      * dfg/DFGLoopPreHeaderCreationPhase.h:
      * dfg/DFGNode.h:
      (JSC::DFG::Node::hasUnlinkedLocal):
      (JSC::DFG::Node::unlinkedLocal):
      * dfg/DFGNodeType.h:
      * dfg/DFGOSREntry.cpp:
      (JSC::DFG::prepareOSREntry):
      * dfg/DFGOSREntrypointCreationPhase.cpp: Added.
      (JSC::DFG::OSREntrypointCreationPhase::OSREntrypointCreationPhase):
      (JSC::DFG::OSREntrypointCreationPhase::run):
      (JSC::DFG::performOSREntrypointCreation):
      * dfg/DFGOSREntrypointCreationPhase.h: Added.
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::Plan):
      (JSC::DFG::Plan::compileInThread):
      (JSC::DFG::Plan::compileInThreadImpl):
      * dfg/DFGPlan.h:
      * dfg/DFGPredictionInjectionPhase.cpp:
      (JSC::DFG::PredictionInjectionPhase::run):
      * 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/DFGTierUpCheckInjectionPhase.cpp: Added.
      (JSC::DFG::TierUpCheckInjectionPhase::TierUpCheckInjectionPhase):
      (JSC::DFG::TierUpCheckInjectionPhase::run):
      (JSC::DFG::performTierUpCheckInjection):
      * dfg/DFGTierUpCheckInjectionPhase.h: Added.
      * dfg/DFGToFTLDeferredCompilationCallback.cpp: Added.
      (JSC::DFG::ToFTLDeferredCompilationCallback::ToFTLDeferredCompilationCallback):
      (JSC::DFG::ToFTLDeferredCompilationCallback::~ToFTLDeferredCompilationCallback):
      (JSC::DFG::ToFTLDeferredCompilationCallback::create):
      (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
      (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
      * dfg/DFGToFTLDeferredCompilationCallback.h: Added.
      * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp: Added.
      (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
      (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::~ToFTLForOSREntryDeferredCompilationCallback):
      (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::create):
      (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
      (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
      * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h: Added.
      * dfg/DFGWorklist.cpp:
      (JSC::DFG::globalWorklist):
      * dfg/DFGWorklist.h:
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLCapabilities.h:
      * ftl/FTLForOSREntryJITCode.cpp: Added.
      (JSC::FTL::ForOSREntryJITCode::ForOSREntryJITCode):
      (JSC::FTL::ForOSREntryJITCode::~ForOSREntryJITCode):
      (JSC::FTL::ForOSREntryJITCode::ftlForOSREntry):
      (JSC::FTL::ForOSREntryJITCode::initializeEntryBuffer):
      * ftl/FTLForOSREntryJITCode.h: Added.
      (JSC::FTL::ForOSREntryJITCode::entryBuffer):
      (JSC::FTL::ForOSREntryJITCode::setBytecodeIndex):
      (JSC::FTL::ForOSREntryJITCode::bytecodeIndex):
      (JSC::FTL::ForOSREntryJITCode::countEntryFailure):
      (JSC::FTL::ForOSREntryJITCode::entryFailureCount):
      * ftl/FTLJITFinalizer.cpp:
      (JSC::FTL::JITFinalizer::finalizeFunction):
      * ftl/FTLLink.cpp:
      (JSC::FTL::link):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileBlock):
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileExtractOSREntryLocal):
      (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
      (JSC::FTL::LowerDFGToLLVM::addWeakReference):
      * ftl/FTLOSREntry.cpp: Added.
      (JSC::FTL::prepareOSREntry):
      * ftl/FTLOSREntry.h: Added.
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::crashNonTerminal):
      (JSC::FTL::Output::crash):
      * ftl/FTLState.cpp:
      (JSC::FTL::State::State):
      * interpreter/Register.h:
      (JSC::Register::unboxedDouble):
      * jit/JIT.cpp:
      (JSC::JIT::emitEnterOptimizationCheck):
      * jit/JITCode.cpp:
      (JSC::JITCode::ftlForOSREntry):
      * jit/JITCode.h:
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      * runtime/Executable.cpp:
      (JSC::ScriptExecutable::newReplacementCodeBlockFor):
      * runtime/Options.h:
      * runtime/VM.cpp:
      (JSC::VM::ensureWorklist):
      * runtime/VM.h:
      
      LayoutTests: 
      
      Reviewed by Mark Hahnenberg.
              
      Fix marsaglia to check the result instead of printing, and add a second
      version that relies on OSR entry.
      
      * fast/js/regress/marsaglia-osr-entry-expected.txt: Added.
      * fast/js/regress/marsaglia-osr-entry.html: Added.
      * fast/js/regress/script-tests/marsaglia-osr-entry.js: Added.
      (marsaglia):
      * fast/js/regress/script-tests/marsaglia.js:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@155023 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      532f1e51
  21. 21 Aug, 2013 1 commit
    • fpizlo@apple.com's avatar
      DFG should inline new typedArray() · 372fa82b
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=120022
      
      Source/JavaScriptCore: 
      
      Reviewed by Oliver Hunt.
              
      Adds inlining of typed array allocations in the DFG. Any operation of the
      form:
              
          new foo(blah)
              
      or:
              
          foo(blah)
              
      where 'foo' is a typed array constructor and 'blah' is exactly one argument,
      is turned into the NewTypedArray intrinsic. Later, of child1 (i.e. 'blah')
      is predicted integer, we generate inline code for an allocation. Otherwise
      it turns into a call to an operation that behaves like the constructor would
      if it was passed one argument (i.e. it may wrap a buffer or it may create a
      copy or another array, or it may allocate an array of that length).
      
      * bytecode/SpeculatedType.cpp:
      (JSC::speculationFromTypedArrayType):
      (JSC::speculationFromClassInfo):
      * bytecode/SpeculatedType.h:
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGBackwardsPropagationPhase.cpp:
      (JSC::DFG::BackwardsPropagationPhase::propagate):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
      (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
      * dfg/DFGCCallHelpers.h:
      (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::putStructureStoreElimination):
      * 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::hasTypedArrayType):
      (JSC::DFG::Node::typedArrayType):
      * dfg/DFGNodeType.h:
      * dfg/DFGOperations.cpp:
      (JSC::DFG::newTypedArrayWithSize):
      (JSC::DFG::newTypedArrayWithOneArgument):
      * dfg/DFGOperations.h:
      (JSC::DFG::operationNewTypedArrayWithSizeForType):
      (JSC::DFG::operationNewTypedArrayWithOneArgumentForType):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * jit/JITOpcodes.cpp:
      (JSC::JIT::emit_op_new_object):
      * jit/JITOpcodes32_64.cpp:
      (JSC::JIT::emit_op_new_object):
      * runtime/JSArray.h:
      (JSC::JSArray::allocationSize):
      * runtime/JSArrayBufferView.h:
      (JSC::JSArrayBufferView::allocationSize):
      * runtime/JSGenericTypedArrayViewConstructorInlines.h:
      (JSC::constructGenericTypedArrayView):
      * runtime/JSObject.h:
      (JSC::JSFinalObject::allocationSize):
      * runtime/TypedArrayType.cpp:
      (JSC::constructorClassInfoForType):
      * runtime/TypedArrayType.h:
      (JSC::indexToTypedArrayType):
      
      LayoutTests: 
      
      Reviewed by Oliver Hunt.
      
      * fast/js/regress/Float64Array-alloc-long-lived-expected.txt: Added.
      * fast/js/regress/Float64Array-alloc-long-lived.html: Added.
      * fast/js/regress/Int16Array-alloc-long-lived-expected.txt: Added.
      * fast/js/regress/Int16Array-alloc-long-lived.html: Added.
      * fast/js/regress/Int8Array-alloc-long-lived-expected.txt: Added.
      * fast/js/regress/Int8Array-alloc-long-lived.html: Added.
      * fast/js/regress/script-tests/Float64Array-alloc-long-lived.js: Added.
      * fast/js/regress/script-tests/Int16Array-alloc-long-lived.js: Added.
      * fast/js/regress/script-tests/Int32Array-alloc-long-lived.js:
      * fast/js/regress/script-tests/Int8Array-alloc-long-lived.js: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154403 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      372fa82b
  22. 19 Aug, 2013 2 commits
    • fpizlo@apple.com's avatar
      DFG should inline typedArray.byteOffset · 537a477d
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=119962
      
      Source/JavaScriptCore: 
      
      Reviewed by Oliver Hunt.
              
      This adds a new node, GetTypedArrayByteOffset, which inlines
      typedArray.byteOffset.
              
      Also, I improved a bunch of the clobbering logic related to typed arrays
      and clobbering in general. For example, PutByOffset/PutStructure are not
      clobber-world so they can be handled by most default cases in CSE. Also,
      It's better to use the 'Class_field' notation for typed arrays now that
      they no longer involve magical descriptor thingies.
      
      * bytecode/SpeculatedType.h:
      * dfg/DFGAbstractHeap.h:
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGArrayMode.h:
      (JSC::DFG::neverNeedsStorage):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::getByValLoadElimination):
      (JSC::DFG::CSEPhase::getByOffsetLoadElimination):
      (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
      (JSC::DFG::CSEPhase::checkArrayElimination):
      (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
      (JSC::DFG::CSEPhase::getTypedArrayByteOffsetLoadElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteLength):
      (JSC::DFG::FixupPhase::convertToGetArrayLength):
      (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
      * dfg/DFGNodeType.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
      * dfg/DFGSpeculativeJIT.h:
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGTypeCheckHoistingPhase.cpp:
      (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
      * runtime/ArrayBuffer.h:
      (JSC::ArrayBuffer::offsetOfData):
      * runtime/Butterfly.h:
      (JSC::Butterfly::offsetOfArrayBuffer):
      * runtime/IndexingHeader.h:
      (JSC::IndexingHeader::offsetOfArrayBuffer):
      
      LayoutTests: 
      
      Reviewed by Oliver Hunt.
      
      * fast/js/dfg-byteOffset-neuter.html: Added.
      * fast/js/dfg-byteOffset-neuter-expected.txt: Added.
      * fast/js/regress/ArrayBuffer-Int32Array-byteOffset-expected.txt: Added.
      * fast/js/regress/ArrayBuffer-Int32Array-byteOffset.html: Added.
      * fast/js/regress/script-tests/ArrayBuffer-Int32Array-byteOffset.js: Added.
      * fast/js/script-tests/dfg-byteOffset-neuter.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154305 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      537a477d
    • oliver@apple.com's avatar
      <https://webkit.org/b/119860> Crash during exception unwinding · 1fc04184
      oliver@apple.com authored
      Reviewed by Filip Pizlo.
      
      Source/JavaScriptCore:
      
      Add an "Unreachable" NodeType, and then rearrange op_throw and op_throw_reference_error
      to plant Throw or ThrowReferenceError followed by a flush and then the Unreachable node.
      
      We need this so that Throw and ThrowReferenceError no longer need to be treated as
      terminals and the subsequent flush keeps the activation (and other registers) live.
      
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::isTerminal):
      * 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):
      
      LayoutTests:
      
      Add a test
      
      * fast/js/dfg-activation-register-overwritten-in-throw-expected.txt: Added.
      * fast/js/dfg-activation-register-overwritten-in-throw.html: Added.
      * fast/js/script-tests/dfg-activation-register-overwritten-in-throw.js: Added.
      (g):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154290 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      1fc04184
  23. 25 Jul, 2013 10 commits
    • oliver@apple.com's avatar
      fourthTier: NodeExitsForward shouldn't be duplicated in NodeType · 500b53ae
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118956
      
      Reviewed by Sam Weinig.
      
      We had two way of expressing that something exits forward: the NodeExitsForward
      flag and the word 'Forward' in the NodeType. That's kind of dumb. This patch
      makes it just be a flag.
      
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGArgumentsSimplificationPhase.cpp:
      (JSC::DFG::ArgumentsSimplificationPhase::run):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::int32ToDoubleCSE):
      (JSC::DFG::CSEPhase::checkStructureElimination):
      (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
      (JSC::DFG::CSEPhase::putStructureStoreElimination):
      (JSC::DFG::CSEPhase::checkArrayElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGConstantFoldingPhase.cpp:
      (JSC::DFG::ConstantFoldingPhase::foldConstants):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
      * dfg/DFGMinifiedNode.h:
      (JSC::DFG::belongsInMinifiedGraph):
      (JSC::DFG::MinifiedNode::hasChild):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::convertToStructureTransitionWatchpoint):
      (JSC::DFG::Node::hasStructureSet):
      (JSC::DFG::Node::hasStructure):
      (JSC::DFG::Node::hasArrayMode):
      (JSC::DFG::Node::willHaveCodeGenOrOSR):
      * dfg/DFGNodeType.h:
      (DFG):
      (JSC::DFG::needsOSRForwardRewiring):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGTypeCheckHoistingPhase.cpp:
      (JSC::DFG::TypeCheckHoistingPhase::run):
      (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
      (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
      * dfg/DFGVariableEventStream.cpp:
      (JSC::DFG::VariableEventStream::reconstruct):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153292 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      500b53ae
    • oliver@apple.com's avatar
      fourthTier: DFG should have an SSA form for use by FTL · 827d2cf7
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118338
      
      Source/JavaScriptCore:
      
      Reviewed by Mark Hahnenberg.
      
      Adds an SSA form to the DFG. We can convert ThreadedCPS form into SSA form
      after breaking critical edges. The conversion algorithm follows Aycock and
      Horspool, and the SSA form itself follows something I've done before, where
      instead of having Phi functions specify input nodes corresponding to block
      predecessors, we instead have Upsilon functions in the predecessors that
      specify which value in that block goes into which subsequent Phi. Upsilons
      don't have to dominate Phis (usually they don't) and they correspond to a
      non-SSA "mov" into the Phi's "variable". This gives all of the good
      properties of SSA, while ensuring that a bunch of CFG transformations don't
      have to be SSA-aware.
      
      So far the only DFG phases that are SSA-aware are DCE and CFA. CFG
      simplification is probably SSA-aware by default, though I haven't tried it.
      Constant folding probably needs a few tweaks, but is likely ready. Ditto
      for CSE, though it's not clear that we'd want to use block-local CSE when
      we could be doing GVN.
      
      Currently only the FTL can generate code from the SSA form, and there is no
      way to convert from SSA to ThreadedCPS or LoadStore. There probably will
      never be such a capability.
      
      In order to handle OSR exit state in the SSA, we place MovHints at Phi
      points. Other than that, you can reconstruct state-at-exit by forward
      propagating MovHints. Note that MovHint is the new SetLocal in SSA.
      SetLocal and GetLocal only survive into SSA if they are on captured
      variables, or in the case of flushes. A "live SetLocal" will be
      NodeMustGenerate and will always correspond to a flush. Computing the
      state-at-exit requires running SSA liveness analysis, OSR availability
      analysis, and flush liveness analysis. The FTL runs all of these prior to
      generating code. While OSR exit continues to be tricky, much of the logic
      is now factored into separate phases and the backend has to do less work
      to reason about what happened outside of the basic block that is being
      lowered.
      
      Conversion from DFG SSA to LLVM SSA is done by ensuring that we generate
      code in depth-first order, thus guaranteeing that a node will always be
      lowered (and hence have a LValue) before any of the blocks dominated by
      that node's block have code generated. For Upsilon/Phi, we just use
      alloca's. We could do something more clever there, but it's probably not
      worth it, at least not now.
      
      Finally, while the SSA form is currently only being converted to LLVM IR,
      there is nothing that prevents us from considering other backends in the
      future - with the caveat that this form is designed to be first lowered to
      a lower-level SSA before actual machine code generation commences. So we
      ought to either use LLVM (the intended path) or we will have to write our
      own SSA low-level backend.
      
      This runs all of the code that the FTL was known to run previously. No
      change in performance for now. But it does open some exciting
      possibilities!
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/Operands.h:
      (JSC::OperandValueTraits::dump):
      (JSC::Operands::fill):
      (Operands):
      (JSC::Operands::clear):
      (JSC::Operands::operator==):
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::beginBasicBlock):
      (JSC::DFG::setLiveValues):
      (DFG):
      (JSC::DFG::AbstractState::initialize):
      (JSC::DFG::AbstractState::endBasicBlock):
      (JSC::DFG::AbstractState::executeEffects):
      (JSC::DFG::AbstractState::mergeStateAtTail):
      (JSC::DFG::AbstractState::merge):
      * dfg/DFGAbstractState.h:
      (AbstractState):
      * dfg/DFGAdjacencyList.h:
      (JSC::DFG::AdjacencyList::justOneChild):
      (AdjacencyList):
      * dfg/DFGBasicBlock.cpp: Added.
      (DFG):
      (JSC::DFG::BasicBlock::BasicBlock):
      (JSC::DFG::BasicBlock::~BasicBlock):
      (JSC::DFG::BasicBlock::ensureLocals):
      (JSC::DFG::BasicBlock::isInPhis):
      (JSC::DFG::BasicBlock::isInBlock):
      (JSC::DFG::BasicBlock::removePredecessor):
      (JSC::DFG::BasicBlock::replacePredecessor):
      (JSC::DFG::BasicBlock::dump):
      (JSC::DFG::BasicBlock::SSAData::SSAData):
      (JSC::DFG::BasicBlock::SSAData::~SSAData):
      * dfg/DFGBasicBlock.h:
      (BasicBlock):
      (JSC::DFG::BasicBlock::operator[]):
      (JSC::DFG::BasicBlock::successor):
      (JSC::DFG::BasicBlock::successorForCondition):
      (SSAData):
      * dfg/DFGBasicBlockInlines.h:
      (DFG):
      * dfg/DFGBlockInsertionSet.cpp: Added.
      (DFG):
      (JSC::DFG::BlockInsertionSet::BlockInsertionSet):
      (JSC::DFG::BlockInsertionSet::~BlockInsertionSet):
      (JSC::DFG::BlockInsertionSet::insert):
      (JSC::DFG::BlockInsertionSet::insertBefore):
      (JSC::DFG::BlockInsertionSet::execute):
      * dfg/DFGBlockInsertionSet.h: Added.
      (DFG):
      (BlockInsertionSet):
      * dfg/DFGCFAPhase.cpp:
      (JSC::DFG::CFAPhase::run):
      * dfg/DFGCFGSimplificationPhase.cpp:
      * dfg/DFGCPSRethreadingPhase.cpp:
      (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
      * dfg/DFGCommon.cpp:
      (WTF::printInternal):
      * dfg/DFGCommon.h:
      (JSC::DFG::doesKill):
      (DFG):
      (JSC::DFG::killStatusForDoesKill):
      * dfg/DFGConstantFoldingPhase.cpp:
      (JSC::DFG::ConstantFoldingPhase::foldConstants):
      (JSC::DFG::ConstantFoldingPhase::isCapturedAtOrAfter):
      * dfg/DFGCriticalEdgeBreakingPhase.cpp: Added.
      (DFG):
      (CriticalEdgeBreakingPhase):
      (JSC::DFG::CriticalEdgeBreakingPhase::CriticalEdgeBreakingPhase):
      (JSC::DFG::CriticalEdgeBreakingPhase::run):
      (JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
      (JSC::DFG::performCriticalEdgeBreaking):
      * dfg/DFGCriticalEdgeBreakingPhase.h: Added.
      (DFG):
      * dfg/DFGDCEPhase.cpp:
      (JSC::DFG::DCEPhase::run):
      (JSC::DFG::DCEPhase::findTypeCheckRoot):
      (JSC::DFG::DCEPhase::countNode):
      (DCEPhase):
      (JSC::DFG::DCEPhase::countEdge):
      (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
      * dfg/DFGDriver.cpp:
      (JSC::DFG::compile):
      * dfg/DFGEdge.cpp:
      (JSC::DFG::Edge::dump):
      * dfg/DFGEdge.h:
      (JSC::DFG::Edge::Edge):
      (JSC::DFG::Edge::setNode):
      (JSC::DFG::Edge::useKindUnchecked):
      (JSC::DFG::Edge::setUseKind):
      (JSC::DFG::Edge::setProofStatus):
      (JSC::DFG::Edge::willNotHaveCheck):
      (JSC::DFG::Edge::willHaveCheck):
      (Edge):
      (JSC::DFG::Edge::killStatusUnchecked):
      (JSC::DFG::Edge::killStatus):
      (JSC::DFG::Edge::setKillStatus):
      (JSC::DFG::Edge::doesKill):
      (JSC::DFG::Edge::doesNotKill):
      (JSC::DFG::Edge::shift):
      (JSC::DFG::Edge::makeWord):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGFlushFormat.cpp: Added.
      (WTF):
      (WTF::printInternal):
      * dfg/DFGFlushFormat.h: Added.
      (DFG):
      (JSC::DFG::resultFor):
      (JSC::DFG::useKindFor):
      (WTF):
      * dfg/DFGFlushLivenessAnalysisPhase.cpp: Added.
      (DFG):
      (FlushLivenessAnalysisPhase):
      (JSC::DFG::FlushLivenessAnalysisPhase::FlushLivenessAnalysisPhase):
      (JSC::DFG::FlushLivenessAnalysisPhase::run):
      (JSC::DFG::FlushLivenessAnalysisPhase::process):
      (JSC::DFG::FlushLivenessAnalysisPhase::setForNode):
      (JSC::DFG::FlushLivenessAnalysisPhase::flushFormat):
      (JSC::DFG::performFlushLivenessAnalysis):
      * dfg/DFGFlushLivenessAnalysisPhase.h: Added.
      (DFG):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      (JSC::DFG::Graph::dumpBlockHeader):
      (DFG):
      (JSC::DFG::Graph::addForDepthFirstSort):
      (JSC::DFG::Graph::getBlocksInDepthFirstOrder):
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::convertToConstant):
      (JSC::DFG::Graph::valueProfileFor):
      (Graph):
      * dfg/DFGInsertionSet.h:
      (DFG):
      (JSC::DFG::InsertionSet::execute):
      * dfg/DFGLivenessAnalysisPhase.cpp: Added.
      (DFG):
      (LivenessAnalysisPhase):
      (JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase):
      (JSC::DFG::LivenessAnalysisPhase::run):
      (JSC::DFG::LivenessAnalysisPhase::process):
      (JSC::DFG::LivenessAnalysisPhase::addChildUse):
      (JSC::DFG::performLivenessAnalysis):
      * dfg/DFGLivenessAnalysisPhase.h: Added.
      (DFG):
      * dfg/DFGNode.cpp:
      (JSC::DFG::Node::hasVariableAccessData):
      (DFG):
      * dfg/DFGNode.h:
      (DFG):
      (Node):
      (JSC::DFG::Node::hasLocal):
      (JSC::DFG::Node::variableAccessData):
      (JSC::DFG::Node::hasPhi):
      (JSC::DFG::Node::phi):
      (JSC::DFG::Node::takenBlock):
      (JSC::DFG::Node::notTakenBlock):
      (JSC::DFG::Node::successor):
      (JSC::DFG::Node::successorForCondition):
      (JSC::DFG::nodeComparator):
      (JSC::DFG::nodeListDump):
      (JSC::DFG::nodeMapDump):
      * dfg/DFGNodeFlags.cpp:
      (JSC::DFG::dumpNodeFlags):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: Added.
      (DFG):
      (OSRAvailabilityAnalysisPhase):
      (JSC::DFG::OSRAvailabilityAnalysisPhase::OSRAvailabilityAnalysisPhase):
      (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
      (JSC::DFG::performOSRAvailabilityAnalysis):
      * dfg/DFGOSRAvailabilityAnalysisPhase.h: Added.
      (DFG):
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::compileInThreadImpl):
      * dfg/DFGPredictionInjectionPhase.cpp:
      (JSC::DFG::PredictionInjectionPhase::run):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSSAConversionPhase.cpp: Added.
      (DFG):
      (SSAConversionPhase):
      (JSC::DFG::SSAConversionPhase::SSAConversionPhase):
      (JSC::DFG::SSAConversionPhase::run):
      (JSC::DFG::SSAConversionPhase::forwardPhiChildren):
      (JSC::DFG::SSAConversionPhase::forwardPhi):
      (JSC::DFG::SSAConversionPhase::forwardPhiEdge):
      (JSC::DFG::SSAConversionPhase::deduplicateChildren):
      (JSC::DFG::SSAConversionPhase::addFlushedLocalOp):
      (JSC::DFG::SSAConversionPhase::addFlushedLocalEdge):
      (JSC::DFG::performSSAConversion):
      * dfg/DFGSSAConversionPhase.h: Added.
      (DFG):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGValidate.cpp:
      (JSC::DFG::Validate::validate):
      (Validate):
      (JSC::DFG::Validate::validateCPS):
      * dfg/DFGVariableAccessData.h:
      (JSC::DFG::VariableAccessData::flushFormat):
      (VariableAccessData):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
      (JSC::FTL::LowerDFGToLLVM::lower):
      (JSC::FTL::LowerDFGToLLVM::createPhiVariables):
      (JSC::FTL::LowerDFGToLLVM::compileBlock):
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileUpsilon):
      (LowerDFGToLLVM):
      (JSC::FTL::LowerDFGToLLVM::compilePhi):
      (JSC::FTL::LowerDFGToLLVM::compileJSConstant):
      (JSC::FTL::LowerDFGToLLVM::compileWeakJSConstant):
      (JSC::FTL::LowerDFGToLLVM::compileGetArgument):
      (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
      (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
      (JSC::FTL::LowerDFGToLLVM::compileAdd):
      (JSC::FTL::LowerDFGToLLVM::compileArithSub):
      (JSC::FTL::LowerDFGToLLVM::compileArithMul):
      (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
      (JSC::FTL::LowerDFGToLLVM::compileArithMod):
      (JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
      (JSC::FTL::LowerDFGToLLVM::compileArithAbs):
      (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
      (JSC::FTL::LowerDFGToLLVM::compileBitAnd):
      (JSC::FTL::LowerDFGToLLVM::compileBitOr):
      (JSC::FTL::LowerDFGToLLVM::compileBitXor):
      (JSC::FTL::LowerDFGToLLVM::compileBitRShift):
      (JSC::FTL::LowerDFGToLLVM::compileBitLShift):
      (JSC::FTL::LowerDFGToLLVM::compileBitURShift):
      (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
      (JSC::FTL::LowerDFGToLLVM::compileInt32ToDouble):
      (JSC::FTL::LowerDFGToLLVM::compileGetButterfly):
      (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
      (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
      (JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
      (JSC::FTL::LowerDFGToLLVM::compileGetGlobalVar):
      (JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
      (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEqConstant):
      (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
      (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq):
      (JSC::FTL::LowerDFGToLLVM::compileCompareGreater):
      (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq):
      (JSC::FTL::LowerDFGToLLVM::compileLogicalNot):
      (JSC::FTL::LowerDFGToLLVM::speculateBackward):
      (JSC::FTL::LowerDFGToLLVM::lowInt32):
      (JSC::FTL::LowerDFGToLLVM::lowCell):
      (JSC::FTL::LowerDFGToLLVM::lowBoolean):
      (JSC::FTL::LowerDFGToLLVM::lowDouble):
      (JSC::FTL::LowerDFGToLLVM::lowJSValue):
      (JSC::FTL::LowerDFGToLLVM::lowStorage):
      (JSC::FTL::LowerDFGToLLVM::speculate):
      (JSC::FTL::LowerDFGToLLVM::speculateBoolean):
      (JSC::FTL::LowerDFGToLLVM::isLive):
      (JSC::FTL::LowerDFGToLLVM::use):
      (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
      (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
      (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
      (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
      (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
      (JSC::FTL::LowerDFGToLLVM::setInt32):
      (JSC::FTL::LowerDFGToLLVM::setJSValue):
      (JSC::FTL::LowerDFGToLLVM::setBoolean):
      (JSC::FTL::LowerDFGToLLVM::setStorage):
      (JSC::FTL::LowerDFGToLLVM::setDouble):
      (JSC::FTL::LowerDFGToLLVM::isValid):
      * ftl/FTLLoweredNodeValue.h: Added.
      (FTL):
      (LoweredNodeValue):
      (JSC::FTL::LoweredNodeValue::LoweredNodeValue):
      (JSC::FTL::LoweredNodeValue::isSet):
      (JSC::FTL::LoweredNodeValue::operator!):
      (JSC::FTL::LoweredNodeValue::value):
      (JSC::FTL::LoweredNodeValue::block):
      * ftl/FTLValueFromBlock.h:
      (JSC::FTL::ValueFromBlock::ValueFromBlock):
      (ValueFromBlock):
      * ftl/FTLValueSource.cpp:
      (JSC::FTL::ValueSource::dump):
      * ftl/FTLValueSource.h:
      
      Source/WTF:
      
      Reviewed by Mark Hahnenberg.
      
      - Extend variadicity of PrintStream and dataLog.
      
      - Give HashSet the ability to add a span of things.
      
      - Give HashSet the ability to == another HashSet.
      
      - Note FIXME's in HashTable concerning copying performance, that affects
        the way that the DFG now uses HashSets and HashMaps.
      
      - Factor out the bulk-insertion logic of JSC::DFG::InsertionSet into
        WTF::Insertion, so that it can be used in more places.
      
      - Create a dumper for lists and maps.
      
      * WTF.xcodeproj/project.pbxproj:
      * wtf/DataLog.h:
      (WTF):
      (WTF::dataLog):
      * wtf/HashSet.h:
      (HashSet):
      (WTF):
      (WTF::::add):
      (WTF::=):
      * wtf/HashTable.h:
      (WTF::::HashTable):
      (WTF::=):
      * wtf/Insertion.h: Added.
      (WTF):
      (Insertion):
      (WTF::Insertion::Insertion):
      (WTF::Insertion::index):
      (WTF::Insertion::element):
      (WTF::Insertion::operator<):
      (WTF::executeInsertions):
      * wtf/ListDump.h: Added.
      (WTF):
      (ListDump):
      (WTF::ListDump::ListDump):
      (WTF::ListDump::dump):
      (MapDump):
      (WTF::MapDump::MapDump):
      (WTF::MapDump::dump):
      (WTF::listDump):
      (WTF::sortedListDump):
      (WTF::lessThan):
      (WTF::mapDump):
      (WTF::sortedMapDump):
      * wtf/PrintStream.h:
      (PrintStream):
      (WTF::PrintStream::print):
      
      Conflicts:
      	Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153274 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      827d2cf7
    • oliver@apple.com's avatar
      fourthTier: Graph::clearAndDerefChild() makes no sense anymore, and neither does Nop · afbdabe0
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118452
      
      Reviewed by Sam Weinig.
      
      Noticed that ArgumentsSimplificationPhase was converting something to a Nop and then
      resetting its children using clearAndDerefChild(). Using Nop instead of Phantom is a
      holdover from back when we needed a no-MustGenerate no-op. We don't anymore. Using
      clearAndDerefChild() was necessary back when we did eager reference counting. We
      don't need to do that anymore, and in fact clearAndDerefChild() appeared to not do
      any reference counting, so it was badly named to begin with.
      
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::executeEffects):
      * dfg/DFGArgumentsSimplificationPhase.cpp:
      (JSC::DFG::ArgumentsSimplificationPhase::run):
      * dfg/DFGCPSRethreadingPhase.cpp:
      (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGGraph.h:
      (Graph):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::willHaveCodeGenOrOSR):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153269 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      afbdabe0
    • oliver@apple.com's avatar
      fourthTier: DFG should support op_switch_imm · 9b7647ba
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=117559
      
      Reviewed by Oliver Hunt.
      
      Implement integer (i.e. immediate) switches in the DFG. Reduce the minimum
      threshold for using op_switch.
      
      Also get rid of edge code support, since we haven't used it in the year since
      I introduced it. It was supposed to allow us to break critical edges late in
      the backend, thus enabling global register allocation from an SSA-form graph.
      But we aren't doing that so I figure we should just kill the code for now. It
      would have made implementing switch harder.
      
      * assembler/AbstractMacroAssembler.h:
      (JSC::AbstractMacroAssembler::timesPtr):
      * assembler/MacroAssemblerCodeRef.h:
      (JSC::MacroAssemblerCodePtr::dumpWithName):
      (MacroAssemblerCodePtr):
      (JSC::MacroAssemblerCodePtr::dump):
      (MacroAssemblerCodeRef):
      (JSC::MacroAssemblerCodeRef::dump):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::shrinkToFit):
      * bytecode/JumpTable.h:
      (SimpleJumpTable):
      (JSC::SimpleJumpTable::clear):
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::executeEffects):
      (JSC::DFG::AbstractState::mergeToSuccessors):
      * dfg/DFGBackwardsPropagationPhase.cpp:
      (JSC::DFG::BackwardsPropagationPhase::propagate):
      * dfg/DFGByteCodeParser.cpp:
      (InlineStackEntry):
      (JSC::DFG::ByteCodeParser::parseBlock):
      (JSC::DFG::ByteCodeParser::linkBlock):
      (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::capabilityLevel):
      * dfg/DFGCommon.h:
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      (JSC::DFG::Graph::determineReachability):
      * dfg/DFGGraph.h:
      (Graph):
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::JITCompiler):
      (JSC::DFG::JITCompiler::link):
      * dfg/DFGJITCompiler.h:
      (JITCompiler):
      (JSC::DFG::JITCompiler::blockHeads):
      * dfg/DFGNode.h:
      (DFG):
      (JSC::DFG::SwitchCase::SwitchCase):
      (SwitchCase):
      (SwitchData):
      (JSC::DFG::SwitchData::SwitchData):
      (Node):
      (JSC::DFG::Node::isSwitch):
      (JSC::DFG::Node::isTerminal):
      (JSC::DFG::Node::switchData):
      (JSC::DFG::Node::numSuccessors):
      (JSC::DFG::Node::successor):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
      (JSC::DFG::SpeculativeJIT::compile):
      (JSC::DFG::SpeculativeJIT::createOSREntries):
      (JSC::DFG::SpeculativeJIT::emitSwitchImmIntJump):
      (DFG):
      (JSC::DFG::SpeculativeJIT::emitSwitchImm):
      (JSC::DFG::SpeculativeJIT::emitSwitch):
      (JSC::DFG::SpeculativeJIT::linkBranches):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      (SpeculativeJIT):
      (JSC::DFG::SpeculativeJIT::branchDouble):
      (JSC::DFG::SpeculativeJIT::branchDoubleNonZero):
      (JSC::DFG::SpeculativeJIT::branch32):
      (JSC::DFG::SpeculativeJIT::branchTest32):
      (JSC::DFG::SpeculativeJIT::branch64):
      (JSC::DFG::SpeculativeJIT::branchPtr):
      (JSC::DFG::SpeculativeJIT::branchTestPtr):
      (JSC::DFG::SpeculativeJIT::branchTest8):
      (JSC::DFG::SpeculativeJIT::jump):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      * parser/Nodes.h:
      (CaseBlockNode):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153228 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9b7647ba
    • oliver@apple.com's avatar
      fourthTier: DFG should support op_in and it should use patching to make it fast · b3e5acbf
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=117385
      
      Source/JavaScriptCore:
      
      Reviewed by Geoffrey Garen.
      
      Implement op_in in the DFG and give it patching. The code we generate is just
      a jump on the hot path, and the slow paths generate stubs and link the jump to
      them. I didn't want to bother with patching structures and load offsets and
      the like, although I probably could have.
      
      This is a ginormous speed-up on microbenchmarks for "in", obviously.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpAssumingJITType):
      (JSC::CodeBlock::resetStubInternal):
      (JSC::structureStubInfoLessThan):
      (JSC):
      (JSC::CodeBlock::sortStructureStubInfos):
      * bytecode/CodeBlock.h:
      (CodeBlock):
      * bytecode/StructureStubInfo.cpp:
      (JSC::StructureStubInfo::deref):
      (JSC::StructureStubInfo::visitWeakReferences):
      * bytecode/StructureStubInfo.h:
      (JSC::isInAccess):
      (JSC):
      (StructureStubInfo):
      (JSC::StructureStubInfo::initInList):
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCCallHelpers.h:
      (JSC::DFG::CCallHelpers::setupResults):
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::capabilityLevel):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGGPRInfo.h:
      (JSC::DFG::JSValueRegs::payloadOnly):
      (JSValueRegs):
      (JSC::DFG::JSValueRegs::JSValueRegs):
      (JSC::DFG::JSValueRegs::operator!):
      (JSC::DFG::JSValueSource::operator!):
      * dfg/DFGJITCompiler.cpp:
      (JSC::DFG::JITCompiler::link):
      * dfg/DFGJITCompiler.h:
      (JSC::DFG::InRecord::InRecord):
      (InRecord):
      (DFG):
      (JITCompiler):
      (JSC::DFG::JITCompiler::addIn):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGRepatch.cpp:
      (JSC::DFG::tryRepatchIn):
      (DFG):
      (JSC::DFG::dfgRepatchIn):
      (JSC::DFG::dfgResetIn):
      * dfg/DFGRepatch.h:
      (DFG):
      (JSC::DFG::dfgResetIn):
      * dfg/DFGSlowPathGenerator.h:
      (JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
      (JSC::DFG::CallSlowPathGenerator::tearDown):
      (JSC::DFG::CallResultAndNoArgumentsSlowPathGenerator::generateInternal):
      (JSC::DFG::CallResultAndOneArgumentSlowPathGenerator::generateInternal):
      (JSC::DFG::CallResultAndTwoArgumentsSlowPathGenerator::generateInternal):
      (JSC::DFG::CallResultAndThreeArgumentsSlowPathGenerator::generateInternal):
      (JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::generateInternal):
      (JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::generateInternal):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileIn):
      (DFG):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::extractResult):
      (DFG):
      (SpeculativeJIT):
      (JSC::DFG::SpeculativeJIT::callOperation):
      (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult):
      (JSC::DFG::SpeculativeJIT::appendCallSetResult):
      (JSC::DFG::JSValueOperand::tagGPR):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * runtime/JSCJSValue.cpp:
      (JSC::JSValue::dump):
      * runtime/JSString.h:
      (JSString):
      (JSC::JSString::tryGetValueImpl):
      (JSC):
      * runtime/Operations.h:
      (JSC::normalizePrototypeChainForChainAccess):
      
      Source/WTF:
      
      Reviewed by Geoffrey Garen.
      
      Now if you pass a null StringImpl* then something will still get printed instead
      of crashing. I figure that this is broadly useful for debug code, and I make use
      of it in the JSC portion of this patch.
      
      * wtf/PrintStream.cpp:
      (WTF::printInternal):
      
      LayoutTests:
      
      Reviewed by Geoffrey Garen.
      
      Test coverage for op_in performance.
      
      * fast/js/regress/in-four-cases-expected.txt: Added.
      * fast/js/regress/in-four-cases.html: Added.
      * fast/js/regress/in-one-case-false-expected.txt: Added.
      * fast/js/regress/in-one-case-false.html: Added.
      * fast/js/regress/in-one-case-true-expected.txt: Added.
      * fast/js/regress/in-one-case-true.html: Added.
      * fast/js/regress/in-two-cases-expected.txt: Added.
      * fast/js/regress/in-two-cases.html: Added.
      * fast/js/regress/script-tests/in-four-cases.js: Added.
      (foo):
      (bar):
      * fast/js/regress/script-tests/in-one-case-false.js: Added.
      (foo):
      (bar):
      * fast/js/regress/script-tests/in-one-case-true.js: Added.
      (foo):
      (bar):
      * fast/js/regress/script-tests/in-two-cases.js: Added.
      (foo):
      (bar):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153225 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b3e5acbf
    • oliver@apple.com's avatar
      fourthTier: Re-worked non-local variable resolution · 58c86752
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=117375
      
      Reviewed by Filip Pizlo.
      
      Source/JavaScriptCore:
      
      This patch has two goals:
      
      (1) Simplicity.
      
          * Net removes 15 opcodes.
          * Net removes 2,000 lines of code.
          * Removes setPair() from the DFG: All DFG nodes have 1 result register now.
      
      (2) Performance.
      
          * 2%-3% speedup on SunSpider (20% in LLInt and Baseline JIT)
          * 2% speedup on v8-spider
          * 10% speedup on js-regress-hashmap*
          * Amusing 2X speedup on js-regress-poly-stricteq
      
      The bytecode now separates the scope chain resolution opcode from the
      scope access opcode.
      
          OLD:
              get_scoped_var  r0, 1, 0
              inc             r0
              put_scoped_var  1, 0, r0
      
          NEW:
              resolve_scope   r0, x(@id0)
              get_from_scope  r1, r0, x(@id0)
              inc             r1
              put_to_scope    r0, x(@id0), r1
      
      Also, we link non-local variable resolution opcodes at CodeBlock link
      time instead of time of first opcode execution.
      
      This means that we can represent all possible non-local variable
      resolutions using just three opcodes, and any optimizations in these
      opcodes naturally apply across-the-board.
      
      * API/JSCTestRunnerUtils.cpp:
      (JSC::numberOfDFGCompiles):
      * GNUmakefile.list.am:
      * JavaScriptCore.gypi:
      * JavaScriptCore.order:
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * Target.pri: Build!
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpBytecode): Updated for removed things.
      
      (JSC::CodeBlock::CodeBlock): Always provide the full scope chain when
      creating a CodeBlock, so we can perform non-local variable resolution.
      
      Added code to perform linking for these opcodes. This is where we figure
      out which non-local variable resolutions are optimizable, and how.
      
      (JSC::CodeBlock::finalizeUnconditionally):
      (JSC::CodeBlock::noticeIncomingCall):
      (JSC::CodeBlock::optimizeAfterWarmUp):
      (JSC::CodeBlock::optimizeAfterLongWarmUp):
      (JSC::CodeBlock::optimizeSoon): Updated for removed things.
      
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::needsActivation):
      (JSC::GlobalCodeBlock::GlobalCodeBlock):
      (JSC::ProgramCodeBlock::ProgramCodeBlock):
      (JSC::EvalCodeBlock::EvalCodeBlock):
      (JSC::FunctionCodeBlock::FunctionCodeBlock):
      * bytecode/EvalCodeCache.h:
      (JSC::EvalCodeCache::getSlow): Updated for interface changes.
      
      * bytecode/GetByIdStatus.cpp:
      (JSC::GetByIdStatus::computeFor): Treat global object access as
      optimizable even though the global object has a custom property access
      callback. This is what we've always done since, otherwise, we can't
      optimize globals. (In future, we probably want to figure out a more
      targeted policy than "any property access callback means no
      optimization".)
      
      * bytecode/GlobalResolveInfo.h: Removed.
      * bytecode/Instruction.h:
      * bytecode/Opcode.h:
      (JSC::padOpcodeName):
      
      * bytecode/PutByIdStatus.cpp:
      (JSC::PutByIdStatus::computeFor): Like GetByIdStatus.
      
      * bytecode/ResolveGlobalStatus.cpp: Removed.
      * bytecode/ResolveGlobalStatus.h: Removed.
      * bytecode/ResolveOperation.h: Removed.
      
      * bytecode/UnlinkedCodeBlock.cpp:
      (JSC::generateFunctionCodeBlock):
      (JSC::UnlinkedFunctionExecutable::codeBlockFor):
      (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
      * bytecode/UnlinkedCodeBlock.h: Don't provide a scope chain to unlinked
      code blocks. Giving a scope to an unscoped compilation unit invites
      programming errors.
      
      * bytecode/Watchpoint.h:
      (JSC::WatchpointSet::addressOfIsInvalidated):
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      (JSC::BytecodeGenerator::resolveCallee):
      (JSC::BytecodeGenerator::local):
      (JSC::BytecodeGenerator::constLocal):
      (JSC::BytecodeGenerator::resolveType):
      (JSC::BytecodeGenerator::emitResolveScope):
      (JSC::BytecodeGenerator::emitGetFromScope):
      (JSC::BytecodeGenerator::emitPutToScope):
      (JSC::BytecodeGenerator::emitInstanceOf):
      (JSC::BytecodeGenerator::emitPushWithScope):
      (JSC::BytecodeGenerator::emitPopScope):
      (JSC::BytecodeGenerator::pushFinallyContext):
      (JSC::BytecodeGenerator::emitComplexPopScopes):
      (JSC::BytecodeGenerator::popTryAndEmitCatch):
      (JSC::BytecodeGenerator::emitPushNameScope):
      (JSC::BytecodeGenerator::isArgumentNumber):
      * bytecompiler/BytecodeGenerator.h:
      (JSC::Local::Local):
      (JSC::Local::operator bool):
      (JSC::Local::get):
      (JSC::Local::isReadOnly):
      (JSC::BytecodeGenerator::scopeDepth):
      (JSC::BytecodeGenerator::shouldOptimizeLocals):
      (JSC::BytecodeGenerator::canOptimizeNonLocals): Refactored the bytecode
      generator to resolve all variables within local scope, as if there
      were no non-local scope. This helps provide a separation of concerns:
      unlinked bytecode is always scope-free, and the linking stage links
      in the provided scope.
      
      * bytecompiler/NodesCodegen.cpp:
      (JSC::ResolveNode::isPure):
      (JSC::ResolveNode::emitBytecode):
      (JSC::EvalFunctionCallNode::emitBytecode):
      (JSC::FunctionCallResolveNode::emitBytecode):
      (JSC::PostfixNode::emitResolve):
      (JSC::DeleteResolveNode::emitBytecode):
      (JSC::TypeOfResolveNode::emitBytecode):
      (JSC::PrefixNode::emitResolve):
      (JSC::ReadModifyResolveNode::emitBytecode):
      (JSC::AssignResolveNode::emitBytecode):
      (JSC::ConstDeclNode::emitCodeSingle):
      (JSC::ForInNode::emitBytecode): A bunch of this codegen is no longer
      necessary, since it's redundant with the linking stage.
      
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::ByteCodeParser):
      (JSC::DFG::ByteCodeParser::cellConstantWithStructureCheck):
      (JSC::DFG::ByteCodeParser::handlePutByOffset):
      (JSC::DFG::ByteCodeParser::handleGetById):
      (JSC::DFG::ByteCodeParser::parseBlock): Updated for interface changes.
      Notably, we can reuse existing DFG nodes -- but the mapping between
      bytecode and DFG nodes has changed, and some nodes and corner cases have
      been removed.
      
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::scopedVarLoadElimination):
      (JSC::DFG::CSEPhase::varInjectionWatchpointElimination):
      (JSC::DFG::CSEPhase::globalVarStoreElimination):
      (JSC::DFG::CSEPhase::scopedVarStoreElimination):
      (JSC::DFG::CSEPhase::getLocalLoadElimination):
      (JSC::DFG::CSEPhase::setLocalStoreElimination):
      (JSC::DFG::CSEPhase::performNodeCSE): Added CSE for var injection
      watchpoints. Even though watchpoints are "free", they're quite common
      inside code that's subject to var injection, so I figured we'd save a
      little memory.
      
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::capabilityLevel):
      * dfg/DFGCapabilities.h: Removed detection for old forms.
      
      * dfg/DFGDriver.h:
      (JSC::DFG::tryCompile):
      (JSC::DFG::tryCompileFunction):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGGraph.h:
      * dfg/DFGJITCode.cpp:
      * dfg/DFGNode.h:
      (JSC::DFG::Node::convertToStructureTransitionWatchpoint):
      (JSC::DFG::Node::hasVarNumber):
      (JSC::DFG::Node::hasIdentifierNumberForCheck):
      (JSC::DFG::Node::hasRegisterPointer):
      (JSC::DFG::Node::hasHeapPrediction):
      * dfg/DFGNodeType.h:
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGRepatch.h:
      (JSC::DFG::dfgResetGetByID):
      (JSC::DFG::dfgResetPutByID):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation): Removed some unneeded things,
      and updated for renames.
      
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile): The two primary changes here are:
      
      (1) Use a watchpoint for var injection instead of looping over the scope
      chain and checking. This is more efficient and much easier to model in
      code generation.
      
      (2) I've eliminated the notion of an optimized global assignment that
      needs to check for whether it should fire a watchpiont. Instead, we
      fire pre-emptively at the point of optimization. This removes a bunch
      of edge cases, and it seems like a more honest representation of
      the fact that our new optimization contradicts our old one.
      
      * dfg/DFGTypeCheckHoistingPhase.cpp:
      (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
      (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
      * heap/DFGCodeBlocks.cpp:
      (JSC::DFGCodeBlocks::jettison):
      * interpreter/CallFrame.h:
      (JSC::ExecState::trueCallFrame): Removed stuff that's unused now, and
      fixed the build.
      
      * interpreter/Interpreter.cpp:
      (JSC::eval):
      (JSC::getBytecodeOffsetForCallFrame):
      (JSC::getCallerInfo):
      (JSC::Interpreter::throwException): Updated exception scope tracking
      to match the rest of our linking strategy: The unlinked bytecode compiles
      exception scope as if non-local scope did not exist, and we add in
      non-local scope at link time. This means that we can restore the right
      scope depth based on a simple number, without checking the contents of
      the scope chain.
      
      (JSC::Interpreter::execute): Make sure to establish the full scope chain
      before linking eval code. We now require the full scope chain at link
      time, in order to link non-local variable resolution opcodes.
      
      * jit/JIT.cpp:
      (JSC::JIT::JIT):
      (JSC::JIT::privateCompileMainPass):
      (JSC::JIT::privateCompileSlowCases):
      * jit/JIT.h:
      * jit/JITArithmetic.cpp:
      (JSC::JIT::emit_op_add):
      * jit/JITCode.cpp:
      * jit/JITOpcodes.cpp:
      (JSC::JIT::emitSlow_op_bitxor):
      (JSC::JIT::emitSlow_op_bitor):
      * jit/JITOpcodes32_64.cpp:
      (JSC::JIT::emitSlow_op_to_primitive):
      (JSC::JIT::emit_op_strcat):
      (JSC::JIT::emitSlow_op_create_this):
      (JSC::JIT::emitSlow_op_to_this):
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emitVarInjectionCheck):
      (JSC::JIT::emitResolveClosure):
      (JSC::JIT::emit_op_resolve_scope):
      (JSC::JIT::emitSlow_op_resolve_scope):
      (JSC::JIT::emitLoadWithStructureCheck):
      (JSC::JIT::emitGetGlobalProperty):
      (JSC::JIT::emitGetGlobalVar):
      (JSC::JIT::emitGetClosureVar):
      (JSC::JIT::emit_op_get_from_scope):
      (JSC::JIT::emitSlow_op_get_from_scope):
      (JSC::JIT::emitPutGlobalProperty):
      (JSC::JIT::emitPutGlobalVar):
      (JSC::JIT::emitPutClosureVar):
      (JSC::JIT::emit_op_put_to_scope):
      (JSC::JIT::emitSlow_op_put_to_scope):
      (JSC::JIT::emit_op_init_global_const):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emitVarInjectionCheck):
      (JSC::JIT::emitResolveClosure):
      (JSC::JIT::emit_op_resolve_scope):
      (JSC::JIT::emitSlow_op_resolve_scope):
      (JSC::JIT::emitLoadWithStructureCheck):
      (JSC::JIT::emitGetGlobalProperty):
      (JSC::JIT::emitGetGlobalVar):
      (JSC::JIT::emitGetClosureVar):
      (JSC::JIT::emit_op_get_from_scope):
      (JSC::JIT::emitSlow_op_get_from_scope):
      (JSC::JIT::emitPutGlobalProperty):
      (JSC::JIT::emitPutGlobalVar):
      (JSC::JIT::emitPutClosureVar):
      (JSC::JIT::emit_op_put_to_scope):
      (JSC::JIT::emitSlow_op_put_to_scope):
      (JSC::JIT::emit_op_init_global_const):
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      * jit/JITStubs.h: Re-wrote baseline JIT codegen for our new variable
      resolution model.
      
      * llint/LLIntData.cpp:
      (JSC::LLInt::Data::performAssertions):
      * llint/LLIntSlowPaths.cpp:
      * llint/LLIntSlowPaths.h:
      * llint/LowLevelInterpreter.asm:
      * llint/LowLevelInterpreter.cpp:
      (JSC::CLoop::execute):
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm: Ditto for LLInt.
      
      * offlineasm/x86.rb: Fixed a pre-existing encoding bug for a syntactic
      form that we never used before.
      
      * runtime/ArrayPrototype.cpp:
      (JSC::arrayProtoFuncToString):
      (JSC::arrayProtoFuncToLocaleString):
      (JSC::arrayProtoFuncJoin):
      (JSC::arrayProtoFuncConcat):
      (JSC::arrayProtoFuncPop):
      (JSC::arrayProtoFuncPush):
      (JSC::arrayProtoFuncReverse):
      (JSC::arrayProtoFuncShift):
      (JSC::arrayProtoFuncSlice):
      (JSC::arrayProtoFuncSort):
      (JSC::arrayProtoFuncSplice):
      (JSC::arrayProtoFuncUnShift):
      (JSC::arrayProtoFuncFilter):
      (JSC::arrayProtoFuncMap):
      (JSC::arrayProtoFuncEvery):
      (JSC::arrayProtoFuncForEach):
      (JSC::arrayProtoFuncSome):
      (JSC::arrayProtoFuncReduce):
      (JSC::arrayProtoFuncReduceRight):
      (JSC::arrayProtoFuncIndexOf):
      (JSC::arrayProtoFuncLastIndexOf): Fixed some pre-existing bugs in
      'this' value conversion, which I made much more common by removing
      special cases in bytecode generation.
      
      These functions need to invoke toThis() because they observe the 'this'
      value. Also, toLocaleString() is specified to accept non-array 'this'
      values.
      
      (Most other host functions don't need this fix because they perform
      strict 'this' checking, which never coerces unexpected types.)
      
      * runtime/CodeCache.cpp:
      (JSC::CodeCache::getCodeBlock):
      (JSC::CodeCache::getProgramCodeBlock):
      (JSC::CodeCache::getEvalCodeBlock):
      * runtime/CodeCache.h: Don't supply a scope to the unlinked code cache.
      Unlinked code is supposed to be scope-free, so let's have the compiler
      help verify that.
      
      * runtime/CommonSlowPaths.cpp:
      (JSC::SLOW_PATH_DECL):
      * runtime/CommonSlowPaths.h:
      * runtime/Executable.cpp:
      (JSC::EvalExecutable::create):
      (JSC::EvalExecutable::compileInternal):
      (JSC::ProgramExecutable::compileInternal):
      (JSC::FunctionExecutable::produceCodeBlockFor):
      (JSC::FunctionExecutable::compileForCallInternal):
      (JSC::FunctionExecutable::compileForConstructInternal):
      * runtime/Executable.h:
      (JSC::EvalExecutable::numVariables):
      (JSC::EvalExecutable::numberOfFunctionDecls):
      * runtime/ExecutionHarness.h:
      (JSC::prepareForExecutionImpl):
      (JSC::prepareFunctionForExecutionImpl):
      (JSC::installOptimizedCode): Fiddled with executable initialization so
      that we can always generate a full scope chain before we go to link a
      code block. We need this because code block linking now depends on the
      scope chain to link non-local variable resolution opcodes.
      
      * runtime/JSActivation.h:
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::JSGlobalObject):
      (JSC::JSGlobalObject::createEvalCodeBlock):
      * runtime/JSGlobalObject.h:
      (JSC::JSGlobalObject::varInjectionWatchpoint):
      * runtime/JSGlobalObjectFunctions.cpp:
      (JSC::globalFuncEval):
      * runtime/JSNameScope.h:
      * runtime/JSScope.cpp:
      (JSC::abstractAccess):
      (JSC::JSScope::objectAtScope):
      (JSC::JSScope::depth):
      (JSC::JSScope::resolve):
      (JSC::JSScope::abstractResolve): Updated to match changes explained above.
      
      * runtime/JSScope.h:
      (JSC::makeType):
      (JSC::needsVarInjectionChecks):
      (JSC::ResolveOp::ResolveOp):
      (JSC::ResolveModeAndType::ResolveModeAndType):
      (JSC::ResolveModeAndType::mode):
      (JSC::ResolveModeAndType::type):
      (JSC::ResolveModeAndType::operand): Removed the old variable resolution
      state machine, since it's unused now. Added logic for performing abstract
      variable resolution at link time. This is used by codeblock linking.
      
      * runtime/ObjectPrototype.cpp:
      (JSC::objectProtoFuncValueOf):
      (JSC::objectProtoFuncHasOwnProperty):
      (JSC::objectProtoFuncIsPrototypeOf):
      (JSC::objectProtoFuncDefineGetter):
      (JSC::objectProtoFuncDefineSetter):
      (JSC::objectProtoFuncLookupGetter):
      (JSC::objectProtoFuncLookupSetter):
      (JSC::objectProtoFuncPropertyIsEnumerable):
      (JSC::objectProtoFuncToLocaleString):
      (JSC::objectProtoFuncToString): Fixed some pre-existing bugs in
      'this' value conversion, which I made much more common by removing
      special cases in bytecode generation.
      
      These functions need to invoke toThis() because they observe the 'this'
      value.
      
      * runtime/StringPrototype.cpp:
      (JSC::checkObjectCoercible):
      (JSC::stringProtoFuncReplace):
      (JSC::stringProtoFuncCharAt):
      (JSC::stringProtoFuncCharCodeAt):
      (JSC::stringProtoFuncConcat):
      (JSC::stringProtoFuncIndexOf):
      (JSC::stringProtoFuncLastIndexOf):
      (JSC::stringProtoFuncMatch):
      (JSC::stringProtoFuncSearch):
      (JSC::stringProtoFuncSlice):
      (JSC::stringProtoFuncSplit):
      (JSC::stringProtoFuncSubstr):
      (JSC::stringProtoFuncSubstring):
      (JSC::stringProtoFuncToLowerCase):
      (JSC::stringProtoFuncToUpperCase):
      (JSC::stringProtoFuncLocaleCompare):
      (JSC::stringProtoFuncBig):
      (JSC::stringProtoFuncSmall):
      (JSC::stringProtoFuncBlink):
      (JSC::stringProtoFuncBold):
      (JSC::stringProtoFuncFixed):
      (JSC::stringProtoFuncItalics):
      (JSC::stringProtoFuncStrike):
      (JSC::stringProtoFuncSub):
      (JSC::stringProtoFuncSup):
      (JSC::stringProtoFuncFontcolor):
      (JSC::stringProtoFuncFontsize):
      (JSC::stringProtoFuncAnchor):
      (JSC::stringProtoFuncLink):
      (JSC::trimString): Fixed some pre-existing bugs in
      'this' value conversion, which I made much more common by removing
      special cases in bytecode generation.
      
      These functions need to invoke toThis() because they observe the 'this'
      value.
      
      * runtime/StructureRareData.cpp:
      * runtime/VM.cpp:
      (JSC::VM::~VM):
      
      * runtime/WriteBarrier.h:
      (JSC::WriteBarrierBase::slot): Modified to reduce casting in client code.
      
      LayoutTests:
      
      This patch removed special-case 'this' resolution from bytecode, making
      some pre-existing edge cases in 'this' value treatment much more common.
      
      I updated the test results below, and added some tests, to match bug
      fixes for these cases.
      
      * fast/js/script-tests/array-functions-non-arrays.js:
      * fast/js/array-functions-non-arrays-expected.txt: As specified, it's
      not an error to pass a non-array to toLocaleString. Our new result
      matches Firefox and Chrome.
      
      * fast/js/array-prototype-properties-expected.txt: Updated for slightly
      clearer error message.
      
      * fast/js/basic-strict-mode-expected.txt: Updated for slightly more
      standard error message.
      
      * fast/js/object-prototype-toString-expected.txt: Added.
      * fast/js/object-prototype-toString.html: Added. This test demonstrates
      why we now fail a Sputnik test below, while Firefox and Chrome pass it.
      (The test doesn't test what it thinks it tests, and this test verifies
      that we get right what it does think it tests.)
      
      * fast/js/string-prototype-function-this-expected.txt: Added.
      * fast/js/string-prototype-function-this.html: Added. This test shows
      that we CheckObjectCoercible in string prototype functions. (We used
      to get this wrong, but Sputnik tests made it seem like we got it right
      because they didn't test the dynamic scope case.)
      
      * sputnik/Conformance/11_Expressions/11.1_Primary_Expressions/11.1.1_The_this_Keyword/S11.1.1_A2-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.3_Array_prototype_toLocaleString/S15.4.4.3_A2_T1-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.10_String.prototype.match/S15.5.4.10_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.11_String.prototype.replace/S15.5.4.11_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.12_String.prototype.search/S15.5.4.12_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.13_String.prototype.slice/S15.5.4.13_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.14_String.prototype.split/S15.5.4.14_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.15_String.prototype.substring/S15.5.4.15_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.6_String.prototype.concat/S15.5.4.6_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.7_String.prototype.indexOf/S15.5.4.7_A1_T3-expected.txt:
      * sputnik/Conformance/15_Native_Objects/15.5_String/15.5.4/15.5.4.8_String.prototype.lastIndexOf/S15.5.4.8_A1_T3-expected.txt:
      
      Updated to show failing results. Firefox and Chrome also fail these
      tests, and the ES5 spec seems to mandate failure. Because these tests
      resolve a String.prototype function at global scope, the 'this' value
      for the call is an environment record. Logically, an environment record
      converts to 'undefined' at the call site, and should then fail the
      CheckObjectCoercible test.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153221 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      58c86752
    • oliver@apple.com's avatar
      fourthTier: DFG CFA should know when it hits a contradiction · 3391387e
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=117272
      
      Reviewed by Oliver Hunt.
      
      This makes the DFG CFA immediately detect when it hit a contradiction. Previously
      we might not know this: for example if we did an int32 type check on a known string;
      the code would definitely always exit but the CFA would think that we wouldn't have
      even though it would have computed a BOTTOM (i.e. contradictory) value for that
      variable.
      
      This requires two other changes:
      
      - CFA must report contradictions as if they are frequent exit sites, since
        contradictory speculations will subsequently get replaced with ForceOSRExit.
        ForceOSRExit cannot itself report profiling data back to the DFG::ExitProfile. So,
        we do this on behalf of the speculation, eagerly, within the CFA. This also has
        the effect of speeding convergence somewhat. We may want to revisit this later;
        for example we might want to instead have the notion of a ForceOSRExit that knows
        the set of speculations that got folded into it.
      
      - This revealed a bug where the CFA was modeling CheckStructure on a node that had
        a known singleton m_futurePossibleStructure set somewhat differently than the
        constant folder. If the CheckStructure was checking a structure set with two or
        more structures in it, it would not filter the abstract value. But the constant
        folder would turn this into a watchpoint on the singleton structure, thereby
        filtering the value. This discrepancy meant that we wouldn't realize the
        contradiction until the backend, and the AbstractState::bail() method asserts that
        we always realize contradictions in the constant folder.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::addFrequentExitSite):
      (JSC::CodeBlock::hasExitSite):
      (CodeBlock):
      * bytecode/DFGExitProfile.cpp:
      (JSC::DFG::ExitProfile::add):
      (JSC::DFG::ExitProfile::hasExitSite):
      (JSC::DFG::QueryableExitProfile::QueryableExitProfile):
      (JSC::DFG::QueryableExitProfile::~QueryableExitProfile):
      (DFG):
      (JSC::DFG::QueryableExitProfile::initialize):
      * bytecode/DFGExitProfile.h:
      (JSC::DFG::FrequentExitSite::FrequentExitSite):
      (ExitProfile):
      (JSC::DFG::ExitProfile::hasExitSite):
      (QueryableExitProfile):
      * bytecode/ExitKind.cpp:
      (JSC::exitKindToString):
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::AbstractState):
      (JSC::DFG::AbstractState::beginBasicBlock):
      (JSC::DFG::AbstractState::reset):
      (JSC::DFG::AbstractState::startExecuting):
      (JSC::DFG::AbstractState::executeEffects):
      (JSC::DFG::AbstractState::execute):
      (JSC::DFG::AbstractState::filter):
      (DFG):
      (JSC::DFG::AbstractState::filterArrayModes):
      (JSC::DFG::AbstractState::filterByValue):
      (JSC::DFG::AbstractState::bail):
      * dfg/DFGAbstractState.h:
      (AbstractState):
      (JSC::DFG::AbstractState::filter):
      (JSC::DFG::AbstractState::filterArrayModes):
      (JSC::DFG::AbstractState::filterByValue):
      (JSC::DFG::AbstractState::filterByType):
      * dfg/DFGAbstractValue.cpp:
      (JSC::DFG::AbstractValue::filter):
      (JSC::DFG::AbstractValue::filterArrayModes):
      (DFG):
      (JSC::DFG::AbstractValue::filterByValue):
      (JSC::DFG::AbstractValue::normalizeClarity):
      * dfg/DFGAbstractValue.h:
      (AbstractValue):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
      * dfg/DFGCFAPhase.cpp:
      (JSC::DFG::CFAPhase::performBlockCFA):
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::debugFail):
      (JSC::DFG::capabilityLevel):
      * dfg/DFGConstantFoldingPhase.cpp:
      (JSC::DFG::ConstantFoldingPhase::foldConstants):
      (ConstantFoldingPhase):
      (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode):
      * dfg/DFGFiltrationResult.h: Added.
      (DFG):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGOSRExitBase.cpp:
      (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
      * dfg/DFGOSRExitBase.h:
      (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::backwardTypeCheck):
      (JSC::DFG::SpeculativeJIT::bail):
      (DFG):
      (JSC::DFG::SpeculativeJIT::compile):
      (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
      (JSC::DFG::SpeculativeJIT::speculateStringObject):
      (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
      * dfg/DFGSpeculativeJIT.h:
      (SpeculativeJIT):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
      (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
      (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
      (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
      (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
      (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
      (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
      (JSC::DFG::SpeculativeJIT::compile):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::appendTypeCheck):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153213 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3391387e
    • oliver@apple.com's avatar
      fourthTier: CheckArrays should be hoisted · c0a050be
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=116353
      
      Source/JavaScriptCore:
      
      Performance neutral. This will be more important when we start depending on CheckArray for flat arrays.
      
      Reviewed by Filip Pizlo.
      
      * dfg/DFGAbstractState.cpp: Add ForwardCheckArray to wherever we had a CheckArray before.
      (JSC::DFG::AbstractState::executeEffects):
      * dfg/DFGArgumentsSimplificationPhase.cpp:
      (JSC::DFG::ArgumentsSimplificationPhase::run):
      * dfg/DFGArrayMode.h:
      (JSC::DFG::ArrayMode::isContravenedByStructure): Checks if the ArrayMode derived from a specific Structure
      would contradict the ArrayModes that would be filtered by the current ArrayMode. This is used to detect
      if any specific CheckStructures would contradict our CheckArray so that we can defer to the CheckStructure's
      judgment.
      * dfg/DFGByteCodeParser.cpp: Fill in checkArrayHoistingFailed where we previously exited due to a BadIndexingType.
      (JSC::DFG::ByteCodeParser::setLocal):
      (JSC::DFG::ByteCodeParser::setArgument):
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::checkArrayElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGConstantFoldingPhase.cpp:
      (JSC::DFG::ConstantFoldingPhase::foldConstants):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::hasArrayMode):
      * dfg/DFGNodeType.h: New ForwardCheckArray node type.
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGTypeCheckHoistingPhase.cpp: Refactored most of TypeCheckHoistingPhase into separate functions, some
      of which are now generic to both CheckStructure and CheckArray hoisting while others are specific to one or the
      other. Both of the non-zero CheckBallot values must be 1 because we use them as an index into an array of
      length 2 inside the VariableAccessData.
      (CheckData): Moved structure outside of TypeCheckHoistingPhase so that ArrayTypeCheck and StructureTypeCheck
      can access it. Also added new fields for tracking ArrayModes. We need the m_arrayModeIsValid because there
      isn't a good sentinel value for "this ArrayMode is invalid and meaningless" like there is for m_structure.
      We need m_arrayModeHoistingOkay for when we want to permanently disable hoisting for that particular variable.
      (JSC::DFG::CheckData::CheckData):
      (JSC::DFG::CheckData::disableCheckArrayHoisting): Helper function for disabling CheckArray hoisting for a
      specific CheckData.
      (JSC::DFG::TypeCheckHoistingPhase::run): We now do both CheckStructure and CheckArray hoisting, although we prefer
      CheckStructure hoisting when given the possibility to do both.
      (TypeCheckHoistingPhase):
      (JSC::DFG::TypeCheckHoistingPhase::clearVariableVotes): Clears all of the VariableAccessData votes since they
      can only have two types of votes at any particular time.
      (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
      (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): Very similar to identifyRedundantStructureChecks,
      but with a few different nodes that are important, namely CheckArray (instead of CheckStructure) and the Arrayify-like
      nodes always disable hoisting since they always change the IndexingType.
      (JSC::DFG::TypeCheckHoistingPhase::disableHoistingForVariablesWithInsufficientVotes):
      (JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
      (JSC::DFG::TypeCheckHoistingPhase::disableCheckArrayHoisting): Helper that looks up the CheckData for the
      specified variable and disables CheckArray hoisting on it.
      (JSC::DFG::TypeCheckHoistingPhase::shouldConsiderForHoisting):
      (JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheck):
      (JSC::DFG::TypeCheckHoistingPhase::noticeCheckArray):
      (JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheckAccountingForArrayMode): We want to take CheckStructure nodes
      into account when hoisting CheckArrays, so we make sure that if we contradict what a CheckStructure says then we
      give up on hoisting the CheckArray.
      (JSC::DFG::ArrayTypeCheck::isValidToHoist):
      (ArrayTypeCheck): Structure that houses some of the specifics on how to hoist CheckArrays. This structure
      is used a template argument to allow some of the very similar code to statically parameterized and reused
      for both CheckStructure and CheckArray hoisting.
      (JSC::DFG::ArrayTypeCheck::disableHoisting):
      (JSC::DFG::ArrayTypeCheck::isContravenedByValue):
      (JSC::DFG::ArrayTypeCheck::hasEnoughVotesToHoist):
      (JSC::DFG::ArrayTypeCheck::hoistingPreviouslyFailed):
      (JSC::DFG::StructureTypeCheck::isValidToHoist):
      (StructureTypeCheck): Same as ArrayTypeCheck, but specific to CheckStructure hoisting.
      (JSC::DFG::StructureTypeCheck::disableHoisting):
      (JSC::DFG::StructureTypeCheck::isContravenedByValue):
      (JSC::DFG::StructureTypeCheck::hasEnoughVotesToHoist):
      (JSC::DFG::StructureTypeCheck::hoistingPreviouslyFailed):
      * dfg/DFGUnificationPhase.cpp: Added merging of whether or not CheckArray hoisting failed.
      (JSC::DFG::UnificationPhase::run):
      * dfg/DFGVariableAccessData.h:
      (JSC::DFG::VariableAccessData::VariableAccessData):
      (JSC::DFG::VariableAccessData::mergeCheckArrayHoistingFailed):
      (VariableAccessData):
      (JSC::DFG::VariableAccessData::checkArrayHoistingFailed):
      * runtime/Options.h:
      
      LayoutTests:
      
      Added a microbenchmark to JSRegress that specifically targets CheckArray hoisting.
      We get a 25% improvement on it.
      
      Reviewed by Filip Pizlo.
      
      * fast/js/regress/check-array-hoisting-expected.txt: Added.
      * fast/js/regress/check-array-hoisting.html: Added.
      * fast/js/regress/script-tests/check-array-hoisting.js: Added.
      (f):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153167 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c0a050be
    • oliver@apple.com's avatar
      fourthTier: Rationalized 'this' conversion, includes subsequent FTL branch fixes · e2fe4ceb
      oliver@apple.com authored
      Reviewed by Oliver Hunt.
      
      Source/JavaScriptCore:
      
          Rationalized 'this' value conversion
          https://bugs.webkit.org/show_bug.cgi?id=115542
      
          This fixes a bunch of Sputnik tests, and some bad pointer access.
      
          The new model is that the callee always performs 'this' value conversion.
      
          My ultimate goal is to break up resolve_with_this into single-result
          opcodes. This step avoids having to add a special form of convert_this
          that distinguishes callers vs callees.
      
          Only the callee knows whether it uses 'this' and/or whether 'this'
          conversion should use StrictMode, so it's most natural to perform
          convert_this in the callee.
      
          * API/JSCallbackFunction.cpp:
          (JSC::JSCallbackFunction::call): Perform 'this' value conversion for
          our callee, since it may observe 'this'.
      
          * API/JSCallbackObjectFunctions.h:
          (JSC::::call): Ditto.
      
          * API/JSContextRef.cpp:
          (JSGlobalContextCreateInGroup): Use a proxy 'this' object in global scope
          even when we're not in the browser. This eliminates some odd cases where
          API clients used to be able to get a direct reference to an environment
          record. Now, any reference to an environment record unambiguously means
          that the VM resolved that record in the scope chain.
      
          (JSContextGetGlobalObject): Removed an incorrect comment. Now that JSC
          participates in the proxy 'this' object scheme, the behavior is not
          WebCore-only.
      
          * API/JSObjectRef.cpp:
          (JSObjectSetPrototype):
          (JSObjectCallAsFunction): Don't perform 'this' value conversion in the
          caller; the callee will do it if needed.
      
          * JavaScriptCore.order: Order!
      
          * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
          * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
          What are the chances that this will work?
      
          * bytecode/CodeBlock.cpp:
          (JSC::CodeBlock::dumpBytecode):
          (JSC::CodeBlock::CodeBlock): Renamed convert_this to to_this, to match our
          other conversion opcodes.
      
          * bytecode/CodeOrigin.h:
          (CodeOrigin):
          (InlineCallFrame):
          (JSC::CodeOrigin::codeOriginOwner): Use the more precise type for our
          executable, so compilation can discover where we're in strict mode.
      
          * bytecode/Opcode.h:
          (JSC::padOpcodeName): Updated for rename.
      
          * bytecompiler/BytecodeGenerator.cpp:
          (JSC::BytecodeGenerator::BytecodeGenerator): Always emit to_this when
          'this' is in use -- strict mode still needs to convert environment
          records to 'undefined'.
      
          * dfg/DFGAbstractState.cpp:
          (JSC::DFG::AbstractState::executeEffects):
          * dfg/DFGByteCodeParser.cpp:
          (JSC::DFG::ByteCodeParser::parseBlock):
          * dfg/DFGCapabilities.h:
          (JSC::DFG::canCompileOpcode): Updated for renames.
      
          * dfg/DFGFixupPhase.cpp:
          (JSC::DFG::FixupPhase::fixupNode): Tightened up this code to consider
          strict mode (a new requirement) and to consider the global object (which
          was always a requirement).
      
          * dfg/DFGGraph.h:
          (JSC::DFG::Graph::globalThisObjectFor):
          (JSC::DFG::Graph::executableFor):
          * dfg/DFGNodeType.h:
          * dfg/DFGOperations.cpp:
          * dfg/DFGOperations.h:
          * dfg/DFGPredictionPropagationPhase.cpp:
          (JSC::DFG::PredictionPropagationPhase::propagate):
          * dfg/DFGSpeculativeJIT32_64.cpp:
          (JSC::DFG::SpeculativeJIT::compile):
          * dfg/DFGSpeculativeJIT64.cpp:
          (JSC::DFG::SpeculativeJIT::compile): Ditto.
      
          * interpreter/Interpreter.cpp:
          (JSC::eval):
          (JSC::Interpreter::execute):
          (JSC::Interpreter::executeCall):
          * interpreter/Interpreter.h: Don't ASSERT about 'this' -- it's our job
          to fix it up if needed.
      
          * jit/JIT.cpp:
          (JSC::JIT::privateCompileMainPass):
          (JSC::JIT::privateCompileSlowCases):
          * jit/JIT.h:
          (JIT):
          * jit/JITOpcodes.cpp:
          (JSC::JIT::emit_op_to_this):
          (JSC::JIT::emitSlow_op_to_this):
          * jit/JITOpcodes32_64.cpp:
          (JSC::JIT::emit_op_to_this):
          (JSC::JIT::emitSlow_op_to_this):
          * jit/JITStubs.cpp:
          (JSC::DEFINE_STUB_FUNCTION):
          * jit/JITStubs.h: Removed special-case code for various kinds of
          conversions. The baseline fast path is now final objects only. It hurt
          my brain to think through how to keep the other fast paths working, and
          our benchmarks do not object.
      
          * llint/LLIntData.cpp:
          (JSC::LLInt::Data::performAssertions):
          * llint/LLIntSlowPaths.cpp:
          (JSC::LLInt::LLINT_SLOW_PATH_DECL):
          * llint/LLIntSlowPaths.h:
          (LLInt):
          * llint/LowLevelInterpreter.asm:
          * llint/LowLevelInterpreter32_64.asm:
          * llint/LowLevelInterpreter64.asm: Updated for renames. Removed some
          special case code, as in the JIT above.
      
          * profiler/ProfileGenerator.cpp:
          (JSC::ProfileGenerator::addParentForConsoleStart):
          * runtime/CallData.cpp:
          (JSC::call):
          * runtime/ClassInfo.h:
          (MethodTable):
          * runtime/Completion.cpp:
          (JSC::evaluate):
          * runtime/DatePrototype.cpp:
          (JSC::dateProtoFuncToJSON): The callee performs 'this' conversion, not
          the caller.
      
          * runtime/GetterSetter.cpp:
          (JSC::callGetter):
          (JSC::callSetter):
          * runtime/GetterSetter.h: Added helper functions for invoking getters
          and setters from C++ code, since this was duplicated in a bunch of
          places.
      
          * runtime/JSActivation.cpp:
          (JSC::JSActivation::toThis):
          * runtime/JSActivation.h:
          (JSActivation):
          * runtime/JSCJSValue.cpp:
          (JSC::JSValue::toThisSlowCase):
          (JSC::JSValue::putToPrimitive):
          * runtime/JSCJSValue.h:
          (JSValue):
          * runtime/JSCJSValueInlines.h:
          (JSC::JSValue::toThis):
          * runtime/JSCell.cpp:
          (JSC::JSCell::toThis):
          * runtime/JSCell.h:
          (JSCell):
          * runtime/JSGlobalObject.cpp:
          (JSC::JSGlobalObject::toThis):
          * runtime/JSGlobalObject.h:
          (JSGlobalObject): Filled out runtime support for converting 'this'
          values as needed, according to the appropriate strictness, using
          helper functions where getter/setter code was duplicated.
      
          * runtime/JSGlobalObjectFunctions.cpp:
          (JSC::globalFuncProtoGetter):
          (JSC::globalFuncProtoSetter): Perform 'this' value conversion, since we
          observe 'this'.
      
          * runtime/JSNameScope.cpp:
          (JSC::JSNameScope::toThis):
          * runtime/JSNameScope.h:
          (JSNameScope): Same as JSActivation.
      
          * runtime/JSObject.cpp:
          (JSC::JSObject::put):
          (JSC::JSObject::setPrototypeWithCycleCheck): Bug fix. Don't peform
          'this' value conversion in this helper function. The __proto__
          setter does this for us, since it's the function that logically observes
          'this' -- and we can ASSERT so. Also, the previous code used
          "globalExec()->thisValue()", which is a read past the beginning of a
          buffer! I don't think this ever worked on purpose.
      
          (JSC::JSObject::toThis):
          (JSC::JSObject::fillGetterPropertySlot):
          * runtime/JSObject.h:
          (JSC::JSObject::inlineGetOwnPropertySlot):
          * runtime/JSScope.cpp:
          (JSC::JSScope::resolveWithThis):
          * runtime/JSString.cpp:
          (JSC::JSString::toThis):
          * runtime/JSString.h:
          (JSString):
          * runtime/PropertySlot.cpp:
          (JSC::PropertySlot::functionGetter):
          * runtime/PropertySlot.h:
          (JSC):
          (JSC::PropertySlot::setGetterSlot):
          (JSC::PropertySlot::setCacheableGetterSlot):
          * runtime/SparseArrayValueMap.cpp:
          (JSC::SparseArrayEntry::get):
          (JSC::SparseArrayEntry::put):
          * runtime/StrictEvalActivation.cpp:
          (JSC::StrictEvalActivation::toThis):
          * runtime/StrictEvalActivation.h:
          (StrictEvalActivation): Ditto.
      
      Source/WebCore:
      
          Rationalized 'this' value conversion
          https://bugs.webkit.org/show_bug.cgi?id=115542
      
      Source/WebKit/mac:
      
          Rationalized 'this' value conversion
          https://bugs.webkit.org/show_bug.cgi?id=115542
      
      Source/WebKit2:
      
          Rationalized 'this' value conversion
          https://bugs.webkit.org/show_bug.cgi?id=115542
      
      LayoutTests:
      
          Rationalized 'this' value conversion
          https://bugs.webkit.org/show_bug.cgi?id=115542
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153145 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e2fe4ceb
    • oliver@apple.com's avatar
      fourthTier: Landing the initial FTL logic in a single commit to avoid spurious · ea77149c
      oliver@apple.com authored
      broken builds.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153121 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ea77149c
  24. 26 Apr, 2013 2 commits
    • fpizlo@apple.com's avatar
      DFG doesn't support to_jsnumber · 46955911
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=115129
      
      Reviewed by Geoffrey Garen.
              
      Based on Oliver's patch. Implements to_jsnumber as Identity(Number:@thingy), and then does
      an optimization in Fixup to turn Identity(Number:) into Identity(Int32:) if the predictions
      tell us to. Identity is later turned into Phantom.
              
      Also fixed BackPropMask, which appeared to have NodeDoesNotExit included in it. That's
      wrong; NodeDoesNotExit is not a backward propagation property.
              
      Also fixed Identity to be marked as CanExit (i.e. not NodeDoesNotExit).
              
      This more than doubles the FPS on ammo.
      
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCapabilities.h:
      (JSC::DFG::canCompileOpcode):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      (FixupPhase):
      (JSC::DFG::FixupPhase::observeUseKindOnNode):
      (JSC::DFG::FixupPhase::observeUseKindOnEdge):
      * dfg/DFGNodeFlags.h:
      (DFG):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149162 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      46955911
    • oliver@apple.com's avatar
      Add support for Math.imul · 6436732a
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=115143
      
      Reviewed by Filip Pizlo.
      
      Source/JavaScriptCore:
      
      Add support for Math.imul, a thunk generator for Math.imul,
      and an intrinsic.
      
      Fairly self explanatory set of changes, DFG intrinsics simply
      leverages the existing ValueToInt32 nodes.
      
      * create_hash_table:
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::executeEffects):
      * dfg/DFGBackwardsPropagationPhase.cpp:
      (JSC::DFG::BackwardsPropagationPhase::propagate):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::handleIntrinsic):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileArithIMul):
      * dfg/DFGSpeculativeJIT.h:
      (SpeculativeJIT):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * jit/ThunkGenerators.cpp:
      (JSC::imulThunkGenerator):
      (JSC):
      * jit/ThunkGenerators.h:
      (JSC):
      * runtime/Intrinsic.h:
      * runtime/MathObject.cpp:
      (JSC):
      (JSC::mathProtoFuncIMul):
      * runtime/VM.cpp:
      (JSC::thunkGeneratorForIntrinsic):
      
      LayoutTests:
      
      Add a bunch of tests for Math.imul
      
      * fast/js/Object-getOwnPropertyNames-expected.txt:
      * fast/js/imul-expected.txt: Added.
      * fast/js/imul.html: Added.
      * fast/js/regress/imul-double-only-expected.txt: Added.
      * fast/js/regress/imul-double-only.html: Added.
      * fast/js/regress/imul-int-only-expected.txt: Added.
      * fast/js/regress/imul-int-only.html: Added.
      * fast/js/regress/imul-mixed-expected.txt: Added.
      * fast/js/regress/imul-mixed.html: Added.
      * fast/js/regress/script-tests/imul-double-only.js: Added.
      (f):
      * fast/js/regress/script-tests/imul-int-only.js: Added.
      (f):
      * fast/js/regress/script-tests/imul-mixed.js: Added.
      (f):
      * fast/js/script-tests/Object-getOwnPropertyNames.js:
      * fast/js/script-tests/imul.js: Added.
      (testIMul):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149159 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6436732a
  25. 25 Apr, 2013 1 commit
    • mark.lam@apple.com's avatar
      Add watchdog timer polling for the DFG. · 10d23a1b
      mark.lam@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=115134.
      
      Reviewed by Geoffrey Garen.
      
      The strategy is to add a speculation check to the DFG generated code to
      test if the watchdog timer has fired or not. If the watchdog timer has
      fired, the generated code will do an OSR exit to the baseline JIT, and
      let it handle servicing the watchdog timer.
      
      If the watchdog is not enabled, this speculation check will not be
      emitted.
      
      * API/tests/testapi.c:
      (currentCPUTime_callAsFunction):
      (extendTerminateCallback):
      (main):
      - removed try/catch statements so that we can test the watchdog on the DFG.
      - added JS bindings to a native currentCPUTime() function so that the timeout
        tests can be more accurate.
      - also shortened the time values so that the tests can complete sooner.
      
      * bytecode/ExitKind.h:
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNodeType.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * runtime/Watchdog.cpp:
      (JSC::Watchdog::setTimeLimit):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149089 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      10d23a1b
  26. 09 Apr, 2013 1 commit
    • commit-queue@webkit.org's avatar
      Adds fromCharCode intrinsic support. · aa31a5ed
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=104807
      
      Patch by Vahag Vardanyan <vaag@ispras.ru> on 2013-04-08
      Reviewed by Oliver Hunt.
      
      Switch to using fromCharCode intrinsic instead of call operation in some cases.
      
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::handleIntrinsic):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileFromCharCode):
      (DFG):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      (SpeculativeJIT):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * runtime/StringConstructor.cpp:
      (JSC::stringFromCharCode):
      (JSC):
      * runtime/StringConstructor.h:
      (JSC):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@147985 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      aa31a5ed
  27. 20 Mar, 2013 1 commit
    • fpizlo@apple.com's avatar
      DFG implementation of op_strcat should inline rope allocations · 4463e44f
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112780
      
      Reviewed by Oliver Hunt.
              
      This gets rid of the StrCat node and adds a MakeRope node. The MakeRope node can
      take either two or three operands, and allocates a rope string with either two or
      three fibers. (The magic choice of three children for non-VarArg nodes happens to
      match exactly with the magic choice of three fibers for rope strings.)
              
      ValueAdd on KnownString is replaced with MakeRope with two children.
              
      StrCat gets replaced by an appropriate sequence of MakeRope's.
              
      MakeRope does not do the dynamic check to see if its children are empty strings.
      This is replaced by a static check, instead. The downside is that we may use more
      memory if the strings passed to MakeRope turn out to dynamically be empty. The
      upside is that we do fewer checks in the cases where either the strings are not
      empty, or where the strings are statically known to be empty. I suspect both of
      those cases are more common, than the case where the string is dynamically empty.
              
      This also results in some badness for X86. MakeRope needs six registers if it is
      allocating a three-rope. We don't have six registers to spare on X86. Currently,
      the code side-steps this problem by just never usign three-ropes in optimized
      code on X86. All other architectures, including X86_64, don't have this problem.
              
      This is a shocking speed-up. 9% progressions on both V8/splay and
      SunSpider/date-format-xparb. 1% progression on V8v7 overall, and ~0.5% progression
      on SunSpider. 2x speed-up on microbenchmarks that test op_strcat.
      
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::executeEffects):
      * dfg/DFGAdjacencyList.h:
      (AdjacencyList):
      (JSC::DFG::AdjacencyList::removeEdge):
      * dfg/DFGArgumentsSimplificationPhase.cpp:
      (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
      * dfg/DFGBackwardsPropagationPhase.cpp:
      (JSC::DFG::BackwardsPropagationPhase::propagate):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::putStructureStoreElimination):
      (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGDCEPhase.cpp:
      (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      (JSC::DFG::FixupPhase::createToString):
      (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
      (JSC::DFG::FixupPhase::convertStringAddUse):
      (FixupPhase):
      (JSC::DFG::FixupPhase::convertToMakeRope):
      (JSC::DFG::FixupPhase::fixupMakeRope):
      (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileAdd):
      (JSC::DFG::SpeculativeJIT::compileMakeRope):
      (DFG):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      (SpeculativeJIT):
      (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
      (JSC::DFG::SpeculateCellOperand::~SpeculateCellOperand):
      (JSC::DFG::SpeculateCellOperand::gpr):
      (JSC::DFG::SpeculateCellOperand::use):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * runtime/JSString.h:
      (JSRopeString):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146382 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4463e44f