Source/JavaScriptCore/ChangeLog-2013-10-13

2013-10-13  Anders Carlsson  <andersca@apple.com>

        Try to fix the Lion build.

        * Configurations/JavaScriptCore.xcconfig:

2013-10-12  Alexey Proskuryakov  <ap@apple.com>

        Add a feature define for SubtleCrypto
        https://bugs.webkit.org/show_bug.cgi?id=122683

        Reviewed by Anders Carlsson.

        * Configurations/FeatureDefines.xcconfig:

2013-10-12  Julien Brianceau  <jbriance@cisco.com>

        Fix potential register trampling in JIT since r157313.
        https://bugs.webkit.org/show_bug.cgi?id=122691

        Reviewed by Michael Saboff.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):

2013-10-12  Julien Brianceau  <jbriance@cisco.com>

        [sh4] Add missing spaces in JITStubsSH4.h
        https://bugs.webkit.org/show_bug.cgi?id=122690

        Reviewed by Andreas Kling.

        * jit/JITStubsSH4.h: Space between string concatenation is mandatory with C++11

2013-10-12  Julien Brianceau  <jbriance@cisco.com>

        [sh4] Add missing test32 implementation in macro assembler.
        https://bugs.webkit.org/show_bug.cgi?id=122689

        Reviewed by Andreas Kling.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::test32):

2013-10-11  Darin Adler  <darin@apple.com>

        Change most call sites to call ICU directly instead of through WTF::Unicode
        https://bugs.webkit.org/show_bug.cgi?id=122635

        Reviewed by Alexey Proskuryakov.

        * parser/Lexer.cpp:
        (JSC::isNonLatin1IdentStart): Take a UChar since that's what the only caller wants to pass.
        Use U_GET_GC_MASK instead of WTF::Unicode::category.
        (JSC::isNonLatin1IdentPart): Ditto.

        * parser/Lexer.h:
        (JSC::Lexer::isWhiteSpace): Use u_charType instead of WTF::Unicode::isSeparatorSpace.

        * runtime/JSFunction.cpp: Removed "using namespace" for WTF::Unicode, this will no longer
        compile since this doesn't include anything that defines that namespace.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::isStrWhiteSpace): Use u_charType instead of WTF::Unicode::isSeparatorSpace.

        * yarr/YarrInterpreter.cpp:
        (JSC::Yarr::ByteCompiler::atomPatternCharacter): Use u_tolower and u_toupper instead of
        Unicode::toLower and Unicode::toUpper. Also added some assertions since this code assumes
        it can convert any UChar to lowercase or uppercase in another UChar, with no risk of needing
        a UChar32 for the result. I guess that's probably true, but it would be good to know in a
        debug build if not.

2013-10-11  Nadav Rotem  <nrotem@apple.com>

        DFG: Add JIT support for  LogicalNot(String/StringIdent)
        https://bugs.webkit.org/show_bug.cgi?id=122627

        Reviewed by Filip Pizlo.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileStringZeroLength):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):

2013-10-11  Filip Pizlo  <fpizlo@apple.com>

        sunspider-1.0/math-spectral-norm.js.dfg-eager occasionally fails with Trap 5 (i.e int $3)
        https://bugs.webkit.org/show_bug.cgi?id=122462

        Reviewed by Mark Hahnenberg.
        
        This fixes two bugs, both of which led to GetByVal on Int32 trapping because the
        array no longer had Int32 shape but the check wasn't executed:
        
        1) We weren't snapshotting the structures of mustHandleValues. This led to an awesome
           race where if a mustHandleValue JSValue's structure changed on the main thread
           between runs of the AI, the AI would contradict each other and things would just
           get corrupted in funny ways.
        
        2) The constant folder has a long standing bug! It will fold a node to a constant if
           the AI proved it to be a constant. But it's possible that the original node also
           proved things about the constant's structure. In that case "folding" to a
           JSConstant actually loses information since JSConstant doesn't guarantee anything
           about a constant's structure. There are various things we could do here to ensure
           that a folded constant's structure doesn't change, and that if it does, we
           deoptimize the code. But for now we can just make this sound by disabling folding
           in this pathological case.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        * dfg/DFGGraph.h:
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):

2013-10-11  Filip Pizlo  <fpizlo@apple.com>

        Fix handling of indirect stackmap locations in FTL OSR exit
        https://bugs.webkit.org/show_bug.cgi?id=122666

        Reviewed by Mark Hahnenberg.
        
        With this change, the llvm.webkit.stackmap-based OSR exit only fails one test, down from
        five tests previously.

        * ftl/FTLLocation.cpp:
        (JSC::FTL::Location::gpr): It's OK to call this method when kind() == Indirect, so asserting that isGPR() is wrong; change to assert that involvesGPR().
        (JSC::FTL::Location::restoreInto): Stack-related registers aren't saved to the scratch buffer, so use them directly.
        * ftl/FTLLocation.h: Add comment about requirements for stack layout.
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStubWithOSRExitStackmap): Make enough room on the stack so that saveAllRegisters() has a scratchpad to save things to. Without this, saveAllRegisters() may clobber a spilled value.

2013-10-11  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r157307.
        http://trac.webkit.org/changeset/157307
        https://bugs.webkit.org/show_bug.cgi?id=122671

        Many assertion failures (Requested by ap on #webkit).

        * jit/ThunkGenerators.cpp:
        (JSC::arrayIteratorNextThunkGenerator):
        * jit/ThunkGenerators.h:
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        (JSC::createIteratorResult):
        (JSC::arrayIteratorPrototypeNext):
        * runtime/Intrinsic.h:
        * runtime/JSArrayIterator.cpp:
        (JSC::JSArrayIterator::finishCreation):
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):

2013-10-11  Mark Lam  <mark.lam@apple.com>

        Transition op_new_* JITStubs to JIT operations.
        https://bugs.webkit.org/show_bug.cgi?id=122460.

        Reviewed by Michael Saboff.

        Also:
        - Removed the redundant operationNewFunctionExpression().  It is identical to
          operationNewFunctionNoCheck().
        - Sorted JIT operation signature keys in the comment in JITOperations.h.
        - Removed the unused returnValue2Register definition for X86_64.

        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitSlow_op_new_object):
        (JSC::JIT::emit_op_new_func):
        (JSC::JIT::emit_op_new_func_exp):
        (JSC::JIT::emit_op_new_array):
        (JSC::JIT::emit_op_new_array_with_size):
        (JSC::JIT::emit_op_new_array_buffer):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emitSlow_op_new_object):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITStubs.cpp:
        * jit/JITStubs.h:
        * jit/JSInterfaceJIT.h:

2013-10-11  Oliver Hunt  <oliver@apple.com>

        Separate out array iteration intrinsics
        https://bugs.webkit.org/show_bug.cgi?id=122656

        Reviewed by Michael Saboff.

        Separate out the intrinsics for key and values iteration
        of arrays.

        This requires moving moving array iteration into the iterator
        instance, rather than the prototype, but this is essentially
        unobservable so we'll live with it for now.

        * jit/ThunkGenerators.cpp:
        (JSC::arrayIteratorNextThunkGenerator):
        (JSC::arrayIteratorNextKeyThunkGenerator):
        (JSC::arrayIteratorNextValueThunkGenerator):
        * jit/ThunkGenerators.h:
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        * runtime/Intrinsic.h:
        * runtime/JSArrayIterator.cpp:
        (JSC::JSArrayIterator::finishCreation):
        (JSC::createIteratorResult):
        (JSC::arrayIteratorNext):
        (JSC::arrayIteratorNextKey):
        (JSC::arrayIteratorNextValue):
        (JSC::arrayIteratorNextGeneric):
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):

2013-10-11  Andreas Kling  <akling@apple.com>

        Pass VM instead of ExecState to JSGenericTypedArrayViewPrototype.
        <https://webkit.org/b/122632>

        Reviewed by Sam Weinig.

        This code was only using the ExecState to find the VM.

2013-10-11  Julien Brianceau  <jbriance@cisco.com>

        [sh4] Fix build after r157209.
        https://bugs.webkit.org/show_bug.cgi?id=122643

        Reviewed by Ryosuke Niwa.

        * assembler/MacroAssemblerSH4.h: Add framePointerRegister declaration.
        * assembler/SH4Assembler.h: Add firstRegister() declaration.
        (JSC::SH4Assembler::firstRegister):

2013-10-10  Filip Pizlo  <fpizlo@apple.com>

        FTL shouldn't pass i1's into llvm.webkit.stackmap's
        https://bugs.webkit.org/show_bug.cgi?id=122629
        <rdar://problem/15203037>

        Reviewed by Sam Weinig and Nadav Rotem.
        
        LLVM's stackmap support requires that we only pass operands with legal types (i.e. types
        that are hardware-representable). i1, which the FTL previously used for Booleans, is not
        legal.
        
        We have two options: either add support in LLVM to legalize stackmap operands, or add
        support to the FTL to legalize stackmap operands. It's easier to fix this in FTL, and
        that's what this patch does.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):

2013-10-09  Oliver Hunt  <oliver@apple.com>

        Further improve ArrayIterator performance
        https://bugs.webkit.org/show_bug.cgi?id=122575

        Reviewed by Mark Hahnenberg.

        Add an assembly thunk for ArrayIterator.@@next so that we
        can avoid marshalling costs when iterating arrays.

        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        (JSC::SpecializedThunkJIT::loadSpecificClassArgument):
        * jit/ThunkGenerators.cpp:
        (JSC::arrayIteratorNextThunkGenerator):
        * jit/ThunkGenerators.h:
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        * runtime/Intrinsic.h:
        * runtime/JSArrayIterator.h:
        (JSC::JSArrayIterator::offsetOfIterationKind):
        (JSC::JSArrayIterator::offsetOfIteratedObject):
        (JSC::JSArrayIterator::offsetOfNextIndex):
        * runtime/JSCJSValue.h:
        (JSC::JSValue::offsetOfPayload):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::iteratorResultStructureOffset):
        * runtime/VM.cpp:
        (JSC::thunkGeneratorForIntrinsic):

2013-10-10  Michael Saboff  <msaboff@apple.com>

        transition cti_op_* methods returning int to JIT operations.
        https://bugs.webkit.org/show_bug.cgi?id=122563

        Reviewed by Oliver Hunt.

        Moved serveral operationCompare* functions from DFGOperations to JITOperations as well as changing
        dfgConvertJSValueToBoolean to operationConvertJSValueToBoolean so that they can be shared with the baseline JIT.
        Added JITOperation operationHasProperty().  Added needed callOperation helpers and transitioned baseline JIT code
        to use the new operations.
        
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitSlow_op_jless):
        (JSC::JIT::emitSlow_op_jlesseq):
        (JSC::JIT::emitSlow_op_jgreater):
        (JSC::JIT::emitSlow_op_jgreatereq):
        (JSC::JIT::emitSlow_op_jnless):
        (JSC::JIT::emitSlow_op_jnlesseq):
        (JSC::JIT::emitSlow_op_jngreater):
        (JSC::JIT::emitSlow_op_jngreatereq):
        (JSC::JIT::emit_compareAndJumpSlow):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_compareAndJumpSlow):
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_next_pname):
        (JSC::JIT::emitSlow_op_jfalse):
        (JSC::JIT::emitSlow_op_jtrue):
        (JSC::JIT::emitSlow_op_eq):
        (JSC::JIT::emitSlow_op_neq):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emitSlow_op_jfalse):
        (JSC::JIT::emitSlow_op_jtrue):
        (JSC::JIT::emitSlow_op_eq):
        (JSC::JIT::emitSlow_op_neq):
        (JSC::JIT::emit_op_next_pname):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITStubs.cpp:
        * jit/JITStubs.h:

2013-10-10  Filip Pizlo  <fpizlo@apple.com>

        OSR exit using llvm.webkit.stackmap should pass more tests
        https://bugs.webkit.org/show_bug.cgi?id=122518

        Reviewed by Mark Hahnenberg.
        
        - Make the X86Assembler capable of dealing with all XMM registers.
        
        - Make the StackMaps code on WebKit's side capable of dealing with XMM registers.
        
        - Factor out most of the smarts of StackMaps::Location into a self-contained object.
          Previously you needed both StackMaps::Location and a StackMaps reference to do most
          things since the Location might have referred to a constant. Now you can just get a
          self-contained Location object.
        
        - Fix a bug where OSR exit generation thunk generator was assuming that the call frame
          register is already in argumentGPR0. In the future, the call frame will just be the
          machine FP and we won't have to do anything special. But for now the "call frame" is
          just a normal value in LLVM IR and may end up in any register. Make the OSR exit
          generation thunk generator polymorphic over the call frame argument's Location.
        
        - Move the stuff that depends on the polymorphic OSR exit generation thunk generator
          into the finalizer, since generating and linking one of those thunks requires a cache
          flush and we need to do that on the main thread.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::firstRegister):
        (JSC::ARMv7Assembler::lastRegister):
        (JSC::ARMv7Assembler::firstFPRegister):
        (JSC::ARMv7Assembler::lastFPRegister):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::firstFPRegister):
        (JSC::AbstractMacroAssembler::lastFPRegister):
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::nextFPRegister):
        * assembler/MacroAssemblerARMv7.h:
        * assembler/MacroAssemblerX86Common.h:
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::firstFPRegister):
        (JSC::X86Assembler::lastFPRegister):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::fixFunctionBasedOnStackMaps):
        * ftl/FTLExitThunkGenerator.cpp:
        (JSC::FTL::ExitThunkGenerator::emitThunk):
        (JSC::FTL::ExitThunkGenerator::emitThunks):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h:
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLocation.cpp: Added.
        (JSC::FTL::Location::forStackmaps):
        (JSC::FTL::Location::dump):
        (JSC::FTL::Location::involvesGPR):
        (JSC::FTL::Location::isGPR):
        (JSC::FTL::Location::gpr):
        (JSC::FTL::Location::isFPR):
        (JSC::FTL::Location::fpr):
        (JSC::FTL::Location::restoreInto):
        (WTF::printInternal):
        * ftl/FTLLocation.h: Added.
        (JSC::FTL::Location::Location):
        (JSC::FTL::Location::forRegister):
        (JSC::FTL::Location::forIndirect):
        (JSC::FTL::Location::forConstant):
        (JSC::FTL::Location::kind):
        (JSC::FTL::Location::hasDwarfRegNum):
        (JSC::FTL::Location::dwarfRegNum):
        (JSC::FTL::Location::hasOffset):
        (JSC::FTL::Location::offset):
        (JSC::FTL::Location::hasConstant):
        (JSC::FTL::Location::constant):
        (JSC::FTL::Location::operator!):
        (JSC::FTL::Location::isHashTableDeletedValue):
        (JSC::FTL::Location::operator==):
        (JSC::FTL::Location::hash):
        (JSC::FTL::LocationHash::hash):
        (JSC::FTL::LocationHash::equal):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
        * ftl/FTLSaveRestore.cpp:
        (JSC::FTL::bytesForFPRs):
        (JSC::FTL::requiredScratchMemorySizeInBytes):
        (JSC::FTL::offsetOfFPR):
        (JSC::FTL::saveAllRegisters):
        (JSC::FTL::restoreAllRegisters):
        * ftl/FTLSaveRestore.h:
        * ftl/FTLStackMaps.cpp:
        (JSC::FTL::StackMaps::Location::restoreInto):
        * ftl/FTLStackMaps.h:
        * ftl/FTLState.h:
        * ftl/FTLThunks.cpp:
        (JSC::FTL::osrExitGenerationWithoutStackMapThunkGenerator):
        (JSC::FTL::osrExitGenerationWithStackMapThunkGenerator):
        * ftl/FTLThunks.h:
        (JSC::FTL::generateIfNecessary):
        (JSC::FTL::Thunks::getOSRExitGenerationThunk):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2013-10-09  Filip Pizlo  <fpizlo@apple.com>

        FTL: Soft-link LLVM as a workaround for LLVM's static initializers and exit-time destructors
        https://bugs.webkit.org/show_bug.cgi?id=122566

        Reviewed by Mark Rowe.
        
        The JSC project now builds a libllvmForJSC.dylib. If FTL is enabled, this
        gets copied into JavaScriptCore.framework/Versions/A/Libraries. JSC will
        load the dylib by finding it using NSBundle APIs and then doing dlopen().
        That will only happen lazily, when something happens that requires LLVM.
        
        This mostly takes care of LLVM static initialization overhead by deferring
        it until it's really needed.
        
        This takes care of LLVM's exit-time destructors because inside
        libllvmForJSC.dylib, we override __cxa_atexit.
        
        * Configurations/JavaScriptCore.xcconfig:
        * Configurations/LLVMForJSC.xcconfig: Added.
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * disassembler/LLVMDisassembler.cpp:
        (JSC::tryToDisassembleWithLLVM):
        * ftl/FTLAbbreviatedTypes.h:
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::voidType):
        (JSC::FTL::int1Type):
        (JSC::FTL::int8Type):
        (JSC::FTL::int16Type):
        (JSC::FTL::int32Type):
        (JSC::FTL::int64Type):
        (JSC::FTL::intPtrType):
        (JSC::FTL::floatType):
        (JSC::FTL::doubleType):
        (JSC::FTL::pointerType):
        (JSC::FTL::structType):
        (JSC::FTL::functionType):
        (JSC::FTL::typeOf):
        (JSC::FTL::mdKindID):
        (JSC::FTL::mdString):
        (JSC::FTL::mdNode):
        (JSC::FTL::setMetadata):
        (JSC::FTL::addFunction):
        (JSC::FTL::setLinkage):
        (JSC::FTL::setFunctionCallingConv):
        (JSC::FTL::getParam):
        (JSC::FTL::constInt):
        (JSC::FTL::constReal):
        (JSC::FTL::constIntToPtr):
        (JSC::FTL::constBitCast):
        (JSC::FTL::appendBasicBlock):
        (JSC::FTL::insertBasicBlock):
        (JSC::FTL::buildPhi):
        (JSC::FTL::addIncoming):
        (JSC::FTL::buildAlloca):
        (JSC::FTL::buildAdd):
        (JSC::FTL::buildSub):
        (JSC::FTL::buildMul):
        (JSC::FTL::buildDiv):
        (JSC::FTL::buildRem):
        (JSC::FTL::buildNeg):
        (JSC::FTL::buildFAdd):
        (JSC::FTL::buildFSub):
        (JSC::FTL::buildFMul):
        (JSC::FTL::buildFDiv):
        (JSC::FTL::buildFRem):
        (JSC::FTL::buildFNeg):
        (JSC::FTL::buildAnd):
        (JSC::FTL::buildOr):
        (JSC::FTL::buildXor):
        (JSC::FTL::buildShl):
        (JSC::FTL::buildAShr):
        (JSC::FTL::buildLShr):
        (JSC::FTL::buildNot):
        (JSC::FTL::buildLoad):
        (JSC::FTL::buildStore):
        (JSC::FTL::buildSExt):
        (JSC::FTL::buildZExt):
        (JSC::FTL::buildFPToSI):
        (JSC::FTL::buildFPToUI):
        (JSC::FTL::buildSIToFP):
        (JSC::FTL::buildUIToFP):
        (JSC::FTL::buildIntCast):
        (JSC::FTL::buildFPCast):
        (JSC::FTL::buildIntToPtr):
        (JSC::FTL::buildPtrToInt):
        (JSC::FTL::buildBitCast):
        (JSC::FTL::buildICmp):
        (JSC::FTL::buildFCmp):
        (JSC::FTL::buildCall):
        (JSC::FTL::setTailCall):
        (JSC::FTL::buildExtractValue):
        (JSC::FTL::buildSelect):
        (JSC::FTL::buildBr):
        (JSC::FTL::buildCondBr):
        (JSC::FTL::buildSwitch):
        (JSC::FTL::addCase):
        (JSC::FTL::buildRet):
        (JSC::FTL::buildUnreachable):
        (JSC::FTL::dumpModule):
        (JSC::FTL::verifyModule):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLFail.cpp:
        (JSC::FTL::fail):
        * ftl/FTLJITCode.h:
        * ftl/FTLJITFinalizer.h:
        * ftl/FTLLink.cpp:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::Output):
        (JSC::FTL::Output::~Output):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::appendTo):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        (JSC::FTL::State::~State):
        * ftl/WebKitLLVMLibraryAnchor.cpp: Removed.
        * jsc.cpp:
        (jscmain):
        * llvm: Added.
        * llvm/InitializeLLVM.cpp: Added.
        (JSC::initializeLLVM):
        * llvm/InitializeLLVM.h: Added.
        * llvm/InitializeLLVMMac.mm: Added.
        (JSC::initializeLLVMImpl):
        * llvm/InitializeLLVMPOSIX.cpp: Added.
        (JSC::initializeLLVMPOSIX):
        * llvm/InitializeLLVMPOSIX.h: Added.
        * llvm/LLVMAPI.cpp: Added.
        * llvm/LLVMAPI.h: Added.
        * llvm/LLVMAPIFunctions.h: Added.
        * llvm/LLVMHeaders.h: Added.
        * llvm/library: Added.
        * llvm/library/LLVMAnchor.cpp: Added.
        * llvm/library/LLVMExports.cpp: Added.
        (initializeAndGetJSCLLVMAPI):
        * llvm/library/LLVMOverrides.cpp: Added.
        (__cxa_atexit):
        * llvm/library/config_llvm.h: Added.
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreadingOnce):
        * runtime/Options.h:

2013-10-10  Mark Hahnenberg  <mhahnenberg@apple.com>

        currentThis and currentArguments crash if called from outside a callback
        https://bugs.webkit.org/show_bug.cgi?id=122620

        Reviewed by Filip Pizlo.

        The documentation for these methods claims that they will return nil if called 
        from somewhere other than an API callback, but currently they both crash.

        * API/JSContext.mm:
        (+[JSContext currentThis]):
        (+[JSContext currentArguments]):
        * API/tests/testapi.mm:

2013-10-10  Filip Pizlo  <fpizlo@apple.com>

        Minor clean-ups in the JSC Xcode project.

        Rubber stamped by Mark Rowe.
        
        - When we copy the jsc binary into the framework,
          $(BUILT_PRODUCTS_DIR)/JavaScriptCore.framework/Resources/jsc is the *output* file not
          the input file. The input file is $(BUILT_PRODUCTS_DIR)/jsc.
        
        - Correct capitalization of "JavaScriptcore.framework" in a comment in a shell script in
          the project.
        
        Roll back in after confirming that Mark's fixes make this work right.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2013-10-10  Mark Hahnenberg  <mhahnenberg@apple.com>

        CallbackData unnecessarily caches the JSValue for currentThis
        https://bugs.webkit.org/show_bug.cgi?id=122616

        Reviewed by Oliver Hunt.

        CallbackData implements its own version of caching the JSValue* for the JSValueRef it stores. 
        +[JSValue valueWithJSValueRef:inContext:] already does caching, thus obviating the need for 
        CallbackData to do its own caching.

        * API/JSContext.mm:
        (+[JSContext currentThis]):
        (-[JSContext beginCallbackWithData:thisValue:argumentCount:arguments:]):
        (-[JSContext endCallbackWithData:]):
        * API/JSContextInternal.h:

2013-10-10  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, roll out r157193. It broke some builds.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2013-10-10  Mark Rowe  <mrowe@apple.com>

        <rdar://problem/13341666> WebKit should always build against an SDK.

        Have all projects default to building against the OS X Internal SDK for the Production
        configuration. For the Debug and Release configurations, look for UseInternalSDK.xcconfig
        to determine whether the OS X Internal SDK should be used. If not, use the normal OS X SDK.

        Reviewed by Dan Bernstein.

        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:

2013-10-10  Mark Rowe  <mrowe@apple.com>

        <rdar://problem/13871507> JavaScriptCore fails to build with C++ 98 conformance changes

        Reviewed by Andreas Kling.

        * heap/VTableSpectrum.cpp:
        (JSC::VTableSpectrum::dump): strrchr returns a const char* when passed one.
        Update the type of the local variable to accommodate that.

2013-10-10  Mark Hahnenberg  <mhahnenberg@apple.com>

        Objective-C API: blocks aren't callable via 'new'
        https://bugs.webkit.org/show_bug.cgi?id=122561

        Reviewed by Oliver Hunt.

        Currently the only way for clients to vend new native objects to JavaScript code 
        is via factory methods in the form of exported class methods or blocks. Blocks can 
        be called like normal functions from JavaScript code, but they cannot be invoked 
        with 'new'. This would give a simple way for clients to expose constructor-like 
        behavior to their JavaScript code.

        This patch adds the ability for blocks to be invoked as if they were a constructor.
        Blocks invoked as constructors are required to return an object. If the block doesn't
        return an object then an error is thrown. The 'this' object is not provided to the 
        block and must be created within the block itself. 

        This patch also unifies the native 'construct' callback used in both the C and Obj-C
        APIs under the APICallbackFunction struct, similar to how we unified the 'call' callback
        between ObjCCallbackFunction and JSCallbackFunction before.

        This patch also adds tests to make sure that different blocks generate objects that
        correctly behave when queried with instanceof. It also makes sure that the correct 
        JS exception is thrown when a block fails to return an object.

        * API/APICallbackFunction.h:
        (JSC::APICallbackFunction::call):
        (JSC::APICallbackFunction::construct):
        * API/JSCallbackConstructor.cpp:
        (JSC::JSCallbackConstructor::getConstructData):
        * API/JSCallbackConstructor.h:
        (JSC::JSCallbackConstructor::constructCallback):
        * API/JSCallbackFunction.h:
        (JSC::JSCallbackFunction::functionCallback):
        * API/ObjCCallbackFunction.h:
        (JSC::ObjCCallbackFunction::functionCallback):
        (JSC::ObjCCallbackFunction::constructCallback):
        * API/ObjCCallbackFunction.mm:
        (JSC::objCCallbackFunctionCallAsConstructor):
        (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
        (JSC::ObjCCallbackFunction::create):
        (JSC::ObjCCallbackFunction::getConstructData):
        * API/tests/testapi.mm:

2013-10-08  Filip Pizlo  <fpizlo@apple.com>

        FTL should be able to do simple OSR exits using llvm.webkit.stackmap
        https://bugs.webkit.org/show_bug.cgi?id=122538

        Reviewed by Oliver Hunt.
        
        This gives the FTL the ability to OSR exit using the llvm.webkit.stackmap intrinsic.
        
        - The FTL compiles all OSR exit calls as calls to llvm.webkit.stackmap with a unique
          ID, passing a requested size that is big enough for own jump replacement.
        
        - After LLVM compilation, we parse the new LLVM stackmap section.
        
        - For all llvm.webkit.stackmaps that we used for OSR exits, we do a jumpReplacement,
          which targets exit thunks that we generate.
        
        - If an exit thunk fires, it causes JSC to compile an exit off-ramp that uses a
          combination of the JSC-internal OSR exit accounting (FTL::ExitValue and friends) and
          LLVM stackmap's accounting of where data actually ended up (register, indirect,
          constant) to reconstruct bytecode state.
        
        This still has shortcomings; for example it cannot handle XMM or YMM registers. Handling
        YMM registers will require adding some basic YMM support to our assemblers - really we
        just need the ability to move a YMM's value into a GPR.
        
        This patch preserves all of the old, intrinsic-less, FTL OSR exit support. Hence it
        manages to pass all existing FTL tests even despite its incompleteness. I think that's
        the right way to go since this is already a big patch, and anyway it would be great to
        keep the intrinsic-less FTL OSR exit support so long as the LLVM side of this hasn't
        landed.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::firstRegister):
        (JSC::AbstractMacroAssembler::lastRegister):
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::isStackRelated):
        (JSC::MacroAssembler::firstRealRegister):
        (JSC::MacroAssembler::nextRegister):
        (JSC::MacroAssembler::secondRealRegister):
        * assembler/MacroAssemblerX86Common.h:
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::firstRegister):
        (JSC::X86Assembler::lastRegister):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * ftl/FTLCArgumentGetter.cpp:
        (JSC::FTL::CArgumentGetter::loadNextAndBox):
        * ftl/FTLCArgumentGetter.h:
        (JSC::FTL::CArgumentGetter::loadNextDoubleIntoGPR):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateCodeSection):
        (JSC::FTL::mmAllocateDataSection):
        (JSC::FTL::dumpDataSection):
        (JSC::FTL::fixFunctionBasedOnStackMaps):
        (JSC::FTL::compile):
        * ftl/FTLExitThunkGenerator.cpp:
        (JSC::FTL::ExitThunkGenerator::emitThunk):
        (JSC::FTL::ExitThunkGenerator::emitThunks):
        * ftl/FTLExitThunkGenerator.h:
        * ftl/FTLExitValue.h:
        (JSC::FTL::ExitValue::isInJSStackSomehow):
        (JSC::FTL::ExitValue::valueFormat):
        * ftl/FTLFail.cpp:
        (JSC::FTL::fail):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLJITCode.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::generateExitThunks):
        (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
        (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
        * ftl/FTLOSRExit.h:
        * ftl/FTLOSRExitCompilationInfo.h:
        (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStubWithOSRExitStackmap):
        (JSC::FTL::compileStubWithoutOSRExitStackmap):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLSaveRestore.cpp: Added.
        (JSC::FTL::bytesForGPRs):
        (JSC::FTL::requiredScratchMemorySizeInBytes):
        (JSC::FTL::offsetOfGPR):
        (JSC::FTL::saveAllRegisters):
        (JSC::FTL::restoreAllRegisters):
        * ftl/FTLSaveRestore.h: Added.
        * ftl/FTLStackMaps.cpp: Added.
        (JSC::FTL::readObject):
        (JSC::FTL::StackMaps::Constant::parse):
        (JSC::FTL::StackMaps::Constant::dump):
        (JSC::FTL::StackMaps::Location::parse):
        (JSC::FTL::StackMaps::Location::dump):
        (JSC::FTL::StackMaps::Location::involvesGPR):
        (JSC::FTL::StackMaps::Location::isGPR):
        (JSC::FTL::StackMaps::Location::gpr):
        (JSC::FTL::StackMaps::Location::restoreInto):
        (JSC::FTL::StackMaps::Record::parse):
        (JSC::FTL::StackMaps::Record::dump):
        (JSC::FTL::StackMaps::parse):
        (JSC::FTL::StackMaps::dump):
        (JSC::FTL::StackMaps::dumpMultiline):
        (JSC::FTL::StackMaps::getRecordMap):
        (WTF::printInternal):
        * ftl/FTLStackMaps.h: Added.
        * ftl/FTLState.h:
        * ftl/FTLThunks.cpp:
        (JSC::FTL::osrExitGenerationThunkGenerator):
        * ftl/FTLValueFormat.cpp:
        (JSC::FTL::reboxAccordingToFormat):
        * ftl/FTLValueFormat.h:
        * runtime/DataView.cpp:
        (JSC::DataView::create):
        * runtime/DataView.h:
        (JSC::DataView::read):
        * runtime/Options.h:

2013-10-09  Filip Pizlo  <fpizlo@apple.com>

        Minor clean-ups in the JSC Xcode project.

        Rubber stamped by Mark Rowe.
        
        - When we copy the jsc binary into the framework,
          $(BUILT_PRODUCTS_DIR)/JavaScriptCore.framework/Resources/jsc is the *output* file not
          the input file. The input file is $(BUILT_PRODUCTS_DIR)/jsc.
        
        - Correct capitalization of "JavaScriptcore.framework" in a comment in a shell script in
          the project.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2013-10-09  Julien Brianceau  <jbriance@cisco.com>

        [arm] Inverted src and dest FP registers in DFG speculative JIT when using hardfp.
        https://bugs.webkit.org/show_bug.cgi?id=122555

        Reviewed by Michael Saboff.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult):
        (JSC::DFG::SpeculativeJIT::appendCallSetResult):

2013-10-08  Michael Saboff  <msaboff@apple.com>

        Transition call and construct JITStubs to CCallHelper functions
        https://bugs.webkit.org/show_bug.cgi?id=122453

        Reviewed by Geoffrey Garen.

        Transitioned cti_op_call_eval to operationCallEval.  Migrated baseline JIT to use the same 
        call thunks as the DFG.  Eliminated all of the "oldStyle" thunks and related functions.

        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::unlink):
        * jit/JIT.cpp:
        (JSC::JIT::linkFor):
        (JSC::JIT::linkSlowCall):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::privateCompileClosureCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::privateCompileClosureCall):
        * jit/JITInlines.h:
        (JSC::JIT::callOperationWithCallFrameRollbackOnException):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITStubs.cpp:
        * jit/JITStubs.h:
        * jit/ThunkGenerators.cpp:
        * jit/ThunkGenerators.h:

2013-10-09  Julien Brianceau  <jbriance@cisco.com>

        [sh4] Fix lots of unused parameter warnings.
        https://bugs.webkit.org/show_bug.cgi?id=122545

        Reviewed by Csaba Osztrogonác.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::revertJumpReplacementToPatchableBranchPtrWithPatch):
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::andlImm8r):
        (JSC::SH4Assembler::orlImm8r):
        (JSC::SH4Assembler::xorlImm8r):
        (JSC::SH4Assembler::cmpEqImmR0):
        (JSC::SH4Assembler::testlImm8r):
        (JSC::SH4Assembler::movwPCReg):
        (JSC::SH4Assembler::movwMemReg):
        (JSC::SH4Assembler::movbMemReg):
        (JSC::SH4Assembler::printInstr):
        (JSC::SH4Assembler::printBlockInstr):

2013-10-09  Julien Brianceau  <jbriance@cisco.com>

        [sh4] Add sh4 support when building with CMake.
        https://bugs.webkit.org/show_bug.cgi?id=122542

        Reviewed by Csaba Osztrogonác.

        * CMakeLists.txt:

2013-10-08  Oliver Hunt  <oliver@apple.com>

        Convert for-of iteration to in-band signalling so we can trivially avoid unnecessary object allocation
        https://bugs.webkit.org/show_bug.cgi?id=122532

        Reviewed by Michael Saboff.

        Switch for-of enumeration to use in band signalling to determine the end
        of iteration.  This allows us to trivially remove an otherwise unnecessary
        object allocation, and paves the way for optimised thunks in future.

        We can re-add explicit .next() functions in future that would marshall
        the true iteration functions, but for now we'll ignore them.

        This results in a huge improvement in the performance of for-of (in the order
        of 2x) but there's still a long way to go in order to get the performance to
        a satisfactory level.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForOfNode::emitBytecode):
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        (JSC::createIteratorResult):
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers):
        * runtime/CommonIdentifiers.h:
        * runtime/Identifier.cpp:
        (JSC::Identifier::addSlowCase):
        * runtime/JSObject.h:
        (JSC::JSFinalObject::create):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2013-10-08  Alex Christensen  <achristensen@webkit.org>

        Fixed compile errors while compiling without the JIT enabled.
        https://bugs.webkit.org/show_bug.cgi?id=122530

        Reviewed by Brent Fulgham.

        * jit/JITOperations.cpp:
        Protected with #if ENABLE(JIT) like the rest of the JIT source.

2013-10-07  Mark Hahnenberg  <mhahnenberg@apple.com>

        JSManagedValue should be able to store non-object JSValues
        https://bugs.webkit.org/show_bug.cgi?id=122351

        Reviewed by Oliver Hunt.

        We decided not to support this because we thought it didn't make sense to have a 
        "weak" JSValue that wasn't an object.

        Our general thought process was if you have a JSObject-ObjC object pair (i.e. an 
        Obj-C object that you exported to JavaScript-land), it makes more sense to store 
        a non-object JSValue on the JavaScript-land version of the object rather than as 
        an ivar in the Objective-C object.

        In retrospect, this may not have been a good decision at least w.r.t. consistency 
        in client code. If you're storing a bag of JSValues off an Obj-C object, you'd 
        like to store all of them either in ObjC-land or JavaScript-land, but doing some 
        in one and some in the other doesn't sound too good. Also, what if the object you 
        want to hang these values off of doesn't have a corresponding object in JavaScript-
        land in which to store them?

        The solution is to fix JSManagedValue to be able to reference non-object JSValues. 
        Right now, all JSManagedValues contain a Weak<JSObject>. We'll change this so that
        they can contain either a non-cell JSValue or a JSObject*, along with a weak 
        reference to the JSGlobalObject for reconstructing a JSValue later on.

        * API/JSManagedValue.mm:
        (PrimitiveOrObject::PrimitiveOrObject):
        (PrimitiveOrObject::~PrimitiveOrObject):
        (PrimitiveOrObject::clear):
        (PrimitiveOrObject::isClear):
        (PrimitiveOrObject::isSet):
        (PrimitiveOrObject::isPrimitive):
        (PrimitiveOrObject::isObject):
        (PrimitiveOrObject::setPrimitive):
        (PrimitiveOrObject::setObject):
        (PrimitiveOrObject::object):
        (PrimitiveOrObject::primitive):
        (-[JSManagedValue initWithValue:]):
        (-[JSManagedValue value]):
        (-[JSManagedValue disconnectValue]):

2013-10-08  Robert Plociennik  <r.plociennik@samsung.com>

        JavaScriptCore fails to build
        https://bugs.webkit.org/show_bug.cgi?id=122440

        Reviewed by Darin Adler.

        Compilation fails in debug due to 'comparison of unsigned expression >= 0 is
        always true'.

        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::positionForCallFrame): Removed the offending ASSERTS.

2013-10-07  Andreas Kling  <akling@apple.com>

        Pass VM instead of ExecState to JSNotAnObject constructor.
        <https://webkit.org/b/122474>

        Reviewed by Sam Weinig.

        JSNotAnObject was only using the ExecState to find the VM.

2013-10-07  Filip Pizlo  <fpizlo@apple.com>

        FTL memory allocator should be able to allocate data sections in non-executable memory
        https://bugs.webkit.org/show_bug.cgi?id=116189

        Reviewed by Sam Weinig.
        
        Use a RefCountedArray<int64_t> for data sections. This works out great because
        RefCountedArray<> knows its own size and because the reference counting makes passing
        it around very easy (you don't have to stress out about ownership).

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        (JSC::FTL::compile):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::addDataSection):
        * ftl/FTLJITCode.h:
        (JSC::FTL::JITCode::dataSections):

2013-10-07  Roger Fong  <roger_fong@apple.com>

        Modify JavascriptCore makefile for x64 build.
        https://bugs.webkit.org/show_bug.cgi?id=122467.
        <rdar://problem/15169174>.

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.make:

2013-10-07  Nadav Rotem  <nrotem@apple.com>

        FTL: Optimize IsString(@2<String>) -> JSConst(true) + Phantom()
        https://bugs.webkit.org/show_bug.cgi?id=122363

        Reviewed by Filip Pizlo.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2013-10-04  Michael Saboff  <msaboff@apple.com>

        Transition stack check JITStubs to CCallHelper functions
        https://bugs.webkit.org/show_bug.cgi?id=122289

        Reviewed by Filip Pizlo.

        Replaced jit stubs cti_stack_check, cti_op_call_arityCheck and cti_op_construct_arityCheck with
        jit operations operationStackCheck, operationCallArityCheck & operationConstructArityCheck.
        Added new callOperationWithCallFrameRollbackOnException() in baseline and DFG JITs to call
        these new functions.  Added code to unwind one frame in JIT::privateCompileExceptionHandlers() 
        and JITCompiler::compileExceptionHandlers() for these cases that need to throw exceptions in
        their caller frame when the stack is exhausted.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::andPtr): Added to handle masking a pointer with a literal.
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::and64): Added to handle masking a pointer with a literal.
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileExceptionHandlers):
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::linkFunction):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperationWithCallFrameRollbackOnException):
        (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck):
        (JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnException):
        (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult):
        (JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnExceptionSetResult):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * interpreter/CallFrame.h:
        (JSC::ExecState::hostCallFrameFlag):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::jitAssertIsNull):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::jitAssertIsNull):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JIT.h:
        (JSC::JIT::exceptionCheckWithCallFrameRollback):
        * jit/JITInlines.h:
        (JSC::JIT::appendCallWithCallFrameRollbackOnException):
        (JSC::JIT::callOperationWithCallFrameRollbackOnException):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITStubs.cpp:
        * jit/JITStubs.h:

2013-10-07  Filip Pizlo  <fpizlo@apple.com>

        ASSERTION FAILED: isUInt32() in jsc-layout-tests.yaml/js/script-tests/dfg-uint32-to-number-in-middle-of-copy-propagation.js.layout-dfg-eager-no-cjit
        https://bugs.webkit.org/show_bug.cgi?id=122419

        Reviewed by Oliver Hunt.
        
        AI was using JSValue::asUInt32() incorrectly. That method presumes that the input is
        both a int32 and a uint32 (it's in the range [0, 2^31)). The UInt32ToNumber node is
        instead dealing with an input that is always represented as a int32 but that has the
        meaning of a uint32 - so AI should use JSValue::asInt32() and then do the cast.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):

2013-10-07  Julien Brianceau  <jbriance@cisco.com>

        [sh4] Jump over maxJumpReplacementSize in revertJumpToMove.
        https://bugs.webkit.org/show_bug.cgi?id=120007

        Reviewed by Oliver Hunt.

        Jump over maxJumpReplacementSize in revertJumpToMove, even if there is no constant
        value within the area. This patch fixes debug ASSERTs failures for sh4 architecture.

        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::revertJumpToMove):

2013-10-06  Anders Carlsson  <andersca@apple.com>

        Add OVERRIDE and virtual where appropriate
        https://bugs.webkit.org/show_bug.cgi?id=122439

        Reviewed by Antti Koivisto.

        * API/JSAPIWrapperObject.mm:
        * API/JSCallbackObject.h:
        (JSC::JSCallbackObjectData::~JSCallbackObjectData):
        * API/JSManagedValue.mm:
        * API/JSScriptRef.cpp:
        (OpaqueJSScript::~OpaqueJSScript):
        * bytecode/CodeBlock.h:
        * bytecode/StructureStubClearingWatchpoint.h:
        * dfg/DFGArrayifySlowPathGenerator.h:
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        * dfg/DFGFailedFinalizer.h:
        * dfg/DFGJITCode.h:
        * dfg/DFGJITFinalizer.h:
        * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
        * dfg/DFGSlowPathGenerator.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        * heap/Heap.h:
        * heap/IncrementalSweeper.h:
        * heap/SuperRegion.h:
        * jit/ClosureCallStubRoutine.h:
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        * jit/GCAwareJITStubRoutine.h:
        * jit/JITCode.h:
        * jit/JITStubs.cpp:
        * jit/JITToDFGDeferredCompilationCallback.h:
        * jit/JumpReplacementWatchpoint.h:
        * parser/Nodes.h:
        * runtime/DataView.h:
        * runtime/GCActivityCallback.h:
        * runtime/GenericTypedArrayView.h:
        * runtime/RegExpCache.h:
        * runtime/SimpleTypedArrayController.h:
        * runtime/WeakMapData.h:

2013-10-07  Filip Pizlo  <fpizlo@apple.com>

        Trap 5 (most likely int $3) in jsc-layout-tests.yaml/js/script-tests/integer-division-neg2tothe32-by-neg1.js.layout-dfg-eager-no-cjit
        https://bugs.webkit.org/show_bug.cgi?id=122420

        Reviewed by Michael Saboff.
        
        For the (-2^31/-1)|0 case, we were returning the left operand (i.e. -2^31) but we were
        failing to account for the possibility that this operand has high-bit garbage and
        int32Result() requires that the high bits are zero.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithDiv):

2013-10-06  Filip Pizlo  <fpizlo@apple.com>

        ASSERTION FAILED: bitwise_cast<WriteBarrier<Unknown>*>(callFrame) == m_registers in jsc-layout-tests.yaml/js/script-tests/dfg-inline-arguments-capture-throw-exception.js.layout-dfg-eager-no-cjit
        https://bugs.webkit.org/show_bug.cgi?id=122418

        Reviewed by Oliver Hunt.

        This is pretty awesome. With stack compression, Arguments created in the DFG will point
        their m_registers pointers into a different slab of stack than they would have in byte
        code.

        Hence OSR exit must repoint any Arguments objects' m_registers pointers. It previously
        neglected to do so. This patch fixes that.
        
        Fixing this unveiled another bug: the stack reversal broke the reification of inlined
        phantom arguments.
        
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/Arguments.h:
        (JSC::Arguments::offsetOfNumArguments):
        (JSC::Arguments::offsetOfRegisters):
        (JSC::Arguments::offsetOfSlowArgumentData):
        (JSC::Arguments::offsetOfOverrodeLength):

2013-10-06  Filip Pizlo  <fpizlo@apple.com>

        Unified test infrastructure via the jsc shell
        https://bugs.webkit.org/show_bug.cgi?id=120696

        Reviewed by Oliver Hunt.
        
        Add a mozilla-tests.yaml list. This is autogenerated by create-mozilla-js-test-list.
        I think it's better to leave this checked in; we may even just edit it directly in
        the future. Also generating it is not cheap.
        
        Fix some low-hanging fruit bugs that I caught by introducing more test coverage.
        
        - We were not emitting labels for CFA-unreachable blocks, which caused link errors.
          It's possible for a CFA-unreachable block to be jumped to, if the thing that causes
          it to be unreachable is a speculation in a Branch or peephole compare.
        
        - The register allocation assertions didn't handle peephole branches correctly. Since
          the peephole branch handling returns early from compile(), the clearBlahbittyBlah()
          method wasn't being called.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * tests/mozilla/mozilla-tests.yaml: Added.

2013-10-05  Andreas Kling  <akling@apple.com>

        Pass VM instead of ExecState to StringObject constructor.
        <https://webkit.org/b/122395>

        Reviewed by Sam Weinig.

        StringObject() only uses the ExecState to find the VM.

2013-10-05  Filip Pizlo  <fpizlo@apple.com>

        Compress DFG stack layout
        https://bugs.webkit.org/show_bug.cgi?id=122024

        Reviewed by Oliver Hunt.
        
        The DFG needs to be able to store things at a known offset from frame pointer so that
        the runtime can read those things. Prior to this patch, the DFG would use the exact
        offsets that the bytecode asked for, even in the case of inlining, where it would use
        the callsite stack offset to shift all of the inlined function's variables over just as
        they would have been if a bytecode interpreter had really made the call.
        
        But this won't work once WebKit-LLVM integration is complete. LLVM has no notion of
        storing things at a fixed offset from the frame pointer. We could try to hack LLVM to do
        that, but it would seriously complicate LLVM's stack layout. But what we might be able
        to do is have LLVM tell us (via an addressof intrinsic and a side-channel) where some
        alloca landed relative to the frame pointer. Hence if the DFG can put all of its flushed
        variables in a contiguous range that can be expressed to LLVM as a struct that we
        alloca, then all of this can still work just fine.
        
        Previously the flushed variables didn't fit in a contiguous range, but this patch makes
        them contiguous by allowing the stack layout to be compressed.
        
        What this really means is that there is now a distinction between where the DFG saw a
        variable stored in bytecode and where it will actually store it in the resulting machine
        code. Henceforth when the DFG says "local" or "virtual register" it means the variable
        according to bytecode (with the stack offsetting for inlined code as before), but when
        it says "machine local" or "machine virtual register" it means the actual place where it
        will store things in the resulting machine code. All of the OSR exit, inlined arguments,
        captured variables, and various stack unwinding machine now knows about all of this.
        
        Note that the DFG's abstract interpretation still uses bytecode variables rather than
        machine variables. Same for CSE and abstract heaps. This makes sense since it means that
        we don't have to decide on machine variable allocation just to do those optimizations.
        
        The decision of what a local's machine location becomes is deferred to very late in
        compilation. We only need to assign machine locations to variables that must be stored
        to the stack. It's now mandatory to run some kind of "stack layout phase" that makes the
        decision and updates all data structures.
        
        So far the way that this is being used is just to compress the DFG stack layout, which
        is something that we should have done anyway, a long time ago. And the compression isn't
        even that good - the current StackLayoutPhase just identifies local indices that are
        unused in machine code and slides all other variables towards zero. This doesn't achieve
        particularly good compression but it is better than nothing. Note that this phase makes
        it seem like the bytecode-machine mapping is based on bytecode local indices; for
        example if bytecode local 4 is mapped to machine local 3 then it always will be. That's
        true for the current StackLayoutPhase but it _will not_ be true for all possible stack
        layout phases and it would be incorrect to assume that it should be true. This is why
        the current data structures have each VariableAccessData hold its own copy of the
        machine virtual register, and also have each InlineCallFrame report their own machine
        virtual registers for the various things. The DFG backend is likely to always use the
        dumb StackLayoutPhase since it is very cheap to run, but the FTL backend is likely to
        eventually get a better one, where we do some kind of constraint-based coloring: we
        institute constraints where some VariableAccessData's must have the same indices as some
        other ones, and also must be right next to some other ones; then we process all
        VariableAccessData's and attempt to assign them machine locals while preserving those
        constraints. This could lead to two VariableAccessDatas for the same bytecode local
        ending up with different machine locals.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::isCaptured):
        (JSC::CodeBlock::framePointerOffsetToGetActivationRegisters):
        (JSC::CodeBlock::machineSlowArguments):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::hasSlowArguments):
        * bytecode/CodeOrigin.cpp:
        (JSC::CodeOrigin::dump):
        (JSC::InlineCallFrame::calleeForCallFrame):
        (JSC::InlineCallFrame::dumpInContext):
        * bytecode/CodeOrigin.h:
        (JSC::InlineCallFrame::InlineCallFrame):
        (JSC::InlineCallFrame::calleeConstant):
        * bytecode/Operands.h:
        (JSC::Operands::indexForOperand):
        * dfg/DFGBasicBlock.cpp:
        (JSC::DFG::BasicBlock::SSAData::SSAData):
        * dfg/DFGBasicBlock.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::ByteCodeParser):
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::getLocal):
        (JSC::DFG::ByteCodeParser::flushDirect):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCommon.h:
        * dfg/DFGCommonData.h:
        (JSC::DFG::CommonData::CommonData):
        * dfg/DFGDesiredWriteBarriers.cpp:
        (JSC::DFG::DesiredWriteBarrier::trigger):
        * dfg/DFGDesiredWriteBarriers.h:
        * dfg/DFGFlushLivenessAnalysisPhase.cpp:
        (JSC::DFG::FlushLivenessAnalysisPhase::run):
        (JSC::DFG::FlushLivenessAnalysisPhase::process):
        (JSC::DFG::FlushLivenessAnalysisPhase::reportError):
        * dfg/DFGFlushedAt.cpp: Added.
        (JSC::DFG::FlushedAt::dump):
        (JSC::DFG::FlushedAt::dumpInContext):
        * dfg/DFGFlushedAt.h: Added.
        (JSC::DFG::FlushedAt::FlushedAt):
        (JSC::DFG::FlushedAt::operator!):
        (JSC::DFG::FlushedAt::format):
        (JSC::DFG::FlushedAt::virtualRegister):
        (JSC::DFG::FlushedAt::operator==):
        (JSC::DFG::FlushedAt::operator!=):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::bytecodeRegisterForArgument):
        (JSC::DFG::Graph::argumentsRegisterFor):
        (JSC::DFG::Graph::machineArgumentsRegisterFor):
        (JSC::DFG::Graph::uncheckedArgumentsRegisterFor):
        (JSC::DFG::Graph::activationRegister):
        (JSC::DFG::Graph::uncheckedActivationRegister):
        (JSC::DFG::Graph::machineActivationRegister):
        (JSC::DFG::Graph::uncheckedMachineActivationRegister):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::noticeOSREntry):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToGetLocalUnlinked):
        (JSC::DFG::Node::convertToGetLocal):
        (JSC::DFG::Node::machineLocal):
        (JSC::DFG::Node::hasUnlinkedMachineLocal):
        (JSC::DFG::Node::setUnlinkedMachineLocal):
        (JSC::DFG::Node::unlinkedMachineLocal):
        (JSC::DFG::Node::hasInlineStartData):
        (JSC::DFG::Node::inlineStartData):
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::dumpNodeFlags):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSREntry.h:
        (JSC::DFG::OSREntryReshuffling::OSREntryReshuffling):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGScoreBoard.h:
        (JSC::DFG::ScoreBoard::ScoreBoard):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInlineStart):
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::createOSREntries):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::calleeFrameOffset):
        (JSC::DFG::SpeculativeJIT::callFrameSlot):
        (JSC::DFG::SpeculativeJIT::argumentSlot):
        (JSC::DFG::SpeculativeJIT::callFrameTagSlot):
        (JSC::DFG::SpeculativeJIT::callFramePayloadSlot):
        (JSC::DFG::SpeculativeJIT::argumentTagSlot):
        (JSC::DFG::SpeculativeJIT::argumentPayloadSlot):
        (JSC::DFG::SpeculativeJIT::framePointerOffsetToGetActivationRegisters):
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::recordSetLocal):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStackLayoutPhase.cpp: Added.
        (JSC::DFG::StackLayoutPhase::StackLayoutPhase):
        (JSC::DFG::StackLayoutPhase::run):
        (JSC::DFG::performStackLayout):
        * dfg/DFGStackLayoutPhase.h: Added.
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        * dfg/DFGVariableAccessData.h:
        (JSC::DFG::VariableAccessData::machineLocal):
        (JSC::DFG::VariableAccessData::flushedAt):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::VirtualRegisterAllocationPhase::run):
        * ftl/FTLExitValue.h:
        (JSC::FTL::ExitValue::inJSStack):
        (JSC::FTL::ExitValue::inJSStackAsInt32):
        (JSC::FTL::ExitValue::inJSStackAsInt52):
        (JSC::FTL::ExitValue::inJSStackAsDouble):
        (JSC::FTL::ExitValue::virtualRegister):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileGetArgument):
        (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
        (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
        (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
        (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * ftl/FTLValueSource.cpp:
        (JSC::FTL::ValueSource::dump):
        * ftl/FTLValueSource.h:
        (JSC::FTL::ValueSource::ValueSource):
        (JSC::FTL::ValueSource::kind):
        (JSC::FTL::ValueSource::operator!):
        (JSC::FTL::ValueSource::node):
        (JSC::FTL::ValueSource::virtualRegister):
        * interpreter/Interpreter.cpp:
        (JSC::unwindCallFrame):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::readInlinedFrame):
        (JSC::StackVisitor::Frame::createArguments):
        (JSC::StackVisitor::Frame::existingArguments):
        * interpreter/StackVisitor.h:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::addressFor):
        (JSC::AssemblyHelpers::tagFor):
        (JSC::AssemblyHelpers::payloadFor):
        (JSC::AssemblyHelpers::offsetOfArgumentsIncludingThis):
        * runtime/Arguments.cpp:
        (JSC::Arguments::tearOff):
        * runtime/Arguments.h:
        (JSC::Arguments::allocateSlowArguments):
        (JSC::Arguments::tryDeleteArgument):
        (JSC::Arguments::isDeletedArgument):
        (JSC::Arguments::isArgument):
        (JSC::Arguments::argument):
        (JSC::Arguments::finishCreation):
        * runtime/JSActivation.h:
        (JSC::JSActivation::create):
        (JSC::JSActivation::JSActivation):
        * runtime/JSFunction.cpp:
        (JSC::RetrieveArgumentsFunctor::operator()):

2013-10-05  Anders Carlsson  <andersca@apple.com>

        Remove createOwned
        https://bugs.webkit.org/show_bug.cgi?id=122388

        Reviewed by Darin Adler.

        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::save):

2013-10-05  Darin Adler  <darin@apple.com>

        Cut down on use of String::number
        https://bugs.webkit.org/show_bug.cgi?id=122382

        Reviewed by Anders Carlsson.

        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject::putByIndex): Use Identifier::from instead of calling
        String::number and creating an identifier from that. Can save creating and then
        destroying a string if an identifier already exists.
        * runtime/Arguments.cpp:
        (JSC::Arguments::getOwnPropertySlotByIndex): Ditto.
        (JSC::Arguments::getOwnPropertyNames): Ditto.
        (JSC::Arguments::putByIndex): Ditto.
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::::getOwnPropertyNames): Ditto.
        * runtime/StringObject.cpp:
        (JSC::StringObject::getOwnPropertyNames): Ditto.

2013-10-04  Mark Lam  <mark.lam@apple.com>

        Change ScriptDebugServer to use DebuggerCallFrame instead of JavaScriptCallFrame.
        https://bugs.webkit.org/show_bug.cgi?id=121969.

        Reviewed by Geoffrey Garen.

        1. Make JavaScriptCallFrame a thin shell around the DebuggerCallFrame.
           DebuggerCallFrame now tracks whether it is valid instead of needing
           JavaScriptCallFrame do it.
        2. ScriptDebugServer now only instantiates an DebuggerCallFrame when needed
           just before it pauses and calls back to its client, and then invalidates
           it immediately when the callback returns. Every subsequent callback to
           the client will use a new instance of the DebuggerCallFrame.
        3. Similarly, ScriptDebugServer now only creates a JavaScriptCallFrame when
           it "pauses".
        4. DebuggerCallFrame only creates its caller DebuggerCallFrame when
           it is needed i.e. when the client calls callerFrame(). Similarly,
           JavaScriptCallFrame only creates its caller when it's requested.
        5. DebuggerCallFrame's line() and column() now returns a base-zero int.
        6. WebScriptDebugDelegate now only caches the functionName of the frame
           instead of the entire DebuggerCallFrame because that is all that is
           needed.
        7. Also removed evaluateInGlobalCallFrame() which is not used anywhere.

        * debugger/Debugger.cpp:
        * debugger/Debugger.h:
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::DebuggerCallFrame):
        (JSC::DebuggerCallFrame::callerFrame):
        (JSC::DebuggerCallFrame::dynamicGlobalObject):
        (JSC::DebuggerCallFrame::sourceId):
        (JSC::DebuggerCallFrame::functionName):
        (JSC::DebuggerCallFrame::scope):
        (JSC::DebuggerCallFrame::type):
        (JSC::DebuggerCallFrame::thisValue):
        (JSC::DebuggerCallFrame::evaluate):
        (JSC::DebuggerCallFrame::evaluateWithCallFrame):
        (JSC::DebuggerCallFrame::invalidate):
        (JSC::DebuggerCallFrame::positionForCallFrame):
        (JSC::DebuggerCallFrame::sourceIdForCallFrame):
        (JSC::DebuggerCallFrame::thisValueForCallFrame):
        * debugger/DebuggerCallFrame.h:
        (JSC::DebuggerCallFrame::create):
        (JSC::DebuggerCallFrame::exec):
        (JSC::DebuggerCallFrame::line):
        (JSC::DebuggerCallFrame::column):
        (JSC::DebuggerCallFrame::position):
        (JSC::DebuggerCallFrame::isValid):
        * interpreter/StackVisitor.cpp:

2013-10-04  Brent Fulgham  <bfulgham@apple.com>

        Silence compiler warning when building 64-bit (on Windows)

        Reviewed by Geoffrey Garen.

        * jit/JSInterfaceJIT.h: Add a static cast for assignment.

2013-10-04  Nadav Rotem  <nrotem@apple.com>

        FTL: Add support for ValueToInt32(bool(x))
        https://bugs.webkit.org/show_bug.cgi?id=122346

        Reviewed by Geoffrey Garen.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileValueToInt32):

2013-10-04  Oliver Hunt  <oliver@apple.com>

        Build fix.

        * runtime/JSArrayIterator.cpp:

2013-10-04  Oliver Hunt  <oliver@apple.com>

        Support for-of syntax
        https://bugs.webkit.org/show_bug.cgi?id=122339

        Reviewed by Geoffrey Garen.

        Add support for for-of syntax to JSC.  As part of doing this I had to make
        us support unique empty strings as identifiers.  In a follow on patch i'm
        going to remove the distinction entirely as it's purely a complicating
        separation.

        Otherwise the logic here is fairly self-explanatory.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addConstant):
        (JSC::BytecodeGenerator::emitCall):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallArguments::CallArguments):
        (JSC::ForOfNode::emitBytecode):
        * jit/JITOperations.cpp:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createForOfLoop):
        * parser/NodeConstructors.h:
        (JSC::EnumerationNode::EnumerationNode):
        (JSC::ForInNode::ForInNode):
        (JSC::ForOfNode::ForOfNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::::parseVarDeclarationList):
        (JSC::::parseForStatement):
        * parser/Parser.h:
        (JSC::Parser::isofToken):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createForOfLoop):
        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        (JSC::arrayIteratorPrototypeIterate):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::create):
        (JSC::ArrayPrototype::finishCreation):
        * runtime/ArrayPrototype.h:
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::CommonIdentifiers):
        * runtime/CommonIdentifiers.h:
        * runtime/Identifier.h:
        (JSC::Identifier::from):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpInContext):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectNativeFunction):
        * runtime/PrivateName.h:
        (JSC::PrivateName::PrivateName):
        * runtime/PropertyName.h:
        (JSC::PropertyName::PropertyName):

2013-10-04  Michael Saboff  <msaboff@apple.com>

        FTL::OSRExit::convertToForward() shouldn't misuse Operands<>::operator[]
        https://bugs.webkit.org/show_bug.cgi?id=122336

        Reviewed by Geoffrey Garen.

        Changed code in change set r156900 to use the operand() accessor instead of operator[].

        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExit::convertToForward):

2013-10-04  Michael Saboff  <msaboff@apple.com>

        FTL: Crash in OSRExit::convertToForward() using VirtualRegister.offset() as array index
        https://bugs.webkit.org/show_bug.cgi?id=122332

        Reviewed by Oliver Hunt.

        Changed the uses of .offset(), which returns a negative number for locals, to be
        toLocal() which returns a local's ordinal number.

        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExit::convertToForward):

2013-10-04  Michael Saboff  <msaboff@apple.com>

        Add callOperation to Baseline JIT
        https://bugs.webkit.org/show_bug.cgi?id=122306

        Reviewed by Geoffrey Garen.

        Created baseline JIT compatible versions for a few flavors of callOperation().
        Migrated cti_op_new_regexp() and its caller to callOperation(operationNewRegexp()).

        * dfg/DFGOperations.cpp: Moved operationNewRegexp() to JITOperations
        * dfg/DFGOperations.h:
        * jit/JIT.h:
        (JSC::JIT::appendCall):
        * jit/JITInlines.h:
        (JSC::JIT::appendCallWithExceptionCheck):
        (JSC::JIT::appendCallWithExceptionCheckSetJSValueResult):
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_regexp):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITStubs.cpp:
        * jit/JITStubs.h:
        * jit/JSInterfaceJIT.h:

2013-10-03  Mark Rowe  <mrowe@apple.com>

        REGRESSION (r156811): WebCore rebuilds from scratch when doing an incremental build

        The change in r156811 resulted in several public headers in the JavaScriptCore framework having their modification
        date touched on every build, even if their contents had not changed. This resulted in a large portion of WebCore
        needing to rebuilt after an incremental build of JavaScriptCore.

        Reviewed by Dan Bernstein.

        * JavaScriptCore.xcodeproj/project.pbxproj: Have unifdef generate its output to a temporary file. If its exit status
        indicates that the content did not change, remove the temporary file. If the content changed, moved the temporary file
        over the destination.

2013-10-03  Brent Fulgham  <bfulgham@apple.com>

        [Win] Unreviewed gardening.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Clean up the
        paths for various files added outside of Visual Studio. They are all
        displayed in the root of the project, rather than the proper sub-folder.

2013-10-03  Brent Fulgham  <bfulgham@apple.com>

        [Win] Update solutions and projects to support 64-bit builds.
        https://bugs.webkit.org/show_bug.cgi?id=122225

        Reviewed by Anders Carlsson.

        Revise ordering of CPU(X86) and CPU(X86_64) tests, because MSVC always defines
        both when targeting a 64-bit build.

        * JavaScriptCore.vcxproj/JavaScriptCore.submit.sln: Add an x64 target
        for 64-bit builds.

2013-10-03  Michael Saboff  <msaboff@apple.com>

        Eliminate unused JITStub function declarations
        https://bugs.webkit.org/show_bug.cgi?id=122288

        Reviewed by Geoffrey Garen.

        Removed unused JITStub declarations.

        * jit/JITStubs.h:

2013-10-03  Sergio Correia  <sergio.correia@openbossa.org>

        [EFL] [DEBUG] JavaScriptCore fails to build
        https://bugs.webkit.org/show_bug.cgi?id=122267

        Reviewed by Michael Saboff.

        Build fails due to an expression containing comparison between signed
        and unsigned integer.

        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions): Add cast to avoid signed vs.
        unsigned comparison warning.

2013-10-03  Nadav Rotem  <nrotem@apple.com>

        DFG: ConstProp the pattern ValueToInt32(Bool(x)) -> Int32(x)
        https://bugs.webkit.org/show_bug.cgi?id=122263

        Reviewed by Geoffrey Garen.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):

2013-10-02  Dan Bernstein  <mitz@apple.com>

        REGRESSION (r156811): Objective-C JavaScriptCore API test failing on Mountain Lion bots
        https://bugs.webkit.org/show_bug.cgi?id=122260

        Reviewed by Mark Rowe.

        For the API to work, the tests need to be compiled with a newer version of the LLVM
        compiler. Until the bots are updated to that version, disable the tests on 10.8.

        * API/tests/testapi.mm:

2013-10-02  Mark Lam  <mark.lam@apple.com>

        Make LLINT exception stack unwinding consistent with the JIT.
        https://bugs.webkit.org/show_bug.cgi?id=122255.

        Reviewed by Filip Pizlo.

        Previously, the CommonSlowPaths code is expected to behave in an
        inconsistent way in terms of whether to unwind the stack when handling
        exceptions or not. For the LLINT, the slow path should unwind the stack
        before returning. For the JIT, the slow path should not unwind the stack.
        This can result in the stack being unwound twice when the exception
        being handled is a TerminationException.

        This patch fixes the LLINT's expectation so that it expects the same
        slow path behavior as the JIT does.

        * llint/LLIntExceptions.cpp:
        (JSC::LLInt::returnToThrow):
        (JSC::LLInt::callToThrow):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPathsExceptions.cpp:
        (JSC::CommonSlowPaths::interpreterThrowInCaller):

2013-10-02  Filip Pizlo  <fpizlo@apple.com>

        The DFG should use always DFG::Graph methods for determining where special registers are
        https://bugs.webkit.org/show_bug.cgi?id=122248

        Reviewed by Michael Saboff.
        
        This makes it possible to have the DFG use different registers than the other engines
        for things like activation and arguments.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::setLocalStoreElimination):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::activationRegister):
        (JSC::DFG::Graph::uncheckedActivationRegister):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::baselineArgumentsRegisterFor):

2013-10-02  Dan Bernstein  <mitz@apple.com>

        The Objective-C API should be available in 10.8 builds
        https://bugs.webkit.org/show_bug.cgi?id=122245

        Reviewed by Mark Rowe.

        Enabled the Objective-C API when building on OS X 10.8 with the modern Objective-C runtime,
        but kept the availability attributes in API headers for 10.9 and later as they were.

        * API/JSBase.h: When JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 is defined, made
        JSC_OBJC_API_ENABLED true on 10.8 and above.
        * API/JSContext.h: When JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 is defined, marked the class
        as available on all OS X versions.
        * API/JSManagedValue.h: Ditto.
        * API/JSValue.h: Ditto.
        * API/JSVirtualMachine.h: Ditto.
        * Configurations/Base.xcconfig: Added JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 to
        GCC_PREPROCESSOR_DEFINITIONS.
        * JavaScriptCore.xcodeproj/project.pbxproj: Added a script build phase to unifdef the
        above header files with JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 either defined or not based on
        the OS X version we are targeting.

2013-10-02  Michael Saboff  <msaboff@apple.com>

        Make Baseline JIT exception handling work like the DFG JIT
        https://bugs.webkit.org/show_bug.cgi?id=122244

        Reviewed by Filip Pizlo.

        Added a jump list (m_exceptionChecks) to JIT as a common place for exception processing within
        generated code.  Added exceptionCheck() helpers that check for an exception which add a branch
        to the list.

        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JIT.h:
        (JSC::JIT::exceptionCheck):

2013-10-02  Oliver Hunt  <oliver@apple.com>

        Fix MSVC build

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:

2013-10-02  Geoffrey Garen  <ggaren@apple.com>

        Optimized VM access from C++ code
        https://bugs.webkit.org/show_bug.cgi?id=122241

        Reviewed by Filip Pizlo.

        * runtime/JSScope.h:
        (JSC::JSScope::vm): Use MarkedBlock instead of Heap, since both have a
        pointer to the VM, and Heap is one extra load.

2013-10-02  Michael Saboff  <msaboff@apple.com>

        The LLInt should not use JITStackFrame
        https://bugs.webkit.org/show_bug.cgi?id=122231

        Reviewed by Filip Pizlo.

        Replaced uses of JITStackFrame::vm with code to either access the vm via the CodeBlock from
        known JavaScript call frames or via the JSScope* for host call frames.  This eliminates
        all uses of JITStackFrame from the LLInt.

        * heap/MarkedBlock.h: Made LLIntOffsetsExtractor a friend to access member offsets.
        * heap/WeakSet.h: Made LLIntOffsetsExtractor a friend to access member offsets.
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions): Added an ASSERT for the newly added MarkedBlockMask
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2013-10-01  Oliver Hunt  <oliver@apple.com>

        Implement Array key, value and entries iterators
        https://bugs.webkit.org/show_bug.cgi?id=122195

        Reviewed by Filip Pizlo.

        Add implementation of ES6 Array iterators for keys(), values() and entries()

        Fairly self explanatory as we just need a simple implementation so that we can
        implement and test other features.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/ArrayIteratorConstructor.cpp: Added.
        (JSC::ArrayIteratorConstructor::finishCreation):
        * runtime/ArrayIteratorConstructor.h: Added.
        (JSC::ArrayIteratorConstructor::create):
        (JSC::ArrayIteratorConstructor::createStructure):
        (JSC::ArrayIteratorConstructor::ArrayIteratorConstructor):
        * runtime/ArrayIteratorPrototype.cpp: Added.
        (JSC::ArrayIteratorPrototype::finishCreation):
        (JSC::createIteratorResult):
        (JSC::arrayIteratorPrototypeNext):
        * runtime/ArrayIteratorPrototype.h: Added.
        (JSC::ArrayIteratorPrototype::create):
        (JSC::ArrayIteratorPrototype::createStructure):
        (JSC::ArrayIteratorPrototype::ArrayIteratorPrototype):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncValues):
        (JSC::arrayProtoFuncEntries):
        (JSC::arrayProtoFuncKeys):
        * runtime/CommonIdentifiers.h:
        * runtime/Identifier.h:
        (JSC::Identifier::createEmptyUnique):
        * runtime/JSArrayIterator.cpp: Added.
        (JSC::JSArrayIterator::finishCreation):
        * runtime/JSArrayIterator.h: Added.
        (JSC::JSArrayIterator::createStructure):
        (JSC::JSArrayIterator::create):
        (JSC::JSArrayIterator::iterationKind):
        (JSC::JSArrayIterator::iteratedObject):
        (JSC::JSArrayIterator::nextIndex):
        (JSC::JSArrayIterator::setNextIndex):
        (JSC::JSArrayIterator::finish):
        (JSC::JSArrayIterator::JSArrayIterator):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::iteratorResultStructure):

2013-10-02  Mark Hahnenberg  <mhahnenberg@apple.com>

        get_callee and to_this aren't properly cleared during finalizeUnconditionally
        https://bugs.webkit.org/show_bug.cgi?id=122224

        Reviewed by Geoffrey Garen.

        Even though there is code to clear unmarked inline cache objects in finalizeUnconditionally,
        it will never run because get_callee and to_this weren't added to the proper Vector in the 
        UnlinkedCodeBlock that is iterated during finalizeUnconditionally.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCreateThis):

2013-09-25  Oliver Hunt  <oliver@apple.com>

        Implement prefixed-destructuring assignment
        https://bugs.webkit.org/show_bug.cgi?id=121930

        Reviewed by Mark Hahnenberg.

        Relanding with fix after rollout - it helps to not completely destroy
        optimisations for no reason.

2013-10-02  Nadav Rotem  <nrotem@apple.com>

        FTL: Refactor compileArithDiv and compileArithMod into one function.
        https://bugs.webkit.org/show_bug.cgi?id=122205

        Reviewed by Filip Pizlo.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileAddSub):
        (JSC::FTL::LowerDFGToLLVM::compileArithDivMod):

2013-10-02  Anders Carlsson  <andersca@apple.com>

        Get rid of Qt code from JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=122223

        Reviewed by Oliver Hunt.

        * API/JSStringRefQt.cpp: Removed.
        * API/JSStringRefQt.h: Removed.
        * API/OpaqueJSString.h:
        * DerivedSources.pri: Removed.
        * JavaScriptCore.pri: Removed.
        * JavaScriptCore.pro: Removed.
        * LLIntOffsetsExtractor.pro: Removed.
        * Target.pri: Removed.
        * assembler/AbstractMacroAssembler.h:
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::urshift32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::shouldBlindForSpecificArch):
        * assembler/MacroAssemblerX86Common.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        * heap/HeapTimer.cpp:
        (JSC::HeapTimer::timerEvent):
        * heap/HeapTimer.h:
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::scheduleTimer):
        * heap/IncrementalSweeper.h:
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emitSub32Constant):
        * jsc.cpp:
        (main):
        * jsc.pro: Removed.
        * runtime/DateConstructor.cpp:
        * runtime/GCActivityCallback.cpp:
        (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
        (JSC::DefaultGCActivityCallback::cancelTimer):
        * runtime/GCActivityCallback.h:
        * testRegExp.cpp:
        (main):
        * yarr/yarr.pri: Removed.

2013-10-01  Filip Pizlo  <fpizlo@apple.com>

        FTL should use the new version of LLVM MCJIT memory manager APIs that take a SectionName
        https://bugs.webkit.org/show_bug.cgi?id=122193

        Reviewed by Geoffrey Garen.
        
        Update our usage of the LLVM C API since the API is about to change.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateCodeSection):
        (JSC::FTL::mmAllocateDataSection):

2013-10-01  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(156464): 50% regression on SunSpider/string-fasta
        https://bugs.webkit.org/show_bug.cgi?id=122202

        Unreviewed, roll out r156464.
        
        This is a progression on string-fasta, since it fixes the regression.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::paramString):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitExpressionInfo):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitBytecode):
        (JSC::FuncExprNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFormalParameterList):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::addVar):
        * parser/NodeConstructors.h:
        (JSC::CommaNode::CommaNode):
        (JSC::ParameterNode::ParameterNode):
        (JSC::ForInNode::ForInNode):
        * parser/Nodes.cpp:
        (JSC::FunctionParameters::create):
        (JSC::FunctionParameters::FunctionParameters):
        (JSC::FunctionParameters::~FunctionParameters):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isDotAccessorNode):
        (JSC::CommaNode::append):
        (JSC::ParameterNode::ident):
        (JSC::FunctionParameters::at):
        (JSC::FunctionParameters::identifiers):
        * parser/Parser.cpp:
        (JSC::::Parser):
        (JSC::::parseVarDeclaration):
        (JSC::::parseVarDeclarationList):
        (JSC::::parseForStatement):
        (JSC::::parseFormalParameters):
        (JSC::::parseAssignmentExpression):
        * parser/Parser.h:
        (JSC::Scope::declareParameter):
        (JSC::Parser::declareParameter):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFormalParameterList):
        (JSC::SyntaxChecker::createForInLoop):
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/JSONObject.cpp:
        * runtime/JSONObject.h:

2013-10-01  Filip Pizlo  <fpizlo@apple.com>

        Variable event stream (for DFG OSR exit) should be explicit about where on the stack a SetLocal put a value
        https://bugs.webkit.org/show_bug.cgi?id=122178

        Reviewed by Geoffrey Garen.
        
        Now if the DFG stores the value of a variable into the stack explicitly via a SetLocal,
        it will record where on the stack it stored the value in addition to recording where on
        the stack the bytecode would have done the SetLocal. Previously it just recorded the
        format and the bytecode variable. Recording just the bytecode variable is currently fine
        since the DFG always executes SetLocal's to the same stack location that the bytecode
        would have used. But that prevents stack compression (webkit.org/b/122024) so this patch
        allows the SetLocal to say both the bytecode variable that we're speaking of and the
        actual stack location to which the SetLocal stored the value.
        
        This had to touch a lot of code, so I took the opportunity to also resolve
        webkit.org/b/108019.

        * bytecode/Operands.h:
        (JSC::Operands::hasOperand):
        * dfg/DFGFlushFormat.h:
        (JSC::DFG::dataFormatFor):
        * dfg/DFGMinifiedID.h:
        (JSC::DFG::MinifiedID::bits):
        (JSC::DFG::MinifiedID::invalidID):
        (JSC::DFG::MinifiedID::otherInvalidID):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileMovHint):
        (JSC::DFG::SpeculativeJIT::compileInlineStart):
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::recordSetLocal):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValueSource.cpp:
        (JSC::DFG::ValueSource::dump):
        * dfg/DFGValueSource.h:
        (JSC::DFG::ValueSource::ValueSource):
        (JSC::DFG::ValueSource::forFlushFormat):
        (JSC::DFG::ValueSource::forDataFormat):
        (JSC::DFG::ValueSource::isSet):
        (JSC::DFG::ValueSource::kind):
        (JSC::DFG::ValueSource::valueRecovery):
        (JSC::DFG::ValueSource::id):
        (JSC::DFG::ValueSource::virtualRegister):
        * dfg/DFGVariableEvent.cpp:
        (JSC::DFG::VariableEvent::dump):
        (JSC::DFG::VariableEvent::dumpSpillInfo):
        * dfg/DFGVariableEvent.h:
        (JSC::DFG::VariableEvent::fillGPR):
        (JSC::DFG::VariableEvent::fillPair):
        (JSC::DFG::VariableEvent::fillFPR):
        (JSC::DFG::VariableEvent::spill):
        (JSC::DFG::VariableEvent::death):
        (JSC::DFG::VariableEvent::setLocal):
        (JSC::DFG::VariableEvent::movHint):
        (JSC::DFG::VariableEvent::id):
        (JSC::DFG::VariableEvent::gpr):
        (JSC::DFG::VariableEvent::tagGPR):
        (JSC::DFG::VariableEvent::payloadGPR):
        (JSC::DFG::VariableEvent::fpr):
        (JSC::DFG::VariableEvent::spillRegister):
        (JSC::DFG::VariableEvent::bytecodeRegister):
        (JSC::DFG::VariableEvent::machineRegister):
        (JSC::DFG::VariableEvent::variableRepresentation):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):

2013-10-01  Nadav Rotem  <nrotem@apple.com>

        FTL: split overflow checks into non-overflow arithmetic and an additional call to the overflow intrinsic check.
        https://bugs.webkit.org/show_bug.cgi?id=122170

        Reviewed by Filip Pizlo.

        Overflow intrinsics are preventing SCEV and other LLVM analysis passes from analyzing loops. This patch changes the FTL-IR gen by splitting arithmetic calculations into two parts:
        1. Generate the arithmetic calculation (that may overflow)
        2. Generate the overflow check (that is only used by the OSR-exit logic).

        We trust LLVM (SelectionDAG) to merge these calculations into a single opcode.

        This JS function:

        function foo() {
            for (i=0; i < 10000000; i++) { }
        }

        Is now compiled into this LLVM-IR: 

        "OSR exit continuation for @24<Int32>":           ; preds = %"Block #0", %"OSR exit continuation for @24<Int32>2"
          %4 = phi i64 [ %10, %"OSR exit continuation for @24<Int32>2" ], [ -281474976710656, %"Block #0" ]
          %5 = trunc i64 %4 to i32
          %6 = add i32 %5, 1
          %7 = tail call { i32, i1 } @llvm.sadd.with.overflow.i32(i32 %5, i32 1)
          %8 = extractvalue { i32, i1 } %7, 1
          br i1 %8, label %"OSR exit failCase for @24<Int32>1", label %"OSR exit continuation for @24<Int32>2"

         And into this assembly:

        LBB0_1:                                 ## %OSR exit continuation for @24<Int32>
                                        ## =>This Inner Loop Header: Depth=1
            movl  %ecx, %esi
            incl  %esi
            jo  LBB0_4

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileAddSub):
        (JSC::FTL::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::LowerDFGToLLVM::compileArithNegate):

2013-10-01  Nadav Rotem  <nrotem@apple.com>

        Consolidate multiple OSRExit calls into one.
        https://bugs.webkit.org/show_bug.cgi?id=122168

        Reviewed by Filip Pizlo.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
        (JSC::FTL::LowerDFGToLLVM::compileArithMod):

2013-09-30  Filip Pizlo  <fpizlo@apple.com>

        SpeculativeJIT::m_arguments/m_variables are vestiges of a time long gone
        https://bugs.webkit.org/show_bug.cgi?id=122140

        Reviewed by Darin Adler.
        
        Just killing code.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::compileInlineStart):
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::recordSetLocal):

2013-10-01  Daniel Bates  <dabates@apple.com>

        [iOS] JavaScriptCore fails to build with newer versions of clang
        https://bugs.webkit.org/show_bug.cgi?id=122162

        Reviewed by Darin Adler.

        * runtime/GCActivityCallback.cpp: Add !PLATFORM(IOS)-guard around constant pagingTimeOut
        as we don't compile the code that uses it on iOS.

2013-09-30  Sam Weinig  <sam@webkit.org>

        Remove support for DOMFileSystem
        https://bugs.webkit.org/show_bug.cgi?id=122137

        Reviewed by Anders Carlsson.

        * Configurations/FeatureDefines.xcconfig:

2013-09-30  Dan Bernstein  <mitz@apple.com>

        <rdar://problem/15114974> Assertion failure under -[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:] if no classes conform to JSExport
        https://bugs.webkit.org/show_bug.cgi?id=122124

        Reviewed by Darin Adler.

        * API/JSWrapperMap.mm: Defined an empty class that conforms to the JSExport protocol, to
        ensure that the protocol is always registered with the runtime by the time
        getJSExportProtocol() is called.

2013-09-30  Benjamin Poulain  <benjamin@webkit.org>

        Remove the code guarded by STYLE_SCOPED
        https://bugs.webkit.org/show_bug.cgi?id=122123

        Reviewed by Anders Carlsson.

        * Configurations/FeatureDefines.xcconfig:

2013-09-30  Andreas Kling  <akling@apple.com>

        Pass VM instead of ExecState to ObjectPrototype constructor.
        <https://webkit.org/b/122116>

        Reviewed by Geoffrey Garen.

        The ObjectPrototype constructor was only using the ExecState to get
        to the VM.

2013-09-30  Andreas Kling  <akling@apple.com>

        Pass VM instead of JSGlobalObject to MathObject constructor.
        <https://webkit.org/b/122119>

        Reviewed by Geoffrey Garen.

        The MathObject constructor was only using the global object to get
        to the VM. finishCreation() still uses it to set up functions.

2013-09-30  Filip Pizlo  <fpizlo@apple.com>

        Get rid of the AlreadyInJSStack recoveries since they are totally redundant with the DisplacedInJSStack recoveries
        https://bugs.webkit.org/show_bug.cgi?id=122065

        Reviewed by Mark Hahnenberg.
        
        This mostly just kills a bunch of code.
        
        But incidentaly while killing that code, I uncovered a bug in our FTL OSR entrypoint
        creation phase. The phase inserts a sequence of SetLocal(ExtractOSREntryLocal) nodes.
        If we hoist some type check into the local, then we might inject a conversion node
        between the ExtractOSREntryLocal and the SetLocal - for example we might put in a
        Int32ToDouble node. But currently the FixupPhase will make all conversion nodes placed
        on an edge of a SetLocal use forward exit. This then confuses the OSR exit machinery.
        When OSR exit sees a forward exit, it tries to "roll forward" execution from the exiting
        node to the first node that has a different CodeOrigin. This only works if the nodes
        after the forward exit are MovHints or other tnings that the OSR exit compiler can
        forward-execute. But here, it will see a bunch of SetLocal and ExtractOSREntryLocal
        nodes for the same bytecode index. Two possible solutions exist. We could teach the
        forward-execution logic how to deal with multiple SetLocals and ExtractOSREntryLocals.
        This would be a lot of complexity; right now it just needs to deal with exactly one
        SetLocal-like operation. The alternative is to make sure that the conversion node that
        we inject ends up exiting *backward* rather than forward.
        
        But making the conversion nodes exit backward is somewhat tricky. Before this patch,
        conversion nodes always exit forward for SetLocals and backwards otherwise. It turns out
        that the solution is to rationalize how we choose the speculation direciton for a
        conversion node. The conversion node's speculation direction should be the same as the
        speculation direction of the node for which it is doing a conversion. Since SetLocal's
        already exit forward by default, this policy preserves our previous behavior. But it
        also allows the OSR entrypoint creation phase to make its SetLocals exit backward
        instead.
        
        Of course, if the SetLocal(ExtractOSREntryLocal) sequences exit backward, then we need
        to make sure that the OSR exit machine knows that the local variables are indeed live.
        Consider that if we have:
        
            a: ExtractOSREntryLocal(loc1)
            b: SetLocal(@a, loc1)
            c: ExtractOSRentryLocal(loc2)
            d: SetLocal(@c, loc2)
        
        Without additional magic, the exit at @b will think that loc2 is dead and the OSR exit
        compiler will clobber loc2 with Undefined. So we need to make sure that we actually
        emit code like:
        
            a: ExtractOSREntryLocal(loc1)
            b: ExtractOSREntryLocal(loc2)
            c: SetLocal(@a, loc1)
            d: SetLocal(@b, loc2)
            e: SetLocal(@a, loc1)
            f: SetLocal(@b, loc2)

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeOrigin.h:
        * bytecode/ValueRecovery.cpp: Added.
        (JSC::ValueRecovery::recover):
        (JSC::ValueRecovery::dumpInContext):
        (JSC::ValueRecovery::dump):
        * bytecode/ValueRecovery.h:
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupSetLocalsInBlock):
        (JSC::DFG::FixupPhase::fixEdge):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::reconstruct):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::speculationDirection):
        (JSC::DFG::Node::setSpeculationDirection):
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInlineStart):
        (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor):
        * dfg/DFGValueSource.h:
        (JSC::DFG::ValueSource::valueRecovery):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::speculateMachineInt):
        * interpreter/Register.h:
        (JSC::Register::unboxedStrictInt52):
        * runtime/Arguments.cpp:
        (JSC::Arguments::tearOff):
        * runtime/Arguments.h:

2013-09-30  Alex Christensen  <alex.christensen@flexsim.com>

        Win64 compile fix after r1256490.
        https://bugs.webkit.org/show_bug.cgi?id=122117

        Reviewed by Michael Saboff.

        * jit/JITStubsMSVC64.asm:
        Implemented getHostCallReturnValue for Windows x86_64 processors.

2013-09-30  Andreas Kling  <akling@apple.com>

        Pass VM instead of JSGlobalObject to RegExp constructor.
        <https://webkit.org/b/122113>

        Reviewed by Darin Adler.

        RegExps don't need anything from the global object during their
        construction and only use it to get to the VM. Reduce loads by
        simply passing the VM around instead.

        JSC release binary size -= 120 bytes(!)

2013-09-30  Patrick Gansterer  <paroga@webkit.org>

        Fix compilation for COMPILER(MSVC) && !CPU(X86) after r156490.
        https://bugs.webkit.org/show_bug.cgi?id=122102

        Reviewed by Geoffrey Garen.

        _AddressOfReturnAddress() is supported for all platforms of
        ths Microsoft compiler, so we can use it for !CPU(X86) too.

        * jit/JITOperationWrappers.h:

2013-09-30  Gabor Rapcsanyi  <rgabor@webkit.org>

        Unreviewed. Build fix for DEBUG_VERBOSE mode after r156511.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):

2013-09-30  Gabor Rapcsanyi  <rgabor@webkit.org>

        Unreviewed. Speculative build fix on ARMv7 Thumb2 after r156490.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::fmodAsDFGOperation):

2013-09-29  Nadav Rotem  <nrotem@apple.com>

        FTL: refactor compileAdd and compileArithSub into one function.
        https://bugs.webkit.org/show_bug.cgi?id=122081

        Reviewed by Geoffrey Garen.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileAddSub):

2013-09-29  Andreas Kling  <akling@apple.com>

        Pass VM instead of JSGlobalObject to function constructors.
        <https://webkit.org/b/122082>

        Reviewed by Darin Adler.

        Functions don't need anything from the global object during their
        construction and only use it to get to the VM. Reduce loads by
        simply passing the VM around instead.

        This patch is mostly mechanical, I just changed the signature of
        InternalFunction and worked my way from there until it built.

        JSC release binary size -= 4840 bytes.

2013-09-29  Andreas Kling  <akling@apple.com>

        Pass VM instead of JSGlobalObject to ArrayPrototype constructor.
        <https://webkit.org/b/122079>

        Reviewed by Geoffrey Garen.

        ArrayPrototype doesn't need the global object for anything during
        construction, so reduce the amount of loads by just passing the VM.

2013-09-29  Andreas Kling  <akling@apple.com>

        Pass VM instead of ExecState to simple builtin constructors.
        <https://webkit.org/b/122077>

        Reviewed by Sam Weinig.

        None of the simple builtins need the ExecState for anything during
        their construction, so reduce the amount of loads by just passing
        the VM around instead.

2013-09-29  Nadav Rotem  <nrotem@apple.com>

        Refactor code for finding x86 scratch register.
        https://bugs.webkit.org/show_bug.cgi?id=122072

        Reviewed by Geoffrey Garen.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::getUnusedRegister):
        (JSC::MacroAssemblerX86Common::store8):
        (JSC::MacroAssemblerX86Common::store16):

2013-09-28  Mark Rowe  <mrowe@apple.com>

        Take Xcode's advice and enable some extra warnings.

        Reviewed by Sam Weinig.

        * Configurations/Base.xcconfig:
        * JavaScriptCore.xcodeproj/project.pbxproj:

2013-09-28  Andreas Kling  <akling@apple.com>

        Pass VM instead of ExecState to JSFunction constructors.
        <https://webkit.org/b/122014>

        Reviewed by Geoffrey Garen.

        JSFunction doesn't need the ExecState for anything during its
        construction, so reduce the amount of loads by just passing the
        VM around instead.

        Factored out putDirectNonIndexAccessor() from the existing
        putDirectAccessor() to avoid snowballing the patch (and because
        it's kinda neat to avoid the extra branch.)

        JSC release binary size -= 9680 bytes.

2013-09-28  Mark Rowe  <mrowe@apple.com>

        JavaScriptCore fails to build with newer versions of clang.

        Reviewed by Sam Weinig.

        * interpreter/Interpreter.cpp: Remove an unused function.
        * parser/SourceProvider.cpp: Ditto.
        * runtime/GCActivityCallback.cpp: #if a constant that's only used on non-CF platforms.
        * runtime/JSCJSValue.cpp: Remove an unused constant.
        * runtime/JSString.cpp: Ditto.

2013-09-27  Filip Pizlo  <fpizlo@apple.com>

        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):

2013-09-27  Filip Pizlo  <fpizlo@apple.com>

        Deoptimize 32-bit deoptimization
        https://bugs.webkit.org/show_bug.cgi?id=122025

        Reviewed by Oliver Hunt.
        
        Just simplifying a bunch of code. I don't want the old, super-complicated,
        deoptimization code to get in the way of changes I'll be making to DFG stack layout.

        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::inGPR):
        (JSC::ValueRecovery::isInRegisters):
        (JSC::ValueRecovery::gpr):
        (JSC::ValueRecovery::dumpInContext):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):

2013-09-27  Alex Christensen  <alex.christensen@flexsim.com>

        Fixed Win64 build after r156184.
        https://bugs.webkit.org/show_bug.cgi?id=121994

        Reviewed by Oliver Hunt.

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupTwoStubArgsGPR):
        (JSC::CCallHelpers::setupTwoStubArgsFPR):
        Renamed from setupTwoStubArgs.
        Visual Studio x64 compiler fails to see that this is an overloaded template function.
        (JSC::CCallHelpers::setupStubArguments):
        (JSC::CCallHelpers::setupArguments):
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        Use setupTwoStubArgsGPR or setupTwoStubArgsFPR instead of setupTwoStubArgs.

2013-09-27  Gabor Rapcsanyi  <rgabor@webkit.org>

        LLInt alignment problem on ARM in debug mode
        https://bugs.webkit.org/show_bug.cgi?id=122012

        Reviewed by Michael Saboff.

        Force GCC to put the LLInt code to .text section.

        * llint/LowLevelInterpreter.cpp:

2013-09-06  Jer Noble  <jer.noble@apple.com>

        [Mac] Implement the media controls in JavaScript.
        https://bugs.webkit.org/show_bug.cgi?id=120895

        Reviewed by Dean Jackson.

        Define and turn on ENABLE_MEDIA_CONTROLS_SCRIPT.

        * Configurations/FeatureDefines.xcconfig:

2013-09-27  Andreas Kling  <akling@apple.com>

        Pass VM instead of ExecState to JSDateMath functions.
        <https://webkit.org/b/121997>

        Reviewed by Geoffrey Garen.

        The JSC date math functions only need the VM, so pass that from
        callers instead of the whole ExecState.

2013-09-26  Andreas Kling  <akling@apple.com>

        GetterSetter construction should take a VM instead of ExecState.
        <https://webkit.org/b/121993>

        Reviewed by Sam Weinig.

        Pass VM& instead of ExecState* to GetterSetter. Updated surrounding
        code at touched sites to cache VM in a local for fewer loads.

        JSC release binary size -= 4120 bytes.

2013-09-26  Oliver Hunt  <oliver@apple.com>

        Make GCC happy

        * parser/Parser.h:

2013-09-25  Oliver Hunt  <oliver@apple.com>

        Implement prefixed-destructuring assignment
        https://bugs.webkit.org/show_bug.cgi?id=121930

        Reviewed by Mark Hahnenberg.

        Relanding with fix after rollout

2013-09-26  Michael Saboff  <msaboff@apple.com>

        VirtualRegister should be a class
        https://bugs.webkit.org/show_bug.cgi?id=121732

        Reviewed by Geoffrey Garen.

        This is a refactoring change.  Changed VirtualRegister from an enum to a class.
        Moved Operands::operandIsArgument(), operandToArgument(), argumentToOperand()
        and the similar functions for locals to VirtualRegister class.

        This is in preparation for changing the offset for the first local register from
        0 to -1.  This is needed since most native calling conventions have the architected
        frame pointer (e.g. %rbp for X86) point at the slot that stores the previous frame
        pointer.  Local values start below that address.

        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:
        * bytecode/Instruction.h:
        * bytecode/LazyOperandValueProfile.h:
        * bytecode/MethodOfGettingAValueProfile.cpp:
        * bytecode/Operands.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        * bytecode/UnlinkedCodeBlock.h:
        * bytecode/ValueRecovery.h:
        * bytecode/VirtualRegister.h:
        * bytecompiler/BytecodeGenerator.cpp:
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/RegisterID.h:
        * debugger/DebuggerCallFrame.cpp:
        * dfg/DFGAbstractHeap.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        * dfg/DFGArgumentPosition.h:
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        * dfg/DFGByteCodeParser.cpp:
        * dfg/DFGCFGSimplificationPhase.cpp:
        * dfg/DFGCPSRethreadingPhase.cpp:
        * dfg/DFGCapabilities.cpp:
        * dfg/DFGConstantFoldingPhase.cpp:
        * dfg/DFGFlushLivenessAnalysisPhase.cpp:
        * dfg/DFGGraph.cpp:
        * dfg/DFGGraph.h:
        * dfg/DFGJITCode.cpp:
        * dfg/DFGNode.h:
        * dfg/DFGOSREntry.cpp:
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        * dfg/DFGOSRExitCompiler64.cpp:
        * dfg/DFGRegisterBank.h:
        * dfg/DFGScoreBoard.h:
        * dfg/DFGSpeculativeJIT.cpp:
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        * dfg/DFGSpeculativeJIT64.cpp:
        * dfg/DFGValidate.cpp:
        * dfg/DFGValueRecoveryOverride.h:
        * dfg/DFGVariableAccessData.h:
        * dfg/DFGVariableEvent.h:
        * dfg/DFGVariableEventStream.cpp:
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        * ftl/FTLExitArgumentForOperand.h:
        * ftl/FTLLink.cpp:
        * ftl/FTLLowerDFGToLLVM.cpp:
        * ftl/FTLOSREntry.cpp:
        * ftl/FTLOSRExit.cpp:
        * ftl/FTLOSRExit.h:
        * ftl/FTLOSRExitCompiler.cpp:
        * interpreter/CallFrame.h:
        * interpreter/Interpreter.cpp:
        * jit/AssemblyHelpers.h:
        * jit/JIT.h:
        * jit/JITCall.cpp:
        * jit/JITCall32_64.cpp:
        * jit/JITInlines.h:
        * jit/JITOpcodes.cpp:
        * jit/JITOpcodes32_64.cpp:
        * jit/JITPropertyAccess32_64.cpp:
        * jit/JITStubs.cpp:
        * llint/LLIntSlowPaths.cpp:
        * profiler/ProfilerBytecodeSequence.cpp:
        * runtime/CommonSlowPaths.cpp:
        * runtime/JSActivation.cpp:

2013-09-26  Anders Carlsson  <andersca@apple.com>

        Work around another MSVC bug.

        * runtime/PrototypeMap.cpp:
        (JSC::PrototypeMap::emptyObjectStructureForPrototype):

2013-09-26  Anders Carlsson  <andersca@apple.com>

        Attempt to fix the FTL build.

        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::IndexedAbstractHeap::atSlow):

2013-09-26  Andreas Kling  <akling@apple.com>

        Pass VM instead of ExecState to many finishCreation() functions.
        <https://webkit.org/b/121975>

        Reviewed by Sam Weinig.

        Reduce unnecessary loads by passing the VM to object creation
        functions that don't need the ExecState.

        There are tons of opportunities in this area, I'm just scratching
        the surface.

2013-09-26  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r156464 and r156480.
        http://trac.webkit.org/changeset/156464
        http://trac.webkit.org/changeset/156480
        https://bugs.webkit.org/show_bug.cgi?id=121981

        Leaking too much and killing buildbot. (Requested by xenon on
        #webkit).

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::paramString):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitExpressionInfo):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitBytecode):
        (JSC::FuncExprNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFormalParameterList):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::addVar):
        * parser/NodeConstructors.h:
        (JSC::CommaNode::CommaNode):
        (JSC::ParameterNode::ParameterNode):
        (JSC::ForInNode::ForInNode):
        * parser/Nodes.cpp:
        (JSC::FunctionParameters::create):
        (JSC::FunctionParameters::FunctionParameters):
        (JSC::FunctionParameters::~FunctionParameters):
        * parser/Nodes.h:
        (JSC::CommaNode::append):
        (JSC::ParameterNode::ident):
        (JSC::FunctionParameters::at):
        (JSC::FunctionParameters::identifiers):
        * parser/Parser.cpp:
        (JSC::::Parser):
        (JSC::::parseVarDeclaration):
        (JSC::::parseVarDeclarationList):
        (JSC::::parseForStatement):
        (JSC::::parseFormalParameters):
        (JSC::::parseAssignmentExpression):
        * parser/Parser.h:
        (JSC::Scope::declareParameter):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFormalParameterList):
        (JSC::SyntaxChecker::createForInLoop):
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/JSONObject.cpp:
        * runtime/JSONObject.h:

2013-09-26  Anders Carlsson  <andersca@apple.com>

        Try to fix the Windows build.

        * jit/JITThunks.cpp:
        (JSC::JITThunks::hostFunctionStub):
        * jit/JITThunks.h:

2013-09-26  Anders Carlsson  <andersca@apple.com>

        Change a couple of HashMap value types from OwnPtr to std::unique_ptr
        https://bugs.webkit.org/show_bug.cgi?id=121973

        Reviewed by Andreas Kling.

        * API/JSClassRef.cpp:
        (OpaqueJSClassContextData::OpaqueJSClassContextData):
        (OpaqueJSClass::contextData):
        * API/JSClassRef.h:
        * bytecode/SamplingTool.h:
        * ftl/FTLAbstractHeap.h:
        * parser/Parser.cpp:
        (JSC::::parseFunctionInfo):
        * parser/SourceProviderCache.cpp:
        (JSC::SourceProviderCache::add):
        * parser/SourceProviderCache.h:
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::create):
        * profiler/ProfilerCompilation.cpp:
        (JSC::Profiler::Compilation::executionCounterFor):
        (JSC::Profiler::Compilation::toJS):
        * profiler/ProfilerCompilation.h:
        * runtime/JSGlobalObject.h:

2013-09-26  Mark Lam  <mark.lam@apple.com>

        Move DFG inline caching logic into jit/.
        https://bugs.webkit.org/show_bug.cgi?id=121749.

        Reviewed by Geoffrey Garen.

        Relanding http://trac.webkit.org/changeset/156235 after rebasing to latest
        revision and fixing build breakages on Windows.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::unlink):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resetStubInternal):
        * bytecode/StructureStubInfo.h:
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
        (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
        * dfg/DFGJITCompiler.h:
        * dfg/DFGOSRExitCompiler.h:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * dfg/DFGOperations.h:
        (JSC::DFG::operationNewTypedArrayWithSizeForType):
        (JSC::DFG::operationNewTypedArrayWithOneArgumentForType):
        * dfg/DFGRegisterSet.h: Removed.
        * dfg/DFGRepatch.cpp: Removed.
        * dfg/DFGRepatch.h: Removed.
        * dfg/DFGScratchRegisterAllocator.h: Removed.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeCompare):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
        (JSC::DFG::SpeculativeJIT::compare):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGThunks.cpp:
        * dfg/DFGThunks.h:
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
        * ftl/FTLOSRExitCompiler.h:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::writeBarrier):
        * jit/JIT.cpp:
        (JSC::JIT::linkFor):
        (JSC::JIT::linkSlowCall):
        * jit/JITCall.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::privateCompileClosureCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::privateCompileClosureCall):
        * jit/JITOperationWrappers.h: Copied from Source/JavaScriptCore/jit/JITOperationWrappers.h.
        * jit/JITOperations.cpp: Copied from Source/JavaScriptCore/jit/JITOperations.cpp.
        (JSC::getHostCallReturnValueWithExecState):
        * jit/JITOperations.h: Copied from Source/JavaScriptCore/jit/JITOperations.h.
        * jit/RegisterSet.h: Copied from Source/JavaScriptCore/jit/RegisterSet.h.
        * jit/Repatch.cpp: Copied from Source/JavaScriptCore/jit/Repatch.cpp.
        (JSC::tryBuildGetByIDList):
        * jit/Repatch.h: Copied from Source/JavaScriptCore/jit/Repatch.h.
        * jit/ScratchRegisterAllocator.h: Copied from Source/JavaScriptCore/jit/ScratchRegisterAllocator.h.
        * jit/ThunkGenerators.cpp:
        (JSC::oldStyleGenerateSlowCaseFor):
        (JSC::oldStyleLinkForGenerator):
        (JSC::oldStyleLinkCallGenerator):
        (JSC::oldStyleLinkConstructGenerator):
        (JSC::oldStyleLinkClosureCallGenerator):
        (JSC::oldStyleVirtualForGenerator):
        (JSC::oldStyleVirtualCallGenerator):
        (JSC::oldStyleVirtualConstructGenerator):
        (JSC::emitPointerValidation):
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::slowPathFor):
        (JSC::linkForThunkGenerator):
        (JSC::linkCallThunkGenerator):
        (JSC::linkConstructThunkGenerator):
        (JSC::linkClosureCallThunkGenerator):
        (JSC::virtualForThunkGenerator):
        (JSC::virtualCallThunkGenerator):
        (JSC::virtualConstructThunkGenerator):
        * jit/ThunkGenerators.h:

2013-09-26  Anders Carlsson  <andersca@apple.com>

        Remove PassWeak.h
        https://bugs.webkit.org/show_bug.cgi?id=121971

        Reviewed by Geoffrey Garen.

        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/PassWeak.h: Removed.
        * heap/WeakInlines.h:

2013-09-26  Anders Carlsson  <andersca@apple.com>

        Stop using PassWeak
        https://bugs.webkit.org/show_bug.cgi?id=121968

        Reviewed by Sam Weinig.

        * heap/Weak.h:
        Remove all knowledge of PassWeak.

        (JSC::Weak::Weak):
        These constructors don't need to be explicit.

        * heap/WeakInlines.h:
        (JSC::weakAdd):
        Change Value to be an rvalue reference and use std::forward.

        * jit/JITThunks.cpp:
        (JSC::JITThunks::hostFunctionStub):
        Remove PassWeak.

        * runtime/RegExpCache.cpp:
        (JSC::RegExpCache::lookupOrCreate):
        Use Weak instead of PassWeak.

        * runtime/SimpleTypedArrayController.cpp:
        Change add and set to take Weak by value and std::move into place.

        * runtime/WeakGCMap.h:
        (JSC::WeakGCMap::get):
        (JSC::WeakGCMap::set):
        (JSC::WeakGCMap::add):

2013-09-26  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r156474.
        http://trac.webkit.org/changeset/156474
        https://bugs.webkit.org/show_bug.cgi?id=121966

        Broke the builds. (Requested by xenon on #webkit).

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::registerName):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::createActivation):
        (JSC::CodeBlock::nameForRegister):
        * bytecode/CodeBlock.h:
        (JSC::unmodifiedArgumentsRegister):
        (JSC::CodeBlock::isKnownNotImmediate):
        (JSC::CodeBlock::setThisRegister):
        (JSC::CodeBlock::thisRegister):
        (JSC::CodeBlock::setArgumentsRegister):
        (JSC::CodeBlock::argumentsRegister):
        (JSC::CodeBlock::uncheckedArgumentsRegister):
        (JSC::CodeBlock::setActivationRegister):
        (JSC::CodeBlock::activationRegister):
        (JSC::CodeBlock::uncheckedActivationRegister):
        (JSC::CodeBlock::usesArguments):
        (JSC::CodeBlock::isCaptured):
        * bytecode/Instruction.h:
        * bytecode/LazyOperandValueProfile.h:
        (JSC::LazyOperandValueProfileKey::LazyOperandValueProfileKey):
        (JSC::LazyOperandValueProfileKey::operator!):
        (JSC::LazyOperandValueProfileKey::hash):
        (JSC::LazyOperandValueProfileKey::operand):
        (JSC::LazyOperandValueProfileKey::isHashTableDeletedValue):
        (JSC::LazyOperandValueProfile::LazyOperandValueProfile):
        * bytecode/MethodOfGettingAValueProfile.cpp:
        (JSC::MethodOfGettingAValueProfile::fromLazyOperand):
        (JSC::MethodOfGettingAValueProfile::getSpecFailBucket):
        * bytecode/Operands.h:
        (JSC::localToOperand):
        (JSC::operandIsLocal):
        (JSC::operandToLocal):
        (JSC::operandIsArgument):
        (JSC::operandToArgument):
        (JSC::argumentToOperand):
        (JSC::Operands::operand):
        (JSC::Operands::hasOperand):
        (JSC::Operands::setOperand):
        (JSC::Operands::operandForIndex):
        (JSC::Operands::setOperandFirstTime):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::setThisRegister):
        (JSC::UnlinkedCodeBlock::setActivationRegister):
        (JSC::UnlinkedCodeBlock::setArgumentsRegister):
        (JSC::UnlinkedCodeBlock::usesArguments):
        (JSC::UnlinkedCodeBlock::argumentsRegister):
        (JSC::UnlinkedCodeBlock::usesGlobalObject):
        (JSC::UnlinkedCodeBlock::setGlobalObjectRegister):
        (JSC::UnlinkedCodeBlock::globalObjectRegister):
        (JSC::UnlinkedCodeBlock::thisRegister):
        (JSC::UnlinkedCodeBlock::activationRegister):
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::displacedInJSStack):
        (JSC::ValueRecovery::virtualRegister):
        (JSC::ValueRecovery::dumpInContext):
        * bytecode/VirtualRegister.h:
        (WTF::printInternal):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::addVar):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::createLazyRegisterIfNecessary):
        (JSC::BytecodeGenerator::newRegister):
        (JSC::BytecodeGenerator::emitLoadGlobalObject):
        (JSC::BytecodeGenerator::emitGetArgumentsLength):
        (JSC::BytecodeGenerator::emitGetArgumentByVal):
        (JSC::BytecodeGenerator::createArgumentsIfNecessary):
        (JSC::BytecodeGenerator::emitReturn):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::registerFor):
        * bytecompiler/RegisterID.h:
        (JSC::RegisterID::RegisterID):
        (JSC::RegisterID::setIndex):
        (JSC::RegisterID::index):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::thisObject):
        * dfg/DFGAbstractHeap.h:
        (JSC::DFG::AbstractHeap::Payload::Payload):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        (JSC::DFG::::clobberCapturedVars):
        * dfg/DFGArgumentPosition.h:
        (JSC::DFG::ArgumentPosition::dump):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse):
        (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::newVariableAccessData):
        (JSC::DFG::ByteCodeParser::getDirect):
        (JSC::DFG::ByteCodeParser::get):
        (JSC::DFG::ByteCodeParser::setDirect):
        (JSC::DFG::ByteCodeParser::set):
        (JSC::DFG::ByteCodeParser::getLocal):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::getArgument):
        (JSC::DFG::ByteCodeParser::setArgument):
        (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
        (JSC::DFG::ByteCodeParser::findArgumentPosition):
        (JSC::DFG::ByteCodeParser::flush):
        (JSC::DFG::ByteCodeParser::flushDirect):
        (JSC::DFG::ByteCodeParser::getToInt32):
        (JSC::DFG::ByteCodeParser::getThis):
        (JSC::DFG::ByteCodeParser::addCall):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::emitFunctionChecks):
        (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleMinMax):
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCFGSimplificationPhase.cpp:
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocal):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocal):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeSetArgument):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::isCapturedAtOrAfter):
        * dfg/DFGFlushLivenessAnalysisPhase.cpp:
        (JSC::DFG::FlushLivenessAnalysisPhase::setForNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::argumentsRegisterFor):
        (JSC::DFG::Graph::uncheckedArgumentsRegisterFor):
        (JSC::DFG::Graph::uncheckedActivationRegisterFor):
        (JSC::DFG::Graph::valueProfileFor):
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::reconstruct):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::Node):
        (JSC::DFG::Node::convertToGetLocalUnlinked):
        (JSC::DFG::Node::hasVirtualRegister):
        (JSC::DFG::Node::virtualRegister):
        (JSC::DFG::Node::setVirtualRegister):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGRegisterBank.h:
        (JSC::DFG::RegisterBank::tryAllocate):
        (JSC::DFG::RegisterBank::allocateSpecific):
        (JSC::DFG::RegisterBank::retain):
        (JSC::DFG::RegisterBank::isInUse):
        (JSC::DFG::RegisterBank::dump):
        (JSC::DFG::RegisterBank::releaseAtIndex):
        (JSC::DFG::RegisterBank::allocateInternal):
        (JSC::DFG::RegisterBank::MapEntry::MapEntry):
        * dfg/DFGScoreBoard.h:
        (JSC::DFG::ScoreBoard::allocate):
        (JSC::DFG::ScoreBoard::use):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::checkConsistency):
        (JSC::DFG::SpeculativeJIT::compileMovHint):
        (JSC::DFG::SpeculativeJIT::compileInlineStart):
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::allocate):
        (JSC::DFG::SpeculativeJIT::fprAllocate):
        (JSC::DFG::SpeculativeJIT::silentSpillAllRegistersImpl):
        (JSC::DFG::SpeculativeJIT::flushRegisters):
        (JSC::DFG::SpeculativeJIT::isFlushed):
        (JSC::DFG::SpeculativeJIT::argumentSlot):
        (JSC::DFG::SpeculativeJIT::argumentTagSlot):
        (JSC::DFG::SpeculativeJIT::argumentPayloadSlot):
        (JSC::DFG::SpeculativeJIT::valueSourceForOperand):
        (JSC::DFG::SpeculativeJIT::setNodeForOperand):
        (JSC::DFG::SpeculativeJIT::valueSourceReferenceForOperand):
        (JSC::DFG::SpeculativeJIT::recordSetLocal):
        (JSC::DFG::SpeculativeJIT::generationInfoFromVirtualRegister):
        (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        (JSC::DFG::Validate::validateCPS):
        (JSC::DFG::Validate::checkOperand):
        (JSC::DFG::Validate::reportValidationContext):
        * dfg/DFGValueRecoveryOverride.h:
        (JSC::DFG::ValueRecoveryOverride::ValueRecoveryOverride):
        * dfg/DFGVariableAccessData.h:
        (JSC::DFG::VariableAccessData::operand):
        (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote):
        (JSC::DFG::VariableAccessData::tallyVotesForShouldUseDoubleFormat):
        (JSC::DFG::VariableAccessData::flushFormat):
        * dfg/DFGVariableEvent.h:
        (JSC::DFG::VariableEvent::spill):
        (JSC::DFG::VariableEvent::setLocal):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::VirtualRegisterAllocationPhase::run):
        * ftl/FTLExitArgumentForOperand.h:
        (JSC::FTL::ExitArgumentForOperand::ExitArgumentForOperand):
        (JSC::FTL::ExitArgumentForOperand::operand):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compileGetArgument):
        (JSC::FTL::LowerDFGToLLVM::compileExtractOSREntryLocal):
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::LowerDFGToLLVM::observeMovHint):
        (JSC::FTL::LowerDFGToLLVM::addressFor):
        (JSC::FTL::LowerDFGToLLVM::payloadFor):
        (JSC::FTL::LowerDFGToLLVM::tagFor):
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExit::convertToForward):
        * ftl/FTLOSRExit.h:
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * interpreter/CallFrame.h:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters):
        (JSC::unwindCallFrame):
        (JSC::Interpreter::unwind):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::addressFor):
        (JSC::AssemblyHelpers::tagFor):
        (JSC::AssemblyHelpers::payloadFor):
        (JSC::AssemblyHelpers::argumentsRegisterFor):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileLoadVarargs):
        * jit/JITInlines.h:
        (JSC::JIT::emitGetVirtualRegister):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_tear_off_arguments):
        (JSC::JIT::emit_op_get_pnames):
        (JSC::JIT::emit_op_enter):
        (JSC::JIT::emit_op_create_arguments):
        (JSC::JIT::emitSlow_op_get_argument_by_val):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_enter):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::BytecodeSequence):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::argumentsGetter):

2013-09-26  Oliver Hunt  <oliver@apple.com>

        Attempt to fix MSVC build

        * parser/Parser.cpp:
        (JSC::::createBindingPattern):
        (JSC::::parseDeconstructionPattern):
        * parser/Parser.h:

2013-09-26  Julien Brianceau  <jbriance@cisco.com>

        [sh4] JSValue* exception is unused since r70703 in JITStackFrame.
        https://bugs.webkit.org/show_bug.cgi?id=121962

        This is a cosmetic change, but it could avoid people reading sh4 part to
        waste time to understand why there is a JSValue* here.

        Reviewed by Darin Adler.

        * jit/JITStubs.h:

2013-09-26  Anders Carlsson  <andersca@apple.com>

        WeakGCMap should not inherit from HashMap
        https://bugs.webkit.org/show_bug.cgi?id=121964

        Reviewed by Geoffrey Garen.

        Add the HashMap as a member variable instead and implement the missing member functions.

        * runtime/WeakGCMap.h:

2013-09-25  Michael Saboff  <msaboff@apple.com>

        VirtualRegister should be a class
        https://bugs.webkit.org/show_bug.cgi?id=121732

        Reviewed by Geoffrey Garen.

        This is a refactoring change.  Changed VirtualRegister from an enum to a class.
        Moved Operands::operandIsArgument(), operandToArgument(), argumentToOperand()
        and the similar functions for locals to VirtualRegister class.

        This is in preparation for changing the offset for the first local register from
        0 to -1.  This is needed since most native calling conventions have the architected
        frame pointer (e.g. %rbp for X86) point at the slot that stores the previous frame
        pointer.  Local values start below that address.

        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:
        * bytecode/Instruction.h:
        * bytecode/LazyOperandValueProfile.h:
        * bytecode/MethodOfGettingAValueProfile.cpp:
        * bytecode/Operands.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        * bytecode/UnlinkedCodeBlock.h:
        * bytecode/ValueRecovery.h:
        * bytecode/VirtualRegister.h:
        * bytecompiler/BytecodeGenerator.cpp:
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/RegisterID.h:
        * debugger/DebuggerCallFrame.cpp:
        * dfg/DFGAbstractHeap.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        * dfg/DFGArgumentPosition.h:
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        * dfg/DFGByteCodeParser.cpp:
        * dfg/DFGCFGSimplificationPhase.cpp:
        * dfg/DFGCPSRethreadingPhase.cpp:
        * dfg/DFGCapabilities.cpp:
        * dfg/DFGConstantFoldingPhase.cpp:
        * dfg/DFGFlushLivenessAnalysisPhase.cpp:
        * dfg/DFGGraph.cpp:
        * dfg/DFGGraph.h:
        * dfg/DFGJITCode.cpp:
        * dfg/DFGNode.h:
        * dfg/DFGOSREntry.cpp:
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        * dfg/DFGOSRExitCompiler64.cpp:
        * dfg/DFGRegisterBank.h:
        * dfg/DFGScoreBoard.h:
        * dfg/DFGSpeculativeJIT.cpp:
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        * dfg/DFGValidate.cpp:
        * dfg/DFGValueRecoveryOverride.h:
        * dfg/DFGVariableAccessData.h:
        * dfg/DFGVariableEvent.h:
        * dfg/DFGVariableEventStream.cpp:
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        * ftl/FTLExitArgumentForOperand.h:
        * ftl/FTLLink.cpp:
        * ftl/FTLLowerDFGToLLVM.cpp:
        * ftl/FTLOSREntry.cpp:
        * ftl/FTLOSRExit.cpp:
        * ftl/FTLOSRExit.h:
        * ftl/FTLOSRExitCompiler.cpp:
        * interpreter/CallFrame.h:
        * interpreter/Interpreter.cpp:
        * jit/AssemblyHelpers.h:
        * jit/JIT.h:
        * jit/JITCall.cpp:
        * jit/JITInlines.h:
        * jit/JITOpcodes.cpp:
        * jit/JITOpcodes32_64.cpp:
        * jit/JITStubs.cpp:
        * llint/LLIntSlowPaths.cpp:
        * profiler/ProfilerBytecodeSequence.cpp:
        * runtime/CommonSlowPaths.cpp:
        * runtime/JSActivation.cpp:

2013-09-26  Anders Carlsson  <andersca@apple.com>

        Weak should have a move constructor and move assignment operator
        https://bugs.webkit.org/show_bug.cgi?id=121963

        Reviewed by Oliver Hunt.

        This is the first step towards getting rid of PassWeak.

        * API/JSClassRef.cpp:
        (OpaqueJSClass::prototype):
        * heap/Weak.h:
        * heap/WeakInlines.h:
        (JSC::::Weak):
        (JSC::::leakImpl):
        * runtime/SimpleTypedArrayController.cpp:
        (JSC::SimpleTypedArrayController::toJS):

2013-09-26  Mark Hahnenberg  <mhahnenberg@apple.com>

        op_to_this shouldn't use value profiling
        https://bugs.webkit.org/show_bug.cgi?id=121920

        Reviewed by Geoffrey Garen.

        Currently it's the only opcode that uses m_singletonValue, which is unnecessary. Our current plan is 
        to remove m_singletonValue so that GenGC can have a simpler story for handling CodeBlocks/FunctionExecutables 
        during nursery collections.

        This patch adds an inline cache for the Structure of to_this so it no longer depends on the ValueProfile's
        m_singletonValue. Since nobody uses m_singletonValue now, this patch also removes m_singletonValue from
        ValueProfile.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::updateAllValueProfilePredictions):
        (JSC::CodeBlock::updateAllPredictions):
        (JSC::CodeBlock::shouldOptimizeNow):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::updateAllValueProfilePredictions):
        (JSC::CodeBlock::updateAllPredictions):
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
        * bytecode/LazyOperandValueProfile.h:
        * bytecode/ValueProfile.h:
        (JSC::ValueProfileBase::ValueProfileBase):
        (JSC::ValueProfileBase::briefDescription):
        (JSC::ValueProfileBase::dump):
        (JSC::ValueProfileBase::computeUpdatedPrediction):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * 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):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2013-09-25  Oliver Hunt  <oliver@apple.com>

        Implement prefixed-destructuring assignment
        https://bugs.webkit.org/show_bug.cgi?id=121930

        Reviewed by Mark Hahnenberg.

        This is mostly simple - the semantics of deconstruction are already
        present in the language, so most of the complexity (if you call it
        that) is addition of new AST nodes, and parsing the syntax.

        In order to get correct semantics for the parameter lists, FunctionParameters
        now needs to store refcounted references to the parameter patterns.
        There's also a little work to ensure that variable creation and assignment
        occurs in the correct order while the BytecodeGenerator is being constructed. 

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::paramString):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitExpressionInfo):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitBytecode):
        (JSC::DeconstructingAssignmentNode::emitBytecode):
        (JSC::DeconstructionPatternNode::~DeconstructionPatternNode):
        (JSC::ArrayPatternNode::emitBytecode):
        (JSC::ArrayPatternNode::emitDirectBinding):
        (JSC::ArrayPatternNode::toString):
        (JSC::ArrayPatternNode::collectBoundIdentifiers):
        (JSC::ObjectPatternNode::toString):
        (JSC::ObjectPatternNode::emitBytecode):
        (JSC::ObjectPatternNode::collectBoundIdentifiers):
        (JSC::BindingNode::emitBytecode):
        (JSC::BindingNode::toString):
        (JSC::BindingNode::collectBoundIdentifiers):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFormalParameterList):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::addVar):
        (JSC::ASTBuilder::createDeconstructingAssignment):
        (JSC::ASTBuilder::createArrayPattern):
        (JSC::ASTBuilder::appendArrayPatternSkipEntry):
        (JSC::ASTBuilder::appendArrayPatternEntry):
        (JSC::ASTBuilder::createObjectPattern):
        (JSC::ASTBuilder::appendObjectPatternEntry):
        (JSC::ASTBuilder::createBindingLocation):
        * parser/NodeConstructors.h:
        (JSC::CommaNode::CommaNode):
        (JSC::ParameterNode::ParameterNode):
        (JSC::ForInNode::ForInNode):
        (JSC::DeconstructionPatternNode::DeconstructionPatternNode):
        (JSC::ArrayPatternNode::ArrayPatternNode):
        (JSC::ArrayPatternNode::create):
        (JSC::ObjectPatternNode::ObjectPatternNode):
        (JSC::ObjectPatternNode::create):
        (JSC::BindingNode::create):
        (JSC::BindingNode::BindingNode):
        (JSC::DeconstructingAssignmentNode::DeconstructingAssignmentNode):
        * parser/Nodes.cpp:
        (JSC::FunctionParameters::create):
        (JSC::FunctionParameters::FunctionParameters):
        (JSC::FunctionParameters::~FunctionParameters):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isDeconstructionNode):
        (JSC::ArrayNode::elements):
        (JSC::CommaNode::append):
        (JSC::ParameterNode::pattern):
        (JSC::FunctionParameters::at):
        (JSC::FunctionParameters::patterns):
        (JSC::DeconstructionPatternNode::isBindingNode):
        (JSC::DeconstructionPatternNode::emitDirectBinding):
        (JSC::ArrayPatternNode::appendIndex):
        (JSC::ObjectPatternNode::appendEntry):
        (JSC::ObjectPatternNode::Entry::Entry):
        (JSC::BindingNode::boundProperty):
        (JSC::BindingNode::isBindingNode):
        (JSC::DeconstructingAssignmentNode::bindings):
        (JSC::DeconstructingAssignmentNode::isLocation):
        (JSC::DeconstructingAssignmentNode::isDeconstructionNode):
        * parser/Parser.cpp:
        (JSC::::Parser):
        (JSC::::parseVarDeclaration):
        (JSC::::parseVarDeclarationList):
        (JSC::::createBindingPattern):
        (JSC::::parseDeconstructionPattern):
        (JSC::::parseForStatement):
        (JSC::::parseFormalParameters):
        (JSC::::parseAssignmentExpression):
        * parser/Parser.h:
        (JSC::Scope::declareBoundParameter):
        (JSC::Parser::declareBoundParameter):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createFormalParameterList):
        (JSC::SyntaxChecker::addVar):
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/JSONObject.cpp:
        (JSC::escapeStringToBuilder):
        * runtime/JSONObject.h:

2013-09-25  Brady Eidson  <beidson@apple.com>

        Enable the IndexedDB build on Mac, but leave the feature non-functional
        https://bugs.webkit.org/show_bug.cgi?id=121918

        Reviewed by Alexey Proskuryakov.

        * Configurations/FeatureDefines.xcconfig:

2013-09-25  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r156432.
        http://trac.webkit.org/changeset/156432
        https://bugs.webkit.org/show_bug.cgi?id=121932

        some integer conversion things that need brady to fix
        (Requested by thorton on #webkit).

        * Configurations/FeatureDefines.xcconfig:

2013-09-25  Anders Carlsson  <andersca@apple.com>

        Move KeyValuePairTraits inside HashMap
        https://bugs.webkit.org/show_bug.cgi?id=121931

        Reviewed by Sam Weinig.

        * tools/ProfileTreeNode.h:

2013-09-25  Brady Eidson  <beidson@apple.com>

        Enable the IndexedDB build on Mac, but leave the feature non-functional
        https://bugs.webkit.org/show_bug.cgi?id=121918

        Reviewed by Alexey Proskuryakov.

        * Configurations/FeatureDefines.xcconfig:

2013-09-25  Brady Eidson  <beidson@apple.com>

        FeatureDefine.xcconfig cleanup (They should all be identical).
        https://bugs.webkit.org/show_bug.cgi?id=121921

        Reviewed by Mark Rowe.

        * Configurations/FeatureDefines.xcconfig:

2013-09-25  Patrick Gansterer  <paroga@webkit.org>

        Build fix for WinCE after r155098.

        Windows CE does not support getenv().

        * jsc.cpp:
        (main):

2013-09-24  Mark Hahnenberg  <mhahnenberg@apple.com>

        op_get_callee shouldn't use value profiling
        https://bugs.webkit.org/show_bug.cgi?id=121821

        Reviewed by Filip Pizlo.

        Currently it's one of the two opcodes that uses m_singletonValue, which is unnecessary. 
        Our current plan is to remove m_singletonValue so that GenGC can have a simpler story 
        for handling CodeBlocks/FunctionExecutables during nursery collections.

        Instead of using a ValueProfile op_get_callee now has a simple inline cache of the most 
        recent JSFunction that we saw.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finalizeUnconditionally):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCreateThis):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_get_callee):
        (JSC::JIT::emitSlow_op_get_callee):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_callee):
        (JSC::JIT::emitSlow_op_get_callee):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:

2013-09-24  Mark Lam  <mark.lam@apple.com>

        Change JSC debug hooks to pass a CallFrame* instead of a DebuggerCallFrame.
        https://bugs.webkit.org/show_bug.cgi?id=121867.

        Reviewed by Geoffrey Garen.

        1. Removed the need for passing the line and column info to the debug hook
           callbacks. We now get the line and column info from the CallFrame.

        2. Simplify BytecodeGenerator::emitDebugHook() to only take 1 line number
           argument. The caller can determine whether to pass in the first or last
           line number of the block of source code as appropriate.
           Note: we still need to pass in the line and column info to emitDebugHook()
           because it uses this info to emit expression info which is later used by
           the StackVisitor to determine the line and column info for its "pc".

        3. Pass the exceptionValue explicitly to the exception() debug hook
           callback. It should not be embedded in the CallFrame / DebuggerCallFrame.

        4. Change the op_debug opcode size to 2 (from 5) since we've removing 3 arg
           values. Update the LLINT and JIT code to handle this.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDebugHook):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ConstStatementNode::emitBytecode):
        (JSC::EmptyStatementNode::emitBytecode):
        (JSC::DebuggerStatementNode::emitBytecode):
        (JSC::ExprStatementNode::emitBytecode):
        (JSC::VarStatementNode::emitBytecode):
        (JSC::IfElseNode::emitBytecode):
        (JSC::DoWhileNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::WithNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        (JSC::LabelNode::emitBytecode):
        (JSC::ThrowNode::emitBytecode):
        (JSC::TryNode::emitBytecode):
        (JSC::ProgramNode::emitBytecode):
        (JSC::EvalNode::emitBytecode):
        (JSC::FunctionBodyNode::emitBytecode):
        * debugger/Debugger.h:
        * debugger/DebuggerCallFrame.cpp:
        (JSC::LineAndColumnFunctor::operator()):
        (JSC::LineAndColumnFunctor::line):
        (JSC::LineAndColumnFunctor::column):
        (JSC::DebuggerCallFrame::DebuggerCallFrame):
        (JSC::DebuggerCallFrame::clear):
        * debugger/DebuggerCallFrame.h:
        (JSC::DebuggerCallFrame::line):
        (JSC::DebuggerCallFrame::column):
        * interpreter/Interpreter.cpp:
        (JSC::unwindCallFrame):
        (JSC::UnwindFunctor::UnwindFunctor):
        (JSC::UnwindFunctor::operator()):
        (JSC::Interpreter::unwind):
        (JSC::Interpreter::debug):
        * interpreter/Interpreter.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_debug):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_debug):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:

2013-09-24  Filip Pizlo  <fpizlo@apple.com>

        Crashing under JSC::DFG::SpeculativeJIT::spill visiting citicards.com
        https://bugs.webkit.org/show_bug.cgi?id=121844

        Reviewed by Mark Hahnenberg.
        
        Fix some int52 bugs that caused this.

        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::dumpInContext): There's no such thing as int53.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::spill): Actually spill int52's, instead of hitting an assert and crashing.
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): Use the right format (from before when we clobber it).

2013-09-24  Mark Rowe  <mrowe@apple.com>

        <rdar://problem/14971518> WebKit should build against the Xcode default toolchain when targeting OS X 10.8

        Reviewed by Dan Bernstein.

        * Configurations/Base.xcconfig:

2013-09-23  Patrick Gansterer  <paroga@webkit.org>

        use NOMINMAX instead of #define min min
        https://bugs.webkit.org/show_bug.cgi?id=73563

        Reviewed by Brent Fulgham.

        Use NOMINMAX instead of #define min/max as a cleaner
        way of ensuring that Windows system header files don't
        define min/max as macro in the first place.

        * config.h:

2013-09-23  Filip Pizlo  <fpizlo@apple.com>

        Never use ReturnPC for exception handling and quit using exception check indices as a lame replica of the CodeOrigin index
        https://bugs.webkit.org/show_bug.cgi?id=121734

        Reviewed by Mark Hahnenberg.
        
        Exception handling can deduce where the exception was thrown from by looking at the
        code origin that was stored into the call frame header. There is no need to pass any
        additional meta-data into the exception throwing logic. But the DFG was still doing it
        anyway.
        
        This removes all of the logic to pass extra meta-data into lookupExceptionHandler()
        and friends. It simplifies a lot of code.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::shrinkToFit):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::codeOrigins):
        (JSC::CodeBlock::hasCodeOrigins):
        (JSC::CodeBlock::canGetCodeOrigin):
        (JSC::CodeBlock::codeOrigin):
        * bytecode/CodeOrigin.h:
        (JSC::InlineCallFrame::InlineCallFrame):
        * bytecode/InlineCallFrameSet.cpp: Added.
        (JSC::InlineCallFrameSet::InlineCallFrameSet):
        (JSC::InlineCallFrameSet::~InlineCallFrameSet):
        (JSC::InlineCallFrameSet::add):
        (JSC::InlineCallFrameSet::shrinkToFit):
        * bytecode/InlineCallFrameSet.h: Added.
        (JSC::InlineCallFrameSet::isEmpty):
        (JSC::InlineCallFrameSet::size):
        (JSC::InlineCallFrameSet::at):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::addCodeOrigin):
        (JSC::DFG::CommonData::shrinkToFit):
        * dfg/DFGCommonData.h:
        * dfg/DFGDesiredWriteBarriers.cpp:
        (JSC::DFG::DesiredWriteBarrier::DesiredWriteBarrier):
        (JSC::DFG::DesiredWriteBarrier::trigger):
        * dfg/DFGDesiredWriteBarriers.h:
        (JSC::DFG::DesiredWriteBarriers::add):
        (JSC::DFG::initializeLazyWriteBarrierForInlineCallFrameExecutable):
        (JSC::DFG::initializeLazyWriteBarrierForInlineCallFrameCallee):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        * dfg/DFGGraph.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (JSC::DFG::JITCompiler::compileExceptionHandlers):
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
        (JSC::DFG::JITCompiler::exceptionCheck):
        (JSC::DFG::JITCompiler::fastExceptionCheck):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryBuildGetByIDList):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck):
        (JSC::DFG::SpeculativeJIT::appendCallSetResult):
        (JSC::DFG::SpeculativeJIT::appendCall):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::VirtualRegisterAllocationPhase::run):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::callPreflight):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitExceptionCheck):

2013-09-23  Oliver Hunt  <oliver@apple.com>

        CodeLoad performance regression

        Reviewed by Filip Pizlo.

        Temporarily remove the ExpressionInfo compression until we can
        work out how to make it not clobber performance.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):
        (JSC::UnlinkedCodeBlock::addExpressionInfo):
        * bytecode/UnlinkedCodeBlock.h:

2013-09-23  Patrick Gansterer  <paroga@webkit.org>

        Cleanup CMake files in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=121762

        Reviewed by Gyuyoung Kim.

        Sort files and unify style.

        * CMakeLists.txt:
        * shell/CMakeLists.txt:
        * shell/PlatformBlackBerry.cmake:
        * shell/PlatformEfl.cmake:

2013-09-22  Filip Pizlo  <fpizlo@apple.com>

        Get rid of CodeBlock::RareData::callReturnIndexVector and most of the evil that it introduced
        https://bugs.webkit.org/show_bug.cgi?id=121766

        Reviewed by Andreas Kling.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::shrinkToFit):
        * bytecode/CodeBlock.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileExceptionHandlers):
        (JSC::DFG::JITCompiler::link):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):

2013-09-21  Filip Pizlo  <fpizlo@apple.com>

        Interpreter::unwind() has no need for the bytecodeOffset
        https://bugs.webkit.org/show_bug.cgi?id=121755

        Reviewed by Oliver Hunt.
        
        It was only using the bytecodeOffset for some debugger stuff, but the debugger could
        just get the bytecodeOffset the same way the rest of the machinery does: by using the
        CallFrame's location.
        
        It turns out that a lot of really ugly code was in place just to supply this
        bytecodeOffset. This patch kills most of that code, and allows us to kill even more
        code in a future patch - though most likely that killage will involve further
        refactorings as well, see https://bugs.webkit.org/show_bug.cgi?id=121734.

        * dfg/DFGOperations.cpp:
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::bytecodeOffset):
        (JSC::CallFrame::codeOrigin):
        * interpreter/CallFrame.h:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwind):
        * interpreter/Interpreter.h:
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITExceptions.h:
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::cti_vm_handle_exception):
        * llint/LLIntExceptions.cpp:
        (JSC::LLInt::doThrow):
        (JSC::LLInt::returnToThrow):
        (JSC::LLInt::callToThrow):
        * llint/LLIntExceptions.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPathsExceptions.cpp:
        (JSC::CommonSlowPaths::interpreterThrowInCaller):
        * runtime/CommonSlowPathsExceptions.h:

2013-09-21  Darin Adler  <darin@apple.com>

        Add ExecState::uncheckedArgument and use where possible to shrink a bit
        https://bugs.webkit.org/show_bug.cgi?id=121750

        Reviewed by Andreas Kling.

        * interpreter/CallFrame.h:
        (JSC::ExecState::uncheckedArgument): Added. Like argument, but with an
        assertion rather than a runtime check.

        * API/APICallbackFunction.h:
        (JSC::APICallbackFunction::call): Use uncheckedArgument because we are
        already in a loop over arguments, so don't need a range check.
        * API/JSCallbackConstructor.cpp:
        (JSC::constructJSCallback): Ditto.
        * API/JSCallbackObjectFunctions.h:
        (JSC::JSCallbackObject::construct): Ditto.
        (JSC::JSCallbackObject::call): Ditto.
        * jsc.cpp:
        (functionPrint): Ditto.
        (functionRun): Ditto.
        (functionSetSamplingFlags): Ditto.
        (functionClearSamplingFlags): Ditto.
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncConcat): Ditto.
        (JSC::arrayProtoFuncPush): Use uncheckedArgument because there is already
        code that explicitly checks argumentCount.
        (JSC::arrayProtoFuncSplice): Ditto.
        (JSC::arrayProtoFuncUnShift): Ditto.
        (JSC::arrayProtoFuncReduce): Ditto.
        (JSC::arrayProtoFuncReduceRight): Ditto.
        (JSC::arrayProtoFuncLastIndexOf): Ditto.
        * runtime/DatePrototype.cpp:
        (JSC::fillStructuresUsingTimeArgs): Ditto.
        (JSC::fillStructuresUsingDateArgs): Ditto.
        * runtime/JSArrayBufferConstructor.cpp:
        (JSC::constructArrayBuffer): Ditto.
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::arrayBufferProtoFuncSlice): Ditto.
        * runtime/JSBoundFunction.cpp:
        (JSC::boundFunctionCall): Ditto.
        (JSC::boundFunctionConstruct): Ditto.
        * runtime/JSDataViewPrototype.cpp:
        (JSC::getData): Ditto.
        (JSC::setData): Ditto.
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayView): Ditto.
        * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
        (JSC::genericTypedArrayViewProtoFuncSet): Ditto.
        (JSC::genericTypedArrayViewProtoFuncSubarray): Ditto.
        * runtime/JSONObject.cpp:
        (JSC::JSONProtoFuncParse): Ditto.
        (JSC::JSONProtoFuncStringify): Ditto.
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise): Ditto.
        (JSC::JSPromiseConstructorFuncFulfill): Ditto.
        (JSC::JSPromiseConstructorFuncResolve): Ditto.
        (JSC::JSPromiseConstructorFuncReject): Ditto.
        * runtime/MathObject.cpp:
        (JSC::mathProtoFuncMax): Ditto.
        (JSC::mathProtoFuncMin): Ditto.

        * runtime/NameConstructor.cpp:
        (JSC::constructPrivateName): Removed unneeded check of argumentCout
        that simply repeats what argument already does.
        * runtime/NativeErrorConstructor.cpp:
        (JSC::Interpreter::constructWithNativeErrorConstructor): Ditto.
        (JSC::Interpreter::callNativeErrorConstructor): Ditto.

        * runtime/NumberConstructor.cpp:
        (JSC::constructWithNumberConstructor): Use uncheckedArgument since
        there is already code that explicitly checks argument count.
        (JSC::callNumberConstructor): Ditto.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorCreate): Small refactoring to not call argument(0)
        three times.

        * runtime/SetConstructor.cpp:
        (JSC::constructSet): Use uncheckedArgument since we are already in a loop
        over arguments.

        * runtime/StringConstructor.cpp:
        (JSC::stringFromCharCodeSlowCase): In a loop.
        (JSC::stringFromCharCode): Already checked count.
        (JSC::constructWithStringConstructor): Ditto.
        (JSC::callStringConstructor): Ditto.
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncConcat): Already checked count.
        * runtime/TestRunnerUtils.cpp:
        (JSC::numberOfDFGCompiles): Ditto.
        (JSC::setNeverInline): Ditto.

2013-09-21  Filip Pizlo  <fpizlo@apple.com>

        Remove the notion that a CallFrame can have a pointer to an InlineCallFrame, since that doesn't happen anymore
        https://bugs.webkit.org/show_bug.cgi?id=121753

        Reviewed by Darin Adler.

        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::bytecodeOffsetFromCodeOriginIndex):
        * interpreter/CallFrame.h:
        * interpreter/Register.h:

2013-09-21  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix the revert.

        * dfg/DFGRepatch.cpp:

2013-09-21  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, revert http://trac.webkit.org/changeset/156235. It won't work on Windows.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::unlink):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resetStubInternal):
        * bytecode/StructureStubInfo.h:
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
        (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
        * dfg/DFGJITCompiler.h:
        * dfg/DFGOSRExitCompiler.h:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * dfg/DFGOperations.h:
        (JSC::DFG::operationNewTypedArrayWithSizeForType):
        (JSC::DFG::operationNewTypedArrayWithOneArgumentForType):
        * dfg/DFGRegisterSet.h: Added.
        (JSC::DFG::RegisterSet::RegisterSet):
        (JSC::DFG::RegisterSet::asPOD):
        (JSC::DFG::RegisterSet::copyInfo):
        (JSC::DFG::RegisterSet::set):
        (JSC::DFG::RegisterSet::setGPRByIndex):
        (JSC::DFG::RegisterSet::clear):
        (JSC::DFG::RegisterSet::get):
        (JSC::DFG::RegisterSet::getGPRByIndex):
        (JSC::DFG::RegisterSet::getFreeGPR):
        (JSC::DFG::RegisterSet::setFPRByIndex):
        (JSC::DFG::RegisterSet::getFPRByIndex):
        (JSC::DFG::RegisterSet::setByIndex):
        (JSC::DFG::RegisterSet::getByIndex):
        (JSC::DFG::RegisterSet::numberOfSetGPRs):
        (JSC::DFG::RegisterSet::numberOfSetFPRs):
        (JSC::DFG::RegisterSet::numberOfSetRegisters):
        (JSC::DFG::RegisterSet::setBit):
        (JSC::DFG::RegisterSet::clearBit):
        (JSC::DFG::RegisterSet::getBit):
        * dfg/DFGRepatch.cpp: Added.
        (JSC::DFG::repatchCall):
        (JSC::DFG::repatchByIdSelfAccess):
        (JSC::DFG::addStructureTransitionCheck):
        (JSC::DFG::replaceWithJump):
        (JSC::DFG::emitRestoreScratch):
        (JSC::DFG::linkRestoreScratch):
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::repatchGetByID):
        (JSC::DFG::getPolymorphicStructureList):
        (JSC::DFG::patchJumpToGetByIdStub):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::buildGetByIDList):
        (JSC::DFG::appropriateGenericPutByIdFunction):
        (JSC::DFG::appropriateListBuildingPutByIdFunction):
        (JSC::DFG::emitPutReplaceStub):
        (JSC::DFG::emitPutTransitionStub):
        (JSC::DFG::tryCachePutByID):
        (JSC::DFG::repatchPutByID):
        (JSC::DFG::tryBuildPutByIdList):
        (JSC::DFG::buildPutByIdList):
        (JSC::DFG::tryRepatchIn):
        (JSC::DFG::repatchIn):
        (JSC::DFG::linkSlowFor):
        (JSC::DFG::linkFor):
        (JSC::DFG::linkClosureCall):
        (JSC::DFG::resetGetByID):
        (JSC::DFG::resetPutByID):
        (JSC::DFG::resetIn):
        * dfg/DFGRepatch.h: Added.
        (JSC::DFG::resetGetByID):
        (JSC::DFG::resetPutByID):
        (JSC::DFG::resetIn):
        * dfg/DFGScratchRegisterAllocator.h: Added.
        (JSC::DFG::ScratchRegisterAllocator::ScratchRegisterAllocator):
        (JSC::DFG::ScratchRegisterAllocator::lock):
        (JSC::DFG::ScratchRegisterAllocator::allocateScratch):
        (JSC::DFG::ScratchRegisterAllocator::allocateScratchGPR):
        (JSC::DFG::ScratchRegisterAllocator::allocateScratchFPR):
        (JSC::DFG::ScratchRegisterAllocator::didReuseRegisters):
        (JSC::DFG::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
        (JSC::DFG::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
        (JSC::DFG::ScratchRegisterAllocator::desiredScratchBufferSize):
        (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer):
        (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::writeBarrier):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeCompare):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
        (JSC::DFG::SpeculativeJIT::compare):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::emitPointerValidation):
        (JSC::DFG::throwExceptionFromCallSlowPathGenerator):
        (JSC::DFG::slowPathFor):
        (JSC::DFG::linkForThunkGenerator):
        (JSC::DFG::linkCallThunkGenerator):
        (JSC::DFG::linkConstructThunkGenerator):
        (JSC::DFG::linkClosureCallThunkGenerator):
        (JSC::DFG::virtualForThunkGenerator):
        (JSC::DFG::virtualCallThunkGenerator):
        (JSC::DFG::virtualConstructThunkGenerator):
        * dfg/DFGThunks.h:
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
        * ftl/FTLOSRExitCompiler.h:
        * jit/AssemblyHelpers.h:
        * jit/JIT.cpp:
        (JSC::JIT::linkFor):
        (JSC::JIT::linkSlowCall):
        * jit/JITCall.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::privateCompileClosureCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::privateCompileClosureCall):
        * jit/JITOperationWrappers.h: Removed.
        * jit/JITOperations.cpp: Removed.
        * jit/JITOperations.h: Removed.
        * jit/RegisterSet.h: Removed.
        * jit/Repatch.cpp: Removed.
        * jit/Repatch.h: Removed.
        * jit/ScratchRegisterAllocator.h: Removed.
        * jit/ThunkGenerators.cpp:
        (JSC::generateSlowCaseFor):
        (JSC::linkForGenerator):
        (JSC::linkCallGenerator):
        (JSC::linkConstructGenerator):
        (JSC::linkClosureCallGenerator):
        (JSC::virtualForGenerator):
        (JSC::virtualCallGenerator):
        (JSC::virtualConstructGenerator):
        * jit/ThunkGenerators.h:

2013-09-21  Filip Pizlo  <fpizlo@apple.com>

        Move DFG inline caching logic into jit/
        https://bugs.webkit.org/show_bug.cgi?id=121749

        Rubber stamped by Sam Weinig.
        
        We want to get rid of the baseline JIT's inline caching machinery and have it use the
        DFG's instead. But before we do that we need to move the DFG's inline caching machine
        out from behind its ENABLE(DFG_JIT) guards and make it available to the whole system.
        This patch does that:
        
        - dfg/DFGRepatch becomes jit/Repatch.
        
        - The thunks used by the DFG IC go into jit/ThunkGenerators, instead of dfg/DFGThunks.
        
        - The operations used by the DFG IC go into jit/JITOperations, instead of
          dfg/DFGOperations.
        
        - The old JIT's thunk generators for calls are renamed to reduce confusion. Previously
          it was easy to know which generators belong to which JIT because the old JIT used
          JSC::virtualCallBlah and the DFG used JSC::DFG::virtualCallBlah, but that's not the
          case anymore. Note that the old JIT's thunk generators will die in a future patch.
        
        No functional changes beyond those moves.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::unlink):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resetStubInternal):
        * bytecode/StructureStubInfo.h:
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
        (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
        * dfg/DFGJITCompiler.h:
        * dfg/DFGOSRExitCompiler.h:
        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * dfg/DFGOperations.h:
        (JSC::DFG::operationNewTypedArrayWithSizeForType):
        (JSC::DFG::operationNewTypedArrayWithOneArgumentForType):
        * dfg/DFGRegisterSet.h: Removed.
        * dfg/DFGRepatch.cpp: Removed.
        * dfg/DFGRepatch.h: Removed.
        * dfg/DFGScratchRegisterAllocator.h: Removed.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeCompare):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
        (JSC::DFG::SpeculativeJIT::compare):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGThunks.cpp:
        * dfg/DFGThunks.h:
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::writeBarrier):
        * jit/JIT.cpp:
        (JSC::JIT::linkFor):
        (JSC::JIT::linkSlowCall):
        * jit/JITCall.cpp:
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::privateCompileClosureCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::privateCompileClosureCall):
        * jit/JITOperationWrappers.h: Added.
        * jit/JITOperations.cpp: Added.
        * jit/JITOperations.h: Added.
        * jit/RegisterSet.h: Added.
        (JSC::RegisterSet::RegisterSet):
        (JSC::RegisterSet::asPOD):
        (JSC::RegisterSet::copyInfo):
        (JSC::RegisterSet::set):
        (JSC::RegisterSet::setGPRByIndex):
        (JSC::RegisterSet::clear):
        (JSC::RegisterSet::get):
        (JSC::RegisterSet::getGPRByIndex):
        (JSC::RegisterSet::getFreeGPR):
        (JSC::RegisterSet::setFPRByIndex):
        (JSC::RegisterSet::getFPRByIndex):
        (JSC::RegisterSet::setByIndex):
        (JSC::RegisterSet::getByIndex):
        (JSC::RegisterSet::numberOfSetGPRs):
        (JSC::RegisterSet::numberOfSetFPRs):
        (JSC::RegisterSet::numberOfSetRegisters):
        (JSC::RegisterSet::setBit):
        (JSC::RegisterSet::clearBit):
        (JSC::RegisterSet::getBit):
        * jit/Repatch.cpp: Added.
        (JSC::repatchCall):
        (JSC::repatchByIdSelfAccess):
        (JSC::addStructureTransitionCheck):
        (JSC::replaceWithJump):
        (JSC::emitRestoreScratch):
        (JSC::linkRestoreScratch):
        (JSC::generateProtoChainAccessStub):
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::getPolymorphicStructureList):
        (JSC::patchJumpToGetByIdStub):
        (JSC::tryBuildGetByIDList):
        (JSC::buildGetByIDList):
        (JSC::appropriateGenericPutByIdFunction):
        (JSC::appropriateListBuildingPutByIdFunction):
        (JSC::emitPutReplaceStub):
        (JSC::emitPutTransitionStub):
        (JSC::tryCachePutByID):
        (JSC::repatchPutByID):
        (JSC::tryBuildPutByIdList):
        (JSC::buildPutByIdList):
        (JSC::tryRepatchIn):
        (JSC::repatchIn):
        (JSC::linkSlowFor):
        (JSC::linkFor):
        (JSC::linkClosureCall):
        (JSC::resetGetByID):
        (JSC::resetPutByID):
        (JSC::resetIn):
        * jit/Repatch.h: Added.
        (JSC::resetGetByID):
        (JSC::resetPutByID):
        (JSC::resetIn):
        * jit/ScratchRegisterAllocator.h: Added.
        (JSC::ScratchRegisterAllocator::ScratchRegisterAllocator):
        (JSC::ScratchRegisterAllocator::lock):
        (JSC::ScratchRegisterAllocator::allocateScratch):
        (JSC::ScratchRegisterAllocator::allocateScratchGPR):
        (JSC::ScratchRegisterAllocator::allocateScratchFPR):
        (JSC::ScratchRegisterAllocator::didReuseRegisters):
        (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
        (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
        (JSC::ScratchRegisterAllocator::desiredScratchBufferSize):
        (JSC::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer):
        (JSC::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer):
        * jit/ThunkGenerators.cpp:
        (JSC::oldStyleGenerateSlowCaseFor):
        (JSC::oldStyleLinkForGenerator):
        (JSC::oldStyleLinkCallGenerator):
        (JSC::oldStyleLinkConstructGenerator):
        (JSC::oldStyleLinkClosureCallGenerator):
        (JSC::oldStyleVirtualForGenerator):
        (JSC::oldStyleVirtualCallGenerator):
        (JSC::oldStyleVirtualConstructGenerator):
        (JSC::emitPointerValidation):
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::slowPathFor):
        (JSC::linkForThunkGenerator):
        (JSC::linkCallThunkGenerator):
        (JSC::linkConstructThunkGenerator):
        (JSC::linkClosureCallThunkGenerator):
        (JSC::virtualForThunkGenerator):
        (JSC::virtualCallThunkGenerator):
        (JSC::virtualConstructThunkGenerator):
        * jit/ThunkGenerators.h:

2013-09-21  Anders Carlsson  <andersca@apple.com>

        Fix the non-DFG build.

        * interpreter/Interpreter.cpp:
        (JSC::unwindCallFrame):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::r):

2013-09-21  Filip Pizlo  <fpizlo@apple.com>

        Get rid of IsInlinedCodeTag and its associated methods since it's unused
        https://bugs.webkit.org/show_bug.cgi?id=121737

        Reviewed by Sam Weinig.
        
        This was meant to be easy, but I kept wondering if it was safe to remove the
        inline call frame check in Arguments::tearOff(). The check was clearly dead
        since the bit wasn't being set anywhere.
        
        It turns out that the unwindCallFrame() function was relying on tearOff()
        doing the right thing for inlined code, but it wasn't even passing it an
        inline call frame. I fixed this by having unwindCallFrame() inlining check,
        while also making sure that the code uses the right operand index for the
        arguments register.

        * interpreter/CallFrame.h:
        * interpreter/CallFrameInlines.h:
        * interpreter/Interpreter.cpp:
        (JSC::unwindCallFrame):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::r):
        * interpreter/StackVisitor.h:
        * runtime/Arguments.cpp:
        (JSC::Arguments::tearOff):

2013-09-20  Mark Hahnenberg  <mhahnenberg@apple.com>

        (un)shiftCountWithAnyIndexingType will start over in the middle of copying if it sees a hole
        https://bugs.webkit.org/show_bug.cgi?id=121717

        Reviewed by Oliver Hunt.

        This bug caused the array to become corrupted. We now check for holes before we start moving things, 
        and start moving things only once we've determined that there are none.

        * runtime/JSArray.cpp:
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):

2013-09-20  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r156047): WebCore hangs inside JSC::toInt32(double)
        https://bugs.webkit.org/show_bug.cgi?id=121648

        Reviewed by Mark Hahnenberg.
        
        The Int52<->StrictInt52 conversion did the opposite fill() than what it was
        supposed to. For example when converting a Int52 to a StrictInt52 it would fill
        as Int52, and vice-versa.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):

2013-09-20  Oliver Hunt  <oliver@apple.com>

        REGRESSION(r153215): New iCloud site crashes
        https://bugs.webkit.org/show_bug.cgi?id=121710

        Reviewed by Filip Pizlo.

        Don't claim to be able to rely on the arguments structure, use the Arguments
        speculation type

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):

2013-09-20  Mark Hahnenberg  <mhahnenberg@apple.com>

        Clobberize phase forgets to indicate that it writes GCState for several node types
        https://bugs.webkit.org/show_bug.cgi?id=121702

        Reviewed by Oliver Hunt.

        Added read and write for GCState to the nodes that could end up allocating (and thereby
        cause a garbage collection).

        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):

2013-09-19  Filip Pizlo  <fpizlo@apple.com>

        Move CCallHelpers and AssemblyHelpers into jit/ and have JSInterfaceJIT use them
        https://bugs.webkit.org/show_bug.cgi?id=121637

        Rubber stamped by Michael Saboff.
        
        Also moved GPRInfo/FPRInfo into jit/. Rolling back in after fixing JIT-only build
        and tests.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::dumpInContext):
        * dfg/DFGAssemblyHelpers.cpp: Removed.
        * dfg/DFGAssemblyHelpers.h: Removed.
        * dfg/DFGBinarySwitch.h:
        * dfg/DFGByteCodeParser.cpp:
        * dfg/DFGCCallHelpers.h: Removed.
        * dfg/DFGDisassembler.cpp:
        * dfg/DFGFPRInfo.h: Removed.
        * dfg/DFGGPRInfo.h: Removed.
        * dfg/DFGGraph.cpp:
        * dfg/DFGGraph.h:
        * dfg/DFGJITCompiler.h:
        * dfg/DFGOSRExit.cpp:
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitCompiler.h:
        * dfg/DFGOSRExitCompilerCommon.h:
        * dfg/DFGRegisterBank.h:
        * dfg/DFGRegisterSet.h:
        * dfg/DFGRepatch.cpp:
        * dfg/DFGSilentRegisterSavePlan.h:
        * dfg/DFGThunks.cpp:
        * dfg/DFGVariableEvent.cpp:
        * ftl/FTLCArgumentGetter.h:
        (JSC::FTL::CArgumentGetter::CArgumentGetter):
        (JSC::FTL::CArgumentGetter::loadNext8):
        (JSC::FTL::CArgumentGetter::loadNext32):
        (JSC::FTL::CArgumentGetter::loadNext64):
        (JSC::FTL::CArgumentGetter::loadNextPtr):
        (JSC::FTL::CArgumentGetter::loadNextDouble):
        * ftl/FTLCompile.cpp:
        * ftl/FTLExitThunkGenerator.h:
        * ftl/FTLLink.cpp:
        * ftl/FTLThunks.cpp:
        * jit/AssemblyHelpers.cpp: Copied from Source/JavaScriptCore/dfg/DFGAssemblyHelpers.cpp.
        * jit/AssemblyHelpers.h: Copied from Source/JavaScriptCore/dfg/DFGAssemblyHelpers.h.
        (JSC::AssemblyHelpers::AssemblyHelpers):
        (JSC::AssemblyHelpers::debugCall):
        * jit/CCallHelpers.h: Copied from Source/JavaScriptCore/dfg/DFGCCallHelpers.h.
        * jit/FPRInfo.h: Copied from Source/JavaScriptCore/dfg/DFGFPRInfo.h.
        (WTF::printInternal):
        * jit/GPRInfo.h: Copied from Source/JavaScriptCore/dfg/DFGGPRInfo.h.
        (WTF::printInternal):
        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::JSInterfaceJIT):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        (JSC::SpecializedThunkJIT::finalize):
        * jit/ThunkGenerators.cpp:
        (JSC::linkForGenerator):
        (JSC::virtualForGenerator):
        (JSC::stringLengthTrampolineGenerator):
        (JSC::nativeForGenerator):
        (JSC::arityFixup):
        (JSC::charCodeAtThunkGenerator):
        (JSC::charAtThunkGenerator):
        (JSC::fromCharCodeThunkGenerator):
        (JSC::sqrtThunkGenerator):
        (JSC::floorThunkGenerator):
        (JSC::ceilThunkGenerator):
        (JSC::roundThunkGenerator):
        (JSC::expThunkGenerator):
        (JSC::logThunkGenerator):
        (JSC::absThunkGenerator):
        (JSC::powThunkGenerator):
        (JSC::imulThunkGenerator):
        * llint/LLIntThunks.cpp:
        (JSC::LLInt::generateThunkWithJumpTo):
        * runtime/JSCJSValue.h:

2013-09-20  Allan Sandfeld Jensen  <allan.jensen@digia.com>

        Inline method exported
        https://bugs.webkit.org/show_bug.cgi?id=121664

        Reviewed by Darin Adler.

        WatchDog::didFire() is marked as an exported symbol eventhough it is
        defined inline. This breaks the build on MinGW since it results in dllimport
        being declared on a definition.

        * runtime/Watchdog.h:
        (JSC::Watchdog::didFire):

2013-09-20  Patrick Gansterer  <paroga@webkit.org>

        [CMake] Use COMPILE_DEFINITIONS target property for setting BUILDING_* defines
        https://bugs.webkit.org/show_bug.cgi?id=121672

        Reviewed by Gyuyoung Kim.

        Since the scope of add_definitions() is always a whole file, we need to use
        target properties instead to set definitions only for specific targets.

        * CMakeLists.txt:

2013-09-19  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r156120.
        http://trac.webkit.org/changeset/156120
        https://bugs.webkit.org/show_bug.cgi?id=121651

        Broke windows runtime and all tests (Requested by bfulgham on
        #webkit).

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::dumpInContext):
        * dfg/DFGAssemblyHelpers.cpp: Renamed from Source/JavaScriptCore/jit/AssemblyHelpers.cpp.
        (JSC::DFG::AssemblyHelpers::executableFor):
        (JSC::DFG::AssemblyHelpers::decodedCodeMapFor):
        (JSC::DFG::AssemblyHelpers::setSamplingFlag):
        (JSC::DFG::AssemblyHelpers::clearSamplingFlag):
        (JSC::DFG::AssemblyHelpers::jitAssertIsInt32):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSInt32):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSNumber):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSDouble):
        (JSC::DFG::AssemblyHelpers::jitAssertIsCell):
        (JSC::DFG::AssemblyHelpers::jitAssertHasValidCallFrame):
        * dfg/DFGAssemblyHelpers.h: Renamed from Source/JavaScriptCore/jit/AssemblyHelpers.h.
        (JSC::DFG::AssemblyHelpers::AssemblyHelpers):
        (JSC::DFG::AssemblyHelpers::codeBlock):
        (JSC::DFG::AssemblyHelpers::vm):
        (JSC::DFG::AssemblyHelpers::assembler):
        (JSC::DFG::AssemblyHelpers::preserveReturnAddressAfterCall):
        (JSC::DFG::AssemblyHelpers::restoreReturnAddressBeforeReturn):
        (JSC::DFG::AssemblyHelpers::emitGetFromCallFrameHeaderPtr):
        (JSC::DFG::AssemblyHelpers::emitPutToCallFrameHeader):
        (JSC::DFG::AssemblyHelpers::emitPutImmediateToCallFrameHeader):
        (JSC::DFG::AssemblyHelpers::branchIfNotCell):
        (JSC::DFG::AssemblyHelpers::addressFor):
        (JSC::DFG::AssemblyHelpers::tagFor):
        (JSC::DFG::AssemblyHelpers::payloadFor):
        (JSC::DFG::AssemblyHelpers::branchIfNotObject):
        (JSC::DFG::AssemblyHelpers::selectScratchGPR):
        (JSC::DFG::AssemblyHelpers::debugCall):
        (JSC::DFG::AssemblyHelpers::jitAssertIsInt32):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSInt32):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSNumber):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSDouble):
        (JSC::DFG::AssemblyHelpers::jitAssertIsCell):
        (JSC::DFG::AssemblyHelpers::jitAssertHasValidCallFrame):
        (JSC::DFG::AssemblyHelpers::boxDouble):
        (JSC::DFG::AssemblyHelpers::unboxDouble):
        (JSC::DFG::AssemblyHelpers::boxInt52):
        (JSC::DFG::AssemblyHelpers::emitExceptionCheck):
        (JSC::DFG::AssemblyHelpers::emitCount):
        (JSC::DFG::AssemblyHelpers::globalObjectFor):
        (JSC::DFG::AssemblyHelpers::strictModeFor):
        (JSC::DFG::AssemblyHelpers::baselineCodeBlockFor):
        (JSC::DFG::AssemblyHelpers::baselineCodeBlock):
        (JSC::DFG::AssemblyHelpers::argumentsRegisterFor):
        (JSC::DFG::AssemblyHelpers::symbolTableFor):
        (JSC::DFG::AssemblyHelpers::offsetOfLocals):
        (JSC::DFG::AssemblyHelpers::offsetOfArgumentsIncludingThis):
        * dfg/DFGBinarySwitch.h:
        * dfg/DFGByteCodeParser.cpp:
        * dfg/DFGCCallHelpers.h: Renamed from Source/JavaScriptCore/jit/CCallHelpers.h.
        (JSC::DFG::CCallHelpers::CCallHelpers):
        (JSC::DFG::CCallHelpers::resetCallArguments):
        (JSC::DFG::CCallHelpers::addCallArgument):
        (JSC::DFG::CCallHelpers::setupArguments):
        (JSC::DFG::CCallHelpers::setupArgumentsExecState):
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        (JSC::DFG::CCallHelpers::setupTwoStubArgs):
        (JSC::DFG::CCallHelpers::setupStubArguments):
        (JSC::DFG::CCallHelpers::setupResults):
        * dfg/DFGDisassembler.cpp:
        * dfg/DFGFPRInfo.h: Renamed from Source/JavaScriptCore/jit/FPRInfo.h.
        (JSC::DFG::FPRInfo::toRegister):
        (JSC::DFG::FPRInfo::toIndex):
        (JSC::DFG::FPRInfo::toArgumentRegister):
        (JSC::DFG::FPRInfo::debugName):
        * dfg/DFGGPRInfo.h: Renamed from Source/JavaScriptCore/jit/GPRInfo.h.
        (JSC::DFG::JSValueRegs::JSValueRegs):
        (JSC::DFG::JSValueRegs::payloadOnly):
        (JSC::DFG::JSValueRegs::operator!):
        (JSC::DFG::JSValueRegs::gpr):
        (JSC::DFG::JSValueRegs::payloadGPR):
        (JSC::DFG::JSValueSource::JSValueSource):
        (JSC::DFG::JSValueSource::unboxedCell):
        (JSC::DFG::JSValueSource::operator!):
        (JSC::DFG::JSValueSource::isAddress):
        (JSC::DFG::JSValueSource::offset):
        (JSC::DFG::JSValueSource::base):
        (JSC::DFG::JSValueSource::gpr):
        (JSC::DFG::JSValueSource::asAddress):
        (JSC::DFG::JSValueSource::notAddress):
        (JSC::DFG::JSValueRegs::tagGPR):
        (JSC::DFG::JSValueSource::tagGPR):
        (JSC::DFG::JSValueSource::payloadGPR):
        (JSC::DFG::JSValueSource::hasKnownTag):
        (JSC::DFG::JSValueSource::tag):
        (JSC::DFG::GPRInfo::toRegister):
        (JSC::DFG::GPRInfo::toIndex):
        (JSC::DFG::GPRInfo::debugName):
        (JSC::DFG::GPRInfo::toArgumentRegister):
        * dfg/DFGGraph.cpp:
        * dfg/DFGGraph.h:
        * dfg/DFGJITCompiler.h:
        * dfg/DFGOSRExit.cpp:
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitCompiler.h:
        * dfg/DFGOSRExitCompilerCommon.h:
        * dfg/DFGRegisterBank.h:
        * dfg/DFGRegisterSet.h:
        * dfg/DFGRepatch.cpp:
        * dfg/DFGSilentRegisterSavePlan.h:
        * dfg/DFGThunks.cpp:
        * dfg/DFGVariableEvent.cpp:
        * ftl/FTLCArgumentGetter.h:
        (JSC::FTL::CArgumentGetter::CArgumentGetter):
        (JSC::FTL::CArgumentGetter::loadNext8):
        (JSC::FTL::CArgumentGetter::loadNext32):
        (JSC::FTL::CArgumentGetter::loadNext64):
        (JSC::FTL::CArgumentGetter::loadNextPtr):
        (JSC::FTL::CArgumentGetter::loadNextDouble):
        * ftl/FTLCompile.cpp:
        * ftl/FTLExitThunkGenerator.h:
        * ftl/FTLLink.cpp:
        * ftl/FTLThunks.cpp:
        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::preserveReturnAddressAfterCall):
        (JSC::JSInterfaceJIT::restoreReturnAddressBeforeReturn):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        (JSC::SpecializedThunkJIT::finalize):
        * jit/ThunkGenerators.cpp:
        (JSC::linkForGenerator):
        (JSC::virtualForGenerator):
        (JSC::stringLengthTrampolineGenerator):
        (JSC::nativeForGenerator):
        (JSC::arityFixup):
        (JSC::charCodeAtThunkGenerator):
        (JSC::charAtThunkGenerator):
        (JSC::fromCharCodeThunkGenerator):
        (JSC::sqrtThunkGenerator):
        (JSC::floorThunkGenerator):
        (JSC::ceilThunkGenerator):
        (JSC::roundThunkGenerator):
        (JSC::expThunkGenerator):
        (JSC::logThunkGenerator):
        (JSC::absThunkGenerator):
        (JSC::powThunkGenerator):
        (JSC::imulThunkGenerator):
        * llint/LLIntThunks.cpp:
        (JSC::LLInt::generateThunkWithJumpTo):
        * runtime/JSCJSValue.h:

2013-09-19  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix Windows build part 2. m_jitCodeMap should always be there.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::jitCodeMap):

2013-09-19  Filip Pizlo  <fpizlo@apple.com>

        Remove some of the tautologies in DFGRepatch function naming.

        Rubber stamped by Mark Hahnenberg.
        
        For example change DFG::dfgLinkFor() to be DFG::linkFor().

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resetStubInternal):
        * dfg/DFGOperations.cpp:
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::repatchCall):
        (JSC::DFG::repatchByIdSelfAccess):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::repatchGetByID):
        (JSC::DFG::buildGetByIDList):
        (JSC::DFG::tryCachePutByID):
        (JSC::DFG::repatchPutByID):
        (JSC::DFG::buildPutByIdList):
        (JSC::DFG::repatchIn):
        (JSC::DFG::linkFor):
        (JSC::DFG::linkSlowFor):
        (JSC::DFG::linkClosureCall):
        (JSC::DFG::resetGetByID):
        (JSC::DFG::resetPutByID):
        (JSC::DFG::resetIn):
        * dfg/DFGRepatch.h:
        (JSC::DFG::resetGetByID):
        (JSC::DFG::resetPutByID):
        (JSC::DFG::resetIn):

2013-09-19  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix Windows build. ScratchBuffer should always be available regardless of
        ENABLE_DFG_JIT.

        * runtime/VM.h:

2013-09-19  Daniel Bates  <dabates@apple.com>

        [iOS] Add more iOS logic to the JavaScriptCore build configuration files
        https://bugs.webkit.org/show_bug.cgi?id=121635

        Reviewed by Geoffrey Garen.

        Towards building JavaScriptCore for both OS X and iOS using the same
        set of configuration files, add more iOS logic.

        * Configurations/Base.xcconfig:
        * Configurations/JSC.xcconfig:
        * Configurations/JavaScriptCore.xcconfig:
        * Configurations/ToolExecutable.xcconfig:

2013-09-19  Filip Pizlo  <fpizlo@apple.com>

        Move CCallHelpers and AssemblyHelpers into jit/ and have JSInterfaceJIT use them
        https://bugs.webkit.org/show_bug.cgi?id=121637

        Rubber stamped by Michael Saboff.
        
        Also moved GPRInfo/FPRInfo into jit/.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::dumpInContext):
        * dfg/DFGAssemblyHelpers.cpp: Removed.
        * dfg/DFGAssemblyHelpers.h: Removed.
        * dfg/DFGBinarySwitch.h:
        * dfg/DFGByteCodeParser.cpp:
        * dfg/DFGCCallHelpers.h: Removed.
        * dfg/DFGDisassembler.cpp:
        * dfg/DFGFPRInfo.h: Removed.
        * dfg/DFGGPRInfo.h: Removed.
        * dfg/DFGGraph.cpp:
        * dfg/DFGGraph.h:
        * dfg/DFGJITCompiler.h:
        * dfg/DFGOSRExit.cpp:
        * dfg/DFGOSRExit.h:
        * dfg/DFGOSRExitCompiler.h:
        * dfg/DFGOSRExitCompilerCommon.h:
        * dfg/DFGRegisterBank.h:
        * dfg/DFGRegisterSet.h:
        * dfg/DFGRepatch.cpp:
        * dfg/DFGSilentRegisterSavePlan.h:
        * dfg/DFGThunks.cpp:
        * dfg/DFGVariableEvent.cpp:
        * ftl/FTLCArgumentGetter.h:
        (JSC::FTL::CArgumentGetter::CArgumentGetter):
        (JSC::FTL::CArgumentGetter::loadNext8):
        (JSC::FTL::CArgumentGetter::loadNext32):
        (JSC::FTL::CArgumentGetter::loadNext64):
        (JSC::FTL::CArgumentGetter::loadNextPtr):
        (JSC::FTL::CArgumentGetter::loadNextDouble):
        * ftl/FTLCompile.cpp:
        * ftl/FTLExitThunkGenerator.h:
        * ftl/FTLLink.cpp:
        * ftl/FTLThunks.cpp:
        * jit/AssemblyHelpers.cpp: Copied from Source/JavaScriptCore/dfg/DFGAssemblyHelpers.cpp.
        * jit/AssemblyHelpers.h: Copied from Source/JavaScriptCore/dfg/DFGAssemblyHelpers.h.
        (JSC::AssemblyHelpers::AssemblyHelpers):
        (JSC::AssemblyHelpers::debugCall):
        * jit/CCallHelpers.h: Copied from Source/JavaScriptCore/dfg/DFGCCallHelpers.h.
        * jit/FPRInfo.h: Copied from Source/JavaScriptCore/dfg/DFGFPRInfo.h.
        (WTF::printInternal):
        * jit/GPRInfo.h: Copied from Source/JavaScriptCore/dfg/DFGGPRInfo.h.
        (WTF::printInternal):
        * jit/JIT.cpp:
        (JSC::JIT::JIT):
        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::JSInterfaceJIT):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        (JSC::SpecializedThunkJIT::finalize):
        * jit/ThunkGenerators.cpp:
        (JSC::linkForGenerator):
        (JSC::virtualForGenerator):
        (JSC::stringLengthTrampolineGenerator):
        (JSC::nativeForGenerator):
        (JSC::arityFixup):
        (JSC::charCodeAtThunkGenerator):
        (JSC::charAtThunkGenerator):
        (JSC::fromCharCodeThunkGenerator):
        (JSC::sqrtThunkGenerator):
        (JSC::floorThunkGenerator):
        (JSC::ceilThunkGenerator):
        (JSC::roundThunkGenerator):
        (JSC::expThunkGenerator):
        (JSC::logThunkGenerator):
        (JSC::absThunkGenerator):
        (JSC::powThunkGenerator):
        (JSC::imulThunkGenerator):
        * llint/LLIntThunks.cpp:
        (JSC::LLInt::generateThunkWithJumpTo):
        * runtime/JSCJSValue.h:

2013-09-19  Daniel Bates  <dabates@apple.com>

        [iOS] Substitute UNREACHABLE_FOR_PLATFORM() for RELEASE_ASSERT_NOT_REACHED()

        Rubber-stamped by Joseph Pecoraro.

        Use UNREACHABLE_FOR_PLATFORM() instead of RELEASE_ASSERT_NOT_REACHED() in
        the non-x86/x86-64 variant of JIT::emitSlow_op_mod() so as to avoid a missing
        noreturn warning in Clang while simultaneously asserting unreachable code.

        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitSlow_op_mod):

2013-09-19  Michael Saboff  <msaboff@apple.com>

        JSC: X86 disassembler shows 16, 32 and 64 bit displacements as unsigned
        https://bugs.webkit.org/show_bug.cgi?id=121625

        Rubber-stamped by Filip Pizlo.

        Chenged 16, 32 and 64 bit offsets to be signed.  Kept the original tab indented
        spacing to match the rest of the file.

        * disassembler/udis86/udis86_syn-att.c:
        (gen_operand):

2013-09-19  Daniel Bates  <dabates@apple.com>

        Remove names of unused arguments from the non-x86/x86-64 function prototype
        for JIT::emitSlow_op_mod()

        Rubber-stamped by Ryosuke Niwa.

        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitSlow_op_mod):

2013-09-18  Sam Weinig  <sam@webkit.org>

        Replace use of OwnArrayPtr<Foo> with std::unique_ptr<Foo[]> in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=121583

        Reviewed by Anders Carlsson.

        * API/JSStringRefCF.cpp:
        (JSStringCreateWithCFString):
        * API/JSStringRefQt.cpp:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::dumpDisassembly):
        * runtime/Arguments.cpp:
        (JSC::Arguments::tearOff):
        * runtime/Arguments.h:
        (JSC::Arguments::isTornOff):
        (JSC::Arguments::allocateSlowArguments):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::JSPropertyNameIterator):
        * runtime/JSPropertyNameIterator.h:
        * runtime/JSSegmentedVariableObject.h:
        * runtime/JSVariableObject.h:
        * runtime/PropertyNameArray.h:
        * runtime/RegExp.cpp:
        * runtime/StructureChain.h:
        (JSC::StructureChain::finishCreation):
        * runtime/SymbolTable.h:
        (JSC::SharedSymbolTable::setSlowArguments):

2013-09-18  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed build fix after r156064.

        * jsc.cpp:
        (jscmain): Need a temporary to perform '&' in VS2010.

2013-09-18  Filip Pizlo  <fpizlo@apple.com>

        Give 'jsc' commandline an option to disable deleting the VM.

        Reviewed by Mark Hahnenberg.

        * jsc.cpp:
        (jscmain):
        * runtime/Options.h:

2013-09-18  Anders Carlsson  <andersca@apple.com>

        RefPtrHashMap should work with move only types
        https://bugs.webkit.org/show_bug.cgi?id=121564

        Reviewed by Andreas Kling.

        * runtime/VM.cpp:
        (JSC::VM::addSourceProviderCache):

2013-09-17  Mark Hahnenberg  <mhahnenberg@apple.com>

        Rename OperationInProgress to HeapOperation and move it out of Heap.h into its own header
        https://bugs.webkit.org/show_bug.cgi?id=121534

        Reviewed by Geoffrey Garen.

        OperationInProgress is a silly name. 

        Many parts of the Heap would like to know what HeapOperation is currently underway, but 
        since they are included in Heap.h they can't directly reference HeapOperation if it also 
        lives in Heap.h. The simplest thing to do is to give HeapOperation its own header. While 
        a bit overkill, it simplifies including it wherever its needed.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::updateAllValueProfilePredictions):
        (JSC::CodeBlock::updateAllPredictions):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::updateAllValueProfilePredictions):
        (JSC::CodeBlock::updateAllPredictions):
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
        * bytecode/LazyOperandValueProfile.h:
        * bytecode/ValueProfile.h:
        (JSC::ValueProfileBase::computeUpdatedPrediction):
        * heap/Heap.h:
        * heap/HeapOperation.h: Added.

2013-09-18  Filip Pizlo  <fpizlo@apple.com>

        DFG should support Int52 for local variables
        https://bugs.webkit.org/show_bug.cgi?id=121064

        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):

2013-09-17  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r155771): js/stack-overflow-arrity-catch.html is crashing on non-Mac platforms
        https://bugs.webkit.org/show_bug.cgi?id=121376

        Reviewed by Oliver Hunt.

        Fix stack grow() call for stack growing down.  This should catch running out of stack space before
        we try to move the frame down due to arity mismatch.

        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):

2013-09-18  Andreas Kling  <akling@apple.com>

        YARR: Put UCS2 canonicalization tables in read-only memory.
        <https://webkit.org/b/121547>

        Reviewed by Sam Weinig.

        These tables never mutate so mark them const.

2013-09-18  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r156019 and r156020.
        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).

        * 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:

2013-09-17  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix 32-bit build.

        * runtime/JSCJSValue.h:

2013-09-16  Filip Pizlo  <fpizlo@apple.com>

        DFG should support Int52 for local variables
        https://bugs.webkit.org/show_bug.cgi?id=121064

        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):

2013-09-17  Filip Pizlo  <fpizlo@apple.com>

        Use CheckStructure for checking the types of typed arrays whenever possible
        https://bugs.webkit.org/show_bug.cgi?id=121514

        Reviewed by Oliver Hunt.

        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):
        (JSC::DFG::ArrayMode::refine):
        (JSC::DFG::ArrayMode::originalArrayStructure):
        (JSC::DFG::arrayClassToString):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::ArrayMode):
        (JSC::DFG::ArrayMode::arrayModesWithIndexingShape):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::isOriginalTypedArrayStructure):

2013-09-17  Filip Pizlo  <fpizlo@apple.com>

        DFG should use the (x & 0x7fffffff) trick for doing overflow and neg-zero checks on negation in one go
        https://bugs.webkit.org/show_bug.cgi?id=121520

        Reviewed by Oliver Hunt.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithNegate):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileArithNegate):

2013-09-17  Andreas Kling  <akling@apple.com>

        Pack create_hash_table tables better.
        <https://webkit.org/b/121517>

        Reviewed by Sam Weinig.

        Reduces JavaScriptCore binary size by 4648 bytes.

        * create_hash_table:
        * runtime/Lookup.h:

            Reorder HashTableValue members to avoid unnecessary padding.

2013-09-17  Mark Hahnenberg  <mhahnenberg@apple.com>

        DFG doesn't properly keep scope alive for op_put_to_scope
        https://bugs.webkit.org/show_bug.cgi?id=121519

        Reviewed by Michael Saboff.

        This was a latent bug that can't actually occur in ToT. It was uncovered by causing slow 
        path calls in the baseline JIT for op_put_to_scope in places where we couldn't before (but 
        which were necessary for gen GC).

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

2013-09-17  Filip Pizlo  <fpizlo@apple.com>

        Don't GC while OSR compiling
        https://bugs.webkit.org/show_bug.cgi?id=121513

        Reviewed by Mark Hahnenberg.
        
        Fixes some rare crashes that I see in ConservativeRoots, while in a GC from OSR exit
        compilation.

        * dfg/DFGOSRExitCompiler.cpp:
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):

2013-09-17  Alberto Garcia  <berto@igalia.com>

        Unreviewed make distcheck fix.

        * GNUmakefile.list.am:

2013-09-13  Mark Hahnenberg  <mhahnenberg@apple.com>

        MarkedBlocks shouldn't be put in Allocated state if they didn't produce a FreeList
        https://bugs.webkit.org/show_bug.cgi?id=121236

        Reviewed by Geoffrey Garen.

        Right now, after a collection all MarkedBlocks are in the Marked block state. When lazy sweeping 
        happens, if a block returns an empty free list after being swept, we call didConsumeFreeList(), 
        which moves the block into the Allocated block state. This happens to both the block that was 
        just being allocated out of (i.e. m_currentBlock) as well as any blocks who are completely full. 
        We should distinguish between these two cases: m_currentBlock should transition to 
        Allocated (because we were just allocating out of it) and any subsequent block that returns an 
        empty free list should transition back to the Marked state. This will make the block state more 
        consistent with the actual state the block is in, and it will also allow us to speed up moving 
        all blocks the the Marked state during generational collection.

        Added new RAII-style HeapIterationScope class that notifies the Heap when it is about to be 
        iterated and when iteration has finished. Any clients that need accurate liveness data when 
        iterating over the Heap now need to use a HeapIterationScope so that the state of Heap can 
        be properly restored after they are done iterating. No new GC-allocated objects can be created 
        until this object goes out of scope.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * debugger/Debugger.cpp: 
        (JSC::Debugger::recompileAllJSFunctions): Added HeapIterationScope for the Recompiler iteration.
        * heap/Heap.cpp:
        (JSC::Heap::willStartIterating): Callback used by HeapIterationScope to indicate that iteration of 
        the Heap is about to begin. This will cause cell liveness data to be canonicalized by calling stopAllocating.
        (JSC::Heap::didFinishIterating): Same, but indicates that iteration has finished.
        (JSC::Heap::globalObjectCount): Used HeapIterationScope.
        (JSC::Heap::objectTypeCounts): Ditto.
        (JSC::Heap::markDeadObjects): Ditto.
        (JSC::Heap::zombifyDeadObjects): Ditto.
        * heap/Heap.h:
        * heap/HeapIterationScope.h: Added. New RAII-style object for indicating to the Heap that it's about
        to be iterated or that iteration has finished.
        (JSC::HeapIterationScope::HeapIterationScope):
        (JSC::HeapIterationScope::~HeapIterationScope):
        * heap/HeapStatistics.cpp:
        (JSC::HeapStatistics::showObjectStatistics): Used new HeapIterationScope.
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper): We now treat the case where we have just finished 
        allocating out of the current block differently from the case where we sweep a block and it 
        returns an empty free list. This was the primary point of this patch.
        (JSC::MarkedAllocator::allocateSlowCase): ASSERT that nobody is currently iterating the Heap 
        when allocating.
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::reset): All allocators are reset after every collection. We need to make 
        sure that the m_lastActiveBlock gets cleared, which it might not always because we don't call 
        takeCanonicalizedBlock on blocks in the large allocators.
        (JSC::MarkedAllocator::stopAllocating): We shouldn't already have a last active block,
        so ASSERT as much.
        (JSC::MarkedAllocator::resumeAllocating): Do the opposite of what stopAllocating
        does. So, if we don't have a m_lastActiveBlock then we don't have to worry about undoing anything
        done by stopAllocating. If we do, then we call resumeAllocating on the block, which returns the FreeList
        as it was prior to stopping allocation. We then set the current block to the last active block and 
        clear the last active block. 
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::resumeAllocating): Any block resuming allocation should be in 
        the Marked state, so ASSERT as much. We always allocate a m_newlyAllocated Bitmap if we're
        FreeListed, so if we didn't allocate one then we know we were Marked when allocation was stopped,
        so just return early with an empty FreeList. If we do have a non-null m_newlyAllocated Bitmap
        then we need to be swept in order to rebuild our FreeList.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::didConsumeEmptyFreeList): This is called if we ever sweep a block and get back
        an empty free list. Instead of transitioning to the Allocated state, we now go straight back to the 
        Marked state. This makes sense because we weren't actually allocated out of, so we shouldn't be in 
        the allocated state. Also added some ASSERTs to make sure that we're in the state that we expect: all of
        our mark bits should be set and we should not have a m_newlyAllocated Bitmap.
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::forEachAllocator): Added a new functor-style iteration method so that we can 
        easily iterate over each allocator for, e.g., stopping and resuming allocators without
        duplicating code. 
        (JSC::StopAllocatingFunctor::operator()): New functors for use with forEachAllocator.
        (JSC::MarkedSpace::stopAllocating): Ditto.
        (JSC::ResumeAllocatingFunctor::operator()): Ditto.
        (JSC::MarkedSpace::resumeAllocating): Ditto.
        (JSC::MarkedSpace::willStartIterating): Callback that notifies MarkedSpace that it is being iterated.
        Does some ASSERTs, sets a flag, canonicalizes cell liveness data by calling stopAllocating.
        (JSC::MarkedSpace::didFinishIterating): Ditto, but to signal that iteration has completed.
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::iterationInProgress): Returns true if a HeapIterationScope is currently active.
        (JSC::MarkedSpace::forEachLiveCell): Accepts a HeapIterationScope to enforce the rule that you have to 
        create one prior to iterating over the Heap.
        (JSC::MarkedSpace::forEachDeadCell): Ditto.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::haveABadTime): Changed to use new HeapIterationScope.
        * runtime/VM.cpp:
        (JSC::VM::releaseExecutableMemory): Ditto.

2013-09-16  Filip Pizlo  <fpizlo@apple.com>

        Inlining should work in debug mode (i.e. Executable::newCodeBlock() should call recordParse())
        https://bugs.webkit.org/show_bug.cgi?id=121444

        Reviewed by Mark Hahnenberg.

        * dfg/DFGArgumentPosition.h: Fix a bug discovered by reenabling inlining. ArgumentPosition may point to the non-canonical VariableAccessData but users of someVariable() want the canonical one.
        (JSC::DFG::ArgumentPosition::someVariable):
        * runtime/Executable.cpp: Call recordParse() so that the Executable knows things about itself (like if it has captured variables). Otherwise those fields are uninitialized.
        (JSC::ScriptExecutable::newCodeBlockFor):

2013-09-16  Balazs Kilvady  <kilvadyb@homejinni.com>

        Aligned argument signatures of setupArgumentsWithExecState are missing on MIPS.
        https://bugs.webkit.org/show_bug.cgi?id=121439

        Reviewed by Geoffrey Garen.

        Missing implementations of setupArgumentsWithExecState added.

        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):

2013-09-16  Julien Brianceau  <jbriance@cisco.com>

        [sh4] Fix typo in subp implementation in LLINT.
        https://bugs.webkit.org/show_bug.cgi?id=121438

        Reviewed by Andreas Kling.

        * offlineasm/sh4.rb:

2013-09-16  Julien Brianceau  <jbriance@cisco.com>

        [sh4] Handle subp opcode with 3 operands and bpbeq opcode in LLINT.
        https://bugs.webkit.org/show_bug.cgi?id=121412

        Reviewed by Andreas Kling.

        * offlineasm/sh4.rb:

2013-09-15  Gustavo Noronha Silva  <gns@gnome.org>

        Unreviewed make distcheck fix.

        * GNUmakefile.list.am:

2013-09-15  Filip Pizlo  <fpizlo@apple.com>

        Deoptimize deoptimization: make DFGOSRExitCompiler64.cpp more hackable
        https://bugs.webkit.org/show_bug.cgi?id=121374

        Reviewed by Geoffrey Garen.
        
        This reduces the size of DFGOSRExitCompiler64.cpp by almost 50%, and makes it
        super easy to add new recovery kinds. For recoveries that involve reboxing, it
        allows you to keep most of the code common between the on-stack and in-reg
        cases: they all get funneled through the "load from scratch buffer, convert,
        and then store to stack" logic.
        
        This opens up a bunch of possibilities. It'll make adding Int48 much easier,
        and it probably will come in handy as we do various DFG stack layout changes in
        support of the FTL.

        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::dumpInContext):
        (JSC::ValueRecovery::dump):
        * dfg/DFGOSRExitCompiler.cpp:
        (JSC::DFG::shortOperandsDump):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):

2013-09-14  Filip Pizlo  <fpizlo@apple.com>

        It should be easy to add new nodes that do OSR forward rewiring in both DFG and FTL
        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):

2013-09-14  Filip Pizlo  <fpizlo@apple.com>

        Rename IntegerBranch/IntegerCompare to Int32Branch/Int32Compare.

        Rubber stamped by Mark Hahnenberg.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleInt32Branch):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
        (JSC::DFG::SpeculativeJIT::compare):
        (JSC::DFG::SpeculativeJIT::compileStrictEq):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileInt32Compare):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileInt32Compare):

2013-09-13  Filip Pizlo  <fpizlo@apple.com>

        Rename SpeculativeJIT::integerResult() to int32Result().

        Rubber stamped by Mark Hahnenberg.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
        (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileAdd):
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        (JSC::DFG::SpeculativeJIT::compileArithNegate):
        (JSC::DFG::SpeculativeJIT::compileArithIMul):
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        (JSC::DFG::SpeculativeJIT::compileArithMod):
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::int32Result):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2013-09-13  Michael Saboff  <msaboff@apple.com>

        FTL JIT broke after r155711
        https://bugs.webkit.org/show_bug.cgi?id=121332

        Reviewed by Geoffrey Garen.

        Fixed OSR entry to use the local variable's index instead of its VirtualRegister.
        Initialized ExitArgumentForOperand::m_operand to InvalidVirtualRegister instead of -1.
        Fixed compileCallOrConstruct() to update locals on callframe going down.
        Fixed prepareOSREntry() to grow stack down if needed.

        * ftl/FTLExitArgumentForOperand.h:
        (JSC::FTL::ExitArgumentForOperand::ExitArgumentForOperand):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileExtractOSREntryLocal):
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):

2013-09-13  Anders Carlsson  <andersca@apple.com>

        Avoid a couple of zero-sized fastMalloc calls
        https://bugs.webkit.org/show_bug.cgi?id=121333

        Reviewed by Geoffrey Garen.

        * API/JSStringRefCF.cpp:
        (JSStringCopyCFString):
        Return an empty constant CFStringRef if the JSStringRef is empty.

        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::JSPropertyNameIterator):
        Don't allocate an empty m_jsStrings array if m_jsStringsSize is 0.

2013-09-13  Filip Pizlo  <fpizlo@apple.com>

        DFG AI assumes that ToThis can never return non-object if it is passed an object, and operationToThis will get the wrong value of isStrictMode() if there's inlining
        https://bugs.webkit.org/show_bug.cgi?id=121330

        Reviewed by Mark Hahnenberg and Oliver Hunt.
        
        Also print whether a function is strict mode in debug dumps.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpAssumingJITType):
        * bytecode/CodeOrigin.cpp:
        (JSC::InlineCallFrame::dumpInContext):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2013-09-13  Anders Carlsson  <andersca@apple.com>

        Use nullptr instead of 0 in calls to HashMap::add
        https://bugs.webkit.org/show_bug.cgi?id=121322

        Reviewed by Sam Weinig.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitLoad):
        (JSC::BytecodeGenerator::addStringConstant):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::cellConstant):

2013-09-13  Oliver Hunt  <oliver@apple.com>

        Try to kill initialiser expression in for-in statements
        https://bugs.webkit.org/show_bug.cgi?id=121311

        Reviewed by Gavin Barraclough.

        We'd like to get rid of this pointless initialiser expression
        in for-in statements.  Unfortunately we have to keep the no_in
        variant of expression parsing to avoid ambiguity in the grammar.
        There's a possibility that this will need to be rolled out, but
        we'll need to live on it to see.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ForInNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createForInLoop):
        * parser/NodeConstructors.h:
        (JSC::ForInNode::ForInNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::::parseForStatement):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createForInLoop):

2013-09-12  Michael Saboff  <msaboff@apple.com>

        fourthTier: Change JSStack to grow from high to low addresses
        https://bugs.webkit.org/show_bug.cgi?id=118758

        Reviewed by Oliver Hunt.

        Changed the JSC stack to grow down.  Effectively the JSC stack frame is flipped from
        what it was.  See JSStack.h for the new offsets.  Changed JSStack begin() and end()
        to be getBaseOfStack() and getLimitOfStack().  Most of the changes are address or offset
        calculation changes.  Decoupled a local register ordinal (loop variable or array index)
        from the offset into the callFrame using localToOperand() and the inverse operandToLocal().

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::trustedImm32ForShift):
        (JSC::MacroAssembler::lshiftPtr): Added to create scaled addresses with a negative index
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::lshift64): Added to create scaled addresses with a negative index
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::shlq_i8r): Added to create scaled addresses with a negative index
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/CodeBlock.h:
        (JSC::unmodifiedArgumentsRegister):
        (JSC::CodeBlock::isCaptured):
        * bytecode/CodeOrigin.h:
        (JSC::CodeOrigin::stackOffset):
        * bytecode/Operands.h:
        (JSC::localToOperand):
        (JSC::operandIsLocal):
        (JSC::operandToLocal):
        (JSC::operandIsArgument):
        (JSC::operandToArgument):
        (JSC::argumentToOperand):
        * bytecode/VirtualRegister.h: Made InvalidVirtualRegister a positive value that fits in
        31 bits since it can be placed into the 31 bit field "stackOffset" in struct InlineCallFrame.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::createLazyRegisterIfNecessary):
        (JSC::BytecodeGenerator::newRegister):
        (JSC::BytecodeGenerator::emitNewArray):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::CallArguments::registerOffset):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallArguments::CallArguments):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
        (JSC::DFG::ByteCodeParser::addCall):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGScoreBoard.h:
        (JSC::DFG::ScoreBoard::allocate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callFrameSlot):
        (JSC::DFG::SpeculativeJIT::argumentSlot):
        (JSC::DFG::SpeculativeJIT::callFrameTagSlot):
        (JSC::DFG::SpeculativeJIT::callFramePayloadSlot):
        (JSC::DFG::SpeculativeJIT::argumentTagSlot):
        (JSC::DFG::SpeculativeJIT::argumentPayloadSlot):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::reportValidationContext):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::genericAddSpan):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::frameExtentInternal):
        * interpreter/CallFrame.h:
        (JSC::ExecState::init):
        (JSC::ExecState::argumentOffset):
        (JSC::ExecState::argumentOffsetIncludingThis):
        (JSC::ExecState::argIndexForRegister):
        * interpreter/Interpreter.cpp:
        (JSC::loadVarargs):
        (JSC::Interpreter::dumpRegisters):
        * interpreter/JSStack.cpp:
        (JSC::JSStack::JSStack):
        (JSC::JSStack::~JSStack):
        (JSC::JSStack::growSlowCase):
        (JSC::JSStack::gatherConservativeRoots):
        (JSC::JSStack::releaseExcessCapacity):
        (JSC::JSStack::disableErrorStackReserve):
        * interpreter/JSStack.h:
        (JSC::JSStack::getBaseOfStack):
        (JSC::JSStack::getLimitOfStack):
        (JSC::JSStack::size):
        (JSC::JSStack::end):
        (JSC::JSStack::containsAddress):
        (JSC::JSStack::lowAddress):
        (JSC::JSStack::highAddress):
        (JSC::JSStack::reservationEnd):
        (JSC::JSStack::shrink):
        (JSC::JSStack::grow):
        * interpreter/JSStackInlines.h:
        (JSC::JSStack::getTopOfFrame):
        (JSC::JSStack::pushFrame):
        (JSC::JSStack::popFrame):
        (JSC::JSStack::installTrapsAfterFrame):
        * interpreter/StackVisitor.cpp:
        (JSC::inlinedFrameOffset):
        (JSC::StackVisitor::readInlinedFrame):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITCall.cpp:
        (JSC::JIT::compileLoadVarargs):
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileLoadVarargs):
        (JSC::JIT::compileOpCall):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_activation):
        (JSC::JIT::emit_op_get_argument_by_val):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_argument_by_val):
        * jit/JITStubs.cpp:
        (JSC::throwExceptionFromOpCall):
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/ThunkGenerators.cpp:
        (JSC::arityFixup):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::genericCall):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArgList.cpp:
        (JSC::ArgList::getSlice):
        (JSC::MarkedArgumentBuffer::slowAppend):
        * runtime/ArgList.h:
        (JSC::MarkedArgumentBuffer::MarkedArgumentBuffer):
        (JSC::MarkedArgumentBuffer::slotFor):
        (JSC::MarkedArgumentBuffer::mallocBase):
        (JSC::ArgList::at):
        * runtime/Arguments.cpp:
        (JSC::Arguments::tearOff):
        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/JSActivation.h:
        (JSC::JSActivation::registersOffset):
        (JSC::JSActivation::tearOff):
        (JSC::JSActivation::isValidIndex):
        * runtime/JSArray.h:
        (JSC::constructArrayNegativeIndexed): New method to create an array from registers that grow down.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::globalExec):
        * runtime/JSGlobalObject.h:
        (JSC::constructArrayNegativeIndexed):
        * runtime/JSString.h:
        * runtime/Operations.h:
        (JSC::jsStringFromRegisterArray):
        * runtime/SymbolTable.h:
        (JSC::SharedSymbolTable::captureCount):

2013-09-13  Csaba Osztrogonác  <ossy@webkit.org>

        ARM EABI hardfp buildfix after r155675
        https://bugs.webkit.org/show_bug.cgi?id=121287

        Reviewed by Geoffrey Garen.

        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):

2013-09-13  Youngho Yoo  <youngho33.yoo@lge.com>

        Fixed crash in V8 benchmark suite in ARM,softp,EABI environment. 
        https://bugs.webkit.org/show_bug.cgi?id=117281

        Reviewed by Michael Saboff.

        Fix the missing EABI_32BIT_DUMMY_ARG in FPRReg using callOperation function.

        Test 1 : fast/js/array-with-double-assign.html
        Test 2 : fast/js/array-with-double-push.html

        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):

2013-09-12  Filip Pizlo  <fpizlo@apple.com>

        DFG::Int32Operand and fillInt32() should go away and all uses should be replaced with SpeculateInt32Operand
        https://bugs.webkit.org/show_bug.cgi?id=121268

        Reviewed by Oliver Hunt.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):

2013-09-12  Geoffrey Garen  <ggaren@apple.com>

        Web Inspector shouldn't artificially allocate the arguments object in functions that don't use it
        https://bugs.webkit.org/show_bug.cgi?id=121206
        <rdar://problem/6911886>

        Reviewed by Joseph Pecoraro.

        This is a step toward better tools, and a 23% speedup in a simple
        JavaScript benchmark run with the Web Inspector open.

        We want the Web Inspector to be fast, and we want it to produce reliable
        CPU and memory profiles. We can't do that if just opening the Web Inspector
        incurs huge CPU/memory penalties like the arguments object.

        Also, since use of the 'arguments' identifier is an API for allocating
        an object, I think it's good for the UI to let developers know when
        they've invoked that API and when they haven't.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): No need to allocate the
        arguments object artificially for the debugger's sake. The activation
        object no longer assumes that the stack frame is laid out for one.

        (Long-term, this code will move out of the activation object, into a
        special object for interfacing with the debugger.)

        * runtime/JSActivation.cpp:
        (JSC::JSActivation::getOwnNonIndexPropertyNames):
        (JSC::JSActivation::getOwnPropertySlot): Don't advertise or provide an
        arguments object if the user function didn't include one. The bytecode
        generator will not have laid out the stack frame to support one.

        (Eventually, we do want the Web Inspector to see an arguments
        object in scope in the console. That's a one-line change in JSActivation,
        but it's blocked by https://bugs.webkit.org/show_bug.cgi?id=121208.)

        (JSC::JSActivation::argumentsGetter):
        * runtime/JSActivation.h: Removed this obsolete performance
        work-around. C++ property access to an activation object is no longer
        hot.

2013-09-12  Mark Hahnenberg  <mhahnenberg@apple.com>

        Rolling out r155632

        Broke some tests.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper):
        * heap/MarkedBlock.h:

2013-09-12  Ryosuke Niwa  <rniwa@webkit.org>

        Qt build fix. Add a return to make the compiler happy.

        * dfg/DFGGPRInfo.h:
        (JSC::DFG::JSValueRegs::gpr):

2013-09-12  Filip Pizlo  <fpizlo@apple.com>

        DFG::GenerationInfo init/fill methods shouldn't duplicate a bunch of logic
        https://bugs.webkit.org/show_bug.cgi?id=121253

        Reviewed by Oliver Hunt.

        * dfg/DFGGenerationInfo.h:
        (JSC::DFG::GenerationInfo::initGPR):
        (JSC::DFG::GenerationInfo::initInt32):
        (JSC::DFG::GenerationInfo::initJSValue):
        (JSC::DFG::GenerationInfo::initCell):
        (JSC::DFG::GenerationInfo::initBoolean):
        (JSC::DFG::GenerationInfo::initStorage):
        (JSC::DFG::GenerationInfo::fillGPR):
        (JSC::DFG::GenerationInfo::fillJSValue):
        (JSC::DFG::GenerationInfo::fillCell):
        (JSC::DFG::GenerationInfo::fillInt32):
        (JSC::DFG::GenerationInfo::fillBoolean):
        (JSC::DFG::GenerationInfo::fillStorage):

2013-09-12  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix mispelling (Specualte -> Speculate) that I introduced in an
        earlier patch.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculateInt32Operand::gpr):
        (JSC::DFG::SpeculateStrictInt32Operand::gpr):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32):
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Strict):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32):
        (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Strict):

2013-09-12  Filip Pizlo  <fpizlo@apple.com>

        GPRTemporary's reuse constructor should be templatized to reduce code duplication, and the bool to denote tag or payload should be replaced with an enum
        https://bugs.webkit.org/show_bug.cgi?id=121250

        Reviewed by Oliver Hunt.

        * dfg/DFGGPRInfo.h:
        (JSC::DFG::JSValueRegs::gpr):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::GPRTemporary::GPRTemporary):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileAdd):
        (JSC::DFG::SpeculativeJIT::compileStringEquality):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::JSValueOperand::gpr):
        (JSC::DFG::GPRTemporary::GPRTemporary):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileIntegerCompare):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/JSCJSValue.h:

2013-09-12  Mark Hahnenberg  <mhahnenberg@apple.com>

        MarkedBlocks shouldn't be put in Allocated state if they didn't produce a FreeList
        https://bugs.webkit.org/show_bug.cgi?id=121236

        Reviewed by Geoffrey Garen.

        Right now, after a collection all MarkedBlocks are in the Marked block state. When lazy sweeping 
        happens, if a block returns an empty free list after being swept, we call didConsumeFreeList(), 
        which moves the block into the Allocated block state. This happens to both the block that was 
        just being allocated out of (i.e. m_currentBlock) as well as any blocks who are completely full. 
        We should distinguish between these two cases: m_currentBlock should transition to 
        Allocated (because we were just allocating out of it) and any subsequent block that returns an 
        empty free list should transition back to the Marked state. This will make the block state more 
        consistent with the actual state the block is in, and it will also allow us to speed up moving 
        all blocks to the Marked state during generational collection.

        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::didConsumeEmptyFreeList):

2013-09-12  Mark Lam  <mark.lam@apple.com>

        Change debug hooks to pass sourceID and position info via the DebuggerCallFrame.
        https://bugs.webkit.org/show_bug.cgi?id=121214.

        Reviewed by Geoffrey Garen.

        * debugger/Debugger.h:
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::sourceId):
        (JSC::DebuggerCallFrame::clear):
        * debugger/DebuggerCallFrame.h:
        (JSC::DebuggerCallFrame::DebuggerCallFrame):
        (JSC::DebuggerCallFrame::line):
        (JSC::DebuggerCallFrame::column):
        * interpreter/Interpreter.cpp:
        (JSC::unwindCallFrame):
        (JSC::Interpreter::unwind):
        (JSC::Interpreter::debug):

2013-09-12  Csaba Osztrogonác  <ossy@webkit.org>

        Add back c++11 features removed by buildfixes after all ports did the switch
        https://bugs.webkit.org/show_bug.cgi?id=119266

        Reviewed by Anders Carlsson.

        * bytecode/GetByIdStatus.h:
        (JSC::GetByIdStatus::GetByIdStatus):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::~Worklist):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::codeType):
        (JSC::StackVisitor::Frame::functionName):
        (JSC::StackVisitor::Frame::sourceURL):
        (JSC::StackVisitor::Frame::print):

2013-09-12  Mikhail Pozdnyakov  <mikhail.pozdnyakov@intel.com>

        Remove home-brewed nullptr
        https://bugs.webkit.org/show_bug.cgi?id=119624

        Reviewed by Anders Carlsson.

        The standard C++11 nullptr and std::nullptr_t type should be used now.

        * heap/PassWeak.h:
        * heap/Weak.h:

2013-09-11  Filip Pizlo  <fpizlo@apple.com>

        Rename initInteger() to initInt32()

        Rubber stamped by Mark Hahnenberg.

        * dfg/DFGGenerationInfo.h:
        (JSC::DFG::GenerationInfo::initInt32):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::integerResult):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2013-09-11  Filip Pizlo  <fpizlo@apple.com>

        Rename IntegerOperand to Int32Operand and fillInteger() to fillInt32().

        Rubber stamped by Mark Hahnenberg.

        * dfg/DFGGenerationInfo.h:
        (JSC::DFG::GenerationInfo::fillInt32):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::GPRTemporary::GPRTemporary):
        (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::Int32Operand::Int32Operand):
        (JSC::DFG::Int32Operand::~Int32Operand):
        (JSC::DFG::Int32Operand::gpr):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillInt32):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
        (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillInt32):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
        (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):

2013-09-11  Filip Pizlo  <fpizlo@apple.com>

        FixupPhase should always call fixEdge() exactly once for every edge
        https://bugs.webkit.org/show_bug.cgi?id=121211

        Reviewed by Geoffrey Garen.
        
        Previously we only call fixEdge() on edges that we want to make typed. UntypedUse
        edges don't get fixEdge() called. This makes it difficult to add functionality in
        fixEdge() that runs for UntypedUses. It's difficult to remember to call fixEdge()
        for every edge that we don't want to turn into a typed edge; in an alternative
        universe where we did this, it would mean that every case in FixupPhase would
        have to make a fixEdge() call for *every* edge even ones that it doesn't want to
        modify.
        
        This patch takes a different path. fixEdge() must never be called explicitly with
        UntypedUse. fixEdge() should be used to set the UseKind of edges. Consequently,
        all that FixupPhase has to do is call fixEdge<UntypedUse>(edge) for every edge
        that was still UntypedUse after we are done processing a node.
        
        This is cheap and easy to implement and ought to be easy to maintain. We won't
        have a need to call fixEdge<UntypedUse>(edge) explicitly, so depending on that is
        only natural.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::observeUntypedEdge):
        (JSC::DFG::FixupPhase::observeUseKindOnNode):

2013-09-11  Filip Pizlo  <fpizlo@apple.com>

        FixupPhase's setUseKindAndUnboxBlahbittyblah and fixDoubleEdge methods should be merged and given intuitive names
        https://bugs.webkit.org/show_bug.cgi?id=121202

        Reviewed by Geoffrey Garen.
        
        Got rid of a method whose name was so descriptive that I couldn't ever remember
        it. And despite the descriptive name, I always had to look at its implementation
        to remind myself what it did, anyway.
        
        Now that method is called fixEdge(). This is a good name because we're in a phase
        called FixupPhase, and we call this fixEdge() method on pretty much every edge.
        For the Int48 work, it makes more sense for this method to be a kind of hook into
        which we can place various things: it's just a way of observing edges that need
        attention.
        
        As part of this refactoring, I also fold fixDoubleEdge into fixEdge. This makes
        sense because previously it was never correct to call fixDoubleEdge with non-
        double use kinds; and conversely it was never correct to call fixEdge with double
        use kinds.
        
        Also I found that isDouble() in DFGUseKind.h would return true for KnownInt32Use.
        That's almost certainly wrong, and removing that behavior doesn't fail any tests.
        I'm assuming that was just a bug.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupToPrimitive):
        (JSC::DFG::FixupPhase::fixupToString):
        (JSC::DFG::FixupPhase::fixupSetLocalsInBlock):
        (JSC::DFG::FixupPhase::fixEdge):
        (JSC::DFG::FixupPhase::fixIntEdge):
        (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
        (JSC::DFG::FixupPhase::convertToGetArrayLength):
        (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
        * dfg/DFGUseKind.h:
        (JSC::DFG::isDouble):

2013-09-11  Mark Lam  <mark.lam@apple.com>

        Fixed indentation in JSC Debugger header files.
        https://bugs.webkit.org/show_bug.cgi?id=121203.

        Reviewed by Ryosuke Niwa.

        * debugger/Debugger.h:
        * debugger/DebuggerActivation.h:
        (JSC::DebuggerActivation::create):
        (JSC::DebuggerActivation::createStructure):
        * debugger/DebuggerCallFrame.h:
        (JSC::DebuggerCallFrame::DebuggerCallFrame):
        (JSC::DebuggerCallFrame::callFrame):
        (JSC::DebuggerCallFrame::dynamicGlobalObject):
        (JSC::DebuggerCallFrame::scope):
        (JSC::DebuggerCallFrame::exception):

2013-09-11  Filip Pizlo  <fpizlo@apple.com>

        Remove needsDataFormatConversion because it is unused.

        Rubber stamped by Mark Hahnenberg.

        * bytecode/DataFormat.h:

2013-09-11  Filip Pizlo  <fpizlo@apple.com>

        Rename fillSpeculateInt to fillSpeculateInt32.

        Rubber stamped by Mark Hahnenberg.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculateInt32Operand::gpr):
        (JSC::DFG::SpeculateStrictInt32Operand::gpr):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpecualteInt32):
        (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Strict):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Internal):
        (JSC::DFG::SpeculativeJIT::fillSpecualteInt32):
        (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Strict):

2013-09-11  Filip Pizlo  <fpizlo@apple.com>

        Rename DataFormatInteger to DataFormatInt32.

        Rubber stamped by Mark Hahnenberg.

        * bytecode/DataFormat.h:
        (JSC::dataFormatToString):
        (JSC::needDataFormatConversion):
        (JSC::isJSInt32):
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::inGPR):
        (JSC::ValueRecovery::displacedInJSStack):
        * dfg/DFGGenerationInfo.h:
        (JSC::DFG::GenerationInfo::initInteger):
        (JSC::DFG::GenerationInfo::isJSInt32):
        (JSC::DFG::GenerationInfo::fillInteger):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
        (JSC::DFG::SpeculativeJIT::checkConsistency):
        (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::spill):
        (JSC::DFG::SpeculativeJIT::integerResult):
        (JSC::DFG::SpeculativeJIT::jsValueResult):
        (JSC::DFG::SpeculativeJIT::isInteger):
        (JSC::DFG::IntegerOperand::format):
        (JSC::DFG::SpeculateInt32Operand::format):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillInteger):
        (JSC::DFG::SpeculativeJIT::fillJSValue):
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillInteger):
        (JSC::DFG::SpeculativeJIT::fillJSValue):
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValueSource.h:
        (JSC::DFG::dataFormatToValueSourceKind):
        (JSC::DFG::valueSourceKindToDataFormat):

2013-09-11  Filip Pizlo  <fpizlo@apple.com>

        Int32ToDouble should be predicted SpecInt48 and predictions should have nothing to do with constant folding
        https://bugs.webkit.org/show_bug.cgi?id=121141

        Reviewed by Oliver Hunt.
        
        Just changing Int32ToDouble to be predicted SpecInt48 breaks constant folding on that
        node because of soooper old code that prevented constant folding on mismatched
        predictions. Kill that code.

        * dfg/DFGAbstractInterpreter.h:
        (JSC::DFG::AbstractInterpreter::setConstant):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):

2013-09-10  Filip Pizlo  <fpizlo@apple.com>

        VariableAccessData::flushFormat() should be the universal way of deciding how to speculate on stores to locals and how locals are formatted
        https://bugs.webkit.org/show_bug.cgi?id=121142

        Reviewed by Geoffrey Garen.
        
        Make everyone rely on VariableAccessData::flushFormat() instead of trying to
        compute that information from scratch. The FTL already used flushFormat(), now
        the DFG does, too.

        * dfg/DFGArgumentPosition.h:
        (JSC::DFG::ArgumentPosition::someVariable):
        (JSC::DFG::ArgumentPosition::flushFormat):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupSetLocalsInBlock):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::noticeOSREntry):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInlineStart):
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValueSource.h:
        (JSC::DFG::ValueSource::forFlushFormat):
        * dfg/DFGVariableAccessDataDump.cpp:
        (JSC::DFG::VariableAccessDataDump::dump):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileSetLocal):

2013-09-11  Oliver Hunt  <oliver@apple.com>

        Partial Information Leakage in Hash Table implementations (PrivateName)
        https://bugs.webkit.org/show_bug.cgi?id=120663

        Reviewed by Michael Saboff.

        Undo change to the PropertyTable in my last patch, instead lets just
        use a random value as the initial hash for unique strings.

        * runtime/PropertyMapHashTable.h:
        (JSC::PropertyTable::find):
        (JSC::PropertyTable::findWithString):
        (JSC::PropertyTable::rehash):

2013-09-11  Oliver Hunt  <oliver@apple.com>

        Partial Information Leakage in Hash Table implementations (PrivateName)
        https://bugs.webkit.org/show_bug.cgi?id=120663

        Reviewed by Michael Saboff.

        These hashtables mix keys that are hashed on pointers or user controlled
        data.  To prevent any potential information leak we mask the keys with
        a per table entropy value.

        * runtime/MapData.cpp:
        (JSC::MapData::MapData):
        (JSC::MapData::find):
        (JSC::MapData::add):
        (JSC::MapData::remove):
        * runtime/MapData.h:
        * runtime/PropertyMapHashTable.h:
        (JSC::PropertyTable::find):
        (JSC::PropertyTable::findWithString):
        (JSC::PropertyTable::rehash):
        * runtime/PropertyTable.cpp:
        (JSC::PropertyTable::PropertyTable):

2013-09-11  Sam Weinig  <sam@webkit.org>

        MapData and WeakMapData don't need to be objects
        https://bugs.webkit.org/show_bug.cgi?id=121167

        Reviewed by Geoffrey Garen.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::mapStructure):
        Remove MapData and WeakMapData structures (they moved to VM with other non-object Structures).

        * runtime/JSMap.cpp:
        (JSC::JSMap::finishCreation):
        * runtime/JSMap.h:
        (JSC::JSMap::create):
        * runtime/JSSet.cpp:
        (JSC::JSSet::finishCreation):
        * runtime/JSSet.h:
        (JSC::JSSet::create):
        * runtime/JSWeakMap.cpp:
        (JSC::JSWeakMap::finishCreation):
        * runtime/JSWeakMap.h:
        (JSC::JSWeakMap::create):
        Update to not pass a global object to the MapData or WeakMapData Structure.

        * runtime/MapData.cpp:
        (JSC::MapData::MapData):
        * runtime/MapData.h:
        (JSC::MapData::create):
        (JSC::MapData::createStructure):
        * runtime/WeakMapData.cpp:
        (JSC::WeakMapData::WeakMapData):
        (JSC::WeakMapData::set): Change to take a VM rather than a CallFrame, as that it all it needs.
        * runtime/WeakMapData.h:
        (JSC::WeakMapData::create):
        (JSC::WeakMapData::createStructure):
        Instead of inheriting from JSDestructibleObject, inherit from JSCell and mark self as needing destruction
        and having an immortal structure.

        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        Add MapData and WeakMapData Structures.

        * runtime/WeakMapPrototype.cpp:
        (JSC::protoFuncWeakMapSet):
        Pass a VM rather than an ExecState.

2013-09-10  Filip Pizlo  <fpizlo@apple.com>

        Propagate the Int48 stuff into the prediction propagator.
        https://bugs.webkit.org/show_bug.cgi?id=121132

        Reviewed by Mark Hahnenberg.
        
        This still has no effect on codegen since Int48 still looks like a Double right now.

        * bytecode/ExitKind.cpp:
        (JSC::exitKindToString):
        * bytecode/ExitKind.h:
        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromValue):
        * bytecode/SpeculatedType.h:
        (JSC::isMachineIntSpeculation):
        (JSC::isMachineIntSpeculationExpectingDefined):
        (JSC::isMachineIntSpeculationForArithmetic):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addShouldSpeculateMachineInt):
        (JSC::DFG::Graph::mulShouldSpeculateInt32):
        (JSC::DFG::Graph::mulShouldSpeculateMachineInt):
        (JSC::DFG::Graph::negateShouldSpeculateMachineInt):
        (JSC::DFG::Graph::hasExitSite):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateMachineInt):
        (JSC::DFG::Node::shouldSpeculateMachineIntForArithmetic):
        (JSC::DFG::Node::shouldSpeculateMachineIntExpectingDefined):
        (JSC::DFG::Node::canSpeculateInt48):
        * dfg/DFGNodeFlags.h:
        (JSC::DFG::nodeCanSpeculateInt48):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):

2013-09-10  Filip Pizlo  <fpizlo@apple.com>

        Be explicit about backwards propagation properties that care about escaping to bytecode, as opposed to just escaping within DFG code.

        Rubber stamped by Mark Hahnenberg.
        
        We need to care about escaping to bytecode if we're doing a lossy optimization,
        i.e. the optimization means we produce less information and so we can't rescue
        ourselves during OSR exit.
        
        We only need to care about escaping within the DFG code (and can ignore what
        might happen in bytecode) if we're doing an optimization that is lossless, i.e.
        we can always still reconstruct the values that bytecode wants.
        
        Example #1:
        
            Large int32 + int32 which overflows. We want to optimize away the overflow
            check and just do a 32-bit add.
            
            This is lossy; the result should have one extra bit but we simply throw
            that bit away by doing a check-less 32-bit add. Hence we need to know that 
            even the bytecode wouldn't have cared about that bit. This is true in cases
            like (a + b) | 0.
        
        Example #2:
        
            Larbe int32 + int32 which overflows. We want to optimize away the overflow
            check by doing a 64-bit add.
            
            This is lossless. We can always convert the resulting 64-bit int back to a
            double if that's what bytecode wants. Hence we only need to know that the
            DFG code won't want to do something to this value that would make 64-bit
            ints either unprofitable or unsound.
        
        The backwards propagator's notions of flags (NodeUsedAsValue, etc) are for lossy
        optimizations and so should be named in a way that reflects this. This patch
        calls then NodeBytecodeUsesAsValue, etc.
        
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags):
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::arithNodeFlags):
        * dfg/DFGNodeFlags.cpp:
        (JSC::DFG::dumpNodeFlags):
        * dfg/DFGNodeFlags.h:
        (JSC::DFG::bytecodeUsesAsNumber):
        (JSC::DFG::bytecodeCanTruncateInteger):
        (JSC::DFG::bytecodeCanIgnoreNegativeZero):
        (JSC::DFG::nodeMayNegZero):
        (JSC::DFG::nodeCanSpeculateInt32):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
        (JSC::DFG::SpeculativeJIT::compileAdd):
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        (JSC::DFG::SpeculativeJIT::compileArithNegate):
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        (JSC::DFG::SpeculativeJIT::compileArithMod):
        * dfg/DFGVariableAccessData.h:
        (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileAdd):
        (JSC::FTL::LowerDFGToLLVM::compileArithSub):
        (JSC::FTL::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
        (JSC::FTL::LowerDFGToLLVM::compileArithMod):
        (JSC::FTL::LowerDFGToLLVM::compileArithNegate):

2013-09-10  Chris Curtis  <chris_curtis@apple.com>

        WebKit crashes when trying to send a msg via 'today's birthdays' dialogue box on Facebook
        https://bugs.webkit.org/show_bug.cgi?id=120612#add_comment
        Reviewed by Geoffrey Garen.

        The codeBlock was assumed to exist when appendSourceToMessage was set.
        This was an invalid assumption. I added a check to ensure that there is a
        valid codeBlock before accessing it.

        * API/tests/testapi.c:
        (valueToObjectExceptionCallAsFunction):
        (valueToObjectExceptionTest):
        (main):
        * runtime/VM.cpp:
        (JSC::VM::throwException):

2013-09-10  Mark Lam  <mark.lam@apple.com>

        Fix some indentation in Interpreter.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=121136.

        Reviewed by Darin Adler.

        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()):

2013-09-10  Mark Hahnenberg  <mhahnenberg@apple.com>

        MapData has some issues
        https://bugs.webkit.org/show_bug.cgi?id=121118

        Reviewed by Geoffrey Garen.

        * heap/CopiedBlock.h: Added some debug-only consistency checking logic. We now make sure that 
        m_liveBytes is consistent with another field, m_liveObjects. m_liveObjects is the number of 
        "objects" that currently reside in the CopiedBlock. If we have zero live bytes then we should have
        zero live objects. The converse and the inverse should also be true.
        (JSC::CopiedBlock::CopiedBlock):
        (JSC::CopiedBlock::didSurviveGC):
        (JSC::CopiedBlock::didEvacuateBytes):
        (JSC::CopiedBlock::canBeRecycled):
        (JSC::CopiedBlock::shouldEvacuate):
        (JSC::CopiedBlock::liveBytes):
        (JSC::CopiedBlock::checkConsistency):
        * heap/CopiedBlockInlines.h:
        (JSC::CopiedBlock::reportLiveBytes):
        * heap/CopyVisitorInlines.h:
        (JSC::CopyVisitor::didCopy):
        * runtime/MapData.cpp:
        (JSC::MapData::replaceAndPackBackingStore): Renamed parameter to be consistent with its meaning.
        (JSC::MapData::replaceBackingStore): Ditto. Also removed an unnecessary local variable.
        (JSC::MapData::visitChildren): Before we passed the size of the MapData to copyLater(), which 
        was wrong. Now we pass capacity * sizeof(Entry).
        (JSC::MapData::copyBackingStore): Before when we reassigned the newly copied backing store, we 
        set the capacity (in elements) to the size (in bytes) of the backing store. This made us think 
        we're way bigger than we actually are. Now we just pass the old capacity in.
        * runtime/MapData.h:
        (JSC::MapData::capacityInBytes): Helper function to calculate the size of the backing store.

2013-09-10  Filip Pizlo  <fpizlo@apple.com>

        We should say Int32 when we mean Int32. Saying Integer is just weird.

        Rubber stamped by Mark Hahnenberg.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupToPrimitive):
        (JSC::DFG::FixupPhase::fixIntEdge):
        (JSC::DFG::FixupPhase::truncateConstantsIfNecessary):
        (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::addSpeculationMode):
        (JSC::DFG::Graph::valueAddSpeculationMode):
        (JSC::DFG::Graph::arithAddSpeculationMode):
        (JSC::DFG::Graph::addShouldSpeculateInt32):
        (JSC::DFG::Graph::mulShouldSpeculateInt32):
        (JSC::DFG::Graph::negateShouldSpeculateInt32):
        (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
        (JSC::DFG::Graph::mulImmediateShouldSpeculateInt32):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateInt32):
        (JSC::DFG::Node::shouldSpeculateInt32ForArithmetic):
        (JSC::DFG::Node::shouldSpeculateInt32ExpectingDefined):
        (JSC::DFG::Node::canSpeculateInt32):
        * dfg/DFGNodeFlags.h:
        (JSC::DFG::nodeCanSpeculateInt32):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::arrayify):
        (JSC::DFG::GPRTemporary::GPRTemporary):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleIntegerBranch):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
        (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::compileArithIMul):
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        (JSC::DFG::SpeculativeJIT::compileArithMod):
        (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
        (JSC::DFG::SpeculativeJIT::speculateInt32):
        (JSC::DFG::SpeculativeJIT::emitSwitchImm):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculateInt32Operand::SpeculateInt32Operand):
        (JSC::DFG::SpeculateInt32Operand::~SpeculateInt32Operand):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileIntegerCompare):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileIntegerCompare):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):

2013-09-10  Filip Pizlo  <fpizlo@apple.com>

        Introduce a SpecInt48 type and be more careful about what we mean by "Top"
        https://bugs.webkit.org/show_bug.cgi?id=121116

        Reviewed by Oliver Hunt.
        
        SpecInt48 will mean that we have something that would be a double if it was a JSValue,
        but it's profitable to represent it as something other than a double.
        
        SpecInt48AsDouble means that it has a value that could have been represented like
        SpecInt48, but we're making a heuristic decision not to do it.

        * bytecode/SpeculatedType.h:
        (JSC::isInt48Speculation):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        (JSC::DFG::::clobberCapturedVars):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::filter):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::makeHeapTop):
        (JSC::DFG::AbstractValue::makeBytecodeTop):
        (JSC::DFG::AbstractValue::isHeapTop):
        (JSC::DFG::AbstractValue::heapTop):
        (JSC::DFG::AbstractValue::validateType):
        (JSC::DFG::AbstractValue::validate):
        (JSC::DFG::AbstractValue::makeTop):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::initialize):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::noticeOSREntry):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):

2013-09-09  Oliver Hunt  <oliver@apple.com>

        Support WeakMap
        https://bugs.webkit.org/show_bug.cgi?id=120912

        Reviewed by Geoffrey Garen.

        Add support for ES6 WeakMap.  Add the cluster of boilerplate
        classes around the core WeakMapData class.

        WeakMapData is a simple object->value hash table that uses a
        combo of WeakReferenceHarvester to conditionally keep the weak
        value reference live, and UnconditionalFinalizer to clean the
        dead keys from the table post-GC.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::weakMapDataStructure):
        * runtime/JSWeakMap.cpp: Added.
        (JSC::JSWeakMap::finishCreation):
        (JSC::JSWeakMap::visitChildren):
        * runtime/JSWeakMap.h: Added.
        (JSC::JSWeakMap::createStructure):
        (JSC::JSWeakMap::create):
        (JSC::JSWeakMap::weakMapData):
        (JSC::JSWeakMap::JSWeakMap):
        * runtime/WeakMapConstructor.cpp: Added.
        (JSC::WeakMapConstructor::finishCreation):
        (JSC::constructWeakMap):
        (JSC::WeakMapConstructor::getConstructData):
        (JSC::WeakMapConstructor::getCallData):
        * runtime/WeakMapConstructor.h: Added.
        (JSC::WeakMapConstructor::create):
        (JSC::WeakMapConstructor::createStructure):
        (JSC::WeakMapConstructor::WeakMapConstructor):
        * runtime/WeakMapData.cpp: Added.
        (JSC::WeakMapData::WeakMapData):
        (JSC::WeakMapData::finishCreation):
        (JSC::WeakMapData::destroy):
        (JSC::WeakMapData::visitChildren):
        (JSC::WeakMapData::set):
        (JSC::WeakMapData::get):
        (JSC::WeakMapData::remove):
        (JSC::WeakMapData::contains):
        (JSC::WeakMapData::clear):
        (JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
        (JSC::WeakMapData::DeadKeyCleaner::finalizeUnconditionally):
        * runtime/WeakMapData.h: Added.
        (JSC::WeakMapData::create):
        (JSC::WeakMapData::createStructure):
        (JSC::WeakMapData::DeadKeyCleaner::DeadKeyCleaner):
        * runtime/WeakMapPrototype.cpp: Added.
        (JSC::WeakMapPrototype::finishCreation):
        (JSC::getWeakMapData):
        (JSC::protoFuncWeakMapClear):
        (JSC::protoFuncWeakMapDelete):
        (JSC::protoFuncWeakMapGet):
        (JSC::protoFuncWeakMapHas):
        (JSC::protoFuncWeakMapSet):
        * runtime/WeakMapPrototype.h: Added.
        (JSC::WeakMapPrototype::create):
        (JSC::WeakMapPrototype::createStructure):
        (JSC::WeakMapPrototype::WeakMapPrototype):

2013-09-10  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: [JSC] Caught exception is treated as uncaught
        https://bugs.webkit.org/show_bug.cgi?id=93607

        Reviewed by Geoff Garen.

        Check up the entire call stack to see if there is an exception handler.

        * interpreter/Interpreter.cpp:
        (JSC::GetExceptionHandlerFunctor::GetExceptionHandlerFunctor):
        (JSC::GetExceptionHandlerFunctor::handler):
        (JSC::GetExceptionHandlerFunctor::operator()):

2013-09-10  Filip Pizlo  <fpizlo@apple.com>

        SpecType should have SpecInt48AsDouble
        https://bugs.webkit.org/show_bug.cgi?id=121065

        Reviewed by Oliver Hunt.

        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationToAbbreviatedString):
        (JSC::speculationFromValue):
        * bytecode/SpeculatedType.h:
        (JSC::isInt48AsDoubleSpeculation):
        (JSC::isIntegerSpeculation):
        (JSC::isDoubleRealSpeculation):

2013-09-10  Filip Pizlo  <fpizlo@apple.com>

        Don't GC while in the OSR-triggered jettison code
        https://bugs.webkit.org/show_bug.cgi?id=121106

        Reviewed by Mark Hahnenberg.

        * dfg/DFGOperations.cpp:

2013-09-10  Filip Pizlo  <fpizlo@apple.com>

        jsc commandline's run() function should take extra arguments
        https://bugs.webkit.org/show_bug.cgi?id=121098

        Reviewed by Michael Saboff.

        * jsc.cpp:
        (functionRun):

2013-09-09  Michael Saboff  <msaboff@apple.com>

        There should be one "invalid" virtual register constant
        https://bugs.webkit.org/show_bug.cgi?id=121057

        Reviewed by Filip Pizlo.

        Unify all references to an invalid virtual register to be the enum InvalidVirtualRegister.
        Changed the value of InvalidVirtualRegister to be maximum integer value.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setArgumentsRegister):
        (JSC::CodeBlock::usesArguments):
        * bytecode/LazyOperandValueProfile.h:
        (JSC::LazyOperandValueProfileKey::LazyOperandValueProfileKey):
        (JSC::LazyOperandValueProfileKey::operator!):
        (JSC::LazyOperandValueProfileKey::isHashTableDeletedValue):
        (JSC::LazyOperandValueProfile::LazyOperandValueProfile):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::usesArguments):
        (JSC::UnlinkedCodeBlock::usesGlobalObject):
        * bytecode/VirtualRegister.h:

2013-09-09  Michael Saboff  <msaboff@apple.com>

        Change virtual register function arguments from unsigned to int
        https://bugs.webkit.org/show_bug.cgi?id=121055

        Reviewed by Filip Pizlo.

        This is a largely mechanical change.  This changes function paramaters and local variables used to
        represent bytecode operands from being unsigned to be int.

        * bytecode/CodeOrigin.h:
        * dfg/DFGByteCodeParser.cpp:
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        * jit/JITArithmetic32_64.cpp:
        * jit/JITInlines.h:
        * jit/JITOpcodes.cpp:
        * jit/JITOpcodes32_64.cpp:
        * jit/JITPropertyAccess.cpp:
        * jit/JITPropertyAccess32_64.cpp:
        * jit/JITStubCall.h:

2013-09-09  Michael Saboff  <msaboff@apple.com>

        Add local to/from operand helpers similar to argument to/from operand2
        https://bugs.webkit.org/show_bug.cgi?id=121056

        Reviewed by Geoffrey Garen.

        Added localToOperand(), operandToLocal() and operandIsLocal() to Operands.h, very similar to
        argumentToOperand(), et al.  Used the new helpers everywhere where an index into a data
        structure is intended instead of the actual virtual register offset.  When the stack is
        changed to grow down, local register offsets can be negative.  Also added the helper
        DFG::SpeculativeJIT::generationInfoFromVirtualRegister() for the common case accessing 
        m_generationInfo[operandToLocal(val)].

        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:
        * bytecode/Operands.h:
        (JSC::localToOperand):
        (JSC::operandIsLocal):
        (JSC::operandToLocal):
        * bytecompiler/BytecodeGenerator.h:
        * dfg/DFGAbstractInterpreterInlines.h:
        * dfg/DFGByteCodeParser.cpp:
        * dfg/DFGCFGSimplificationPhase.cpp:
        * dfg/DFGCPSRethreadingPhase.cpp:
        * dfg/DFGOSREntry.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        * dfg/DFGOSRExitCompiler64.cpp:
        * dfg/DFGScoreBoard.h:
        * dfg/DFGSpeculativeJIT.cpp:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::generationInfoFromVirtualRegister):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        * dfg/DFGSpeculativeJIT64.cpp:
        * dfg/DFGValidate.cpp:
        * dfg/DFGVariableEventStream.cpp:
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        * jit/JITInlines.h:
        * jit/JITOpcodes.cpp:
        * jit/JITOpcodes32_64.cpp:

2013-09-09  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, disable GC logging.

        * heap/Heap.cpp:

2013-09-09  Mark Hahnenberg  <mhahnenberg@apple.com>

        CopiedSpace::startedCopying should not call MarkedSpace::capacity
        https://bugs.webkit.org/show_bug.cgi?id=121045

        Reviewed by Geoffrey Garen.

        MarkedSpace::capacity() iterates every block in MarkedSpace. Instead we should just 
        keep track of our total capacity in MarkedSpace as we add and remove MarkedBlocks.

        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::freeBlock):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::didAddBlock):
        (JSC::MarkedSpace::capacity):

2013-09-09  Michael Saboff  <msaboff@apple.com>

        Wrong for SlowPathCall to load callFrame reg from vm.topCallFrame after call
        https://bugs.webkit.org/show_bug.cgi?id=120537

        Reviewed by Geoffrey Garen.

        Changed JITSlowPathCall::call() to update vm.topCallFrame from the callFrameRegister instead of the
        other way around.

        * jit/JIT.h:
        * jit/JITInlines.h:
        * jit/SlowPathCall.h:
        (JSC::JITSlowPathCall::call):

2013-08-29  Mark Hahnenberg  <mhahnenberg@apple.com>

        JSArray::shiftCountWithArrayStorage doesn't change indexBias when shifting the last element in m_vector
        https://bugs.webkit.org/show_bug.cgi?id=120389

        Reviewed by Michael Saboff.

        Went through and cleaned up shiftCountWithArrayStorage. Gave meaningful variable names
        and commented the confusing parts. This led to realizing how to fix this bug, which has
        been done. The issue was that we were modifying the vector length unconditionally, even
        when we weren't logically changing the length of the vector. Instead, we should only modify
        the vector length when we modify the index bias.

        * runtime/JSArray.cpp:
        (JSC::JSArray::shiftCountWithArrayStorage):

2013-09-08  Anders Carlsson  <andersca@apple.com>

        Begin moving off of TypeTraits.h
        https://bugs.webkit.org/show_bug.cgi?id=121006

        Reviewed by Darin Adler.

        Convert uses of WTF type traits to STL type traits.

        * heap/PassWeak.h:
        * runtime/JSCell.h:
        (JSC::jsCast):
        (JSC::jsDynamicCast):
        * runtime/WriteBarrier.h:
        (JSC::validateCell):

2013-09-08  Mark Hahnenberg  <mhahnenberg@apple.com>

        Calculating the size of the Heap should not require walking over it
        https://bugs.webkit.org/show_bug.cgi?id=120910

        Reviewed by Geoffrey Garen.

        Currently Heap::size() is O(sizeof(Heap)). This is too expensive to 
        call during a collection. We should keep a count of visited and copied 
        bytes as each collection progresses so as to avoid re-walking the Heap 
        at the end of collection.

        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::childBytesVisited):
        (JSC::GCThreadSharedData::childBytesCopied):
        * heap/GCThreadSharedData.h:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::markRoots):
        (JSC::Heap::sizeAfterCollect):
        (JSC::Heap::collect):
        * heap/Heap.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::SlotVisitor):
        (JSC::SlotVisitor::reset):
        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::bytesVisited):
        (JSC::SlotVisitor::bytesCopied):
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::internalAppend):
        (JSC::SlotVisitor::copyLater):

2013-09-08  Mark Hahnenberg  <mhahnenberg@apple.com>

        Clearing MarkedBlock::m_newlyAllocated should be separate from MarkedBlock::clearMarks
        https://bugs.webkit.org/show_bug.cgi?id=121007

        Reviewed by Oliver Hunt.

        We call clearMarks on every MarkedBlock in the Heap, whereas we only need to clear 
        m_newlyAllocated for the m_currentBlock at the time of the last canonicalizeCellLiveness() 
        for each MarkedAllocator. We also need to call it on every block in the largeAllocators 
        because each one of their blocks is canonicalized as it is used.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::getAndClearCanonicalizedBlock):
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::canonicalizeCellLivenessData):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::lastChanceToFinalize):
        (JSC::MarkedBlock::clearMarks):
        (JSC::MarkedBlock::clearNewlyAllocated):
        * heap/MarkedSpace.cpp:
        (JSC::clearNewlyAllocatedInBlock):
        (JSC::ClearNewlyAllocated::operator()):
        (JSC::MarkedSpace::clearNewlyAllocated):
        * heap/MarkedSpace.h:

2013-09-07  Filip Pizlo  <fpizlo@apple.com>

        FTL should support typed array PutByVal
        https://bugs.webkit.org/show_bug.cgi?id=120972

        Reviewed by Oliver Hunt.

        Due to increased FTL coverage, this revealed a bug in LICM where we were trying to
        have AI execute the tail of a block that !cfaDidFinish. We don't need to execute AI
        for such blocks since LICM will bail for them anyway, and AI asserts that cfaDidFinish
        is true.

        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::attemptHoist):
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::buildFPToUI):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
        (JSC::FTL::LowerDFGToLLVM::doubleToInt32):
        (JSC::FTL::LowerDFGToLLVM::doubleToUInt32):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::fpToUInt):
        (JSC::FTL::Output::fpToUInt32):
        (JSC::FTL::Output::store8):
        (JSC::FTL::Output::store16):
        (JSC::FTL::Output::storeFloat):

2013-09-07  Filip Pizlo  <fpizlo@apple.com>

        FTL should support basic closure operations
        https://bugs.webkit.org/show_bug.cgi?id=120987

        Reviewed by Oliver Hunt.

        * ftl/FTLAbstractHeapRepository.cpp:
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetMyScope):
        (JSC::FTL::LowerDFGToLLVM::compileSkipScope):
        (JSC::FTL::LowerDFGToLLVM::compileGetClosureRegisters):
        (JSC::FTL::LowerDFGToLLVM::compileGetClosureVar):
        (JSC::FTL::LowerDFGToLLVM::compilePutClosureVar):

2013-09-07  Filip Pizlo  <fpizlo@apple.com>

        Only run FTL tests if we have the FTL
        https://bugs.webkit.org/show_bug.cgi?id=120974

        Reviewed by Geoffrey Garen.
        
        The test infrastructure is now smart enough to not pass --useExperimentalFTL=true
        unless it knows that we have the FTL.

        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):

2013-09-07  Anders Carlsson  <andersca@apple.com>

        Get rid of PassOwnArrayPtr
        https://bugs.webkit.org/show_bug.cgi?id=120964

        Reviewed by Andreas Kling.

        Use OwnArrayPtr instead of PassOwnArrayPtr.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * runtime/SymbolTable.h:
        (JSC::SharedSymbolTable::setSlowArguments):

2013-09-07  Filip Pizlo  <fpizlo@apple.com>

        FTL should support typed array GetByVal and related ops
        https://bugs.webkit.org/show_bug.cgi?id=120965

        Reviewed by Oliver Hunt.
        
        This adds support for typed array instantiations of the following DFG IR ops:
        
        - GetByVal
        
        - GetIndexedPropertyStorage
        
        - CheckArray
        
        - GetArrayLength
        
        This also adds CheckArray for Int32/Double/Contiguous arrays.

        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::toIndexingShape):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::shapeMask):
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::floatType):
        (JSC::FTL::buildSExt):
        (JSC::FTL::buildFPCast):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
        (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
        (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::LowerDFGToLLVM::isArrayType):
        (JSC::FTL::LowerDFGToLLVM::hasClassInfo):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::constIntPtr):
        (JSC::FTL::Output::signExt):
        (JSC::FTL::Output::fpCast):
        (JSC::FTL::Output::loadFloat):

2013-09-07  Anders Carlsson  <andersca@apple.com>

        VectorMover should use std::move
        https://bugs.webkit.org/show_bug.cgi?id=120959

        Reviewed by Geoffrey Garen.

        Work around a bug in GCC by changing the type of the callType bitfield 
        in CallLinkInfo to be unsigned instead of CallType.

        * bytecode/CallLinkInfo.h:

2013-09-07  Anders Carlsson  <andersca@apple.com>

        Get rid of FastAllocBase.h
        https://bugs.webkit.org/show_bug.cgi?id=120952

        Reviewed by Antti Koivisto.

        Include FastMalloc.h instead of FastAllocBase.h.

        * assembler/LinkBuffer.h:
        * bytecode/CodeBlock.h:
        * bytecode/StructureStubClearingWatchpoint.h:
        * dfg/DFGFinalizer.h:
        * dfg/DFGLongLivedState.h:
        * dfg/DFGSlowPathGenerator.h:
        * ftl/FTLAbstractHeap.h:
        * heap/JITStubRoutineSet.h:
        * jit/CompactJITCodeMap.h:
        * profiler/ProfilerDatabase.h:
        * profiler/ProfilerExecutionCounter.h:

2013-09-06  Filip Pizlo  <fpizlo@apple.com>

        FTL should support Call/Construct in the worst way possible
        https://bugs.webkit.org/show_bug.cgi?id=120916

        Reviewed by Oliver Hunt.
        
        This adds support for Call/Construct by just calling out to C code that uses
        the JSC::call/JSC::construct runtime functions for making calls. This is slow
        and terrible, but it dramatically extends FTL coverage.
        
        Supporting calls in a meaningful way meant also supporting
        GlobalVarWatchpoint.
        
        The extension of coverage helped to find a bunch of bugs:
        
        - ObjectOrOtherUse was claimed to be supported in the FTL but speculate()
          didn't support it. That means that any node with an ObjectOrOtherUse edge
          that got DCE'd would cause the FTL to ICE.
        
        - There was a bad fall-through compileCompareStrictEq() that led to ICE.
        
        - The OSR exit reconstruction code was assuming it could do fast checks on
          node->child1() before even determining the type of node; that crashes if
          the node is HasVarArgs. Fixed by checking HasVarArgs first.
        
        - The OSR exit compiler was using the wrong peekOffset for CArgumentGetter.
          The default is 1, which assumes that you didn't push anything onto the
          stack after getting called. The OSR exit thunks push FP, so the offset
          should be 2.
        
        This passes stress tests and is probably huge performance regression if you
        --useExperimentalFTL=true. The regression will be fixed in
        https://bugs.webkit.org/show_bug.cgi?id=113621.

        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGlobalVarWatchpoint):
        (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
        (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
        (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):

2013-09-06  Filip Pizlo  <fpizlo@apple.com>

        jsc shell should destroy VM as a workaround for LLVM's exit-time destructors
        https://bugs.webkit.org/show_bug.cgi?id=120921

        Reviewed by Oliver Hunt.
        
        LLVM's exit-time destructors will fire when we exit. If there is an on-going
        FTL compile at exit, which will happen if the VM that triggered the compile
        isn't shut down, then we will crash.
        
        We should get rid of LLVM's exit-time destructors. But before we do that, we
        should just do a clean VM shutdown to suppress spurious crashes. This will
        help in expanding LLVM coverage for now.

        * jsc.cpp:
        (jscmain):

2013-09-06  Filip Pizlo  <fpizlo@apple.com>

        FTL ArithMod Int32Use doesn't check for negative zero correctly
        https://bugs.webkit.org/show_bug.cgi?id=120905

        Reviewed by Mark Hahnenberg.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileArithMod):

2013-09-06  Filip Pizlo  <fpizlo@apple.com>

        FTL ArithNeg Int32Use doesn't check negative zero
        https://bugs.webkit.org/show_bug.cgi?id=120900

        Reviewed by Mark Hahnenberg.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileArithNegate):

2013-09-06  Anders Carlsson  <andersca@apple.com>

        Stop using fastNew/fastDelete in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=120898

        Reviewed by Oliver Hunt.

        Change all the hash table members in ExecState to be OwnPtrs and use
        adoptPtr instead. Also, since none of the hash tables can be null, change their getters
        to return references and propagate the reference types wherever we know that a HashTable can't be null.

        * interpreter/CallFrame.h:
        (JSC::ExecState::arrayConstructorTable):
        (JSC::ExecState::arrayPrototypeTable):
        (JSC::ExecState::booleanPrototypeTable):
        (JSC::ExecState::dataViewTable):
        (JSC::ExecState::dateTable):
        (JSC::ExecState::dateConstructorTable):
        (JSC::ExecState::errorPrototypeTable):
        (JSC::ExecState::globalObjectTable):
        (JSC::ExecState::jsonTable):
        (JSC::ExecState::numberConstructorTable):
        (JSC::ExecState::numberPrototypeTable):
        (JSC::ExecState::objectConstructorTable):
        (JSC::ExecState::privateNamePrototypeTable):
        (JSC::ExecState::regExpTable):
        (JSC::ExecState::regExpConstructorTable):
        (JSC::ExecState::regExpPrototypeTable):
        (JSC::ExecState::stringConstructorTable):
        (JSC::ExecState::promisePrototypeTable):
        (JSC::ExecState::promiseConstructorTable):
        (JSC::ExecState::promiseResolverPrototypeTable):
        * runtime/ClassInfo.h:
        (JSC::ClassInfo::propHashTable):
        * runtime/Lookup.h:
        (JSC::getStaticPropertySlot):
        (JSC::getStaticFunctionSlot):
        (JSC::getStaticValueSlot):
        (JSC::lookupPut):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        * runtime/VM.h:

2013-09-06  Filip Pizlo  <fpizlo@apple.com>

        Concurrent FTL causes !hasOptimizedReplacement() asserts in cti_optimize
        https://bugs.webkit.org/show_bug.cgi?id=120890

        Reviewed by Mark Hahnenberg.
        
        Don't install an FTL code block if the DFG code block has already been jettisoned.

        * dfg/DFGToFTLDeferredCompilationCallback.cpp:
        (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):

2013-09-06  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(149636, merged in 153145): ToThis conversion doesn't work in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=120781

        Reviewed by Mark Hahnenberg.
        
        Roll this back in with a build fix.
        
        - Use some method table hacks to detect if the CheckStructure optimization is
          valid for to_this.
        
        - Introduce a FinalObjectUse and use it for ToThis->Identity conversion.
        
        This looks like it might be perf-neutral on the major benchmarks, but it
        introduces some horrible performance cliffs. For example if you add methods to
        the Array prototype, you'll get horrible performance cliffs. As in virtual calls
        to C++ every time you call a JS function even if it's inlined.
        LongSpider/3d-cube appears to hit this.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::emitPutTransitionStub):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateFinalObject):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isCell):

2013-09-05  Filip Pizlo  <fpizlo@apple.com>

        Introduce a way to run benchmarks and JSRegress as stress tests with different jsc command-line options
        https://bugs.webkit.org/show_bug.cgi?id=120808

        Reviewed by Mark Hahnenberg and rubber stamped by Geoffrey Garen.
        
        Allow --useExperimentalFTL=true even if FTL isn't built since this simplifies
        testing.

        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):

2013-09-06  Zan Dobersek  <zdobersek@igalia.com>

        Unreviewed build fix for the GTK port when building with FTL JIT enabled.

        * GNUmakefile.list.am: Add the missing files to the build.

2013-09-05  Oliver Hunt  <oliver@apple.com>

        Make it simpler to introduce new data types to the global object
        https://bugs.webkit.org/show_bug.cgi?id=120801

        Reviewed by Gavin Barraclough.

        Add an iterator macro that lists all the "simple" ES types (e.g. type
        consists of instance, constructor, and prototype classes).  So that
        we don't need to have every new type litter JSGlobalObject.{cpp,h} with
        members, accessors, and manual GC visiting.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:

2013-09-05  Mark Rowe  <mrowe@apple.com>
        
        Roll out r155149 since it broke the build.

2013-09-05  Michael Saboff  <msaboff@apple.com>

        Cleanup formatting of byte code debug output
        Source/JavaScriptCore/ChangeLog

        Rubber stamped by Filip Pizlo.

        Put the formatting of the byte code offset and operation into one common function to
        simplify and unify formatting.  Changed CodeBlock::registerName() to return
        "thist" for argument register 0, "argN" for other argument registers and "locN" for
        local registers.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::registerName):
        (JSC::CodeBlock::printUnaryOp):
        (JSC::CodeBlock::printBinaryOp):
        (JSC::CodeBlock::printConditionalJump):
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::printCallOp):
        (JSC::CodeBlock::printPutByIdOp):
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::printLocationAndOp):
        (JSC::CodeBlock::printLocationOpAndRegisterOperand):

2013-09-05  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(149636, merged in 153145): ToThis conversion doesn't work in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=120781

        Reviewed by Mark Hahnenberg.
        
        - Use some method table hacks to detect if the CheckStructure optimization is
          valid for to_this.
        
        - Introduce a FinalObjectUse and use it for ToThis->Identity conversion.
        
        This looks like it might be perf-neutral on the major benchmarks, but it
        introduces some horrible performance cliffs. For example if you add methods to
        the Array prototype, you'll get horrible performance cliffs. As in virtual calls
        to C++ every time you call a JS function even if it's inlined.
        LongSpider/3d-cube appears to hit this.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::speculateFinalObject):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isCell):

2013-09-05  Anders Carlsson  <andersca@apple.com>

        GCAssertions.h should use STL type traits and static_assert
        https://bugs.webkit.org/show_bug.cgi?id=120785

        Reviewed by Andreas Kling.

        There's no need to rely on compiler specific support to figure out if a class is trivially destructable,
        we can just use type traits from STL. Do this, fix the assert macro to use static_assert directly and
        rename it from ASSERT_HAS_TRIVIAL_DESTRUCTOR to STATIC_ASSERT_IS_TRIVIALLY_DESTRUCTIBLE to clarify that
        it's a static assert and to match the STL nomenclature.
        
        * API/JSCallbackFunction.cpp:
        * debugger/DebuggerActivation.cpp:
        * heap/GCAssertions.h:
        * runtime/ArrayConstructor.cpp:
        * runtime/BooleanConstructor.cpp:
        * runtime/BooleanObject.cpp:
        * runtime/BooleanPrototype.cpp:
        * runtime/DateConstructor.cpp:
        * runtime/ErrorConstructor.cpp:
        * runtime/ErrorInstance.cpp:
        * runtime/ErrorPrototype.cpp:
        * runtime/ExceptionHelpers.cpp:
        * runtime/FunctionConstructor.cpp:
        * runtime/FunctionPrototype.cpp:
        * runtime/GetterSetter.cpp:
        * runtime/InternalFunction.cpp:
        * runtime/JSAPIValueWrapper.cpp:
        * runtime/JSArray.cpp:
        * runtime/JSCell.cpp:
        * runtime/JSNotAnObject.cpp:
        * runtime/JSONObject.cpp:
        * runtime/JSObject.cpp:
        * runtime/JSPromiseConstructor.cpp:
        * runtime/JSPromisePrototype.cpp:
        * runtime/JSPromiseResolverConstructor.cpp:
        * runtime/JSPromiseResolverPrototype.cpp:
        * runtime/JSProxy.cpp:
        * runtime/JSScope.cpp:
        * runtime/JSWrapperObject.cpp:
        * runtime/MathObject.cpp:
        * runtime/NameConstructor.cpp:
        * runtime/NativeErrorConstructor.cpp:
        * runtime/NumberConstructor.cpp:
        * runtime/NumberObject.cpp:
        * runtime/NumberPrototype.cpp:
        * runtime/ObjectConstructor.cpp:
        * runtime/ObjectPrototype.cpp:
        * runtime/RegExpObject.cpp:
        * runtime/StrictEvalActivation.cpp:
        * runtime/StringConstructor.cpp:
        * runtime/StringObject.cpp:
        * runtime/StringPrototype.cpp:

2013-09-05  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed build fix for DebugSuffix target.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Don't build 64-bit assembly in 32-bit build.
        Also correct 'filters' file so that files appear in categories that match their on-disk locations.

2013-09-04  Filip Pizlo  <fpizlo@apple.com>

        jsc tests should have timeouts
        https://bugs.webkit.org/show_bug.cgi?id=120725

        Reviewed by Geoffrey Garen.
        
        Add the timeout logic directly to 'jsc' because that's easier to do than
        writing shell/perl code for it.

        * jsc.cpp:
        (timeoutThreadMain):
        (main):

2013-09-04  Filip Pizlo  <fpizlo@apple.com>

        fast/js/dfg-* tests should wait for the concurrent JIT
        https://bugs.webkit.org/show_bug.cgi?id=120723

        Reviewed by Geoffrey Garen.
        
        * runtime/TestRunnerUtils.cpp:
        (JSC::numberOfDFGCompiles): This should also handle constructors.

2013-09-04  Filip Pizlo  <fpizlo@apple.com>

        run-fast-jsc should work with new-school fast/js tests that loop until the DFG tiers up
        https://bugs.webkit.org/show_bug.cgi?id=120697

        Reviewed by Mark Hahnenberg.

        * API/JSCTestRunnerUtils.cpp:
        (JSC::numberOfDFGCompiles):
        (JSC::setNeverInline):
        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionNeverInlineFunction):
        (functionNumberOfDFGCompiles):
        * runtime/TestRunnerUtils.cpp: Added.
        (JSC::getExecutable):
        (JSC::numberOfDFGCompiles):
        (JSC::setNeverInline):
        * runtime/TestRunnerUtils.h: Added.

2013-09-04  Mark Lam  <mark.lam@apple.com>

        Renamed StackIterator to StackVisitor.
        https://bugs.webkit.org/show_bug.cgi?id=120706.

        Reviewed by Geoffrey Garen.

        Also did some minor refactoring:
        - Renamed StackIterator::iterate() to StackVisitor::visit().
        - Make StackVisitor::visit() a static method.
        - Move the instantiation of the StackVisitor instance into StackVisitor::visit()
          from CallFrame::iterate().
        - Removed StackIterator::resetIterator() and inline its body into the
          StackVisitor constructor since this is the only remaining caller of it.

        * API/JSContextRef.cpp:
        (BacktraceFunctor::operator()):
        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * interpreter/CallFrame.h:
        (JSC::ExecState::iterate):
        * interpreter/Interpreter.cpp:
        (JSC::DumpRegisterFunctor::operator()):
        (JSC::unwindCallFrame):
        (JSC::getStackFrameCodeType):
        (JSC::GetStackTraceFunctor::operator()):
        (JSC::UnwindFunctor::operator()):
        * interpreter/Interpreter.h:
        * interpreter/StackIterator.cpp: Removed.
        * interpreter/StackIterator.h: Removed.
        * interpreter/StackVisitor.cpp: Copied from Source/JavaScriptCore/interpreter/StackIterator.cpp.
        (JSC::StackVisitor::StackVisitor):
        (JSC::StackVisitor::gotoNextFrame):
        (JSC::StackVisitor::readFrame):
        (JSC::StackVisitor::readNonInlinedFrame):
        (JSC::StackVisitor::readInlinedFrame):
        (JSC::StackVisitor::Frame::codeType):
        (JSC::StackVisitor::Frame::functionName):
        (JSC::StackVisitor::Frame::sourceURL):
        (JSC::StackVisitor::Frame::toString):
        (JSC::StackVisitor::Frame::arguments):
        (JSC::StackVisitor::Frame::computeLineAndColumn):
        (JSC::StackVisitor::Frame::retrieveExpressionInfo):
        (JSC::StackVisitor::Frame::setToEnd):
        (JSC::StackVisitor::Frame::print):
        (DebugPrintFrameFunctor::operator()):
        * interpreter/StackVisitor.h: Copied from Source/JavaScriptCore/interpreter/StackIterator.h.
        (JSC::StackVisitor::visit):
        * jsc.cpp:
        (FunctionJSCStackFunctor::operator()):
        * profiler/ProfileGenerator.cpp:
        (JSC::AddParentForConsoleStartFunctor::operator()):
        * runtime/JSFunction.cpp:
        (JSC::RetrieveArgumentsFunctor::operator()):
        (JSC::RetrieveCallerFunctionFunctor::operator()):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::GlobalFuncProtoGetterFunctor::operator()):
        (JSC::GlobalFuncProtoSetterFunctor::operator()):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):

2013-09-04  Roger Fong  <roger_fong@apple.com>

        Unreviewed Build fix for Windows DebugSuffix configuration.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2013-09-04  Mark Lam  <mark.lam@apple.com>

        Refining the StackIterator callback interface.
        https://bugs.webkit.org/show_bug.cgi?id=120695.

        Reviewed by Geoffrey Garen.

        Introduce CallFrame::iterate() which instantiates a StackIterator and
        invoke its iterate() method with the passed in functor. The only place
        where the client code gets access to the StackIterator now is as an
        argument to the client's functor.

        * API/JSContextRef.cpp:
        (JSContextCreateBacktrace):
        * interpreter/CallFrame.cpp:
        * interpreter/CallFrame.h:
        (JSC::ExecState::iterate):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters):
        (JSC::Interpreter::getStackTrace):
        (JSC::Interpreter::unwind):
        * interpreter/StackIterator.cpp:
        (JSC::StackIterator::StackIterator):
        (DebugPrintFrameFunctor::DebugPrintFrameFunctor):
        (DebugPrintFrameFunctor::operator()):
        (debugPrintCallFrame):
        (debugPrintStack):
        * interpreter/StackIterator.h:
        (JSC::StackIterator::iterate):
        * jsc.cpp:
        (functionJSCStack):
        * profiler/ProfileGenerator.cpp:
        (JSC::ProfileGenerator::addParentForConsoleStart):
        * runtime/JSFunction.cpp:
        (JSC::retrieveArguments):
        (JSC::RetrieveCallerFunctionFunctor::operator()):
        (JSC::retrieveCallerFunction):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetPrototypeOf):

2013-09-04  Benjamin Poulain  <benjamin@webkit.org>

        JSGenericTypedArrayViewConstructor.h is referenced twice in the XCode project build section, causing warnings
        https://bugs.webkit.org/show_bug.cgi?id=120698

        Reviewed by Darin Adler.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2013-09-04  Mark Hahnenberg  <mhahnenberg@apple.com>

        ASSERT in MarkedAllocator::allocateSlowCase is wrong
        https://bugs.webkit.org/show_bug.cgi?id=120639

        Reviewed by Oliver Hunt.

        ASSERT(!m_heap->shouldCollect()) is no longer true due to our use of the GC 
        deferral mechanism. We could technically be beyond our byte allocation limit, 
        but still not try to collect due to deferral. This patch amends shouldCollect() 
        to return false if GC is currently deferred.

        * heap/Heap.h:
        (JSC::Heap::shouldCollect):

2013-09-03  Filip Pizlo  <fpizlo@apple.com>

        The DFG should be able to tier-up and OSR enter into the FTL
        https://bugs.webkit.org/show_bug.cgi?id=112838

        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:

2013-09-03  Filip Pizlo  <fpizlo@apple.com>

        CodeBlock memory cost reporting should be rationalized
        https://bugs.webkit.org/show_bug.cgi?id=120615

        Reviewed by Darin Adler.
        
        Report the size of the instruction stream, and then remind the GC that we're
        using memory when we trace.
        
        This is a slight slow-down on some JSBench tests because it makes us GC a
        bit more frequently. But I think it's well worth it; if we really want those
        tests to GC less frequently then we can achieve that through other kinds of
        tuning. It's better that the GC knows that CodeBlocks do in fact use memory;
        what it does with that information is a somewhat orthogonal question.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::visitAggregate):

2013-09-03  Mark Lam  <mark.lam@apple.com>

        Converting StackIterator to a callback interface.
        https://bugs.webkit.org/show_bug.cgi?id=120564.

        Reviewed by Filip Pizlo.

        * API/JSContextRef.cpp:
        (BacktraceFunctor::BacktraceFunctor):
        (BacktraceFunctor::operator()):
        (JSContextCreateBacktrace):
        * interpreter/CallFrame.cpp:
        * interpreter/CallFrame.h:
        * interpreter/Interpreter.cpp:
        (JSC::DumpRegisterFunctor::DumpRegisterFunctor):
        (JSC::DumpRegisterFunctor::operator()):
        (JSC::Interpreter::dumpRegisters):
        (JSC::unwindCallFrame):
        (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
        (JSC::GetStackTraceFunctor::operator()):
        (JSC::Interpreter::getStackTrace):
        (JSC::Interpreter::stackTraceAsString):
        (JSC::UnwindFunctor::UnwindFunctor):
        (JSC::UnwindFunctor::operator()):
        (JSC::Interpreter::unwind):
        * interpreter/Interpreter.h:
        * interpreter/StackIterator.cpp:
        (JSC::StackIterator::numberOfFrames):
        (JSC::StackIterator::gotoFrameAtIndex):
        (JSC::StackIterator::gotoNextFrameWithFilter):
        (JSC::StackIterator::resetIterator):
        (JSC::StackIterator::Frame::print):
        (debugPrintCallFrame):
        (DebugPrintStackFunctor::operator()):
        (debugPrintStack): Added for debugging convenience.
        * interpreter/StackIterator.h:
        (JSC::StackIterator::Frame::index):
        (JSC::StackIterator::iterate):
        * jsc.cpp:
        (FunctionJSCStackFunctor::FunctionJSCStackFunctor):
        (FunctionJSCStackFunctor::operator()):
        (functionJSCStack):
        * profiler/ProfileGenerator.cpp:
        (JSC::AddParentForConsoleStartFunctor::AddParentForConsoleStartFunctor):
        (JSC::AddParentForConsoleStartFunctor::foundParent):
        (JSC::AddParentForConsoleStartFunctor::operator()):
        (JSC::ProfileGenerator::addParentForConsoleStart):
        * runtime/JSFunction.cpp:
        (JSC::RetrieveArgumentsFunctor::RetrieveArgumentsFunctor):
        (JSC::RetrieveArgumentsFunctor::result):
        (JSC::RetrieveArgumentsFunctor::operator()):
        (JSC::retrieveArguments):
        (JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
        (JSC::RetrieveCallerFunctionFunctor::result):
        (JSC::RetrieveCallerFunctionFunctor::operator()):
        (JSC::retrieveCallerFunction):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::GlobalFuncProtoGetterFunctor::GlobalFuncProtoGetterFunctor):
        (JSC::GlobalFuncProtoGetterFunctor::result):
        (JSC::GlobalFuncProtoGetterFunctor::operator()):
        (JSC::globalFuncProtoGetter):
        (JSC::GlobalFuncProtoSetterFunctor::GlobalFuncProtoSetterFunctor):
        (JSC::GlobalFuncProtoSetterFunctor::allowsAccess):
        (JSC::GlobalFuncProtoSetterFunctor::operator()):
        (JSC::globalFuncProtoSetter):
        * runtime/ObjectConstructor.cpp:
        (JSC::ObjectConstructorGetPrototypeOfFunctor::ObjectConstructorGetPrototypeOfFunctor):
        (JSC::ObjectConstructorGetPrototypeOfFunctor::result):
        (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
        (JSC::objectConstructorGetPrototypeOf):

2013-09-03  Oliver Hunt  <oliver@apple.com>

        Support structured clone of Map and Set
        https://bugs.webkit.org/show_bug.cgi?id=120654

        Reviewed by Simon Fraser.

        Make xcode copy the required headers, and add appropriate export attributes

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSMap.h:
        * runtime/JSSet.h:
        * runtime/MapData.h:

2013-09-02  Ryosuke Niwa  <rniwa@webkit.org>

        Support the "json" responseType and JSON response entity in XHR
        https://bugs.webkit.org/show_bug.cgi?id=73648

        Reviewed by Oliver Hunt.

        Based on the patch written by Jarred Nicholls.

        Add JSC::JSONParse. This function will be used in XMLHttpRequest.response of type 'json'.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSONObject.cpp:
        (JSC::JSONParse):
        * runtime/JSONObject.h:

2013-09-02  Filip Pizlo  <fpizlo@apple.com>

        CodeBlock::jettison() should be implicit
        https://bugs.webkit.org/show_bug.cgi?id=120567

        Reviewed by Oliver Hunt.
        
        This is a risky change from a performance standpoint, but I believe it's
        necessary. This makes all CodeBlocks get swept by GC. Nobody but the GC
        can delete CodeBlocks because the GC always holds a reference to them.
        Once a CodeBlock reaches just one reference (i.e. the one from the GC)
        then the GC will free it only if it's not on the stack.
        
        This allows me to get rid of the jettisoning logic. We need this for FTL
        tier-up. Well; we don't need it, but it will help prevent a lot of bugs.
        Previously, if you wanted to to replace one code block with another, you
        had to remember to tell the GC that the previous code block is
        "jettisoned". We would need to do this when tiering up from DFG to FTL
        and when dealing with DFG-to-FTL OSR entry code blocks. There are a lot
        of permutations here - tiering up to the FTL, OSR entering into the FTL,
        deciding that an OSR entry code block is not relevant anymore - just to
        name a few. In each of these cases we'd have to jettison the previous
        code block. It smells like a huge source of future bugs.
        
        So I made jettisoning implicit by making the GC always watch out for a
        CodeBlock being owned solely by the GC.
        
        This change is performance neutral.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::~CodeBlock):
        (JSC::CodeBlock::visitAggregate):
        (JSC::CodeBlock::jettison):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
        (JSC::CodeBlockSet::mark):
        * dfg/DFGCommonData.h:
        (JSC::DFG::CommonData::CommonData):
        * heap/CodeBlockSet.cpp: Added.
        (JSC::CodeBlockSet::CodeBlockSet):
        (JSC::CodeBlockSet::~CodeBlockSet):
        (JSC::CodeBlockSet::add):
        (JSC::CodeBlockSet::clearMarks):
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
        (JSC::CodeBlockSet::traceMarked):
        * heap/CodeBlockSet.h: Added.
        * heap/ConservativeRoots.cpp:
        (JSC::ConservativeRoots::add):
        * heap/ConservativeRoots.h:
        * heap/DFGCodeBlocks.cpp: Removed.
        * heap/DFGCodeBlocks.h: Removed.
        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::deleteAllCompiledCode):
        (JSC::Heap::deleteUnmarkedCompiledCode):
        * heap/Heap.h:
        * interpreter/JSStack.cpp:
        (JSC::JSStack::gatherConservativeRoots):
        * interpreter/JSStack.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::installCode):
        * runtime/Executable.h:
        * runtime/VM.h:

2013-09-02  Darin Adler  <darin@apple.com>

        [Mac] No need for HardAutorelease, which is same as CFBridgingRelease
        https://bugs.webkit.org/show_bug.cgi?id=120569

        Reviewed by Andy Estes.

        * API/JSValue.mm:
        (valueToString): Use CFBridgingRelease.

2013-08-30  Filip Pizlo  <fpizlo@apple.com>

        CodeBlock refactoring broke profile dumping
        https://bugs.webkit.org/show_bug.cgi?id=120551

        Reviewed by Michael Saboff.
        
        Fix the bug, and did a big clean-up of how Executable returns CodeBlocks. A lot
        of the problems we have with code like CodeBlock::baselineVersion() is that we
        were trying *way too hard* to side-step the fact that Executable can't return a
        CodeBlock*. Previously it could only return CodeBlock&, so if it didn't have a
        CodeBlock yet, you were screwed. And if you didn't know, or weren't sure, if it
        did have a CodeBlock, you were really going to have a bad time. Also it really
        bugs me that the methods were called generatedBytecode(). In all other contexts
        if you ask for a CodeBlock, then method to call is codeBlock(). So I made all
        of those changes.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::baselineVersion):
        (JSC::ProgramCodeBlock::replacement):
        (JSC::EvalCodeBlock::replacement):
        (JSC::FunctionCodeBlock::replacement):
        (JSC::CodeBlock::globalObjectFor):
        * bytecode/CodeOrigin.cpp:
        (JSC::InlineCallFrame::hash):
        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * jit/JITCode.h:
        (JSC::JITCode::isExecutableScript):
        (JSC::JITCode::isLowerTier):
        * jit/JITStubs.cpp:
        (JSC::lazyLinkFor):
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::traceFunctionPrologue):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::setUpCall):
        * runtime/ArrayPrototype.cpp:
        (JSC::isNumericCompareFunction):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::installCode):
        * runtime/Executable.h:
        (JSC::EvalExecutable::codeBlock):
        (JSC::ProgramExecutable::codeBlock):
        (JSC::FunctionExecutable::eitherCodeBlock):
        (JSC::FunctionExecutable::codeBlockForCall):
        (JSC::FunctionExecutable::codeBlockForConstruct):
        (JSC::FunctionExecutable::codeBlockFor):
        * runtime/FunctionExecutableDump.cpp:
        (JSC::FunctionExecutableDump::dump):

2013-08-30  Oliver Hunt  <oliver@apple.com>

        Implement ES6 Set class
        https://bugs.webkit.org/show_bug.cgi?id=120549

        Reviewed by Filip Pizlo.

        We simply reuse the MapData type from JSMap making the
        it much simpler.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::setStructure):
        * runtime/JSSet.cpp: Added.
        (JSC::JSSet::visitChildren):
        (JSC::JSSet::finishCreation):
        * runtime/JSSet.h: Added.
        (JSC::JSSet::createStructure):
        (JSC::JSSet::create):
        (JSC::JSSet::mapData):
        (JSC::JSSet::JSSet):
        * runtime/SetConstructor.cpp: Added.
        (JSC::SetConstructor::finishCreation):
        (JSC::callSet):
        (JSC::constructSet):
        (JSC::SetConstructor::getConstructData):
        (JSC::SetConstructor::getCallData):
        * runtime/SetConstructor.h: Added.
        (JSC::SetConstructor::create):
        (JSC::SetConstructor::createStructure):
        (JSC::SetConstructor::SetConstructor):
        * runtime/SetPrototype.cpp: Added.
        (JSC::SetPrototype::finishCreation):
        (JSC::getMapData):
        (JSC::setProtoFuncAdd):
        (JSC::setProtoFuncClear):
        (JSC::setProtoFuncDelete):
        (JSC::setProtoFuncForEach):
        (JSC::setProtoFuncHas):
        (JSC::setProtoFuncSize):
        * runtime/SetPrototype.h: Added.
        (JSC::SetPrototype::create):
        (JSC::SetPrototype::createStructure):
        (JSC::SetPrototype::SetPrototype):

2013-08-30  Oliver Hunt  <oliver@apple.com>

        Make JSValue bool conversion less dangerous
        https://bugs.webkit.org/show_bug.cgi?id=120505

        Reviewed by Darin Adler.

        Replaces JSValue::operator bool() with a operator UnspecifiedBoolType* as
        we do elsewhere.  Then fix the places where terrible type coercion was
        happening.  All of the changes made had no fundamental behavioural impact
        as they were coercion results that were ignored (returning undefined 
        after an exception).  

        * dfg/DFGOperations.cpp:
        * interpreter/CallFrame.h:
        (JSC::ExecState::hadException):
        * runtime/JSCJSValue.h:
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::operator UnspecifiedBoolType*):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * runtime/PropertyDescriptor.cpp:
        (JSC::PropertyDescriptor::equalTo)

2013-08-30  Chris Curtis  <chris_curtis@apple.com>

        Cleaning errorDescriptionForValue after r154839
        https://bugs.webkit.org/show_bug.cgi?id=120531
        
        Reviewed by Darin Adler.
        
        Changed the assert to ASSERT_NOT_REACHED, now that r154839 has landed. errorDescriptionForValue 
        can assert again that the parameterized JSValue is !isEmpty().
        
        * runtime/ExceptionHelpers.cpp:
        (JSC::errorDescriptionForValue):

2013-08-30  Antti Koivisto  <antti@apple.com>

        Remove code behind ENABLE(DIALOG_ELEMENT)
        https://bugs.webkit.org/show_bug.cgi?id=120467

        Reviewed by Darin Adler.

        * Configurations/FeatureDefines.xcconfig:

2013-08-29  Andreas Kling  <akling@apple.com>

        De-bork Qt build.

        * Target.pri:

2013-08-29  Ryuan Choi  <ryuan.choi@samsung.com>

        Unreviewed build fix attempt for Windows.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        Renamed JSMapConstructor and JSMapPrototype.

2013-08-29  Ryuan Choi  <ryuan.choi@samsung.com>

        Fix build break after r154861
        https://bugs.webkit.org/show_bug.cgi?id=120503

        Reviewed by Geoffrey Garen.

        Unreviewed build fix attempt for GTK, Qt Windows and CMake based ports.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * Target.pri:
        * runtime/MapData.h:
        (JSC::MapData::KeyType::KeyType):

2013-08-29  Andreas Kling  <akling@apple.com>

        CodeBlock: LLIntCallLinkInfo vector can be sized-to-fit at creation.
        <https://webkit.org/b/120487>

        Reviewed by Oliver Hunt.

        CodeBlock::m_llintCallLinkInfos never changes size after creation, so make it a Vector
        instead of a SegmentedVector. Use resizeToFit() instead of grow() since we know the
        exact amount of space needed.

        * bytecode/CodeBlock.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::shrinkToFit):

2013-08-29  Oliver Hunt  <oliver@apple.com>

        Fix issues found by MSVC (which also happily fixes an unintentional pessimisation)

        * runtime/MapData.h:
        (JSC::MapData::KeyType::KeyType):

2013-08-29  Oliver Hunt  <oliver@apple.com>


        Implement ES6 Map object
        https://bugs.webkit.org/show_bug.cgi?id=120333

        Reviewed by Geoffrey Garen.

        Implement support for the ES6 Map type and related classes.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/CopyToken.h: Add a new token to track copying the backing store
        * runtime/CommonIdentifiers.h: Add new identifiers
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
            Add new structures and prototypes

        * runtime/JSMap.cpp: Added.
        * runtime/JSMap.h: Added.
            New JSMap class to represent a Map instance

        * runtime/MapConstructor.cpp: Added.
        * runtime/MapConstructor.h: Added.
            The Map constructor

        * runtime/MapData.cpp: Added.
        * runtime/MapData.h: Added.
            The most interesting data structure.  The roughly corresponds
            to the ES6 notion of MapData.  It provides the core JSValue->JSValue
            map implementation.  We implement it using 2 hashtables and a flat
            table.  Due to the different semantics of string comparisons vs.
            all others we need have one map keyed by String and the other by
            generic JSValue.  The actual table is represented more or less
            exactly as described in the ES6 draft - a single contiguous list of
            key/value pairs.  The entire map could be achieved with just this
            table, however we need the HashMaps in order to maintain O(1) lookup.

            Deleted values are simply cleared as the draft says, however the
            implementation compacts the storage on copy as long as the are no
            active iterators.

        * runtime/MapPrototype.cpp: Added.
        * runtime/MapPrototype.h: Added.
            Implement Map prototype functions

        * runtime/VM.cpp:
            Add new structures.

2013-08-29  Filip Pizlo  <fpizlo@apple.com>

        Teach DFG::Worklist and its clients that it may be reused for different kinds of compilations
        https://bugs.webkit.org/show_bug.cgi?id=120489

        Reviewed by Geoffrey Garen.
        
        If the baseline JIT hits an OSR entry trigger into the DFG and we already have a
        DFG compilation but we've also started one or more FTL compilations, then we
        shouldn't get confused. Previously we would have gotten confused because we would
        see an in-process deferred compile (the FTL compile) and also an optimized
        replacement (the DFG code).
        
        If the baseline JIT hits an OSR entry trigger into the DFG and we previously
        did two things in this order: triggered a tier-up compilation from the DFG into
        the FTL, and then jettisoned the DFG code because it exited a bunch, then we
        shouldn't be confused by the presence of an in-process deferred compile (the FTL
        compile). Previously we would have waited for that compile to finish; but the more
        sensible thing to do is to let it complete and then invalidate it, while at the
        same time enqueueing a DFG compile to create a new, more valid, DFG code block.
        
        If the DFG JIT hits a loop OSR entry trigger (into the FTL) and it has already
        triggered an FTL compile for replacement, then it should fire off a second compile
        instead of thinking that it can wait for that one to finish. Or vice-versa. We
        need to allow for two FTL compiles to be enqueued at the same time (one for
        replacement and one for OSR entry in a loop).
        
        Then there's also the problem that DFG::compile() is almost certainly going to be
        the hook for triggering both DFG compiles and the two kinds of FTL compiles, but
        right now there is no way to tell it which one you want.
        
        This fixes these problems and removes a bunch of potential confusion by making the
        key for a compile in the DFG::Worklist be a CompilationMode (one of DFGMode,
        FTLMode, or FTLForOSREntryMode). That mode is also passed to DFG::compile().
        
        Awkwardly, this still leaves us in a no DFG->FTL tier-up situation - so
        DFG::compile() is always passed DFGMode and then it might do an FTL compile if
        possible. Fixing that is a bigger issue for a later changeset.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::checkIfOptimizationThresholdReached):
        * dfg/DFGCompilationKey.cpp: Added.
        (JSC::DFG::CompilationKey::dump):
        * dfg/DFGCompilationKey.h: Added.
        (JSC::DFG::CompilationKey::CompilationKey):
        (JSC::DFG::CompilationKey::operator!):
        (JSC::DFG::CompilationKey::isHashTableDeletedValue):
        (JSC::DFG::CompilationKey::profiledBlock):
        (JSC::DFG::CompilationKey::mode):
        (JSC::DFG::CompilationKey::operator==):
        (JSC::DFG::CompilationKey::hash):
        (JSC::DFG::CompilationKeyHash::hash):
        (JSC::DFG::CompilationKeyHash::equal):
        * dfg/DFGCompilationMode.cpp: Added.
        (WTF::printInternal):
        * dfg/DFGCompilationMode.h: Added.
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        (JSC::DFG::compile):
        * dfg/DFGDriver.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::key):
        * dfg/DFGPlan.h:
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::enqueue):
        (JSC::DFG::Worklist::compilationState):
        (JSC::DFG::Worklist::completeAllReadyPlansForVM):
        (JSC::DFG::Worklist::runThread):
        * dfg/DFGWorklist.h:
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):

2013-08-29  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed build fix after r154847.
        If you are going to exclude promises, actually exclude the build components.

        * interpreter/CallFrame.h: Exclude promise declarations
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset): Exclude promise code.
        (JSC::JSGlobalObject::visitChildren): Ditto.
        * runtime/VM.cpp: Ditto.
        (JSC::VM::VM):
        (JSC::VM::~VM):
        * runtime/VM.h:

2013-08-29  Sam Weinig  <sam@webkit.org>

        Add ENABLE guards for Promises
        https://bugs.webkit.org/show_bug.cgi?id=120488

        Reviewed by Andreas Kling.

        * Configurations/FeatureDefines.xcconfig:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSPromise.cpp:
        * runtime/JSPromise.h:
        * runtime/JSPromiseCallback.cpp:
        * runtime/JSPromiseCallback.h:
        * runtime/JSPromiseConstructor.cpp:
        * runtime/JSPromiseConstructor.h:
        * runtime/JSPromisePrototype.cpp:
        * runtime/JSPromisePrototype.h:
        * runtime/JSPromiseResolver.cpp:
        * runtime/JSPromiseResolver.h:
        * runtime/JSPromiseResolverConstructor.cpp:
        * runtime/JSPromiseResolverConstructor.h:
        * runtime/JSPromiseResolverPrototype.cpp:
        * runtime/JSPromiseResolverPrototype.h:

2013-08-29  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix FTL build.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::callCheck):

2013-08-29  Julien Brianceau  <jbriance@cisco.com>

        REGRESSION(r153222, 32-bit): NULL JSValue() seen when running peacekeeper benchmark.
        https://bugs.webkit.org/show_bug.cgi?id=120080

        Reviewed by Michael Saboff.

        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emitSlow_op_get_argument_by_val): Revert changes introduced by r153222 in this function.

2013-08-29  Filip Pizlo  <fpizlo@apple.com>

        Kill code that became dead after http://trac.webkit.org/changeset/154833

        Rubber stamped by Oliver Hunt.

        * dfg/DFGDriver.h:

2013-08-29  Filip Pizlo  <fpizlo@apple.com>

        CodeBlock's magic for scaling tier-up thresholds should be more reusable
        https://bugs.webkit.org/show_bug.cgi?id=120486

        Reviewed by Oliver Hunt.
        
        Removed the counterValueForBlah() methods and exposed the reusable scaling logic
        as a adjustedCounterValue() method.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::adjustedCounterValue):
        (JSC::CodeBlock::optimizeAfterWarmUp):
        (JSC::CodeBlock::optimizeAfterLongWarmUp):
        (JSC::CodeBlock::optimizeSoon):
        * bytecode/CodeBlock.h:
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::handleExitCounts):

2013-08-29  Filip Pizlo  <fpizlo@apple.com>

        CodeBlock::prepareForExecution() is silly
        https://bugs.webkit.org/show_bug.cgi?id=120453

        Reviewed by Oliver Hunt.
        
        Instead of saying:
        
            codeBlock->prepareForExecution(stuff, BaselineJIT, more stuff)
        
        we should just say:
        
            JIT::compile(stuff, codeBlock, more stuff);
        
        And similarly for the LLInt and DFG.
        
        This kills a bunch of code, since CodeBlock::prepareForExecution() is just a
        wrapper that uses the JITType argument to call into the appropriate execution
        engine, which is what the user wanted to do in the first place.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        (JSC::DFG::compile):
        * dfg/DFGDriver.h:
        (JSC::DFG::tryCompile):
        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::globalWorklist):
        * dfg/DFGWorklist.h:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        (JSC::JIT::compile):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntEntrypoint.cpp: Copied from Source/JavaScriptCore/llint/LLIntEntrypoints.cpp.
        (JSC::LLInt::setFunctionEntrypoint):
        (JSC::LLInt::setEvalEntrypoint):
        (JSC::LLInt::setProgramEntrypoint):
        (JSC::LLInt::setEntrypoint):
        * llint/LLIntEntrypoint.h: Copied from Source/JavaScriptCore/llint/LLIntEntrypoints.h.
        * llint/LLIntEntrypoints.cpp: Removed.
        * llint/LLIntEntrypoints.h: Removed.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::prepareForExecutionImpl):

2013-08-29  Mark Lam  <mark.lam@apple.com>

        Gardening: fixed broken non-DFG build.
        https://bugs.webkit.org/show_bug.cgi?id=120481.

        Not reviewed.

        * interpreter/StackIterator.h:

2013-08-29  Filip Pizlo  <fpizlo@apple.com>

        CodeBlock compilation and installation should be simplified and rationalized
        https://bugs.webkit.org/show_bug.cgi?id=120326

        Reviewed by Oliver Hunt.
        
        Rolling r154804 back in after fixing no-LLInt build.
        
        Previously Executable owned the code for generating JIT code; you always had
        to go through Executable. But often you also had to go through CodeBlock,
        because ScriptExecutable couldn't have virtual methods, but CodeBlock could.
        So you'd ask CodeBlock to do something, which would dispatch through a
        virtual method that would select the appropriate Executable subtype's method.
        This all meant that the same code would often be duplicated, because most of
        the work needed to compile something was identical regardless of code type.
        But then we tried to fix this, by having templatized helpers in
        ExecutionHarness.h and JITDriver.h. The result was that if you wanted to find
        out what happened when you asked for something to be compiled, you'd go on a
        wild ride that started with CodeBlock, touched upon Executable, and then
        ricocheted into either ExecutionHarness or JITDriver (likely both).
        
        Another awkwardness was that for concurrent compiles, the DFG::Worklist had
        super-special inside knowledge of what JITStubs.cpp's cti_optimize would have
        done once the compilation finished.
        
        Also, most of the DFG JIT drivers assumed that they couldn't install the
        JITCode into the CodeBlock directly - instead they would return it via a
        reference, which happened to be a reference to the JITCode pointer in
        Executable. This was super weird.
        
        Finally, there was no notion of compiling code into a special CodeBlock that
        wasn't used for handling calls into an Executable. I'd like this for FTL OSR
        entry.
        
        This patch solves these problems by reducing all of that complexity into just
        three primitives:
        
        - Executable::newCodeBlock(). This gives you a new code block, either for call
          or for construct, and either to serve as the baseline code or the optimized
          code. The new code block is then owned by the caller; Executable doesn't
          register it anywhere. The new code block has no JITCode and isn't callable,
          but it has all of the bytecode.
        
        - CodeBlock::prepareForExecution(). This takes the CodeBlock's bytecode and
          produces a JITCode, and then installs the JITCode into the CodeBlock. This
          method takes a JITType, and always compiles with that JIT. If you ask for
          JITCode::InterpreterThunk then you'll get JITCode that just points to the
          LLInt entrypoints. Once this returns, it is possible to call into the
          CodeBlock if you do so manually - but the Executable still won't know about
          it so JS calls to that Executable will still be routed to whatever CodeBlock
          is associated with the Executable.
        
        - Executable::installCode(). This takes a CodeBlock and makes it the code-for-
          entry for that Executable. This involves unlinking the Executable's last
          CodeBlock, if there was one. This also tells the GC about any effect on
          memory usage and does a bunch of weird data structure rewiring, since
          Executable caches some of CodeBlock's fields for the benefit of virtual call
          fast paths.
        
        This functionality is then wrapped around three convenience methods:
        
        - Executable::prepareForExecution(). If there is no code block for that
          Executable, then one is created (newCodeBlock()), compiled
          (CodeBlock::prepareForExecution()) and installed (installCode()).
        
        - CodeBlock::newReplacement(). Asks the Executable for a new CodeBlock that
          can serve as an optimized replacement of the current one.
        
        - CodeBlock::install(). Asks the Executable to install this code block.
        
        This patch allows me to kill *a lot* of code and to remove a lot of
        specializations for functions vs. not-functions, and a lot of places where we
        pass around JITCode references and such. ExecutionHarness and JITDriver are
        both gone. Overall this patch has more red than green.
        
        It also allows me to work on FTL OSR entry and tier-up:
        
        - FTL tier-up: this will involve DFGOperations.cpp asking the DFG::Worklist
          to do some compilation, but it will require the DFG::Worklist to do
          something different than what JITStubs.cpp would want, once the compilation
          finishes. This patch introduces a callback mechanism for that purpose.
        
        - FTL OSR entry: this will involve creating a special auto-jettisoned
          CodeBlock that is used only for FTL OSR entry. The new set of primitives
          allows for this: Executable can vend you a fresh new CodeBlock, and you can
          ask that CodeBlock to compile itself with any JIT of your choosing. Or you
          can take that CodeBlock and compile it yourself. Previously the act of
          producing a CodeBlock-for-optimization and the act of compiling code for it
          were tightly coupled; now you can separate them and you can create such
          auto-jettisoned CodeBlocks that are used for a one-shot OSR entry.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::unlinkIncomingCalls):
        (JSC::CodeBlock::prepareForExecutionImpl):
        (JSC::CodeBlock::prepareForExecution):
        (JSC::CodeBlock::prepareForExecutionAsynchronously):
        (JSC::CodeBlock::install):
        (JSC::CodeBlock::newReplacement):
        (JSC::FunctionCodeBlock::jettisonImpl):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::hasBaselineJITProfiling):
        * bytecode/DeferredCompilationCallback.cpp: Added.
        (JSC::DeferredCompilationCallback::DeferredCompilationCallback):
        (JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
        * bytecode/DeferredCompilationCallback.h: Added.
        * dfg/DFGDriver.cpp:
        (JSC::DFG::tryCompile):
        * dfg/DFGDriver.h:
        (JSC::DFG::tryCompile):
        * dfg/DFGFailedFinalizer.cpp:
        (JSC::DFG::FailedFinalizer::finalize):
        (JSC::DFG::FailedFinalizer::finalizeFunction):
        * dfg/DFGFailedFinalizer.h:
        * dfg/DFGFinalizer.h:
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        * dfg/DFGJITFinalizer.h:
        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::notifyReady):
        (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
        (JSC::DFG::Plan::finalizeAndNotifyCallback):
        * dfg/DFGPlan.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::completeAllReadyPlansForVM):
        (JSC::DFG::Worklist::runThread):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalize):
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h:
        * heap/Heap.h:
        (JSC::Heap::isDeferred):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * jit/JITDriver.h: Removed.
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::jitCompileFor):
        (JSC::lazyLinkFor):
        * jit/JITToDFGDeferredCompilationCallback.cpp: Added.
        (JSC::JITToDFGDeferredCompilationCallback::JITToDFGDeferredCompilationCallback):
        (JSC::JITToDFGDeferredCompilationCallback::~JITToDFGDeferredCompilationCallback):
        (JSC::JITToDFGDeferredCompilationCallback::create):
        (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
        (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
        * jit/JITToDFGDeferredCompilationCallback.h: Added.
        * llint/LLIntEntrypoints.cpp:
        (JSC::LLInt::setFunctionEntrypoint):
        (JSC::LLInt::setEvalEntrypoint):
        (JSC::LLInt::setProgramEntrypoint):
        * llint/LLIntEntrypoints.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::setUpCall):
        * runtime/ArrayPrototype.cpp:
        (JSC::isNumericCompareFunction):
        * runtime/CommonSlowPaths.cpp:
        * runtime/CompilationResult.cpp:
        (WTF::printInternal):
        * runtime/CompilationResult.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::installCode):
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ScriptExecutable::newReplacementCodeBlockFor):
        (JSC::ScriptExecutable::prepareForExecutionImpl):
        * runtime/Executable.h:
        (JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor):
        (JSC::ExecutableBase::offsetOfNumParametersFor):
        (JSC::ScriptExecutable::prepareForExecution):
        (JSC::FunctionExecutable::jettisonOptimizedCodeFor):
        * runtime/ExecutionHarness.h: Removed.

2013-08-29  Mark Lam  <mark.lam@apple.com>

        Change StackIterator to not require writes to the JS stack.
        https://bugs.webkit.org/show_bug.cgi?id=119657.

        Reviewed by Geoffrey Garen.

        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/CallFrame.h:
        - Removed references to StackIteratorPrivate.h.
        * interpreter/StackIterator.cpp:
        (JSC::StackIterator::numberOfFrames):
        (JSC::StackIterator::gotoFrameAtIndex):
        (JSC::StackIterator::gotoNextFrame):
        (JSC::StackIterator::resetIterator):
        (JSC::StackIterator::find):
        (JSC::StackIterator::readFrame):
        (JSC::StackIterator::readNonInlinedFrame):
        - Reads in the current CallFrame's data for non-inlined frames.
        (JSC::inlinedFrameOffset):
        - Convenience function to compute the inlined frame offset based on the
          CodeOrigin. If the offset is 0, then we're looking at the physical frame.
          Otherwise, it's an inlined frame.
        (JSC::StackIterator::readInlinedFrame):
        - Determines the inlined frame's caller frame. Will read in the caller
          frame if it is also an inlined frame i.e. we haven't reached the
          outer most frame yet. Otherwise, will call readNonInlinedFrame() to
          read on the outer most frame.
          This is based on the old StackIterator::Frame::logicalFrame().
        (JSC::StackIterator::updateFrame):
        - Reads the data of the caller frame of the current one. This function
          is renamed and moved from the old StackIterator::Frame::logicalCallerFrame(),
          but is now simplified because it delegates to the readInlinedFrame()
          to get the caller for inlined frames.
        (JSC::StackIterator::Frame::arguments):
        - Fixed to use the inlined frame versions of Arguments::create() and
          Arguments::tearOff() when the frame is an inlined frame.
        (JSC::StackIterator::Frame::print):
        (debugPrintCallFrame):
        (debugPrintStack):
        - Because sometimes, we want to see the whole stack while debugging.
        * interpreter/StackIterator.h:
        (JSC::StackIterator::Frame::argumentCount):
        (JSC::StackIterator::Frame::callerFrame):
        (JSC::StackIterator::Frame::callee):
        (JSC::StackIterator::Frame::scope):
        (JSC::StackIterator::Frame::codeBlock):
        (JSC::StackIterator::Frame::bytecodeOffset):
        (JSC::StackIterator::Frame::inlinedFrameInfo):
        (JSC::StackIterator::Frame::isJSFrame):
        (JSC::StackIterator::Frame::isInlinedFrame):
        (JSC::StackIterator::Frame::callFrame):
        (JSC::StackIterator::Frame::Frame):
        (JSC::StackIterator::Frame::~Frame):
        - StackIterator::Frame now caches commonly used accessed values from
          the CallFrame. It still delegates argument queries to the CallFrame.
        (JSC::StackIterator::operator*):
        (JSC::StackIterator::operator->):
        (JSC::StackIterator::operator!=):
        (JSC::StackIterator::operator++):
        (JSC::StackIterator::end):
        (JSC::StackIterator::operator==):
        * interpreter/StackIteratorPrivate.h: Removed.

2013-08-29  Chris Curtis  <chris_curtis@apple.com>

        VM::throwException() crashes reproducibly in testapi with !ENABLE(JIT)
        https://bugs.webkit.org/show_bug.cgi?id=120472

        Reviewed by Filip Pizlo.
        
        With the JIT disabled, interpreterThrowInCaller was attempting to throw an error, 
        but the topCallFrame was not set yet. By passing the error object into interpreterThrowInCaller
        throwException can be called when topCallFrame is set.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPathsExceptions.cpp:
        (JSC::CommonSlowPaths::interpreterThrowInCaller):
        * runtime/CommonSlowPathsExceptions.h:

        Renamed genericThrow -> genericUnwind, because this function no longer has the ability
        to throw errors. It unwinds the stack in order to report them. 
        * dfg/DFGOperations.cpp:
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        (JSC::jitThrowNew):
        (JSC::jitThrow):
        * jit/JITExceptions.h:
        * llint/LLIntExceptions.cpp:
        (JSC::LLInt::doThrow):
    
2013-08-29  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r154804.
        http://trac.webkit.org/changeset/154804
        https://bugs.webkit.org/show_bug.cgi?id=120477

        Broke Windows build (assumes LLInt features not enabled on
        this build) (Requested by bfulgham on #webkit).

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::linkIncomingCall):
        (JSC::CodeBlock::unlinkIncomingCalls):
        (JSC::CodeBlock::reoptimize):
        (JSC::ProgramCodeBlock::replacement):
        (JSC::EvalCodeBlock::replacement):
        (JSC::FunctionCodeBlock::replacement):
        (JSC::ProgramCodeBlock::compileOptimized):
        (JSC::ProgramCodeBlock::replaceWithDeferredOptimizedCode):
        (JSC::EvalCodeBlock::compileOptimized):
        (JSC::EvalCodeBlock::replaceWithDeferredOptimizedCode):
        (JSC::FunctionCodeBlock::compileOptimized):
        (JSC::FunctionCodeBlock::replaceWithDeferredOptimizedCode):
        (JSC::ProgramCodeBlock::jitCompileImpl):
        (JSC::EvalCodeBlock::jitCompileImpl):
        (JSC::FunctionCodeBlock::jitCompileImpl):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::jitType):
        (JSC::CodeBlock::jitCompile):
        * bytecode/DeferredCompilationCallback.cpp: Removed.
        * bytecode/DeferredCompilationCallback.h: Removed.
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        (JSC::DFG::tryFinalizePlan):
        * dfg/DFGDriver.h:
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        (JSC::DFG::tryFinalizePlan):
        * dfg/DFGFailedFinalizer.cpp:
        (JSC::DFG::FailedFinalizer::finalize):
        (JSC::DFG::FailedFinalizer::finalizeFunction):
        * dfg/DFGFailedFinalizer.h:
        * dfg/DFGFinalizer.h:
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        * dfg/DFGJITFinalizer.h:
        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::finalize):
        * dfg/DFGPlan.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::completeAllReadyPlansForVM):
        (JSC::DFG::Worklist::runThread):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalize):
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h:
        * heap/Heap.h:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * jit/JITDriver.h: Added.
        (JSC::jitCompileIfAppropriateImpl):
        (JSC::jitCompileFunctionIfAppropriateImpl):
        (JSC::jitCompileIfAppropriate):
        (JSC::jitCompileFunctionIfAppropriate):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::jitCompileFor):
        (JSC::lazyLinkFor):
        * jit/JITToDFGDeferredCompilationCallback.cpp: Removed.
        * jit/JITToDFGDeferredCompilationCallback.h: Removed.
        * llint/LLIntEntrypoints.cpp:
        (JSC::LLInt::getFunctionEntrypoint):
        (JSC::LLInt::getEvalEntrypoint):
        (JSC::LLInt::getProgramEntrypoint):
        * llint/LLIntEntrypoints.h:
        (JSC::LLInt::getEntrypoint):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::setUpCall):
        * runtime/ArrayPrototype.cpp:
        (JSC::isNumericCompareFunction):
        * runtime/CommonSlowPaths.cpp:
        * runtime/CompilationResult.cpp:
        (WTF::printInternal):
        * runtime/CompilationResult.h:
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileOptimized):
        (JSC::EvalExecutable::jitCompile):
        (JSC::EvalExecutable::compileInternal):
        (JSC::EvalExecutable::replaceWithDeferredOptimizedCode):
        (JSC::ProgramExecutable::compileOptimized):
        (JSC::ProgramExecutable::jitCompile):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::ProgramExecutable::replaceWithDeferredOptimizedCode):
        (JSC::FunctionExecutable::compileOptimizedForCall):
        (JSC::FunctionExecutable::compileOptimizedForConstruct):
        (JSC::FunctionExecutable::jitCompileForCall):
        (JSC::FunctionExecutable::jitCompileForConstruct):
        (JSC::FunctionExecutable::produceCodeBlockFor):
        (JSC::FunctionExecutable::compileForCallInternal):
        (JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeForCall):
        (JSC::FunctionExecutable::compileForConstructInternal):
        (JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeForConstruct):
        * runtime/Executable.h:
        (JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor):
        (JSC::ExecutableBase::offsetOfNumParametersFor):
        (JSC::ExecutableBase::catchRoutineFor):
        (JSC::EvalExecutable::compile):
        (JSC::ProgramExecutable::compile):
        (JSC::FunctionExecutable::compileForCall):
        (JSC::FunctionExecutable::compileForConstruct):
        (JSC::FunctionExecutable::compileFor):
        (JSC::FunctionExecutable::compileOptimizedFor):
        (JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeFor):
        (JSC::FunctionExecutable::jitCompileFor):
        * runtime/ExecutionHarness.h: Added.
        (JSC::prepareForExecutionImpl):
        (JSC::prepareFunctionForExecutionImpl):
        (JSC::installOptimizedCode):
        (JSC::prepareForExecution):
        (JSC::prepareFunctionForExecution):
        (JSC::replaceWithDeferredOptimizedCode):

2013-08-28  Filip Pizlo  <fpizlo@apple.com>

        CodeBlock compilation and installation should be simplified and rationalized
        https://bugs.webkit.org/show_bug.cgi?id=120326

        Reviewed by Oliver Hunt.
        
        Previously Executable owned the code for generating JIT code; you always had
        to go through Executable. But often you also had to go through CodeBlock,
        because ScriptExecutable couldn't have virtual methods, but CodeBlock could.
        So you'd ask CodeBlock to do something, which would dispatch through a
        virtual method that would select the appropriate Executable subtype's method.
        This all meant that the same code would often be duplicated, because most of
        the work needed to compile something was identical regardless of code type.
        But then we tried to fix this, by having templatized helpers in
        ExecutionHarness.h and JITDriver.h. The result was that if you wanted to find
        out what happened when you asked for something to be compiled, you'd go on a
        wild ride that started with CodeBlock, touched upon Executable, and then
        ricocheted into either ExecutionHarness or JITDriver (likely both).
        
        Another awkwardness was that for concurrent compiles, the DFG::Worklist had
        super-special inside knowledge of what JITStubs.cpp's cti_optimize would have
        done once the compilation finished.
        
        Also, most of the DFG JIT drivers assumed that they couldn't install the
        JITCode into the CodeBlock directly - instead they would return it via a
        reference, which happened to be a reference to the JITCode pointer in
        Executable. This was super weird.
        
        Finally, there was no notion of compiling code into a special CodeBlock that
        wasn't used for handling calls into an Executable. I'd like this for FTL OSR
        entry.
        
        This patch solves these problems by reducing all of that complexity into just
        three primitives:
        
        - Executable::newCodeBlock(). This gives you a new code block, either for call
          or for construct, and either to serve as the baseline code or the optimized
          code. The new code block is then owned by the caller; Executable doesn't
          register it anywhere. The new code block has no JITCode and isn't callable,
          but it has all of the bytecode.
        
        - CodeBlock::prepareForExecution(). This takes the CodeBlock's bytecode and
          produces a JITCode, and then installs the JITCode into the CodeBlock. This
          method takes a JITType, and always compiles with that JIT. If you ask for
          JITCode::InterpreterThunk then you'll get JITCode that just points to the
          LLInt entrypoints. Once this returns, it is possible to call into the
          CodeBlock if you do so manually - but the Executable still won't know about
          it so JS calls to that Executable will still be routed to whatever CodeBlock
          is associated with the Executable.
        
        - Executable::installCode(). This takes a CodeBlock and makes it the code-for-
          entry for that Executable. This involves unlinking the Executable's last
          CodeBlock, if there was one. This also tells the GC about any effect on
          memory usage and does a bunch of weird data structure rewiring, since
          Executable caches some of CodeBlock's fields for the benefit of virtual call
          fast paths.
        
        This functionality is then wrapped around three convenience methods:
        
        - Executable::prepareForExecution(). If there is no code block for that
          Executable, then one is created (newCodeBlock()), compiled
          (CodeBlock::prepareForExecution()) and installed (installCode()).
        
        - CodeBlock::newReplacement(). Asks the Executable for a new CodeBlock that
          can serve as an optimized replacement of the current one.
        
        - CodeBlock::install(). Asks the Executable to install this code block.
        
        This patch allows me to kill *a lot* of code and to remove a lot of
        specializations for functions vs. not-functions, and a lot of places where we
        pass around JITCode references and such. ExecutionHarness and JITDriver are
        both gone. Overall this patch has more red than green.
        
        It also allows me to work on FTL OSR entry and tier-up:
        
        - FTL tier-up: this will involve DFGOperations.cpp asking the DFG::Worklist
          to do some compilation, but it will require the DFG::Worklist to do
          something different than what JITStubs.cpp would want, once the compilation
          finishes. This patch introduces a callback mechanism for that purpose.
        
        - FTL OSR entry: this will involve creating a special auto-jettisoned
          CodeBlock that is used only for FTL OSR entry. The new set of primitives
          allows for this: Executable can vend you a fresh new CodeBlock, and you can
          ask that CodeBlock to compile itself with any JIT of your choosing. Or you
          can take that CodeBlock and compile it yourself. Previously the act of
          producing a CodeBlock-for-optimization and the act of compiling code for it
          were tightly coupled; now you can separate them and you can create such
          auto-jettisoned CodeBlocks that are used for a one-shot OSR entry.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::prepareForExecution):
        (JSC::CodeBlock::install):
        (JSC::CodeBlock::newReplacement):
        (JSC::FunctionCodeBlock::jettisonImpl):
        (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::hasBaselineJITProfiling):
        * bytecode/DeferredCompilationCallback.cpp: Added.
        (JSC::DeferredCompilationCallback::DeferredCompilationCallback):
        (JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
        * bytecode/DeferredCompilationCallback.h: Added.
        * dfg/DFGDriver.cpp:
        (JSC::DFG::tryCompile):
        * dfg/DFGDriver.h:
        (JSC::DFG::tryCompile):
        * dfg/DFGFailedFinalizer.cpp:
        (JSC::DFG::FailedFinalizer::finalize):
        (JSC::DFG::FailedFinalizer::finalizeFunction):
        * dfg/DFGFailedFinalizer.h:
        * dfg/DFGFinalizer.h:
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        * dfg/DFGJITFinalizer.h:
        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::compileInThreadImpl):
        (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
        (JSC::DFG::Plan::finalizeAndNotifyCallback):
        * dfg/DFGPlan.h:
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::completeAllReadyPlansForVM):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalize):
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h:
        * heap/Heap.h:
        (JSC::Heap::isDeferred):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * jit/JITDriver.h: Removed.
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::jitCompileFor):
        (JSC::lazyLinkFor):
        * jit/JITToDFGDeferredCompilationCallback.cpp: Added.
        (JSC::JITToDFGDeferredCompilationCallback::JITToDFGDeferredCompilationCallback):
        (JSC::JITToDFGDeferredCompilationCallback::~JITToDFGDeferredCompilationCallback):
        (JSC::JITToDFGDeferredCompilationCallback::create):
        (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
        * jit/JITToDFGDeferredCompilationCallback.h: Added.
        * llint/LLIntEntrypoints.cpp:
        (JSC::LLInt::setFunctionEntrypoint):
        (JSC::LLInt::setEvalEntrypoint):
        (JSC::LLInt::setProgramEntrypoint):
        * llint/LLIntEntrypoints.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::setUpCall):
        * runtime/ArrayPrototype.cpp:
        (JSC::isNumericCompareFunction):
        * runtime/CommonSlowPaths.cpp:
        * runtime/CompilationResult.cpp:
        (WTF::printInternal):
        * runtime/CompilationResult.h:
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::installCode):
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ScriptExecutable::newReplacementCodeBlockFor):
        (JSC::ScriptExecutable::prepareForExecutionImpl):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::prepareForExecution):
        (JSC::FunctionExecutable::jettisonOptimizedCodeFor):
        * runtime/ExecutionHarness.h: Removed.

2013-08-28  Chris Curtis  <chris_curtis@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=119548
        Refactoring Exception throws.
        
        Reviewed by Geoffrey Garen.
        
        Gardening of exception throws. The act of throwing an exception was being handled in 
        different ways depending on whether the code was running in the LLint, Baseline JIT, 
        or the DFG Jit. This made development in the vm exception and error objects difficult.
        
         * runtime/VM.cpp:
        (JSC::appendSourceToError): 
        This function moved from the interpreter into the VM. It views the developers code
        (if there is a codeBlock) to extract what was trying to be evaluated when the error
        occurred.
        
        (JSC::VM::throwException):
        This function takes in the error object and sets the following:
            1: The VM's exception stack
            2: The VM's exception 
            3: Appends extra information on the error message(via appendSourceToError)
            4: The error object's line number
            5: The error object's column number
            6: The error object's sourceURL
            7: The error object's stack trace (unless it already exists because the developer 
                created the error object). 

        (JSC::VM::getExceptionInfo):
        (JSC::VM::setExceptionInfo):
        (JSC::VM::clearException):
        (JSC::clearExceptionStack):
        * runtime/VM.h:
        (JSC::VM::exceptionOffset):
        (JSC::VM::exception):
        (JSC::VM::addressOfException):
        (JSC::VM::exceptionStack):
        VM exception and exceptionStack are now private data members.

        * interpreter/Interpreter.h:
        (JSC::ClearExceptionScope::ClearExceptionScope):
        Created this structure to temporarily clear the exception within the VM. This 
        needed to see if addition errors occur when setting the debugger as we are 
        unwinding the stack.

         * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwind): 
        Removed the code that would try to add error information if it did not exist. 
        All of this functionality has moved into the VM and all error information is set 
        at the time the error occurs. 

        The rest of these functions reference the new calling convention to throw an error.

        * API/APICallbackFunction.h:
        (JSC::APICallbackFunction::call):
        * API/JSCallbackConstructor.cpp:
        (JSC::constructJSCallback):
        * API/JSCallbackObjectFunctions.h:
        (JSC::::getOwnPropertySlot):
        (JSC::::defaultValue):
        (JSC::::put):
        (JSC::::putByIndex):
        (JSC::::deleteProperty):
        (JSC::::construct):
        (JSC::::customHasInstance):
        (JSC::::call):
        (JSC::::getStaticValue):
        (JSC::::staticFunctionGetter):
        (JSC::::callbackGetter):
        * debugger/Debugger.cpp:
        (JSC::evaluateInGlobalCallFrame):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluate):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::emitExceptionCheck):
        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationPutByValInternal):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::callCheck):
        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        * interpreter/CallFrame.h:
        (JSC::ExecState::clearException):
        (JSC::ExecState::exception):
        (JSC::ExecState::hadException):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        (JSC::loadVarargs):
        (JSC::stackTraceAsString):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * interpreter/Interpreter.h:
        (JSC::ClearExceptionScope::ClearExceptionScope):
        * jit/JITCode.cpp:
        (JSC::JITCode::execute):
        * jit/JITExceptions.cpp:
        (JSC::genericThrow):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emit_op_catch):
        * jit/JITStubs.cpp:
        (JSC::returnToThrowTrampoline):
        (JSC::throwExceptionFromOpCall):
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::jitCompileFor):
        (JSC::lazyLinkFor):
        (JSC::putByVal):
        (JSC::cti_vm_handle_exception):
        * jit/SlowPathCall.h:
        (JSC::JITSlowPathCall::call):
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        * jsc.cpp:
        (functionRun):
        (functionLoad):
        (functionCheckSyntax):
        * llint/LLIntExceptions.cpp:
        (JSC::LLInt::doThrow):
        (JSC::LLInt::returnToThrow):
        (JSC::LLInt::callToThrow):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ArrayConstructor.cpp:
        (JSC::constructArrayWithSizeQuirk):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::opIn):
        * runtime/CommonSlowPathsExceptions.cpp:
        (JSC::CommonSlowPaths::interpreterThrowInCaller):
        * runtime/Completion.cpp:
        (JSC::evaluate):
        * runtime/Error.cpp:
        (JSC::addErrorInfo):
        (JSC::throwTypeError):
        (JSC::throwSyntaxError):
        * runtime/Error.h:
        (JSC::throwVMError):
        * runtime/ExceptionHelpers.cpp:
        (JSC::throwOutOfMemoryError):
        (JSC::throwStackOverflowError):
        (JSC::throwTerminatedExecutionException):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::create):
        (JSC::FunctionExecutable::produceCodeBlockFor):
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty):
        (JSC::JSArray::put):
        (JSC::JSArray::push):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::toObjectSlowCase):
        (JSC::JSValue::synthesizePrototype):
        (JSC::JSValue::putToPrimitive):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::::create):
        (JSC::::createUninitialized):
        (JSC::::validateRange):
        (JSC::::setWithSpecificType):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::encode):
        (JSC::decode):
        (JSC::globalFuncProtoSetter):
        * runtime/JSNameScope.cpp:
        (JSC::JSNameScope::put):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::appendStringifiedValue):
        (JSC::Walker::walk):
        * runtime/JSObject.cpp:
        (JSC::JSObject::put):
        (JSC::JSObject::defaultValue):
        (JSC::JSObject::hasInstance):
        (JSC::JSObject::defaultHasInstance):
        (JSC::JSObject::defineOwnNonIndexProperty):
        (JSC::throwTypeError):
        * runtime/ObjectConstructor.cpp:
        (JSC::toPropertyDescriptor):
        * runtime/RegExpConstructor.cpp:
        (JSC::constructRegExp):
        * runtime/StringObject.cpp:
        (JSC::StringObject::defineOwnProperty):
        * runtime/StringRecursionChecker.cpp:
        (JSC::StringRecursionChecker::throwStackOverflowError):

2013-08-28  Zan Dobersek  <zdobersek@igalia.com>

        [GTK] Add support for building JSC with FTL JIT enabled
        https://bugs.webkit.org/show_bug.cgi?id=120270

        Reviewed by Filip Pizlo.

        * GNUmakefile.am: Add LLVM_LIBS to the list of linker flags and LLVM_CFLAGS to the list of
        compiler flags for the JSC library.
        * GNUmakefile.list.am: Add the missing build targets.
        * ftl/FTLAbbreviations.h: Include the <cstring> header and use std::strlen. This avoids compilation
        failures when using the Clang compiler with the libstdc++ standard library.
        (JSC::FTL::mdKindID):
        (JSC::FTL::mdString):

2013-08-23  Andy Estes  <aestes@apple.com>

        Fix issues found by the Clang Static Analyzer
        https://bugs.webkit.org/show_bug.cgi?id=120230

        Reviewed by Darin Adler.

        * API/JSValue.mm:
        (valueToString): Don't leak every CFStringRef when in Objective-C GC.
        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunctionImpl::~ObjCCallbackFunctionImpl): Don't
        release m_invocation's target since NSInvocation will do it for us on
        -dealloc.
        (objCCallbackFunctionForBlock): Tell NSInvocation to retain its target
        and -release our reference to the copied block.
        * API/tests/minidom.c:
        (createStringWithContentsOfFile): Free buffer before returning.
        * API/tests/testapi.c:
        (createStringWithContentsOfFile): Ditto.

2013-08-26  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed build fix after r154629.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add missing build files.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2013-08-26  Ryosuke Niwa  <rniwa@webkit.org>

        Windows build fix attempt after r154629.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:

2013-08-25  Mark Hahnenberg  <mhahnenberg@apple.com>

        JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage does a check on the length of the ArrayStorage after possible reallocing it
        https://bugs.webkit.org/show_bug.cgi?id=120278

        Reviewed by Geoffrey Garen.

        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):

2013-08-26  Filip Pizlo  <fpizlo@apple.com>

        Fix indention of Executable.h.

        Rubber stamped by Mark Hahnenberg.

        * runtime/Executable.h:

2013-08-26  Mark Hahnenberg  <mhahnenberg@apple.com>

        Object.defineProperty should be able to create a PropertyDescriptor where m_attributes == 0
        https://bugs.webkit.org/show_bug.cgi?id=120314

        Reviewed by Darin Adler.

        Currently with the way that defineProperty works, we leave a stray low bit set in 
        PropertyDescriptor::m_attributes in the following code:

        var o = {};
        Object.defineProperty(o, 100, {writable:true, enumerable:true, configurable:true, value:"foo"});
        
        This is due to the fact that the lowest non-zero attribute (ReadOnly) is represented as 1 << 1 
        instead of 1 << 0. We then calculate the default attributes as (DontDelete << 1) - 1, which is 0xF, 
        but only the top three bits mean anything. Even in the case above, the top three bits are set 
        to 0 but the bottom bit remains set, which causes us to think m_attributes is non-zero.

        Since some of these attributes and their corresponding values are exposed in the JavaScriptCore 
        framework's public C API, it's safer to just change how we calculate the default value, which is
        where the weirdness was originating from in the first place.

        * runtime/PropertyDescriptor.cpp:

2013-08-24  Sam Weinig  <sam@webkit.org>

        Add support for Promises
        https://bugs.webkit.org/show_bug.cgi?id=120260

        Reviewed by Darin Adler.

        Add an initial implementation of Promises - http://dom.spec.whatwg.org/#promises.
        - Despite Promises being defined in the DOM, the implementation is being put in JSC
          in preparation for the Promises eventually being defined in ECMAScript.

        * CMakeLists.txt:
        * DerivedSources.make:
        * DerivedSources.pri:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        Add new files.

        * jsc.cpp:
        Update jsc's GlobalObjectMethodTable to stub out the new QueueTaskToEventLoop callback. This mean's
        you can't quite use Promises with with the command line tool yet.
    
        * interpreter/CallFrame.h:
        (JSC::ExecState::promisePrototypeTable):
        (JSC::ExecState::promiseConstructorTable):
        (JSC::ExecState::promiseResolverPrototypeTable):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        * runtime/VM.h:
        Add supporting code for the new static lookup tables.

        * runtime/CommonIdentifiers.h:
        Add 3 new identifiers, "Promise", "PromiseResolver", and "then".

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC::JSGlobalObject::visitChildren):
        Add supporting code Promise and PromiseResolver's constructors and structures.

        * runtime/JSGlobalObject.h:
        (JSC::TaskContext::~TaskContext):
        Add a new callback to the GlobalObjectMethodTable to post a task on the embedder's runloop.

        (JSC::JSGlobalObject::promisePrototype):
        (JSC::JSGlobalObject::promiseResolverPrototype):
        (JSC::JSGlobalObject::promiseStructure):
        (JSC::JSGlobalObject::promiseResolverStructure):
        (JSC::JSGlobalObject::promiseCallbackStructure):
        (JSC::JSGlobalObject::promiseWrapperCallbackStructure):
        Add supporting code Promise and PromiseResolver's constructors and structures.

        * runtime/JSPromise.cpp: Added.
        * runtime/JSPromise.h: Added.
        * runtime/JSPromiseCallback.cpp: Added.
        * runtime/JSPromiseCallback.h: Added.
        * runtime/JSPromiseConstructor.cpp: Added.
        * runtime/JSPromiseConstructor.h: Added.
        * runtime/JSPromisePrototype.cpp: Added.
        * runtime/JSPromisePrototype.h: Added.
        * runtime/JSPromiseResolver.cpp: Added.
        * runtime/JSPromiseResolver.h: Added.
        * runtime/JSPromiseResolverConstructor.cpp: Added.
        * runtime/JSPromiseResolverConstructor.h: Added.
        * runtime/JSPromiseResolverPrototype.cpp: Added.
        * runtime/JSPromiseResolverPrototype.h: Added.
        Add Promise implementation.

2013-08-26  Zan Dobersek  <zdobersek@igalia.com>

        Plenty of -Wcast-align warnings in KeywordLookup.h
        https://bugs.webkit.org/show_bug.cgi?id=120316

        Reviewed by Darin Adler.

        * KeywordLookupGenerator.py: Use reinterpret_cast instead of a C-style cast when casting
        the character pointers to types of larger size. This avoids spewing lots of warnings
        in the KeywordLookup.h header when compiling with the -Wcast-align option.

2013-08-26  Gavin Barraclough  <barraclough@apple.com>

        RegExpMatchesArray should not call [[put]]
        https://bugs.webkit.org/show_bug.cgi?id=120317

        Reviewed by Oliver Hunt.

        This will call accessors on the JSObject/JSArray prototypes - so adding an accessor or read-only
        property called index or input to either of these prototypes will result in broken behavior.

        * runtime/RegExpMatchesArray.cpp:
        (JSC::RegExpMatchesArray::reifyAllProperties):
            - put -> putDirect

2013-08-24  Filip Pizlo  <fpizlo@apple.com>

        FloatTypedArrayAdaptor::toJSValue should almost certainly not use jsNumber() since that attempts int conversions
        https://bugs.webkit.org/show_bug.cgi?id=120228

        Reviewed by Oliver Hunt.
        
        It turns out that there were three problems:
        
        - Using jsNumber() meant that we were converting doubles to integers and then
          possibly back again whenever doing a set() between floating point arrays.
        
        - Slow-path accesses to double typed arrays were slower than necessary because
          of the to-int conversion attempt.
        
        - The use of JSValue as an intermediate for converting between differen types
          in typedArray.set() resulted in worse code than I had previously expected.
        
        This patch solves the problem by using template double-dispatch to ensure that
        that C++ compiler sees the simplest possible combination of casts between any
        combination of typed array types, while still preserving JS and typed array
        conversion semantics. Conversions are done as follows:
        
            SourceAdaptor::convertTo<TargetAdaptor>(value)
        
        Internally, convertTo() calls one of three possible methods on TargetAdaptor,
        with one method for each of int32_t, uint32_t, and double. This means that the
        C++ compiler will at worst see a widening cast to one of those types followed
        by a narrowing conversion (not necessarily a cast - may have clamping or the
        JS toInt32() function).
        
        This change doesn't just affect typedArray.set(); it also affects slow-path
        accesses to typed arrays as well. This patch also adds a bunch of new test
        coverage.
        
        This change is a ~50% speed-up on typedArray.set() involving floating point
        types.

        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/GenericTypedArrayView.h:
        (JSC::GenericTypedArrayView::set):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::setData):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
        (JSC::JSGenericTypedArrayView::setIndexQuickly):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::::setWithSpecificType):
        (JSC::::set):
        * runtime/ToNativeFromValue.h: Added.
        (JSC::toNativeFromValue):
        * runtime/TypedArrayAdaptors.h:
        (JSC::IntegralTypedArrayAdaptor::toJSValue):
        (JSC::IntegralTypedArrayAdaptor::toDouble):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromInt32):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromUint32):
        (JSC::IntegralTypedArrayAdaptor::toNativeFromDouble):
        (JSC::IntegralTypedArrayAdaptor::convertTo):
        (JSC::FloatTypedArrayAdaptor::toJSValue):
        (JSC::FloatTypedArrayAdaptor::toDouble):
        (JSC::FloatTypedArrayAdaptor::toNativeFromInt32):
        (JSC::FloatTypedArrayAdaptor::toNativeFromUint32):
        (JSC::FloatTypedArrayAdaptor::toNativeFromDouble):
        (JSC::FloatTypedArrayAdaptor::convertTo):
        (JSC::Uint8ClampedAdaptor::toJSValue):
        (JSC::Uint8ClampedAdaptor::toDouble):
        (JSC::Uint8ClampedAdaptor::toNativeFromInt32):
        (JSC::Uint8ClampedAdaptor::toNativeFromUint32):
        (JSC::Uint8ClampedAdaptor::toNativeFromDouble):
        (JSC::Uint8ClampedAdaptor::convertTo):

2013-08-24  Dan Bernstein  <mitz@apple.com>

        [mac] link against libz in a more civilized manner
        https://bugs.webkit.org/show_bug.cgi?id=120258

        Reviewed by Darin Adler.

        * Configurations/JavaScriptCore.xcconfig: Removed “-lz” from OTHER_LDFLAGS_BASE.
        * JavaScriptCore.xcodeproj/project.pbxproj: Added libz.dylib to the JavaScriptCore target’s
        Link Binary With Libraries build phase.

2013-08-23  Laszlo Papp  <lpapp@kde.org>

        Failure building with python3
        https://bugs.webkit.org/show_bug.cgi?id=106645

        Reviewed by Benjamin Poulain.

        Use print functions instead of python statements to be compatible with python 3.X and 2.7 as well.
        Archlinux has been using python3 and that is what causes issues while packaging QtWebKit along with Qt5.

        * disassembler/udis86/itab.py:
        (UdItabGenerator.genInsnTable):
        * disassembler/udis86/ud_opcode.py:
        (UdOpcodeTables.print_table):
        * disassembler/udis86/ud_optable.py:
        (UdOptableXmlParser.parseDef):
        (UdOptableXmlParser.parse):
        (printFn):

2013-08-23  Filip Pizlo  <fpizlo@apple.com>

        Incorrect TypedArray#set behavior
        https://bugs.webkit.org/show_bug.cgi?id=83818

        Reviewed by Oliver Hunt and Mark Hahnenberg.
        
        This was so much fun! typedArray.set() is like a memmove on steroids, and I'm
        not smart enough to figure out optimal versions for *all* of the cases. But I
        did come up with optimal implementations for most of the cases, and I wrote
        spec-literal code (i.e. copy via a transfer buffer) for the cases I'm not smart
        enough to write optimal code for.

        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::hasArrayBuffer):
        * runtime/JSArrayBufferViewInlines.h:
        (JSC::JSArrayBufferView::buffer):
        (JSC::JSArrayBufferView::existingBufferInButterfly):
        (JSC::JSArrayBufferView::neuter):
        (JSC::JSArrayBufferView::byteOffset):
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::::setWithSpecificType):
        (JSC::::set):
        (JSC::::existingBuffer):

2013-08-23  Alex Christensen  <achristensen@apple.com>

        Re-separating Win32 and Win64 builds.
        https://bugs.webkit.org/show_bug.cgi?id=120178

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
        Pass PlatformArchitecture as a command line parameter to bash scripts.
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh:
        * JavaScriptCore.vcxproj/build-generated-files.sh:
        Use PlatformArchitecture from command line to determine which object directory to use (obj32 or obj64).

2013-08-22  Filip Pizlo  <fpizlo@apple.com>

        build-jsc --ftl-jit should work
        https://bugs.webkit.org/show_bug.cgi?id=120194

        Reviewed by Oliver Hunt.

        * Configurations/Base.xcconfig: CPPFLAGS should include FEATURE_DEFINES
        * Configurations/JSC.xcconfig: The 'jsc' tool includes headers where field layout may depend on FEATURE_DEFINES
        * Configurations/ToolExecutable.xcconfig: All other tools include headers where field layout may depend on FEATURE_DEFINES
        * ftl/FTLLowerDFGToLLVM.cpp: Build fix
        (JSC::FTL::LowerDFGToLLVM::compilePutStructure):
        (JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure):

2013-08-23  Oliver Hunt  <oliver@apple.com>

        Re-sort xcode project file

        * JavaScriptCore.xcodeproj/project.pbxproj:

2013-08-23  Oliver Hunt  <oliver@apple.com>

        Support in memory compression of rarely used data
        https://bugs.webkit.org/show_bug.cgi?id=120143

        Reviewed by Gavin Barraclough.

        Include zlib in LD_FLAGS and make UnlinkedCodeBlock make use of CompressibleVector.  This saves ~200k on google maps.

        * Configurations/JavaScriptCore.xcconfig:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):
        (JSC::UnlinkedCodeBlock::addExpressionInfo):
        * bytecode/UnlinkedCodeBlock.h:

2013-08-22  Mark Hahnenberg  <mhahnenberg@apple.com>

        JSObject and JSArray code shouldn't have to tiptoe around garbage collection
        https://bugs.webkit.org/show_bug.cgi?id=120179

        Reviewed by Geoffrey Garen.

        There are many places in the code for JSObject and JSArray where they are manipulating their 
        Butterfly/Structure, e.g. after expanding their out-of-line backing storage via allocating. Within 
        these places there are certain "critical sections" where a GC would be disastrous. Gen GC looks 
        like it will make this dance even more intricate. To make everybody's lives easier we should use 
        the DeferGC mechanism in these functions to make these GC critical sections both obvious in the 
        code and trivially safe. Deferring collections will usually only last marginally longer, thus we 
        should not incur any additional overhead.

        * heap/Heap.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::unshiftCountSlowCase):
        * runtime/JSObject.cpp:
        (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
        (JSC::JSObject::createInitialUndecided):
        (JSC::JSObject::createInitialInt32):
        (JSC::JSObject::createInitialDouble):
        (JSC::JSObject::createInitialContiguous):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::increaseVectorLength):
        (JSC::JSObject::ensureLengthSlow):
        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
        (JSC::JSObject::putDirectWithoutTransition):

2013-08-22  Filip Pizlo  <fpizlo@apple.com>

        Update LLVM binary drops and scripts to the latest version from SVN
        https://bugs.webkit.org/show_bug.cgi?id=120184

        Reviewed by Mark Hahnenberg.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):

2013-08-22  Gavin Barraclough  <barraclough@apple.com>

        Don't leak registers for redeclared variables
        https://bugs.webkit.org/show_bug.cgi?id=120174

        Reviewed by Geoff Garen.

        We currently always allocate registers for new global variables, but these are wasted when the variable is being redeclared.
        Only allocate new registers when necessary.

        No performance impact.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
            - Don't allocate the register here.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::addGlobalVar):
            - Allocate the register here instead.

2013-08-22  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120128
        Remove putDirectVirtual

        Unreviewed, checked in commented out code. :-(

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
            - delete commented out code

2013-08-22  Gavin Barraclough  <barraclough@apple.com>

        Error.stack should not be enumerable
        https://bugs.webkit.org/show_bug.cgi?id=120171

        Reviewed by Oliver Hunt.

        Breaks ECMA tests.

        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
            - None -> DontEnum

2013-08-21  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120128
        Remove putDirectVirtual

        Reviewed by Sam Weinig.

        This could most generously be described as 'vestigial'.
        No performance impact.

        * API/JSObjectRef.cpp:
        (JSObjectSetProperty):
            - changed to use defineOwnProperty
        * debugger/DebuggerActivation.cpp:
        * debugger/DebuggerActivation.h:
            - remove putDirectVirtual
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
            - changed to use defineOwnProperty
        * runtime/ClassInfo.h:
        * runtime/JSActivation.cpp:
        * runtime/JSActivation.h:
        * runtime/JSCell.cpp:
        * runtime/JSCell.h:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSObject.cpp:
        * runtime/JSObject.h:
        * runtime/JSProxy.cpp:
        * runtime/JSProxy.h:
        * runtime/JSSymbolTableObject.cpp:
        * runtime/JSSymbolTableObject.h:
            - remove putDirectVirtual
        * runtime/PropertyDescriptor.h:
        (JSC::PropertyDescriptor::PropertyDescriptor):
            - added constructor for convenience

2013-08-22  Chris Curtis  <chris_curtis@apple.com>

        errorDescriptionForValue() should not assume error value is an Object
        https://bugs.webkit.org/show_bug.cgi?id=119812

        Reviewed by Geoffrey Garen.

        Added a check to make sure that the JSValue was an object before casting it as an object. Also, in case the parameterized JSValue
        has no type, the function now returns the empty string. 
        * runtime/ExceptionHelpers.cpp:
        (JSC::errorDescriptionForValue):

2013-08-22  Julien Brianceau  <jbrianceau@nds.com>

        Fix P_DFGOperation_EJS call for MIPS and ARM EABI.
        https://bugs.webkit.org/show_bug.cgi?id=120107

        Reviewed by Yong Li.

        EncodedJSValue parameters must be aligned to even registers for MIPS and ARM EABI.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):

2013-08-21  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r154416.
        http://trac.webkit.org/changeset/154416
        https://bugs.webkit.org/show_bug.cgi?id=120147

        Broke Windows builds (Requested by rniwa on #webkit).

        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh:
        * JavaScriptCore.vcxproj/build-generated-files.sh:

2013-08-21  Gavin Barraclough  <barraclough@apple.com>

        Clarify var/const/function declaration
        https://bugs.webkit.org/show_bug.cgi?id=120144

        Reviewed by Sam Weinig.

        Add methods to JSGlobalObject to declare vars, consts, and functions.

        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::initializeGlobalProperties):
        * runtime/Executable.h:
            - Moved declaration code to JSGlobalObject
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::addGlobalVar):
            - internal implementation of addVar, addConst, addFunction
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::addVar):
        (JSC::JSGlobalObject::addConst):
        (JSC::JSGlobalObject::addFunction):
            - Added methods to declare vars, consts, and functions

2013-08-21  Yi Shen  <max.hong.shen@gmail.com>

        https://bugs.webkit.org/show_bug.cgi?id=119900
        Exception in global setter doesn't unwind correctly

        Reviewed by Geoffrey Garen.

        Call VM_THROW_EXCEPTION_AT_END in op_put_to_scope if the setter throws exception.

        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):

2013-08-21  Mark Hahnenberg  <mhahnenberg@apple.com>

        Rename/refactor setButterfly/setStructure
        https://bugs.webkit.org/show_bug.cgi?id=120138

        Reviewed by Geoffrey Garen.

        setButterfly becomes setStructureAndButterfly.

        Also removed the Butterfly* argument from setStructure and just implicitly
        used m_butterfly internally since that's what every single client of setStructure
        was doing already.

        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/JSObject.cpp:
        (JSC::JSObject::notifyPresenceOfIndexedAccessors):
        (JSC::JSObject::createInitialUndecided):
        (JSC::JSObject::createInitialInt32):
        (JSC::JSObject::createInitialDouble):
        (JSC::JSObject::createInitialContiguous):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToDouble):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToContiguous):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::genericConvertDoubleToContiguous):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::switchToSlowPutArrayStorage):
        (JSC::JSObject::setPrototype):
        (JSC::JSObject::putDirectAccessor):
        (JSC::JSObject::seal):
        (JSC::JSObject::freeze):
        (JSC::JSObject::preventExtensions):
        (JSC::JSObject::reifyStaticFunctionsForDelete):
        (JSC::JSObject::removeDirect):
        * runtime/JSObject.h:
        (JSC::JSObject::setStructureAndButterfly):
        (JSC::JSObject::setStructure):
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
        (JSC::JSObject::putDirectWithoutTransition):
        * runtime/Structure.cpp:
        (JSC::Structure::flattenDictionaryStructure):

2013-08-21  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120127
        Remove JSObject::propertyIsEnumerable

        Unreviewed typo fix

        * runtime/JSObject.h:
            - fix typo

2013-08-21  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120139
        PropertyDescriptor argument to define methods should be const

        Rubber stamped by Sam Weinig.

        This should never be modified, and this way we can use rvalues.

        * debugger/DebuggerActivation.cpp:
        (JSC::DebuggerActivation::defineOwnProperty):
        * debugger/DebuggerActivation.h:
        * runtime/Arguments.cpp:
        (JSC::Arguments::defineOwnProperty):
        * runtime/Arguments.h:
        * runtime/ClassInfo.h:
        * runtime/JSArray.cpp:
        (JSC::JSArray::defineOwnProperty):
        * runtime/JSArray.h:
        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::defineOwnProperty):
        * runtime/JSArrayBuffer.h:
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::defineOwnProperty):
        * runtime/JSArrayBufferView.h:
        * runtime/JSCell.cpp:
        (JSC::JSCell::defineOwnProperty):
        * runtime/JSCell.h:
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSFunction.h:
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::::defineOwnProperty):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::defineOwnProperty):
        * runtime/JSGlobalObject.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::putIndexedDescriptor):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::putDescriptor):
        (JSC::JSObject::defineOwnNonIndexProperty):
        (JSC::JSObject::defineOwnProperty):
        * runtime/JSObject.h:
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::defineOwnProperty):
        * runtime/JSProxy.h:
        * runtime/RegExpMatchesArray.h:
        (JSC::RegExpMatchesArray::defineOwnProperty):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::defineOwnProperty):
        * runtime/RegExpObject.h:
        * runtime/StringObject.cpp:
        (JSC::StringObject::defineOwnProperty):
        * runtime/StringObject.h:
            - make PropertyDescriptor const

2013-08-21  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION: Crash under JITCompiler::link while loading Gmail
        https://bugs.webkit.org/show_bug.cgi?id=119872

        Reviewed by Mark Hahnenberg.
        
        Apparently, unsigned + signed = unsigned. Work around it with a cast.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

2013-08-21  Alex Christensen  <achristensen@apple.com>

        <https://webkit.org/b/120137> Separating Win32 and Win64 builds.

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
        Pass PlatformArchitecture as a command line parameter to bash scripts.
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh:
        * JavaScriptCore.vcxproj/build-generated-files.sh:
        Use PlatformArchitecture from command line to determine which object directory to use (obj32 or obj64).

2013-08-21  Filip Pizlo  <fpizlo@apple.com>

        Assertion failure in JSC::SlotVisitor::copyLater when marking JSDataView
        https://bugs.webkit.org/show_bug.cgi?id=120099

        Reviewed by Mark Hahnenberg.
        
        JSDataView should not store the ArrayBuffer* in the butterfly indexing header, since
        JSDataView may have ordinary JS indexed properties.

        * runtime/ClassInfo.h:
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        (JSC::JSArrayBufferView::finishCreation):
        * runtime/JSArrayBufferView.h:
        (JSC::hasArrayBuffer):
        * runtime/JSArrayBufferViewInlines.h:
        (JSC::JSArrayBufferView::buffer):
        (JSC::JSArrayBufferView::neuter):
        (JSC::JSArrayBufferView::byteOffset):
        * runtime/JSCell.cpp:
        (JSC::JSCell::slowDownAndWasteMemory):
        * runtime/JSCell.h:
        * runtime/JSDataView.cpp:
        (JSC::JSDataView::JSDataView):
        (JSC::JSDataView::create):
        (JSC::JSDataView::slowDownAndWasteMemory):
        * runtime/JSDataView.h:
        (JSC::JSDataView::buffer):
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::::visitChildren):
        (JSC::::slowDownAndWasteMemory):

2013-08-21  Mark Hahnenberg  <mhahnenberg@apple.com>

        Remove incorrect ASSERT from CopyVisitor::visitItem

        Rubber stamped by Filip Pizlo.

        * heap/CopyVisitorInlines.h:
        (JSC::CopyVisitor::visitItem):

2013-08-21  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120127
        Remove JSObject::propertyIsEnumerable

        Reviewed by Sam Weinig.

        This method is just a wart - it contains unnecessary const-casting, function call overhead, and LOC.

        * runtime/JSObject.cpp:
        * runtime/JSObject.h:
            - remove propertyIsEnumerable
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncPropertyIsEnumerable):
            - Move implementation here using getOwnPropertyDescriptor directly.

2013-08-20  Filip Pizlo  <fpizlo@apple.com>

        DFG should inline new typedArray()
        https://bugs.webkit.org/show_bug.cgi?id=120022

        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):

2013-08-21  Julien Brianceau  <jbrianceau@nds.com>

        <https://webkit.org/b/120106> Fix V_DFGOperation_EJPP signature in DFG.

        Reviewed by Geoffrey Garen.

        * dfg/DFGOperations.h:

2013-08-20  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120093
        Remove getOwnPropertyDescriptor trap

        Reviewed by Geoff Garen.

        All implementations of this method are now called via the method table, and equivalent in behaviour.
        Remove all duplicate implementations (and the method table trap), and add a single member function implementation on JSObject.

        * API/JSCallbackObject.h:
        * API/JSCallbackObjectFunctions.h:
        * debugger/DebuggerActivation.cpp:
        * debugger/DebuggerActivation.h:
        * runtime/Arguments.cpp:
        * runtime/Arguments.h:
        * runtime/ArrayConstructor.cpp:
        * runtime/ArrayConstructor.h:
        * runtime/ArrayPrototype.cpp:
        * runtime/ArrayPrototype.h:
        * runtime/BooleanPrototype.cpp:
        * runtime/BooleanPrototype.h:
            - remove getOwnPropertyDescriptor
        * runtime/ClassInfo.h:
            - remove getOwnPropertyDescriptor from MethodTable
        * runtime/DateConstructor.cpp:
        * runtime/DateConstructor.h:
        * runtime/DatePrototype.cpp:
        * runtime/DatePrototype.h:
        * runtime/ErrorPrototype.cpp:
        * runtime/ErrorPrototype.h:
        * runtime/JSActivation.cpp:
        * runtime/JSActivation.h:
        * runtime/JSArray.cpp:
        * runtime/JSArray.h:
        * runtime/JSArrayBuffer.cpp:
        * runtime/JSArrayBuffer.h:
        * runtime/JSArrayBufferView.cpp:
        * runtime/JSArrayBufferView.h:
        * runtime/JSCell.cpp:
        * runtime/JSCell.h:
        * runtime/JSDataView.cpp:
        * runtime/JSDataView.h:
        * runtime/JSDataViewPrototype.cpp:
        * runtime/JSDataViewPrototype.h:
        * runtime/JSFunction.cpp:
        * runtime/JSFunction.h:
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSNotAnObject.cpp:
        * runtime/JSNotAnObject.h:
        * runtime/JSONObject.cpp:
        * runtime/JSONObject.h:
            - remove getOwnPropertyDescriptor
        * runtime/JSObject.cpp:
        (JSC::JSObject::propertyIsEnumerable):
            - switch to call new getOwnPropertyDescriptor member function
        (JSC::JSObject::getOwnPropertyDescriptor):
            - new, based on imlementation from GET_OWN_PROPERTY_DESCRIPTOR_IMPL
        (JSC::JSObject::defineOwnNonIndexProperty):
            - switch to call new getOwnPropertyDescriptor member function
        * runtime/JSObject.h:
        * runtime/JSProxy.cpp:
        * runtime/JSProxy.h:
        * runtime/NamePrototype.cpp:
        * runtime/NamePrototype.h:
        * runtime/NumberConstructor.cpp:
        * runtime/NumberConstructor.h:
        * runtime/NumberPrototype.cpp:
        * runtime/NumberPrototype.h:
            - remove getOwnPropertyDescriptor
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetOwnPropertyDescriptor):
        (JSC::objectConstructorSeal):
        (JSC::objectConstructorFreeze):
        (JSC::objectConstructorIsSealed):
        (JSC::objectConstructorIsFrozen):
            - switch to call new getOwnPropertyDescriptor member function
        * runtime/ObjectConstructor.h:
            - remove getOwnPropertyDescriptor
        * runtime/PropertyDescriptor.h:
            - remove GET_OWN_PROPERTY_DESCRIPTOR_IMPL
        * runtime/RegExpConstructor.cpp:
        * runtime/RegExpConstructor.h:
        * runtime/RegExpMatchesArray.cpp:
        * runtime/RegExpMatchesArray.h:
        * runtime/RegExpObject.cpp:
        * runtime/RegExpObject.h:
        * runtime/RegExpPrototype.cpp:
        * runtime/RegExpPrototype.h:
        * runtime/StringConstructor.cpp:
        * runtime/StringConstructor.h:
        * runtime/StringObject.cpp:
        * runtime/StringObject.h:
            - remove getOwnPropertyDescriptor

2013-08-20  Mark Hahnenberg  <mhahnenberg@apple.com>

        <https://webkit.org/b/120079> Flattening a dictionary can cause CopiedSpace corruption

        Reviewed by Oliver Hunt.

        When we flatten an object in dictionary mode, we compact its properties. If the object 
        had out-of-line storage in the form of a Butterfly prior to this compaction, and after 
        compaction its properties fit inline, the object's Structure "forgets" that the object 
        has a non-zero Butterfly pointer. During GC, we check the Butterfly and reportLiveBytes 
        with bytes = 0, which causes all sorts of badness in CopiedSpace.

        Instead, after we flatten a dictionary, if properties fit inline we should clear the 
        Butterfly pointer so that the GC doesn't get confused later.

        This patch does this clearing, and it also adds JSObject::checkStructure, which overrides
        JSCell::checkStructure to add an ASSERT that makes sure that the Structure being assigned
        agrees with the whether or not the object has a Butterfly. Also added an ASSERT to check
        that the number of bytes reported to SlotVisitor::copyLater is non-zero.

        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::copyLater):
        * runtime/JSObject.cpp:
        (JSC::JSObject::notifyPresenceOfIndexedAccessors):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToDouble):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToContiguous):
        (JSC::JSObject::genericConvertDoubleToContiguous):
        (JSC::JSObject::switchToSlowPutArrayStorage):
        (JSC::JSObject::setPrototype):
        (JSC::JSObject::putDirectAccessor):
        (JSC::JSObject::seal):
        (JSC::JSObject::freeze):
        (JSC::JSObject::preventExtensions):
        (JSC::JSObject::reifyStaticFunctionsForDelete):
        (JSC::JSObject::removeDirect):
        * runtime/JSObject.h:
        (JSC::JSObject::setButterfly):
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::setStructure):
        (JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
        * runtime/Structure.cpp:
        (JSC::Structure::flattenDictionaryStructure):

2013-08-20  Alex Christensen  <achristensen@apple.com>

        Compile fix for Win64 after r154156.

        Rubber stamped by Oliver Hunt.

        * jit/JITStubsMSVC64.asm:
        Renamed ctiVMThrowTrampolineSlowpath to ctiVMHandleException and
        cti_vm_throw_slowpath to cti_vm_handle_exception.

2013-08-20  Alex Christensen  <achristensen@apple.com>

        <https://webkit.org/b/120076> More work towards a Win64 build

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
        * JavaScriptCore.vcxproj/copy-files.cmd:
        * JavaScriptCore.vcxproj/jsc/jscCommon.props:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props:
        Use PlatformArchitecture macro instead of bin32, lib32, and obj32.

2013-08-20  Mark Hahnenberg  <mhahnenberg@apple.com>

        <https://webkit.org/b/119919> Concurrent JIT crashes in various fast/js/dfg-* tests while the main thread is setting innerHTML

        Reviewed by Geoffrey Garen.

        More fixes for WriteBarrier deferral during concurrent JIT-ing. This patch makes the use of DesiredWriteBarriers class and the 
        initializeLazyWriteBarrierFor* wrapper functions more sane. 

        Refactored DesiredWriteBarrier to require an owner, a type, a CodeBlock, and an index. The type indicates how to use the CodeBlock
        and index when triggering the WriteBarrier at the end of compilation. 

        The client code of initializeLazy* is now responsible for creating the WriteBarrier that will be initialized as well as passing
        in the relevant index to be used at the end of compilation. Things were kind of muddled before in that one function did a 
        little extra work that really shouldn't have been its responsibility.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addConstant):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGDesiredWriteBarriers.cpp:
        (JSC::DFG::DesiredWriteBarrier::DesiredWriteBarrier):
        (JSC::DFG::DesiredWriteBarrier::trigger):
        * dfg/DFGDesiredWriteBarriers.h:
        (JSC::DFG::DesiredWriteBarriers::add):
        (JSC::DFG::initializeLazyWriteBarrierForInlineCallFrameExecutable):
        (JSC::DFG::initializeLazyWriteBarrierForInlineCallFrameCallee):
        (JSC::DFG::initializeLazyWriteBarrierForConstant):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::truncateConstantToInt32):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::constantRegisterForConstant):

2013-08-20  Michael Saboff  <msaboff@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120075
        REGRESSION (r128400): BBC4 website not displaying pictures

        Reviewed by Oliver Hunt.

        * runtime/RegExpMatchesArray.h:
        (JSC::RegExpMatchesArray::createStructure): Changed the array IndexingType to be ArrayWithSlowPutArrayStorage
        so that the match results will be reified before any other modification to the results array.

2013-08-19  Filip Pizlo  <fpizlo@apple.com>

        Incorrect behavior on emscripten-compiled cube2hash
        https://bugs.webkit.org/show_bug.cgi?id=120033

        Reviewed by Mark Hahnenberg.
        
        If PutClosureVar is may-aliased to another PutClosureVar or GetClosureVar
        then we should bail attempts to CSE.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::scopedVarLoadElimination):
        (JSC::DFG::CSEPhase::scopedVarStoreElimination):

2013-08-20  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120073
        Remove use of GOPD from JSFunction::defineProperty

        Reviewed by Oliver Hunt.

        Call getOwnPropertySlot to check for existing properties instead.

        * runtime/JSFunction.cpp:
        (JSC::JSFunction::defineOwnProperty):
            - getOwnPropertyDescriptor -> getOwnPropertySlot

2013-08-20  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120067
        Remove getPropertyDescriptor

        Reviewed by Oliver Hunt.

        This is used by lookupGetter/lookupSetter - this can easily bee replaced by getPropertySlot.
        Since we'll be getting the GetterSetter from the slot in the setter case, rename isGetter() to isAccessor().

        * runtime/JSObject.cpp:
        * runtime/JSObject.h:
            - remove getPropertyDescriptor
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncLookupGetter):
        (JSC::objectProtoFuncLookupSetter):
            - replace call to getPropertyDescriptor with getPropertySlot
        * runtime/PropertyDescriptor.h:
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::isAccessor):
        (JSC::PropertySlot::isCacheableGetter):
        (JSC::PropertySlot::getterSetter):
            - rename isGetter() to isAccessor()

2013-08-20  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120054
        Remove some dead code following getOwnPropertyDescriptor cleanup

        Reviewed by Oliver Hunt.

        * runtime/Lookup.h:
        (JSC::getStaticFunctionSlot):
            - remove getStaticPropertyDescriptor, getStaticFunctionDescriptor, getStaticValueDescriptor.

2013-08-20  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120052
        Remove custom getOwnPropertyDescriptor for JSProxy

        Reviewed by Geoff Garen.

        GET_OWN_PROPERTY_DESCRIPTOR_IMPL runs afoul with JSProxy due to the workaround for JSDOMWindow's broken behavior.
        Because the window object incorrectly searches the prototype chain in getOwnPropertySlot we check that the base
        object matches, but in the case of JSProxy we can end up comparing the window object to the window shell & falsely
        assuming this is a prototype property. Add toThis conversion to correctly identify proxied own access. I've kept
        the original slotBase check as a fast case, and also so that direct access on JSDOMWindow still works.

        * runtime/JSProxy.cpp:
            - Remove custom getOwnPropertyDescriptor implementation.
        * runtime/PropertyDescriptor.h:
            - Modify own property access check to perform toThis conversion.

2013-08-20  Alex Christensen  <achristensen@apple.com>

        Use PlatformArchitecture to distinguish between 32-bit and 64-bit builds on Windows.
        https://bugs.webkit.org/show_bug.cgi?id=119512

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props:
        Replaced obj32, bin32, and lib32 with macros for 64-bit build.

2013-08-20  Julien Brianceau  <jbrianceau@nds.com>

        <https://webkit.org/b/120062> Missing ensureSpace call in sh4 baseline JIT.

        Reviewed by Allan Sandfeld Jensen.

        branchPtrWithPatch() of baseline JIT must ensure that space is available for its
        instructions and two constants now DFG is enabled for sh4 architecture.
        These missing ensureSpace calls lead to random crashes.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::branchPtrWithPatch):

2013-08-19  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120034
        Remove custom getOwnPropertyDescriptor for global objects

        Reviewed by Geoff Garen.

        Fix attributes of JSC SynbolTableObject entries, ensure that cross frame access is safe, and suppress prototype chain walk.

        * runtime/JSGlobalObject.cpp:
            - Remove custom getOwnPropertyDescriptor implementation.
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
            - The symbol table does not store the DontDelete attribute, we should be adding it back in.
        * runtime/PropertyDescriptor.h:
            - JSDOMWindow walks the prototype chain on own access. This is bad, but for now workaround for the getOwnPropertyDescriptor case.
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::setUndefined):
            - This is used by WebCore when blocking access to properties on cross-frame access.
              Mark blocked properties as read-only, non-configurable to prevent defineProperty.

2013-08-17  Filip Pizlo  <fpizlo@apple.com>

        DFG should inline typedArray.byteOffset
        https://bugs.webkit.org/show_bug.cgi?id=119962

        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):

2013-08-18  Filip Pizlo  <fpizlo@apple.com>

        <https://webkit.org/b/119994> DFG new Array() inlining could get confused about global objects

        Reviewed by Geoffrey Garen.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):

2013-08-18  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=119995
        Start removing custom implementations of getOwnPropertyDescriptor

        Reviewed by Oliver Hunt.

        This can now typically implemented in terms of getOwnPropertySlot.
        Add a macro to PropertyDescriptor to define an implementation of GOPD in terms of GOPS.
        Switch over most classes in JSC & the WebCore bindings generator to use this.

        * API/JSCallbackObjectFunctions.h:
        * debugger/DebuggerActivation.cpp:
        * runtime/Arguments.cpp:
        * runtime/ArrayConstructor.cpp:
        * runtime/ArrayPrototype.cpp:
        * runtime/BooleanPrototype.cpp:
        * runtime/DateConstructor.cpp:
        * runtime/DatePrototype.cpp:
        * runtime/ErrorPrototype.cpp:
        * runtime/JSActivation.cpp:
        * runtime/JSArray.cpp:
        * runtime/JSArrayBuffer.cpp:
        * runtime/JSArrayBufferView.cpp:
        * runtime/JSCell.cpp:
        * runtime/JSDataView.cpp:
        * runtime/JSDataViewPrototype.cpp:
        * runtime/JSFunction.cpp:
        * runtime/JSGenericTypedArrayViewInlines.h:
        * runtime/JSNotAnObject.cpp:
        * runtime/JSONObject.cpp:
        * runtime/JSObject.cpp:
        * runtime/NamePrototype.cpp:
        * runtime/NumberConstructor.cpp:
        * runtime/NumberPrototype.cpp:
        * runtime/ObjectConstructor.cpp:
            - Implement getOwnPropertySlot in terms of GET_OWN_PROPERTY_DESCRIPTOR_IMPL.
        * runtime/PropertyDescriptor.h:
            - Added GET_OWN_PROPERTY_DESCRIPTOR_IMPL macro.
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::isValue):
        (JSC::PropertySlot::isGetter):
        (JSC::PropertySlot::isCustom):
        (JSC::PropertySlot::isCacheableValue):
        (JSC::PropertySlot::isCacheableGetter):
        (JSC::PropertySlot::isCacheableCustom):
        (JSC::PropertySlot::attributes):
        (JSC::PropertySlot::getterSetter):
            - Add accessors necessary to convert PropertySlot to descriptor.
        * runtime/RegExpConstructor.cpp:
        * runtime/RegExpMatchesArray.cpp:
        * runtime/RegExpMatchesArray.h:
        * runtime/RegExpObject.cpp:
        * runtime/RegExpPrototype.cpp:
        * runtime/StringConstructor.cpp:
        * runtime/StringObject.cpp:
            - Implement getOwnPropertySlot in terms of GET_OWN_PROPERTY_DESCRIPTOR_IMPL.

2013-08-19  Michael Saboff  <msaboff@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120015 DFG 32Bit: Crash loading "Classic" site @ translate.google.com

        Reviewed by Sam Weinig.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell): Added checks for spillFormat being
        DataFormatInteger or DataFormatDouble similar to what is in the 64 bit code and in
        all versions of fillSpeculateBoolean().

2013-08-19  Michael Saboff  <msaboff@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=120020 Change Set 154207 causes wrong register to be used for 32 bit tests

        Reviewed by Benjamin Poulain.

        Change branshTest32 to only use the byte for 8 bit test on the lower 4 registers.
        Registers 4 through 7 as byte regisers are ah, ch, dh and bh instead of sp, bp, si and di.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::branchTest32):

2013-08-16  Oliver Hunt  <oliver@apple.com>

        <https://webkit.org/b/119860> Crash during exception unwinding

        Reviewed by Filip Pizlo.

        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):

2013-08-19  Víctor Manuel Jáquez Leal  <vjaquez@igalia.com>

        <https://webkit.org/b/120008> [GTK][ARM] javascriptcore compilation is broken

        Reviewed by Oliver Hunt.

        Guard the compilation of these files only if DFG_JIT is enabled.

        * dfg/DFGDesiredTransitions.cpp:
        * dfg/DFGDesiredTransitions.h:
        * dfg/DFGDesiredWeakReferences.cpp:
        * dfg/DFGDesiredWeakReferences.h:
        * dfg/DFGDesiredWriteBarriers.cpp:
        * dfg/DFGDesiredWriteBarriers.h:

2013-08-17  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r154218): DFG::FixupPhase no longer turns GetById's child1 into CellUse
        https://bugs.webkit.org/show_bug.cgi?id=119961

        Reviewed by Mark Hahnenberg.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2013-08-18  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=119972
        Add attributes field to PropertySlot

        Reviewed by Geoff Garen.

        For all JSC types, this makes getOwnPropertyDescriptor redundant.
        There will be a bit more hacking required in WebCore to remove GOPD whilst maintaining current behaviour.
        (Current behaviour is in many ways broken, particularly in that GOPD & GOPS are inconsistent, but we should fix incrementally).

        No performance impact.

        * runtime/PropertySlot.h:
        (JSC::PropertySlot::setValue):
        (JSC::PropertySlot::setCustom):
        (JSC::PropertySlot::setCacheableCustom):
        (JSC::PropertySlot::setCustomIndex):
        (JSC::PropertySlot::setGetterSlot):
        (JSC::PropertySlot::setCacheableGetterSlot):
            - These mathods now all require 'attributes'.
        * runtime/JSObject.h:
        (JSC::JSObject::getDirect):
        (JSC::JSObject::getDirectOffset):
        (JSC::JSObject::inlineGetOwnPropertySlot):
            - Added variants of getDirect, getDirectOffset that return the attributes.
        * API/JSCallbackObjectFunctions.h:
        (JSC::::getOwnPropertySlot):
        * runtime/Arguments.cpp:
        (JSC::Arguments::getOwnPropertySlotByIndex):
        (JSC::Arguments::getOwnPropertySlot):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::symbolTableGet):
        (JSC::JSActivation::getOwnPropertySlot):
        * runtime/JSArray.cpp:
        (JSC::JSArray::getOwnPropertySlot):
        * runtime/JSArrayBuffer.cpp:
        (JSC::JSArrayBuffer::getOwnPropertySlot):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::getOwnPropertySlot):
        * runtime/JSDataView.cpp:
        (JSC::JSDataView::getOwnPropertySlot):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::::getOwnPropertySlot):
        (JSC::::getOwnPropertySlotByIndex):
        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::fillGetterPropertySlot):
        * runtime/JSString.h:
        (JSC::JSString::getStringPropertySlot):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        * runtime/Lookup.cpp:
        (JSC::setUpStaticFunctionSlot):
        * runtime/Lookup.h:
        (JSC::getStaticPropertySlot):
        (JSC::getStaticPropertyDescriptor):
        (JSC::getStaticValueSlot):
        (JSC::getStaticValueDescriptor):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::getOwnPropertySlot):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayEntry::get):
            - Pass attributes to PropertySlot::set* methods.

2013-08-17  Mark Hahnenberg  <mhahnenberg@apple.com>

        <https://webkit.org/b/119919> Concurrent JIT crashes in various fast/js/dfg-* tests while the main thread is setting innerHTML

        Reviewed by Filip Pizlo.

        Added a new mode for DesiredWriteBarrier that allows it to track a position in a 
        Vector of WriteBarriers rather than the specific address. The fact that we were 
        arbitrarily storing into a Vector's backing store for constants at the end of 
        compilation after the Vector could have resized was causing crashes.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::constants):
        (JSC::CodeBlock::addConstantLazily):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addConstant):
        * dfg/DFGDesiredWriteBarriers.cpp:
        (JSC::DFG::DesiredWriteBarrier::DesiredWriteBarrier):
        (JSC::DFG::DesiredWriteBarrier::trigger):
        (JSC::DFG::initializeLazyWriteBarrierForConstant):
        * dfg/DFGDesiredWriteBarriers.h:
        (JSC::DFG::DesiredWriteBarriers::add):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::truncateConstantToInt32):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::constantRegisterForConstant):

2013-08-16  Filip Pizlo  <fpizlo@apple.com>

        DFG should optimize typedArray.byteLength
        https://bugs.webkit.org/show_bug.cgi?id=119909

        Reviewed by Oliver Hunt.
        
        This adds typedArray.byteLength inlining to the DFG, and does so without changing
        the IR: byteLength is turned into GetArrayLength followed by BitLShift. This is
        legal since the byteLength of a typed array cannot exceed
        numeric_limits<int32_t>::max().

        * bytecode/SpeculatedType.cpp:
        (JSC::typedArrayTypeFromSpeculation):
        * bytecode/SpeculatedType.h:
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::toArrayType):
        * dfg/DFGArrayMode.h:
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
        (JSC::DFG::FixupPhase::attemptToMakeGetByteLength):
        (JSC::DFG::FixupPhase::convertToGetArrayLength):
        (JSC::DFG::FixupPhase::prependGetArrayLength):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::constantRegisterForConstant):
        (JSC::DFG::Graph::convertToConstant):
        * runtime/TypedArrayType.h:
        (JSC::logElementSize):
        (JSC::elementSize):

2013-08-16  Filip Pizlo  <fpizlo@apple.com>

        DFG optimizes out strict mode arguments tear off
        https://bugs.webkit.org/show_bug.cgi?id=119504

        Reviewed by Mark Hahnenberg and Oliver Hunt.
        
        Don't do the optimization for strict mode.

        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        (JSC::DFG::ArgumentsSimplificationPhase::pruneObviousArgumentCreations):

2013-08-16  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] x86: improve code generation for xxxTest32
        https://bugs.webkit.org/show_bug.cgi?id=119876

        Reviewed by Geoffrey Garen.

        Try to use testb whenever possible when testing for an immediate value.

        When the input is an address and an offset, we can tweak the mask
        and offset to be able to generate testb for any byte of the mask.

        When the input is a register, we can use testb if we are only interested
        in testing the low bits.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::branchTest32):
        (JSC::MacroAssemblerX86Common::test32):
        (JSC::MacroAssemblerX86Common::generateTest32):

2013-08-16  Mark Lam  <mark.lam@apple.com>

        <https://bugs.webkit.org/show_bug.cgi?id=119913> Baseline JIT gives erroneous
        error message that an object is not a constructor though it expects a function

        Reviewed by Michael Saboff.

        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):

2013-08-16  Filip Pizlo  <fpizlo@apple.com>

        Object properties added using dot syntax (o.f = ...) from code that isn't in eval should be less likely to cause an object to become a dictionary
        https://bugs.webkit.org/show_bug.cgi?id=119897

        Reviewed by Oliver Hunt.
        
        6-10x speed-up on microbenchmarks that create large static objects. 40-65% speed-up
        on Octane/gbemu. 3% overall speed-up on Octane. No slow-downs anywhere; our ability
        to turn objects into dictionaries when you're storing using bracket syntax or using
        eval is still in place.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::putByIdContext):
        * dfg/DFGOperations.cpp:
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal):
        * runtime/PutPropertySlot.h:
        (JSC::PutPropertySlot::PutPropertySlot):
        (JSC::PutPropertySlot::context):
        * runtime/Structure.cpp:
        (JSC::Structure::addPropertyTransition):
        * runtime/Structure.h:

2013-08-16  Balazs Kilvady  <kilvadyb@homejinni.com>

        <https://webkit.org/b/119742> REGRESSION(FTL): Fix register usage in mips implementation of ctiVMHandleException

        Reviewed by Allan Sandfeld Jensen.

        ctiVMHandleException must jump/return using register ra (r31).

        * jit/JITStubsMIPS.h:

2013-08-16  Julien Brianceau  <jbrianceau@nds.com>

        <https://webkit.org/b/119879> Fix sh4 build after r154156.

        Reviewed by Allan Sandfeld Jensen.

        Fix typo in JITStubsSH4.h file.

        * jit/JITStubsSH4.h:

2013-08-15  Mark Hahnenberg  <mhahnenberg@apple.com>

        <https://webkit.org/b/119833> Concurrent compilation thread should not trigger WriteBarriers

        Reviewed by Oliver Hunt.

        The concurrent compilation thread should interact minimally with the Heap, including not 
        triggering WriteBarriers. This is a prerequisite for generational GC.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::addOrFindConstant):
        (JSC::CodeBlock::findConstant):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addConstantLazily):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getJSConstantForValue):
        (JSC::DFG::ByteCodeParser::constantUndefined):
        (JSC::DFG::ByteCodeParser::constantNull):
        (JSC::DFG::ByteCodeParser::one):
        (JSC::DFG::ByteCodeParser::constantNaN):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::notifyCompilingStructureTransition):
        * dfg/DFGCommonData.h:
        * dfg/DFGDesiredTransitions.cpp: Added.
        (JSC::DFG::DesiredTransition::DesiredTransition):
        (JSC::DFG::DesiredTransition::reallyAdd):
        (JSC::DFG::DesiredTransitions::DesiredTransitions):
        (JSC::DFG::DesiredTransitions::~DesiredTransitions):
        (JSC::DFG::DesiredTransitions::addLazily):
        (JSC::DFG::DesiredTransitions::reallyAdd):
        * dfg/DFGDesiredTransitions.h: Added.
        * dfg/DFGDesiredWeakReferences.cpp: Added.
        (JSC::DFG::DesiredWeakReferences::DesiredWeakReferences):
        (JSC::DFG::DesiredWeakReferences::~DesiredWeakReferences):
        (JSC::DFG::DesiredWeakReferences::addLazily):
        (JSC::DFG::DesiredWeakReferences::reallyAdd):
        * dfg/DFGDesiredWeakReferences.h: Added.
        * dfg/DFGDesiredWriteBarriers.cpp: Added.
        (JSC::DFG::DesiredWriteBarrier::DesiredWriteBarrier):
        (JSC::DFG::DesiredWriteBarrier::trigger):
        (JSC::DFG::DesiredWriteBarriers::DesiredWriteBarriers):
        (JSC::DFG::DesiredWriteBarriers::~DesiredWriteBarriers):
        (JSC::DFG::DesiredWriteBarriers::addImpl):
        (JSC::DFG::DesiredWriteBarriers::trigger):
        * dfg/DFGDesiredWriteBarriers.h: Added.
        (JSC::DFG::DesiredWriteBarriers::add):
        (JSC::DFG::initializeLazyWriteBarrier):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::truncateConstantToInt32):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::convertToConstant):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::addWeakReference):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::reallyAdd):
        * dfg/DFGPlan.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/WriteBarrier.h:
        (JSC::WriteBarrierBase::set):
        (JSC::WriteBarrier::WriteBarrier):

2013-08-15  Benjamin Poulain  <benjamin@webkit.org>

        Fix x86 32bits build after r154158

        * assembler/X86Assembler.h: Add missing #ifdef for the x86_64 instructions.

2013-08-15  Ryosuke Niwa  <rniwa@webkit.org>

        Build fix attempt after r154156.

        * jit/JITStubs.cpp:
        (JSC::cti_vm_handle_exception): encode!

2013-08-15  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] x86: Use inc and dec when possible
        https://bugs.webkit.org/show_bug.cgi?id=119831

        Reviewed by Geoffrey Garen.

        When incrementing or decrementing by an immediate of 1, use the insctructions
        inc and dec instead of add and sub.
        The instructions have good timing and their encoding is smaller.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86_64::add32):
        (JSC::MacroAssemblerX86_64::sub32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::add64):
        (JSC::MacroAssemblerX86_64::sub64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::dec_r):
        (JSC::X86Assembler::decq_r):
        (JSC::X86Assembler::inc_r):
        (JSC::X86Assembler::incq_r):

2013-08-15  Filip Pizlo  <fpizlo@apple.com>

        Sometimes, the DFG uses a GetById for typed array length accesses despite profiling data that indicates that it's a typed array length access
        https://bugs.webkit.org/show_bug.cgi?id=119874

        Reviewed by Oliver Hunt and Mark Hahnenberg.
        
        It was a confusion between heuristics in DFG::ArrayMode that are assuming that
        you'll use ForceExit if array profiles are empty, the JIT creating empty profiles
        sometimes for typed array length accesses, and the FixupPhase assuming that a
        ForceExit ArrayMode means that it should continue using a generic GetById.

        This fixes the confusion.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2013-08-15  Mark Lam  <mark.lam@apple.com>

        Fix crash when performing activation tearoff.
        https://bugs.webkit.org/show_bug.cgi?id=119848

        Reviewed by Oliver Hunt.

        The activation tearoff crash was due to a bug in the baseline JIT.
        If we have a scenario where the a baseline JIT frame calls a LLINT
        frame, an exception may be thrown while in the LLINT.

        Interpreter::throwException() which handles the exception will unwind
        all frames until it finds a catcher or sees a host frame. When we
        return from the LLINT to the baseline JIT code, the baseline JIT code
        errorneously sets topCallFrame to the value in its call frame register,
        and starts unwinding the stack frames that have already been unwound.

        The fix is:
        1. Rename ctiVMThrowTrampolineSlowpath to ctiVMHandleException.
           This is a more accurate description of what this runtime function
           is supposed to do i.e. it handles the exception which include doing
           nothing (if there are no more frames to unwind).
        2. Fix up topCallFrame values so that the HostCallFrameFlag is never
           set on it.
        3. Reloading the call frame register from topCallFrame when we're
           returning from a callee and detect exception handling in progress.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwindCallFrame):
        - Ensure that topCallFrame is not set with the HostCallFrameFlag.
        (JSC::Interpreter::getStackTrace):
        * interpreter/Interpreter.h:
        (JSC::TopCallFrameSetter::TopCallFrameSetter):
        (JSC::TopCallFrameSetter::~TopCallFrameSetter):
        (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
        - Ensure that topCallFrame is not set with the HostCallFrameFlag.
        * jit/JIT.h:
        * jit/JITExceptions.cpp:
        (JSC::uncaughtExceptionHandler):
        - Convenience function to get the handler for uncaught exceptions.
        * jit/JITExceptions.h:
        * jit/JITInlines.h:
        (JSC::JIT::reloadCallFrameFromTopCallFrame):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        - Rename ctiVMThrowTrampolineSlowpath to ctiVMHandleException.
        * jit/JITStubs.cpp:
        (JSC::throwExceptionFromOpCall):
        - Ensure that topCallFrame is not set with the HostCallFrameFlag.
        (JSC::cti_vm_handle_exception):
        - Check for the case when there are no more frames to unwind.
        * jit/JITStubs.h:
        * jit/JITStubsARM.h:
        * jit/JITStubsARMv7.h:
        * jit/JITStubsMIPS.h:
        * jit/JITStubsSH4.h:
        * jit/JITStubsX86.h:
        * jit/JITStubsX86_64.h:
        - Rename ctiVMThrowTrampolineSlowpath to ctiVMHandleException.
        * jit/SlowPathCall.h:
        (JSC::JITSlowPathCall::call):
        - reload cfr from topcallFrame when handling an exception.
        - Rename ctiVMThrowTrampolineSlowpath to ctiVMHandleException.
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        - reload cfr from topcallFrame when handling an exception.
        * runtime/VM.cpp:
        (JSC::VM::VM):
        - Ensure that topCallFrame is not set with the HostCallFrameFlag.

2013-08-15  Filip Pizlo  <fpizlo@apple.com>

        Remove some code duplication.
        
        Rubber stamped by Mark Hahnenberg.

        * runtime/JSDataViewPrototype.cpp:
        (JSC::getData):
        (JSC::setData):

2013-08-15  Julien Brianceau  <jbrianceau@nds.com>

        [DFG] isDouble() and isNumerical() should return true with KnownNumberUse UseKind.
        https://bugs.webkit.org/show_bug.cgi?id=119794

        Reviewed by Filip Pizlo.

        This patch fixes ASSERTs failures in debug builds for sh4 and mips architecture.

        * dfg/DFGUseKind.h:
        (JSC::DFG::isNumerical):
        (JSC::DFG::isDouble):

2013-08-15  Filip Pizlo  <fpizlo@apple.com>

        http://trac.webkit.org/changeset/154120 accidentally changed DFGCapabilities to read the resolve type from operand 4, not 3; it should be 3.

        Rubber stamped by Oliver Hunt.
        
        This was causing some test crashes for me.

        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):

2013-08-15  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Clear up improper export declaration.

        * runtime/ArrayBufferView.h:

2013-08-15  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, remove some unnecessary periods from exceptions.

        * runtime/JSDataViewPrototype.cpp:
        (JSC::getData):
        (JSC::setData):

2013-08-15  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix 32-bit build.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2013-08-14  Filip Pizlo  <fpizlo@apple.com>

        Typed arrays should be rewritten
        https://bugs.webkit.org/show_bug.cgi?id=119064

        Reviewed by Oliver Hunt.
        
        Typed arrays were previously deficient in several major ways:
        
        - They were defined separately in WebCore and in the jsc shell. The two
          implementations were different, and the jsc shell one was basically wrong.
          The WebCore one was quite awful, also.
        
        - Typed arrays were not visible to the JIT except through some weird hooks.
          For example, the JIT could not ask "what is the Structure that this typed
          array would have if I just allocated it from this global object". Also,
          it was difficult to wire any of the typed array intrinsics, because most
          of the functionality wasn't visible anywhere in JSC.
        
        - Typed array allocation was brain-dead. Allocating a typed array involved
          two JS objects, two GC weak handles, and three malloc allocations.
        
        - Neutering. It involved keeping tabs on all native views but not the view
          wrappers, even though the native views can autoneuter just by asking the
          buffer if it was neutered anytime you touch them; while the JS view
          wrappers are the ones that you really want to reach out to.
        
        - Common case-ing. Most typed arrays have one buffer and one view, and
          usually nobody touches the buffer. Yet we created all of that stuff
          anyway, using data structures optimized for the case where you had a lot
          of views.
        
        - Semantic goofs. Typed arrays should, in the future, behave like ES
          features rather than DOM features, for example when it comes to exceptions.
          Firefox already does this and I agree with them.
        
        This patch cleanses our codebase of these sins:
        
        - Typed arrays are almost entirely defined in JSC. Only the lifecycle
          management of native references to buffers is left to WebCore.
        
        - Allocating a typed array requires either two GC allocations (a cell and a
          copied storage vector) or one GC allocation, a malloc allocation, and a
          weak handle (a cell and a malloc'd storage vector, plus a finalizer for the
          latter). The latter is only used for oversize arrays. Remember that before
          it was 7 allocations no matter what.
        
        - Typed arrays require just 4 words of overhead: Structure*, Butterfly*,
          mode/length, void* vector. Before it was a lot more than that - remember,
          there were five additional objects that did absolutely nothing for anybody.
        
        - Native views aren't tracked by the buffer, or by the wrappers. They are
          transient. In the future we'll probably switch to not even having them be
          malloc'd.
        
        - Native array buffers have an efficient way of tracking all of their JS view
          wrappers, both for neutering, and for lifecycle management. The GC
          special-cases native array buffers. This saves a bunch of grief; for example
          it means that a JS view wrapper can refer to its buffer via the butterfly,
          which would be dead by the time we went to finalize.
        
        - Typed array semantics now match Firefox, which also happens to be where the
          standards are going. The discussion on webkit-dev seemed to confirm that
          Chrome is also heading in this direction. This includes making
          Uint8ClampedArray not a subtype of Uint8Array, and getting rid of
          ArrayBufferView as a JS-visible construct.
        
        This is up to a 10x speed-up on programs that allocate a lot of typed arrays.
        It's a 1% speed-up on Octane. It also opens up a bunch of possibilities for
        further typed array optimizations in the JSC JITs, including inlining typed
        array allocation, inlining more of the accessors, reducing the cost of type
        checks, etc.
        
        An additional property of this patch is that typed arrays are mostly
        implemented using templates. This deduplicates a bunch of code, but does mean
        that we need some hacks for exporting s_info's of template classes. See
        JSGenericTypedArrayView.h and JSTypedArrays.cpp. Those hacks are fairly
        low-impact compared to code duplication.
        
        Automake work courtesy of Zan Dobersek <zdobersek@igalia.com>.

        * CMakeLists.txt:
        * DerivedSources.make:
        * GNUmakefile.list.am:
        * JSCTypedArrayStubs.h: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/ByValInfo.h:
        (JSC::hasOptimizableIndexingForClassInfo):
        (JSC::jitArrayModeForClassInfo):
        (JSC::typedArrayTypeForJITArrayMode):
        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromClassInfo):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::toTypedArrayType):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::typedArrayType):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * heap/CopyToken.h:
        * heap/DeferGC.h:
        (JSC::DeferGCForAWhile::DeferGCForAWhile):
        (JSC::DeferGCForAWhile::~DeferGCForAWhile):
        * heap/GCIncomingRefCounted.h: Added.
        (JSC::GCIncomingRefCounted::GCIncomingRefCounted):
        (JSC::GCIncomingRefCounted::~GCIncomingRefCounted):
        (JSC::GCIncomingRefCounted::numberOfIncomingReferences):
        (JSC::GCIncomingRefCounted::incomingReferenceAt):
        (JSC::GCIncomingRefCounted::singletonFlag):
        (JSC::GCIncomingRefCounted::hasVectorOfCells):
        (JSC::GCIncomingRefCounted::hasAnyIncoming):
        (JSC::GCIncomingRefCounted::hasSingleton):
        (JSC::GCIncomingRefCounted::singleton):
        (JSC::GCIncomingRefCounted::vectorOfCells):
        * heap/GCIncomingRefCountedInlines.h: Added.
        (JSC::::addIncomingReference):
        (JSC::::filterIncomingReferences):
        * heap/GCIncomingRefCountedSet.h: Added.
        (JSC::GCIncomingRefCountedSet::size):
        * heap/GCIncomingRefCountedSetInlines.h: Added.
        (JSC::::GCIncomingRefCountedSet):
        (JSC::::~GCIncomingRefCountedSet):
        (JSC::::addReference):
        (JSC::::sweep):
        (JSC::::removeAll):
        (JSC::::removeDead):
        * heap/Heap.cpp:
        (JSC::Heap::addReference):
        (JSC::Heap::extraSize):
        (JSC::Heap::size):
        (JSC::Heap::capacity):
        (JSC::Heap::collect):
        (JSC::Heap::decrementDeferralDepth):
        (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
        * heap/Heap.h:
        * interpreter/CallFrame.h:
        (JSC::ExecState::dataViewTable):
        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompileGetByVal):
        (JSC::JIT::privateCompilePutByVal):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        * runtime/ArrayBuffer.cpp:
        (JSC::ArrayBuffer::transfer):
        * runtime/ArrayBuffer.h:
        (JSC::ArrayBuffer::createAdopted):
        (JSC::ArrayBuffer::ArrayBuffer):
        (JSC::ArrayBuffer::gcSizeEstimateInBytes):
        (JSC::ArrayBuffer::pin):
        (JSC::ArrayBuffer::unpin):
        (JSC::ArrayBufferContents::tryAllocate):
        * runtime/ArrayBufferView.cpp:
        (JSC::ArrayBufferView::ArrayBufferView):
        (JSC::ArrayBufferView::~ArrayBufferView):
        (JSC::ArrayBufferView::setNeuterable):
        * runtime/ArrayBufferView.h:
        (JSC::ArrayBufferView::isNeutered):
        (JSC::ArrayBufferView::buffer):
        (JSC::ArrayBufferView::baseAddress):
        (JSC::ArrayBufferView::byteOffset):
        (JSC::ArrayBufferView::verifySubRange):
        (JSC::ArrayBufferView::clampOffsetAndNumElements):
        (JSC::ArrayBufferView::calculateOffsetAndLength):
        * runtime/ClassInfo.h:
        * runtime/CommonIdentifiers.h:
        * runtime/DataView.cpp: Added.
        (JSC::DataView::DataView):
        (JSC::DataView::create):
        (JSC::DataView::wrap):
        * runtime/DataView.h: Added.
        (JSC::DataView::byteLength):
        (JSC::DataView::getType):
        (JSC::DataView::get):
        (JSC::DataView::set):
        * runtime/Float32Array.h:
        * runtime/Float64Array.h:
        * runtime/GenericTypedArrayView.h: Added.
        (JSC::GenericTypedArrayView::data):
        (JSC::GenericTypedArrayView::set):
        (JSC::GenericTypedArrayView::setRange):
        (JSC::GenericTypedArrayView::zeroRange):
        (JSC::GenericTypedArrayView::zeroFill):
        (JSC::GenericTypedArrayView::length):
        (JSC::GenericTypedArrayView::byteLength):
        (JSC::GenericTypedArrayView::item):
        (JSC::GenericTypedArrayView::checkInboundData):
        (JSC::GenericTypedArrayView::getType):
        * runtime/GenericTypedArrayViewInlines.h: Added.
        (JSC::::GenericTypedArrayView):
        (JSC::::create):
        (JSC::::createUninitialized):
        (JSC::::subarray):
        (JSC::::wrap):
        * runtime/IndexingHeader.h:
        (JSC::IndexingHeader::arrayBuffer):
        (JSC::IndexingHeader::setArrayBuffer):
        * runtime/Int16Array.h:
        * runtime/Int32Array.h:
        * runtime/Int8Array.h:
        * runtime/JSArrayBuffer.cpp: Added.
        (JSC::JSArrayBuffer::JSArrayBuffer):
        (JSC::JSArrayBuffer::finishCreation):
        (JSC::JSArrayBuffer::create):
        (JSC::JSArrayBuffer::createStructure):
        (JSC::JSArrayBuffer::getOwnPropertySlot):
        (JSC::JSArrayBuffer::getOwnPropertyDescriptor):
        (JSC::JSArrayBuffer::put):
        (JSC::JSArrayBuffer::defineOwnProperty):
        (JSC::JSArrayBuffer::deleteProperty):
        (JSC::JSArrayBuffer::getOwnNonIndexPropertyNames):
        * runtime/JSArrayBuffer.h: Added.
        (JSC::JSArrayBuffer::impl):
        (JSC::toArrayBuffer):
        * runtime/JSArrayBufferConstructor.cpp: Added.
        (JSC::JSArrayBufferConstructor::JSArrayBufferConstructor):
        (JSC::JSArrayBufferConstructor::finishCreation):
        (JSC::JSArrayBufferConstructor::create):
        (JSC::JSArrayBufferConstructor::createStructure):
        (JSC::constructArrayBuffer):
        (JSC::JSArrayBufferConstructor::getConstructData):
        (JSC::JSArrayBufferConstructor::getCallData):
        * runtime/JSArrayBufferConstructor.h: Added.
        * runtime/JSArrayBufferPrototype.cpp: Added.
        (JSC::arrayBufferProtoFuncSlice):
        (JSC::JSArrayBufferPrototype::JSArrayBufferPrototype):
        (JSC::JSArrayBufferPrototype::finishCreation):
        (JSC::JSArrayBufferPrototype::create):
        (JSC::JSArrayBufferPrototype::createStructure):
        * runtime/JSArrayBufferPrototype.h: Added.
        * runtime/JSArrayBufferView.cpp: Added.
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        (JSC::JSArrayBufferView::JSArrayBufferView):
        (JSC::JSArrayBufferView::finishCreation):
        (JSC::JSArrayBufferView::getOwnPropertySlot):
        (JSC::JSArrayBufferView::getOwnPropertyDescriptor):
        (JSC::JSArrayBufferView::put):
        (JSC::JSArrayBufferView::defineOwnProperty):
        (JSC::JSArrayBufferView::deleteProperty):
        (JSC::JSArrayBufferView::getOwnNonIndexPropertyNames):
        (JSC::JSArrayBufferView::finalize):
        * runtime/JSArrayBufferView.h: Added.
        (JSC::JSArrayBufferView::sizeOf):
        (JSC::JSArrayBufferView::ConstructionContext::operator!):
        (JSC::JSArrayBufferView::ConstructionContext::structure):
        (JSC::JSArrayBufferView::ConstructionContext::vector):
        (JSC::JSArrayBufferView::ConstructionContext::length):
        (JSC::JSArrayBufferView::ConstructionContext::mode):
        (JSC::JSArrayBufferView::ConstructionContext::butterfly):
        (JSC::JSArrayBufferView::mode):
        (JSC::JSArrayBufferView::vector):
        (JSC::JSArrayBufferView::length):
        (JSC::JSArrayBufferView::offsetOfVector):
        (JSC::JSArrayBufferView::offsetOfLength):
        (JSC::JSArrayBufferView::offsetOfMode):
        * runtime/JSArrayBufferViewInlines.h: Added.
        (JSC::JSArrayBufferView::slowDownAndWasteMemoryIfNecessary):
        (JSC::JSArrayBufferView::buffer):
        (JSC::JSArrayBufferView::impl):
        (JSC::JSArrayBufferView::neuter):
        (JSC::JSArrayBufferView::byteOffset):
        * runtime/JSCell.cpp:
        (JSC::JSCell::slowDownAndWasteMemory):
        (JSC::JSCell::getTypedArrayImpl):
        * runtime/JSCell.h:
        * runtime/JSDataView.cpp: Added.
        (JSC::JSDataView::JSDataView):
        (JSC::JSDataView::create):
        (JSC::JSDataView::createUninitialized):
        (JSC::JSDataView::set):
        (JSC::JSDataView::typedImpl):
        (JSC::JSDataView::getOwnPropertySlot):
        (JSC::JSDataView::getOwnPropertyDescriptor):
        (JSC::JSDataView::slowDownAndWasteMemory):
        (JSC::JSDataView::getTypedArrayImpl):
        (JSC::JSDataView::createStructure):
        * runtime/JSDataView.h: Added.
        * runtime/JSDataViewPrototype.cpp: Added.
        (JSC::JSDataViewPrototype::JSDataViewPrototype):
        (JSC::JSDataViewPrototype::create):
        (JSC::JSDataViewPrototype::createStructure):
        (JSC::JSDataViewPrototype::getOwnPropertySlot):
        (JSC::JSDataViewPrototype::getOwnPropertyDescriptor):
        (JSC::getData):
        (JSC::setData):
        (JSC::dataViewProtoFuncGetInt8):
        (JSC::dataViewProtoFuncGetInt16):
        (JSC::dataViewProtoFuncGetInt32):
        (JSC::dataViewProtoFuncGetUint8):
        (JSC::dataViewProtoFuncGetUint16):
        (JSC::dataViewProtoFuncGetUint32):
        (JSC::dataViewProtoFuncGetFloat32):
        (JSC::dataViewProtoFuncGetFloat64):
        (JSC::dataViewProtoFuncSetInt8):
        (JSC::dataViewProtoFuncSetInt16):
        (JSC::dataViewProtoFuncSetInt32):
        (JSC::dataViewProtoFuncSetUint8):
        (JSC::dataViewProtoFuncSetUint16):
        (JSC::dataViewProtoFuncSetUint32):
        (JSC::dataViewProtoFuncSetFloat32):
        (JSC::dataViewProtoFuncSetFloat64):
        * runtime/JSDataViewPrototype.h: Added.
        * runtime/JSFloat32Array.h: Added.
        * runtime/JSFloat64Array.h: Added.
        * runtime/JSGenericTypedArrayView.h: Added.
        (JSC::JSGenericTypedArrayView::byteLength):
        (JSC::JSGenericTypedArrayView::byteSize):
        (JSC::JSGenericTypedArrayView::typedVector):
        (JSC::JSGenericTypedArrayView::canGetIndexQuickly):
        (JSC::JSGenericTypedArrayView::canSetIndexQuickly):
        (JSC::JSGenericTypedArrayView::getIndexQuicklyAsNativeValue):
        (JSC::JSGenericTypedArrayView::getIndexQuicklyAsDouble):
        (JSC::JSGenericTypedArrayView::getIndexQuickly):
        (JSC::JSGenericTypedArrayView::setIndexQuicklyToNativeValue):
        (JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
        (JSC::JSGenericTypedArrayView::setIndexQuickly):
        (JSC::JSGenericTypedArrayView::canAccessRangeQuickly):
        (JSC::JSGenericTypedArrayView::typedImpl):
        (JSC::JSGenericTypedArrayView::createStructure):
        (JSC::JSGenericTypedArrayView::info):
        (JSC::toNativeTypedView):
        * runtime/JSGenericTypedArrayViewConstructor.h: Added.
        * runtime/JSGenericTypedArrayViewConstructorInlines.h: Added.
        (JSC::::JSGenericTypedArrayViewConstructor):
        (JSC::::finishCreation):
        (JSC::::create):
        (JSC::::createStructure):
        (JSC::constructGenericTypedArrayView):
        (JSC::::getConstructData):
        (JSC::::getCallData):
        * runtime/JSGenericTypedArrayViewInlines.h: Added.
        (JSC::::JSGenericTypedArrayView):
        (JSC::::create):
        (JSC::::createUninitialized):
        (JSC::::validateRange):
        (JSC::::setWithSpecificType):
        (JSC::::set):
        (JSC::::getOwnPropertySlot):
        (JSC::::getOwnPropertyDescriptor):
        (JSC::::put):
        (JSC::::defineOwnProperty):
        (JSC::::deleteProperty):
        (JSC::::getOwnPropertySlotByIndex):
        (JSC::::putByIndex):
        (JSC::::deletePropertyByIndex):
        (JSC::::getOwnNonIndexPropertyNames):
        (JSC::::getOwnPropertyNames):
        (JSC::::visitChildren):
        (JSC::::copyBackingStore):
        (JSC::::slowDownAndWasteMemory):
        (JSC::::getTypedArrayImpl):
        * runtime/JSGenericTypedArrayViewPrototype.h: Added.
        * runtime/JSGenericTypedArrayViewPrototypeInlines.h: Added.
        (JSC::genericTypedArrayViewProtoFuncSet):
        (JSC::genericTypedArrayViewProtoFuncSubarray):
        (JSC::::JSGenericTypedArrayViewPrototype):
        (JSC::::finishCreation):
        (JSC::::create):
        (JSC::::createStructure):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::arrayBufferPrototype):
        (JSC::JSGlobalObject::arrayBufferStructure):
        (JSC::JSGlobalObject::typedArrayStructure):
        * runtime/JSInt16Array.h: Added.
        * runtime/JSInt32Array.h: Added.
        * runtime/JSInt8Array.h: Added.
        * runtime/JSTypedArrayConstructors.cpp: Added.
        * runtime/JSTypedArrayConstructors.h: Added.
        * runtime/JSTypedArrayPrototypes.cpp: Added.
        * runtime/JSTypedArrayPrototypes.h: Added.
        * runtime/JSTypedArrays.cpp: Added.
        * runtime/JSTypedArrays.h: Added.
        * runtime/JSUint16Array.h: Added.
        * runtime/JSUint32Array.h: Added.
        * runtime/JSUint8Array.h: Added.
        * runtime/JSUint8ClampedArray.h: Added.
        * runtime/Operations.h:
        * runtime/Options.h:
        * runtime/SimpleTypedArrayController.cpp: Added.
        (JSC::SimpleTypedArrayController::SimpleTypedArrayController):
        (JSC::SimpleTypedArrayController::~SimpleTypedArrayController):
        (JSC::SimpleTypedArrayController::toJS):
        * runtime/SimpleTypedArrayController.h: Added.
        * runtime/Structure.h:
        (JSC::Structure::couldHaveIndexingHeader):
        * runtime/StructureInlines.h:
        (JSC::Structure::hasIndexingHeader):
        * runtime/TypedArrayAdaptors.h: Added.
        (JSC::IntegralTypedArrayAdaptor::toNative):
        (JSC::IntegralTypedArrayAdaptor::toJSValue):
        (JSC::IntegralTypedArrayAdaptor::toDouble):
        (JSC::FloatTypedArrayAdaptor::toNative):
        (JSC::FloatTypedArrayAdaptor::toJSValue):
        (JSC::FloatTypedArrayAdaptor::toDouble):
        (JSC::Uint8ClampedAdaptor::toNative):
        (JSC::Uint8ClampedAdaptor::toJSValue):
        (JSC::Uint8ClampedAdaptor::toDouble):
        (JSC::Uint8ClampedAdaptor::clamp):
        * runtime/TypedArrayController.cpp: Added.
        (JSC::TypedArrayController::TypedArrayController):
        (JSC::TypedArrayController::~TypedArrayController):
        * runtime/TypedArrayController.h: Added.
        * runtime/TypedArrayDescriptor.h: Removed.
        * runtime/TypedArrayInlines.h: Added.
        * runtime/TypedArrayType.cpp: Added.
        (JSC::classInfoForType):
        (WTF::printInternal):
        * runtime/TypedArrayType.h: Added.
        (JSC::toIndex):
        (JSC::isTypedView):
        (JSC::elementSize):
        (JSC::isInt):
        (JSC::isFloat):
        (JSC::isSigned):
        (JSC::isClamped):
        * runtime/TypedArrays.h: Added.
        * runtime/Uint16Array.h:
        * runtime/Uint32Array.h:
        * runtime/Uint8Array.h:
        * runtime/Uint8ClampedArray.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        * runtime/VM.h:

2013-08-15  Oliver Hunt  <oliver@apple.com>

        <https://webkit.org/b/119830> Assigning to a readonly global results in DFG byte code parse failure

        Reviewed by Filip Pizlo.

        Make sure dfgCapabilities doesn't report a Dynamic put as
        being compilable when we don't actually support it.  

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):

2013-08-15  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Incorrect DLL Linkage for JSC ArrayBuffer and ArrayBufferView
        https://bugs.webkit.org/show_bug.cgi?id=119847

        Reviewed by Oliver Hunt.

        * runtime/ArrayBuffer.h: Switch from WTF_EXPORT_PRIVATE to JS_EXPORT_PRIVATE
        * runtime/ArrayBufferView.h: Ditto.

2013-08-15  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=119843
        PropertySlot::setValue is ambiguous

        Reviewed by Geoff Garen.

        There are three different versions of PropertySlot::setValue, one for cacheable properties, and two that are used interchangeably and inconsistently.
        The problematic variants are the ones that just take a value, and one that takes a value and also the object containing the property.
        Unify on always providing the object, and remove the version that just takes a value.
        This always works except for JSString, where we optimize out the object (logically we should be instantiating a temporary StringObject on every property access).
        Provide a version of setValue that takes a JSString as the owner of the property.
        We won't store this, but it makes it clear that this interface should only be used from JSString.

        * API/JSCallbackObjectFunctions.h:
        (JSC::::getOwnPropertySlot):
        * JSCTypedArrayStubs.h:
        * runtime/Arguments.cpp:
        (JSC::Arguments::getOwnPropertySlotByIndex):
        (JSC::Arguments::getOwnPropertySlot):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::symbolTableGet):
        (JSC::JSActivation::getOwnPropertySlot):
        * runtime/JSArray.cpp:
        (JSC::JSArray::getOwnPropertySlot):
        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertySlotByIndex):
        * runtime/JSString.h:
        (JSC::JSString::getStringPropertySlot):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayEntry::get):
            - Pass object containing property to PropertySlot::setValue
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::setValue):
            - Logically, the base of a string property access is a temporary StringObject, but we optimize that away.
        (JSC::PropertySlot::setUndefined):
            - removed setValue(JSValue), added setValue(JSString*, JSValue)

2013-08-15  Oliver Hunt  <oliver@apple.com>

        Remove bogus assertion.

        RS=Filip Pizlo

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):

2013-08-15  Allan Sandfeld Jensen  <allan.jensen@digia.com>

        REGRESSION(r148790) Made 7 tests fail on x86 32bit
        https://bugs.webkit.org/show_bug.cgi?id=114913

        Reviewed by Filip Pizlo.

        The X87 register was not freed before some calls. Instead
        of inserting resetX87Registers to the last call sites,
        the two X87 registers are now freed in every call.

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/instructions.rb:
        * offlineasm/x86.rb:

2013-08-14  Michael Saboff  <msaboff@apple.com>

        Fixed jit on Win64.
        https://bugs.webkit.org/show_bug.cgi?id=119601

        Reviewed by Oliver Hunt.

        * jit/JITStubsMSVC64.asm: Added ctiVMThrowTrampolineSlowpath implementation.
        * jit/JSInterfaceJIT.h: Added thirdArgumentRegister.
        * jit/SlowPathCall.h:
        (JSC::JITSlowPathCall::call): Added correct calling convention for Win64.

2013-08-14  Alex Christensen  <achristensen@apple.com>

        Compile fix for Win64 with jit disabled.
        https://bugs.webkit.org/show_bug.cgi?id=119804

        Reviewed by Michael Saboff.

        * offlineasm/cloop.rb: Added std:: before isnan.

2013-08-14  Julien Brianceau  <jbrianceau@nds.com>

        DFG_JIT implementation for sh4 architecture.
        https://bugs.webkit.org/show_bug.cgi?id=119737

        Reviewed by Oliver Hunt.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::invert):
        (JSC::MacroAssemblerSH4::add32):
        (JSC::MacroAssemblerSH4::and32):
        (JSC::MacroAssemblerSH4::lshift32):
        (JSC::MacroAssemblerSH4::mul32):
        (JSC::MacroAssemblerSH4::or32):
        (JSC::MacroAssemblerSH4::rshift32):
        (JSC::MacroAssemblerSH4::sub32):
        (JSC::MacroAssemblerSH4::xor32):
        (JSC::MacroAssemblerSH4::store32):
        (JSC::MacroAssemblerSH4::swapDouble):
        (JSC::MacroAssemblerSH4::storeDouble):
        (JSC::MacroAssemblerSH4::subDouble):
        (JSC::MacroAssemblerSH4::mulDouble):
        (JSC::MacroAssemblerSH4::divDouble):
        (JSC::MacroAssemblerSH4::negateDouble):
        (JSC::MacroAssemblerSH4::zeroExtend32ToPtr):
        (JSC::MacroAssemblerSH4::branchTruncateDoubleToUint32):
        (JSC::MacroAssemblerSH4::truncateDoubleToUint32):
        (JSC::MacroAssemblerSH4::swap):
        (JSC::MacroAssemblerSH4::jump):
        (JSC::MacroAssemblerSH4::branchNeg32):
        (JSC::MacroAssemblerSH4::branchAdd32):
        (JSC::MacroAssemblerSH4::branchMul32):
        (JSC::MacroAssemblerSH4::urshift32):
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::SH4Assembler):
        (JSC::SH4Assembler::labelForWatchpoint):
        (JSC::SH4Assembler::label):
        (JSC::SH4Assembler::debugOffset):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::preserveReturnAddressAfterCall):
        (JSC::DFG::AssemblyHelpers::restoreReturnAddressBeforeReturn):
        (JSC::DFG::AssemblyHelpers::debugCall):
        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArguments):
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        * dfg/DFGFPRInfo.h:
        (JSC::DFG::FPRInfo::toRegister):
        (JSC::DFG::FPRInfo::toIndex):
        (JSC::DFG::FPRInfo::debugName):
        * dfg/DFGGPRInfo.h:
        (JSC::DFG::GPRInfo::toRegister):
        (JSC::DFG::GPRInfo::toIndex):
        (JSC::DFG::GPRInfo::debugName):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * jit/JITStubs.h:
        * jit/JITStubsSH4.h:

2013-08-13  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix build.

        * API/JSValue.mm:
        (isDate):
        (isArray):
        * API/JSWrapperMap.mm:
        (tryUnwrapObjcObject):
        * API/ObjCCallbackFunction.mm:
        (tryUnwrapBlock):

2013-08-13  Filip Pizlo  <fpizlo@apple.com>

        Foo::s_info should be Foo::info(), so that you can change how the s_info is actually linked
        https://bugs.webkit.org/show_bug.cgi?id=119770

        Reviewed by Mark Hahnenberg.

        * API/JSCallbackConstructor.cpp:
        (JSC::JSCallbackConstructor::finishCreation):
        * API/JSCallbackConstructor.h:
        (JSC::JSCallbackConstructor::createStructure):
        * API/JSCallbackFunction.cpp:
        (JSC::JSCallbackFunction::finishCreation):
        * API/JSCallbackFunction.h:
        (JSC::JSCallbackFunction::createStructure):
        * API/JSCallbackObject.cpp:
        (JSC::::createStructure):
        * API/JSCallbackObject.h:
        (JSC::JSCallbackObject::visitChildren):
        * API/JSCallbackObjectFunctions.h:
        (JSC::::asCallbackObject):
        (JSC::::finishCreation):
        * API/JSObjectRef.cpp:
        (JSObjectGetPrivate):
        (JSObjectSetPrivate):
        (JSObjectGetPrivateProperty):
        (JSObjectSetPrivateProperty):
        (JSObjectDeletePrivateProperty):
        * API/JSValueRef.cpp:
        (JSValueIsObjectOfClass):
        * API/JSWeakObjectMapRefPrivate.cpp:
        * API/ObjCCallbackFunction.h:
        (JSC::ObjCCallbackFunction::createStructure):
        * JSCTypedArrayStubs.h:
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::CallLinkStatus):
        (JSC::CallLinkStatus::function):
        (JSC::CallLinkStatus::internalFunction):
        * bytecode/CodeBlock.h:
        (JSC::baselineCodeBlockForInlineCallFrame):
        * bytecode/SpeculatedType.cpp:
        (JSC::speculationFromClassInfo):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::visitChildren):
        (JSC::UnlinkedCodeBlock::visitChildren):
        (JSC::UnlinkedProgramCodeBlock::visitChildren):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedFunctionExecutable::createStructure):
        (JSC::UnlinkedProgramCodeBlock::createStructure):
        (JSC::UnlinkedEvalCodeBlock::createStructure):
        (JSC::UnlinkedFunctionCodeBlock::createStructure):
        * debugger/Debugger.cpp:
        * debugger/DebuggerActivation.cpp:
        (JSC::DebuggerActivation::visitChildren):
        * debugger/DebuggerActivation.h:
        (JSC::DebuggerActivation::createStructure):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::functionName):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
        (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::isInternalFunctionConstant):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileNewStringObject):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::virtualForThunkGenerator):
        * interpreter/Interpreter.cpp:
        (JSC::loadVarargs):
        * jsc.cpp:
        (GlobalObject::createStructure):
        * profiler/LegacyProfiler.cpp:
        (JSC::LegacyProfiler::createCallIdentifier):
        * runtime/Arguments.cpp:
        (JSC::Arguments::visitChildren):
        * runtime/Arguments.h:
        (JSC::Arguments::createStructure):
        (JSC::asArguments):
        (JSC::Arguments::finishCreation):
        * runtime/ArrayConstructor.cpp:
        (JSC::arrayConstructorIsArray):
        * runtime/ArrayConstructor.h:
        (JSC::ArrayConstructor::createStructure):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoFuncConcat):
        (JSC::attemptFastSort):
        * runtime/ArrayPrototype.h:
        (JSC::ArrayPrototype::createStructure):
        * runtime/BooleanConstructor.h:
        (JSC::BooleanConstructor::createStructure):
        * runtime/BooleanObject.cpp:
        (JSC::BooleanObject::finishCreation):
        * runtime/BooleanObject.h:
        (JSC::BooleanObject::createStructure):
        (JSC::asBooleanObject):
        * runtime/BooleanPrototype.cpp:
        (JSC::BooleanPrototype::finishCreation):
        (JSC::booleanProtoFuncToString):
        (JSC::booleanProtoFuncValueOf):
        * runtime/BooleanPrototype.h:
        (JSC::BooleanPrototype::createStructure):
        * runtime/DateConstructor.cpp:
        (JSC::constructDate):
        * runtime/DateConstructor.h:
        (JSC::DateConstructor::createStructure):
        * runtime/DateInstance.cpp:
        (JSC::DateInstance::finishCreation):
        * runtime/DateInstance.h:
        (JSC::DateInstance::createStructure):
        (JSC::asDateInstance):
        * runtime/DatePrototype.cpp:
        (JSC::formateDateInstance):
        (JSC::DatePrototype::finishCreation):
        (JSC::dateProtoFuncToISOString):
        (JSC::dateProtoFuncToLocaleString):
        (JSC::dateProtoFuncToLocaleDateString):
        (JSC::dateProtoFuncToLocaleTimeString):
        (JSC::dateProtoFuncGetTime):
        (JSC::dateProtoFuncGetFullYear):
        (JSC::dateProtoFuncGetUTCFullYear):
        (JSC::dateProtoFuncGetMonth):
        (JSC::dateProtoFuncGetUTCMonth):
        (JSC::dateProtoFuncGetDate):
        (JSC::dateProtoFuncGetUTCDate):
        (JSC::dateProtoFuncGetDay):
        (JSC::dateProtoFuncGetUTCDay):
        (JSC::dateProtoFuncGetHours):
        (JSC::dateProtoFuncGetUTCHours):
        (JSC::dateProtoFuncGetMinutes):
        (JSC::dateProtoFuncGetUTCMinutes):
        (JSC::dateProtoFuncGetSeconds):
        (JSC::dateProtoFuncGetUTCSeconds):
        (JSC::dateProtoFuncGetMilliSeconds):
        (JSC::dateProtoFuncGetUTCMilliseconds):
        (JSC::dateProtoFuncGetTimezoneOffset):
        (JSC::dateProtoFuncSetTime):
        (JSC::setNewValueFromTimeArgs):
        (JSC::setNewValueFromDateArgs):
        (JSC::dateProtoFuncSetYear):
        (JSC::dateProtoFuncGetYear):
        * runtime/DatePrototype.h:
        (JSC::DatePrototype::createStructure):
        * runtime/Error.h:
        (JSC::StrictModeTypeErrorFunction::createStructure):
        * runtime/ErrorConstructor.h:
        (JSC::ErrorConstructor::createStructure):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::createStructure):
        * runtime/ErrorPrototype.cpp:
        (JSC::ErrorPrototype::finishCreation):
        * runtime/ErrorPrototype.h:
        (JSC::ErrorPrototype::createStructure):
        * runtime/ExceptionHelpers.cpp:
        (JSC::isTerminatedExecutionException):
        * runtime/ExceptionHelpers.h:
        (JSC::TerminatedExecutionError::createStructure):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::visitChildren):
        (JSC::ProgramExecutable::visitChildren):
        (JSC::FunctionExecutable::visitChildren):
        (JSC::ExecutableBase::hashFor):
        * runtime/Executable.h:
        (JSC::ExecutableBase::createStructure):
        (JSC::NativeExecutable::createStructure):
        (JSC::EvalExecutable::createStructure):
        (JSC::ProgramExecutable::createStructure):
        (JSC::FunctionExecutable::compileFor):
        (JSC::FunctionExecutable::compileOptimizedFor):
        (JSC::FunctionExecutable::createStructure):
        * runtime/FunctionConstructor.h:
        (JSC::FunctionConstructor::createStructure):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):
        (JSC::functionProtoFuncApply):
        (JSC::functionProtoFuncBind):
        * runtime/FunctionPrototype.h:
        (JSC::FunctionPrototype::createStructure):
        * runtime/GetterSetter.cpp:
        (JSC::GetterSetter::visitChildren):
        * runtime/GetterSetter.h:
        (JSC::GetterSetter::createStructure):
        * runtime/InternalFunction.cpp:
        (JSC::InternalFunction::finishCreation):
        * runtime/InternalFunction.h:
        (JSC::InternalFunction::createStructure):
        (JSC::asInternalFunction):
        * runtime/JSAPIValueWrapper.h:
        (JSC::JSAPIValueWrapper::createStructure):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::visitChildren):
        (JSC::JSActivation::argumentsGetter):
        * runtime/JSActivation.h:
        (JSC::JSActivation::createStructure):
        (JSC::asActivation):
        * runtime/JSArray.h:
        (JSC::JSArray::createStructure):
        (JSC::asArray):
        (JSC::isJSArray):
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::finishCreation):
        (JSC::JSBoundFunction::visitChildren):
        * runtime/JSBoundFunction.h:
        (JSC::JSBoundFunction::createStructure):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dumpInContext):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::isFunction):
        * runtime/JSCell.h:
        (JSC::jsCast):
        (JSC::jsDynamicCast):
        * runtime/JSCellInlines.h:
        (JSC::allocateCell):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::finishCreation):
        (JSC::JSFunction::visitChildren):
        (JSC::skipOverBoundFunctions):
        (JSC::JSFunction::callerGetter):
        * runtime/JSFunction.h:
        (JSC::JSFunction::createStructure):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::visitChildren):
        (JSC::slowValidateCell):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::createStructure):
        * runtime/JSNameScope.cpp:
        (JSC::JSNameScope::visitChildren):
        * runtime/JSNameScope.h:
        (JSC::JSNameScope::createStructure):
        * runtime/JSNotAnObject.h:
        (JSC::JSNotAnObject::createStructure):
        * runtime/JSONObject.cpp:
        (JSC::JSONObject::finishCreation):
        (JSC::unwrapBoxedPrimitive):
        (JSC::Stringifier::Stringifier):
        (JSC::Stringifier::appendStringifiedValue):
        (JSC::Stringifier::Holder::Holder):
        (JSC::Walker::walk):
        (JSC::JSONProtoFuncStringify):
        * runtime/JSONObject.h:
        (JSC::JSONObject::createStructure):
        * runtime/JSObject.cpp:
        (JSC::getCallableObjectSlow):
        (JSC::JSObject::visitChildren):
        (JSC::JSObject::copyBackingStore):
        (JSC::JSFinalObject::visitChildren):
        (JSC::JSObject::ensureInt32Slow):
        (JSC::JSObject::ensureDoubleSlow):
        (JSC::JSObject::ensureContiguousSlow):
        (JSC::JSObject::ensureArrayStorageSlow):
        * runtime/JSObject.h:
        (JSC::JSObject::finishCreation):
        (JSC::JSObject::createStructure):
        (JSC::JSNonFinalObject::createStructure):
        (JSC::JSFinalObject::createStructure):
        (JSC::isJSFinalObject):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::visitChildren):
        * runtime/JSPropertyNameIterator.h:
        (JSC::JSPropertyNameIterator::createStructure):
        * runtime/JSProxy.cpp:
        (JSC::JSProxy::visitChildren):
        * runtime/JSProxy.h:
        (JSC::JSProxy::createStructure):
        * runtime/JSScope.cpp:
        (JSC::JSScope::visitChildren):
        * runtime/JSSegmentedVariableObject.cpp:
        (JSC::JSSegmentedVariableObject::visitChildren):
        * runtime/JSString.h:
        (JSC::JSString::createStructure):
        (JSC::isJSString):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::visitChildren):
        * runtime/JSVariableObject.h:
        * runtime/JSWithScope.cpp:
        (JSC::JSWithScope::visitChildren):
        * runtime/JSWithScope.h:
        (JSC::JSWithScope::createStructure):
        * runtime/JSWrapperObject.cpp:
        (JSC::JSWrapperObject::visitChildren):
        * runtime/JSWrapperObject.h:
        (JSC::JSWrapperObject::createStructure):
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        * runtime/MathObject.h:
        (JSC::MathObject::createStructure):
        * runtime/NameConstructor.h:
        (JSC::NameConstructor::createStructure):
        * runtime/NameInstance.h:
        (JSC::NameInstance::createStructure):
        (JSC::NameInstance::finishCreation):
        * runtime/NamePrototype.cpp:
        (JSC::NamePrototype::finishCreation):
        (JSC::privateNameProtoFuncToString):
        * runtime/NamePrototype.h:
        (JSC::NamePrototype::createStructure):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::NativeErrorConstructor::visitChildren):
        * runtime/NativeErrorConstructor.h:
        (JSC::NativeErrorConstructor::createStructure):
        (JSC::NativeErrorConstructor::finishCreation):
        * runtime/NumberConstructor.cpp:
        (JSC::NumberConstructor::finishCreation):
        * runtime/NumberConstructor.h:
        (JSC::NumberConstructor::createStructure):
        * runtime/NumberObject.cpp:
        (JSC::NumberObject::finishCreation):
        * runtime/NumberObject.h:
        (JSC::NumberObject::createStructure):
        * runtime/NumberPrototype.cpp:
        (JSC::NumberPrototype::finishCreation):
        * runtime/NumberPrototype.h:
        (JSC::NumberPrototype::createStructure):
        * runtime/ObjectConstructor.h:
        (JSC::ObjectConstructor::createStructure):
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        * runtime/ObjectPrototype.h:
        (JSC::ObjectPrototype::createStructure):
        * runtime/PropertyMapHashTable.h:
        (JSC::PropertyTable::createStructure):
        * runtime/PropertyTable.cpp:
        (JSC::PropertyTable::visitChildren):
        * runtime/RegExp.h:
        (JSC::RegExp::createStructure):
        * runtime/RegExpConstructor.cpp:
        (JSC::RegExpConstructor::finishCreation):
        (JSC::RegExpConstructor::visitChildren):
        (JSC::constructRegExp):
        * runtime/RegExpConstructor.h:
        (JSC::RegExpConstructor::createStructure):
        (JSC::asRegExpConstructor):
        * runtime/RegExpMatchesArray.cpp:
        (JSC::RegExpMatchesArray::visitChildren):
        * runtime/RegExpMatchesArray.h:
        (JSC::RegExpMatchesArray::createStructure):
        * runtime/RegExpObject.cpp:
        (JSC::RegExpObject::finishCreation):
        (JSC::RegExpObject::visitChildren):
        * runtime/RegExpObject.h:
        (JSC::RegExpObject::createStructure):
        (JSC::asRegExpObject):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncTest):
        (JSC::regExpProtoFuncExec):
        (JSC::regExpProtoFuncCompile):
        (JSC::regExpProtoFuncToString):
        * runtime/RegExpPrototype.h:
        (JSC::RegExpPrototype::createStructure):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::createStructure):
        * runtime/SparseArrayValueMap.h:
        * runtime/StrictEvalActivation.h:
        (JSC::StrictEvalActivation::createStructure):
        * runtime/StringConstructor.h:
        (JSC::StringConstructor::createStructure):
        * runtime/StringObject.cpp:
        (JSC::StringObject::finishCreation):
        * runtime/StringObject.h:
        (JSC::StringObject::createStructure):
        (JSC::asStringObject):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::stringProtoFuncReplace):
        (JSC::stringProtoFuncToString):
        (JSC::stringProtoFuncMatch):
        (JSC::stringProtoFuncSearch):
        (JSC::stringProtoFuncSplit):
        * runtime/StringPrototype.h:
        (JSC::StringPrototype::createStructure):
        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::materializePropertyMap):
        (JSC::Structure::get):
        (JSC::Structure::visitChildren):
        * runtime/Structure.h:
        (JSC::Structure::typeInfo):
        (JSC::Structure::previousID):
        (JSC::Structure::outOfLineSize):
        (JSC::Structure::totalStorageCapacity):
        (JSC::Structure::materializePropertyMapIfNecessary):
        (JSC::Structure::materializePropertyMapIfNecessaryForPinning):
        * runtime/StructureChain.cpp:
        (JSC::StructureChain::visitChildren):
        * runtime/StructureChain.h:
        (JSC::StructureChain::createStructure):
        * runtime/StructureInlines.h:
        (JSC::Structure::get):
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::createStructure):
        (JSC::StructureRareData::visitChildren):
        * runtime/StructureRareData.h:
        * runtime/SymbolTable.h:
        (JSC::SharedSymbolTable::createStructure):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::StackPreservingRecompiler::operator()):
        (JSC::VM::releaseExecutableMemory):
        * runtime/WriteBarrier.h:
        (JSC::validateCell):
        * testRegExp.cpp:
        (GlobalObject::createStructure):

2013-08-13  Arunprasad Rajkumar  <arurajku@cisco.com>

        [WTF] [JSC] Replace currentTime() with monotonicallyIncreasingTime() in all possible places
        https://bugs.webkit.org/show_bug.cgi?id=119762

        Reviewed by Geoffrey Garen.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::markRoots):
        (JSC::Heap::collect):
        * jsc.cpp:
        (StopWatch::start):
        (StopWatch::stop):
        * testRegExp.cpp:
        (StopWatch::start):
        (StopWatch::stop):

2013-08-13  Julien Brianceau  <jbrianceau@nds.com>

        [sh4] Prepare LLINT for DFG_JIT implementation.
        https://bugs.webkit.org/show_bug.cgi?id=119755

        Reviewed by Oliver Hunt.

        * LLIntOffsetsExtractor.pro: Add sh4.rb dependency.
        * offlineasm/sh4.rb:
            - Handle storeb opcode.
            - Make relative jumps when possible using braf opcode.
            - Update bmulio implementation to be consistent with baseline JIT.
            - Remove useless code from leap opcode.
            - Fix incorrect comment.

2013-08-13  Julien Brianceau  <jbrianceau@nds.com>

        [sh4] Prepare baseline JIT for DFG_JIT implementation.
        https://bugs.webkit.org/show_bug.cgi?id=119758

        Reviewed by Oliver Hunt.

        * assembler/MacroAssemblerSH4.h:
            - Introduce a loadEffectiveAddress function to avoid code duplication.
            - Add ASSERTs and clean code.
        * assembler/SH4Assembler.h:
            - Prepare DFG_JIT implementation.
            - Add ASSERTs.
        * jit/JITStubs.cpp:
            - Add SH4 specific call for assertions.
        * jit/JITStubs.h:
            - Cosmetic change.
        * jit/JITStubsSH4.h:
            - Use constants to be more flexible with sh4 JIT stack frame.
        * jit/JSInterfaceJIT.h:
            - Cosmetic change.

2013-08-13  Oliver Hunt  <oliver@apple.com>

        Harden executeConstruct against incorrect return types from host functions
        https://bugs.webkit.org/show_bug.cgi?id=119757

        Reviewed by Mark Hahnenberg.

        Add logic to guard against bogus return types.  There doesn't seem to be any
        class in webkit that does this wrong, but the typed array stubs in debug JSC
        do exhibit this bad behaviour.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeConstruct):

2013-08-13  Allan Sandfeld Jensen  <allan.jensen@digia.com>

        [Qt] Fix C++11 build with gcc 4.4 and 4.5
        https://bugs.webkit.org/show_bug.cgi?id=119736

        Reviewed by Anders Carlsson.

        Don't force C++11 mode off anymore.

        * Target.pri:

2013-08-12  Oliver Hunt  <oliver@apple.com>

        Remove CodeBlock's notion of adding identifiers entirely
        https://bugs.webkit.org/show_bug.cgi?id=119708

        Reviewed by Geoffrey Garen.

        Remove addAdditionalIdentifier entirely, including the bogus assertion.
        Move the addition of identifiers to DFGPlan::reallyAdd

        * bytecode/CodeBlock.h:
        * dfg/DFGDesiredIdentifiers.cpp:
        (JSC::DFG::DesiredIdentifiers::reallyAdd):
        * dfg/DFGDesiredIdentifiers.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::reallyAdd):
        (JSC::DFG::Plan::finalize):
        * dfg/DFGPlan.h:

2013-08-12  Oliver Hunt  <oliver@apple.com>

        Build fix

        * runtime/JSCell.h:

2013-08-12  Oliver Hunt  <oliver@apple.com>

        Move additionalIdentifiers into DFGCommonData as only the optimising JITs use them
        https://bugs.webkit.org/show_bug.cgi?id=119705

        Reviewed by Geoffrey Garen.

        Relatively trivial refactoring

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numberOfAdditionalIdentifiers):
        (JSC::CodeBlock::addAdditionalIdentifier):
        (JSC::CodeBlock::identifier):
        (JSC::CodeBlock::numberOfIdentifiers):
        * dfg/DFGCommonData.h:

2013-08-12  Oliver Hunt  <oliver@apple.com>

        Stop making unnecessary copy of CodeBlock Identifier Vector
        https://bugs.webkit.org/show_bug.cgi?id=119702

        Reviewed by Michael Saboff.

        Make CodeBlock simply use a separate Vector for additional Identifiers
        and use the UnlinkedCodeBlock for the initial set of identifiers.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::dumpStructure):
        (JSC::dumpChain):
        (JSC::CodeBlock::printGetByIdCacheStatus):
        (JSC::CodeBlock::printPutByIdOp):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::shrinkToFit):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numberOfIdentifiers):
        (JSC::CodeBlock::numberOfAdditionalIdentifiers):
        (JSC::CodeBlock::addAdditionalIdentifier):
        (JSC::CodeBlock::identifier):
        * dfg/DFGDesiredIdentifiers.cpp:
        (JSC::DFG::DesiredIdentifiers::reallyAdd):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitSlow_op_get_arguments_length):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::compileGetByIdSlowCase):
        (JSC::JIT::emitSlow_op_put_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::compileGetByIdSlowCase):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):

2013-08-08  Mark Lam  <mark.lam@apple.com>

        Restoring use of StackIterator instead of Interpreter::getStacktrace().
        https://bugs.webkit.org/show_bug.cgi?id=119575.

        Reviewed by Oliver Hunt.

        * interpreter/Interpreter.h:
        - Made getStackTrace() private.
        * interpreter/StackIterator.cpp:
        (JSC::StackIterator::StackIterator):
        (JSC::StackIterator::numberOfFrames):
        - Computes the number of frames by iterating through the whole stack
          from the starting frame. The iterator will save its current frame
          position before counting the frames, and then restoring it after
          the counting.
        (JSC::StackIterator::gotoFrameAtIndex):
        (JSC::StackIterator::gotoNextFrame):
        (JSC::StackIterator::resetIterator):
        - Points the iterator to the starting frame.
        * interpreter/StackIteratorPrivate.h:

2013-08-08  Mark Lam  <mark.lam@apple.com>

        Moved ErrorConstructor and NativeErrorConstructor helper functions into
        the Interpreter class.
        https://bugs.webkit.org/show_bug.cgi?id=119576.

        Reviewed by Oliver Hunt.

        This change is needed to prepare for making Interpreter::getStackTrace()
        private. It does not change the behavior of the code, only the lexical
        scoping.

        * interpreter/Interpreter.h:
        - Added helper functions for ErrorConstructor and NativeErrorConstructor.
        * runtime/ErrorConstructor.cpp:
        (JSC::Interpreter::constructWithErrorConstructor):
        (JSC::ErrorConstructor::getConstructData):
        (JSC::Interpreter::callErrorConstructor):
        (JSC::ErrorConstructor::getCallData):
        - Don't want ErrorConstructor to call Interpreter::getStackTrace()
          directly. So, we moved the helper functions into the Interpreter
          class.
        * runtime/NativeErrorConstructor.cpp:
        (JSC::Interpreter::constructWithNativeErrorConstructor):
        (JSC::NativeErrorConstructor::getConstructData):
        (JSC::Interpreter::callNativeErrorConstructor):
        (JSC::NativeErrorConstructor::getCallData):
        - Don't want NativeErrorConstructor to call Interpreter::getStackTrace()
          directly. So, we moved the helper functions into the Interpreter
          class.

2013-08-07  Mark Hahnenberg  <mhahnenberg@apple.com>

        32-bit code gen for TypeOf doesn't properly update the AbstractInterpreter state
        https://bugs.webkit.org/show_bug.cgi?id=119555

        Reviewed by Geoffrey Garen.

        It uses a speculationCheck where it should be using a DFG_TYPE_CHECK like the 64-bit backend does.
        This was causing crashes on maps.google.com in 32-bit debug builds.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2013-08-06  Michael Saboff  <msaboff@apple.com>

        REGRESSION(FTL merge): Assertion fail on 32 bit with enabled DFG JIT
        https://bugs.webkit.org/show_bug.cgi?id=119405

        Reviewed by Geoffrey Garen.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString): For X86 32 bit, construct an indexed address
        ourselves to save a register and then load from it.

2013-08-06  Filip Pizlo  <fpizlo@apple.com>

        DFG FixupPhase should insert Int32ToDouble nodes for number uses in NewArray, and SpeculativeJIT 64-bit should not try to coerce integer constants to double constants
        https://bugs.webkit.org/show_bug.cgi?id=119528

        Reviewed by Geoffrey Garen.

        Either of the two fixes would solve the crash I saw. Basically, for best performance, we want the DFG register allocator to track double uses and non-double
        uses of a node separately, and we accomplish this by inserting Int32ToDouble nodes in the FixupPhase. But even if FixupPhase fails to do this, we still want
        the DFG register allocator to do the right thing: if it encounters a double use of an integer, it should perform a conversion and preserve the original
        format of the value (namely, that it was an integer). For constants, the best format to preserve is None, so that future integer uses rematerialize the int
        from scratch. This only affects the 64-bit backend; the 32-bit backend was already doing the right thing.

        This also fixes some more debug dumping code, and adds some stronger assertions for integer arrays.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeUnconditionally):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        * runtime/JSObject.h:
        (JSC::JSObject::getIndexQuickly):
        (JSC::JSObject::tryGetIndexQuickly):

2013-08-08  Stephanie Lewis  <slewis@apple.com>

        <rdar://problem/14680524> REGRESSION(153806): Crash @ yahoo.com when WebKit is built with a .order file

        Unreviewed.

        Ensure llint symbols are in source order.

        * JavaScriptCore.order:

2013-08-06  Mark Lam  <mark.lam@apple.com>

        Assertion failure in emitExpressionInfo when reloading with Web Inspector open.
        https://bugs.webkit.org/show_bug.cgi?id=119532.

        Reviewed by Oliver Hunt.

        * parser/Parser.cpp:
        (JSC::::Parser):
        - Just need to initialize the Parser's JSTokenLocation's initial line and
          startOffset as well during Parser construction.

2013-08-06  Stephanie Lewis  <slewis@apple.com>

        Update Order Files for Safari
        <rdar://problem/14517392>

        Unreviewed.

        * JavaScriptCore.order:

2013-08-04  Sam Weinig  <sam@webkit.org>

        Remove support for HTML5 MicroData
        https://bugs.webkit.org/show_bug.cgi?id=119480

        Reviewed by Anders Carlsson.

        * Configurations/FeatureDefines.xcconfig:

2013-08-05  Oliver Hunt  <oliver@apple.com>

        Delay Arguments creation in strict mode
        https://bugs.webkit.org/show_bug.cgi?id=119505

        Reviewed by Geoffrey Garen.

        Make use of the write tracking performed by the parser to
        allow us to know if we're modifying the parameters to a function.
        Then use that information to make strict mode function opt out
        of eager arguments creation.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::createArgumentsIfNecessary):
        (JSC::BytecodeGenerator::emitReturn):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::shouldTearOffArgumentsEagerly):
        * parser/Nodes.h:
        (JSC::ScopeNode::modifiesParameter):
        * parser/Parser.cpp:
        (JSC::::parseInner):
        * parser/Parser.h:
        (JSC::Scope::declareParameter):
        (JSC::Scope::getCapturedVariables):
        (JSC::Parser::declareWrite):
        * parser/ParserModes.h:

2013-08-06  Patrick Gansterer  <paroga@webkit.org>

        Remove useless code from COMPILER(RVCT) JITStubs
        https://bugs.webkit.org/show_bug.cgi?id=119521

        Reviewed by Geoffrey Garen.

        * jit/JITStubsARMv7.h:
        (JSC::ctiVMThrowTrampoline): "ldr r6, [sp, #PRESERVED_R6_OFFSET]" was called twice.
        (JSC::ctiOpThrowNotCaught): Ditto.

2013-07-23  David Farler  <dfarler@apple.com>

        Provide optional OTHER_CFLAGS, OTHER_CPPFLAGS, OTHER_LDFLAGS additions for building with ASAN
        https://bugs.webkit.org/show_bug.cgi?id=117762

        Reviewed by Mark Rowe.

        * Configurations/DebugRelease.xcconfig:
        Add ASAN_OTHER_CFLAGS, CPLUSPLUSFLAGS, LDFLAGS.
        * Configurations/JavaScriptCore.xcconfig:
        Add ASAN_OTHER_LDFLAGS.
        * Configurations/ToolExecutable.xcconfig:
        Don't use ASAN for build tools.

2013-08-06  Patrick Gansterer  <paroga@webkit.org>

        Build fix for ARM MSVC after r153222 and r153648.

        * jit/JITStubsARM.h: Added ctiVMThrowTrampolineSlowpath.

2013-08-06  Patrick Gansterer  <paroga@webkit.org>

        Build fix for ARM MSVC after r150109.

        Read the stub template from a header files instead of the JITStubs.cpp.

        * CMakeLists.txt:
        * DerivedSources.pri:
        * create_jit_stubs:

2013-08-05  Oliver Hunt  <oliver@apple.com>

        Move TypedArray implementation into JSC
        https://bugs.webkit.org/show_bug.cgi?id=119489

        Reviewed by Filip Pizlo.

        Move TypedArray implementation into JSC in advance of re-implementation

        * GNUmakefile.list.am:
        * JSCTypedArrayStubs.h:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/ArrayBuffer.cpp: Renamed from Source/WTF/wtf/ArrayBuffer.cpp.
        (JSC::ArrayBuffer::transfer):
        (JSC::ArrayBuffer::addView):
        (JSC::ArrayBuffer::removeView):
        * runtime/ArrayBuffer.h: Renamed from Source/WTF/wtf/ArrayBuffer.h.
        (JSC::ArrayBufferContents::ArrayBufferContents):
        (JSC::ArrayBufferContents::data):
        (JSC::ArrayBufferContents::sizeInBytes):
        (JSC::ArrayBufferContents::transfer):
        (JSC::ArrayBufferContents::copyTo):
        (JSC::ArrayBuffer::isNeutered):
        (JSC::ArrayBuffer::~ArrayBuffer):
        (JSC::ArrayBuffer::clampValue):
        (JSC::ArrayBuffer::create):
        (JSC::ArrayBuffer::createUninitialized):
        (JSC::ArrayBuffer::ArrayBuffer):
        (JSC::ArrayBuffer::data):
        (JSC::ArrayBuffer::byteLength):
        (JSC::ArrayBuffer::slice):
        (JSC::ArrayBuffer::sliceImpl):
        (JSC::ArrayBuffer::clampIndex):
        (JSC::ArrayBufferContents::tryAllocate):
        (JSC::ArrayBufferContents::~ArrayBufferContents):
        * runtime/ArrayBufferView.cpp: Renamed from Source/WTF/wtf/ArrayBufferView.cpp.
        (JSC::ArrayBufferView::ArrayBufferView):
        (JSC::ArrayBufferView::~ArrayBufferView):
        (JSC::ArrayBufferView::neuter):
        * runtime/ArrayBufferView.h: Renamed from Source/WTF/wtf/ArrayBufferView.h.
        (JSC::ArrayBufferView::buffer):
        (JSC::ArrayBufferView::baseAddress):
        (JSC::ArrayBufferView::byteOffset):
        (JSC::ArrayBufferView::setNeuterable):
        (JSC::ArrayBufferView::isNeuterable):
        (JSC::ArrayBufferView::verifySubRange):
        (JSC::ArrayBufferView::clampOffsetAndNumElements):
        (JSC::ArrayBufferView::setImpl):
        (JSC::ArrayBufferView::setRangeImpl):
        (JSC::ArrayBufferView::zeroRangeImpl):
        (JSC::ArrayBufferView::calculateOffsetAndLength):
        * runtime/Float32Array.h: Renamed from Source/WTF/wtf/Float32Array.h.
        (JSC::Float32Array::set):
        (JSC::Float32Array::getType):
        (JSC::Float32Array::create):
        (JSC::Float32Array::createUninitialized):
        (JSC::Float32Array::Float32Array):
        (JSC::Float32Array::subarray):
        * runtime/Float64Array.h: Renamed from Source/WTF/wtf/Float64Array.h.
        (JSC::Float64Array::set):
        (JSC::Float64Array::getType):
        (JSC::Float64Array::create):
        (JSC::Float64Array::createUninitialized):
        (JSC::Float64Array::Float64Array):
        (JSC::Float64Array::subarray):
        * runtime/Int16Array.h: Renamed from Source/WTF/wtf/Int16Array.h.
        (JSC::Int16Array::getType):
        (JSC::Int16Array::create):
        (JSC::Int16Array::createUninitialized):
        (JSC::Int16Array::Int16Array):
        (JSC::Int16Array::subarray):
        * runtime/Int32Array.h: Renamed from Source/WTF/wtf/Int32Array.h.
        (JSC::Int32Array::getType):
        (JSC::Int32Array::create):
        (JSC::Int32Array::createUninitialized):
        (JSC::Int32Array::Int32Array):
        (JSC::Int32Array::subarray):
        * runtime/Int8Array.h: Renamed from Source/WTF/wtf/Int8Array.h.
        (JSC::Int8Array::getType):
        (JSC::Int8Array::create):
        (JSC::Int8Array::createUninitialized):
        (JSC::Int8Array::Int8Array):
        (JSC::Int8Array::subarray):
        * runtime/IntegralTypedArrayBase.h: Renamed from Source/WTF/wtf/IntegralTypedArrayBase.h.
        (JSC::IntegralTypedArrayBase::set):
        (JSC::IntegralTypedArrayBase::IntegralTypedArrayBase):
        * runtime/TypedArrayBase.h: Renamed from Source/WTF/wtf/TypedArrayBase.h.
        (JSC::TypedArrayBase::data):
        (JSC::TypedArrayBase::set):
        (JSC::TypedArrayBase::setRange):
        (JSC::TypedArrayBase::zeroRange):
        (JSC::TypedArrayBase::length):
        (JSC::TypedArrayBase::byteLength):
        (JSC::TypedArrayBase::item):
        (JSC::TypedArrayBase::checkInboundData):
        (JSC::TypedArrayBase::TypedArrayBase):
        (JSC::TypedArrayBase::create):
        (JSC::TypedArrayBase::createUninitialized):
        (JSC::TypedArrayBase::subarrayImpl):
        (JSC::TypedArrayBase::neuter):
        * runtime/Uint16Array.h: Renamed from Source/WTF/wtf/Uint16Array.h.
        (JSC::Uint16Array::getType):
        (JSC::Uint16Array::create):
        (JSC::Uint16Array::createUninitialized):
        (JSC::Uint16Array::Uint16Array):
        (JSC::Uint16Array::subarray):
        * runtime/Uint32Array.h: Renamed from Source/WTF/wtf/Uint32Array.h.
        (JSC::Uint32Array::getType):
        (JSC::Uint32Array::create):
        (JSC::Uint32Array::createUninitialized):
        (JSC::Uint32Array::Uint32Array):
        (JSC::Uint32Array::subarray):
        * runtime/Uint8Array.h: Renamed from Source/WTF/wtf/Uint8Array.h.
        (JSC::Uint8Array::getType):
        (JSC::Uint8Array::create):
        (JSC::Uint8Array::createUninitialized):
        (JSC::Uint8Array::Uint8Array):
        (JSC::Uint8Array::subarray):
        * runtime/Uint8ClampedArray.h: Renamed from Source/WTF/wtf/Uint8ClampedArray.h.
        (JSC::Uint8ClampedArray::getType):
        (JSC::Uint8ClampedArray::create):
        (JSC::Uint8ClampedArray::createUninitialized):
        (JSC::Uint8ClampedArray::zeroFill):
        (JSC::Uint8ClampedArray::set):
        (JSC::Uint8ClampedArray::Uint8ClampedArray):
        (JSC::Uint8ClampedArray::subarray):
        * runtime/VM.h:

2013-08-03  Filip Pizlo  <fpizlo@apple.com>

        Copied space should be able to handle more than one copied backing store per JSCell
        https://bugs.webkit.org/show_bug.cgi?id=119471

        Reviewed by Mark Hahnenberg.
        
        This allows a cell to call copyLater() multiple times for multiple different
        backing stores, and then have copyBackingStore() called exactly once for each
        of those. A token tells it which backing store to copy. All backing stores
        must be named using the CopyToken, an enumeration which currently cannot
        exceed eight entries.
        
        When copyBackingStore() is called, it's up to the callee to (a) use the token
        to decide what to copy and (b) call its base class's copyBackingStore() in
        case the base class had something that needed copying. The only exception is
        that JSCell never asks anything to be copied, and so if your base is JSCell
        then you don't have to do anything.

        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/CopiedBlock.h:
        * heap/CopiedBlockInlines.h:
        (JSC::CopiedBlock::reportLiveBytes):
        * heap/CopyToken.h: Added.
        * heap/CopyVisitor.cpp:
        (JSC::CopyVisitor::copyFromShared):
        * heap/CopyVisitor.h:
        * heap/CopyVisitorInlines.h:
        (JSC::CopyVisitor::visitItem):
        * heap/CopyWorkList.h:
        (JSC::CopyWorklistItem::CopyWorklistItem):
        (JSC::CopyWorklistItem::cell):
        (JSC::CopyWorklistItem::token):
        (JSC::CopyWorkListSegment::get):
        (JSC::CopyWorkListSegment::append):
        (JSC::CopyWorkListSegment::data):
        (JSC::CopyWorkListIterator::get):
        (JSC::CopyWorkListIterator::operator*):
        (JSC::CopyWorkListIterator::operator->):
        (JSC::CopyWorkList::append):
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::copyLater):
        * runtime/ClassInfo.h:
        * runtime/JSCell.cpp:
        (JSC::JSCell::copyBackingStore):
        * runtime/JSCell.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::copyBackingStore):
        * runtime/JSObject.h:

2013-08-05  Zan Dobersek  <zdobersek@igalia.com>

        [Automake] Define ENABLE_JIT through the Autoconf header
        https://bugs.webkit.org/show_bug.cgi?id=119445

        Reviewed by Martin Robinson.

        * GNUmakefile.am: Remove JSC_CPPFLAGS from the cpp flags for the JSC library.

2013-08-03  Filip Pizlo  <fpizlo@apple.com>

        hasIndexingHeader() ought really to be a property of an object and its structure, not just its structure
        https://bugs.webkit.org/show_bug.cgi?id=119470

        Reviewed by Oliver Hunt.
        
        Structure can still tell you if the object "could" (in the conservative sense)
        have an indexing header; that's used by the compiler.
        
        Most of the time if you want to know if there's an indexing header, you ask the
        JSObject.
        
        In some cases, the JSObject wants to know if it would have an indexing header if
        it had a different structure; then it uses Structure::hasIndexingHeader(JSCell*).

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCachePutByID):
        (JSC::DFG::tryBuildPutByIdList):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::create):
        (JSC::Butterfly::growPropertyStorage):
        (JSC::Butterfly::growArrayRight):
        (JSC::Butterfly::resizeArray):
        * runtime/JSObject.cpp:
        (JSC::JSObject::copyButterfly):
        (JSC::JSObject::visitButterfly):
        * runtime/JSObject.h:
        (JSC::JSObject::hasIndexingHeader):
        (JSC::JSObject::setButterfly):
        * runtime/Structure.h:
        (JSC::Structure::couldHaveIndexingHeader):
        (JSC::Structure::hasIndexingHeader):

2013-08-02  Chris Curtis  <chris_curtis@apple.com>

        Give the error object's stack property accessor attributes.
        https://bugs.webkit.org/show_bug.cgi?id=119404

        Reviewed by Geoffrey Garen.
        
        Changed the attributes of error object's stack property to allow developers to write
        and delete the stack property. This will match the functionality of Chrome. Firefox  
        allows developers to write the error's stack, but not delete it. 

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::addStackTraceIfNecessary):
        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):

2013-08-02  Oliver Hunt  <oliver@apple.com>

        Incorrect type speculation reported by ToPrimitive
        https://bugs.webkit.org/show_bug.cgi?id=119458

        Reviewed by Mark Hahnenberg.

        Make sure that we report the correct type possibilities for the output
        from ToPrimitive

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):

2013-08-02  Gavin Barraclough  <barraclough@apple.com>

        Remove no-arguments constructor to PropertySlot
        https://bugs.webkit.org/show_bug.cgi?id=119460

        Reviewed by Geoff Garen.

        This constructor was unsafe if getValue is subsequently called,
        and the property is a getter. Simplest to just remove it.

        * runtime/Arguments.cpp:
        (JSC::Arguments::defineOwnProperty):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::getOwnPropertyDescriptor):
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertyDescriptor):
        (JSC::JSFunction::getOwnNonIndexPropertyNames):
        (JSC::JSFunction::put):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::defineOwnProperty):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::hasOwnPropertyForWrite):
        * runtime/JSNameScope.cpp:
        (JSC::JSNameScope::put):
        * runtime/JSONObject.cpp:
        (JSC::Stringifier::Holder::appendNextProperty):
        (JSC::Walker::walk):
        * runtime/JSObject.cpp:
        (JSC::JSObject::hasProperty):
        (JSC::JSObject::hasOwnProperty):
        (JSC::JSObject::reifyStaticFunctionsForDelete):
        * runtime/Lookup.h:
        (JSC::getStaticPropertyDescriptor):
        (JSC::getStaticFunctionDescriptor):
        (JSC::getStaticValueDescriptor):
        * runtime/ObjectConstructor.cpp:
        (JSC::defineProperties):
        * runtime/PropertySlot.h:

2013-08-02  Mark Hahnenberg  <mhahnenberg@apple.com>

        DFG validation can cause assertion failures due to dumping
        https://bugs.webkit.org/show_bug.cgi?id=119456

        Reviewed by Geoffrey Garen.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::hasHash):
        (JSC::CodeBlock::isSafeToComputeHash):
        (JSC::CodeBlock::hash):
        (JSC::CodeBlock::dumpAssumingJITType):
        * bytecode/CodeBlock.h:

2013-08-02  Chris Curtis  <chris_curtis@apple.com>

        Have vm's exceptionStack match java's vm's exceptionStack.
        https://bugs.webkit.org/show_bug.cgi?id=119362

        Reviewed by Geoffrey Garen.
        
        The error object's stack is only updated if it does not exist yet. This matches 
        the functionality of other browsers, and Java VMs. 

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::addStackTraceIfNecessary):
        (JSC::Interpreter::throwException):
        * runtime/VM.cpp:
        (JSC::VM::clearExceptionStack):
        * runtime/VM.h:
        (JSC::VM::lastExceptionStack):

2013-08-02  Julien Brianceau  <jbrianceau@nds.com>

        REGRESSION(FTL): Fix mips implementation of ctiVMThrowTrampolineSlowpath.
        https://bugs.webkit.org/show_bug.cgi?id=119447

        Reviewed by Geoffrey Garen.

        Fix .cpload, update call frame and do not restore registers from JIT stack frame in
        mips implementation of ctiVMThrowTrampolineSlowpath. This change is similar to
        r153583 (sh4) and r153648 (ARM).

        * jit/JITStubsMIPS.h:

2013-08-01  Filip Pizlo  <fpizlo@apple.com>

        hasIndexingHeader should be a property of the Structure, not just the IndexingType
        https://bugs.webkit.org/show_bug.cgi?id=119422

        Reviewed by Oliver Hunt.
        
        This simplifies some code and also allows Structure to claim that an object
        has an indexing header even if it doesn't have indexed properties.
        
        I also changed some calls to use hasIndexedProperties() since in some cases,
        that's what we actually meant. Currently the two are synonyms.

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCachePutByID):
        (JSC::DFG::tryBuildPutByIdList):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::create):
        (JSC::Butterfly::growPropertyStorage):
        (JSC::Butterfly::growArrayRight):
        (JSC::Butterfly::resizeArray):
        * runtime/IndexingType.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::copyButterfly):
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::setPrototype):
        * runtime/JSObject.h:
        (JSC::JSObject::setButterfly):
        * runtime/JSPropertyNameIterator.cpp:
        (JSC::JSPropertyNameIterator::create):
        * runtime/Structure.h:
        (JSC::Structure::hasIndexingHeader):

2013-08-02  Julien Brianceau  <jbrianceau@nds.com>

        REGRESSION: ARM still crashes after change set r153612.
        https://bugs.webkit.org/show_bug.cgi?id=119433

        Reviewed by Michael Saboff.

        Update call frame and do not restore registers from JIT stack frame in ARM and ARMv7
        implementations of ctiVMThrowTrampolineSlowpath. This change is similar to r153583
        for sh4 architecture.

        * jit/JITStubsARM.h:
        * jit/JITStubsARMv7.h:

2013-08-02  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r153612): It made jsc and layout tests crash
        https://bugs.webkit.org/show_bug.cgi?id=119440

        Reviewed by Csaba Osztrogonác.

        Made the changes if changeset r153612 only apply to 32 bit builds.

        * jit/JITExceptions.cpp:
        * jit/JITExceptions.h:
        * jit/JITStubs.cpp:
        (JSC::cti_vm_throw_slowpath):
        * jit/JITStubs.h:

2013-08-02  Patrick Gansterer  <paroga@webkit.org>

        Add JSCTestRunnerUtils to the list of forwarding headers to fix build.

        * CMakeLists.txt:

2013-08-01  Ruth Fong  <ruth_fong@apple.com>

        [Forms: color] <input type='color'> popover color well implementation
        <rdar://problem/14411008> and https://bugs.webkit.org/show_bug.cgi?id=119356

        Reviewed by Benjamin Poulain.

        * Configurations/FeatureDefines.xcconfig: Added and enabled INPUT_TYPE_COLOR_POPOVER.

2013-08-01  Oliver Hunt  <oliver@apple.com>

        DFG is not enforcing correct ordering of ToString conversion in MakeRope
        https://bugs.webkit.org/show_bug.cgi?id=119408

        Reviewed by Filip Pizlo.

        Construct ToString and Phantom nodes in advance of MakeRope
        nodes to ensure that ordering is ensured, and correct values
        will be reified on OSR exit.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

2013-08-01  Michael Saboff  <msaboff@apple.com>

        REGRESSION: Crash beneath cti_vm_throw_slowpath due to invalid CallFrame pointer
        https://bugs.webkit.org/show_bug.cgi?id=119140

        Reviewed by Filip Pizlo.

        Ensure that ExceptionHandler is returned by functions in two registers by encoding the value as a 64 bit int.

        * jit/JITExceptions.cpp:
        (JSC::encode):
        * jit/JITExceptions.h:
        * jit/JITStubs.cpp:
        (JSC::cti_vm_throw_slowpath):
        * jit/JITStubs.h:

2013-08-01  Julien Brianceau  <jbrianceau@nds.com>

        REGRESSION(FTL): Fix sh4 implementation of ctiVMThrowTrampolineSlowpath.
        https://bugs.webkit.org/show_bug.cgi?id=119391

        Reviewed by Csaba Osztrogonác.

        * jit/JITStubsSH4.h: Fix ctiVMThrowTrampolineSlowpath implementation:
            - Call frame is in r14 register.
            - Do not restore registers from JIT stack frame here.

2013-07-31  Gavin Barraclough  <barraclough@apple.com>

        More cleanup in PropertySlot
        https://bugs.webkit.org/show_bug.cgi?id=119359

        Reviewed by Geoff Garen.

        m_slotBase is overloaded to store the (receiver) thisValue and the object that contains the property,
        This is confusing, and means that slotBase cannot be typed correctly (can only be a JSObject).

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
            - No need to ASSERT slotBase is an object.
        * jit/JITStubs.cpp:
        (JSC::tryCacheGetByID):
        (JSC::DEFINE_STUB_FUNCTION):
            - No need to ASSERT slotBase is an object.
        * runtime/JSObject.cpp:
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::fillGetterPropertySlot):
            - Pass an object through to setGetterSlot.
        * runtime/JSObject.h:
        (JSC::PropertySlot::getValue):
            - Moved from PropertySlot (need to know anout JSObject).
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::functionGetter):
            - update per member name changes
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::PropertySlot):
            - Argument to constructor set to 'thisValue'.
        (JSC::PropertySlot::slotBase):
            - This returns a JSObject*.
        (JSC::PropertySlot::setValue):
        (JSC::PropertySlot::setCustom):
        (JSC::PropertySlot::setCacheableCustom):
        (JSC::PropertySlot::setCustomIndex):
        (JSC::PropertySlot::setGetterSlot):
        (JSC::PropertySlot::setCacheableGetterSlot):
            - slotBase is a JSObject*, make setGetterSlot set slotBase for consistency.
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayEntry::get):
            - Pass an object through to setGetterSlot.
        * runtime/SparseArrayValueMap.h:
            - Pass an object through to setGetterSlot.

2013-07-31  Yi Shen  <max.hong.shen@gmail.com>

        Reduce JSC API static value setter/getter overhead.
        https://bugs.webkit.org/show_bug.cgi?id=119277

        Reviewed by Geoffrey Garen.

        Add property name to the static value entry, so that OpaqueJSString::create() doesn't
        need to get called every time when set or get the static value.

        * API/JSCallbackObjectFunctions.h:
        (JSC::::put):
        (JSC::::putByIndex):
        (JSC::::getStaticValue):
        * API/JSClassRef.cpp:
        (OpaqueJSClassContextData::OpaqueJSClassContextData):
        * API/JSClassRef.h:
        (StaticValueEntry::StaticValueEntry):

2013-07-31  Kwang Yul Seo  <skyul@company100.net>

        Use emptyString instead of String("")
        https://bugs.webkit.org/show_bug.cgi?id=119335

        Reviewed by Darin Adler.

        Use emptyString() instead of String("") because it is better style and
        faster. This is a followup to r116908, removing all occurrences of
        String("") from WebKit.

        * runtime/RegExpConstructor.cpp:
        (JSC::constructRegExp):
        * runtime/RegExpPrototype.cpp:
        (JSC::regExpProtoFuncCompile):
        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncMatch):
        (JSC::stringProtoFuncSearch):

2013-07-31  Ruth Fong  <ruth_fong@apple.com>

        <input type=color> Mac UI behaviour
        <rdar://problem/10269922> and https://bugs.webkit.org/show_bug.cgi?id=61276

        Reviewed by Brady Eidson.

        * Configurations/FeatureDefines.xcconfig: Enabled INPUT_TYPE_COLOR.

2013-07-31  Mark Hahnenberg  <mhahnenberg@apple.com>

        DFG doesn't account for inlining of functions with switch statements that haven't been executed by the baseline JIT
        https://bugs.webkit.org/show_bug.cgi?id=119349

        Reviewed by Geoffrey Garen.

        Prior to this patch, the baseline JIT was responsible for resizing the ctiOffsets Vector for 
        SimpleJumpTables to be equal to the size of the branchOffsets Vector. The DFG implicitly relied
        on code it compiled with any switch statements to have been run in the baseline JIT first. 
        However, if the DFG chooses to inline a function that has never been compiled by the baseline 
        JIT then this resizing never happens and we crash at link time in the DFG.

        We can fix this by also doing the resize in the DFG to catch this case.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):

2013-07-31  Gavin Barraclough  <barraclough@apple.com>

        Speculative Windows build fix.

        Reviewed by NOBODY

        * runtime/JSString.cpp:
        (JSC::JSRopeString::getIndexSlowCase):
        * runtime/JSString.h:

2013-07-30  Gavin Barraclough  <barraclough@apple.com>

        Some cleanup in JSValue::get
        https://bugs.webkit.org/show_bug.cgi?id=119343

        Reviewed by Geoff Garen.

        JSValue::get is implemented to:
            1) Check if the value is a cell – if not, synthesize a prototype to search,
            2) call getOwnPropertySlot on the cell,
            3) if this returns false, cast to JSObject to get the prototype, and walk the prototype chain.
        By all rights this should crash when passed a string and accessing a property that does not exist, because
        the string is a cell, getOwnPropertySlot should return false, and the cast to JSObject should be unsafe.
        To work around this, JSString::getOwnPropertySlot actually implements 'get' functionality - searching the
        prototype chain, and faking out a return value of undefined if no property is found.

        This is a huge hazard, since fixing JSString::getOwnPropertySlot or calling getOwnPropertySlot on cells
        from elsewhere would introduce bugs. Fortunately it is only ever called in this one place.

        The fix here is to move getOwnPropertySlot onto JSObjecte and end this madness - cells don't have property
        slots anyway.

        Interesting changes are in JSCJSValueInlines.h, JSString.cpp - the rest is pretty much all JSCell -> JSObject.

2013-07-31  Michael Saboff  <msaboff@apple.com>

        [Win] JavaScript crash.
        https://bugs.webkit.org/show_bug.cgi?id=119339

        Reviewed by Mark Hahnenberg.

        * jit/JITStubsX86.h: Implement ctiVMThrowTrampoline and
        ctiVMThrowTrampolineSlowpath the same way as the gcc x86 version does.

2013-07-30  Mark Hahnenberg  <mhahnenberg@apple.com>

        GetByVal on Arguments does the wrong size load when checking the Arguments object length
        https://bugs.webkit.org/show_bug.cgi?id=119281

        Reviewed by Geoffrey Garen.

        This leads to out of bounds accesses and subsequent crashes.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2013-07-30  Oliver Hunt  <oliver@apple.com>

        Add an assertion to SpeculateCellOperand
        https://bugs.webkit.org/show_bug.cgi?id=119276

        Reviewed by Michael Saboff.

        More assertions are better

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::compile):

2013-07-30  Mark Lam  <mark.lam@apple.com>

        Fix problems with divot and lineStart mismatches.
        https://bugs.webkit.org/show_bug.cgi?id=118662.

        Reviewed by Oliver Hunt.

        r152494 added the recording of lineStart values for divot positions.
        This is needed for the computation of column numbers. Similarly, it also
        added the recording of line numbers for the divot positions. One problem
        with the approach taken was that the line and lineStart values were
        recorded independently, and hence were not always guaranteed to be
        sampled at the same place that the divot position is recorded. This
        resulted in potential mismatches that cause some assertions to fail.

        The solution is to introduce a JSTextPosition abstraction that records
        the divot position, line, and lineStart as a single quantity. Wherever
        we record the divot position as an unsigned int previously, we now record
        its JSTextPosition which captures all 3 values in one go. This ensures
        that the captured line and lineStart will always match the captured divot
        position.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallEval):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitConstruct):
        (JSC::BytecodeGenerator::emitDebugHook):
        - Use JSTextPosition instead of passing line and lineStart explicitly.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitExpressionInfo):
        - Use JSTextPosition instead of passing line and lineStart explicitly.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThrowableExpressionData::emitThrowReferenceError):
        (JSC::ResolveNode::emitBytecode):
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::DotAccessorNode::emitBytecode):
        (JSC::NewExprNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::FunctionCallBracketNode::emitBytecode):
        (JSC::FunctionCallDotNode::emitBytecode):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::PostfixNode::emitBracket):
        (JSC::PostfixNode::emitDot):
        (JSC::DeleteResolveNode::emitBytecode):
        (JSC::DeleteBracketNode::emitBytecode):
        (JSC::DeleteDotNode::emitBytecode):
        (JSC::PrefixNode::emitResolve):
        (JSC::PrefixNode::emitBracket):
        (JSC::PrefixNode::emitDot):
        (JSC::UnaryOpNode::emitBytecode):
        (JSC::BinaryOpNode::emitStrcat):
        (JSC::BinaryOpNode::emitBytecode):
        (JSC::ThrowableBinaryOpNode::emitBytecode):
        (JSC::InstanceOfNode::emitBytecode):
        (JSC::emitReadModifyAssignment):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::AssignDotNode::emitBytecode):
        (JSC::ReadModifyDotNode::emitBytecode):
        (JSC::AssignBracketNode::emitBytecode):
        (JSC::ReadModifyBracketNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        (JSC::WithNode::emitBytecode):
        (JSC::ThrowNode::emitBytecode):
        - Use JSTextPosition instead of passing line and lineStart explicitly.
        * parser/ASTBuilder.h:
        - Replaced ASTBuilder::PositionInfo with JSTextPosition.
        (JSC::ASTBuilder::BinaryOpInfo::BinaryOpInfo):
        (JSC::ASTBuilder::AssignmentInfo::AssignmentInfo):
        (JSC::ASTBuilder::createResolve):
        (JSC::ASTBuilder::createBracketAccess):
        (JSC::ASTBuilder::createDotAccess):
        (JSC::ASTBuilder::createRegExp):
        (JSC::ASTBuilder::createNewExpr):
        (JSC::ASTBuilder::createAssignResolve):
        (JSC::ASTBuilder::createExprStatement):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::createReturnStatement):
        (JSC::ASTBuilder::createBreakStatement):
        (JSC::ASTBuilder::createContinueStatement):
        (JSC::ASTBuilder::createLabelStatement):
        (JSC::ASTBuilder::createWithStatement):
        (JSC::ASTBuilder::createThrowStatement):
        (JSC::ASTBuilder::appendBinaryExpressionInfo):
        (JSC::ASTBuilder::appendUnaryToken):
        (JSC::ASTBuilder::unaryTokenStackLastStart):
        (JSC::ASTBuilder::assignmentStackAppend):
        (JSC::ASTBuilder::createAssignment):
        (JSC::ASTBuilder::setExceptionLocation):
        (JSC::ASTBuilder::makeDeleteNode):
        (JSC::ASTBuilder::makeFunctionCallNode):
        (JSC::ASTBuilder::makeBinaryNode):
        (JSC::ASTBuilder::makeAssignNode):
        (JSC::ASTBuilder::makePrefixNode):
        (JSC::ASTBuilder::makePostfixNode):
        - Use JSTextPosition instead of passing line and lineStart explicitly.
        * parser/Lexer.cpp:
        (JSC::::lex):
        - Added support for capturing the appropriate JSTextPositions instead
          of just the character offset.
        * parser/Lexer.h:
        (JSC::Lexer::currentPosition):
        (JSC::::lexExpectIdentifier):
        - Added support for capturing the appropriate JSTextPositions instead
          of just the character offset.
        * parser/NodeConstructors.h:
        (JSC::Node::Node):
        (JSC::ResolveNode::ResolveNode):
        (JSC::EvalFunctionCallNode::EvalFunctionCallNode):
        (JSC::FunctionCallValueNode::FunctionCallValueNode):
        (JSC::FunctionCallResolveNode::FunctionCallResolveNode):
        (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
        (JSC::FunctionCallDotNode::FunctionCallDotNode):
        (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
        (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
        (JSC::PostfixNode::PostfixNode):
        (JSC::DeleteResolveNode::DeleteResolveNode):
        (JSC::DeleteBracketNode::DeleteBracketNode):
        (JSC::DeleteDotNode::DeleteDotNode):
        (JSC::PrefixNode::PrefixNode):
        (JSC::ReadModifyResolveNode::ReadModifyResolveNode):
        (JSC::ReadModifyBracketNode::ReadModifyBracketNode):
        (JSC::AssignBracketNode::AssignBracketNode):
        (JSC::AssignDotNode::AssignDotNode):
        (JSC::ReadModifyDotNode::ReadModifyDotNode):
        (JSC::AssignErrorNode::AssignErrorNode):
        (JSC::WithNode::WithNode):
        (JSC::ForInNode::ForInNode):
        - Use JSTextPosition instead of passing line and lineStart explicitly.
        * parser/Nodes.cpp:
        (JSC::StatementNode::setLoc):
        - Use JSTextPosition instead of passing line and lineStart explicitly.
        * parser/Nodes.h:
        (JSC::Node::lineNo):
        (JSC::Node::startOffset):
        (JSC::Node::lineStartOffset):
        (JSC::Node::position):
        (JSC::ThrowableExpressionData::ThrowableExpressionData):
        (JSC::ThrowableExpressionData::setExceptionSourceCode):
        (JSC::ThrowableExpressionData::divot):
        (JSC::ThrowableExpressionData::divotStart):
        (JSC::ThrowableExpressionData::divotEnd):
        (JSC::ThrowableSubExpressionData::ThrowableSubExpressionData):
        (JSC::ThrowableSubExpressionData::setSubexpressionInfo):
        (JSC::ThrowableSubExpressionData::subexpressionDivot):
        (JSC::ThrowableSubExpressionData::subexpressionStart):
        (JSC::ThrowableSubExpressionData::subexpressionEnd):
        (JSC::ThrowablePrefixedSubExpressionData::ThrowablePrefixedSubExpressionData):
        (JSC::ThrowablePrefixedSubExpressionData::setSubexpressionInfo):
        (JSC::ThrowablePrefixedSubExpressionData::subexpressionDivot):
        (JSC::ThrowablePrefixedSubExpressionData::subexpressionStart):
        (JSC::ThrowablePrefixedSubExpressionData::subexpressionEnd):
        - Use JSTextPosition instead of passing line and lineStart explicitly.
        * parser/Parser.cpp:
        (JSC::::Parser):
        (JSC::::parseInner):
        - Use JSTextPosition instead of passing line and lineStart explicitly.
        (JSC::::didFinishParsing):
        - Remove setting of m_lastLine value. We always pass in the value from
          m_lastLine anyway. So, this assignment is effectively a nop.
        (JSC::::parseVarDeclaration):
        (JSC::::parseVarDeclarationList):
        (JSC::::parseForStatement):
        (JSC::::parseBreakStatement):
        (JSC::::parseContinueStatement):
        (JSC::::parseReturnStatement):
        (JSC::::parseThrowStatement):
        (JSC::::parseWithStatement):
        (JSC::::parseTryStatement):
        (JSC::::parseBlockStatement):
        (JSC::::parseFunctionDeclaration):
        (JSC::LabelInfo::LabelInfo):
        (JSC::::parseExpressionOrLabelStatement):
        (JSC::::parseExpressionStatement):
        (JSC::::parseAssignmentExpression):
        (JSC::::parseBinaryExpression):
        (JSC::::parseProperty):
        (JSC::::parsePrimaryExpression):
        (JSC::::parseMemberExpression):
        (JSC::::parseUnaryExpression):
        - Use JSTextPosition instead of passing line and lineStart explicitly.
        * parser/Parser.h:
        (JSC::Parser::next):
        (JSC::Parser::nextExpectIdentifier):
        (JSC::Parser::getToken):
        (JSC::Parser::tokenStartPosition):
        (JSC::Parser::tokenEndPosition):
        (JSC::Parser::lastTokenEndPosition):
        (JSC::::parse):
        - Use JSTextPosition instead of passing line and lineStart explicitly.
        * parser/ParserTokens.h:
        (JSC::JSTextPosition::JSTextPosition):
        (JSC::JSTextPosition::operator+):
        (JSC::JSTextPosition::operator-):
        (JSC::JSTextPosition::operator int):
        - Added JSTextPosition.
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::makeFunctionCallNode):
        (JSC::SyntaxChecker::makeAssignNode):
        (JSC::SyntaxChecker::makePrefixNode):
        (JSC::SyntaxChecker::makePostfixNode):
        (JSC::SyntaxChecker::makeDeleteNode):
        (JSC::SyntaxChecker::createResolve):
        (JSC::SyntaxChecker::createBracketAccess):
        (JSC::SyntaxChecker::createDotAccess):
        (JSC::SyntaxChecker::createRegExp):
        (JSC::SyntaxChecker::createNewExpr):
        (JSC::SyntaxChecker::createAssignResolve):
        (JSC::SyntaxChecker::createForInLoop):
        (JSC::SyntaxChecker::createReturnStatement):
        (JSC::SyntaxChecker::createBreakStatement):
        (JSC::SyntaxChecker::createContinueStatement):
        (JSC::SyntaxChecker::createWithStatement):
        (JSC::SyntaxChecker::createLabelStatement):
        (JSC::SyntaxChecker::createThrowStatement):
        (JSC::SyntaxChecker::appendBinaryExpressionInfo):
        (JSC::SyntaxChecker::operatorStackPop):
        - Use JSTextPosition instead of passing line and lineStart explicitly.

2013-07-29  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix make distcheck.

        * GNUmakefile.list.am: Add missing files to compilation.
        * bytecode/CodeBlock.cpp: Add a ENABLE(FTL_JIT) #if block to
        include FTL header files not included in the compilation.
        * dfg/DFGDriver.cpp: Ditto.
        * dfg/DFGPlan.cpp: Ditto.

2013-07-29  Chris Curtis  <chris_curtis@apple.com>

        Eager stack trace for error objects.
        https://bugs.webkit.org/show_bug.cgi?id=118918

        Reviewed by Geoffrey Garen.
        
        Chrome and Firefox give error objects the stack property and we wanted to match
        that functionality. This allows developers to see the stack without throwing an object.

        * runtime/ErrorInstance.cpp:
        (JSC::ErrorInstance::finishCreation):
         For error objects that are not thrown as an exception, we pass the stackTrace in 
         as a parameter. This allows the error object to have the stack property.
        
        * interpreter/Interpreter.cpp:
        (JSC::stackTraceAsString):
        Helper function used to eliminate duplicate code.

        (JSC::Interpreter::addStackTraceIfNecessary):
        When an error object is created by the user the vm->exceptionStack is not set.
        If the user throws this error object later the stack that is in the error object 
        may not be the correct stack for the throw, so when we set the vm->exception stack,
        the stack property on the error object is set as well.
        
        * runtime/ErrorConstructor.cpp:
        (JSC::constructWithErrorConstructor):
        (JSC::callErrorConstructor):
        * runtime/NativeErrorConstructor.cpp:
        (JSC::constructWithNativeErrorConstructor):
        (JSC::callNativeErrorConstructor):
        These functions indicate that the user created an error object. For all error objects 
        that the user explicitly creates, the topCallFrame is at a new frame created to 
        handle the user's call. In this case though, the error object needs the caller's 
        frame to create the stack trace correctly.
        
        * interpreter/Interpreter.h:
        * runtime/ErrorInstance.h:
        (JSC::ErrorInstance::create):

2013-07-29  Gavin Barraclough  <barraclough@apple.com>

        Some cleanup in PropertySlot
        https://bugs.webkit.org/show_bug.cgi?id=119189

        Reviewed by Geoff Garen.

        PropertySlot represents a property in one of four states - value, getter, custom, or custom-index.
        The state is currently tracked redundantly by two mechanisms - the custom getter function (m_getValue)
        is set to a special value to indicate the type (other than custom), and the type is also tracked by
        an enum - but only if cacheable. Cacheability can typically be determined by the value of m_offset
        (this is invalidOffset if not cacheable).

            * Internally, always track the type of the property using an enum value, PropertyType.
            * Use m_offset to indicate cacheable.
            * Keep the external interface (CachedPropertyType) unchanged.
            * Better pack data into the m_data union.

        Performance neutral.

        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
            - cachedPropertyType() -> isCacheable*()
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompileGetByIdProto):
        (JSC::JIT::privateCompileGetByIdSelfList):
        (JSC::JIT::privateCompileGetByIdProtoList):
        (JSC::JIT::privateCompileGetByIdChainList):
        (JSC::JIT::privateCompileGetByIdChain):
            - cachedPropertyType() -> isCacheable*()
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::privateCompileGetByIdProto):
        (JSC::JIT::privateCompileGetByIdSelfList):
        (JSC::JIT::privateCompileGetByIdProtoList):
        (JSC::JIT::privateCompileGetByIdChainList):
        (JSC::JIT::privateCompileGetByIdChain):
            - cachedPropertyType() -> isCacheable*()
        * jit/JITStubs.cpp:
        (JSC::tryCacheGetByID):
            - cachedPropertyType() -> isCacheable*()
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
            - cachedPropertyType() -> isCacheable*()
        * runtime/PropertySlot.cpp:
        (JSC::PropertySlot::functionGetter):
            - refactoring described above.
        * runtime/PropertySlot.h:
        (JSC::PropertySlot::PropertySlot):
        (JSC::PropertySlot::getValue):
        (JSC::PropertySlot::isCacheable):
        (JSC::PropertySlot::isCacheableValue):
        (JSC::PropertySlot::isCacheableGetter):
        (JSC::PropertySlot::isCacheableCustom):
        (JSC::PropertySlot::cachedOffset):
        (JSC::PropertySlot::customGetter):
        (JSC::PropertySlot::setValue):
        (JSC::PropertySlot::setCustom):
        (JSC::PropertySlot::setCacheableCustom):
        (JSC::PropertySlot::setCustomIndex):
        (JSC::PropertySlot::setGetterSlot):
        (JSC::PropertySlot::setCacheableGetterSlot):
        (JSC::PropertySlot::setUndefined):
        (JSC::PropertySlot::slotBase):
        (JSC::PropertySlot::setBase):
            - refactoring described above.

2013-07-28  Oliver Hunt  <oliver@apple.com>

        REGRESSION: Crash when opening Facebook.com
        https://bugs.webkit.org/show_bug.cgi?id=119155

        Reviewed by Andreas Kling.

        Scope nodes are always objects, so we should be using SpecObjectOther
        rather than SpecCellOther.  Marking Scopes as CellOther leads to a
        contradiction in the CFA, resulting in bogus codegen.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):

2013-07-26  Oliver Hunt  <oliver@apple.com>

        REGRESSION(FTL?): Crashes in plugin tests
        https://bugs.webkit.org/show_bug.cgi?id=119141

        Reviewed by Michael Saboff.

        Re-export getStackTrace

        * interpreter/Interpreter.h:

2013-07-26  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION: Crash when opening a message on Gmail
        https://bugs.webkit.org/show_bug.cgi?id=119105

        Reviewed by Oliver Hunt and Mark Hahnenberg.
        
        - GetById patching in the DFG needs to be more disciplined about how it derives the
          slow path.
        
        - Fix some dumping code thread safety issues.

        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::dump):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::getPolymorphicStructureList):
        (JSC::DFG::tryBuildGetByIDList):

2013-07-26  Balazs Kilvady  <kilvadyb@homejinni.com>

        [mips] Fix LLINT build for mips backend
        https://bugs.webkit.org/show_bug.cgi?id=119152

        Reviewed by Oliver Hunt.

        * offlineasm/mips.rb:

2013-07-19  Mark Hahnenberg  <mhahnenberg@apple.com>

        Setting a large numeric property on an object causes it to allocate a huge backing store
        https://bugs.webkit.org/show_bug.cgi?id=118914

        Reviewed by Geoffrey Garen.

        There are two distinct actions that we're trying to optimize for:

        new Array(100000);

        and:

        a = [];
        a[100000] = 42;
        
        In the first case, the programmer has indicated that they expect this Array to be very big, 
        so they should get a contiguous array up until some threshold, above which we perform density 
        calculations to see if it is indeed dense enough to warrant being contiguous.
        
        In the second case, the programmer hasn't indicated anything about the size of the Array, so 
        we should be more conservative and assume it should be sparse until we've proven otherwise.
        
        Currently both of those cases are handled by MIN_SPARSE_ARRAY_INDEX. We should distinguish 
        between them for the purposes of not over-allocating large backing stores like we see on 
        http://www.peekanalytics.com/burgerjoints/
        
        The way that we'll do this is to keep the MIN_SPARSE_ARRAY_INDEX for the first case, and 
        introduce a new heuristic for the second case. If we are putting to an index above a certain 
        threshold (say, 1000) and it is beyond the length of the array, then we will use a sparse 
        map instead. So for example, in the second case above the empty array has a blank indexing 
        type and a length of 0. We put-by-val to an index > 1000 and > a.length, so we'll use a sparse map.

        This fix is ~800x speedup on the accompanying regression test :-o

        * runtime/ArrayConventions.h:
        (JSC::indexIsSufficientlyBeyondLengthForSparseMap):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):

2013-07-26  Julien Brianceau  <jbrianceau@nds.com>

        REGRESSION(FTL): Fix lots of crashes in sh4 baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=119148

        Reviewed by Csaba Osztrogonác.

        * jit/JSInterfaceJIT.h: "secondArgumentRegister" is wrong for sh4.
        * llint/LowLevelInterpreter32_64.asm: "move t0, a0" is missing
        in nativeCallTrampoline for sh4. Reuse MIPS implementation to avoid
        code duplication.

2013-07-26  Julien Brianceau  <jbrianceau@nds.com>

        REGRESSION(FTL): Crash in sh4 baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=119138

        Reviewed by Csaba Osztrogonác.

        This crash is due to incomplete report of r150146 and r148474.

        * jit/JITStubsSH4.h:

2013-07-26  Zan Dobersek  <zdobersek@igalia.com>

        Unreviewed.

        * Target.pri: Adding missing DFG files to the Qt build.

2013-07-25  Csaba Osztrogonác  <ossy@webkit.org>

        GTK and Qt buildfix after the intrusive win buildfix r153360.

        * GNUmakefile.list.am:
        * Target.pri:

2013-07-25  Gyuyoung Kim  <gyuyoung.kim@samsung.com>

        Unreviewed, fix build break after r153360.

        * CMakeLists.txt: Add CommonSlowPathsExceptions.cpp.

2013-07-25  Roger Fong  <roger_fong@apple.com>

        Unreviewed build fix, AppleWin port.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.vcxproj/copy-files.cmd:

2013-07-25  Roger Fong  <roger_fong@apple.com>

        Unreviewed. Followup to r153360.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2013-07-25  Michael Saboff  <msaboff@apple.com>

        [Windows] Speculative build fix.

        Moved interpreterThrowInCaller() out of LLintExceptions.cpp into new CommonSlowPathsExceptions.cpp
        that is always compiled.  Made LLInt::returnToThrow() conditional on LLINT being enabled.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * llint/LLIntExceptions.cpp:
        * llint/LLIntExceptions.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPathsExceptions.cpp: Added.
        (JSC::CommonSlowPaths::interpreterThrowInCaller):
        * runtime/CommonSlowPathsExceptions.h: Added.

2013-07-25  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed build fix.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add missing IntendedStructureChange.h,.cpp and
        parser/SourceCode.h,.cpp.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.

2013-07-25  Anders Carlsson  <andersca@apple.com>

        ASSERT(m_vm->apiLock().currentThreadIsHoldingLock()); fails for Safari on current ToT
        https://bugs.webkit.org/show_bug.cgi?id=119108

        Reviewed by Mark Hahnenberg.

        Add a currentThreadIsHoldingAPILock() function to VM that checks if the current thread is the exclusive API thread.

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::tryAllocateSlowCase):
        * heap/Heap.cpp:
        (JSC::Heap::protect):
        (JSC::Heap::unprotect):
        (JSC::Heap::collect):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateSlowCase):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/VM.h:
        (JSC::VM::currentThreadIsHoldingAPILock):

2013-07-25  Zan Dobersek  <zdobersek@igalia.com>

        REGRESSION(FTL): Most layout tests crashes
        https://bugs.webkit.org/show_bug.cgi?id=119089

        Reviewed by Oliver Hunt.

        * runtime/ExecutionHarness.h:
        (JSC::prepareForExecution): Move prepareForExecutionImpl call into its own statement. This prevents the GCC-compiled
        code to create the PassOwnPtr<JSC::JITCode> (intended as a parameter to the installOptimizedCode call) from the jitCode
        RefPtr<JSC::JITCode> parameter before the latter was actually given a proper value through the prepareForExecutionImpl call.
        Currently it's created beforehand and therefor holds a null pointer before it's anchored as the JIT code in
        JSC::CodeBlock::setJITCode, which later indirectly causes assertions in JSC::CodeBlock::jitCompile.
        (JSC::prepareFunctionForExecution): Ditto for prepareFunctionForExecutionImpl.

2013-07-25  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed build fix.

        * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Add missing 'ftl'
        include path.

2013-07-25  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed build fix.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add some missing files:
        runtime/VM.h,.cpp; Remove deleted JSGlobalData.h,.cpp.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.

2013-07-25  Oliver Hunt  <oliver@apple.com>

        Make all jit & non-jit combos build cleanly
        https://bugs.webkit.org/show_bug.cgi?id=119102

        Reviewed by Anders Carlsson.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::counterValueForOptimizeSoon):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::optimizeAfterWarmUp):
        (JSC::CodeBlock::numberOfDFGCompiles):

2013-07-25  Oliver Hunt  <oliver@apple.com>

        32 bit portion of load validation logic
        https://bugs.webkit.org/show_bug.cgi?id=118878

        Reviewed by NOBODY (Build fix).

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2013-07-25  Oliver Hunt  <oliver@apple.com>

        More 32bit build fixes

        - Apparnetly some compilers don't track the fastcall directive everywhere we expect

        * API/APICallbackFunction.h:
        (JSC::APICallbackFunction::call):
        * bytecode/CodeBlock.cpp:
        * runtime/Structure.cpp:

2013-07-25  Yi Shen  <max.hong.shen@gmail.com>

        Optimize the thread locks for API Shims
        https://bugs.webkit.org/show_bug.cgi?id=118573

        Reviewed by Geoffrey Garen.

        Remove the thread lock from API Shims if the VM has an exclusive thread (e.g. the VM 
        only used by WebCore's main thread).

        * API/APIShims.h:
        (JSC::APIEntryShim::APIEntryShim):
        (JSC::APICallbackShim::APICallbackShim):
        * runtime/JSLock.cpp:
        (JSC::JSLockHolder::JSLockHolder):
        (JSC::JSLockHolder::init):
        (JSC::JSLockHolder::~JSLockHolder):
        (JSC::JSLock::DropAllLocks::DropAllLocks):
        (JSC::JSLock::DropAllLocks::~DropAllLocks):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2013-07-25  Christophe Dumez  <ch.dumez@sisa.samsung.com>

        Unreviewed build fix after r153218.

        Broke the EFL port build with gcc 4.7.

        * interpreter/StackIterator.cpp:
        (JSC::printif):

2013-07-25  Julien Brianceau  <jbrianceau@nds.com>

        Build fix: add missing #include.
        https://bugs.webkit.org/show_bug.cgi?id=119087

        Reviewed by Allan Sandfeld Jensen.

        * bytecode/ArrayProfile.cpp:

2013-07-25  Ryuan Choi  <ryuan.choi@samsung.com>

        Unreviewed, build fix on the EFL port.

        * CMakeLists.txt: Added JSCTestRunnerUtils.cpp.

2013-07-25  Julien Brianceau  <jbrianceau@nds.com>

        [sh4] Add missing store8(TrustedImm32, void*) implementation in baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=119083

        Reviewed by Allan Sandfeld Jensen.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::store8):

2013-07-25  Allan Sandfeld Jensen  <allan.jensen@digia.com>

        [Qt] Fix test build after FTL upstream

        Unreviewed build fix.

        * Target.pri:

2013-07-25  Allan Sandfeld Jensen  <allan.jensen@digia.com>

        [Qt] Build fix after FTL.

        Un Reviewed build fix.

        * Target.pri:
        * interpreter/StackIterator.cpp:
        (JSC::StackIterator::Frame::print):

2013-07-25  Gabor Rapcsanyi  <rgabor@webkit.org>

        Unreviewed build fix after FTL upstream.

        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::~Worklist):

2013-07-25  Ryuan Choi  <ryuan.choi@samsung.com>

        Unreviewed, build fix on the EFL port.

        * CMakeLists.txt:
        Added SourceCode.cpp and removed BlackBerry file.
        * jit/JITCode.h:
        (JSC::JITCode::nextTierJIT):
        Fixed to build break because of -Werror=return-type
        * parser/Lexer.cpp: Includes JSFunctionInlines.h
        * runtime/JSScope.h:
        (JSC::makeType):
        Fixed to build break because of -Werror=return-type

2013-07-25  Ádám Kallai  <kadam@inf.u-szeged.hu>

        Unreviewed build fixing after FTL upstream.

        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::produceCodeBlockFor):

2013-07-25  Julien Brianceau  <jbrianceau@nds.com>

        Add missing implementation of bxxxnz in sh4 LLINT.
        https://bugs.webkit.org/show_bug.cgi?id=119079

        Reviewed by Allan Sandfeld Jensen.

        * offlineasm/sh4.rb:

2013-07-25  Gabor Rapcsanyi  <rgabor@webkit.org>

        Unreviewed, build fix on the Qt port.

        * Target.pri: Add additional build files for the FTL.

2013-07-25  Ádám Kallai  <kadam@inf.u-szeged.hu>

        Unreviewed buildfix after FTL upstream..

        * interpreter/StackIterator.cpp:
        (JSC::StackIterator::Frame::codeType):
        (JSC::StackIterator::Frame::functionName):
        (JSC::StackIterator::Frame::sourceURL):
        (JSC::StackIterator::Frame::logicalFrame):

2013-07-25  Zan Dobersek  <zdobersek@igalia.com>

        Unreviewed.

        * heap/CopyVisitor.cpp: Include CopiedSpaceInlines header so the CopiedSpace::recycleEvacuatedBlock
        method is not left undefined, causing build failures on (at least) the GTK port.

2013-07-25  Zan Dobersek  <zdobersek@igalia.com>

        Unreviewed, further build fixing on the GTK port.

        * GNUmakefile.list.am: Add CompilationResult source files to the build.

2013-07-25  Zan Dobersek  <zdobersek@igalia.com>

        Unreviewed GTK build fixing.

        * GNUmakefile.am: Make the shared libjsc library depend on any changes to the build target list.
        * GNUmakefile.list.am: Add additional build targets for files that were introduced by the FTL branch merge.

2013-07-25  Csaba Osztrogonác  <ossy@webkit.org>

        Buildfix after this error:
        error: 'pathName' may be used uninitialized in this function [-Werror=uninitialized]

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):

2013-07-25  Csaba Osztrogonác  <ossy@webkit.org>

        One more buildfix after FTL upstream.

        Return a dummy value after RELEASE_ASSERT_NOT_REACHED() to make GCC happy.

        * dfg/DFGLazyJSValue.cpp:
        (JSC::DFG::LazyJSValue::getValue):
        (JSC::DFG::LazyJSValue::strictEqual):

2013-07-25  Julien Brianceau  <jbrianceau@nds.com>

        Fix "Unhandled opcode localAnnotation" build error in sh4 and mips LLINT.
        https://bugs.webkit.org/show_bug.cgi?id=119076

        Reviewed by Allan Sandfeld Jensen.

        * offlineasm/mips.rb:
        * offlineasm/sh4.rb:

2013-07-25  Zan Dobersek  <zdobersek@igalia.com>

        Unreviewed GTK build fix.

        * GNUmakefile.list.am: Adding JSCTestRunnerUtils files to the build.

2013-07-25  Zan Dobersek  <zdobersek@igalia.com>

        Unreviewed. Further build fixing for the GTK port. Adding the forwarding header
        for JSCTestRunnerUtils.h as required by the DumpRenderTree compilation.

        * ForwardingHeaders/JavaScriptCore/JSCTestRunnerUtils.h: Added.

2013-07-25  Zan Dobersek  <zdobersek@igalia.com>

        Unreviewed. Fixing the GTK build after the FTL merging by updating the build targets list.

        * GNUmakefile.am:
        * GNUmakefile.list.am:

2013-07-25  Ádám Kallai  <kadam@inf.u-szeged.hu>

        Unreviewed buildfix after FTL upstream.

        * runtime/JSScope.h:
        (JSC::needsVarInjectionChecks):

2013-07-25  Csaba Osztrogonác  <ossy@webkit.org>

        One more fix after FTL upstream.

        * Target.pri:
        * bytecode/CodeBlock.h:
        * bytecode/GetByIdStatus.h:
        (JSC::GetByIdStatus::GetByIdStatus):

2013-07-24  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed buildfix after FTL upstream.

        Add ftl directory as include path.

        * CMakeLists.txt:
        * JavaScriptCore.pri:

2013-07-24  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed buildfix after FTL upstream for non C++11 builds.

        * interpreter/CallFrame.h:
        * interpreter/StackIteratorPrivate.h:
        (JSC::StackIterator::end):

2013-07-24  Oliver Hunt  <oliver@apple.com>

        Endeavour to fix CMakelist builds

        * CMakeLists.txt:

2013-07-24  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG IR dumps should be easier to read
        https://bugs.webkit.org/show_bug.cgi?id=119050

        Reviewed by Mark Hahnenberg.
        
        Added a DumpContext that includes support for printing an endnote
        that describes all structures in full, while the main flow of the
        dump just uses made-up names for the structures. This is helpful
        since Structure::dump() may print a lot. The stuff it prints is
        useful, but if it's all inline with the surrounding thing you're        
        dumping (often, a node in the DFG), then you get a ridiculously
        long print-out. All classes that dump structures (including
        Structure itself) now have dumpInContext() methods that use
        inContext() for dumping anything that might transitively print a
        structure. If Structure::dumpInContext() is called with a NULL
        context, it just uses dump() like before. Hence you don't have to
        know anything about DumpContext unless you want to.
        
        inContext(*structure, context) dumps something like %B4:Array,
        and the endnote will have something like:
        
            %B4:Array    = 0x10e91a180:[Array, {Edge:100, Normal:101, Line:102, NumPx:103, LastPx:104}, ArrayWithContiguous, Proto:0x10e99ffe0]
        
        where B4 is the inferred name that StringHashDumpContext came up
        with.
        
        Also shortened a bunch of other dumps, removing information that
        isn't so important.
        
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ArrayProfile.cpp:
        (JSC::dumpArrayModes):
        * bytecode/CodeBlockHash.cpp:
        (JSC):
        (JSC::CodeBlockHash::CodeBlockHash):
        (JSC::CodeBlockHash::dump):
        * bytecode/CodeOrigin.cpp:
        (JSC::CodeOrigin::dumpInContext):
        (JSC):
        (JSC::InlineCallFrame::dumpInContext):
        (JSC::InlineCallFrame::dump):
        * bytecode/CodeOrigin.h:
        (CodeOrigin):
        (InlineCallFrame):
        * bytecode/Operands.h:
        (JSC::OperandValueTraits::isEmptyForDump):
        (Operands):
        (JSC::Operands::dump):
        (JSC):
        * bytecode/OperandsInlines.h: Added.
        (JSC):
        (JSC::::dumpInContext):
        * bytecode/StructureSet.h:
        (JSC::StructureSet::dumpInContext):
        (JSC::StructureSet::dump):
        (StructureSet):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::dump):
        (DFG):
        (JSC::DFG::AbstractValue::dumpInContext):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::operator!):
        (AbstractValue):
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::performBlockCFA):
        * dfg/DFGCommon.cpp:
        * dfg/DFGCommon.h:
        (JSC::DFG::NodePointerTraits::isEmptyForDump):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::createDumpList):
        * dfg/DFGDisassembler.h:
        (Disassembler):
        * dfg/DFGFlushFormat.h:
        (WTF::inContext):
        (WTF):
        * dfg/DFGFlushLivenessAnalysisPhase.cpp:
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dumpCodeOrigin):
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::dumpBlockHeader):
        * dfg/DFGGraph.h:
        (Graph):
        * dfg/DFGLazyJSValue.cpp:
        (JSC::DFG::LazyJSValue::dumpInContext):
        (JSC::DFG::LazyJSValue::dump):
        (DFG):
        * dfg/DFGLazyJSValue.h:
        (LazyJSValue):
        * dfg/DFGNode.h:
        (JSC::DFG::nodeMapDump):
        (WTF::inContext):
        (WTF):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGStructureAbstractValue.h:
        (JSC::DFG::StructureAbstractValue::dumpInContext):
        (JSC::DFG::StructureAbstractValue::dump):
        (StructureAbstractValue):
        * ftl/FTLExitValue.cpp:
        (JSC::FTL::ExitValue::dumpInContext):
        (JSC::FTL::ExitValue::dump):
        (FTL):
        * ftl/FTLExitValue.h:
        (ExitValue):
        * ftl/FTLLowerDFGToLLVM.cpp:
        * ftl/FTLValueSource.cpp:
        (JSC::FTL::ValueSource::dumpInContext):
        (FTL):
        * ftl/FTLValueSource.h:
        (ValueSource):
        * runtime/DumpContext.cpp: Added.
        (JSC):
        (JSC::DumpContext::DumpContext):
        (JSC::DumpContext::~DumpContext):
        (JSC::DumpContext::isEmpty):
        (JSC::DumpContext::dump):
        * runtime/DumpContext.h: Added.
        (JSC):
        (DumpContext):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dump):
        (JSC):
        (JSC::JSValue::dumpInContext):
        * runtime/JSCJSValue.h:
        (JSC):
        (JSValue):
        * runtime/Structure.cpp:
        (JSC::Structure::dumpInContext):
        (JSC):
        (JSC::Structure::dumpBrief):
        (JSC::Structure::dumpContextHeader):
        * runtime/Structure.h:
        (JSC):
        (Structure):

2013-07-22  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should do a high-level LICM before going to FTL
        https://bugs.webkit.org/show_bug.cgi?id=118749

        Reviewed by Oliver Hunt.
        
        Implements LICM hoisting for nodes that never write anything and never read
        things that are clobbered by the loop. There are some other preconditions for
        hoisting, see DFGLICMPhase.cpp.

        Also did a few fixes:
        
        - ClobberSet::add was failing to switch Super entries to Direct entries in
          some cases.
        
        - DFGClobberize.cpp needed to #include "Operations.h".
        
        - DCEPhase needs to process the graph in reverse DFS order, when we're in SSA.
        
        - AbstractInterpreter can now execute a Node without knowing its indexInBlock.
          Knowing the indexInBlock is an optional optimization that all other clients
          of AI still opt into, but LICM doesn't.
        
        This makes the FTL a 2.19x speed-up on imaging-gaussian-blur.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractInterpreter.h:
        (AbstractInterpreter):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        (JSC::DFG::::execute):
        (DFG):
        (JSC::DFG::::clobberWorld):
        (JSC::DFG::::clobberStructures):
        * dfg/DFGAtTailAbstractState.cpp: Added.
        (DFG):
        (JSC::DFG::AtTailAbstractState::AtTailAbstractState):
        (JSC::DFG::AtTailAbstractState::~AtTailAbstractState):
        (JSC::DFG::AtTailAbstractState::createValueForNode):
        (JSC::DFG::AtTailAbstractState::forNode):
        * dfg/DFGAtTailAbstractState.h: Added.
        (DFG):
        (AtTailAbstractState):
        (JSC::DFG::AtTailAbstractState::initializeTo):
        (JSC::DFG::AtTailAbstractState::forNode):
        (JSC::DFG::AtTailAbstractState::variables):
        (JSC::DFG::AtTailAbstractState::block):
        (JSC::DFG::AtTailAbstractState::isValid):
        (JSC::DFG::AtTailAbstractState::setDidClobber):
        (JSC::DFG::AtTailAbstractState::setIsValid):
        (JSC::DFG::AtTailAbstractState::setBranchDirection):
        (JSC::DFG::AtTailAbstractState::setFoundConstants):
        (JSC::DFG::AtTailAbstractState::haveStructures):
        (JSC::DFG::AtTailAbstractState::setHaveStructures):
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::insertBeforeLast):
        * dfg/DFGBasicBlockInlines.h:
        (DFG):
        * dfg/DFGClobberSet.cpp:
        (JSC::DFG::ClobberSet::add):
        (JSC::DFG::ClobberSet::addAll):
        * dfg/DFGClobberize.cpp:
        (JSC::DFG::doesWrites):
        * dfg/DFGClobberize.h:
        (DFG):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::DCEPhase):
        (JSC::DFG::DCEPhase::run):
        (JSC::DFG::DCEPhase::fixupBlock):
        (DCEPhase):
        * dfg/DFGEdgeDominates.h: Added.
        (DFG):
        (EdgeDominates):
        (JSC::DFG::EdgeDominates::EdgeDominates):
        (JSC::DFG::EdgeDominates::operator()):
        (JSC::DFG::EdgeDominates::result):
        (JSC::DFG::edgesDominate):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGLICMPhase.cpp: Added.
        (LICMPhase):
        (JSC::DFG::LICMPhase::LICMPhase):
        (JSC::DFG::LICMPhase::run):
        (JSC::DFG::LICMPhase::attemptHoist):
        (DFG):
        (JSC::DFG::performLICM):
        * dfg/DFGLICMPhase.h: Added.
        (DFG):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):

2013-07-21  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG Nodes should be able to abstractly tell you what they read and what they write
        https://bugs.webkit.org/show_bug.cgi?id=118910

        Reviewed by Sam Weinig.
        
        Add the notion of AbstractHeap to the DFG. This is analogous to the AbstractHeap in
        the FTL, except that the FTL's AbstractHeaps are used during LLVM lowering and are
        engineered to obey LLVM TBAA logic. The FTL's AbstractHeaps are also engineered to
        be inexpensive to use (they just give you a TBAA node) but expensive to create (you
        create them all up front). FTL AbstractHeaps also don't actually give you the
        ability to reason about aliasing; they are *just* a mechanism for lowering to TBAA.
        The DFG's AbstractHeaps are engineered to be both cheap to create and cheap to use.
        They also give you aliasing machinery. The DFG AbstractHeaps are represented
        internally by a int64_t. Many comparisons between them are just integer comaprisons.
        AbstractHeaps form a three-level hierarchy (World is the supertype of everything,
        Kind with a TOP payload is a direct subtype of World, and Kind with a non-TOP
        payload is the direct subtype of its corresponding TOP Kind).
        
        Add the notion of a ClobberSet. This is the set of AbstractHeaps that you had
        clobbered. It represents the set that results from unifying a bunch of
        AbstractHeaps, and is intended to quickly answer overlap questions: does the given
        AbstractHeap overlap any AbstractHeap in the ClobberSet? To this end, if you add an
        AbstractHeap to a set, it "directly" adds the heap itself, and "super" adds all of
        its ancestors. An AbstractHeap is said to overlap a set if any direct or super
        member is equal to it, or if any of its ancestors are equal to a direct member.
        
        Example #1:
        
            - I add Variables(5). I.e. Variables is the Kind and 5 is the payload. This
              is a subtype of Variables, which is a subtype of World.
            - You query Variables. I.e. Variables with a TOP payload, which is the
              supertype of Variables(X) for any X, and a subtype of World.
            
            The set will have Variables(5) as a direct member, and Variables and World as
            super members. The Variables query will immediately return true, because
            Variables is indeed a super member.
        
        Example #2:
        
            - I add Variables(5)
            - You query NamedProperties
            
            NamedProperties is not a member at all (neither direct or super). We next
            query World. World is a member, but it's a super member, so we return false.
        
        Example #3:
        
            - I add Variables
            - You query Variables(5)
            
            The set will have Variables as a direct member, and World as a super member.
            The Variables(5) query will not find Variables(5) in the set, but then it
            will query Variables. Variables is a direct member, so we return true.
        
        Example #4:
        
            - I add Variables
            - You query NamedProperties(5)
            
            Neither NamedProperties nor NamedProperties(5) are members. We next query
            World. World is a member, but it's a super member, so we return false.
        
        Overlap queries require that either the heap being queried is in the set (either
        direct or super), or that one of its ancestors is a direct member. Another way to
        think about how this works is that two heaps A and B are said to overlap if
        A.isSubtypeOf(B) or B.isSubtypeOf(A). This is sound since heaps form a
        single-inheritance heirarchy. Consider that we wanted to implement a set that holds
        heaps and answers the question, "is any member in the set an ancestor (i.e.
        supertype) of some other heap". We would have the set contain the heaps themselves,
        and we would satisfy the query "A.isSubtypeOfAny(set)" by walking the ancestor
        chain of A, and repeatedly querying its membership in the set. This is what the
        "direct" members of our set do. Now consider the other part, where we want to ask if
        any member of the set is a descendent of a heap, or "A.isSupertypeOfAny(set)". We
        would implement this by implementing set.add(B) as adding not just B but also all of
        B's ancestors; then we would answer A.isSupertypeOfAny(set) by just checking if A is
        in the set. With two such sets - one that answers isSubtypeOfAny() and another that
        answers isSupertypeOfAny() - we could answer the "do any of my heaps overlap your
        heap" question. ClobberSet does this, but combines the two sets into a single
        HashMap. The HashMap's value, "direct", means that the key is a member of both the
        supertype set and the subtype set; if it's false then it's only a member of one of
        them.
        
        Finally, this adds a functorized clobberize() method that adds the read and write
        clobbers of a DFG::Node to read and write functors. Common functors for adding to
        ClobberSets, querying overlap, and doing nothing are provided. Convenient wrappers
        are also provided. This allows you to say things like:
        
            ClobberSet set;
            addWrites(graph, node1, set);
            if (readsOverlap(graph, node2, set))
                // We know that node1 may write to something that node2 may read from.
        
        Currently this facility is only used to improve graph dumping, but it will be
        instrumental in both LICM and GVN. In the future, I want to completely kill the
        NodeClobbersWorld and NodeMightClobber flags, and eradicate CSEPhase's hackish way
        of accomplishing almost exactly what AbstractHeap gives you.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractHeap.cpp: Added.
        (DFG):
        (JSC::DFG::AbstractHeap::Payload::dump):
        (JSC::DFG::AbstractHeap::dump):
        (WTF):
        (WTF::printInternal):
        * dfg/DFGAbstractHeap.h: Added.
        (DFG):
        (AbstractHeap):
        (Payload):
        (JSC::DFG::AbstractHeap::Payload::Payload):
        (JSC::DFG::AbstractHeap::Payload::top):
        (JSC::DFG::AbstractHeap::Payload::isTop):
        (JSC::DFG::AbstractHeap::Payload::value):
        (JSC::DFG::AbstractHeap::Payload::valueImpl):
        (JSC::DFG::AbstractHeap::Payload::operator==):
        (JSC::DFG::AbstractHeap::Payload::operator!=):
        (JSC::DFG::AbstractHeap::Payload::operator<):
        (JSC::DFG::AbstractHeap::Payload::isDisjoint):
        (JSC::DFG::AbstractHeap::Payload::overlaps):
        (JSC::DFG::AbstractHeap::AbstractHeap):
        (JSC::DFG::AbstractHeap::operator!):
        (JSC::DFG::AbstractHeap::kind):
        (JSC::DFG::AbstractHeap::payload):
        (JSC::DFG::AbstractHeap::isDisjoint):
        (JSC::DFG::AbstractHeap::overlaps):
        (JSC::DFG::AbstractHeap::supertype):
        (JSC::DFG::AbstractHeap::hash):
        (JSC::DFG::AbstractHeap::operator==):
        (JSC::DFG::AbstractHeap::operator!=):
        (JSC::DFG::AbstractHeap::operator<):
        (JSC::DFG::AbstractHeap::isHashTableDeletedValue):
        (JSC::DFG::AbstractHeap::payloadImpl):
        (JSC::DFG::AbstractHeap::encode):
        (JSC::DFG::AbstractHeapHash::hash):
        (JSC::DFG::AbstractHeapHash::equal):
        (AbstractHeapHash):
        (WTF):
        * dfg/DFGClobberSet.cpp: Added.
        (DFG):
        (JSC::DFG::ClobberSet::ClobberSet):
        (JSC::DFG::ClobberSet::~ClobberSet):
        (JSC::DFG::ClobberSet::add):
        (JSC::DFG::ClobberSet::addAll):
        (JSC::DFG::ClobberSet::contains):
        (JSC::DFG::ClobberSet::overlaps):
        (JSC::DFG::ClobberSet::clear):
        (JSC::DFG::ClobberSet::direct):
        (JSC::DFG::ClobberSet::super):
        (JSC::DFG::ClobberSet::dump):
        (JSC::DFG::ClobberSet::setOf):
        (JSC::DFG::addReads):
        (JSC::DFG::addWrites):
        (JSC::DFG::addReadsAndWrites):
        (JSC::DFG::readsOverlap):
        (JSC::DFG::writesOverlap):
        * dfg/DFGClobberSet.h: Added.
        (DFG):
        (ClobberSet):
        (JSC::DFG::ClobberSet::isEmpty):
        (ClobberSetAdd):
        (JSC::DFG::ClobberSetAdd::ClobberSetAdd):
        (JSC::DFG::ClobberSetAdd::operator()):
        (ClobberSetOverlaps):
        (JSC::DFG::ClobberSetOverlaps::ClobberSetOverlaps):
        (JSC::DFG::ClobberSetOverlaps::operator()):
        (JSC::DFG::ClobberSetOverlaps::result):
        * dfg/DFGClobberize.cpp: Added.
        (DFG):
        (JSC::DFG::didWrites):
        * dfg/DFGClobberize.h: Added.
        (DFG):
        (JSC::DFG::clobberize):
        (NoOpClobberize):
        (JSC::DFG::NoOpClobberize::NoOpClobberize):
        (JSC::DFG::NoOpClobberize::operator()):
        (CheckClobberize):
        (JSC::DFG::CheckClobberize::CheckClobberize):
        (JSC::DFG::CheckClobberize::operator()):
        (JSC::DFG::CheckClobberize::result):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):

2013-07-21  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: It should be easy to figure out which blocks nodes belong to
        https://bugs.webkit.org/show_bug.cgi?id=118957

        Reviewed by Sam Weinig.

        * dfg/DFGGraph.cpp:
        (DFG):
        (JSC::DFG::Graph::initializeNodeOwners):
        * dfg/DFGGraph.h:
        (Graph):
        * dfg/DFGNode.h:

2013-07-21  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: NodeExitsForward shouldn't be duplicated in NodeType
        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):

2013-07-21  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: It should be possible for a DFG::Node to claim to exit to one CodeOrigin, but then claim that it belongs to a different CodeOrigin for all other purposes
        https://bugs.webkit.org/show_bug.cgi?id=118946

        Reviewed by Geoffrey Garen.
        
        We want to decouple the exit target code origin of a node from the code origin
        for all other purposes. The purposes of code origins are:
        
        - Where the node will exit, if it exits. The exit target should be consistent with
          the surrounding nodes, in that if you just looked at the code origins of nodes in
          the graph, they would be consistent with the code origins in bytecode. This is
          necessary for live-at-bytecode analyses to work, and to preserve the original
          bytecode semantics when exiting.
        
        - What kind of code the node came from, for semantics thingies. For example, we
          might use the code origin to find the node's global object for doing an original
          array check. Or we might use it to determine if the code is in strict mode. Or
          other similar things. When we use the code origin in this way, we're basically
          using it as a way of describing the node's meta-data without putting it into the
          node directly, to save space. In the absurd extreme you could imagine nodes not
          even having NodeTypes or NodeFlags, and just using the CodeOrigin to determine
          what bytecode the node originated from. We won't do that, but you can think of
          this use of code origins as just a way of compressing meta-data.
        
        - What code origin we should supply profiling to, if we exit. This is closely
          related to the semantics thingies, in that the exit profiling is a persistent
          kind of semantic meta-data that survives between recompiles, and the only way to
          do that is to ascribe it to the original bytecode via the code origin.
        
        If we hoist a node, we need to change the exit target code origin, but we must not
        change the code origin for other purposes. The best way to do this is to decouple
        the two kinds of code origin.
        
        OSR exit data structures already do this, because they may edit the exit target
        code origin while keeping the code origin for profiling intact. This happens for
        forward exits. So, we just need to thread separation all the way back to DFG::Node.
        That's what this patch does.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::Node):
        (Node):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExitBase.h:
        (JSC::DFG::OSRExitBase::OSRExitBase):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
        (LowerDFGToLLVM):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExit::OSRExit):
        * ftl/FTLOSRExit.h:
        (OSRExit):

2013-07-20  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: each DFG node that relies on other nodes to do their type checks should be able to tell you if those type checks happened
        https://bugs.webkit.org/show_bug.cgi?id=118866

        Reviewed by Sam Weinig.
        
        Adds a safeToExecute() method that takes a node and an abstract state and tells you
        if the node will run without crashing under that state.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * dfg/DFGCFAPhase.cpp:
        (CFAPhase):
        (JSC::DFG::CFAPhase::CFAPhase):
        (JSC::DFG::CFAPhase::run):
        (JSC::DFG::CFAPhase::performBlockCFA):
        (JSC::DFG::CFAPhase::performForwardCFA):
        * dfg/DFGSafeToExecute.h: Added.
        (DFG):
        (SafeToExecuteEdge):
        (JSC::DFG::SafeToExecuteEdge::SafeToExecuteEdge):
        (JSC::DFG::SafeToExecuteEdge::operator()):
        (JSC::DFG::SafeToExecuteEdge::result):
        (JSC::DFG::safeToExecute):
        * dfg/DFGStructureAbstractValue.h:
        (JSC::DFG::StructureAbstractValue::isValidOffset):
        (StructureAbstractValue):
        * runtime/Options.h:
        (JSC):

2013-07-20  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should be able to generate LLVM IR that uses an intrinsic for OSR exit
        https://bugs.webkit.org/show_bug.cgi?id=118948

        Reviewed by Sam Weinig.
        
        - Add the ability to generate LLVM IR but then not use it, via --llvmAlwaysFails=true.
          This allows doing "what if" experiments with IR generation, even if the generated IR
          can't yet execute.
        
        - Add an OSR exit path that just calls an intrinsic that combines the branch and the
          off-ramp.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * ftl/FTLFail.cpp: Added.
        (FTL):
        (JSC::FTL::fail):
        * ftl/FTLFail.h: Added.
        (FTL):
        * ftl/FTLIntrinsicRepository.h:
        (FTL):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
        * runtime/Options.h:
        (JSC):

2013-07-19  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: StringObjectUse uses structures, and CSE should know that
        https://bugs.webkit.org/show_bug.cgi?id=118940

        Reviewed by Geoffrey Garen.
        
        This is asymptomatic right now, but we should fix it.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::putStructureStoreElimination):
        * dfg/DFGEdgeUsesStructure.h: Added.
        (DFG):
        (EdgeUsesStructure):
        (JSC::DFG::EdgeUsesStructure::EdgeUsesStructure):
        (JSC::DFG::EdgeUsesStructure::operator()):
        (JSC::DFG::EdgeUsesStructure::result):
        (JSC::DFG::edgesUseStructure):
        * dfg/DFGUseKind.h:
        (DFG):
        (JSC::DFG::usesStructure):

2013-07-19  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: String GetByVal out-of-bounds handling is so wrong
        https://bugs.webkit.org/show_bug.cgi?id=118935

        Reviewed by Geoffrey Garen.
        
        Bunch of String GetByVal out-of-bounds fixes:
        
        - Even if the string proto chain is sane, we need to watch out for negative
          indices. They may get values or call getters in the prototypes, since proto
          sanity doesn't check for negative indexed properties, as they are not
          technically indexed properties.
        
        - GetByVal String out-of-bounds does in fact clobberWorld(). CSE should be
          given this information.
        
        - GetByVal String out-of-bounds does in fact clobberWorld(). CFA should be
          given this information.
        
        Also fixed some other things:
        
        - If the DFG is disabled, the testRunner should pretend that we've done a
          bunch of DFG compiles. That's necessary to prevent the tests from timing
          out.
        
        - Disassembler shouldn't try to dump source code since it's not safe in the
          concurrent JIT.

        * API/JSCTestRunnerUtils.cpp:
        (JSC::numberOfDFGCompiles):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::dumpHeader):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        * dfg/DFGSaneStringGetByValSlowPathGenerator.h: Added.
        (DFG):
        (SaneStringGetByValSlowPathGenerator):
        (JSC::DFG::SaneStringGetByValSlowPathGenerator::SaneStringGetByValSlowPathGenerator):
        (JSC::DFG::SaneStringGetByValSlowPathGenerator::generateInternal):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):

2013-07-19  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Structure::isValidOffset() should be able to tell you if you're loading a valid JSValue, and not just not crashing
        https://bugs.webkit.org/show_bug.cgi?id=118911

        Reviewed by Geoffrey Garen.
        
        We could also have a separate method like "willNotCrash(offset)", but that's not
        what isValidOffset() is intended to mean.

        * runtime/Structure.h:
        (JSC::Structure::isValidOffset):

2013-07-19  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Structure should be able to tell you if it's valid to load at a given offset from any object with that structure
        https://bugs.webkit.org/show_bug.cgi?id=118878

        Reviewed by Oliver Hunt.
        
        - Change Structure::isValidOffset() to actually answer the question "If I attempted
          to load from an object of this structure, at this offset, would I commit suicide
          or would I get back some kind of value?"
        
        - Change StorageAccessData::offset to use a PropertyOffset. It should have been that
          way from the start.
        
        - Fix PutStructure so that it sets haveStructures in all of the cases that it should.
        
        - Make GetByOffset also reference the base object in addition to the butterfly.
        
        The future use of this power will be to answer questions like "If I hoisted this
        GetByOffset or PutByOffset to this point, would it cause crashes, or would it be
        fine?"
        
        I don't currently plan to use this power to perform validation, since the CSE has
        the power to eliminate CheckStructure's that the CFA wouldn't be smart enough to
        remove - both in the case of StructureSets where size >= 2 and in the case of
        CheckStructures that match across PutStructures. At first I tried to write a
        validator that was aware of this, but the validation code got way too complicated
        and I started having nightmares of spurious assertion bugs being filed against me.
        
        This also changes some of the code for how we hash FunctionExecutable's for debug
        dumps, since that code still had some thread-safety issues. Basically, the
        concurrent JIT needs to use the CodeBlock's precomputed hash and never call anything
        that could transitively try to compute the hash from the source code. The source
        code is a string that may be lazily computed, and that involves all manner of thread
        unsafe things.

        * bytecode/CodeOrigin.cpp:
        (JSC::InlineCallFrame::hash):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (JSC::DFG::ByteCodeParser::handlePutByOffset):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::performBlockCFA):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.h:
        (StorageAccessData):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToGetByOffset):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
        (JSC::FTL::LowerDFGToLLVM::compilePutByOffset):
        * runtime/FunctionExecutableDump.cpp:
        (JSC::FunctionExecutableDump::dump):
        * runtime/Structure.h:
        (Structure):
        (JSC::Structure::isValidOffset):

2013-07-18  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: AbstractInterpreter should explicitly ask AbstractState to create new AbstractValues for newly born nodes
        https://bugs.webkit.org/show_bug.cgi?id=118880

        Reviewed by Sam Weinig.
        
        It should be possible to have an AbstractState that is backed by a HashMap. But to
        do this, the AbstractInterpreter should explicitly ask for new nodes to be added to
        the map, since otherwise the idiom of getting a reference to the AbstractValue
        returned by forNode() would cause really subtle memory corruption bugs.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::::executeEffects):
        * dfg/DFGInPlaceAbstractState.h:
        (JSC::DFG::InPlaceAbstractState::createValueForNode):
        (InPlaceAbstractState):

2013-07-18  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Decouple the way that CFA stores its state from the way it does abstract interpretation
        https://bugs.webkit.org/show_bug.cgi?id=118835

        Reviewed by Oliver Hunt.
        
        This separates AbstractState into two things:
        
        - InPlaceAbstractState, which can tell you the abstract state of anything you
          might care about, and uses the old AbstractState's algorithms and data
          structures for doing so.
        
        - AbstractInterpreter<AbstractStateType>, which can execute a DFG::Node* with
          respect to an AbstractStateType. Currently we always use
          AbstractStateType = InPlaceAbstractState. But we could drop in an other
          class that supports basic primitives like forNode() and variables().
        
        This is important because:
        
        - We want to hoist things out of loops.

        - We don't know what things rely on what type checks.

        - We only want to hoist type checks out of loops if they aren't clobbered.

        - We may want to still hoist things that depended on those type checks, if it's
          safe to do those things based on the CFA state at the tail of the loop
          pre-header.

        - We don't want things to rely on their type checks by way of a token, because
          that's just weird.

        So, we want to be able to have a special form of the CFA that can
        incrementally update a basic block's state-at-tail, and we want to be able to
        do this for multiple blocks simultaneously. This requires *not* storing the
        per-node state in the nodes themselves, but instead using the at-tail HashMap
        directly.

        Hence we need to have a way of making the abstract interpreter (i.e.
        AbstractState::execute) polymorphic with respect to state representation. Put
        another way, we need to separate the way that abstract state is represented
        from the way DFG IR is abstractly interpreted.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractInterpreter.h: Added.
        (DFG):
        (AbstractInterpreter):
        (JSC::DFG::AbstractInterpreter::forNode):
        (JSC::DFG::AbstractInterpreter::variables):
        (JSC::DFG::AbstractInterpreter::needsTypeCheck):
        (JSC::DFG::AbstractInterpreter::filterEdgeByUse):
        (JSC::DFG::AbstractInterpreter::filter):
        (JSC::DFG::AbstractInterpreter::filterArrayModes):
        (JSC::DFG::AbstractInterpreter::filterByValue):
        (JSC::DFG::AbstractInterpreter::trySetConstant):
        (JSC::DFG::AbstractInterpreter::filterByType):
        * dfg/DFGAbstractInterpreterInlines.h: Added.
        (DFG):
        (JSC::DFG::::AbstractInterpreter):
        (JSC::DFG::::~AbstractInterpreter):
        (JSC::DFG::::booleanResult):
        (JSC::DFG::::startExecuting):
        (JSC::DFG::::executeEdges):
        (JSC::DFG::::verifyEdge):
        (JSC::DFG::::verifyEdges):
        (JSC::DFG::::executeEffects):
        (JSC::DFG::::execute):
        (JSC::DFG::::clobberWorld):
        (JSC::DFG::::clobberCapturedVars):
        (JSC::DFG::::clobberStructures):
        (JSC::DFG::::dump):
        (JSC::DFG::::filter):
        (JSC::DFG::::filterArrayModes):
        (JSC::DFG::::filterByValue):
        * dfg/DFGAbstractState.cpp: Removed.
        * dfg/DFGAbstractState.h: Removed.
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::CFAPhase):
        (JSC::DFG::CFAPhase::performBlockCFA):
        (CFAPhase):
        * dfg/DFGCFGSimplificationPhase.cpp:
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::ConstantFoldingPhase):
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (ConstantFoldingPhase):
        * dfg/DFGInPlaceAbstractState.cpp: Added.
        (DFG):
        (JSC::DFG::InPlaceAbstractState::InPlaceAbstractState):
        (JSC::DFG::InPlaceAbstractState::~InPlaceAbstractState):
        (JSC::DFG::InPlaceAbstractState::beginBasicBlock):
        (JSC::DFG::setLiveValues):
        (JSC::DFG::InPlaceAbstractState::initialize):
        (JSC::DFG::InPlaceAbstractState::endBasicBlock):
        (JSC::DFG::InPlaceAbstractState::reset):
        (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
        (JSC::DFG::InPlaceAbstractState::merge):
        (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
        (JSC::DFG::InPlaceAbstractState::mergeVariableBetweenBlocks):
        * dfg/DFGInPlaceAbstractState.h: Added.
        (DFG):
        (InPlaceAbstractState):
        (JSC::DFG::InPlaceAbstractState::forNode):
        (JSC::DFG::InPlaceAbstractState::variables):
        (JSC::DFG::InPlaceAbstractState::block):
        (JSC::DFG::InPlaceAbstractState::didClobber):
        (JSC::DFG::InPlaceAbstractState::isValid):
        (JSC::DFG::InPlaceAbstractState::setDidClobber):
        (JSC::DFG::InPlaceAbstractState::setIsValid):
        (JSC::DFG::InPlaceAbstractState::setBranchDirection):
        (JSC::DFG::InPlaceAbstractState::setFoundConstants):
        (JSC::DFG::InPlaceAbstractState::haveStructures):
        (JSC::DFG::InPlaceAbstractState::setHaveStructures):
        * dfg/DFGMergeMode.h: Added.
        (DFG):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::backwardTypeCheck):
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
        (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
        (JSC::DFG::SpeculativeJIT::speculateStringObject):
        (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::needsTypeCheck):
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (FTL):
        (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::appendTypeCheck):
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::speculateNumber):
        (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
        (LowerDFGToLLVM):

2013-07-18  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG shouldn't create CheckStructures for array accesses except if the ArrayMode implies an original array access
        https://bugs.webkit.org/show_bug.cgi?id=118867

        Reviewed by Mark Hahnenberg.
        
        This allows us to kill off a bunch of code in the parser, in fixup, and to simplify
        ArrayProfile.

        It also makes it easier to ask any array-using node how to create its type check.
        
        Doing this required fixing a bug in LowLevelInterpreter64, where it was storing into
        an array profile, thinking that it was storing into a value profile. Reshuffling the
        fields in ArrayProfile revealed this.

        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        (JSC::ArrayProfile::briefDescriptionWithoutUpdating):
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::ArrayProfile):
        (ArrayProfile):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateAllArrayPredictions):
        (JSC::CodeBlock::updateAllPredictions):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::updateAllArrayPredictions):
        * dfg/DFGArrayMode.h:
        (ArrayMode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (FixupPhase):
        (JSC::DFG::FixupPhase::checkArray):
        (JSC::DFG::FixupPhase::blessArrayOperation):
        * llint/LowLevelInterpreter64.asm:

2013-07-18  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: CFA should consider live-at-head for clobbering and dumping
        https://bugs.webkit.org/show_bug.cgi?id=118857

        Reviewed by Mark Hahnenberg.
        
        - clobberStructures() was not considering nodes live-at-head when in SSA
          form. This means it would fail to clobber some structures.
        
        - dump() was not considering nodes live-at-head when in SSA form. This
          means it wouldn't dump everything that you might be interested in.
        
        - AbstractState::m_currentNode is a useless variable and we should get
          rid of it.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::AbstractState):
        (JSC::DFG::AbstractState::beginBasicBlock):
        (JSC::DFG::AbstractState::reset):
        (JSC::DFG::AbstractState::startExecuting):
        (JSC::DFG::AbstractState::clobberStructures):
        (JSC::DFG::AbstractState::dump):
        * dfg/DFGAbstractState.h:
        (AbstractState):

2013-07-16  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Add a phase to create loop pre-headers
        https://bugs.webkit.org/show_bug.cgi?id=118778

        Reviewed by Oliver Hunt.
        
        Add a loop pre-header creation phase. Any loop that doesn't already have
        just one predecessor that isn't part of the loop has a pre-header
        prepended. All non-loop predecessors then jump to that pre-header.
        
        Also fix a handful of bugs:
        
        - DFG::Analysis should set m_valid before running the analysis, since that
          makes it easier to use ASSERT(m_valid) in the analysis' methods, which
          may be called by the analysis before the analysis completes. NaturalLoops
          does this with loopsOf().
        
        - NaturalLoops::headerOf() was missing a check for innerMostLoopOf()
          returning 0, since that'll happen if the block isn't in any loop.
        
        - Change BlockInsertionSet to dethread the graph, since anyone using it
          will want to do so.
        
        - Change dethreading to ignore SSA form graphs.
        
        This also adds NaturalLoops::belongsTo(), which I always used in the
        pre-header creation phase. I didn't end up using it but I'll probably use
        it in the near future.
        
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAnalysis.h:
        (JSC::DFG::Analysis::computeIfNecessary):
        * dfg/DFGBlockInsertionSet.cpp:
        (JSC::DFG::BlockInsertionSet::execute):
        * dfg/DFGCriticalEdgeBreakingPhase.cpp:
        (JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dethread):
        * dfg/DFGLoopPreHeaderCreationPhase.cpp: Added.
        (DFG):
        (LoopPreHeaderCreationPhase):
        (JSC::DFG::LoopPreHeaderCreationPhase::LoopPreHeaderCreationPhase):
        (JSC::DFG::LoopPreHeaderCreationPhase::run):
        (JSC::DFG::performLoopPreHeaderCreation):
        * dfg/DFGLoopPreHeaderCreationPhase.h: Added.
        (DFG):
        * dfg/DFGNaturalLoops.h:
        (NaturalLoop):
        (JSC::DFG::NaturalLoops::headerOf):
        (JSC::DFG::NaturalLoops::innerMostLoopOf):
        (JSC::DFG::NaturalLoops::innerMostOuterLoop):
        (JSC::DFG::NaturalLoops::belongsTo):
        (NaturalLoops):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):

2013-07-16  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Rationalize Node::replacement
        https://bugs.webkit.org/show_bug.cgi?id=118774

        Reviewed by Oliver Hunt.
        
        - Clearing of replacements is now done in Graph::clearReplacements().
        
        - New nodes now have replacement set to 0.
        
        - Node::replacement is now part of a 'misc' union. I'll be putting at least
          one other field into that union as part of LICM work (see
          https://bugs.webkit.org/show_bug.cgi?id=118749).

        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::run):
        (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::run):
        (JSC::DFG::CSEPhase::setReplacement):
        (JSC::DFG::CSEPhase::performBlockCSE):
        * dfg/DFGGraph.cpp:
        (DFG):
        (JSC::DFG::Graph::clearReplacements):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::performSubstitutionForEdge):
        (Graph):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::Node):
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):

2013-07-16  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: NaturalLoops should be able to quickly answer questions like "what loops own this basic block"
        https://bugs.webkit.org/show_bug.cgi?id=118750

        Reviewed by Mark Hahnenberg.

        * dfg/DFGBasicBlock.h:
        (BasicBlock):
        * dfg/DFGNaturalLoops.cpp:
        (JSC::DFG::NaturalLoops::compute):
        (JSC::DFG::NaturalLoops::loopsOf):
        * dfg/DFGNaturalLoops.h:
        (DFG):
        (JSC::DFG::NaturalLoop::NaturalLoop):
        (NaturalLoop):
        (JSC::DFG::NaturalLoop::index):
        (JSC::DFG::NaturalLoop::isOuterMostLoop):
        (JSC::DFG::NaturalLoop::addBlock):
        (JSC::DFG::NaturalLoops::headerOf):
        (JSC::DFG::NaturalLoops::innerMostLoopOf):
        (NaturalLoops):
        (JSC::DFG::NaturalLoops::innerMostOuterLoop):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):

2013-07-16  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: don't GC when shutting down the VM
        https://bugs.webkit.org/show_bug.cgi?id=118751

        Reviewed by Mark Hahnenberg.

        * heap/Heap.h:
        (Heap):
        * runtime/VM.cpp:
        (JSC::VM::~VM):

2013-07-12  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should have an SSA form for use by FTL
        https://bugs.webkit.org/show_bug.cgi?id=118338

        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:

2013-07-11  Mark Lam  <mark.lam@apple.com>

        Resurrect the CLoop LLINT on the FTL branch.
        https://bugs.webkit.org/show_bug.cgi?id=118144.

        Reviewed by Mark Hahnenberg.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::jitType):
          - Fix the CodeBlock jitType to be InterpreterThunk when !ENABLE_JIT.
        * bytecode/JumpTable.h:
        (JSC::SimpleJumpTable::clear):
        * interpreter/StackIterator.cpp:
        (JSC::StackIterator::Frame::bytecodeOffset):
        (JSC::StackIterator::Frame::print):
        * jit/JITCode.cpp:
        (JSC):
        * jit/JITExceptions.cpp:
        (JSC::getExceptionLocation):
        * llint/LowLevelInterpreter.cpp:
        * offlineasm/cloop.rb:
        * runtime/Structure.cpp:

2013-07-08  Filip Pizlo  <fpizlo@apple.com>

        NaturalLoops + Profiler = Crash
        https://bugs.webkit.org/show_bug.cgi?id=118486

        Reviewed by Geoffrey Garen.
        
        I borked dominators in:
        http://trac.webkit.org/changeset/152431/branches/dfgFourthTier/Source/JavaScriptCore/dfg/DFGDominators.h
        
        This patch also adds some debug support, and fixes the loop that adds a block to
        an already-existing natural loop. Note that we currently don't take that path in
        most programs, but it will arise, for example if you use 'continue' - though you'd
        have to use it rather cleverly since the bytecode will not jump to the loop header
        in most uses of 'continue'.

        * dfg/DFGDominators.cpp:
        (JSC::DFG::Dominators::dump):
        (DFG):
        * dfg/DFGDominators.h:
        (JSC::DFG::Dominators::dominates):
        (Dominators):
        * dfg/DFGNaturalLoops.cpp:
        (JSC::DFG::NaturalLoops::compute):

2013-07-08  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG::AbstractState::beginBasicBlock() should set m_haveStructures if any of the valuesAtHead have either a current known structure or a non-top/non-bottom array modes
        https://bugs.webkit.org/show_bug.cgi?id=118489

        Reviewed by Mark Hahnenberg.

        * bytecode/ArrayProfile.h:
        (JSC::arrayModesAreClearOrTop):
        (JSC):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::beginBasicBlock):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::hasClobberableState):
        (AbstractValue):

2013-07-08  Mark Hahnenberg  <mhahnenberg@apple.com>

        CheckArray should call the right version of filterArrayModes
        https://bugs.webkit.org/show_bug.cgi?id=118488

        Reviewed by Filip Pizlo.

        Currently in the CFA CheckArray doesn't call the right filterArrayMode which can cause 
        the CFA to ignore when it sees a contradiction.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::executeEffects):

2013-07-07  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Graph::clearAndDerefChild() makes no sense anymore, and neither does Nop
        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):

2013-07-04  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should better report its compile-times and it should be able to run in a mode where it doesn't spend time generating OSR exits
        https://bugs.webkit.org/show_bug.cgi?id=118401

        Reviewed by Sam Weinig.
        
        Add two new OSR exit modes, which are useful only for playing with compile times:
        
        - All OSR exits are llvm.trap().
        
        - OSR exits don't take arguments and have no exit value marshaling.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPlan.h:
        (Plan):
        * ftl/FTLIntrinsicRepository.h:
        (FTL):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::trap):
        * runtime/Options.h:
        (JSC):

2013-07-04  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should refer to BasicBlocks by BasicBlock* and not BlockIndex
        https://bugs.webkit.org/show_bug.cgi?id=118339

        Reviewed by Michael Saboff.
        
        This accomplishes two goals:

        1) Simplifies a bunch of code. You can now much more directly get to a successor
           or predecessor, since you just get the pointer directly. The backend(s) always
           hold onto a pointer to the block they're on, so you don't have to do work to
           get the block from the index.
        
        2) It allows for the possibility of inserting blocks into the program.
           Previously, if you did that, you'd have to edit all references to blocks since
           those references would have outdated indexing after an insertion. Now, if you
           change the indexing, you just have to invalidate some analyses and make sure
           that you change each block's BasicBlock::index accordingly.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        (JSC::DFG::AbstractState::endBasicBlock):
        (JSC::DFG::AbstractState::mergeToSuccessors):
        * dfg/DFGAbstractState.h:
        (AbstractState):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::run):
        * dfg/DFGBasicBlock.h:
        (DFG):
        (JSC::DFG::BasicBlock::BasicBlock):
        (JSC::DFG::BasicBlock::size):
        (JSC::DFG::BasicBlock::isEmpty):
        (JSC::DFG::BasicBlock::at):
        (JSC::DFG::BasicBlock::operator[]):
        (JSC::DFG::BasicBlock::last):
        (JSC::DFG::BasicBlock::resize):
        (JSC::DFG::BasicBlock::grow):
        (BasicBlock):
        (JSC::DFG::BasicBlock::append):
        (JSC::DFG::BasicBlock::numSuccessors):
        (JSC::DFG::BasicBlock::successor):
        (JSC::DFG::BasicBlock::successorForCondition):
        (JSC::DFG::BasicBlock::dump):
        (UnlinkedBlock):
        (JSC::DFG::UnlinkedBlock::UnlinkedBlock):
        (JSC::DFG::getBytecodeBeginForBlock):
        (JSC::DFG::blockForBytecodeOffset):
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (InlineStackEntry):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::linkBlock):
        (JSC::DFG::ByteCodeParser::linkBlocks):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::performBlockCFA):
        (JSC::DFG::CFAPhase::performForwardCFA):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        (JSC::DFG::CFGSimplificationPhase::convertToJump):
        * dfg/DFGCPSRethreadingPhase.cpp:
        (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
        (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlocks):
        (JSC::DFG::CPSRethreadingPhase::propagatePhis):
        (CPSRethreadingPhase):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::run):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::run):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::Disassembler):
        (JSC::DFG::Disassembler::createDumpList):
        * dfg/DFGDisassembler.h:
        (JSC::DFG::Disassembler::setForBlockIndex):
        * dfg/DFGDominators.cpp:
        (JSC::DFG::Dominators::compute):
        (JSC::DFG::Dominators::iterateForBlock):
        * dfg/DFGDominators.h:
        (JSC::DFG::Dominators::dominates):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::run):
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::dumpBlockHeader):
        (JSC::DFG::Graph::handleSuccessor):
        (JSC::DFG::Graph::determineReachability):
        (JSC::DFG::Graph::resetReachability):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::numBlocks):
        (JSC::DFG::Graph::block):
        (JSC::DFG::Graph::lastBlock):
        (Graph):
        (JSC::DFG::Graph::appendBlock):
        (JSC::DFG::Graph::killBlock):
        (DFG):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::setForBlockIndex):
        * dfg/DFGNaturalLoops.cpp:
        (JSC::DFG::NaturalLoop::dump):
        (JSC::DFG::NaturalLoops::compute):
        (JSC::DFG::NaturalLoops::loopsOf):
        * dfg/DFGNaturalLoops.h:
        (JSC::DFG::NaturalLoop::NaturalLoop):
        (JSC::DFG::NaturalLoop::addBlock):
        (JSC::DFG::NaturalLoop::header):
        (JSC::DFG::NaturalLoop::at):
        (JSC::DFG::NaturalLoop::operator[]):
        (JSC::DFG::NaturalLoop::contains):
        (NaturalLoop):
        (JSC::DFG::NaturalLoops::headerOf):
        (NaturalLoops):
        * dfg/DFGNode.h:
        (DFG):
        (JSC::DFG::SwitchCase::SwitchCase):
        (JSC::DFG::SwitchCase::withBytecodeIndex):
        (SwitchCase):
        (JSC::DFG::SwitchCase::targetBytecodeIndex):
        (JSC::DFG::SwitchData::SwitchData):
        (JSC::DFG::SwitchData::setFallThroughBytecodeIndex):
        (JSC::DFG::SwitchData::fallThroughBytecodeIndex):
        (SwitchData):
        (JSC::DFG::Node::setTakenBlock):
        (JSC::DFG::Node::setNotTakenBlock):
        (JSC::DFG::Node::takenBlock):
        (JSC::DFG::Node::notTakenBlock):
        (JSC::DFG::Node::successor):
        (JSC::DFG::Node::successorForCondition):
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagateForward):
        (JSC::DFG::PredictionPropagationPhase::propagateBackward):
        (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeCompare):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeStrictEq):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleDoubleBranch):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleIntegerBranch):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::createOSREntries):
        (JSC::DFG::SpeculativeJIT::linkOSREntries):
        (JSC::DFG::SpeculativeJIT::compileStrictEqForConstant):
        (JSC::DFG::SpeculativeJIT::compileStrictEq):
        (JSC::DFG::SpeculativeJIT::compileRegExpExec):
        (JSC::DFG::SpeculativeJIT::addBranch):
        (JSC::DFG::SpeculativeJIT::linkBranches):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::nextBlock):
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
        (JSC::DFG::SpeculativeJIT::branchDouble):
        (JSC::DFG::SpeculativeJIT::branchDoubleNonZero):
        (JSC::DFG::SpeculativeJIT::branch32):
        (JSC::DFG::SpeculativeJIT::branchTest32):
        (JSC::DFG::SpeculativeJIT::branch64):
        (JSC::DFG::SpeculativeJIT::branch8):
        (JSC::DFG::SpeculativeJIT::branchPtr):
        (JSC::DFG::SpeculativeJIT::branchTestPtr):
        (JSC::DFG::SpeculativeJIT::branchTest8):
        (JSC::DFG::SpeculativeJIT::jump):
        (JSC::DFG::SpeculativeJIT::addBranch):
        (JSC::DFG::SpeculativeJIT::StringSwitchCase::StringSwitchCase):
        (StringSwitchCase):
        (JSC::DFG::SpeculativeJIT::BranchRecord::BranchRecord):
        (BranchRecord):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
        (JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
        * dfg/DFGUnificationPhase.cpp:
        (JSC::DFG::UnificationPhase::run):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        (JSC::DFG::Validate::checkOperand):
        (JSC::DFG::Validate::reportValidationContext):
        * dfg/DFGVirtualRegisterAllocationPhase.cpp:
        (JSC::DFG::VirtualRegisterAllocationPhase::run):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileBlock):
        (JSC::FTL::LowerDFGToLLVM::compileJump):
        (JSC::FTL::LowerDFGToLLVM::compileBranch):
        (JSC::FTL::LowerDFGToLLVM::lowBlock):

2013-07-04  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, add a helpful comment for why DCE is needed in the FTL.

        I believe I've now twice down the experiment of disabling DCE in the FTL,
        only to realize that this can't work, and that DCE is needed. I'd kind of
        like to not make that mistake again.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):

2013-07-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG::Node::m_opInfo2 should also be a uintptr_t
        https://bugs.webkit.org/show_bug.cgi?id=118340

        Reviewed by Sam Weinig.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::Node):

2013-07-02  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix 32-bit build.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::comparePtr):
        (MacroAssembler):
        * dfg/DFGBinarySwitch.cpp:
        (JSC::DFG::BinarySwitch::advance):
        * dfg/DFGBinarySwitch.h:
        (JSC::DFG::BinarySwitch::caseValue):

2013-07-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Have fewer Arrayify's
        https://bugs.webkit.org/show_bug.cgi?id=118335

        Reviewed by Mark Hahnenberg.
        
        A lot of Arrayify's arise because some program saw Int32 arrays early on in
        execution, but then they all got converted to Double arrays and the program
        will never see Int32 arrays ever again. Prior to this change you would always
        have an Arrayify in this case. But with this change, the first time that an
        ArrayProfile is about to go polymorphic in computeUpdatedPrediction(), it
        instead forcibly monomorphises itself to the latest-seen structure.
        Thereafter it will never again perform this monomorphisation. This is
        controlled by ArrayProfile::m_didPerformFirstRunPruning. This is a 5%
        speed-up on Kraken/imaging-gaussian-blur with the FTL enabled, and it
        unblocks a bunch of stuff we want to do in the future because it makes a
        bunch of loops effect-free.
        
        We will still want to implement Arrayify hoisting in the future, but this is
        great anyway because it's better to not have Arrayifications than it is to
        have hoisted Arrayifications.

        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        (JSC::ArrayProfile::briefDescription):
        (JSC):
        (JSC::ArrayProfile::briefDescriptionWithoutUpdating):
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::ArrayProfile):
        (ArrayProfile):

2013-07-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: add option to disable OSR entry in loops
        https://bugs.webkit.org/show_bug.cgi?id=118329

        Reviewed by Mark Hahnenberg.
        
        This adds that option, and also makes the OSR exit reoptimization trigger rely less on
        OSR entry failing. Now even if we never attempt OSR entry but our execution counter gets
        high after a small number of OSR exits, we will recompile.

        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::handleExitCounts):
        * dfg/DFGOperations.cpp:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_loop_hint):
        (JSC::JIT::emitSlow_op_loop_hint):
        * runtime/Options.h:
        (JSC):

2013-07-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: since the FTL disassembly hacks cannot distinguish between code and data, the LLVM disassembler symbol table callback should be able to deal gracefully with arbitrary garbage
        https://bugs.webkit.org/show_bug.cgi?id=118313

        Reviewed by Mark Hahnenberg.
        
        Give it a mode where we can still crash on unrecognized reference types, so that we might
        implement them in the future, but by default just print some stuff and keep going.

        * disassembler/LLVMDisassembler.cpp:
        (JSC):
        (JSC::symbolLookupCallback):

2013-07-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should use the equivalent of llvm opt -O2 by default
        https://bugs.webkit.org/show_bug.cgi?id=118311

        Reviewed by Mark Hahnenberg.
        
        Use a PassManagerBuilder instead of rolling our own.
        
        This boosts our speed-up by another 5% or so.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * runtime/Options.h:
        (JSC):

2013-07-01  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should run LICM after AA setup
        https://bugs.webkit.org/show_bug.cgi?id=118277

        Reviewed by Maciej Stachowiak.
        
        LICM queries alias analysis. Hence, just like GVN, it should run after
        we have set up the alias analysis.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):

2013-07-01  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should run AA passes before GVN
        https://bugs.webkit.org/show_bug.cgi?id=118276

        Rubber stamped by Geoffrey Garen.
        
        These enable load elimination in GVN.
        
        Immediately gives us a speed-up on a bunch of benchmarks I hacked to run
        properly in the FTL. One example is 20% on imaging-gaussian-blur. (Fair
        warning: the stock version of that benchmark won't see speed-ups -
        probably slow-downs instead - because the FTL can't do OSR entry yet.)
        Another example is the findGraphNode function, which now sees a 7%
        speed-up, and that's without even doing LICM or other good things.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):

2013-06-27  Filip Pizlo  <fpizlo@apple.com>

        Make Graph::substituteGetLocal() out-of-line

        Rubber stamped by Geoffrey Garen.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::substituteGetLocal):
        (DFG):
        * dfg/DFGGraph.h:
        (Graph):

2013-06-27  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should know how to find natural loops
        https://bugs.webkit.org/show_bug.cgi?id=118152

        Reviewed by Mark Hahnenberg.
        
        There are a bunch of things we can do when we know where the loops are.
        Previously we didn't. With this patch, we do.
        
        This patch adds the classic dominator based natural loop finder.
        
        The only client of this right now is the DFG::Disassembler. It prints out
        a summary of the analysis for each block.
        
        This will become more important when I do
        https://bugs.webkit.org/show_bug.cgi?id=118151, which definitely requires
        this kind of analysis, at least if we want to do the optimization over
        DFG IR (and I'm pretty sure we do).

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAnalysis.h: Added.
        (DFG):
        (Analysis):
        (JSC::DFG::Analysis::Analysis):
        (JSC::DFG::Analysis::invalidate):
        (JSC::DFG::Analysis::computeIfNecessary):
        (JSC::DFG::Analysis::isValid):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::createDumpList):
        * dfg/DFGDominators.cpp:
        (JSC::DFG::Dominators::Dominators):
        (JSC::DFG::Dominators::compute):
        * dfg/DFGDominators.h:
        (Dominators):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dumpBlockHeader):
        (JSC::DFG::Graph::invalidateCFG):
        (DFG):
        * dfg/DFGGraph.h:
        (Graph):
        * dfg/DFGNaturalLoops.cpp: Added.
        (DFG):
        (JSC::DFG::NaturalLoop::dump):
        (JSC::DFG::NaturalLoops::NaturalLoops):
        (JSC::DFG::NaturalLoops::~NaturalLoops):
        (JSC::DFG::NaturalLoops::compute):
        (JSC::DFG::NaturalLoops::loopsOf):
        (JSC::DFG::NaturalLoops::dump):
        * dfg/DFGNaturalLoops.h: Added.
        (DFG):
        (NaturalLoop):
        (JSC::DFG::NaturalLoop::NaturalLoop):
        (JSC::DFG::NaturalLoop::addBlock):
        (JSC::DFG::NaturalLoop::header):
        (JSC::DFG::NaturalLoop::size):
        (JSC::DFG::NaturalLoop::at):
        (JSC::DFG::NaturalLoop::operator[]):
        (JSC::DFG::NaturalLoop::contains):
        (NaturalLoops):
        (JSC::DFG::NaturalLoops::numLoops):
        (JSC::DFG::NaturalLoops::loop):
        (JSC::DFG::NaturalLoops::headerOf):

2013-06-27  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: JSC's disassembly infrastructure should be able to disassemble the code that LLVM generates
        https://bugs.webkit.org/show_bug.cgi?id=118148

        Reviewed by Anders Carlsson.
        
        Oh boy. UDis86 cannot disassemble the AVX (or whatever it's called) stuff
        that LLVM generates for floating point. So the right decision is to
        switch to the LLVM disassembler, right? Wrong!! LLVM's disassembler
        cannot disassemble the load-from-absolute-address-into-%rax instructions
        that our JIT generates quite a lot of.
        
        So, this keeps the UDis86 disassembler, but adds the LLVM disassembler,
        and requires the caller of disassemble() to hint which one is likely to
        be less wrong for the given code.
        
        Maybe in the future LLVM will catch up to UDis86, but it's definitely not
        there right now.
        
        This now allows us to disassemble all of the code that LLVM generates.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * disassembler/Disassembler.cpp:
        (JSC::disassemble):
        * disassembler/Disassembler.h:
        (JSC::tryToDisassemble):
        (JSC):
        * disassembler/LLVMDisassembler.cpp: Added.
        (JSC):
        (JSC::symbolLookupCallback):
        (JSC::tryToDisassembleWithLLVM):
        * disassembler/LLVMDisassembler.h: Added.
        (JSC):
        (JSC::tryToDisassembleWithLLVM):
        * disassembler/UDis86Disassembler.cpp:
        (JSC::tryToDisassembleWithUDis86):
        * disassembler/UDis86Disassembler.h: Added.
        (JSC):
        (JSC::tryToDisassembleWithUDis86):
        * disassembler/X86Disassembler.cpp: Added.
        (JSC):
        (JSC::tryToDisassemble):
        * ftl/FTLAbbreviatedTypes.h:
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLJITCode.h:
        * ftl/FTLJITFinalizer.h:
        * ftl/FTLLLVMHeaders.h: Removed.
        * ftl/FTLLink.cpp:
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreadingOnce):
        * runtime/Options.h:
        (JSC):

2013-06-27  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should be able to dump disassembly
        https://bugs.webkit.org/show_bug.cgi?id=118141

        Reviewed by Geoffrey Garen.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):

2013-06-27  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix build for LLVM ToT.

        This doesn't affect those using the binary drops, but if you're building from
        LLVM ToT you'll get link errors. These arise because we expect there to be a
        libLLVMArchive, but that is no longer built by LLVM ToT. This casues the linker
        to fall back on the system's libLLVMArchive, which is incompatible with the
        other LLVM libs we pull in.
        
        Also, we didn't need that library anyway and shouldn't have been linking
        against it.

        * Configurations/JavaScriptCore.xcconfig:

2013-06-26  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support hole/OOB PutByVal's
        https://bugs.webkit.org/show_bug.cgi?id=118112

        Reviewed by Geoffrey Garen.
        
        Added a common code generator for the out-of-bounds case that is reused by
        all contiguous-like arrays (Int32, Double, Contiguous).
        
        This is relatively straight-forward, except that it's the first time that
        the FTL has to call DFG operations that take more than two arguments.

        * ftl/FTLAbbreviations.h:
        (JSC::FTL::functionType):
        (JSC::FTL::buildCall):
        * ftl/FTLAbstractHeapRepository.h:
        (FTL):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        (FTL):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::contiguousPutByValOutOfBounds):
        (JSC::FTL::LowerDFGToLLVM::vmCall):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::call):

2013-06-26  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL::canCompile(Graph&) should not consider nodes that won't be compiled
        https://bugs.webkit.org/show_bug.cgi?id=118097

        Reviewed by Mark Hahnenberg.
        
        This increases coverage to include programs that have unprofiled paths. Those paths will
        often have nodes that appear to do untyped speculations, and the FTL sometimes doesn't
        support those; except that it doesn't matter since the reason why they were untyped is
        that they were unprofiled and anyway we won't run them because we'll exit before them.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):

2013-06-26  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support ArrayifyToStructure
        https://bugs.webkit.org/show_bug.cgi?id=118095

        Reviewed by Mark Hahnenberg.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        (FTL):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
        (LowerDFGToLLVM):

2013-06-26  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support ForwardCheckStructure/ForwardStructureTransitionWatchpoint and doing so shouldn't break V8/crypto
        https://bugs.webkit.org/show_bug.cgi?id=118091

        Reviewed by Mark Hahnenberg.
        
        I was going to just add ForwardCheckStructure/ForwardStructureTransitionWatchpoint support,
        which is trivial. But doing so increases coverage a lot, and revealed long-standing bugs in
        the FTL. I then fixed those bugs, also:
        
        - The FTL should not attempt to compile a block that is not reachable according to the CFA.
          This is analogous to terminating basic block compilation if the CFA becomes !isValid().
          Attempting to compile such a block means that you're running on broken CFA state, and the
          CFA will become inconsistent with the code you're generating, leading to some
          strangeness. For example, the FTL relies on the CFA to tell it that we gave up compiling
          a node and hence don't have LValue's for that node (by virtue of us giving up due to
          !isValid()). But the CFA's isValid() bit will not be set correctly for blocks that
          weren't visited by the CFA at all, and the CFA expects you to know this because it
          expects that you already checked BasicBlock::cfaHasVisited.
        
        - SetLocal needs to change the ValueSource of the operand to indicate that its value has
          been stashed in the local (i.e. the "reference" corresponding to the operand in FTL
          speak). This is because although OSR exit already knows that the value of the operand is
          stored in the Node, and it already knows what LValue corresponds to the node, OSR exit
          will also assume that if the Node dies then the value-at-exit for that operand should be
          Dead (i.e. jsUndefined). But the Node dying, and the local dying, are two distinct
          things; in particular the local always outlives the Node in the case of a SetLocal. So,
          we just need to have SetLocal have the ValueSource be BlahInLocal rather than HaveNode,
          to ensure that OSR exit knows that the darn thing is really live until the end of the
          basic block, as opposed to until whenever the Node dies (which could be at any time).
        
        - PutByOffset was erroneously storing to an offset from the base object, rather than an
          offset from the storage. Note that the storage will be the base object (exactly - i.e.
          same node, same value) for inline stores, but will be a distinct thing for out-of-line
          stores.
        
        - At-head set-up of OSR exit state was using ValueInLocals for variables forced double,
          when it should have been using DoubleInLocals.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileBlock):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
        (JSC::FTL::LowerDFGToLLVM::compilePutByOffset):
        (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
        (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):

2013-06-26  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support PutByVal
        https://bugs.webkit.org/show_bug.cgi?id=118075

        Reviewed by Mark Hahnenberg.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compilePutByVal):

2013-06-25  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Convert versus AsIs should have no bearing on whether we can do the SaneChain optimization for double array GetByVals
        https://bugs.webkit.org/show_bug.cgi?id=118028

        Reviewed by Sam Weinig.
        
        The SaneChain optimization allows us to get rid of the NaN check on loading from
        a double array, if the result is used in an arithmetic op that wouldn't
        distinguish between NaN and undefined. Normally the NaN check would be needed
        because NaN is the hole marker.
        
        The SaneChain optimization definitely requires that you're an Original array,
        since we need to watchpoint the array prototype chain. And so it also needs to
        be a JSArray, and not an object that has indexed double properties. We also
        require an in-bounds access, since the backend is only capable of the
        optimization in the in-bounds case (though we could extend it to OOB in the
        future). But whether the array is being converted or is as-is isn't relevant.
        Either way, if it's a double original array in-bounds access by the time that
        the array check (or conversion!) completes, we can do the optimization.
        
        Ever-so-slight speed-up on Kraken/imaging-gaussian-blur.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):

2013-06-25  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should support switch_string
        https://bugs.webkit.org/show_bug.cgi?id=117967

        Reviewed by Sam Weinig.
        
        Add a reusable binary switch creator.
        
        Implement switch on string using three modes:
        
        - Binary switch on StringImpl* in the case of identifiers.
        
        - Trie of binary switches on characters in the case of a not-too-big
          switch over not-too-big 8-bit strings.
        
        - Hash lookup if all else fails.
        
        Anywhere from a 2x to 3x speed-up on microbenchmarks that stress
        string switches. 25-35% speed-up on HashMap tests. 4% speed-up on
        pdfjs.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/JumpTable.h:
        (StringJumpTable):
        (JSC::StringJumpTable::clear):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGBinarySwitch.cpp: Added.
        (DFG):
        (JSC::DFG::BinarySwitch::BinarySwitch):
        (JSC::DFG::BinarySwitch::advance):
        (JSC::DFG::BinarySwitch::build):
        * dfg/DFGBinarySwitch.h: Added.
        (DFG):
        (BinarySwitch):
        (JSC::DFG::BinarySwitch::caseIndex):
        (JSC::DFG::BinarySwitch::caseValue):
        (JSC::DFG::BinarySwitch::fallThrough):
        (JSC::DFG::BinarySwitch::Case::Case):
        (Case):
        (JSC::DFG::BinarySwitch::Case::operator<):
        (JSC::DFG::BinarySwitch::BranchCode::BranchCode):
        (BranchCode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGLazyJSValue.cpp:
        (JSC::DFG::LazyJSValue::getValue):
        (JSC::DFG::equalToStringImpl):
        (DFG):
        (JSC::DFG::LazyJSValue::strictEqual):
        (JSC::DFG::LazyJSValue::dump):
        * dfg/DFGLazyJSValue.h:
        (JSC::DFG::LazyJSValue::knownStringImpl):
        (LazyJSValue):
        (JSC::DFG::LazyJSValue::stringImpl):
        (JSC::DFG::LazyJSValue::switchLookupValue):
        * dfg/DFGNode.cpp:
        (WTF::printInternal):
        * dfg/DFGNode.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitSwitchChar):
        (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
        (DFG):
        (JSC::DFG::SpeculativeJIT::emitBinarySwitchStringRecurse):
        (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
        (JSC::DFG::SpeculativeJIT::emitSwitchString):
        (JSC::DFG::SpeculativeJIT::emitSwitch):
        (JSC::DFG::SpeculativeJIT::addBranch):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::branch8):
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::StringSwitchCase::StringSwitchCase):
        (StringSwitchCase):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileSwitch):
        * runtime/Options.h:
        (JSC):

2013-06-24  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Count external memory usage towards heap footprint
        https://bugs.webkit.org/show_bug.cgi?id=117948

        Reviewed by Geoffrey Garen.

        Currently just count strings. Strings get counted in such a way that we won't re-count strings
        that are aliased, by dividing by the reference count. This then ups the GC footprint and allows
        the collector to appropriately amortize itself.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::size):
        (JSC::Heap::collect):
        * heap/Heap.h:
        (Heap):
        * heap/SlotVisitor.h:
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::reportExtraMemoryUsage):
        (JSC):
        * runtime/JSString.cpp:
        (JSC::JSString::visitChildren):

2013-06-23  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should optimize identifier string equality
        https://bugs.webkit.org/show_bug.cgi?id=117920

        Reviewed by Sam Weinig.
        
        This is a 20% speed-up for string equality comparisons when both strings are
        identifiers.
        
        This is important for two reasons:
        
        1) Using strings as enumerations is an idiom. A great example is typeof. It
           would be great if this performed better.
        
        2) When I implement switch_string in the DFG, it would be great to optimize
           the case where the switched-on value is an identifier. That would involve
           a simple binary switch rather than a more complicated trie-switch over
           characters.

        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        (JSC::speculationToAbbreviatedString):
        (JSC::speculationFromCell):
        * bytecode/SpeculatedType.h:
        (JSC):
        (JSC::isStringIdentSpeculation):
        (JSC::isStringSpeculation):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateStringIdent):
        (Node):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
        (JSC::DFG::SpeculativeJIT::compare):
        (JSC::DFG::SpeculativeJIT::compileStrictEq):
        (JSC::DFG::SpeculativeJIT::compileStringEquality):
        (JSC::DFG::SpeculativeJIT::compileStringIdentEquality):
        (DFG):
        (JSC::DFG::SpeculativeJIT::speculateString):
        (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
        (JSC::DFG::SpeculativeJIT::speculateStringIdent):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        (JSC::DFG::isCell):

2013-06-22  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG shouldn't exit just because a String GetByVal went out-of-bounds
        https://bugs.webkit.org/show_bug.cgi?id=117906

        Reviewed by Mark Hahnenberg.
        
        This does the obvious thing, but also makes sure that out-of-bounds accesses
        don't fall off into a C call, but try to do the fast thing if the prototype
        chain is sane. We ought to probably do this for other array accesses in the
        future, as well, since it's so darn easy.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::objectPrototypeIsSane):
        (JSC):
        (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
        (JSC::JSGlobalObject::stringPrototypeChainIsSane):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):

2013-06-22  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: GC's put_by_id transition fixpoint should converge more quickly
        https://bugs.webkit.org/show_bug.cgi?id=117912

        Reviewed by Mark Hahnenberg.

        This was a rookie mistake. The GC does a classic forward data flow fixpoint. These work well so long as you
        iterate the program in program order, or at least something close to program order. Because I enjoy reverse
        loops ("while (n--) blah"), I ended up iterating in *reverse* of program order which ensured worst-case
        pathologies every single time. And unsurprisingly, this slowed down a program, namely pdfjs.

        Flipping the loops to iterate forward fixes a 90% regression in Octane/pdfjs and is otherwise neutral.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::propagateTransitions):

2013-06-21  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should CSE MakeRope
        https://bugs.webkit.org/show_bug.cgi?id=117905

        Reviewed by Geoffrey Garen.
        
        Adds MakeRope to the CSE phase and removes the comment that says that
        we could do it but aren't doing it.
        
        Also fixed SpeculatedType dumping so that if you have a Cell type then
        it just prints "Cell" and if you just have Object then it just prints
        "Object", instead of printing the long list of types.

        * bytecode/SpeculatedType.cpp:
        (JSC::dumpSpeculation):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::performNodeCSE):

2013-06-21  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should't exit just because it GetByVal'd a big character
        https://bugs.webkit.org/show_bug.cgi?id=117899

        Reviewed by Mark Hahnenberg.
        
        Add a slow path. Also clarify handling of GetByVal in PutStructure elimination.
        Previously it would fail due to canExit() but now we can also fail because
        GetByVal(String) can allocate. Just make it so GetByVal is totally poisoned, in
        a very explicit way.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::putStructureStoreElimination):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (SpeculativeJIT):

2013-06-21  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Small strings shouldn't get GC'd
        https://bugs.webkit.org/show_bug.cgi?id=117897

        Reviewed by Mark Hahnenberg.
        
        Kill off the code needed to allocate them lazily and finalize them.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        * heap/Heap.cpp:
        (JSC::Heap::collect):
        * runtime/JSString.h:
        (JSC::jsSingleCharacterString):
        (JSC::jsSingleCharacterSubstring):
        (JSC::jsString):
        (JSC::jsSubstring8):
        (JSC::jsSubstring):
        (JSC::jsOwnedString):
        * runtime/NumberPrototype.cpp:
        (JSC::integerValueToString):
        * runtime/SmallStrings.cpp:
        (JSC):
        (JSC::SmallStrings::initializeCommonStrings):
        (JSC::SmallStrings::visitStrongReferences):
        * runtime/SmallStrings.h:
        (JSC::SmallStrings::singleCharacterString):
        (SmallStrings):

2013-06-20  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Structure should have a dump()
        https://bugs.webkit.org/show_bug.cgi?id=117859

        Reviewed by Geoffrey Garen.
        
        This is pretty cool. Anywhere we previously printed Structure pointers in dumps,
        we now print a bunch of other info as well. For example, for an object literal
        like "{f:42, g:64, h:24}", when we print the structure we'll now get:

            0x107a0af80:[Object, {f:0, g:1, h:2}, NonArray, Proto:0x107a8fff0]
        
        This also changes a bunch of places to use the dump method.

        * bytecode/StructureSet.h:
        (JSC::StructureSet::dump):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGStructureAbstractValue.h:
        (JSC::DFG::StructureAbstractValue::dump):
        * runtime/JSCJSValue.cpp:
        (JSC::JSValue::dump):
        * runtime/Structure.cpp:
        (JSC::Structure::dump):
        (JSC):
        * runtime/Structure.h:
        (Structure):

2013-06-20  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: There should only be one table of SimpleJumpTables
        https://bugs.webkit.org/show_bug.cgi?id=117856

        Reviewed by Geoffrey Garen.
        
        Having multiple tables of SimpleJumpTables just means we have to duplicate a
        ton of code. This patch deduplicates all of it.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::shrinkToFit):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numberOfSwitchJumpTables):
        (JSC::CodeBlock::addSwitchJumpTable):
        (JSC::CodeBlock::switchJumpTable):
        (JSC::CodeBlock::clearSwitchJumpTables):
        (RareData):
        * bytecode/PreciseJumpTargets.cpp:
        (JSC):
        (JSC::computePreciseJumpTargets):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::shrinkToFit):
        (JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables):
        (JSC::UnlinkedCodeBlock::addSwitchJumpTable):
        (JSC::UnlinkedCodeBlock::switchJumpTable):
        (RareData):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC):
        (JSC::prepareJumpTableForSwitch):
        (JSC::BytecodeGenerator::endSwitch):
        * dfg/DFGByteCodeParser.cpp:
        (InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGJITCompiler.h:
        (JITCompiler):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
        (DFG):
        (JSC::DFG::SpeculativeJIT::emitSwitchImm):
        (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_switch_imm):
        (JSC::JIT::emit_op_switch_char):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_switch_imm):
        (JSC::JIT::emit_op_switch_char):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2013-06-20  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should clear character switch jump tables
        https://bugs.webkit.org/show_bug.cgi?id=117852

        Reviewed by Sam Weinig.
        
        The FTL just uses LLVM's switch, which results in LLVM allocating its own switch
        jump tables as needed.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::clearCharacterSwitchJumpTables):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):

2013-06-20  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support SwitchChar
        https://bugs.webkit.org/show_bug.cgi?id=117849

        Reviewed by Geoffrey Garen.
        
        This adds Switch(SwitchChar) to the FTL and also implicitly does some other things.
        SwitchChar requires calling a slow path to resolve ropes. Previously the FTL had no
        support for calling slow paths, and we avoided adding coverage that would require
        that. Well, this patch adds the ability to call slow paths and just uses that for
        resolving ropes for SwitchChar. Also SwitchChar required adding awareness of strings,
        so I did that, too.

        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::addCodeOrigin):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGNode.cpp:
        (WTF):
        (WTF::printInternal):
        * dfg/DFGNode.h:
        (WTF):
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::int16Type):
        (JSC::FTL::constInt):
        * ftl/FTLAbstractHeapRepository.h:
        (FTL):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h:
        (CommonValues):
        * ftl/FTLIntrinsicRepository.cpp:
        (JSC::FTL::IntrinsicRepository::IntrinsicRepository):
        (FTL):
        * ftl/FTLIntrinsicRepository.h:
        (FTL):
        (IntrinsicRepository):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments):
        (JSC::FTL::LowerDFGToLLVM::compileJump):
        (JSC::FTL::LowerDFGToLLVM::compileBranch):
        (JSC::FTL::LowerDFGToLLVM::compileSwitch):
        (JSC::FTL::LowerDFGToLLVM::buildSwitch):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::lowString):
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::isObject):
        (JSC::FTL::LowerDFGToLLVM::isNotString):
        (JSC::FTL::LowerDFGToLLVM::isString):
        (JSC::FTL::LowerDFGToLLVM::isNotObject):
        (JSC::FTL::LowerDFGToLLVM::speculateObject):
        (JSC::FTL::LowerDFGToLLVM::speculateString):
        (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
        (JSC::FTL::LowerDFGToLLVM::vmCall):
        (JSC::FTL::LowerDFGToLLVM::callPreflight):
        (JSC::FTL::LowerDFGToLLVM::callCheck):
        (JSC::FTL::LowerDFGToLLVM::lowBlock):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::constBool):
        (JSC::FTL::Output::constInt8):
        (JSC::FTL::Output::constInt32):
        (JSC::FTL::Output::constIntPtr):
        (JSC::FTL::Output::constInt64):
        (JSC::FTL::Output::load16):
        (JSC::FTL::Output::isNull):
        (JSC::FTL::Output::notNull):
        (JSC::FTL::Output::testIsZero32):
        (JSC::FTL::Output::testNonZero32):
        (Output):
        (JSC::FTL::Output::operation):
        (JSC::FTL::Output::crash):

2013-06-18  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should have switch_char
        https://bugs.webkit.org/show_bug.cgi?id=117710

        Reviewed by Michael Saboff.
        
        Add op_switch_char. Most of this is fairly simple, except for the whole
        LazyJSValue thing.
        
        It's long been the case that anytime you wanted the DFG to speak of a string
        that didn't appear in the constant pool, you would have a hard time since
        the DFG isn't allowed to allocate in the GC heap. For example, if you know
        that you want to speak of a single character string, you might find that
        the one you wanted to speak of had been GC'd. Another example is if you
        wanted to add constant folding for string concatenation - something we don't
        have yet but will want eventually.
        
        I solve this by finally adding the notion of LazyJSValue. In the future I
        anticipate using this for a variety of string-related things. The idea here
        is that the DFG can either say that it already knows what the value is, or
        it can describe the value. For example, in this patch I needed to be able to
        describe single-character strings.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        * bytecode/JumpTable.h:
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGPRInfo.h:
        (JSC::DFG::JSValueRegs::payloadGPR):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::jumpTable):
        (DFG):
        (JSC::DFG::JITCompiler::numberOfJumpTables):
        (JSC::DFG::JITCompiler::linkSwitches):
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGJITCompiler.h:
        (JITCompiler):
        * dfg/DFGLazyJSValue.cpp: Added.
        (DFG):
        (JSC::DFG::LazyJSValue::getValue):
        (JSC::DFG::equalToSingleCharacter):
        (JSC::DFG::LazyJSValue::strictEqual):
        (JSC::DFG::LazyJSValue::dump):
        * dfg/DFGLazyJSValue.h: Added.
        (DFG):
        (LazyJSValue):
        (JSC::DFG::LazyJSValue::LazyJSValue):
        (JSC::DFG::LazyJSValue::singleCharacterString):
        (JSC::DFG::LazyJSValue::tryGetValue):
        (JSC::DFG::LazyJSValue::value):
        (JSC::DFG::LazyJSValue::character):
        (JSC::DFG::LazyJSValue::switchLookupValue):
        * dfg/DFGNode.h:
        (JSC::DFG::SwitchCase::SwitchCase):
        (SwitchCase):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
        (JSC::DFG::SpeculativeJIT::emitSwitchImmIntJump):
        (DFG):
        (JSC::DFG::SpeculativeJIT::emitSwitchImm):
        (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
        (JSC::DFG::SpeculativeJIT::emitSwitchChar):
        (JSC::DFG::SpeculativeJIT::emitSwitch):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):

2013-06-19  Mark Hahnenberg  <mhahnenberg@apple.com>

        Refactor ObjCCallbackFunction to inherit directly from InternalFunction
        https://bugs.webkit.org/show_bug.cgi?id=117595

        Reviewed by Geoffrey Garen.

        * API/APICallbackFunction.h: Added. New struct that allows JSCallbackFunction and 
        ObjCCallbackFunction to share their host call() implementation through the magic of 
        templates.
        (JSC::APICallbackFunction::call):
        * API/JSCallbackFunction.cpp:
        (JSC::JSCallbackFunction::getCallData): Changed to get the template-ized version of 
        the host function.
        * API/JSCallbackFunction.h:
        * API/ObjCCallbackFunction.h: Now inherits directly from InternalFunction.
        * API/ObjCCallbackFunction.mm:
        (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
        (JSC::ObjCCallbackFunction::getCallData): Ditto.
        * GNUmakefile.list.am: Build files!
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

2013-06-19  Michael Saboff  <msaboff@apple.com>

        fourthTier: Arity fixup should be done while on same stack
        https://bugs.webkit.org/show_bug.cgi?id=117102

        Reviewed by Oliver Hunt.

        Removed the fixup part of op_call_arityCheck() and op_construct_arityCheck() and moved it to
        a thunk for the JITs and as assembly for the llint.  This patch provides the plumbing needed to
        move to the C stack for JS execution.  The fixup thunk and llint code would need to be change to
        work with a stack that grows down when we do move to the C stack.
        
        Due to an issue with the offline assembler, I moved the const at the top of LowLevelInterpreter64.asm
        and LowLevelInterpreter32_64.asm to LowLevelInterpreter.asm.  The problem is that a const defined in
        one file that are used in a macro doesn't resolve the const if the macro is used in another file.  This
        seemed like the quickest path.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::linkFunction):
        * dfg/DFGJITCompiler.h:
        (JITCompiler):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/JITStubs.h:
        * jit/ThunkGenerators.cpp:
        (JSC::arityFixup):
        * jit/ThunkGenerators.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):

2013-06-19  Michael Saboff  <msaboff@apple.com>

        FTL: arm build is broken in ToT
        https://bugs.webkit.org/show_bug.cgi?id=117800

        Unreviewed build fixes.

        * assembler/ARMv7Assembler.h:
        (ARMv7Assembler): Merge of r147941
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_op_mod): Moved variable declaration back inside #ifdef where used.

2013-06-17  Michael Saboff  <msaboff@apple.com>

        FTL: Add another temp register regT4 to JSInterfaceJIT
        https://bugs.webkit.org/show_bug.cgi?id=117719

        Reviewed by Geoffrey Garen.

        Made the dedicated bucketCounterRegister to be regT4 and then used regT4 wherever
        bucketCounterRegister had been used.  Since it is masked whenever it is used and
        we are looking for some randomness in the register anyway, we can use it without
        any issues.

        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        (JSC::JIT::emitValueProfilingSite):
        * jit/JITCall.cpp:
        (JSC::JIT::emitPutCallResult):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emitPutCallResult):
        * jit/JITInlines.h:
        (JSC::JIT::emitValueProfilingSite):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_this):
        (JSC::JIT::emit_op_get_callee):
        (JSC::JIT::emit_op_get_argument_by_val):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_callee):
        (JSC::JIT::emit_op_to_this):
        (JSC::JIT::emit_op_get_argument_by_val):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emitSlow_op_get_by_id):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        * jit/JITStubCall.h:
        (JSC::JITStubCall::callWithValueProfiling):
        * jit/JSInterfaceJIT.h:
        (JSInterfaceJIT):

2013-06-17  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support Switch
        https://bugs.webkit.org/show_bug.cgi?id=117704

        Reviewed by Oliver Hunt.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::clearImmediateSwitchJumpTables):
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::buildFPToSI):
        (JSC::FTL::buildSwitch):
        (JSC::FTL::addCase):
        (FTL):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileSwitch):
        (LowerDFGToLLVM):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::fpToInt):
        (JSC::FTL::Output::fpToInt32):
        (Output):
        (JSC::FTL::Output::switchInstruction):
        * ftl/FTLSwitchCase.h: Added.
        (FTL):
        (SwitchCase):
        (JSC::FTL::SwitchCase::SwitchCase):
        (JSC::FTL::SwitchCase::value):
        (JSC::FTL::SwitchCase::target):

2013-06-15  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Add CFG simplification for Switch
        https://bugs.webkit.org/show_bug.cgi?id=117677

        Reviewed by Mark Hahnenberg.
        
        This is for completeness. It only speeds up a microbenchmark at this point.
        Broadly, we want all control constructs to be known to the CFG simplifier.

        * dfg/DFGCFGSimplificationPhase.cpp:
        (JSC::DFG::CFGSimplificationPhase::run):
        (JSC::DFG::CFGSimplificationPhase::convertToJump):
        (CFGSimplificationPhase):
        (JSC::DFG::CFGSimplificationPhase::noBlocks):
        (JSC::DFG::CFGSimplificationPhase::oneBlock):
        (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
        * runtime/JSCJSValue.h:
        (JSValue):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::pureStrictEqual):
        (JSC):

2013-06-13  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should support op_switch_imm
        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):

2013-06-15  Filip Pizlo  <fpizlo@apple.com>

        Concurrent JIT shouldn't try to recompute the CodeBlockHash as part of debug dumps, since doing so may fail if dealing with a CachedScript that doesn't have its script string handy
        https://bugs.webkit.org/show_bug.cgi?id=117676

        Reviewed by Sam Weinig.

        CodeBlock now caches m_hash, and the DFG Driver will force its computation if we're doing debug dumps of any kind.
        
        Also made sure that CodeBlock::CodeBlock initializes all of its fields; it was previously missing the
        initialization of m_capabilityLevelState.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::hash):
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * bytecode/CodeBlockHash.cpp:
        (JSC::CodeBlockHash::CodeBlockHash):
        * bytecode/CodeBlockHash.h:
        (CodeBlockHash):
        (JSC::CodeBlockHash::isSet):
        (JSC::CodeBlockHash::operator!):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):

2013-06-11  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should support op_in and it should use patching to make it fast
        https://bugs.webkit.org/show_bug.cgi?id=117385

        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):

2013-06-12  Geoffrey Garen  <ggaren@apple.com>

        The Math object should not be polymorphic
        https://bugs.webkit.org/show_bug.cgi?id=117576

        Reviewed by Oliver Hunt.

        Fill in the Math object eagerly, to avoid its structure changing during
        execution. There are lots of ways to skin this cat; this one seemed
        easiest, and justified given the relative hotness of math operations.

        20% speedup on DSP-filtrr tests, small speedups on a few Kraken tests.

        * DerivedSources.make:
        * JavaScriptCore.order:
        * create_hash_table:
        * interpreter/CallFrame.h:
        (JSC::ExecState::jsonTable): Removed the Math object's static table.

        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectNativeFunctionWithoutTransition):
        * runtime/JSObject.h:
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        * runtime/MathObject.h:
        (JSC::MathObject::create): Set up the Math object at construction time.

        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        * runtime/VM.h: Removed the Math object's static table.

2013-06-09  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolled back in http://trac.webkit.org/changeset/151342.

        I filled in the missing return register loads, and tests
        seem to pass now.

                2013-06-07  Michael Saboff  <msaboff@apple.com>

                        fourthTier: The baseline jit and LLint should use common slow paths
                        https://bugs.webkit.org/show_bug.cgi?id=116889

2013-06-07  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, roll out http://trac.webkit.org/changeset/151342
        It broke Kraken crypto tests in debug build. That results in a pretty bad
        loss of test coverage.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JIT.cpp:
        (JSC):
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        (JIT):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitSlow_op_negate):
        (JSC::JIT::emitSlow_op_lshift):
        (JSC::JIT::emitSlow_op_rshift):
        (JSC::JIT::emitSlow_op_urshift):
        (JSC::JIT::emitSlow_op_bitand):
        (JSC::JIT::emitSlow_op_inc):
        (JSC::JIT::emitSlow_op_dec):
        (JSC::JIT::emitSlow_op_mod):
        (JSC::JIT::emit_op_mod):
        (JSC::JIT::compileBinaryArithOpSlowCase):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emitSlow_op_div):
        (JSC::JIT::emitSlow_op_sub):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emitSlow_op_negate):
        (JSC::JIT::emitSlow_op_lshift):
        (JSC::JIT::emitRightShiftSlowCase):
        (JSC::JIT::emitSlow_op_bitand):
        (JSC::JIT::emitSlow_op_bitor):
        (JSC::JIT::emitSlow_op_bitxor):
        (JSC::JIT::emitSlow_op_inc):
        (JSC::JIT::emitSlow_op_dec):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emitSlow_op_sub):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emitSlow_op_div):
        (JSC::JIT::emit_op_mod):
        (JSC::JIT::emitSlow_op_mod):
        * jit/JITExceptions.cpp:
        (JSC):
        (JSC::genericThrow):
        * jit/JITExceptions.h:
        (ExceptionHandler):
        (JSC):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_strcat):
        (JSC::JIT::emitSlow_op_create_this):
        (JSC::JIT::emitSlow_op_to_this):
        (JSC::JIT::emitSlow_op_to_primitive):
        (JSC::JIT::emitSlow_op_not):
        (JSC::JIT::emitSlow_op_bitxor):
        (JSC::JIT::emitSlow_op_bitor):
        (JSC::JIT::emitSlow_op_stricteq):
        (JSC::JIT::emitSlow_op_nstricteq):
        (JSC::JIT::emitSlow_op_to_number):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emitSlow_op_to_primitive):
        (JSC::JIT::emit_op_strcat):
        (JSC::JIT::emitSlow_op_not):
        (JSC::JIT::emitSlow_op_stricteq):
        (JSC::JIT::emitSlow_op_nstricteq):
        (JSC::JIT::emitSlow_op_to_number):
        (JSC::JIT::emit_op_create_arguments):
        (JSC::JIT::emitSlow_op_create_this):
        (JSC::JIT::emitSlow_op_to_this):
        (JSC::JIT::emitSlow_op_get_argument_by_val):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC):
        * jit/JITStubs.h:
        (JSC):
        * jit/JITStubsARM.h:
        (JSC):
        * jit/JITStubsARMv7.h:
        (JSC):
        * jit/JITStubsMIPS.h:
        (JSC):
        * jit/JITStubsSH4.h:
        (JSC):
        * jit/JITStubsX86.h:
        (JSC):
        * jit/JITStubsX86_64.h:
        (JSC):
        * jit/JSInterfaceJIT.h:
        (JSInterfaceJIT):
        * jit/SlowPathCall.h: Removed.
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (LLInt):
        * llint/LLIntSlowPaths.h:
        (LLInt):
        (SlowPathReturnType):
        (JSC::LLInt::encodeResult):
        (JSC::LLInt::decodeResult):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp: Removed.
        * runtime/CommonSlowPaths.h:
        * runtime/JSCJSValue.h:
        (JSValue):

2013-06-07  Michael Saboff  <msaboff@apple.com>

        fourthTier: The baseline jit and LLint should use common slow paths
        https://bugs.webkit.org/show_bug.cgi?id=116889

        Reviewed by Filip Pizlo.

        Moved the llint_slow_paths that return JSValue along with several others to CommonSlowPaths.cpp.
        Eliminated the related JIT stubs.  Changes the baseline JIT to call these new common stubs.
        Added a simple slow path call class that uses argument registers or the stack instead of
        JITStackFrame.  Changes the exception mechanism for to check for an exception after making
        a slowpath call instead of returning to the handler directly form the slowpath function.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        (JIT):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emitSlow_op_negate):
        (JSC::JIT::emitSlow_op_lshift):
        (JSC::JIT::emitSlow_op_rshift):
        (JSC::JIT::emitSlow_op_urshift):
        (JSC::JIT::emitSlow_op_bitand):
        (JSC::JIT::emitSlow_op_inc):
        (JSC::JIT::emitSlow_op_dec):
        (JSC::JIT::emitSlow_op_mod):
        (JSC::JIT::emit_op_mod):
        (JSC::JIT::compileBinaryArithOpSlowCase):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emitSlow_op_div):
        (JSC::JIT::emitSlow_op_sub):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emitSlow_op_negate):
        (JSC::JIT::emitSlow_op_lshift):
        (JSC::JIT::emitRightShiftSlowCase):
        (JSC::JIT::emitSlow_op_bitand):
        (JSC::JIT::emitSlow_op_bitor):
        (JSC::JIT::emitSlow_op_bitxor):
        (JSC::JIT::emitSlow_op_inc):
        (JSC::JIT::emitSlow_op_dec):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emitSlow_op_sub):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emitSlow_op_div):
        (JSC::JIT::emit_op_mod):
        (JSC::JIT::emitSlow_op_mod):
        * jit/JITExceptions.cpp:
        (JSC::getExceptionLocation):
        (JSC::genericThrow):
        (JSC::jitThrowNew):
        * jit/JITExceptions.h:
        (ExceptionHandler):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_strcat):
        (JSC::JIT::emitSlow_op_create_this):
        (JSC::JIT::emitSlow_op_to_this):
        (JSC::JIT::emitSlow_op_to_primitive):
        (JSC::JIT::emitSlow_op_not):
        (JSC::JIT::emitSlow_op_bitxor):
        (JSC::JIT::emitSlow_op_bitor):
        (JSC::JIT::emitSlow_op_stricteq):
        (JSC::JIT::emitSlow_op_nstricteq):
        (JSC::JIT::emitSlow_op_to_number):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emitSlow_op_to_primitive):
        (JSC::JIT::emit_op_strcat):
        (JSC::JIT::emitSlow_op_not):
        (JSC::JIT::emitSlow_op_stricteq):
        (JSC::JIT::emitSlow_op_nstricteq):
        (JSC::JIT::emitSlow_op_to_number):
        (JSC::JIT::emit_op_create_arguments):
        (JSC::JIT::emitSlow_op_create_this):
        (JSC::JIT::emitSlow_op_to_this):
        (JSC::JIT::emitSlow_op_get_argument_by_val):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::cti_vm_throw_slowpath):
        * jit/JITStubs.h:
        * jit/JITStubsARM.h:
        * jit/JITStubsARMv7.h:
        * jit/JITStubsMIPS.h:
        * jit/JITStubsSH4.h:
        * jit/JITStubsX86.h:
        * jit/JITStubsX86_64.h:
        * jit/JSInterfaceJIT.h:
        (JSInterfaceJIT):
        * jit/SlowPathCall.h: Added.
        (JITSlowPathCall):
        (JSC::JITSlowPathCall::JITSlowPathCall):
        (JSC::JITSlowPathCall::call):
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        * llint/LLIntSlowPaths.cpp:
        (LLInt):
        * llint/LLIntSlowPaths.h:
        (LLInt):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp: Added.
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (SlowPathReturnType):
        (JSC::encodeResult):
        (JSC::decodeResult):
        * runtime/JSCJSValue.h:
        (JSValue):

2013-06-11  Geoffrey Garen  <ggaren@apple.com>

        Rolled back in <http://trac.webkit.org/changeset/151363>.

        Rubber stamped by Phil Pizlo.

        The ASSERTs were due to the bytecode parser performing a
        StructureTransitionWatchpoint optimization in a case where the CFA
        wouldn't because the CFA could prove that the watchpoint would contradict
        a preceding CheckStructure.

        I fixed this by removing the bytecode parser optimization: now, we fully
        rely on CFA and constant folding to optimize structure checks when
        possible.

        I verified that there's no performance change vs doing the optimization
        in the bytecode parser. (The optimization is very simple, so this is not
        surprising.)

2013-06-10  Mark Hahnenberg  <mhahnenberg@apple.com>

        isContravenedByStructure is backwards
        https://bugs.webkit.org/show_bug.cgi?id=117366

        We should be checking if arrayModeForStructure(structure) is a 
        subset of arrayModesThatPassFiltering(), not the other way around.
        Also renamed isContravenedByStructure to better reflect what the 
        function is trying to determine.

        Rubber stamped by Filip Pizlo.

        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::structureWouldPassArrayModeFiltering):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheckAccountingForArrayMode):
        (JSC::DFG::ArrayTypeCheck::isContravenedByValue):

2013-06-10  Mark Hahnenberg  <mhahnenberg@apple.com>

        isContravenedByStructure is backwards
        https://bugs.webkit.org/show_bug.cgi?id=117366

        We should be checking if arrayModeForStructure(structure) is a 
        subset of arrayModesThatPassFiltering(), not the other way around.
        Also renamed isContravenedByStructure to better reflect what the 
        function is trying to determine.

        Rubber stamped by Filip Pizlo.

        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::structureWouldPassArrayModeFiltering):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheckAccountingForArrayMode):
        (JSC::DFG::ArrayTypeCheck::isContravenedByValue):

2013-06-11  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Type check hoisting phase has a dead if statement
        https://bugs.webkit.org/show_bug.cgi?id=117510

        Reviewed by Geoffrey Garen.

        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):

2013-06-10  Mark Lam  <mark.lam@apple.com>

        Introducing the StackIterator class.
        https://bugs.webkit.org/show_bug.cgi?id=117390.

        Reviewed by Geoffrey Garen.

        The StackIterator class is meant to unify the way we iterate the JS
        stack. It also makes it so that we don't have to copy the frame data
        into the intermediate StackFrame struct before processing it.
        Unfortunately we still can't get rid of StackFrame because it is used
        to record frame information for the Exception stack that is expected
        to persist beyond when the frames have been popped off the JS stack.

        The StackIterator will iterate over all "logical" frames (i.e. including
        inlined frames). As it iterates the JS stack, if it encounters a DFG
        frame that has inlined frames, the iterator will canonicalize the
        inlined frames before returning. Once canonicalized, the frame can be
        read like any other frame.

        The StackIterator implements a Frame class that inherits from CallFrame.
        The StackIterator::Frame serves as reader of the CallFrame that makes
        it easier to access information about the frame. The StackIterator::Frame
        only adds functions, and no additional data fields.

        * API/JSContextRef.cpp:
        (JSContextCreateBacktrace):
        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::begin):
        (JSC::CallFrame::beginAt):
        * interpreter/CallFrame.h:
        (JSC::ExecState::setInlineCallFrame):
        (ExecState):
        (JSC::ExecState::end):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters):
        (JSC::Interpreter::unwindCallFrame):
        (JSC::Interpreter::getStackTrace):
        (JSC::Interpreter::throwException):
        (JSC::Interpreter::debug):
        * interpreter/Interpreter.h:
        (Interpreter):
        * interpreter/StackIterator.cpp: Added.
        (JSC::StackIterator::StackIterator):
        (JSC::StackIterator::beginAt):
        (JSC::StackIterator::gotoNextFrame):
        - Based on the deleted Interpreter::findFunctionCallFrameFromVMCode().
        (JSC::StackIterator::findFrameForFunction):
        - Based on the deleted Interpreter::retrieveCallerFromVMCode().
        (JSC::StackIterator::Frame::codeType):
        - Based on the deleted getStackFrameCodeType().
        (JSC::StackIterator::Frame::functionName):
        - Based on StackFrame::friendlyFunctionName().
        (JSC::StackIterator::Frame::sourceURL):
        - Based on StackFrame::friendlySourceURL().
        (JSC::StackIterator::Frame::toString):
        - Based on StackFrame::toString().
        (JSC::StackIterator::Frame::bytecodeOffset):
        (JSC::StackIterator::Frame::line):
        - Based on StackFrame::line().
        (JSC::StackIterator::Frame::column):
        - Based on StackFrame::column().
        (JSC::StackIterator::Frame::arguments):
        - Based on the deleted Interpreter::retrieveArgumentsFromVMCode().
        (JSC::StackIterator::Frame::retrieveExpressionInfo):
        - Based on StackFrame::expressionInfo().
        (JSC::StackIterator::Frame::logicalFrame):
        - Based on the now deleted CallFrame::trueCallFrame().
        (JSC::StackIterator::Frame::logicalCallerFrame):
        - Based on the now deleted CallFrame::trueCallerFrame().
        (JSC::jitTypeName):
        (JSC::printIndents):
        (JSC::printif):
        (JSC::StackIterator::Frame::print):
        (debugPrintCallFrame):
        - Prints the contents of the frame for debugging purposes.
          There are 2 versions that can be used as follows:

          1. When you have a valid StackIterator, you can print
             the current frame's content using the print instance
             method:
                 iter->print(indentLevel);

          2. When you have a CallFrame* that you want to dump from a debugger
             console, you can print its content as follows:
                 (gdb) call debugPrintCallFrame(callFrame)

          A sample of the output looks like this:

              frame 0x1510c70b0 {
                 name 'shouldBe'
                 sourceURL 'testapi.js'
                 hostFlag 0
                 isInlinedFrame 0
                 callee 0x15154efb0
                 returnPC 0x10ed0786d
                 callerFrame 0x1510c7058
                 logicalCallerFrame 0x1510c7058
                 rawLocationBits 27 0x1b
                 codeBlock 0x7fe79b037200
                    bytecodeOffset 27 0x1b / 210
                    line 46
                    column 20
                    jitType 3 <BaselineJIT> isOptimizingJIT 0
                    hasCodeOrigins 0
              }

        * interpreter/StackIterator.h: Added.
        (StackIterator::Frame):
        (JSC::StackIterator::Frame::create):
        (JSC::StackIterator::Frame::isJSFrame):
        (JSC::StackIterator::Frame::callFrame):
        * interpreter/StackIteratorPrivate.h: Added.
        (StackIterator):
        (JSC::StackIterator::operator*):
        (JSC::StackIterator::operator->):
        (JSC::StackIterator::operator==):
        (JSC::StackIterator::operator!=):
        (JSC::StackIterator::operator++):
        (JSC::StackIterator::end):
        (JSC::StackIterator::empty):
        * jsc.cpp:
        (functionJSCStack):
        * profiler/ProfileGenerator.cpp:
        (JSC::ProfileGenerator::addParentForConsoleStart):
        * profiler/ProfileNode.h:
        (ProfileNode):
        * runtime/JSFunction.cpp:
        (JSC::retrieveArguments):
        (JSC::JSFunction::argumentsGetter):
        (JSC::skipOverBoundFunctions):
        (JSC::retrieveCallerFunction):
        (JSC::JSFunction::callerGetter):
        (JSC::JSFunction::getOwnPropertyDescriptor):
        (JSC::JSFunction::defineOwnProperty):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncProtoGetter):
        (JSC::globalFuncProtoSetter):
        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorGetPrototypeOf):
        * runtime/Operations.h:

2013-06-09  Filip Pizlo  <fpizlo@apple.com>

        Marge trunk r146653.

    2013-03-22  Filip Pizlo  <fpizlo@apple.com>
    
            DFG folding of PutById to SimpleReplace should consider the specialized function case
            https://bugs.webkit.org/show_bug.cgi?id=113093
    
            Reviewed by Geoffrey Garen and Mark Hahnenberg.
    
            * bytecode/PutByIdStatus.cpp:
            (JSC::PutByIdStatus::computeFor):
    
2013-06-09  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG GetById patching shouldn't distinguish between self lists and proto lists
        https://bugs.webkit.org/show_bug.cgi?id=117377

        Reviewed by Geoffrey Garen.
        
        Previously if you did self accesses and then wanted to do a prototype access, you'd
        have a bad time: the prototype accesses would be forced to take slow path because
        the self list wouldn't allow prototype accesses. Likewise if you did prototype (or
        chain) accesses and then wanted to do a self access, similar stupidity would ensue.
        
        This fixes the stupidity.

        I believe that this was introduced way back in the days of the old interpreter,
        where distinguishing between self lists, proto lists, and chain lists was meaningful
        for interpreter performance: it meant fewer branches to evaluate those lists. Then
        it got mostly carried over to the old JIT since the old JIT was just initially an
        optimized version of the old interpreter, and then later it got carried over to the
        DFG because I didn't know any better at the time. Now I do know better and I'm
        fixing it.

        * bytecode/PolymorphicAccessStructureList.h:
        (JSC::PolymorphicAccessStructureList::PolymorphicStubInfo::set):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::initGetByIdSelfList):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::getPolymorphicStructureList):
        (DFG):
        (JSC::DFG::patchJumpToGetByIdStub):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::dfgBuildGetByIDList):

2013-06-09  Mark Lam  <mark.lam@apple.com>

        Fix broken no-DFG build.
        https://bugs.webkit.org/show_bug.cgi?id=117381.

        Reviewed by Geoffrey Garen.

        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (ProgramCodeBlock):
        (EvalCodeBlock):
        (FunctionCodeBlock):
        * dfg/DFGCapabilities.h:
        * dfg/DFGDriver.h:
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        * dfg/DFGJITCode.cpp:
        * dfg/DFGRepatch.h:
        (JSC::DFG::dfgResetGetByID):
        (JSC::DFG::dfgResetPutByID):
        * heap/DFGCodeBlocks.cpp:
        (JSC::DFGCodeBlocks::jettison):
        * interpreter/CallFrame.h:
        (ExecState):
        (JSC::ExecState::trueCallFrame):
        * interpreter/Interpreter.cpp:
        (JSC::getCallerInfo):
        * runtime/Executable.cpp:
        * runtime/Executable.h:
        (EvalExecutable):
        (ProgramExecutable):
        (FunctionExecutable):
        * runtime/ExecutionHarness.h:
        * runtime/VM.cpp:
        (JSC::VM::~VM):

2013-06-08  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Recursive deadlock in DFG::ByteCodeParser
        https://bugs.webkit.org/show_bug.cgi?id=117376

        Reviewed by Mark Hahnenberg.
        
        Leave the lock early to prevent a deadlock beneath get().

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

2013-06-08  Mark Lam  <mark.lam@apple.com>

        Removed bogus assertion in CallFrame::setLocationAsBytecodeOffset().
        https://bugs.webkit.org/show_bug.cgi?id=117373.

        Reviewed by Oliver Hunt.

        The assertion wrongly assumes that the incoming offset argument is in
        units of bytes. This is not true. It is in units of Instruction*. Hence,
        the assertion which checks for the low 2 bits to be clear can fail.

        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::setLocationAsBytecodeOffset):

2013-06-07  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: don't insert ForceOSRExits except for inadequate coverage
        https://bugs.webkit.org/show_bug.cgi?id=117363

        Reviewed by Mark Hahnenberg.
        
        Previously (in http://trac.webkit.org/changeset/151303) I made it so that we
        inserted ForceOSRExits more eagerly.  I now think it's better to have
        contradictions execute normally and exit with full OSR exit profiling.  It's
        better at catching the few cases where the DFG will end up with different
        types than the baseline engines.
        
        This simplifies a bunch of code. For example it gets rid of
        ConstantFoldingPhase::paintUnreachableCode().
        
        You can think of this as a partial roll-out of r151303, except that it uses
        the facilities introduced by that patch to give us run-time assertions that
        check the CFA's correctness: if the CFA thought that something was a
        contradiction but the code didn't exit, we'll now trap.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::AbstractState):
        (JSC::DFG::AbstractState::startExecuting):
        (JSC::DFG::AbstractState::executeEffects):
        (JSC::DFG::AbstractState::execute):
        (JSC::DFG::AbstractState::filter):
        (JSC::DFG::AbstractState::filterArrayModes):
        (JSC::DFG::AbstractState::filterByValue):
        (DFG):
        * dfg/DFGAbstractState.h:
        (AbstractState):
        (JSC::DFG::AbstractState::filter):
        (JSC::DFG::AbstractState::filterArrayModes):
        (JSC::DFG::AbstractState::filterByValue):
        * dfg/DFGCFAPhase.cpp:
        (JSC::DFG::CFAPhase::performBlockCFA):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run):
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (ConstantFoldingPhase):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):

2013-06-07  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix release build.

        * ftl/FTLLink.cpp:

2013-06-06  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Reenable the DFG optimization fixpoint now that it's profitable to do so with concurrent compilation
        https://bugs.webkit.org/show_bug.cgi?id=117331

        Rubber stamped by Sam Weinig.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):

2013-06-05  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG CFA should know when it hits a contradiction
        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):

2013-06-07  Mark Lam  <mark.lam@apple.com>

        32-bit CallFrame::Location should use Instruction* for BytecodeLocation, not bytecodeOffset.
        https://bugs.webkit.org/show_bug.cgi?id=117327.

        Reviewed by Michael Saboff.

        - Renamed CallFrame::Location's Type to TypeTag.
        - Made the CallFrame::Location::TypeTag private, and provided type
          specific encoder functions. This reduces verbosity in client code.
        - Fixed the DFG's reifyInlinedCallFrames() on 32-bit ports to store a
          bytecode Instruction* in the CallFrame location instead of a bytecode
          offset.
        - Fixed places in JIT and FTL code which populate the CallFrame location
          (i.e. ArgumentCount tag) to use a Location encoder instead of storing
          the bytecodeOffset directly. This doesn't make any semantic difference,
          but it does assert that the stored value does not have bits where we
          would expect Location TypeTags to be.

        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::beginCall):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::setLocationAsBytecodeOffset):
        * interpreter/CallFrame.h:
        (Location):
        * interpreter/CallFrameInlines.h:
        (JSC::CallFrame::Location::encodeAsBytecodeOffset):
        (JSC::CallFrame::Location::encodeAsBytecodeInstruction):
        (JSC::CallFrame::Location::encodeAsCodeOriginIndex):
        (JSC::CallFrame::Location::encodeAsInlinedCode):
        (JSC::CallFrame::Location::isBytecodeLocation):
        (JSC::CallFrame::setIsInlinedFrame):
        (JSC::CallFrame::hasLocationAsBytecodeOffset):
        (JSC::CallFrame::setLocationAsBytecodeOffset):
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileOpCall):
        * jit/JITInlines.h:
        (JSC::JIT::updateTopCallFrame):

2013-06-06  Mark Lam  <mark.lam@apple.com>

        Encode CallFrame::Location flags in the low bits when USE(JSVALUE32_64).
        https://bugs.webkit.org/show_bug.cgi?id=117312.

        Reviewed by Michael Saboff.

        For USE(JSVALUE32_64), we store the location flags in the low 2 bits of
        the word because we need the high bits for address bits.

        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::setLocationAsBytecodeOffset):
        * interpreter/CallFrame.h:
        * interpreter/CallFrameInlines.h:
        (JSC::CallFrame::Location::encode):
        (JSC::CallFrame::Location::decode):
        (JSC::CallFrame::Location::isCodeOriginIndex):
        (JSC::CallFrame::Location::isInlinedCode):

2013-06-06  Mark Lam  <mark.lam@apple.com>

        CallFrame::trueCallFrame() should populate the bytecodeOffset field
        when reifying inlined frames..
        https://bugs.webkit.org/show_bug.cgi?id=117209.

        Reviewed by Geoffrey Garen.

        When reifying an inlined frame, we fill in its CodeBlock, and
        bytecodeOffset. We also set the InlinedFrame bit in the location field.
        This is needed in order to iterate the stack correctly. Here's why:

            Let's say we have the following stack trace:
              X calls A inlines B inlines C calls D

            Based on the above scenario,
            1. D's callerFrame points to A (not C).
            2. A has a codeOriginIndex that points to C.

        When iterating the stack (from D back towards X), we will encounter A
        twice:

            t1. when trying to find C as D's caller.
                This is the time when we reify B and C using the
                codeOriginIndex in A, and return C as the caller frame of D.

            t2. when getting's the reified B's caller.
                This time, we don't run the reification process, and
                just take A as the caller frame of B.

        To discern which treatment of the DFG frame (i.e. A) we need to apply,
        we check if the callee is an inlined frame:

            If callee is NOT an inlined frame (e.g. frame D), apply treatment t1.
            If callee is an inlined frame (e.g. frame B), apply treatment t2.

        Why not just reify A by replacing its codeOriginIndex with A's
        bytecodeOffset?

        We can't do this because D's callerFrame pointer still points to A, and
        needs to remain that way because we did not deopt A. It remains a DFG
        frame which inlined B and C.

        If we replace the codeOriginIndex in A with A's bytecodeOffset, we will
        only get to iterate the stack correctly once. If we try to iterate the
        stack a second time, we will not have the information from the
        codeOriginIndex to tell us that D's caller is actually the inlined C,
        and not A.

        To recap, when reifying frames for stack iteration purposes, the DFG
        frame needs to hold on to its codeOriginIndex. This in turn means the
        DFG frame will need to be treated in 2 possible ways, and we need to
        know if a callee frame is an inlined frame in order to choose the
        correct treatment for the DFG frame.

        Other changes:
        - Simplified Interpreter::getCallerInfo().
        - Removed CodeBlock::codeOriginForReturn() and supporting code
          which is now unneeded.
        - Moved CallFrame location bit encoding from the CodeOrigin to the
          new CallFrame::Location class.
        - Explicitly tagged inlined frames. This is necessary in order to
          iterate the stack correctly as explained above.

        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::codeOrigins):
        (CodeBlock):
        (JSC::CodeBlock::codeOrigin):
        (RareData):
        * bytecode/CodeOrigin.h:
        (CodeOrigin):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::beginCall):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::trueCallFrame):
        (JSC::CallFrame::trueCallerFrame):
        (JSC::CallFrame::bytecodeOffsetFromCodeOriginIndex):
        * interpreter/CallFrame.h:
        (Location):
        (ExecState):
        (JSC::ExecState::trueCallerFrame):
        (JSC::ExecState::callerFrameNoFlags):
        * interpreter/CallFrameInlines.h:
        (JSC::CallFrame::Location::encode):
        (JSC::CallFrame::Location::decode):
        (JSC::CallFrame::Location::isBytecodeOffset):
        (JSC::CallFrame::Location::isCodeOriginIndex):
        (JSC::CallFrame::Location::isInlinedFrame):
        (JSC::CallFrame::isInlinedFrame):
        (JSC::CallFrame::setIsInlinedFrame):
        (JSC::CallFrame::hasLocationAsBytecodeOffset):
        (JSC::CallFrame::hasLocationAsCodeOriginIndex):
        (JSC::CallFrame::locationAsBytecodeOffset):
        (JSC::CallFrame::setLocationAsBytecodeOffset):
        (JSC::CallFrame::locationAsCodeOriginIndex):
        * interpreter/Interpreter.cpp:
        (JSC::getCallerInfo):
        (JSC::Interpreter::getStackTrace):
        (JSC::Interpreter::findFunctionCallFrameFromVMCode):
        * runtime/Arguments.cpp:
        (JSC::Arguments::tearOff):

2013-06-05  Filip Pizlo  <fpizlo@apple.com>

        DFG CFA shouldn't filter ArrayModes with ALL_NON_ARRAY_ARRAY_MODES if the speculated type is not SpecArray
        https://bugs.webkit.org/show_bug.cgi?id=117279

        Reviewed by Mark Hahnenberg.
        
        The normalization of abstract value clarity introduced in r151229 revealed a
        long-standing bug where we filtered ArrayModes incorrectly and sometimes ended
        up with BOTTOM incorrectly.
        
        This patch fixes that bug, and cleans up a bunch of debugging infrastructure
        that I needed to resurrect to track this down.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resetStubInternal):
        (JSC::CodeBlock::noticeIncomingCall):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::filterArrayModesByType):
        * dfg/DFGCFAPhase.cpp:
        (CFAPhase):
        (JSC::DFG::CFAPhase::run):
        (JSC::DFG::CFAPhase::performBlockCFA):
        (JSC::DFG::CFAPhase::performForwardCFA):
        * runtime/Options.h:
        (JSC):

2013-06-05  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix release build.

        * interpreter/Interpreter.cpp:
        * jit/JITStubs.cpp:

2013-06-05  Mark Lam  <mark.lam@apple.com>

        Disambiguate between CallFrame bytecodeOffset and codeOriginIndex.
        https://bugs.webkit.org/show_bug.cgi?id=117262.

        Reviewed by Geoffrey Garen.

        When writing to the ArgumentCount tag in CallFrame, we will set the high
        bit if the written value is a codeOriginIndex.

        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeOrigin.h:
        (CodeOrigin):
        (JSC::CodeOrigin::isHandle):
        (JSC::CodeOrigin::encodeHandle):
        (JSC::CodeOrigin::decodeHandle):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::beginCall):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryBuildGetByIDList):
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::locationAsBytecodeOffset):
        (JSC::CallFrame::setLocationAsBytecodeOffset):
        (JSC::CallFrame::currentVPC):
        (JSC::CallFrame::setCurrentVPC):
        (JSC::CallFrame::trueCallFrame):
        * interpreter/CallFrame.h:
        (ExecState):
        (JSC::ExecState::inlineCallFrame):
        * interpreter/CallFrameInlines.h: Added.
        (JSC::CallFrame::hasLocationAsBytecodeOffset):
        (JSC::CallFrame::hasLocationAsCodeOriginIndex):
        (JSC::CallFrame::locationAsRawBits):
        (JSC::CallFrame::setLocationAsRawBits):
        (JSC::CallFrame::locationAsBytecodeOffset):
        (JSC::CallFrame::setLocationAsBytecodeOffset):
        (JSC::CallFrame::locationAsCodeOriginIndex):
        * interpreter/Interpreter.cpp:
        (JSC::getBytecodeOffsetForCallFrame):
        (JSC::getCallerInfo):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):

2013-06-05  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix release build.

        * interpreter/Interpreter.cpp:
        * jit/JITStubs.cpp:

2013-06-04  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Clean up AbstractValue
        https://bugs.webkit.org/show_bug.cgi?id=117217

        Reviewed by Oliver Hunt.
        
        This started as an attempt to make it so that when AbstractValue becomes empty,
        its m_type always becomes SpecNone. I wanted this to happen naturally. That turns
        out to be basically impossible, since AbstractValue is a set that is dynamically
        computed from the intersection of several internal sets: so the value becomes
        empty when any of the sets go empty. It's OK if we're imprecise here because it's
        always safe for the AbstractValue to seem to overapproximate the set of values
        that we see. So I mostly gave up on cleaning up that aspect of AbstractValue. But
        while trying to make this happen, I encountered two bugs:
        
        - filterValueByType() ignores the case when m_type contravenes m_value. Namely,
          we might filter the AbstractValue against a SpeculatedType leading to m_value
          becoming inconsistent with the new m_type. This change fixes that case. This
          wasn't a symptomatic bug but it was a silly oversight.
        
        - filterFuturePossibleStructure() was never right. The one call to this method,
          in filter(Graph&, const StructureSet&), assumed that the previous notions of
          what structures the value could have in the future were still relevant. This
          could lead to a bug where we:
          
          1) CheckStructure(@foo, S1)
          
             Where S1 has a valid watchpoint. Now @foo's abstract value will have current
             and future structure = S1.
          
          2) Clobber the world.
          
             Now @foo's abstract value will have current structure = TOP, and future
             possible structure = S1.
          
          3) CheckStructure(@foo, S2)
          
             Now @foo's abstract value will have current structure = S2 and future
             possible structure = S1 intersect S2 = BOTTOM.
          
          Now we will think that any subsequent watchpoint on @foo is valid because the
          value is effectively BOTTOM. That would only be correct if we had actually set
          a watchpoint on S1. If we had done so, then (3) would only pass (i.e. @foo
          would only have structure S2) if S1's watchpoint fired, in which case (3)
          wouldn't have been reachable. But we didn't actually set a watchpoint on S1:
          we just observed that we *could* have set the watchpoint. Hence future possible
          structure should only be set to either the known structure at compile-time, or
          it should be the structure we just checked; in both cases it should only be set
          if the structure is watchable.
        
        Then, in addition to all of this, I changed AbstractValue's filtering methods to
        call clear() if the AbstractValue is effectively clear. This is just meant to
        simplify the recognition of truly empty AbstractValues, but doesn't actually have
        any other implications.

        * bytecode/StructureSet.h:
        (JSC::StructureSet::dump):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::filter):
        (DFG):
        (JSC::DFG::AbstractValue::filterArrayModes):
        (JSC::DFG::AbstractValue::filterValueByType):
        (JSC::DFG::AbstractValue::filterArrayModesByType):
        (JSC::DFG::AbstractValue::shouldBeClear):
        (JSC::DFG::AbstractValue::normalizeClarity):
        (JSC::DFG::AbstractValue::checkConsistency):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::isClear):
        (AbstractValue):

2013-06-04  Mark Lam  <mark.lam@apple.com>

        The DFG JIT should populate frame bytecodeOffsets on OSR exit.
        https://bugs.webkit.org/show_bug.cgi?id=117103.

        Reviewed by Geoffrey Garen.

        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):

2013-06-03  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: all cached put_by_id transitions, even ones that weren't inlined by the DFG, should be propagated by the GC
        https://bugs.webkit.org/show_bug.cgi?id=117170

        Reviewed by Mark Hahnenberg.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitAggregate):
        (JSC::CodeBlock::propagateTransitions):
        (JSC):
        (JSC::CodeBlock::determineLiveness):
        (JSC::CodeBlock::visitWeakReferences):
        (JSC::CodeBlock::finalizeUnconditionally):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * bytecode/PolymorphicPutByIdList.h:
        (JSC):
        (PutByIdAccess):
        (PolymorphicPutByIdList):
        * bytecode/StructureStubInfo.h:
        (StructureStubInfo):
        * jit/JITCode.h:
        (JSC::JITCode::couldBeInterpreted):
        (JITCode):

2013-06-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Get rid of StructureStubInfo::bytecodeIndex
        https://bugs.webkit.org/show_bug.cgi?id=117127

        Reviewed by Mark Hahnenberg.
        
        StructureStubInfo already has a CodeOrigin field, which also has a bytecodeIndex.
        It makes sense to just always use the CodeOrigin.

        * bytecode/StructureStubInfo.h:
        (StructureStubInfo):
        (JSC::getStructureStubInfoBytecodeIndex):
        * jit/JIT.cpp:
        (JSC::PropertyStubCompilationInfo::copyToStubInfo):
        * jit/JIT.h:
        (JSC::JIT::compileGetByIdProto):
        (JSC::JIT::compileGetByIdSelfList):
        (JSC::JIT::compileGetByIdProtoList):
        (JSC::JIT::compileGetByIdChainList):
        (JSC::JIT::compileGetByIdChain):
        (JSC::JIT::compilePutByIdTransition):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):

2013-06-01  Filip Pizlo  <fpizlo@apple.com>

        Fix some minor issues in the DFG's profiling of heap accesses
        https://bugs.webkit.org/show_bug.cgi?id=113010

        Reviewed by Goeffrey Garen.
        
        Carefully merge r146669 from trunk. This required some fiddling since it
        wasn't a clean apply.
        
        Original changelog:

            1) If a CodeBlock gets jettisoned by GC, we should count the exit sites.
    
            2) If a CodeBlock clears a structure stub during GC, it should record this, and
            the DFG should prefer to not inline that access (i.e. treat it as if it had an
            exit site).
    
            3) If a PutById was seen by the baseline JIT, and the JIT attempted to cache it,
            but it chose not to, then assume that it will take slow path.
    
            4) If we frequently exited because of a structure check on a weak constant,
            don't try to inline that access in the future.
    
            5) Treat all exits that were counted as being frequent.
            
            81% speed-up on Octane/gbemu. Small speed-ups elsewhere, and no regressions.
    
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC):
        (JSC::CodeBlock::resetStubDuringGCInternal):
        (JSC::CodeBlock::reoptimize):
        (JSC::CodeBlock::jettison):
        (JSC::ProgramCodeBlock::jettisonImpl):
        (JSC::EvalCodeBlock::jettisonImpl):
        (JSC::FunctionCodeBlock::jettisonImpl):
        (JSC::CodeBlock::tallyFrequentExitSites):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::tallyFrequentExitSites):
        (ProgramCodeBlock):
        (EvalCodeBlock):
        (FunctionCodeBlock):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::StructureStubInfo):
        (StructureStubInfo):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGOSRExitBase.cpp:
        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGOSRExitBase.h:
        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
        (OSRExitBase):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/Options.h:
        (JSC):

2013-05-31  Filip Pizlo  <fpizlo@apple.com>

        Remove CodeOrigin::valueProfileOffset since it was only needed for op_call_put_result.

        Rubber stamped by Mark Hahnenberg.

        * bytecode/CodeOrigin.h:
        (CodeOrigin):
        (JSC::CodeOrigin::CodeOrigin):
        (JSC::CodeOrigin::isSet):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::currentCodeOrigin):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::valueProfileFor):

2013-05-31  Filip Pizlo  <fpizlo@apple.com>

        Remove finalDestinationOrIgnored since it isn't called anymore.

        Rubber stamped by Mark Hahnenberg.

        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):

2013-05-31  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: get rid of op_call_put_result
        https://bugs.webkit.org/show_bug.cgi?id=117047

        Reviewed by Gavin Barraclough.
        
        op_call_put_result is an oddball. Its semantics are that it takes the return
        value of a call instruction, which is set aside in regT0/regT1, and places them
        into some stack slot. This is weird since there is an implicit contract with the
        preceding bytecode instruction, and it's even weirder since it means that it
        doesn't make sense to jump to it; for example OSR exit from the preceding call
        instruction must make sure to jump over the op_call_put_result.
        
        So this patch gets rid of op_call_put_result:
        
        - In bytecode, all calls return a value and we always allocate a temporary for
          that value even if it isn't used.
        
        - The LLInt does the return value saving as part of dispatchAfterCall().
        
        - The JIT and DFG do the return value saving as part of normal code generation.
          The DFG already did the right thing.
        
        - DFG->JIT OSR exit in the case of inlining will make the return PC's point at
          the CallLinkInfo::callReturnLocation, rather than the machine PC associated
          with the op_call_put_result instruction.
        
        - Tons of code gets removed. The DFG had to track whether or not a call had a
          return value in a bunch of places. It had to track the fact that we would
          exit to after the op_call_put_result. It was a mess. That mess is now gone.

        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromLLInt):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printCallOp):
        (JSC::CodeBlock::dumpArrayProfiling):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargs):
        (JSC::BytecodeGenerator::emitConstruct):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::NewExprNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::FunctionCallBracketNode::emitBytecode):
        (JSC::FunctionCallDotNode::emitBytecode):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::ByteCodeParser):
        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::currentCodeOrigin):
        (JSC::DFG::ByteCodeParser::addCall):
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::getPrediction):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleMinMax):
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        (JIT):
        * jit/JITCall.cpp:
        (JSC::JIT::emitPutCallResult):
        (JSC::JIT::compileLoadVarargs):
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::emit_op_call):
        (JSC):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_construct):
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_construct):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emitPutCallResult):
        (JSC::JIT::compileLoadVarargs):
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        * jit/JITOpcodes.cpp:
        (JSC):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::genericCall):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2013-05-30  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: LLInt shouldn't store an offset call PC during op_call-like calls
        https://bugs.webkit.org/show_bug.cgi?id=117048

        Reviewed by Mark Hahnenberg.
        
        This just makes everything consistent in the LLInt: anytime any op calls out,
        it stores its PC and never the next op's PC.
        
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::linkIncomingCall):
        (JSC::CodeBlock::bytecodeOffset):
        * bytecode/CodeBlock.h:
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCallVarargs):
        * llint/LLIntExceptions.cpp:
        (JSC::LLInt::interpreterThrowInCaller):
        (JSC::LLInt::returnToThrow):
        (JSC::LLInt::callToThrow):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2013-05-28  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support ArithAbs
        https://bugs.webkit.org/show_bug.cgi?id=116890

        Reviewed by Oliver Hunt.
        
        Implements ArithAbs in the FTL, and cleans up the DFG implementation. The
        DFG implementation was previously doing zero extensions manually when it
        is probably better to just use StrictInt32Operand instead.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLIntrinsicRepository.h:
        (FTL):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileArithAbs):
        (LowerDFGToLLVM):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::doubleAbs):

2013-05-28  Mark Lam  <mark.lam@apple.com>

        Misc JIT probe enhacements.
        https://bugs.webkit.org/show_bug.cgi?id=116586.

        Reviewed by Michael Saboff.

        1. Added JIT probe support for ARMv7 and traditional ARM.
           Built and tested on ARMv7. ARM version not tested nor built. 
        2. Fix the following bugs in the X86 and X86_64 probes:
           a. Cannot assume that the stack pointer is already aligned when
              we push args for the probe. Instead, we ensure the stack
              alignment at runtime when we set up the probe call.
              This is now done in the ctiMasmProbeTrampoline.
           b. On return, the user probe function may have altered the stack
              pointer value to be restored. Previously, if the sp restore value
              points to some of the other register restore values in the
              ProbeContext record, we will fail to return from the probe having
              those user specified value as we're expected to do.
              This is now fixed.
        3. Rearranged the X86/X86_64 registers order to organize them like gdb
           expects on X86_64.
        4. We also now preserve the condition code registers.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARMAssembler.h:
        * assembler/ARMv7Assembler.h:
        (ARMRegisters):
        * assembler/MacroAssemblerARM.cpp:
        (JSC::isVFPPresent):
        (JSC::MacroAssemblerARM::ProbeContext::dumpCPURegisters):
        (JSC::MacroAssemblerARM::ProbeContext::dump):
        (JSC::MacroAssemblerARM::probe):
        * assembler/MacroAssemblerARM.h:
        (MacroAssemblerARM):
        (CPUState):
        (ProbeContext):
        (JSC::MacroAssemblerARM::trustedImm32FromPtr):
        * assembler/MacroAssemblerARMv7.h:
        (MacroAssemblerARMv7):
        (CPUState):
        (ProbeContext):
        (JSC::MacroAssemblerARMv7::trustedImm32FromPtr):
        * assembler/MacroAssemblerX86.h:
        (MacroAssemblerX86):
        (JSC::MacroAssemblerX86::probe):
        * assembler/MacroAssemblerX86Common.cpp:
        (JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::probe):
        * assembler/X86Assembler.h:
        * config.h:
        * jit/JITStubsARM.h:
        * jit/JITStubsARMv7.h:
        * jit/JITStubsX86.h:
        * jit/JITStubsX86Common.h:
        * jit/JITStubsX86_64.h:

2013-05-28  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should call masqueradesAsUndefinedWatchpointIfIsStillValid() in all of the places where it currently calls masqueradesAsUndefinedWatchpointIsStillValid()
        https://bugs.webkit.org/show_bug.cgi?id=116892

        Reviewed by Oliver Hunt.
        
        All of those places mean to plant the watchpoint if it's still valid.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
        (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):

2013-05-28  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support ArithMin/ArithMax
        https://bugs.webkit.org/show_bug.cgi?id=116885

        Reviewed by Oliver Hunt.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):

2013-05-28  Filip Pizlo  <fpizlo@apple.com>

        testRunner should have a way of disabling inlining of functions
        https://bugs.webkit.org/show_bug.cgi?id=116875

        Reviewed by Mark Hahnenberg.

        * API/JSCTestRunnerUtils.cpp:
        (JSC::getExecutable):
        (JSC):
        (JSC::numberOfDFGCompiles):
        (JSC::setNeverInline):
        * API/JSCTestRunnerUtils.h:
        (JSC):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpAssumingJITType):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::mightInlineFunctionForCall):
        (JSC::DFG::mightInlineFunctionForClosureCall):
        (JSC::DFG::mightInlineFunctionForConstruct):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::ScriptExecutable):
        (ScriptExecutable):
        (JSC::ScriptExecutable::setNeverInline):
        (JSC::ScriptExecutable::neverInline):
        (JSC::ScriptExecutable::isInliningCandidate):

2013-05-27  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support ArithMod
        https://bugs.webkit.org/show_bug.cgi?id=116792

        Reviewed by Oliver Hunt.

        * ftl/FTLAbbreviations.h:
        (JSC::FTL::buildFRem):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileArithMod):
        (LowerDFGToLLVM):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::doubleRem):

2013-05-27  Filip Pizlo  <fpizlo@apple.com>

        It should be possible to record heap operations (both FastMalloc and JSC GC)
        https://bugs.webkit.org/show_bug.cgi?id=116848

        Reviewed by Mark Hahnenberg.
        
        Record GC heap operations if ENABLE(ALLOCATION_LOGGING).

        * API/JSManagedValue.mm:
        * dfg/DFGOperations.cpp:
        * heap/Heap.cpp:
        (JSC::Heap::collect):
        * heap/Heap.h:
        (Heap):
        (JSC::Heap::allocateWithNormalDestructor):
        (JSC::Heap::allocateWithImmortalStructureDestructor):
        (JSC::Heap::allocateWithoutDestructor):
        (JSC::Heap::tryAllocateStorage):
        (JSC::Heap::tryReallocateStorage):
        (JSC):
        (JSC::Heap::ascribeOwner):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::internalAppend):
        * heap/SlotVisitor.h:
        (SlotVisitor):
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::appendUnbarrieredPointer):
        (JSC::SlotVisitor::appendUnbarrieredValue):
        (JSC::SlotVisitor::appendUnbarrieredWeak):
        (JSC::SlotVisitor::internalAppend):
        (JSC):
        (JSC::SlotVisitor::appendValues):
        * jit/JITWriteBarrier.h:
        (JSC::SlotVisitor::append):
        * llint/LLIntCommon.h:
        * runtime/Butterfly.h:
        (Butterfly):
        * runtime/ButterflyInlines.h:
        (JSC::Butterfly::createUninitialized):
        (JSC::Butterfly::create):
        (JSC::Butterfly::growPropertyStorage):
        (JSC::Butterfly::createOrGrowArrayRight):
        (JSC):
        (JSC::Butterfly::growArrayRight):
        (JSC::Butterfly::resizeArray):
        * runtime/JSArray.cpp:
        (JSC::createArrayButterflyInDictionaryIndexingMode):
        (JSC::JSArray::unshiftCountSlowCase):
        * runtime/JSArray.h:
        (JSC::createContiguousArrayButterfly):
        (JSC::createArrayButterfly):
        (JSC):
        (JSC::JSArray::create):
        (JSC::JSArray::tryCreateUninitialized):
        * runtime/JSObject.cpp:
        (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements):
        (JSC::JSObject::increaseVectorLength):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::growOutOfLineStorage):
        * runtime/JSObject.h:
        (JSC::JSObject::JSObject):
        * runtime/Operations.h:
        * runtime/RegExpMatchesArray.cpp:
        (JSC::RegExpMatchesArray::create):
        * runtime/StructureInlines.h:
        (JSC):
        * runtime/WriteBarrier.h:
        (JSC):

2013-05-27  Filip Pizlo  <fpizlo@apple.com>

        testRunner should be able to tell you if a function is DFG compiled
        https://bugs.webkit.org/show_bug.cgi?id=116847

        Reviewed by Mark Hahnenberg.

        * API/JSCTestRunnerUtils.cpp: Added.
        (JSC):
        (JSC::numberOfDFGCompiles):
        * API/JSCTestRunnerUtils.h: Added.
        (JSC):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::numberOfDFGCompiles):
        (JSC):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::runThread):
        * runtime/Executable.h:
        (JSC):
        * runtime/JSFunctionInlines.h: Added.
        (JSC):
        (JSC::JSFunction::JSFunction):
        (JSC::JSFunction::jsExecutable):
        (JSC::JSFunction::isHostFunction):
        (JSC::JSFunction::nativeFunction):
        (JSC::JSFunction::nativeConstructor):
        * runtime/Operations.h:

2013-05-27  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG ArithMod should have the !nodeUsedAsNumber optimizations that ArithDiv has
        https://bugs.webkit.org/show_bug.cgi?id=116841

        Reviewed by Mark Hahnenberg.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithMod):

2013-05-26  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: clean up ArithDiv/ArithMod in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=116793

        Reviewed by Mark Hahnenberg.
        
        This makes ArithDiv and ArithMod behave similarly, and moves both of their
        implementations entirely into DFGSpeculativeJIT.cpp into methods named like
        the ones for ArithSub/ArithMul.
        
        Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
        ArithDiv used for platforms that don't support integer division. Previously
        ArithMod had its own int-to-double and double-to-int conversions for this
        purpose.
        
        As well, this gets rid of confusing methods like compileSoftModulo() (which
        did no such thing, there wasn't anything "soft" about it) and 
        compileIntegerArithDivForX86() (which is accurately named but we don't use
        the platform-specific method convention anywhere else).
        
        Finally, this takes the optimized power-of-two modulo operation that was
        previously only for ARMv7s, and makes it available for all platforms. Well,
        sort of: I actually rewrote it to do what latest LLVM appears to do, which
        is a crazy straight-line power-of-2 modulo based on a combination of shifts,
        ands, additions, and subtractions. I can kind of understand it well enough
        to see that it complies with both C and JS power-of-2 modulo semantics. I've
        also confirmed that it does by testing (hence the corresponding improvements
        to one of the division tests). But, I don't claim to know exactly how this
        code works other than to observe that it is super leet.
        
        Overall, this patch has the effect of killing some code (no more hackish
        int-to-double conversions in ArithMod), making some optimization work on
        more platforms, and making the compiler less confusing by doing more things
        with the same idiom.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (DFG):
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        (JSC::DFG::SpeculativeJIT::compileArithMod):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2013-05-25  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: cti_optimize shouldn't allow GCs to get in the way of it seeing the state of its CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=116748

        Reviewed by Geoffrey Garen.
        
        This fixes the following race: an optimized version of our code block could be installed
        by the GC just as we return from completeAllReadyPlansForVM(), leading us to believe
        that the code block isn't ready yet even though it is. Currently this triggers a
        RELEASE_ASSERT. We could remove that assertion, but then this case would lead to the
        code in question entering into optimizeAfterWarmUp mode. That seems pretty wasteful.
        
        Fix the bug, and hopefully close the door on these bugs for a while, by wrapping
        cti_optimize in a DeferGC. There is little downside to doing so since the only
        "allocations" in cti_optimize are the ones where we inform the GC about extra memory
        usage.
        
        I had a more comprehensive solution (see the bug, "work in progress" patch) but that
        one involved adding *more* raciness to cti_optimize. I decided that was a less good
        approach once I came to appreciate the simplicity of just using DeferGC.

        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):

2013-05-25  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support ArithDiv
        https://bugs.webkit.org/show_bug.cgi?id=116771

        Reviewed by Oliver Hunt.

        * ftl/FTLAbbreviations.h:
        (JSC::FTL::buildDiv):
        (JSC::FTL::buildRem):
        (JSC::FTL::buildFDiv):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h:
        (CommonValues):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
        (LowerDFGToLLVM):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::div):
        (JSC::FTL::Output::rem):
        (JSC::FTL::Output::doubleDiv):

2013-05-25  Mark Lam  <mark.lam@apple.com>

        Remove Interpreter::retrieveLastCaller().
        https://bugs.webkit.org/show_bug.cgi?id=116753.

        Reviewed by Geoffrey Garen.

        This is part of the refactoring effort to get rid of functions walking
        the JS stack in their own way.

        * API/JSContextRef.cpp:
        (JSContextCreateBacktrace):
        * interpreter/CallFrame.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::Interpreter):
        (JSC::Interpreter::getStackTrace):
        (JSC::Interpreter::addStackTraceIfNecessary):
        * interpreter/Interpreter.h:
        (StackFrame):
        (JSC::StackFrame::StackFrame):
        (Interpreter):
        * jsc.cpp:
        (functionJSCStack):
        * profiler/ProfileGenerator.cpp:
        (JSC::ProfileGenerator::addParentForConsoleStart):

2013-05-24  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL boolify should support ObjectOrOtherUse
        https://bugs.webkit.org/show_bug.cgi?id=116741

        Reviewed by Geoffrey Garen.
        
        Just reusing what was already there in equalNullOrUndefined(). Note that we will
        sometimes generate some redundant IR - like having some spurious bitNot's in
        places - but it's safe to assume that LLVM will simplify those, and that it won't
        be the longest pole in the tent for compile times.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
        (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEqConstant):
        (JSC::FTL::LowerDFGToLLVM::boolify):
        (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):

2013-05-24  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support LogicalNot and Branch on Int32 and Number
        https://bugs.webkit.org/show_bug.cgi?id=116739

        Reviewed by Gavin Barraclough.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileLogicalNot):
        (JSC::FTL::LowerDFGToLLVM::compileBranch):
        (JSC::FTL::LowerDFGToLLVM::boolify):
        (LowerDFGToLLVM):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::isZero32):
        (JSC::FTL::Output::notZero32):

2013-05-23  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: add heuristics to reduce the likelihood of a trivially inlineable function being independently compiled by the concurrent JIT
        https://bugs.webkit.org/show_bug.cgi?id=116557

        Reviewed by Geoffrey Garen.
        
        This introduces a fairly comprehensive mechanism for preventing trivially inlineable
        functions from being compiled independently of all of the things into which they end
        up being inlined.
        
        The trick is CodeBlock::m_shouldAlwaysBeInlined, or SABI for short (that's what the
        debug logging calls it). A SABI function is one that we currently believe should
        never be DFG optimized because it should always be inlined into the functions that
        call it. SABI follows "innocent until proven guilty": all functions start out SABI
        and have SABI set to false if we see proof that that function may be called in some
        possibly non-inlineable way. So long as a function is SABI, it will not tier up to
        the DFG: cti_optimize will perpetually postpone its optimization. Because SABI has
        such a severe effect, we make the burden of proof of guilt quite low. SABI gets
        cleared if any of the following happen:
        
        - You get called from native code (either through CallData or CachedCall).
        
        - You get called from an eval, since eval code takes a long time to get DFG
          optimized.
        
        - You get called from global code, since often global code doesn't tier-up since
          it's run-once.
        
        - You get called recursively, where recursion is detected by a stack walk of depth
          Options::maximumInliningDepth().
        
        - You get called through an unlinked virtual call.
        
        - You get called from DFG code, since if the caller was already DFG optimized and
          didn't inline you then obviously, you might not get inlined.
        
        - You've tiered up to the baseline JIT and you get called from the interpreter.
          The idea here is that this kind of ensures that you stay SABI only if you're
          called no more frequently than any of your callers.
        
        - You get called from a code block that isn't a DFG candidate.
        
        - You aren't an inlining candidate.
        
        Most of the heuristics for SABI are in CodeBlock::noticeIncomingCall().
        
        This is neutral on SunSpider and V8Spider, and appears to be a slight speed-up on
        V8v7, which was previously adversely affected by concurrent compilation. I also
        confirmed that for example on V8/richards, it dramatically reduces the number of
        code blocks that get DFG compiled. It is a speed-up on those V8v7 benchmarks that
        saw regressions from concurrent compilation.
        
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpAssumingJITType):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::linkIncomingCall):
        (JSC):
        (JSC::CodeBlock::noticeIncomingCall):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::mightInlineFunction):
        (DFG):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::dfgLinkFor):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        (JSC::JIT::linkFor):
        * jit/JIT.h:
        (JIT):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::lazyLinkFor):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::setUpCall):

2013-05-23  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: rationalize DFG::CapabilityLevel and DFGCapabilities.[h|cpp]
        https://bugs.webkit.org/show_bug.cgi?id=116696

        Reviewed by Sam Weinig.
        
        Make it so that all capability calculation is funneled through one function, which tells
        you everything you wanted to know: can it be inlined, and can it be compiled.
        
        This work will help with https://bugs.webkit.org/show_bug.cgi?id=116557, since now the
        JIT has a fairly authoritative answer to the "can it be inlined" question.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::ProgramCodeBlock::capabilityLevelInternal):
        (JSC::EvalCodeBlock::capabilityLevelInternal):
        (JSC::FunctionCodeBlock::capabilityLevelInternal):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::capabilityLevel):
        (JSC::CodeBlock::capabilityLevelState):
        (ProgramCodeBlock):
        (EvalCodeBlock):
        (FunctionCodeBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::debugFail):
        (DFG):
        (JSC::DFG::canInlineResolveOperations):
        (JSC::DFG::capabilityLevel):
        * dfg/DFGCapabilities.h:
        (DFG):
        (JSC::DFG::capabilityLevel):
        (JSC::DFG::evalCapabilityLevel):
        (JSC::DFG::programCapabilityLevel):
        (JSC::DFG::functionForCallCapabilityLevel):
        (JSC::DFG::functionForConstructCapabilityLevel):
        (JSC::DFG::canInlineFunctionForCall):
        (JSC::DFG::canInlineFunctionForClosureCall):
        (JSC::DFG::canInlineFunctionForConstruct):
        * dfg/DFGCommon.h:
        (JSC::DFG::canCompile):
        (DFG):
        (JSC::DFG::canInline):
        (JSC::DFG::leastUpperBound):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):
        * tools/CodeProfile.cpp:
        (JSC::CodeProfile::sample):

2013-05-22  Filip Pizlo  <fpizlo@apple.com>

        Rename getJITCode and getJITType to jitCode and jitType.
        
        Rubber stampted by Mark Hahnenberg.

        * assembler/RepatchBuffer.h:
        (JSC::RepatchBuffer::RepatchBuffer):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::visitAggregate):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::resetStubInternal):
        (JSC::CodeBlock::stronglyVisitWeakReferences):
        (JSC::CodeBlock::baselineVersion):
        (JSC::CodeBlock::hasOptimizedReplacement):
        (JSC::CodeBlock::bytecodeOffset):
        (JSC::CodeBlock::codeOriginForReturn):
        (JSC::ProgramCodeBlock::compileOptimized):
        (JSC::EvalCodeBlock::compileOptimized):
        (JSC::FunctionCodeBlock::compileOptimized):
        (JSC::ProgramCodeBlock::jettison):
        (JSC::EvalCodeBlock::jettison):
        (JSC::FunctionCodeBlock::jettison):
        (JSC::ProgramCodeBlock::jitCompileImpl):
        (JSC::EvalCodeBlock::jitCompileImpl):
        (JSC::FunctionCodeBlock::jitCompileImpl):
        (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
        (JSC::CodeBlock::adjustedExitCountThreshold):
        (JSC::CodeBlock::tallyFrequentExitSites):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::getCallLinkInfo):
        (JSC::CodeBlock::jitCode):
        (JSC::CodeBlock::jitCodeWithArityCheck):
        (JSC::CodeBlock::jitType):
        (JSC::CodeBlock::hasBaselineJITProfiling):
        (JSC::CodeBlock::jitCompile):
        (JSC::CodeBlock::addFrequentExitSite):
        (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
        (JSC::ExecState::isInlineCallFrame):
        * dfg/DFGAssemblyHelpers.cpp:
        (JSC::DFG::AssemblyHelpers::decodedCodeMapFor):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::AssemblyHelpers):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::codeLocationForRepatch):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGOperations.cpp:
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):
        * heap/DFGCodeBlocks.cpp:
        (JSC::DFGCodeBlocks::~DFGCodeBlocks):
        (JSC::DFGCodeBlocks::jettison):
        (JSC::DFGCodeBlocks::clearMarks):
        (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
        (JSC::DFGCodeBlocks::traceMarkedCodeBlocks):
        * interpreter/Interpreter.cpp:
        (JSC::getLineNumberForCallFrame):
        (JSC::getCallerInfo):
        * jit/JITDriver.h:
        (JSC::jitCompileIfAppropriateImpl):
        (JSC::jitCompileFunctionIfAppropriateImpl):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Executable.cpp:
        (JSC::jettisonCodeBlock):
        (JSC::EvalExecutable::compileOptimized):
        (JSC::EvalExecutable::jettisonOptimizedCode):
        (JSC::ProgramExecutable::compileOptimized):
        (JSC::ProgramExecutable::jettisonOptimizedCode):
        (JSC::FunctionExecutable::baselineCodeBlockFor):
        (JSC::FunctionExecutable::compileOptimizedForCall):
        (JSC::FunctionExecutable::compileOptimizedForConstruct):
        (JSC::FunctionExecutable::jettisonOptimizedCodeForCall):
        (JSC::FunctionExecutable::jettisonOptimizedCodeForConstruct):
        * tools/CodeProfile.cpp:
        (JSC::CodeProfile::sample):

2013-05-22  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Race between LLInt->Baseline tier-up and DFG reading Baseline profiling data
        https://bugs.webkit.org/show_bug.cgi?id=116633

        Reviewed by Mark Hahnenberg.
        
        Previously we would check if we had Baseline JIT profiling data by seeing if the
        appropriate vector was non-empty. This is horrible if we're doing LLInt->Baseline
        tier-up at the same time. This will happen for code we are inlining, if we're
        deciding to inline it before the LLInt->Baseline tier-up happened for that code.
        
        This changes things to take advantage of the fact that the very last thing that
        LLInt->Baseline tier-up will do (in JITDriver.h) is setJITCode(). We now precede
        the actual work in setJITCode() with a store-store fence to ensure that all
        stores to modify the CodeBlock happen before setting the JITCode, and we modify
        CodeBlock::getJITType() to use load-load fences to ensure that if you see
        JITCode::BaselineJIT then you will also see all of those vectors. Then this
        changes all of the code that scrapes Baseline JIT profiles to check if
        getJITType() returns JITCode::BaselineJIT instead of checking vector sizes.
        
        The outcome is that for the non-racy cases we behave as we did before (we fall
        back on LLInt profiling if the tier-up hasn't happened) and for racy cases we
        use LLInt profiling conservatively.
        
        Note that for some (but not all!) of the cases where we scrape Baseline JIT
        profiling, we would have anyway been holding the CodeBlock::m_lock so we can also
        fix those cases by just having setJITCode graph that lock. This patch does that
        also, mainly because although we only call setJITCode() from the main thread, in
        general it's dangerous to have a pointer to a ref-counted object being modified
        in a racy way. So, this patch just does the most conservative thing possible that
        does we can afford to do.

        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFor):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::getJITType):
        (JSC::CodeBlock::hasBaselineJITProfiling):
        (JSC::CodeBlock::likelyToTakeSlowCase):
        (JSC::CodeBlock::couldTakeSlowCase):
        (JSC::CodeBlock::likelyToTakeSpecialFastCase):
        (JSC::CodeBlock::couldTakeSpecialFastCase):
        (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
        (JSC::CodeBlock::likelyToTakeAnySlowCase):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):

2013-05-22  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: It should be possible to use more than one compiler thread
        https://bugs.webkit.org/show_bug.cgi?id=116630

        Reviewed by Mark Hahnenberg.
        
        This gives us the ability to use more compiler threads, but doesn't actually
        enable the functionality because it isn't a speed-up on any benchmark. It can
        even be a slow-down. This also adds the ability to disable concurrent
        compilation if we're on a uniprocessor machine, and adds more logging to the
        worklist code to allow us to investigate how many threads are active. It
        appears that even on the most compiler-heavy benchmarks, we never have enough
        work for more than 4 threads, and even then the 4 threads are all active for
        a short time.
        
        Something that having more threads does accomplish is that it shakes out bugs.
        This patch fixes a bug with Watchpoint not being thread-safe ref-counted,
        which enabling 7 compilation threads did catch.
        
        As it stands, this patch is performance-neutral and just fixes bugs and adds
        some options.

        * bytecode/Watchpoint.h:
        * dfg/DFGCommon.h:
        (JSC::DFG::enableConcurrentJIT):
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::Worklist):
        (JSC::DFG::Worklist::~Worklist):
        (JSC::DFG::Worklist::finishCreation):
        (JSC::DFG::Worklist::create):
        (JSC::DFG::Worklist::enqueue):
        (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
        (JSC::DFG::Worklist::dump):
        (JSC::DFG::Worklist::runThread):
        (JSC::DFG::initializeGlobalWorklistOnce):
        * dfg/DFGWorklist.h:
        * runtime/Options.cpp:
        (JSC::computeNumberOfWorkerThreads):
        (JSC):
        (JSC::computeNumberOfGCMarkers):
        * runtime/Options.h:
        (JSC):

2013-05-22  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL shouldn't use the LLVM global context, and should instead create its own context for each compilation
        https://bugs.webkit.org/show_bug.cgi?id=116631

        Reviewed by Mark Hahnenberg.
        
        In the future we might want to share contexts for multiple compilations, but for
        now using one context per compilation is a progression over just constantly using
        the global context.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThread):
        (DFG):
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPlan.h:
        * ftl/FTLAbbreviatedTypes.h:
        (FTL):
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::voidType):
        (JSC::FTL::int1Type):
        (JSC::FTL::int8Type):
        (JSC::FTL::int32Type):
        (JSC::FTL::int64Type):
        (JSC::FTL::intPtrType):
        (JSC::FTL::doubleType):
        (JSC::FTL::structType):
        (JSC::FTL::mdKindID):
        (JSC::FTL::mdString):
        (JSC::FTL::mdNode):
        (JSC::FTL::appendBasicBlock):
        (JSC::FTL::insertBasicBlock):
        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::AbstractHeap::tbaaMetadataSlow):
        (JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap):
        (JSC::FTL::NumberedAbstractHeap::NumberedAbstractHeap):
        (JSC::FTL::AbsoluteAbstractHeap::AbsoluteAbstractHeap):
        * ftl/FTLAbstractHeap.h:
        (IndexedAbstractHeap):
        (NumberedAbstractHeap):
        (AbsoluteAbstractHeap):
        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        * ftl/FTLAbstractHeapRepository.h:
        (AbstractHeapRepository):
        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h:
        (CommonValues):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateCodeSection):
        * ftl/FTLIntrinsicRepository.cpp:
        (JSC::FTL::IntrinsicRepository::IntrinsicRepository):
        * ftl/FTLIntrinsicRepository.h:
        (FTL):
        (IntrinsicRepository):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::lower):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::Output):
        * ftl/FTLOutput.h:
        (Output):
        (JSC::FTL::Output::newBlock):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        (JSC::FTL::State::~State):
        (FTL):
        * ftl/FTLState.h:
        (State):
        * runtime/Options.h:
        (JSC):

2013-05-18  Filip Pizlo  <fpizlo@apple.com>

        FTL should force LLVM to use our own JIT memory allocator, and we shouldn't have to keep around an LLVMExecutionEngineRef to keep code alive
        https://bugs.webkit.org/show_bug.cgi?id=113619

        Reviewed by Geoffrey Garen.
        
        This uses new API that I've exposed, which allows for memory manager callbacks
        from within LLVM. LLVM may allocate multiple independent chunks of memory for
        a module, and we track all of those in a Vector in FTL::JITCode.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateCodeSection):
        (FTL):
        (JSC::FTL::mmAllocateDataSection):
        (JSC::FTL::mmApplyPermissions):
        (JSC::FTL::mmDestroy):
        (JSC::FTL::compile):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::JITCode):
        (JSC::FTL::JITCode::~JITCode):
        (JSC::FTL::JITCode::addHandle):
        (FTL):
        (JSC::FTL::JITCode::initializeCode):
        * ftl/FTLJITCode.h:
        (JITCode):
        (JSC::FTL::JITCode::handles):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::~JITFinalizer):
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h:
        (JSC::FTL::JITFinalizer::initializeEntrypointLinkBuffer):
        (JITFinalizer):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        * ftl/FTLState.h:
        (State):

2013-05-12  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL shouldn't use FastISel and Small code model should be turned off for now
        https://bugs.webkit.org/show_bug.cgi?id=115998

        Reviewed by Oliver Hunt.
        
        This switches off FastISel and makes it possible to turn off Small code model.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * runtime/Options.h:
        (JSC):

2013-05-21  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: should use ConcurrentJITLock[er] directly and not through typedef
        https://bugs.webkit.org/show_bug.cgi?id=116561

        Rubber stamped by Geoffrey Garen.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        (JSC::ArrayProfile::briefDescription):
        * bytecode/ArrayProfile.h:
        (ArrayProfile):
        (JSC::ArrayProfile::expectedStructure):
        (JSC::ArrayProfile::structureIsPolymorphic):
        (JSC::ArrayProfile::hasDefiniteStructure):
        (JSC::ArrayProfile::observedArrayModes):
        (JSC::ArrayProfile::mayInterceptIndexedAccesses):
        (JSC::ArrayProfile::mayStoreToHole):
        (JSC::ArrayProfile::outOfBounds):
        (JSC::ArrayProfile::usesOriginalArrayStructures):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFor):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpValueProfiling):
        (JSC::CodeBlock::dumpArrayProfiling):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::updateAllArrayPredictions):
        (JSC::CodeBlock::nameForRegister):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
        (CodeBlock):
        * bytecode/CodeBlockLock.h: Removed.
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
        (JSC::CompressedLazyOperandValueProfileHolder::add):
        (JSC::LazyOperandValueProfileParser::initialize):
        (JSC::LazyOperandValueProfileParser::prediction):
        * bytecode/LazyOperandValueProfile.h:
        (CompressedLazyOperandValueProfileHolder):
        (LazyOperandValueProfileParser):
        * bytecode/MethodOfGettingAValueProfile.cpp:
        (JSC::MethodOfGettingAValueProfile::getSpecFailBucket):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC::ResolveGlobalStatus::computeFor):
        * bytecode/ValueProfile.h:
        (JSC::ValueProfileBase::briefDescription):
        (JSC::ValueProfileBase::computeUpdatedPrediction):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):
        * dfg/DFGArrayMode.h:
        (ArrayMode):
        (JSC::DFG::ArrayMode::withProfile):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
        (JSC::DFG::ByteCodeParser::parseResolveOperations):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * jit/JITInlines.h:
        (JSC::JIT::chooseArrayMode):
        * jit/JITStubs.cpp:
        (JSC::tryCachePutByID):
        (JSC::tryCacheGetByID):
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::lazyLinkFor):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::setUpCall):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::BytecodeSequence):
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::addGlobalVar):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::getOwnNonIndexPropertyNames):
        (JSC::JSActivation::symbolTablePutWithAttributes):
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolveContainingScopeInternal):
        (JSC::JSScope::resolvePut):
        * runtime/JSSegmentedVariableObject.cpp:
        (JSC::JSSegmentedVariableObject::findRegisterIndex):
        (JSC::JSSegmentedVariableObject::addRegisters):
        * runtime/JSSegmentedVariableObject.h:
        (JSSegmentedVariableObject):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/Structure.cpp:
        (JSC::Structure::materializePropertyMap):
        (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
        (JSC::Structure::addPropertyTransition):
        (JSC::Structure::takePropertyTableOrCloneIfPinned):
        (JSC::Structure::nonPropertyTransition):
        (JSC::Structure::putSpecificValue):
        (JSC::Structure::remove):
        (JSC::Structure::createPropertyMap):
        * runtime/Structure.h:
        (Structure):
        * runtime/SymbolTable.h:
        (SymbolTable):
        (JSC::SymbolTable::find):
        (JSC::SymbolTable::get):
        (JSC::SymbolTable::inlineGet):
        (JSC::SymbolTable::begin):
        (JSC::SymbolTable::end):
        (JSC::SymbolTable::size):
        (JSC::SymbolTable::add):
        (JSC::SymbolTable::set):
        (JSC::SymbolTable::contains):

2013-05-20  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should be able to run on a separate thread
        https://bugs.webkit.org/show_bug.cgi?id=112839

        Reviewed by Geoffrey Garen.
        
        This is the final bit of concurrent JITing. The idea is that there is a
        single global worklist, and a single global thread, that does all
        optimizing compilation. This is the DFG::Worklist. It contains a queue of
        DFG::Plans, and a map from CodeBlock* (the baseline code block we're
        trying to optimize) to DFG::Plan. If the DFGDriver tries to concurrently
        compile something, it puts the Plan on the Worklist. The Worklist's
        thread will compile that Plan eventually, and when it's done, it will
        signal its completion by (1) notifying anyone waiting for the Worklist to
        be done, and (2) forcing the CodeBlock::m_jitExecuteCounter to take slow
        path. The next Baseline JIT cti_optimize call will then install all ready
        (i.e. compiled) Plans for that VM. Note that (1) is only for the GC and
        VM shutdown, which will want to ensure that there aren't any outstanding
        async compilations before proceeding. They do so by simply waiting for
        all of the plans for the current VM to complete. (2) is the actual way
        that code typically gets installed.
        
        This is all very racy by design. For example, just as we try to force the
        execute counter to take slow path, the main thread may be setting the
        execute counter to some other value. The main thread must set it to
        another value because (a) JIT code is constantly incrementing the counter
        in a racy way, (b) the cti_optimize slow path will set it to some
        large-ish negative value to ensure that cti_optimize isn't called
        repeatedly, and (c) OSR exits from previously jettisoned code blocks may
        still want to reset the counter values. This "race" is made benign, by
        ensuring that while there is an asynchronous compilation, we at worse set
        the counter to optimizeAfterWarmUp and never to deferIndefinitely. Hence
        if the race happens then the worst case is that we wait another ~1000
        counts before installing the optimized code. Another defense is that if
        any CodeBlock calls into cti_optimize, then it will check for all ready
        plans for the VM - so even if a code block has to wait another ~1000
        executions before it calls cti_optimize to do the installation, it may
        actually end up being installed sooner because a different code block had
        called cti_optimize, potentially for an unrelated reason.
        
        Special care is taken to ensure that installing plans informs the GC
        about the increased memory usage, but also ensures that we don't recurse
        infinitely - since at start of GC we try to install outstanding plans.
        This is done by introducing a new GC deferral mechanism (the DeferGC
        block-scoped thingy), which will ensure that GCs don't happen in the
        scope but are allowed to happen after. This still leaves the strange
        corner case that cti_optimize may install outstanding plans, then GC, and
        that GC may jettison the code block that was installed. This, and the
        fact that the plan that we took slow path to install could have been a
        failed or invalid compile, mean that we have to take special precautions
        in cti_optimize.
        
        This patch also fixes a number of small concurrency bugs that I found
        when things started running. There are probably more of those bugs still
        left to fix. This patch just fixes the ones I know about.
        
        Concurrent compilation is right now only enabled on X86_64 Mac. We need
        platforms that are sufficiently CAStastic so that we can do the various
        memory fence and CAS tricks that make this safe. We also need a platform
        that uses JSVALUE64. And we need pthread_once. So, that pretty much means
        just X64_64 for now. Enabling Linux-64_64 should be a breeze, but I'll
        leave that up to the Qt and GTK+ ports to do at their discretion.
        
        This is a solid speed-up on SunSpider (8-9%) and V8Spider (16%), our two
        main compile-time benchmarks. Most peculiarly, this also appears to
        reduce measurement noise, rather than increasing it as you would have
        expected. I don't understand that result but I like it anyway. On the
        other hand, this is a slight (1%) slow-down on V8v7. I will continue to
        investigate this but I think that the results are already good enough
        that we should land this as-is. So far, it appears that the slow-down is
        due to this breaking the don't-compile-inlineables heuristics. See
        investigation in https://bugs.webkit.org/show_bug.cgi?id=116556 and the
        bug https://bugs.webkit.org/show_bug.cgi?id=116557.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::resetStubInternal):
        (JSC::CodeBlock::baselineVersion):
        (JSC::CodeBlock::hasOptimizedReplacement):
        (JSC::CodeBlock::optimizationThresholdScalingFactor):
        (JSC::CodeBlock::checkIfOptimizationThresholdReached):
        (JSC::CodeBlock::optimizeNextInvocation):
        (JSC::CodeBlock::dontOptimizeAnytimeSoon):
        (JSC::CodeBlock::optimizeAfterWarmUp):
        (JSC::CodeBlock::optimizeAfterLongWarmUp):
        (JSC::CodeBlock::optimizeSoon):
        (JSC::CodeBlock::forceOptimizationSlowPathConcurrently):
        (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::updateAllArrayPredictions):
        (JSC::CodeBlock::shouldOptimizeNow):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::jitCompile):
        * bytecode/CodeBlockLock.h:
        (JSC):
        * bytecode/ExecutionCounter.cpp:
        (JSC::ExecutionCounter::forceSlowPathConcurrently):
        (JSC):
        (JSC::ExecutionCounter::setThreshold):
        * bytecode/ExecutionCounter.h:
        (ExecutionCounter):
        * debugger/Debugger.cpp:
        (JSC::Debugger::recompileAllJSFunctions):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
        * dfg/DFGCommon.h:
        (JSC::DFG::enableConcurrentJIT):
        (DFG):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        * dfg/DFGGraph.h:
        (Graph):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOperations.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::key):
        (DFG):
        * dfg/DFGPlan.h:
        (DFG):
        (Plan):
        * dfg/DFGWorklist.cpp: Added.
        (DFG):
        (JSC::DFG::Worklist::Worklist):
        (JSC::DFG::Worklist::~Worklist):
        (JSC::DFG::Worklist::finishCreation):
        (JSC::DFG::Worklist::create):
        (JSC::DFG::Worklist::enqueue):
        (JSC::DFG::Worklist::compilationState):
        (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
        (JSC::DFG::Worklist::removeAllReadyPlansForVM):
        (JSC::DFG::Worklist::completeAllReadyPlansForVM):
        (JSC::DFG::Worklist::completeAllPlansForVM):
        (JSC::DFG::Worklist::queueLength):
        (JSC::DFG::Worklist::dump):
        (JSC::DFG::Worklist::runThread):
        (JSC::DFG::Worklist::threadFunction):
        (JSC::DFG::initializeGlobalWorklistOnce):
        (JSC::DFG::globalWorklist):
        * dfg/DFGWorklist.h: Added.
        (DFG):
        (Worklist):
        * heap/CopiedSpaceInlines.h:
        (JSC::CopiedSpace::allocateBlock):
        * heap/DeferGC.h: Added.
        (JSC):
        (DeferGC):
        (JSC::DeferGC::DeferGC):
        (JSC::DeferGC::~DeferGC):
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::reportExtraMemoryCostSlowCase):
        (JSC::Heap::collectAllGarbage):
        (JSC::Heap::collect):
        (JSC::Heap::collectIfNecessaryOrDefer):
        (JSC):
        (JSC::Heap::incrementDeferralDepth):
        (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
        * heap/Heap.h:
        (Heap):
        (JSC::Heap::isCollecting):
        (JSC):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateSlowCase):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * profiler/ProfilerBytecodes.h:
        * runtime/ConcurrentJITLock.h: Added.
        (JSC):
        * runtime/ExecutionHarness.h:
        (JSC::replaceWithDeferredOptimizedCode):
        * runtime/JSSegmentedVariableObject.cpp:
        (JSC::JSSegmentedVariableObject::findRegisterIndex):
        (JSC::JSSegmentedVariableObject::addRegisters):
        * runtime/JSSegmentedVariableObject.h:
        (JSSegmentedVariableObject):
        * runtime/Options.h:
        (JSC):
        * runtime/Structure.h:
        (Structure):
        * runtime/StructureInlines.h:
        (JSC::Structure::propertyTable):
        * runtime/SymbolTable.h:
        (SymbolTable):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        (JSC::VM::~VM):
        (JSC::VM::prepareToDiscardCode):
        (JSC):
        (JSC::VM::discardAllCode):
        (JSC::VM::releaseExecutableMemory):
        * runtime/VM.h:
        (DFG):
        (VM):

2013-05-17  Mark Hahnenberg  <mhahnenberg@apple.com>

        CheckArrays should be hoisted
        https://bugs.webkit.org/show_bug.cgi?id=116353

        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:

2013-05-17  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: getCTIStub should be thread-safe
        https://bugs.webkit.org/show_bug.cgi?id=116126

        Reviewed by Dan Bernstein.
        
        It's called from the compilation thread. Give it locks.

        * jit/JITThunks.cpp:
        (JSC::JITThunks::ctiStub):
        (JSC::JITThunks::hostFunctionStub):
        * jit/JITThunks.h:
        (JITThunks):

2013-05-17  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Executable and CodeBlock should be aware of DFG::Plans that complete asynchronously
        https://bugs.webkit.org/show_bug.cgi?id=116350

        Reviewed by Oliver Hunt.
        
        This refactors compilation so that:
        
        - JITStubs knows exactly what the result of compilation was. For example, if
          compilation was deferred, it will now know this.
        
        - The set of things that has to happen to install compiled code is now factored
          out into JSC::installOptimizedCode().
        
        - A bunch of the code in Executable.cpp is now made more common to reduce code
          duplication. For example, the heap heuristics stuff is now in one place.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::ProgramCodeBlock::compileOptimized):
        (JSC::ProgramCodeBlock::replaceWithDeferredOptimizedCode):
        (JSC):
        (JSC::EvalCodeBlock::compileOptimized):
        (JSC::EvalCodeBlock::replaceWithDeferredOptimizedCode):
        (JSC::FunctionCodeBlock::compileOptimized):
        (JSC::FunctionCodeBlock::replaceWithDeferredOptimizedCode):
        (JSC::ProgramCodeBlock::jitCompileImpl):
        (JSC::EvalCodeBlock::jitCompileImpl):
        (JSC::FunctionCodeBlock::jitCompileImpl):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::jitCompile):
        (ProgramCodeBlock):
        (EvalCodeBlock):
        (FunctionCodeBlock):
        * dfg/DFGDesiredIdentifiers.cpp:
        (JSC::DFG::DesiredIdentifiers::numberOfIdentifiers):
        (DFG):
        (JSC::DFG::DesiredIdentifiers::at):
        * dfg/DFGDesiredIdentifiers.h:
        (JSC):
        (DesiredIdentifiers):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        (JSC::DFG::tryFinalizePlan):
        (DFG):
        * dfg/DFGDriver.h:
        (DFG):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        (JSC::DFG::tryFinalizePlan):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalizeCommon):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::reallyAdd):
        * dfg/DFGPlan.h:
        (JSC):
        (Plan):
        (DFG):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * jit/JITDriver.h:
        (JSC::jitCompileIfAppropriateImpl):
        (JSC::jitCompileFunctionIfAppropriateImpl):
        (JSC):
        (JSC::jitCompileIfAppropriate):
        (JSC::jitCompileFunctionIfAppropriate):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        * runtime/CompilationResult.cpp: Added.
        (WTF):
        (WTF::printInternal):
        * runtime/CompilationResult.h: Added.
        (JSC):
        (WTF):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileOptimized):
        (JSC::EvalExecutable::jitCompile):
        (JSC::EvalExecutable::compileInternal):
        (JSC::EvalExecutable::replaceWithDeferredOptimizedCode):
        (JSC):
        (JSC::ProgramExecutable::compileOptimized):
        (JSC::ProgramExecutable::jitCompile):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::ProgramExecutable::replaceWithDeferredOptimizedCode):
        (JSC::FunctionExecutable::compileOptimizedForCall):
        (JSC::FunctionExecutable::compileOptimizedForConstruct):
        (JSC::FunctionExecutable::jitCompileForCall):
        (JSC::FunctionExecutable::jitCompileForConstruct):
        (JSC::FunctionExecutable::compileForCallInternal):
        (JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeForCall):
        (JSC::FunctionExecutable::compileForConstructInternal):
        (JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeForConstruct):
        * runtime/Executable.h:
        (ScriptExecutable):
        (EvalExecutable):
        (ProgramExecutable):
        (FunctionExecutable):
        (JSC::FunctionExecutable::compileOptimizedFor):
        (JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeFor):
        (JSC::FunctionExecutable::jitCompileFor):
        * runtime/ExecutionHarness.h:
        (JSC::prepareForExecutionImpl):
        (JSC::prepareFunctionForExecutionImpl):
        (JSC):
        (JSC::installOptimizedCode):
        (JSC::prepareForExecution):
        (JSC::prepareFunctionForExecution):
        (JSC::replaceWithDeferredOptimizedCode):

2013-05-16  Mark Hahnenberg  <mhahnenberg@apple.com>

        observeUseKindOnNode doesn't contain a case for KnownCellUse
        https://bugs.webkit.org/show_bug.cgi?id=116130

        This would just lead to us being overly conservative when deciding
        whether we should unbox GetLocals with KnownCellUse UseKinds.

        Reviewed by Filip Pizlo.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::observeUseKindOnNode):

2013-05-16  Mark Hahnenberg  <mhahnenberg@apple.com>

        fourthTier: infrequent segfault in DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks()
        https://bugs.webkit.org/show_bug.cgi?id=116134

        CodeBlock and JITCode should be ThreadSafeRefCounted. We're going to
        start using them on more threads very soon (with concurrent
        compilation). This patch also fixes the specific place where we were
        superfluously creating a RefPtr.

        Reviewed by Oliver Hunt.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::getJITType):
        * jit/JITCode.h:

2013-05-16  Mark Lam  <mark.lam@apple.com>

        Implement a probe mechanism for JIT generated code.
        https://bugs.webkit.org/show_bug.cgi?id=115705.

        Reviewed by Geoffrey Garen.

        Edit: For C++ code, you can do debugging by adding printfs to your
        code. For JIT generated code, you can now do the equivalent by
        inserting a probe and have it emit a call to your probe function.

        The probe is in the form of a MacroAssembler pseudo instruction.
        It takes 3 arguments: a ProbeFunction, and 2 void* args.

        When inserted into the JIT at some code generation site, the probe
        pseudo "instruction" will emit a minimal amount of code to save the
        stack pointer, 1 (or more) scratch register(s), and the probe
        arguments into a ProbeContext record on the stack. The emitted code
        will then call a probe trampoline to do the rest of the work, which
        consists of:
        1. saving the remaining registers into the ProbeContext.
        2. calling the ProbeFunction, and passing it the ProbeContext pointer.
        3. restoring the registers from the ProbeContext after the ProbeFunction
           returns, and then returning to the JIT generated code.

        The ProbeContext is stack allocated and is only valid for the duration
        that the ProbeFunction is executing.

        If the user supplied ProbeFunction alters the register values in the
        ProbeContext, the new values will be installed into the registers upon
        returning from the probe. This can be useful for some debugging or
        testing purposes.

        The probe mechanism is built conditional on USE(MASM_PROBE) which is
        defined in config.h. USE(MASM_PROBE) will off by default.

        This changeset only implements the probe mechanism for X86 and X86_64.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/MacroAssembler.h:
        (MacroAssembler):
        (JSC::MacroAssembler::shouldBlind):
        (JSC::MacroAssembler::store32):
        * assembler/MacroAssemblerX86.h:
        (MacroAssemblerX86):
        (JSC::MacroAssemblerX86::trustedImm32FromPtr):
        (JSC::MacroAssemblerX86::probe):
        * assembler/MacroAssemblerX86Common.cpp: Added.
        (JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters):
        - CPU specific register dumper called by ProbeContext::dump().
        (JSC::MacroAssemblerX86Common::ProbeContext::dump):
        - Prints the ProbeContext to the DataLog.
        * assembler/MacroAssemblerX86Common.h:
        (MacroAssemblerX86Common):
        (CPUState): Added.
        (ProbeContext): Added.
        * assembler/MacroAssemblerX86_64.h:
        (MacroAssemblerX86_64):
        (JSC::MacroAssemblerX86_64::trustedImm64FromPtr):
        (JSC::MacroAssemblerX86_64::probe):
        * assembler/X86Assembler.h:
        * config.h: Added WTF_USE_MASM_PROBE flag.
        * jit/JITStubs.cpp:
        * jit/JITStubs.h:
        * jit/JITStubsX86.h:
        * jit/JITStubsX86Common.h: Added.
        * jit/JITStubsX86_64.h:

2013-05-15  Mark Lam  <mark.lam@apple.com>

        Fix for broken 32-bit build in SpeculativeJIT::checkArray().
        https://bugs.webkit.org/show_bug.cgi?id=116184.

        Rubber stamped by Mark Hahnenberg.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):

2013-05-15  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should separate link phase into things that must be done concurrently and things that must be done synchronously, and have a way of passing data from one to the other
        https://bugs.webkit.org/show_bug.cgi?id=116060

        Reviewed by Gavin Barraclough.
        
        This introduces the concept of a DFG::Plan, which corresponds to:
        
        - The data that the concurrent DFG or FTL need to start compiling a CodeBlock.
          This mostly includes basic things like CodeBlock*, but also a list of
          must-handle values for OSR entry.
        
        - The data that the synchronous linker need to link in code compiled by a
          concurrent compilation thread. This is further encapsulated by DFG::Finalizer,
          since the data, and the actions that need to be taken, are different in DFG
          versus FTL. This patch also institutes the policy that the concurrent
          compilation thread shall not use LinkBuffer::performFinalization(), since that
          code assumes that it's running on the same thread that will actually run the
          code.
        
        - The actions that need to be taken to compile code. In other words, most of the
          code that previously lived in DFGDriver.cpp now lives in
          DFG::Plan::compileInThread().
        
        - The actions that need to be taken when synchronously linking the code. This
          includes "really" adding watchpoints and identifiers, checking watchpoint and
          chain validity, and running the DFG::Finalizer.
        
        Currently, DFGDriver just creates a Plan and runs it synchronously. But in the
        future, we will be able to malloc some Plans and enqueue them, and have the
        concurrent thread dequeue them and call Plan::compileInThread().
        
        For now, this has no behavior or performance change.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::performFinalization):
        * assembler/LinkBuffer.h:
        (LinkBuffer):
        (JSC::LinkBuffer::LinkBuffer):
        (JSC::LinkBuffer::~LinkBuffer):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        (JSC::DFG::AbstractState::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::setFuturePossibleStructure):
        (JSC::DFG::AbstractValue::filterFuturePossibleStructure):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addStructureTransitionCheck):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::parseResolveOperations):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
        * dfg/DFGDriver.cpp:
        (DFG):
        (JSC::DFG::compile):
        * dfg/DFGFailedFinalizer.cpp: Added.
        (DFG):
        (JSC::DFG::FailedFinalizer::FailedFinalizer):
        (JSC::DFG::FailedFinalizer::~FailedFinalizer):
        (JSC::DFG::FailedFinalizer::finalize):
        (JSC::DFG::FailedFinalizer::finalizeFunction):
        * dfg/DFGFailedFinalizer.h: Added.
        (DFG):
        (FailedFinalizer):
        * dfg/DFGFinalizer.cpp: Added.
        (DFG):
        (JSC::DFG::Finalizer::Finalizer):
        (JSC::DFG::Finalizer::~Finalizer):
        * dfg/DFGFinalizer.h: Added.
        (DFG):
        (Finalizer):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::dump):
        (DFG):
        * dfg/DFGGraph.h:
        (Graph):
        (JSC::DFG::Graph::masqueradesAsUndefinedWatchpointIsStillValid):
        (JSC::DFG::Graph::compilation):
        (JSC::DFG::Graph::identifiers):
        (JSC::DFG::Graph::watchpoints):
        (JSC::DFG::Graph::chains):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::linkFunction):
        (DFG):
        (JSC::DFG::JITCompiler::disassemble):
        * dfg/DFGJITCompiler.h:
        (JITCompiler):
        (JSC::DFG::JITCompiler::addLazily):
        * dfg/DFGJITFinalizer.cpp: Added.
        (DFG):
        (JSC::DFG::JITFinalizer::JITFinalizer):
        (JSC::DFG::JITFinalizer::~JITFinalizer):
        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        (JSC::DFG::JITFinalizer::finalizeCommon):
        * dfg/DFGJITFinalizer.h: Added.
        (DFG):
        (JITFinalizer):
        * dfg/DFGPlan.cpp: Added.
        (DFG):
        (JSC::DFG::dumpAndVerifyGraph):
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::~Plan):
        (JSC::DFG::Plan::compileInThread):
        (JSC::DFG::Plan::isStillValid):
        (JSC::DFG::Plan::reallyAdd):
        (JSC::DFG::Plan::finalize):
        * dfg/DFGPlan.h: Added.
        (DFG):
        (Plan):
        (JSC::DFG::Plan::vm):
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::identifierUID):
        (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::run):
        * ftl/FTLGeneratedFunction.h: Added.
        (FTL):
        * ftl/FTLJITFinalizer.cpp: Added.
        (FTL):
        (JSC::FTL::JITFinalizer::JITFinalizer):
        (JSC::FTL::JITFinalizer::~JITFinalizer):
        (JSC::FTL::JITFinalizer::finalize):
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h: Added.
        (FTL):
        (JITFinalizer):
        (JSC::FTL::JITFinalizer::initializeExitThunksLinkBuffer):
        (JSC::FTL::JITFinalizer::initializeEntrypointLinkBuffer):
        (JSC::FTL::JITFinalizer::initializeCode):
        (JSC::FTL::JITFinalizer::initializeFunction):
        (JSC::FTL::JITFinalizer::initializeArityCheck):
        (JSC::FTL::JITFinalizer::initializeJITCode):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLink.h:
        (FTL):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        * ftl/FTLState.h:
        (FTL):
        (State):

2013-05-14  Mark Lam  <mark.lam@apple.com>

        Refactor JITStubs.cpp to move CPU specific parts out into their own files.
        https://bugs.webkit.org/show_bug.cgi?id=116135.

        Reviewed by Michael Saboff.

        This mod only moves the CPU specific parts out. There is no code change.
        Tested on debug builds of X86, X86_64, ARM and ARMv7. The SH4 and MIPS
        ports are untested. Windows port also not tested.

        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JITStubs.cpp:
        (JSC::performPlatformSpecificJITAssertions):
        * jit/JITStubsARM.h: Added.
        (JSC::ctiTrampoline):
        (JSC::ctiTrampolineEnd):
        (JSC::ctiVMThrowTrampoline):
        (JSC::ctiOpThrowNotCaught):
        (JSC::performARMJITAssertions):
        * jit/JITStubsARMv7.h: Added.
        (JSC::ctiTrampoline):
        (JSC::ctiVMThrowTrampoline):
        (JSC::ctiOpThrowNotCaught):
        (JSC::performARMv7JITAssertions):
        * jit/JITStubsMIPS.h: Added.
        (JSC::performMIPSJITAssertions):
        * jit/JITStubsSH4.h: Added.
        * jit/JITStubsX86.h: Added.
        * jit/JITStubsX86_64.h: Added.

2013-05-14  Mark Hahnenberg  <mhahnenberg@apple.com>

        fourthTier: Segfault in jsc with simple test program when running with profile dumping enabled
        https://bugs.webkit.org/show_bug.cgi?id=116082

        It's crashing because CodeBlock::baselineVersion() doesn't know how to handle the case where 'this' is the 
        baseline version but it hasn't been assigned to the m_blahCodeBlock field in BlahExecutable. The fix is to 
        check if we're the baseline version in baselineVersion() and return this if so.

        Reviewed by Filip Pizlo.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::baselineVersion):

2013-05-11  Mark Hahnenberg  <mhahnenberg@apple.com>

        Rename StructureCheckHoistingPhase to TypeCheckHoistingPhase
        https://bugs.webkit.org/show_bug.cgi?id=115938

        We're going to add some more types of check hoisting soon, so let's have
        the right name here.

        Rubber stamped by Filip Pizlo.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp: Removed.
        * dfg/DFGStructureCheckHoistingPhase.h: Removed.
        * dfg/DFGTypeCheckHoistingPhase.cpp: Added.
        (DFG):
        (TypeCheckHoistingPhase):
        (JSC::DFG::TypeCheckHoistingPhase::TypeCheckHoistingPhase):
        (JSC::DFG::TypeCheckHoistingPhase::run):
        (JSC::DFG::TypeCheckHoistingPhase::shouldConsiderForHoisting):
        (JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheck):
        (CheckData):
        (JSC::DFG::TypeCheckHoistingPhase::CheckData::CheckData):
        (JSC::DFG::performTypeCheckHoisting):
        * dfg/DFGTypeCheckHoistingPhase.h: Added.

2013-05-10  Mark Hahnenberg  <mhahnenberg@apple.com>

        SpeculativeJIT::checkArray should use the correct ExitKind
        https://bugs.webkit.org/show_bug.cgi?id=115943

        Currently it uses Uncountable, which gives us no information if we end up exiting due to a 
        mismatched ClassInfo pointer. It should instead use BadType and should pass the correct 
        JSValueSource and Node instead of passing empty values.

        Reviewed by Filip Pizlo.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):

2013-05-11  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support Jump and ForceOSRExit
        https://bugs.webkit.org/show_bug.cgi?id=115942

        Reviewed by Oliver Hunt.
        
        Added two obvious nodes: Jump and ForceOSRExit. We already had everything we needed
        to support them.
        
        Adding these increases our coverage a fair bit, and revealed a bug: LLVM's full
        instruction selector currently appears to mishandle doubles in constant pools (or
        just constant pools in general) with the small code model in the MCJIT. But switching
        to FastISel "fixes" it. That's what this patch does, for now. This will probably
        actually be permanent; the FastISel does pretty much everything we would ever want,
        at least in the foreseeable future.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        (FTL):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileBlock):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileJSConstant):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compileJump):
        (JSC::FTL::LowerDFGToLLVM::compileReturn):
        (JSC::FTL::LowerDFGToLLVM::compileForceOSRExit):
        * runtime/Options.h:
        (JSC):

2013-05-10  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support CompareStrictEqConstant
        https://bugs.webkit.org/show_bug.cgi?id=115941

        Reviewed by Mark Hahnenberg.
        
        Pretty simple, but factors out the craziness of comparing against null or undefined
        in a way that is reusable for both == and ===.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
        (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEqConstant):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):

2013-05-10  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support CompareEqConstant
        https://bugs.webkit.org/show_bug.cgi?id=115939

        Reviewed by Oliver Hunt and Mark Hahnenberg.
        
        The most interesting part of this patch is the way I make it easier to deal with
        the inputs to Phi functions. This adds the notion of ValueFromBlock, which you
        can get by doing m_out.anchor(value). You can build up a vector of these, and then
        pass them to m_out.phi(type, vector) in one go.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLAbbreviatedTypes.h: Added.
        (FTL):
        * ftl/FTLAbbreviations.h:
        (FTL):
        (JSC::FTL::addIncoming):
        (JSC::FTL::buildPhi):
        * ftl/FTLAbstractHeapRepository.h:
        (FTL):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::lowDouble):
        (JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIfIsStillValid):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::phi):
        (Output):
        (JSC::FTL::Output::anchor):
        * ftl/FTLValueFromBlock.h: Added.
        (FTL):
        (ValueFromBlock):
        (JSC::FTL::ValueFromBlock::ValueFromBlock):
        (JSC::FTL::ValueFromBlock::value):
        (JSC::FTL::ValueFromBlock::block):

2013-05-10  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support CompareStrictEq
        https://bugs.webkit.org/show_bug.cgi?id=115927

        Reviewed by Mark Hahnenberg.
        
        Do the sensible thing, and make it so that for common cases, CompareEq is
        implemented in terms of CompareStrictEq in the FTL backend. All of the cases
        we currently support can be done this way.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):

2013-05-10  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support Int32ToDouble
        https://bugs.webkit.org/show_bug.cgi?id=115926

        Reviewed by Mark Hahnenberg.
        
        This node exists mainly to help the DFG see that a node may have both an int
        and a double representation. But in the FTL, nodes already have multiple
        representations. So this is just a no-op for the FTL.
        
        I considered making it so that the node isn't even inserted if we're doing
        FTL compilation, but that would have required a bunch of conditionalizing in
        the DFG's optimization phases, which sort of expect this node to be present
        and necessary.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileInt32ToDouble):
        (LowerDFGToLLVM):

2013-05-10  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support LogicalNot
        https://bugs.webkit.org/show_bug.cgi?id=115924

        Reviewed by Mark Hahnenberg.

        * ftl/FTLAbbreviations.h:
        (JSC::FTL::buildNot):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileLogicalNot):
        (LowerDFGToLLVM):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::bitNot):

2013-05-10  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support CompareGreater, CompareLessEq, and CompareGreaterEq
        https://bugs.webkit.org/show_bug.cgi?id=115923

        Reviewed by Mark Hahnenberg.
        
        Also fixed a bug where double CompareLess would assert.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq):
        (JSC::FTL::LowerDFGToLLVM::compileCompareGreater):
        (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq):

2013-05-10  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL CompareEq ObjectUse should handle masquerading
        https://bugs.webkit.org/show_bug.cgi?id=115920

        Reviewed by Mark Hahnenberg.
        
        We don't yet support watchpoints, but this does all the wiring right up to the
        part where we would have emitted watchpoints. I've also written this in a way that
        makes it easy to use the case where you would have anyway speculated non-masquerading
        even if the watchpoint was invalidated.
        
        This is inherently racy, of course: but the only race here is that you might first
        set the watchpoint, and then the watchpoint is invalidated, and then you compile rest
        of the code in a way that doesn't need the watchpoint. That's fine, since the FTL
        will remember that it had set the watchpoint and then cancel the compilation.

        * ftl/FTLAbbreviations.h:
        (JSC::FTL::int8Type):
        * ftl/FTLAbstractHeapRepository.h:
        (FTL):
        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h:
        (CommonValues):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
        (JSC::FTL::LowerDFGToLLVM::lowNonNullObject):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
        (JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIsStillValid):
        (JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIfIsStillValid):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::constInt8):
        (JSC::FTL::Output::load8):
        (JSC::FTL::Output::isZero8):
        (JSC::FTL::Output::notZero8):
        (JSC::FTL::Output::testIsZero8):
        (JSC::FTL::Output::testNonZero8):

2013-05-09  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG shouldn't allocate in the GC heap
        https://bugs.webkit.org/show_bug.cgi?id=115598

        Reviewed by Geoffrey Garen.
        
        I believe that we've now fixed this, and this patch just adds the relevant assertion.

        * runtime/JSCellInlines.h:
        (JSC::JSCell::JSCell):

2013-05-09  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: CodeBlock should be RefCounted
        https://bugs.webkit.org/show_bug.cgi?id=115594

        Reviewed by Geoffrey Garen.
        
        This makes it possible to have the currently-being-compiled CodeBlock not be
        installed in Executable, while also allowing it to point to its intended
        alternative(). So long as we were using ownership and not reference counting, it
        would have been difficult to have both CodeBlock::m_alternative and
        Executable::m_codeBlockForBlah point to the previous CodeBlock.
        
        I also took the opportunity to clean up a bunch of code that appears to have
        rotted.

        * assembler/MacroAssemblerCodeRef.h:
        (MacroAssemblerCodePtr):
        (JSC::MacroAssemblerCodePtr::operator==):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::releaseAlternative):
        (JSC::CodeBlock::setAlternative):
        (CodeBlock):
        (JSC::GlobalCodeBlock::GlobalCodeBlock):
        (JSC::ProgramCodeBlock::ProgramCodeBlock):
        (JSC::EvalCodeBlock::EvalCodeBlock):
        (JSC::FunctionCodeBlock::FunctionCodeBlock):
        * heap/DFGCodeBlocks.cpp:
        (JSC::DFGCodeBlocks::~DFGCodeBlocks):
        (JSC::DFGCodeBlocks::jettison):
        (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
        * heap/DFGCodeBlocks.h:
        (DFGCodeBlocks):
        * heap/Heap.cpp:
        (JSC::Heap::jettisonDFGCodeBlock):
        * heap/Heap.h:
        * jit/JITDriver.h:
        (JSC::jitCompileIfAppropriate):
        (JSC::jitCompileFunctionIfAppropriate):
        * runtime/Executable.cpp:
        (JSC::jettisonCodeBlock):
        (JSC::EvalExecutable::jitCompile):
        (JSC::EvalExecutable::compileInternal):
        (JSC::ProgramExecutable::jitCompile):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::FunctionExecutable::jitCompileForCall):
        (JSC::FunctionExecutable::jitCompileForConstruct):
        (JSC::FunctionExecutable::produceCodeBlockFor):
        (JSC::FunctionExecutable::compileForCallInternal):
        (JSC::FunctionExecutable::compileForConstructInternal):
        * runtime/Executable.h:
        (EvalExecutable):
        (FunctionExecutable):
        (JSC::FunctionExecutable::codeBlockFor):
        * runtime/ExecutionHarness.h:
        (JSC::prepareForExecution):
        (JSC::prepareFunctionForExecution):

2013-05-09  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should have its own notion of StructureChain, and it should be possible to validate it after compilation finishes
        https://bugs.webkit.org/show_bug.cgi?id=115841

        Reviewed by Oliver Hunt.
        
        This adds IntendedStructureChain, which is like StructureChain, except that it holds a bit
        more information and can be validated independantly of its owning Structure and lexical
        GlobalObject, since it remembers both of those things. It's also malloc'd and RefCounted
        rather than GC'd, so it can be allocated in a concurrent compilation thread.
        
        Gave this class a bunch of methods to allow the following idiom:
        
        - Snapshot a structure chain concurrently. This structure chain may end up being
          wrong in case of races, but in that case we will find out when we try to validate
          it.
        
        - Perform validation on the structure chain itself, without recomputing the chain.
          Previously, many chain validation methods (prototypeChainMayInterceptStoreTo() for
          example) recomputed the chain, and hence, were inherently racy: you could build one
          chain and then validate against a different chain, and hence not realize that the
          chain you did build was actually broken for your purposes, because the chain you
          checked was a different one.
        
        - Validate that the chain is still the right one at any time, allowing the cancellation
          of compilation if there was a race.
        
        Also added DFG::DesiredStructureChains, which tracks those intended structure chains that
        the compiler had already chosen to use. If any of those are invalid at link time, throw
        out the compilation.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForChain):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/GetByIdStatus.h:
        (JSC::GetByIdStatus::GetByIdStatus):
        (JSC::GetByIdStatus::chain):
        (GetByIdStatus):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        * bytecode/PutByIdStatus.h:
        (JSC::PutByIdStatus::PutByIdStatus):
        (JSC::PutByIdStatus::structureChain):
        (PutByIdStatus):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDesiredStructureChains.cpp: Added.
        (DFG):
        (JSC::DFG::DesiredStructureChains::DesiredStructureChains):
        (JSC::DFG::DesiredStructureChains::~DesiredStructureChains):
        (JSC::DFG::DesiredStructureChains::areStillValid):
        * dfg/DFGDesiredStructureChains.h: Added.
        (DFG):
        (DesiredStructureChains):
        (JSC::DFG::DesiredStructureChains::addLazily):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isStillValid):
        (DFG):
        * dfg/DFGGraph.h:
        (Graph):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::linkFunction):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * runtime/IntendedStructureChain.cpp: Added.
        (JSC):
        (JSC::IntendedStructureChain::IntendedStructureChain):
        (JSC::IntendedStructureChain::~IntendedStructureChain):
        (JSC::IntendedStructureChain::isStillValid):
        (JSC::IntendedStructureChain::matches):
        (JSC::IntendedStructureChain::chain):
        (JSC::IntendedStructureChain::mayInterceptStoreTo):
        (JSC::IntendedStructureChain::isNormalized):
        (JSC::IntendedStructureChain::terminalPrototype):
        * runtime/IntendedStructureChain.h: Added.
        (JSC):
        (IntendedStructureChain):
        (JSC::IntendedStructureChain::head):
        (JSC::IntendedStructureChain::size):
        (JSC::IntendedStructureChain::at):
        (JSC::IntendedStructureChain::operator[]):
        (JSC::IntendedStructureChain::last):
        * runtime/Structure.cpp:
        (JSC::Structure::prototypeChainMayInterceptStoreTo):
        * runtime/Structure.h:
        (Structure):
        * runtime/StructureInlines.h:
        (JSC::Structure::storedPrototypeObject):
        (JSC):
        (JSC::Structure::storedPrototypeStructure):

2013-05-06  Mark Lam  <mark.lam@apple.com>

        Fix broken 32-bit build + some clean up in JITStubs.cpp.
        https://bugs.webkit.org/show_bug.cgi?id=115684.

        Reviewed by Geoffrey Garen.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITStubs.cpp:
        - removed unneeded stubs for CPU(X86_64) && USE(JSVALUE32_64).
        - added some line breaks to more clearly delineate between
          ports/configurations of stub code.

2013-05-05  Geoffrey Garen  <ggaren@apple.com>

        Rolled back in r149527 with crash fixed.

        Reviewed by Oliver Hunt.

            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.

2013-05-03  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG::ByteCodeParser doesn't need ExecState*
        https://bugs.webkit.org/show_bug.cgi?id=115582

        Reviewed by Geoffrey Garen.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::ByteCodeParser):
        (ByteCodeParser):
        (JSC::DFG::parse):
        * dfg/DFGByteCodeParser.h:
        (DFG):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):

2013-05-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Profiler should be thread-safe
        https://bugs.webkit.org/show_bug.cgi?id=115445

        Reviewed by Geoffrey Garen.
        
        Change the Profiler::Database API for Compilation creation so that we don't add
        it to the Database until it's completely constructed. This prevents the Database
        from seeing Compilations that are being concurrently constructed.
        
        Change the Profiler::Database itself to do locking for creation of Bytecodes and
        for modifying the map. This map may be consulted by both the main thread and the
        concurrent thread.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::linkFunction):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * profiler/ProfilerBytecodes.h:
        * profiler/ProfilerDatabase.cpp:
        (JSC::Profiler::Database::ensureBytecodesFor):
        (JSC::Profiler::Database::notifyDestruction):
        (JSC::Profiler::Database::addCompilation):
        * profiler/ProfilerDatabase.h:
        (Database):

2013-05-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG tries to ref/deref StringImpls in a ton of places
        https://bugs.webkit.org/show_bug.cgi?id=115300

        Reviewed by Geoffrey Garen.
        
        Change any code transitively called from DFG compilation to use StringImpl*
        directly instead of String, Identifier, or PropertyName. I use the convention
        of passing "StringImpl* uid" instead of an Identifier or PropertyName.
        
        Switch over any code transitively called from DFG compilation to use CStrings
        whenever possible for all of its debug dumping.
        
        This makes it possible to compile things without hitting the ref/deref
        assertion in StringImpl.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::inferredName):
        (JSC::CodeBlock::sourceCodeForTools):
        (JSC::CodeBlock::sourceCodeOnOneLine):
        (JSC::constantName):
        (JSC::idName):
        (JSC::CodeBlock::registerName):
        (JSC::regexpToSourceString):
        (JSC::regexpName):
        (JSC::pointerToSourceString):
        (JSC::CodeBlock::printUnaryOp):
        (JSC::CodeBlock::printBinaryOp):
        (JSC::CodeBlock::printConditionalJump):
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::dumpStructure):
        (JSC::CodeBlock::printCallOp):
        (JSC::CodeBlock::printPutByIdOp):
        (JSC::CodeBlock::printStructure):
        (JSC::CodeBlock::printStructures):
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * bytecode/CodeBlockHash.cpp:
        (JSC::CodeBlockHash::CodeBlockHash):
        * bytecode/CodeOrigin.cpp:
        (JSC::InlineCallFrame::inferredName):
        * bytecode/CodeOrigin.h:
        (InlineCallFrame):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        (JSC::GetByIdStatus::computeForChain):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/GetByIdStatus.h:
        (JSC):
        (GetByIdStatus):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        * bytecode/PutByIdStatus.h:
        (JSC):
        (PutByIdStatus):
        * bytecode/ReduceWhitespace.cpp:
        (JSC::reduceWhitespace):
        * bytecode/ReduceWhitespace.h:
        (JSC):
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC::computeForStructure):
        (JSC::ResolveGlobalStatus::computeFor):
        * bytecode/ResolveGlobalStatus.h:
        (JSC):
        (ResolveGlobalStatus):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (JSC::DFG::ByteCodeParser::parseResolveOperations):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGDesiredIdentifiers.cpp: Added.
        (DFG):
        (JSC::DFG::DesiredIdentifiers::DesiredIdentifiers):
        (JSC::DFG::DesiredIdentifiers::~DesiredIdentifiers):
        (JSC::DFG::DesiredIdentifiers::addLazily):
        (JSC::DFG::DesiredIdentifiers::reallyAdd):
        * dfg/DFGDesiredIdentifiers.h: Added.
        (DFG):
        (DesiredIdentifiers):
        (JSC::DFG::DesiredIdentifiers::numberOfIdentifiers):
        (JSC::DFG::DesiredIdentifiers::at):
        (JSC::DFG::DesiredIdentifiers::operator[]):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
        (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (Graph):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryBuildGetByIDList):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::identifierUID):
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::compile):
        * parser/SourceCode.cpp: Added.
        (JSC):
        (JSC::SourceCode::toUTF8):
        * parser/SourceCode.h:
        (SourceCode):
        * profiler/ProfilerBytecodes.cpp:
        (JSC::Profiler::Bytecodes::toJS):
        * profiler/ProfilerBytecodes.h:
        (JSC::Profiler::Bytecodes::inferredName):
        (JSC::Profiler::Bytecodes::sourceCode):
        (Bytecodes):
        * runtime/Identifier.h:
        (JSC::Identifier::utf8):
        (JSC):
        * runtime/Structure.cpp:
        (JSC::Structure::addPropertyTransitionToExistingStructureImpl):
        (JSC::Structure::addPropertyTransitionToExistingStructure):
        (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
        (JSC::Structure::getConcurrently):
        (JSC::Structure::prototypeChainMayInterceptStoreTo):
        (JSC):
        * runtime/Structure.h:
        (Structure):
        * runtime/StructureInlines.h:
        (JSC::Structure::getConcurrently):

2013-05-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Structure transition table keys don't have to ref their StringImpl's
        https://bugs.webkit.org/show_bug.cgi?id=115525

        Reviewed by Geoffrey Garen.
        
        The structure transition table basically maps string to structure. The string is
        always also stored, and ref'd, in the structure in Structure::m_nameInPrevious.
        m_nameInPrevious is never mutated, and never cleared. The string cannot die unless
        the structure dies. If the structure dies, then that entry in the transition map
        becomes a zombie anyway and we will detect this separately.
        
        So, we don't need to use RefPtr<StringImpl>. We can just use StringImpl*.
        
        This also fixes a goof where we were getting the StringImpl's hash rather than
        using a pointer hash. Not only is the latter faster, but it prevents my change
        from leading to crashes: with my change we can have zombie keys, not just zombie
        values. They will exist only until the next map mutation, which will clear them.
        Lookups will work fine because the lookup routine will reject zombies. But it
        does mean that the HashMap will have to deal with dangling StringImpl*'s; all it
        takes to make this work is to ensure that the HashMap itself never dereferences
        them. Using a pointer hash rather than StringImpl::existingHash() accomplishes
        this.
        
        This also ensures that we don't accidentally call ref() or deref() from the
        compilation thread, if the compilation thread inspects the transition table.
        
        And no, we wouldn't have been able to use the HashMap<RefPtr<...>, ...>
        specialization, because the transition table is actually
        HashMap<pair<RefPtr<StringImpl>, unsigned>, ...>: hence that specialization
        doesn't kick in. We could have written a new specialization or something, but
        that seemed like a lot of work given that we don't need the table to be ref'ing
        the strings anyways.

        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::add):
        * runtime/StructureTransitionTable.h:
        (StructureTransitionTable):
        (Hash):
        (JSC::StructureTransitionTable::Hash::hash):

2013-05-01  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Structure::addPropertyTransitionToExistingStructure should be thread-safe
        https://bugs.webkit.org/show_bug.cgi?id=115468

        Reviewed by Geoffrey Garen.
        
        This makes the main thread modify the transition table while holding a lock. Note
        that the GC might modify its weak pointers without locking, but the GC will lock out
        the compilation thread anyway. The map will then only reshape in response to add()
        and set(), which happen while holding a lock.
        
        This allows the compilation thread to now query transition tables safely, provided it
        holds a lock when doing so.
        
        Also changed LLVM asm printer initialization to just initialize the X86 one. It makes
        sense for us to just initialize the asm printer(s) that we actually use; you could
        imagine us being linked to a system LLVM that has cross-compilation support; there is
        no point in the WebKit or JSC process doing work to initialize all of those targets.
        That part was rubber stamped by Mark Hahnenberg.
        
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreadingOnce):
        * runtime/Structure.cpp:
        (JSC::Structure::addPropertyTransitionToExistingStructureImpl):
        (JSC::Structure::addPropertyTransitionToExistingStructure):
        (JSC):
        (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
        (JSC::Structure::addPropertyTransition):
        (JSC::Structure::nonPropertyTransition):
        * runtime/Structure.h:
        (Structure):

2013-04-30  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Structure::getConcurrently() may be called from for uncacheable dictionaries, and this is safe
        https://bugs.webkit.org/show_bug.cgi?id=115464

        Reviewed by Oliver Hunt and Geoffrey Garen.
        
        This can happen for example transitively from JSObject::put(). getCurrently() does
        work for uncacheable dictionaries; it just has the obvious race that right after it
        returns, the result it returned may no longer be right. This isn't an issue if it was
        called on the main thread, and may not be an issue in some other situations.
        
        So, we should just remove the assertion, since the only thing it buys us is crashes.

        * runtime/Structure.cpp:
        (JSC::Structure::getConcurrently):

2013-04-30  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Don't link gtest into JavaScriptCore

        Rubber stamped by Mark Rowe.

        * Configurations/JavaScriptCore.xcconfig:

2013-04-29  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: String::utf8() should also be available as StringImpl::utf8() so that you don't have to ref() a StringImpl just to get its utf8()
        https://bugs.webkit.org/show_bug.cgi?id=115393

        Reviewed by Geoffrey Garen.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::encode):

2013-07-16  Oliver Hunt <oliver@apple.com>

        Merge dfgFourthTier r149301

    2013-04-28  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: ASSERT that commonly used not-thread-safe methods in the runtime are not being called during compilation
        https://bugs.webkit.org/show_bug.cgi?id=115297

        Reviewed by Geoffrey Garen.
        
        Put in assertions that we're not doing bad things in compilation threads. Also
        factored compilation into compile+link so that even though we don't yet have
        concurrent compilation, we can be explicit about which parts of DFG work are
        meant to be concurrent, and which aren't.
        
        Also fix a handful of bugs found by these assertions.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC::computeForStructure):
        * bytecode/Watchpoint.cpp:
        (JSC::WatchpointSet::add):
        (JSC::InlineWatchpointSet::inflateSlow):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::~JITCompiler):
        (DFG):
        (JSC::DFG::JITCompiler::compileBody):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compileFunction):
        (JSC::DFG::JITCompiler::linkFunction):
        * dfg/DFGJITCompiler.h:
        (JITCompiler):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLCompile.h:
        (FTL):
        * ftl/FTLLink.cpp: Added.
        (FTL):
        (JSC::FTL::compileEntry):
        (JSC::FTL::link):
        * ftl/FTLLink.h: Added.
        (FTL):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        * ftl/FTLState.h:
        (FTL):
        (State):
        * runtime/Structure.cpp:
        (JSC::Structure::get):
        (JSC::Structure::prototypeChainMayInterceptStoreTo):
        * runtime/Structure.h:
        (JSC::Structure::materializePropertyMapIfNecessary):
        * runtime/StructureInlines.h:
        (JSC::Structure::get):

2013-04-27  Filip Pizlo  <fpizlo@apple.com>

        FTL should support double variables
        https://bugs.webkit.org/show_bug.cgi?id=113624

        Reviewed by Geoffrey Garen.
        
        Made all of the operations that the FTL already supports, also support doubles.
        OSR exit already basically had everything it needed, so no changes there. This
        mostly just glues together bits of DFG IR to LLVM IR, in a straight-forward way.

        * ftl/FTLAbbreviations.h:
        (FTL):
        (JSC::FTL::doubleType):
        (JSC::FTL::constReal):
        (JSC::FTL::buildPhi):
        (JSC::FTL::addIncoming):
        (JSC::FTL::buildFAdd):
        (JSC::FTL::buildFSub):
        (JSC::FTL::buildFMul):
        (JSC::FTL::buildFNeg):
        (JSC::FTL::buildSIToFP):
        (JSC::FTL::buildUIToFP):
        (JSC::FTL::buildBitCast):
        (JSC::FTL::buildFCmp):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h:
        (CommonValues):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
        (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
        (JSC::FTL::LowerDFGToLLVM::compileAdd):
        (JSC::FTL::LowerDFGToLLVM::compileArithSub):
        (JSC::FTL::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
        (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
        (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
        (JSC::FTL::LowerDFGToLLVM::lowDouble):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::lowJSValue):
        (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
        (JSC::FTL::LowerDFGToLLVM::unboxDouble):
        (JSC::FTL::LowerDFGToLLVM::boxDouble):
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::speculateNumber):
        (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
        (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::constDouble):
        (Output):
        (JSC::FTL::Output::phi):
        (JSC::FTL::Output::doubleAdd):
        (JSC::FTL::Output::doubleSub):
        (JSC::FTL::Output::doubleMul):
        (JSC::FTL::Output::doubleNeg):
        (JSC::FTL::Output::intToFP):
        (JSC::FTL::Output::intToDouble):
        (JSC::FTL::Output::unsignedToFP):
        (JSC::FTL::Output::unsignedToDouble):
        (JSC::FTL::Output::bitCast):
        (JSC::FTL::Output::loadDouble):
        (JSC::FTL::Output::storeDouble):
        (JSC::FTL::Output::doubleEqual):
        (JSC::FTL::Output::doubleNotEqualOrUnordered):
        (JSC::FTL::Output::doubleLessThan):
        (JSC::FTL::Output::doubleLessThanOrEqual):
        (JSC::FTL::Output::doubleGreaterThan):
        (JSC::FTL::Output::doubleGreaterThanOrEqual):
        (JSC::FTL::Output::doubleEqualOrUnordered):
        (JSC::FTL::Output::doubleNotEqual):
        (JSC::FTL::Output::doubleLessThanOrUnordered):
        (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
        (JSC::FTL::Output::doubleGreaterThanOrUnordered):
        (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
        (JSC::FTL::Output::testIsZero64):

2013-04-27  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: SymbolTable should be thread-safe
        https://bugs.webkit.org/show_bug.cgi?id=115301

        Reviewed by Geoffrey Garen.
        
        Makes SymbolTable thread-safe. Relies on SymbolTableEntry already being immutable,
        other than the WatchpointSet; but the WatchpointSet already has a righteous
        concurrency protocol. So, this patch just protects the SymbolTable's HashMap.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::nameForRegister):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):
        * runtime/Executable.cpp:
        (JSC::ProgramExecutable::addGlobalVar):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::getOwnNonIndexPropertyNames):
        (JSC::JSActivation::symbolTablePutWithAttributes):
        * runtime/JSSymbolTableObject.cpp:
        (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutWithAttributes):
        * runtime/SymbolTable.cpp:
        (JSC::SymbolTable::SymbolTable):
        (JSC::SymbolTable::~SymbolTable):
        * runtime/SymbolTable.h:
        (JSC::SymbolTable::find):
        (JSC::SymbolTable::get):
        (JSC::SymbolTable::inlineGet):
        (JSC::SymbolTable::begin):
        (JSC::SymbolTable::end):
        (JSC::SymbolTable::size):
        (JSC::SymbolTable::add):
        (JSC::SymbolTable::set):
        (JSC::SymbolTable::contains):

2013-04-26  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: WatchpointSet should make racy uses easier to reason about
        https://bugs.webkit.org/show_bug.cgi?id=115299

        Reviewed by Anders Carlsson.
        
        The compiler often does things like:

        1c) Observe something that would imply that a WatchpointSet ought to be invalid

        2c) Check that it is invalid

        The main thread often does things like:

        1m) Fire the watchpoint set

        2m) Do some other thing that would cause the compiler to assume that the WatchpointSet
        ought to be invalid

        An example is structure transitions, where (1c) is the compiler noticing that a
        put_by_id inline cache is in a transition state, with the source structure being S;
        (2c) is the compiler asserting that S's watchpoint set is invalid; (1m) is the main
        thread firing S's watchpoint set before it does the first transition away from S; and
        (2m) is the main thread caching the put_by_id transition away from S.

        This is totally fine, except that (1c) and (2c), and (1m) and (2m) could be reordered.
        Probably, in most cases, this ought to do enough things that the main thread probably
        already has some fencing. But the compiler thread definitely doesn't have fencing. In
        any case, we should play it safe and just have additional fencing in all of the
        relevant places.

        We already have some idioms to put load-load and store-store fences in the right
        places. But this change just makes WatchpointSet take care of this for us, thus
        reducing the chances of us getting this wrong.

        * bytecode/Watchpoint.cpp:
        (JSC::WatchpointSet::notifyWriteSlow):
        * bytecode/Watchpoint.h:
        (WatchpointSet):
        (JSC::WatchpointSet::isStillValid):
        (JSC::WatchpointSet::hasBeenInvalidated):
        (JSC::InlineWatchpointSet::hasBeenInvalidated):
        (JSC::InlineWatchpointSet::notifyWrite):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGDesiredWatchpoints.h:
        (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState):

2013-07-16  Oliver Hunt <oliver@apple.com>

        Merge dfgFourthTier r149233

    2013-04-26  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: CFA should defend against results seeming inconsistent due to a watchpoint firing during compilation
        https://bugs.webkit.org/show_bug.cgi?id=115083

        Reviewed by Geoffrey Garen.
        
        This ruggedizes our racyness with respect to watchpoints. We want to be able to assert,
        in some places, that a watchpoint-based optimization has only occurred if the
        watchpoint set was still valid. But currently we *can* soundly do watchpoint-based
        optimizations even for invalid watchpoints, so long as we recorded in the IR that we
        had done so; this will then lead to the code being insta-jettisoned after compilation
        completes. Obviously, we don't want this to happen often - but we do want to allow it
        precisely in the case of watchpoint races.
        
        This adds the ability to assert that we hadn't over-watchpointed ourselves, with and
        exemption for races.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::executeEffects):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::setFuturePossibleStructure):
        (JSC::DFG::AbstractValue::filterFuturePossibleStructure):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addStructureTransitionCheck):
        (JSC::DFG::ByteCodeParser::parseResolveOperations):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
        * dfg/DFGDesiredWatchpoints.h:
        (GenericDesiredWatchpoints):
        (JSC::DFG::GenericDesiredWatchpoints::isStillValid):
        (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState):
        (JSC::DFG::GenericDesiredWatchpoints::isValidOrMixed):
        (JSC::DFG::DesiredWatchpoints::isStillValid):
        (JSC::DFG::DesiredWatchpoints::shouldAssumeMixedState):
        (JSC::DFG::DesiredWatchpoints::isValidOrMixed):
        (DesiredWatchpoints):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::masqueradesAsUndefinedWatchpointIsStillValid):
        (Graph):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::addLazily):
        (JITCompiler):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid):
        (JSC::DFG::SpeculativeJIT::speculationWatchpointForMasqueradesAsUndefined):
        (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):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLState.h:
        (State):

2013-04-23  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: AbstractValue methods that deal with watchpoints should have access to Graph, so that in debug mode, Graph can track the history of watchpoint states and detect races
        https://bugs.webkit.org/show_bug.cgi?id=115084

        Reviewed by Geoffrey Garen.
        
        The idea is that as part of https://bugs.webkit.org/show_bug.cgi?id=115083, I'll have
        Graph record the initial state of a watchpoint at the time that we decide to take
        advantage of it; then I will use this to disable any watchpoint-related assertions
        in debug mode. Note that this "watchpoint cache" will only be maintained in debug
        mode, so there will be no release performance implications. But to do this, I need to
        ensure that all of the places that reason about watchpoints have access to Graph.
        For example, I'll want AbstractValue::setFuturePossibleStructure to record the state
        of the watchpoint in Graph so that subsequent assertions can check if the watchpoint's
        state had changed since that decision was made.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        (JSC::DFG::AbstractState::executeEffects):
        (JSC::DFG::AbstractState::mergeStateAtTail):
        * dfg/DFGAbstractState.h:
        (JSC::DFG::AbstractState::trySetConstant):
        * dfg/DFGAbstractValue.cpp: Added.
        (DFG):
        (JSC::DFG::AbstractValue::setMostSpecific):
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::filter):
        (JSC::DFG::AbstractValue::setFuturePossibleStructure):
        (JSC::DFG::AbstractValue::filterFuturePossibleStructure):
        (JSC::DFG::AbstractValue::dump):
        * dfg/DFGAbstractValue.h:
        (DFG):
        (AbstractValue):
        (JSC::DFG::AbstractValue::setType):
        (JSC::DFG::AbstractValue::filterByValue):

2013-07-16  Oliver Hunt <oliver@apple.com>

        Merge dfgFourthTier r148936

    2013-04-22  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Create an equivalent of Structure::get() that can work from a compilation thread
        https://bugs.webkit.org/show_bug.cgi?id=114987

        Reviewed by Geoffrey Garen.
        
        This completes the work started by r148570. That patch made it possible to do
        Structure::get() without modifying Structure. This patch takes this further, and
        makes this thread-safe (for non-uncacheable-dictionaries) via
        Structure::getConcurrently(). This method not only doesn't modify Structure, but
        also ensures that any concurrent attempts to add to, remove from, or steal the
        table from that structure doesn't mess up the result of the call. The call may
        return invalidOffset even if a property is *just* about to be added, but it will
        never do the reverse: if it returns a property then you can be sure that the
        structure really does have that property and always will have it.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        (JSC::GetByIdStatus::computeForChain):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
        * runtime/PropertyMapHashTable.h:
        (PropertyTable):
        (JSC::PropertyTable::findConcurrently):
        (JSC):
        (JSC::PropertyTable::add):
        (JSC::PropertyTable::remove):
        (JSC::PropertyTable::reinsert):
        (JSC::PropertyTable::rehash):
        * runtime/PropertyTable.cpp:
        (JSC::PropertyTable::PropertyTable):
        * runtime/Structure.cpp:
        (JSC::Structure::findStructuresAndMapForMaterialization):
        (JSC::Structure::getConcurrently):
        * runtime/Structure.h:
        (Structure):
        * runtime/StructureInlines.h:
        (JSC::Structure::getConcurrently):

2013-07-16  Oliver Hunt <oliver@apple.com>

        Merge dfgFourthTier r148850

    2013-04-21  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: WebKit's build system should relink JavaScriptCore if LLVM's libraries changed but its headers didn't
        https://bugs.webkit.org/show_bug.cgi?id=114926

        Reviewed by Geoffrey Garen.
        
        Use a phony file that includes a phony header to force JavaScriptCore to be relinked
        if necessary. The external LLVM-importing scripts will touch the header if the libraries
        are known to have changed.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/WebKitLLVMLibraryAnchor.cpp: Added.

2013-07-16  Oliver Hunt <oliver@apple.com>

        Merge dfgFourthTier r148836

    2013-04-21  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: It should be possible to query WatchpointSets, and add Watchpoints, even if the compiler is running in another thread
        https://bugs.webkit.org/show_bug.cgi?id=114909

        Reviewed by Oliver Hunt.
        
        The idea here is that a concurrent compiler will use watchpoint sets as follows:
        
        During concurrent compilation: It will create Watchpoints, and query WatchpointSets only
        for the purpose of profiling. That is, it will use decide whether it is profitable to
        compile the code "as if" the watchpoint sets are valid.
        
        During synchronous linking: By "linking" I don't necessarily mean the LinkBuffer stuff,
        but just the very bitter end of compilation where we make the JIT code callable. This
        can happen after LinkBuffer stuff. Anyway, this will have to happen synchronously, and
        at that point we can (a) check that all WatchpointSets that we assumed were valid are
        still valid and (b) if they are then we add the watchpoints to those sets. If any of the
        sets are invalid, we give up on this compilation and try again later.
        
        The querying of WatchpointSets is engineered to say that the set is still valid if it
        is so *right now*, but this is done in a racy way and so it may say so spuriously: we
        may, with hopefully low probability, have a set that says it is valid even though it was
        just invalidated. The goal is only to ensure that (i) a set never claims to be invalid
        if it is actually valid, (ii) a set doesn't claim to be valid if it was invalidated
        before compilation even began, and (iii) querying the validity of a set doesn't cause us
        to crash.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/Watchpoint.cpp:
        (JSC::InlineWatchpointSet::inflateSlow):
        * bytecode/Watchpoint.h:
        (WatchpointSet):
        (InlineWatchpointSet):
        (JSC::InlineWatchpointSet::hasBeenInvalidated):
        (JSC::InlineWatchpointSet::isThin):
        (JSC::InlineWatchpointSet::isFat):
        (JSC::InlineWatchpointSet::fat):
        * dfg/DFGDesiredWatchpoints.cpp: Added.
        (DFG):
        (JSC::DFG::DesiredWatchpoints::DesiredWatchpoints):
        (JSC::DFG::DesiredWatchpoints::~DesiredWatchpoints):
        (JSC::DFG::DesiredWatchpoints::addLazily):
        (JSC::DFG::DesiredWatchpoints::reallyAdd):
        (JSC::DFG::DesiredWatchpoints::areStillValid):
        * dfg/DFGDesiredWatchpoints.h: Added.
        (DFG):
        (JSC::DFG::WatchpointForGenericWatchpointSet::WatchpointForGenericWatchpointSet):
        (WatchpointForGenericWatchpointSet):
        (GenericDesiredWatchpoints):
        (JSC::DFG::GenericDesiredWatchpoints::GenericDesiredWatchpoints):
        (JSC::DFG::GenericDesiredWatchpoints::addLazily):
        (JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
        (JSC::DFG::GenericDesiredWatchpoints::areStillValid):
        (DesiredWatchpoints):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::addLazily):
        (JITCompiler):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
        * 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):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLCompile.h:
        (FTL):
        * ftl/FTLState.h:
        (State):
        * runtime/JSFunction.h:
        (JSFunction):
        (JSC::JSFunction::allocationProfileWatchpointSet):
        * runtime/Structure.h:
        (Structure):
        (JSC::Structure::transitionWatchpointSet):

2013-07-16  Oliver Hunt <oliver@apple.com>

        Merge dfgFourthTier r148804

    2013-04-20  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: value profiles and array profiles should be thread-safe enough to be accessible in a concurrent compilation thread
        https://bugs.webkit.org/show_bug.cgi?id=114906

        Reviewed by Oliver Hunt.
        
        This introduces thread safety to value profiles, array profiles, and
        array allocation profiles.
        
        We already have three separate operations that happen on profiles:
        (1) writing, which the JIT, LLInt, and OSR exit do; (2) updating,
        which happens during GC, from OSR entry slow-paths, and in the DFG;
        and (3) reading, which happens in the DFG. For example, the JIT/LLInt
        and OSR exit write to ValueProfile::m_buckets, which gets synthesized
        into ValueProfile::m_prediction (and other fields) during update, and
        the latter gets read by the DFG. Note that (2) must also happen in
        the DFG since only the DFG knows which code blocks it will inline,
        and those blocks' profiles may not have otherwise been updated via
        any other mechanism.
        
        I refer to these three operations as writing, updating, and reading.
        
        Consequently, both profile updating and profile reading may happen
        asynchronously, if the JIT is asynchronous.
        
        The locking protocol for profiles works as follows:
        
        - Writing does not require locking, but is only allowed on the main
          thread. We require that these fields can be stored atomically by
          the profiling code, even without locks. For value profiles, this
          only works on 64-bit platforms, currently. For array profiles,
          which consist of multiple separate fields, this means that an
          asynchronous update of the profile may see slight inconsistencies
          (like a structure that doesn't quite match the array modes bits),
          but these should be harmless: at worst, the DFG will specialize
          too much and we'll have OSR exits.
        
        - Updating a value profile requires holding a lock, but must assume
          that the fields written by the profiling code in JIT/LLInt may
          be written to without locking.
        
        - Reading a value profile requires holding a lock.
        
        The one major exception to these rules is the ArrayAllocationProfile,
        which requires no locking. We do this because it's used so often and
        in places where we don't necessarily have access to the owning
        CodeBlock, so if we did want it to be locked it would have to have
        its own lock. Also, I believe that it is sound to just make this
        profile racy and not worry about locking at all. All that was needed
        were some changes to ensure that we explicitly read some raced-over
        fields only once.

        Two additional interesting things in this change:
        
        - To make it easy to see which profile methods require locking, they
          take a const CodeBlockLocker& as an argument. I saw this idiom for
          identifying which methods require which locks to be held being used
          in LLVM, and I quite like it.
        
        - Lazy operand value profiles, which are created lazily and at any
          time, require the CodeBlockLock to be held when they are being
          created. Writes to them are lockless and main-thread-only, but as
          with other profiles, updates and reads require locking.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ArrayAllocationProfile.cpp:
        (JSC::ArrayAllocationProfile::updateIndexingType):
        * bytecode/ArrayAllocationProfile.h:
        (JSC::ArrayAllocationProfile::selectIndexingType):
        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        (JSC::ArrayProfile::briefDescription):
        * bytecode/ArrayProfile.h:
        (ArrayProfile):
        (JSC::ArrayProfile::expectedStructure):
        (JSC::ArrayProfile::structureIsPolymorphic):
        (JSC::ArrayProfile::hasDefiniteStructure):
        (JSC::ArrayProfile::observedArrayModes):
        (JSC::ArrayProfile::mayInterceptIndexedAccesses):
        (JSC::ArrayProfile::mayStoreToHole):
        (JSC::ArrayProfile::outOfBounds):
        (JSC::ArrayProfile::usesOriginalArrayStructures):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFor):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpValueProfiling):
        (JSC::CodeBlock::dumpArrayProfiling):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        (JSC::CodeBlock::updateAllArrayPredictions):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
        (JSC::CodeBlock::updateAllPredictionsAndCheckIfShouldOptimizeNow):
        (CodeBlock):
        * bytecode/CodeBlockLock.h: Added.
        (JSC):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        * bytecode/LazyOperandValueProfile.cpp:
        (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
        (JSC::CompressedLazyOperandValueProfileHolder::add):
        (JSC::LazyOperandValueProfileParser::LazyOperandValueProfileParser):
        (JSC::LazyOperandValueProfileParser::~LazyOperandValueProfileParser):
        (JSC):
        (JSC::LazyOperandValueProfileParser::initialize):
        (JSC::LazyOperandValueProfileParser::prediction):
        * bytecode/LazyOperandValueProfile.h:
        (CompressedLazyOperandValueProfileHolder):
        (LazyOperandValueProfileParser):
        * bytecode/MethodOfGettingAValueProfile.cpp:
        (JSC::MethodOfGettingAValueProfile::getSpecFailBucket):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC::ResolveGlobalStatus::computeFor):
        * bytecode/ValueProfile.h:
        (JSC::ValueProfileBase::briefDescription):
        (ValueProfileBase):
        (JSC::ValueProfileBase::computeUpdatedPrediction):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):
        * dfg/DFGArrayMode.h:
        (ArrayMode):
        (JSC::DFG::ArrayMode::withProfile):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
        (JSC::DFG::ByteCodeParser::parseResolveOperations):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * dfg/DFGPredictionInjectionPhase.cpp:
        (JSC::DFG::PredictionInjectionPhase::run):
        * jit/JITInlines.h:
        (JSC::JIT::chooseArrayMode):
        * jit/JITStubs.cpp:
        (JSC::tryCachePutByID):
        (JSC::tryCacheGetByID):
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::lazyLinkFor):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::setUpCall):
        * profiler/ProfilerBytecodeSequence.cpp:
        (JSC::Profiler::BytecodeSequence::BytecodeSequence):
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolveContainingScopeInternal):
        (JSC::JSScope::resolvePut):

2013-04-17  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: all inline caches should thread-safe enough to allow a concurrent compilation thread to read them safely
        https://bugs.webkit.org/show_bug.cgi?id=114762

        Reviewed by Mark Hahnenberg.
        
        For most inline caches this is easy: the inline cache has a clean temporal
        separation between doing the requested action (which may take an unbounded
        amount of time, may recurse, and may do arbitrary things) and recording the
        relevant information in the cache. So, we just put locks around the
        recording bit. That part is always O(1) and does not recurse. The lock we
        use is per-CodeBlock to achieve a good balance between locking granularity
        and low space overhead. So a concurrent compilation thread will only block
        if an inline cache ping-pongs in the code block being compiled (or inlined)
        and never when other inline caches do things.
        
        For resolve operations, it's a bit tricky. The global resolve bit works
        like any other IC in that it has the clean temporal separation. But the
        operations vector itself doesn't have this separation, since we will be
        filling it in tandem with actions that may take a long time. This patch
        gets around this by having a m_ready bit in the ResolveOperations and
        PutToBaseOperation. This is set while holding the CodeBlock's lock. If the
        DFG observes the m_ready bit not set (while holding the lock) then it
        conservatively assumes that the resolve hasn't happened yet and just
        plants a ForceOSRExit.

        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFor):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC::ResolveGlobalStatus::computeFor):
        * bytecode/ResolveOperation.h:
        (JSC::ResolveOperations::ResolveOperations):
        (ResolveOperations):
        (JSC::PutToBaseOperation::PutToBaseOperation):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseResolveOperations):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * jit/JITStubs.cpp:
        (JSC::tryCachePutByID):
        (JSC::tryCacheGetByID):
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC::lazyLinkFor):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::setUpCall):
        * runtime/JSScope.cpp:
        (JSC::JSScope::resolveContainingScopeInternal):
        (JSC::JSScope::resolveContainingScope):
        (JSC::JSScope::resolvePut):

2013-04-16  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should be able to query Structure without modifying it
        https://bugs.webkit.org/show_bug.cgi?id=114708

        Reviewed by Oliver Hunt.
        
        This is work towards allowing the DFG, and FTL, to run on a separate thread.
        The idea is that the most evil thing that the DFG does that has thread-safety
        issues is fiddling with Structures by calling Structure::get(). This can lead
        to rematerialization of property tables, which is definitely not thread-safe
        due to how StringImpl works. So, this patch completely side-steps the problem
        by creating a new version of Structure::get, called
        Structure::getWithoutMaterializing, which may choose to do an O(n) search if
        necessary to avoid materialization. I believe this should be fine - the DFG
        does't call into these code path often enough for this to matter, and most of
        the time, the Structure that we call this on will already have a property
        table because some inline cache would have already called ::get() on that
        Structure.
        
        Also cleaned up the materialization logic: we can stop the search as soon as
        we find any Structure with a property table rather than searching all the way
        for a pinned one.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        * runtime/Structure.cpp:
        (JSC::Structure::findStructuresAndMapForMaterialization):
        (JSC::Structure::materializePropertyMap):
        (JSC::Structure::getWithoutMaterializing):
        (JSC):
        * runtime/Structure.h:
        (Structure):
        * runtime/StructureInlines.h:
        (JSC::Structure::getWithoutMaterializing):
        (JSC):

2013-04-13  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Fix release build.

        * dfg/DFGOSRExitCompilerCommon.cpp:
        * ftl/FTLExitValue.cpp:
        * ftl/FTLOSRExitCompiler.cpp:

2013-04-13  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should have OSR exit
        https://bugs.webkit.org/show_bug.cgi?id=113623

        Reviewed by Oliver Hunt.
        
        This implements OSR exit, and hilariously, it actually works. The idea is to have
        LLVM call a no-return function on the off-ramp, passing it everything we know about
        bytecode state that isn't already flushed to the call frame. Our own JIT takes care
        of the rest.
        
        We can now run all of SunSpider, V8, and Kraken with the FTL enabled.
        
        The details are described in FTLOSRExit.h.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/AbstractMacroAssembler.h:
        (Address):
        (JSC::AbstractMacroAssembler::Address::withOffset):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::offsetOf):
        (LinkBuffer):
        * assembler/MacroAssemblerX86Common.h:
        * assembler/RepatchBuffer.h:
        (JSC::RepatchBuffer::RepatchBuffer):
        (JSC::RepatchBuffer::~RepatchBuffer):
        (RepatchBuffer):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::tallyFrequentExitSites):
        * bytecode/Operands.h:
        (Operands):
        (JSC):
        (JSC::::dump):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        * dfg/DFGGPRInfo.h:
        (DFG):
        (GPRInfo):
        * dfg/DFGMinifiedNode.h:
        (JSC::DFG::belongsInMinifiedGraph):
        * dfg/DFGNodeType.h:
        (JSC::DFG::needsOSRBackwardRewiring):
        (DFG):
        (JSC::DFG::needsOSRForwardRewiring):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        (DFG):
        (JSC::DFG::OSRExit::convertToForward):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOSRExitBase.cpp: Added.
        (DFG):
        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
        (JSC::DFG::OSRExitBase::doSearchForForwardConversion):
        * dfg/DFGOSRExitBase.h: Added.
        (DFG):
        (JSC::DFG::OSRExitBase::OSRExitBase):
        (OSRExitBase):
        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::handleExitCounts):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGOSRExitCompilerCommon.h:
        (DFG):
        * dfg/DFGOSRExitPreparation.cpp: Added.
        (DFG):
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * dfg/DFGOSRExitPreparation.h: Added.
        (DFG):
        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        * dfg/DFGValueSource.h:
        (JSC::DFG::ValueSource::forSpeculation):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::functionType):
        (FTL):
        (JSC::FTL::typeOf):
        (JSC::FTL::appendBasicBlock):
        (JSC::FTL::insertBasicBlock):
        (JSC::FTL::buildCall):
        (JSC::FTL::setTailCall):
        * ftl/FTLCArgumentGetter.cpp: Added.
        (FTL):
        (JSC::FTL::CArgumentGetter::loadNextAndBox):
        * ftl/FTLCArgumentGetter.h: Added.
        (FTL):
        (JSC::FTL::isArgumentRegister):
        (CArgumentGetter):
        (JSC::FTL::CArgumentGetter::CArgumentGetter):
        (JSC::FTL::CArgumentGetter::loadNext8):
        (JSC::FTL::CArgumentGetter::loadNext32):
        (JSC::FTL::CArgumentGetter::loadNext64):
        (JSC::FTL::CArgumentGetter::loadNextPtr):
        (JSC::FTL::CArgumentGetter::loadNextDouble):
        (JSC::FTL::CArgumentGetter::nextAddress):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLExitArgument.cpp: Added.
        (FTL):
        (JSC::FTL::ExitArgument::dump):
        * ftl/FTLExitArgument.h: Added.
        (FTL):
        (ExitArgumentRepresentation):
        (ExitArgument):
        (JSC::FTL::ExitArgument::ExitArgument):
        (JSC::FTL::ExitArgument::operator!):
        (JSC::FTL::ExitArgument::format):
        (JSC::FTL::ExitArgument::argument):
        (JSC::FTL::ExitArgument::withFormat):
        (JSC::FTL::ExitArgument::representation):
        * ftl/FTLExitArgumentForOperand.cpp: Added.
        (FTL):
        (JSC::FTL::ExitArgumentForOperand::dump):
        * ftl/FTLExitArgumentForOperand.h: Added.
        (FTL):
        (ExitArgumentForOperand):
        (JSC::FTL::ExitArgumentForOperand::ExitArgumentForOperand):
        (JSC::FTL::ExitArgumentForOperand::operator!):
        (JSC::FTL::ExitArgumentForOperand::exitArgument):
        (JSC::FTL::ExitArgumentForOperand::operand):
        (JSC::FTL::lesserArgumentIndex):
        * ftl/FTLExitArgumentList.h: Added.
        (FTL):
        * ftl/FTLExitThunkGenerator.cpp: Added.
        (FTL):
        (JSC::FTL::ExitThunkGenerator::ExitThunkGenerator):
        (JSC::FTL::ExitThunkGenerator::~ExitThunkGenerator):
        (JSC::FTL::ExitThunkGenerator::emitThunk):
        * ftl/FTLExitThunkGenerator.h: Added.
        (FTL):
        (ExitThunkGenerator):
        (JSC::FTL::ExitThunkGenerator::didThings):
        * ftl/FTLExitValue.cpp: Added.
        (FTL):
        (JSC::FTL::ExitValue::dump):
        * ftl/FTLExitValue.h: Added.
        (FTL):
        (ExitValue):
        (JSC::FTL::ExitValue::ExitValue):
        (JSC::FTL::ExitValue::operator!):
        (JSC::FTL::ExitValue::dead):
        (JSC::FTL::ExitValue::inJSStack):
        (JSC::FTL::ExitValue::inJSStackAsInt32):
        (JSC::FTL::ExitValue::inJSStackAsDouble):
        (JSC::FTL::ExitValue::constant):
        (JSC::FTL::ExitValue::exitArgument):
        (JSC::FTL::ExitValue::kind):
        (JSC::FTL::ExitValue::isDead):
        (JSC::FTL::ExitValue::isInJSStackSomehow):
        (JSC::FTL::ExitValue::isConstant):
        (JSC::FTL::ExitValue::isArgument):
        * ftl/FTLFormattedValue.h:
        (FTL):
        (JSC::FTL::noValue):
        (JSC::FTL::int32Value):
        (JSC::FTL::uInt32Value):
        (JSC::FTL::booleanValue):
        (JSC::FTL::jsValueValue):
        (JSC::FTL::doubleValue):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::initializeExitThunks):
        (FTL):
        (JSC::FTL::JITCode::exitThunks):
        * ftl/FTLJITCode.h:
        (JITCode):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (FTL):
        (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments):
        (JSC::FTL::LowerDFGToLLVM::compileBlock):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
        (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compileMovHint):
        (JSC::FTL::LowerDFGToLLVM::compileZombieHint):
        (JSC::FTL::LowerDFGToLLVM::compileMovHintAndCheck):
        (JSC::FTL::LowerDFGToLLVM::compileAdd):
        (JSC::FTL::LowerDFGToLLVM::compileArithSub):
        (JSC::FTL::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
        (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
        (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::LowerDFGToLLVM::speculateBackward):
        (JSC::FTL::LowerDFGToLLVM::speculateForward):
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::terminate):
        (JSC::FTL::LowerDFGToLLVM::backwardTypeCheck):
        (JSC::FTL::LowerDFGToLLVM::forwardTypeCheck):
        (JSC::FTL::LowerDFGToLLVM::typeCheck):
        (JSC::FTL::LowerDFGToLLVM::appendTypeCheck):
        (JSC::FTL::LowerDFGToLLVM::lowInt32):
        (JSC::FTL::LowerDFGToLLVM::lowCell):
        (JSC::FTL::LowerDFGToLLVM::lowBoolean):
        (JSC::FTL::LowerDFGToLLVM::speculateObject):
        (JSC::FTL::LowerDFGToLLVM::isLive):
        (JSC::FTL::LowerDFGToLLVM::use):
        (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
        (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
        (JSC::FTL::LowerDFGToLLVM::tryToSetConstantExitArgument):
        (JSC::FTL::LowerDFGToLLVM::addExitArgument):
        (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
        (JSC::FTL::LowerDFGToLLVM::observeMovHint):
        * ftl/FTLOSRExit.cpp: Added.
        (FTL):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        (JSC::FTL::OSRExit::convertToForward):
        * ftl/FTLOSRExit.h: Added.
        (FTL):
        (OSRExit):
        * ftl/FTLOSRExitCompilationInfo.h: Added.
        (FTL):
        (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
        (OSRExitCompilationInfo):
        * ftl/FTLOSRExitCompiler.cpp: Added.
        (FTL):
        (JSC::FTL::compileStub):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLOSRExitCompiler.h: Added.
        (FTL):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::newBlock):
        (JSC::FTL::Output::intToPtr):
        (JSC::FTL::Output::load):
        (JSC::FTL::Output::store):
        (Output):
        (JSC::FTL::Output::call):
        (JSC::FTL::Output::convertToTailCall):
        (FTL):
        * ftl/FTLState.h:
        (State):
        * ftl/FTLThunks.cpp: Added.
        (FTL):
        (JSC::FTL::osrExitGenerationThunkGenerator):
        * ftl/FTLThunks.h: Added.
        (JSC):
        (FTL):
        * ftl/FTLValueFormat.cpp: Added.
        (WTF):
        (WTF::printInternal):
        * ftl/FTLValueFormat.h: Added.
        (FTL):
        (WTF):
        * ftl/FTLValueSource.cpp: Added.
        (FTL):
        (JSC::FTL::ValueSource::dump):
        * ftl/FTLValueSource.h: Added.
        (FTL):
        (ValueSource):
        (JSC::FTL::ValueSource::ValueSource):
        (JSC::FTL::ValueSource::kind):
        (JSC::FTL::ValueSource::operator!):
        (JSC::FTL::ValueSource::node):

2013-04-12  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: switch to using MCJIT and disable frame pointer elimination
        https://bugs.webkit.org/show_bug.cgi?id=114542

        Reviewed by Oliver Hunt and Michael Saboff.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreadingOnce):

2013-04-09  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should provide utilities for common OSR exit tasks
        https://bugs.webkit.org/show_bug.cgi?id=114306

        Reviewed by Mark Hahnenberg.
        
        Just abstract out some things that the FTL will want to use as well.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler.h:
        (OSRExitCompiler):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp: Added.
        (DFG):
        (JSC::DFG::handleExitCounts):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGOSRExitCompilerCommon.h: Added.
        (DFG):

2013-04-09  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should better abstract floating point arguments
        https://bugs.webkit.org/show_bug.cgi?id=114300

        Reviewed by Mark Hahnenberg.

        * dfg/DFGFPRInfo.h:
        (FPRInfo):
        (JSC::DFG::FPRInfo::toArgumentRegister):

2013-04-05  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should better abstract arguments
        https://bugs.webkit.org/show_bug.cgi?id=114073

        Reviewed by Mark Hahnenberg.

        * dfg/DFGGPRInfo.h:
        (GPRInfo):
        (JSC::DFG::GPRInfo::toArgumentRegister):

2013-04-03  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: put DFG data into a DFG::JITCode, and put common DFG and FTL data into something accessible from both DFG::JITCode and FTL::JITCode
        https://bugs.webkit.org/show_bug.cgi?id=113905

        Reviewed by Geoffrey Garen.
        
        This removes one pointer from CodeBlock.
        
        It also gives us a framework for having JITType-specific data in CodeBlock, by
        putting it into the appropriate JITCode class (either DFG::JITCode or
        FTL::JITCode). And it allows us to have DFG and FTL share some common data,
        via DFG::CommonData, which is stored in both DFG::JITCode and FTL::JITCode and
        always accessible via JITCode::dfgCommon().

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::visitAggregate):
        (JSC::CodeBlock::performTracingFixpointIteration):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::stronglyVisitWeakReferences):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::tallyFrequentExitSites):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
        (JSC::DFGCodeBlocks::mark):
        * dfg/DFGAssemblyHelpers.h:
        * dfg/DFGCommonData.cpp: Added.
        (DFG):
        (JSC::DFG::CommonData::notifyCompilingStructureTransition):
        (JSC::DFG::CommonData::shrinkToFit):
        * dfg/DFGCommonData.h: Added.
        (JSC):
        (DFG):
        (JSC::DFG::WeakReferenceTransition::WeakReferenceTransition):
        (WeakReferenceTransition):
        (CommonData):
        (JSC::DFG::CommonData::CommonData):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        * dfg/DFGDriver.h:
        (DFG):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        * dfg/DFGGraph.h:
        (Graph):
        * dfg/DFGJITCode.cpp: Added.
        (DFG):
        (JSC::DFG::JITCode::JITCode):
        (JSC::DFG::JITCode::~JITCode):
        (JSC::DFG::JITCode::dfgCommon):
        (JSC::DFG::JITCode::dfg):
        (JSC::DFG::JITCode::shrinkToFit):
        * dfg/DFGJITCode.h: Added.
        (DFG):
        (JITCode):
        (JSC::DFG::JITCode::appendOSREntryData):
        (JSC::DFG::JITCode::osrEntryDataForBytecodeIndex):
        (JSC::DFG::JITCode::appendOSRExit):
        (JSC::DFG::JITCode::lastOSRExit):
        (JSC::DFG::JITCode::appendSpeculationRecovery):
        (JSC::DFG::JITCode::appendWatchpoint):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JITCompiler):
        (JSC::DFG::JITCompiler::addWeakReference):
        (JSC::DFG::JITCompiler::noticeOSREntry):
        (JSC::DFG::JITCompiler::jitCode):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::backwardSpeculationCheck):
        (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGVariableEventStream.cpp:
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::JITCode):
        (JSC::FTL::JITCode::~JITCode):
        (FTL):
        (JSC::FTL::JITCode::initializeCode):
        (JSC::FTL::JITCode::addressForCall):
        (JSC::FTL::JITCode::executableAddressAtOffset):
        (JSC::FTL::JITCode::dataAddressAtOffset):
        (JSC::FTL::JITCode::offsetOf):
        (JSC::FTL::JITCode::size):
        (JSC::FTL::JITCode::contains):
        (JSC::FTL::JITCode::ftl):
        (JSC::FTL::JITCode::dfgCommon):
        * ftl/FTLJITCode.h:
        (JITCode):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint):
        (JSC::FTL::LowerDFGToLLVM::compilePutStructure):
        (JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure):
        (JSC::FTL::LowerDFGToLLVM::addWeakReference):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::weakPointer):
        * ftl/FTLState.cpp:
        (FTL):
        (JSC::FTL::State::State):
        (JSC::FTL::State::dumpState):
        * ftl/FTLState.h:
        (State):
        * heap/DFGCodeBlocks.cpp:
        (JSC::DFGCodeBlocks::~DFGCodeBlocks):
        (JSC::DFGCodeBlocks::jettison):
        (JSC::DFGCodeBlocks::clearMarks):
        (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
        (JSC::DFGCodeBlocks::traceMarkedCodeBlocks):
        * jit/JITCode.cpp:
        (JSC::JITCode::dfgCommon):
        (JSC):
        (JSC::JITCode::dfg):
        (JSC::JITCode::ftl):
        (JSC::DirectJITCode::DirectJITCode):
        (JSC::DirectJITCode::initializeCodeRef):
        (JSC::DirectJITCode::addressForCall):
        (JSC::DirectJITCode::executableAddressAtOffset):
        (JSC::DirectJITCode::dataAddressAtOffset):
        (JSC::DirectJITCode::offsetOf):
        (JSC::DirectJITCode::size):
        (JSC::DirectJITCode::contains):
        * jit/JITCode.h:
        (DFG):
        (FTL):
        (JSC):
        (JITCode):
        (DirectJITCode):

2013-04-03  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Include LLVM headers with surrounding #pragmas instead of using my #define
        https://bugs.webkit.org/show_bug.cgi?id=113921

        Reviewed by Oliver Hunt.
        
        The LLVM community wants us to continue including all of LLVM's C++ headers. Change
        to using #pragma's to disable warnings that they cannot handle.

        * ftl/FTLLLVMHeaders.h:

2013-04-03  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Everyone should know about the FTL
        https://bugs.webkit.org/show_bug.cgi?id=113897

        Reviewed by Mark Hahnenberg.
        
        In order to get OSR exit to work right, we need the distinction between DFG and
        FTL to be clear even after compilation finishes, since they will have subtly
        different OSR stories and likely use different data structures.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resetStubInternal):
        (JSC::ProgramCodeBlock::compileOptimized):
        (JSC::EvalCodeBlock::compileOptimized):
        (JSC::FunctionCodeBlock::compileOptimized):
        (JSC::CodeBlock::adjustedExitCountThreshold):
        (JSC::CodeBlock::tallyFrequentExitSites):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::hasOptimizedReplacement):
        (JSC::ExecState::isInlineCallFrame):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::JITCode):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::dumpState):
        * heap/DFGCodeBlocks.cpp:
        (JSC::DFGCodeBlocks::jettison):
        * interpreter/Interpreter.cpp:
        (JSC::getLineNumberForCallFrame):
        (JSC::getCallerInfo):
        * jit/JITCode.cpp:
        (WTF::printInternal):
        * jit/JITCode.h:
        (JSC::JITCode::topTierJIT):
        (JSC::JITCode::nextTierJIT):
        (JITCode):
        (JSC::JITCode::isJIT):
        (JSC::JITCode::isLowerTier):
        (JSC::JITCode::isHigherTier):
        (JSC::JITCode::isLowerOrSameTier):
        (JSC::JITCode::isHigherOrSameTier):
        (JSC::JITCode::isOptimizingJIT):
        * jit/JITDriver.h:
        (JSC::jitCompileIfAppropriate):
        (JSC::jitCompileFunctionIfAppropriate):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileOptimized):
        (JSC::samplingDescription):
        (JSC::ProgramExecutable::compileOptimized):
        (JSC::FunctionExecutable::compileOptimizedForCall):
        (JSC::FunctionExecutable::compileOptimizedForConstruct):

2013-04-03  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should abstract out how it does forward exits, and that code should be simplified
        https://bugs.webkit.org/show_bug.cgi?id=113894

        Reviewed by Mark Hahnenberg.
        
        1) We previously had two different ways of convertingToForward, one path for
           where we had a ValueRecovery for the current node and one where we didn't.
           But the paths were doing exactly the same thing except that if you have a
           ValueRecovery, you also find the last applicable mov hint and do some
           extra things. This patch combines the two paths and bases both of them on
           the previous no-ValueRecovery path, which was simpler to begin with.
        
        2) This moves the logic into DFG::OSRExit, which further simplifies the code
           and makes the logic available to the FTL.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::convertToForward):
        (DFG):
        * dfg/DFGOSRExit.h:
        (DFG):
        (OSRExit):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):

2013-04-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should have the equivalent of a ValueRecovery
        https://bugs.webkit.org/show_bug.cgi?id=113819

        Reviewed by Mark Hahnenberg.
        
        This adds a way of saying that we have a value, we don't want to say what
        node the value came from, but we know specifics of how the value is
        formatted. This is the LLVM equivalent of DFG's ValueRecovery.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLFormattedValue.h: Added.
        (FTL):
        (FormattedValue):
        (JSC::FTL::FormattedValue::FormattedValue):
        (JSC::FTL::FormattedValue::operator!):
        (JSC::FTL::FormattedValue::format):
        (JSC::FTL::FormattedValue::value):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
        (JSC::FTL::LowerDFGToLLVM::speculateForward):
        (JSC::FTL::LowerDFGToLLVM::weakPointer):

2013-04-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should use the right abstract heap for Int32 array accesses
        https://bugs.webkit.org/show_bug.cgi?id=113759

        Reviewed by Mark Hahnenberg.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):

2013-04-02  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support fast property stores
        https://bugs.webkit.org/show_bug.cgi?id=113757

        Reviewed by Oliver Hunt.
        
        Simplified the task of handling property transitions and reduced amount of code
        duplication between the JITs.
        
        Added PutByOffset, PutStructure, PhantomPutStructure, WeakJSConstant, and a
        stub form of StructureTransitionWatchpoint to the FTL.
        
        Also simplified the creation of pointer constants, and fixed a bug in
        speculateObject().

        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::notifyCompilingStructureTransition):
        (Graph):
        * dfg/DFGJITCompiler.h:
        (JITCompiler):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileWeakJSConstant):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint):
        (JSC::FTL::LowerDFGToLLVM::compilePutStructure):
        (JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure):
        (JSC::FTL::LowerDFGToLLVM::compilePutByOffset):
        (JSC::FTL::LowerDFGToLLVM::speculateObject):
        (JSC::FTL::LowerDFGToLLVM::weakPointer):
        * ftl/FTLOutput.h:
        (Output):
        (JSC::FTL::Output::constIntPtr):
        (JSC::FTL::Output::absolute):

2013-04-01  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support some more integer arithmetic ops (negate, xor, urshift)
        https://bugs.webkit.org/show_bug.cgi?id=113740

        Reviewed by Geoffrey Garen.

        * ftl/FTLAbbreviations.h:
        (JSC::FTL::buildNeg):
        (JSC::FTL::buildLShr):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compileBitXor):
        (JSC::FTL::LowerDFGToLLVM::compileBitURShift):
        (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::neg):
        (JSC::FTL::Output::lShr):

2013-04-01  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support GetGlobalVar/PutGlobalVar
        https://bugs.webkit.org/show_bug.cgi?id=113728

        Reviewed by Gavin Barraclough.
        
        Removed the macro magic for the globals absolute abstract heap, since for anything
        with absolute addresses we can just share a common absolute abstract heap. It
        would only be a problem if we for example were emitting an access to a global but
        not using an absolute address, and then wanted to say that this access was
        constrained to global variables. I don't believe we do that, and I don't believe we
        ever will.
        
        Then added Output::absolute(), a convenient way of building a typed pointer for an
        absolute address.
        
        Then added GetGlobalVar/PutGlobalVar.

        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        * ftl/FTLAbstractHeapRepository.h:
        (FTL):
        (AbstractHeapRepository):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileGetGlobalVar):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::absolute):
        (Output):

2013-03-31  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL should support ArithSub
        https://bugs.webkit.org/show_bug.cgi?id=113675

        Reviewed by Oliver Hunt.
        
        This does the obvious bit of implementing ArithSub, but it also takes this
        as an opportunity to clean up how intrinsics and common values (common types
        and constants) are handled. Previously they were all lumped together in
        FTL::Output. Now, in an effort to split up the files and make FTL::Output
        less big, I created a thing called FTL::CommonValues which just tracks the
        common values, and a thing called FTL::IntrinsicRepository which just tracks
        intrinsics. These and FTL::Output are all related to each other in a linear
        hierarchy. Moreover, IntrinsicRepository uses macro-fu to make it easy to
        declare new intrinsics in the future.
        
        I also out-of-lined some things and made .cpp files for each of these classes.
        Initialize I wasn't going to do this but then I realized that FTL::Output is
        already included in multiple places. Probably it's better if some of its guts
        are not inline, and it's also good to now have .cpp "landing pads" if we ever
        want to add more things to that class.
        
        Note that a lot of how these things are designed has to do with the fact
        that pretty soon here I'll have to switch us from using the LLVM global
        context to using a context that we create. When that happens, anyone who
        creates anything will have to know the context; that's why FTL::CommonValues
        already knows the module but doesn't use it - in the future it will have to
        do things with it.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::buildSub):
        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCommonValues.cpp: Added.
        (FTL):
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h: Added.
        (FTL):
        (CommonValues):
        (JSC::FTL::CommonValues::initialize):
        * ftl/FTLIntrinsicRepository.cpp: Added.
        (FTL):
        (JSC::FTL::IntrinsicRepository::IntrinsicRepository):
        * ftl/FTLIntrinsicRepository.h: Added.
        (FTL):
        (IntrinsicRepository):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileArithSub):
        (LowerDFGToLLVM):
        * ftl/FTLOutput.cpp: Added.
        (FTL):
        (JSC::FTL::Output::Output):
        (JSC::FTL::Output::~Output):
        * ftl/FTLOutput.h:
        (Output):
        (JSC::FTL::Output::initialize):
        (JSC::FTL::Output::sub):
        (JSC::FTL::Output::addWithOverflow32):
        (JSC::FTL::Output::subWithOverflow32):
        (JSC::FTL::Output::mulWithOverflow32):

2013-03-31  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL doesn't need virtual register allocation
        https://bugs.webkit.org/show_bug.cgi?id=113679

        Reviewed by Mark Hahnenberg.

        * dfg/DFGDriver.cpp:
        (JSC::DFG::dumpAndVerifyGraph):
        (DFG):
        (JSC::DFG::compile):

2013-03-31  Filip Pizlo  <fpizlo@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=113656
        Fix Sam's nits.

        Unreviewed.

        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::IndexedAbstractHeap::initialize):
        * ftl/FTLAbstractHeap.h:
        (IndexedAbstractHeap):
        (AbsoluteAbstractHeap):
        * ftl/FTLAbstractHeapRepository.h:
        (AbstractHeapRepository):

2013-03-31  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL JIT should support GetByVal on Int32 arrays
        https://bugs.webkit.org/show_bug.cgi?id=113668

        Reviewed by Sam Weinig.
        
        It actually already supported this, but needed to be told that it did.
        
        Also adds an option to enable LICM (loop-invariant code motion, i.e.
        http://llvm.org/docs/Passes.html#licm-loop-invariant-code-motion). LICM
        isn't doing me any good right now, but I guess I'll have to play with
        it more. And this adds the ability to tweak the LLVM optimization level
        from the command-line.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        * runtime/Options.h:
        (JSC):

2013-03-31  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL JIT should supply TBAA meta-data to LLVM
        https://bugs.webkit.org/show_bug.cgi?id=113656

        Reviewed by Oliver Hunt.
        
        This adds support for performing strong typing on the LLVM IR that the FTL
        generates, by using TBAA meta-data. This will permit LLVM to do aggressive
        GVN, load elimination, and LICM optimization even if it sees pointer store
        side-effects. The goal is to precisely model all loads and stores we emit,
        except for the super crazy ones (GetById that can go all-out polymorphic,
        or for example a Call where we know nothing).
        
        This is accomplished by introducing the notion of an AbstractHeap
        typesystem. An AbstractHeap is a subset of all possible memory locations
        that we might store to. For example, JSCell::m_structure and
        JSObject::m_butterfly are two disjoint AbstractHeaps because we know that
        a store to one cannot clobber the other. AbstractHeaps follow a
        single-inheritance hierarchy. There is the root heap, which corresponds to
        any possible memory location accessible to the JS engine, and then there
        are heaps for all internal object fields, a heap for each global object,
        and so on.
        
        There are three other tidbits here that make this somewhat more interesting.
        We have a notion of an AbstractHeap-with-offset, called AbstractField.
        JSCell::m_structure is actually an AbstractField. This allows us to say
        things like m_out.loadPtr(base, m_heaps.JSCell_structure); this both
        gives you the offset of JSCell::m_structure and ascribes TBAA meta-data for
        the JSCell::m_structure heap to the generated load instrction.
        
        Another fun tidbit is the notion of Indexed, Numbered, and Absolute abstract
        heaps. An indexed abstract heap corresponds to a set of locations that you
        might access by index from some base. Virtual registers are a great example.
        Though I call them just "variables" in the FTL. When we access a virtual
        register, we know that we aren't interfering with accesses to
        Structure-managed named properties, or with JSCell::m_structure, or with
        other such disjoint heaps. But we also know that if we access a variable at
        offset X and then another variable at offset Y and we know that X and Y are
        unequal, then these two accesses are on disjoint subheaps of the variables
        heap. This works out naturally for interference between, say, scoped variable
        access and local variable access: if you access scoped variable r5 and then
        access a local variable r5, these might interfere - and they will get the
        same abstract subheap of the variables heap. IndexedAbstractHeaps
        conveniently remember the size of the elements and will give you an
        AbstractField (i.e. heap-with-offset) if you give it an index. This is great
        for conveniently writing code that accesses contiguous arrays of well-typed
        things. This allows you to literally do things like
        m_out.load64(callFrameRegister, m_heaps.variables[operand]) and the right
        thing will happen. You can also get the heap variables.atAnyIndex(), if
        you're doing an access with an unknown index.
        
        Numbered and Absolute abstract heaps are related except that they don't
        assume that the value used to get the abstract subheap corresponds to any
        meaningful offset from any base. Numbered heaps, like the properties heap
        (for named properties tracked by Structure), are "numbered" (not indexed)
        by the propertyNumber. So you can emit a GetByOffset by separately
        computing the offset and the propertyNumber (both values are stored in the
        StorageAccessData), and passing the offset directly to Output::address()
        and passing m_heaps.properties[propertyNumber] as the field. Absolute heaps
        are similar, but are keyed on absolute address. This is appropriate for
        global variables, and possibly other things.
        
        Finally, FTL::Output understands the notion of a pointer-with-TBAA-data,
        and calls it a TypedPointer. TypedPointer is a tuple of a LLVMValueRef
        referencing an intptr value and a pointer to an AbstractHeap. All load()
        and store() operations now take a TypedPointer, and will perform the access
        by casting the intptr to a pointer of the right type and then ascribing the
        TBAA meta-data from the AbstractHeap.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLAbbreviations.h:
        (JSC::FTL::mdKindID):
        (JSC::FTL::mdString):
        (JSC::FTL::mdNode):
        (FTL):
        (JSC::FTL::setMetadata):
        * ftl/FTLAbstractHeap.cpp: Added.
        (FTL):
        (JSC::FTL::AbstractHeap::tbaaMetadataSlow):
        (JSC::FTL::AbstractHeap::decorateInstruction):
        (JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap):
        (JSC::FTL::IndexedAbstractHeap::~IndexedAbstractHeap):
        (JSC::FTL::IndexedAbstractHeap::baseIndex):
        (JSC::FTL::IndexedAbstractHeap::atSlow):
        (JSC::FTL::IndexedAbstractHeap::initialize):
        (JSC::FTL::NumberedAbstractHeap::NumberedAbstractHeap):
        (JSC::FTL::NumberedAbstractHeap::~NumberedAbstractHeap):
        (JSC::FTL::AbsoluteAbstractHeap::AbsoluteAbstractHeap):
        (JSC::FTL::AbsoluteAbstractHeap::~AbsoluteAbstractHeap):
        * ftl/FTLAbstractHeap.h: Added.
        (FTL):
        (AbstractHeap):
        (JSC::FTL::AbstractHeap::AbstractHeap):
        (JSC::FTL::AbstractHeap::isInitialized):
        (JSC::FTL::AbstractHeap::initialize):
        (JSC::FTL::AbstractHeap::parent):
        (JSC::FTL::AbstractHeap::heapName):
        (JSC::FTL::AbstractHeap::tbaaMetadata):
        (AbstractField):
        (JSC::FTL::AbstractField::AbstractField):
        (JSC::FTL::AbstractField::initialize):
        (JSC::FTL::AbstractField::offset):
        (IndexedAbstractHeap):
        (JSC::FTL::IndexedAbstractHeap::atAnyIndex):
        (JSC::FTL::IndexedAbstractHeap::at):
        (JSC::FTL::IndexedAbstractHeap::operator[]):
        (JSC::FTL::IndexedAbstractHeap::returnInitialized):
        (JSC::FTL::IndexedAbstractHeap::MyHashTraits::constructDeletedValue):
        (JSC::FTL::IndexedAbstractHeap::MyHashTraits::isDeletedValue):
        (NumberedAbstractHeap):
        (JSC::FTL::NumberedAbstractHeap::atAnyNumber):
        (JSC::FTL::NumberedAbstractHeap::at):
        (JSC::FTL::NumberedAbstractHeap::operator[]):
        (AbsoluteAbstractHeap):
        (JSC::FTL::AbsoluteAbstractHeap::atAnyAddress):
        (JSC::FTL::AbsoluteAbstractHeap::at):
        (JSC::FTL::AbsoluteAbstractHeap::operator[]):
        * ftl/FTLAbstractHeapRepository.cpp: Added.
        (FTL):
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        (JSC::FTL::AbstractHeapRepository::~AbstractHeapRepository):
        * ftl/FTLAbstractHeapRepository.h: Added.
        (FTL):
        (AbstractHeapRepository):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
        (JSC::FTL::LowerDFGToLLVM::compileGetButterfly):
        (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
        (JSC::FTL::LowerDFGToLLVM::speculateObject):
        (JSC::FTL::LowerDFGToLLVM::addressFor):
        (JSC::FTL::LowerDFGToLLVM::payloadFor):
        (JSC::FTL::LowerDFGToLLVM::tagFor):
        (LowerDFGToLLVM):
        * ftl/FTLOutput.h:
        (FTL):
        (JSC::FTL::Output::Output):
        (JSC::FTL::Output::initialize):
        (JSC::FTL::Output::set):
        (JSC::FTL::Output::load):
        (JSC::FTL::Output::store):
        (Output):
        (JSC::FTL::Output::load32):
        (JSC::FTL::Output::load64):
        (JSC::FTL::Output::loadPtr):
        (JSC::FTL::Output::store32):
        (JSC::FTL::Output::store64):
        (JSC::FTL::Output::storePtr):
        (JSC::FTL::Output::addPtr):
        (JSC::FTL::Output::address):
        (JSC::FTL::Output::baseIndex):
        * ftl/FTLTypedPointer.h: Added.
        (FTL):
        (TypedPointer):
        (JSC::FTL::TypedPointer::TypedPointer):
        (JSC::FTL::TypedPointer::operator!):
        (JSC::FTL::TypedPointer::heap):
        (JSC::FTL::TypedPointer::value):
        * runtime/Options.h:
        (JSC):

2013-03-30  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL JIT should be able to compile the Array.prototype.findGraphNode function in Kraken/ai-astar
        https://bugs.webkit.org/show_bug.cgi?id=113646

        Reviewed by Oliver Hunt.
        
        This adds enough FTL support to compile Array.prototype.findGraphNode. This isn't
        a speed-up, yet, because findGraphNode tends to be aggressively inlined by the DFG,
        and the FTL can't yet compile the things into which it was inlined. In future
        patches we will get to a point where we can compile the callers, and then we'll be
        able to see what the performance effects are.
        
        But the interesting thing is that it isn't a slow-down, either. This implies that
        even if we FTL compile a CodeBlock that we shouldn't have (the fact that we
        compiling things that end up being inlined is dumb, and the fact that the current
        FTL tiering strategy launches LLVM for those things is even dumber), we still run
        at OK performance.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compileGetButterfly):
        (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
        (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
        (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
        (JSC::FTL::LowerDFGToLLVM::lowInt32):
        (JSC::FTL::LowerDFGToLLVM::lowCell):
        (JSC::FTL::LowerDFGToLLVM::lowObject):
        (JSC::FTL::LowerDFGToLLVM::lowBoolean):
        (JSC::FTL::LowerDFGToLLVM::lowJSValue):
        (JSC::FTL::LowerDFGToLLVM::lowStorage):
        (JSC::FTL::LowerDFGToLLVM::isNotInt32):
        (JSC::FTL::LowerDFGToLLVM::isNotCell):
        (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::speculateCell):
        (JSC::FTL::LowerDFGToLLVM::speculateObject):
        (JSC::FTL::LowerDFGToLLVM::accountedPointer):
        (JSC::FTL::LowerDFGToLLVM::weakPointer):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::Output):
        (JSC::FTL::Output::insertNewBlocksBefore):
        (JSC::FTL::Output::appendTo):
        (Output):
        (JSC::FTL::Output::baseIndex):

2013-03-29  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL JIT should be able to compile the Marsaglia random number generator
        https://bugs.webkit.org/show_bug.cgi?id=113635

        Reviewed by Oliver Hunt.
        
        Just adding missing functionality.
        
        Also "fixed" OSR exit to use a call to abort() in addition to using Unreachable
        since the latter doesn't actually mean trap - quite the opposite, it tells LLVM
        that the code can never be reached.
        
        The Marsaglia function runs ~60% faster with FTL, than DFG. Not a terrible start.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLAbbreviations.h:
        (FTL):
        (JSC::FTL::voidType):
        (JSC::FTL::structType):
        (JSC::FTL::functionType):
        (JSC::FTL::addFunction):
        (JSC::FTL::setLinkage):
        (JSC::FTL::setFunctionCallingConv):
        (JSC::FTL::addExternFunction):
        (JSC::FTL::constIntToPtr):
        (JSC::FTL::constBitCast):
        (JSC::FTL::buildMul):
        (JSC::FTL::buildOr):
        (JSC::FTL::buildShl):
        (JSC::FTL::buildAShr):
        (JSC::FTL::buildCall):
        (JSC::FTL::buildExtractValue):
        (JSC::FTL::dumpModule):
        (JSC::FTL::verifyModule):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::compileBlock):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileAdd):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::LowerDFGToLLVM::compileBitAnd):
        (JSC::FTL::LowerDFGToLLVM::compileBitOr):
        (JSC::FTL::LowerDFGToLLVM::compileBitRShift):
        (JSC::FTL::LowerDFGToLLVM::compileBitLShift):
        (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
        (JSC::FTL::LowerDFGToLLVM::compileBranch):
        (JSC::FTL::LowerDFGToLLVM::speculateBackward):
        (JSC::FTL::LowerDFGToLLVM::lowBoolean):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::Output):
        (JSC::FTL::Output::initialize):
        (JSC::FTL::Output::appendTo):
        (Output):
        (JSC::FTL::Output::mul):
        (JSC::FTL::Output::bitOr):
        (JSC::FTL::Output::shl):
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::addWithOverflow32):
        (JSC::FTL::Output::mulWithOverflow32):
        (JSC::FTL::Output::extractValue):
        (JSC::FTL::Output::call):
        (JSC::FTL::Output::addWithOverflow32Function):
        (JSC::FTL::Output::mulWithOverflow32Function):
        * ftl/FTLState.cpp: Added.
        (FTL):
        (JSC::FTL::State::dumpState):
        * ftl/FTLState.h:
        (State):

2013-03-29  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, release mode build fix.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::LowerDFGToLLVM::lowInt32):
        (JSC::FTL::LowerDFGToLLVM::lowCell):
        (JSC::FTL::LowerDFGToLLVM::lowBoolean):
        (JSC::FTL::LowerDFGToLLVM::lowJSValue):

2013-03-29  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Change DO_NOT_INCLUDE_LLVM_CPP_HEADERS to LLVM_DO_NOT_INCLUDE_CPP_HEADERS
        https://bugs.webkit.org/show_bug.cgi?id=113634

        Reviewed by Dan Bernstein.

        * ftl/FTLLLVMHeaders.h:

2013-03-29  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL JIT should be able run some simple function
        https://bugs.webkit.org/show_bug.cgi?id=113481

        Reviewed by Geoffrey Garen.
        
        I forgot to make a couple of the requested review changes, so I'm making
        them now!

        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLJITCode.h:

2013-03-29  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: FTL JIT should be able run some simple function
        https://bugs.webkit.org/show_bug.cgi?id=113481

        Reviewed by Geoffrey Garen.
        
        This is the initial version of the FTL JIT (Fourth Tier LLVM JIT).
        It includes a lowering from the DFG IR to LLVM IR (FTL::lowerDFGToLLVM)
        and a "backend" step that invokes the LLVM and wraps the resulting
        function in a thunk (FTL::compile).
        
        All LLVM IR building functions are wrapped up into a nicer FTL API.
        First they're wrapped in an abbreviated API (FTLAbbreviations.h) and
        then again into an object-oriented IR builder (FTLOutput.h).
        
        This runs things. I don't know how fast it runs things. And I don't
        make any claims of stability. The FTL is runtime-disabled by default;
        you will enable it by doing --useExperimentalFTL=true. Probably if you
        do this, you will run slower, because of the heavy thunking we do, the
        fact that we don't have anything resembling a sensible tiering story,
        and because we only compile ridiculously tiny functions.
            
        Finally, this still requires a custom set of LLVM headers to build.
        I am working on getting that up-streamed to LLVM, and separately I'll
        make sure that we have a build checked into this branch.

        * Configurations/JavaScriptCore.xcconfig:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/Operands.h:
        (Operands):
        (JSC::Operands::Operands):
        * dfg/DFGAbstractState.h:
        (JSC::DFG::AbstractState::needsTypeCheck):
        (AbstractState):
        (JSC::DFG::AbstractState::filterEdgeByUse):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::needsTypeCheck):
        (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand):
        (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
        (DFG):
        * dfg/DFGUseKind.h:
        (JSC::DFG::shouldNotHaveTypeCheck):
        (DFG):
        (JSC::DFG::mayHaveTypeCheck):
        (JSC::DFG::isDouble):
        (JSC::DFG::isCell):
        * ftl: Added.
        * ftl/FTLAbbreviations.h: Added.
        (FTL):
        (JSC::FTL::int1Type):
        (JSC::FTL::int32Type):
        (JSC::FTL::int64Type):
        (JSC::FTL::intPtrType):
        (JSC::FTL::pointerType):
        (JSC::FTL::getParam):
        (JSC::FTL::constInt):
        (JSC::FTL::appendBasicBlock):
        (JSC::FTL::insertBasicBlock):
        (JSC::FTL::buildAlloca):
        (JSC::FTL::buildAdd):
        (JSC::FTL::buildAnd):
        (JSC::FTL::buildXor):
        (JSC::FTL::buildLoad):
        (JSC::FTL::buildStore):
        (JSC::FTL::buildZExt):
        (JSC::FTL::buildIntCast):
        (JSC::FTL::buildIntToPtr):
        (JSC::FTL::buildPtrToInt):
        (JSC::FTL::buildICmp):
        (JSC::FTL::buildSelect):
        (JSC::FTL::buildBr):
        (JSC::FTL::buildCondBr):
        (JSC::FTL::buildRet):
        (JSC::FTL::buildUnreachable):
        * ftl/FTLCapabilities.cpp: Added.
        (FTL):
        (JSC::FTL::canCompile):
        * ftl/FTLCapabilities.h: Added.
        (FTL):
        * ftl/FTLCompile.cpp: Added.
        (FTL):
        (JSC::FTL::compileEntry):
        (JSC::FTL::compile):
        * ftl/FTLCompile.h: Added.
        (FTL):
        * ftl/FTLJITCode.cpp: Added.
        (FTL):
        (JSC::FTL::JITCode::JITCode):
        (JSC::FTL::JITCode::~JITCode):
        (JSC::FTL::JITCode::addressForCall):
        (JSC::FTL::JITCode::executableAddressAtOffset):
        (JSC::FTL::JITCode::dataAddressAtOffset):
        (JSC::FTL::JITCode::offsetOf):
        (JSC::FTL::JITCode::size):
        (JSC::FTL::JITCode::contains):
        * ftl/FTLJITCode.h: Added.
        (FTL):
        (JITCode):
        * ftl/FTLLLVMHeaders.h: Added.
        * ftl/FTLLowerDFGToLLVM.cpp: Added.
        (FTL):
        (LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::LowerDFGToLLVM::lower):
        (JSC::FTL::LowerDFGToLLVM::addFlushedLocalOpRoots):
        (JSC::FTL::LowerDFGToLLVM::closeOverFlushedLocalOps):
        (JSC::FTL::LowerDFGToLLVM::addFlushedLocalOp):
        (JSC::FTL::LowerDFGToLLVM::addFlushedLocalEdge):
        (JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments):
        (JSC::FTL::LowerDFGToLLVM::compileBlock):
        (JSC::FTL::LowerDFGToLLVM::compileNode):
        (JSC::FTL::LowerDFGToLLVM::compileJSConstant):
        (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
        (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
        (JSC::FTL::LowerDFGToLLVM::compileMovHintAndCheck):
        (JSC::FTL::LowerDFGToLLVM::compilePhantom):
        (JSC::FTL::LowerDFGToLLVM::compileReturn):
        (JSC::FTL::LowerDFGToLLVM::speculateBackward):
        (JSC::FTL::LowerDFGToLLVM::speculateForward):
        (JSC::FTL::LowerDFGToLLVM::speculate):
        (JSC::FTL::LowerDFGToLLVM::terminate):
        (JSC::FTL::LowerDFGToLLVM::backwardTypeCheck):
        (JSC::FTL::LowerDFGToLLVM::forwardTypeCheck):
        (JSC::FTL::LowerDFGToLLVM::typeCheck):
        (JSC::FTL::LowerDFGToLLVM::lowInt32):
        (JSC::FTL::LowerDFGToLLVM::lowCell):
        (JSC::FTL::LowerDFGToLLVM::lowBoolean):
        (JSC::FTL::LowerDFGToLLVM::lowJSValue):
        (JSC::FTL::LowerDFGToLLVM::checkNotInt32):
        (JSC::FTL::LowerDFGToLLVM::unboxInt32):
        (JSC::FTL::LowerDFGToLLVM::boxInt32):
        (JSC::FTL::LowerDFGToLLVM::checkNotCell):
        (JSC::FTL::LowerDFGToLLVM::checkNotBoolean):
        (JSC::FTL::LowerDFGToLLVM::unboxBoolean):
        (JSC::FTL::LowerDFGToLLVM::boxBoolean):
        (JSC::FTL::LowerDFGToLLVM::speculateInt32):
        (JSC::FTL::LowerDFGToLLVM::addressFor):
        (JSC::FTL::LowerDFGToLLVM::payloadFor):
        (JSC::FTL::LowerDFGToLLVM::tagFor):
        (JSC::FTL::LowerDFGToLLVM::globalData):
        (JSC::FTL::LowerDFGToLLVM::codeBlock):
        (JSC::FTL::lowerDFGToLLVM):
        * ftl/FTLLowerDFGToLLVM.h: Added.
        (FTL):
        * ftl/FTLOutput.h: Added.
        (FTL):
        (Output):
        (JSC::FTL::Output::Output):
        (JSC::FTL::Output::~Output):
        (JSC::FTL::Output::initialize):
        (JSC::FTL::Output::appendTo):
        (JSC::FTL::Output::newBlock):
        (JSC::FTL::Output::param):
        (JSC::FTL::Output::constBool):
        (JSC::FTL::Output::constInt32):
        (JSC::FTL::Output::constIntPtr):
        (JSC::FTL::Output::constInt64):
        (JSC::FTL::Output::add):
        (JSC::FTL::Output::bitAnd):
        (JSC::FTL::Output::bitXor):
        (JSC::FTL::Output::zeroExt):
        (JSC::FTL::Output::intCast):
        (JSC::FTL::Output::castToInt32):
        (JSC::FTL::Output::get):
        (JSC::FTL::Output::set):
        (JSC::FTL::Output::load):
        (JSC::FTL::Output::store):
        (JSC::FTL::Output::load32):
        (JSC::FTL::Output::load64):
        (JSC::FTL::Output::loadPtr):
        (JSC::FTL::Output::store32):
        (JSC::FTL::Output::store64):
        (JSC::FTL::Output::storePtr):
        (JSC::FTL::Output::equal):
        (JSC::FTL::Output::notEqual):
        (JSC::FTL::Output::above):
        (JSC::FTL::Output::aboveOrEqual):
        (JSC::FTL::Output::below):
        (JSC::FTL::Output::belowOrEqual):
        (JSC::FTL::Output::greaterThan):
        (JSC::FTL::Output::greaterThanOrEqual):
        (JSC::FTL::Output::lessThan):
        (JSC::FTL::Output::lessThanOrEqual):
        (JSC::FTL::Output::isZero64):
        (JSC::FTL::Output::notZero64):
        (JSC::FTL::Output::testNonZero64):
        (JSC::FTL::Output::select):
        (JSC::FTL::Output::jump):
        (JSC::FTL::Output::branch):
        (JSC::FTL::Output::ret):
        (JSC::FTL::Output::unreachable):
        * ftl/FTLState.h: Added.
        (FTL):
        (State):
        (JSC::FTL::State::State):
        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreadingOnce):
        * runtime/Options.h:
        (JSC):

2013-03-27  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: JITCode should abstract exactly how the JIT code is structured and where it was allocated
        https://bugs.webkit.org/show_bug.cgi?id=113437

        Reviewed by Mark Hahnenberg.
        
        JITCode is now a virtual base class, which will allow different JITs to have radically
        different memory allocation and management conventions in the future. It will also
        make it easier to store JIT-specific meta-data in CodeBlock just by putting it into
        an appropriate JITCode subclass.
        
        For now there is one subclass, DirectJITCode, which just behaves like JITCode used to
        behave.

        * assembler/RepatchBuffer.h:
        (JSC::RepatchBuffer::RepatchBuffer):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resetStubInternal):
        (JSC::CodeBlock::bytecodeOffset):
        (JSC::CodeBlock::codeOriginForReturn):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::getJITCode):
        (JSC::CodeBlock::getJITType):
        (CodeBlock):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        * dfg/DFGDriver.h:
        (DFG):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JITCompiler):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::codeLocationForRepatch):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        (JSC::JIT::compile):
        (JIT):
        * jit/JITCode.cpp:
        (JSC):
        (JSC::JITCode::JITCode):
        (JSC::JITCode::~JITCode):
        (JSC::JITCode::execute):
        (JSC::JITCode::hostFunction):
        (JSC::DirectJITCode::DirectJITCode):
        (JSC::DirectJITCode::~DirectJITCode):
        (JSC::DirectJITCode::addressForCall):
        (JSC::DirectJITCode::executableAddressAtOffset):
        (JSC::DirectJITCode::dataAddressAtOffset):
        (JSC::DirectJITCode::offsetOf):
        (JSC::DirectJITCode::size):
        (JSC::DirectJITCode::contains):
        * jit/JITCode.h:
        (JSC):
        (JITCode):
        (JSC::JITCode::bottomTierJIT):
        (JSC::JITCode::topTierJIT):
        (JSC::JITCode::nextTierJIT):
        (JSC::JITCode::isOptimizingJIT):
        (JSC::JITCode::isBaselineCode):
        (JSC::JITCode::jitType):
        (JSC::JITCode::jitTypeFor):
        (JSC::JITCode::executableAddress):
        (JSC::JITCode::start):
        (JSC::JITCode::end):
        (DirectJITCode):
        * jit/JITDriver.h:
        (JSC::jitCompileIfAppropriate):
        (JSC::jitCompileFunctionIfAppropriate):
        * jit/JITStubs.cpp:
        (JSC::lazyLinkFor):
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualForGenerator):
        * llint/LLIntEntrypoints.cpp:
        (JSC::LLInt::getFunctionEntrypoint):
        (JSC::LLInt::getEvalEntrypoint):
        (JSC::LLInt::getProgramEntrypoint):
        * llint/LLIntEntrypoints.h:
        (JSC):
        (LLInt):
        (JSC::LLInt::getEntrypoint):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileInternal):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::FunctionExecutable::compileForCallInternal):
        (JSC::FunctionExecutable::compileForConstructInternal):
        * runtime/Executable.h:
        (JSC::ExecutableBase::generatedJITCodeForCall):
        (JSC::ExecutableBase::generatedJITCodeForConstruct):
        (JSC::ExecutableBase::generatedJITCodeFor):
        (ExecutableBase):
        (JSC::ExecutableBase::hostCodeEntryFor):
        (JSC::ExecutableBase::jsCodeEntryFor):
        (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor):
        (JSC::NativeExecutable::create):
        (JSC::NativeExecutable::finishCreation):
        (JSC::EvalExecutable::generatedJITCode):
        (JSC::ProgramExecutable::generatedJITCode):
        * runtime/ExecutionHarness.h:
        (JSC::prepareForExecution):
        (JSC::prepareFunctionForExecution):

2013-07-16  Oliver Hunt  <oliver@apple.com>

        Merged dfgFourthTier r148570

    2013-04-16  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should be able to query Structure without modifying it
        https://bugs.webkit.org/show_bug.cgi?id=114708

        Reviewed by Oliver Hunt.
        
        This is work towards allowing the DFG, and FTL, to run on a separate thread.
        The idea is that the most evil thing that the DFG does that has thread-safety
        issues is fiddling with Structures by calling Structure::get(). This can lead
        to rematerialization of property tables, which is definitely not thread-safe
        due to how StringImpl works. So, this patch completely side-steps the problem
        by creating a new version of Structure::get, called
        Structure::getWithoutMaterializing, which may choose to do an O(n) search if
        necessary to avoid materialization. I believe this should be fine - the DFG
        does't call into these code path often enough for this to matter, and most of
        the time, the Structure that we call this on will already have a property
        table because some inline cache would have already called ::get() on that
        Structure.
        
        Also cleaned up the materialization logic: we can stop the search as soon as
        we find any Structure with a property table rather than searching all the way
        for a pinned one.

        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        * runtime/Structure.cpp:
        (JSC::Structure::findStructuresAndMapForMaterialization):
        (JSC::Structure::materializePropertyMap):
        (JSC::Structure::getWithoutMaterializing):
        (JSC):
        * runtime/Structure.h:
        (Structure):
        * runtime/StructureInlines.h:
        (JSC::Structure::getWithoutMaterializing):
        (JSC):

2013-07-15  Oliver Hunt  <oliver@apple.com>

        Merged dfgFourthTier r148047

    2013-04-09  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should provide utilities for common OSR exit tasks
        https://bugs.webkit.org/show_bug.cgi?id=114306

        Reviewed by Mark Hahnenberg.
        
        Just abstract out some things that the FTL will want to use as well.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler.h:
        (OSRExitCompiler):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp: Added.
        (DFG):
        (JSC::DFG::handleExitCounts):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGOSRExitCompilerCommon.h: Added.
        (DFG):

2013-07-15  Oliver Hunt  <oliver@apple.com>

        Merged dfgFourthTier r148037

    2013-04-09  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should better abstract floating point arguments
        https://bugs.webkit.org/show_bug.cgi?id=114300

        Reviewed by Mark Hahnenberg.

        * dfg/DFGFPRInfo.h:
        (FPRInfo):
        (JSC::DFG::FPRInfo::toArgumentRegister):

2013-07-15  Oliver Hunt  <oliver@apple.com>

        Merged dfgFourthTier r147821

    2013-04-05  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should better abstract arguments
        https://bugs.webkit.org/show_bug.cgi?id=114073

        Reviewed by Mark Hahnenberg.

        * dfg/DFGGPRInfo.h:
        (GPRInfo):
        (JSC::DFG::GPRInfo::toArgumentRegister):

2013-07-15  Oliver Hunt  <oliver@apple.com>

        Merged dfgFourthTier r147609

    2013-04-03  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: put DFG data into a DFG::JITCode, and put common DFG and FTL data into something accessible from both DFG::JITCode and FTL::JITCode
        https://bugs.webkit.org/show_bug.cgi?id=113905

        Reviewed by Geoffrey Garen.
        
        This removes one pointer from CodeBlock.
        
        It also gives us a framework for having JITType-specific data in CodeBlock, by
        putting it into the appropriate JITCode class (either DFG::JITCode or
        FTL::JITCode). And it allows us to have DFG and FTL share some common data,
        via DFG::CommonData, which is stored in both DFG::JITCode and FTL::JITCode and
        always accessible via JITCode::dfgCommon().

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/CodeBlock.cpp:
        (JSC):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::visitAggregate):
        (JSC::CodeBlock::performTracingFixpointIteration):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::stronglyVisitWeakReferences):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::tallyFrequentExitSites):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
        (JSC::DFGCodeBlocks::mark):
        * dfg/DFGAssemblyHelpers.h:
        * dfg/DFGCommonData.cpp: Added.
        (DFG):
        (JSC::DFG::CommonData::notifyCompilingStructureTransition):
        (JSC::DFG::CommonData::shrinkToFit):
        * dfg/DFGCommonData.h: Added.
        (JSC):
        (DFG):
        (JSC::DFG::WeakReferenceTransition::WeakReferenceTransition):
        (WeakReferenceTransition):
        (CommonData):
        (JSC::DFG::CommonData::CommonData):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        * dfg/DFGDriver.h:
        (DFG):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        * dfg/DFGGraph.h:
        (Graph):
        * dfg/DFGJITCode.cpp: Added.
        (DFG):
        (JSC::DFG::JITCode::JITCode):
        (JSC::DFG::JITCode::~JITCode):
        (JSC::DFG::JITCode::dfgCommon):
        (JSC::DFG::JITCode::dfg):
        (JSC::DFG::JITCode::shrinkToFit):
        * dfg/DFGJITCode.h: Added.
        (DFG):
        (JITCode):
        (JSC::DFG::JITCode::appendOSREntryData):
        (JSC::DFG::JITCode::osrEntryDataForBytecodeIndex):
        (JSC::DFG::JITCode::appendOSRExit):
        (JSC::DFG::JITCode::lastOSRExit):
        (JSC::DFG::JITCode::appendSpeculationRecovery):
        (JSC::DFG::JITCode::appendWatchpoint):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JITCompiler):
        (JSC::DFG::JITCompiler::addWeakReference):
        (JSC::DFG::JITCompiler::noticeOSREntry):
        (JSC::DFG::JITCompiler::jitCode):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::backwardSpeculationCheck):
        (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGVariableEventStream.cpp:
        * heap/DFGCodeBlocks.cpp:
        (JSC::DFGCodeBlocks::~DFGCodeBlocks):
        (JSC::DFGCodeBlocks::jettison):
        (JSC::DFGCodeBlocks::clearMarks):
        (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
        (JSC::DFGCodeBlocks::traceMarkedCodeBlocks):
        * jit/JITCode.cpp:
        (JSC::JITCode::dfgCommon):
        (JSC):
        (JSC::JITCode::dfg):
        (JSC::JITCode::ftl):
        (JSC::DirectJITCode::DirectJITCode):
        (JSC::DirectJITCode::initializeCodeRef):
        (JSC::DirectJITCode::addressForCall):
        (JSC::DirectJITCode::executableAddressAtOffset):
        (JSC::DirectJITCode::dataAddressAtOffset):
        (JSC::DirectJITCode::offsetOf):
        (JSC::DirectJITCode::size):
        (JSC::DirectJITCode::contains):
        * jit/JITCode.h:
        (DFG):
        (FTL):
        (JSC):
        (JITCode):
        (DirectJITCode):

2013-07-15  Oliver Hunt  <oliver@apple.com>

        Merge dfgFourthTier r147587

    2013-04-03  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: Everyone should know about the FTL
        https://bugs.webkit.org/show_bug.cgi?id=113897

        Reviewed by Mark Hahnenberg.
        
        In order to get OSR exit to work right, we need the distinction between DFG and
        FTL to be clear even after compilation finishes, since they will have subtly
        different OSR stories and likely use different data structures.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resetStubInternal):
        (JSC::ProgramCodeBlock::compileOptimized):
        (JSC::EvalCodeBlock::compileOptimized):
        (JSC::FunctionCodeBlock::compileOptimized):
        (JSC::CodeBlock::adjustedExitCountThreshold):
        (JSC::CodeBlock::tallyFrequentExitSites):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::hasOptimizedReplacement):
        (JSC::ExecState::isInlineCallFrame):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::JITCode):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::dumpState):
        * heap/DFGCodeBlocks.cpp:
        (JSC::DFGCodeBlocks::jettison):
        * interpreter/Interpreter.cpp:
        (JSC::getLineNumberForCallFrame):
        (JSC::getCallerInfo):
        * jit/JITCode.cpp:
        (WTF::printInternal):
        * jit/JITCode.h:
        (JSC::JITCode::topTierJIT):
        (JSC::JITCode::nextTierJIT):
        (JITCode):
        (JSC::JITCode::isJIT):
        (JSC::JITCode::isLowerTier):
        (JSC::JITCode::isHigherTier):
        (JSC::JITCode::isLowerOrSameTier):
        (JSC::JITCode::isHigherOrSameTier):
        (JSC::JITCode::isOptimizingJIT):
        * jit/JITDriver.h:
        (JSC::jitCompileIfAppropriate):
        (JSC::jitCompileFunctionIfAppropriate):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileOptimized):
        (JSC::samplingDescription):
        (JSC::ProgramExecutable::compileOptimized):
        (JSC::FunctionExecutable::compileOptimizedForCall):
        (JSC::FunctionExecutable::compileOptimizedForConstruct):

2013-04-03  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: DFG should abstract out how it does forward exits, and that code should be simplified
        https://bugs.webkit.org/show_bug.cgi?id=113894

        Reviewed by Mark Hahnenberg.
        
        1) We previously had two different ways of convertingToForward, one path for
           where we had a ValueRecovery for the current node and one where we didn't.
           But the paths were doing exactly the same thing except that if you have a
           ValueRecovery, you also find the last applicable mov hint and do some
           extra things. This patch combines the two paths and bases both of them on
           the previous no-ValueRecovery path, which was simpler to begin with.
        
        2) This moves the logic into DFG::OSRExit, which further simplifies the code
           and makes the logic available to the FTL.

        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::convertToForward):
        (DFG):
        * dfg/DFGOSRExit.h:
        (DFG):
        (OSRExit):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):

2013-07-15  Oliver Hunt  <oliver@apple.com>

        Merge dfgFourthTier r147582

2013-07-15  Oliver Hunt  <oliver@apple.com>

        Merge dfgFourthTier r147014

    2013-03-27  Filip Pizlo  <fpizlo@apple.com>

        fourthTier: JITCode should abstract exactly how the JIT code is structured and where it was allocated
        https://bugs.webkit.org/show_bug.cgi?id=113437

        Reviewed by Mark Hahnenberg.
        
        JITCode is now a virtual base class, which will allow different JITs to have radically
        different memory allocation and management conventions in the future. It will also
        make it easier to store JIT-specific meta-data in CodeBlock just by putting it into
        an appropriate JITCode subclass.
        
        For now there is one subclass, DirectJITCode, which just behaves like JITCode used to
        behave.

        * assembler/RepatchBuffer.h:
        (JSC::RepatchBuffer::RepatchBuffer):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::resetStubInternal):
        (JSC::CodeBlock::bytecodeOffset):
        (JSC::CodeBlock::codeOriginForReturn):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::getJITCode):
        (JSC::CodeBlock::getJITType):
        (CodeBlock):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        * dfg/DFGDriver.h:
        (DFG):
        (JSC::DFG::tryCompile):
        (JSC::DFG::tryCompileFunction):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        (JITCompiler):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::codeLocationForRepatch):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOperations.cpp:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        (JSC::JIT::compile):
        (JIT):
        * jit/JITCode.cpp:
        (JSC):
        (JSC::JITCode::JITCode):
        (JSC::JITCode::~JITCode):
        (JSC::JITCode::execute):
        (JSC::JITCode::hostFunction):
        (JSC::DirectJITCode::DirectJITCode):
        (JSC::DirectJITCode::~DirectJITCode):
        (JSC::DirectJITCode::addressForCall):
        (JSC::DirectJITCode::executableAddressAtOffset):
        (JSC::DirectJITCode::dataAddressAtOffset):
        (JSC::DirectJITCode::offsetOf):
        (JSC::DirectJITCode::size):
        (JSC::DirectJITCode::contains):
        * jit/JITCode.h:
        (JSC):
        (JITCode):
        (JSC::JITCode::bottomTierJIT):
        (JSC::JITCode::topTierJIT):
        (JSC::JITCode::nextTierJIT):
        (JSC::JITCode::isOptimizingJIT):
        (JSC::JITCode::isBaselineCode):
        (JSC::JITCode::jitType):
        (JSC::JITCode::jitTypeFor):
        (JSC::JITCode::executableAddress):
        (JSC::JITCode::start):
        (JSC::JITCode::end):
        (DirectJITCode):
        * jit/JITDriver.h:
        (JSC::jitCompileIfAppropriate):
        (JSC::jitCompileFunctionIfAppropriate):
        * jit/JITStubs.cpp:
        (JSC::lazyLinkFor):
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualForGenerator):
        * llint/LLIntEntrypoints.cpp:
        (JSC::LLInt::getFunctionEntrypoint):
        (JSC::LLInt::getEvalEntrypoint):
        (JSC::LLInt::getProgramEntrypoint):
        * llint/LLIntEntrypoints.h:
        (JSC):
        (LLInt):
        (JSC::LLInt::getEntrypoint):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileInternal):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::FunctionExecutable::compileForCallInternal):
        (JSC::FunctionExecutable::compileForConstructInternal):
        * runtime/Executable.h:
        (JSC::ExecutableBase::generatedJITCodeForCall):
        (JSC::ExecutableBase::generatedJITCodeForConstruct):
        (JSC::ExecutableBase::generatedJITCodeFor):
        (ExecutableBase):
        (JSC::ExecutableBase::hostCodeEntryFor):
        (JSC::ExecutableBase::jsCodeEntryFor):
        (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor):
        (JSC::NativeExecutable::create):
        (JSC::NativeExecutable::finishCreation):
        (JSC::EvalExecutable::generatedJITCode):
        (JSC::ProgramExecutable::generatedJITCode):
        * runtime/ExecutionHarness.h:
        (JSC::prepareForExecution):
        (JSC::prepareFunctionForExecution):

2013-07-24  Filip Pizlo  <fpizlo@apple.com>

        It should be possible to hijack IndexingHeader for things other than lengths
        https://bugs.webkit.org/show_bug.cgi?id=119065

        Reviewed by Mark Hahnenberg.
        
        Made the body of IndexingHeader be a union.
        
        Modified the offlineasm so that you can say IndexingHeader::u.lengths.publicLength.
        Previously those dots would cause parse errors. Now an identifier in offlineasm can
        have a dot anywhere except the first character.

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * offlineasm/parser.rb:
        * runtime/IndexingHeader.h:
        (JSC::IndexingHeader::offsetOfPublicLength):
        (JSC::IndexingHeader::offsetOfVectorLength):
        (JSC::IndexingHeader::IndexingHeader):
        (JSC::IndexingHeader::vectorLength):
        (JSC::IndexingHeader::setVectorLength):
        (JSC::IndexingHeader::publicLength):
        (JSC::IndexingHeader::setPublicLength):

2013-07-24  Mark Hahnenberg  <mhahnenberg@apple.com>

        JIT::updateTopCallFrame doesn't update the CallFrame's bytecodeOffset if bytecodeOffset == 0
        https://bugs.webkit.org/show_bug.cgi?id=118923

        Reviewed by Filip Pizlo.

        This bug causes the CallFrame's bytecodeOffset to not be properly set when we 
        enter, e.g., cti_optimize from an op_enter.

        * jit/JITInlines.h:
        (JSC::JIT::updateTopCallFrame):

2013-07-23  Filip Pizlo  <fpizlo@apple.com>

        DFG string concatenation optimizations might emit speculative nodes after emitting nodes that kill the original inputs
        https://bugs.webkit.org/show_bug.cgi?id=119032

        Reviewed by Oliver Hunt.

        It just needs some Phantom action.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):

2013-07-10  Mark Lam  <mark.lam@apple.com>

        Need ExpressionRangeInfo before ResolveForPuts in strict mode.
        https://bugs.webkit.org/show_bug.cgi?id=118997.

        Reviewed by Oliver Hunt.

        If we add an assertion in UnlinkedCodeBlock::expressionRangeForBytecodeOffset()
        to ensure that we are able to find an ExpressionRangeInfo for any given bytecode
        offset, the following tests will fails:
            fast/js/basic-strict-mode.html
            fast/js/mozilla/strict/8.7.2.html
        With this fix, those tests will no longer fail.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        - Emit expression info before calls to emitResolveBaseForPut() when in strict mode.

2013-07-23  Mark Lam  <mark.lam@apple.com>

        Added ExpressionRangeInfo for BinaryOpNodes that can throw exceptions
        due to type coersion.
        https://bugs.webkit.org/show_bug.cgi?id=116853.

        Reviewed by Geoffrey Garen.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::BinaryOpNode::emitBytecode):
        - Added expression info for the strcat and the general binary op cases.
          I did not add expression info for the "compare with null" case because
          that comparison cannot trigger type coersion, and hence it won't throw
          any exceptions and doesn't need the expression info.

2013-07-23  Mark Lam  <mark.lam@apple.com>

        Removed unused sourceOffset from JSTokenLocation.
        https://bugs.webkit.org/show_bug.cgi?id=118996.

        Reviewed by Geoffrey Garen.

        This also removes the assertion reported in the bug because it is now
        moot, thereby resolving the assertion failure issue on Windows.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayNode::toArgumentList):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        * parser/Lexer.cpp:
        (JSC::::lex):
        * parser/Lexer.h:
        (JSC::::lexExpectIdentifier):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::::Parser):
        (JSC::::parseFunctionInfo):
        (JSC::::parseExpressionOrLabelStatement):
        (JSC::::parseMemberExpression):
        * parser/Parser.h:
        (JSC::::parse):
        * parser/ParserTokens.h:
        (JSC::JSTokenLocation::JSTokenLocation):

2013-07-22  Alex Christensen  <achristensen@apple.com>

        Added assembly files to Windows 64-bit builds.
        https://bugs.webkit.org/show_bug.cgi?id=118931

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Added JITStubsMSVC64.asm for x64 and enabled MASM.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Added JITStubsMSVC64.asm.

2013-07-20  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Remove unneeded custom stdint.h now that we build on VS2010.
        https://bugs.webkit.org/show_bug.cgi?id=118868.

        Reviewed by Anders Carlsson.

        * os-win32/stdint.h: Removed.
        * GNUmakefile.list.am: Removed reference to os-win32/stdint.h

2013-07-19  Alex Christensen  <achristensen@apple.com>

        Added x64 configuration to Visual Studio build.
        https://bugs.webkit.org/show_bug.cgi?id=118888

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
        * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:

2013-07-18  Andreas Kling  <akling@apple.com>

        CodeBlock DFG entry list isn't getting shrunk-to-fit after linking.
        <http://webkit.org/b/118875>
        <rdar://problem/14488577>

        Reviewed by Geoffrey Garen.

        Move the CodeBlock::shrinkToFit() call out of JITCompiler::link() and to the call sites
        so SpeculativeJIT::linkOSREntries() can fill in CodeBlock::m_dfgData->osrEntry first.

        886 kB progression on <http://twitter.com/awesomekling>

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):

2013-07-18  Chris Curtis  <chris_curtis@apple.com>

        Fixed ASSERTION FAILED: callFrame == globalData->topCallFrame in JSC::Interpreter::addStackTraceIfNecessary
        https://bugs.webkit.org/show_bug.cgi?id=118498

        Reviewed by Geoffrey Garen.

        * jit/JITStubs.cpp:
        (throwExceptionFromOpCall):
        Created new throwExceptionFromOpCall that takes in a functor that contains
        a function pointer (to create the errorObject) instead of a JSValue. Inside
        of throwExceptionFromOpCall the topCallFrame is being rolled back in order
        to handle the error throw. By passing the function pointer in, we can defer
        the creation of the error object until after topCallFrame has been rolled 
        back. This allows the error object to be created with the appropriate top 
        frame.

        DEFINE_STUB_FUNCTION(void*, stack_check):
        DEFINE_STUB_FUNCTION(void*, op_call_arityCheck):
        DEFINE_STUB_FUNCTION(void*, op_construct_arityCheck):
        DEFINE_STUB_FUNCTION(EncodedJSValue, op_call_NotJSFunction):
        DEFINE_STUB_FUNCTION(EncodedJSValue, op_construct_NotJSConstruct):

        (JSC::ErrorFunctor::~ErrorFunctor):
        (JSC::ErrorWithExecFunctor::ErrorWithExecFunctor):
        (JSC::ErrorWithExecFunctor::operator()):
        (JSC::ErrorWithExecAndCalleeFunctor::ErrorWithExecAndCalleeFunctor):
        (JSC::ErrorWithExecAndCalleeFunctor::operator()):
        (JSC::ErrorWithExceptionFunctor::ErrorWithExceptionFunctor):
        (JSC::ErrorWithExceptionFunctor::operator()):
        (JSC::throwExceptionFromOpCall):

        In order to eliminate the need to duplicate code, an error functor was 
        created for the 3 different throwExceptionFromOpCall handles. 
        1. The exception needs to be created, and the function pointer takes 1 
            parameter(callFrame->callerFrame()).
        2. The exception needs to be created, and the function pointer takes 2 
            parameters (callFrame->callerFrame(), callFrame.calleeAsValue()).
        3. The exception is already created. In this case, At the time when 
            the error functor is called, globalData.exception is returned. 

        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/ExceptionHelpers.cpp:
        (JSC::errorDescriptionForValue):
        (JSC::createError):
        (JSC::createInvalidParameterError):
        (JSC::createNotAConstructorError):
        (JSC::createNotAFunctionError):
        (JSC::createNotAnObjectError):
        * runtime/ExceptionHelpers.h:

        The function toString() was being used to stringify an object for an exception
        message. If the user wrote a toString() for that object, then the system would 
        continue to evaluate that code. A new helper function was created to prevent 
        the system to continue execution and exception creation from that execution.

2013-07-18  Filip Pizlo  <fpizlo@apple.com>

        LLInt get_argument_by_val for JSVALUE64 stores into the array profile when it meant to store into the value profile
        https://bugs.webkit.org/show_bug.cgi?id=118865

        Reviewed by Mark Hahnenberg.

        * llint/LowLevelInterpreter64.asm:

2013-07-18  Andreas Kling  <akling@apple.com>

        CodeBlock::m_argumentValueProfiles wastes a lot of memory.
        <http://webkit.org/b/118852>
        <rdar://problem/14481659>

        Reviewed by Anders Carlsson.

        Use Vector::resizeToFit() for CodeBlock::m_argumentValueProfiles. We don't need any padding
        for growth, since we won't be appending to it anyway.

        921 KB progression on <http://twitter.com/awesomekling>

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::setNumParameters):

2013-07-17  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix 32-bit after http://trac.webkit.org/changeset/152813

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2013-07-17  Geoffrey Garen  <ggaren@apple.com>

        API tests should test for JSStringCreateWithCFString with empty string
        https://bugs.webkit.org/show_bug.cgi?id=118819

        Reviewed by Mark Hahnenberg.

        * API/tests/testapi.c:
        (main): Test!

2013-07-17  Filip Pizlo  <fpizlo@apple.com>

        DFG assumes that NewFunction will never pass its input through
        https://bugs.webkit.org/show_bug.cgi?id=118798

        Reviewed by Sam Weinig.
        
        Previously the DFG was assuming that NewFunction always returns a function. That's not
        the case. It may return whatever was passed to it, if it wasn't passed SpecEmpty.
        
        This fact needed to be wired through the compiler.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::executeEffects):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::makeTop):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2013-07-17  Geoffrey Garen  <ggaren@apple.com>

        JSStringCreateWithCFString should not convert the empty string into the NULL string
        https://bugs.webkit.org/show_bug.cgi?id=118816

        Reviewed by Sam Weinig.

        * API/JSStringRef.cpp:
        (JSStringCreateWithUTF8CString): Removed an extraneous comment, which
        a previous version of the patch made incorrect.

        * API/JSStringRefCF.cpp:
        (JSStringCreateWithCFString): Don't convert the empty string into the
        null string.

2013-07-17  Chris Curtis  <chris_curtis@apple.com>

        Naming convention on createInvalidParamError is incorrect.
        https://bugs.webkit.org/show_bug.cgi?id=118756

        Reviewed by Geoffrey Garen.
        
        Changed the naming of createInvalidParamError to createInvalidParameterError.
        This corrects the naming convention for the function listed in the WebKit code styling.

        * interpreter/Interpreter.cpp:
        (JSC::loadVarargs):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::opIn):
        * runtime/ExceptionHelpers.cpp:
        (JSC::createInvalidParameterError):
        * runtime/ExceptionHelpers.h:
        * runtime/JSObject.cpp:
        (JSC::JSObject::hasInstance):

2013-07-16  David Farler  <dfarler@apple.com>

        Typo in DFGInsertionSet.h header guard: "DFGInsectionSet_h" -> "DFGInsertionSet_h"
        https://bugs.webkit.org/show_bug.cgi?id=118753

        Reviewed by Geoffrey Garen.

        * dfg/DFGInsertionSet.h:
        "DFGInsectionSet_h" -> "DFGInsertionSet_h"

2013-07-16  Filip Pizlo  <fpizlo@apple.com>

        MakeRope fixup shouldn't lead to an Identity without kids
        https://bugs.webkit.org/show_bug.cgi?id=118745

        Reviewed by Mark Hahnenberg.
        
        Make the empty string pruning part of fixupMakeRope() stop if it's on the last child.
        
        Make Node::convertToIdentity release-assert that it has exactly one kid.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupMakeRope):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::convertToIdentity):

2013-07-16  Mark Hahnenberg  <mhahnenberg@apple.com>

        Remove reference to JSValueStructSupport.h from JSExport.h
        https://bugs.webkit.org/show_bug.cgi?id=118746

        Reviewed by Filip Pizlo.

        * API/JSExport.h: No such header exists, so it doesn't make sense to reference it.

2013-07-13  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r151978.
        http://trac.webkit.org/changeset/151978
        https://bugs.webkit.org/show_bug.cgi?id=118651

        Caused regressions at least 3 websites (Requested by rniwa on
        #webkit).

        * runtime/JSCJSValue.h:
        * runtime/JSString.h:

2013-07-12  Chris Curtis    <chris_curtis@apple.com>

        Optimize addStrackTraceIfNecessary to be faster in the case when it's not necessary
        https://bugs.webkit.org/show_bug.cgi?id=118328

        Reviewed by Geoffrey Garen.

        Retrieving the stack is costly. We want to get it only once. By moving the check
        for the .stack property above the code to retrieve the stack, we ensure this. 

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::addStackTraceIfNecessary):

2013-07-12  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Build correction after r152573/r152577.
        https://bugs.webkit.org/show_bug.cgi?id=118610

        Reviewed by Oliver Hunt.

        * jit/JITThunks.cpp:
        (JSC::JITThunks::hostFunctionStub): Hand-feed MSVC++ the fact that we want the second
        argument of the make_pair to be a function pointer.

2013-07-11  Oliver Hunt  <oliver@apple.com>

        Attempt to fix the windows build.

        * jit/JITThunks.cpp:
        (JSC::JITThunks::hostFunctionStub):
        * jit/JITThunks.h:

2013-07-10  Oliver Hunt  <oliver@apple.com>

        NativeExecutable cache needs to use both call and construct functions for key
        https://bugs.webkit.org/show_bug.cgi?id=118545

        Reviewed by Geoffrey Garen.

        Make the native executable cache make use a key pair so we don't decide to
        treat all subsequent functions as not being constructors.

        * jit/JITThunks.cpp:
        (JSC::JITThunks::hostFunctionStub):
        * jit/JITThunks.h:
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::create):
        * runtime/JSCell.cpp:
        (JSC::JSCell::getCallData):
        (JSC::JSCell::getConstructData):

2013-07-09  Mark Lam  <mark.lam@apple.com>

        Gardening to unbreak builds on the Windows bot.

        Not reviewed.

        * parser/ParserTokens.h:

2013-07-09  Mark Lam  <mark.lam@apple.com>

        Fix 30% JSBench regression (caused by adding column numbers to stack traces).
        https://bugs.webkit.org/show_bug.cgi?id=118481.

        Reviewed by Mark Hahnenberg and Geoffrey Garen.

        Previously, we already capture ExpressionRangeInfo that provides a divot for
        each bytecode that can potentially throw an exception (and therefore generate
        a stack trace). On first attempt to compute column numbers, we then do a walk
        of the source string to record all line start positions in a table associated
        with the SourceProvider. The column number can then be computed as
            divot - lineStartFor(bytecodeOffset).

        The computation of this lineStarts table is the source of the 30% JSBench
        performance regression.

        The new code now records lineStarts as the lexer and parser scans the source
        code. These lineStarts are then used to compute the column number for the
        given divot, and stored in the ExpressionRangeInfo. Similarly, we also capture
        the line number at the divot point and store that in the ExpressionRangeInfo.
        Hence, to look up line and column numbers, we now lookup the ExpressionRangeInfo
        for the bytecodeOffset, and then compute the line and column from the values
        stored in the expression info.

        The strategy:
        1. We want to minimize perturbations to the lexer and parser. Specifically,
           the changes added should not change how it scans code, and generate bytecode.
        2. We regard the divot as the source character position we are interested
           in. As such, we'll capture line and lineStart (for column) at the point
           when we capture the divot information. This ensures that the 3 values are
           consistent.

        How the change is done:
        1. Change the lexer to track lineStarts.
        2. Change the parser to capture line and lineStarts at the point of capturing
           divots.
        3. Change the parser and associated code to plumb these values all the way to
           the point that the correspoinding ExpressionRangeInfo is emitted.
        4. Propagate and record SourceCode firstLine and firstLineColumnOffset to the
           the necessary places so that we can add them as needed when reifying
           UnlinkedCodeBlocks into CodeBlocks.
        5. Compress the line and column number values in the ExpressionRangeInfo. In
           practice, we seldom have both large line and column numbers. Hence, we can
           encode both in an uint32_t most of the time. For the times when we encounter
           both large line and column numbers, we have a fallback to store the "fat"
           position info.
        6. Emit an ExpressionRangeInfo for UnaryOp nodes to get more line and column
           number coverage.
        7. Change the interpreter to use the new way of computing line and column.
        8. Delete old line and column computation code that is now unused.

        Misc details:
        - the old lexer was tracking both a startOffset and charPosition where
          charPosition equals startOffset - SourceCode.startOffset. We now use
          startOffset exclusively throughout the system for consistency.
          All offset values (including lineStart) are relative to the start of the
          SourceProvider string. These values will only be converted to be relative
          to the SourceCode.startOffset at the very last minute i.e. when the divot
          is stored into the ExpressionRangeInfo.

          This change to use the same offset system everywhere reduces confusion
          from having to convert back and forth between the 2 systems. It also
          enables a lot of assertions to be used.

        - Also fixed some bugs in the choice of divot positions to use. For example,
          both Eval and Function expressions previously used column numbers from
          the start of the expression but used the line number at the end of the
          expression. This is now fixed to use either the start or end positions
          as appropriate, but not a mix of line and columns from both.

        - Why use ints instead of unsigneds for offsets and lineStarts inside the
          lexer and parser?
          Some tests (e.g. fast/js/call-base-resolution.html and
          fast/js/eval-cross-window.html) has shown that lineStart offsets can be
          prior to the SourceCode.startOffset. Keeping the lexer offsets as ints
          simplifies computations and makes it easier to maintain the assertions
          that (startOffset >= lineStartOffset).

          However, column and line numbers are always unsigned when we publish
          them to the ExpressionRangeInfo. The ints are only used inside the
          lexer and parser ... well, and bytecode generator.

        - For all cases, lineStart is always captured where the divot is captured.
          However, some sputnik conformance tests have shown that we cannot honor
          line breaks for assignment statements like the following:

              eval("x\u000A*=\u000A-1;");

          In this case, the lineStart is expected to be captured at the start of
          the assignment expression instead of at the divot point in the middle.
          The assignment expression is the only special case for this.

        This patch has been tested against the full layout tests both with release
        and debug builds with no regression.

        * API/JSContextRef.cpp:
        (JSContextCreateBacktrace):
          - Updated to use the new StackFrame::computeLineAndColumn().
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
          - Added m_firstLineColumnOffset initialization.
          - Plumbed the firstLineColumnOffset into the SourceCode.
          - Initialized column for op_debug using the new way.
        (JSC::CodeBlock::lineNumberForBytecodeOffset):
          - Changed to compute line number using the ExpressionRangeInfo.
        (JSC::CodeBlock::columnNumberForBytecodeOffset): Added
          - Changed to compute column number using the ExpressionRangeInfo.
        (JSC::CodeBlock::expressionRangeForBytecodeOffset):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::firstLineColumnOffset):
        (JSC::GlobalCodeBlock::GlobalCodeBlock):
          - Plumbed firstLineColumnOffset through to the super class.
        (JSC::ProgramCodeBlock::ProgramCodeBlock):
          - Plumbed firstLineColumnOffset through to the super class.
        (JSC::EvalCodeBlock::EvalCodeBlock):
          - Plumbed firstLineColumnOffset through to the super class.
            But for EvalCodeBlocks, the firstLineColumnOffset is always 1
            because we're starting with a new source string with no start
            offset.
        (JSC::FunctionCodeBlock::FunctionCodeBlock):
          - Plumbed firstLineColumnOffset through to the super class.

        * bytecode/ExpressionRangeInfo.h:
          - Added modes for encoding line and column into a single 30-bit
            unsigned. The encoding is in 1 of 3 modes:
            1. FatLineMode: 22-bit line, 8-bit column
            2. FatColumnMode: 8-bit line, 22-bit column
            3. FatLineAndColumnMode: 32-bit line, 32-bit column
        (JSC::ExpressionRangeInfo::encodeFatLineMode): Added.
          - Encodes line and column into the 30-bit position using FatLine mode.
        (JSC::ExpressionRangeInfo::encodeFatColumnMode): Added.
          - Encodes line and column into the 30-bit position using FatColumn mode.
        (JSC::ExpressionRangeInfo::decodeFatLineMode): Added.
          - Decodes the FatLine mode 30-bit position into line and column.
        (JSC::ExpressionRangeInfo::decodeFatColumnMode): Added.
          - Decodes the FatColumn mode 30-bit position into line and column.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
          - Plumbed startColumn through.
        (JSC::UnlinkedFunctionExecutable::link):
          - Plumbed startColumn through.
        (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
          - Computes a line number using the new way.
        (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):
          - Added decoding of line and column.
          - Added handling of the case when we do not find a fitting expression
            range info for a specified bytecodeOffset. This only happens if the
            bytecodeOffset is below the first expression range info. In that
            case, we'll use the first expression range info entry.
        (JSC::UnlinkedCodeBlock::addExpressionInfo):
          - Added encoding of line and column.

        * bytecode/UnlinkedCodeBlock.h:
          - Added m_expressionInfoFatPositions in RareData.
        (JSC::UnlinkedFunctionExecutable::functionStartColumn):
        (JSC::UnlinkedCodeBlock::shrinkToFit):
          - Removed obsoleted m_lineInfo.
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCall): Plumbed line and lineStart through.
        (JSC::BytecodeGenerator::emitCallEval): Plumbed line and lineStart through.
        (JSC::BytecodeGenerator::emitCallVarargs): Plumbed line and lineStart through.
        (JSC::BytecodeGenerator::emitConstruct): Plumbed line and lineStart through.
        (JSC::BytecodeGenerator::emitDebugHook): Plumbed lineStart through.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitNode):
        (JSC::BytecodeGenerator::emitNodeInConditionContext):
          - Removed obsoleted m_lineInfo.
        (JSC::BytecodeGenerator::emitExpressionInfo):
          - Plumbed line and lineStart through.
          - Compute the line and column to be added to the expression range info.
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThrowableExpressionData::emitThrowReferenceError):
        (JSC::ResolveNode::emitBytecode):
        (JSC::ArrayNode::toArgumentList):
        (JSC::BracketAccessorNode::emitBytecode):
        (JSC::DotAccessorNode::emitBytecode):
        (JSC::NewExprNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::FunctionCallBracketNode::emitBytecode):
        (JSC::FunctionCallDotNode::emitBytecode):
        (JSC::CallFunctionCallDotNode::emitBytecode):
        (JSC::ApplyFunctionCallDotNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::PostfixNode::emitBracket):
        (JSC::PostfixNode::emitDot):
        (JSC::DeleteResolveNode::emitBytecode):
        (JSC::DeleteBracketNode::emitBytecode):
        (JSC::DeleteDotNode::emitBytecode):
        (JSC::PrefixNode::emitResolve):
        (JSC::PrefixNode::emitBracket):
        (JSC::PrefixNode::emitDot):
          - Plumbed line and lineStart through the above as needed.

        (JSC::UnaryOpNode::emitBytecode):
          - Added emission of an ExpressionRangeInfo for the UnaryOp node.

        (JSC::BinaryOpNode::emitStrcat):
        (JSC::ThrowableBinaryOpNode::emitBytecode):
        (JSC::InstanceOfNode::emitBytecode):
        (JSC::emitReadModifyAssignment):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::AssignDotNode::emitBytecode):
        (JSC::ReadModifyDotNode::emitBytecode):
        (JSC::AssignBracketNode::emitBytecode):
        (JSC::ReadModifyBracketNode::emitBytecode):
          - Plumbed line and lineStart through the above as needed.

        (JSC::ConstStatementNode::emitBytecode):
        (JSC::EmptyStatementNode::emitBytecode):
        (JSC::DebuggerStatementNode::emitBytecode):
        (JSC::ExprStatementNode::emitBytecode):
        (JSC::VarStatementNode::emitBytecode):
        (JSC::IfElseNode::emitBytecode):
        (JSC::DoWhileNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::WithNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        (JSC::LabelNode::emitBytecode):
        (JSC::ThrowNode::emitBytecode):
        (JSC::TryNode::emitBytecode):
        (JSC::ProgramNode::emitBytecode):
        (JSC::EvalNode::emitBytecode):
        (JSC::FunctionBodyNode::emitBytecode):
          - Plumbed line and lineStart through the above as needed.

        * interpreter/Interpreter.cpp:
        (JSC::appendSourceToError):
          - Added line and column arguments for expressionRangeForBytecodeOffset().
        (JSC::StackFrame::computeLineAndColumn):
          - Replaces StackFrame::line() and StackFrame::column().
        (JSC::StackFrame::expressionInfo):
          - Added line and column arguments.
        (JSC::StackFrame::toString):
          - Changed to use the new StackFrame::computeLineAndColumn().
        (JSC::Interpreter::getStackTrace):
          - Added the needed firstLineColumnOffset arg for the StackFrame.

        * interpreter/Interpreter.h:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::BinaryOpInfo::BinaryOpInfo):
        (JSC::ASTBuilder::AssignmentInfo::AssignmentInfo):
        (JSC::ASTBuilder::createResolve):
        (JSC::ASTBuilder::createBracketAccess):
        (JSC::ASTBuilder::createDotAccess):
        (JSC::ASTBuilder::createRegExp):
        (JSC::ASTBuilder::createNewExpr):
        (JSC::ASTBuilder::createAssignResolve):
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createFunctionBody):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createFuncDeclStatement):
        (JSC::ASTBuilder::createBlockStatement):
        (JSC::ASTBuilder::createExprStatement):
        (JSC::ASTBuilder::createIfStatement):
        (JSC::ASTBuilder::createForLoop):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::createVarStatement):
        (JSC::ASTBuilder::createReturnStatement):
        (JSC::ASTBuilder::createBreakStatement):
        (JSC::ASTBuilder::createContinueStatement):
        (JSC::ASTBuilder::createTryStatement):
        (JSC::ASTBuilder::createSwitchStatement):
        (JSC::ASTBuilder::createWhileStatement):
        (JSC::ASTBuilder::createDoWhileStatement):
        (JSC::ASTBuilder::createLabelStatement):
        (JSC::ASTBuilder::createWithStatement):
        (JSC::ASTBuilder::createThrowStatement):
        (JSC::ASTBuilder::createDebugger):
        (JSC::ASTBuilder::createConstStatement):
        (JSC::ASTBuilder::appendBinaryExpressionInfo):
        (JSC::ASTBuilder::appendUnaryToken):
        (JSC::ASTBuilder::unaryTokenStackLastStart):
        (JSC::ASTBuilder::unaryTokenStackLastLineStartPosition): Added.
        (JSC::ASTBuilder::assignmentStackAppend):
        (JSC::ASTBuilder::createAssignment):
        (JSC::ASTBuilder::setExceptionLocation):
        (JSC::ASTBuilder::makeDeleteNode):
        (JSC::ASTBuilder::makeFunctionCallNode):
        (JSC::ASTBuilder::makeBinaryNode):
        (JSC::ASTBuilder::makeAssignNode):
        (JSC::ASTBuilder::makePrefixNode):
        (JSC::ASTBuilder::makePostfixNode):.
          - Plumbed line, lineStart, and startColumn through the above as needed.

        * parser/Lexer.cpp:
        (JSC::::currentSourcePtr):
        (JSC::::setCode):
          - Added tracking for sourceoffset and lineStart.
        (JSC::::internalShift):
        (JSC::::parseIdentifier):
          - Added tracking for lineStart.
        (JSC::::parseIdentifierSlowCase):
        (JSC::::parseString):
          - Added tracking for lineStart.
        (JSC::::parseStringSlowCase):
        (JSC::::lex):
          - Added tracking for sourceoffset.
        (JSC::::sourceCode):
        * parser/Lexer.h:
        (JSC::Lexer::currentOffset):
        (JSC::Lexer::currentLineStartOffset):
        (JSC::Lexer::setOffset):
          - Added tracking for lineStart.
        (JSC::Lexer::offsetFromSourcePtr): Added. conversion function.
        (JSC::Lexer::sourcePtrFromOffset): Added. conversion function.
        (JSC::Lexer::setOffsetFromSourcePtr):
        (JSC::::lexExpectIdentifier):
          - Added tracking for sourceoffset and lineStart.

        * parser/NodeConstructors.h:
        (JSC::Node::Node):
        (JSC::ResolveNode::ResolveNode):
        (JSC::EvalFunctionCallNode::EvalFunctionCallNode):
        (JSC::FunctionCallValueNode::FunctionCallValueNode):
        (JSC::FunctionCallResolveNode::FunctionCallResolveNode):
        (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
        (JSC::FunctionCallDotNode::FunctionCallDotNode):
        (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
        (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
        (JSC::PostfixNode::PostfixNode):
        (JSC::DeleteResolveNode::DeleteResolveNode):
        (JSC::DeleteBracketNode::DeleteBracketNode):
        (JSC::DeleteDotNode::DeleteDotNode):
        (JSC::PrefixNode::PrefixNode):
        (JSC::ReadModifyResolveNode::ReadModifyResolveNode):
        (JSC::ReadModifyBracketNode::ReadModifyBracketNode):
        (JSC::AssignBracketNode::AssignBracketNode):
        (JSC::AssignDotNode::AssignDotNode):
        (JSC::ReadModifyDotNode::ReadModifyDotNode):
        (JSC::AssignErrorNode::AssignErrorNode):
        (JSC::WithNode::WithNode):
        (JSC::ForInNode::ForInNode):
          - Plumbed line and lineStart through the above as needed.
        * parser/Nodes.cpp:
        (JSC::StatementNode::setLoc): Plumbed lineStart.
        (JSC::ScopeNode::ScopeNode): Plumbed lineStart.
        (JSC::ProgramNode::ProgramNode): Plumbed startColumn.
        (JSC::ProgramNode::create): Plumbed startColumn.
        (JSC::EvalNode::create):
        (JSC::FunctionBodyNode::FunctionBodyNode): Plumbed startColumn.
        (JSC::FunctionBodyNode::create): Plumbed startColumn.
        * parser/Nodes.h:
        (JSC::Node::startOffset):
        (JSC::Node::lineStartOffset): Added.
        (JSC::StatementNode::firstLine):
        (JSC::StatementNode::lastLine):
        (JSC::ThrowableExpressionData::ThrowableExpressionData):
        (JSC::ThrowableExpressionData::setExceptionSourceCode):
        (JSC::ThrowableExpressionData::divotStartOffset):
        (JSC::ThrowableExpressionData::divotEndOffset):
        (JSC::ThrowableExpressionData::divotLine):
        (JSC::ThrowableExpressionData::divotLineStart):
        (JSC::ThrowableSubExpressionData::ThrowableSubExpressionData):
        (JSC::ThrowableSubExpressionData::setSubexpressionInfo):
        (JSC::ThrowableSubExpressionData::subexpressionDivot):
        (JSC::ThrowableSubExpressionData::subexpressionStartOffset):
        (JSC::ThrowableSubExpressionData::subexpressionEndOffset):
        (JSC::ThrowableSubExpressionData::subexpressionLine):
        (JSC::ThrowableSubExpressionData::subexpressionLineStart):
        (JSC::ThrowablePrefixedSubExpressionData::ThrowablePrefixedSubExpressionData):
        (JSC::ThrowablePrefixedSubExpressionData::setSubexpressionInfo):
        (JSC::ThrowablePrefixedSubExpressionData::subexpressionDivot):
        (JSC::ThrowablePrefixedSubExpressionData::subexpressionStartOffset):
        (JSC::ThrowablePrefixedSubExpressionData::subexpressionEndOffset):
        (JSC::ThrowablePrefixedSubExpressionData::subexpressionLine):
        (JSC::ThrowablePrefixedSubExpressionData::subexpressionLineStart):
        (JSC::ScopeNode::startStartOffset):
        (JSC::ScopeNode::startLineStartOffset):
        (JSC::ProgramNode::startColumn):
        (JSC::EvalNode::startColumn):
        (JSC::FunctionBodyNode::startColumn):
          - Plumbed line and lineStart through the above as needed.
        * parser/Parser.cpp:
        (JSC::::Parser):
        (JSC::::parseSourceElements):
        (JSC::::parseVarDeclarationList):
        (JSC::::parseConstDeclarationList):
        (JSC::::parseForStatement):
        (JSC::::parseBreakStatement):
        (JSC::::parseContinueStatement):
        (JSC::::parseReturnStatement):
        (JSC::::parseThrowStatement):
        (JSC::::parseWithStatement):
          - Plumbed line and lineStart through the above as needed.
        (JSC::::parseFunctionBody):
          - Plumbed startColumn.
        (JSC::::parseFunctionInfo):
        (JSC::::parseFunctionDeclaration):
        (JSC::LabelInfo::LabelInfo):
        (JSC::::parseExpressionOrLabelStatement):
        (JSC::::parseAssignmentExpression):
        (JSC::::parseBinaryExpression):
        (JSC::::parseProperty):
        (JSC::::parseObjectLiteral):
        (JSC::::parsePrimaryExpression):
        (JSC::::parseMemberExpression):
        (JSC::::parseUnaryExpression):
          - Plumbed line, lineStart, startColumn through the above as needed.
        * parser/Parser.h:
        (JSC::Parser::next):
        (JSC::Parser::nextExpectIdentifier):
        (JSC::Parser::tokenStart):
        (JSC::Parser::tokenColumn):
        (JSC::Parser::tokenEnd):
        (JSC::Parser::tokenLineStart):
        (JSC::Parser::lastTokenLine):
        (JSC::Parser::lastTokenLineStart):
        (JSC::::parse):
        * parser/ParserTokens.h:
        (JSC::JSTokenLocation::JSTokenLocation):
          - Plumbed lineStart.
        (JSC::JSTokenLocation::lineStartPosition):
        (JSC::JSTokenLocation::startPosition):
        (JSC::JSTokenLocation::endPosition):
        * parser/SourceCode.h:
        (JSC::SourceCode::SourceCode):
        (JSC::SourceCode::startColumn):
        (JSC::makeSource):
        (JSC::SourceCode::subExpression):
        * parser/SourceProvider.cpp: delete old code.
        * parser/SourceProvider.h: delete old code.
        * parser/SourceProviderCacheItem.h:
        (JSC::SourceProviderCacheItem::closeBraceToken):
        (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
          - Plumbed lineStart.
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::makeFunctionCallNode):
        (JSC::SyntaxChecker::makeAssignNode):
        (JSC::SyntaxChecker::makePrefixNode):
        (JSC::SyntaxChecker::makePostfixNode):
        (JSC::SyntaxChecker::makeDeleteNode):
        (JSC::SyntaxChecker::createResolve):
        (JSC::SyntaxChecker::createBracketAccess):
        (JSC::SyntaxChecker::createDotAccess):
        (JSC::SyntaxChecker::createRegExp):
        (JSC::SyntaxChecker::createNewExpr):
        (JSC::SyntaxChecker::createAssignResolve):
        (JSC::SyntaxChecker::createFunctionExpr):
        (JSC::SyntaxChecker::createFunctionBody):
        (JSC::SyntaxChecker::createFuncDeclStatement):
        (JSC::SyntaxChecker::createForInLoop):
        (JSC::SyntaxChecker::createReturnStatement):
        (JSC::SyntaxChecker::createBreakStatement):
        (JSC::SyntaxChecker::createContinueStatement):
        (JSC::SyntaxChecker::createWithStatement):
        (JSC::SyntaxChecker::createLabelStatement):
        (JSC::SyntaxChecker::createThrowStatement):
        (JSC::SyntaxChecker::createGetterOrSetterProperty):
        (JSC::SyntaxChecker::appendBinaryExpressionInfo):
        (JSC::SyntaxChecker::operatorStackPop):
          - Made SyntaxChecker prototype changes to match ASTBuilder due to new
            args added for plumbing line, lineStart, and startColumn.
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::generateBytecode):
        (JSC::CodeCache::getCodeBlock):
          - Plumbed startColumn.
        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::FunctionExecutable::produceCodeBlockFor):
        (JSC::FunctionExecutable::fromGlobalCode):
          - Plumbed startColumn.
        * runtime/Executable.h:
        (JSC::ScriptExecutable::startColumn):
        (JSC::ScriptExecutable::recordParse):
        (JSC::FunctionExecutable::create):
          - Plumbed startColumn.

2013-07-08  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix make distcheck.

        * GNUmakefile.list.am: Add missing header files.

2013-07-04  Patrick Gansterer  <paroga@webkit.org>

        [CMake] Add generation of JITStubs for x86_64 MSVC
        https://bugs.webkit.org/show_bug.cgi?id=116666

        Reviewed by Laszlo Gombos.

        Also move the generation for ARM CPU into the CMakeLists.txt,
        since it's compiler specific and not dedicated to Windows CE.

        * CMakeLists.txt:
        * PlatformWinCE.cmake: Removed.

2013-07-04  Patrick Gansterer  <paroga@webkit.org>

        [CMake] Add STATICALLY_LINKED_WITH_WTF to JavaScriptCore project
        https://bugs.webkit.org/show_bug.cgi?id=118120

        Reviewed by Gyuyoung Kim.

        Since WTF is a static library linked to JavaScriptCore on all CMake ports
        we need to define STATICALLY_LINKED_WITH_WTF for all of them.
        This makes only a difference for Windows, since WTF_EXPORT and WTF_IMPORT
        are the same on all other platforms.

        * CMakeLists.txt:

2013-07-02  Mark Hahnenberg  <mhahnenberg@apple.com>

        Replace RELEASE_ASSERT with ASSERT in CodeBlock:: bytecodeOffsetForCallAtIndex
        https://bugs.webkit.org/show_bug.cgi?id=118316

        Reviewed by Geoffrey Garen.

        This is causing some crashiness in release builds. We should replace it with an ASSERT 
        until we track down all the places that need fixing in bug 118315.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::bytecodeOffsetForCallAtIndex):

2013-07-02  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed build correction for 'DebugSuffix' target.

        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Must pass the
        DEBUGSUFFIX definition to the nmake instance to be available during script processing.

2013-07-01  Sergio Correia  <sergio.correia@openbossa.org>

        [JSC]: Fix maybe-uninitialized gcc 4.8 warning in DFGSpeculativeJIT.cpp
        https://bugs.webkit.org/show_bug.cgi?id=118278

        Reviewed by Filip Pizlo.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
        Initialize valueGPR with InvalidGPRReg.

2013-07-01  Csaba Osztrogonác  <ossy@webkit.org>

        Fix cast-align warnings in JavaScriptCore/heap/HandleBlockInlines.h
        https://bugs.webkit.org/show_bug.cgi?id=118242

        Reviewed by Mark Hahnenberg.

        * heap/HandleBlockInlines.h:
        (JSC::HandleBlock::nodes):

2013-06-29  Andreas Kling  <akling@apple.com>

        Follow-up to r152206: also update HashFlags8BitBuffer in the LLInt.

        * llint/LowLevelInterpreter.asm:

2013-06-28  Andreas Kling  <akling@apple.com>

        Un-crashify JSC tests on debug bots after Anders had his way with StringImpl.

        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):

2013-06-28  Anders Carlsson  <andersca@apple.com>

        Remove String::deprecatedCharactersWithNullTermination() and related code
        https://bugs.webkit.org/show_bug.cgi?id=118211

        Reviewed by Benjamin Poulain.

        * API/JSStringRef.cpp:
        (JSStringCreateWithCharactersNoCopy):
        Update call to StringImpl::createWithoutCopying.

2013-06-27  Timothy Hatcher  <timothy@apple.com>

        Notify the debugger about functions created from source code via new Function() or WebCore::JSLazyEventListener.

        https://bugs.webkit.org/show_bug.cgi?id=118063

        Reviewed by Geoffrey Garen.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedFunctionExecutable::fromGlobalCode): Call Debugger::sourceParsed.

2013-06-26  Anders Carlsson  <andersca@apple.com>

        Add JSStringCreateWithCharactersNoCopy SPI
        https://bugs.webkit.org/show_bug.cgi?id=118074
        <rdar://problem/14279905>

        Reviewed by Geoffrey Garen.

        * API/JSStringRef.cpp:
        (JSStringCreateWithCharactersNoCopy):
        Create a new OpaqueJSString, using the newly added StringImpl::createWithoutCopying function.

        * API/JSStringRefPrivate.h: Added.
        Add a home for the JSStringCreateWithCharactersNoCopy function.

        * API/OpaqueJSString.h:
        (OpaqueJSString::OpaqueJSString):
        Just call isolatedCopy on the passed in string.

        * API/tests/testapi.c:
        Add an API test for JSStringCreateWithCharactersNoCopy.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        Add new files.

2013-06-25  Ryosuke Niwa  <rniwa@webkit.org>

        JSString should remember AtomicString
        https://bugs.webkit.org/show_bug.cgi?id=117386

        Reviewed by Geoffrey Garen.

        Added JSValue::toAtomicString and JSString::atomicString. These two functions allow WebCore to update
        JSString's m_value to set isAtomic flag and avoid the AtomicStringTable lookups in subsequent attempts
        to obtain the AtomicString of the same value.

        * runtime/JSCJSValue.h:
        * runtime/JSString.h:
        (JSC::JSString::atomicString):
        (JSC::JSValue::toAtomicString):

2013-06-24  Roger Fong  <roger_fong@apple.com>

        Unreviewed. Makefile build fix for AppleWindows.

        * JavaScriptCore.vcxproj/JavaScriptCore.make:

2013-06-17  Darin Adler  <darin@apple.com>

        Sort all the Xcode project files
        https://bugs.webkit.org/show_bug.cgi?id=117696

        Reviewed by Anders Carlsson.

        * JavaScriptCore.xcodeproj/project.pbxproj: Ran the sort-Xcode-project-file script.

2013-06-21  Mark Lam  <mark.lam@apple.com>

        Introducing the VMStackBounds class.
        https://bugs.webkit.org/show_bug.cgi?id=117862.

        Reviewed by Geoffrey Garen.

        - Removed Interpreter::StackPolicy.
        - The new VMStackBounds will take over choosing the appropriate stack
          size requirements, and invoking the underlying WTF::StackBounds to
          to the real bounds check.
        - VMStackBounds will now be used universally throughout JSC instead of
          WTF::StackBounds.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * bytecompiler/BytecodeGenerator.h:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::isInErrorHandlingMode):
        * parser/Parser.cpp:
        (JSC::::Parser):
        * parser/Parser.h:
        * runtime/StringRecursionChecker.h:
        (JSC::StringRecursionChecker::performCheck):
        * runtime/VMStackBounds.h: Added.
        (JSC::VMStackBounds::VMStackBounds):
        (JSC::VMStackBounds::isSafeToRecurse):
        (JSC::VMStackBounds::requiredCapacity):

2013-06-20  Mark Lam  <mark.lam@apple.com>

        Change stack capacity requirement to be more reasonable.
        https://bugs.webkit.org/show_bug.cgi?id=117801.

        Reviewed by Geoffrey Garen.

        Previously, the requiredStack in StackPolicy::StackPolicy() was set to
        to a high value like 256K to reduce the chances of encountering an
        undetected stack overflow in a scenario where we have a combination of
        deeply nested divs and a large amount recursive re-entries into the JSGlobalData.

        However, this high value of requiredStack still does not completely
        ensure that we will never encounter an undetected stack overflow. It
        only lessens the probability of encountering it.

        Secondly, on some platforms, the total stack size can be less than 256K
        to start with. Hence, this high value requiredStack renders the JSGlobalData
        unuseable on those platforms.

        This patch will fix the requiredStack to be more reasonable based on
        real world stack usage by the JSGlobalData. We won't (and cannot) try to prevent
        undetected stack overflows outside of JSC as well. External code that
        do deep recursion (e.g. Documnet::updateLayout()) should do their own
        stack checks.

        From a previous experiment, we measured the following:

        On a debug build on OSX:
        1. Stack usage different between recursive calls to interpreter entry:
           7744 bytes
        On a release build on OSX:
        2. Stack usage difference between recursive calls to interpreter entry:
           6352 bytes

        Using these as a guide, we'll pick the following values for the
        StackPolicy:
           requiredStack: 32K
           errorModeRequiredStack: 16K

        The requiredStack is chosen to be 4x the measured usage above. The
        additional 3x is a conservative estimate to account for stack space
        that may be needed by other native functions called while in the
        interpreter.

        The errorModeRequiredStack has to be less than the requiredStack or we
        won't be able to reenter the interpreter to do error handling work when
        an imminent stack overflow is detected. It is assumed that the error
        handling code will only do minimal work to allocate an exception and its
        stack trace, and not run any arbitrary JS code. As such, it is safe to
        allow re-entry into the interpreter with only 2x the measured usage in
        this case.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::StackPolicy::StackPolicy):

2013-06-20  Mikhail Pozdnyakov  <mikhail.pozdnyakov@intel.com>

        HashSet: reverse the order of the template arguments at alternate 'find', 'contains' and 'add' methods
        https://bugs.webkit.org/show_bug.cgi?id=117830

        Reviewed by Anders Carlsson.

        The order of the template arguments at HashSet alternate 'find', 'contains' and
        'add' methods is reversed so that callers can just pass the translator
        and let the compiler deduce input argument type.

        * runtime/Identifier.h:
        (JSC::IdentifierTable::add):

2013-06-20  Roger Fong  <roger_fong@apple.com>

        Make Windows makefile copy build output to a different folder.
        <rdar://problem/14219184>.

        * JavaScriptCore.vcxproj/JavaScriptCore.make:

2013-06-20  Mark Hahnenberg  <mhahnenberg@apple.com>

        Improper deallocation of JSManagedValue causes crashes during autorelease pool draining
        https://bugs.webkit.org/show_bug.cgi?id=117840

        Reviewed by Geoffrey Garen.

        Improperly managing a JSManagedValue can cause a crash when the JSC::Weak inside the 
        JSManagedValue is destroyed upon deallocation. We would rather have improperly maintained 
        JSManagedValues cause memory leaks than take down the whole app. 

        The fix is to use the callback to the JSC::Weak on the destruction of the JSGlobalData so that we 
        can safely null it out. This will prevent ~Weak from crashing.

        * API/JSManagedValue.mm:
        (-[JSManagedValue JSC::JSC::]):
        (JSManagedValueHandleOwner::finalize):
        * API/tests/testapi.mm: Added a test that crashed prior to this fix due to a leaked 
        managed reference. Also fixed a small style nit I noticed in another test.

2013-06-18  Oliver Hunt  <oliver@apple.com>

        Going to google.com/trends causes a crash
        https://bugs.webkit.org/show_bug.cgi?id=117602

        Reviewed by Geoffrey Garen.

        When handling op_throw, etc we need to flush the variables and arguments
        for the entire inline stack, not just the top frame.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::flushAllArgumentsAndCapturedVariablesInInlineStack):
        (JSC::DFG::ByteCodeParser::parseBlock):

2013-06-18  Roger Fong  <roger_fong@apple.com>

        Replace tools32 folder with tools and update WebKit Windows solution accordingly.
        <rdar://problem/14118143>.

        Rubberstamped by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCoreDebug.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedDebug.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedProduction.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props:
        * JavaScriptCore.vcxproj/JavaScriptCorePostBuild.cmd:
        * JavaScriptCore.vcxproj/JavaScriptCoreProduction.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreRelease.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props:
        * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
        * JavaScriptCore.vcxproj/jsc/jscDebug.props:
        * JavaScriptCore.vcxproj/jsc/jscProduction.props:
        * JavaScriptCore.vcxproj/jsc/jscRelease.props:
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapiDebug.props:
        * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props:
        * JavaScriptCore.vcxproj/testapi/testapiProduction.props:
        * JavaScriptCore.vcxproj/testapi/testapiRelease.props:
        * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props:

2013-06-17  Roger Fong  <roger_fong@apple.com>

        Modify Windows makefiles to copy some bin output into Program Files.
        https://bugs.webkit.org/show_bug.cgi?id=117714.
        <rdar://problem/14179054>

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.make:

2013-06-14  Ryosuke Niwa  <rniwa@webkit.org>

        Function names on Object.prototype should be common identifiers
        https://bugs.webkit.org/show_bug.cgi?id=117614

        Reviewed by Darin Adler.

        Patch written by Sam Weinig. Make Object's prototype function names common identififers since they're used frequently.

        * runtime/CommonIdentifiers.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        * runtime/JSObject.h:
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):

2013-06-13  Ryosuke Niwa  <rniwa@webkit.org>

        Remove LiteralIdentifierTable
        https://bugs.webkit.org/show_bug.cgi?id=117613

        Reviewed by Geoffrey Garen.

        Removed LiteralIdentifierTable since it doesn't seem to have any perf. impact now.

        * runtime/Identifier.cpp:
        (JSC::Identifier::add):

2013-06-12  Conrad Shultz  <conrad_shultz@apple.com>

        JSExport header documentation substitutes "semicolon" for "colon"
        https://bugs.webkit.org/show_bug.cgi?id=117552

        Reviewed by Mark Hahnenberg.

        * API/JSExport.h:
        Fix a couple typos.

2013-06-10  Raphael Kubo da Costa  <raphael.kubo.da.costa@intel.com>

        [JSC] Remove a vestige of wxWidgets support.
        https://bugs.webkit.org/show_bug.cgi?id=117419

        Reviewed by Benjamin Poulain.

        * runtime/JSExportMacros.h: Remove a check for BUILDING_WX__ that
        seems to have gone unnoticed when the wxWidgets port was removed.

2013-06-06  Roger Fong  <roger_fong@apple.com>

        Stop copying AAS binaries into build folder.
        https://bugs.webkit.org/show_bug.cgi?id=117319.

        Rubberstamped by Darin Adler.

        * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd:
        * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd:
        * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd:
        * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd:

2013-06-05  Filip Pizlo  <fpizlo@apple.com>

        DFG CFA shouldn't filter ArrayModes with ALL_NON_ARRAY_ARRAY_MODES if the speculated type is not SpecArray
        https://bugs.webkit.org/show_bug.cgi?id=117279
        <rdar://problem/14078025>        

        Reviewed by Mark Hahnenberg.

        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::filterArrayModesByType):

2013-06-05  Michael Saboff  <msaboff@apple.com>

        JSC: Crash beneath cti_op_div @ http://gmailblog.blogspot.com
        https://bugs.webkit.org/show_bug.cgi?id=117280

        Reviewed by Filip Pizlo.

        Updated the merging of VariableAccessData nodes in ArgumentPosition lists
        to find the unified VariableAccessData node that is the root of the
        current node instead of using the current node directly when merging
        attributes.
        Added new dump code to dump the ArgumentPosition list.

        * dfg/DFGArgumentPosition.h:
        (JSC::DFG::rgumentPosition::mergeArgumentPredictionAwareness):
        (JSC::DFG::ArgumentPosition::mergeArgumentUnboxingAwareness):
        (JSC::DFG::ArgumentPosition::dump):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):

2013-06-05  Bear Travis  <betravis@adobe.com>

        [CSS Exclusions][CSS Shapes] Split CSS Exclusions & Shapes compile & runtime flags
        https://bugs.webkit.org/show_bug.cgi?id=117172

        Reviewed by Alexandru Chiculita.

        Adding the CSS_SHAPES compile flag.

        * Configurations/FeatureDefines.xcconfig:

2013-06-05  Balazs Kilvady  <kilvadyb@homejinni.com>

        JSC Assertion tests failures on MIPS.
        https://bugs.webkit.org/show_bug.cgi?id=116552

        Reviewed by Geoffrey Garen.

        Fix condition handlig in branchAdd32 implemetations.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::branchAdd32):

2013-06-04  Julien Brianceau  <jbrianceau@nds.com>

        [sh4] Add floating point absolute function support in baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=117147

        Reviewed by Geoffrey Garen.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::supportsFloatingPointAbs):
        (JSC::MacroAssemblerSH4::absDouble):
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::dabs):
        (JSC::SH4Assembler::printInstr):

2013-06-04  Zan Dobersek  <zdobersek@igalia.com>

        [JSC] Test262 15.5.4.9_3 test is failing
        https://bugs.webkit.org/show_bug.cgi?id=116789

        Reviewed by Geoffrey Garen.

        Bring the String.prototype.localeCompare behavior in line wit ES5 15.9.4.9.
        If method is not given enough arguments, the minimal amount of arguments must be assumed, with their value being undefined.
        The first argument to localeCompare, in its string form, is used as the 'that' string that's used in the comparison.
        Therefor, when calling str.localeCompare() or str.localeCompare(undefined), the first argument is `undefined` and the
        string "undefined" is used as the string to which value of str is compared.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncLocaleCompare): Remove the early return in case of no given arguments to achieve the desired behavior.

2013-06-03  Hojong Han  <hojong.han@samsung.com>

        [EFL] Implement GCActivityCallback
        https://bugs.webkit.org/show_bug.cgi?id=95923

        Reviewed by Geoffrey Garen.

        Implements the activity triggered garbage collector.
        Additional GCs can be triggered by platfrom timer.
        It has sort of compaction effect not to make JSC heap grow fast
        so that memory usage becomes lower than usual.

        * PlatformEfl.cmake: Added.
        * heap/HeapTimer.cpp:
        (JSC):
        (JSC::HeapTimer::HeapTimer):
        (JSC::HeapTimer::~HeapTimer):
        (JSC::HeapTimer::add):
        (JSC::HeapTimer::stop):
        (JSC::HeapTimer::timerEvent):
        * heap/HeapTimer.h:
        (HeapTimer):
        * jsc.cpp:
        (main):
        * runtime/GCActivityCallback.cpp:
        (JSC):
        (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback):
        (JSC::DefaultGCActivityCallback::scheduleTimer):
        (JSC::DefaultGCActivityCallback::cancelTimer):
        (JSC::DefaultGCActivityCallback::didAllocate):
        * runtime/GCActivityCallback.h:
        (GCActivityCallback):
        (JSC::GCActivityCallback::GCActivityCallback):
        (DefaultGCActivityCallback):

2013-06-03  Roger Fong  <roger_fong@apple.com>

        Nuke VS2005 files from the tree.
        <rdar://problem/14042021>.

        Rubberstamped by Brent Fulgham.

        * JavaScriptCore.vcproj: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore.make: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore.resources: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore.resources/Info.plist: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore.sln: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCF.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreDebug.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreDebugAll.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreDebugCairoCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.make: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.vcproj: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedCommon.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedDebug.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedDebugAll.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedDebugCairoCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedProduction.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedRelease.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedReleaseCairoCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedReleasePGO.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePGOOptimize.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePostBuild.cmd: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePreBuild.cmd: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePreLink.cmd: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreProduction.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreRelease.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreReleaseCairoCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreReleasePGO.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreReleasePGOOptimize.vsprops: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/build-generated-files.sh: Removed.
        * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd: Removed.
        * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Removed.
        * JavaScriptCore.vcproj/LLIntAssembly: Removed.
        * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.make: Removed.
        * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: Removed.
        * JavaScriptCore.vcproj/LLIntAssembly/build-LLIntAssembly.sh: Removed.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets: Removed.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Removed.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: Removed.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Removed.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor: Removed.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: Removed.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: Removed.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.vsprops: Removed.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugAll.vsprops: Removed.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugCairoCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.vsprops: Removed.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.vsprops: Removed.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleaseCairoCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleasePGO.vsprops: Removed.
        * JavaScriptCore.vcproj/jsc: Removed.
        * JavaScriptCore.vcproj/jsc/jsc.vcproj: Removed.
        * JavaScriptCore.vcproj/jsc/jscCommon.vsprops: Removed.
        * JavaScriptCore.vcproj/jsc/jscDebug.vsprops: Removed.
        * JavaScriptCore.vcproj/jsc/jscDebugAll.vsprops: Removed.
        * JavaScriptCore.vcproj/jsc/jscDebugCairoCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/jsc/jscPostBuild.cmd: Removed.
        * JavaScriptCore.vcproj/jsc/jscPreBuild.cmd: Removed.
        * JavaScriptCore.vcproj/jsc/jscPreLink.cmd: Removed.
        * JavaScriptCore.vcproj/jsc/jscProduction.vsprops: Removed.
        * JavaScriptCore.vcproj/jsc/jscRelease.vsprops: Removed.
        * JavaScriptCore.vcproj/jsc/jscReleaseCairoCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/jsc/jscReleasePGO.vsprops: Removed.
        * JavaScriptCore.vcproj/testRegExp: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExp.vcproj: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExpCommon.vsprops: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExpDebug.vsprops: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExpDebugAll.vsprops: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExpDebugCairoCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExpPostBuild.cmd: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExpPreBuild.cmd: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExpPreLink.cmd: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExpProduction.vsprops: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExpRelease.vsprops: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExpReleaseCairoCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/testRegExp/testRegExpReleasePGO.vsprops: Removed.
        * JavaScriptCore.vcproj/testapi: Removed.
        * JavaScriptCore.vcproj/testapi/testapi.vcproj: Removed.
        * JavaScriptCore.vcproj/testapi/testapiCommon.vsprops: Removed.
        * JavaScriptCore.vcproj/testapi/testapiDebug.vsprops: Removed.
        * JavaScriptCore.vcproj/testapi/testapiDebugAll.vsprops: Removed.
        * JavaScriptCore.vcproj/testapi/testapiDebugCairoCFLite.vsprops: Removed.
        * JavaScriptCore.vcproj/testapi/testapiPostBuild.cmd: Removed.
        * JavaScriptCore.vcproj/testapi/testapiPreBuild.cmd: Removed.
        * JavaScriptCore.vcproj/testapi/testapiPreLink.cmd: Removed.
        * JavaScriptCore.vcproj/testapi/testapiProduction.vsprops: Removed.
        * JavaScriptCore.vcproj/testapi/testapiRelease.vsprops: Removed.
        * JavaScriptCore.vcproj/testapi/testapiReleaseCairoCFLite.vsprops: Removed.

2013-05-31  Filip Pizlo  <fpizlo@apple.com>

        Incorrect assertion in DFG::Graph::uncheckedActivationRegisterFor()
        <rdar://problem/13989324>

        Rubber stamped by Mark Hahnenberg.
        
        This has a bogus assertion that checks that the passed CodeOrigin doesn't have
        an inline call frame. This was well intentioned in the sense that it is true
        that inlined call frames wouldn't have an activation register. But that doesn't
        mean that people won't ask. Removing the assertion fixes a debug-only crash and
        has no impact on production code. This change adds a comment to that effect.

        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::uncheckedActivationRegisterFor):

2013-05-31  Julien Brianceau  <jbrianceau@nds.com>

        [sh4] Fix Overflow case of branchMul32 in baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=117057

        Reviewed by Oliver Hunt.

        Current implementation of Overflow case in branchMul32 performs an
        unsigned multiplication whereas a signed multiplication is expected.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::branchMul32):

2013-05-31  Julien Brianceau  <jbrianceau@nds.com>

        [sh4] Fix floating point comparisons in baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=117066.

        Reviewed by Oliver Hunt.

        Current implementation of branchDouble function in baseline JIT is wrong
        for some conditions and overkill for others. For instance:
        - With DoubleGreaterThanOrEqual condition, branch will be taken if either
          operand is NaN with current implementation whereras it should not.
        - With DoubleNotEqualOrUnordered condition, performed NaN checks are
          useless (because comparison result is false if either operand is NaN).

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::branchDouble):

2013-05-31  Julien Brianceau  <jbrianceau@nds.com>

        [sh4] Fix double floating point transfer in baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=117054

        Reviewed by Oliver Hunt.

        In current implementation, dmovRegReg function transfers only one single
        FPRegister as PR=1 and SZ=0 in floating point status/control register.
        Double transfers must be performed with two fmov.s opcodes.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::moveDouble):
        (JSC::MacroAssemblerSH4::addDouble): Handle (op2==dest) case properly.
        (JSC::MacroAssemblerSH4::sqrtDouble):
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::fmovsRegReg):

2013-05-31  Julien Brianceau  <jbrianceau@nds.com>

        [sh4] Handle branchType properly in branchTruncateDoubleToInt32.
        https://bugs.webkit.org/show_bug.cgi?id=117062

        Reviewed by Oliver Hunt.

        Current implementation of branchTruncateDoubleToInt32 is incorrect
        when branchType == BranchIfTruncateSuccessful in sh4 baseline JIT.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::branchTruncateDoubleToInt32):

2013-05-31  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed build fix for VS2005 builders.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Add
        missing export for WTF::SHA1::computeHexDigest

2013-05-30  David Farler  <dfarler@apple.com>

        Fix jscore-test when not using --sdk option with jsDriver.pl
        https://bugs.webkit.org/show_bug.cgi?id=116339

        Reviewed by Joe Pecoraro.

        * tests/mozilla/jsDriver.pl:
        (execute_tests):
        With each test, the shell_command needs to be started from scratch.

        This fix will clear the shell_command and start over as before with
        the opt_arch option when not using --sdk with jsDriver.pl.

2013-05-30  Roger Fong  <roger_fong@apple.com>

        Get rid of JavaScript exports file on AppleWin port.
        https://bugs.webkit.org/show_bug.cgi?id=117050.

        Reviewed by Darin Adler.

        Delete the JavaScriptCoreExportGenerator folder and remove dependencies.
        Start linking in WTF.lib now that it's a shared library.

        * JavaScriptCore.vcxproj/JavaScriptCore.submit.sln:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorBuildCmd.cmd: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorDebug.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPreBuild.cmd: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorProduction.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: Removed.
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/make-export-file-generator: Removed.
        * JavaScriptCore.vcxproj/jsc/jscCommon.props:
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props:
        * JavaScriptCore.vcxproj/testapi/testapiCommon.props:

2013-05-22  David Farler  <dfarler@apple.com>

        Add --sdk option to jsDriver.pl to run with iOS Simulator
        https://bugs.webkit.org/show_bug.cgi?id=116339

        Reviewed by David Kilzer.

        * tests/mozilla/jsDriver.pl:
        (execute_tests):
        Prefix shell command with the path to the "sim" tool.
        (parse_args):
        Add -d / --sdk option.
        (usage):
        Help message for -d / --sdk option.

2013-05-30  Julien Brianceau  <jbrianceau@nds.com>

        [sh4] Optimize NaN checks in LLINT for floating point comparisons.
        https://bugs.webkit.org/show_bug.cgi?id=117049

        Reviewed by Oliver Hunt.

        Use the fcmp/eq opcode in sh4 LLINT to test if a double is NaN.
        This is more efficient, doesn't require two tmp registers and requires
        less code than current implementation (which converts double to float,
        then checks 'E = Emax + 1' and 'f != 0').

        * offlineasm/sh4.rb:

2013-05-30  Oliver Hunt  <oliver@apple.com>

        JSCallbackObject does not correctly initialise the PropertySlot for getOwnPropertyDescriptor
        https://bugs.webkit.org/show_bug.cgi?id=117053

        Reviewed by Mark Hahnenberg.

        Set appropriate thisValue on the PropertySlot

        * API/JSCallbackObjectFunctions.h:
        (JSC::::getOwnPropertyDescriptor):
        * API/tests/testapi.mm:

2013-05-29  Jeffrey Pfau  <jpfau@apple.com>

        [Mac] Enable cache partitioning and the public suffix list on 10.8
        <rdar://problem/13679019>

        Rubber-stamped by David Kilzer.

        * Configurations/FeatureDefines.xcconfig:

2013-05-28  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Put correct byteCompile symbol in file. Previous version
        had an extra 'i' appended to the end.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

2013-05-28  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed build fix.  Remove ?byteCompile symbol that
        is no longer accessible during link.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

2013-05-28  Gavin Barraclough  <barraclough@apple.com>

        String(new Date(2010,10,1)) is wrong in KRAT, YAKT
        https://bugs.webkit.org/show_bug.cgi?id=106750

        Reviewed by Darin Adler.

        * runtime/JSDateMath.cpp:
        (JSC::msToGregorianDateTime):
            - Additional review comment fix.

2013-05-28  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed build fix after r150833

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
        A CR/LF combination was lost in the file, combining two symbols.

2013-05-27  Gavin Barraclough  <barraclough@apple.com>

        String(new Date(2010,10,1)) is wrong in KRAT, YAKT
        https://bugs.webkit.org/show_bug.cgi?id=106750

        Reviewed by Darin Adler.

        First part of a fix, simplfy date handling code, instead of operating separately
        on the UTC-standard and standard-DST offsets, just generate a combined UTC-local
        offset (this is what we actually need, and what the OS gives us).

        * runtime/JSDateMath.cpp:
        (JSC::getLocalTimeOffset):
            - removed getUTCOffset, converted getDSTOffset -> getLocalTimeOffset
        (JSC::gregorianDateTimeToMS):
        (JSC::msToGregorianDateTime):
        (JSC::parseDateFromNullTerminatedCharacters):
            - call getLocalTimeOffset instead of getUTCOffset/getDSTOffset
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::resetDateCache):
            - removed cachedUTCOffset, converted DSTOffsetCache -> LocalTimeOffsetCache
        * runtime/JSGlobalData.h:
        (JSC::LocalTimeOffsetCache::LocalTimeOffsetCache):
        (JSC::LocalTimeOffsetCache::reset):
        (LocalTimeOffsetCache):
            - removed cachedUTCOffset, converted DSTOffsetCache -> LocalTimeOffsetCache

2013-05-28  Mark Hahnenberg  <mhahnenberg@apple.com>

        r150199 is very wrong
        https://bugs.webkit.org/show_bug.cgi?id=116876

        JSValue needs to protect its internal JSValueRef.

        Reviewed by Darin Adler.

        * API/JSValue.mm:
        (-[JSValue initWithValue:inContext:]):
        (-[JSValue dealloc]):
        * API/tests/testapi.mm: Added a simple test to make sure that we protect the
        underlying JavaScript value across garbage collections.

2013-05-27  Patrick Gansterer  <paroga@webkit.org>

        Use ICU_INCLUDE_DIRS in BlackBerry CMake files
        https://bugs.webkit.org/show_bug.cgi?id=116210

        Reviewed by Rob Buis.

        Set and use the ICU_INCLUDE_DIRS variable to avoid
        duplicated adding of the ICU include directory.

        * PlatformBlackBerry.cmake:

2013-05-27  Gabor Rapcsanyi  <rgabor@webkit.org>

        MacroAssemblerARM should use xor to swap registers instead of move
        https://bugs.webkit.org/show_bug.cgi?id=116306

        Reviewed by Zoltan Herczeg.

        Change register swapping to xor from move and this way we don't need
        temporary register anymore.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::swap):

2013-05-25  Filip Pizlo  <fpizlo@apple.com>

        We broke (-2^31/-1)|0 in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=116767

        Reviewed by Andreas Kling.
        
        The bug is that we were assuming that in the -2^31 case, we already had -2^31
        in the result register. This was a wrong assumption.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForX86):

2013-05-24  Filip Pizlo  <fpizlo@apple.com>

        We broke !(0/0)
        https://bugs.webkit.org/show_bug.cgi?id=116736

        Reviewed by Gavin Barraclough.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createLogicalNot):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::pureToBoolean):

2013-05-24  Julien Brianceau  <jbrianceau@nds.com>

        [sh4] Optimize LLINT generated code and fix few bugs in baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=116716

        Reviewed by Geoffrey Garen.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::mul32): Cosmetic changes.
        (JSC::MacroAssemblerSH4::convertInt32ToDouble): Absolute address was not dereferenced.
        (JSC::MacroAssemblerSH4::branch32): Absolute address was not dereferenced.
        (JSC::MacroAssemblerSH4::revertJumpReplacementToBranchPtrWithPatch): Use all 32 bits of pointer for revertJump call.
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::revertJump): Use changePCrelativeAddress to patch the whole pointer.
        (JSC::SH4Assembler::linkJump): Cosmetic change.
        * offlineasm/sh4.rb: Optimize LLINT generated code.

2013-05-23  Peter Wang  <peter.wang@torchmobile.com.cn>

        CLoop llint backend should not use the d8 register as scratch register
        https://bugs.webkit.org/show_bug.cgi?id=116019

        Reviewed by Csaba Osztrogonác.

        * offlineasm/cloop.rb:

2013-05-22  Peter Wang  <peter.wang@torchmobile.com.cn>

        Use uninitialized register in "JIT::emit_op_neq_null" and "emit_op_eq_null"
        https://bugs.webkit.org/show_bug.cgi?id=116593

        Reviewed by Filip Pizlo.

        Generated instructions using uninitialized register. It's caused by a mistake of r126494.

        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):

2013-05-22  Filip Pizlo  <fpizlo@apple.com>

        Fix indentation of CodeBlock.h

        Rubber stampted by Mark Hahnenberg.

        * bytecode/CodeBlock.h:

2013-05-22  Julien Brianceau  <jbrianceau@nds.com>

        [sh4] Remove MacroAssemblerSH4.cpp file.
        https://bugs.webkit.org/show_bug.cgi?id=116596.

        Reviewed by Geoffrey Garen.

        Move linkCall and repatchCall implementations from MacroAssemblerSH4.cpp
        to MacroAssemblerSH4.h and remove MacroAssemblerSH4.cpp, as it is done
        for other architectures.

        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * assembler/MacroAssemblerSH4.cpp: Removed.
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::linkCall):
        (MacroAssemblerSH4):
        (JSC::MacroAssemblerSH4::repatchCall):

2013-05-21  Brent Fulgham  <bfulgham@apple.com>

        [Windows] Unreviewed speculative fix for test-bots.

        Add export declaration for WTFInvokeCrashHook to avoid runtime
        load error on test bots.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

2013-05-21  Mark Lam  <mark.lam@apple.com>

        Added missing assert condition for PositiveOrZero in ARM branch32().
        https://bugs.webkit.org/show_bug.cgi?id=116538.

        Reviewed by Geoffrey Garen.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::branchAdd32):

2013-05-20  Mark Hahnenberg  <mhahnenberg@apple.com>

        Disable SuperRegion
        https://bugs.webkit.org/show_bug.cgi?id=116362

        Rubber stamped by Geoff Garen.

        * heap/Region.h:

2013-05-20  Oliver Hunt  <oliver@apple.com>

        Make C API more robust against null contexts
        https://bugs.webkit.org/show_bug.cgi?id=116462

        Reviewed by Anders Carlsson.

        Handle null contexts in a non-crashy way.  It's a bug to ever call the
        API with a null context, and the absence of a context means we can't
        produce a meaningful result, so we still assert in debug builds.

        Now where possible we detect and early return, returning null for any
        pointer type, NaN for doubles, and false for any boolean result.

        * API/JSBase.cpp:
        (JSEvaluateScript):
        (JSCheckScriptSyntax):
        (JSReportExtraMemoryCost):
        * API/JSContextRef.cpp:
        (JSContextGetGlobalObject):
        (JSContextGetGroup):
        (JSContextGetGlobalContext):
        (JSContextCreateBacktrace):
        * API/JSObjectRef.cpp:
        (JSObjectMake):
        (JSObjectMakeFunctionWithCallback):
        (JSObjectMakeConstructor):
        (JSObjectMakeFunction):
        (JSObjectMakeArray):
        (JSObjectMakeDate):
        (JSObjectMakeError):
        (JSObjectMakeRegExp):
        (JSObjectGetPrototype):
        (JSObjectSetPrototype):
        (JSObjectHasProperty):
        (JSObjectGetProperty):
        (JSObjectSetProperty):
        (JSObjectGetPropertyAtIndex):
        (JSObjectSetPropertyAtIndex):
        (JSObjectDeleteProperty):
        (JSObjectCopyPropertyNames):
        * API/JSValueRef.cpp:
        (JSValueGetType):
        (JSValueIsUndefined):
        (JSValueIsNull):
        (JSValueIsBoolean):
        (JSValueIsNumber):
        (JSValueIsString):
        (JSValueIsObject):
        (JSValueIsObjectOfClass):
        (JSValueIsEqual):
        (JSValueIsStrictEqual):
        (JSValueIsInstanceOfConstructor):
        (JSValueMakeUndefined):
        (JSValueMakeNull):
        (JSValueMakeBoolean):
        (JSValueMakeNumber):
        (JSValueMakeString):
        (JSValueMakeFromJSONString):
        (JSValueCreateJSONString):
        (JSValueToBoolean):
        (JSValueToNumber):
        (JSValueToStringCopy):
        (JSValueToObject):
        (JSValueProtect):
        * API/JSWeakObjectMapRefPrivate.cpp:

2013-05-20  David Kilzer  <ddkilzer@apple.com>

        Synchronize FeatureDefines.xcconfig

        * Configurations/FeatureDefines.xcconfig: Remove
        ENABLE_LINK_PRERENDER.  This was missed in r150356.

2013-05-19  Anders Carlsson  <andersca@apple.com>

        Remove link prerendering code
        https://bugs.webkit.org/show_bug.cgi?id=116415

        Reviewed by Darin Adler.

        This code was only used by Chromium and is dead now.

        * Configurations/FeatureDefines.xcconfig:

2013-05-18  Patrick Gansterer  <paroga@webkit.org>

        [CMake] Replace *_LIBRARY_NAME with *_OUTPUT_NAME
        https://bugs.webkit.org/show_bug.cgi?id=114554

        Reviewed by Gyuyoung Kim.

        Using variables as target names is very uncommon in CMake.
        The usual way to specify the name of the resulting binary
        is to set the OUTPUT_NAME target property.

        * CMakeLists.txt:
        * shell/CMakeLists.txt:

2013-05-17  Patrick Gansterer  <paroga@webkit.org>

        [CMake] Remove invalid include paths
        https://bugs.webkit.org/show_bug.cgi?id=116213

        Reviewed by Gyuyoung Kim.

        Since "${JAVASCRIPTCORE_DIR}/wtf" does not exist, it is safe
        to remove them from the list of include directories.

        * PlatformEfl.cmake: Removed.
        * PlatformGTK.cmake: Removed.

2013-05-16  Patrick Gansterer  <paroga@webkit.org>

        Consolidate lists in JavaScriptCore CMake files
        https://bugs.webkit.org/show_bug.cgi?id=115992

        Reviewed by Gyuyoung Kim.

        Move common files into the CMakeLists.txt to avoid duplicating the list of files.
        Also rebase the recently added GTK files to match the other CMake ports, since
        the submitted patch was based on an older version of the source tree.

        * CMakeLists.txt:
        * PlatformEfl.cmake:
        * PlatformGTK.cmake:
        * shell/CMakeLists.txt:
        * shell/PlatformEfl.cmake:
        * shell/PlatformGTK.cmake:

2013-05-16  Geoffrey Garen  <ggaren@apple.com>

        JSValue shouldn't protect/unprotect its context
        https://bugs.webkit.org/show_bug.cgi?id=116234

        Reviewed by Mark Hahnenberg.

        Our retain on _context is sufficient.

        * API/JSValue.mm:
        (-[JSValue initWithValue:inContext:]):
        (-[JSValue dealloc]):

2013-05-15  Ryosuke Niwa  <rniwa@webkit.org>

        Another Windows build fix attempt after r150160.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

2013-05-15  Oliver Hunt  <oliver@apple.com>

        RefCountedArray needs to use vector initialisers for its backing store
        https://bugs.webkit.org/show_bug.cgi?id=116194

        Reviewed by Gavin Barraclough.

        Use an out of line function to clear the exception stack to avoid
        needing to include otherwise unnecessary headers all over the place.

        Everything else is just being updated to use that.

        * bytecompiler/BytecodeGenerator.cpp:
        * interpreter/CallFrame.h:
        (JSC::ExecState::clearSupplementaryExceptionInfo):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::addStackTraceIfNecessary):
        (JSC::Interpreter::throwException):
        * runtime/JSGlobalObject.cpp:
        (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope):
        * runtime/JSGlobalData.cpp:
        (JSC):
        (JSC::JSGlobalData::clearExceptionStack):
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        (JSC::JSGlobalData::exceptionStack):

2013-05-15  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r150051.
        http://trac.webkit.org/changeset/150051
        https://bugs.webkit.org/show_bug.cgi?id=116186

        Broke all JSC tests on Mac and the author is unresponsive
        (Requested by rniwa on #webkit).

        * JavaScriptCore.xcodeproj/project.pbxproj:

2013-05-15  Julien Brianceau  <jbrianceau@nds.com>

        Remove savedTimeoutReg from JITStackFrame for sh4 base JIT.
        https://bugs.webkit.org/show_bug.cgi?id=116143

        Reviewed by Geoffrey Garen.

        Since r148119, timeoutCheckRegister is removed from baseline JIT.
        So we don't need to save r8 register in JITStackFrame anymore for sh4.

        * jit/JITStubs.cpp:
        * jit/JITStubs.h:
        (JITStackFrame):

2013-05-15  Nico Weber  <thakis@chromium.org>

        WebKit doesn't support MSVS2003 any more, remove preprocessor checks for older versions.
        https://bugs.webkit.org/show_bug.cgi?id=116157

        Reviewed by Anders Carlsson.

        Also remove a gcc3.2 workaround.

        Merges parts of these two commits by the talented Nico Weber:
        https://chromium.googlesource.com/chromium/blink/+/3677e2f47348daeff405a40b6f90fbdf0654c2f5
        https://chromium.googlesource.com/chromium/blink/+/0fcd96c448dc30be1416dcc15713c53710c1a312

        * os-win32/inttypes.h:

2013-05-13  Alvaro Lopez Ortega  <alvaro@alobbs.com>

        Nightly build's jsc doesn't work without DYLD_FRAMEWORK...
        https://bugs.webkit.org/show_bug.cgi?id=79065

        Reviewed by Darin Adler.

        Fixes the build process so the depencencies of the jsc binary are
        modified before its copied to its target directory. In this way
        jsc should always use relative reference to the JavaScriptCore
        libraries.

        * JavaScriptCore.xcodeproj/project.pbxproj: Fixes the commands in
        the "Copy Into Framework" target.

2013-05-13  Mark Hahnenberg  <mhahnenberg@apple.com>

        Objective-C API: scanExternalObjectGraph should not create new JSVirtualMachine wrappers
        https://bugs.webkit.org/show_bug.cgi?id=116074

        If scanExternalObjectGraph creates a new JSVirtualMachine wrapper during collection, when the 
        scanExternalObjectGraph call finishes and the autorelease pool is drained we will dealloc the 
        JSVirtualMachine which will cause us to try to take the API lock for the corresponding JSGlobalData. 
        If this happens on a GC thread other than the "main" thread, we will deadlock. The solution 
        is to just check the JSGlobalData cache, and if there is no JSVirtualMachine wrapper, return early.

        Reviewed by Darin Adler.

        * API/JSVirtualMachine.mm:
        (scanExternalObjectGraph):

2013-05-13  Benjamin Poulain  <benjamin@webkit.org>

        Improve stringProtoFuncLastIndexOf for the prefix case
        https://bugs.webkit.org/show_bug.cgi?id=115952

        Reviewed by Geoffrey Garen.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncLastIndexOf):
        Use the optimized string search when possible.

        On Joseph Pecoraro's tests, this gives a ~30% speed improvement.

2013-05-13  Zalan Bujtas  <zalan@apple.com>

        WebProcess consuming very high CPU on linkedin.com
        https://bugs.webkit.org/show_bug.cgi?id=115601

        Reviewed by Andreas Kling.

        Disable WEB_TIMING_MINIMAL.
        Turn off window.performance and performance.now(). Some JS frameworks expect
        additional Web Timing APIs, when performance.now() is available.

        * Configurations/FeatureDefines.xcconfig:

2013-05-12  Anders Carlsson  <andersca@apple.com>

        Stop including UnusedParam.h
        https://bugs.webkit.org/show_bug.cgi?id=116003

        Reviewed by Sam Weinig.

        UnusedParam.h is empty now so there's no need to include it anymore.

        * API/APICast.h:
        * API/tests/JSNode.c:
        * API/tests/JSNodeList.c:
        * API/tests/minidom.c:
        * API/tests/testapi.c:
        * assembler/AbstractMacroAssembler.h:
        * assembler/MacroAssemblerCodeRef.h:
        * bytecode/CodeBlock.cpp:
        * heap/HandleStack.h:
        * interpreter/JSStackInlines.h:
        * jit/CompactJITCodeMap.h:
        * jit/ExecutableAllocator.h:
        * parser/SourceProvider.h:
        * runtime/DatePrototype.cpp:
        * runtime/JSNotAnObject.cpp:
        * runtime/JSSegmentedVariableObject.h:
        * runtime/JSVariableObject.h:
        * runtime/Options.cpp:
        * runtime/PropertyOffset.h:

2013-05-11  Martin Robinson  <mrobinson@igalia.com>

        [GTK] Add a basic cmake build for WTF and JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=115967

        Reviewed by Laszlo Gombos.

        * PlatformGTK.cmake: Added.
        * shell/PlatformGTK.cmake: Added.

2013-05-10  Laszlo Gombos  <l.gombos@samsung.com>

        Remove USE(OS_RANDOMNESS)
        https://bugs.webkit.org/show_bug.cgi?id=108095

        Reviewed by Darin Adler.

        Remove the USE(OS_RANDOMNESS) guard as it is turned on for all
        ports.

        * jit/JIT.cpp:
        (JSC::JIT::JIT):

2013-05-10  Mark Hahnenberg  <mhahnenberg@apple.com>

        Rename StructureCheckHoistingPhase to TypeCheckHoistingPhase
        https://bugs.webkit.org/show_bug.cgi?id=115938

        We're going to add some more types of check hoisting soon, so let's have the right name here.

        Rubber stamped by Filip Pizlo.
        
        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp: Removed.
        * dfg/DFGStructureCheckHoistingPhase.h: Removed.
        * dfg/DFGTypeCheckHoistingPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGStructureCheckHoistingPhase.cpp.
        (JSC::DFG::TypeCheckHoistingPhase::TypeCheckHoistingPhase):
        (JSC::DFG::performTypeCheckHoisting):
        * dfg/DFGTypeCheckHoistingPhase.h: Copied from Source/JavaScriptCore/dfg/DFGStructureCheckHoistingPhase.h.

2013-05-09  Christophe Dumez  <ch.dumez@sisa.samsung.com>

        Unreviewed build fix after r149836.

        It broke at least EFL and GTK builds. Move new static members initialization
        outside the class. Those need to have a definition outside the class because
        their address is used (e.g. CodeCacheMap::nonGlobalWorkingSetMaxEntries).

        * runtime/CodeCache.cpp:
        (JSC):
        * runtime/CodeCache.h:
        (CodeCacheMap):

2013-05-08  Oliver Hunt  <oliver@apple.com>

        Code cache stores bogus var references for functions in eval code
        https://bugs.webkit.org/show_bug.cgi?id=115747

        Reviewed by Mark Hahnenberg.

        Non-global eval now uses a per-CodeBlock cache, and only use it
        when we're at the top of a function's scope.  This means that we
        will no longer cache the parsing of a single string across
        multiple functions, and we won't cache when we're nested inside
        constructs like |with| and |catch| where previously we would, which
        is good because caching in those cases is unsound.

        * bytecode/EvalCodeCache.h:
        (JSC):
        (JSC::EvalCodeCache::getSlow):
        (JSC::EvalCodeCache::get):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::codeCacheForEval):
        (UnlinkedCodeBlock):
        (RareData):
        * debugger/Debugger.cpp:
        (JSC::evaluateInGlobalCallFrame):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluate):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::CodeCache):
        (JSC::CodeCache::generateBytecode):
        (JSC):
        (JSC::CodeCache::getCodeBlock):
        * runtime/CodeCache.h:
        (JSC::CodeCacheMap::CodeCacheMap):
        (CodeCacheMap):
        (JSC::CodeCacheMap::canPruneQuickly):
        (JSC::CodeCacheMap::prune):
        (JSC::CodeCache::create):
        (CodeCache):
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::EvalExecutable):
        (JSC::EvalExecutable::compileInternal):
        * runtime/Executable.h:
        (JSC::EvalExecutable::create):
        (EvalExecutable):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createEvalCodeBlock):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSGlobalData):

2013-05-08  Mark Hahnenberg  <mhahnenberg@apple.com>

        DFGArrayMode::fromObserved is too liberal when it sees different Array and NonArray shapes
        https://bugs.webkit.org/show_bug.cgi?id=115805

        Reviewed by Geoffrey Garen.

        It checks the observed ArrayModes to see if we have seen any ArrayWith* first. If so, it assumes it's 
        an Array::Array, even if we've also observed any NonArrayWith* in the ArrayProfile. This leads to the 
        code generated by jumpSlowForUnwantedArrayMode to check the indexing type against (shape | IsArray) 
        instead of just shape, which can cause us to exit a lot in the case that we saw a NonArray.

        To fix this we need to add a case that checks for both ArrayWith* and NonArrayWith* cases first, which 
        should then use Array::PossiblyArray, then do the checks we were already doing.

        * bytecode/ArrayProfile.h:
        (JSC::hasSeenArray):
        (JSC::hasSeenNonArray):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):

2013-05-09  Joe Mason  <jmason@blackberry.com>

        [BlackBerry] Set up logging buffer on start of jsc executable
        https://bugs.webkit.org/show_bug.cgi?id=114688

        Reviewed by Rob Buis.

        Internal PR: 322715
        Internally Reviewed By: Jeff Rogers

        * jsc.cpp:
        (main): call BB::Platform::setupApplicationLogging

2013-05-08  Michael Saboff  <msaboff@apple.com>

        JSC: There should be a disassembler for ARM Thumb 2
        https://bugs.webkit.org/show_bug.cgi?id=115827

        Reviewed by Filip Pizlo.

        Added a new disassembler for ARMv7 Thumb2 instructions for use by the JSC debugging
        and profiling code.  The opcode coverage is currently not complete.  It covers all
        of the integer instructions JSC currently emits, but only a limited number of
        floating point opcodes.  Currently that is just the 64 bit vmov and vmsr instructions.

        The disassembler is structured as a base opcode class ARMv7DOpcode with sub-classes
        for each instruction group.  There is a public format method that does the bulk of
        the disassembly work.  There are two broad sub-classes, ARMv7D16BitOpcode and
        ARMv7D32BitOpcode, for the 16 bit and 32 bit opcodes.  There are sub-classes under
        those two classes for individual and related groups of opcodes.  Instructions are
        "dispatched" to the right subclass via two arrays of linked lists in the inner classes
        OpcodeGroup.  There is one such inner class for each ARMv7D16BitOpcode and ARMv7D32BitOpcode.
        Each OpcodeGroup has a mask and a pattern that it applies to the instruction to determine
        that it matches a particular group.  OpcodeGroup uses a static method to reinterpret_cast
        the Opcode object to the right base class for the instruction group for formatting.
        The cast eliminates the need of allocating an object for each decoded instruction.
        Unknown instructions are formatted as ".word 1234" or ".long 12345678" depending whether
        the instruction is 16 or 32 bit.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * disassembler/ARMv7: Added.
        * disassembler/ARMv7/ARMv7DOpcode.cpp: Added.
        (ARMv7Disassembler):
        (OpcodeGroupInitializer):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::init):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::startITBlock):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::saveITConditionAt):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::fetchOpcode):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::disassemble):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::bufferPrintf):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendInstructionName):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendRegisterName):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendRegisterList):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendFPRegisterName):
        (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::init):
        (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::doDisassemble):
        (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::defaultFormat):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddRegisterT2::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSPPlusImmediate::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchConditionalT1::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchExchangeT1::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchT2::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareImmediateT1::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT1::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT2::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeGeneratePCRelativeAddress::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadFromLiteralPool::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscBreakpointT1::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscByteHalfwordOps::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscHint16::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscIfThenT1::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveImmediateT1::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveRegisterT1::format):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::init):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::doDisassemble):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::defaultFormat):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::appendModifiedImmediate):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::appendImmShift):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::appendFPRegister):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegShift::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegParallel::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegMisc::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadRegister::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadUnsignedImmediate::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataPushPopSingle::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate12::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleRegister::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::format):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMSR::format):
        * disassembler/ARMv7/ARMv7DOpcode.h: Added.
        (ARMv7Disassembler):
        (ARMv7DOpcode):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::ARMv7DOpcode):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::is32BitInstruction):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::isFPInstruction):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::conditionName):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::shiftName):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::inITBlock):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::startingITBlock):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::endITBlock):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendInstructionNameNoITBlock):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendSeparator):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendCharacter):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendString):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendShiftType):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendSignedImmediate):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendUnsignedImmediate):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendPCRelativeOffset):
        (JSC::ARMv7Disassembler::ARMv7DOpcode::appendShiftAmount):
        (ARMv7D16BitOpcode):
        (OpcodeGroup):
        (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::OpcodeGroup):
        (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::setNext):
        (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::next):
        (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::matches):
        (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::format):
        (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::rm):
        (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::rd):
        (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::opcodeGroupNumber):
        (ARMv7DOpcodeAddRegisterT2):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddRegisterT2::rdn):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddRegisterT2::rm):
        (ARMv7DOpcodeAddSPPlusImmediate):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSPPlusImmediate::rd):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSPPlusImmediate::immediate8):
        (ARMv7DOpcodeAddSubtract):
        (ARMv7DOpcodeAddSubtractT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::rm):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::rn):
        (ARMv7DOpcodeAddSubtractImmediate3):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::immediate3):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::rn):
        (ARMv7DOpcodeAddSubtractImmediate8):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::rdn):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::immediate8):
        (ARMv7DOpcodeBranchConditionalT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchConditionalT1::condition):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchConditionalT1::offset):
        (ARMv7DOpcodeBranchExchangeT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchExchangeT1::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchExchangeT1::rm):
        (ARMv7DOpcodeBranchT2):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchT2::immediate11):
        (ARMv7DOpcodeCompareImmediateT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareImmediateT1::rn):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareImmediateT1::immediate8):
        (ARMv7DOpcodeCompareRegisterT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT1::rn):
        (ARMv7DOpcodeCompareRegisterT2):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT2::rn):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT2::rm):
        (ARMv7DOpcodeDataProcessingRegisterT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::rm):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::rdn):
        (ARMv7DOpcodeGeneratePCRelativeAddress):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeGeneratePCRelativeAddress::rd):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeGeneratePCRelativeAddress::immediate8):
        (ARMv7DOpcodeLoadFromLiteralPool):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadFromLiteralPool::rt):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadFromLiteralPool::immediate8):
        (ARMv7DOpcodeLoadStoreRegisterImmediate):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::immediate5):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::rn):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::rt):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale):
        (ARMv7DOpcodeLoadStoreRegisterImmediateWordAndByte):
        (ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord):
        (ARMv7DOpcodeLoadStoreRegisterOffsetT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::opB):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::rm):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::rn):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::rt):
        (ARMv7DOpcodeLoadStoreRegisterSPRelative):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::rt):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::immediate8):
        (ARMv7DOpcodeLogicalImmediateT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::immediate5):
        (ARMv7DOpcodeMiscAddSubSP):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::immediate7):
        (ARMv7DOpcodeMiscByteHalfwordOps):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscByteHalfwordOps::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscByteHalfwordOps::op):
        (ARMv7DOpcodeMiscBreakpointT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscBreakpointT1::immediate8):
        (ARMv7DOpcodeMiscCompareAndBranch):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::immediate6):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::rn):
        (ARMv7DOpcodeMiscHint16):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscHint16::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscHint16::opA):
        (ARMv7DOpcodeMiscIfThenT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscIfThenT1::firstCondition):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscIfThenT1::mask):
        (ARMv7DOpcodeMiscPushPop):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::registerMask):
        (ARMv7DOpcodeMoveImmediateT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveImmediateT1::rd):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveImmediateT1::immediate8):
        (ARMv7DOpcodeMoveRegisterT1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveRegisterT1::rd):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveRegisterT1::rm):
        (ARMv7D32BitOpcode):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::OpcodeGroup):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::setNext):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::next):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::matches):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::format):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rd):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rm):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rn):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rt):
        (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::opcodeGroupNumber):
        (ARMv7DOpcodeBranchRelative):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::sBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::j1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::j2):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::immediate11):
        (ARMv7DOpcodeConditionalBranchT3):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::offset):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::condition):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::immediate6):
        (ARMv7DOpcodeBranchOrBranchLink):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::offset):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::immediate10):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::isBL):
        (ARMv7DOpcodeDataProcessingLogicalAndRithmetic):
        (ARMv7DOpcodeDataProcessingModifiedImmediate):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::sBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::immediate12):
        (ARMv7DOpcodeDataProcessingShiftedReg):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::sBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::immediate5):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::type):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::tbBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::tBit):
        (ARMv7DOpcodeDataProcessingReg):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingReg::op1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingReg::op2):
        (ARMv7DOpcodeDataProcessingRegShift):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegShift::opName):
        (ARMv7DOpcodeDataProcessingRegExtend):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::opExtendName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::opExtendAndAddName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::rotate):
        (ARMv7DOpcodeDataProcessingRegParallel):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegParallel::opName):
        (ARMv7DOpcodeDataProcessingRegMisc):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegMisc::opName):
        (ARMv7DOpcodeHint32):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::isDebugHint):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::debugOption):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::op):
        (ARMv7DOpcodeFPTransfer):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opH):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opL):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::rt):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opC):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opB):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::vd):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::vn):
        (ARMv7DOpcodeDataLoad):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataLoad::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataLoad::op):
        (ARMv7DOpcodeLoadRegister):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadRegister::immediate2):
        (ARMv7DOpcodeLoadSignedImmediate):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::pBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::uBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::wBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::immediate8):
        (ARMv7DOpcodeLoadUnsignedImmediate):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadUnsignedImmediate::immediate12):
        (ARMv7DOpcodeLongMultipleDivide):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::smlalOpName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::smlaldOpName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::smlsldOpName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::rdLo):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::rdHi):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::op1):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::op2):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::nBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::mBit):
        (ARMv7DOpcodeDataPushPopSingle):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataPushPopSingle::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataPushPopSingle::op):
        (ARMv7DOpcodeDataStoreSingle):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataStoreSingle::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeDataStoreSingle::op):
        (ARMv7DOpcodeStoreSingleImmediate12):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate12::immediate12):
        (ARMv7DOpcodeStoreSingleImmediate8):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::pBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::uBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::wBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::immediate8):
        (ARMv7DOpcodeStoreSingleRegister):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleRegister::immediate2):
        (ARMv7DOpcodeUnmodifiedImmediate):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::opName):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::shBit):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::bitNumOrSatImmediate):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::immediate5):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::immediate12):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::immediate16):
        (ARMv7DOpcodeVMOVDoublePrecision):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::rt2):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::rt):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::globalData):
        (ARMv7DOpcodeVMOVSinglePrecision):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::op):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::rt2):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::rt):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::globalData):
        (ARMv7DOpcodeVMSR):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMSR::opL):
        (JSC::ARMv7Disassembler::ARMv7DOpcodeVMSR::rt):
        * disassembler/ARMv7Disassembler.cpp: Added.
        (JSC::tryToDisassemble):

2013-05-07  Julien Brianceau  <jbrianceau@nds.com>

        Take advantage of pre-decrement and post-increment opcodes for sh4 base JIT.
        https://bugs.webkit.org/show_bug.cgi?id=115722

        Reviewed by Oliver Hunt.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::load8PostInc):
        (MacroAssemblerSH4):
        (JSC::MacroAssemblerSH4::load16Unaligned):
        (JSC::MacroAssemblerSH4::load16PostInc):
        (JSC::MacroAssemblerSH4::storeDouble):
        (JSC::MacroAssemblerSH4::load32WithUnalignedHalfWords):
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::movwMemRegIn):
        (SH4Assembler):
        (JSC::SH4Assembler::movbMemRegIn):
        (JSC::SH4Assembler::printInstr):

2013-05-07  Anders Carlsson  <andersca@apple.com>

        Remove AlwaysInline.h from WTF
        https://bugs.webkit.org/show_bug.cgi?id=115727

        Reviewed by Brent Fulgham.

        The macro that used to be in AlwaysInline.h is now in Compiler.h so there's no reason
        to keep AlwaysInline.h around anymore.

        * jit/JSInterfaceJIT.h:
        * parser/Lexer.h:
        * runtime/JSCJSValue.h:
        * runtime/SymbolTable.h:

2013-05-07  Mikhail Pozdnyakov  <mikhail.pozdnyakov@intel.com>

        HashTraits<RefPtr<P> >::PeekType should be raw pointer for better performance
        https://bugs.webkit.org/show_bug.cgi?id=115646

        Reviewed by Darin Adler.

        * bytecompiler/StaticPropertyAnalyzer.h:
        (JSC::StaticPropertyAnalyzer::putById):
            Updated accordingly to new HashMap<.., RefPtr>::get() semantics.

2013-05-06  Julien Brianceau  <jbrianceau@nds.com>

        Misc bugfix and cleaning in sh4 base JIT.
        https://bugs.webkit.org/show_bug.cgi?id=115627

        Reviewed by Oliver Hunt.

        Get rid of loadX(RegisterID r0, RegisterID src, RegisterID dest) functions.
        Remove misplaced extuw() implementation from MacroAssemblerSH4.
        Add movbRegMemr0 and movwRegMemr0 functions in SH4Assembler.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::add32): Skip operation when first operand is a zero immediate.
        (JSC::MacroAssemblerSH4::sub32): Skip operation when first operand is a zero immediate.
        (JSC::MacroAssemblerSH4::load32): Fix wrong usage of r0 register.
        (JSC::MacroAssemblerSH4::load8Signed): Handle "base == r0" case.
        (MacroAssemblerSH4):
        (JSC::MacroAssemblerSH4::load16): Handle "base == r0" case.
        (JSC::MacroAssemblerSH4::load16Unaligned): Use extuw() implementation from SH4Assembler.
        (JSC::MacroAssemblerSH4::load16Signed): Cosmetic change.
        (JSC::MacroAssemblerSH4::store8): Fix unhandled BaseIndex offset and handle (base == r0) case.
        (JSC::MacroAssemblerSH4::store16): Fix unhandled BaseIndex offset and handle (base == r0) case.
        (JSC::MacroAssemblerSH4::store32):
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::movwRegMemr0):
        (SH4Assembler):
        (JSC::SH4Assembler::movbRegMemr0):
        (JSC::SH4Assembler::placeConstantPoolBarrier): Cosmetic change.
        (JSC::SH4Assembler::maxJumpReplacementSize):
        (JSC::SH4Assembler::replaceWithJump): Correct branch range and save an opcode.
        (JSC::SH4Assembler::printInstr):

2013-05-06  Anders Carlsson  <andersca@apple.com>

        Stop using WTF::deleteAllValues in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=115670

        Reviewed by Oliver Hunt.

        Change the Vectors used to Vectors of OwnPtrs instead.

        * heap/DFGCodeBlocks.cpp:
        (JSC::DFGCodeBlocks::~DFGCodeBlocks):
        (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):

2013-05-06  Andras Becsi  <andras.becsi@digia.com>

        Build with GCC 4.8 fails because of -Wmaybe-uninitialized
        https://bugs.webkit.org/show_bug.cgi?id=115648

        Reviewed by Michael Saboff.

        Initialize values in Options::setOption since from
        there we end up calling OptionRange::init with
        uninitialized members.

        * runtime/Options.cpp:

2013-05-06  Gabor Rapcsanyi  <rgabor@webkit.org>

        JSC ARM traditional failing on Octane NavierStokes test
        https://bugs.webkit.org/show_bug.cgi?id=115626

        Reviewed by Zoltan Herczeg.

        Change the ARM traditional assembler to use double precision on value
        conversions.

        * assembler/ARMAssembler.h:

2013-05-03  Michael Saboff  <msaboff@apple.com>

        There should be a runtime option to constrain what functions get DFG compiled
        https://bugs.webkit.org/show_bug.cgi?id=115576

        Reviewed by Mark Hahnenberg.

        Added OptionRange to Options to allow checking that something is within an option
        or not.  The new OptionClass supports range strings in the form of [!]<low>[:<high>].
        If only one value is given, then it will be used for both low and high.  A leading
        '!' inverts the check.  If no range is given, then checking for a value within a range
        will always return true.  Added the option "bytecodeRangeToDFGCompile" that takes an
        OptionRange string to select the bytecode range of code blocks to DFG compile.

        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile): Added new check for bytecode count within bytecodeRangeToDFGCompile
        range.
        * runtime/Options.cpp:
        (JSC::parse): Added overloaded parse() for OptionRange.
        (JSC::OptionRange::init): Parse range string and then initialize the range.
        (JSC::OptionRange::isInRange): Function used by consumer to check if a value is within
        the specified range.
        (JSC::Options::dumpOption): Added code to dump OptionRange options.
        * runtime/Options.h:
        (OptionRange): New class.
        (JSC::OptionRange::operator= ): This is really used as a default ctor for use within
        the Option static array initialization.
        (JSC::OptionRange::rangeString): This is used for debug.  It assumes that the char*
        passed into OptionRange::init is valid when this function is called.

2013-05-02  Oliver Hunt  <oliver@apple.com>

        Fix potential bug in lookup logic
        https://bugs.webkit.org/show_bug.cgi?id=115522

        Reviewed by Mark Hahnenberg.

        Though not a problem in practise, it is technically possible
        to inject an un-proxied global object into the scope chain
        via the C API.  This change makes sure that the scope walk
        in BytecodeGenerator actually limits itself to scopes that
        are statically bindable.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::resolve):
        * runtime/JSObject.h:
        (JSObject):
        (JSC):
        (JSC::JSObject::isStaticScopeObject):

2013-05-01  Roger Fong  <roger_fong@apple.com>

        Set Path in makefile for AppleWin.

        * JavaScriptCore.vcxproj/JavaScriptCore.make:

2013-05-01  Benjamin Poulain  <benjamin@webkit.org>

        Remove the remaining wscript
        https://bugs.webkit.org/show_bug.cgi?id=115459

        Reviewed by Andreas Kling.

        * wscript: Removed.

2013-04-30  Mark Lam  <mark.lam@apple.com>

        JSContextGroupSetExecutionTimeLimit() should not pass a callback to the
        JSGlobalData watchdog if its client did not pass one in.
        https://bugs.webkit.org/show_bug.cgi?id=115461.

        Reviewed by Geoffrey Garen.

        * API/JSContextRef.cpp:
        (internalScriptTimeoutCallback):
        (JSContextGroupSetExecutionTimeLimit):
        * API/tests/testapi.c:
        (main):
        - Added test case when the time limit callback is 0.
        - Also updated a check to verify that a TerminatedExecutionException is
          thrown when the time out is cancelled.
        - Also fixed some cosmetic typos.

2013-04-30  Geoffrey Garen  <ggaren@apple.com>

        Removed op_ensure_property_exists
        https://bugs.webkit.org/show_bug.cgi?id=115460

        Reviewed by Mark Hahnenberg.

        It was unused, and whatever it was once used for was not optimized.

        * JavaScriptCore.order:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        * jit/JITOpcodes32_64.cpp:
        * jit/JITStubs.cpp:
        * jit/JITStubs.h:
        * llint/LLIntSlowPaths.cpp:
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:

2013-04-30  Oliver Hunt  <oliver@apple.com>

        JSC Stack walking logic craches in the face of inlined functions triggering JSGlobalData re-entry
        https://bugs.webkit.org/show_bug.cgi?id=115449

        Reviewed by Geoffrey Garen.

        Rename callframeishost to something that makes sense, and fix
        getCallerInfo to correctly handle inline functions calling into
        the JSGlobalData.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::codeOriginForReturn):
          Make this more robust in the face of incorrect stack walking
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::trueCallerFrame):
          Everyone has to perform a codeblock() check before calling this
          so we might as well just do it here.
        * interpreter/Interpreter.cpp:
        (JSC::getCallerInfo):

2013-04-30  Julien Brianceau  <jbrianceau@nds.com>

        Bug fixing in sh4 base JIT and LLINT.
        https://bugs.webkit.org/show_bug.cgi?id=115420

        Reviewed by Oliver Hunt.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::lshift32):
        (JSC::MacroAssemblerSH4::rshift32):
        (JSC::MacroAssemblerSH4::branchMul32):
        (JSC::MacroAssemblerSH4::urshift32):
        (JSC::MacroAssemblerSH4::replaceWithJump):
        (JSC::MacroAssemblerSH4::maxJumpReplacementSize):
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::shldRegReg):
        (JSC::SH4Assembler::shadRegReg):
        (JSC::SH4Assembler::shalImm8r):
        (SH4Assembler):
        (JSC::SH4Assembler::sharImm8r):
        (JSC::SH4Assembler::maxJumpReplacementSize):
        (JSC::SH4Assembler::replaceWithJump):
        * offlineasm/sh4.rb:

2013-04-30  Geoffrey Garen  <ggaren@apple.com>

        Objective-C JavaScriptCore API should publicly support bridging to C
        https://bugs.webkit.org/show_bug.cgi?id=115447

        Reviewed by Mark Hahnenberg.

        For consistency, I renamed

            +[JSValue valueWithValue:] => +[JSValue valueWithJSValueRef]
            +[JSContext contextWithGlobalContextRef] => +[JSContext contextWithJSGlobalContextRef]
            -[JSContext globalContext] => -[JSContext JSGlobalContextRef]

        I searched svn to verify that these functions don't have clients yet,
        so we won't break anything.

        I also exported as public API

            +[JSValue valueWithJSValueRef:]
            +[JSContext contextWithJSGlobalContextRef:]

        It's hard to integrate with the C API without these.

2013-04-30  Commit Queue  <rniwa@webkit.org>

        Unreviewed, rolling out r149349 and r149354.
        http://trac.webkit.org/changeset/149349
        http://trac.webkit.org/changeset/149354
        https://bugs.webkit.org/show_bug.cgi?id=115444

         The Thumb version of compileSoftModulo make invalid use of
        registers (Requested by benjaminp on #webkit).

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARMv7Assembler.h:
        (ARMv7Assembler):
        * assembler/AbstractMacroAssembler.h:
        (JSC::isARMv7s):
        (JSC):
        * assembler/MacroAssemblerARMv7.cpp: Removed.
        * assembler/MacroAssemblerARMv7.h:
        (MacroAssemblerARMv7):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileSoftModulo):
        (DFG):
        (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForARMv7s):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

2013-04-30  Zalan Bujtas  <zalan@apple.com>

        Animations fail to start on http://www.google.com/insidesearch/howsearchworks/thestory/
        https://bugs.webkit.org/show_bug.cgi?id=111244

        Reviewed by David Kilzer.
        
        Enable performance.now() as a minimal subset of Web Timing API. 
        It returns DOMHighResTimeStamp, a monotonically increasing value representing the 
        number of milliseconds from the start of the navigation of the current document.
        JS libraries use this API to check against the requestAnimationFrame() timestamp.

        * Configurations/FeatureDefines.xcconfig:

2013-04-30  Zoltan Arvai  <zarvai@inf.u-szeged.hu>

        Unreviewed. Speculative build fix on Qt Arm and Mips after r149349.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileSoftModulo):

2013-04-29  Cosmin Truta  <ctruta@blackberry.com>

        [ARM] Expand the use of integer division
        https://bugs.webkit.org/show_bug.cgi?id=115138

        Reviewed by Benjamin Poulain.

        If availability of hardware integer division isn't known at compile
        time, check the CPU flags and decide at runtime whether to fall back
        to software. Currently, this OS-specific check is implemented on QNX.

        Moreover, use operator % instead of fmod() in the calculation of the
        software modulo. Even when it's software-emulated, operator % is faster
        than fmod(): on ARM v7 QNX, without hardware division, we noticed
        >3% speedup on SunSpider.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::sdiv): Did not compile conditionally.
        (JSC::ARMv7Assembler::udiv): Ditto.
        * assembler/AbstractMacroAssembler.h:
        (JSC::isARMv7s): Removed.
        * assembler/MacroAssemblerARMv7.cpp: Added.
        (JSC::isIntegerDivSupported): Added.
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::supportsIntegerDiv): Added.
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode): Checked MacroAssembler::supportsIntegerDiv() in ArithDiv case.
        * dfg/DFGOperations.cpp:
        (JSC::DFG::operationModOnInts): Added.
        * dfg/DFGOperations.h:
        (JSC::DFG::Z_DFGOperation_ZZ): Added.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileSoftModulo): Separated the X86-specific and ARM-specific codegen
        from the common implementation; used operationModOnInts on ARM.
        (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForARM): Renamed from compileIntegerArithDivForARMv7.
        (JSC::DFG::SpeculativeJIT::compileArithMod): Allowed run-time detection of integer div on ARM.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation): Added overloads with Z_DFGOperation_ZZ arguments.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Used compileIntegerArithDivForARM.

2013-04-29  Benjamin Poulain  <benjamin@webkit.org>

        Unify the data access of StringImpl members from JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=115320

        Reviewed by Andreas Kling.

        DFG accesses the member infos by directly calling the methods on StringImpl,
        while the baseline JIT was using helper methods on ThunkHelpers.

        Cut the middle man, and use StringImpl directly everywhere.

        * jit/JITInlines.h:
        (JSC::JIT::emitLoadCharacterString):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::stringGetByValStubGenerator):
        * jit/JSInterfaceJIT.h:
        * jit/ThunkGenerators.cpp:
        (JSC::stringCharLoad):

2013-04-29  Benjamin Poulain  <bpoulain@apple.com>

        Use push and pop for iOS math function thunks
        https://bugs.webkit.org/show_bug.cgi?id=115215

        Reviewed by Filip Pizlo.

        The iOS ABI is a little different than regular ARM ABI regarding stack alignment.
        The requirement is 4 bytes:
        "The ARM environment uses a stack that—at the point of function calls—is 4-byte aligned,
         grows downward, and contains local variables and a function’s parameters."

        Subsequently, we can just use push and pop to preserve the link register.

        * jit/ThunkGenerators.cpp:

2013-04-29  Brent Fulgham  <bfulgham@webkit.org>

        [Windows, WinCairo] Get rid of last few pthread include/link references.
        https://bugs.webkit.org/show_bug.cgi?id=115375

        Reviewed by Tim Horton.

        * JavaScriptCore.vcproj/jsc/jscPostBuild.cmd:
        * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props:
        * JavaScriptCore.vcxproj/jsc/jscCommon.props:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props:
        * JavaScriptCore.vcxproj/testapi/testapiCommon.props:

2013-04-29  Roger Fong  <roger_fong@apple.com>

        Unreviewed. AppleWin VS2010 build fix.

        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

2013-04-26  Mark Hahnenberg  <mhahnenberg@apple.com>

        ~BlockAllocator should ASSERT that it has no more Regions left
        https://bugs.webkit.org/show_bug.cgi?id=115287

        Reviewed by Andreas Kling.

        * heap/BlockAllocator.cpp:
        (JSC::BlockAllocator::~BlockAllocator):
        (JSC::BlockAllocator::allRegionSetsAreEmpty):
        * heap/BlockAllocator.h:
        (RegionSet):
        (JSC::BlockAllocator::RegionSet::isEmpty):
        (BlockAllocator):

2013-04-29  Mark Hahnenberg  <mhahnenberg@apple.com>

        IndexingTypes should use hex
        https://bugs.webkit.org/show_bug.cgi?id=115286

        Decimal is kind of confusing/hard to read because they're used as bit masks. Hex seems more appropriate.

        Reviewed by Geoffrey Garen.

        * runtime/IndexingType.h:

2013-04-29  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix make distcheck.

        * GNUmakefile.list.am: Add missing headers files to compilation
        and offlineasm/sh4.rb script.

2013-04-28  Dean Jackson  <dino@apple.com>

        [Mac] Disable canvas backing store scaling (HIGH_DPI_CANVAS)
        https://bugs.webkit.org/show_bug.cgi?id=115310

        Reviewed by Simon Fraser.

        Remove ENABLE_HIGH_DPI_CANVAS_macosx.

        * Configurations/FeatureDefines.xcconfig:

2013-04-27  Darin Adler  <darin@apple.com>

        Move from constructor and member function adoptCF/NS to free function adoptCF/NS.
        https://bugs.webkit.org/show_bug.cgi?id=115307

        Reviewed by Geoffrey Garen.

        * heap/HeapTimer.cpp:
        (JSC::HeapTimer::HeapTimer):
        * runtime/JSGlobalData.cpp:
        (JSC::enableAssembler):
        Use adoptCF free function.

2013-04-27  Anders Carlsson  <andersca@apple.com>

        Try to fix the Windows build.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:

2013-04-25  Geoffrey Garen  <ggaren@apple.com>

        Cleaned up pre/post inc/dec in bytecode
        https://bugs.webkit.org/show_bug.cgi?id=115222

        Reviewed by Filip Pizlo.

        A few related changes here:

        (*) Removed post_inc and post_dec. The two-result form was awkward to
        reason about. Being explicit about the intermediate mov and to_number
        reduces DFG overhead, removes some fragile ASSERTs from the DFG, and
        fixes a const bug. Plus, we get to blow away 262 lines of code.

        (*) Renamed pre_inc and pre_dec to inc and dec, since there's only one
        version now.

        (*) Renamed to_jsnumber to to_number, to match the ECMA name.

        (*) Tightened up the codegen and runtime support for to_number.


        * JavaScriptCore.order: Order!

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitInc):
        (JSC::BytecodeGenerator::emitDec):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitToNumber):
        (BytecodeGenerator): Removed post_inc and post_dec.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::emitPreIncOrDec): Updated for rename.

        (JSC::emitPostIncOrDec): Issue an explicit mov and to_number when needed.
        These are rare, and they boil away in the DFG.

        (JSC::PostfixNode::emitResolve):
        (JSC::PrefixNode::emitResolve): For const, use an explicit mov instead
        of any special forms. This fixes a bug where we would do string
        add/subtract instead of number.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.h:
        (JSC::DFG::canCompileOpcode):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_inc):
        (JSC::JIT::emitSlow_op_inc):
        (JSC::JIT::emit_op_dec):
        (JSC::JIT::emitSlow_op_dec):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_op_inc):
        (JSC::JIT::emitSlow_op_inc):
        (JSC::JIT::emit_op_dec):
        (JSC::JIT::emitSlow_op_dec): Removed post_inc/dec, and updated for renames.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_to_number):
        (JSC::JIT::emitSlow_op_to_number): Removed a test for number cells. There's
        no such thing!

        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_to_number): Use LowestTag to avoid making assumptions
        about the lowest valued tag.

        (JSC::JIT::emitSlow_op_to_number): Updated for renames.

        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/JITStubs.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/NodeConstructors.h:
        (JSC::UnaryPlusNode::UnaryPlusNode): Removed post_inc/dec, and updated for renames.

        * runtime/Operations.cpp:
        (JSC::jsIsObjectType): Removed a test for number cells. There's
        no such thing!

2013-04-27  Julien Brianceau  <jbrianceau@nds.com>

        REGRESSION(r149114): cache flush for SH4 arch may flush an extra page.
        https://bugs.webkit.org/show_bug.cgi?id=115305

        Reviewed by Andreas Kling.

        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::cacheFlush):

2013-04-26  Geoffrey Garen  <ggaren@apple.com>

        Re-landing <http://trac.webkit.org/changeset/148999>

            Filled out more cases of branch folding in bytecode when emitting
            expressions into a branching context
            https://bugs.webkit.org/show_bug.cgi?id=115057

            Reviewed by Phil Pizlo.

        We can't fold the number == 1 case to boolean because all non-zero numbers
        down-cast to true, but only 1 is == to true.

2013-04-26  Filip Pizlo  <fpizlo@apple.com>

        Correct indentation of SymbolTable.h
        
        Rubber stamped by Mark Hahnenberg.

        * runtime/SymbolTable.h:

2013-04-26  Roger Fong  <roger_fong@apple.com>

        Make Apple Windows VS2010 build results into and get dependencies from __32 suffixed folders.
        Make the DebugSuffix configuration use _debug dependencies.

        * JavaScriptCore.vcxproj/JavaScriptCore.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.vcxproj/JavaScriptCoreCF.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreDebug.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorBuildCmd.cmd:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorDebug.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPreBuild.cmd:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorProduction.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
        * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedCommon.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedDebug.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedProduction.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props:
        * JavaScriptCore.vcxproj/JavaScriptCorePostBuild.cmd:
        * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd:
        * JavaScriptCore.vcxproj/JavaScriptCoreProduction.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreRelease.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props:
        * JavaScriptCore.vcxproj/build-generated-files.sh:
        * JavaScriptCore.vcxproj/copy-files.cmd:
        * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
        * JavaScriptCore.vcxproj/jsc/jscCommon.props:
        * JavaScriptCore.vcxproj/jsc/jscDebug.props:
        * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd:
        * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd:
        * JavaScriptCore.vcxproj/jsc/jscProduction.props:
        * JavaScriptCore.vcxproj/jsc/jscRelease.props:
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapiCommon.props:
        * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props:
        * JavaScriptCore.vcxproj/testapi/testapiDebug.props:
        * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props:
        * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd:
        * JavaScriptCore.vcxproj/testapi/testapiProduction.props:
        * JavaScriptCore.vcxproj/testapi/testapiRelease.props:
        * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props:

2013-04-26  Roger Fong  <roger_fong@apple.com>

        Disable sub-pixel layout on mac.
        https://bugs.webkit.org/show_bug.cgi?id=114999.

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2013-04-26  Oliver Hunt  <oliver@apple.com>

        Make stack tracing more robust
        https://bugs.webkit.org/show_bug.cgi?id=115272

        Reviewed by Geoffrey Garen.

        CallFrame already handles stack walking confusion robustly,
        so we should make sure that the actual walk handles that as well.

        * interpreter/Interpreter.cpp:
        (JSC::getCallerInfo):

2013-04-26  Mark Hahnenberg  <mhahnenberg@apple.com>

        REGRESSION(r149165): It made many tests crash on 32 bit
        https://bugs.webkit.org/show_bug.cgi?id=115227

        Reviewed by Csaba Osztrogonác.

        m_reservation is uninitialized when ENABLE(SUPER_REGION) is false.

        * heap/SuperRegion.cpp:
        (JSC::SuperRegion::~SuperRegion):

2013-04-26  Julien Brianceau  <jbrianceau@nds.com>

        Fix SH4 build broken since r149159.
        https://bugs.webkit.org/show_bug.cgi?id=115229

        Add BranchTruncateType enum in SH4 port and handle it in branchTruncateDoubleToInt32.

        Reviewed by Allan Sandfeld Jensen.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::branchTruncateDoubleToInt32):

2013-04-25  Mark Hahnenberg  <mhahnenberg@apple.com>

        SuperRegion doesn't call deallocate() on its PageReservation
        https://bugs.webkit.org/show_bug.cgi?id=115208

        Reviewed by Geoffrey Garen.

        It should. This doesn't cause us to leak physical memory, but it does cause us to leak virtual 
        address space (and probably mach ports), which is also bad :-( FixedVMPoolExecutableAllocator 
        also has this bug, but it doesn't matter much because there's only one instance of that class 
        throughout the entire lifetime of the process, whereas each JSGlobalData has its own SuperRegion. 

        * heap/SuperRegion.cpp:
        (JSC::SuperRegion::~SuperRegion):
        * heap/SuperRegion.h:
        (SuperRegion):
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (FixedVMPoolExecutableAllocator):
        (JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator):

2013-04-25  Filip Pizlo  <fpizlo@apple.com>

        DFG doesn't support to_jsnumber
        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):

2013-04-24  Oliver Hunt  <oliver@apple.com>

        Add support for Math.imul
        https://bugs.webkit.org/show_bug.cgi?id=115143

        Reviewed by Filip Pizlo.

        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/JSGlobalData.cpp:
        (JSC::thunkGeneratorForIntrinsic):

2013-04-25  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, roll out http://trac.webkit.org/changeset/148999
        It broke http://kripken.github.io/ammo.js/examples/new/ammo.html

        * JavaScriptCore.order:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewArray):
        (JSC::BytecodeGenerator::emitThrowReferenceError):
        (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::shouldEmitProfileHooks):
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC):
        (JSC::NullNode::emitBytecode):
        (JSC::BooleanNode::emitBytecode):
        (JSC::NumberNode::emitBytecode):
        (JSC::StringNode::emitBytecode):
        (JSC::IfNode::emitBytecode):
        (JSC::IfElseNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createIfStatement):
        (ASTBuilder):
        * parser/NodeConstructors.h:
        (JSC):
        (JSC::NullNode::NullNode):
        (JSC::BooleanNode::BooleanNode):
        (JSC::NumberNode::NumberNode):
        (JSC::StringNode::StringNode):
        (JSC::IfNode::IfNode):
        (JSC::IfElseNode::IfElseNode):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isPure):
        (JSC::ExpressionNode::isSubtract):
        (StatementNode):
        (NullNode):
        (JSC::NullNode::isNull):
        (BooleanNode):
        (JSC::BooleanNode::isPure):
        (NumberNode):
        (JSC::NumberNode::value):
        (JSC::NumberNode::isPure):
        (StringNode):
        (JSC::StringNode::isPure):
        (JSC::StringNode::isString):
        (BinaryOpNode):
        (IfNode):
        (JSC):
        (IfElseNode):
        (ContinueNode):
        (BreakNode):
        * parser/Parser.cpp:
        (JSC::::parseIfStatement):
        * parser/ResultType.h:
        (ResultType):
        * runtime/JSCJSValueInlines.h:
        (JSC::JSValue::pureToBoolean):
        * runtime/JSCell.h:
        (JSCell):
        * runtime/JSCellInlines.h:
        (JSC):

2013-04-25  Filip Pizlo  <fpizlo@apple.com>

        PreciseJumpTargets should treat loop_hint as a jump target
        https://bugs.webkit.org/show_bug.cgi?id=115209

        Reviewed by Mark Hahnenberg.
        
        I didn't add a test but I turned this into a release assertion. Running Octane is enough
        to trigger it.

        * bytecode/PreciseJumpTargets.cpp:
        (JSC::computePreciseJumpTargets):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

2013-04-25  Roman Zhuykov  <zhroma@ispras.ru>

        Fix problems with processing negative zero on DFG.
        https://bugs.webkit.org/show_bug.cgi?id=113862

        Reviewed by Filip Pizlo.

        Fix NodeNeedsNegZero flag propagation in BackwardPropagationPhase.
        Function arithNodeFlags should not mask NodeNeedsNegZero flag for ArithNegate and DoubleAsInt32
        nodes and this flag should be always used to decide where we need to generate nezative-zero checks.
        Remove unnecessary negative-zero checks from integer ArithDiv on ARM.
        Also remove such checks from integer ArithMod on ARM and X86, and make them always to
        check not only "modulo_result == 0" but also "dividend < 0".
        Generate faster code for case when ArithMod operation divisor is constant power of 2 on ARMv7
        in the same way as on ARMv7s, and add negative-zero checks into this code when needed.
        Change speculationCheck ExitKind from Overflow to NegativeZero where applicable.
 
        This shows 30% speedup of math-spectral-norm, and 5% speedup
        on SunSpider overall on ARMv7 Linux.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::branchConvertDoubleToInt32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::branchConvertDoubleToInt32):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::branchConvertDoubleToInt32):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::branchConvertDoubleToInt32):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::isNotNegZero):
        (JSC::DFG::BackwardsPropagationPhase::isNotPosZero):
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::arithNodeFlags):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
        (JSC::DFG::SpeculativeJIT::compileSoftModulo):
        (JSC::DFG::SpeculativeJIT::compileArithNegate):

2013-04-25  Oliver Hunt  <oliver@apple.com>

        Stack guards are too conservative
        https://bugs.webkit.org/show_bug.cgi?id=115147

        Reviewed by Mark Hahnenberg.

        Increase stack guard to closer to old size.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::StackPolicy::StackPolicy):

2013-04-25  Oliver Hunt  <oliver@apple.com>

        Stack guards are too conservative
        https://bugs.webkit.org/show_bug.cgi?id=115147

        Reviewed by Geoffrey Garen.

        Reduce the limits and simplify the decision making.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::StackPolicy::StackPolicy):

2013-04-25  Nick Diego Yamane  <nick.yamane@openbossa.org>

        JSC: Fix interpreter misbehavior in builds with JIT disabled
        https://bugs.webkit.org/show_bug.cgi?id=115190

        Reviewed by Oliver Hunt.

        Commit http://trac.webkit.org/changeset/147858 modified
        some details on how JS stack traces are built. The method
        "getLineNumberForCallFrame", renamed in that changeset to
        "getBytecodeOffsetForCallFrame" is always returning `0' when
        JIT is disabled

        How to reproduce:
         - Build webkit with JIT disabled
         - Open MiniBrowser, for example, with http://google.com
         - In a debug build, WebProcess will hit the following ASSERT:
           Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp:279 ASSERT(low);

        * interpreter/Interpreter.cpp:
        (JSC::getBytecodeOffsetForCallFrame):

2013-04-25  Oliver Hunt  <oliver@apple.com>

        Make checkSyntax take a JSGlobalData instead of an ExecState

        RS=Tim

        * jsc.cpp:
        (runInteractive):
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        * runtime/Completion.h:
        (JSC):

2013-04-25  Michael Saboff  <msaboff@apple.com>

        32 Bit: Crash due to RegExpTest nodes not setting result type to Boolean
        https://bugs.webkit.org/show_bug.cgi?id=115188

        Reviewed by Geoffrey Garen.

        Changed the RegExpTest node to set the AbstractValue to boolean, since that
        what it is.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::executeEffects):

2013-04-25  Julien Brianceau  <jbrianceau@nds.com>

        REGRESSION(r137994): Random crashes occur with SH4 JSC.
        https://bugs.webkit.org/show_bug.cgi?id=115167.

        Reviewed by Oliver Hunt.

        Since r137994, uncommited pages could be inside the area of memory in
        parameter of the cacheFlush function. That's why we have to flush each
        page separately to avoid a fail of the whole flush, if an uncommited page
        is in the area.

        This patch is very similar to changeset 145194 made for ARMv7 architecture,
        see https://bugs.webkit.org/show_bug.cgi?id=111441 for further information.

        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::cacheFlush):

2013-04-24  Mark Lam  <mark.lam@apple.com>

        Add watchdog timer polling for the DFG.
        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):

2013-04-24  Filip Pizlo  <fpizlo@apple.com>

        Special thunks for math functions should work on ARMv7
        https://bugs.webkit.org/show_bug.cgi?id=115144

        Reviewed by Gavin Barraclough and Oliver Hunt.
        
        The only hard bit here was ensuring that we implemented the very special
        "cheap C call" convention on ARMv7.

        * assembler/AbstractMacroAssembler.h:
        (JSC::isARMv7s):
        (JSC):
        (JSC::isX86):
        * dfg/DFGCommon.h:
        * jit/SpecializedThunkJIT.h:
        (SpecializedThunkJIT):
        (JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn):
        * jit/ThunkGenerators.cpp:
        (JSC::floorThunkGenerator):
        (JSC::ceilThunkGenerator):
        (JSC::roundThunkGenerator):
        (JSC::expThunkGenerator):
        (JSC::logThunkGenerator):

2013-04-24  Julien Brianceau  <jbrianceau@nds.com>

        Misc bugfix and cleaning in sh4 base JIT.
        https://bugs.webkit.org/show_bug.cgi?id=115022.

        Reviewed by Oliver Hunt.

        Remove unused add32() and sub32() with scratchreg parameter to avoid
        confusion as this function prototype means another behaviour.
        Remove unused "void push(Address)" function which seems quite buggy.

        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::and32): Cosmetic change.
        (JSC::MacroAssemblerSH4::lshift32): Cosmetic change.
        (JSC::MacroAssemblerSH4::or32): Cosmetic change.
        (JSC::MacroAssemblerSH4::xor32): Cosmetic change.
        (MacroAssemblerSH4):
        (JSC::MacroAssemblerSH4::load32): Cosmetic change.
        (JSC::MacroAssemblerSH4::load8Signed): Fix invalid offset upper limit
        when using r0 register and cosmetic changes.
        (JSC::MacroAssemblerSH4::load8): Reuse load8Signed to avoid duplication.
        (JSC::MacroAssemblerSH4::load16): Fix invalid offset upper limit when
        using r0 register, fix missing offset shift and cosmetic changes.
        (JSC::MacroAssemblerSH4::store32): Cosmetic change.
        (JSC::MacroAssemblerSH4::branchAdd32): Store result value before branch.

2013-04-24  Patrick Gansterer  <paroga@webkit.org>

        [WIN] Remove pthread from Visual Studio files in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=114864

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops:
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops:
        * JavaScriptCore.vcproj/jsc/jscCommon.vsprops:
        * JavaScriptCore.vcproj/testRegExp/testRegExpCommon.vsprops:
        * JavaScriptCore.vcproj/testapi/testapiCommon.vsprops:
        * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props:
        * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props:
        * JavaScriptCore.vcxproj/jsc/jscCommon.props:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props:
        * JavaScriptCore.vcxproj/testapi/testapiCommon.props:
        * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props:

2013-04-24  Filip Pizlo  <fpizlo@apple.com>

        DFG should keep the operand to create_this alive if it's emitting code for create_this
        https://bugs.webkit.org/show_bug.cgi?id=115133

        Reviewed by Mark Hahnenberg.
        
        The DFG must model bytecode liveness, or else OSR exit is going to have a really bad time.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

2013-04-24  Roger Fong  <roger_fong@apple.com>

        Have VS2010 WebKit solution look in WebKit_Libraries/lib32 for dependencies.

        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd:
        * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd:
        * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd:
        * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd:
        * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd:
        * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd:
        * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd:

2013-04-24  Geoffrey Garen  <ggaren@apple.com>

        32-bit build fix.

        Unreviewed.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch): Explicitly
        truncate to 32-bit to avoid compiler warnings. It's safe to truncate
        because the payload of a boolean is the low bits on both 64-bit and 32-bit.

2013-04-23  Geoffrey Garen  <ggaren@apple.com>

        Filled out more cases of branch folding in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=115088

        Reviewed by Oliver Hunt.

        No change on the benchmarks we track, but a 3X speedup on a
        microbenchmark that uses these techniques.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): (!/=)= and (!/=)== can constant
        fold all types, not just numbers, because true constants have no
        side effects when type-converted at runtime.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateBoolean): Added support for fixing up
        boolean uses, like we do for other types like number.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
        (JSC::DFG::SpeculativeJIT::compare):
        (JSC::DFG::SpeculativeJIT::compileStrictEq):
        (JSC::DFG::SpeculativeJIT::compileBooleanCompare): Peephole fuse
        boolean compare and/or compare-branch, now that we have the types for
        them.

        * dfg/DFGSpeculativeJIT.h: Updated declarations.

== Rolled over to ChangeLog-2013-04-24 ==