2015-12-04  Filip Pizlo  <fpizlo@apple.com>

        Having a bad time has a really awful time when it runs at the same time as the JIT
        https://bugs.webkit.org/show_bug.cgi?id=151882
        rdar://problem/23547038

        Reviewed by Geoffrey Garen.

        The DFG's use of watchpoints for havingABadTime goes back a long time. We introduced this feature
        when we first introduced watchpoints. That left it open to a lot of bitrot. On top of that, this
        code doesn't get tested much because having a bad time is not something that is really supposed to
        happen.

        Well, now I've got reports that it does happen - or at least, we know that it is because of
        crashes in an assertion that could only be triggered if a bad time was had. In the meantime, we
        added two new features without adequately testing havingABadTime: concurrent JIT and FTL.
        Concurrency means that we have to worry about the havingABadTime watchpoint triggering during
        compilation. FTL means that we have new code and new optimizations that needs to deal with this
        feature correctly.

        The bug can arise via race condition or just goofy profiling. As in the newly added test, we could
        first profile an allocation thinking that it will allocate sane arrays. Then we might have a bad
        time, and then compile that function with the FTL. The ByteCodeParser will represent the
        allocation with a NewArray node that has a sane indexingType(). But when we go to lower the Node,
        we observe that the Structure* that the JSGlobalObject tells us to use has a different indexing
        type. This is a feature of havingABadTime that the DFG knew about, but the FTL didn't. The FTL
        didn't know about it because we didn't have adequate tests, and this code rarely gets triggered in
        the wild. So, the FTL had a silly assertion that the indexing types match. They absolutely don't
        have to match.

        There is another bug, a race condition, that remains even if we remove the bad assertion. We set
        the havingABadTime watchpoint late in compilation, and we do it based on whether the watchpoint is
        still OK. This means that we could parse a function before we have a bad time and then do
        optimizations (for example in AbstractInterpreter) like proving that the structure set associated
        with the value returned by the NewArray is the one with a sane indexing type. Then, after those
        optimizations have already been done, we will go to set the watchpoint. But just as we are doing
        this, we could haveABadTime on the main thread. Currently this sort of almost works because
        having a bad time requires doing a GC, and we can't GC until the watchpoint collection phase. But
        that feels too fragile. So, this phase moves the setting of the watchpoint to the FixupPhase. This
        is consistent with our long-term goal of removing the WatchpointCollectionPhase. Moving this to
        FixupPhase means that we set the watchpoint before doing any optimizations. So, if having a bad
        time happens before the FixupPhase then all optimizations will agree that we're having a bad time
        and so everything is fine; if we have a bad time after FixupPhase then we will cancel the
        compilation anyway.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::watchHavingABadTime):
        (JSC::DFG::FixupPhase::createToString):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasIndexingType):
        (JSC::DFG::Node::indexingType):
        * dfg/DFGWatchpointCollectionPhase.cpp:
        (JSC::DFG::WatchpointCollectionPhase::handle):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArray):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayBuffer):
        * tests/stress/ftl-has-a-bad-time.js: Added.

2015-12-04  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Use Div and ChillDiv in FTL(B3)Output
        https://bugs.webkit.org/show_bug.cgi?id=151844

        Reviewed by Geoffrey Garen.

        I copied part of the code of compileArithDiv()
        to create a new function FTLOutput::childDiv().

        With childDiv() being a concept of FTLOutput,
        FTLB3Output was updated accordingly.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::div):
        (JSC::FTL::Output::chillDiv):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::chillDiv):
        * ftl/FTLOutput.h:

2015-12-04  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Extend the strength reduction of B3's BitAnd with booleans
        https://bugs.webkit.org/show_bug.cgi?id=151852

        Reviewed by Saam Barati.

        1) Masking a boolean with any pattern that has the lsb set
           remains a boolean.
        2) ReduceStrength on that particular pattern of BitAnd.

        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::returnsBool):
        * b3/testb3.cpp:
        (JSC::B3::testBitAndWithMaskReturnsBooleans):
        (JSC::B3::run):

2015-12-04  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add doubleRem() to FTLB3Output
        https://bugs.webkit.org/show_bug.cgi?id=151851

        Reviewed by Geoffrey Garen.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleRem):

2015-12-04  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add signExt() to FTLB3Output
        https://bugs.webkit.org/show_bug.cgi?id=151853

        Reviewed by Geoffrey Garen.

        Rename signExt() to signExt32To64(). This is just to separate
        it explicitly from the remaining signExt() used inside FTLOutput.

        Then use the SExt32 for implementing that in B3.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::signExt32To64):
        (JSC::FTL::Output::signExt): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInt52Rep):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetDirectPname):
        (JSC::FTL::DFG::LowerDFGToLLVM::strictInt52ToInt32):
        (JSC::FTL::DFG::LowerDFGToLLVM::strictInt52ToJSValue):
        (JSC::FTL::DFG::LowerDFGToLLVM::jsValueToStrictInt52):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::signExt32To64):
        (JSC::FTL::Output::signExt):

2015-12-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Unskip many inspector/debugger tests
        https://bugs.webkit.org/show_bug.cgi?id=151843

        Reviewed by Timothy Hatcher.

        * bindings/ScriptFunctionCall.cpp:
        (Deprecated::ScriptFunctionCall::call):
        Ignore TerminationExceptions, as those aren't real execution
        exceptions and may be seen on Workers that have closed.

2015-12-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove untested and unused Worker inspection
        https://bugs.webkit.org/show_bug.cgi?id=151848

        Reviewed by Brian Burg.

        * CMakeLists.txt:
        * DerivedSources.make:
        * debugger/Debugger.cpp:
        (JSC::Debugger::Debugger):
        (JSC::Debugger::willExecuteProgram):
        * debugger/Debugger.h:
        * inspector/JSGlobalObjectScriptDebugServer.cpp:
        (Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::ScriptDebugServer):
        * inspector/ScriptDebugServer.h:
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::run): Deleted.
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/agents/JSGlobalObjectConsoleAgent.h:
        * inspector/protocol/Runtime.json:
        * inspector/protocol/Worker.json: Removed.

2015-12-04  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Specifically Identify the Global Lexical Environment Scope
        https://bugs.webkit.org/show_bug.cgi?id=151828

        Reviewed by Brian Burg.

        * inspector/InjectedScriptSource.js:
        Include the new scope type.

        * inspector/JSJavaScriptCallFrame.h:
        * inspector/JSJavaScriptCallFrame.cpp:
        (Inspector::JSJavaScriptCallFrame::scopeType):
        Set the new value for the new scope type.

        * inspector/JSJavaScriptCallFramePrototype.cpp:
        (Inspector::JSJavaScriptCallFramePrototype::finishCreation): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantGLOBAL_SCOPE): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantLOCAL_SCOPE): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantWITH_SCOPE): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantCLOSURE_SCOPE): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantCATCH_SCOPE): Deleted.
        (Inspector::jsJavaScriptCallFrameConstantFUNCTION_NAME_SCOPE): Deleted.
        Remove unused constants on the JavaScriptCallFrame object.
        Currently they are just hardcoded in InjectedScriptSource
        and they don't make sense on instances anyways.

2015-12-04  Keith Miller  <keith_miller@apple.com>

        Add an option to emit instructions validating exceptions in the DFG rather than always emiting them.
        https://bugs.webkit.org/show_bug.cgi?id=151841

        Reviewed by Saam Barati.

        Add a new option that validates the DFG execption checking. The default value for the option is
        true in Debug builds and false in Release builds. Additionally, renamed jitAssertNoException to
        jitReleaseAssertNoException for consistency with our ASSERT naming convention.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::jitReleaseAssertNoException):
        (JSC::AssemblyHelpers::jitAssertNoException): Deleted.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::jitAssertNoException): Deleted.
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2015-12-04  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the !ENABLE(DFG_JIT) build after r190735
        https://bugs.webkit.org/show_bug.cgi?id=151617

        Reviewed by Filip Pizlo.

        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):

2015-12-04  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Fix the B3 build after r192946
        https://bugs.webkit.org/show_bug.cgi?id=151857

        Reviewed by Michael Saboff.

        * CMakeLists.txt:

2015-12-04  Csaba Osztrogonác  <ossy@webkit.org>

        [AArch64] Typo fix after r189575
        https://bugs.webkit.org/show_bug.cgi?id=151855

        Reviewed by Michael Saboff.

        * ftl/FTLUnwindInfo.cpp:
        (JSC::FTL::parseUnwindInfo):

2015-12-03  Filip Pizlo  <fpizlo@apple.com>

        B3 Patchpoint and Check opcodes should be able to specify WarmAny, ColdAny, and LateColdAny
        https://bugs.webkit.org/show_bug.cgi?id=151335

        Reviewed by Geoffrey Garen.

        This removes ValueRep::Any and replaces it with ValueRep::WarmAny, ValueRep::ColdAny, and
        ValueRep::LateColdAny. I think that conceptually the most obvious users of patchpoints are inline
        caches, which would use WarmAny for their non-OSR inputs. For this reason, I make WarmAny the
        default.

        However, the StackmapValue optimization that provides a default ValueRep for any that are missing
        was meant for OSR. So, this optimization now uses ColdAny.

        This patch wires this change through the whole compiler and adds some tests.

        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::Key::Key):
        (JSC::B3::CheckSpecial::Key::dump):
        (JSC::B3::CheckSpecial::CheckSpecial):
        * b3/B3CheckSpecial.h:
        (JSC::B3::CheckSpecial::Key::Key):
        (JSC::B3::CheckSpecial::Key::opcode):
        (JSC::B3::CheckSpecial::Key::numArgs):
        (JSC::B3::CheckSpecial::Key::stackmapRole):
        * b3/B3CheckValue.cpp:
        (JSC::B3::CheckValue::CheckValue):
        * b3/B3ConstrainedValue.h:
        (JSC::B3::ConstrainedValue::ConstrainedValue):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::fillStackmap):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3MoveConstants.cpp:
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::forEachArg):
        (JSC::B3::PatchpointSpecial::isValid):
        (JSC::B3::PatchpointSpecial::admitsStack):
        * b3/B3PatchpointValue.cpp:
        (JSC::B3::PatchpointValue::PatchpointValue):
        * b3/B3PatchpointValue.h:
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::admitsStackImpl):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        (WTF::printInternal):
        * b3/B3StackmapSpecial.h:
        * b3/B3StackmapValue.cpp:
        (JSC::B3::StackmapValue::append):
        (JSC::B3::StackmapValue::setConstraint):
        * b3/B3StackmapValue.h:
        * b3/B3Validate.cpp:
        * b3/B3ValueRep.cpp:
        (JSC::B3::ValueRep::dump):
        (WTF::printInternal):
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::ValueRep):
        (JSC::B3::ValueRep::reg):
        (JSC::B3::ValueRep::operator!=):
        (JSC::B3::ValueRep::operator bool):
        (JSC::B3::ValueRep::isAny):
        (JSC::B3::ValueRep::isSomeRegister):
        * b3/testb3.cpp:
        (JSC::B3::compileAndRun):
        (JSC::B3::add32):
        (JSC::B3::test42):
        (JSC::B3::testSimplePatchpoint):
        (JSC::B3::testPatchpointWithEarlyClobber):
        (JSC::B3::testPatchpointFixedRegister):
        (JSC::B3::testPatchpointAny):
        (JSC::B3::testPatchpointLotsOfLateAnys):
        (JSC::B3::testPatchpointAnyImm):
        (JSC::B3::testPatchpointManyImms):
        (JSC::B3::testPatchpointWithRegisterResult):
        (JSC::B3::testPatchpointWithAnyResult):
        (JSC::B3::run):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):

2015-12-03  Filip Pizlo  <fpizlo@apple.com>

        B3 patchpoints should allow specifying output constraints
        https://bugs.webkit.org/show_bug.cgi?id=151809

        Reviewed by Benjamin Poulain.

        JS call patchpoints should put their result into the result register, while most other patchpoints
        should put their results into some register. I think that it's best if we just allow arbitrary
        constraints on the result of a patchpoint. And by "arbitrary" I mean allowing the same kinds of
        constraints as we allow on the stackmap children.

        This also adds a large comment in B3StackmapValue.h that lays out the philosophy of our stackmaps
        and patchpoints. I found it useful to write down the plan since it's pretty subtle.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::isValid):
        (JSC::B3::PatchpointSpecial::admitsStack):
        * b3/B3PatchpointValue.cpp:
        (JSC::B3::PatchpointValue::~PatchpointValue):
        (JSC::B3::PatchpointValue::dumpMeta):
        (JSC::B3::PatchpointValue::PatchpointValue):
        * b3/B3PatchpointValue.h:
        (JSC::B3::PatchpointValue::accepts):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::code):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::isValidImpl):
        (JSC::B3::StackmapSpecial::appendRepsImpl):
        (JSC::B3::StackmapSpecial::isArgValidForValue):
        (JSC::B3::StackmapSpecial::isArgValidForRep):
        (JSC::B3::StackmapSpecial::repForArg):
        * b3/B3StackmapSpecial.h:
        * b3/B3StackmapValue.h:
        * b3/B3Validate.cpp:
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::doubleValue):
        * b3/testb3.cpp:
        (JSC::B3::testPatchpointManyImms):
        (JSC::B3::testPatchpointWithRegisterResult):
        (JSC::B3::testPatchpointWithStackArgumentResult):
        (JSC::B3::testPatchpointWithAnyResult):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::run):
        * jit/RegisterSet.h:

2015-12-03  Anders Carlsson  <andersca@apple.com>

        Remove Objective-C GC support
        https://bugs.webkit.org/show_bug.cgi?id=151819
        rdar://problem/23746991

        Reviewed by Dan Bernstein.

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

2015-12-03  Benjamin Poulain  <bpoulain@apple.com>

        Attempt to fix GTK again after r193125

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::supportsLZCNT):

2015-12-03  Benjamin Poulain  <bpoulain@apple.com>

        Attempt to fix GTK after r193125

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::supportsLZCNT):
        GCC is unable to handle EBX correctly when clobbered by inline asm.

2015-12-03  Saam barati  <sbarati@apple.com>

        FTL::OSRExitDescriptor should use less memory by having a companion object that dies after compilation
        https://bugs.webkit.org/show_bug.cgi?id=151795

        Reviewed by Geoffrey Garen.

        There were a few fields on FTL::OSRExitDescriptor that are only
        needed during compilation. This patch introduces OSRExitDescriptorImpl 
        which is a struct that we create for each OSRExitDescriptor. The difference is 
        that OSRExitDescriptorImpl lives off of FTL::State so it dies after we compile.
        This way no unnecessary fields persist after the compilation.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExceptionHandlerManager.cpp:
        (JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::getCallOSRExitCommon):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
        (JSC::FTL::OSRExitDescriptor::validateReferences):
        (JSC::FTL::OSRExitDescriptor::emitOSRExit):
        (JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
        (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        (JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):
        (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
        (JSC::FTL::exceptionTypeWillArriveAtOSRExitFromGenericUnwind):
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromGenericUnwind):
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
        (JSC::FTL::OSRExitDescriptor::isExceptionHandler): Deleted.
        * ftl/FTLOSRExit.h:
        (JSC::FTL::OSRExitDescriptorImpl::OSRExitDescriptorImpl):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLState.h:

2015-12-03  Alex Christensen  <achristensen@webkit.org>

        Fix 64-bit Windows build after r193125.
        https://bugs.webkit.org/show_bug.cgi?id=151799

        Reviewed by Michael Saboff.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::supportsLZCNT):
        Use __cpuid intrinsic instead of inline assembly.

2015-12-02  Filip Pizlo  <fpizlo@apple.com>

        FTL B3 should support OSR exit
        https://bugs.webkit.org/show_bug.cgi?id=151710

        Reviewed by Saam Barati.

        This adds OSR exit support using the same style that I established with lazy slow paths. All of
        the work is driven by FTL::LowerDFGToLLVM, and from there any work that needs to be deferred
        until after B3 finishes is attached to the stackmap generator. In order to make it easy to port
        all of the different forms of OSR exit - invalidation points, exceptions, etc. - the logic for
        registering an OSR exit is abstracted behind OSRExitDescriptor and OSRExitHandle.

        An issue that I encountered repeatedly in this patch is OSRExitDescriptor being passed as a
        reference (&) rather than pointer (*). The new code uses a lot of lambdas that run after the
        current frame pops, so the capture list cannot be [&]. I believe that always listing all of the
        captured variables is not scalable considering how sophisticated our use of lambdas is. So, it
        makes sense to use [=]. But anytime we captured a variable whose type was OSRExitDescriptor&, it
        would be captured by value, because that's how references work. One has to be mindful of these
        things whenever using [=]. Note that it's not enough to say that we should have listed the
        captured variables explicitly - in that case, we still could have made the mistake by forgetting
        to put & in front of the variant. The pattern that worked for me to reason about whether I'm
        capturing an object or a pointer to an object is to always use pointer types for pointers: either
        RefPtr<> when we also want the lambda to prolong the object's life, or * if we are confident that
        the object will stay alive. For this reason, this patch changes all code that references
        OSRExitDescriptor to use * instead of &. Consistency makes the code easier to grok, and it made
        it easier to introduce the required uses of * in places where there were lambdas.

        I tested this by running imaging-gaussian-blur, and running some tests that reqiure OSR exit. I'm
        not promising that all kinds of exits work, but we have to begin somewhere.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Compilation.cpp:
        (JSC::B3::Compilation::Compilation):
        (JSC::B3::Compilation::~Compilation):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addDataSection):
        (JSC::B3::Procedure::frameSize):
        (JSC::B3::Procedure::calleeSaveRegisters):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::releaseByproducts):
        (JSC::B3::Procedure::code):
        (JSC::B3::Procedure::takeByproducts): Deleted.
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::setFrameSize):
        (JSC::B3::Air::Code::calleeSaveRegisters):
        * b3/air/AirGenerationContext.h:
        * ftl/FTLB3Compile.cpp:
        (JSC::FTL::compile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExceptionHandlerManager.cpp:
        (JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::getCallOSRExitCommon):
        * ftl/FTLExitThunkGenerator.cpp:
        * ftl/FTLExitThunkGenerator.h:
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::JITCode):
        (JSC::FTL::JITCode::initializeB3Code):
        (JSC::FTL::JITCode::initializeB3Byproducts):
        (JSC::FTL::JITCode::initializeExitThunks):
        (JSC::FTL::JITCode::validateReferences):
        (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * ftl/FTLJITCode.h:
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h:
        * ftl/FTLJSCall.cpp:
        (JSC::FTL::JSCall::emit):
        * ftl/FTLJSCallBase.cpp:
        (JSC::FTL::JSCallBase::emit):
        * ftl/FTLJSTailCall.cpp:
        (JSC::FTL::JSTailCall::JSTailCall):
        (JSC::FTL::JSTailCall::emit):
        (JSC::FTL::DFG::getRegisterWithAddend): Deleted.
        (JSC::FTL::m_instructionOffset): Deleted.
        * ftl/FTLJSTailCall.h:
        (JSC::FTL::JSTailCall::patchpoint):
        (JSC::FTL::JSTailCall::stackmapID):
        (JSC::FTL::JSTailCall::estimatedSize):
        (JSC::FTL::JSTailCall::operator<):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):
        (JSC::FTL::lowerDFGToLLVM):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
        (JSC::FTL::OSRExitDescriptor::validateReferences):
        (JSC::FTL::OSRExitDescriptor::appendOSRExit):
        (JSC::FTL::OSRExitDescriptor::appendOSRExitLater):
        (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        (JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):
        (JSC::FTL::OSRExit::spillRegistersToSpillSlot):
        (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
        (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
        * ftl/FTLOSRExit.h:
        (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
        * ftl/FTLOSRExitCompilationInfo.h:
        (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::reboxAccordingToFormat):
        (JSC::FTL::compileRecovery):
        (JSC::FTL::compileStub):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLOSRExitHandle.cpp: Added.
        (JSC::FTL::OSRExitHandle::emitExitThunk):
        * ftl/FTLOSRExitHandle.h: Added.
        (JSC::FTL::OSRExitHandle::OSRExitHandle):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        (JSC::FTL::State::~State):

2015-12-03  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION:(r192753): Remote Web Inspector: RemoteInspector::sendMessageToRemote with null connection
        https://bugs.webkit.org/show_bug.cgi?id=151789

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::sendMessageToRemote):
        Bail if the connection is no longer available. It may have
        been closed remotely.

2015-12-03  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION:(r192753): Remote Web Inspector: Window immediately closes after opening
        https://bugs.webkit.org/show_bug.cgi?id=151788

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::pushListingsNow):
        The key at the outer level was not a string. Ensure it is a
        string for backwards compatibility. One day we may use
        non-numeric page identifiers as listing keys.

2015-12-03  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(r192753): Remote Web Inspector: Enabling Remote Inspection on Auto Inspect candidate Debuggable doesn't show up in debuggers
        https://bugs.webkit.org/show_bug.cgi?id=151792

        Reviewed by Brian Burg.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        When m_debuggablesMap was split into both m_targetMap and m_listingMap
        this particular case was missed in updating both the target and listing
        when the target is updated. We should match RemoteInspector::updateTarget
        and update the listing map as the debuggable may have changed to be
        allowed to debug.

2015-12-03  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add CLZ support to B3
        https://bugs.webkit.org/show_bug.cgi?id=151799

        Reviewed by Michael Saboff.

        Previously we were counting on LLVM to select LZCNT
        when its available.
        Since we have to do that ourself now, I added feature
        detection based on the CPUID. The MacroAssembler just
        pick the best available lowering based on the platform.

        * assembler/MacroAssemblerX86Common.cpp:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::countLeadingZeros32):
        (JSC::MacroAssemblerX86Common::supportsLZCNT):
        (JSC::MacroAssemblerX86Common::clz32AfterBsr):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::countLeadingZeros64):
        (JSC::MacroAssemblerX86_64::clz64AfterBsr):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::lzcnt_rr):
        (JSC::X86Assembler::lzcnt_mr):
        (JSC::X86Assembler::lzcntq_rr):
        (JSC::X86Assembler::lzcntq_mr):
        (JSC::X86Assembler::bsr_mr):
        (JSC::X86Assembler::bsrq_rr):
        (JSC::X86Assembler::bsrq_mr):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::countLeadingZero):
        (JSC::B3::testClzArg64):
        (JSC::B3::testClzMem64):
        (JSC::B3::testClzArg32):
        (JSC::B3::testClzMem32):
        (JSC::B3::doubleOperands):
        (JSC::B3::run):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::ctlz32):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithClz32):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::ctlz32):

2015-12-02  Mark Lam  <mark.lam@apple.com>

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

        Reviewed by Filip Pizlo.

        Perf on benchmarks is neutral except for the newly added JSRegress ftl-object-mul
        test which shows a 2.16x speed up on x86_64 FTL, 1.27x speed up on x86_64 DFG,
        and 1.56x on x86 DFG. 

        The speed up comes not from the mul operator itself, but from the fact that the
        polymorphic operand types support now allow the test function to run without OSR
        exiting, thereby realizing the DFG and FTL's speed up on other work that the test
        function does.

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

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithMul):
        * ftl/FTLCompile.cpp:
        - Changed to call generateBinaryOpFastPath() instead now, and let it dispatch to
          the appropriate snippet generator.

        * ftl/FTLCompileBinaryOp.cpp:
        (JSC::FTL::generateBinaryArithOpFastPath):
        (JSC::FTL::generateBinaryOpFastPath):
        (JSC::FTL::generateArithSubFastPath): Deleted.
        (JSC::FTL::generateValueAddFastPath): Deleted.
        - Refactored these functions to eliminate the need for copy-pasting every time
          we add support for another binary arithmetic snippet.

        * ftl/FTLCompileBinaryOp.h:
        * ftl/FTLInlineCacheDescriptor.h:
        * ftl/FTLInlineCacheDescriptorInlines.h:
        (JSC::FTL::ArithMulDescriptor::ArithMulDescriptor):
        (JSC::FTL::ArithMulDescriptor::icSize):
        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfArithMul):
        * ftl/FTLInlineCacheSize.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::JITMulGenerator):

        * tests/stress/op_mul.js:
        - Updated a test value: the interesting value for imminent overflow from an
          int32 is 0x7fffffff, not 0x7ffffff.

2015-12-02  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(r192753): Remote Web Inspector: Applications and Debuggables not showing up in debuggers
        https://bugs.webkit.org/show_bug.cgi?id=151787

        Reviewed by Brian Burg.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::receivedIndicateMessage):
        Removed lock that was unnecessarily added in r192753. It was
        protecting nothing.

2015-12-02  Saam barati  <sbarati@apple.com>

        Insert a FIXME comment FTLLazySlowPath.h to remind us to remove/refactor the ScratchRegisterAllocator field.

        Rubber-stamped by Filip Pizlo.

        * ftl/FTLLazySlowPath.h:

2015-12-02  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Remove insertElement() from FTLB3Output
        https://bugs.webkit.org/show_bug.cgi?id=151781

        Reviewed by Sam Weinig.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::insertElement): Deleted.
        That's a LLVM concept.

2015-12-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove stuffs related to alloca from FTLB3Output
        https://bugs.webkit.org/show_bug.cgi?id=151780

        Reviewed by Mark Lam.

        We can use the Phis directly with B3 :)

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::alloca): Deleted.
        (JSC::FTL::Output::get): Deleted.
        (JSC::FTL::Output::set): Deleted.

2015-12-02  Benjamin Poulain  <benjamin@webkit.org>

        [JSC] Add sin(), cos(), pow() and log() to B3
        https://bugs.webkit.org/show_bug.cgi?id=151778

        Reviewed by Geoffrey Garen.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleSin):
        (JSC::FTL::Output::doubleCos):
        (JSC::FTL::Output::doublePow):
        (JSC::FTL::Output::doubleLog):
        (JSC::FTL::Output::callWithoutSideEffects):

2015-12-02  Filip Pizlo  <fpizlo@apple.com>

        Add a few obvious strength-reductions to Air
        https://bugs.webkit.org/show_bug.cgi?id=151777

        Reviewed by Mark Lam.

        The absence of these optimizations was obnoxious.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::add32): lea 1(reg), reg -> add 1, reg.
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate): Emit simpler prologue/epilogue if !frameSize.
        * b3/air/AirOpcode.opcodes: We have matching for BranchMul32 with immediate, but we forgot to add the instruction form.
        * jit/AssemblyHelpers.h: Support for the prologue/epilogue optimizations.
        (JSC::AssemblyHelpers::emitFunctionPrologue):
        (JSC::AssemblyHelpers::emitFunctionEpilogueWithEmptyFrame):
        (JSC::AssemblyHelpers::emitFunctionEpilogue):

2015-12-02  Benjamin Poulain  <bpoulain@apple.com>

        Update the interface added in r192967

        * b3/B3CCallValue.h:
        Filip prefers explicit effects.
        * b3/testb3.cpp:
        (JSC::B3::testCallSimplePure):

2015-12-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add a function attribute for Pure functions in B3
        https://bugs.webkit.org/show_bug.cgi?id=151741

        Reviewed by Geoffrey Garen.

        We have plenty of functions without side effects
        when lowering DFG.
        This patch adds the "PureCall" flag to B3's CCall
        to make sure those functions do not prevent optimizations.

        * b3/B3CCallValue.h:
        * b3/testb3.cpp:
        (JSC::B3::testCallSimplePure):
        (JSC::B3::run):

2015-12-02  Mark Lam  <mark.lam@apple.com>

        Removed unnecessary #if USE(JSVALUE64).
        https://bugs.webkit.org/show_bug.cgi?id=151733

        Not reviewed.

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

2015-12-02  Mark Lam  <mark.lam@apple.com>

        Use the JITAddGenerator snippet in the FTL.
        https://bugs.webkit.org/show_bug.cgi?id=151519

        Reviewed by Geoffrey Garen.

        One detail about how we choosing to handle operands to the binary snippets that
        may be constant: the slow path call to a C++ function still needs the constant
        operand loaded in a register.  To simplify things, we're choosing to always tell
        LLVM to load the operands into registers even if they may be constant.  However,
        even though a constant operand is preloaded in a register, the snippet generator
        will not be made aware of it.  It will continue to load the constant as an
        immediate.

        * ftl/FTLCompile.cpp:
        * ftl/FTLCompileBinaryOp.cpp:
        (JSC::FTL::generateArithSubFastPath):
        (JSC::FTL::generateValueAddFastPath):
        - generateValueAddFastPath() currently is an exact copy of generateArithSubFastPath()
          except that it uses JITAddGenerator instead of JITSubGenerator.  When we add
          support for JITMulGenerator later, the code will start to vary.  We'll refactor
          these functions then when we have more insight into what needs to vary between
          the implementations.

        * ftl/FTLCompileBinaryOp.h:
        * ftl/FTLInlineCacheDescriptor.h:
        * ftl/FTLInlineCacheDescriptorInlines.h:
        (JSC::FTL::ValueAddDescriptor::ValueAddDescriptor):
        (JSC::FTL::ValueAddDescriptor::icSize):
        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfValueAdd):
        * ftl/FTLInlineCacheSize.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):

2015-12-02  Mark Lam  <mark.lam@apple.com>

        Teach DFG that ArithSub can now clobber the heap (and other things).
        https://bugs.webkit.org/show_bug.cgi?id=151733

        Reviewed by Geoffrey Garen.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):

2015-12-02  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Handle x86 partial register stalls in Air
        https://bugs.webkit.org/show_bug.cgi?id=151735

        Reviewed by Filip Pizlo.

        This patch adds a primitive false-dependency breaking
        algorithm to Air. We look for redefinition of the same
        variable that is too close to a partial definition.

        There is not explicit dependency tracking going on,
        but it is pretty fast and the extra xorps added on false-positives
        are cheap anyway.

        Typically, partial register stalls appear from instructions
        interfering with themselves in small loops. Something like:

          Label0:
            cvtsi2sdq %eax, %xmm0
            ...
            jmp Label0

        Those are correctly detected by propagating the local distance
        information from block to block until no unsafe chain is found.

        The test testInt32ToDoublePartialRegisterStall() checks the kind
        of cases we typically find from JavaScript.
        The execution time is 20% faster with a register reset (which is
        astounding since the very next instruction has a real dependency).

        Future tweaks will be needed when we can run more JavaScript:
        -Handle function calls differently.
        -Anything with a special can have hidden instructions.
         We need to take them into account.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::moveZeroToDouble):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::xorps_rr):
        (JSC::X86Assembler::xorpd_rr):
        According to the documentation, starting with Sandy Bridge,
        registers reset can be done in the frontend with xorps.

        * b3/B3IndexSet.h:
        (JSC::B3::IndexSet::remove):
        * b3/air/AirFixPartialRegisterStalls.cpp: Added.
        (JSC::B3::Air::fixPartialRegisterStalls):
        * b3/air/AirFixPartialRegisterStalls.h: Added.
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        * b3/testb3.cpp:
        (JSC::B3::testInt32ToDoublePartialRegisterStall):
        (JSC::B3::run):
        * jit/FPRInfo.h:

2015-12-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement LLInt/Baseline Support for ES6 Generators and enable this feature
        https://bugs.webkit.org/show_bug.cgi?id=150792

        Reviewed by Saam Barati.

        This patch implements basic functionality of ES6 Generators in LLInt and Baseline tiers.
        While the implementation has some inefficient part, the implementation covers edge cases.
        Later, we will make this efficient.

            https://bugs.webkit.org/show_bug.cgi?id=151545
            https://bugs.webkit.org/show_bug.cgi?id=151546
            https://bugs.webkit.org/show_bug.cgi?id=151547
            https://bugs.webkit.org/show_bug.cgi?id=151552
            https://bugs.webkit.org/show_bug.cgi?id=151560
            https://bugs.webkit.org/show_bug.cgi?id=151586

        To encourage DFG / FTL later, we take the following design.

        1. Use switch_imm to jump to the save/resume points.

        Instead of saving / restoring instruction pointer to resume from it, we use switch_imm to jump to the resume point.
        This limits one entry point to a given generator function. This design makes inlining easy.
        The generated code becomes the following.

            function @generatorNext(@generator, @generatorState, @generatorValue, @generatorResumeMode)
            {
                switch (@generatorState) {
                case Initial:
                    ...
                    initial sequence.
                    ...


                    op_save(Yield_0);  // op_save contains *virtual* jump to Yield_0.
                                       // CFG shows a jump edge to Yield_0 point, but it won't be actually used.
                    return ...;

                case Yield_0:
                    op_resume();
                    if (@generatorResumeMode == Throw)
                        ...
                    else if (@generatorResumeMode == Return)
                        ...
                    ...
                    // sentValue is a value sent from a caller by `generator.next(sentValue)`.
                    sentValue = @generatorValue;
                    ...
                    op_save(Yield_1);
                    return ...;

                case Yield_1:
                    op_resume();
                    if (@generatorResumeMode == Throw)
                        ...
                    else if (@generatorResumeMode == Return)
                        ...
                    ...
                    sentValue = @generatorValue;
                    ...

                ...
                }
            }

            Resume sequence should not be emitted per yield.
            This should be done in https://bugs.webkit.org/show_bug.cgi?id=151552.

        2. Store live frame registers to GeneratorFrame

        To save and resume generator's state, we save all the live registers in GeneratorFrame.
        And when resuming, we refill registers with saved ones.
        Since saved register contains scope register, |this| etc., the environment including the scope chain will be recovered automatically.
        While saving and resuming callee registers, we don't save parameter registers.
        These registers will be used to control generator's resume behavior.

        We perform BytecodeLivenessAnalysis in CodeBlock to determine actually *def*ined registers at that resume point.

        3. GeneratorFunction will evaluate parameters before generating Generator

        Generator's parameter should be evaluated before entering Generator's body. For example,

            function hello() { ... }
            function *gen(a, b = hello())
            {
                yield b;
            }
            let g = gen(20);  // Now, hello should be called.

        To enable this, we evaluate parameters in GeneratorFunction, and after that, we create a Generator and return it.
        This can be explained by the following pseudo code.

            function *gen(a, b = hello())
            {
                // This is generator.
                return {
                    @generatorNext: function (@generator, @generatorState, @generatorValue, @generatorResumeMode)
                    {
                        ...
                    }
                }
            }

        4. op_save seems similar to conditional jump

        We won't jump to elsewhere from op_save actually. But we add a *virtual* jump edge (flow) from op_save to the point so called *merge point*.
        We construct the CFG as follows,

            (global generator switch) -> (initial sequence) -> (op_save) ----+-> (merge point) -> (next sequence)*
                   |                                              |          |
                   |                                              v          |
                   |                                           (op_ret)      |
                   |                                                         |
                   +------------------------------------------->(op_resume)--+

        By constructing such a graph,

            1. Since we have a flow from (op_save) to (merge point), at merge point, we can *use* locals that are defined before (op_save)
            2. op_save should claim that it does not define anything. And claim that it *use*s locals that are used in (merge point).
            3. at op_resume, we see *use*d locals at merge point and define all of them.

        We can do the above things in use-def analysis because use-def analysis is backward analysis.
        And after analyzing use-def chains, in op_save / op_resume, we only save / resume live registers at the head of merge point.

        * API/JSScriptRef.cpp:
        (parseScript):
        * CMakeLists.txt:
        * Configurations/FeatureDefines.xcconfig:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * builtins/GeneratorPrototype.js: Added.
        (generatorResume):
        (next):
        (return):
        (throw):
        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::isBranch):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::stepOverInstruction):
        (JSC::computeLocalLivenessForBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        (JSC::BytecodeLivenessAnalysis::computeKills):
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::validate):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numCalleeLocals):
        (JSC::CodeBlock::liveCalleeLocalsAtYield):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        (JSC::EvalCodeCache::isCacheable):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::generatorThisMode):
        (JSC::ExecutableInfo::superBinding):
        (JSC::ExecutableInfo::parseMode):
        (JSC::ExecutableInfo::isArrowFunction): Deleted.
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::parseMode):
        (JSC::UnlinkedCodeBlock::generatorThisMode):
        (JSC::UnlinkedCodeBlock::superBinding):
        (JSC::UnlinkedCodeBlock::isArrowFunction): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeParameters):
        (JSC::BytecodeGenerator::newRegister):
        (JSC::BytecodeGenerator::reclaimFreeRegisters):
        (JSC::BytecodeGenerator::createVariable):
        (JSC::BytecodeGenerator::emitCreateThis):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewFunctionExpression):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitIteratorNextWithValue):
        (JSC::BytecodeGenerator::emitYieldPoint):
        (JSC::BytecodeGenerator::emitSave):
        (JSC::BytecodeGenerator::emitResume):
        (JSC::BytecodeGenerator::emitYield):
        (JSC::BytecodeGenerator::emitDelegateYield):
        (JSC::BytecodeGenerator::emitGeneratorStateChange):
        (JSC::BytecodeGenerator::emitGeneratorStateLabel):
        (JSC::BytecodeGenerator::beginGenerator):
        (JSC::BytecodeGenerator::endGenerator):
        (JSC::BytecodeGenerator::emitNewFunctionInternal): Deleted.
        (JSC::BytecodeGenerator::emitNewFunctionCommon): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::generatorThisMode):
        (JSC::BytecodeGenerator::superBinding):
        (JSC::BytecodeGenerator::generatorRegister):
        (JSC::BytecodeGenerator::generatorStateRegister):
        (JSC::BytecodeGenerator::generatorValueRegister):
        (JSC::BytecodeGenerator::generatorResumeModeRegister):
        (JSC::BytecodeGenerator::parseMode):
        (JSC::BytecodeGenerator::registerFor):
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::emitHomeObjectForCallee):
        (JSC::emitSuperBaseForCallee):
        (JSC::ReturnNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        (JSC::YieldExprNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::ByteCodeParser):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKilledOperands):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * ftl/FTLForOSREntryJITCode.cpp:
        (JSC::FTL::ForOSREntryJITCode::initializeEntryBuffer):
        * ftl/FTLForOSREntryJITCode.h:
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::isAtom):
        (JSC::MarkedBlock::isLiveCell):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        (JSC::Interpreter::dumpRegisters):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::frameRegisterCountFor):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncCommon):
        (JSC::JIT::emit_op_new_func):
        (JSC::JIT::emit_op_new_generator_func):
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_func_exp):
        (JSC::JIT::emit_op_new_generator_func_exp):
        (JSC::JIT::emit_op_save):
        (JSC::JIT::emit_op_resume):
        * jit/JITOperations.cpp:
        (JSC::operationNewFunctionCommon):
        * jit/JITOperations.h:
        * llint/LLIntEntrypoint.cpp:
        (JSC::LLInt::frameRegisterCountFor):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::traceFunctionPrologue):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createYield):
        (JSC::ASTBuilder::createFunctionMetadata):
        (JSC::ASTBuilder::propagateArgumentsUse):
        * parser/Nodes.cpp:
        (JSC::FunctionMetadataNode::FunctionMetadataNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::createGeneratorParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseYieldExpression):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseFunctionExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setSourceParseMode):
        (JSC::Scope::hasArguments):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::setIsFunction):
        (JSC::Scope::setIsGeneratorFunction):
        (JSC::Scope::setIsGenerator):
        (JSC::parse):
        * parser/ParserModes.h:
        (JSC::isFunctionParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        * parser/SourceCodeKey.h: Added.
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::isHashTableDeletedValue):
        (JSC::SourceCodeKey::hash):
        (JSC::SourceCodeKey::length):
        (JSC::SourceCodeKey::isNull):
        (JSC::SourceCodeKey::string):
        (JSC::SourceCodeKey::operator==):
        (JSC::SourceCodeKeyHash::hash):
        (JSC::SourceCodeKeyHash::equal):
        (JSC::SourceCodeKeyHashTraits::isEmptyValue):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createYield):
        (JSC::SyntaxChecker::createFunctionMetadata):
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        (JSC::SourceCodeKey::SourceCodeKey): Deleted.
        (JSC::SourceCodeKey::isHashTableDeletedValue): Deleted.
        (JSC::SourceCodeKey::hash): Deleted.
        (JSC::SourceCodeKey::length): Deleted.
        (JSC::SourceCodeKey::isNull): Deleted.
        (JSC::SourceCodeKey::string): Deleted.
        (JSC::SourceCodeKey::operator==): Deleted.
        (JSC::SourceCodeKeyHash::hash): Deleted.
        (JSC::SourceCodeKeyHash::equal): Deleted.
        (JSC::SourceCodeKeyHashTraits::isEmptyValue): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * runtime/GeneratorFrame.cpp: Added.
        (JSC::GeneratorFrame::GeneratorFrame):
        (JSC::GeneratorFrame::finishCreation):
        (JSC::GeneratorFrame::createStructure):
        (JSC::GeneratorFrame::create):
        (JSC::GeneratorFrame::save):
        (JSC::GeneratorFrame::resume):
        (JSC::GeneratorFrame::visitChildren):
        * runtime/GeneratorFrame.h: Added.
        (JSC::GeneratorFrame::locals):
        (JSC::GeneratorFrame::localAt):
        (JSC::GeneratorFrame::offsetOfLocals):
        (JSC::GeneratorFrame::allocationSizeForLocals):
        * runtime/GeneratorFunctionConstructor.cpp: Added.
        (JSC::GeneratorFunctionConstructor::GeneratorFunctionConstructor):
        (JSC::GeneratorFunctionConstructor::finishCreation):
        (JSC::callGeneratorFunctionConstructor):
        (JSC::constructGeneratorFunctionConstructor):
        (JSC::GeneratorFunctionConstructor::getCallData):
        (JSC::GeneratorFunctionConstructor::getConstructData):
        * runtime/GeneratorFunctionConstructor.h: Added.
        (JSC::GeneratorFunctionConstructor::create):
        (JSC::GeneratorFunctionConstructor::createStructure):
        * runtime/GeneratorFunctionPrototype.cpp: Added.
        (JSC::GeneratorFunctionPrototype::GeneratorFunctionPrototype):
        (JSC::GeneratorFunctionPrototype::finishCreation):
        * runtime/GeneratorFunctionPrototype.h: Added.
        (JSC::GeneratorFunctionPrototype::create):
        (JSC::GeneratorFunctionPrototype::createStructure):
        * runtime/GeneratorPrototype.cpp: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
        (JSC::GeneratorPrototype::finishCreation):
        (JSC::GeneratorPrototype::getOwnPropertySlot):
        * runtime/GeneratorPrototype.h: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
        (JSC::GeneratorPrototype::create):
        (JSC::GeneratorPrototype::createStructure):
        (JSC::GeneratorPrototype::GeneratorPrototype):
        * runtime/GeneratorThisMode.h: Added.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGeneratorFunction.cpp: Added.
        (JSC::JSGeneratorFunction::JSGeneratorFunction):
        (JSC::JSGeneratorFunction::createImpl):
        (JSC::JSGeneratorFunction::create):
        (JSC::JSGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
        * runtime/JSGeneratorFunction.h: Added.
        (JSC::JSGeneratorFunction::allocationSize):
        (JSC::JSGeneratorFunction::createStructure):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::generatorFunctionPrototype):
        (JSC::JSGlobalObject::generatorPrototype):
        (JSC::JSGlobalObject::generatorFunctionStructure):
        * runtime/ModuleLoaderObject.cpp:
        (JSC::moduleLoaderObjectParseModule):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * tests/es6.yaml:
        * tests/es6/generators_yield_star_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_instances_of_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_iterator_closing_via_throw.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/stress/generator-arguments-from-function.js: Added.
        (shouldBe):
        (test):
        * tests/stress/generator-arguments.js: Added.
        (shouldBe):
        (g1):
        * tests/stress/generator-class-methods-syntax.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntaxError.Cocoa):
        (testSyntax.Cocoa.prototype.ok):
        (testSyntax.Cocoa):
        (testSyntax.Cocoa.ok):
        * tests/stress/generator-class-methods.js: Added.
        (shouldBe):
        (prototype.gen):
        (staticGen):
        (shouldBe.g.next):
        * tests/stress/generator-eval-this.js: Added.
        (shouldBe):
        (shouldThrow):
        (B):
        (A):
        (C.prototype.generator):
        (C):
        (TypeError):
        * tests/stress/generator-function-constructor.js: Added.
        (shouldBe):
        (generatorFunctionConstructor):
        * tests/stress/generator-function-name.js: Added.
        (shouldBe):
        (ok):
        * tests/stress/generator-methods-with-non-generator.js: Added.
        (shouldThrow):
        * tests/stress/generator-relations.js: Added.
        (shouldBe):
        (generatorFunction):
        * tests/stress/generator-return-before-first-call.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-return.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-this.js: Added.
        (shouldBe):
        (shouldThrow):
        (gen):
        (shouldBe.g.next):
        * tests/stress/generator-throw-before-first-call.js: Added.
        (unreachable):
        (gen):
        (catch):
        * tests/stress/generator-throw.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-with-new-target.js: Added.
        (shouldBe):
        (gen):
        * tests/stress/generator-with-super.js: Added.
        (shouldThrow):
        (test):
        (B.prototype.gen):
        (B):
        (A.prototype.gen):
        (A):
        * tests/stress/generator-yield-star.js: Added.
        (shouldBe):
        (shouldThrow):
        (prototype.call):
        (Arrays):
        (Arrays.prototype.Symbol.iterator):
        (Iterator.prototype.next):
        (Iterator.prototype.string_appeared_here):
        (Iterator.prototype.Symbol.iterator):
        (Iterator):
        (gen):

2015-12-01  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r192914.
        https://bugs.webkit.org/show_bug.cgi?id=151734

        JSC tests for this change are failing on 32 and 64-bit bots
        (Requested by ryanhaddad on #webkit).

        Reverted changeset:

        "[ES6] Implement LLInt/Baseline Support for ES6 Generators and
        enable this feature"
        https://bugs.webkit.org/show_bug.cgi?id=150792
        http://trac.webkit.org/changeset/192914

2015-12-01  Caitlin Potter  <caitpotter88@gmail.com>

        [JSC] support CoverInitializedName in nested AssignmentPatterns
        https://bugs.webkit.org/show_bug.cgi?id=151595

        Reviewed by Geoffrey Garen.

        A regression introduced in bug https://bugs.webkit.org/show_bug.cgi?id=151026
        causes the parser to fail when attempting to parse nested
        ObjectAssignmentPatterns with CoverInitializedName destructuring targets.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseAssignmentExpressionOrPropagateErrorClass):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parseArrayLiteral):
        * parser/Parser.h:
        (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass):
        * tests/es6.yaml:
        * tests/es6/destructuring_assignment_nested_cover_initialized_name.js: Added.
        (test1):
        (test2):

2015-12-01  Juergen Ributzka  <juergen@apple.com>

        Add new library dependency for LLVMForJavaScriptCore dylib
        https://bugs.webkit.org/show_bug.cgi?id=151687
        
        Changes on open source LLVM added a new dependency to libLLVMInstrumentation.a.
        Adding this dependency should be backwards compatible, since LLVM has built and
        shipped this library even before the creation of FTL.

        Reviewed by Geoffrey Garen.

        * Configurations/LLVMForJSC.xcconfig:

2015-12-01  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement LLInt/Baseline Support for ES6 Generators and enable this feature
        https://bugs.webkit.org/show_bug.cgi?id=150792

        Reviewed by Saam Barati.

        This patch implements basic functionality of ES6 Generators in LLInt and Baseline tiers.
        While the implementation has some inefficient part, the implementation covers edge cases.
        Later, we will make this efficient.

            https://bugs.webkit.org/show_bug.cgi?id=151545
            https://bugs.webkit.org/show_bug.cgi?id=151546
            https://bugs.webkit.org/show_bug.cgi?id=151547
            https://bugs.webkit.org/show_bug.cgi?id=151552
            https://bugs.webkit.org/show_bug.cgi?id=151560
            https://bugs.webkit.org/show_bug.cgi?id=151586

        To encourage DFG / FTL later, we take the following design.

        1. Use switch_imm to jump to the save/resume points.

        Instead of saving / restoring instruction pointer to resume from it, we use switch_imm to jump to the resume point.
        This limits one entry point to a given generator function. This design makes inlining easy.
        The generated code becomes the following.

            function @generatorNext(@generator, @generatorState, @generatorValue, @generatorResumeMode)
            {
                switch (@generatorState) {
                case Initial:
                    ...
                    initial sequence.
                    ...


                    op_save(Yield_0);  // op_save contains *virtual* jump to Yield_0.
                                       // CFG shows a jump edge to Yield_0 point, but it won't be actually used.
                    return ...;

                case Yield_0:
                    op_resume();
                    if (@generatorResumeMode == Throw)
                        ...
                    else if (@generatorResumeMode == Return)
                        ...
                    ...
                    // sentValue is a value sent from a caller by `generator.next(sentValue)`.
                    sentValue = @generatorValue;
                    ...
                    op_save(Yield_1);
                    return ...;

                case Yield_1:
                    op_resume();
                    if (@generatorResumeMode == Throw)
                        ...
                    else if (@generatorResumeMode == Return)
                        ...
                    ...
                    sentValue = @generatorValue;
                    ...

                ...
                }
            }

            Resume sequence should not be emitted per yield.
            This should be done in https://bugs.webkit.org/show_bug.cgi?id=151552.

        2. Store live frame registers to GeneratorFrame

        To save and resume generator's state, we save all the live registers in GeneratorFrame.
        And when resuming, we refill registers with saved ones.
        Since saved register contains scope register, |this| etc., the environment including the scope chain will be recovered automatically.
        While saving and resuming callee registers, we don't save parameter registers.
        These registers will be used to control generator's resume behavior.

        We perform BytecodeLivenessAnalysis in CodeBlock to determine actually *def*ined registers at that resume point.

        3. GeneratorFunction will evaluate parameters before generating Generator

        Generator's parameter should be evaluated before entering Generator's body. For example,

            function hello() { ... }
            function *gen(a, b = hello())
            {
                yield b;
            }
            let g = gen(20);  // Now, hello should be called.

        To enable this, we evaluate parameters in GeneratorFunction, and after that, we create a Generator and return it.
        This can be explained by the following pseudo code.

            function *gen(a, b = hello())
            {
                // This is generator.
                return {
                    @generatorNext: function (@generator, @generatorState, @generatorValue, @generatorResumeMode)
                    {
                        ...
                    }
                }
            }

        4. op_save seems similar to conditional jump

        We won't jump to elsewhere from op_save actually. But we add a *virtual* jump edge (flow) from op_save to the point so called *merge point*.
        We construct the CFG as follows,

            (global generator switch) -> (initial sequence) -> (op_save) ----+-> (merge point) -> (next sequence)*
                   |                                              |          |
                   |                                              v          |
                   |                                           (op_ret)      |
                   |                                                         |
                   +------------------------------------------->(op_resume)--+

        By constructing such a graph,

            1. Since we have a flow from (op_save) to (merge point), at merge point, we can *use* locals that are defined before (op_save)
            2. op_save should claim that it does not define anything. And claim that it *use*s locals that are used in (merge point).
            3. at op_resume, we see *use*d locals at merge point and define all of them.

        We can do the above things in use-def analysis because use-def analysis is backward analysis.
        And after analyzing use-def chains, in op_save / op_resume, we only save / resume live registers at the head of merge point.

        * API/JSScriptRef.cpp:
        (parseScript):
        * CMakeLists.txt:
        * Configurations/FeatureDefines.xcconfig:
        * DerivedSources.make:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * builtins/GeneratorPrototype.js: Added.
        (generatorResume):
        (next):
        (return):
        (throw):
        * bytecode/BytecodeBasicBlock.cpp:
        (JSC::isBranch):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeLivenessAnalysis.cpp:
        (JSC::stepOverInstruction):
        (JSC::computeLocalLivenessForBytecodeOffset):
        (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
        (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
        (JSC::BytecodeLivenessAnalysis::computeKills):
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::shrinkToFit):
        (JSC::CodeBlock::validate):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numCalleeLocals):
        (JSC::CodeBlock::liveCalleeLocalsAtYield):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        (JSC::EvalCodeCache::isCacheable):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::generatorThisMode):
        (JSC::ExecutableInfo::superBinding):
        (JSC::ExecutableInfo::parseMode):
        (JSC::ExecutableInfo::isArrowFunction): Deleted.
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::getJumpTargetsForBytecodeOffset):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::parseMode):
        (JSC::UnlinkedCodeBlock::generatorThisMode):
        (JSC::UnlinkedCodeBlock::superBinding):
        (JSC::UnlinkedCodeBlock::isArrowFunction): Deleted.
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeParameters):
        (JSC::BytecodeGenerator::newRegister):
        (JSC::BytecodeGenerator::reclaimFreeRegisters):
        (JSC::BytecodeGenerator::createVariable):
        (JSC::BytecodeGenerator::emitCreateThis):
        (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
        (JSC::BytecodeGenerator::emitNewFunctionExpression):
        (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitIteratorNextWithValue):
        (JSC::BytecodeGenerator::emitYieldPoint):
        (JSC::BytecodeGenerator::emitSave):
        (JSC::BytecodeGenerator::emitResume):
        (JSC::BytecodeGenerator::emitYield):
        (JSC::BytecodeGenerator::emitDelegateYield):
        (JSC::BytecodeGenerator::emitGeneratorStateChange):
        (JSC::BytecodeGenerator::emitGeneratorStateLabel):
        (JSC::BytecodeGenerator::beginGenerator):
        (JSC::BytecodeGenerator::endGenerator):
        (JSC::BytecodeGenerator::emitNewFunctionInternal): Deleted.
        (JSC::BytecodeGenerator::emitNewFunctionCommon): Deleted.
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::generatorThisMode):
        (JSC::BytecodeGenerator::superBinding):
        (JSC::BytecodeGenerator::generatorRegister):
        (JSC::BytecodeGenerator::generatorStateRegister):
        (JSC::BytecodeGenerator::generatorValueRegister):
        (JSC::BytecodeGenerator::generatorResumeModeRegister):
        (JSC::BytecodeGenerator::parseMode):
        (JSC::BytecodeGenerator::registerFor):
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::emitHomeObjectForCallee):
        (JSC::emitSuperBaseForCallee):
        (JSC::ReturnNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        (JSC::YieldExprNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::ByteCodeParser):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        * dfg/DFGForAllKills.h:
        (JSC::DFG::forAllKilledOperands):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGVariableEventStream.cpp:
        (JSC::DFG::VariableEventStream::reconstruct):
        * ftl/FTLForOSREntryJITCode.cpp:
        (JSC::FTL::ForOSREntryJITCode::initializeEntryBuffer):
        * ftl/FTLForOSREntryJITCode.h:
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::isAtom):
        (JSC::MarkedBlock::isLiveCell):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        (JSC::Interpreter::dumpRegisters):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::frameRegisterCountFor):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncCommon):
        (JSC::JIT::emit_op_new_func):
        (JSC::JIT::emit_op_new_generator_func):
        (JSC::JIT::emitNewFuncExprCommon):
        (JSC::JIT::emit_op_new_func_exp):
        (JSC::JIT::emit_op_new_generator_func_exp):
        (JSC::JIT::emit_op_save):
        (JSC::JIT::emit_op_resume):
        * jit/JITOperations.cpp:
        (JSC::operationNewFunctionCommon):
        * jit/JITOperations.h:
        * llint/LLIntEntrypoint.cpp:
        (JSC::LLInt::frameRegisterCountFor):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::traceFunctionPrologue):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createYield):
        (JSC::ASTBuilder::createFunctionMetadata):
        (JSC::ASTBuilder::propagateArgumentsUse):
        * parser/Nodes.cpp:
        (JSC::FunctionMetadataNode::FunctionMetadataNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
        (JSC::Parser<LexerType>::parseFunctionBody):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::createGeneratorParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseYieldExpression):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseFunctionExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setSourceParseMode):
        (JSC::Scope::hasArguments):
        (JSC::Scope::collectFreeVariables):
        (JSC::Scope::setIsFunction):
        (JSC::Scope::setIsGeneratorFunction):
        (JSC::Scope::setIsGenerator):
        (JSC::parse):
        * parser/ParserModes.h:
        (JSC::isFunctionParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        * parser/SourceCodeKey.h: Added.
        (JSC::SourceCodeKey::SourceCodeKey):
        (JSC::SourceCodeKey::isHashTableDeletedValue):
        (JSC::SourceCodeKey::hash):
        (JSC::SourceCodeKey::length):
        (JSC::SourceCodeKey::isNull):
        (JSC::SourceCodeKey::string):
        (JSC::SourceCodeKey::operator==):
        (JSC::SourceCodeKeyHash::hash):
        (JSC::SourceCodeKeyHash::equal):
        (JSC::SourceCodeKeyHashTraits::isEmptyValue):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createYield):
        (JSC::SyntaxChecker::createFunctionMetadata):
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        (JSC::SourceCodeKey::SourceCodeKey): Deleted.
        (JSC::SourceCodeKey::isHashTableDeletedValue): Deleted.
        (JSC::SourceCodeKey::hash): Deleted.
        (JSC::SourceCodeKey::length): Deleted.
        (JSC::SourceCodeKey::isNull): Deleted.
        (JSC::SourceCodeKey::string): Deleted.
        (JSC::SourceCodeKey::operator==): Deleted.
        (JSC::SourceCodeKeyHash::hash): Deleted.
        (JSC::SourceCodeKeyHash::equal): Deleted.
        (JSC::SourceCodeKeyHashTraits::isEmptyValue): Deleted.
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * runtime/Completion.cpp:
        (JSC::checkSyntax):
        (JSC::checkModuleSyntax):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ProgramExecutable::checkSyntax):
        * runtime/Executable.h:
        * runtime/FunctionConstructor.cpp:
        (JSC::constructFunction):
        (JSC::constructFunctionSkippingEvalEnabledCheck):
        * runtime/FunctionConstructor.h:
        * runtime/GeneratorFrame.cpp: Added.
        (JSC::GeneratorFrame::GeneratorFrame):
        (JSC::GeneratorFrame::finishCreation):
        (JSC::GeneratorFrame::createStructure):
        (JSC::GeneratorFrame::create):
        (JSC::GeneratorFrame::save):
        (JSC::GeneratorFrame::resume):
        (JSC::GeneratorFrame::visitChildren):
        * runtime/GeneratorFrame.h: Added.
        (JSC::GeneratorFrame::locals):
        (JSC::GeneratorFrame::localAt):
        (JSC::GeneratorFrame::offsetOfLocals):
        (JSC::GeneratorFrame::allocationSizeForLocals):
        * runtime/GeneratorFunctionConstructor.cpp: Added.
        (JSC::GeneratorFunctionConstructor::GeneratorFunctionConstructor):
        (JSC::GeneratorFunctionConstructor::finishCreation):
        (JSC::callGeneratorFunctionConstructor):
        (JSC::constructGeneratorFunctionConstructor):
        (JSC::GeneratorFunctionConstructor::getCallData):
        (JSC::GeneratorFunctionConstructor::getConstructData):
        * runtime/GeneratorFunctionConstructor.h: Added.
        (JSC::GeneratorFunctionConstructor::create):
        (JSC::GeneratorFunctionConstructor::createStructure):
        * runtime/GeneratorFunctionPrototype.cpp: Added.
        (JSC::GeneratorFunctionPrototype::GeneratorFunctionPrototype):
        (JSC::GeneratorFunctionPrototype::finishCreation):
        * runtime/GeneratorFunctionPrototype.h: Added.
        (JSC::GeneratorFunctionPrototype::create):
        (JSC::GeneratorFunctionPrototype::createStructure):
        * runtime/GeneratorPrototype.cpp: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
        (JSC::GeneratorPrototype::finishCreation):
        (JSC::GeneratorPrototype::getOwnPropertySlot):
        * runtime/GeneratorPrototype.h: Copied from Source/JavaScriptCore/ftl/FTLForOSREntryJITCode.cpp.
        (JSC::GeneratorPrototype::create):
        (JSC::GeneratorPrototype::createStructure):
        (JSC::GeneratorPrototype::GeneratorPrototype):
        * runtime/GeneratorThisMode.h: Added.
        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        * runtime/JSGeneratorFunction.cpp: Added.
        (JSC::JSGeneratorFunction::JSGeneratorFunction):
        (JSC::JSGeneratorFunction::createImpl):
        (JSC::JSGeneratorFunction::create):
        (JSC::JSGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
        * runtime/JSGeneratorFunction.h: Added.
        (JSC::JSGeneratorFunction::allocationSize):
        (JSC::JSGeneratorFunction::createStructure):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::generatorFunctionPrototype):
        (JSC::JSGlobalObject::generatorPrototype):
        (JSC::JSGlobalObject::generatorFunctionStructure):
        * runtime/ModuleLoaderObject.cpp:
        (JSC::moduleLoaderObjectParseModule):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * tests/es6.yaml:
        * tests/es6/generators_yield_star_generic_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_instances_of_iterables.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_iterator_closing.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/es6/generators_yield_star_iterator_closing_via_throw.js:
        (iterator.next):
        (iterable.Symbol.iterator):
        (__createIterableObject):
        * tests/stress/generator-arguments-from-function.js: Added.
        (shouldBe):
        (test):
        * tests/stress/generator-arguments.js: Added.
        (shouldBe):
        (g1):
        * tests/stress/generator-class-methods-syntax.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntaxError.Cocoa):
        (testSyntax.Cocoa.prototype.ok):
        (testSyntax.Cocoa):
        (testSyntax.Cocoa.ok):
        * tests/stress/generator-class-methods.js: Added.
        (shouldBe):
        (prototype.gen):
        (staticGen):
        (shouldBe.g.next):
        * tests/stress/generator-eval-this.js: Added.
        (shouldBe):
        (shouldThrow):
        (B):
        (A):
        (C.prototype.generator):
        (C):
        (TypeError):
        * tests/stress/generator-function-constructor.js: Added.
        (shouldBe):
        (generatorFunctionConstructor):
        * tests/stress/generator-function-name.js: Added.
        (shouldBe):
        (ok):
        * tests/stress/generator-methods-with-non-generator.js: Added.
        (shouldThrow):
        * tests/stress/generator-relations.js: Added.
        (shouldBe):
        (generatorFunction):
        * tests/stress/generator-return-before-first-call.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-return.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-this.js: Added.
        (shouldBe):
        (shouldThrow):
        (gen):
        (shouldBe.g.next):
        * tests/stress/generator-throw-before-first-call.js: Added.
        (unreachable):
        (gen):
        (catch):
        * tests/stress/generator-throw.js: Added.
        (shouldBe):
        (shouldBeIteratorResult):
        * tests/stress/generator-with-new-target.js: Added.
        (shouldBe):
        (gen):
        * tests/stress/generator-with-super.js: Added.
        (shouldThrow):
        (test):
        (B.prototype.gen):
        (B):
        (A.prototype.gen):
        (A):
        * tests/stress/generator-yield-star.js: Added.
        (shouldBe):
        (shouldThrow):
        (prototype.call):
        (Arrays):
        (Arrays.prototype.Symbol.iterator):
        (Iterator.prototype.next):
        (Iterator.prototype.string_appeared_here):
        (Iterator.prototype.Symbol.iterator):
        (Iterator):
        (gen):

2015-12-01  Filip Pizlo  <fpizlo@apple.com>

        Remove repetitive cruft from FTL OSR exit code in LowerDFGToLLVM
        https://bugs.webkit.org/show_bug.cgi?id=151718

        Reviewed by Geoffrey Garen.

        * b3/B3StackmapValue.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):

2015-12-01  Caitlin Potter  <caitp@igalia.com>

        [JSC] add missing RequireObjectCoercible() step in destructuring
        https://bugs.webkit.org/show_bug.cgi?id=151596

        Reviewed by Darin Adler.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitRequireObjectCoercible):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectPatternNode::bindValue):
        * tests/stress/destructuring-assignment-require-object-coercible.js: Added.
        (testTypeError):
        (testOK):

2015-12-01  Mark Lam  <mark.lam@apple.com>

        Refactor FTL sub snippet code to support general binary op snippets.
        https://bugs.webkit.org/show_bug.cgi?id=151706

        Reviewed by Geoffrey Garen.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

        * ftl/FTLCompile.cpp:
        - Moved the BinarySnippetRegisterContext to FTLCompileBinaryOp.cpp verbatim.
        - Generalize generateArithSubICFastPath() to generateBinaryOpICFastPath().
          It now uses snippet specific helpers in FTLCompileBinaryOp.cpp to generate
          the fast paths.

        * ftl/FTLCompileBinaryOp.cpp: Added.
        (JSC::FTL::BinarySnippetRegisterContext::BinarySnippetRegisterContext):
        (JSC::FTL::BinarySnippetRegisterContext::initializeRegisters):
        (JSC::FTL::BinarySnippetRegisterContext::restoreRegisters):
        - Moved here without changed from FTLCompile.cpp.
        (JSC::FTL::generateArithSubFastPath):
        * ftl/FTLCompileBinaryOp.h: Added.

        * ftl/FTLInlineCacheDescriptor.h:
        (JSC::FTL::BinaryOpDescriptor::nodeType):
        (JSC::FTL::BinaryOpDescriptor::size):
        (JSC::FTL::BinaryOpDescriptor::name):
        (JSC::FTL::BinaryOpDescriptor::fastPathICName):
        (JSC::FTL::BinaryOpDescriptor::slowPathFunction):
        (JSC::FTL::BinaryOpDescriptor::leftOperand):
        (JSC::FTL::BinaryOpDescriptor::rightOperand):
        (JSC::FTL::BinaryOpDescriptor::BinaryOpDescriptor):
        (JSC::FTL::ArithSubDescriptor::ArithSubDescriptor): Deleted.
        (JSC::FTL::ArithSubDescriptor::leftType): Deleted.
        (JSC::FTL::ArithSubDescriptor::rightType): Deleted.
        - Refactor ArithSubDescriptor into BinaryOpDescriptor, and re-add a sub-class
          ArithSubDescriptor as specializations of BinaryOpDescriptor.

        * ftl/FTLInlineCacheDescriptorInlines.h: Added.
        (JSC::FTL::ArithSubDescriptor::ArithSubDescriptor):
        (JSC::FTL::ArithSubDescriptor::icSize):

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
        * ftl/FTLOSRExit.h:
        * ftl/FTLState.h:

2015-12-01  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed, rolling out r192876.

        It broke a lot of JSC and layout tests for GTK and EFL

        Reverted changeset:

        "[ES6] "super" and "this" should be lexically bound inside an
        arrow function and should live in a JSLexicalEnvironment"
        https://bugs.webkit.org/show_bug.cgi?id=149338
        http://trac.webkit.org/changeset/192876

2015-12-01 Aleksandr Skachkov   <gskachkov@gmail.com>

        [ES6] "super" and "this" should be lexically bound inside an arrow function and should live in a JSLexicalEnvironment
        https://bugs.webkit.org/show_bug.cgi?id=149338

        Reviewed by Saam Barati.

        Implemented new version of the lexically bound 'this' in arrow function. In current version 
        'this' is stored inside of the lexical environment of the function. To store and load we use
        op_get_from_scope and op_put_to_scope operations. Also new implementation prevent raising TDZ
        error for arrow functions that are declared before super() but invoke after.

        * builtins/BuiltinExecutables.cpp:
        (JSC::createExecutableInternal):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::getSlow):
        * bytecode/ExecutableInfo.h:
        (JSC::ExecutableInfo::ExecutableInfo):
        (JSC::ExecutableInfo::isDerivedConstructorContext):
        (JSC::ExecutableInfo::isArrowFunctionContext):
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedCodeBlock::isDerivedConstructorContext):
        (JSC::UnlinkedCodeBlock::isArrowFunctionContext):
        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::generateUnlinkedFunctionCodeBlock):
        (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
        (JSC::BytecodeGenerator::variable):
        (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
        (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
        (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::isDerivedConstructorContext):
        (JSC::BytecodeGenerator::usesArrowFunction):
        (JSC::BytecodeGenerator::needsToUpdateArrowFunctionContext):
        (JSC::BytecodeGenerator::usesEval):
        (JSC::BytecodeGenerator::usesThis):
        (JSC::BytecodeGenerator::newTarget):
        (JSC::BytecodeGenerator::makeFunction):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ThisNode::emitBytecode):
        (JSC::SuperNode::emitBytecode):
        (JSC::EvalFunctionCallNode::emitBytecode):
        (JSC::FunctionCallValueNode::emitBytecode):
        (JSC::FunctionNode::emitBytecode):
        * debugger/DebuggerCallFrame.cpp:
        (JSC::DebuggerCallFrame::evaluate):
        * dfg/DFGAbstractInterpreterInlines.h:
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        * dfg/DFGClobberize.h:
        * dfg/DFGDoesGC.cpp:
        * dfg/DFGFixupPhase.cpp:
        * dfg/DFGNodeType.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPredictionPropagationPhase.cpp:
        * dfg/DFGPromotedHeapLocation.cpp:
        * dfg/DFGPromotedHeapLocation.h:
        * dfg/DFGSafeToExecute.h:
        * dfg/DFGSpeculativeJIT.cpp:
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        * dfg/DFGSpeculativeJIT64.cpp:
        * ftl/FTLCapabilities.cpp:
        * ftl/FTLLowerDFGToLLVM.cpp:
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * jit/JIT.cpp:
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncExprCommon):
        * jit/JITOpcodes32_64.cpp:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createArrowFunctionExpr):
        (JSC::ASTBuilder::usesArrowFunction):
        * parser/Nodes.h:
        (JSC::ScopeNode::usesArrowFunction):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseFunctionInfo):
        * parser/ParserModes.h:
        * runtime/CodeCache.cpp:
        (JSC::CodeCache::getGlobalCodeBlock):
        (JSC::CodeCache::getProgramCodeBlock):
        (JSC::CodeCache::getEvalCodeBlock):
        (JSC::CodeCache::getModuleProgramCodeBlock):
        (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
        * runtime/CodeCache.h:
        * runtime/CommonIdentifiers.h:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::ScriptExecutable):
        (JSC::EvalExecutable::create):
        (JSC::EvalExecutable::EvalExecutable):
        (JSC::ProgramExecutable::ProgramExecutable):
        (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
        (JSC::FunctionExecutable::FunctionExecutable):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::isArrowFunctionContext):
        (JSC::ScriptExecutable::isDerivedConstructorContext):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::createEvalCodeBlock):
        * runtime/JSGlobalObject.h:
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
        * tests/es6.yaml:
        * tests/stress/arrowfunction-activation-sink-osrexit.js:
        * tests/stress/arrowfunction-activation-sink.js:
        * tests/stress/arrowfunction-lexical-bind-newtarget.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-1.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-2.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-3.js: Added.
        * tests/stress/arrowfunction-lexical-bind-supercall-4.js: Added.
        * tests/stress/arrowfunction-lexical-bind-this-1.js:
        * tests/stress/arrowfunction-lexical-bind-this-7.js: Added.
        * tests/stress/arrowfunction-tdz-1.js: Added.
        * tests/stress/arrowfunction-tdz-2.js: Added.
        * tests/stress/arrowfunction-tdz-3.js: Added.
        * tests/stress/arrowfunction-tdz-4.js: Added.
        * tests/stress/arrowfunction-tdz.js: Removed.

2015-12-01  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        [Streams API] streams should not directly use Number and related methods
        https://bugs.webkit.org/show_bug.cgi?id=151499

        Reviewed by Darin Adler.

        * runtime/CommonIdentifiers.h: Adding isNaN as private symbol.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Adding @isNaN function.

2015-12-01  Csaba Osztrogonác  <ossy@webkit.org>

        Don't hide the argument name inside for block in AirIteratedRegisterCoalescing.cpp
        https://bugs.webkit.org/show_bug.cgi?id=151622

        Reviewed by Darin Adler.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):

2015-12-01  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        [Streams API] Remove use of @catch for exposed promises
        https://bugs.webkit.org/show_bug.cgi?id=151625

        Reviewed by Darin Adler.

        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::addOwnInternalSlots): Removing @catch from the prototype as it is not safe.

2015-11-30  Filip Pizlo  <fpizlo@apple.com>

        B3::ValueRep::Any should translate into a Arg::ColdUse role in Air
        https://bugs.webkit.org/show_bug.cgi?id=151174

        Reviewed by Geoffrey Garen and Benjamin Poulain.

        This teaches the register allocator that it should pick spills based on whichever tmp has the
        highest score:

            score(tmp) = degree(tmp) / sum(for each use of tmp, block->frequency)

        In other words, the numerator is the number of edges in the inteference graph and the denominator
        is an estimate of the dynamic number of uses.

        This also extends Arg::Role to know that there is such a thing as ColdUse, i.e. a Use that
        doesn't count as such for the above formula. Because LateUse is always used in contexts where we
        want it to be Cold, I've defined LateUse to imply ColdUse.

        This gets rid of all spilling inside the hot loop in Kraken/imaging-gaussian-blur. But more
        importantly, it makes our register allocator use a well-known heuristic based on reusable
        building blocks like the new Air::UseCounts. Even if the heuristic is slightly wrong, the right
        heuristic probably uses the same building blocks.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        * b3/B3ValueRep.h:
        * b3/air/AirArg.cpp:
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isAnyUse):
        (JSC::B3::Air::Arg::isColdUse):
        (JSC::B3::Air::Arg::isWarmUse):
        (JSC::B3::Air::Arg::isEarlyUse):
        (JSC::B3::Air::Arg::isDef):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::iteratedRegisterCoalescing):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator): Deleted.
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocatedReg): Deleted.
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::tmpArraySize): Deleted.
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::initializeDegrees): Deleted.
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::build): Deleted.
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill): Deleted.
        (JSC::B3::Air::isUselessMoveInst): Deleted.
        (JSC::B3::Air::assignRegisterToTmpInProgram): Deleted.
        (JSC::B3::Air::addSpillAndFillToProgram): Deleted.
        (JSC::B3::Air::iteratedRegisterCoalescingOnType): Deleted.
        * b3/air/AirLiveness.h:
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/air/AirUseCounts.h: Added.
        (JSC::B3::Air::UseCounts::Counts::dump):
        (JSC::B3::Air::UseCounts::UseCounts):
        (JSC::B3::Air::UseCounts::operator[]):
        (JSC::B3::Air::UseCounts::dump):
        * runtime/Options.h:

2015-11-30  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the !ENABLE(DFG_JIT) build after r192699
        https://bugs.webkit.org/show_bug.cgi?id=151616

        Reviewed by Darin Adler.

        * assembler/MacroAssembler.h:

2015-11-30  Yusuke Suzuki  <utatane.tea@gmail.com>

        Object::{freeze, seal} perform preventExtensionsTransition twice
        https://bugs.webkit.org/show_bug.cgi?id=151606

        Reviewed by Darin Adler.

        In Structure::{freezeTransition, sealTransition}, we perform preventExtensionsTransition.
        So it is unnecessary to perform preventExtensionsTransition before executing Structure::{freezeTransition, sealTransition}.

        * runtime/JSObject.cpp:
        (JSC::JSObject::seal):
        (JSC::JSObject::freeze):
        (JSC::JSObject::preventExtensions):
        * tests/stress/freeze-and-seal-should-prevent-extensions.js: Added.
        (shouldBe):
        (shouldThrow):

2015-11-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Add Sqrt to B3
        https://bugs.webkit.org/show_bug.cgi?id=151692

        Reviewed by Geoffrey Garen.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::sqrtDouble):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::sqrtsd_mr):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::typeFor):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testSqrtArg):
        (JSC::B3::testSqrtImm):
        (JSC::B3::testSqrtMem):
        (JSC::B3::run):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::doubleSqrt):

2015-11-30  Filip Pizlo  <fpizlo@apple.com>

        FTL lazy slow paths should work with B3
        https://bugs.webkit.org/show_bug.cgi?id=151667

        Reviewed by Geoffrey Garen.

        This adds all of the glue necessary to make FTL::LazySlowPath work with B3. The B3 approach
        allows us to put all of the code in FTL::LowerDFGToLLVM, instead of having supporting data
        structures on the side and a bunch of complex code in FTLCompile.cpp.

        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::generate):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::generate):
        * b3/B3StackmapValue.h:
        * ftl/FTLJSTailCall.cpp:
        (JSC::FTL::DFG::recoveryFor):
        (JSC::FTL::JSTailCall::emit):
        * ftl/FTLLazySlowPath.cpp:
        (JSC::FTL::LazySlowPath::LazySlowPath):
        (JSC::FTL::LazySlowPath::generate):
        * ftl/FTLLazySlowPath.h:
        (JSC::FTL::LazySlowPath::createGenerator):
        (JSC::FTL::LazySlowPath::patchableJump):
        (JSC::FTL::LazySlowPath::done):
        (JSC::FTL::LazySlowPath::patchpoint):
        (JSC::FTL::LazySlowPath::usedRegisters):
        (JSC::FTL::LazySlowPath::callSiteIndex):
        (JSC::FTL::LazySlowPath::stub):
        * ftl/FTLLocation.cpp:
        (JSC::FTL::Location::forValueRep):
        (JSC::FTL::Location::forStackmaps):
        (JSC::FTL::Location::dump):
        (JSC::FTL::Location::isGPR):
        (JSC::FTL::Location::gpr):
        (JSC::FTL::Location::isFPR):
        (JSC::FTL::Location::fpr):
        (JSC::FTL::Location::restoreInto):
        * ftl/FTLLocation.h:
        (JSC::FTL::Location::Location):
        (JSC::FTL::Location::forRegister):
        (JSC::FTL::Location::forIndirect):
        (JSC::FTL::Location::forConstant):
        (JSC::FTL::Location::kind):
        (JSC::FTL::Location::hasReg):
        (JSC::FTL::Location::reg):
        (JSC::FTL::Location::hasOffset):
        (JSC::FTL::Location::offset):
        (JSC::FTL::Location::hash):
        (JSC::FTL::Location::hasDwarfRegNum): Deleted.
        (JSC::FTL::Location::dwarfRegNum): Deleted.
        (JSC::FTL::Location::hasDwarfReg): Deleted.
        (JSC::FTL::Location::dwarfReg): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::stubUnavailableRegisters):
        (JSC::RegisterSet::macroScratchRegisters):
        (JSC::RegisterSet::calleeSaveRegisters):
        * jit/RegisterSet.h:

2015-11-30  Geoffrey Garen  <ggaren@apple.com>

        Use a better RNG for Math.random()
        https://bugs.webkit.org/show_bug.cgi?id=151641

        Reviewed by Anders Carlsson.

        Updated for interface change.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::setInputCursor):

2015-11-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Speed up Air Liveness Analysis on Tmps
        https://bugs.webkit.org/show_bug.cgi?id=151556

        Reviewed by Filip Pizlo.

        Liveness Analysis scales poorly on large graphs like the ones
        generated by testComplex().
        This patch introduces a faster of Liveness using the continuous indices
        of values instead of the values themselves.

        There are two main areas of improvements:
        1) Reduce the cost of doing a LocalCalc over a BasicBlock.
        2) Reduce how many LocalCalc are needed to converge to a solution.

        Most of the costs of LocalCalc are from HashSet manipulations.
        The HashSet operations are O(1) but the constant is large enough
        to be a problem.

        I used a similar trick as the Register Allocator to remove hashing
        and collision handling: the absolute value of the Tmp is used as an index
        into a flat array.

        I used Briggs's Sparse Set implementation for the local live information
        at each instruction. It has great properties for doing the local calculation:
        -No memory reallocation.
        -O(1) add() and remove() with a small constant.
        -Strict O(n) iteration.
        -O(1) clear().

        The values Live-At-Head are now stored into a Vector. The Sparse Set
        is used to maintain the Tmp uniqueness.

        When forwarding new liveness at head to the predecessor, I start by removing
        everything that was already in live-at-head. We can assume that any value
        in that list has already been added to the predecessors.
        This leaves us with a small-ish number of Tmps to add to live-at-head
        and to the predecessors.

        The speed up convergence, I used the same trick as DFG's liveness: keep
        a set of dirty blocks to process. In practice, all the blocks without
        back-edges converge quickly, and we only propagate liveness as needed.

        This patch reduces the time taken by "testComplex(64, 384)" by another 5%.

        The remaining things to do for Liveness are:
        -Skip the first block for the fix point (it is often large and doing a local
         calc on it is useless).
        -Find a better Data Structure for live-at-tail (updating the HashSet takes
         > 50% of the total convergence time).

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::getAlias):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::getAliasWhenSpilling):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocatedReg):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::tmpArraySize):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::initializeDegrees):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdge):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::makeWorkList):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::simplify):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::forEachAdjacent):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::hasBeenSimplified):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::decrementDegree):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::forEachNodeMoves):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::isMoveRelated):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::enableMovesOnValue):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::precoloredCoalescingHeuristic):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::conservativeHeuristic):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addWorkList):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::combine):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::freezeMoves):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::assignColors):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::dumpInterferenceGraphInDot):
        (JSC::B3::Air::iteratedRegisterCoalescingOnType):
        (JSC::B3::Air::iteratedRegisterCoalescing):
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::GP>::absoluteIndex): Deleted.
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::GP>::tmpFromAbsoluteIndex): Deleted.
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::FP>::absoluteIndex): Deleted.
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::FP>::tmpFromAbsoluteIndex): Deleted.
        * b3/air/AirReportUsedRegisters.cpp:
        (JSC::B3::Air::reportUsedRegisters):
        * b3/air/AirTmpInlines.h:
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::absoluteIndex):
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::tmpFromAbsoluteIndex):
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::absoluteIndex):
        (JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::tmpFromAbsoluteIndex):
        * b3/air/AirLiveness.h: Added.

2015-11-30  Saam barati  <sbarati@apple.com>

        FTL OSR Exits that are exception handlers should not have two different entrances. Instead, we should have two discrete OSR exits that do different things.
        https://bugs.webkit.org/show_bug.cgi?id=151404

        Reviewed by Filip Pizlo.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExceptionHandlerManager.cpp:
        (JSC::FTL::ExceptionHandlerManager::addNewExit):
        (JSC::FTL::ExceptionHandlerManager::addNewCallOperationExit):
        (JSC::FTL::ExceptionHandlerManager::callOperationExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::callOperationOSRExit):
        (JSC::FTL::ExceptionHandlerManager::getByIdOSRExit): Deleted.
        (JSC::FTL::ExceptionHandlerManager::subOSRExit): Deleted.
        * ftl/FTLExceptionHandlerManager.h:
        * ftl/FTLExitThunkGenerator.cpp:
        (JSC::FTL::ExitThunkGenerator::emitThunk):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
        (JSC::FTL::OSRExitDescriptor::isExceptionHandler):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::spillRegistersToSpillSlot):
        (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
        (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromGenericUnwind):
        (JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
        (JSC::FTL::OSRExit::needsRegisterRecoveryOnGenericUnwindOSRExitPath):
        (JSC::FTL::OSRExitDescriptor::willArriveAtExitFromIndirectExceptionCheck): Deleted.
        (JSC::FTL::OSRExitDescriptor::mightArriveAtOSRExitFromGenericUnwind): Deleted.
        (JSC::FTL::OSRExitDescriptor::mightArriveAtOSRExitFromCallOperation): Deleted.
        (JSC::FTL::OSRExitDescriptor::needsRegisterRecoveryOnGenericUnwindOSRExitPath): Deleted.
        * ftl/FTLOSRExit.h:
        * ftl/FTLOSRExitCompilationInfo.h:
        (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):

2015-11-30  Mark Lam  <mark.lam@apple.com>

        Refactor the op_add, op_sub, and op_mul snippets to use the SnippetOperand class.
        https://bugs.webkit.org/show_bug.cgi?id=151678

        Reviewed by Geoffrey Garen.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        * ftl/FTLCompile.cpp:
        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::JITAddGenerator):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emit_op_sub):
        * jit/JITMulGenerator.cpp:
        (JSC::JITMulGenerator::generateFastPath):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::JITMulGenerator):
        * jit/JITSubGenerator.cpp:
        (JSC::JITSubGenerator::generateFastPath):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::JITSubGenerator):
        * jit/SnippetOperand.h:
        (JSC::SnippetOperand::isPositiveConstInt32):

2015-11-30  Filip Pizlo  <fpizlo@apple.com>

        B3 stackmaps should support early clobber
        https://bugs.webkit.org/show_bug.cgi?id=151668

        Reviewed by Geoffrey Garen.

        While starting work on FTL lazy slow paths, I realized that we needed some way to say that r11 is
        off limits. Not just that it's clobbered, but that it cannot be used for any input values to a
        stackmap.

        In LLVM we do this by having the AnyRegCC forbid r11.

        In B3, we want something more flexible. In this and other cases, what we really want is an early
        clobber set. B3 already supported a late clobber set for every stackmap value. Late clobber means
        that the act of performing the operation will cause garbage to be written into those registers.
        But here we want: assume that garbage magically appears in those registers in the moment before
        the operation executes. Any registers in that set will be off-limits to the inputs to the
        stackmap. This should be great for other things, like the way the we handle exceptions.

        For the simple r11 issue, what we want is to call the StackmapValue::clobber() method, which now
        means both early and late clobber. It's the weapon of choice whenever you're unsure.

        This adds the early clobber feature, does some minor Inst refactoring to make this less scary,
        and adds a test. The test is simple but it's very comprehensive - for example it tests the
        early-clobber-after-Move special case.

        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::extraClobberedRegs):
        (JSC::B3::StackmapSpecial::extraEarlyClobberedRegs):
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        * b3/B3StackmapSpecial.h:
        * b3/B3StackmapValue.cpp:
        (JSC::B3::StackmapValue::dumpMeta):
        (JSC::B3::StackmapValue::StackmapValue):
        * b3/B3StackmapValue.h:
        * b3/air/AirCCallSpecial.cpp:
        (JSC::B3::Air::CCallSpecial::extraClobberedRegs):
        (JSC::B3::Air::CCallSpecial::extraEarlyClobberedRegs):
        (JSC::B3::Air::CCallSpecial::dumpImpl):
        * b3/air/AirCCallSpecial.h:
        * b3/air/AirInst.h:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::extraClobberedRegs):
        (JSC::B3::Air::Inst::extraEarlyClobberedRegs):
        (JSC::B3::Air::Inst::forEachTmpWithExtraClobberedRegs):
        (JSC::B3::Air::Inst::reportUsedRegisters):
        (JSC::B3::Air::Inst::forEachDefAndExtraClobberedTmp): Deleted.
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocate):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::initializeDegrees):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdge):
        (JSC::B3::Air::iteratedRegisterCoalescingOnType):
        (JSC::B3::Air::iteratedRegisterCoalescing):
        * b3/air/AirSpecial.h:
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/testb3.cpp:
        (JSC::B3::testSimplePatchpointWithoutOuputClobbersGPArgs):
        (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
        (JSC::B3::testSimplePatchpointWithoutOuputClobbersFPArgs):
        (JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
        (JSC::B3::testPatchpointWithEarlyClobber):
        (JSC::B3::testPatchpointCallArg):
        (JSC::B3::run):
        * dfg/DFGCommon.h:

2015-11-30  Mark Lam  <mark.lam@apple.com>

        Snippefy op_div for the baseline JIT.
        https://bugs.webkit.org/show_bug.cgi?id=151607

        Reviewed by Geoffrey Garen.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:

        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emitSlow_op_div):
        (JSC::JIT::compileBinaryArithOpSlowCase): Deleted.

        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emitBinaryDoubleOp):
        (JSC::JIT::emit_op_div): Deleted.
        (JSC::JIT::emitSlow_op_div): Deleted.
        - Removed the 32-bit specific op_div implementation.  The 64-bit version with the
          op_div snippet can now service both 32-bit and 64-bit.
 
        * jit/JITDivGenerator.cpp: Added.
        (JSC::JITDivGenerator::loadOperand):
        (JSC::JITDivGenerator::generateFastPath):
        * jit/JITDivGenerator.h: Added.
        (JSC::JITDivGenerator::JITDivGenerator):
        (JSC::JITDivGenerator::didEmitFastPath):
        (JSC::JITDivGenerator::endJumpList):
        (JSC::JITDivGenerator::slowPathJumpList):
 
        * jit/JITInlines.h:
        (JSC::JIT::getOperandConstantDouble): Added.
 
        * jit/SnippetOperand.h: Added.
        (JSC::SnippetOperand::SnippetOperand):
        (JSC::SnippetOperand::mightBeNumber):
        (JSC::SnippetOperand::definitelyIsNumber):
        (JSC::SnippetOperand::isConst):
        (JSC::SnippetOperand::isConstInt32):
        (JSC::SnippetOperand::isConstDouble):
        (JSC::SnippetOperand::asRawBits):
        (JSC::SnippetOperand::asConstInt32):
        (JSC::SnippetOperand::asConstDouble):
        (JSC::SnippetOperand::setConstInt32):
        (JSC::SnippetOperand::setConstDouble):
        - The SnippetOperand encapsulates operand constness, const type, and profiling
          information.  As a result:
          1. The argument list to the JITDivGenerator constructor is now more concise.
          2. The logic of the JITDivGenerator is now less verbose and easier to express.

        * parser/ResultType.h:
        (JSC::ResultType::isInt32):
        (JSC::ResultType::definitelyIsNumber):
        (JSC::ResultType::definitelyIsString):
        (JSC::ResultType::definitelyIsBoolean):
        (JSC::ResultType::mightBeNumber):
        (JSC::ResultType::isNotNumber):
        - Made these functions const because they were always meant to be const.
          This also allows me to enforce constness in the SnippetOperand.

2015-11-30  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Fix coding style of Intl code
        https://bugs.webkit.org/show_bug.cgi?id=151491

        Reviewed by Darin Adler.

        This patch does three things:
        1. Rename pointers and references to ExecState from "exec" to "state".
        2. Pass parameters by references instead of pointers if the parameters
           are required.
        3. Remove the word "get" from the names of functions that don't return
           values through out arguments.

        * runtime/IntlCollator.cpp:
        (JSC::IntlCollatorFuncCompare):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::initializeCollator):
        (JSC::constructIntlCollator):
        (JSC::callIntlCollator):
        (JSC::IntlCollatorConstructor::getOwnPropertySlot):
        (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
        * runtime/IntlDateTimeFormat.cpp:
        (JSC::IntlDateTimeFormatFuncFormatDateTime):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::constructIntlDateTimeFormat):
        (JSC::callIntlDateTimeFormat):
        (JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot):
        (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlDateTimeFormatPrototype.cpp:
        (JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot):
        (JSC::IntlDateTimeFormatPrototypeGetterFormat):
        (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
        * runtime/IntlNumberFormat.cpp:
        (JSC::IntlNumberFormatFuncFormatNumber):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::constructIntlNumberFormat):
        (JSC::callIntlNumberFormat):
        (JSC::IntlNumberFormatConstructor::getOwnPropertySlot):
        (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlNumberFormatPrototype.cpp:
        (JSC::IntlNumberFormatPrototype::getOwnPropertySlot):
        (JSC::IntlNumberFormatPrototypeGetterFormat):
        (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
        * runtime/IntlObject.cpp:
        (JSC::intlBooleanOption):
        (JSC::intlStringOption):
        (JSC::privateUseLangTag):
        (JSC::canonicalLangTag):
        (JSC::grandfatheredLangTag):
        (JSC::canonicalizeLanguageTag):
        (JSC::canonicalizeLocaleList):
        (JSC::lookupSupportedLocales):
        (JSC::bestFitSupportedLocales):
        (JSC::supportedLocales):
        (JSC::getIntlBooleanOption): Deleted.
        (JSC::getIntlStringOption): Deleted.
        (JSC::getPrivateUseLangTag): Deleted.
        (JSC::getCanonicalLangTag): Deleted.
        (JSC::getGrandfatheredLangTag): Deleted.
        * runtime/IntlObject.h:

2015-11-30  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Simplify the loop that remove useless Air instructions
        https://bugs.webkit.org/show_bug.cgi?id=151652

        Reviewed by Andreas Kling.

        * b3/air/AirEliminateDeadCode.cpp:
        (JSC::B3::Air::eliminateDeadCode):
        Use Vector's removeAllMatching() instead of custom code.

        It is likely faster too since we remove few values and Vector
        is good at doing that.

2015-11-30  Filip Pizlo  <fpizlo@apple.com>

        B3 should be be clever about choosing which child to reuse for result in two-operand commutative operations
        https://bugs.webkit.org/show_bug.cgi?id=151321

        Reviewed by Geoffrey Garen.

        When lowering a commutative operation to a two-operand instruction, you have a choice of which
        child value to move into the result tmp. For example we might have:

            @x = Add(@y, @z)

        Assuming no three-operand add is available, we could either lower it to this:

            Move %y, %x
            Add %z, %x

        or to this:

            Move %z, %x
            Add %y, %x

        Which is better depends on the likelihood of coalescing with %x. If it's more likely that %y will
        coalesce with %x, then we want to use the first form. Otherwise, we should use the second form.

        This implements two heuristics for selecting the right form, and makes those heuristics reusable
        within the B3->Air lowering by abstracting it as preferRightForResult(). For non-commutative
        operations we must use the first form, so the first form is the default. The heuristics are:

        - If the right child has only one user, then use the second form instead. This is profitable because
          that means that @z dies at the Add, so using the second form means that the Move will be coalesced
          away.

        - If one of the children is a Phi that this operation (the Add in this case) flows into via some
          Upsilon - possibly transitively through other Phis - then use the form that cases a Move on that
          child. This overrides everything else, and is meant to optimize variables that accumulate in a
          loop.

        This required adding a reusable PhiChildren analysis, so I wrote one. It has an API that is mostly
        based on iterators, and a higher-level API for looking at transitive children that is based on
        functors.

        I was originally implementing this for completeness, but when looking at how it interacted with
        imaging-gaussian-blur, I realized the need for some heuristic for the loop-accumulator case. This
        helps a lot on that benchmark. This widens the overall lead that B3 has on imaging-gaussian-blur, but
        steady-state runs that exclude compile latency still show a slight deficit. That will most likely get
        fixed by https://bugs.webkit.org/show_bug.cgi?id=151174.

        No new tests because the commutativity appears to be covered by existing tests, and anyway, there are
        no correctness implications to commuting a commutative operation.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::LowerToAir):
        (JSC::B3::Air::LowerToAir::canBeInternal):
        (JSC::B3::Air::LowerToAir::appendUnOp):
        (JSC::B3::Air::LowerToAir::preferRightForResult):
        (JSC::B3::Air::LowerToAir::appendBinOp):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3PhiChildren.cpp: Added.
        (JSC::B3::PhiChildren::PhiChildren):
        (JSC::B3::PhiChildren::~PhiChildren):
        * b3/B3PhiChildren.h: Added.
        (JSC::B3::PhiChildren::ValueCollection::ValueCollection):
        (JSC::B3::PhiChildren::ValueCollection::size):
        (JSC::B3::PhiChildren::ValueCollection::at):
        (JSC::B3::PhiChildren::ValueCollection::operator[]):
        (JSC::B3::PhiChildren::ValueCollection::contains):
        (JSC::B3::PhiChildren::ValueCollection::iterator::iterator):
        (JSC::B3::PhiChildren::ValueCollection::iterator::operator*):
        (JSC::B3::PhiChildren::ValueCollection::iterator::operator++):
        (JSC::B3::PhiChildren::ValueCollection::iterator::operator==):
        (JSC::B3::PhiChildren::ValueCollection::iterator::operator!=):
        (JSC::B3::PhiChildren::ValueCollection::begin):
        (JSC::B3::PhiChildren::ValueCollection::end):
        (JSC::B3::PhiChildren::UpsilonCollection::UpsilonCollection):
        (JSC::B3::PhiChildren::UpsilonCollection::size):
        (JSC::B3::PhiChildren::UpsilonCollection::at):
        (JSC::B3::PhiChildren::UpsilonCollection::operator[]):
        (JSC::B3::PhiChildren::UpsilonCollection::contains):
        (JSC::B3::PhiChildren::UpsilonCollection::begin):
        (JSC::B3::PhiChildren::UpsilonCollection::end):
        (JSC::B3::PhiChildren::UpsilonCollection::values):
        (JSC::B3::PhiChildren::UpsilonCollection::forAllTransitiveIncomingValues):
        (JSC::B3::PhiChildren::UpsilonCollection::transitivelyUses):
        (JSC::B3::PhiChildren::at):
        (JSC::B3::PhiChildren::operator[]):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::Procedure):
        * b3/B3Procedure.h:
        * b3/B3UseCounts.cpp:
        (JSC::B3::UseCounts::UseCounts):
        * b3/B3UseCounts.h:
        (JSC::B3::UseCounts::numUses):
        (JSC::B3::UseCounts::numUsingInstructions):
        (JSC::B3::UseCounts::operator[]): Deleted.

2015-11-30  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r192812): This change seems to have broken the iOS builds (Requested by ryanhaddad on #webkit).
        https://bugs.webkit.org/show_bug.cgi?id=151669

        Unreviewed, fix build.

        * dfg/DFGCommon.h:

2015-11-30  Saam barati  <sbarati@apple.com>

        implement op_get_rest_length so that we can allocate the rest array with the right size from the start
        https://bugs.webkit.org/show_bug.cgi?id=151467

        Reviewed by Geoffrey Garen and Mark Lam.

        This patch implements op_get_rest_length which returns the length
        that the rest parameter array will be. We're implementing this because
        it might be a constant value in the presence of inlining in the DFG.
        We will take advantage of this optimization opportunity in a future patch:
        https://bugs.webkit.org/show_bug.cgi?id=151454
        to emit better code for op_copy_rest.

        op_get_rest_length has two operands: 
        1) a destination
        2) A constant indicating the number of parameters to skip when copying the rest array.

        op_get_rest_length lowers to a JSConstant node when we're inlined
        and not a varargs call (in this case, we statically know the arguments
        length). When that condition isn't met, we lower op_get_rest_length to 
        GetRestArray. GetRestArray produces its result as an int32.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewArray):
        (JSC::BytecodeGenerator::emitNewArrayWithSize):
        (JSC::BytecodeGenerator::emitNewFunction):
        (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
        (JSC::BytecodeGenerator::emitRestParameter):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::RestParameterNode::emit):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGMayExit.cpp:
        (JSC::DFG::mayExit):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::numberOfArgumentsToSkip):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileCopyRest):
        (JSC::DFG::SpeculativeJIT::compileGetRestLength):
        (JSC::DFG::SpeculativeJIT::compileNotifyWrite):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * 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::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCopyRest):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetRestLength):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewObject):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_copy_rest):
        (JSC::JIT::emit_op_get_rest_length):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):

2015-11-30  Filip Pizlo  <fpizlo@apple.com>

        MacroAssembler needs an API for disabling scratch registers
        https://bugs.webkit.org/show_bug.cgi?id=151010

        Reviewed by Saam Barati and Michael Saboff.

        This adds two scope classes, DisallowMacroScratchRegisterUsage and
        AllowMacroScratchRegisterUsage. The default is that the scratch registers are enabled. Air
        disables them before generation.

        Henceforth the pattern inside B3 stackmap generator callbacks will be that you can only use
        AllowMacroScratchRegisterUsage if you've either supplied the scratch register as a clobbered
        register and arranged for all of the stackmap values to be late uses, or you're writing a test
        and you're OK with it being fragile with respect to scratch registers. The latter holds in most
        of testb3.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::optimizeForX86):
        (JSC::AbstractMacroAssembler::setTempRegisterValid):
        * assembler/AllowMacroScratchRegisterUsage.h: Added.
        (JSC::AllowMacroScratchRegisterUsage::AllowMacroScratchRegisterUsage):
        (JSC::AllowMacroScratchRegisterUsage::~AllowMacroScratchRegisterUsage):
        * assembler/DisallowMacroScratchRegisterUsage.h: Added.
        (JSC::DisallowMacroScratchRegisterUsage::DisallowMacroScratchRegisterUsage):
        (JSC::DisallowMacroScratchRegisterUsage::~DisallowMacroScratchRegisterUsage):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::scratchRegister):
        (JSC::MacroAssemblerX86Common::loadDouble):
        (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::add32):
        (JSC::MacroAssemblerX86_64::and32):
        (JSC::MacroAssemblerX86_64::or32):
        (JSC::MacroAssemblerX86_64::sub32):
        (JSC::MacroAssemblerX86_64::load8):
        (JSC::MacroAssemblerX86_64::addDouble):
        (JSC::MacroAssemblerX86_64::convertInt32ToDouble):
        (JSC::MacroAssemblerX86_64::store32):
        (JSC::MacroAssemblerX86_64::store8):
        (JSC::MacroAssemblerX86_64::callWithSlowPathReturnType):
        (JSC::MacroAssemblerX86_64::call):
        (JSC::MacroAssemblerX86_64::jump):
        (JSC::MacroAssemblerX86_64::tailRecursiveCall):
        (JSC::MacroAssemblerX86_64::makeTailRecursiveCall):
        (JSC::MacroAssemblerX86_64::branchAdd32):
        (JSC::MacroAssemblerX86_64::add64):
        (JSC::MacroAssemblerX86_64::addPtrNoFlags):
        (JSC::MacroAssemblerX86_64::and64):
        (JSC::MacroAssemblerX86_64::lshift64):
        (JSC::MacroAssemblerX86_64::or64):
        (JSC::MacroAssemblerX86_64::sub64):
        (JSC::MacroAssemblerX86_64::store64):
        (JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch):
        (JSC::MacroAssemblerX86_64::branch64):
        (JSC::MacroAssemblerX86_64::branchPtr):
        (JSC::MacroAssemblerX86_64::branchTest64):
        (JSC::MacroAssemblerX86_64::test64):
        (JSC::MacroAssemblerX86_64::branchPtrWithPatch):
        (JSC::MacroAssemblerX86_64::branch32WithPatch):
        (JSC::MacroAssemblerX86_64::storePtrWithPatch):
        (JSC::MacroAssemblerX86_64::branch8):
        (JSC::MacroAssemblerX86_64::branchTest8):
        (JSC::MacroAssemblerX86_64::convertInt64ToDouble):
        (JSC::MacroAssemblerX86_64::readCallTarget):
        (JSC::MacroAssemblerX86_64::haveScratchRegisterForBlinding):
        (JSC::MacroAssemblerX86_64::scratchRegisterForBlinding):
        (JSC::MacroAssemblerX86_64::canJumpReplacePatchableBranchPtrWithPatch):
        (JSC::MacroAssemblerX86_64::canJumpReplacePatchableBranch32WithPatch):
        (JSC::MacroAssemblerX86_64::revertJumpReplacementToPatchableBranchPtrWithPatch):
        (JSC::MacroAssemblerX86_64::revertJumpReplacementToPatchableBranch32WithPatch):
        (JSC::MacroAssemblerX86_64::revertJumpReplacementToBranchPtrWithPatch):
        (JSC::MacroAssemblerX86_64::repatchCall):
        (JSC::MacroAssemblerX86_64::add64AndSetFlags):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/testb3.cpp:
        (JSC::B3::testSimplePatchpoint):
        (JSC::B3::testSimplePatchpointWithoutOuputClobbersGPArgs):
        (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
        (JSC::B3::testSimplePatchpointWithoutOuputClobbersFPArgs):
        (JSC::B3::testSimplePatchpointWithOuputClobbersFPArgs):
        (JSC::B3::testPatchpointCallArg):
        (JSC::B3::testPatchpointFixedRegister):
        (JSC::B3::testPatchpointAny):
        (JSC::B3::testPatchpointAnyImm):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::testCheckLessThan):
        (JSC::B3::testCheckMegaCombo):
        (JSC::B3::testCheckAddImm):
        (JSC::B3::testCheckAddImmCommute):
        (JSC::B3::testCheckAddImmSomeRegister):
        (JSC::B3::testCheckAdd):
        (JSC::B3::testCheckAdd64):
        (JSC::B3::testCheckAddFoldFail):
        (JSC::B3::testCheckSubImm):
        (JSC::B3::testCheckSubBadImm):
        (JSC::B3::testCheckSub):
        (JSC::B3::testCheckSub64):
        (JSC::B3::testCheckSubFoldFail):
        (JSC::B3::testCheckNeg):
        (JSC::B3::testCheckNeg64):
        (JSC::B3::testCheckMul):
        (JSC::B3::testCheckMulMemory):
        (JSC::B3::testCheckMul2):
        (JSC::B3::testCheckMul64):
        (JSC::B3::testCheckMulFoldFail):
        (JSC::B3::genericTestCompare):
        * dfg/DFGCommon.h:
        * jit/GPRInfo.h:
        (JSC::GPRInfo::toRegister):
        (JSC::GPRInfo::reservedRegisters):

2015-11-26  Mark Lam  <mark.lam@apple.com>

        [ARM64] stress/op_div.js is failing on some divide by 0 cases.
        https://bugs.webkit.org/show_bug.cgi?id=151515

        Reviewed by Saam Barati.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        - Added a check for the divide by zero case.
        * tests/stress/op_div.js:
        - Un-skipped the test.

2015-11-27  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Add testb3 to the build system
        https://bugs.webkit.org/show_bug.cgi?id=151619

        Reviewed by Gyuyoung Kim.

        * shell/CMakeLists.txt:

2015-11-27  Csaba Osztrogonác  <ossy@webkit.org>

        Use mark pragmas only if it is supported
        https://bugs.webkit.org/show_bug.cgi?id=151621

        Reviewed by Mark Lam.

        * b3/air/AirIteratedRegisterCoalescing.cpp:

2015-11-27  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the ENABLE(B3_JIT) build with GCC in B3Procedure.h
        https://bugs.webkit.org/show_bug.cgi?id=151620

        Reviewed by Mark Lam.

        * b3/B3Procedure.h:

2015-11-27  Csaba Osztrogonác  <ossy@webkit.org>

        [cmake] Add new B3 source files to the build system
        https://bugs.webkit.org/show_bug.cgi?id=151618

        Reviewed by Gyuyoung Kim.

        * CMakeLists.txt:

2015-11-26  Carlos Garcia Campos  <cgarcia@igalia.com>

        [GLIB] Implement garbage collector timers
        https://bugs.webkit.org/show_bug.cgi?id=151391

        Reviewed by Žan Doberšek.

        Add GLib implementation using GSource.

        * heap/EdenGCActivityCallback.cpp:
        * heap/FullGCActivityCallback.cpp:
        * heap/GCActivityCallback.cpp:
        (JSC::GCActivityCallback::GCActivityCallback):
        (JSC::GCActivityCallback::scheduleTimer):
        (JSC::GCActivityCallback::cancelTimer):
        * heap/GCActivityCallback.h:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        * heap/HeapTimer.cpp:
        (JSC::HeapTimer::HeapTimer):
        (JSC::HeapTimer::~HeapTimer):
        (JSC::HeapTimer::timerDidFire):
        * heap/HeapTimer.h:
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::scheduleTimer):
        (JSC::IncrementalSweeper::cancelTimer):
        * heap/IncrementalSweeper.h:

2015-11-24  Caitlin Potter  <caitp@igalia.com>

        [JSC] support Computed Property Names in destructuring Patterns
        https://bugs.webkit.org/show_bug.cgi?id=151494

        Reviewed by Saam Barati.

        Add support for computed property names in destructuring BindingPatterns
        and AssignmentPatterns.

        Productions BindingProperty(1) and AssignmentProperty(2) allow for any valid
        PropertName(3), including ComputedPropertyName(4)

        1: http://tc39.github.io/ecma262/#prod-BindingProperty
        2: http://tc39.github.io/ecma262/#prod-AssignmentProperty
        3: http://tc39.github.io/ecma262/#prod-PropertyName
        4: http://tc39.github.io/ecma262/#prod-ComputedPropertyName

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ObjectPatternNode::bindValue):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::appendObjectPatternEntry):
        * parser/Nodes.h:
        (JSC::ObjectPatternNode::appendEntry):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):
        * tests/es6.yaml:
        * tests/es6/destructuring_assignment_computed_properties.js: Added.
        (test):
        (test.computeName):
        (test.loadValue):
        (test.out.get a):
        (test.out.set a):
        (test.out.get b):
        (test.out.set b):
        (test.out.get c):
        (test.out.set c):
        (test.get var):

2015-11-24  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r192536, r192722, and r192743.
        https://bugs.webkit.org/show_bug.cgi?id=151593

        Still causing trouble. (Requested by kling on #webkit).

        Reverted changesets:

        "[JSC] JSPropertyNameEnumerator could be destructorless."
        https://bugs.webkit.org/show_bug.cgi?id=151242
        http://trac.webkit.org/changeset/192536

        "REGRESSION(r192536): Null pointer dereference in
        JSPropertyNameEnumerator::visitChildren()."
        https://bugs.webkit.org/show_bug.cgi?id=151495
        http://trac.webkit.org/changeset/192722

        "REGRESSION(r192536): Null pointer dereference in
        JSPropertyNameEnumerator::visitChildren()."
        https://bugs.webkit.org/show_bug.cgi?id=151495
        http://trac.webkit.org/changeset/192743

2015-11-23  Brian Burg  <bburg@apple.com>

        Unreviewed, fix the Mac CMake build after r192793.

        * PlatformMac.cmake:

2015-11-20  Brian Burg  <bburg@apple.com>

        Web Inspector: RemoteInspector should track targets and connections for remote automation
        https://bugs.webkit.org/show_bug.cgi?id=151042

        Reviewed by Joseph Pecoraro.

        Refactor RemoteInspector so it can be used to send listings of different target types.
        First, rename Debuggable to RemoteInspectionTarget, and pull things not specific to
        remote inspection into the base class RemoteControllableTarget and its Connection class.

        Add a new RemoteControllableTarget called RemoteAutomationTarget, used by UIProcess
        to support remote UI automation via webinspectord. On the protocol side, this target
        uses a new WIRTypeKey called WIRTypeAutomation to distiguish the listing from
        Web and JavaScript listings and avoid inventing a new listing mechanism.

        * API/JSContextRef.cpp:
        (JSGlobalContextGetDebuggerRunLoop):
        (JSGlobalContextSetDebuggerRunLoop):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/InspectorFrontendChannel.h:
        * inspector/remote/RemoteAutomationTarget.cpp: Added.
        (Inspector::RemoteAutomationTarget::setAutomationAllowed): Added.
        * inspector/remote/RemoteAutomationTarget.h: Added.
        * inspector/remote/RemoteConnectionToTarget.h: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggableConnection.h.
        (Inspector::RemoteTargetBlock::RemoteTargetBlock):
        (Inspector::RemoteTargetBlock::~RemoteTargetBlock):
        (Inspector::RemoteTargetBlock::operator=):
        (Inspector::RemoteTargetBlock::operator()):
        * inspector/remote/RemoteConnectionToTarget.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggableConnection.mm.
        (Inspector::RemoteTargetHandleRunSourceGlobal):
        (Inspector::RemoteTargetQueueTaskOnGlobalQueue):
        (Inspector::RemoteTargetInitializeGlobalQueue):
        (Inspector::RemoteTargetHandleRunSourceWithInfo):
        (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget):
        (Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget):
        (Inspector::RemoteConnectionToTarget::destination):
        (Inspector::RemoteConnectionToTarget::connectionIdentifier):
        (Inspector::RemoteConnectionToTarget::dispatchAsyncOnTarget):
        (Inspector::RemoteConnectionToTarget::setup):
        (Inspector::RemoteConnectionToTarget::targetClosed):
        (Inspector::RemoteConnectionToTarget::close):
        (Inspector::RemoteConnectionToTarget::sendMessageToTarget):
        (Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
        (Inspector::RemoteConnectionToTarget::setupRunLoop):
        (Inspector::RemoteConnectionToTarget::teardownRunLoop):
        (Inspector::RemoteConnectionToTarget::queueTaskOnPrivateRunLoop):
        * inspector/remote/RemoteControllableTarget.cpp: Added.
        (Inspector::RemoteControllableTarget::~RemoteControllableTarget):
        (Inspector::RemoteControllableTarget::init):
        (Inspector::RemoteControllableTarget::update):
        * inspector/remote/RemoteControllableTarget.h: Added.
        * inspector/remote/RemoteInspectionTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggable.cpp.
        (Inspector::RemoteInspectionTarget::remoteControlAllowed):
        (Inspector::RemoteInspectionTarget::setRemoteDebuggingAllowed):
        (Inspector::RemoteInspectionTarget::pauseWaitingForAutomaticInspection):
        (Inspector::RemoteInspectionTarget::unpauseForInitializedInspector):
        * inspector/remote/RemoteInspectionTarget.h: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorDebuggable.h.
        (isType):
        * inspector/remote/RemoteInspector.h:

            Code to manage Debuggables now works with RemoteControllableTargets and doesn't
            care whether the target is for Inspection or Automation. Listing data with target-
            and type-specific information are captured when clients call into RemoteInspector
            since that's the easiest time to gather this information on the right thread.
            Use the is<> / downcast<> machinery when we need a concrete Target type.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::nextAvailableIdentifier):
        (Inspector::RemoteInspector::registerTarget): renamed from registerDebuggable.
        (Inspector::RemoteInspector::unregisterTarget): renamed from unregisterDebuggable.
        (Inspector::RemoteInspector::updateTarget): renamed from updateDebuggable.
        (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
        (Inspector::RemoteInspector::sendMessageToRemote):
        (Inspector::RemoteInspector::setupFailed):
        (Inspector::RemoteInspector::stopInternal):
        (Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
        (Inspector::RemoteInspector::xpcConnectionFailed):
        (Inspector::RemoteInspector::listingForTarget):
        (Inspector::RemoteInspector::listingForInspectionTarget):
        (Inspector::RemoteInspector::listingForAutomationTarget):
        (Inspector::RemoteInspector::pushListingsNow):
        (Inspector::RemoteInspector::pushListingsSoon):
        (Inspector::RemoteInspector::receivedSetupMessage):
        (Inspector::RemoteInspector::receivedDataMessage):
        (Inspector::RemoteInspector::receivedDidCloseMessage):
        (Inspector::RemoteInspector::receivedGetListingMessage):
        (Inspector::RemoteInspector::receivedIndicateMessage):
        (Inspector::RemoteInspector::receivedConnectionDiedMessage):
        (Inspector::RemoteInspector::RemoteInspector): Deleted.
        (Inspector::RemoteInspector::registerDebuggable): Deleted.
        (Inspector::RemoteInspector::unregisterDebuggable): Deleted.
        (Inspector::RemoteInspector::updateDebuggable): Deleted.
        (Inspector::RemoteInspector::updateDebuggableAutomaticInspectCandidate): Deleted.
        (Inspector::RemoteInspector::sendMessageToRemoteFrontend): Deleted.
        (Inspector::RemoteInspector::listingForDebuggable): Deleted.
        (Inspector::RemoteInspector::pushListingNow): Deleted.
        (Inspector::RemoteInspector::pushListingSoon): Deleted.
        * inspector/remote/RemoteInspectorConstants.h:
        * runtime/JSGlobalObjectDebuggable.cpp:
        (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemote):
        (JSC::JSGlobalObjectDebuggable::pauseWaitingForAutomaticInspection):
        (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemoteFrontend): Deleted.
        * runtime/JSGlobalObjectDebuggable.h:

2015-11-23  Brian Burg  <bburg@apple.com>

        Rename JavaScriptCore builtins files to match exposed object names
        https://bugs.webkit.org/show_bug.cgi?id=151549

        Reviewed by Youenn Fablet.

        As a subtask of unifying code generation for WebCore and JSC builtins, we need to get rid of
        differences between builtins filenames (e.g., Promise.prototype.js) and the name of the
        generated Builtin object (PromisePrototype).

        If we don't do this, then both build systems need special hacks to normalize the object name
        from the file name. It's easier to just normalize the filename.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/ArrayIteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/ArrayIterator.prototype.js.
        * builtins/ArrayPrototype.js: Renamed from Source/JavaScriptCore/builtins/Array.prototype.js.
        * builtins/FunctionPrototype.js: Renamed from Source/JavaScriptCore/builtins/Function.prototype.js.
        * builtins/IteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/Iterator.prototype.js.
        * builtins/PromiseOperations.js: Renamed from Source/JavaScriptCore/builtins/Operations.Promise.js.
        * builtins/PromisePrototype.js: Renamed from Source/JavaScriptCore/builtins/Promise.prototype.js.
        * builtins/StringIteratorPrototype.js: Renamed from Source/JavaScriptCore/builtins/StringIterator.prototype.js.
        * builtins/TypedArrayPrototype.js: Renamed from Source/JavaScriptCore/builtins/TypedArray.prototype.js.

2015-11-23  Andreas Kling  <akling@apple.com>

        REGRESSION(r192536): Null pointer dereference in JSPropertyNameEnumerator::visitChildren().
        <https://webkit.org/b/151495>

        Reviewed by Mark Lam

        The test I added when fixing this bug the first time caught another bug when
        run on 32-bit: jsString() can also cause GC, so we have to make sure that
        JSPropertyNameEnumerator::m_propertyNames is null until after the array it
        points to has been populated.

        Test: property-name-enumerator-gc-151495.js

        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::finishCreation):

== Rolled over to ChangeLog-2015-11-21 ==