ChangeLog-2015-11-21   [plain text]


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

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

        Reviewed by Mark Lam.

        The copied space allocation in JSPropertyNameEnumerator::finishCreation()
        may end up triggering a GC, and so JSPropertyNameEnumerator::visitChildren()
        would get called while m_propertyNames was still null.

        This patch fixes that by having visitChildren() check for pointer nullity
        instead of the number of names, since that is non-zero even before the
        allocation is made.

        Added a test that induces GC during JSPropertyNameEnumerator construction
        to cover this bug.

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

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

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

        GC timers should carry on gracefully when Heap claims it grew from GC.
        <https://webkit.org/b/151521>

        Reviewed by Mark Lam.

        TL;DR the Heap "extra memory" reporting APIs are hard to use 100% correctly
        and GC scheduling shouldn't break if someone makes a mistake with it.

        The JSC::Heap allows you to report an extra memory cost for any GC object.
        This is reported first when allocating the memory, and then each time the
        object is visited during the marking phase.

        When reporting an allocation, it's added to the Heap's "bytes allocated in
        this cycle" counter. This contributes to the computed heap size at the start
        of a collection.

        When visiting a GC object that reports extra memory, it's added to the Heap's
        "extra memory visited in this collection" counter. This contributes to the
        computed heap size at the end of a collection.

        As you can see, this means that visiting more memory than we said we allocated
        can lead to the Heap thinking it's bigger after a collection than it was before.

        Clients of this API do some sketchy things to compute costs, for instance
        StringImpl cost is determined by dividing the number of bytes used for the
        characters, and dividing it by the StringImpl's ref count. Since a JSString
        could be backed by any StringImpl, any code that modifies a StringImpl's
        ref count during collection will change the extra memory reported by all
        JSString objects that wrap that StringImpl.

        So anyways...

        The object death rate, which is the basis for when to schedule the next
        collection is computed like so:

            deathRate = (sizeBeforeGC - sizeAfterGC) / sizeBeforeGC

        This patch adds a safety mechanism that returns a zero death rate when the Heap
        claims it grew from collection.

        * heap/EdenGCActivityCallback.cpp:
        (JSC::EdenGCActivityCallback::deathRate):
        * heap/FullGCActivityCallback.cpp:
        (JSC::FullGCActivityCallback::deathRate):

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

        New JSC tests introduced in r192664 fail on ARM.
        https://bugs.webkit.org/show_bug.cgi?id=151485

        Reviewed by Geoffrey Garen.

        The newly added tests are exposing some pre-existing bugs.  The bugs are tracked here:
            https://bugs.webkit.org/show_bug.cgi?id=151514
            https://bugs.webkit.org/show_bug.cgi?id=151515

        Skipping the tests for now.

        * tests/stress/op_div.js:
        * tests/stress/op_rshift.js:
        * tests/stress/op_urshift.js:

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

        B3 should have a Select opcode
        https://bugs.webkit.org/show_bug.cgi?id=150762

        Reviewed by Benjamin Poulain.

        This cleans up our conditional move implementation - specifically so that it distinguishes between
        comparing the low 32 bits of a GPR and all bits of a GPR - and fixes bugs with operand ordering. It
        then adds a Select opcode to B3 and adds all of the strength reduction and lowering magic that it
        needs. Finally this change implements FTL::Output::select() in terms of B3::Select.

        This patch lets us run Kraken/imaging-gaussian-blur. Running that benchmark using FTL+B3 is a 17%
        speed-up. The compile times go down dramatically (by about 7x) and code quality stays about the same.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::moveDoubleConditionally32):
        (JSC::MacroAssembler::moveDoubleConditionally64):
        (JSC::MacroAssembler::moveDoubleConditionallyTest32):
        (JSC::MacroAssembler::moveDoubleConditionallyTest64):
        (JSC::MacroAssembler::moveDoubleConditionallyDouble):
        (JSC::MacroAssembler::lea):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::move):
        (JSC::MacroAssemblerX86Common::moveConditionallyDouble):
        (JSC::MacroAssemblerX86Common::zeroExtend32ToPtr):
        (JSC::MacroAssemblerX86Common::moveConditionally32):
        (JSC::MacroAssemblerX86Common::moveConditionallyTest32):
        (JSC::MacroAssemblerX86Common::set32):
        (JSC::MacroAssemblerX86Common::cmov):
        (JSC::MacroAssemblerX86Common::moveConditionally): Deleted.
        (JSC::MacroAssemblerX86Common::moveConditionallyTest): Deleted.
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::branchNeg64):
        (JSC::MacroAssemblerX86_64::moveConditionally64):
        (JSC::MacroAssemblerX86_64::moveConditionallyTest64):
        (JSC::MacroAssemblerX86_64::abortWithReason):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::cmovl_rr):
        (JSC::X86Assembler::cmovl_mr):
        (JSC::X86Assembler::cmovel_rr):
        (JSC::X86Assembler::cmovnel_rr):
        (JSC::X86Assembler::cmovpl_rr):
        (JSC::X86Assembler::cmovnpl_rr):
        (JSC::X86Assembler::cmovq_rr):
        (JSC::X86Assembler::cmovq_mr):
        (JSC::X86Assembler::cmoveq_rr):
        (JSC::X86Assembler::cmovneq_rr):
        (JSC::X86Assembler::cmovpq_rr):
        (JSC::X86Assembler::cmovnpq_rr):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createCompare):
        (JSC::B3::Air::LowerToAir::createSelect):
        (JSC::B3::Air::LowerToAir::marshallCCallArgument):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3MoveConstants.cpp:
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::checkOpcode):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/B3ValueKey.cpp:
        (JSC::B3::ValueKey::dump):
        (JSC::B3::ValueKey::materialize):
        * b3/B3ValueKey.h:
        (JSC::B3::ValueKey::ValueKey):
        (JSC::B3::ValueKey::hash):
        (JSC::B3::ValueKey::operator bool):
        * b3/B3ValueKeyInlines.h:
        (JSC::B3::ValueKey::ValueKey):
        (JSC::B3::ValueKey::child):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testTruncSExt32):
        (JSC::B3::testBasicSelect):
        (JSC::B3::testSelectTest):
        (JSC::B3::testSelectCompareDouble):
        (JSC::B3::testSelectDouble):
        (JSC::B3::testSelectDoubleTest):
        (JSC::B3::testSelectDoubleCompareDouble):
        (JSC::B3::zero):
        (JSC::B3::run):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::testIsZeroPtr):
        (JSC::FTL::Output::testNonZeroPtr):
        (JSC::FTL::Output::select):
        (JSC::FTL::Output::extractValue):
        (JSC::FTL::Output::fence):

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

        [JSC] Add Air lowering to BitNot() for Xor(value, -1)
        https://bugs.webkit.org/show_bug.cgi?id=151474

        Reviewed by Filip Pizlo.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::not32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::not64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::notq_r):
        (JSC::X86Assembler::notq_m):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3ReduceStrength.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testNegValueSubOne):
        (JSC::B3::testNegValueSubOne32):
        (JSC::B3::testBitNotArg):
        (JSC::B3::testBitNotImm):
        (JSC::B3::testBitNotMem):
        (JSC::B3::testBitNotArg32):
        (JSC::B3::testBitNotImm32):
        (JSC::B3::testBitNotMem32):
        (JSC::B3::testBitNotOnBooleanAndBranch32):
        (JSC::B3::int64Operands):
        (JSC::B3::int32Operands):
        (JSC::B3::run):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::bitNot):

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

        Super use should be recorded in per-function scope
        https://bugs.webkit.org/show_bug.cgi?id=151500

        Reviewed by Geoffrey Garen.

        "super" use is prohibited under the non-constructor / non-class-method-related functions.
        This "super" use should be recorded in per-function scope to check its incorrect use after
        parsing a function.
        Currently, we accidentally record it to a lexical current scope. So when using "super" inside
        a block scope, our "super" use guard miss it.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseMemberExpression):
        * parser/Parser.h:
        (JSC::Parser::currentVariableScope):
        (JSC::Parser::currentFunctionScope):
        (JSC::Parser::declareVariable):
        * tests/stress/super-in-lexical-scope.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntaxError.test):

2015-11-20  Chris Dumez  <cdumez@apple.com>

        Caching of properties on objects that have named property getters is sometimes incorrect
        https://bugs.webkit.org/show_bug.cgi?id=151453
        <rdar://problem/23049343>

        Reviewed by Gavin Barraclough.

        Add new GetOwnPropertySlotIsImpureForPropertyAbsence TypeInfo flag to be
        used by objects that have a non-'OverrideBuiltins' named property getter.
        This flag prevents caching of properties that are missing as a named
        property with this name may later become available.

        Objects with an 'OverrideBuiltins' named property getter will keep using
        the GetOwnPropertySlotIsImpure TypeInfo flag, which prevents all property
        caching since named properties can override own properties or properties
        on the prototype.

        * bytecode/ComplexGetStatus.cpp:
        (JSC::ComplexGetStatus::computeFor):
        * bytecode/PropertyCondition.cpp:
        (JSC::PropertyCondition::isStillValid):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryRepatchIn):
        * jsc.cpp:
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::getOwnPropertySlotIsImpure):
        (JSC::TypeInfo::getOwnPropertySlotIsImpureForPropertyAbsence):
        (JSC::TypeInfo::prohibitsPropertyCaching): Deleted.
        * runtime/Structure.h:

2015-11-19  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION(r189433) Web Inspector: JSContext inspection exceptions should include native call frames by default
        https://bugs.webkit.org/show_bug.cgi?id=151479

        Reviewed by Brian Burg.

        * inspector/JSGlobalObjectInspectorController.h:
        Value accidentally got flipped when moving to initializer syntax.

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

        [ES6] Add support for rest parameters
        https://bugs.webkit.org/show_bug.cgi?id=38408

        Reviewed by Geoffrey Garen.

        This patch implements rest parameters from the ES6 spec.
        http://www.ecma-international.org/ecma-262/6.0/index.html#sec-function-definitions

        We implement the rest parameter as a new AST node. This AST node
        lowers to "op_new_array X, op_copy_rest X". Note
        that the op_copy_rest opcode does not have a result.
        The bulk of this patch is implementing op_copy_rest.
        This patch implements this in all four tiers in a straight forward way.
        The opcode is implemented as a C call that will read the pertinent
        arguments from the call frame and fill them into the array.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
        (JSC::BytecodeGenerator::invalidateForInContextForLocal):
        (JSC::BytecodeGenerator::emitRestParameter):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::AssignmentElementNode::toString):
        (JSC::RestParameterNode::collectBoundIdentifiers):
        (JSC::RestParameterNode::toString):
        (JSC::RestParameterNode::bindValue):
        (JSC::RestParameterNode::emit):
        (JSC::SpreadExpressionNode::emitBytecode):
        * 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/DFGNode.h:
        (JSC::DFG::Node::setEpoch):
        (JSC::DFG::Node::numberOfArgumentsToSkip):
        (JSC::DFG::Node::dumpChildren):
        * 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::compileCreateClonedArguments):
        (JSC::DFG::SpeculativeJIT::compileCopyRest):
        (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/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateClonedArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCopyRest):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewObject):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_create_out_of_band_arguments):
        (JSC::JIT::emit_op_copy_rest):
        * jit/JITOperations.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createBindingLocation):
        (JSC::ASTBuilder::createRestParameter):
        (JSC::ASTBuilder::createAssignmentElement):
        * parser/NodeConstructors.h:
        (JSC::AssignmentElementNode::AssignmentElementNode):
        (JSC::RestParameterNode::RestParameterNode):
        (JSC::DestructuringAssignmentNode::DestructuringAssignmentNode):
        * parser/Nodes.h:
        (JSC::DestructuringPatternNode::isBindingNode):
        (JSC::DestructuringPatternNode::isRestParameter):
        (JSC::DestructuringPatternNode::emitDirectBinding):
        (JSC::RestParameterNode::name):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::declareRestOrNormalParameter):
        (JSC::Parser<LexerType>::createBindingPattern):
        (JSC::Parser<LexerType>::parseFormalParameters):
        * parser/Parser.h:
        (JSC::Parser::strictMode):
        (JSC::Parser::isValidStrictMode):
        (JSC::Parser::declareParameter):
        (JSC::Parser::breakIsValid):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        * tests/es6.yaml:
        * tests/stress/rest-parameter-and-default-arguments.js: Added.
        (assert):
        (shouldThrowTDZ):
        (foo):
        (baz):
        (i.shouldThrowTDZ):
        * tests/stress/rest-parameter-basics.js: Added.
        (assert):
        (foo):
        (bar):
        (capture):
        (baz):
        (jaz):
        (kaz):
        (raz):
        (restLength):
        (testArgumentsObject):
        (strictModeLikeArgumentsObject):
        * tests/stress/rest-parameter-inlined.js: Added.
        (assert):
        (bar):
        (foo):
        (baz):
        (jaz):

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

        B3 should have a story for Ext/Trunc strength reduction
        https://bugs.webkit.org/show_bug.cgi?id=151464

        Reviewed by Geoffrey Garen.

        The LLVM shift operations require the shift amount to have the same type as the shift base. The B3
        shift operations require the shift amount to be an Int32. DFG concurs with this. But the initial
        lowering should involve pretending the FTLOutput's shift operations still take an LLVM-style shift
        amount so that we don't regress FTL->LLVM performance. That means emitting an extra Trunc. That means
        that we want to be able to constant fold Trunc and be able to fold Trunc(ZExt).

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3ReduceStrength.cpp:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testSwitchChillDiv):
        (JSC::B3::testTruncFold):
        (JSC::B3::testZExt32):
        (JSC::B3::testZExt32Fold):
        (JSC::B3::testSExt32):
        (JSC::B3::testSExt32Fold):
        (JSC::B3::testTruncZExt32):
        (JSC::B3::testTruncSExt32):
        (JSC::B3::zero):
        (JSC::B3::run):
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::store):
        (JSC::FTL::Output::baseIndex):
        (JSC::FTL::Output::branch):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::bitAnd):
        (JSC::FTL::Output::bitOr):
        (JSC::FTL::Output::bitXor):
        (JSC::FTL::Output::shl):
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::bitNot):
        (JSC::FTL::Output::insertElement):
        (JSC::FTL::Output::address):
        (JSC::FTL::Output::baseIndex):

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

        Create correctness tests for binary snippet operators.
        https://bugs.webkit.org/show_bug.cgi?id=151465

        Reviewed by Geoffrey Garen.

        Implement a common infrastructure for generating and running tests on binary
        operators.  Also re-implemented the op_add, op_sub, and op_mul tests to be based
        on this new infrastructure.

        * tests/stress/op_add.js:
        * tests/stress/op_mul.js:
        * tests/stress/op_sub.js:
        - These were reimplemented using binary-op-test.js.

        * tests/stress/op_div.js: Added.
        * tests/stress/op_mod.js: Added.

        * tests/stress/op_bitand.js: Added.
        * tests/stress/op_bitor.js: Added.
        * tests/stress/op_bitxor.js: Added.

        * tests/stress/op_lshift.js: Added.
        * tests/stress/op_rshift.js: Added.
        * tests/stress/op_urshift.js: Added.

        * tests/stress/resources/binary-op-test.js: Added.
        - Common code for generating and running tests.

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

        [JSC] Fix AssignmentElement parsing
        https://bugs.webkit.org/show_bug.cgi?id=151026

        Reviewed by Geoffrey Garen.

        When parsing an AssignmentPattern, any LeftHandSideExpression which
        is a valid assignment target is acceptable.

        Additionally, this change minimizes the amount of time spent
        re-parsing ObjectLiteral and ArrayLiterals, by parsing as an
        Expression first (the common case), and re-parsing only if the
        result is a valid ObjectLiteral or ArrayLiteral followed by an `=`,
        or if an error specifically indicates that the expression could
        have been parsed as an AssignmentPattern.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::AssignmentElementNode::collectBoundIdentifiers):
        (JSC::AssignmentElementNode::bindValue):
        (JSC::AssignmentElementNode::toString):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::isAssignmentLocation):
        (JSC::ASTBuilder::isObjectLiteral):
        (JSC::ASTBuilder::isArrayLiteral):
        (JSC::ASTBuilder::isObjectOrArrayLiteral):
        (JSC::ASTBuilder::createAssignmentElement):
        * parser/NodeConstructors.h:
        (JSC::AssignmentElementNode::AssignmentElementNode):
        * parser/Nodes.h:
        (JSC::ExpressionNode::isObjectLiteral):
        (JSC::ExpressionNode::isArrayLiteral):
        (JSC::AssignmentElementNode::assignmentTarget):
        (JSC::AssignmentElementNode::divotStart):
        (JSC::AssignmentElementNode::divotEnd):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::createAssignmentElement):
        (JSC::Parser<LexerType>::parseBindingOrAssignmentElement):
        (JSC::Parser<LexerType>::parseAssignmentElement):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseProperty):
        * parser/Parser.h:
        (JSC::Parser::ExpressionErrorClassifier::ExpressionErrorClassifier):
        (JSC::Parser::ExpressionErrorClassifier::~ExpressionErrorClassifier):
        (JSC::Parser::ExpressionErrorClassifier::classifyExpressionError):
        (JSC::Parser::ExpressionErrorClassifier::indicatesPossiblePattern):
        (JSC::Parser::classifyExpressionError):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):
        * tests/es6.yaml:
        * tests/es6/destructuring_assignment_non_simple_target.js: Added.
        (test.):
        (test):
        * tests/es6/destructuring_initializer_scoping.js: Added.
        (test.tester):
        * tests/stress/destructuring-assignment-syntax.js: Added.
        (testSyntax):
        (testSyntaxError):
        * tests/stress/rest-elements.js:
        (shouldThrow): Deleted.

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

        FTL->B3 lowering should support integer comparisons with the opcode abstracted and a few other things
        https://bugs.webkit.org/show_bug.cgi?id=151463

        Reviewed by Geoffrey Garen.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::signExt):
        (JSC::FTL::Output::zeroExt):
        (JSC::FTL::Output::zeroExtPtr):
        (JSC::FTL::Output::fpToInt):
        (JSC::FTL::Output::fpToUInt):
        (JSC::FTL::Output::fpToInt32):
        (JSC::FTL::Output::baseIndex):
        (JSC::FTL::Output::absolute):
        (JSC::FTL::Output::load32NonNegative):
        (JSC::FTL::Output::equal):
        (JSC::FTL::Output::notEqual):
        (JSC::FTL::Output::above):
        (JSC::FTL::Output::lessThan):
        (JSC::FTL::Output::lessThanOrEqual):
        (JSC::FTL::Output::doubleEqual):
        (JSC::FTL::Output::doubleNotEqualOrUnordered):
        (JSC::FTL::Output::doubleLessThan):
        (JSC::FTL::Output::icmp): Deleted.
        (JSC::FTL::Output::fcmp): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEq):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareLess):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareLessEq):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareGreater):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareGreaterEq):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileLogicalNot):
        (JSC::FTL::DFG::LowerDFGToLLVM::baseIndex):
        (JSC::FTL::DFG::LowerDFGToLLVM::compare):
        (JSC::FTL::DFG::LowerDFGToLLVM::speculateTruthyObject):
        (JSC::FTL::DFG::LowerDFGToLLVM::nonSpeculativeCompare):

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

        [JSC] When the iterated allocator is forced to spill, nuke the Moves that were already proven to be useless
        https://bugs.webkit.org/show_bug.cgi?id=151461

        Reviewed by Filip Pizlo.

        Previously, when we had to spill, we were just inserting new Spill() and Fill()
        in code while everything else remained identical.

        Coalescing moves is a big part of the algorithm and takes a non-trivial time.
        Since we were never removing Moves until reaching a successful coloring, we were
        paying that cost with every single iteration.

        With this patch, I keep a copy of the coalescing aliases when we make the first
        potential spill decision. Before doing that, we have only simplified and coalesced
        vertices that are provably colorable regardless of the other vertices' colors
        (because their degree is <K, potentially after other edges were removed by simplification).

        If we end up actually spilling, I use the old aliases to simplify the blocks if possible.

        This is a 5% progression on "testComplex(64, 384)".

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::getAliasWhenSpilling):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::coalesce):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::assignColors):
        (JSC::B3::Air::addSpillAndFillToProgram):
        (JSC::B3::Air::iteratedRegisterCoalescingOnType):
        (JSC::B3::Air::iteratedRegisterCoalescing):

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

        Fix FTL->B3 lowering of Phi
        https://bugs.webkit.org/show_bug.cgi?id=151460

        Reviewed by Geoffrey Garen.

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

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

        FTL->B3 lowering should support lazy slow paths, patchpoints, all integer comparisons, and more load/stores
        https://bugs.webkit.org/show_bug.cgi?id=151459

        Reviewed by Benjamin Poulain.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::absolute):
        (JSC::FTL::Output::load8SignExt32):
        (JSC::FTL::Output::load8ZeroExt32):
        (JSC::FTL::Output::load16SignExt32):
        (JSC::FTL::Output::load16ZeroExt32):
        (JSC::FTL::Output::load32):
        (JSC::FTL::Output::load64):
        (JSC::FTL::Output::loadPtr):
        (JSC::FTL::Output::loadDouble):
        (JSC::FTL::Output::store32):
        (JSC::FTL::Output::store64):
        (JSC::FTL::Output::storePtr):
        (JSC::FTL::Output::storeDouble):
        (JSC::FTL::Output::ascribeRange):
        (JSC::FTL::Output::nonNegative32):
        (JSC::FTL::Output::load32NonNegative):
        (JSC::FTL::Output::icmp):
        (JSC::FTL::Output::equal):
        (JSC::FTL::Output::notEqual):
        (JSC::FTL::Output::above):
        (JSC::FTL::Output::aboveOrEqual):
        (JSC::FTL::Output::below):
        (JSC::FTL::Output::belowOrEqual):
        (JSC::FTL::Output::greaterThan):
        (JSC::FTL::Output::greaterThanOrEqual):
        (JSC::FTL::Output::lessThan):
        (JSC::FTL::Output::lessThanOrEqual):
        (JSC::FTL::Output::fcmp):
        (JSC::FTL::Output::doubleEqual):
        (JSC::FTL::Output::speculateMul):
        (JSC::FTL::Output::patchpoint):
        (JSC::FTL::Output::trap):
        (JSC::FTL::Output::anchor):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):

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

        FTL->B3 lowering should support absolute(), double comparisons, and intToDouble()
        https://bugs.webkit.org/show_bug.cgi?id=151457

        Reviewed by Benjamin Poulain.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::fpToInt32):
        (JSC::FTL::Output::fpToUInt32):
        (JSC::FTL::Output::intToFP):
        (JSC::FTL::Output::intToDouble):
        (JSC::FTL::Output::unsignedToFP):
        (JSC::FTL::Output::unsignedToDouble):
        (JSC::FTL::Output::intCast):
        (JSC::FTL::Output::baseIndex):
        (JSC::FTL::Output::absolute):
        (JSC::FTL::Output::load8SignExt32):
        (JSC::FTL::Output::load8ZeroExt32):
        (JSC::FTL::Output::lessThanOrEqual):
        (JSC::FTL::Output::fcmp):
        (JSC::FTL::Output::doubleEqual):
        (JSC::FTL::Output::doubleNotEqualOrUnordered):
        (JSC::FTL::Output::doubleLessThan):
        (JSC::FTL::Output::doubleLessThanOrEqual):
        (JSC::FTL::Output::doubleGreaterThan):
        (JSC::FTL::Output::doubleGreaterThanOrEqual):
        (JSC::FTL::Output::doubleEqualOrUnordered):
        (JSC::FTL::Output::doubleNotEqual):
        (JSC::FTL::Output::doubleLessThanOrUnordered):
        (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
        (JSC::FTL::Output::doubleGreaterThanOrUnordered):
        (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
        (JSC::FTL::Output::isZero32):
        (JSC::FTL::Output::notZero32):

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

        FTL->B3 lowering should support checked int math
        https://bugs.webkit.org/show_bug.cgi?id=151451

        Reviewed by Saam Barati.

        Adds lowering of ArithAdd/Sub/Mul to CheckAdd/Sub/Mul. Includes a nice refactoring of the OSR exit
        code that made this a lot easier. Also needed to implement a few other ops in FTL::Output.

        I ended up renaming "check" to "speculate" in FTL::Output, because it already had a thing called
        "check". The FTL terminology for side-exit is "speculate", so I think that this is appropriate.

        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::sensibleDoubleToInt):
        (JSC::FTL::Output::signExt):
        (JSC::FTL::Output::zeroExt):
        (JSC::FTL::Output::zeroExtPtr):
        (JSC::FTL::Output::fpToInt):
        (JSC::FTL::Output::fpToUInt):
        (JSC::FTL::Output::unsignedToFP):
        (JSC::FTL::Output::unsignedToDouble):
        (JSC::FTL::Output::intCast):
        (JSC::FTL::Output::castToInt32):
        (JSC::FTL::Output::fpCast):
        (JSC::FTL::Output::intToPtr):
        (JSC::FTL::Output::ptrToInt):
        (JSC::FTL::Output::unreachable):
        (JSC::FTL::Output::speculate):
        (JSC::FTL::Output::speculateAdd):
        (JSC::FTL::Output::speculateSub):
        (JSC::FTL::Output::speculateMul):
        (JSC::FTL::Output::trap):
        (JSC::FTL::Output::check): Deleted.
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):

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

        JIT snippet generator JumpLists should be returned as references.
        https://bugs.webkit.org/show_bug.cgi?id=151445

        Reviewed by Gavin Barraclough.

        The JumpLists were being returned by value.  As a result, new jumps added to
        them in the client are actually added to a temporary copy and promptly discarded.
        Those jumps never get linked, resulting in infinite loops in DFG generated code
        that used the snippets.

        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::endJumpList):
        (JSC::JITAddGenerator::slowPathJumpList):
        * jit/JITMulGenerator.h:
        (JSC::JITMulGenerator::endJumpList):
        (JSC::JITMulGenerator::slowPathJumpList):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::endJumpList):
        (JSC::JITSubGenerator::slowPathJumpList):

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

        Unreviewed CLOOP buildfix after r192624.

        * runtime/MemoryStatistics.cpp:
        (JSC::globalMemoryStatistics):
        * runtime/MemoryStatistics.h:

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

        Remove unused LLVM API functions
        https://bugs.webkit.org/show_bug.cgi?id=151184

        Reviewed by Filip Pizlo.

        * ftl/FTLAbbreviations.h:
        (JSC::FTL::typeOf): Deleted.
        (JSC::FTL::getElementType): Deleted.
        (JSC::FTL::getNamedFunction): Deleted.
        (JSC::FTL::removeFunctionAttr): Deleted.
        (JSC::FTL::getLinkage): Deleted.
        (JSC::FTL::setVisibility): Deleted.
        (JSC::FTL::isDeclaration): Deleted.
        (JSC::FTL::linkModules): Deleted.
        (JSC::FTL::getValueName): Deleted.
        (JSC::FTL::getNamedGlobal): Deleted.
        (JSC::FTL::getFirstGlobal): Deleted.
        (JSC::FTL::getNextGlobal): Deleted.
        (JSC::FTL::createMemoryBufferWithContentsOfFile): Deleted.
        (JSC::FTL::parseBitcodeInContext): Deleted.
        (JSC::FTL::disposeMemoryBuffer): Deleted.
        (JSC::FTL::getParamTypes): Deleted.
        (JSC::FTL::constIntToPtr): Deleted.
        (JSC::FTL::constBitCast): Deleted.
        * llvm/LLVMAPIFunctions.h:

2015-11-19  Gyuyoung Kim  <gyuyoung.kim@webkit.org>

        Remove unnecessary PLATFORM(EFL) macro in globalMemoryStatistics()
        https://bugs.webkit.org/show_bug.cgi?id=151301

        Reviewed by Csaba Osztrogonác.

        EXECUTABLE_ALLOCATOR_FIXED is enabled on EFL port. So we don't need to keep
        PLATFORM(EFL) macro anymore. Besides ENABLE(EXECUTABLE_ALLOCATOR_FIXED) guard
        isn't related with ExecutableAllocator::committedByteCount() closely. So this patch
        removes it as well.

        * runtime/MemoryStatistics.cpp:
        (JSC::globalMemoryStatistics):

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

        [JSC] Add bitwise Double-Int conversion to B3
        https://bugs.webkit.org/show_bug.cgi?id=151432

        Reviewed by Filip Pizlo.

        This is needed for boxing/unboxing doubles.

        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::bitwiseCastConstant):
        * b3/B3Const64Value.h:
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::bitwiseCastConstant):
        * b3/B3ConstDoubleValue.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.cpp:
        (WTF::printInternal):
        * b3/B3Opcode.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::bitwiseCastConstant):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testDoubleArgToInt64BitwiseCast):
        (JSC::B3::testDoubleImmToInt64BitwiseCast):
        (JSC::B3::testTwoBitwiseCastOnDouble):
        (JSC::B3::testBitwiseCastOnDoubleInMemory):
        (JSC::B3::testInt64BArgToDoubleBitwiseCast):
        (JSC::B3::testInt64BImmToDoubleBitwiseCast):
        (JSC::B3::testTwoBitwiseCastOnInt64):
        (JSC::B3::testBitwiseCastOnInt64InMemory):
        (JSC::B3::int64Operands):
        (JSC::B3::run):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::bitCast):

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

        [JSC] Add some missing load/store to FTLB3Output
        https://bugs.webkit.org/show_bug.cgi?id=151427

        Reviewed by Filip Pizlo.

        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::load8SignExt32):
        (JSC::FTL::Output::load8ZeroExt32):
        (JSC::FTL::Output::load16SignExt32):
        (JSC::FTL::Output::load16ZeroExt32):
        (JSC::FTL::Output::loadFloatToDouble):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::load32):
        (JSC::FTL::Output::loadPtr):
        (JSC::FTL::Output::loadDouble):
        (JSC::FTL::Output::load8SignExt32): Deleted.
        (JSC::FTL::Output::load8ZeroExt32): Deleted.
        (JSC::FTL::Output::load16SignExt32): Deleted.
        (JSC::FTL::Output::load16ZeroExt32): Deleted.
        (JSC::FTL::Output::loadFloatToDouble): Deleted.

2015-11-18  Benjamin Poulain  <benjamin@webkit.org>

        Fix typos in r192605

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

2015-11-18  Filip Pizlo  <fpizlo@apple.com> and Benjamin Poulain  <bpoulain@apple.com>

        FTL should be able to compile a small function with B3
        https://bugs.webkit.org/show_bug.cgi?id=151423

        Reviewed by Filip Pizlo.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * ftl/FTLAbbreviatedTypes.h:
        * ftl/FTLB3Output.cpp:
        (JSC::FTL::Output::Output):
        (JSC::FTL::Output::~Output):
        (JSC::FTL::Output::initialize):
        (JSC::FTL::Output::appendTo):
        (JSC::FTL::Output::lockedStackSlot):
        (JSC::FTL::Output::load):
        (JSC::FTL::Output::store):
        (JSC::FTL::Output::branch):
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::newBlock):
        (JSC::FTL::Output::setOrigin):
        (JSC::FTL::Output::origin):
        (JSC::FTL::Output::framePointer):
        (JSC::FTL::Output::constBool):
        (JSC::FTL::Output::constInt32):
        (JSC::FTL::Output::constIntPtr):
        (JSC::FTL::Output::constInt64):
        (JSC::FTL::Output::constDouble):
        (JSC::FTL::Output::upsilon):
        (JSC::FTL::Output::phi):
        (JSC::FTL::Output::add):
        (JSC::FTL::Output::sub):
        (JSC::FTL::Output::mul):
        (JSC::FTL::Output::neg):
        (JSC::FTL::Output::doubleAdd):
        (JSC::FTL::Output::doubleSub):
        (JSC::FTL::Output::doubleMul):
        (JSC::FTL::Output::doubleDiv):
        (JSC::FTL::Output::doubleNeg):
        (JSC::FTL::Output::bitAnd):
        (JSC::FTL::Output::bitOr):
        (JSC::FTL::Output::bitXor):
        (JSC::FTL::Output::shl):
        (JSC::FTL::Output::aShr):
        (JSC::FTL::Output::lShr):
        (JSC::FTL::Output::load64):
        (JSC::FTL::Output::store32):
        (JSC::FTL::Output::store64):
        (JSC::FTL::Output::storePtr):
        (JSC::FTL::Output::storeDouble):
        (JSC::FTL::Output::addPtr):
        (JSC::FTL::Output::address):
        (JSC::FTL::Output::below):
        (JSC::FTL::Output::isZero32):
        (JSC::FTL::Output::notZero32):
        (JSC::FTL::Output::isZero64):
        (JSC::FTL::Output::notZero64):
        (JSC::FTL::Output::isNull):
        (JSC::FTL::Output::notNull):
        (JSC::FTL::Output::testIsZero32):
        (JSC::FTL::Output::testNonZero32):
        (JSC::FTL::Output::testIsZero64):
        (JSC::FTL::Output::testNonZero64):
        (JSC::FTL::Output::testIsZeroPtr):
        (JSC::FTL::Output::testNonZeroPtr):
        (JSC::FTL::Output::call):
        (JSC::FTL::Output::operation):
        (JSC::FTL::Output::jump):
        (JSC::FTL::Output::branch):
        (JSC::FTL::Output::ret):
        (JSC::FTL::Output::unreachable):
        (JSC::FTL::Output::check):
        (JSC::FTL::Output::anchor):
        (JSC::FTL::Output::addIncomingToPhi):
        (JSC::FTL::Output::~Output): Deleted.
        (JSC::FTL::Output::appendTo): Deleted.
        (JSC::FTL::Output::param): Deleted.
        (JSC::FTL::Output::load): Deleted.
        (JSC::FTL::Output::store): Deleted.
        (JSC::FTL::Output::store16): Deleted.
        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        (JSC::FTL::CommonValues::initializeConstants):
        * ftl/FTLCommonValues.h:
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::createPhiVariables):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::safelyInvalidateAfterTermination):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePhi):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileToThis):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArrayifyToStructure):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutByVal):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutGetterSetterById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorByVal):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArrayPush):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArrayPop):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateActivation):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateScopedArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateClonedArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArray):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayBuffer):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileToPrimitive):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileLoadVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileSwitch):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileHasIndexedProperty):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileHasGenericProperty):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileHasStructureProperty):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetDirectPname):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetPropertyEnumerator):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileToIndexString):
        (JSC::FTL::DFG::LowerDFGToLLVM::didOverflowStack):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToLLVM::reallocatePropertyStorage):
        (JSC::FTL::DFG::LowerDFGToLLVM::getById):
        (JSC::FTL::DFG::LowerDFGToLLVM::nonSpeculativeCompare):
        (JSC::FTL::DFG::LowerDFGToLLVM::contiguousPutByValOutOfBounds):
        (JSC::FTL::DFG::LowerDFGToLLVM::switchStringSlow):
        (JSC::FTL::DFG::LowerDFGToLLVM::doubleToInt32):
        (JSC::FTL::DFG::LowerDFGToLLVM::sensibleDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        (JSC::FTL::DFG::LowerDFGToLLVM::jsValueToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToLLVM::doubleToStrictInt52):
        (JSC::FTL::DFG::LowerDFGToLLVM::vmCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):
        (JSC::FTL::DFG::LowerDFGToLLVM::probe):
        (JSC::FTL::DFG::LowerDFGToLLVM::crash):
        (JSC::FTL::lowerDFGToLLVM):
        (JSC::FTL::DFG::LowerDFGToLLVM::vmCallNoExceptions): Deleted.
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::sensibleDoubleToInt):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::ceil64):
        (JSC::FTL::Output::ctlz32):
        (JSC::FTL::Output::addWithOverflow32):
        (JSC::FTL::Output::subWithOverflow32):
        (JSC::FTL::Output::mulWithOverflow32):
        (JSC::FTL::Output::addWithOverflow64):
        (JSC::FTL::Output::subWithOverflow64):
        (JSC::FTL::Output::mulWithOverflow64):
        (JSC::FTL::Output::doubleAbs):
        (JSC::FTL::Output::doubleSin):
        (JSC::FTL::Output::doubleCos):
        (JSC::FTL::Output::doublePow):
        (JSC::FTL::Output::doublePowi):
        (JSC::FTL::Output::doubleSqrt):
        (JSC::FTL::Output::doubleLog):
        (JSC::FTL::Output::call):
        (JSC::FTL::Output::trap):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State): Deleted.
        * ftl/FTLState.h:
        * ftl/FTLWeight.h:
        (JSC::FTL::Weight::frequencyClass):

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

        There is a bug when default parameter values are mixed with destructuring parameter values
        https://bugs.webkit.org/show_bug.cgi?id=151369

        Reviewed by Geoffrey Garen and Mark Lam.

        Relanding this after a rollout.

        This patch changes our parser to no longer declare destructuring
        parameters as "var"s. This is a weird bug that just happened
        to work in a world without default parameter values. In a world with
        default parameter values this is just completely wrong. It would
        incorrectly transform this program:
        ```function foo(a = function() { b = 40; }, {b}) { a(); return b; }; foo(undefined, {b: 42}); // Should return 40```
        into
        ```function foo(a = function() { b = 40; }, {b}) { var b; a(); return b; }; foo(undefined, {b:42}); // Returns 42, not 40.```
        Which is wrong because we end up with two distinct bindings of "b" when
        there should only be one.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::createBindingPattern):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        * parser/Parser.h:
        (JSC::Scope::declareParameter):
        (JSC::Scope::getUsedVariables):
        (JSC::Parser::strictMode):
        (JSC::Parser::isValidStrictMode):
        (JSC::Parser::declareParameter):
        (JSC::Parser::breakIsValid):
        (JSC::Scope::declareBoundParameter): Deleted.
        (JSC::Parser::declareBoundParameter): Deleted.
        * tests/stress/es6-default-parameters.js:

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

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

        Reviewed by Geoffrey Garen.

        Benchmarks shows that perf is neutral on x86 and x86_64 with the DFG enabled.

        With the DFG disabled (relying on the baseline JIT for perf), LongSpider
        3d-morph shows a 7.6% regression.  However, there are other benchmarks that shows
        a progression e.g. on Kraken, audio-beat-detection and audio-fft.

        Upon inspection of the generated code for 3d-morph, the only differences is the
        added use of a scratch register for the result as well as a jump around the
        code that handles double types.  It does not look like we're generating bad code.
        I'll consider the perf acceptable in aggregate.

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

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::boxInt32):
        * jit/IntrinsicEmitter.cpp:
        (JSC::AccessCase::emitIntrinsicGetter):
        - Changed AssemblyHelpers::boxInt32() to take a TagRegistersMode.
          The pre-existing boxInt32() always assume that the tag registers are not
          available.  Since we should assume we have tag registers by default, I also
          changed all the other clients to explicitly specify a more of
          DoNotHaveTagRegisters.  That is except for the snippet generators that do have
          the tag registers.

        * jit/JIT.h:
        * jit/JITArithmetic.cpp:
        (JSC::JIT::compileBinaryArithOpSlowCase):
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emit_op_sub):
        (JSC::JIT::compileBinaryArithOp): Deleted.
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emitBinaryDoubleOp):
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emit_op_mul): Deleted.
        (JSC::JIT::emitSlow_op_mul): Deleted.
        * jit/JITMulGenerator.cpp: Added.
        (JSC::JITMulGenerator::generateFastPath):
        * jit/JITMulGenerator.h: Added.
        (JSC::JITMulGenerator::JITMulGenerator):
        (JSC::JITMulGenerator::didEmitFastPath):
        (JSC::JITMulGenerator::endJumpList):
        (JSC::JITMulGenerator::slowPathJumpList):

        * tests/stress/op_mul.js: Added.
        (o1.valueOf):
        (generateScenarios):
        (printScenarios):
        (testCases.func):
        (func):
        (initializeTestCases):
        (stringifyIfNeeded):
        (isIdentical):
        (runTest):
        - Tests that JIT op_mul results are equivalent to the expected values as
          defined by the LLINT.

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

        Remove some unnecessary jumps in snippet code.
        https://bugs.webkit.org/show_bug.cgi?id=151415

        Reviewed by Geoffrey Garen.

        Previously, the snippet generators always emit a jump at the end of the fast
        path.  In the baseline JIT and FTL, this results in a jump to the very next
        instruction.  I've change it to assume that the fast path will just fall thru,
        and let the client decide instead if it wants/needs a jump or not after the fast
        path.

        I also changed the generators to provide a didEmitFastPath() query explicitly
        declare if they actually generated the fast path, instead of having the client
        infer it from an empty endJumpList.

        Benchmarks show that perf is neutral with this change (tested on x86_64).

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::didEmitFastPath):
        (JSC::JITAddGenerator::endJumpList):
        (JSC::JITAddGenerator::slowPathJumpList):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emit_op_sub):
        * jit/JITSubGenerator.cpp:
        (JSC::JITSubGenerator::generateFastPath):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::didEmitFastPath):
        (JSC::JITSubGenerator::endJumpList):
        (JSC::JITSubGenerator::slowPathJumpList):

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

        Unreviewed, rolling out r192436 and r192586.
        https://bugs.webkit.org/show_bug.cgi?id=151417

        Caused a hang in the inspector and a crash @ google.com.
        (Requested by saamyjoon on #webkit).

        Reverted changesets:

        "Allow any LeftHandSideExpression as a valid
        AssignmentElement"
        https://bugs.webkit.org/show_bug.cgi?id=151026
        http://trac.webkit.org/changeset/192436

        "There is a bug when default parameter values are mixed with
        destructuring parameter values"
        https://bugs.webkit.org/show_bug.cgi?id=151369
        http://trac.webkit.org/changeset/192586

2015-11-17  Keith Miller  <keith_miller@apple.com>

        [JSC] TailCalls should not trigger assertion failures when running with the jsc profiler on.
        https://bugs.webkit.org/show_bug.cgi?id=151359

        Reviewed by Geoffrey Garen.

        If we have the profiler on when parsing tail calls in the dfg we would emit a CountExecutions node
        following a TailCall node as our bytecode for tail calls always emits a op_ret following an op_tail_call.
        This trips assertions that no nodes follow a terminal in a basic block. This patch fixes this issue by
        not emiting a CountExecutions when we have a tail call that is terminal i.e. the tail caller is not
        inlined into another function or the tail caller is inlined but is in tail position itself.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * tests/stress/tail-call-profiler.js: Added.
        (tail):
        (inlineTail):
        (inlineTailVarArgs):
        (inlineTailTernary):
        (body):

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

        [JSC] Make LBasicBlock into an alias for B3::BasicBlock. #ifdef anything that does not compile
        https://bugs.webkit.org/show_bug.cgi?id=151381

        Reviewed by Filip Pizlo.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLAbbreviatedTypes.h:
        * ftl/FTLAbbreviations.h:
        * ftl/FTLAbstractHeap.cpp:
        (JSC::FTL::AbstractHeap::decorateInstruction):
        (JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap):
        * ftl/FTLAbstractHeap.h:
        (JSC::FTL::AbstractHeap::AbstractHeap):
        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::newBlock):
        (JSC::FTL::Output::insertNewBlocksBefore):
        (JSC::FTL::Output::addIncomingToPhi):
        (JSC::FTL::Output::Output): Deleted.
        (JSC::FTL::Output::initialize): Deleted.
        * ftl/FTLCommonValues.cpp:
        (JSC::FTL::CommonValues::CommonValues):
        * ftl/FTLCommonValues.h:
        * ftl/FTLIntrinsicRepository.cpp:
        * ftl/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM):
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileForwardVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInstanceOf):
        (JSC::FTL::DFG::LowerDFGToLLVM::getById):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildSwitch):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        (JSC::FTL::DFG::LowerDFGToLLVM::crash):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::Output):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::addIncomingToPhi):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::dumpState):
        * ftl/FTLValueRange.cpp:
        (JSC::FTL::ValueRange::decorateInstruction):
        * ftl/FTLValueRange.h:
        (JSC::FTL::ValueRange::ValueRange):

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

        Implement the B3 equivalent of FTLCompile
        https://bugs.webkit.org/show_bug.cgi?id=151370

        Reviewed by Benjamin Poulain.

        This adds a B3 version of FTLCompile and gets the data structures related to installing an FTL
        compilation (i.e. the finalizer and JITCode) to be aware of B3. That requires stubbing a lot of stuff
        out and also simplifying a lot of code around having everything inside a single contiguous chunk of
        JIT code rather than some opaque JIT code handles plus miscellaneous side-codes. This compiles but
        crashes because lowering isn't done yet.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addDataSection):
        (JSC::B3::Procedure::calleeSaveRegisters):
        (JSC::B3::Procedure::addValueIndex):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::code):
        * ftl/FTLB3Compile.cpp: Added.
        (JSC::FTL::compile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExceptionHandlerManager.cpp:
        (JSC::FTL::ExceptionHandlerManager::callOperationExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::getByIdOSRExit):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::~JITCode):
        (JSC::FTL::JITCode::initializeB3Code):
        (JSC::FTL::JITCode::initializeExitThunks):
        (JSC::FTL::JITCode::addDataSection):
        (JSC::FTL::JITCode::initializeAddressForCall):
        (JSC::FTL::JITCode::initializeArityCheckEntrypoint):
        (JSC::FTL::JITCode::addressForCall):
        (JSC::FTL::JITCode::contains):
        (JSC::FTL::JITCode::exitThunks):
        (JSC::FTL::JITCode::ftl):
        * ftl/FTLJITCode.h:
        (JSC::FTL::JITCode::b3Code):
        (JSC::FTL::JITCode::handles):
        (JSC::FTL::JITCode::dataSections):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::codeSize):
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h:
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        (JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):

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

        There is a bug when default parameter values are mixed with destructuring parameter values
        https://bugs.webkit.org/show_bug.cgi?id=151369

        Reviewed by Geoffrey Garen and Mark Lam.

        This patch changes our parser to no longer declare destructuring
        parameters as "var"s. This is a weird bug that just happened
        to work in a world without default parameter values. In a world with
        default parameter values this is just completely wrong. It would
        incorrectly transform this program:
        ```function foo(a = function() { b = 40; }, {b}) { a(); return b; }; foo(undefined, {b: 42}); // Should return 40```
        into
        ```function foo(a = function() { b = 40; }, {b}) { var b; a(); return b; }; foo(undefined, {b:42}); // Returns 42, not 40.```
        Which is wrong because we end up with two distinct bindings of "b" when
        there should only be one.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::createBindingPattern):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        * parser/Parser.h:
        (JSC::Scope::declareParameter):
        (JSC::Scope::getUsedVariables):
        (JSC::Parser::strictMode):
        (JSC::Parser::isValidStrictMode):
        (JSC::Parser::declareParameter):
        (JSC::Parser::breakIsValid):
        (JSC::Scope::declareBoundParameter): Deleted.
        (JSC::Parser::declareBoundParameter): Deleted.
        * tests/stress/es6-default-parameters.js:

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

        [JSC] Untangle the dependencies on FTLAbbreviations a bit
        https://bugs.webkit.org/show_bug.cgi?id=151375

        Reviewed by Geoffrey Garen.

        FTLAbbreviations was included in many places but in most cases
        we just need the Abbreviated types. Update the #include accordingly.

        Also remove the IntrinsicRepository dependency from the B3Output.

        * ftl/FTLAbstractHeap.cpp:
        * ftl/FTLAbstractHeap.h:
        * ftl/FTLAbstractHeapRepository.cpp:
        * ftl/FTLB3Output.h:
        (JSC::FTL::Output::Output):
        (JSC::FTL::Output::stackmapIntrinsic):
        (JSC::FTL::Output::frameAddressIntrinsic):
        (JSC::FTL::Output::patchpointInt64Intrinsic):
        (JSC::FTL::Output::patchpointVoidIntrinsic):
        * ftl/FTLCommonValues.cpp:
        * ftl/FTLCommonValues.h:
        * ftl/FTLFormattedValue.h:
        * ftl/FTLIntrinsicRepository.cpp:
        * ftl/FTLOSRExit.h:
        * ftl/FTLOSRExitCompilationInfo.h:
        * ftl/FTLStackmapArgumentList.h:
        * ftl/FTLState.cpp:
        * ftl/FTLState.h:
        * ftl/FTLTypedPointer.h:

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

        B3::generate should separate out the final Air codegen, so that it can be done outside the Graph safepoint
        https://bugs.webkit.org/show_bug.cgi?id=151371

        Reviewed by Benjamin Poulain.

        One of the FTL optimizations is that while the expensive backend is running, we are at a "graph
        safepoint" that allows the VM to do GCs and other dangerous and time-sensitive things without
        waiting for the compilation thread. While in the safepoint, we cannot do anything that touches
        anything other than the backend's state. That means, for example, that we wouldn't be able to run
        any of the stackmap generation callbacks, since those need to mess with DFG state.

        That means that we need to separate the B3 pipeline into "preparation" and "generation".
        Preparation is all of the expensive stuff: all B3 phases, lowering to Air, all Air phases.
        Generation is just the part where we turn fully lowered Air into machine code. Generation also
        happens to be the part where we call stackmap generation callbacks. In other words, preparation
        is exactly the stuff that should go into the graph safepoint, while generation is the stuff that
        we want to do after we emerge from the safepoint.

        Because the tests were using the higher-level Compilation API, I didn't have to change any test
        code. The FTL will not use that high-level API.

        * b3/B3Compilation.cpp:
        (JSC::B3::Compilation::Compilation):
        * b3/B3Generate.cpp:
        (JSC::B3::prepareForGeneration):
        (JSC::B3::generate):
        (JSC::B3::generateToAir):
        * b3/B3Generate.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::LowerToAir):
        (JSC::B3::lowerToAir):
        * b3/B3LowerToAir.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::Procedure):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::takeByproducts):
        (JSC::B3::Procedure::code):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::proc):
        (JSC::B3::Air::Code::lastPhaseName):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::prepareForGeneration):
        (JSC::B3::Air::generate):
        * b3/air/AirGenerate.h:

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

        FTL::State should be able to refer to B3::Procedure

        Rubber stamped by Benjamin Poulain.

        * ftl/FTLState.h:

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

        [JSC] Add an empty FTLOutput for B3 that crashes on any operation
        https://bugs.webkit.org/show_bug.cgi?id=151366

        Reviewed by Filip Pizlo.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLB3Output.h: Added.
        * ftl/FTLAbbreviatedTypes.h:
        * ftl/FTLAbstractHeap.cpp:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::createPhiVariables):
        * ftl/FTLOutput.cpp:
        * ftl/FTLOutput.h:

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

        [JSC] Do not copy the adjacency list when we just need to manipulate them
        https://bugs.webkit.org/show_bug.cgi?id=151343

        Reviewed by Geoffrey Garen.

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

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

        [JSC] Remove FTLOutput operations that act directly on floats
        https://bugs.webkit.org/show_bug.cgi?id=151342

        Reviewed by Geoffrey Garen.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithFRound):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutByVal):
        * ftl/FTLOutput.cpp:
        (JSC::FTL::Output::store):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::loadFloatToDouble):
        (JSC::FTL::Output::fround):
        (JSC::FTL::Output::loadFloat): Deleted.

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

        Add a FTL_USES_B3 compile-time setting and set it to 0.

        Rubber stamped by Benjamin Poulain.

        * dfg/DFGCommon.h:

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

        CheckAdd/Mul should have commutativity optimizations in B3->Air lowering
        https://bugs.webkit.org/show_bug.cgi?id=151214

        Reviewed by Geoffrey Garen.

        This is an overhaul of CheckAdd/CheckSub/CheckMul that fixes bugs, improves codegen, and
        simplifies the contract between B3 and its client.

        Previously, the idea was that the operands to the Air BranchAdd/Sub/Mul matched the children of
        the B3 CheckAdd/Sub/Mul, or at least, that's what the B3::CheckSpecial would make you believe.
        This meant that B3/Air had to avoid optimizations that would break this protocol. This prevented
        commutativity optimizations on CheckAdd/Mul and it also prevented strength reduction from
        CheckMul(x, 2) to CheckAdd(x, x), for example. Those optimizations would break things because the
        client's Stackmap generation callback was allowed to assume that the first entry in params.reps
        was the first child. Also, there was a contract between B3 and its client that for CheckAdd/Sub,
        the client would undo the operation by doing the opposite operation with the params.reps[0] as the
        source and params.reps[1] as the destination.

        This not only prevented commutativity optimizations, it also led to bugs. Here are two bugs that
        we had:

        - Add(x, x) would not work. The client would be told to undo the add using %x as both the source
          and destination. The client would use a sub() instruction. The result would not be x - it would
          be zero.

        - Mul where the result got coalesced with one of the sources. You can't undo a multiplication, so
          you need to keep the inputs alive until after the result is computed - i.e. the inputs are late
          uses. I initially thought I worked around this by using a three-operand form of Mul, but of
          course that doesn't actually fix the issue.

        This patch fixes these issues comprehensively by introducing the following changes:

        The params.reps corresponding to the first two children of CheckAdd/Sub/Mul and the first child of
        Check are always garbage: if you want to know the values of those children in the slow path, pass
        them as additional stackmap children. This makes it clear to the compiler whose values you
        actually care about, and frees the compiler to reorder and commute the non-stackmap children.

        The "undo" of an Add or Sub is handled internally by B3: the client doesn't have to know anything
        about undoing. B3 does it. The contract is simply that if a B3::Value* is a stackmap child of a
        CheckXYZ, then the corresponding entry in params.reps inside the stackmap generator callback will
        contain the value of that Value*. For Add and Sub, B3 undoes the operation. For Add(x, x), the
        undo uses the carry flag and some shift magic. For Mul, B3 uses LateUse:

        A new kind of Arg::Role called Arg::LateUse is introduced: This kind of use means that the use
        happens at the start of the execution of the next instruction. None of the built-in Air opcodes
        use LateUse, but it is used by B3::CheckSpecial. We use it to implement CheckMul.

        Finally, this change fixes testComplex to actually create many live variables. This revealed a
        really dumb pathology in allocateStack(), and this patch fixes it. Basically, it's a bad idea to
        build interference graphs by repeatedly recreating the same cliques.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::test32):
        (JSC::MacroAssemblerX86Common::setCarry):
        (JSC::MacroAssemblerX86Common::invert):
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::Air::numB3Args):
        (JSC::B3::CheckSpecial::Key::Key):
        (JSC::B3::CheckSpecial::Key::dump):
        (JSC::B3::CheckSpecial::CheckSpecial):
        (JSC::B3::CheckSpecial::forEachArg):
        (JSC::B3::CheckSpecial::isValid):
        (JSC::B3::CheckSpecial::generate):
        (JSC::B3::CheckSpecial::dumpImpl):
        (JSC::B3::CheckSpecial::deepDumpImpl):
        * b3/B3CheckSpecial.h:
        (JSC::B3::CheckSpecial::Key::Key):
        (JSC::B3::CheckSpecial::Key::operator==):
        (JSC::B3::CheckSpecial::Key::operator!=):
        (JSC::B3::CheckSpecial::Key::opcode):
        (JSC::B3::CheckSpecial::Key::numArgs):
        (JSC::B3::CheckSpecial::Key::stackmapRole):
        (JSC::B3::CheckSpecial::Key::hash):
        * b3/B3CheckValue.cpp:
        (JSC::B3::CheckValue::~CheckValue):
        (JSC::B3::CheckValue::convertToAdd):
        (JSC::B3::CheckValue::CheckValue):
        * b3/B3CheckValue.h:
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::checkMulConstant):
        (JSC::B3::Const32Value::checkNegConstant):
        (JSC::B3::Const32Value::divConstant):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::checkMulConstant):
        (JSC::B3::Const64Value::checkNegConstant):
        (JSC::B3::Const64Value::divConstant):
        * b3/B3Const64Value.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::appendBinOp):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.h:
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::~PatchpointSpecial):
        (JSC::B3::PatchpointSpecial::forEachArg):
        (JSC::B3::PatchpointSpecial::isValid):
        * b3/B3ReduceStrength.cpp:
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        * b3/B3StackmapSpecial.h:
        * b3/B3StackmapValue.cpp:
        (JSC::B3::StackmapValue::append):
        (JSC::B3::StackmapValue::appendSomeRegister):
        (JSC::B3::StackmapValue::setConstrainedChild):
        * b3/B3StackmapValue.h:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::checkMulConstant):
        (JSC::B3::Value::checkNegConstant):
        (JSC::B3::Value::divConstant):
        * b3/B3Value.h:
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirArg.cpp:
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isAnyUse):
        (JSC::B3::Air::Arg::isEarlyUse):
        (JSC::B3::Air::Arg::isLateUse):
        (JSC::B3::Air::Arg::isDef):
        (JSC::B3::Air::Arg::forEachTmp):
        (JSC::B3::Air::Arg::isUse): Deleted.
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocate):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::hash):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::dump):
        (JSC::B3::Air::addSpillAndFillToProgram):
        (JSC::B3::Air::iteratedRegisterCoalescingOnType):
        (JSC::B3::Air::iteratedRegisterCoalescing):
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::Liveness::Liveness):
        (JSC::B3::Air::Liveness::LocalCalc::LocalCalc):
        (JSC::B3::Air::Liveness::LocalCalc::live):
        (JSC::B3::Air::Liveness::LocalCalc::takeLive):
        (JSC::B3::Air::Liveness::LocalCalc::execute):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirReportUsedRegisters.cpp:
        (JSC::B3::Air::reportUsedRegisters):
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/testb3.cpp:
        (JSC::B3::testMulArg):
        (JSC::B3::testMulArgStore):
        (JSC::B3::testMulAddArg):
        (JSC::B3::testMulArgs):
        (JSC::B3::testComplex):
        (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::testCheckSubImm):
        (JSC::B3::testCheckSubBadImm):
        (JSC::B3::testCheckSub):
        (JSC::B3::testCheckSub64):
        (JSC::B3::testCheckNeg):
        (JSC::B3::testCheckNeg64):
        (JSC::B3::testCheckMul):
        (JSC::B3::testCheckMulMemory):
        (JSC::B3::testCheckMul2):
        (JSC::B3::testCheckMul64):
        (JSC::B3::run):

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

        Air should lay out code optimally
        https://bugs.webkit.org/show_bug.cgi?id=150478

        Reviewed by Geoffrey Garen.

        This adds a phase that optimizes code layout using something that's worked well for me in the past.
        Basically, it just forces pre-ordering on the CFG, except that:

        - Blocks that are only reachable by Rare control flow are scheduled separately, all the way at the
          end.

        - Successors of the same frequency class are pushed in ascending order of frequency, so that the most
          frequent successor is scheduled immediately after.

        This also adds the requisite branch flipping, so that a branch's taken successor is not the
        fall-through block. We want the fall-through to be the not-taken successor if at all possible.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3BlockWorklist.h:
        * b3/B3GenericFrequentedBlock.h:
        (JSC::B3::GenericFrequentedBlock::frequency):
        (JSC::B3::GenericFrequentedBlock::isRare):
        (JSC::B3::GenericFrequentedBlock::dump):
        * b3/B3Procedure.h:
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isDoubleCond):
        (JSC::B3::Air::Arg::isCondition):
        (JSC::B3::Air::Arg::isSpecial):
        (JSC::B3::Air::Arg::asDoubleCondition):
        (JSC::B3::Air::Arg::isInvertible):
        (JSC::B3::Air::Arg::inverted):
        * b3/air/AirBasicBlock.h:
        (JSC::B3::Air::BasicBlock::index):
        (JSC::B3::Air::BasicBlock::setIndex):
        (JSC::B3::Air::BasicBlock::size):
        (JSC::B3::Air::BasicBlock::begin):
        (JSC::B3::Air::BasicBlock::containsPredecessor):
        (JSC::B3::Air::BasicBlock::frequency):
        * b3/air/AirBlockWorklist.h: Added.
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::findNextBlock):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::proc):
        (JSC::B3::Air::Code::at):
        (JSC::B3::Air::Code::operator[]):
        (JSC::B3::Air::Code::blockList):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirOptimizeBlockOrder.cpp: Added.
        (JSC::B3::Air::optimizeBlockOrder):
        * b3/air/AirOptimizeBlockOrder.h: Added.

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

        [JSC] JSPropertyNameEnumerator could be destructorless.
        <https://webkit.org/b/151242>

        Reviewed by Mark Lam.

        Make JSPropertyNameEnumerator destructorless and have it store the property names
        cache in CopiedSpace. This was the most popular occupant of 64-byte destructor cells
        in MarkedSpace, so making it destructorless gets rid of some ill-filled MarkedBlocks.

        This patch had two issues on 32-bit platforms when first landed:

        - Copied space allocations are required to be 8-byte divisible in size.

        - WriteBarrier<Unknown> and WriteBarrier<JSString> are not the same size on 32-bit;
          the former is a 64-bit EncodedJSValue internally, and the latter is a 32-bit JSCell*.
          My patch was reinterpret_cast'ing a WriteBarrier<JSString> to a WriteBarrier<Unknown>
          when passing to SlotVisitor::appendValues(), which led to invalid addresses getting
          marked and strings getting GC'd prematurely.

        * heap/CopyToken.h:
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::finishCreation):
        (JSC::JSPropertyNameEnumerator::visitChildren):
        (JSC::JSPropertyNameEnumerator::copyBackingStore):
        (JSC::JSPropertyNameEnumerator::destroy): Deleted.
        * runtime/JSPropertyNameEnumerator.h:

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

        Refactoring: move branchMul32's imm arg to the 3rd argument to be consistent.
        https://bugs.webkit.org/show_bug.cgi?id=151358

        Reviewed by Saam Barati.

        branch32, branchAdd32, and branchSub32 all have it as the 3rd argument.
        branchMul32 is the odd man out.  This patch makes branchMul32 consistent with
        the others.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::branchAdd32):
        (JSC::MacroAssembler::branchMul32):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::branchMul32):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::branchMul32):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::branchMul32):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::branchMul32):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::branchNeg32):
        (JSC::MacroAssemblerSH4::branchMul32):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::branchMul32):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_mul):

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

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

        Reviewed by Geoffrey Garen.

        No tests added because the op_add.js stress test already tests for correctness
        (using the LLINT as a reference).

        Performance-wise, the difference from the pre-existing DFG implementation is
        insignificant (at least as measured on x86 and x86_64).  We're moving forward
        with adopting this implementation because it unifies the 32-bit and 64-bit
        implementations, as well as lays ground work for a repatching inline cache
        implementation of op_add later.

        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::resultType):
        - Made an assertion less restrictive.  For ValueAdd operands, the DFG thinks that
          the operand can also be empty (though we should never see this in practice).

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        - Add fallback to unused type operands.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueAdd):
        - Introduce a common function to compile the ValueAdd node.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::JSValueOperand::JSValueOperand):
        - Add the forwarding constructor so that we can use Optional<JSValueOperand>.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        - Changed to use the common compileValueAdd().

        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::moveValue):
        - Similar to moveTrustedValue() but used for untrusted constants.

        * jit/JITAddGenerator.cpp:
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITAddGenerator.h:
        (JSC::JITAddGenerator::JITAddGenerator):
        - Updated to take the left or right operand as a constant.  This is necessary
          because the client should not be making assumptions about whether the snippet
          will determine the operation to be commutative or not.  Instead, the client
          should just pass in the operands and let the snippet do any operand order
          swapping if necessary.

        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_add):
        - Updated to use the new JITAddGenerator interface.

        * tests/stress/op_add.js:
        (stringifyIfNeeded):
        (runTest):
        - Made test output more clear about when string results are expected.

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

        It's best for the DFG to always have some guess of basic block frequency
        https://bugs.webkit.org/show_bug.cgi?id=151350

        Reviewed by Geoffrey Garen.

        It'll simplify things for B3 if we always have some estimate of block frequency, even if it's not
        a great estimate. Using NaN as an estimate is probably worse than using any non-NaN number.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGCriticalEdgeBreakingPhase.cpp:
        (JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
        * dfg/DFGLoopPreHeaderCreationPhase.cpp:
        (JSC::DFG::createPreHeader):

2015-11-17  Michael Saboff  <msaboff@apple.com>

        Reserved VM pool established in r187125 is likely too conservative
        https://bugs.webkit.org/show_bug.cgi?id=151351

        Reviewed by Filip Pizlo.

        Reduce the VM allocation reserved pool from 25% to 15% for ARM32.

        * jit/ExecutableAllocator.h:

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

        FTLLazySlowPaths should be able to handle being passed the zero register as a location
        https://bugs.webkit.org/show_bug.cgi?id=151193

        Reviewed by Geoffrey Garen.

        On arm64, SP and ZR are the same register number. The meaning
        of the register number being SP or ZR is dependent on context of
        the instruction and the register within the instruction. LLVM may
        prove that a value is zero, or sometimes, we will lower a
        value as a constant zero (for example, we might compile
        CreateDirectArguments of an inlined call frame and we might know
        that the arguments have a length of zero). LazySlowPaths should
        be able to gracefully handle being passed a stackmap location
        with a gpr value of SP by moving zero into another register
        and replacing the location's register with the new register.
        This way, no lazy slow path will ever have access to a location with a GPR
        value of SP.  This patch makes this work by using a scratch register 
        allocator when we need to do this maneuver of moving zero into a scratch
        register.  Inside FTLCompile, we track if we need to move zero into a register,
        and if so, into which register. We actually emit the necessary
        instructions to move zero into this register, and to spill reused
        registers if necessary, while generating the code for the lazy slow
        path itself.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLDWARFRegister.cpp:
        (JSC::FTL::DWARFRegister::reg):
        * ftl/FTLLazySlowPath.cpp:
        (JSC::FTL::LazySlowPath::LazySlowPath):
        (JSC::FTL::LazySlowPath::generate):
        * ftl/FTLLazySlowPath.h:
        (JSC::FTL::LazySlowPath::createGenerator):

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

        [JSC] Support Doubles with B3's Mul.
        https://bugs.webkit.org/show_bug.cgi?id=151355

        Reviewed by Filip Pizlo.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testMulLoadTwice):
        (JSC::B3::testMulArgDouble):
        (JSC::B3::testMulArgsDouble):
        (JSC::B3::testMulArgImmDouble):
        (JSC::B3::testMulImmArgDouble):
        (JSC::B3::testMulImmsDouble):
        (JSC::B3::testDivArgDouble):
        (JSC::B3::run):

2015-11-17  Matthew Daiter  <mdaiter8121@gmail.com>

        Removed useless variable scriptResult from testExecutionTimeLimit
        https://bugs.webkit.org/show_bug.cgi?id=151331

        Reviewed by Alex Christensen.

        * API/tests/ExecutionTimeLimitTest.cpp: Removed scriptResult
        (testExecutionTimeLimit):

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

        [JSC] Support Doubles with B3's Sub.
        https://bugs.webkit.org/show_bug.cgi?id=151322

        Reviewed by Filip Pizlo.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirOpcode.opcodes:

        * b3/testb3.cpp:
        (JSC::B3::testSubImmArg32):
        (JSC::B3::testSubArgDouble):
        (JSC::B3::testSubArgsDouble):
        (JSC::B3::testSubArgImmDouble):
        (JSC::B3::testSubImmArgDouble):
        (JSC::B3::testSubImmsDouble):
        (JSC::B3::testBitAndArgs):
        (JSC::B3::negativeZero):
        (JSC::B3::posInfinity):
        (JSC::B3::negInfinity):
        (JSC::B3::doubleOperands):
        (JSC::B3::run):
        - Added RUN_UNARY and RUN_BINARY macros to auto generate permutations
          of operands for the tests.
        - Added SubDouble tests using the new macros.

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

        [JSC] IteratedRegisterCoalescingAllocator's freeze can add zombie Tmps to our coloring algorithm
        https://bugs.webkit.org/show_bug.cgi?id=151345

        Reviewed by Filip Pizlo.

        The extended test of https://bugs.webkit.org/show_bug.cgi?id=151214 revealed a problem with
        the Move freezing step of the iterated register allocator.

        When freezing a move related Tmp, we go over all the move instructions and update the other
        Tmp of the move as needed. If that Tmp is no longer Move related and is of low degree it can
        be simplified too.

        The problem arise when one of those Tmp was already coalesced. For example, say we have

          1: move %tmp42, %tmp43
          2: move %tmp42, %tmp44

        The first move cannot be coalesced for some reason and is moved to the Active worklist.
        The second move is coalesced and %tmp42 is now %tmp44.

        When nothing can be simplified or coalesced, we look at freezing a Move-related Tmp.
        Let's say we pick %tmp43. The code of freeze() was going to all the Move instructions
        to update them. Here you would find @1 above, get %tmp42 as the other Tmp. Since %tmp42
        is no longer move related, it is added to the simplify work list.
        -> We just added a coalesced Tmp to our worklist!

        To fix that, I get the alias of every other Tmp before updating its status.

        There is still a problem: multiple Moves instructions may have been coalesced to the same
        Tmp. We must not add a Tmp twice to a worklist.
        To avoid duplicates, I rely on the fact that the freeze worklist should not contains
        aliased Tmps. Before adding something to the simplify worklist, I check that it was
        in the freeze worklist.

        I cannot find how this problem would have been avoided in the original paper. I suspect
        that may have been a bug in the pseudo-code.

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

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

        [JSC] Make FTLOutput's load8() and load16() compatible with B3
        https://bugs.webkit.org/show_bug.cgi?id=151336

        Reviewed by Filip Pizlo.

        B3 does not have 8bit and 16bit types. Make FTLOutput abstract enough
        to handle LLVM IR and B3.

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetArrayLength):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetByVal):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileStringCharAt):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileStringCharCodeAt):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNotifyWrite):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileSwitch):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckHasInstance):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckWatchdogTimer):
        (JSC::FTL::DFG::LowerDFGToLLVM::speculateTruthyObject):
        (JSC::FTL::DFG::LowerDFGToLLVM::boolify):
        (JSC::FTL::DFG::LowerDFGToLLVM::equalNullOrUndefined):
        (JSC::FTL::DFG::LowerDFGToLLVM::switchStringRecurse):
        (JSC::FTL::DFG::LowerDFGToLLVM::isObject):
        (JSC::FTL::DFG::LowerDFGToLLVM::isNotObject):
        (JSC::FTL::DFG::LowerDFGToLLVM::isArrayType):
        (JSC::FTL::DFG::LowerDFGToLLVM::isExoticForTypeof):
        (JSC::FTL::DFG::LowerDFGToLLVM::isType):
        (JSC::FTL::DFG::LowerDFGToLLVM::speculateNonNullObject):
        (JSC::FTL::DFG::LowerDFGToLLVM::loadCellState):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::load8SignExt32):
        (JSC::FTL::Output::load8ZeroExt32):
        (JSC::FTL::Output::load16SignExt32):
        (JSC::FTL::Output::load16ZeroExt32):
        (JSC::FTL::Output::constInt8): Deleted.
        (JSC::FTL::Output::load8): Deleted.
        (JSC::FTL::Output::load16): Deleted.
        (JSC::FTL::Output::store8): Deleted.
        (JSC::FTL::Output::storeFloat): Deleted.
        (JSC::FTL::Output::isZero8): Deleted.
        (JSC::FTL::Output::notZero8): Deleted.
        (JSC::FTL::Output::testIsZero8): Deleted.
        (JSC::FTL::Output::testNonZero8): Deleted.

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

        Fix a typo in AirIteratedRegisterCoalescing

        I forgot to fix that review comment from Geoff.

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

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

        [JSC] Add support for the extra registers that can be clobbered by Specials
        https://bugs.webkit.org/show_bug.cgi?id=151246

        Reviewed by Geoffrey Garen.

        Specials can clobber arbitrary registers. This was not handled correctly by Air
        and nothing was preventing us from re-allocating those registers.

        This patch adds support for the extra clobbered registers in the two register allocators.

        I also fixed the re-spilling FIXME of the iterated allocator because the test might
        not always converge without it. Since we are at maximum register pressure at the patch point,
        we could be always spilling the return value, which would loop forever.

        To fix the re-spilling, I just kept a Set of every value spilled or filled so far. When selecting
        a spill candidate, we never pick a Tmp from that set.

        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirHandleCalleeSaves.cpp:
        (JSC::B3::Air::handleCalleeSaves):
        * b3/air/AirInst.h:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::Inst::forEachDefAndExtraClobberedTmp):
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addEdges):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill):
        (JSC::B3::Air::addSpillAndFillToProgram):
        (JSC::B3::Air::iteratedRegisterCoalescingOnType):
        (JSC::B3::Air::iteratedRegisterCoalescing):
        * 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::run):
        * jit/RegisterSet.h:

2015-11-16  Benjamin Poulain  <benjamin@webkit.org>

        Build fix after r192492

        Last second change broke the build.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::contains):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::takeMove):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::takeLastMove):

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

        [JSC] Add trivial lowering for B3's Div with doubles
        https://bugs.webkit.org/show_bug.cgi?id=151292

        Reviewed by Geoffrey Garen.

        Filip had already made the constant propagation for it.
        The Air Opcode was all we had left.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testDivArgDouble):
        (JSC::B3::testDivArgsDouble):
        (JSC::B3::testDivArgImmDouble):
        (JSC::B3::testDivImmArgDouble):
        (JSC::B3::testDivImmsDouble):
        (JSC::B3::run):

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

        [JSC] Speed up the coalescing-related operation of the iterated register allocator
        https://bugs.webkit.org/show_bug.cgi?id=151290

        Reviewed by Geoffrey Garen.

        One step closer to removing the Hash structures:

        For the coalescing operation, we need to keep track of Move instructions. We do not strictly
        need those to be the Air Move, just any abstract operation that copy a Tmp into another Tmp.

        In this patch, I exploit that to remove the Hash structure related to the Inst. Instead of
        using the Move Inst, we just keep track of the Use() and Def() of the instructions.
        Those are added in the global list m_coalescingCandidates and the index in that list represent
        the move for the remaining of the algorithm.

        With Moves transformed into dense indices, we can start using arrays to make fast sets.

        The m_activeMoves Set is easy since we only need simple add/remove/contains. It is transformed
        into a BitVector.
        The bit vector is always fully allocated to allow for quick uniform access. The assumtion is that
        activeMoves will contains a few values for non trivial cases.

        The worklist m_worklistMoves is more complicated. I want it to be ordered to coalesce moves starting
        at the top of blocks. Having a fast remove() operation is also useful for mass coalescing.
        It also needs Set operations, especially a fast contains().

        For m_worklistMoves, I created a new structure: OrderedMoveSet.
        It contains a list of ordered values, and a map of each value to its position in the list.

        This resembles Briggs' Sparse Set but it is not exactly the same. When removing a value,
        I set a special marker in the map (UINT_MAX). The reason is that I want contains() to be fast
        instead of remove(). The marker in the map allows contains() with a single memory operation instead of two.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocate):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::forEachNodeMoves):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::isMoveRelated):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::enableMovesOnValue):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::coalesce):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::combine):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::freezeMoves):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::dumpWorkLists):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::addMove):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::isEmpty):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::contains):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::takeMove):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::takeLastMove):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::returnMove):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::OrderedMoveSet::clear):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::assignColors): Deleted.

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

        DFGEdge's dump method should print "Untyped:" for untyped uses.
        https://bugs.webkit.org/show_bug.cgi?id=151314

        Rubber stamped by Filip Pizlo.

        * dfg/DFGEdge.cpp:
        (JSC::DFG::Edge::dump):

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

        Make sure that the address matcher correctly handles Shl(x, 1)
        https://bugs.webkit.org/show_bug.cgi?id=151316

        Reviewed by Geoffrey Garen.

        This optimization isn't really that awesome, but the nicest part of the change is just the
        testing. If we ever do more cleverness with shifts, these tests will come in handy.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        * b3/testb3.cpp:
        (JSC::B3::testLoadOffsetUsingAddNotConstant):
        (JSC::B3::testLoadAddrShift):
        (JSC::B3::testFramePointer):
        (JSC::B3::run):

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

        [GTK] Use FTL by default when LLVM 3.7 is available
        https://bugs.webkit.org/show_bug.cgi?id=142128

        Reviewed by Csaba Osztrogonác.

        * PlatformGTK.cmake: Install libllvmForJSC.so.
        * llvm/InitializeLLVMLinux.cpp:
        (JSC::getLLVMInitializerFunction): For developer build try to load first
        libllvmForJSC.so from standard paths since not installed binaries
        have the RPATH set. If it fails try the installed one. For
        production buils load always the installed one.

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

        64-bit in the DFG: non tail Calls unnecessarily store the argument count twice on the callee frame and tails calls unnecessarily store it once
        https://bugs.webkit.org/show_bug.cgi?id=151297

        Reviewed by Geoffrey Garen.

        Non tail calls only need to store the count once. Tail calls
        never need to store the count on the callee frame because they
        will be reusing the caller's frame.

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

2015-11-15  Adam Bergkvist  <adam.bergkvist@ericsson.com>

        WebRTC: Update RTCPeerConnection API and introduce PeerConnectionBackend
        https://bugs.webkit.org/show_bug.cgi?id=150166

        Reviewed by Eric Carlson and Youenn Fablet

        Added generic isDictionary() function to GlobalObject.js that tests if a
        value can be interpreted as a dictionary.

        * builtins/GlobalObject.js:
        (isDictionary):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):

2015-11-14  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r190370): CrashTracer: [USER] com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::JITCode::execute + 158
        https://bugs.webkit.org/show_bug.cgi?id=151279

        Reviewed by Geoffrey Garen.

        We need to restore callee saves even when we take the slow path in a polymorphic call stub.
        Move the restoration to the top of the stub so that it is done for all paths.

        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):

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

        Unreviewed, rolling out r192416 and r192443.
        https://bugs.webkit.org/show_bug.cgi?id=151285

        Broke 32-bit in some mysterious way I need to understand
        (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/192416

        "Follow-up for 32-bit test failures after..."
        https://bugs.webkit.org/show_bug.cgi?id=151242
        http://trac.webkit.org/changeset/192443

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

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

        "caused crashes on animometer" (Requested by thorton on
        #webkit).

        Reverted changeset:

        "Restore CodeBlock jettison code I accidentally removed"
        https://bugs.webkit.org/show_bug.cgi?id=151241
        http://trac.webkit.org/changeset/192401

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

        Follow-up for 32-bit test failures after...
        [JSC] JSPropertyNameEnumerator could be destructorless.
        <https://webkit.org/b/151242>

        Reviewed by Mark Lam

        Apparently copied space allocations need to be in multiples of 8 bytes.
        Have JSPropertyNameEnumerator do what other copied space clients already do
        and round the allocation size up to a multiple of 8.

        Added a little helper function to compute the allocation size so this doesn't
        have to be repeated everywhere.

        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::finishCreation):
        (JSC::JSPropertyNameEnumerator::visitChildren):
        (JSC::JSPropertyNameEnumerator::copyBackingStore):
        * runtime/JSPropertyNameEnumerator.h:

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

        sub IC does not properly handle exception handling now that try/catch is compiled in the FTL
        https://bugs.webkit.org/show_bug.cgi?id=151080

        Reviewed by Geoffrey Garen.

        This patch implements proper exception handling for ArithSubs with binaryUseKind as
        UntypedUse inside try/catch.  We implement this in a very similar way as we implement 
        exception handling from GetById/PutById/LazySlowPaths callOperation calls. We do the needed 
        spilling if the result is the same register as the left/right register because in the event
        of an exception, we don't want to do value recovery on the garbage result, we
        want to do it on the original lhs/rhs of the operation.

        This patch also does some refactoring. No longer does OSRExitDescriptor
        have a long list of booleans that correspond to different OSR exit types.
        It now just has an enum property called ExceptionType that tells us
        what type of exception handler the OSR exit is. Then, we can just ask
        interesting questions about the OSR exit and get answers based on its
        ExceptionType property.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExceptionHandlerManager.cpp:
        (JSC::FTL::ExceptionHandlerManager::addNewExit):
        (JSC::FTL::ExceptionHandlerManager::callOperationExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::getByIdOSRExit):
        (JSC::FTL::ExceptionHandlerManager::subOSRExit):
        (JSC::FTL::ExceptionHandlerManager::getCallOSRExitCommon):
        (JSC::FTL::ExceptionHandlerManager::getOrPutByIdCallOperationExceptionTarget): Deleted.
        * ftl/FTLExceptionHandlerManager.h:
        * ftl/FTLExitThunkGenerator.cpp:
        (JSC::FTL::ExitThunkGenerator::emitThunk):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::getById):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBranchToOSRExitIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
        (JSC::FTL::OSRExitDescriptor::willArriveAtExitFromIndirectExceptionCheck):
        (JSC::FTL::OSRExitDescriptor::mightArriveAtOSRExitFromGenericUnwind):
        (JSC::FTL::OSRExitDescriptor::mightArriveAtOSRExitFromCallOperation):
        (JSC::FTL::OSRExitDescriptor::needsRegisterRecoveryOnGenericUnwindOSRExitPath):
        (JSC::FTL::OSRExitDescriptor::isExceptionHandler):
        (JSC::FTL::OSRExitDescriptor::validateReferences):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        (JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):
        (JSC::FTL::OSRExit::spillRegistersToSpillSlot):
        (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
        * ftl/FTLOSRExit.h:
        * ftl/FTLOSRExitCompilationInfo.h:
        (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileFTLOSRExit):
        * tests/stress/ftl-try-catch-arith-sub-exception.js: Added.
        (assert):
        (let.o.valueOf):
        (baz):
        (foo):
        (bar):

2015-11-13  Caitlin Potter  <caitpotter88@gmail.com>

        Allow any LeftHandSideExpression as a valid AssignmentElement
        https://bugs.webkit.org/show_bug.cgi?id=151026

        Reviewed by Geoffrey Garen.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::AssignmentElementNode::collectBoundIdentifiers):
        (JSC::AssignmentElementNode::bindValue):
        (JSC::AssignmentElementNode::toString):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::isAssignmentLocation):
        (JSC::ASTBuilder::createAssignmentElement):
        * parser/NodeConstructors.h:
        (JSC::AssignmentElementNode::AssignmentElementNode):
        * parser/Nodes.h:
        (JSC::AssignmentElementNode::assignmentTarget):
        (JSC::AssignmentElementNode::divotStart):
        (JSC::AssignmentElementNode::divotEnd):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::createAssignmentElement):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        * parser/Parser.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):

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

        op_assert should declare that it uses the first register argument
        https://bugs.webkit.org/show_bug.cgi?id=151183

        Reviewed by Geoffrey Garen.

        op_assert(conditionRegister, lineNumber) should declare that it
        *uses* (in terms of use-def) the first `conditionRegister` and
        it does not define any variables.

        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):

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

        [JSC] JSPropertyNameEnumerator could be destructorless.
        <https://webkit.org/b/151242>

        Reviewed by Mark Lam.

        Make JSPropertyNameEnumerator destructorless and have it store the property names
        cache in CopiedSpace. This was the most popular occupant of 64-byte destructor cells
        in MarkedSpace, so making it destructorless gets rid of some ill-filled MarkedBlocks.

        * heap/CopyToken.h:
        * runtime/JSPropertyNameEnumerator.cpp:
        (JSC::JSPropertyNameEnumerator::finishCreation):
        (JSC::JSPropertyNameEnumerator::visitChildren):
        (JSC::JSPropertyNameEnumerator::copyBackingStore):
        (JSC::JSPropertyNameEnumerator::destroy): Deleted.
        * runtime/JSPropertyNameEnumerator.h:

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

        [JSC] Do not generate an Add when adding a zero immediate to something
        https://bugs.webkit.org/show_bug.cgi?id=151171

        Reviewed by Geoffrey Garen.

        Avoid generating an add if one of arguments is a zero immediate.

        On x86, the add32/64() were also used internally for branchAdd32/64.
        I split the code that sets flag to add32AndSetFlags() to make sure
        we always force the flags before testing.

        I could have used CMp to set the flags but I would gain nothing from
        that, cmp is just a SUB.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::add32):
        (JSC::MacroAssemblerARM64::add64):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::add32):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::add32):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::add32):
        (JSC::MacroAssemblerX86Common::branchAdd32):
        (JSC::MacroAssemblerX86Common::add32AndSetFlags):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::add32):
        (JSC::MacroAssemblerX86_64::add64):
        (JSC::MacroAssemblerX86_64::branchAdd64):
        (JSC::MacroAssemblerX86_64::add64AndSetFlags):

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

        Restore CodeBlock jettison code I accidentally removed
        https://bugs.webkit.org/show_bug.cgi?id=151241

        Reviewed by Andreas Kling.

        I meant to add this back in <http://trac.webkit.org/changeset/190827>
        but I missed.

        * bytecode/CodeBlock.cpp:
        (JSC::timeToLive):
        (JSC::CodeBlock::shouldJettisonDueToOldAge):

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

        B3 should be able to compile programs with CheckAdd, CheckSub, and CheckMul
        https://bugs.webkit.org/show_bug.cgi?id=151213

        Reviewed by Benjamin Poulain.

        This adds lowering code for CheckAdd, CheckSub, and CheckMul along with support for CheckNeg
        (i.e. CheckSub with the left child being zero).

        This adds tests for these things, by simulating what JS would do: if there is overflow, revert
        to double math. To write the test, I needed support for IToD so I added that support.

        This also fixes a memory corruption bug in the register allocator.

        Also fixes a bug in opcode_generator.rb where we were emitting stray "return" statements inside
        switch statements. I think this was benign, but I'm not sure, so I fixed it.

        Note that I had to convert CheckMul handling to always use a three-operand form. That's because
        there is no other way to tell Air that we need the original value alive. This means that on X86
        we'll emit an extra Move just before the checked mul. That's probably fine since that's
        necessary anyway.

        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::branchMul64):
        (JSC::MacroAssemblerX86_64::branchSub64):
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::generate):
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::mulConstant):
        (JSC::B3::Const32Value::checkAddConstant):
        (JSC::B3::Const32Value::checkSubConstant):
        (JSC::B3::Const32Value::checkMulConstant):
        (JSC::B3::Const32Value::divConstant):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::mulConstant):
        (JSC::B3::Const64Value::checkAddConstant):
        (JSC::B3::Const64Value::checkSubConstant):
        (JSC::B3::Const64Value::checkMulConstant):
        (JSC::B3::Const64Value::divConstant):
        * b3/B3Const64Value.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::appendUnOp):
        (JSC::B3::Air::LowerToAir::ensureSpecial):
        (JSC::B3::Air::LowerToAir::ensureCheckSpecial):
        (JSC::B3::Air::LowerToAir::fillStackmap):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::mulConstant):
        (JSC::B3::Value::checkAddConstant):
        (JSC::B3::Value::checkSubConstant):
        (JSC::B3::Value::checkMulConstant):
        (JSC::B3::Value::divConstant):
        * b3/B3Value.h:
        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::iteratedRegisterCoalescing):
        * b3/air/AirOpcode.opcodes:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (JSC::B3::testCheckMegaCombo):
        (JSC::B3::testCheckAddImm):
        (JSC::B3::testCheckAdd):
        (JSC::B3::testCheckAdd64):
        (JSC::B3::testCheckAddFold):
        (JSC::B3::testCheckAddFoldFail):
        (JSC::B3::testCheckSubImm):
        (JSC::B3::testCheckSub):
        (JSC::B3::doubleSub):
        (JSC::B3::testCheckSub64):
        (JSC::B3::testCheckSubFold):
        (JSC::B3::testCheckSubFoldFail):
        (JSC::B3::testCheckNeg):
        (JSC::B3::testCheckNeg64):
        (JSC::B3::testCheckMul):
        (JSC::B3::testCheckMul64):
        (JSC::B3::testCheckMulFold):
        (JSC::B3::testCheckMulFoldFail):
        (JSC::B3::genericTestCompare):
        (JSC::B3::run):

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

        Web Inspector: Reduce list of saved console messages
        https://bugs.webkit.org/show_bug.cgi?id=151225

        Reviewed by Geoffrey Garen.

        Inspector saves messages so that when an inspector frontend opens it can report
        these messages to the frontend. However we were saving a rather large list of
        1000 messages. Most pages do not produce a large number of console messages.
        However pages that live for a long time can generate many errors over time,
        especially periodic engine issues such as cross-origin access errors. This could
        result in a lot of wasted memory for console messages that may never be used.

        Likewise when an inspector first open sending all 1000 messages to the frontend
        results in a poor experience.

        Lets reduce the list of saved messages. Developer will still be able to see
        all messages as long as they have Web Inspector open at the time the messages
        are generated.

        * inspector/agents/InspectorConsoleAgent.cpp:
        Reduce the list from 1000 to 100. Also, when expiring
        messages from this list, chunk in 10s instead of 100s.

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

        Adjust timeout values in ExecutionTimeLimitTest.
        https://bugs.webkit.org/show_bug.cgi?id=151223

        Reviewed by Geoffrey Garen.

        Some bots were not happy with the existing time out values.  I adjusted them to give
        the system a little more time to fire the timer events, and this made the bots happy.

        * API/tests/ExecutionTimeLimitTest.cpp:
        (testExecutionTimeLimit):

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

        B3 should be able to compile Patchpoints with Register and Any constraints
        https://bugs.webkit.org/show_bug.cgi?id=151209

        Reviewed by Geoffrey Garen.

        Most of this patch is about adding tests, since Register constraints already worked but
        were untested, and almost all forms of the Any constraint worked.

        One change that I'm making is that Patchpoints now default to forCall effects rather
        than no effects. I think this is better because if a client of Patchpoint never supplies
        any effects, it's best to assume the worst.

        My testing uncovered only one real bug: moveConstants() would turn all non-zero double
        constants into Loads, so the optimization to fold constants into a Stackmap would stop
        working. Instead of telling the Stackmap that the double value it wanted is actually a
        constant, we would tell it that it's a register and it would emit code to materialize
        the double into that register. I worked around this by having moveConstants() create
        ConstDoubleValue's just for the Stackmaps, which lowerToAir() recognizes and does the
        right thing with (i.e. folds into the stackmap instead of materializing).

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::fillStackmap):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3MoveConstants.cpp:
        * b3/B3PatchpointValue.cpp:
        (JSC::B3::PatchpointValue::PatchpointValue):
        * b3/testb3.cpp:
        (JSC::B3::testPatchpointCallArg):
        (JSC::B3::testPatchpointFixedRegister):
        (JSC::B3::testPatchpointAny):
        (JSC::B3::testPatchpointAnyImm):
        (JSC::B3::testPatchpointManyImms):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::run):

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

        Move some prototypes to header files.
        https://bugs.webkit.org/show_bug.cgi?id=151194

        Reviewed by Michael Saboff.

        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::printIndent):
        * assembler/MacroAssemblerPrinter.h:
        (JSC::MacroAssembler::print):

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

        Remove ENABLE(SATURATED_LAYOUT_ARITHMETIC) guards
        https://bugs.webkit.org/show_bug.cgi?id=150972

        Reviewed by Darin Adler.

        * Configurations/FeatureDefines.xcconfig:

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

        [JSC] Air: we have more register than what the allocator believed
        https://bugs.webkit.org/show_bug.cgi?id=151182

        Reviewed by Michael Saboff.

        I was using GPRInfo/FPRInfo to get the number of register while coloring the interference graph.
        The problem is, those classes are lying about register availability.

        They don't report stuff reserved by the MacroAssembler and reserve some registers.
        FPRInfo is the worst, reporting only 6 of the 15 registers we have.

        The ground truth in our case is that we can color with all the registers returned
        by regsInPriorityOrder(). I changed IteratedRegisterCoalescingAllocator to use that value.

        The new test testSpillFP() covers simple spilling of doubles.

        * b3/air/AirIteratedRegisterCoalescing.cpp:
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::makeWorkList):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::decrementDegree):
        (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):
        * b3/testb3.cpp:
        (JSC::B3::testSpillFP):
        (JSC::B3::run):

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

        The BinarySnippetRegisterContext needs to copy the result back from the scratch register.
        https://bugs.webkit.org/show_bug.cgi?id=150712

        Reviewed by Geoffrey Garen.

        If the BinarySnippetRegisterContext had re-assigned the result register to a scratch
        before emitting the snippet, it needs to copy the result back from the scratch after
        the snippet is done.

        This fixes the cdjs-tests.yaml/main.js.ftl failure reported in
        https://bugs.webkit.org/show_bug.cgi?id=150687.

        Also added an optimization to check for the case where any of the left, right,
        or result registers are aliased together, and to map them to the corresponding
        allocated scratch register for their alias instead of allocating separate ones.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        - Added JITSubGenerator.h to these project files for completeness.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        - Re-enable ArithSub handling of UntypedUse operands.

        * ftl/FTLCompile.cpp:

        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfArithSub):
        - Adjusted IC sizes to account for the snippet changes.

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

        Crash in sorting-benchmark.js on ARM64 with full op_sub FTL coverage.
        https://bugs.webkit.org/show_bug.cgi?id=150936

        Reviewed by Michael Saboff.

        The OSR entry thunk does not currently restore the callee saved registers that the baseline
        JIT saves but the DFG does not.  As a result, sorting-benchmark.js was crashing with the
        following scenario:

            1. There exists 2 functions: benchmark() and bottom_up_merge_sort().
               Let's call them A() and B() respectively for brevity.
            2. A() is FTL compiled.
            3. B() is FTL compiled.
            4. FTL A() calls FTL B().  FTL B() trashes register x26.
            5. FTL B() goes through an OSR exit, and deopts to baseline.  The OSR exit off-ramp
               puts x26's original value in the baseline B()'s stash location for x26 in its stack
               frame.  It expects baseline B() to restore x26 when it returns.
            6. Baseline B() gets DFG optimized, and we OSR enter into DFG B().
               The OSR entry thunk does nothing to restore x26's original value.  Hence, x26 contains
               whatever value FTL B() left in it.
            7. DFG B() returns to FTL A().
               x26 is not one of the callee saved registers used by DFG B().  Hence, it does nothing
               to restore it.
            8. FTL A() tries to use x26 and crashes, because x26 contains FTL B()'s value for it, and
               not FTL A()'s.

        This patch fixes this issue by having the OSR entry thunk restore all the callee saved
        registers before running the DFG code.

        No new test needed because this issue will be covered by sorting-benchmark.js as soon as
        https://bugs.webkit.org/show_bug.cgi?id=150712 lands.

        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrEntryThunkGenerator):

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

        [JSC] Add a comment explaining the opcode suffixes on x86
        https://bugs.webkit.org/show_bug.cgi?id=151176

        Reviewed by Alex Christensen.

        * assembler/X86Assembler.h:
        I was always confused with the prefixes. Gavin pointed out the Intel documentation
        explains everything.
        I added a comment to help the next person confused about those suffixes.

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

        [JSC] Support Doubles with B3's Add
        https://bugs.webkit.org/show_bug.cgi?id=151164

        Reviewed by Filip Pizlo.

        I tweaked ReduceStrength a bit to maintain correctness.
        Nothing fancy otherwise.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.h:
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::isInteger):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::bitWiseEqual):
        (JSC::B3::testAddArgDouble):
        (JSC::B3::testAddArgsDouble):
        (JSC::B3::testAddArgImmDouble):
        (JSC::B3::testAddImmArgDouble):
        (JSC::B3::testAddImmsDouble):
        (JSC::B3::run):

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

        B3 should be able to compile a program with Switch
        https://bugs.webkit.org/show_bug.cgi?id=151115

        Reviewed by Benjamin Poulain.

        Adds lowering of Switch to a binary switch. This doesn't require any Air support.

        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::append):
        (JSC::B3::BasicBlock::removeLast):
        (JSC::B3::BasicBlock::replaceLast):
        * b3/B3BasicBlock.h:
        * b3/B3BlockInsertionSet.cpp:
        (JSC::B3::BlockInsertionSet::insertBefore):
        (JSC::B3::BlockInsertionSet::insertAfter):
        (JSC::B3::BlockInsertionSet::splitForward):
        * b3/B3BlockInsertionSet.h:
        * b3/B3ControlValue.h:
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3LowerMacros.cpp:
        * b3/B3SwitchValue.cpp:
        (JSC::B3::SwitchValue::dumpMeta):
        (JSC::B3::SwitchValue::SwitchValue):
        * b3/B3SwitchValue.h:
        * b3/testb3.cpp:
        (JSC::B3::testChillDiv64):
        (JSC::B3::testSwitch):
        (JSC::B3::run):

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

        Patchpoints with stackArgument constraints should work
        https://bugs.webkit.org/show_bug.cgi?id=151177

        Reviewed by Saam Barati.

        The only thing broken was that StackmapSpecial's isValidForm would reject Arg::addr, so
        validation would fail after allocateStack.

        In order for StackmapSpecial to validate Arg::addr, it needs to know the frame size. To know
        the frame size, it needs access to Code&. So, this changes Air::Special to always have a
        pointer back to Code.

        Other than this already worked.

        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::isValidImpl):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::addSpecial):
        * b3/air/AirSpecial.cpp:
        (JSC::B3::Air::Special::Special):
        * b3/air/AirSpecial.h:
        (JSC::B3::Air::Special::code):
        * b3/testb3.cpp:
        (JSC::B3::testSimplePatchpoint):
        (JSC::B3::testPatchpointCallArg):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::run):

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

        Add ability to insert probes in LLVM IR that we generate.
        https://bugs.webkit.org/show_bug.cgi?id=151159

        Reviewed by Geoffrey Garen.

        This is done by inserting a stackmap intrinsic and emitting the probe there.

        We can now insert probes that take a lambda like so:

            probe([] (CCallHelpers::ProbeContext*) {
                dataLog("Hello FTL\n");
            });

        * ftl/FTLCompile.cpp:
        * ftl/FTLInlineCacheDescriptor.h:
        (JSC::FTL::ProbeDescriptor::ProbeDescriptor):
        (JSC::FTL::ProbeDescriptor::probeFunction):
        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfProbe):
        * ftl/FTLInlineCacheSize.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::probe):
        * ftl/FTLState.h:

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

        Change probe CPUState gpr() and fpr() to return references.
        https://bugs.webkit.org/show_bug.cgi?id=151154

        Reviewed by Saam Barati.

        This will allow us to set their values as well as reading them.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::CPUState::gpr):
        (JSC::AbstractMacroAssembler::CPUState::fpr):
        (JSC::AbstractMacroAssembler::ProbeContext::gpr):
        (JSC::AbstractMacroAssembler::ProbeContext::fpr):

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

        Add convenience utility to support dataLogging opcodeIDs.
        https://bugs.webkit.org/show_bug.cgi?id=151117

        Reviewed by Saam Barati.

        * bytecode/Opcode.cpp:
        (WTF::printInternal):
        * bytecode/Opcode.h:

2015-11-10  Keith Miller  <keith_miller@apple.com>

        Regression(r191815): 5.3% regression on Dromaeo JS Library Benchmark
        https://bugs.webkit.org/show_bug.cgi?id=150945

        Reviewed by Filip Pizlo.

        This patch fixes a performance regression introduced by r191815. Before adding Symbol.toStringTag
        we would cache the value of Object.prototype.toString() in the rareData of the structure.
        In order to cache the result of Object.prototype.toString() we now need to ensure that the
        value stored in Symbol.toStringTag is a known constant. Thus, in order to ensure the stored Symbol.toStringTag
        value remains constant adaptive inferred value watchpoints have been re-factored to be generalizable and
        a new version that clears the toString value cache when fired has been added.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp.
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::AdaptiveInferredPropertyValueWatchpointBase):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::install):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::fireInternal):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::fireInternal):
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h.
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::key):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint):
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::AdaptiveInferredPropertyValueWatchpoint):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::handleFire):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::install): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::fireInternal): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::fireInternal): Deleted.
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::key): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::StructureWatchpoint): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::PropertyWatchpoint): Deleted.
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::setObjectToStringValue):
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::StructureRareData):
        (JSC::StructureRareData::setObjectToStringValue):
        (JSC::StructureRareData::clearObjectToStringValue):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
        (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::ObjectToStringAdaptiveInferredPropertyValueWatchpoint):
        (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::handleFire):
        * runtime/StructureRareData.h:
        * runtime/StructureRareDataInlines.h:
        (JSC::StructureRareData::setObjectToStringValue): Deleted.
        * tests/stress/symbol-tostringtag-watchpoints.js: Added.
        (Base):

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp.
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::AdaptiveInferredPropertyValueWatchpointBase):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::install):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::fireInternal):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::fireInternal):
        * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h: Copied from Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h.
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::key):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint):
        (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint):
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::AdaptiveInferredPropertyValueWatchpoint):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::handleFire):
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::install): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::fireInternal): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::fireInternal): Deleted.
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::key): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::StructureWatchpoint::StructureWatchpoint): Deleted.
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::PropertyWatchpoint::PropertyWatchpoint): Deleted.
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        (JSC::Structure::setObjectToStringValue):
        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::StructureRareData):
        (JSC::StructureRareData::setObjectToStringValue):
        (JSC::StructureRareData::clearObjectToStringValue):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
        (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
        (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::ObjectToStringAdaptiveInferredPropertyValueWatchpoint):
        (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::handleFire):
        * runtime/StructureRareData.h:
        * runtime/StructureRareDataInlines.h:
        (JSC::StructureRareData::setObjectToStringValue): Deleted.
        * tests/stress/symbol-tostringtag-watchpoints.js: Added.
        (Base):

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

        B3 should be able to compile and canonicalize Mul
        https://bugs.webkit.org/show_bug.cgi?id=151124

        Reviewed by Geoffrey Garen.

        This was a strange trip. I wanted to do a quick patch to implement Mul. But then I realized
        that our tradition when adding new lowerings was to also add the corresponding strength
        reductions. So then I wrote the Mul->Shl strength reduction. But that reminded me that I needed
        to canonicalize between Add(x, x) and Shl(x, 1). I decided that it would probably be better to
        use Shl(x, 1), since that only has one use of x. But that means that we should compile
        Shl(x, 1) to Add x, x in the backend, since that's what X86 wants. While doing that, I almost
        introduced a bug where Shl(Load(x), 1) would cause the compiler to either crash or generate bad
        code. That's because I was using Add(x, x) to handle Shl(x, 1), so we'd end up with
        Add(Load(x), Load(x)) - i.e. we would try to duplicate the Load.

        The instruction selector already defends against this, and the only reason why I would have
        created the bug was by using the Add helper when compiling a Shl. Still, this was so close to
        a bad bug that I added a ton of new tests that cover the Op(x, x) where x = Load case.

        * b3/B3Compilation.cpp:
        (JSC::B3::Compilation::Compilation):
        * b3/B3Compilation.h:
        (JSC::B3::Compilation::code):
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::subConstant):
        (JSC::B3::Const32Value::mulConstant):
        (JSC::B3::Const32Value::bitAndConstant):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::subConstant):
        (JSC::B3::Const64Value::mulConstant):
        (JSC::B3::Const64Value::bitAndConstant):
        * b3/B3Const64Value.h:
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::subConstant):
        (JSC::B3::ConstDoubleValue::mulConstant):
        (JSC::B3::ConstDoubleValue::equalConstant):
        * b3/B3ConstDoubleValue.h:
        * b3/B3Generate.cpp:
        (JSC::B3::generate):
        (JSC::B3::generateToAir):
        * b3/B3Generate.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::appendBinOp):
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::subConstant):
        (JSC::B3::Value::mulConstant):
        (JSC::B3::Value::bitAndConstant):
        * b3/B3Value.h:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::compile):
        (JSC::B3::testReturnConst64):
        (JSC::B3::testAddArg):
        (JSC::B3::testAddArgs):
        (JSC::B3::testAddArgs32):
        (JSC::B3::testAddLoadTwice):
        (JSC::B3::testMulArg):
        (JSC::B3::testMulArgs):
        (JSC::B3::testMulArgImm):
        (JSC::B3::testMulImmArg):
        (JSC::B3::testMulArgs32):
        (JSC::B3::testMulLoadTwice):
        (JSC::B3::testSubArg):
        (JSC::B3::testSubArgs):
        (JSC::B3::testShlArgImm):
        (JSC::B3::testShlArg32):
        (JSC::B3::testShlArgs32):
        (JSC::B3::testSShrArgImm):
        (JSC::B3::testSShrArg32):
        (JSC::B3::testSShrArgs32):
        (JSC::B3::testZShrArgImm):
        (JSC::B3::testZShrArg32):
        (JSC::B3::testZShrArgs32):
        (JSC::B3::genericTestCompare):
        (JSC::B3::testCompareLoad):
        (JSC::B3::testCompareImpl):
        (JSC::B3::run):

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

        Update ES6 Generators' status to "In Development"
        https://bugs.webkit.org/show_bug.cgi?id=151142

        Reviewed by Saam Barati.

        Currently, features.json raises some linting errors.
        This should be cleaned up in another patch.

        * features.json:

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

        B3 should be able to compile a program with ChillDiv
        https://bugs.webkit.org/show_bug.cgi?id=151114

        Reviewed by Benjamin Poulain.

        This change is about a lot more than ChillDiv. I picked that as the next thing to lower
        because I knew that it would force me to come up with a sensible idiom for doing
        stepwise lowerings that require breaking basic blocks. The idea is that you want to
        write a loop that iterates forward over the program, which turns some operations that
        currently are just single Values into an entire little sub-CFGs. That requires splitting
        the block that contained the original Value. That's tricky if you then want to keep
        iterating: the index of the Value you were last looking at has now changed and your
        InsertionSets are now invalid.

        This introduces an idiom that handles this. It's BlockInsertionSet::splitBefore(). The
        idea is that it uses the current block before the split as the continuation after the
        split. When you call splitBefore(), you pass it your loop index and your InsertionSet
        (if applicable). It makes sure that it changes those auxiliary things in such a way that
        you can keep looping.

        This uncovered some bugs, since this is the first time that we're compiling cross edges.

        Because ChillDiv is really a division, I also had to write a bunch of code to support
        the ordinary B3 Div. While doing that, I realized that there was asymmetry to that
        constness of the Value constant folding methods, so I fixed that as well.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::mul32):
        (JSC::MacroAssemblerX86Common::x86ConvertToDoubleWord32):
        (JSC::MacroAssemblerX86Common::x86Div32):
        (JSC::MacroAssemblerX86Common::neg32):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::mul64):
        (JSC::MacroAssemblerX86_64::x86ConvertToQuadWord64):
        (JSC::MacroAssemblerX86_64::x86Div64):
        (JSC::MacroAssemblerX86_64::neg64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::idivl_r):
        (JSC::X86Assembler::idivq_r):
        (JSC::X86Assembler::cmpl_rr):
        (JSC::X86Assembler::cdq):
        (JSC::X86Assembler::cdqq):
        (JSC::X86Assembler::fstps):
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::append):
        (JSC::B3::BasicBlock::replaceLast):
        (JSC::B3::BasicBlock::appendIntConstant):
        (JSC::B3::BasicBlock::replaceSuccessor):
        (JSC::B3::BasicBlock::addPredecessor):
        (JSC::B3::BasicBlock::replacePredecessor):
        (JSC::B3::BasicBlock::updatePredecessors):
        (JSC::B3::BasicBlock::dump):
        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::values):
        (JSC::B3::BasicBlock::numPredecessors):
        (JSC::B3::BasicBlock::predecessor):
        (JSC::B3::BasicBlock::frequency):
        * b3/B3BasicBlockInlines.h:
        (JSC::B3::BasicBlock::appendNew):
        (JSC::B3::BasicBlock::replaceLastWithNew):
        (JSC::B3::BasicBlock::numSuccessors):
        * b3/B3BasicBlockUtils.h:
        (JSC::B3::replacePredecessor):
        (JSC::B3::updatePredecessors):
        (JSC::B3::resetReachability):
        * b3/B3BlockInsertionSet.cpp: Added.
        (JSC::B3::BlockInsertionSet::BlockInsertionSet):
        (JSC::B3::BlockInsertionSet::~BlockInsertionSet):
        (JSC::B3::BlockInsertionSet::insert):
        (JSC::B3::BlockInsertionSet::insertBefore):
        (JSC::B3::BlockInsertionSet::splitForward):
        (JSC::B3::BlockInsertionSet::execute):
        * b3/B3BlockInsertionSet.h: Added.
        * b3/B3Common.h:
        (JSC::B3::isRepresentableAs):
        (JSC::B3::chillDiv):
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::addConstant):
        (JSC::B3::Const32Value::subConstant):
        (JSC::B3::Const32Value::divConstant):
        (JSC::B3::Const32Value::bitAndConstant):
        (JSC::B3::Const32Value::bitOrConstant):
        (JSC::B3::Const32Value::bitXorConstant):
        (JSC::B3::Const32Value::shlConstant):
        (JSC::B3::Const32Value::sShrConstant):
        (JSC::B3::Const32Value::zShrConstant):
        (JSC::B3::Const32Value::equalConstant):
        (JSC::B3::Const32Value::notEqualConstant):
        (JSC::B3::Const32Value::lessThanConstant):
        (JSC::B3::Const32Value::greaterThanConstant):
        (JSC::B3::Const32Value::lessEqualConstant):
        (JSC::B3::Const32Value::greaterEqualConstant):
        (JSC::B3::Const32Value::aboveConstant):
        (JSC::B3::Const32Value::belowConstant):
        (JSC::B3::Const32Value::aboveEqualConstant):
        (JSC::B3::Const32Value::belowEqualConstant):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::addConstant):
        (JSC::B3::Const64Value::subConstant):
        (JSC::B3::Const64Value::divConstant):
        (JSC::B3::Const64Value::bitAndConstant):
        (JSC::B3::Const64Value::bitOrConstant):
        (JSC::B3::Const64Value::bitXorConstant):
        (JSC::B3::Const64Value::shlConstant):
        (JSC::B3::Const64Value::sShrConstant):
        (JSC::B3::Const64Value::zShrConstant):
        (JSC::B3::Const64Value::equalConstant):
        (JSC::B3::Const64Value::notEqualConstant):
        (JSC::B3::Const64Value::lessThanConstant):
        (JSC::B3::Const64Value::greaterThanConstant):
        (JSC::B3::Const64Value::lessEqualConstant):
        (JSC::B3::Const64Value::greaterEqualConstant):
        (JSC::B3::Const64Value::aboveConstant):
        (JSC::B3::Const64Value::belowConstant):
        (JSC::B3::Const64Value::aboveEqualConstant):
        (JSC::B3::Const64Value::belowEqualConstant):
        * b3/B3Const64Value.h:
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::addConstant):
        (JSC::B3::ConstDoubleValue::subConstant):
        (JSC::B3::ConstDoubleValue::divConstant):
        (JSC::B3::ConstDoubleValue::equalConstant):
        (JSC::B3::ConstDoubleValue::notEqualConstant):
        (JSC::B3::ConstDoubleValue::lessThanConstant):
        (JSC::B3::ConstDoubleValue::greaterThanConstant):
        (JSC::B3::ConstDoubleValue::lessEqualConstant):
        (JSC::B3::ConstDoubleValue::greaterEqualConstant):
        * b3/B3ConstDoubleValue.h:
        * b3/B3ControlValue.cpp:
        (JSC::B3::ControlValue::~ControlValue):
        (JSC::B3::ControlValue::replaceSuccessor):
        (JSC::B3::ControlValue::convertToJump):
        * b3/B3ControlValue.h:
        * b3/B3Generate.cpp:
        (JSC::B3::generateToAir):
        * b3/B3GenericFrequentedBlock.h:
        (JSC::B3::GenericFrequentedBlock::block):
        (JSC::B3::GenericFrequentedBlock::frequency):
        (JSC::B3::GenericFrequentedBlock::dump):
        * b3/B3InsertionSet.cpp:
        (JSC::B3::InsertionSet::insertIntConstant):
        (JSC::B3::InsertionSet::execute):
        * b3/B3InsertionSet.h:
        * b3/B3LowerMacros.cpp: Added.
        (JSC::B3::lowerMacros):
        * b3/B3LowerMacros.h: Added.
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addBlock):
        (JSC::B3::Procedure::addIntConstant):
        (JSC::B3::Procedure::addBoolConstant):
        (JSC::B3::Procedure::resetValueOwners):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::takeByproducts):
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::addConstant):
        (JSC::B3::Value::subConstant):
        (JSC::B3::Value::divConstant):
        (JSC::B3::Value::bitAndConstant):
        (JSC::B3::Value::bitOrConstant):
        (JSC::B3::Value::bitXorConstant):
        (JSC::B3::Value::shlConstant):
        (JSC::B3::Value::sShrConstant):
        (JSC::B3::Value::zShrConstant):
        (JSC::B3::Value::equalConstant):
        (JSC::B3::Value::notEqualConstant):
        (JSC::B3::Value::lessThanConstant):
        (JSC::B3::Value::greaterThanConstant):
        (JSC::B3::Value::lessEqualConstant):
        (JSC::B3::Value::greaterEqualConstant):
        (JSC::B3::Value::aboveConstant):
        (JSC::B3::Value::belowConstant):
        (JSC::B3::Value::aboveEqualConstant):
        (JSC::B3::Value::belowEqualConstant):
        * b3/B3Value.h:
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::isUrshift64Valid):
        (JSC::B3::Air::isX86DivHelperValid):
        (JSC::B3::Air::isX86ConvertToDoubleWord32Valid):
        (JSC::B3::Air::isX86ConvertToDoubleWord64Valid):
        (JSC::B3::Air::isX86Div32Valid):
        (JSC::B3::Air::isX86Div64Valid):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirSimplifyCFG.cpp:
        (JSC::B3::Air::simplifyCFG):
        * b3/testb3.cpp:
        (JSC::B3::testCallFunctionWithHellaDoubleArguments):
        (JSC::B3::testChillDiv):
        (JSC::B3::testChillDivTwice):
        (JSC::B3::testChillDiv64):
        (JSC::B3::run):
        * dfg/DFGBlockInsertionSet.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithDiv):
        (JSC::DFG::SpeculativeJIT::compileArithMod):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_mod):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_op_mod):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildBinaryI32):

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

        Air should allocate registers
        https://bugs.webkit.org/show_bug.cgi?id=150457

        Reviewed by Filip Pizlo.

        This is a direct implementation of the Iterated Register Coalescing allocator.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirInstInlines.h:
        * b3/air/AirIteratedRegisterCoalescing.cpp: Added.
        (JSC::B3::Air::MoveInstHelper<Arg::GP>::mayBeCoalescable):
        (JSC::B3::Air::MoveInstHelper<Arg::FP>::mayBeCoalescable):
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::GP>::absoluteIndex):
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::GP>::tmpFromAbsoluteIndex):
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::FP>::absoluteIndex):
        (JSC::B3::Air::AbsoluteTmpHelper<Arg::FP>::tmpFromAbsoluteIndex):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::IteratedRegisterCoalescingAllocator):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::build):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::allocate):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::getAlias):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::spilledTmp):
        (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::enableMovesOnValueAndAdjacents):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::coalesce):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::canBeSafelyCoalesced):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::precoloredCoalescingHeuristic):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::conservativeHeuristic):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::addWorkList):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::combine):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::freeze):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::freezeMoves):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::selectSpill):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::assignColors):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::dumpInterferenceGraphInDot):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::dumpWorkLists):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::InterferenceEdge):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::first):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::second):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::operator==):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::isHashTableDeletedValue):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdge::hash):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdgeHash::hash):
        (JSC::B3::Air::IteratedRegisterCoalescingAllocator::InterferenceEdgeHash::equal):
        (JSC::B3::Air::isUselessMoveInst):
        (JSC::B3::Air::assignRegisterToTmpInProgram):
        (JSC::B3::Air::addSpillAndFillToProgram):
        (JSC::B3::Air::iteratedRegisterCoalescingOnType):
        (JSC::B3::Air::iteratedRegisterCoalescing):
        * b3/air/AirIteratedRegisterCoalescing.h: Added.
        * b3/air/AirTmp.h:
        (JSC::B3::Air::Tmp::internalValue):
        (JSC::B3::Air::Tmp::tmpForInternalValue):
        * b3/testb3.cpp:
        (JSC::B3::testSpillGP):
        (JSC::B3::run):

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

        Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=151128.

        * b3/air/AirInstInlines.h:

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

        Create an FTLExceptionHandlerManager abstraction
        https://bugs.webkit.org/show_bug.cgi?id=151079

        Reviewed by Mark Lam.

        Before, we used to manage the {stackmapRecordIndex => OSRExit} relationship
        for exception handlers with a locally allocated HashMap and a few different
        lambdas and random checks. It's cleaner and more manageable to just create 
        a class that handles this abstraction for us. This class provides nice helper 
        functions for everything we need. This abstraction makes reading the code easier.
        And it will also makes hacking on the code in the future easier.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGOSRExitBase.h:
        (JSC::DFG::OSRExitBase::OSRExitBase):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExceptionHandlerManager.cpp: Added.
        (JSC::FTL::ExceptionHandlerManager::ExceptionHandlerManager):
        (JSC::FTL::ExceptionHandlerManager::addNewExit):
        (JSC::FTL::ExceptionHandlerManager::getOrPutByIdCallOperationExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::lazySlowPathExceptionTarget):
        (JSC::FTL::ExceptionHandlerManager::getByIdOSRExit):
        (JSC::FTL::ExceptionHandlerManager::getCallOSRExitCommon):
        (JSC::FTL::ExceptionHandlerManager::getCallOSRExit):
        (JSC::FTL::ExceptionHandlerManager::procureCallSiteIndex):
        * ftl/FTLExceptionHandlerManager.h: Added.

2015-11-10  Michael Saboff  <msaboff@apple.com>

        X86_64 support for compareDouble(DoubleCondition, FPRegisterID left, FPRegisterID right, RegisterID dest)
        https://bugs.webkit.org/show_bug.cgi?id=151009

        Reviewed by Filip Pizlo.

        Added compareDouble() macro assembler function and the supporting setnp_r() and setp_r() X86 assembler functions.
        Hand tested.

        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::compare64):
        (JSC::MacroAssemblerX86_64::compareDouble):
        (JSC::MacroAssemblerX86_64::branch64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::setnz_r):
        (JSC::X86Assembler::setnp_r):
        (JSC::X86Assembler::setp_r):
        (JSC::X86Assembler::cdq):

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

        Rename FTL's ExitArgumentList to something more indicative of what it is
        https://bugs.webkit.org/show_bug.cgi?id=151078

        Reviewed by Geoffrey Garen.

        New name is: StackmapArgumentList
        We use this to build patchpoint and stackmap intrinsics in FTLLowerDFGToLLVM.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLExitArgumentList.h: Removed.
        * ftl/FTLJSTailCall.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::getById):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):
        (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForAvailability):
        (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::exitArgument):
        (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForTailCall):
        * ftl/FTLOSRExit.cpp:
        * ftl/FTLOSRExit.h:
        * ftl/FTLStackmapArgumentList.h: Copied from Source/JavaScriptCore/ftl/FTLExitArgumentList.h.

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

        [B3] Add more tests for Check and fix bugs this found
        https://bugs.webkit.org/show_bug.cgi?id=151073

        Reviewed by Saam Barati.

        Adds tests for compare/Check fusion. The "MegaCombo" test found a bug in our implementation
        of forEachArg: Air::spillEverything() was expecting that the Arg& to point to the actual Arg
        so that it can mutate it. But this wasn't the case in B3::CheckSpecial. This fixes that bug.

        * b3/B3CheckSpecial.cpp:
        (JSC::B3::Air::numB3Args):
        (JSC::B3::CheckSpecial::hiddenBranch):
        (JSC::B3::CheckSpecial::commitHiddenBranch):
        (JSC::B3::CheckSpecial::forEachArg):
        * b3/B3CheckSpecial.h:
        * b3/testb3.cpp:
        (JSC::B3::testSimpleCheck):
        (JSC::B3::testCheckLessThan):
        (JSC::B3::testCheckMegaCombo):
        (JSC::B3::genericTestCompare):
        (JSC::B3::run):

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

        [B3] Add a test for CCall with double arguments and results
        https://bugs.webkit.org/show_bug.cgi?id=151064

        Reviewed by Saam Barati.

        The test already passed on trunk. But when looking at the disassembly, I realized that I had
        made a rookie mistake in the call argument marshalling: the stores to the stack went after the
        moves to argument registers! This means that arguments that go to stack would be made to
        interfere with all argument registers. That's some severe register pressure right there. So,
        this change fixes that as well, and adds a FIXME to do it in a more principled manner in Air.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
        (JSC::B3::Air::LowerToAir::createStore):
        (JSC::B3::Air::LowerToAir::appendStore):
        (JSC::B3::Air::LowerToAir::moveForType):
        (JSC::B3::Air::LowerToAir::marshallCCallArgument):
        * b3/testb3.cpp:
        (JSC::B3::testReturnDouble):
        (JSC::B3::simpleFunctionDouble):
        (JSC::B3::testCallSimpleDouble):
        (JSC::B3::functionWithHellaDoubleArguments):
        (JSC::B3::testCallFunctionWithHellaDoubleArguments):
        (JSC::B3::run):

2015-11-10  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        Remove create_hash_table options and simplify build system
        https://bugs.webkit.org/show_bug.cgi?id=151081

        Reviewed by Darin Adler.

        * CMakeLists.txt: Merged native and builtin object sources and removed create_hash_table options.
        * DerivedSources.make: Ditto.
        * create_hash_table: Removed -b and -i options.

2015-11-10  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        create_hash_table should know whether a function is JSBuiltin or not.
        https://bugs.webkit.org/show_bug.cgi?id=151016

        Reviewed by Darin Adler.

        lut description information can explicitly state that a function is to be implemented as a JS built-in.
        To do so, the field used to give the C++ function must be set to "JSBuiltin".
        Updated create_hash_table script to handle that.
        create_hash_table only includes JSCBuiltins.h if at least one function is set to "JSBuiltin".

        Updated builtin generator to remove XX_BUILTIN_EXIST macro.
        A further patch should simplify the build system by removing create_hash_table -b option.

        Changes to the builtin generator are covered by rebased expectations.

        Moved all lut information to using JSBuiltin whenever needed.

        * Scripts/builtins/builtins_generate_combined_header.py:
        (generate_section_for_object): Deleted.
        (generate_section_for_code_table_macro): Deleted.
        * Scripts/builtins/builtins_templates.py:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
        * create_hash_table:
        * runtime/ArrayConstructor.cpp:
        * runtime/ArrayIteratorPrototype.cpp:
        * runtime/InspectorInstrumentationObject.cpp:
        * runtime/JSInternalPromiseConstructor.cpp:
        * runtime/JSPromiseConstructor.cpp:
        * runtime/JSPromisePrototype.cpp:
        * runtime/ModuleLoaderObject.cpp:
        * runtime/ObjectConstructor.cpp:
        * runtime/ReflectObject.cpp:
        * runtime/StringConstructor.cpp:
        * runtime/StringIteratorPrototype.cpp:

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

        Implement try/catch in the FTL
        https://bugs.webkit.org/show_bug.cgi?id=149409

        Reviewed by Filip Pizlo.

        This patch implements try/catch in the FTL in a similar
        way to how it's implemented in the DFG. The main idea is
        this: anytime an exception is thrown in a try block, 
        we OSR exit into the baseline JIT's corresponding catch
        block. We compile OSR exits in a few forms:
        1) Explicit exception checks that check VM's exception
        pointer. This is modeled explicitly in LLVM IR.
        2) OSR exits that are arrived at from genericUnwind 
        caused by an exception being thrown in a JS call (including
        getters and setters).
        3) Exception from lazy slow paths.
        4) Exception from when an IC misses and makes a slow path C Call.

        All stackmaps associated with the above types of exits all 
        take arguments that correspond to variables that are 
        bytecode-live in the catch block.

        1) Item 1 is the simplest implementation. When inside
        a try block, exception checks will emit a branch to
        an OSR exit stackmap intrinsic. This stackmap intrinsic
        takes as arguments the live catch variables.

        2) All forms of calls and GetByIds and PutByIds are implemented
        as patchpoints in LLVM. As a patchpoint, they have a stackmap ID.
        We use the same stackmap ID for the OSR exit. The OSR exit arguments
        are appended to the end of the normal arguments for the patchpoint. These
        types of OSR exits are only reached indirectly via genericUnwind.
        Therefore, the LLVM IR we generate never has a direct branch to them.
        These are the OSR exits we store in the CodeBlock's exception handling
        table. The exception handlers' code locations point to the beginning
        of the corresponding OSR exit. There is an interesting story here
        about how we preserve registers. LLVM patchpoints assume late clobber,
        i.e, they assume we use the patchpoint arguments before we clobber them.
        Therefore, it's sound for LLVM to pass us arguments in volatile registers.
        We must take care to store the arguments in volatile registers to the
        stack before making a call. We ensure we have stack space for these
        by using LLVM's alloca instruction. Then, when making a call inside
        a try block, we spill the needed registers, and if that call throws,
        we make sure the OSR exit fills the corresponding registers.

        3) Exceptions from lazy slow paths are similar to (2) except they
        don't go through generic unwind. These OSR Exits are arrived at from explicit
        exception checks in the generated lazy slow path. Therefore, the callframe
        is intact when arriving at the OSR exit. We make sure such lazy slow
        paths exception check are linked to the OSR exit's code location.

        4) This has a really interesting register preservation story.
        We may have a GetById that has an IC miss and therefore goes
        through the FTL's callOperation machinery. LLVM may also
        ask for the result to be placed in the same register as the
        base. Therefore, after the call, when storing to the result,
        we overwrite the base. This can't fly with exceptions because
        operationGetByIdOptimize may throw an exception and return "undefined". What
        we really want is the original base value for OSR exit value
        recovery. In this case, we take special care to flush the base 
        value to the stack before the callOperation GetById slow path. 
        Like call OSR exits, these types of exits will recover the base 
        value from the stack when necessary.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::canOptimizeStringObjectAccess):
        (JSC::DFG::Graph::willCatchExceptionInMachineFrame):
        * dfg/DFGGraph.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
        (JSC::DFG::JITCompiler::exceptionCheck):
        (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
        (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame): Deleted.
        * dfg/DFGJITCompiler.h:
        * dfg/DFGNodeOrigin.h:
        (JSC::DFG::NodeOrigin::withSemantic):
        (JSC::DFG::NodeOrigin::withForExitAndExitOK):
        (JSC::DFG::NodeOrigin::withExitOK):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
        * dfg/DFGOSRExitBase.h:
        (JSC::DFG::OSRExitBase::OSRExitBase):
        (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLExitArgument.h:
        (JSC::FTL::ExitArgument::withFormat):
        (JSC::FTL::ExitArgument::representation):
        * ftl/FTLExitThunkGenerator.cpp:
        (JSC::FTL::ExitThunkGenerator::~ExitThunkGenerator):
        (JSC::FTL::ExitThunkGenerator::emitThunk):
        (JSC::FTL::ExitThunkGenerator::emitThunks):
        * ftl/FTLExitThunkGenerator.h:
        (JSC::FTL::ExitThunkGenerator::didThings):
        * ftl/FTLExitValue.h:
        (JSC::FTL::ExitValue::isArgument):
        (JSC::FTL::ExitValue::isRecovery):
        (JSC::FTL::ExitValue::isObjectMaterialization):
        (JSC::FTL::ExitValue::hasIndexInStackmapLocations):
        (JSC::FTL::ExitValue::exitArgument):
        (JSC::FTL::ExitValue::rightRecoveryArgument):
        (JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
        (JSC::FTL::ExitValue::recoveryFormat):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::validateReferences):
        (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * ftl/FTLJSCall.cpp:
        (JSC::FTL::JSCall::JSCall):
        (JSC::FTL::JSCall::emit):
        * ftl/FTLJSCall.h:
        (JSC::FTL::JSCall::stackmapID):
        * ftl/FTLJSCallBase.cpp:
        (JSC::FTL::JSCallBase::JSCallBase):
        (JSC::FTL::JSCallBase::emit):
        * ftl/FTLJSCallBase.h:
        (JSC::FTL::JSCallBase::setCallSiteIndex):
        (JSC::FTL::JSCallBase::callSiteDescriptionOrigin):
        (JSC::FTL::JSCallBase::setCorrespondingGenericUnwindOSRExit):
        * ftl/FTLJSCallVarargs.cpp:
        (JSC::FTL::JSCallVarargs::numSpillSlotsNeeded):
        (JSC::FTL::JSCallVarargs::emit):
        * ftl/FTLJSCallVarargs.h:
        (JSC::FTL::JSCallVarargs::stackmapID):
        (JSC::FTL::JSCallVarargs::operator<):
        (JSC::FTL::JSCallVarargs::setCallSiteIndex):
        (JSC::FTL::JSCallVarargs::callSiteDescriptionOrigin):
        (JSC::FTL::JSCallVarargs::setCorrespondingGenericUnwindOSRExit):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::getById):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
        (JSC::FTL::DFG::LowerDFGToLLVM::terminate):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendTypeCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitBranchToOSRExitIfWillCatchException):
        (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForNode):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        (JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException):
        (JSC::FTL::OSRExit::spillRegistersToSpillSlot):
        (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
        * ftl/FTLOSRExit.h:
        (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
        * ftl/FTLOSRExitCompilationInfo.h:
        (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLState.cpp:
        (JSC::FTL::State::State):
        * ftl/FTLState.h:
        * interpreter/Interpreter.cpp:
        (JSC::findExceptionHandler):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::specialRegisters):
        (JSC::RegisterSet::volatileRegistersForJSCall):
        (JSC::RegisterSet::stubUnavailableRegisters):
        * jit/RegisterSet.h:
        * tests/stress/ftl-try-catch-getter-ic-fail-to-call-operation-throw-error.js: Added.
        (assert):
        (let.oThrow.get f):
        (let.o2.get f):
        (foo):
        (f):
        * tests/stress/ftl-try-catch-getter-throw.js: Added.
        (assert):
        (random):
        (foo):
        (f):
        (let.o2.get f):
        * tests/stress/ftl-try-catch-oom-error-lazy-slow-path.js: Added.
        (assert):
        (a):
        (b):
        (c):
        (d):
        (e):
        (f):
        (g):
        (foo):
        (blah):
        * tests/stress/ftl-try-catch-patchpoint-with-volatile-registers.js: Added.
        (assert):
        (o1.get f):
        (a):
        (b):
        (c):
        (d):
        (e):
        (f):
        (g):
        (o2.get f):
        (foo):
        * tests/stress/ftl-try-catch-setter-throw.js: Added.
        (foo):
        (assert):
        (f):
        (let.o2.set f):
        * tests/stress/ftl-try-catch-tail-call-inilned-caller.js: Added.
        (value):
        (assert):
        (validate):
        (bar):
        (baz):
        (jaz):
        * tests/stress/ftl-try-catch-varargs-call-throws.js: Added.
        (foo):
        (f):
        * tests/stress/try-catch-stub-routine-replaced.js:
        (hello):
        (foo):

2015-11-09  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        Built-in generator should check that there are no duplicate in JS built-in internal functions
        https://bugs.webkit.org/show_bug.cgi?id=151018

        Reviewed by Brian Burg.

        Added @internal to corresponding JS built-in files.
        Added check in built-in generator so that clashing names result in an error.

        * Scripts/builtins/builtins_generate_combined_header.py:
        (generate_section_for_code_name_macro):
        * Scripts/builtins/builtins_model.py:
        (BuiltinsCollection.all_internal_functions):
        * builtins/GlobalObject.js:
        * builtins/Operations.Promise.js:
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-error: Added.
        * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result: Added.

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

        DFG::PutStackSinkingPhase should not treat the stack variables written by LoadVarargs/ForwardVarargs as being live
        https://bugs.webkit.org/show_bug.cgi?id=145295

        Reviewed by Filip Pizlo.

        This patch fixes PutStackSinkingPhase to no longer escape the stack
        locations that LoadVarargs and ForwardVarargs write to. We used
        to consider sinking PutStacks right before a LoadVarargs/ForwardVarargs
        because we considered them uses of such stack locations. They aren't
        uses of those stack locations, they unconditionally write to those
        stack locations. Sinking PutStacks to these nodes was not needed before,
        but seemed mostly innocent. But I ran into a problem with this while implementing 
        FTL try/catch where we would end up having to generate a value for a sunken PutStack 
        right before a LoadVarargs. This would cause us to issue a GetStack that loaded garbage that 
        was then forwarded into a Phi that was used as the source as the PutStack. This caused the
        abstract interpreter to confuse itself on type information for the garbage GetStack
        that was fed into the Phi, which would cause the abstract interpreter to then claim 
        that the basic block with the PutStack in it would never be reached. This isn't true, the 
        block would indeed be reached. The solution here is to be more precise about the 
        liveness of locals w.r.t LoadVarargs and ForwardVarargs.

        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::PreciseLocalClobberizeAdaptor):
        (JSC::DFG::PreciseLocalClobberizeAdaptor::write):
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGSSACalculator.h:

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

        B3->Air lowering should support CCall
        https://bugs.webkit.org/show_bug.cgi?id=151043

        Reviewed by Geoffrey Garen.

        Adds support for lowering CCall to Air, and adds a test that makes calls. I cannot test doubles
        until https://bugs.webkit.org/show_bug.cgi?id=151002 lands, but this does test integer
        arguments pretty thoroughly including a test for lots of arguments. That test ensures that the
        arguments go to registers and the stack in the right order and such.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createCompare):
        (JSC::B3::Air::LowerToAir::marshallCCallArgument):
        (JSC::B3::Air::LowerToAir::lower):
        * b3/B3Opcode.h:
        * b3/air/AirCCallSpecial.cpp:
        (JSC::B3::Air::CCallSpecial::forEachArg):
        (JSC::B3::Air::CCallSpecial::isValid):
        (JSC::B3::Air::CCallSpecial::admitsStack):
        (JSC::B3::Air::CCallSpecial::generate):
        * b3/air/AirCCallSpecial.h:
        * b3/testb3.cpp:
        (JSC::B3::testCompare):
        (JSC::B3::simpleFunction):
        (JSC::B3::testCallSimple):
        (JSC::B3::functionWithHellaArguments):
        (JSC::B3::testCallFunctionWithHellaArguments):
        (JSC::B3::run):
        * jit/FPRInfo.h:

2015-11-09  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: $0 stops working after navigating to a different domain
        https://bugs.webkit.org/show_bug.cgi?id=147962

        Reviewed by Brian Burg.

        Extract the per-GlobalObject cache of JSValue wrappers for
        InjectedScriptHost objects to be reused by WebCore for its
        CommandLineAPIHost objects injected into multiple contexts.

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

        * inspector/PerGlobalObjectWrapperWorld.h:
        * inspector/PerGlobalObjectWrapperWorld.cpp:
        (Inspector::PerGlobalObjectWrapperWorld::getWrapper):
        (Inspector::PerGlobalObjectWrapperWorld::addWrapper):
        (Inspector::PerGlobalObjectWrapperWorld::clearAllWrappers):
        Hold a bunch of per-global-object wrappers for an object
        that will outlive the global object. This inspector does this
        for host objects that it exposes into scripts it injects into
        each execution context created by the page.

        * inspector/InjectedScriptHost.cpp:
        (Inspector::InjectedScriptHost::wrapper):
        (Inspector::InjectedScriptHost::clearAllWrappers):
        (Inspector::InjectedScriptHost::jsWrapper): Deleted.
        (Inspector::clearWrapperFromValue): Deleted.
        (Inspector::InjectedScriptHost::clearWrapper): Deleted.
        Extract and simplify the Per-GlobalObject wrapping into a class.
        Simplify object construction as well.

        * inspector/InjectedScriptHost.h:
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::createInjectedScript):
        (Inspector::InjectedScriptManager::discardInjectedScripts):
        Make discarding virtual so subclasses may also discard injected scripts.

        * inspector/JSInjectedScriptHost.cpp:
        (Inspector::JSInjectedScriptHost::JSInjectedScriptHost):
        (Inspector::JSInjectedScriptHost::releaseImpl): Deleted.
        (Inspector::JSInjectedScriptHost::~JSInjectedScriptHost): Deleted.
        (Inspector::toJS): Deleted.
        (Inspector::toJSInjectedScriptHost): Deleted.
        * inspector/JSInjectedScriptHost.h:
        (Inspector::JSInjectedScriptHost::create):
        (Inspector::JSInjectedScriptHost::impl):
        Update this code originally copied from older generated bindings to
        be more like new generated bindings and remove some now unused code.

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

        B3 should be able to compile a program with a double constant
        https://bugs.webkit.org/show_bug.cgi?id=151002

        Reviewed by Benjamin Poulain.

        This implements a bunch of annoying stuff that is necessary to support constants that need a
        data section, such as double constants on X86_64:

        - B3::Procedure can now tell you what to keep alive in addition to the MacroAssemblerCodeRef.
          We call this the B3::OpaqueByproducts. It's the client's responsibility to keep this alive
          after calling B3::generate().

        - Added a new helper for compiling B3 code, called B3::Compilation. Constructing a
          Compilation runs the compiler. Then you can pass around a Compilation the way you would
          have passed around a MacroAssemblerCodeRef.

        - Added a constant motion phase, called moveConstants(). This does very simple constant
          hoisting/sinking: it makes sure that each constant is only materialized in one place in
          each basic block. It uses a DataSection, which is a kind of OpaqueByproduct, to store
          double constants.

        - The way I wanted to do constant motion is to basically track what constants are of interest
          and then recreate them as needed, so the original Values become irrelevant in the process.
          To do that, I needed an abstraction that is almost identical to the DFG PureValue
          abstraction that we use for CSE. So, I created such a thing, and called it ValueKey. It
          can be used to compare and hash pure Values, and to recreate them as needed.

        - Fixed the lowering's handling of constants so that we don't perturb the placement of the
          constant materializations.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
        (JSC::MacroAssemblerX86Common::moveZeroToDouble):
        (JSC::MacroAssemblerX86Common::branchDoubleNonZero):
        * b3/B3Common.h:
        (JSC::B3::isIdentical):
        (JSC::B3::isRepresentableAsImpl):
        * b3/B3Compilation.cpp: Added.
        (JSC::B3::Compilation::Compilation):
        (JSC::B3::Compilation::~Compilation):
        * b3/B3Compilation.h: Added.
        (JSC::B3::Compilation::code):
        * b3/B3ConstDoubleValue.h:
        (JSC::B3::ConstDoubleValue::accepts): Deleted.
        * b3/B3DataSection.cpp: Added.
        (JSC::B3::DataSection::DataSection):
        (JSC::B3::DataSection::~DataSection):
        (JSC::B3::DataSection::dump):
        * b3/B3DataSection.h: Added.
        (JSC::B3::DataSection::data):
        (JSC::B3::DataSection::size):
        * b3/B3Generate.cpp:
        (JSC::B3::generate):
        (JSC::B3::generateToAir):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::imm):
        (JSC::B3::Air::LowerToAir::immOrTmp):
        (JSC::B3::Air::LowerToAir::fillStackmap):
        (JSC::B3::Air::LowerToAir::lower):
        (JSC::B3::Air::LowerToAir::immForMove): Deleted.
        (JSC::B3::Air::LowerToAir::immOrTmpForMove): Deleted.
        * b3/B3MoveConstants.cpp: Added.
        (JSC::B3::moveConstants):
        * b3/B3MoveConstants.h: Added.
        * b3/B3OpaqueByproduct.h: Added.
        (JSC::B3::OpaqueByproduct::OpaqueByproduct):
        (JSC::B3::OpaqueByproduct::~OpaqueByproduct):
        * b3/B3OpaqueByproducts.cpp: Added.
        (JSC::B3::OpaqueByproducts::OpaqueByproducts):
        (JSC::B3::OpaqueByproducts::~OpaqueByproducts):
        (JSC::B3::OpaqueByproducts::add):
        (JSC::B3::OpaqueByproducts::dump):
        * b3/B3OpaqueByproducts.h: Added.
        (JSC::B3::OpaqueByproducts::count):
        * b3/B3Opcode.h:
        (JSC::B3::constPtrOpcode):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::Procedure):
        (JSC::B3::Procedure::dump):
        (JSC::B3::Procedure::blocksInPreOrder):
        (JSC::B3::Procedure::deleteValue):
        (JSC::B3::Procedure::addDataSection):
        (JSC::B3::Procedure::addValueIndex):
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::lastPhaseName):
        (JSC::B3::Procedure::byproducts):
        (JSC::B3::Procedure::takeByproducts):
        * b3/B3Type.h:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::key):
        (JSC::B3::Value::performSubstitution):
        * b3/B3Value.h:
        * b3/B3ValueKey.cpp: Added.
        (JSC::B3::ValueKey::dump):
        (JSC::B3::ValueKey::materialize):
        * b3/B3ValueKey.h: Added.
        (JSC::B3::ValueKey::ValueKey):
        (JSC::B3::ValueKey::opcode):
        (JSC::B3::ValueKey::type):
        (JSC::B3::ValueKey::childIndex):
        (JSC::B3::ValueKey::value):
        (JSC::B3::ValueKey::doubleValue):
        (JSC::B3::ValueKey::operator==):
        (JSC::B3::ValueKey::operator!=):
        (JSC::B3::ValueKey::hash):
        (JSC::B3::ValueKey::operator bool):
        (JSC::B3::ValueKey::canMaterialize):
        (JSC::B3::ValueKey::isHashTableDeletedValue):
        (JSC::B3::ValueKeyHash::hash):
        (JSC::B3::ValueKeyHash::equal):
        * b3/B3ValueKeyInlines.h: Added.
        (JSC::B3::ValueKey::ValueKey):
        (JSC::B3::ValueKey::child):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::Code):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::proc):
        (JSC::B3::Air::Code::lastPhaseName):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::compile):
        (JSC::B3::invoke):
        (JSC::B3::compileAndRun):
        (JSC::B3::test42):
        (JSC::B3::testBranch):
        (JSC::B3::testBranchPtr):
        (JSC::B3::testDiamond):
        (JSC::B3::testBranchNotEqual):
        (JSC::B3::testBranchNotEqualCommute):
        (JSC::B3::testBranchNotEqualNotEqual):
        (JSC::B3::testBranchEqual):
        (JSC::B3::testBranchEqualEqual):
        (JSC::B3::testBranchEqualCommute):
        (JSC::B3::testBranchEqualEqual1):
        (JSC::B3::testBranchFold):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::testCompare):
        (JSC::B3::testReturnDouble):
        (JSC::B3::run):

2015-11-09  Michael Saboff  <msaboff@apple.com>

        Need a function that will provide Nth argument register
        https://bugs.webkit.org/show_bug.cgi?id=151041

        Reviewed by Filip Pizlo.

        For 64 bit platforms, return the Nth architected argument register, otherwise InvalidGPRReg.

        * jit/GPRInfo.h:
        (JSC::argumentRegisterFor): Added to return the Nth architected argument register if defined
        for a platform or InvalidGPRReg if not.

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

        [FTL] Fix the build with LLVM 3.7
        https://bugs.webkit.org/show_bug.cgi?id=150595

        Reviewed by Darin Adler.

        * llvm/LLVMAPIFunctions.h: Removed the unused BuildLandingPad function.

2015-11-09  Xabier Rodriguez Calvar  <calvaris@igalia.com>

        [Streams API] Shield implementation from mangling then and catch promise methods
        https://bugs.webkit.org/show_bug.cgi?id=150934

        Reviewed by Youenn Fablet.

        Since the prototype is not deletable and readonly we only have to care about ensuring that it has the right
        @then and @catch internal methods.

        * runtime/JSPromisePrototype.h:
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::addOwnInternalSlots): Added to create the proper @then and @catch internal slots.
        (JSC::JSPromisePrototype::create): Call addOwnInternalSlots.

2015-11-09  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        JS Built-ins functions should be able to assert
        https://bugs.webkit.org/show_bug.cgi?id=150333

        Reviewed by Yusuke Suzuki.

        Introduced @assert to enable asserting in JS built-ins.
        Adding a new bytecode 'assert' to implement it.
        In debug builds, @assert generates 'assert' bytecodes.
        In release builds, no byte code is produced for @assert.

        In case assert is false, the JS built-in and the line number are dumped.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitAssert):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp: Generating op_assert bytecode for @assert for Debug builds.
        (JSC::BytecodeIntrinsicNode::emit_intrinsic_assert):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_assert):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_create_assert):
        * llint/LowLevelInterpreter.asm:
        * runtime/CommonIdentifiers.h: Adding @assert identifier as intrinsic.
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:

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

        [ES6] Minimize ES6_CLASS_SYNTAX ifdefs
        https://bugs.webkit.org/show_bug.cgi?id=151006

        Reviewed by Darin Adler.

        This patch minimizes ENABLE_ES6_CLASS_SYNTAX ifdefs.
        It keeps several ENABLE_ES6_CLASS_SYNTAX ifdefs in Parser.cpp.

        - super meta property
        - class declaration parsing
        - class expression parsing
        - class with import declaration

        This change makes difference minimal between the enabled and disabled configurations;
        reducing accidental build breaks of the disabled configuration.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::constructorKind): Deleted.
        * bytecompiler/NodesCodegen.cpp:
        * parser/ASTBuilder.h:
        * parser/NodeConstructors.h:
        * parser/Nodes.h:
        * parser/Parser.cpp:
        * parser/Parser.h:
        (JSC::Scope::hasDirectSuper): Deleted.
        (JSC::Scope::needsSuperBinding): Deleted.
        * parser/ParserFunctionInfo.h:
        * parser/ParserTokens.h:
        * parser/SyntaxChecker.h:

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

        Use StringView::upconvertedCharacters() to make a 16-bit copy in String.prototype.normalize
        https://bugs.webkit.org/show_bug.cgi?id=151005

        Reviewed by Michael Saboff.

        The ICU's unorm_normalize function used by String.prototype.normalize
        requires a 16-bit string. This patch uses StringView::upconvertedCharacters()
        to make a 16-bit copy of a string.

        * runtime/StringPrototype.cpp:
        (JSC::stringProtoFuncNormalize):

2015-11-08  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        generate-js-builtins.js should support @internal annotation
        https://bugs.webkit.org/show_bug.cgi?id=150929

        Reviewed by Darin Adler.

        * Scripts/builtins/builtins_generate_separate_header.py:
        (BuiltinsSeparateHeaderGenerator.generate_output): Generate internal boilerplate code only if @internal annotation is available.
        * Scripts/builtins/builtins_templates.py: Split boilerplate in two templates (one that is used for all built-ins and one dedicated to internals).
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Removed internal boilerplate.
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.

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

        [ES6] Minimize ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX ifdefs
        https://bugs.webkit.org/show_bug.cgi?id=150998

        Reviewed by Geoffrey Garen.

        This patch minimizes ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX ifdefs.
        It only keeps 2 ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX in Parser.cpp, one for
        template literals and one for tagged templates.
        This change makes difference minimal between the enabled and disabled configurations;
        reducing accidental build breaks of the disabled configuration.

        * bytecompiler/BytecodeGenerator.cpp:
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        * parser/ASTBuilder.h:
        * parser/Lexer.cpp:
        (JSC::Lexer<T>::Lexer): Deleted.
        (JSC::Lexer<T>::lex): Deleted.
        * parser/Lexer.h:
        * parser/NodeConstructors.h:
        * parser/Nodes.h:
        * parser/Parser.cpp:
        * parser/Parser.h:
        * parser/SyntaxChecker.h:

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

        B3->Air lowering should do pattern matching the old fashioned way
        https://bugs.webkit.org/show_bug.cgi?id=150994

        Reviewed by Geoffrey Garen.

        When I first wrote the B3->Air lowering prototype, I was convinced that the patterns would get
        so gnarly that we'd want a pattern language to write them in. So I made one, and that's what
        the lowering has used. But as we've worked with the IR, we've found that it's very easy to
        pattern match in C++ using the B3 API, and we've also found that most of the patterns we wrote
        using the pattern language were mostly trivial. So this change removes the pattern match code
        generator and the patterns files, and redoes the lowering using good old fashioned switch
        statements. This actually reduces the total code of the lowering.

        I also took the opportunity to refactoring UnOp and BinOp lowering. We had a lot of repetetive
        code for 32-vs-64-bit opcode selection, so I factored that out into a helper. This also saves a
        lot of code.

        * CMakeLists.txt:
        * DerivedSources.make:
        * b3/B3AddressMatcher.patterns: Removed.
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::LowerToAir):
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::highBitsAreZero):
        (JSC::B3::Air::LowerToAir::tmp):
        (JSC::B3::Air::LowerToAir::canBeInternal):
        (JSC::B3::Air::LowerToAir::commitInternal):
        (JSC::B3::Air::LowerToAir::crossesInterference):
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        (JSC::B3::Air::LowerToAir::addr):
        (JSC::B3::Air::LowerToAir::loadPromise):
        (JSC::B3::Air::LowerToAir::imm):
        (JSC::B3::Air::LowerToAir::immForMove):
        (JSC::B3::Air::LowerToAir::immOrTmpForMove):
        (JSC::B3::Air::LowerToAir::tryOpcodeForType):
        (JSC::B3::Air::LowerToAir::opcodeForType):
        (JSC::B3::Air::LowerToAir::appendUnOp):
        (JSC::B3::Air::LowerToAir::appendBinOp):
        (JSC::B3::Air::LowerToAir::appendShift):
        (JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
        (JSC::B3::Air::LowerToAir::append):
        (JSC::B3::Air::LowerToAir::ensureSpecial):
        (JSC::B3::Air::LowerToAir::fillStackmap):
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        (JSC::B3::Air::LowerToAir::createBranch):
        (JSC::B3::Air::LowerToAir::createCompare):
        (JSC::B3::Air::LowerToAir::lower):
        (JSC::B3::Air::LowerToAir::immOrTmp): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::AddressSelector): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptRoot): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptRootLate): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptInternals): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptInternalsLate): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptOperands): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptOperandsLate): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::tryAddShift1): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::tryAddShift2): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::tryAdd): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::tryFramePointer): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::tryStackSlot): Deleted.
        (JSC::B3::Air::LowerToAir::AddressSelector::tryDirect): Deleted.
        (JSC::B3::Air::LowerToAir::acceptRoot): Deleted.
        (JSC::B3::Air::LowerToAir::acceptRootLate): Deleted.
        (JSC::B3::Air::LowerToAir::acceptInternals): Deleted.
        (JSC::B3::Air::LowerToAir::acceptInternalsLate): Deleted.
        (JSC::B3::Air::LowerToAir::acceptOperands): Deleted.
        (JSC::B3::Air::LowerToAir::acceptOperandsLate): Deleted.
        (JSC::B3::Air::LowerToAir::tryLoad): Deleted.
        (JSC::B3::Air::LowerToAir::tryLoad8S): Deleted.
        (JSC::B3::Air::LowerToAir::tryLoad8Z): Deleted.
        (JSC::B3::Air::LowerToAir::tryLoad16S): Deleted.
        (JSC::B3::Air::LowerToAir::tryLoad16Z): Deleted.
        (JSC::B3::Air::LowerToAir::tryAdd): Deleted.
        (JSC::B3::Air::LowerToAir::trySub): Deleted.
        (JSC::B3::Air::LowerToAir::tryAnd): Deleted.
        (JSC::B3::Air::LowerToAir::tryOr): Deleted.
        (JSC::B3::Air::LowerToAir::tryXor): Deleted.
        (JSC::B3::Air::LowerToAir::tryShl): Deleted.
        (JSC::B3::Air::LowerToAir::trySShr): Deleted.
        (JSC::B3::Air::LowerToAir::tryZShr): Deleted.
        (JSC::B3::Air::LowerToAir::tryStoreAddLoad): Deleted.
        (JSC::B3::Air::LowerToAir::tryStoreSubLoad): Deleted.
        (JSC::B3::Air::LowerToAir::tryStoreAndLoad): Deleted.
        (JSC::B3::Air::LowerToAir::tryStore): Deleted.
        (JSC::B3::Air::LowerToAir::tryTrunc): Deleted.
        (JSC::B3::Air::LowerToAir::tryZExt32): Deleted.
        (JSC::B3::Air::LowerToAir::tryArgumentReg): Deleted.
        (JSC::B3::Air::LowerToAir::tryConst32): Deleted.
        (JSC::B3::Air::LowerToAir::tryConst64): Deleted.
        (JSC::B3::Air::LowerToAir::tryFramePointer): Deleted.
        (JSC::B3::Air::LowerToAir::tryStackSlot): Deleted.
        (JSC::B3::Air::LowerToAir::tryEqual): Deleted.
        (JSC::B3::Air::LowerToAir::tryNotEqual): Deleted.
        (JSC::B3::Air::LowerToAir::tryLessThan): Deleted.
        (JSC::B3::Air::LowerToAir::tryGreaterThan): Deleted.
        (JSC::B3::Air::LowerToAir::tryLessEqual): Deleted.
        (JSC::B3::Air::LowerToAir::tryGreaterEqual): Deleted.
        (JSC::B3::Air::LowerToAir::tryAbove): Deleted.
        (JSC::B3::Air::LowerToAir::tryBelow): Deleted.
        (JSC::B3::Air::LowerToAir::tryAboveEqual): Deleted.
        (JSC::B3::Air::LowerToAir::tryBelowEqual): Deleted.
        (JSC::B3::Air::LowerToAir::tryPatchpoint): Deleted.
        (JSC::B3::Air::LowerToAir::tryCheck): Deleted.
        (JSC::B3::Air::LowerToAir::tryUpsilon): Deleted.
        (JSC::B3::Air::LowerToAir::tryPhi): Deleted.
        (JSC::B3::Air::LowerToAir::tryBranch): Deleted.
        (JSC::B3::Air::LowerToAir::tryJump): Deleted.
        (JSC::B3::Air::LowerToAir::tryIdentity): Deleted.
        (JSC::B3::Air::LowerToAir::tryReturn): Deleted.
        * b3/B3LoweringMatcher.patterns: Removed.
        * b3/generate_pattern_matcher.rb: Removed.

2015-11-07  Michael Saboff  <msaboff@apple.com>

        Add conditional moves to the MacroAssembler
        https://bugs.webkit.org/show_bug.cgi?id=150761

        Reviewed by Filip Pizlo.

        Added moveConditionally, moveConditionallyTest & moveConditionallyDouble to X86 macro assemblers.
        Bench tested correct opcodes and operations on X86-64 and X86 for a select number of comparisons.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::moveConditionally):
        (JSC::MacroAssemblerX86Common::moveConditionallyTest):
        (JSC::MacroAssemblerX86Common::moveConditionallyDouble):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::cmovcc):
        (JSC::X86Assembler::cmovl_rr):
        (JSC::X86Assembler::cmovl_mr):
        (JSC::X86Assembler::cmovel_rr):
        (JSC::X86Assembler::cmovnel_rr):
        (JSC::X86Assembler::cmovpl_rr):
        (JSC::X86Assembler::cmovnpl_rr):
        (JSC::X86Assembler::cmovq_rr):
        (JSC::X86Assembler::cmovq_mr):
        (JSC::X86Assembler::cmoveq_rr):
        (JSC::X86Assembler::cmovneq_rr):
        (JSC::X86Assembler::cmovpq_rr):
        (JSC::X86Assembler::cmovnpq_rr):
        (JSC::X86Assembler::X86InstructionFormatter::twoByteOp64):

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

        Control Flow Profiler should keep execution counts of basic blocks
        https://bugs.webkit.org/show_bug.cgi?id=146099

        Reviewed by Mark Lam.

        This patch changes the control flow profiler to now
        keep track of execution counts for each basic block
        instead of a boolean indicating if the basic block has 
        executed at all.  This has the consequence of us having to 
        always compile all op_profile_control_flows in the baseline and DFG.

        This patch adds a new "executionCount" field to the inspector protocol
        corresponding to the execution of a basic block. This patch, for now,
        still maintains the previous field of "hasExecuted" even though this is
        redundant with "executionCount".

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::getBasicBlocks):
        * inspector/protocol/Runtime.json:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_profile_control_flow):
        (JSC::JIT::emit_op_create_direct_arguments):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionHasBasicBlockExecuted):
        (functionBasicBlockExecutionCount):
        (functionEnableExceptionFuzz):
        (functionDrainMicrotasks):
        (functionIs32BitPlatform):
        (functionLoadWebAssembly):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/BasicBlockLocation.cpp:
        (JSC::BasicBlockLocation::BasicBlockLocation):
        (JSC::BasicBlockLocation::dumpData):
        (JSC::BasicBlockLocation::emitExecuteCode):
        * runtime/BasicBlockLocation.h:
        (JSC::BasicBlockLocation::endOffset):
        (JSC::BasicBlockLocation::setStartOffset):
        (JSC::BasicBlockLocation::setEndOffset):
        (JSC::BasicBlockLocation::hasExecuted):
        (JSC::BasicBlockLocation::executionCount):
        * runtime/ControlFlowProfiler.cpp:
        (JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
        (JSC::findBasicBlockAtTextOffset):
        (JSC::ControlFlowProfiler::hasBasicBlockAtTextOffsetBeenExecuted):
        (JSC::ControlFlowProfiler::basicBlockExecutionCountAtTextOffset):
        * runtime/ControlFlowProfiler.h:
        (JSC::ControlFlowProfiler::dummyBasicBlock):
        * tests/controlFlowProfiler/execution-count.js: Added.
        (noop):
        (foo):
        (a):
        (b):
        (baz):
        (jaz):
        (testWhile):
        (is32BitPlatform.testMax):
        (is32BitPlatform):

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

        B3 and Air should simplify CFGs
        https://bugs.webkit.org/show_bug.cgi?id=150960

        Reviewed by Geoffrey Garen.

        This adds CFG simplification to both B3 and Air.

        In B3, the simplification is done inside the B3::reduceStrength() fixpoint because we expect
        that it will help to reveal more optimization opportunities. This is going to be particularly
        true when we add Phi elimination.

        In Air, the simplification is its own phase. We expect it to produce most of its benefits once
        we have coalescing. Then, CFG simplification in Air will unbreak critial edges.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbortReason.h:
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::oops): Reveal this as a method so that we can have an Oops instruction.
        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::predecessor):
        (JSC::B3::BasicBlock::predecessors):
        (JSC::B3::BasicBlock::containsPredecessor):
        * b3/B3BasicBlockUtils.h: Bunch of fixes for blocks being killed.
        (JSC::B3::replacePredecessor):
        (JSC::B3::resetReachability):
        * b3/B3ReduceStrength.cpp: Implement B3 CFG simplification.
        * b3/B3ReduceStrength.h:
        * b3/air/AirBasicBlock.h:
        (JSC::B3::Air::BasicBlock::resize):
        (JSC::B3::Air::BasicBlock::insts):
        (JSC::B3::Air::BasicBlock::appendInst):
        (JSC::B3::Air::BasicBlock::containsPredecessor):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirInst.cpp:
        (JSC::B3::Air::Inst::hasArgEffects):
        (JSC::B3::Air::Inst::dump):
        * b3/air/AirInst.h:
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::Liveness::Liveness): Fix for when blocks were killed.
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirSimplifyCFG.cpp: Added.
        (JSC::B3::Air::simplifyCFG):
        * b3/air/AirSimplifyCFG.h: Added.

2015-11-05  Nikos Andronikos  <nikos.andronikos-webkit@cisra.canon.com.au>

        Add runtime and compile time flags for enabling Web Animations API and model.
        https://bugs.webkit.org/show_bug.cgi?id=150914

        Reviewed by Benjamin Poulain.

        Add ENABLE_WEB_ANIMATIONS compile time flag, runtime flag webAnimationsEnabled and Expose WK2 preference for runtime flag.

        * Configurations/FeatureDefines.xcconfig:

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

        Layout Test js/intl-collator.html is crashing on win 7 debug
        https://bugs.webkit.org/show_bug.cgi?id=150943

        Reviewed by Geoffrey Garen.

        The string length returned by ICU's uenum_next seems to be unreliable
        on an old version of ICU. Since uenum_next returns a null-terminated
        string anyway, this patch removes the use of the length.

        * runtime/IntlCollatorConstructor.cpp:
        (JSC::sortLocaleData):

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

        Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=150958 and
        https://bugs.webkit.org/show_bug.cgi?id=150954.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        * b3/B3ReduceStrength.cpp:

2015-11-05  Aleksandr Skachkov  <gskachkov@gmail.com>

        Using emitResolveScope & emitGetFromScope with 'this' that is TDZ lead to segfault in DFG
        https://bugs.webkit.org/show_bug.cgi?id=150902

        Reviewed by Geoffrey Garen.

        Tiny fix provided by Saam Barati. This fix prevent segfault error in arrow function, 
        when it uses in constructor of derived class, before 'super' is called.

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

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

        B3->Air lowering should have a story for compare-branch fusion
        https://bugs.webkit.org/show_bug.cgi?id=150721

        Reviewed by Geoffrey Garen.

        This adds comprehensive support for compares and compare/branch fusion to B3. The fusion is
        super aggressive. It can even handle things like Branch(LessThan(Load8S(...), constant)). It
        can even handle flipping the operands to the branch, and flipping the comparison condition,
        if it enables a more efficient instruction. This happens when there is asymmetry in the
        admitted argument kinds. For example, Branch32 will only accept an Imm as a second operand.
        If we do a LessThan(constant, load) then we will generate it as:

            Branch32 GreaterThan, (addr), $imm

        This also supports compiling and fusing tests, and to some extent, compiling and fusing
        double compares. Though we cannot test doubles yet because we don't have enough support for
        that.

        This also supports fusing compare/branches in Checks. We basically get that for free.

        Because I wanted to fuse comparisons with sub-32-bit loads, I added support for those loads
        directly, too.

        The tests are now getting super big, so I made testb3 run tests in parallel.

        Finally, this slightly changes the semantics of Branch and Check. Previously they would have
        accepted a double to branch on. I found that this is awkward. It's especially awkward since
        we want to be explicit about when a double zero constant is materialized. So, from now on, we
        require that to branch on a double being non-zero, you have to do Branch(NotEqual(value, 0)).

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::invert):
        (JSC::MacroAssembler::isInvertible):
        (JSC::MacroAssembler::flip):
        (JSC::MacroAssembler::isSigned):
        (JSC::MacroAssembler::isUnsigned):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::test32):
        (JSC::MacroAssemblerX86Common::invert):
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::Key::Key):
        (JSC::B3::CheckSpecial::Key::dump):
        (JSC::B3::CheckSpecial::CheckSpecial):
        (JSC::B3::CheckSpecial::~CheckSpecial):
        * b3/B3CheckSpecial.h:
        (JSC::B3::CheckSpecial::Key::Key):
        (JSC::B3::CheckSpecial::Key::operator==):
        (JSC::B3::CheckSpecial::Key::operator!=):
        (JSC::B3::CheckSpecial::Key::operator bool):
        (JSC::B3::CheckSpecial::Key::opcode):
        (JSC::B3::CheckSpecial::Key::numArgs):
        (JSC::B3::CheckSpecial::Key::isHashTableDeletedValue):
        (JSC::B3::CheckSpecial::Key::hash):
        (JSC::B3::CheckSpecialKeyHash::hash):
        (JSC::B3::CheckSpecialKeyHash::equal):
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::zShrConstant):
        (JSC::B3::Const32Value::equalConstant):
        (JSC::B3::Const32Value::notEqualConstant):
        (JSC::B3::Const32Value::lessThanConstant):
        (JSC::B3::Const32Value::greaterThanConstant):
        (JSC::B3::Const32Value::lessEqualConstant):
        (JSC::B3::Const32Value::greaterEqualConstant):
        (JSC::B3::Const32Value::aboveConstant):
        (JSC::B3::Const32Value::belowConstant):
        (JSC::B3::Const32Value::aboveEqualConstant):
        (JSC::B3::Const32Value::belowEqualConstant):
        (JSC::B3::Const32Value::dumpMeta):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::zShrConstant):
        (JSC::B3::Const64Value::equalConstant):
        (JSC::B3::Const64Value::notEqualConstant):
        (JSC::B3::Const64Value::lessThanConstant):
        (JSC::B3::Const64Value::greaterThanConstant):
        (JSC::B3::Const64Value::lessEqualConstant):
        (JSC::B3::Const64Value::greaterEqualConstant):
        (JSC::B3::Const64Value::aboveConstant):
        (JSC::B3::Const64Value::belowConstant):
        (JSC::B3::Const64Value::aboveEqualConstant):
        (JSC::B3::Const64Value::belowEqualConstant):
        (JSC::B3::Const64Value::dumpMeta):
        * b3/B3Const64Value.h:
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::subConstant):
        (JSC::B3::ConstDoubleValue::equalConstant):
        (JSC::B3::ConstDoubleValue::notEqualConstant):
        (JSC::B3::ConstDoubleValue::lessThanConstant):
        (JSC::B3::ConstDoubleValue::greaterThanConstant):
        (JSC::B3::ConstDoubleValue::lessEqualConstant):
        (JSC::B3::ConstDoubleValue::greaterEqualConstant):
        (JSC::B3::ConstDoubleValue::dumpMeta):
        * b3/B3ConstDoubleValue.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::LowerToAir):
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::shouldCopyPropagate):
        (JSC::B3::Air::LowerToAir::ArgPromise::ArgPromise):
        (JSC::B3::Air::LowerToAir::ArgPromise::tmp):
        (JSC::B3::Air::LowerToAir::ArgPromise::operator bool):
        (JSC::B3::Air::LowerToAir::ArgPromise::kind):
        (JSC::B3::Air::LowerToAir::ArgPromise::peek):
        (JSC::B3::Air::LowerToAir::ArgPromise::consume):
        (JSC::B3::Air::LowerToAir::tmp):
        (JSC::B3::Air::LowerToAir::tmpPromise):
        (JSC::B3::Air::LowerToAir::canBeInternal):
        (JSC::B3::Air::LowerToAir::addr):
        (JSC::B3::Air::LowerToAir::loadPromise):
        (JSC::B3::Air::LowerToAir::imm):
        (JSC::B3::Air::LowerToAir::appendBinOp):
        (JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
        (JSC::B3::Air::LowerToAir::createGenericCompare):
        (JSC::B3::Air::LowerToAir::createBranch):
        (JSC::B3::Air::LowerToAir::createCompare):
        (JSC::B3::Air::LowerToAir::tryLoad):
        (JSC::B3::Air::LowerToAir::tryLoad8S):
        (JSC::B3::Air::LowerToAir::tryLoad8Z):
        (JSC::B3::Air::LowerToAir::tryLoad16S):
        (JSC::B3::Air::LowerToAir::tryLoad16Z):
        (JSC::B3::Air::LowerToAir::tryAdd):
        (JSC::B3::Air::LowerToAir::tryStackSlot):
        (JSC::B3::Air::LowerToAir::tryEqual):
        (JSC::B3::Air::LowerToAir::tryNotEqual):
        (JSC::B3::Air::LowerToAir::tryLessThan):
        (JSC::B3::Air::LowerToAir::tryGreaterThan):
        (JSC::B3::Air::LowerToAir::tryLessEqual):
        (JSC::B3::Air::LowerToAir::tryGreaterEqual):
        (JSC::B3::Air::LowerToAir::tryAbove):
        (JSC::B3::Air::LowerToAir::tryBelow):
        (JSC::B3::Air::LowerToAir::tryAboveEqual):
        (JSC::B3::Air::LowerToAir::tryBelowEqual):
        (JSC::B3::Air::LowerToAir::tryPatchpoint):
        (JSC::B3::Air::LowerToAir::tryCheck):
        (JSC::B3::Air::LowerToAir::tryBranch):
        (JSC::B3::Air::LowerToAir::loadAddr): Deleted.
        * b3/B3LoweringMatcher.patterns:
        * b3/B3Opcode.cpp:
        (JSC::B3::invertedCompare):
        * b3/B3Opcode.h:
        (JSC::B3::isCheckMath):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addBlock):
        (JSC::B3::Procedure::addIntConstant):
        (JSC::B3::Procedure::addBoolConstant):
        (JSC::B3::Procedure::resetValueOwners):
        * b3/B3Procedure.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::zShrConstant):
        (JSC::B3::Value::equalConstant):
        (JSC::B3::Value::notEqualConstant):
        (JSC::B3::Value::lessThanConstant):
        (JSC::B3::Value::greaterThanConstant):
        (JSC::B3::Value::lessEqualConstant):
        (JSC::B3::Value::greaterEqualConstant):
        (JSC::B3::Value::aboveConstant):
        (JSC::B3::Value::belowConstant):
        (JSC::B3::Value::aboveEqualConstant):
        (JSC::B3::Value::belowEqualConstant):
        (JSC::B3::Value::invertedCompare):
        * b3/B3Value.h:
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::dump):
        (WTF::printInternal):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isUse):
        (JSC::B3::Air::Arg::typeForB3Type):
        (JSC::B3::Air::Arg::widthForB3Type):
        (JSC::B3::Air::Arg::Arg):
        (JSC::B3::Air::Arg::value):
        (JSC::B3::Air::Arg::isRepresentableAs):
        (JSC::B3::Air::Arg::asNumber):
        (JSC::B3::Air::Arg::pointerValue):
        (JSC::B3::Air::Arg::asDoubleCondition):
        (JSC::B3::Air::Arg::inverted):
        (JSC::B3::Air::Arg::flipped):
        (JSC::B3::Air::Arg::isSignedCond):
        (JSC::B3::Air::Arg::isUnsignedCond):
        * b3/air/AirInst.h:
        (JSC::B3::Air::Inst::Inst):
        (JSC::B3::Air::Inst::operator bool):
        * b3/air/AirOpcode.opcodes:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (hiddenTruthBecauseNoReturnIsStupid):
        (JSC::B3::testStoreLoadStackSlot):
        (JSC::B3::modelLoad):
        (JSC::B3::testLoad):
        (JSC::B3::testBranch):
        (JSC::B3::testComplex):
        (JSC::B3::testSimplePatchpoint):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::genericTestCompare):
        (JSC::B3::modelCompare):
        (JSC::B3::testCompareLoad):
        (JSC::B3::testCompareImpl):
        (JSC::B3::testCompare):
        (JSC::B3::run):
        (main):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithMod):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):

2015-11-05  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Clean up InjectedScript uses
        https://bugs.webkit.org/show_bug.cgi?id=150921

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScript.cpp:
        (Inspector::InjectedScript::wrapCallFrames):
        * inspector/InjectedScript.h:
        * inspector/InjectedScriptBase.cpp:
        (Inspector::InjectedScriptBase::initialize): Deleted.
        * inspector/InjectedScriptBase.h:
        * inspector/InjectedScriptManager.cpp:
        (Inspector::InjectedScriptManager::didCreateInjectedScript):
        * inspector/InjectedScriptManager.h:
        * inspector/InjectedScriptModule.cpp:
        (Inspector::InjectedScriptModule::ensureInjected):
        * inspector/InjectedScriptModule.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::currentCallFrames):
        * inspector/agents/InspectorDebuggerAgent.h:

2015-11-05  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Put ScriptDebugServer into InspectorEnvironment and cleanup duplicate references
        https://bugs.webkit.org/show_bug.cgi?id=150869

        Reviewed by Brian Burg.

        ScriptDebugServer (JSC::Debugger) is being used by more and more agents
        for instrumentation into JavaScriptCore. Currently the ScriptDebugServer
        is owned by DebuggerAgent subclasses that make their own ScriptDebugServer
        subclass. As more agents want to use it there was added boilerplate.
        Instead, put the ScriptDebugServer in the InspectorEnvironment (Controllers).
        Then each agent can access it during construction through the environment.

        Do the same clean up for RuntimeAgent::globalVM, which is now just a
        duplication of InspectorEnvironment::vm.

        * inspector/InspectorEnvironment.h:
        Add scriptDebugServer().

        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::scriptDebugServer):
        Own the JSGlobalObjectScriptDebugServer.

        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
        (Inspector::InspectorDebuggerAgent::enable):
        (Inspector::InspectorDebuggerAgent::disable):
        (Inspector::InspectorDebuggerAgent::setBreakpointsActive):
        (Inspector::InspectorDebuggerAgent::isPaused):
        (Inspector::InspectorDebuggerAgent::setSuppressAllPauses):
        (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
        (Inspector::InspectorDebuggerAgent::removeBreakpoint):
        (Inspector::InspectorDebuggerAgent::continueToLocation):
        (Inspector::InspectorDebuggerAgent::resolveBreakpoint):
        (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
        (Inspector::InspectorDebuggerAgent::cancelPauseOnNextStatement):
        (Inspector::InspectorDebuggerAgent::resume):
        (Inspector::InspectorDebuggerAgent::stepOver):
        (Inspector::InspectorDebuggerAgent::stepInto):
        (Inspector::InspectorDebuggerAgent::stepOut):
        (Inspector::InspectorDebuggerAgent::setPauseOnExceptions):
        (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
        (Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
        (Inspector::InspectorDebuggerAgent::didPause):
        (Inspector::InspectorDebuggerAgent::breakProgram):
        (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::InspectorRuntimeAgent):
        (Inspector::setPauseOnExceptionsState):
        (Inspector::InspectorRuntimeAgent::parse):
        (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
        (Inspector::InspectorRuntimeAgent::setTypeProfilerEnabledState):
        (Inspector::InspectorRuntimeAgent::getBasicBlocks):
        Use VM and ScriptDebugServer passed during construction.

        * inspector/agents/JSGlobalObjectDebuggerAgent.h:
        * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
        (Inspector::JSGlobalObjectDebuggerAgent::injectedScriptForEval):
        (Inspector::JSGlobalObjectDebuggerAgent::JSGlobalObjectDebuggerAgent): Deleted.
        One special case needed by this subclass as a convenience to access the global object.

        * inspector/agents/JSGlobalObjectRuntimeAgent.h:
        * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
        (Inspector::JSGlobalObjectRuntimeAgent::globalVM): Deleted.
        This virtual method is no longer needed, the base class has everything now.

2015-11-05  Xabier Rodriguez Calvar  <calvaris@igalia.com>

        [Streams API] Shield implementation from user mangling Promise.reject and resolve methods
        https://bugs.webkit.org/show_bug.cgi?id=150895

        Reviewed by Youenn Fablet.

        Keep Promise.resolve and reject also as internal slots for the Promise constructor given that there is no way to
        retrieve the former implementation if the user decides to replace it. This allows to safely create vended
        promises even if the user changes the constructor methods.

        * runtime/JSPromiseConstructor.h:
        * runtime/JSPromiseConstructor.cpp:
        (JSC::JSPromiseConstructor::addOwnInternalSlots): Added to include @reject and @resolve.
        (JSC::JSPromiseConstructor::create): Call addOwnInternalSlots.

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

        [JSC] Add B3-to-Air lowering for the shift opcodes
        https://bugs.webkit.org/show_bug.cgi?id=150919

        Reviewed by Filip Pizlo.

        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::rshift64):
        (JSC::MacroAssemblerX86_64::urshift64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::shrq_CLr):
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::shlConstant):
        (JSC::B3::Const32Value::sShrConstant):
        (JSC::B3::Const32Value::zShrConstant):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::shlConstant):
        (JSC::B3::Const64Value::sShrConstant):
        (JSC::B3::Const64Value::zShrConstant):
        * b3/B3Const64Value.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::appendShift):
        (JSC::B3::Air::LowerToAir::tryShl):
        (JSC::B3::Air::LowerToAir::trySShr):
        (JSC::B3::Air::LowerToAir::tryZShr):
        * b3/B3LoweringMatcher.patterns:
        * b3/B3Opcode.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::shlConstant):
        (JSC::B3::Value::sShrConstant):
        (JSC::B3::Value::zShrConstant):
        * b3/B3Value.h:
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::isShiftValid):
        (JSC::B3::Air::isRshift32Valid):
        (JSC::B3::Air::isRshift64Valid):
        (JSC::B3::Air::isUrshift32Valid):
        (JSC::B3::Air::isUrshift64Valid):
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testShlArgs):
        (JSC::B3::testShlImms):
        (JSC::B3::testShlArgImm):
        (JSC::B3::testShlArgs32):
        (JSC::B3::testShlImms32):
        (JSC::B3::testShlArgImm32):
        (JSC::B3::testSShrArgs):
        (JSC::B3::testSShrImms):
        (JSC::B3::testSShrArgImm):
        (JSC::B3::testSShrArgs32):
        (JSC::B3::testSShrImms32):
        (JSC::B3::testSShrArgImm32):
        (JSC::B3::testZShrArgs):
        (JSC::B3::testZShrImms):
        (JSC::B3::testZShrArgImm):
        (JSC::B3::testZShrArgs32):
        (JSC::B3::testZShrImms32):
        (JSC::B3::testZShrArgImm32):
        (JSC::B3::run):

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

        B3 should be able to compile a Check
        https://bugs.webkit.org/show_bug.cgi?id=150878

        Reviewed by Saam Barati.

        The Check opcode in B3 is going to be our main OSR exit mechanism. It is a stackmap
        value, so you can pass it any number of additional arguments, and you will get to find
        out how those arguments are represented at the point that the value lands in the machine
        code. Unlike a Patchpoint, a Check branches on a value, with the goal of supporting full
        compare/branch fusion. The stackmap's generator runs in an out-of-line path to which
        that branch is linked.

        This change fills in the glue necessary to compile a Check and it includes a simple
        test of this functionality. That test also happens to check that such simple code will
        never use callee-saves, which I think is sensible.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::append):
        (JSC::B3::Air::LowerToAir::ensureSpecial):
        (JSC::B3::Air::LowerToAir::fillStackmap):
        (JSC::B3::Air::LowerToAir::tryStackSlot):
        (JSC::B3::Air::LowerToAir::tryPatchpoint):
        (JSC::B3::Air::LowerToAir::tryCheck):
        (JSC::B3::Air::LowerToAir::tryUpsilon):
        * b3/B3LoweringMatcher.patterns:
        * b3/testb3.cpp:
        (JSC::B3::testSimplePatchpoint):
        (JSC::B3::testSimpleCheck):
        (JSC::B3::run):

2015-10-30  Keith Miller  <keith_miller@apple.com>

        Fix endless OSR exits when creating a rope that contains an object that ToPrimitive's to a number.
        https://bugs.webkit.org/show_bug.cgi?id=150583

        Reviewed by Benjamin Poulain.

        Before we assumed that the result of ToPrimitive on any object was a string.
        This had a couple of negative effects. First, the result ToPrimitive on an
        object can be overridden to be any primitive type. In fact, as of ES6, ToPrimitive,
        when part of a addition expression, will type hint a number value. Second, even after
        repeatedly exiting with a bad type we would continue to think that the result
        of ToPrimitive would be a string so we continue to convert StrCats into MakeRope.

        The fix is to make Prediction Propagation match the behavior of Fixup and move
        canOptimizeStringObjectAccess to DFGGraph.

        * bytecode/SpeculatedType.h:
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
        (JSC::DFG::FixupPhase::fixupToPrimitive):
        (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
        (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
        (JSC::DFG::FixupPhase::isStringPrototypeMethodSane): Deleted.
        (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess): Deleted.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isStringPrototypeMethodSane):
        (JSC::DFG::Graph::canOptimizeStringObjectAccess):
        * dfg/DFGGraph.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::resultOfToPrimitive):
        (JSC::DFG::resultOfToPrimitive): Deleted.

        * bytecode/SpeculatedType.h:
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
        (JSC::DFG::FixupPhase::fixupToPrimitive):
        (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
        (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
        (JSC::DFG::FixupPhase::isStringPrototypeMethodSane): Deleted.
        (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess): Deleted.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isStringPrototypeMethodSane):
        (JSC::DFG::Graph::canOptimizeStringObjectAccess):
        * dfg/DFGGraph.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::resultOfToPrimitive):
        (JSC::DFG::resultOfToPrimitive): Deleted.
        * tests/stress/string-rope-with-custom-valueof.js: Added.
        (catNumber):
        (number.valueOf):
        (catBool):
        (bool.valueOf):
        (catUndefined):
        (undef.valueOf):
        (catRandom):
        (random.valueOf):

2015-11-04  Xabier Rodriguez Calvar  <calvaris@igalia.com>

        Remove bogus global internal functions for properties and prototype retrieval
        https://bugs.webkit.org/show_bug.cgi?id=150892

        Reviewed by Darin Adler.

        Global @getOwnPropertyNames and @getPrototypeOf point to the floor function, so it is bogus dead code.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Removed global @getOwnPropertyNames and @getPrototypeOf.

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

        [JSC] Add B3-to-Air lowering for BitXor
        https://bugs.webkit.org/show_bug.cgi?id=150872

        Reviewed by Filip Pizlo.

        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::xor32):
        Fix the indentation.

        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::bitXorConstant):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::bitXorConstant):
        * b3/B3Const64Value.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::tryXor):
        * b3/B3LoweringMatcher.patterns:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::bitXorConstant):
        * b3/B3Value.h:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testBitXorArgs):
        (JSC::B3::testBitXorSameArg):
        (JSC::B3::testBitXorImms):
        (JSC::B3::testBitXorArgImm):
        (JSC::B3::testBitXorImmArg):
        (JSC::B3::testBitXorBitXorArgImmImm):
        (JSC::B3::testBitXorImmBitXorArgImm):
        (JSC::B3::testBitXorArgs32):
        (JSC::B3::testBitXorSameArg32):
        (JSC::B3::testBitXorImms32):
        (JSC::B3::testBitXorArgImm32):
        (JSC::B3::testBitXorImmArg32):
        (JSC::B3::testBitXorBitXorArgImmImm32):
        (JSC::B3::testBitXorImmBitXorArgImm32):
        (JSC::B3::run):

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

        Add op_add tests to compare behavior of JIT generated code to the LLINT's.
        https://bugs.webkit.org/show_bug.cgi?id=150864

        Reviewed by Saam Barati.

        * tests/stress/op_add.js: Added.
        (o1.valueOf):
        (generateScenarios):
        (printScenarios):
        (testCases.func):
        (func):
        (initializeTestCases):
        (runTest):

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

        Rename DFG's compileAdd to compileArithAdd.
        https://bugs.webkit.org/show_bug.cgi?id=150866

        Reviewed by Benjamin Poulain.

        The function is only supposed to generate code to do arithmetic addition on
        numeric types.  Naming it compileArithAdd() is more accurate, and is consistent
        with the name of the node it emits code for (i.e. ArithAdd) as well as other
        compiler functions for analogous operations e.g. compileArithSub.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInstanceOf):
        (JSC::DFG::SpeculativeJIT::compileArithAdd):
        (JSC::DFG::SpeculativeJIT::compileAdd): Deleted.
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

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

        Web Inspector: Remove duplication among ScriptDebugServer subclasses
        https://bugs.webkit.org/show_bug.cgi?id=150860

        Reviewed by Timothy Hatcher.

        ScriptDebugServer expects a list of listeners to dispatch events to.
        However each of its subclasses had their own implementation of the
        list because of different handling when the first was added or when
        the last was removed. Extract common code into ScriptDebugServer
        which simplifies things.

        Subclasses now only implement a virtual methods "attachDebugger"
        and "detachDebugger" which is the unique work done when the first
        listener is added or last is removed.

        * inspector/JSGlobalObjectScriptDebugServer.cpp:
        (Inspector::JSGlobalObjectScriptDebugServer::attachDebugger):
        (Inspector::JSGlobalObjectScriptDebugServer::detachDebugger):
        (Inspector::JSGlobalObjectScriptDebugServer::addListener): Deleted.
        (Inspector::JSGlobalObjectScriptDebugServer::removeListener): Deleted.
        * inspector/JSGlobalObjectScriptDebugServer.h:
        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
        (Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
        (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
        (Inspector::ScriptDebugServer::sourceParsed):
        (Inspector::ScriptDebugServer::dispatchFunctionToListeners):
        (Inspector::ScriptDebugServer::addListener):
        (Inspector::ScriptDebugServer::removeListener):
        * inspector/ScriptDebugServer.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::enable):
        (Inspector::InspectorDebuggerAgent::disable):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
        (Inspector::JSGlobalObjectDebuggerAgent::startListeningScriptDebugServer): Deleted.
        (Inspector::JSGlobalObjectDebuggerAgent::stopListeningScriptDebugServer): Deleted.
        * inspector/agents/JSGlobalObjectDebuggerAgent.h:

        * inspector/ScriptDebugListener.h:
        (Inspector::ScriptDebugListener::Script::Script):
        Drive-by convert Script to a struct, it has public fields and is used as such.

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

        B3::LowerToAir should recognize Neg (i.e. Sub($0, value))
        https://bugs.webkit.org/show_bug.cgi?id=150759

        Reviewed by Benjamin Poulain.

        Adds various forms of Sub(0, value) and compiles them as Neg. Also fixes a bug in
        StoreSubLoad. This bug was correctness-benign, so I couldn't add a test for it.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::immOrTmp):
        (JSC::B3::Air::LowerToAir::appendUnOp):
        (JSC::B3::Air::LowerToAir::appendBinOp):
        (JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
        (JSC::B3::Air::LowerToAir::trySub):
        (JSC::B3::Air::LowerToAir::tryStoreSubLoad):
        * b3/B3LoweringMatcher.patterns:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testAdd1Ptr):
        (JSC::B3::testNeg32):
        (JSC::B3::testNegPtr):
        (JSC::B3::testStoreAddLoad):
        (JSC::B3::testStoreAddAndLoad):
        (JSC::B3::testStoreNegLoad32):
        (JSC::B3::testStoreNegLoadPtr):
        (JSC::B3::testAdd1Uncommuted):
        (JSC::B3::run):

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

        B3::Values that have effects should allow specification of custom HeapRanges
        https://bugs.webkit.org/show_bug.cgi?id=150535

        Reviewed by Benjamin Poulain.

        Add a Effects field to calls and patchpoints. Add a HeapRange to MemoryValues.

        In the process, I created a class for the CCall opcode, so that it has somewhere to put
        the Effects field.

        While doing this, I realized that we didn't have a good way of ensuring that an opcode
        that requires a specific subclass was actually created with that subclass. So, I added
        assertions for this.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3ArgumentRegValue.h:
        * b3/B3CCallValue.cpp: Added.
        * b3/B3CCallValue.h: Added.
        * b3/B3CheckValue.h:
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.h:
        * b3/B3ConstDoubleValue.h:
        (JSC::B3::ConstDoubleValue::ConstDoubleValue):
        * b3/B3ControlValue.h:
        * b3/B3Effects.h:
        (JSC::B3::Effects::forCall):
        (JSC::B3::Effects::mustExecute):
        * b3/B3MemoryValue.h:
        * b3/B3PatchpointValue.h:
        * b3/B3StackSlotValue.h:
        * b3/B3UpsilonValue.h:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        (JSC::B3::Value::dumpMeta):
        (JSC::B3::Value::checkOpcode):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h:

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

        B3::Stackmap should be a superclass of B3::PatchpointValue and B3::CheckValue rather than being one of their members
        https://bugs.webkit.org/show_bug.cgi?id=150831

        Rubber stamped by Benjamin Poulain.

        Previously, Stackmap was a value that PatchpointValue and CheckValue would hold as a field.
        We'd have convenient ways of getting this field, like via Value::stackmap(). But this was a
        bit ridiculous, since Stackmap is logically just a common supertype for Patchpointvalue and
        CheckValue. This patch makes this reality by replacing Stackmap with StackmapValue. This makes
        the code a lot more reasonable.

        I also needed to make dumping a bit more customizable, so I changed dumpMeta() to take a
        CommaPrinter&. This gives subclasses better control over whether or not to emit a comma. Also
        it's now possible for subclasses of Value to customize how children are printed. StackmapValue
        uses this to print the children and their reps together like:

            Int32 @2 = Patchpoint(@0:SomeRegister, @1:SomeRegister, generator = 0x1107ec010, clobbered = [], usedRegisters = [], ExitsSideways|ControlDependent|Writes:Top|Reads:Top)

        This has no behavior change, it's just a big refactoring. You can see how much simpler this
        makes things by looking at the testSimplePatchpoint() test.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/B3ArgumentRegValue.cpp:
        (JSC::B3::ArgumentRegValue::~ArgumentRegValue):
        (JSC::B3::ArgumentRegValue::dumpMeta):
        * b3/B3ArgumentRegValue.h:
        * b3/B3CheckSpecial.cpp:
        (JSC::B3::CheckSpecial::generate):
        * b3/B3CheckValue.cpp:
        (JSC::B3::CheckValue::~CheckValue):
        (JSC::B3::CheckValue::CheckValue):
        (JSC::B3::CheckValue::dumpMeta): Deleted.
        * b3/B3CheckValue.h:
        (JSC::B3::CheckValue::accepts):
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::notEqualConstant):
        (JSC::B3::Const32Value::dumpMeta):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::notEqualConstant):
        (JSC::B3::Const64Value::dumpMeta):
        * b3/B3Const64Value.h:
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::notEqualConstant):
        (JSC::B3::ConstDoubleValue::dumpMeta):
        * b3/B3ConstDoubleValue.h:
        * b3/B3ConstrainedValue.cpp: Added.
        (JSC::B3::ConstrainedValue::dump):
        * b3/B3ConstrainedValue.h: Added.
        (JSC::B3::ConstrainedValue::ConstrainedValue):
        (JSC::B3::ConstrainedValue::operator bool):
        (JSC::B3::ConstrainedValue::value):
        (JSC::B3::ConstrainedValue::rep):
        * b3/B3ControlValue.cpp:
        (JSC::B3::ControlValue::convertToJump):
        (JSC::B3::ControlValue::dumpMeta):
        * b3/B3ControlValue.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::tryPatchpoint):
        * b3/B3MemoryValue.cpp:
        (JSC::B3::MemoryValue::accessByteSize):
        (JSC::B3::MemoryValue::dumpMeta):
        * b3/B3MemoryValue.h:
        * b3/B3PatchpointSpecial.cpp:
        (JSC::B3::PatchpointSpecial::generate):
        * b3/B3PatchpointValue.cpp:
        (JSC::B3::PatchpointValue::~PatchpointValue):
        (JSC::B3::PatchpointValue::PatchpointValue):
        (JSC::B3::PatchpointValue::dumpMeta): Deleted.
        * b3/B3PatchpointValue.h:
        (JSC::B3::PatchpointValue::accepts):
        * b3/B3StackSlotValue.cpp:
        (JSC::B3::StackSlotValue::~StackSlotValue):
        (JSC::B3::StackSlotValue::dumpMeta):
        * b3/B3StackSlotValue.h:
        * b3/B3Stackmap.cpp: Removed.
        * b3/B3Stackmap.h: Removed.
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::reportUsedRegisters):
        (JSC::B3::StackmapSpecial::extraClobberedRegs):
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::isValidImpl):
        (JSC::B3::StackmapSpecial::admitsStackImpl):
        * b3/B3StackmapSpecial.h:
        * b3/B3StackmapValue.cpp: Added.
        (JSC::B3::StackmapValue::~StackmapValue):
        (JSC::B3::StackmapValue::append):
        (JSC::B3::StackmapValue::setConstrainedChild):
        (JSC::B3::StackmapValue::setConstraint):
        (JSC::B3::StackmapValue::dumpChildren):
        (JSC::B3::StackmapValue::dumpMeta):
        (JSC::B3::StackmapValue::StackmapValue):
        * b3/B3StackmapValue.h: Added.
        * b3/B3SwitchValue.cpp:
        (JSC::B3::SwitchValue::appendCase):
        (JSC::B3::SwitchValue::dumpMeta):
        (JSC::B3::SwitchValue::SwitchValue):
        * b3/B3SwitchValue.h:
        * b3/B3UpsilonValue.cpp:
        (JSC::B3::UpsilonValue::~UpsilonValue):
        (JSC::B3::UpsilonValue::dumpMeta):
        * b3/B3UpsilonValue.h:
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::dump):
        (JSC::B3::Value::dumpChildren):
        (JSC::B3::Value::deepDump):
        (JSC::B3::Value::performSubstitution):
        (JSC::B3::Value::dumpMeta):
        * b3/B3Value.h:
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::asNumber):
        (JSC::B3::Value::stackmap): Deleted.
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::kind):
        (JSC::B3::ValueRep::operator==):
        (JSC::B3::ValueRep::operator!=):
        (JSC::B3::ValueRep::operator bool):
        (JSC::B3::ValueRep::isAny):
        * b3/air/AirInstInlines.h:
        * b3/testb3.cpp:
        (JSC::B3::testSimplePatchpoint):

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

        [JSC] Add Air lowering for BitOr and impove BitAnd
        https://bugs.webkit.org/show_bug.cgi?id=150827

        Reviewed by Filip Pizlo.

        In this patch:
        -B3 to Air lowering for BirOr.
        -Codegen for BitOr.
        -Strength reduction for BitOr and BitAnd.
        -Tests for BitAnd and BitOr.
        -Bug fix: Move64 with a negative value was destroying the top bits.

        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::bitAndConstant):
        (JSC::B3::Const32Value::bitOrConstant):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::bitAndConstant):
        (JSC::B3::Const64Value::bitOrConstant):
        * b3/B3Const64Value.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::immForMove):
        (JSC::B3::Air::LowerToAir::immOrTmpForMove):
        (JSC::B3::Air::LowerToAir::tryOr):
        (JSC::B3::Air::LowerToAir::tryConst64):
        (JSC::B3::Air::LowerToAir::tryUpsilon):
        (JSC::B3::Air::LowerToAir::tryIdentity):
        (JSC::B3::Air::LowerToAir::tryReturn):
        (JSC::B3::Air::LowerToAir::immOrTmp): Deleted.
        * b3/B3LoweringMatcher.patterns:
        * b3/B3ReduceStrength.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::bitAndConstant):
        (JSC::B3::Value::bitOrConstant):
        * b3/B3Value.h:
        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testReturnConst64):
        (JSC::B3::testBitAndArgs):
        (JSC::B3::testBitAndSameArg):
        (JSC::B3::testBitAndImms):
        (JSC::B3::testBitAndArgImm):
        (JSC::B3::testBitAndImmArg):
        (JSC::B3::testBitAndBitAndArgImmImm):
        (JSC::B3::testBitAndImmBitAndArgImm):
        (JSC::B3::testBitAndArgs32):
        (JSC::B3::testBitAndSameArg32):
        (JSC::B3::testBitAndImms32):
        (JSC::B3::testBitAndArgImm32):
        (JSC::B3::testBitAndImmArg32):
        (JSC::B3::testBitAndBitAndArgImmImm32):
        (JSC::B3::testBitAndImmBitAndArgImm32):
        (JSC::B3::testBitOrArgs):
        (JSC::B3::testBitOrSameArg):
        (JSC::B3::testBitOrImms):
        (JSC::B3::testBitOrArgImm):
        (JSC::B3::testBitOrImmArg):
        (JSC::B3::testBitOrBitOrArgImmImm):
        (JSC::B3::testBitOrImmBitOrArgImm):
        (JSC::B3::testBitOrArgs32):
        (JSC::B3::testBitOrSameArg32):
        (JSC::B3::testBitOrImms32):
        (JSC::B3::testBitOrArgImm32):
        (JSC::B3::testBitOrImmArg32):
        (JSC::B3::testBitOrBitOrArgImmImm32):
        (JSC::B3::testBitOrImmBitOrArgImm32):
        (JSC::B3::run):

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

        Rewrite "const" as "var" for iTunes/iBooks on the Mac
        https://bugs.webkit.org/show_bug.cgi?id=150852

        Reviewed by Geoffrey Garen.

        VM now has a setting indicating if we should treat
        "const" variables as "var" to more closely match
        JSC's previous implementation of "const" before ES6.

        * parser/Parser.h:
        (JSC::Parser::next):
        (JSC::Parser::nextExpectIdentifier):
        * runtime/VM.h:
        (JSC::VM::setShouldRewriteConstAsVar):
        (JSC::VM::shouldRewriteConstAsVar):

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

        Fix some inefficiencies in the baseline usage of JITAddGenerator.
        https://bugs.webkit.org/show_bug.cgi?id=150850

        Reviewed by Michael Saboff.

        1. emit_op_add() was loading the operands twice.  Removed the redundant load.
        2. The snippet may decide that it wants to go the slow path route all the time.
           In that case, emit_op_add will end up emitting a branch to an out of line
           slow path followed by some dead code to store the result of the fast path
           on to the stack.
           We now check if the snippet determined that there's no fast path, and just
           emit the slow path inline, and skip the dead store of the fast path result.

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

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

        B3::LowerToAir should do copy propagation
        https://bugs.webkit.org/show_bug.cgi?id=150775

        Reviewed by Geoffrey Garen.

        What we are trying to do is remove the unnecessary Move's and Move32's from Trunc and ZExt32.
        You could think of this as an Air optimization, and indeed, Air is powerful enough that we
        could write a phase that does copy propagation through Move's and Move32's. For Move32's it
        would only copy-propagate if it proved that the value was already zero-extended. We could
        know this by just adding a Def32 role to Air.

        But this patch takes a different approach: we ensure that we don't generate such redundant
        Move's and Move32's to begin with. The reason is that it's much cheaper to do analysis over
        B3 than over Air. So, whenever possible, and optimization should be implemented in B3. In
        this case the optimization can't quite be implemented in B3 because you cannot remove a Trunc
        or ZExt32 without violating the B3 type system. So, the best place to do this optimization is
        during lowering: we can use B3 for our analysis and we can use Air to express the
        transformation.

        Copy propagating during B3->Air lowering is natural because we are creating "SSA-like" Tmps
        from the B3 Values. They are SSA-like in the sense that except the tmp for a Phi, we know
        that the Tmp will be assigned once and that the assignment will dominate all uses. So, if we
        see an operation like Trunc that is semantically just a Move, we can skip the Move and just
        claim that the Trunc has the same Tmp as its child. We do something similar for ZExt32,
        except with that one we have to analyze IR to ensure that the value will actually be zero
        extended. Note that this kind of reasoning about how Tmps work in Air is only possible in the
        B3->Air lowering, since at that point we know for sure which Tmps behave this way. If we
        wanted to do anything like this as a later Air phase, we'd have to do more analysis to first
        prove that Tmps behave in this way.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::highBitsAreZero):
        (JSC::B3::Air::LowerToAir::shouldCopyPropagate):
        (JSC::B3::Air::LowerToAir::tmp):
        (JSC::B3::Air::LowerToAir::tryStore):
        (JSC::B3::Air::LowerToAir::tryTrunc):
        (JSC::B3::Air::LowerToAir::tryZExt32):
        (JSC::B3::Air::LowerToAir::tryIdentity):
        (JSC::B3::Air::LowerToAir::tryTruncArgumentReg): Deleted.
        * b3/B3LoweringMatcher.patterns:

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

        Web Inspector: Move ScriptDebugServer::Task to WorkerScriptDebugServer where it is actually used
        https://bugs.webkit.org/show_bug.cgi?id=150847

        Reviewed by Timothy Hatcher.

        * inspector/ScriptDebugServer.h:
        Remove Task from here, it isn't needed in the general case.

        * parser/SourceProvider.h:
        Remove unimplemented method.

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

        Web Inspector: Handle or Remove ParseHTML Timeline Event Records
        https://bugs.webkit.org/show_bug.cgi?id=150689

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Timeline.json:

2015-11-03  Michael Saboff  <msaboff@apple.com>

        Rename InlineCallFrame:: getCallerSkippingDeadFrames to something more descriptive
        https://bugs.webkit.org/show_bug.cgi?id=150832

        Reviewed by Geoffrey Garen.

        Renamed InlineCallFrame::getCallerSkippingDeadFrames() to getCallerSkippingTailCalls().
        Did similar renaming to helper InlineCallFrame::computeCallerSkippingTailCalls() and
        InlineCallFrame::getCallerInlineFrameSkippingTailCalls().

        * bytecode/InlineCallFrame.h:
        (JSC::InlineCallFrame::computeCallerSkippingTailCalls):
        (JSC::InlineCallFrame::getCallerSkippingTailCalls):
        (JSC::InlineCallFrame::getCallerInlineFrameSkippingTailCalls):
        (JSC::InlineCallFrame::computeCallerSkippingDeadFrames): Deleted.
        (JSC::InlineCallFrame::getCallerSkippingDeadFrames): Deleted.
        (JSC::InlineCallFrame::getCallerInlineFrameSkippingDeadFrames): Deleted.
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::allInlineFramesAreTailCalls):
        (JSC::DFG::ByteCodeParser::currentCodeOrigin):
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::isLiveInBytecode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::codeOriginDescriptionOfCallSite):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::gotoNextFrame):

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

        B3/Air should use bubble sort for their insertion sets, because it's faster than std::stable_sort
        https://bugs.webkit.org/show_bug.cgi?id=150828

        Reviewed by Geoffrey Garen.

        Undo the 2% compile time regression caused by http://trac.webkit.org/changeset/191913.

        * b3/B3InsertionSet.cpp:
        (JSC::B3::InsertionSet::execute): Switch to bubble sort.
        * b3/air/AirInsertionSet.cpp:
        (JSC::B3::Air::InsertionSet::execute): Switch to bubble sort.
        * dfg/DFGBlockInsertionSet.cpp:
        (JSC::DFG::BlockInsertionSet::execute): Switch back to quicksort.

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

        Unreviewed, partially revert r191952.

        Removed GCC compiler workarounds (unreachable returns).

        * b3/B3Type.h:
        (JSC::B3::sizeofType):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isUse):
        (JSC::B3::Air::Arg::isDef):
        (JSC::B3::Air::Arg::isGP):
        (JSC::B3::Air::Arg::isFP):
        (JSC::B3::Air::Arg::isType):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::newTmp):
        (JSC::B3::Air::Code::numTmps):

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

        Fix the ENABLE(B3_JIT) build on Linux
        https://bugs.webkit.org/show_bug.cgi?id=150794

        Reviewed by Darin Adler.

        * CMakeLists.txt:
        * b3/B3HeapRange.h:
        * b3/B3IndexSet.h:
        (JSC::B3::IndexSet::Iterable::iterator::operator++):
        * b3/B3Type.h:
        (JSC::B3::sizeofType):
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::dump):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isUse):
        (JSC::B3::Air::Arg::isDef):
        (JSC::B3::Air::Arg::isGP):
        (JSC::B3::Air::Arg::isFP):
        (JSC::B3::Air::Arg::isType):
        * b3/air/AirCode.h:
        (JSC::B3::Air::Code::newTmp):
        (JSC::B3::Air::Code::numTmps):
        * b3/air/AirSpecial.cpp:

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

        Clean up ENABLE(ES6_ARROWFUNCTION_SYNTAX) ifdefs and keep minimal set of them
        https://bugs.webkit.org/show_bug.cgi?id=150793

        Reviewed by Darin Adler.

        Fix the !ENABLE(ES6_ARROWFUNCTION_SYNTAX) build after r191875.
        This patch drops many ENABLE(ES6_ARROWFUNCTION_SYNTAX) ifdefs and keep only one of them;
        the ifdef in parseAssignmentExpression.
        This prevents functionality of parsing arrow function syntax.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::lex):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner): Deleted.
        * parser/Parser.h:
        (JSC::Parser::isArrowFunctionParamters): Deleted.
        * parser/ParserTokens.h:

2015-11-02  Michael Saboff  <msaboff@apple.com>

        WebInspector crashed while viewing Timeline when refreshing cnn.com while it was already loading
        https://bugs.webkit.org/show_bug.cgi?id=150745

        Reviewed by Geoffrey Garen.

        During OSR exit, reifyInlinedCallFrames() was using the call kind from a tail call to
        find the CallLinkInfo / StubInfo to find the return PC.  Instead we need to get the call
        type of the true caller, that is the function we'll be returning to.

        This can be found by remembering the last call type we find while walking up the inlined
        frames in InlineCallFrame::getCallerSkippingDeadFrames().

        We can also return directly back to a getter or setter callsite without using a thunk.

        * bytecode/InlineCallFrame.h:
        (JSC::InlineCallFrame::computeCallerSkippingDeadFrames):
        (JSC::InlineCallFrame::getCallerSkippingDeadFrames):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_id): Need to eliminate the stack pointer check, as it is wrong
        for reified inlined frames created during OSR exit. 
        * jit/ThunkGenerators.cpp:
        (JSC::baselineGetterReturnThunkGenerator): Deleted.
        (JSC::baselineSetterReturnThunkGenerator): Deleted.
        * jit/ThunkGenerators.h:

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

        Wrong value recovery for DFG try/catch with a getter that throws during an IC miss
        https://bugs.webkit.org/show_bug.cgi?id=150760

        Reviewed by Geoffrey Garen.

        This is related to using PhantomLocal instead of Flush as 
        the liveness preservation mechanism for live catch variables. 
        I'm temporarily switching things back to Flush. This will be a
        performance hit for try/catch in the DFG. Landing this patch,
        though, will allow me to land try/catch in the FTL. It also
        makes try/catch in the DFG sound. I have opened another
        bug to further investigate using PhantomLocal as the
        liveness preservation mechanism: https://bugs.webkit.org/show_bug.cgi?id=150824

        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
        * tests/stress/dfg-try-catch-wrong-value-recovery-on-ic-miss.js: Added.
        (assert):
        (let.oThrow.get f):
        (let.o2.get f):
        (foo):
        (f):

2015-11-02  Andy Estes  <aestes@apple.com>

        [Cocoa] Add tvOS and watchOS to SUPPORTED_PLATFORMS
        https://bugs.webkit.org/show_bug.cgi?id=150819

        Reviewed by Dan Bernstein.

        This tells Xcode to include these platforms in its Devices dropdown, making it possible to build in the IDE.

        * Configurations/Base.xcconfig:

2015-11-02  Brent Fulgham  <bfulgham@apple.com>

        [Win] MiniBrowser unable to use WebInspector
        https://bugs.webkit.org/show_bug.cgi?id=150810
        <rdar://problem/23358514>

        Reviewed by Timothy Hatcher.

        The CMakeList rule for creating the InjectedScriptSource.min.js was improperly including
        the quote characters in the text prepended to InjectedScriptSource.min.js. This caused a
        parsing error in the JS file.
        
        The solution was to switch from using "COMMAND echo" to use the more cross-platform
        compatible command "COMMAND ${CMAKE_COMMAND} -E echo ...", which handles the string
        escaping properly on all platforms.

        * CMakeLists.txt: Switch the 'echo' command syntax to be more cross-platform.

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

        B3 should be able to compile a Patchpoint
        https://bugs.webkit.org/show_bug.cgi?id=150750

        Reviewed by Geoffrey Garen.

        This adds the glue in B3::LowerToAir that turns a B3::PatchpointValue into an Air::Patch
        with a B3::PatchpointSpecial.

        Along the way, I found some bugs. For starters, it became clear that I wanted to be able
        to append constraints to a Stackmap, and I wanted to have more flexibility in how I
        created a PatchpointValue. I also wanted more helper methods in ValueRep, since
        otherwise I would have had to write a lot of boilerplate.

        I discovered, and fixed, a minor goof in Air::Code dumping when there are specials.

        There were a ton of indexing bugs in B3StackmapSpecial.

        The spiller was broken in case the Def was not the last Arg, since it was adding things
        to the insertion set both at instIndex and instIndex + 1, and the two types of additions
        could occur in the wrong (i.e. the +1 case first) order with an early Def. We often have
        bugs like this. In the DFG, we were paranoid about performance so we only admit out-of-
        order insertions as a rare case. I think that we don't really need to be so paranoid.
        So, I made the new insertion sets use a stable_sort to ensure that everything happens in
        the right order. I changed DFG::BlockInsertionSet to also use stable_sort; it previously
        used sort, which is slightly wrong.

        This adds a new test that uses Patchpoint to implement a 32-bit add. It works!

        * b3/B3InsertionSet.cpp:
        (JSC::B3::InsertionSet::execute):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
        (JSC::B3::Air::LowerToAir::appendStore):
        (JSC::B3::Air::LowerToAir::moveForType):
        (JSC::B3::Air::LowerToAir::append):
        (JSC::B3::Air::LowerToAir::ensureSpecial):
        (JSC::B3::Air::LowerToAir::tryStore):
        (JSC::B3::Air::LowerToAir::tryStackSlot):
        (JSC::B3::Air::LowerToAir::tryPatchpoint):
        (JSC::B3::Air::LowerToAir::tryUpsilon):
        * b3/B3LoweringMatcher.patterns:
        * b3/B3PatchpointValue.h:
        (JSC::B3::PatchpointValue::accepts): Deleted.
        (JSC::B3::PatchpointValue::PatchpointValue): Deleted.
        * b3/B3Stackmap.h:
        (JSC::B3::Stackmap::constrain):
        (JSC::B3::Stackmap::appendConstraint):
        (JSC::B3::Stackmap::reps):
        (JSC::B3::Stackmap::clobber):
        * b3/B3StackmapSpecial.cpp:
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::isValidImpl):
        * b3/B3Value.h:
        * b3/B3ValueRep.h:
        (JSC::B3::ValueRep::ValueRep):
        (JSC::B3::ValueRep::reg):
        (JSC::B3::ValueRep::operator bool):
        (JSC::B3::ValueRep::isAny):
        (JSC::B3::ValueRep::isSomeRegister):
        (JSC::B3::ValueRep::isReg):
        (JSC::B3::ValueRep::isGPR):
        (JSC::B3::ValueRep::isFPR):
        (JSC::B3::ValueRep::gpr):
        (JSC::B3::ValueRep::fpr):
        (JSC::B3::ValueRep::isStack):
        (JSC::B3::ValueRep::offsetFromFP):
        (JSC::B3::ValueRep::isStackArgument):
        (JSC::B3::ValueRep::offsetFromSP):
        (JSC::B3::ValueRep::isConstant):
        (JSC::B3::ValueRep::value):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::dump):
        * b3/air/AirInsertionSet.cpp:
        (JSC::B3::Air::InsertionSet::execute):
        * b3/testb3.cpp:
        (JSC::B3::testComplex):
        (JSC::B3::testSimplePatchpoint):
        (JSC::B3::run):
        * dfg/DFGBlockInsertionSet.cpp:
        (JSC::DFG::BlockInsertionSet::execute):

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

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

        Reviewed by Geoffrey Garen and Saam Barati.

        Performance is neutral for both 32-bit and 64-bit on X86_64.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/JIT.h:
        (JSC::JIT::getOperandConstantInt):
        - Move getOperandConstantInt() from the JSVALUE64 section to the common section
          because the snippet needs it.

        * jit/JITAddGenerator.cpp: Added.
        (JSC::JITAddGenerator::generateFastPath):
        * jit/JITAddGenerator.h: Added.
        (JSC::JITAddGenerator::JITAddGenerator):
        (JSC::JITAddGenerator::endJumpList):
        (JSC::JITAddGenerator::slowPathJumpList):
        - JITAddGenerator implements an optimization for the case where 1 of the 2 operands
          is a constant int32_t.  It does not implement an optimization for the case where
          both operands are constant int32_t.  This is because:
          1. For the baseline JIT, the ASTBuilder will fold the 2 constants together.
          2. For the DFG, the AbstractInterpreter will also fold the 2 constants.

          Hence, such an optimization path (for 2 constant int32_t operands) would never
          be taken, and is why we won't implement it.

        * jit/JITArithmetic.cpp:
        (JSC::JIT::compileBinaryArithOp):
        (JSC::JIT::compileBinaryArithOpSlowCase):
        - Removed op_add cases.  These are no longer used by the op_add emitters.

        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        - Moved out from the JSVALUE64 section to the common section, and reimplemented
          using the snippet.

        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emitBinaryDoubleOp):
        (JSC::JIT::emit_op_add): Deleted.
        (JSC::JIT::emitAdd32Constant): Deleted.
        (JSC::JIT::emitSlow_op_add): Deleted.
        - Remove 32-bit specific version of op_add.  The snippet serves both 32-bit
          and 64-bit implementations.

        * jit/JITInlines.h:
        (JSC::JIT::getOperandConstantInt):
        - Move getOperandConstantInt() from the JSVALUE64 section to the common section
          because the snippet needs it.

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

        Run sort-Xcode-project-file for the JavaScriptCore project.

        Unreviewed. Many things were out of order following recent B3 commits.

        * JavaScriptCore.xcodeproj/project.pbxproj:

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

        Rename op_put_getter_setter to op_put_getter_setter_by_id
        https://bugs.webkit.org/show_bug.cgi?id=150773

        Reviewed by Mark Lam.

        Renaming op_put_getter_setter to op_put_getter_setter_by_id makes this op name consistent with
        the other ops' names like op_put_getter_by_id etc.

        And to fix build dependencies in Xcode, we added LLIntAssembly.h into Xcode project file.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPutGetterSetter):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_getter_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter): Deleted.
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_getter_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:

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

        Fix the FTL JIT build with system LLVM on Linux
        https://bugs.webkit.org/show_bug.cgi?id=150795

        Reviewed by Filip Pizlo.

        * CMakeLists.txt:

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

        [ES6] Support Generator Syntax
        https://bugs.webkit.org/show_bug.cgi?id=150769

        Reviewed by Geoffrey Garen.

        This patch implements syntax part of ES6 Generators.

        1. Add ENABLE_ES6_GENERATORS compile time flag. It is disabled by default, and will be enabled once ES6 generator functionality is implemented.
        2. Add lexer support for YIELD. It changes "yield" from reserved-if-strict word to keyword. And it is correct under the ES6 spec.
        3. Implement parsing functionality and YieldExprNode stub. YieldExprNode does not emit meaningful bytecodes yet. This should be implemented in the future patch.
        4. Accept "yield" Identifier as an label etc. under sloppy mode && non-generator code. http://ecma-international.org/ecma-262/6.0/#sec-generator-function-definitions-static-semantics-early-errors

        * Configurations/FeatureDefines.xcconfig:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::YieldExprNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createYield):
        * parser/Keywords.table:
        * parser/NodeConstructors.h:
        (JSC::YieldExprNode::YieldExprNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::Parser):
        (JSC::Parser<LexerType>::parseInner):
        (JSC::Parser<LexerType>::parseStatementListItem):
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::parseDestructuringPattern):
        (JSC::Parser<LexerType>::parseBreakStatement):
        (JSC::Parser<LexerType>::parseContinueStatement):
        (JSC::Parser<LexerType>::parseTryStatement):
        (JSC::Parser<LexerType>::parseStatement):
        (JSC::stringForFunctionMode):
        (JSC::Parser<LexerType>::parseFunctionParameters):
        (JSC::Parser<LexerType>::parseFunctionInfo):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
        (JSC::Parser<LexerType>::parseExportDeclaration):
        (JSC::Parser<LexerType>::parseAssignmentExpression):
        (JSC::Parser<LexerType>::parseYieldExpression):
        (JSC::Parser<LexerType>::parseProperty):
        (JSC::Parser<LexerType>::parsePropertyMethod):
        (JSC::Parser<LexerType>::parseGetterSetter):
        (JSC::Parser<LexerType>::parseFunctionExpression):
        (JSC::Parser<LexerType>::parsePrimaryExpression):
        (JSC::Parser<LexerType>::parseArrowFunctionExpression):
        * parser/Parser.h:
        (JSC::Scope::Scope):
        (JSC::Scope::setSourceParseMode):
        (JSC::Scope::isGenerator):
        (JSC::Scope::setIsFunction):
        (JSC::Scope::setIsGenerator):
        (JSC::Scope::setIsModule):
        (JSC::Parser::pushScope):
        (JSC::Parser::isYIELDMaskedAsIDENT):
        (JSC::Parser::matchSpecIdentifier):
        (JSC::Parser::saveState):
        (JSC::Parser::restoreState):
        * parser/ParserModes.h:
        (JSC::isFunctionParseMode):
        (JSC::isModuleParseMode):
        (JSC::isProgramParseMode):
        * parser/ParserTokens.h:
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createYield):
        * tests/stress/generator-methods.js: Added.
        (Hello.prototype.gen):
        (Hello.gen):
        (Hello):
        (Hello.prototype.set get string_appeared_here):
        (Hello.string_appeared_here):
        (Hello.prototype.20):
        (Hello.20):
        (Hello.prototype.42):
        (Hello.42):
        (let.object.gen):
        (let.object.set get string_appeared_here):
        (let.object.20):
        (let.object.42):
        * tests/stress/generator-syntax.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntaxError.Hello.prototype.get gen):
        (testSyntaxError.Hello):
        (SyntaxError.Unexpected.token.string_appeared_here.Expected.an.opening.string_appeared_here.before.a.method.testSyntaxError.Hello.prototype.set gen):
        (SyntaxError.Unexpected.token.string_appeared_here.Expected.an.opening.string_appeared_here.before.a.method.testSyntaxError.Hello):
        (SyntaxError.Unexpected.token.string_appeared_here.Expected.an.opening.string_appeared_here.before.a.method.testSyntaxError.gen):
        (testSyntaxError.value):
        (testSyntaxError.gen.ng):
        (testSyntaxError.gen):
        (testSyntax.gen):
        * tests/stress/yield-and-line-terminator.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntax.gen):
        (testSyntaxError.gen):
        * tests/stress/yield-label-generator.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntaxError.test):
        (SyntaxError.Unexpected.keyword.string_appeared_here.Expected.an.identifier.as.the.target.a.continue.statement.testSyntax.test):
        * tests/stress/yield-label.js: Added.
        (yield):
        (testSyntaxError):
        (testSyntaxError.test):
        * tests/stress/yield-named-accessors-generator.js: Added.
        (t1.let.object.get yield):
        (t1.let.object.set yield):
        (t1):
        (t2.let.object.get yield):
        (t2.let.object.set yield):
        (t2):
        * tests/stress/yield-named-accessors.js: Added.
        (t1.let.object.get yield):
        (t1.let.object.set yield):
        (t1):
        (t2.let.object.get yield):
        (t2.let.object.set yield):
        (t2):
        * tests/stress/yield-named-variable-generator.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntaxError.t1):
        (testSyntaxError.t1.yield):
        (testSyntax.t1.yield):
        (testSyntax.t1):
        * tests/stress/yield-named-variable.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntax.t1):
        (testSyntaxError.t1):
        (testSyntax.t1.yield):
        (testSyntaxError.t1.yield):
        * tests/stress/yield-out-of-generator.js: Added.
        (testSyntax):
        (testSyntaxError):
        (testSyntaxError.hello):
        (testSyntaxError.gen.hello):
        (testSyntaxError.gen):
        (testSyntax.gen):
        (testSyntax.gen.ok):
        (testSyntaxError.gen.ok):

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

        Dominators should be factored out of the DFG
        https://bugs.webkit.org/show_bug.cgi?id=150764

        Reviewed by Geoffrey Garen.

        Factored DFGDominators.h/DFGDominators.cpp into WTF. To do this, I made two changes to the
        DFG:

        1) DFG now has a CFG abstraction called DFG::CFG. The cool thing about this is that in the
           future if we wanted to support inverted dominators, we could do it by just creating a
           DFG::BackwardCFG.

        2) Got rid of DFG::Analysis. From now on, an Analysis being invalidated is expressed by the
           DFG::Graph having a null pointer for that analysis. When we "run" the analysis, we
           just instantiate it. This makes it much more natural to integrate WTF::Dominators into
           the DFG.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAnalysis.h: Removed.
        * dfg/DFGCFG.h: Added.
        (JSC::DFG::CFG::CFG):
        (JSC::DFG::CFG::root):
        (JSC::DFG::CFG::newMap<T>):
        (JSC::DFG::CFG::successors):
        (JSC::DFG::CFG::predecessors):
        (JSC::DFG::CFG::index):
        (JSC::DFG::CFG::node):
        (JSC::DFG::CFG::numNodes):
        (JSC::DFG::CFG::dump):
        * dfg/DFGCSEPhase.cpp:
        * dfg/DFGDisassembler.cpp:
        (JSC::DFG::Disassembler::createDumpList):
        * dfg/DFGDominators.cpp: Removed.
        * dfg/DFGDominators.h:
        (JSC::DFG::Dominators::Dominators):
        (JSC::DFG::Dominators::strictlyDominates): Deleted.
        (JSC::DFG::Dominators::dominates): Deleted.
        (JSC::DFG::Dominators::immediateDominatorOf): Deleted.
        (JSC::DFG::Dominators::forAllStrictDominatorsOf): Deleted.
        (JSC::DFG::Dominators::forAllDominatorsOf): Deleted.
        (JSC::DFG::Dominators::forAllBlocksStrictlyDominatedBy): Deleted.
        (JSC::DFG::Dominators::forAllBlocksDominatedBy): Deleted.
        (JSC::DFG::Dominators::forAllBlocksInDominanceFrontierOf): Deleted.
        (JSC::DFG::Dominators::forAllBlocksInIteratedDominanceFrontierOf): Deleted.
        (JSC::DFG::Dominators::forAllBlocksInPrunedIteratedDominanceFrontierOf): Deleted.
        (JSC::DFG::Dominators::forAllBlocksInDominanceFrontierOfImpl): Deleted.
        (JSC::DFG::Dominators::forAllBlocksInIteratedDominanceFrontierOfImpl): Deleted.
        (JSC::DFG::Dominators::BlockData::BlockData): Deleted.
        * dfg/DFGEdgeDominates.h:
        (JSC::DFG::EdgeDominates::operator()):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        (JSC::DFG::Graph::dumpBlockHeader):
        (JSC::DFG::Graph::invalidateCFG):
        (JSC::DFG::Graph::substituteGetLocal):
        (JSC::DFG::Graph::handleAssertionFailure):
        (JSC::DFG::Graph::ensureDominators):
        (JSC::DFG::Graph::ensurePrePostNumbering):
        (JSC::DFG::Graph::ensureNaturalLoops):
        (JSC::DFG::Graph::valueProfileFor):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::hasDebuggerEnabled):
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::run):
        (JSC::DFG::LICMPhase::attemptHoist):
        * dfg/DFGLoopPreHeaderCreationPhase.cpp:
        (JSC::DFG::createPreHeader):
        (JSC::DFG::LoopPreHeaderCreationPhase::run):
        * dfg/DFGNaturalLoops.cpp:
        (JSC::DFG::NaturalLoop::dump):
        (JSC::DFG::NaturalLoops::NaturalLoops):
        (JSC::DFG::NaturalLoops::~NaturalLoops):
        (JSC::DFG::NaturalLoops::loopsOf):
        (JSC::DFG::NaturalLoops::computeDependencies): Deleted.
        (JSC::DFG::NaturalLoops::compute): Deleted.
        * dfg/DFGNaturalLoops.h:
        (JSC::DFG::NaturalLoops::numLoops):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::SuccessorsIterable::end):
        (JSC::DFG::Node::SuccessorsIterable::size):
        (JSC::DFG::Node::SuccessorsIterable::at):
        (JSC::DFG::Node::SuccessorsIterable::operator[]):
        * dfg/DFGOSREntrypointCreationPhase.cpp:
        (JSC::DFG::OSREntrypointCreationPhase::run):
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPrePostNumbering.cpp:
        (JSC::DFG::PrePostNumbering::PrePostNumbering):
        (JSC::DFG::PrePostNumbering::~PrePostNumbering):
        (JSC::DFG::PrePostNumbering::compute): Deleted.
        * dfg/DFGPrePostNumbering.h:
        (JSC::DFG::PrePostNumbering::preNumber):
        (JSC::DFG::PrePostNumbering::postNumber):
        * dfg/DFGPutStackSinkingPhase.cpp:
        * dfg/DFGSSACalculator.cpp:
        (JSC::DFG::SSACalculator::nonLocalReachingDef):
        (JSC::DFG::SSACalculator::reachingDefAtTail):
        * dfg/DFGSSACalculator.h:
        (JSC::DFG::SSACalculator::computePhis):
        * dfg/DFGSSAConversionPhase.cpp:
        (JSC::DFG::SSAConversionPhase::run):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::safelyInvalidateAfterTermination):
        (JSC::FTL::DFG::LowerDFGToLLVM::isValid):

2015-10-31  Filip Pizlo  <fpizlo@apple.com>

        B3::reduceStrength's DCE should be more agro and less wrong
        https://bugs.webkit.org/show_bug.cgi?id=150748

        Reviewed by Geoffrey Garen.

        First of all, our DCE had a bug where it would keep Upsilons after it deleted the Phis that
        they referenced. But our B3 DCE was also not aggressive enough. It would not eliminate
        cycles. It was also probably slower than it needed to be, since it would eliminate all
        never-referenced things on each fixpoint.

        This adds a presume-everyone-is-dead-and-find-live-things style DCE. This is very natural to
        write, except for Upsilons. For everything but Upsilons, it's just a worklist algorithm. For
        Upsilons, it's a fixpoint. It works fine in the end.

        I kept finding bugs in this algorithm when I tested it against my "Complex" test that I was
        writing as a compile time benchmark. So, I include that test in this change. I also include
        the small lowering extensions that it needed - shifting and zero extending.

        This change also adds an LLVM version of the Complex test. Though the LLVM version feels
        more natural to write because LLVM has traditional Phi's rather than our quirky Phi's, in
        the end LLVM ends up performing very badly - 10x to 20x worse than B3. Some of that gap will
        close once we give B3 a register allocator, but still, that's pretty good news for our B3
        strategy.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::lshift64):
        (JSC::MacroAssemblerX86_64::rshift64):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::shlq_i8r):
        (JSC::X86Assembler::shlq_CLr):
        (JSC::X86Assembler::imull_rr):
        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::replacePredecessor):
        (JSC::B3::BasicBlock::dump):
        (JSC::B3::BasicBlock::removeNops): Deleted.
        * b3/B3BasicBlock.h:
        (JSC::B3::BasicBlock::frequency):
        * b3/B3Common.cpp:
        (JSC::B3::shouldSaveIRBeforePhase):
        (JSC::B3::shouldMeasurePhaseTiming):
        * b3/B3Common.h:
        (JSC::B3::isRepresentableAsImpl):
        * b3/B3Generate.cpp:
        (JSC::B3::generate):
        (JSC::B3::generateToAir):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::tryAnd):
        (JSC::B3::Air::LowerToAir::tryShl):
        (JSC::B3::Air::LowerToAir::tryStoreAddLoad):
        (JSC::B3::Air::LowerToAir::tryTrunc):
        (JSC::B3::Air::LowerToAir::tryZExt32):
        (JSC::B3::Air::LowerToAir::tryArgumentReg):
        * b3/B3LoweringMatcher.patterns:
        * b3/B3PhaseScope.cpp:
        (JSC::B3::PhaseScope::PhaseScope):
        * b3/B3PhaseScope.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3TimingScope.cpp: Added.
        (JSC::B3::TimingScope::TimingScope):
        (JSC::B3::TimingScope::~TimingScope):
        * b3/B3TimingScope.h: Added.
        * b3/B3Validate.cpp:
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirInstInlines.h:
        (JSC::B3::Air::ForEach<Arg>::forEach):
        (JSC::B3::Air::Inst::forEach):
        (JSC::B3::Air::isLshift32Valid):
        (JSC::B3::Air::isLshift64Valid):
        * b3/air/AirLiveness.h:
        (JSC::B3::Air::Liveness::isAlive):
        (JSC::B3::Air::Liveness::Liveness):
        (JSC::B3::Air::Liveness::LocalCalc::execute):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirPhaseScope.cpp:
        (JSC::B3::Air::PhaseScope::PhaseScope):
        * b3/air/AirPhaseScope.h:
        * b3/testb3.cpp:
        (JSC::B3::testBranchEqualFoldPtr):
        (JSC::B3::testComplex):
        (JSC::B3::run):
        * runtime/Options.h:

2015-11-01  Alexey Proskuryakov  <ap@apple.com>

        [ES6] Add support for toStringTag
        https://bugs.webkit.org/show_bug.cgi?id=150696

        Re-landing, as this wasn't the culprit.

        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        * runtime/CommonIdentifiers.h:
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::JSArrayBufferPrototype::finishCreation):
        (JSC::JSArrayBufferPrototype::create):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::JSDataViewPrototype::create):
        (JSC::JSDataViewPrototype::finishCreation):
        (JSC::JSDataViewPrototype::createStructure):
        * runtime/JSDataViewPrototype.h:
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::finishCreation):
        * runtime/JSONObject.cpp:
        (JSC::JSONObject::finishCreation):
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::finishCreation):
        (JSC::JSPromisePrototype::getOwnPropertySlot):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewProtoFuncValues):
        (JSC::typedArrayViewProtoGetterFuncToStringTag):
        (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        (JSC::MapIteratorPrototypeFuncNext):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        (JSC::SetIteratorPrototypeFuncNext):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::SmallStrings):
        (JSC::SmallStrings::initializeCommonStrings):
        (JSC::SmallStrings::visitStrongReferences):
        * runtime/SmallStrings.h:
        (JSC::SmallStrings::typeString):
        (JSC::SmallStrings::objectStringStart):
        (JSC::SmallStrings::nullObjectString):
        (JSC::SmallStrings::undefinedObjectString):
        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation):
        (JSC::getWeakMapData):
        * runtime/WeakSetPrototype.cpp:
        (JSC::WeakSetPrototype::finishCreation):
        (JSC::getWeakMapData):
        * tests/es6.yaml:
        * tests/modules/namespace.js:
        * tests/stress/symbol-tostringtag.js: Copied from Source/JavaScriptCore/tests/stress/symbol-tostringtag.js.

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

        Unreviewed, rolling out r191815 and r191821.
        https://bugs.webkit.org/show_bug.cgi?id=150781

        Seems to have broken JSC API tests on some platforms
        (Requested by ap on #webkit).

        Reverted changesets:

        "[ES6] Add support for toStringTag"
        https://bugs.webkit.org/show_bug.cgi?id=150696
        http://trac.webkit.org/changeset/191815

        "Unreviewed, forgot to mark tests as passing for new feature."
        http://trac.webkit.org/changeset/191821

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

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

        Broke the build (Requested by ap on #webkit).

        Reverted changeset:

        "Rename op_put_getter_setter to op_put_getter_setter_by_id"
        https://bugs.webkit.org/show_bug.cgi?id=150773
        http://trac.webkit.org/changeset/191858

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

        Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=150777.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptRoot):

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

        Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=150775.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::tryTrunc):

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

        Rename op_put_getter_setter to op_put_getter_setter_by_id
        https://bugs.webkit.org/show_bug.cgi?id=150773

        Reviewed by Mark Lam.

        Renaming op_put_getter_setter to op_put_getter_setter_by_id makes this op name consistent with
        the other ops' names like op_put_getter_by_id etc.

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPutGetterSetter):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_getter_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter): Deleted.
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_getter_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter): Deleted.
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:

2015-10-31  Andreas Kling  <akling@apple.com>

        Add a debug overlay with information about web process resource usage.
        <https://webkit.org/b/150599>

        Reviewed by Darin Adler.

        Have Heap track the exact number of bytes allocated in CopiedBlock, MarkedBlock and
        WeakBlock objects, keeping them in a single location that can be sampled by the
        resource usage overlay thread.

        The bulk of these changes is threading a Heap& through from sites where blocks are
        allocated or freed.

        * heap/CopiedBlock.cpp:
        (JSC::CopiedBlock::createNoZeroFill):
        (JSC::CopiedBlock::destroy):
        (JSC::CopiedBlock::create):
        * heap/CopiedBlock.h:
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::~CopiedSpace):
        (JSC::CopiedSpace::tryAllocateOversize):
        (JSC::CopiedSpace::tryReallocateOversize):
        * heap/CopiedSpaceInlines.h:
        (JSC::CopiedSpace::recycleEvacuatedBlock):
        (JSC::CopiedSpace::recycleBorrowedBlock):
        (JSC::CopiedSpace::allocateBlockForCopyingPhase):
        (JSC::CopiedSpace::allocateBlock):
        (JSC::CopiedSpace::startedCopying):
        * heap/Heap.cpp:
        (JSC::Heap::~Heap):
        (JSC::Heap::sweepNextLogicallyEmptyWeakBlock):
        * heap/Heap.h:
        (JSC::Heap::blockBytesAllocated):
        * heap/HeapInlines.h:
        (JSC::Heap::didAllocateBlock):
        (JSC::Heap::didFreeBlock):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::allocateBlock):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::destroy):
        * heap/MarkedBlock.h:
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::freeBlock):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::create):
        (JSC::WeakBlock::destroy):
        * heap/WeakBlock.h:
        * heap/WeakSet.cpp:
        (JSC::WeakSet::~WeakSet):
        (JSC::WeakSet::addAllocator):
        (JSC::WeakSet::removeAllocator):

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

        Air should eliminate dead code
        https://bugs.webkit.org/show_bug.cgi?id=150746

        Reviewed by Geoffrey Garen.

        This adds a very simple dead code elimination to Air. It simply looks at whether a Tmp or
        StackSlot has ever been used by a live instruction. An instruction is live if it has non-arg
        effects (branching, returning, calling, etc) or if it stores to a live Arg. An Arg is live if
        it references a live Tmp or StackSlot, or if it is neither a Tmp nor a StackSlot. The phase
        runs these rules to fixpoint, and then removes the dead instructions.

        This also changes the AirOpcodes parser to handle multiple attributes per opcode, so that we
        could conceivably say things like "FooBar /branch /effects". It also adds the /effects
        attribute, which we currently use for Breakpoint and nothing else. C calls, patchpoints, and
        checks are all Specials, and the Special base class by default always claims that the
        instruction has effects. In the future, we could have B3 use a Patch in Air to implement
        exotic math constructs; then the Special associated with that thing would claim that there
        are no effects.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirBasicBlock.h:
        (JSC::B3::Air::BasicBlock::begin):
        (JSC::B3::Air::BasicBlock::end):
        (JSC::B3::Air::BasicBlock::at):
        (JSC::B3::Air::BasicBlock::last):
        (JSC::B3::Air::BasicBlock::resize):
        (JSC::B3::Air::BasicBlock::appendInst):
        * b3/air/AirEliminateDeadCode.cpp: Added.
        (JSC::B3::Air::eliminateDeadCode):
        * b3/air/AirEliminateDeadCode.h: Added.
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirInst.h:
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirSpecial.cpp:
        (JSC::B3::Air::Special::name):
        (JSC::B3::Air::Special::hasNonArgNonControlEffects):
        (JSC::B3::Air::Special::dump):
        * b3/air/AirSpecial.h:
        * b3/air/opcode_generator.rb:

2015-10-31  Filip Pizlo  <fpizlo@apple.com>

        Air needs a late register liveness phase that calls Special::reportUsedRegisters()
        https://bugs.webkit.org/show_bug.cgi?id=150511

        Reviewed by Saam Barati.

        This change adds such a phase. In the process of writing it, I was reminded about the
        glaring efficiency bugs in Air::Liveness and so I filed a bug and added FIXMEs.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirGenerate.cpp:
        (JSC::B3::Air::generate):
        * b3/air/AirReportUsedRegisters.cpp: Added.
        (JSC::B3::Air::reportUsedRegisters):
        * b3/air/AirReportUsedRegisters.h: Added.

2015-10-31  Brian Burg  <bburg@apple.com>

        Builtins generator should put WebCore-only wrappers in the per-builtin header
        https://bugs.webkit.org/show_bug.cgi?id=150539

        Reviewed by Youenn Fablet.

        If generating for WebCore, put the XXXWrapper and related boilerplate
        in the per-builtin header instead of making a separate XXXWrapper.h.

        Rebaseline the tests.

        * CMakeLists.txt:
        * DerivedSources.make:
        * Scripts/builtins/builtins.py:
        * Scripts/builtins/builtins_generate_separate_header.py:
        (BuiltinsSeparateHeaderGenerator.generate_output):
        (generate_header_includes):
        * Scripts/builtins/builtins_generate_separate_wrapper.py: Deleted.
        * Scripts/builtins/builtins_templates.py: Be consistent with variables.
        * Scripts/generate-js-builtins.py:
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:

2015-10-31  Saam barati  <sbarati@apple.com>

        JSC should have a forceGCSlowPaths option
        https://bugs.webkit.org/show_bug.cgi?id=150744

        Reviewed by Filip Pizlo.

        This patch implements the forceGCSlowPaths option.
        It defaults to false, but when it is set to true,
        the JITs will always allocate objects along the slow
        path. This will be helpful for writing a certain class
        of tests. This may also come in handy for debugging
        later.

        This patch also adds the "forceGCSlowPaths" function
        in jsc.cpp which sets the option to true. If you
        use this function in a jsc stress test, it's best
        to call it as the first thing in the program before
        we JIT anything.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateCell):
        * jit/JITInlines.h:
        (JSC::JIT::emitAllocateJSObject):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionEdenGC):
        (functionForceGCSlowPaths):
        (functionHeapSize):
        * runtime/Options.h:

2015-10-30  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Test Debugger.scriptParsed events received after opening inspector frontend
        https://bugs.webkit.org/show_bug.cgi?id=150753

        Reviewed by Timothy Hatcher.

        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        Only set the directives on the SourceProvider if we were parsing the
        entire file (Program or Module), not if we are in function parsing mode.
        This was inadvertently clearing the directives stored on the
        SourceProvider when the function parse didn't see directives and reset
        the values on the source provider.

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

        [JSC] Add lowering for B3's Sub operation with integers
        https://bugs.webkit.org/show_bug.cgi?id=150749

        Reviewed by Filip Pizlo.

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::trySub):
        (JSC::B3::Air::LowerToAir::tryStoreSubLoad):
        * b3/B3LoweringMatcher.patterns:
        Identical to Add but obviously NotCommutative.

        * b3/B3ReduceStrength.cpp:
        Turn Add/Sub with zero into an identity. I only added for
        Add since Sub with a constant is always turned into an Add.

        Also switched the Sub optimizations to put the strongest first.

        * b3/air/AirOpcode.opcodes:
        * b3/testb3.cpp:
        (JSC::B3::testAddArgImm):
        (JSC::B3::testAddImmArg):
        (JSC::B3::testSubArgs):
        (JSC::B3::testSubArgImm):
        (JSC::B3::testSubImmArg):
        (JSC::B3::testSubArgs32):
        (JSC::B3::testSubArgImm32):
        (JSC::B3::testSubImmArg32):
        (JSC::B3::testStoreSubLoad):
        (JSC::B3::run):

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

        [JSC] Add the Air Opcode definitions to the Xcode project file
        https://bugs.webkit.org/show_bug.cgi?id=150701

        Reviewed by Geoffrey Garen.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        Easier for those who use Xcode :)

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

        Unreviewed, removing FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=150540.

        * b3/B3ValueRep.h:

2015-10-30  Michael Saboff  <msaboff@apple.com>

        Windows X86-64 change for Crash making a tail call from a getter to a host function
        https://bugs.webkit.org/show_bug.cgi?id=150737

        Reviewed by Geoffrey Garen.

        Need to make the same change for Windows X86-64 as was made in change set
        http://trac.webkit.org/changeset/191765.

        * jit/JITStubsMSVC64.asm:

2015-10-30  Keith Miller  <keith_miller@apple.com>

        Unreviewed, forgot to mark tests as passing for new feature.

        * tests/es6.yaml:

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

        B3 should be able to compile a control flow diamond
        https://bugs.webkit.org/show_bug.cgi?id=150720

        Reviewed by Benjamin Poulain.

        Adds support for Branch, Jump, Upsilon, and Phi. Adds some basic strength reduction for
        comparisons and boolean-like operations.

        * assembler/MacroAssembler.cpp:
        (WTF::printInternal):
        * assembler/MacroAssembler.h:
        * b3/B3BasicBlockUtils.h:
        (JSC::B3::replacePredecessor):
        (JSC::B3::resetReachability):
        * b3/B3CheckValue.h:
        * b3/B3Common.h:
        (JSC::B3::isRepresentableAsImpl):
        (JSC::B3::isRepresentableAs):
        * b3/B3Const32Value.cpp:
        (JSC::B3::Const32Value::subConstant):
        (JSC::B3::Const32Value::equalConstant):
        (JSC::B3::Const32Value::notEqualConstant):
        (JSC::B3::Const32Value::dumpMeta):
        * b3/B3Const32Value.h:
        * b3/B3Const64Value.cpp:
        (JSC::B3::Const64Value::subConstant):
        (JSC::B3::Const64Value::equalConstant):
        (JSC::B3::Const64Value::notEqualConstant):
        (JSC::B3::Const64Value::dumpMeta):
        * b3/B3Const64Value.h:
        * b3/B3ConstDoubleValue.cpp:
        (JSC::B3::ConstDoubleValue::subConstant):
        (JSC::B3::ConstDoubleValue::equalConstant):
        (JSC::B3::ConstDoubleValue::notEqualConstant):
        (JSC::B3::ConstDoubleValue::dumpMeta):
        * b3/B3ConstDoubleValue.h:
        * b3/B3ControlValue.cpp:
        (JSC::B3::ControlValue::~ControlValue):
        (JSC::B3::ControlValue::convertToJump):
        (JSC::B3::ControlValue::dumpMeta):
        * b3/B3ControlValue.h:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::imm):
        (JSC::B3::Air::LowerToAir::tryStackSlot):
        (JSC::B3::Air::LowerToAir::tryUpsilon):
        (JSC::B3::Air::LowerToAir::tryPhi):
        (JSC::B3::Air::LowerToAir::tryBranch):
        (JSC::B3::Air::LowerToAir::tryJump):
        (JSC::B3::Air::LowerToAir::tryIdentity):
        * b3/B3LoweringMatcher.patterns:
        * b3/B3Opcode.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::resetReachability):
        (JSC::B3::Procedure::dump):
        * b3/B3ReduceStrength.cpp:
        * b3/B3UpsilonValue.cpp:
        (JSC::B3::UpsilonValue::dumpMeta):
        * b3/B3UpsilonValue.h:
        (JSC::B3::UpsilonValue::accepts): Deleted.
        (JSC::B3::UpsilonValue::phi): Deleted.
        (JSC::B3::UpsilonValue::UpsilonValue): Deleted.
        * b3/B3Validate.cpp:
        * b3/B3Value.cpp:
        (JSC::B3::Value::subConstant):
        (JSC::B3::Value::equalConstant):
        (JSC::B3::Value::notEqualConstant):
        (JSC::B3::Value::returnsBool):
        (JSC::B3::Value::asTriState):
        (JSC::B3::Value::effects):
        * b3/B3Value.h:
        * b3/B3ValueInlines.h:
        (JSC::B3::Value::asInt32):
        (JSC::B3::Value::isInt32):
        (JSC::B3::Value::hasInt64):
        (JSC::B3::Value::asInt64):
        (JSC::B3::Value::isInt64):
        (JSC::B3::Value::hasInt):
        (JSC::B3::Value::asIntPtr):
        (JSC::B3::Value::isIntPtr):
        (JSC::B3::Value::hasDouble):
        (JSC::B3::Value::asDouble):
        (JSC::B3::Value::isEqualToDouble):
        (JSC::B3::Value::hasNumber):
        (JSC::B3::Value::representableAs):
        (JSC::B3::Value::asNumber):
        (JSC::B3::Value::stackmap):
        * b3/air/AirArg.cpp:
        (JSC::B3::Air::Arg::dump):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::resCond):
        (JSC::B3::Air::Arg::doubleCond):
        (JSC::B3::Air::Arg::special):
        (JSC::B3::Air::Arg::isResCond):
        (JSC::B3::Air::Arg::isDoubleCond):
        (JSC::B3::Air::Arg::isSpecial):
        (JSC::B3::Air::Arg::isGP):
        (JSC::B3::Air::Arg::isFP):
        (JSC::B3::Air::Arg::asResultCondition):
        (JSC::B3::Air::Arg::asDoubleCondition):
        (JSC::B3::Air::Arg::Arg):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::resetReachability):
        (JSC::B3::Air::Code::dump):
        * b3/air/AirOpcode.opcodes:
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (hiddenTruthBecauseNoReturnIsStupid):
        (usage):
        (JSC::B3::compile):
        (JSC::B3::invoke):
        (JSC::B3::compileAndRun):
        (JSC::B3::test42):
        (JSC::B3::testStoreLoadStackSlot):
        (JSC::B3::testBranch):
        (JSC::B3::testDiamond):
        (JSC::B3::testBranchNotEqual):
        (JSC::B3::testBranchFold):
        (JSC::B3::testDiamondFold):
        (JSC::B3::run):
        (run):
        (main):

2015-10-30  Keith Miller  <keith_miller@apple.com>

        [ES6] Add support for toStringTag
        https://bugs.webkit.org/show_bug.cgi?id=150696

        Reviewed by Geoffrey Garen.

        This patch adds support for Symbol.toStringTag. This is a simple
        feature, if an object passed to Object.prototype.toString() has a
        toStringTag we use the tag in the string rather than the class info.
        Added a test that checks this works for all the default supported classes
        along with the corresponding prototype and custom cases.

        * runtime/ArrayIteratorPrototype.cpp:
        (JSC::ArrayIteratorPrototype::finishCreation):
        * runtime/CommonIdentifiers.h:
        * runtime/JSArrayBufferPrototype.cpp:
        (JSC::JSArrayBufferPrototype::finishCreation):
        * runtime/JSDataViewPrototype.cpp:
        (JSC::JSDataViewPrototype::finishCreation):
        * runtime/JSDataViewPrototype.h:
        * runtime/JSModuleNamespaceObject.cpp:
        (JSC::JSModuleNamespaceObject::finishCreation):
        * runtime/JSONObject.cpp:
        (JSC::JSONObject::finishCreation):
        * runtime/JSPromisePrototype.cpp:
        (JSC::JSPromisePrototype::finishCreation):
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::typedArrayViewProtoGetterFuncToStringTag):
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * runtime/MapIteratorPrototype.cpp:
        (JSC::MapIteratorPrototype::finishCreation):
        * runtime/MapPrototype.cpp:
        (JSC::MapPrototype::finishCreation):
        * runtime/MathObject.cpp:
        (JSC::MathObject::finishCreation):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):
        * runtime/SetIteratorPrototype.cpp:
        (JSC::SetIteratorPrototype::finishCreation):
        * runtime/SetPrototype.cpp:
        (JSC::SetPrototype::finishCreation):
        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::SmallStrings):
        (JSC::SmallStrings::initializeCommonStrings):
        (JSC::SmallStrings::visitStrongReferences):
        * runtime/SmallStrings.h:
        (JSC::SmallStrings::objectStringStart):
        * runtime/StringIteratorPrototype.cpp:
        (JSC::StringIteratorPrototype::finishCreation):
        * runtime/SymbolPrototype.cpp:
        (JSC::SymbolPrototype::finishCreation):
        * runtime/WeakMapPrototype.cpp:
        (JSC::WeakMapPrototype::finishCreation):
        * runtime/WeakSetPrototype.cpp:
        (JSC::WeakSetPrototype::finishCreation):
        * tests/modules/namespace.js:
        * tests/stress/symbol-tostringtag.js: Added.
        (toStr):
        (strName):
        (classes.string_appeared_here):

2015-10-29  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Do not show JavaScriptCore builtins in inspector
        https://bugs.webkit.org/show_bug.cgi?id=146049

        Reviewed by Geoffrey Garen.

        * debugger/Debugger.cpp:
        When gathering scripts to notify the inspector / debuggers about
        skip over sources containing host / built-in functions as those
        for those won't contain source code developers expect to see.

2015-10-29  Joseph Pecoraro  <pecoraro@apple.com>

        Fix typo in "use strict" in TypedArray builtins
        https://bugs.webkit.org/show_bug.cgi?id=150709

        Reviewed by Geoffrey Garen.

        * builtins/TypedArray.prototype.js:
        (toLocaleString):

2015-10-29  Philippe Normand  <pnormand@igalia.com>

        [GTK][Mac] disable OBJC JSC API
        https://bugs.webkit.org/show_bug.cgi?id=150500

        Reviewed by Alex Christensen.

        * API/JSBase.h: Disable the Objective-C API on Mac for the GTK port.

2015-10-29  Filip Pizlo  <fpizlo@apple.com>

        Air::handleCalleeSaves shouldn't save/restore the frame pointer
        https://bugs.webkit.org/show_bug.cgi?id=150688

        Reviewed by Michael Saboff.

        We save/restore the FP inside Air::generate().

        * b3/air/AirHandleCalleeSaves.cpp:
        (JSC::B3::Air::handleCalleeSaves):

2015-10-29  Michael Saboff  <msaboff@apple.com>

        Crash making a tail call from a getter to a host function
        https://bugs.webkit.org/show_bug.cgi?id=150663

        Reviewed by Geoffrey Garen.

        Change the inline assembly versions of getHostCallReturnValue() to pass the location of the callee
        call frame to getHostCallReturnValueWithExecState().  We were passing the caller's frame address.

        * jit/JITOperations.cpp:

2015-10-29  Filip Pizlo  <fpizlo@apple.com>

        B3::LowerToAir::imm() should work for both 32-bit and 64-bit immediates
        https://bugs.webkit.org/show_bug.cgi?id=150685

        Reviewed by Geoffrey Garen.

        In B3, a constant must match the type of its use. In Air, immediates don't have type, they
        only have representation. A 32-bit immediate (i.e. Arg::imm) can be used either for 32-bit
        operations or for 64-bit operations. The only difference from a Arg::imm64 is that it
        requires fewer bits.

        In the B3->Air lowering, we have a lot of code that is effectively polymorphic over integer
        type. That code should still be able to use Arg::imm, and it should work even for 64-bit
        immediates - so long as they are representable as 32-bit immediates. Therefore, the imm()
        helper should happily accept either Const32Value or Const64Value.

        We already sort of had this with immAnyType(), but it just turns out that anyone using
        immAnyType() should really be using imm().

        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::imm):
        (JSC::B3::Air::LowerToAir::tryStore):
        (JSC::B3::Air::LowerToAir::tryConst64):
        (JSC::B3::Air::LowerToAir::immAnyInt): Deleted.
        * b3/testb3.cpp:
        (JSC::B3::testAdd1):
        (JSC::B3::testAdd1Ptr):
        (JSC::B3::testStoreAddLoad):
        (JSC::B3::run):

2015-10-29  Filip Pizlo  <fpizlo@apple.com>

        StoreOpLoad pattern matching should check effects between the Store and Load
        https://bugs.webkit.org/show_bug.cgi?id=150534

        Reviewed by Geoffrey Garen.

        If we turn:

            a = Load(addr)
            b = Add(a, 42)
            Store(b, addr)

        Into:

            Add $42, (addr)

        Then we must make sure that we didn't really have this to begin with:

            a = Load(addr)
            Store(666, addr)
            b = Add(a, 42)
            Store(b, addr)

        That's because pattern matching doesn't care about control flow, and it finds the Load
        just using data flow. This patch fleshes out B3's aliasing analysis, and makes it powerful
        enough to broadly ask questions about whether such a code motion of the Load is legal.

        * b3/B3Effects.cpp:
        (JSC::B3::Effects::interferes):
        (JSC::B3::Effects::dump):
        * b3/B3Effects.h:
        (JSC::B3::Effects::mustExecute):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::commitInternal):
        (JSC::B3::Air::LowerToAir::crossesInterference):
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        (JSC::B3::Air::LowerToAir::loadAddr):
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::addBlock):
        (JSC::B3::Procedure::resetValueOwners):
        (JSC::B3::Procedure::resetReachability):
        * b3/B3Procedure.h:
        * b3/B3Value.cpp:
        (JSC::B3::Value::effects):
        * b3/B3Value.h:
        * b3/testb3.cpp:
        (JSC::B3::testStoreAddLoad):
        (JSC::B3::testStoreAddLoadInterference):
        (JSC::B3::testStoreAddAndLoad):
        (JSC::B3::testLoadOffsetUsingAdd):
        (JSC::B3::testLoadOffsetUsingAddInterference):
        (JSC::B3::testLoadOffsetUsingAddNotConstant):
        (JSC::B3::run):

2015-10-29  Brady Eidson  <beidson@apple.com>

        Modern IDB: deleteObjectStore support.
        https://bugs.webkit.org/show_bug.cgi?id=150673

        Reviewed by Alex Christensen.

        * runtime/VM.h:

2015-10-29  Mark Lam  <mark.lam@apple.com>

        cdjs-tests.yaml/main.js.ftl fails due to FTL ArithSub code for supporting UntypedUse operands.
        https://bugs.webkit.org/show_bug.cgi?id=150687

        Unreviewed.

        Disabling the feature while it is being debugged.  I'm doing this by effectively
        rolling out only the changes in FTLCapabilities.cpp.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):

2015-10-29  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix iOS build.

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::store64):

2015-10-29  Alex Christensen  <achristensen@webkit.org>

        Fix Mac CMake build
        https://bugs.webkit.org/show_bug.cgi?id=150686

        Reviewed by Filip Pizlo.

        * API/ObjCCallbackFunction.mm:
        * CMakeLists.txt:
        * PlatformMac.cmake:

2015-10-29  Filip Pizlo  <fpizlo@apple.com>

        Air needs syntax for escaping StackSlots
        https://bugs.webkit.org/show_bug.cgi?id=150430

        Reviewed by Geoffrey Garen.

        This adds lowering for FramePointer and StackSlot, and to enable this, it adds the Lea
        instruction for getting the value of an address. This is necessary to support arbitrary
        lowerings of StackSlot, since the only way to get the "value" of a StackSlot in Air is with
        this new instruction.

        Lea uses a new Role, called UseAddr. This describes exactly what the Intel-style LEA opcode
        would do: it evaluates an address, but does not load from it or store to it.

        Lea is also the only way to escape a StackSlot. Well, more accurately, UseAddr is the only
        way to escape and UseAddr is only used by Lea. The stack allocation phase now understands
        that StackSlots may escape, and factors this into its analysis.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::lea):
        * b3/B3AddressMatcher.patterns:
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::addr):
        (JSC::B3::Air::LowerToAir::loadAddr):
        (JSC::B3::Air::LowerToAir::AddressSelector::tryAdd):
        (JSC::B3::Air::LowerToAir::AddressSelector::tryFramePointer):
        (JSC::B3::Air::LowerToAir::AddressSelector::tryStackSlot):
        (JSC::B3::Air::LowerToAir::AddressSelector::tryDirect):
        (JSC::B3::Air::LowerToAir::tryConst64):
        (JSC::B3::Air::LowerToAir::tryFramePointer):
        (JSC::B3::Air::LowerToAir::tryStackSlot):
        (JSC::B3::Air::LowerToAir::tryIdentity):
        * b3/B3LoweringMatcher.patterns:
        * b3/B3MemoryValue.cpp:
        (JSC::B3::MemoryValue::~MemoryValue):
        (JSC::B3::MemoryValue::accessByteSize):
        (JSC::B3::MemoryValue::dumpMeta):
        * b3/B3MemoryValue.h:
        * b3/B3ReduceStrength.cpp:
        * b3/B3StackSlotValue.h:
        (JSC::B3::StackSlotValue::accepts): Deleted.
        * b3/B3Type.h:
        (JSC::B3::pointerType):
        (JSC::B3::sizeofType):
        * b3/B3Validate.cpp:
        * b3/B3Value.h:
        * b3/air/AirAllocateStack.cpp:
        (JSC::B3::Air::allocateStack):
        * b3/air/AirArg.h:
        (JSC::B3::Air::Arg::isUse):
        (JSC::B3::Air::Arg::isDef):
        (JSC::B3::Air::Arg::forEachTmp):
        * b3/air/AirCode.cpp:
        (JSC::B3::Air::Code::addStackSlot):
        (JSC::B3::Air::Code::addSpecial):
        * b3/air/AirCode.h:
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/air/AirStackSlot.h:
        (JSC::B3::Air::StackSlot::byteSize):
        (JSC::B3::Air::StackSlot::kind):
        (JSC::B3::Air::StackSlot::isLocked):
        (JSC::B3::Air::StackSlot::index):
        (JSC::B3::Air::StackSlot::alignment):
        * b3/air/opcode_generator.rb:
        * b3/testb3.cpp:
        (JSC::B3::testLoadOffsetUsingAddNotConstant):
        (JSC::B3::testFramePointer):
        (JSC::B3::testStackSlot):
        (JSC::B3::testLoadFromFramePointer):
        (JSC::B3::testStoreLoadStackSlot):
        (JSC::B3::run):

2015-10-29  Saam barati  <sbarati@apple.com>

        we're incorrectly adjusting a stack location with respect to the localsOffset in FTLCompile
        https://bugs.webkit.org/show_bug.cgi?id=150655

        Reviewed by Filip Pizlo.

        We're recomputing this value for an *OSRExitDescriptor* for every one
        of its corresponding *OSRExits*. This is having a multiplicative
        effect on offsets because each computation is relative to the previous
        value. We must do this computation just once per OSRExitDescriptor.

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

2015-10-28  Filip Pizlo  <fpizlo@apple.com>

        Air::spillEverything() should try to replace tmps with spill slots without using registers whenever possible
        https://bugs.webkit.org/show_bug.cgi?id=150657

        Reviewed by Geoffrey Garen.

        Also added the ability to store an immediate to memory.

        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::storePtr):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::store64):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::store64):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::imm):
        (JSC::B3::Air::LowerToAir::immAnyInt):
        (JSC::B3::Air::LowerToAir::immOrTmp):
        (JSC::B3::Air::LowerToAir::tryStore):
        * b3/air/AirOpcode.opcodes:
        * b3/air/AirSpillEverything.cpp:
        (JSC::B3::Air::spillEverything):
        * b3/testb3.cpp:
        (JSC::B3::testStore):
        (JSC::B3::testStoreConstant):
        (JSC::B3::testStoreConstantPtr):
        (JSC::B3::testTrunc):
        (JSC::B3::run):

2015-10-28  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Rename InspectorResourceAgent to InspectorNetworkAgent
        https://bugs.webkit.org/show_bug.cgi?id=150654

        Reviewed by Geoffrey Garen.

        * inspector/scripts/codegen/generator.py:

2015-10-28  Filip Pizlo  <fpizlo@apple.com>

        B3::reduceStrength() should do DCE
        https://bugs.webkit.org/show_bug.cgi?id=150656

        Reviewed by Saam Barati.

        * b3/B3BasicBlock.cpp:
        (JSC::B3::BasicBlock::removeNops): This now deletes the values from the procedure, to preserve the invariant that valuesInProc == valuesInBlocks.
        * b3/B3BasicBlock.h:
        * b3/B3Procedure.cpp:
        (JSC::B3::Procedure::deleteValue): Add a utility used by removeNops().
        (JSC::B3::Procedure::addValueIndex): Make sure that we reuse Value indices so that m_values doesn't get too sparse.
        * b3/B3Procedure.h:
        (JSC::B3::Procedure::ValuesCollection::iterator::iterator): Teach this that m_values can be slightly sparse.
        (JSC::B3::Procedure::ValuesCollection::iterator::operator++):
        (JSC::B3::Procedure::ValuesCollection::iterator::operator!=):
        (JSC::B3::Procedure::ValuesCollection::iterator::findNext):
        (JSC::B3::Procedure::values):
        * b3/B3ProcedureInlines.h:
        (JSC::B3::Procedure::add): Use addValueIndex() instead of always creating a new index.
        * b3/B3ReduceStrength.cpp: Implement the optimization using UseCounts and Effects.

2015-10-28  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused / duplicate WebSocket timeline records
        https://bugs.webkit.org/show_bug.cgi?id=150647

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Timeline.json:

2015-10-28  Filip Pizlo  <fpizlo@apple.com>

        B3::LowerToAir should not duplicate Loads
        https://bugs.webkit.org/show_bug.cgi?id=150651

        Reviewed by Benjamin Poulain.

        The instruction selector may decide to fuse two Values into one. This ordinarily only happens
        if we haven't already emitted code that uses the Value and the Value has only one direct
        user. Once we have emitted such code, we ensure that everyone knows that we have "locked" the
        Value: we won't emit any more code for it in the future.

        The optimization to fuse Loads was forgetting to do all of these things, and so generated
        code would have a lot of duplicated Loads. That's bad and this change fixes that.

        Ordinarily, this is far less tricky because the pattern matcher does this for us via
        acceptInternals() and acceptInternalsLate(). I added a comment to this effect. I hope that we
        won't need to do this manually very often.

        Also found an uninitialized value bug in UseCounts. That was making all of this super hard to
        debug.

        * b3/B3IndexMap.h:
        (JSC::B3::IndexMap::IndexMap):
        (JSC::B3::IndexMap::resize):
        (JSC::B3::IndexMap::operator[]):
        * b3/B3LowerToAir.cpp:
        (JSC::B3::Air::LowerToAir::tmp):
        (JSC::B3::Air::LowerToAir::canBeInternal):
        (JSC::B3::Air::LowerToAir::commitInternal):
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        (JSC::B3::Air::LowerToAir::loadAddr):
        (JSC::B3::Air::LowerToAir::appendBinOp):
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
        (JSC::B3::Air::LowerToAir::acceptInternals):
        * b3/B3UseCounts.cpp:
        (JSC::B3::UseCounts::UseCounts):

2015-10-28  Mark Lam  <mark.lam@apple.com>

        JITSubGenerator::generateFastPath() does not need to be inlined.
        https://bugs.webkit.org/show_bug.cgi?id=150645

        Reviewed by Geoffrey Garen.

        Moving it to a .cpp file to reduce code size.  Benchmarks shows this to be
        perf neutral.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLCompile.cpp:
        * jit/JITSubGenerator.cpp: Added.
        (JSC::JITSubGenerator::generateFastPath):
        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::JITSubGenerator):
        (JSC::JITSubGenerator::endJumpList):
        (JSC::JITSubGenerator::slowPathJumpList):
        (JSC::JITSubGenerator::generateFastPath): Deleted.

2015-10-28  Filip Pizlo  <fpizlo@apple.com>

        [B3] handleCommutativity should canonicalize commutative operations over non-constants
        https://bugs.webkit.org/show_bug.cgi?id=150649

        Reviewed by Saam Barati.

        Turn this: Add(value1, value2)
        Into this: Add(value2, value1)

        But ony if value2 should come before value1 according to our total ordering. This will allow
        CSE to observe the equality between commuted versions of the same operation, since we will
        first canonicalize them into the same order.

        * b3/B3ReduceStrength.cpp:

2015-10-28  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix the build for case sensitive file systems.

        * b3/air/AirBasicBlock.h:
        * b3/air/AirStackSlot.h:

2015-10-28  Filip Pizlo  <fpizlo@apple.com>

        Create a super rough prototype of B3
        https://bugs.webkit.org/show_bug.cgi?id=150280

        Reviewed by Benjamin Poulain.

        This changeset adds the basic scaffolding of the B3 compiler. B3 stands for Bare Bones
        Backend. It's a low-level SSA-based language-agnostic compiler. The basic structure allows
        for aggressive C-level optimizations and an awesome portable backend. The backend, called
        Air (Assembly IR), is a reflective abstraction over our MacroAssembler. The abstraction is
        defined using a spec file (AirOpcode.opcodes) which describes the various kinds of
        instructions that we wish to support. Then, the B3::LowerToAir phase, which does our
        instruction selection, reflectively selects Air opcodes by querying which instruction forms
        are possible. Air allows for optimal register allocation and stack layout. Currently the
        register allocator isn't written, but the stack layout is.

        Of course this isn't done yet. It can only compile simple programs, seen in the "test suite"
        called "testb3.cpp". There's a lot of optimizations that have to be written and a lot of
        stuff added to the instruction selector. But it's a neat start.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssembler.cpp:
        (WTF::printInternal):
        * assembler/MacroAssembler.h:
        * b3: Added.
        * b3/B3AddressMatcher.patterns: Added.
        * b3/B3ArgumentRegValue.cpp: Added.
        (JSC::B3::ArgumentRegValue::~ArgumentRegValue):
        (JSC::B3::ArgumentRegValue::dumpMeta):
        * b3/B3ArgumentRegValue.h: Added.
        * b3/B3BasicBlock.cpp: Added.
        (JSC::B3::BasicBlock::BasicBlock):
        (JSC::B3::BasicBlock::~BasicBlock):
        (JSC::B3::BasicBlock::append):
        (JSC::B3::BasicBlock::addPredecessor):
        (JSC::B3::BasicBlock::removePredecessor):
        (JSC::B3::BasicBlock::replacePredecessor):
        (JSC::B3::BasicBlock::removeNops):
        (JSC::B3::BasicBlock::dump):
        (JSC::B3::BasicBlock::deepDump):
        * b3/B3BasicBlock.h: Added.
        (JSC::B3::BasicBlock::index):
        (JSC::B3::BasicBlock::begin):
        (JSC::B3::BasicBlock::end):
        (JSC::B3::BasicBlock::size):
        (JSC::B3::BasicBlock::at):
        (JSC::B3::BasicBlock::last):
        (JSC::B3::BasicBlock::values):
        (JSC::B3::BasicBlock::numPredecessors):
        (JSC::B3::BasicBlock::predecessor):
        (JSC::B3::BasicBlock::predecessors):
        (JSC::B3::BasicBlock::frequency):
        (JSC::B3::DeepBasicBlockDump::DeepBasicBlockDump):
        (JSC::B3::DeepBasicBlockDump::dump):
        (JSC::B3::deepDump):
        * b3/B3BasicBlockInlines.h: Added.
        (JSC::B3::BasicBlock::appendNew):
        (JSC::B3::BasicBlock::numSuccessors):
        (JSC::B3::BasicBlock::successor):
        (JSC::B3::BasicBlock::successors):
        (JSC::B3::BasicBlock::successorBlock):
        (JSC::B3::BasicBlock::successorBlocks):
        * b3/B3BasicBlockUtils.h: Added.
        (JSC::B3::addPredecessor):
        (JSC::B3::removePredecessor):
        (JSC::B3::replacePredecessor):
        (JSC::B3::resetReachability):
        (JSC::B3::blocksInPreOrder):
        (JSC::B3::blocksInPostOrder):
        * b3/B3BlockWorklist.h: Added.
        * b3/B3CheckSpecial.cpp: Added.
        (JSC::B3::Air::numB3Args):
        (JSC::B3::CheckSpecial::CheckSpecial):
        (JSC::B3::CheckSpecial::~CheckSpecial):
        (JSC::B3::CheckSpecial::hiddenBranch):
        (JSC::B3::CheckSpecial::forEachArg):
        (JSC::B3::CheckSpecial::isValid):
        (JSC::B3::CheckSpecial::admitsStack):
        (JSC::B3::CheckSpecial::generate):
        (JSC::B3::CheckSpecial::dumpImpl):
        (JSC::B3::CheckSpecial::deepDumpImpl):
        * b3/B3CheckSpecial.h: Added.
        * b3/B3CheckValue.cpp: Added.
        (JSC::B3::CheckValue::~CheckValue):
        (JSC::B3::CheckValue::dumpMeta):
        * b3/B3CheckValue.h: Added.
        * b3/B3Common.cpp: Added.
        (JSC::B3::shouldDumpIR):
        (JSC::B3::shouldDumpIRAtEachPhase):
        (JSC::B3::shouldValidateIR):
        (JSC::B3::shouldValidateIRAtEachPhase):
        (JSC::B3::shouldSaveIRBeforePhase):
        * b3/B3Common.h: Added.
        (JSC::B3::is64Bit):
        (JSC::B3::is32Bit):
        * b3/B3Commutativity.cpp: Added.
        (WTF::printInternal):
        * b3/B3Commutativity.h: Added.
        * b3/B3Const32Value.cpp: Added.
        (JSC::B3::Const32Value::~Const32Value):
        (JSC::B3::Const32Value::negConstant):
        (JSC::B3::Const32Value::addConstant):
        (JSC::B3::Const32Value::subConstant):
        (JSC::B3::Const32Value::dumpMeta):
        * b3/B3Const32Value.h: Added.
        * b3/B3Const64Value.cpp: Added.
        (JSC::B3::Const64Value::~Const64Value):
        (JSC::B3::Const64Value::negConstant):
        (JSC::B3::Const64Value::addConstant):
        (JSC::B3::Const64Value::subConstant):
        (JSC::B3::Const64Value::dumpMeta):
        * b3/B3Const64Value.h: Added.
        * b3/B3ConstDoubleValue.cpp: Added.
        (JSC::B3::ConstDoubleValue::~ConstDoubleValue):
        (JSC::B3::ConstDoubleValue::negConstant):
        (JSC::B3::ConstDoubleValue::addConstant):
        (JSC::B3::ConstDoubleValue::subConstant):
        (JSC::B3::ConstDoubleValue::dumpMeta):
        * b3/B3ConstDoubleValue.h: Added.
        (JSC::B3::ConstDoubleValue::accepts):
        (JSC::B3::ConstDoubleValue::value):
        (JSC::B3::ConstDoubleValue::ConstDoubleValue):
        * b3/B3ConstPtrValue.h: Added.
        (JSC::B3::ConstPtrValue::value):
        (JSC::B3::ConstPtrValue::ConstPtrValue):
        * b3/B3ControlValue.cpp: Added.
        (JSC::B3::ControlValue::~ControlValue):
        (JSC::B3::ControlValue::dumpMeta):
        * b3/B3ControlValue.h: Added.
        * b3/B3Effects.cpp: Added.
        (JSC::B3::Effects::dump):
        * b3/B3Effects.h: Added.
        (JSC::B3::Effects::mustExecute):
        * b3/B3FrequencyClass.cpp: Added.
        (WTF::printInternal):
        * b3/B3FrequencyClass.h: Added.
        * b3/B3FrequentedBlock.h: Added.
        * b3/B3Generate.cpp: Added.
        (JSC::B3::generate):
        (JSC::B3::generateToAir):
        * b3/B3Generate.h: Added.
        * b3/B3GenericFrequentedBlock.h: Added.
        (JSC::B3::GenericFrequentedBlock::GenericFrequentedBlock):
        (JSC::B3::GenericFrequentedBlock::operator==):
        (JSC::B3::GenericFrequentedBlock::operator!=):
        (JSC::B3::GenericFrequentedBlock::operator bool):
        (JSC::B3::GenericFrequentedBlock::block):
        (JSC::B3::GenericFrequentedBlock::frequency):
        (JSC::B3::GenericFrequentedBlock::dump):
        * b3/B3HeapRange.cpp: Added.
        (JSC::B3::HeapRange::dump):
        * b3/B3HeapRange.h: Added.
        (JSC::B3::HeapRange::HeapRange):
        (JSC::B3::HeapRange::top):
        (JSC::B3::HeapRange::operator==):
        (JSC::B3::HeapRange::operator!=):
        (JSC::B3::HeapRange::operator bool):
        (JSC::B3::HeapRange::begin):
        (JSC::B3::HeapRange::end):
        (JSC::B3::HeapRange::overlaps):
        * b3/B3IndexMap.h: Added.
        (JSC::B3::IndexMap::IndexMap):
        (JSC::B3::IndexMap::resize):
        (JSC::B3::IndexMap::operator[]):
        * b3/B3IndexSet.h: Added.
        (JSC::B3::IndexSet::IndexSet):
        (JSC::B3::IndexSet::add):
        (JSC::B3::IndexSet::contains):
        (JSC::B3::IndexSet::Iterable::Iterable):
        (JSC::B3::IndexSet::Iterable::iterator::iterator):
        (JSC::B3::IndexSet::Iterable::iterator::operator*):
        (JSC::B3::IndexSet::Iterable::iterator::operator++):
        (JSC::B3::IndexSet::Iterable::iterator::operator==):
        (JSC::B3::IndexSet::Iterable::iterator::operator!=):
        (JSC::B3::IndexSet::Iterable::begin):
        (JSC::B3::IndexSet::Iterable::end):
        (JSC::B3::IndexSet::values):
        (JSC::B3::IndexSet::indices):
        (JSC::B3::IndexSet::dump):
        * b3/B3InsertionSet.cpp: Added.
        (JSC::B3::InsertionSet::execute):
        * b3/B3InsertionSet.h: Added.
        (JSC::B3::InsertionSet::InsertionSet):
        (JSC::B3::InsertionSet::code):
        (JSC::B3::InsertionSet::appendInsertion):
        (JSC::B3::InsertionSet::insertValue):
        * b3/B3InsertionSetInlines.h: Added.
        (JSC::B3::InsertionSet::insert):
        * b3/B3LowerToAir.cpp: Added.
        (JSC::B3::Air::LowerToAir::LowerToAir):
        (JSC::B3::Air::LowerToAir::run):
        (JSC::B3::Air::LowerToAir::tmp):
        (JSC::B3::Air::LowerToAir::effectiveAddr):
        (JSC::B3::Air::LowerToAir::addr):
        (JSC::B3::Air::LowerToAir::loadAddr):
        (JSC::B3::Air::LowerToAir::imm):
        (JSC::B3::Air::LowerToAir::immOrTmp):
        (JSC::B3::Air::LowerToAir::appendBinOp):
        (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
        (JSC::B3::Air::LowerToAir::moveForType):
        (JSC::B3::Air::LowerToAir::relaxedMoveForType):
        (JSC::B3::Air::LowerToAir::append):
        (JSC::B3::Air::LowerToAir::AddressSelector::AddressSelector):
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptRoot):
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptRootLate):
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptInternals):
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptInternalsLate):
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptOperands):
        (JSC::B3::Air::LowerToAir::AddressSelector::acceptOperandsLate):
        (JSC::B3::Air::LowerToAir::AddressSelector::tryAddShift1):
        (JSC::B3::Air::LowerToAir::AddressSelector::tryAddShift2):
        (JSC::B3::Air::LowerToAir::AddressSelector::tryAdd):
        (JSC::B3::Air::LowerToAir::AddressSelector::tryDirect):
        (JSC::B3::Air::LowerToAir::acceptRoot):
        (JSC::B3::Air::LowerToAir::acceptRootLate):
        (JSC::B3::Air::LowerToAir::acceptInternals):
        (JSC::B3::Air::LowerToAir::acceptInternalsLate):
        (JSC::B3::Air::LowerToAir::acceptOperands):
        (JSC::B3::Air::LowerToAir::acceptOperandsLate):
        (JSC::B3::Air::LowerToAir::tryLoad):
        (JSC::B3::Air::LowerToAir::tryAdd):
        (JSC::B3::Air::LowerToAir::tryAnd):
        (JSC::B3::Air::LowerToAir::tryStoreAddLoad):
        (JSC::B3::Air::LowerToAir::tryStoreAndLoad):
        (JSC::B3::Air::LowerToAir::tryStore):
        (JSC::B3::Air::LowerToAir::tryTruncArgumentReg):
        (JSC::B3::Air::LowerToAir::tryTrunc):
        (JSC::B3::Air::LowerToAir::tryArgumentReg):
        (JSC::B3::Air::LowerToAir::tryConst32):
        (JSC::B3::Air::LowerToAir::tryConst64):
        (JSC::B3::Air::LowerToAir::tryIdentity):
        (JSC::B3::Air::LowerToAir::tryReturn):
        (JSC::B3::lowerToAir):
        * b3/B3LowerToAir.h: Added.
        * b3/B3LoweringMatcher.patterns: Added.
        * b3/B3MemoryValue.cpp: Added.
        (JSC::B3::MemoryValue::~MemoryValue):
        (JSC::B3::MemoryValue::dumpMeta):
        * b3/B3MemoryValue.h: Added.
        * b3/B3Opcode.cpp: Added.
        (WTF::printInternal):
        * b3/B3Opcode.h: Added.
        (JSC::B3::isCheckMath):
        * b3/B3Origin.cpp: Added.
        (JSC::B3::Origin::dump):
        * b3/B3Origin.h: Added.
        (JSC::B3::Origin::Origin):
        (JSC::B3::Origin::operator bool):
        (JSC::B3::Origin::data):
        * b3/B3PatchpointSpecial.cpp: Added.
        (JSC::B3::PatchpointSpecial::PatchpointSpecial):
        (JSC::B3::PatchpointSpecial::~PatchpointSpecial):
        (JSC::B3::PatchpointSpecial::forEachArg):
        (JSC::B3::PatchpointSpecial::isValid):
        (JSC::B3::PatchpointSpecial::admitsStack):
        (JSC::B3::PatchpointSpecial::generate):
        (JSC::B3::PatchpointSpecial::dumpImpl):
        (JSC::B3::PatchpointSpecial::deepDumpImpl):
        * b3/B3PatchpointSpecial.h: Added.
        * b3/B3PatchpointValue.cpp: Added.
        (JSC::B3::PatchpointValue::~PatchpointValue):
        (JSC::B3::PatchpointValue::dumpMeta):
        * b3/B3PatchpointValue.h: Added.
        (JSC::B3::PatchpointValue::accepts):
        (JSC::B3::PatchpointValue::PatchpointValue):
        * b3/B3PhaseScope.cpp: Added.
        (JSC::B3::PhaseScope::PhaseScope):
        (JSC::B3::PhaseScope::~PhaseScope):
        * b3/B3PhaseScope.h: Added.
        * b3/B3Procedure.cpp: Added.
        (JSC::B3::Procedure::Procedure):
        (JSC::B3::Procedure::~Procedure):
        (JSC::B3::Procedure::addBlock):
        (JSC::B3::Procedure::resetReachability):
        (JSC::B3::Procedure::dump):
        (JSC::B3::Procedure::blocksInPreOrder):
        (JSC::B3::Procedure::blocksInPostOrder):
        * b3/B3Procedure.h: Added.
        (JSC::B3::Procedure::size):
        (JSC::B3::Procedure::at):
        (JSC::B3::Procedure::operator[]):
        (JSC::B3::Procedure::iterator::iterator):
        (JSC::B3::Procedure::iterator::operator*):
        (JSC::B3::Procedure::iterator::operator++):
        (JSC::B3::Procedure::iterator::operator==):
        (JSC::B3::Procedure::iterator::operator!=):
        (JSC::B3::Procedure::iterator::findNext):
        (JSC::B3::Procedure::begin):
        (JSC::B3::Procedure::end):
        (JSC::B3::Procedure::ValuesCollection::ValuesCollection):
        (JSC::B3::Procedure::ValuesCollection::iterator::iterator):
        (JSC::B3::Procedure::ValuesCollection::iterator::operator*):
        (JSC::B3::Procedure::ValuesCollection::iterator::operator++):
        (JSC::B3::Procedure::ValuesCollection::iterator::operator==):
        (JSC::B3::Procedure::ValuesCollection::iterator::operator!=):
        (JSC::B3::Procedure::ValuesCollection::begin):
        (JSC::B3::Procedure::ValuesCollection::end):
        (JSC::B3::Procedure::ValuesCollection::size):
        (JSC::B3::Procedure::ValuesCollection::at):
        (JSC::B3::Procedure::ValuesCollection::operator[]):
        (JSC::B3::Procedure::values):
        (JSC::B3::Procedure::setLastPhaseName):
        (JSC::B3::Procedure::lastPhaseName):
        * b3/B3ProcedureInlines.h: Added.
        (JSC::B3::Procedure::add):
        * b3/B3ReduceStrength.cpp: Added.
        (JSC::B3::reduceStrength):
        * b3/B3ReduceStrength.h: Added.
        * b3/B3StackSlotKind.cpp: Added.
        (WTF::printInternal):
        * b3/B3StackSlotKind.h: Added.
        * b3/B3StackSlotValue.cpp: Added.
        (JSC::B3::StackSlotValue::~StackSlotValue):
        (JSC::B3::StackSlotValue::dumpMeta):
        * b3/B3StackSlotValue.h: Added.
        (JSC::B3::StackSlotValue::accepts):
        (JSC::B3::StackSlotValue::byteSize):
        (JSC::B3::StackSlotValue::kind):
        (JSC::B3::StackSlotValue::offsetFromFP):
        (JSC::B3::StackSlotValue::setOffsetFromFP):
        (JSC::B3::StackSlotValue::StackSlotValue):
        * b3/B3Stackmap.cpp: Added.
        (JSC::B3::Stackmap::Stackmap):
        (JSC::B3::Stackmap::~Stackmap):
        (JSC::B3::Stackmap::dump):
        * b3/B3Stackmap.h: Added.
        (JSC::B3::Stackmap::constrain):
        (JSC::B3::Stackmap::reps):
        (JSC::B3::Stackmap::clobber):
        (JSC::B3::Stackmap::clobbered):
        (JSC::B3::Stackmap::setGenerator):
        * b3/B3StackmapSpecial.cpp: Added.
        (JSC::B3::StackmapSpecial::StackmapSpecial):
        (JSC::B3::StackmapSpecial::~StackmapSpecial):
        (JSC::B3::StackmapSpecial::reportUsedRegisters):
        (JSC::B3::StackmapSpecial::extraClobberedRegs):
        (JSC::B3::StackmapSpecial::forEachArgImpl):
        (JSC::B3::StackmapSpecial::isValidImpl):
        (JSC::B3::StackmapSpecial::admitsStackImpl):
        (JSC::B3::StackmapSpecial::appendRepsImpl):
        (JSC::B3::StackmapSpecial::repForArg):
        * b3/B3StackmapSpecial.h: Added.
        * b3/B3SuccessorCollection.h: Added.
        (JSC::B3::SuccessorCollection::SuccessorCollection):
        (JSC::B3::SuccessorCollection::size):
        (JSC::B3::SuccessorCollection::at):
        (JSC::B3::SuccessorCollection::operator[]):
        (JSC::B3::SuccessorCollection::iterator::iterator):
        (JSC::B3::SuccessorCollection::iterator::operator*):
        (JSC::B3::SuccessorCollection::iterator::operator++):
        (JSC::B3::SuccessorCollection::iterator::operator==):
        (JSC::B3::SuccessorCollection::iterator::operator!=):
        (JSC::B3::SuccessorCollection::begin):
        (JSC::B3::SuccessorCollection::end):
        * b3/B3SwitchCase.cpp: Added.
        (JSC::B3::SwitchCase::dump):
        * b3/B3SwitchCase.h: Added.
        (JSC::B3::SwitchCase::SwitchCase):
        (JSC::B3::SwitchCase::operator bool):
        (JSC::B3::SwitchCase::caseValue):
        (JSC::B3::SwitchCase::target):
        (JSC::B3::SwitchCase::targetBlock):
        * b3/B3SwitchValue.cpp: Added.
        (JSC::B3::SwitchValue::~SwitchValue):
        (JSC::B3::SwitchValue::removeCase):
        (JSC::B3::SwitchValue::appendCase):
        (JSC::B3::SwitchValue::dumpMeta):
        (JSC::B3::SwitchValue::SwitchValue):
        * b3/B3SwitchValue.h: Added.
        (JSC::B3::SwitchValue::accepts):
        (JSC::B3::SwitchValue::numCaseValues):
        (JSC::B3::SwitchValue::caseValue):
        (JSC::B3::SwitchValue::caseValues):
        (JSC::B3::SwitchValue::fallThrough):
        (JSC::B3::SwitchValue::size):
        (JSC::B3::SwitchValue::at):
        (JSC::B3::SwitchValue::operator[]):
        (JSC::B3::SwitchValue::iterator::iterator):
        (JSC::B3::SwitchValue::iterator::operator*):
        (JSC::B3::SwitchValue::iterator::operator++):
        (JSC::B3::SwitchValue::iterator::operator==):
        (JSC::B3::SwitchValue::iterator::operator!=):
        (JSC::B3::SwitchValue::begin):
        (JSC::B3::SwitchValue::end):
        * b3/B3Type.cpp: Added.
        (WTF::printInternal):
        * b3/B3Type.h: Added.
        (JSC::B3::isInt):
        (JSC::B3::isFloat):
        (JSC::B3::pointerType):
        * b3/B3UpsilonValue.cpp: Added.
        (JSC::B3::UpsilonValue::~UpsilonValue):
        (JSC::B3::UpsilonValue::dumpMeta):
        * b3/B3UpsilonValue.h: Added.
        (JSC::B3::UpsilonValue::accepts):
        (JSC::B3::UpsilonValue::phi):
        (JSC::B3::UpsilonValue::UpsilonValue):
        * b3/B3UseCounts.cpp: Added.
        (JSC::B3::UseCounts::UseCounts):
        (JSC::B3::UseCounts::~UseCounts):
        * b3/B3UseCounts.h: Added.
        (JSC::B3::UseCounts::operator[]):
        * b3/B3Validate.cpp: Added.
        (JSC::B3::validate):
        * b3/B3Validate.h: Added.
        * b3/B3Value.cpp: Added.
        (JSC::B3::Value::~Value):
        (JSC::B3::Value::replaceWithIdentity):
        (JSC::B3::Value::replaceWithNop):
        (JSC::B3::Value::dump):
        (JSC::B3::Value::deepDump):
        (JSC::B3::Value::negConstant):
        (JSC::B3::Value::addConstant):
        (JSC::B3::Value::subConstant):
        (JSC::B3::Value::effects):
        (JSC::B3::Value::performSubstitution):
        (JSC::B3::Value::dumpMeta):
        (JSC::B3::Value::typeFor):
        * b3/B3Value.h: Added.
        (JSC::B3::DeepValueDump::DeepValueDump):
        (JSC::B3::DeepValueDump::dump):
        (JSC::B3::deepDump):
        * b3/B3ValueInlines.h: Added.
        (JSC::B3::Value::as):
        (JSC::B3::Value::isConstant):
        (JSC::B3::Value::hasInt32):
        (JSC::B3::Value::asInt32):
        (JSC::B3::Value::hasInt64):
        (JSC::B3::Value::asInt64):
        (JSC::B3::Value::hasInt):
        (JSC::B3::Value::asInt):
        (JSC::B3::Value::isInt):
        (JSC::B3::Value::hasIntPtr):
        (JSC::B3::Value::asIntPtr):
        (JSC::B3::Value::hasDouble):
        (JSC::B3::Value::asDouble):
        (JSC::B3::Value::stackmap):
        * b3/B3ValueRep.cpp: Added.
        (JSC::B3::ValueRep::dump):
        (WTF::printInternal):
        * b3/B3ValueRep.h: Added.
        (JSC::B3::ValueRep::ValueRep):
        (JSC::B3::ValueRep::reg):
        (JSC::B3::ValueRep::stack):
        (JSC::B3::ValueRep::stackArgument):
        (JSC::B3::ValueRep::constant):
        (JSC::B3::ValueRep::constantDouble):
        (JSC::B3::ValueRep::kind):
        (JSC::B3::ValueRep::operator bool):
        (JSC::B3::ValueRep::offsetFromFP):
        (JSC::B3::ValueRep::offsetFromSP):
        (JSC::B3::ValueRep::value):
        (JSC::B3::ValueRep::doubleValue):
        * b3/air: Added.
        * b3/air/AirAllocateStack.cpp: Added.
        (JSC::B3::Air::allocateStack):
        * b3/air/AirAllocateStack.h: Added.
        * b3/air/AirArg.cpp: Added.
        (JSC::B3::Air::Arg::dump):
        * b3/air/AirArg.h: Added.
        (JSC::B3::Air::Arg::isUse):
        (JSC::B3::Air::Arg::isDef):
        (JSC::B3::Air::Arg::typeForB3Type):
        (JSC::B3::Air::Arg::Arg):
        (JSC::B3::Air::Arg::imm):
        (JSC::B3::Air::Arg::imm64):
        (JSC::B3::Air::Arg::addr):
        (JSC::B3::Air::Arg::stack):
        (JSC::B3::Air::Arg::callArg):
        (JSC::B3::Air::Arg::isValidScale):
        (JSC::B3::Air::Arg::logScale):
        (JSC::B3::Air::Arg::index):
        (JSC::B3::Air::Arg::relCond):
        (JSC::B3::Air::Arg::resCond):
        (JSC::B3::Air::Arg::special):
        (JSC::B3::Air::Arg::operator==):
        (JSC::B3::Air::Arg::operator!=):
        (JSC::B3::Air::Arg::operator bool):
        (JSC::B3::Air::Arg::kind):
        (JSC::B3::Air::Arg::isTmp):
        (JSC::B3::Air::Arg::isImm):
        (JSC::B3::Air::Arg::isImm64):
        (JSC::B3::Air::Arg::isAddr):
        (JSC::B3::Air::Arg::isStack):
        (JSC::B3::Air::Arg::isCallArg):
        (JSC::B3::Air::Arg::isIndex):
        (JSC::B3::Air::Arg::isRelCond):
        (JSC::B3::Air::Arg::isResCond):
        (JSC::B3::Air::Arg::isSpecial):
        (JSC::B3::Air::Arg::isAlive):
        (JSC::B3::Air::Arg::tmp):
        (JSC::B3::Air::Arg::value):
        (JSC::B3::Air::Arg::pointerValue):
        (JSC::B3::Air::Arg::base):
        (JSC::B3::Air::Arg::hasOffset):
        (JSC::B3::Air::Arg::offset):
        (JSC::B3::Air::Arg::stackSlot):
        (JSC::B3::Air::Arg::scale):
        (JSC::B3::Air::Arg::isGPTmp):
        (JSC::B3::Air::Arg::isFPTmp):
        (JSC::B3::Air::Arg::isGP):
        (JSC::B3::Air::Arg::isFP):
        (JSC::B3::Air::Arg::hasType):
        (JSC::B3::Air::Arg::type):
        (JSC::B3::Air::Arg::isType):
        (JSC::B3::Air::Arg::isGPR):
        (JSC::B3::Air::Arg::gpr):
        (JSC::B3::Air::Arg::isFPR):
        (JSC::B3::Air::Arg::fpr):
        (JSC::B3::Air::Arg::isReg):
        (JSC::B3::Air::Arg::reg):
        (JSC::B3::Air::Arg::gpTmpIndex):
        (JSC::B3::Air::Arg::fpTmpIndex):
        (JSC::B3::Air::Arg::tmpIndex):
        (JSC::B3::Air::Arg::withOffset):
        (JSC::B3::Air::Arg::forEachTmpFast):
        (JSC::B3::Air::Arg::forEachTmp):
        (JSC::B3::Air::Arg::asTrustedImm32):
        (JSC::B3::Air::Arg::asTrustedImm64):
        (JSC::B3::Air::Arg::asTrustedImmPtr):
        (JSC::B3::Air::Arg::asAddress):
        (JSC::B3::Air::Arg::asBaseIndex):
        (JSC::B3::Air::Arg::asRelationalCondition):
        (JSC::B3::Air::Arg::asResultCondition):
        (JSC::B3::Air::Arg::isHashTableDeletedValue):
        (JSC::B3::Air::Arg::hash):
        (JSC::B3::Air::ArgHash::hash):
        (JSC::B3::Air::ArgHash::equal):
        * b3/air/AirBasicBlock.cpp: Added.
        (JSC::B3::Air::BasicBlock::addPredecessor):
        (JSC::B3::Air::BasicBlock::removePredecessor):
        (JSC::B3::Air::BasicBlock::replacePredecessor):
        (JSC::B3::Air::BasicBlock::dump):
        (JSC::B3::Air::BasicBlock::deepDump):
        (JSC::B3::Air::BasicBlock::BasicBlock):
        * b3/air/AirBasicBlock.h: Added.
        (JSC::B3::Air::BasicBlock::index):
        (JSC::B3::Air::BasicBlock::size):
        (JSC::B3::Air::BasicBlock::begin):
        (JSC::B3::Air::BasicBlock::end):
        (JSC::B3::Air::BasicBlock::at):
        (JSC::B3::Air::BasicBlock::last):
        (JSC::B3::Air::BasicBlock::appendInst):
        (JSC::B3::Air::BasicBlock::append):
        (JSC::B3::Air::BasicBlock::numSuccessors):
        (JSC::B3::Air::BasicBlock::successor):
        (JSC::B3::Air::BasicBlock::successors):
        (JSC::B3::Air::BasicBlock::successorBlock):
        (JSC::B3::Air::BasicBlock::successorBlocks):
        (JSC::B3::Air::BasicBlock::numPredecessors):
        (JSC::B3::Air::BasicBlock::predecessor):
        (JSC::B3::Air::BasicBlock::predecessors):
        (JSC::B3::Air::DeepBasicBlockDump::DeepBasicBlockDump):
        (JSC::B3::Air::DeepBasicBlockDump::dump):
        (JSC::B3::Air::deepDump):
        * b3/air/AirCCallSpecial.cpp: Added.
        (JSC::B3::Air::CCallSpecial::CCallSpecial):
        (JSC::B3::Air::CCallSpecial::~CCallSpecial):
        (JSC::B3::Air::CCallSpecial::forEachArg):
        (JSC::B3::Air::CCallSpecial::isValid):
        (JSC::B3::Air::CCallSpecial::admitsStack):
        (JSC::B3::Air::CCallSpecial::reportUsedRegisters):
        (JSC::B3::Air::CCallSpecial::generate):
        (JSC::B3::Air::CCallSpecial::extraClobberedRegs):
        (JSC::B3::Air::CCallSpecial::dumpImpl):
        (JSC::B3::Air::CCallSpecial::deepDumpImpl):
        * b3/air/AirCCallSpecial.h: Added.
        * b3/air/AirCode.cpp: Added.
        (JSC::B3::Air::Code::Code):
        (JSC::B3::Air::Code::~Code):
        (JSC::B3::Air::Code::addBlock):
        (JSC::B3::Air::Code::addStackSlot):
        (JSC::B3::Air::Code::addSpecial):
        (JSC::B3::Air::Code::cCallSpecial):
        (JSC::B3::Air::Code::resetReachability):
        (JSC::B3::Air::Code::dump):
        (JSC::B3::Air::Code::findFirstBlockIndex):
        (JSC::B3::Air::Code::findNextBlockIndex):
        (JSC::B3::Air::Code::findNextBlock):
        * b3/air/AirCode.h: Added.
        (JSC::B3::Air::Code::newTmp):
        (JSC::B3::Air::Code::numTmps):
        (JSC::B3::Air::Code::callArgAreaSize):
        (JSC::B3::Air::Code::requestCallArgAreaSize):
        (JSC::B3::Air::Code::frameSize):
        (JSC::B3::Air::Code::setFrameSize):
        (JSC::B3::Air::Code::calleeSaveRegisters):
        (JSC::B3::Air::Code::size):
        (JSC::B3::Air::Code::at):
        (JSC::B3::Air::Code::operator[]):
        (JSC::B3::Air::Code::iterator::iterator):
        (JSC::B3::Air::Code::iterator::operator*):
        (JSC::B3::Air::Code::iterator::operator++):
        (JSC::B3::Air::Code::iterator::operator==):
        (JSC::B3::Air::Code::iterator::operator!=):
        (JSC::B3::Air::Code::begin):
        (JSC::B3::Air::Code::end):
        (JSC::B3::Air::Code::StackSlotsCollection::StackSlotsCollection):
        (JSC::B3::Air::Code::StackSlotsCollection::size):
        (JSC::B3::Air::Code::StackSlotsCollection::at):
        (JSC::B3::Air::Code::StackSlotsCollection::operator[]):
        (JSC::B3::Air::Code::StackSlotsCollection::iterator::iterator):
        (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator*):
        (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator++):
        (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator==):
        (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator!=):
        (JSC::B3::Air::Code::StackSlotsCollection::begin):
        (JSC::B3::Air::Code::StackSlotsCollection::end):
        (JSC::B3::Air::Code::stackSlots):
        (JSC::B3::Air::Code::SpecialsCollection::SpecialsCollection):
        (JSC::B3::Air::Code::SpecialsCollection::size):
        (JSC::B3::Air::Code::SpecialsCollection::at):
        (JSC::B3::Air::Code::SpecialsCollection::operator[]):
        (JSC::B3::Air::Code::SpecialsCollection::iterator::iterator):
        (JSC::B3::Air::Code::SpecialsCollection::iterator::operator*):
        (JSC::B3::Air::Code::SpecialsCollection::iterator::operator++):
        (JSC::B3::Air::Code::SpecialsCollection::iterator::operator==):
        (JSC::B3::Air::Code::SpecialsCollection::iterator::operator!=):
        (JSC::B3::Air::Code::SpecialsCollection::begin):
        (JSC::B3::Air::Code::SpecialsCollection::end):
        (JSC::B3::Air::Code::specials):
        (JSC::B3::Air::Code::setLastPhaseName):
        (JSC::B3::Air::Code::lastPhaseName):
        * b3/air/AirFrequentedBlock.h: Added.
        * b3/air/AirGenerate.cpp: Added.
        (JSC::B3::Air::generate):
        * b3/air/AirGenerate.h: Added.
        * b3/air/AirGenerated.cpp: Added.
        * b3/air/AirGenerationContext.h: Added.
        * b3/air/AirHandleCalleeSaves.cpp: Added.
        (JSC::B3::Air::handleCalleeSaves):
        * b3/air/AirHandleCalleeSaves.h: Added.
        * b3/air/AirInsertionSet.cpp: Added.
        (JSC::B3::Air::InsertionSet::execute):
        * b3/air/AirInsertionSet.h: Added.
        (JSC::B3::Air::InsertionSet::InsertionSet):
        (JSC::B3::Air::InsertionSet::code):
        (JSC::B3::Air::InsertionSet::appendInsertion):
        (JSC::B3::Air::InsertionSet::insertInst):
        (JSC::B3::Air::InsertionSet::insert):
        * b3/air/AirInst.cpp: Added.
        (JSC::B3::Air::Inst::dump):
        * b3/air/AirInst.h: Added.
        (JSC::B3::Air::Inst::Inst):
        (JSC::B3::Air::Inst::opcode):
        (JSC::B3::Air::Inst::forEachTmpFast):
        (JSC::B3::Air::Inst::forEachTmp):
        * b3/air/AirInstInlines.h: Added.
        (JSC::B3::Air::ForEach<Tmp>::forEach):
        (JSC::B3::Air::ForEach<Arg>::forEach):
        (JSC::B3::Air::Inst::forEach):
        (JSC::B3::Air::Inst::hasSpecial):
        (JSC::B3::Air::Inst::extraClobberedRegs):
        (JSC::B3::Air::Inst::reportUsedRegisters):
        (JSC::B3::Air::isShiftValid):
        (JSC::B3::Air::isLshift32Valid):
        * b3/air/AirLiveness.h: Added.
        (JSC::B3::Air::Liveness::Liveness):
        (JSC::B3::Air::Liveness::liveAtHead):
        (JSC::B3::Air::Liveness::liveAtTail):
        (JSC::B3::Air::Liveness::LocalCalc::LocalCalc):
        (JSC::B3::Air::Liveness::LocalCalc::live):
        (JSC::B3::Air::Liveness::LocalCalc::takeLive):
        (JSC::B3::Air::Liveness::LocalCalc::execute):
        * b3/air/AirOpcode.opcodes: Added.
        * b3/air/AirPhaseScope.cpp: Added.
        (JSC::B3::Air::PhaseScope::PhaseScope):
        (JSC::B3::Air::PhaseScope::~PhaseScope):
        * b3/air/AirPhaseScope.h: Added.
        * b3/air/AirRegisterPriority.cpp: Added.
        (JSC::B3::Air::gprsInPriorityOrder):
        (JSC::B3::Air::fprsInPriorityOrder):
        (JSC::B3::Air::regsInPriorityOrder):
        * b3/air/AirRegisterPriority.h: Added.
        (JSC::B3::Air::RegistersInPriorityOrder<GPRInfo>::inPriorityOrder):
        (JSC::B3::Air::RegistersInPriorityOrder<FPRInfo>::inPriorityOrder):
        (JSC::B3::Air::regsInPriorityOrder):
        * b3/air/AirSpecial.cpp: Added.
        (JSC::B3::Air::Special::Special):
        (JSC::B3::Air::Special::~Special):
        (JSC::B3::Air::Special::name):
        (JSC::B3::Air::Special::dump):
        (JSC::B3::Air::Special::deepDump):
        * b3/air/AirSpecial.h: Added.
        (JSC::B3::Air::DeepSpecialDump::DeepSpecialDump):
        (JSC::B3::Air::DeepSpecialDump::dump):
        (JSC::B3::Air::deepDump):
        * b3/air/AirSpillEverything.cpp: Added.
        (JSC::B3::Air::spillEverything):
        * b3/air/AirSpillEverything.h: Added.
        * b3/air/AirStackSlot.cpp: Added.
        (JSC::B3::Air::StackSlot::setOffsetFromFP):
        (JSC::B3::Air::StackSlot::dump):
        (JSC::B3::Air::StackSlot::deepDump):
        (JSC::B3::Air::StackSlot::StackSlot):
        * b3/air/AirStackSlot.h: Added.
        (JSC::B3::Air::StackSlot::byteSize):
        (JSC::B3::Air::StackSlot::kind):
        (JSC::B3::Air::StackSlot::index):
        (JSC::B3::Air::StackSlot::alignment):
        (JSC::B3::Air::StackSlot::value):
        (JSC::B3::Air::StackSlot::offsetFromFP):
        (JSC::B3::Air::DeepStackSlotDump::DeepStackSlotDump):
        (JSC::B3::Air::DeepStackSlotDump::dump):
        (JSC::B3::Air::deepDump):
        * b3/air/AirTmp.cpp: Added.
        (JSC::B3::Air::Tmp::dump):
        * b3/air/AirTmp.h: Added.
        (JSC::B3::Air::Tmp::Tmp):
        (JSC::B3::Air::Tmp::gpTmpForIndex):
        (JSC::B3::Air::Tmp::fpTmpForIndex):
        (JSC::B3::Air::Tmp::operator bool):
        (JSC::B3::Air::Tmp::isGP):
        (JSC::B3::Air::Tmp::isFP):
        (JSC::B3::Air::Tmp::isGPR):
        (JSC::B3::Air::Tmp::isFPR):
        (JSC::B3::Air::Tmp::isReg):
        (JSC::B3::Air::Tmp::gpr):
        (JSC::B3::Air::Tmp::fpr):
        (JSC::B3::Air::Tmp::reg):
        (JSC::B3::Air::Tmp::hasTmpIndex):
        (JSC::B3::Air::Tmp::gpTmpIndex):
        (JSC::B3::Air::Tmp::fpTmpIndex):
        (JSC::B3::Air::Tmp::tmpIndex):
        (JSC::B3::Air::Tmp::isAlive):
        (JSC::B3::Air::Tmp::operator==):
        (JSC::B3::Air::Tmp::operator!=):
        (JSC::B3::Air::Tmp::isHashTableDeletedValue):
        (JSC::B3::Air::Tmp::hash):
        (JSC::B3::Air::Tmp::encodeGP):
        (JSC::B3::Air::Tmp::encodeFP):
        (JSC::B3::Air::Tmp::encodeGPR):
        (JSC::B3::Air::Tmp::encodeFPR):
        (JSC::B3::Air::Tmp::encodeGPTmp):
        (JSC::B3::Air::Tmp::encodeFPTmp):
        (JSC::B3::Air::Tmp::isEncodedGP):
        (JSC::B3::Air::Tmp::isEncodedFP):
        (JSC::B3::Air::Tmp::isEncodedGPR):
        (JSC::B3::Air::Tmp::isEncodedFPR):
        (JSC::B3::Air::Tmp::isEncodedGPTmp):
        (JSC::B3::Air::Tmp::isEncodedFPTmp):
        (JSC::B3::Air::Tmp::decodeGPR):
        (JSC::B3::Air::Tmp::decodeFPR):
        (JSC::B3::Air::Tmp::decodeGPTmp):
        (JSC::B3::Air::Tmp::decodeFPTmp):
        (JSC::B3::Air::TmpHash::hash):
        (JSC::B3::Air::TmpHash::equal):
        * b3/air/AirTmpInlines.h: Added.
        (JSC::B3::Air::Tmp::Tmp):
        * b3/air/AirValidate.cpp: Added.
        (JSC::B3::Air::validate):
        * b3/air/AirValidate.h: Added.
        * b3/air/opcode_generator.rb: Added.
        * b3/generate_pattern_matcher.rb: Added.
        * b3/testb3.cpp: Added.
        (JSC::B3::compileAndRun):
        (JSC::B3::test42):
        (JSC::B3::testLoad42):
        (JSC::B3::testArg):
        (JSC::B3::testAddArgs):
        (JSC::B3::testAddArgs32):
        (JSC::B3::testStore):
        (JSC::B3::testTrunc):
        (JSC::B3::testAdd1):
        (JSC::B3::testStoreAddLoad):
        (JSC::B3::testStoreAddAndLoad):
        (JSC::B3::testAdd1Uncommuted):
        (JSC::B3::testLoadOffset):
        (JSC::B3::testLoadOffsetNotConstant):
        (JSC::B3::testLoadOffsetUsingAdd):
        (JSC::B3::testLoadOffsetUsingAddNotConstant):
        (JSC::B3::run):
        (run):
        (main):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::specializationKind):
        * jit/Reg.h:
        (JSC::Reg::index):
        (JSC::Reg::isSet):
        (JSC::Reg::operator bool):
        (JSC::Reg::isHashTableDeletedValue):
        (JSC::Reg::AllRegsIterable::iterator::iterator):
        (JSC::Reg::AllRegsIterable::iterator::operator*):
        (JSC::Reg::AllRegsIterable::iterator::operator++):
        (JSC::Reg::AllRegsIterable::iterator::operator==):
        (JSC::Reg::AllRegsIterable::iterator::operator!=):
        (JSC::Reg::AllRegsIterable::begin):
        (JSC::Reg::AllRegsIterable::end):
        (JSC::Reg::all):
        (JSC::Reg::invalid):
        (JSC::Reg::operator!): Deleted.
        * jit/RegisterAtOffsetList.cpp:
        (JSC::RegisterAtOffsetList::RegisterAtOffsetList):
        * jit/RegisterAtOffsetList.h:
        (JSC::RegisterAtOffsetList::clear):
        (JSC::RegisterAtOffsetList::size):
        (JSC::RegisterAtOffsetList::begin):
        (JSC::RegisterAtOffsetList::end):
        * jit/RegisterSet.h:
        (JSC::RegisterSet::operator==):
        (JSC::RegisterSet::hash):
        (JSC::RegisterSet::forEach):
        (JSC::RegisterSet::setAny):

2015-10-28  Mark Lam  <mark.lam@apple.com>

        Rename MacroAssembler::callProbe() to probe().
        https://bugs.webkit.org/show_bug.cgi?id=150641

        Reviewed by Saam Barati.

        To do this, I needed to disambiguate between the low-level probe() from the
        high-level version that takes a std::function.  I did this by changing the low-
        level version to not take default args anymore.

        * assembler/AbstractMacroAssembler.h:
        * assembler/MacroAssembler.cpp:
        (JSC::stdFunctionCallback):
        (JSC::MacroAssembler::probe):
        (JSC::MacroAssembler::callProbe): Deleted.
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::urshift32):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::repatchCall):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::repatchCall):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::repatchCall):
        * assembler/MacroAssemblerPrinter.h:
        (JSC::MacroAssemblerPrinter::print):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::maxJumpReplacementSize):

2015-10-28  Timothy Hatcher  <timothy@apple.com>

        Web Inspector: jsmin.py mistakenly removes whitespace from template literal strings
        https://bugs.webkit.org/show_bug.cgi?id=148728

        Reviewed by Joseph Pecoraro.

        * Scripts/jsmin.py:
        (JavascriptMinify.minify): Make backtick a quoting character.

2015-10-28  Brian Burg  <bburg@apple.com>

        Builtins generator should emit ENABLE(FEATURE) guards based on @conditional annotation
        https://bugs.webkit.org/show_bug.cgi?id=150536

        Reviewed by Yusuke Suzuki.

        Scan JS builtin files for @key=value and @flag annotations in single-line comments.
        For @conditional=CONDITIONAL, emit CONDITIONAL guards around the relevant object's code.

        Generate primary header includes separately from secondary header includes so we can
        put the guard between the two header groups, as is customary in WebKit C++ code.

        New tests:

        Scripts/tests/builtins/WebCore-ArbitraryConditionalGuard-Separate.js
        Scripts/tests/builtins/WebCore-DuplicateFlagAnnotation-Separate.js
        Scripts/tests/builtins/WebCore-DuplicateKeyValueAnnotation-Separate.js

        * Scripts/builtins/builtins_generate_combined_implementation.py:
        (BuiltinsCombinedImplementationGenerator.generate_output):
        (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
        (BuiltinsCombinedImplementationGenerator.generate_header_includes): Deleted.
        * Scripts/builtins/builtins_generate_separate_header.py:
        (BuiltinsSeparateHeaderGenerator.generate_output):
        (generate_secondary_header_includes):
        (generate_header_includes): Deleted.
        * Scripts/builtins/builtins_generate_separate_implementation.py:
        (BuiltinsSeparateImplementationGenerator.generate_output):
        (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
        (BuiltinsSeparateImplementationGenerator.generate_header_includes): Deleted.
        * Scripts/builtins/builtins_generate_separate_wrapper.py:
        (BuiltinsSeparateWrapperGenerator.generate_output):
        (BuiltinsSeparateWrapperGenerator.generate_secondary_header_includes):
        (BuiltinsSeparateWrapperGenerator.generate_header_includes): Deleted.
        * Scripts/builtins/builtins_generator.py:
        (BuiltinsGenerator.generate_includes_from_entries):
        (BuiltinsGenerator):
        (BuiltinsGenerator.generate_primary_header_includes):
        * Scripts/builtins/builtins_model.py:
        (BuiltinObject.__init__):
        (BuiltinsCollection.parse_builtins_file):
        (BuiltinsCollection._parse_annotations):
        * Scripts/tests/builtins/WebCore-ArbitraryConditionalGuard-Separate.js: Added.
        * Scripts/tests/builtins/WebCore-DuplicateFlagAnnotation-Separate.js: Added.
        * Scripts/tests/builtins/WebCore-DuplicateKeyValueAnnotation-Separate.js: Added.
        * Scripts/tests/builtins/WebCore-GuardedBuiltin-Separate.js: Simplify.
        * Scripts/tests/builtins/WebCore-GuardedInternalBuiltin-Separate.js: Simplify.
        * Scripts/tests/builtins/WebCore-UnguardedBuiltin-Separate.js: Simplify.
        * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Added.
        * Scripts/tests/builtins/expected/WebCore-DuplicateFlagAnnotation-Separate.js-error: Added.
        * Scripts/tests/builtins/expected/WebCore-DuplicateKeyValueAnnotation-Separate.js-error: Added.
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:

2015-10-28  Mark Lam  <mark.lam@apple.com>

        Update FTL to support UntypedUse operands for op_sub.
        https://bugs.webkit.org/show_bug.cgi?id=150562

        Reviewed by Geoffrey Garen.

        * assembler/MacroAssemblerARM64.h:
        - make the dataTempRegister and memoryTempRegister public so that we can
          move input registers out of them if needed.

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        - We can now compile ArithSub.

        * ftl/FTLCompile.cpp:
        - Added BinaryArithGenerationContext to shuffle registers into a state that is
          expected by the baseline snippet generator.  This includes:
          1. Making sure that the input and output registers are not in the tag or
             scratch registers.
          2. Loading the tag registers with expected values.
          3. Restoring the registers to their original value on return.
        - Added code to implement the ArithSub inline cache.

        * ftl/FTLInlineCacheDescriptor.h:
        (JSC::FTL::ArithSubDescriptor::ArithSubDescriptor):
        (JSC::FTL::ArithSubDescriptor::leftType):
        (JSC::FTL::ArithSubDescriptor::rightType):

        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfArithSub):
        * ftl/FTLInlineCacheSize.h:

        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        - Added handling for UnusedType for the ArithSub case.

        * ftl/FTLState.h:
        * jit/GPRInfo.h:
        (JSC::GPRInfo::reservedRegisters):

        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::generateFastPath):
        - When the result is in the same as one of the input registers, we'll end up
          corrupting the input in fast path even if we determine that we need to go to
          the slow path.  We now move the input into the scratch register and operate
          on that instead and only move the result into the result register only after
          the fast path has succeeded.

        * tests/stress/op_sub.js:
        (o1.valueOf):
        (runTest):
        - Added some debugging tools: flags for verbose logging, and eager abort on fail.

2015-10-28  Mark Lam  <mark.lam@apple.com>

        Fix a typo in ProbeContext::fpr().
        https://bugs.webkit.org/show_bug.cgi?id=150629

        Reviewed by Yusuke Suzuki.

        ProbeContext::fpr() should be calling CPUState::fpr(), not CPUState::gpr().

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::ProbeContext::fpr):

2015-10-28  Mark Lam  <mark.lam@apple.com>

        Add ability to print the PC register from JIT'ed code.
        https://bugs.webkit.org/show_bug.cgi?id=150561

        Reviewed by Geoffrey Garen.

        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::printPC):
        (JSC::MacroAssemblerPrinter::printCallback):
        * assembler/MacroAssemblerPrinter.h:
        (JSC::MacroAssemblerPrinter::PrintArg::PrintArg):

2015-10-27  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove Timeline MarkDOMContent and MarkLoad, data is already available
        https://bugs.webkit.org/show_bug.cgi?id=150615

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Timeline.json:

2015-10-27  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused / duplicated XHR timeline instrumentation
        https://bugs.webkit.org/show_bug.cgi?id=150605

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Timeline.json:

2015-10-27  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r191360): Crash: com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::FTL:: + 386
        https://bugs.webkit.org/show_bug.cgi?id=150580

        Reviewed by Mark Lam.

        Changed code to box 32 bit integers and booleans arguments when generating the call instead of boxing
        them in the shuffler.

        The ASSERT in CallFrameShuffler::extendFrameIfNeeded is wrong when called from CallFrameShuffler::spill(),
        as we could be making space to spill a register so that we have a spare that we can use for the new
        frame's base pointer.

        * ftl/FTLJSTailCall.cpp:
        (JSC::FTL::DFG::recoveryFor): Added RELEASE_ASSERT to check that we never see unboxed 32 bit
        arguments stored in the stack.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForTailCall):
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::extendFrameIfNeeded): Removed unneeded ASSERT.

2015-10-26  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Add DFG/FTL support for accessor put operations
        https://bugs.webkit.org/show_bug.cgi?id=148860

        Reviewed by Geoffrey Garen.

        This patch introduces accessor defining ops into DFG and FTL.
        The following DFG nodes are introduced.

            op_put_getter_by_id  => PutGetterById
            op_put_setter_by_id  => PutSetterById
            op_put_getter_setter => PutGetterSetterById
            op_put_getter_by_val => PutGetterByVal
            op_put_setter_by_val => PutSetterByVal

        These DFG nodes just call operations. But it does not prevent compiling in DFG/FTL.

        To use operations defined for baseline JIT, we clean up existing operations.
        And reuse these operations in DFG and FTL.

        * 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/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        (JSC::DFG::Node::hasAccessorAttributes):
        (JSC::DFG::Node::accessorAttributes):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePutAccessorById):
        (JSC::DFG::SpeculativeJIT::compilePutGetterSetterById):
        (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
        We should fill all GPRs before calling flushRegisters().
        * 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/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutGetterSetterById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorByVal):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_getter_by_id):
        (JSC::JIT::emit_op_put_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_getter_by_id):
        (JSC::JIT::emit_op_put_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter):
        * tests/stress/dfg-put-accessors-by-id-class.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.Cocoa.prototype.get hello):
        (getter.Cocoa):
        (getter):
        (setter.Cocoa):
        (setter.Cocoa.prototype.set hello):
        (setter):
        (accessors.Cocoa):
        (accessors.Cocoa.prototype.get hello):
        (accessors.Cocoa.prototype.set hello):
        (accessors):
        * tests/stress/dfg-put-accessors-by-id.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.object.get hello):
        (getter):
        (setter.object.set hello):
        (setter):
        (accessors.object.get hello):
        (accessors.object.set hello):
        (accessors):
        * tests/stress/dfg-put-getter-by-id-class.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.Cocoa):
        (getter.Cocoa.prototype.get hello):
        (getter.Cocoa.prototype.get name):
        (getter):
        * tests/stress/dfg-put-getter-by-id.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.object.get hello):
        (getter):
        * tests/stress/dfg-put-getter-by-val-class.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.Cocoa):
        (getter.Cocoa.prototype.get name):
        (getter):
        * tests/stress/dfg-put-getter-by-val.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.object.get name):
        (getter):
        * tests/stress/dfg-put-setter-by-id-class.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.Cocoa):
        (getter.Cocoa.prototype.set hello):
        (getter.Cocoa.prototype.get name):
        (getter):
        * tests/stress/dfg-put-setter-by-id.js: Added.
        (shouldBe):
        (testAttribute):
        (setter.object.set hello):
        (setter):
        * tests/stress/dfg-put-setter-by-val-class.js: Added.
        (shouldBe):
        (testAttribute):
        (setter.Cocoa):
        (setter.Cocoa.prototype.set name):
        (setter):
        * tests/stress/dfg-put-setter-by-val.js: Added.
        (shouldBe):
        (testAttribute):
        (setter.object.set name):
        (setter):

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

        Add logging to warn about under-estimated FTL inline cache sizes.
        https://bugs.webkit.org/show_bug.cgi?id=150570

        Reviewed by Geoffrey Garen.

        Added 2 options:
        1. JSC_dumpFailedICSizing - dumps an error message if the FTL encounters IC size
           estimates that are less than the actual needed code size.

           This option is useful for when we add a new IC and want to compute an
           estimated size for the IC.  To do this:
           1. Build jsc for the target port with a very small IC size (enough to
              store the jump instruction needed for the out of line fallback
              implementation).
           2. Implement a test suite with scenarios that exercise all the code paths in
              the IC generator.
           3. Run jsc with JSC_dumpFailedICSizing=true on the test suite.
           4. The max value reported by the dumps will be the worst case size needed to
              store the IC.  We should use this value for our estimate.
           5. Update the IC's estimated size and rebuild jsc.
           6. Re-run (3) and confirm that there are no more error messages about the
              IC sizing.

        2. JSC_assertICSizing - same as JSC_dumpFailedICSizing except that it also
           crashes the VM each time it encounters an inadequate IC size estimate.

           This option is useful for regression testing to ensure that our estimates
           do not regress.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::generateInlineIfPossibleOutOfLineIfNot):
        * runtime/Options.h:

2015-10-26  Saam barati  <sbarati@apple.com>

        r190735 Caused us to maybe trample the base's tag-GPR on 32-bit inline cache when the cache allocates a scratch register and then jumps to the slow path
        https://bugs.webkit.org/show_bug.cgi?id=150532

        Reviewed by Geoffrey Garen.

        The base's tag register used to show up in the used register set
        before r190735 because of how the DFG kept track of used register. I changed this 
        in my work on inline caching because we don't want to spill these registers
        when we have a GetByIdFlush/PutByIdFlush and we use the used register set
        as the metric of what to spill. That said, these registers should be locked
        and not used as scratch registers by the scratch register allocator. The
        reason is that our inline cache may fail and jump to the slow path. The slow
        path then uses the base's tag register. If the inline cache used the base's tag
        register as a scratch and the inline cache fails and jumps to the slow path, we
        have a problem because the tag may now be trampled.

        Note that this doesn't mean that we can't trample the base's tag register when making
        a call. We can totally trample the register as long as the inline cache succeeds in a GetByIdFlush/PutByIdFlush.
        The problem is only when we trample it and then jump to the slow path.

        This patch fixes this bug by making StructureStubInfo keep track of the base's
        tag GPR. PolymorphicAccess then locks this register when using the ScratchRegisterAllocator.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/StructureStubInfo.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIn):
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITByIdGenerator::JITByIdGenerator):
        * tests/stress/regress-150532.js: Added.
        (assert):
        (randomFunction):
        (foo):
        (i.switch):

2015-10-24  Brian Burg  <bburg@apple.com>

        Teach create_hash_table to omit builtins macros when generating tables for native-only objects
        https://bugs.webkit.org/show_bug.cgi?id=150491

        Reviewed by Yusuke Suzuki.

        In order to support separate compilation for generated builtins files, we need to be able to
        include specific builtins headers from generated .lut.h files. However, the create_hash_table
        script isn't smart enough to figure out when a generated file might actually contain a builtin.
        Without further help, we'd have to include an all-in-one header, mostly defeating the point of
        generating separate .h and .cpp files for every builtin.

        This patch segregates the pure native and partially builtin sources in the build system, and
        gives hints to create_hash_table so that it doesn't even generate checks for builtins if the
        input file has no builtin method implementations. Also do some modernization and code cleanup.

        * CMakeLists.txt:

        Generate each group with different flags to create_hash_table. Change the macro to take
        flags through the variable LUT_GENERATOR_FLAGS. Set this as necessary before calling macro.
        Add an additional hint to CMake that the .cpp source file depends on the generated file.

        * DerivedSources.make:

        Generate each group with different flags to create_hash_table. Clean up the 'all' target
        so that static dependencies are listed first. Use static patterns to decide which .lut.h
        files require which flags. Reduce fragile usages of implicit variables.

        * JavaScriptCore.xcodeproj/project.pbxproj:

        Add some missing .lut.h files to the Derived Sources group. Sort the project.

        * create_hash_table:

        Parse options in a sane way using GetOpt::Long. Remove ability to specify a custom namespace
        since this isn't actually used anywhere. Normalize placement of newlines in quoted strings.
        Only generate builtins macros and includes if the source file is known to have some builtins.

2015-10-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused ScrollLayer Timeline EventType
        https://bugs.webkit.org/show_bug.cgi?id=150518

        Reviewed by Timothy Hatcher.

        * inspector/protocol/Timeline.json:

2015-10-23  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Clean up InspectorInstrumentation includes
        https://bugs.webkit.org/show_bug.cgi?id=150523

        Reviewed by Timothy Hatcher.

        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::consoleMessageArgumentCounts): Deleted.
        * inspector/agents/InspectorConsoleAgent.h:

2015-10-23  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r179357-r179359): WebContent Crash using AOL Mail @ com.apple.JavascriptCore JSC::linkPolymorphicCall(JSC::ExecState*, JSC::CallLinkInfo&, JSC::CallVariant, JSC::RegisterPreservationMode) + 1584
        https://bugs.webkit.org/show_bug.cgi?id=150513

        Reviewed by Saam Barati.

        Add check in linkPolymorphicCall() to make sure we have a CodeBlock for the newly added variant.
        If not, we turn the call into a virtual call.

        The bug was caused by a stack overflow when preparing the function for execution.  This properly
        threw an exception, however linkPolymorphicCall() didn't check for this error case.

        Added a new test function "failNextNewCodeBlock()" to test tools to simplify the testing.

        * API/JSCTestRunnerUtils.cpp:
        (JSC::failNextNewCodeBlock):
        (JSC::numberOfDFGCompiles):
        * API/JSCTestRunnerUtils.h:
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionTransferArrayBuffer):
        (functionFailNextNewCodeBlock):
        (functionQuit):
        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::prepareForExecutionImpl):
        * runtime/TestRunnerUtils.cpp:
        (JSC::optimizeNextInvocation):
        (JSC::failNextNewCodeBlock):
        (JSC::numberOfDFGCompiles):
        * runtime/TestRunnerUtils.h:
        * runtime/VM.h:
        (JSC::VM::setFailNextNewCodeBlock):
        (JSC::VM::getAndClearFailNextNewCodeBlock):
        (JSC::VM::stackPointerAtVMEntry):

2015-10-23  Commit Queue  <commit-queue@webkit.org>

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

        Broke two JSC regression tests (Requested by msaboff on
        #webkit).

        Reverted changeset:

        "[ES6] Add DFG/FTL support for accessor put operations"
        https://bugs.webkit.org/show_bug.cgi?id=148860
        http://trac.webkit.org/changeset/191500

2015-10-23  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Add DFG/FTL support for accessor put operations
        https://bugs.webkit.org/show_bug.cgi?id=148860

        Reviewed by Geoffrey Garen.

        This patch introduces accessor defining ops into DFG and FTL.
        The following DFG nodes are introduced.

            op_put_getter_by_id  => PutGetterById
            op_put_setter_by_id  => PutSetterById
            op_put_getter_setter => PutGetterSetterById
            op_put_getter_by_val => PutGetterByVal
            op_put_setter_by_val => PutSetterByVal

        These DFG nodes just call operations. But it does not prevent compiling in DFG/FTL.

        To use operations defined for baseline JIT, we clean up existing operations.
        And reuse these operations in DFG and FTL.

        * 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/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
        (JSC::DFG::Node::hasAccessorAttributes):
        (JSC::DFG::Node::accessorAttributes):
        * dfg/DFGNodeType.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePutAccessorById):
        (JSC::DFG::SpeculativeJIT::compilePutGetterSetterById):
        (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
        * 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/FTLIntrinsicRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutGetterSetterById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutAccessorByVal):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_getter_by_id):
        (JSC::JIT::emit_op_put_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_getter_by_id):
        (JSC::JIT::emit_op_put_setter_by_id):
        (JSC::JIT::emit_op_put_getter_setter):
        * tests/stress/dfg-put-accessors-by-id-class.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.Cocoa.prototype.get hello):
        (getter.Cocoa):
        (getter):
        (setter.Cocoa):
        (setter.Cocoa.prototype.set hello):
        (setter):
        (accessors.Cocoa):
        (accessors.Cocoa.prototype.get hello):
        (accessors.Cocoa.prototype.set hello):
        (accessors):
        * tests/stress/dfg-put-accessors-by-id.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.object.get hello):
        (getter):
        (setter.object.set hello):
        (setter):
        (accessors.object.get hello):
        (accessors.object.set hello):
        (accessors):
        * tests/stress/dfg-put-getter-by-id-class.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.Cocoa):
        (getter.Cocoa.prototype.get hello):
        (getter.Cocoa.prototype.get name):
        (getter):
        * tests/stress/dfg-put-getter-by-id.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.object.get hello):
        (getter):
        * tests/stress/dfg-put-getter-by-val-class.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.Cocoa):
        (getter.Cocoa.prototype.get name):
        (getter):
        * tests/stress/dfg-put-getter-by-val.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.object.get name):
        (getter):
        * tests/stress/dfg-put-setter-by-id-class.js: Added.
        (shouldBe):
        (testAttribute):
        (getter.Cocoa):
        (getter.Cocoa.prototype.set hello):
        (getter.Cocoa.prototype.get name):
        (getter):
        * tests/stress/dfg-put-setter-by-id.js: Added.
        (shouldBe):
        (testAttribute):
        (setter.object.set hello):
        (setter):
        * tests/stress/dfg-put-setter-by-val-class.js: Added.
        (shouldBe):
        (testAttribute):
        (setter.Cocoa):
        (setter.Cocoa.prototype.set name):
        (setter):
        * tests/stress/dfg-put-setter-by-val.js: Added.
        (shouldBe):
        (testAttribute):
        (setter.object.set name):
        (setter):

2015-10-22  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused Timeline GCEvent Record type
        https://bugs.webkit.org/show_bug.cgi?id=150477

        Reviewed by Timothy Hatcher.

        Garbage Collection events go through the Heap domain, not the
        Timeline domain (long time ago for Chromium).

        * inspector/protocol/Timeline.json:

2015-10-22  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r191360): Repro Crash: com.apple.WebKit.WebContent at JavaScriptCore:JSC::ExecState::bytecodeOffset + 174
        https://bugs.webkit.org/show_bug.cgi?id=150434

        Reviewed by Mark Lam.

        Pass the current frame instead of the caller frame to operationVMHandleException when processing an
        exception in one of the native thunks.

        * jit/JITExceptions.cpp:
        (JSC::genericUnwind): Made debug printing of CodeBlock safe for call frames without one.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):

2015-10-21  Brian Burg  <bburg@apple.com>

        Restructure generate-js-bindings script to be modular and testable
        https://bugs.webkit.org/show_bug.cgi?id=149929

        Reviewed by Alex Christensen.

        This is a new code generator, based on the replay inputs code generator and
        the inspector protocol code generator, which produces various files for JS
        builtins.

        Relative to the generator it replaces, this one consolidates two scripts in
        JavaScriptCore and WebCore into a single script with multiple files. Parsed
        information about the builtins file is stored in backend-independent model
        objects. Each output file has its own code generator that uses the model to
        produce resulting code. Generators are additionally parameterized by the target
        framework (to choose correct macros and includes) and output mode (one
        header/implementation file per builtin or per framework).

        It includes a few simple tests of the generator's functionality. These result-
        based tests will become increasingly more important as we start to add support
        for builtins annotation such as @optional, @internal, etc. to the code generator.

        Some of these complexities, such as having two output modes, will be removed in
        subsequent patches. This patch is intended to exactly replace the existing
        functionality with a unified script that makes additional cleanups straightforward.

        Additional cleanup and consolidation between inspector code generator scripts
        and this script will be pursued in followup patches.

        New tests:

        Scripts/tests/builtins/JavaScriptCore-Builtin.Promise-Combined.js
        Scripts/tests/builtins/JavaScriptCore-Builtin.Promise-Separate.js
        Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Combined.js
        Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Separate.js
        Scripts/tests/builtins/JavaScriptCore-BuiltinConstructor-Combined.js
        Scripts/tests/builtins/JavaScriptCore-BuiltinConstructor-Separate.js
        Scripts/tests/builtins/WebCore-GuardedBuiltin-Separate.js
        Scripts/tests/builtins/WebCore-GuardedInternalBuiltin-Separate.js
        Scripts/tests/builtins/WebCore-UnguardedBuiltin-Separate.js
        Scripts/tests/builtins/WebCore-xmlCasingTest-Separate.js


        * CMakeLists.txt:

            Copy the scripts that are used by other targets to a staging directory inside
            ${DERIVED_SOURCES_DIR}/ForwardingHeaders/JavaScriptCore/Scripts.
            Define JavaScriptCore_SCRIPTS_DIR to point here so that the add_custom_command
            and shared file lists are identical between JavaScriptCore and WebCore. The staged
            scripts are a dependency of the main JavaScriptCore target so that they are
            always staged, even if JavaScriptCore itself does not use a particular script.

            The output files additionally depend on all builtin generator script files
            and input files that are combined into the single header/implementation file.

        * DerivedSources.make:

            Define JavaScriptCore_SCRIPTS_DIR explicitly so the rule for code generation and
            shared file lists are identical between JavaScriptCore and WebCore.

            The output files additionally depend on all builtin generator script files
            and input files that are combined into the single header/implementation file.

        * JavaScriptCore.xcodeproj/project.pbxproj:

            Mark the new builtins generator files as private headers so we can use them from
            WebCore.

        * Scripts/UpdateContents.py: Renamed from Source/JavaScriptCore/UpdateContents.py.
        * Scripts/builtins/__init__.py: Added.
        * Scripts/builtins/builtins.py: Added.
        * Scripts/builtins/builtins_generator.py: Added. This file contains the base generator.
        (WK_lcfirst):
        (WK_ucfirst):
        (BuiltinsGenerator):
        (BuiltinsGenerator.__init__):
        (BuiltinsGenerator.model):
        (BuiltinsGenerator.generate_license):
        (BuiltinsGenerator.generate_includes_from_entries):
        (BuiltinsGenerator.generate_output):
        (BuiltinsGenerator.output_filename):
        (BuiltinsGenerator.mangledNameForFunction):
        (BuiltinsGenerator.mangledNameForFunction.toCamel):
        (BuiltinsGenerator.generate_embedded_code_string_section_for_function):
        * Scripts/builtins/builtins_model.py: Added. This file contains builtins model objects.
        (ParseException):
        (Framework):
        (Framework.__init__):
        (Framework.setting):
        (Framework.fromString):
        (Frameworks):
        (BuiltinObject):
        (BuiltinObject.__init__):
        (BuiltinFunction):
        (BuiltinFunction.__init__):
        (BuiltinFunction.fromString):
        (BuiltinFunction.__str__):
        (BuiltinsCollection):
        (BuiltinsCollection.__init__):
        (BuiltinsCollection.parse_builtins_file):
        (BuiltinsCollection.copyrights):
        (BuiltinsCollection.all_functions):
        (BuiltinsCollection._parse_copyright_lines):
        (BuiltinsCollection._parse_functions):
        * Scripts/builtins/builtins_templates.py: Added.
        (BuiltinsGeneratorTemplates):
        * Scripts/builtins/builtins_generate_combined_header.py: Added.
        (BuiltinsCombinedHeaderGenerator):
        (BuiltinsCombinedHeaderGenerator.__init__):
        (BuiltinsCombinedHeaderGenerator.output_filename):
        (BuiltinsCombinedHeaderGenerator.generate_output):
        (BuiltinsCombinedHeaderGenerator.generate_forward_declarations):
        (FunctionExecutable):
        (VM):
        (ConstructAbility):
        (generate_section_for_object):
        (generate_externs_for_object):
        (generate_macros_for_object):
        (generate_defines_for_object):
        (generate_section_for_code_table_macro):
        (generate_section_for_code_name_macro):
        * Scripts/builtins/builtins_generate_combined_implementation.py: Added.
        (BuiltinsCombinedImplementationGenerator):
        (BuiltinsCombinedImplementationGenerator.__init__):
        (BuiltinsCombinedImplementationGenerator.output_filename):
        (BuiltinsCombinedImplementationGenerator.generate_output):
        (BuiltinsCombinedImplementationGenerator.generate_header_includes):
        * Scripts/builtins/builtins_generate_separate_header.py: Added.
        (BuiltinsSeparateHeaderGenerator):
        (BuiltinsSeparateHeaderGenerator.__init__):
        (BuiltinsSeparateHeaderGenerator.output_filename):
        (BuiltinsSeparateHeaderGenerator.macro_prefix):
        (BuiltinsSeparateHeaderGenerator.generate_output):
        (BuiltinsSeparateHeaderGenerator.generate_forward_declarations):
        (FunctionExecutable):
        (generate_header_includes):
        (generate_section_for_object):
        (generate_externs_for_object):
        (generate_macros_for_object):
        (generate_defines_for_object):
        (generate_section_for_code_table_macro):
        (generate_section_for_code_name_macro):
        * Scripts/builtins/builtins_generate_separate_implementation.py: Added.
        (BuiltinsSeparateImplementationGenerator):
        (BuiltinsSeparateImplementationGenerator.__init__):
        (BuiltinsSeparateImplementationGenerator.output_filename):
        (BuiltinsSeparateImplementationGenerator.macro_prefix):
        (BuiltinsSeparateImplementationGenerator.generate_output):
        (BuiltinsSeparateImplementationGenerator.generate_header_includes):
        * Scripts/builtins/builtins_generate_separate_wrapper.py: Added.
        (BuiltinsSeparateWrapperGenerator):
        (BuiltinsSeparateWrapperGenerator.__init__):
        (BuiltinsSeparateWrapperGenerator.output_filename):
        (BuiltinsSeparateWrapperGenerator.macro_prefix):
        (BuiltinsSeparateWrapperGenerator.generate_output):
        (BuiltinsSeparateWrapperGenerator.generate_header_includes):
        * Scripts/generate-js-builtins.py: Added.

            Parse command line options, decide which generators and output modes to use.

        (generate_bindings_for_builtins_files):
        * Scripts/lazywriter.py: Copied from the inspector protocol generator.
        (LazyFileWriter):
        (LazyFileWriter.__init__):
        (LazyFileWriter.write):
        (LazyFileWriter.close):
        * Scripts/tests/builtins/JavaScriptCore-Builtin.Promise-Combined.js: Added.
        * Scripts/tests/builtins/JavaScriptCore-Builtin.Promise-Separate.js: Added.
        * Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Combined.js: Added.
        * Scripts/tests/builtins/JavaScriptCore-Builtin.prototype-Separate.js: Added.
        * Scripts/tests/builtins/JavaScriptCore-BuiltinConstructor-Combined.js: Added.
        * Scripts/tests/builtins/JavaScriptCore-BuiltinConstructor-Separate.js: Added.
        * Scripts/tests/builtins/WebCore-GuardedBuiltin-Separate.js: Added.
        * Scripts/tests/builtins/WebCore-GuardedInternalBuiltin-Separate.js: Added.
        * Scripts/tests/builtins/WebCore-UnguardedBuiltin-Separate.js: Added.
        * Scripts/tests/builtins/WebCore-xmlCasingTest-Separate.js: Added.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: Added.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result: Added.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result: Added.
        * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result: Added.
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: Added.
        * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result: Added.
        * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Added.
        * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Added.
        * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Added.
        * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Added.
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::BuiltinExecutables):
        * builtins/BuiltinExecutables.h:
        * create_hash_table:

            Update the generated builtin macro names.

        * generate-js-builtins: Removed.

2015-10-21  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove FTL Native Inlining, it is dead code
        https://bugs.webkit.org/show_bug.cgi?id=150429

        Reviewed by Filip Pizlo.

        The code is not used and it is in the way of other changes.

        * ftl/FTLAbbreviations.h:
        (JSC::FTL::getFirstInstruction): Deleted.
        (JSC::FTL::getNextInstruction): Deleted.
        (JSC::FTL::getFirstBasicBlock): Deleted.
        (JSC::FTL::getNextBasicBlock): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::isInlinableSize): Deleted.
        * runtime/Options.h:

2015-10-21  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] Remove two useless temporaries from the PutByOffset codegen
        https://bugs.webkit.org/show_bug.cgi?id=150421

        Reviewed by Geoffrey Garen.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Deleted.
        Looks like they were added by accident in r160796.

2015-10-21  Filip Pizlo  <fpizlo@apple.com>

        Factor out the graph node worklists from DFG into WTF
        https://bugs.webkit.org/show_bug.cgi?id=150411

        Reviewed by Geoffrey Garen.

        Rewrite the DFGBlockWorklist.h file as a bunch of typedefs and aliases for things in
        wtf/GraphNodeWorklist.h. Most users won't notice, except that some small things got
        renamed. For example PreOrder becomes VisitOrder::Pre and item.block becomes item.node.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGBlockWorklist.cpp: Removed.
        * dfg/DFGBlockWorklist.h:
        (JSC::DFG::BlockWorklist::notEmpty): Deleted.
        (JSC::DFG::BlockWith::BlockWith): Deleted.
        (JSC::DFG::BlockWith::operator bool): Deleted.
        (JSC::DFG::ExtendedBlockWorklist::ExtendedBlockWorklist): Deleted.
        (JSC::DFG::ExtendedBlockWorklist::forcePush): Deleted.
        (JSC::DFG::ExtendedBlockWorklist::push): Deleted.
        (JSC::DFG::ExtendedBlockWorklist::notEmpty): Deleted.
        (JSC::DFG::ExtendedBlockWorklist::pop): Deleted.
        (JSC::DFG::BlockWithOrder::BlockWithOrder): Deleted.
        (JSC::DFG::BlockWithOrder::operator bool): Deleted.
        (JSC::DFG::PostOrderBlockWorklist::push): Deleted.
        (JSC::DFG::PostOrderBlockWorklist::notEmpty): Deleted.
        * dfg/DFGDominators.cpp:
        (JSC::DFG::Dominators::compute):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::blocksInPostOrder):
        * dfg/DFGPrePostNumbering.cpp:
        (JSC::DFG::PrePostNumbering::compute):

2015-10-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        [INTL] Implement Intl.Collator.prototype.resolvedOptions ()
        https://bugs.webkit.org/show_bug.cgi?id=147601

        Reviewed by Benjamin Poulain.

        This patch implements Intl.Collator.prototype.resolvedOptions() according
        to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.)
        It also implements the abstract operations InitializeCollator, ResolveLocale,
        LookupMatcher, and BestFitMatcher.

        * runtime/CommonIdentifiers.h:
        * runtime/IntlCollator.h:
        (JSC::IntlCollator::usage):
        (JSC::IntlCollator::setUsage):
        (JSC::IntlCollator::locale):
        (JSC::IntlCollator::setLocale):
        (JSC::IntlCollator::collation):
        (JSC::IntlCollator::setCollation):
        (JSC::IntlCollator::numeric):
        (JSC::IntlCollator::setNumeric):
        (JSC::IntlCollator::sensitivity):
        (JSC::IntlCollator::setSensitivity):
        (JSC::IntlCollator::ignorePunctuation):
        (JSC::IntlCollator::setIgnorePunctuation):
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::sortLocaleData):
        (JSC::searchLocaleData):
        (JSC::initializeCollator):
        (JSC::constructIntlCollator):
        (JSC::callIntlCollator):
        * runtime/IntlCollatorPrototype.cpp:
        (JSC::IntlCollatorPrototypeFuncResolvedOptions):
        * runtime/IntlObject.cpp:
        (JSC::defaultLocale):
        (JSC::getIntlBooleanOption):
        (JSC::getIntlStringOption):
        (JSC::removeUnicodeLocaleExtension):
        (JSC::lookupMatcher):
        (JSC::bestFitMatcher):
        (JSC::resolveLocale):
        (JSC::lookupSupportedLocales):
        * runtime/IntlObject.h:

2015-10-21  Saam barati  <sbarati@apple.com>

        C calls in PolymorphicAccess shouldn't assume that the top of the stack looks like a JSC JIT frame and enable *ByIdFlush in FTL
        https://bugs.webkit.org/show_bug.cgi?id=125711

        Reviewed by Filip Pizlo.

        This patch ensures that anytime we need to make a C call inside
        PolymorphicAccess, we ensure there is enough space on the stack to do so.

        This patch also enables GetByIdFlush/PutByIdFlush inside the FTL.
        Because PolymorphicAccess now spills the necessary registers
        before making a JS/C call, any registers that LLVM report as
        being in use for the patchpoint will be spilled before making
        a call by PolymorphicAccess.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::restoreScratch):
        (JSC::AccessGenerationState::succeed):
        (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
        (JSC::AccessCase::generate):
        (JSC::PolymorphicAccess::regenerate):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetById):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitTypeOf):
        (JSC::AssemblyHelpers::makeSpaceOnStackForCCall):
        (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
        (JSC::RegisterSet::registersToNotSaveForJSCall):
        (JSC::RegisterSet::registersToNotSaveForCCall):
        (JSC::RegisterSet::allGPRs):
        (JSC::RegisterSet::registersToNotSaveForCall): Deleted.
        * jit/RegisterSet.h:
        (JSC::RegisterSet::set):
        * jit/ScratchRegisterAllocator.cpp:
        (JSC::ScratchRegisterAllocator::allocateScratchGPR):
        (JSC::ScratchRegisterAllocator::allocateScratchFPR):
        (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
        (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
        These methods now take an extra parameter indicating if they
        should create space for a C call at the top of the stack if
        there are any reused registers to spill.

        (JSC::ScratchRegisterAllocator::usedRegistersForCall):
        * jit/ScratchRegisterAllocator.h:
        (JSC::ScratchRegisterAllocator::usedRegisters):

2015-10-21  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Array previews with Symbol objects have too few preview values
        https://bugs.webkit.org/show_bug.cgi?id=150404

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
        We should be continuing inside this loop not returning.

2015-10-21  Filip Pizlo  <fpizlo@apple.com>

        Failures in PutStackSinkingPhase should be less severe
        https://bugs.webkit.org/show_bug.cgi?id=150400

        Reviewed by Geoffrey Garen.

        Make the PutStackSinkingPhase abort instead of asserting. To test that it's OK to not have
        PutStackSinkingPhase run, this adds a test mode where we run without PutStackSinkingPhase.

        * dfg/DFGPlan.cpp: Make it possible to not run PutStackSinkingPhase for tests.
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPutStackSinkingPhase.cpp: PutStackSinkingPhase should abort instead of asserting, except when validation is enabled.
        * runtime/Options.h: Add an option for disabling PutStackSinkingPhase.

2015-10-21  Saam barati  <sbarati@apple.com>

        The FTL should place the CallSiteIndex on the call frame for JS calls when it fills in the patchpoint
        https://bugs.webkit.org/show_bug.cgi?id=150104

        Reviewed by Filip Pizlo.

        We lower JS Calls to patchpoints in LLVM. LLVM may decide to duplicate
        these patchpoints (or remove them). We eagerly store the CallSiteIndex on the 
        call frame when lowering DFG to LLVM. But, because the patchpoint we lower to may
        be duplicated, we really don't know the unique CallSiteIndex until we've
        actually seen the resulting patchpoints after LLVM has completed its transformations.
        To solve this, we now store the unique CallSiteIndex on the call frame header 
        when generating code to fill into the patchpoint.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLJSCall.cpp:
        (JSC::FTL::JSCall::JSCall):
        (JSC::FTL::JSCall::emit):
        * ftl/FTLJSCall.h:
        (JSC::FTL::JSCall::stackmapID):
        * ftl/FTLJSCallBase.cpp:
        (JSC::FTL::JSCallBase::JSCallBase):
        (JSC::FTL::JSCallBase::emit):
        (JSC::FTL::JSCallBase::link):
        * ftl/FTLJSCallBase.h:
        * ftl/FTLJSCallVarargs.cpp:
        (JSC::FTL::JSCallVarargs::JSCallVarargs):
        (JSC::FTL::JSCallVarargs::numSpillSlotsNeeded):
        (JSC::FTL::JSCallVarargs::emit):
        * ftl/FTLJSCallVarargs.h:
        (JSC::FTL::JSCallVarargs::node):
        (JSC::FTL::JSCallVarargs::stackmapID):
        * ftl/FTLJSTailCall.cpp:
        (JSC::FTL::JSTailCall::JSTailCall):
        (JSC::FTL::m_instructionOffset):
        (JSC::FTL::JSTailCall::emit):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
        (JSC::FTL::DFG::LowerDFGToLLVM::codeOriginDescriptionOfCallSite):
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):

2015-10-21  Geoffrey Garen  <ggaren@apple.com>

        Date creation should share a little code
        https://bugs.webkit.org/show_bug.cgi?id=150399

        Reviewed by Filip Pizlo.

        I want to fix a bug in this code, but I don't want to fix it in two
        different places. (See https://bugs.webkit.org/show_bug.cgi?id=150386.)

        * runtime/DateConstructor.cpp:
        (JSC::DateConstructor::getOwnPropertySlot):
        (JSC::milliseconds): Factored out a shared helper function. If you look
        closely, you'll see that one copy of this code previously checked isfinite
        while the other checked isnan. isnan returning nan was obviously a no-op,
        so I removed it. isfinite, it turns out, is also a no-op -- but less
        obviously so, so I kept it for now.

        (JSC::constructDate):
        (JSC::dateUTC): Use the helper function.

2015-10-21  Guillaume Emont  <guijemont@igalia.com>

        llint: align stack pointer on mips too

        [MIPS] LLInt: align stack pointer on MIPS too
        https://bugs.webkit.org/show_bug.cgi?id=150380

        Reviewed by Michael Saboff.

        * llint/LowLevelInterpreter32_64.asm:

2015-10-20  Mark Lam  <mark.lam@apple.com>

        YarrPatternConstructor::containsCapturingTerms() should not assume that its terms.size() is greater than 0.
        https://bugs.webkit.org/show_bug.cgi?id=150372

        Reviewed by Geoffrey Garen.

        * yarr/YarrPattern.cpp:
        (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
        (JSC::Yarr::YarrPatternConstructor::optimizeBOL):
        (JSC::Yarr::YarrPatternConstructor::containsCapturingTerms):
        (JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions):

2015-10-20  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r191175): OSR Exit from an inlined tail callee trashes callee save registers
        https://bugs.webkit.org/show_bug.cgi?id=150336

        Reviewed by Mark Lam.

        During OSR exit, we need to restore and transform the active stack into what the baseline
        JIT expects.  Inlined call frames become true call frames.  When we reify an inlined call
        frame and it is a tail call which we will be continuing from, we need to restore the tag
        constant callee save registers with what was saved by the outermost caller.

        Re-enabled tail calls and restored tests for tail calls.

        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames): Select whether or not we use the callee save tag register
        contents or what was saved by the inlining caller when populating an inlined callee's
        callee save registers.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitSaveCalleeSavesFor): This function no longer needs a stack offset.
        (JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor): New helper.
        * runtime/Options.h: Turned tail calls back on.
        * tests/es6.yaml:
        * tests/stress/dfg-tail-calls.js:
        (nonInlinedTailCall.callee):
        * tests/stress/mutual-tail-call-no-stack-overflow.js:
        (shouldThrow):
        * tests/stress/tail-call-in-inline-cache.js:
        (tail):
        * tests/stress/tail-call-no-stack-overflow.js:
        (shouldThrow):
        * tests/stress/tail-call-recognize.js:
        (callerMustBeRun):
        * tests/stress/tail-call-varargs-no-stack-overflow.js:
        (shouldThrow):

2015-10-20  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: JavaScriptCore should parse sourceURL and sourceMappingURL directives
        https://bugs.webkit.org/show_bug.cgi?id=150096

        Reviewed by Geoffrey Garen.

        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::scriptCommentPattern): Deleted.
        (Inspector::ContentSearchUtilities::findScriptSourceURL): Deleted.
        (Inspector::ContentSearchUtilities::findScriptSourceMapURL): Deleted.
        * inspector/ContentSearchUtilities.h:
        No longer need to search script content.

        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::dispatchDidParseSource):
        Carry over the sourceURL and sourceMappingURL from the SourceProvider.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::sourceMapURLForScript):
        (Inspector::InspectorDebuggerAgent::didParseSource):
        No longer do content searching.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::setCode):
        (JSC::Lexer<T>::skipWhitespace):
        (JSC::Lexer<T>::parseCommentDirective):
        (JSC::Lexer<T>::parseCommentDirectiveValue):
        (JSC::Lexer<T>::consume):
        (JSC::Lexer<T>::lex):
        * parser/Lexer.h:
        (JSC::Lexer::sourceURL):
        (JSC::Lexer::sourceMappingURL):
        (JSC::Lexer::sourceProvider): Deleted.
        Give lexer the ability to detect script comment directives.
        This just consumes characters in single line comments and
        ultimately sets the sourceURL or sourceMappingURL found.

        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        * parser/SourceProvider.h:
        (JSC::SourceProvider::url):
        (JSC::SourceProvider::sourceURL):
        (JSC::SourceProvider::sourceMappingURL):
        (JSC::SourceProvider::setSourceURL):
        (JSC::SourceProvider::setSourceMappingURL):
        After parsing a script, update the Source Provider with the
        value of directives that may have been found in the script.

2015-10-20  Saam barati  <sbarati@apple.com>

        GCAwareJITStubRoutineWithExceptionHandler has a stale CodeBlock pointer in its destructor
        https://bugs.webkit.org/show_bug.cgi?id=150351

        Reviewed by Mark Lam.

        We may regenerate many GCAwareJITStubRoutineWithExceptionHandler stubs per one PolymorphicAccess.
        Only the last GCAwareJITStubRoutineWithExceptionHandler stub that was generated will get the CodeBlock's aboutToDie()
        notification. All other GCAwareJITStubRoutineWithExceptionHandler stubs will still be holding a stale CodeBlock pointer
        that they will use in their destructor. The solution is to have GCAwareJITStubRoutineWithExceptionHandler remove its
        exception handler in observeZeroRefCount() instead of its destructor. observeZeroRefCount() will run when a PolymorphicAccess
        replaces its m_stubRoutine.

        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::GCAwareJITStubRoutineWithExceptionHandler::aboutToDie):
        (JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):
        (JSC::createJITStubRoutine):
        (JSC::GCAwareJITStubRoutineWithExceptionHandler::~GCAwareJITStubRoutineWithExceptionHandler): Deleted.
        * jit/GCAwareJITStubRoutine.h:

2015-10-20  Tim Horton  <timothy_horton@apple.com>

        Try to fix the build by disabling MAC_GESTURE_EVENTS on 10.9 and 10.10

        * Configurations/FeatureDefines.xcconfig:

2015-10-20  Xabier Rodriguez Calvar  <calvaris@igalia.com>

        [Streams API] Rework some readable stream internals that can be common to writable streams
        https://bugs.webkit.org/show_bug.cgi?id=150133

        Reviewed by Darin Adler.

        * runtime/CommonIdentifiers.h:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init): Added RangeError also as native functions.

2015-10-20  Yoav Weiss  <yoav@yoav.ws>

        Rename the PICTURE_SIZES flag to CURRENTSRC
        https://bugs.webkit.org/show_bug.cgi?id=150275

        Reviewed by Dean Jackson.

        * Configurations/FeatureDefines.xcconfig:

2015-10-19  Saam barati  <sbarati@apple.com>

        FTL should generate a unique OSR exit for each duplicated OSR exit stackmap intrinsic.
        https://bugs.webkit.org/show_bug.cgi?id=149970

        Reviewed by Filip Pizlo.

        When we lower DFG to LLVM, we generate a stackmap intrnsic for OSR 
        exits. We also recorded the OSR exit inside FTL::JITCode during lowering.
        This stackmap intrinsic may be duplicated or even removed by LLVM.
        When the stackmap intrinsic is duplicated, we used to generate just
        a single OSR exit data structure. Then, when we compiled an OSR exit, we 
        would look for the first record in the record list that had the same stackmap ID
        as what the OSR exit data structure had. We did this even when the OSR exit
        stackmap intrinsic was duplicated. This would lead us to grab the wrong FTL::StackMaps::Record.

        Now, each OSR exit knows exactly which FTL::StackMaps::Record it corresponds to.
        We accomplish this by having an OSRExitDescriptor that is recorded during
        lowering. Each descriptor may be referenced my zero, one, or more OSRExits.
        Now, no more than one stackmap intrinsic corresponds to the same index inside 
        JITCode's OSRExit Vector. Also, each OSRExit jump now jumps to a code location.

        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::validateReferences):
        (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * ftl/FTLJITCode.h:
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileIsUndefined):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::callStackmap):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor):
        (JSC::FTL::OSRExitDescriptor::validateReferences):
        (JSC::FTL::OSRExit::OSRExit):
        (JSC::FTL::OSRExit::codeLocationForRepatch):
        (JSC::FTL::OSRExit::validateReferences): Deleted.
        * ftl/FTLOSRExit.h:
        (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
        * ftl/FTLOSRExitCompilationInfo.h:
        (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLStackMaps.cpp:
        (JSC::FTL::StackMaps::computeRecordMap):
        * ftl/FTLStackMaps.h:

2015-10-16  Brian Burg  <bburg@apple.com>

        Unify handling of JavaScriptCore scripts that are used in WebCore
        https://bugs.webkit.org/show_bug.cgi?id=150245

        Reviewed by Alex Christensen.

        Move all standalone JavaScriptCore scripts that are used by WebCore into the
        JavaScriptCore/Scripts directory. Use JavaScriptCore_SCRIPTS_DIR to refer
        to the path for these scripts.

        * DerivedSources.make:

            Define and use JavaScriptCore_SCRIPTS_DIR.

        * JavaScriptCore.xcodeproj/project.pbxproj:

            Make a new group in the Xcode project and clean up references.

        * PlatformWin.cmake:

            For Windows, copy these scripts over to ForwardingHeaders/Scripts since they
            cannot be used directly from JAVASCRIPTCORE_DIR in AppleWin builds. Do the same
            thing for both Windows variants to be consistent about it.

        * Scripts/cssmin.py: Renamed from Source/JavaScriptCore/inspector/scripts/cssmin.py.
        * Scripts/generate-combined-inspector-json.py: Renamed from Source/JavaScriptCore/inspector/scripts/generate-combined-inspector-json.py.
        * Scripts/generate-js-builtins: Renamed from Source/JavaScriptCore/generate-js-builtins.
        * Scripts/inline-and-minify-stylesheets-and-scripts.py: Renamed from Source/JavaScriptCore/inspector/scripts/inline-and-minify-stylesheets-and-scripts.py.
        * Scripts/jsmin.py: Renamed from Source/JavaScriptCore/inspector/scripts/jsmin.py.
        * Scripts/xxd.pl: Renamed from Source/JavaScriptCore/inspector/scripts/xxd.pl.

2015-10-19  Tim Horton  <timothy_horton@apple.com>

        Try to fix the iOS build

        * Configurations/FeatureDefines.xcconfig:

2015-10-17  Keith Miller  <keith_miller@apple.com>

        Add regression tests for TypedArray.prototype functions' error messages.
        https://bugs.webkit.org/show_bug.cgi?id=150288

        Reviewed by Darin Adler.

        Fix a typo in the text passed by TypedArrray.prototype.filter type error message.
        Add tests that check the actual error message text for all the TypeArray.prototype
        functions that throw.

        * builtins/TypedArray.prototype.js:
        (filter):
        * tests/stress/typedarray-every.js:
        * tests/stress/typedarray-filter.js:
        * tests/stress/typedarray-find.js:
        * tests/stress/typedarray-findIndex.js:
        * tests/stress/typedarray-forEach.js:
        * tests/stress/typedarray-map.js:
        * tests/stress/typedarray-reduce.js:
        * tests/stress/typedarray-reduceRight.js:
        * tests/stress/typedarray-some.js:

2015-10-19  Tim Horton  <timothy_horton@apple.com>

        Add magnify and rotate gesture event support for Mac
        https://bugs.webkit.org/show_bug.cgi?id=150179
        <rdar://problem/8036240>

        Reviewed by Darin Adler.

        * Configurations/FeatureDefines.xcconfig:
        New feature flag.

2015-10-19  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the ENABLE(WEBASSEMBLY) build after r190827
        https://bugs.webkit.org/show_bug.cgi?id=150330

        Reviewed by Geoffrey Garen.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock): Removed the duplicated VM argument.
        * bytecode/CodeBlock.h:
        (JSC::WebAssemblyCodeBlock::create): Added new parameters to finishCreation() calls.
        (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock): Change VM parameter to pointer to match *CodeBlock classes.
        * runtime/Executable.cpp:
        (JSC::WebAssemblyExecutable::prepareForExecution): Removed extra ")" and pass pointer as it is expected.

2015-10-19  Mark Lam  <mark.lam@apple.com>

        DoubleRep fails to convert SpecBoolean values.
        https://bugs.webkit.org/show_bug.cgi?id=150313

        Reviewed by Geoffrey Garen.

        This was uncovered by the op_sub stress test on 32-bit builds.  On 32-bit builds,
        DoubleRep will erroneously convert 'true' to a 'NaN' instead of a double 1.
        On 64-bit, the same issue exists but is masked by another bug in DoubleRep where
        boolean values will always erroneously trigger a BadType OSR exit.

        The erroneous conversion of 'true' to 'NaN' is because the 'true' case in
        compileDoubleRep() is missing a jump to the "done" destination.  Instead, it
        fall through to the "isUndefined" case where it produces a NaN.

        The 64-bit erroneous BadType OSR exit is due to the boolean type check being
        implemented incorrectly.  It was checking if any bits other than bit 0 were set.
        However, boolean JS values always have TagBitBool (the 3rd bit) set.  Hence, the
        check will always fail if we have a boolean value.

        This patch fixes both of these issues.

        No new test is needed because these issues are already covered by scenarios in
        the op_sub.js stress test.  This patch also fixes the op_sub.js test to throw an
        exception if any failures are encountered (as expected by the stress test
        harness).  This patch also re-worked the test code to provide more accurate
        descriptions of each test scenario for error reporting.

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

        * tests/stress/op_sub.js:
        (generateScenarios):
        (func):
        (initializeTestCases):
        (runTest):
        (stringify): Deleted.

2015-10-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        Drop !newTarget check since it always becomes true
        https://bugs.webkit.org/show_bug.cgi?id=150308

        Reviewed by Geoffrey Garen.

        In a context of calling a constructor, `newTarget` should not become JSEmpty.
        So `!newTarget` always becomes true. This patch drops this unneccessary check.
        And to ensure the implementation of the constructor is only called under
        the context of calling it as a constructor, we change these functions to
        static and only use them for constructor implementations of InternalFunction.

        * runtime/IntlCollatorConstructor.cpp:
        (JSC::constructIntlCollator):
        (JSC::callIntlCollator):
        * runtime/IntlCollatorConstructor.h:
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::constructIntlDateTimeFormat):
        (JSC::callIntlDateTimeFormat):
        * runtime/IntlDateTimeFormatConstructor.h:
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::constructIntlNumberFormat):
        (JSC::callIntlNumberFormat):
        * runtime/IntlNumberFormatConstructor.h:
        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):

2015-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        Promise constructor should throw when not called with "new"
        https://bugs.webkit.org/show_bug.cgi?id=149380

        Reviewed by Darin Adler.

        Implement handling new.target in Promise constructor. And
        prohibiting Promise constructor call without "new".

        * runtime/JSPromiseConstructor.cpp:
        (JSC::constructPromise):
        (JSC::callPromise):
        (JSC::JSPromiseConstructor::getCallData):
        * tests/es6.yaml:
        * tests/stress/promise-cannot-be-called.js: Added.
        (shouldBe):
        (shouldThrow):
        (Deferred):
        (super):

2015-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Handle asynchronous tests in tests/es6
        https://bugs.webkit.org/show_bug.cgi?id=150293

        Reviewed by Darin Adler.

        Since JSC can handle microtasks, some of ES6 Promise tests can be executed under the JSC shell.
        Some of them still fail because it uses setTimeout that invokes macrotasks with explicit delay.

        * tests/es6.yaml:
        * tests/es6/Promise_Promise.all.js:
        (test.asyncTestPassed):
        (test):
        * tests/es6/Promise_Promise.all_generic_iterables.js:
        (test.asyncTestPassed):
        (test):
        * tests/es6/Promise_Promise.race.js:
        (test.asyncTestPassed):
        (test):
        * tests/es6/Promise_Promise.race_generic_iterables.js:
        (test.asyncTestPassed):
        (test):
        * tests/es6/Promise_basic_functionality.js:
        (test.asyncTestPassed):
        (test):
        * tests/es6/Promise_is_subclassable_Promise.all.js:
        (test.asyncTestPassed):
        (test):
        * tests/es6/Promise_is_subclassable_Promise.race.js:
        (test.asyncTestPassed):
        (test):
        * tests/es6/Promise_is_subclassable_basic_functionality.js:
        (test.asyncTestPassed):
        (test):

2015-10-18  Sungmann Cho  <sungmann.cho@navercorp.com>

        [Win] Fix the Windows builds.
        https://bugs.webkit.org/show_bug.cgi?id=150300

        Reviewed by Darin Adler.

        Add missing files to JavaScriptCore.vcxproj.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2015-10-17  Filip Pizlo  <fpizlo@apple.com>

        Fix some generational heap growth pathologies
        https://bugs.webkit.org/show_bug.cgi?id=150270

        Reviewed by Andreas Kling.

        When doing generational copying, we would pretend that the size of old space was increased
        just by the amount of bytes we copied. In reality, it would be increased by the number of
        bytes used by the copied blocks we created. This is a larger number, and in some simple
        pathological programs, the difference can be huge.

        Fixing this bug was relatively easy, and the only really meaningful change here is in
        Heap::updateAllocationLimits(). But to convince myself that the change was valid, I had to
        add some debugging code and I had to refactor some stuff so that it made more sense.

        This change does obviate the need for m_totalBytesCopied, because we no longer use it in
        release builds to decide how much heap we are using at the end of collection. But I added a
        FIXME about how we could restore our use of m_totalBytesCopied. So, I kept the logic, for
        now. The FIXME references https://bugs.webkit.org/show_bug.cgi?id=150268.

        Relanding with build fix.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/CopiedBlock.cpp: Added.
        (JSC::CopiedBlock::createNoZeroFill):
        (JSC::CopiedBlock::destroy):
        (JSC::CopiedBlock::create):
        (JSC::CopiedBlock::zeroFillWilderness):
        (JSC::CopiedBlock::CopiedBlock):
        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::didSurviveGC):
        (JSC::CopiedBlock::createNoZeroFill): Deleted.
        (JSC::CopiedBlock::destroy): Deleted.
        (JSC::CopiedBlock::create): Deleted.
        (JSC::CopiedBlock::zeroFillWilderness): Deleted.
        (JSC::CopiedBlock::CopiedBlock): Deleted.
        * heap/CopiedSpaceInlines.h:
        (JSC::CopiedSpace::startedCopying):
        * heap/Heap.cpp:
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::resetVisitors):
        (JSC::Heap::capacity):
        (JSC::Heap::protectedGlobalObjectCount):
        (JSC::Heap::collectImpl):
        (JSC::Heap::willStartCollection):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::sizeAfterCollect): Deleted.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::shouldCollect):
        (JSC::Heap::isBusy):
        (JSC::Heap::collectIfNecessaryOrDefer):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::destroy):

2015-10-17  Commit Queue  <commit-queue@webkit.org>

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

        Broke 32-bit builds (Requested by smfr on #webkit).

        Reverted changeset:

        "Fix some generational heap growth pathologies"
        https://bugs.webkit.org/show_bug.cgi?id=150270
        http://trac.webkit.org/changeset/191240

2015-10-17  Sungmann Cho  <sungmann.cho@navercorp.com>

        [Win] Fix the Windows build.
        https://bugs.webkit.org/show_bug.cgi?id=150278

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2015-10-17  Mark Lam  <mark.lam@apple.com>

        Fixed typos from r191224.

        Not reviewed.

        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::generateFastPath):

2015-10-17  Filip Pizlo  <fpizlo@apple.com>

        Fix some generational heap growth pathologies
        https://bugs.webkit.org/show_bug.cgi?id=150270

        Reviewed by Andreas Kling.

        When doing generational copying, we would pretend that the size of old space was increased
        just by the amount of bytes we copied. In reality, it would be increased by the number of
        bytes used by the copied blocks we created. This is a larger number, and in some simple
        pathological programs, the difference can be huge.

        Fixing this bug was relatively easy, and the only really meaningful change here is in
        Heap::updateAllocationLimits(). But to convince myself that the change was valid, I had to
        add some debugging code and I had to refactor some stuff so that it made more sense.

        This change does obviate the need for m_totalBytesCopied, because we no longer use it in
        release builds to decide how much heap we are using at the end of collection. But I added a
        FIXME about how we could restore our use of m_totalBytesCopied. So, I kept the logic, for
        now. The FIXME references https://bugs.webkit.org/show_bug.cgi?id=150268.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/CopiedBlock.cpp: Added.
        (JSC::CopiedBlock::createNoZeroFill):
        (JSC::CopiedBlock::destroy):
        (JSC::CopiedBlock::create):
        (JSC::CopiedBlock::zeroFillWilderness):
        (JSC::CopiedBlock::CopiedBlock):
        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::didSurviveGC):
        (JSC::CopiedBlock::createNoZeroFill): Deleted.
        (JSC::CopiedBlock::destroy): Deleted.
        (JSC::CopiedBlock::create): Deleted.
        (JSC::CopiedBlock::zeroFillWilderness): Deleted.
        (JSC::CopiedBlock::CopiedBlock): Deleted.
        * heap/CopiedSpaceInlines.h:
        (JSC::CopiedSpace::startedCopying):
        * heap/Heap.cpp:
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::resetVisitors):
        (JSC::Heap::capacity):
        (JSC::Heap::protectedGlobalObjectCount):
        (JSC::Heap::collectImpl):
        (JSC::Heap::willStartCollection):
        (JSC::Heap::updateAllocationLimits):
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::sizeAfterCollect): Deleted.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::shouldCollect):
        (JSC::Heap::isBusy):
        (JSC::Heap::collectIfNecessaryOrDefer):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::destroy):

2015-10-16  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement String.prototype.normalize
        https://bugs.webkit.org/show_bug.cgi?id=150094

        Reviewed by Geoffrey Garen.

        This patch implements String.prototype.normalize leveraging ICU.
        It can provide the feature applying {NFC, NFD, NFKC, NFKD} normalization to a given string.

        * runtime/StringPrototype.cpp:
        (JSC::StringPrototype::finishCreation):
        (JSC::normalize):
        (JSC::stringProtoFuncNormalize):
        * tests/es6.yaml:
        * tests/stress/string-normalize.js: Added.
        (unicode):
        (shouldBe):
        (shouldThrow):
        (normalizeTest):

2015-10-16  Geoffrey Garen  <ggaren@apple.com>

        Update JavaScriptCore API docs
        https://bugs.webkit.org/show_bug.cgi?id=150262

        Reviewed by Mark Lam.

        Apply some edits for clarity. These came out of a docs review.

        * API/JSContext.h:
        * API/JSExport.h:
        * API/JSManagedValue.h:
        * API/JSValue.h:

2015-10-16  Keith Miller  <keith_miller@apple.com>

        Unreviewed. Fix typo in TypeError messages in TypedArray.prototype.forEach/filter.

        * builtins/TypedArray.prototype.js:
        (forEach):
        (filter):

2015-10-16  Mark Lam  <mark.lam@apple.com>

        Use JITSubGenerator to support UntypedUse operands for op_sub in the DFG.
        https://bugs.webkit.org/show_bug.cgi?id=150038

        Reviewed by Geoffrey Garen.

        * bytecode/SpeculatedType.h:
        (JSC::isUntypedSpeculationForArithmetic): Added
        - Also fixed some comments.
        
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::resultType):
        * dfg/DFGAbstractValue.h:
        - Added function to compute the ResultType of an operand from its SpeculatedType.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        - Fix up ArithSub to speculate its operands to be numbers.  But if an OSR exit
          due to a BadType was seen at this node, we'll fix it up to expect UntypedUse
          operands.  This gives the generated code a change to run fast if it only
          receives numeric operands.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateUntypedForArithmetic):

        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        - Add the C++ runtime function to implement op_sub when we really encounter the
          hard types in the operands.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithSub):
        - Added support for UntypedUse operands using the JITSubGenerator.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
        (JSC::DFG::SpeculativeJIT::pickCanTrample):
        (JSC::DFG::SpeculativeJIT::callOperation):

        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        - Just refuse to FTL compile functions with UntypedUse op_sub operands for now.

        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::boxDouble):
        (JSC::AssemblyHelpers::unboxDoubleNonDestructive):
        (JSC::AssemblyHelpers::unboxDouble):
        (JSC::AssemblyHelpers::boxBooleanPayload):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_sub):

        * jit/JITSubGenerator.h:
        (JSC::JITSubGenerator::generateFastPath):
        (JSC::JITSubGenerator::endJumpList):
        - Added some asserts to document the contract that this generator expects in
          terms of its incoming registers.

          Also fixed the generated code to not be destructive with regards to incoming
          registers.  The DFG expects this.

          Also added an endJumpList so that we don't have to jump twice for the fast
          path where both operands are ints.

        * parser/ResultType.h:
        (JSC::ResultType::ResultType):
        - Make the internal Type bits and the constructor private.  Clients should only
          create ResultType values using one of the provided factory methods.

        * tests/stress/op_sub.js: Added.
        (o1.valueOf):
        (stringify):
        (generateScenarios):
        (printScenarios):
        (testCases.func):
        (func):
        (initializeTestCases):
        (runTest):
        - test op_sub results by comparing one LLINT result against the output of
          multiple LLINT, and JIT runs.  This test assume that we'll at least get the
          right result some of the time (if not all the time), and confirms that the
          various engines produce consistent results for all the various value pairs
          being tested.

2015-10-15  Filip Pizlo  <fpizlo@apple.com>

        CopyBarrier must be avoided for slow TypedArrays
        https://bugs.webkit.org/show_bug.cgi?id=150217
        rdar://problem/23128791

        Reviewed by Michael Saboff.

        Change how we access array buffer views so that we don't fire the barrier slow path, and
        don't mask off the spaceBits, if the view is not FastTypedArray. That's because in that case
        m_vector could be misaligned and so have meaningful non-space data in the spaceBits. Also in
        that case, m_vector does not point into copied space.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorWithBarrier):
        (JSC::FTL::DFG::LowerDFGToLLVM::copyBarrier):
        (JSC::FTL::DFG::LowerDFGToLLVM::isInToSpace):
        (JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyReadOnly):
        (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorReadOnly):
        (JSC::FTL::DFG::LowerDFGToLLVM::removeSpaceBits):
        (JSC::FTL::DFG::LowerDFGToLLVM::isFastTypedArray):
        (JSC::FTL::DFG::LowerDFGToLLVM::baseIndex):
        * heap/CopyBarrier.h:
        (JSC::CopyBarrierBase::getWithoutBarrier):
        (JSC::CopyBarrierBase::getPredicated):
        (JSC::CopyBarrierBase::get):
        (JSC::CopyBarrierBase::copyState):
        (JSC::CopyBarrier::get):
        (JSC::CopyBarrier::getPredicated):
        (JSC::CopyBarrier::set):
        * heap/Heap.cpp:
        (JSC::Heap::copyBarrier):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::branchIfNotType):
        (JSC::AssemblyHelpers::branchIfFastTypedArray):
        (JSC::AssemblyHelpers::branchIfNotFastTypedArray):
        (JSC::AssemblyHelpers::loadTypedArrayVector):
        (JSC::AssemblyHelpers::purifyNaN):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchStructure):
        (JSC::AssemblyHelpers::branchIfToSpace):
        (JSC::AssemblyHelpers::branchIfNotToSpace):
        (JSC::AssemblyHelpers::removeSpaceBits):
        (JSC::AssemblyHelpers::addressForByteOffset):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::vector):
        (JSC::JSArrayBufferView::length):
        * runtime/JSArrayBufferViewInlines.h:
        (JSC::JSArrayBufferView::byteOffset):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::typedVector):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore):
        (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
        * tests/stress/misaligned-int8-view-byte-offset.js: Added.
        * tests/stress/misaligned-int8-view-read.js: Added.
        * tests/stress/misaligned-int8-view-write.js: Added.

2015-10-16  Keith Miller  <keith_miller@apple.com>

        Unreviewed. Build fix for 191215.

        * jit/IntrinsicEmitter.cpp:

2015-10-16  Keith Miller  <keith@Keiths-MacBook-Pro-5.local>

        Add Intrinsic Getters and use them to fix performance on the getters of TypedArray properties.
        https://bugs.webkit.org/show_bug.cgi?id=149687

        Reviewed by Geoffrey Garen.

        Add the ability to create intrinsic getters in both the inline cache and the DFG/FTL. When the
        getter fetched by a GetById has an intrinsic we know about we add a new intrinsic access case.
        Once we get to the DFG, we observe that the access case was an intrinsic and add an appropriate
        GetByIdVariant. We then parse the intrinsic into an appropriate DFG node.

        The first intrinsics are the new TypedArray prototype getters length, byteLength, and byteOffset.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/GetByIdVariant.cpp:
        (JSC::GetByIdVariant::GetByIdVariant):
        (JSC::GetByIdVariant::operator=):
        (JSC::GetByIdVariant::canMergeIntrinsicStructures):
        (JSC::GetByIdVariant::attemptToMerge):
        (JSC::GetByIdVariant::dumpInContext):
        * bytecode/GetByIdVariant.h:
        (JSC::GetByIdVariant::intrinsicFunction):
        (JSC::GetByIdVariant::intrinsic):
        (JSC::GetByIdVariant::callLinkStatus): Deleted.
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::addWatchpoint):
        (JSC::AccessGenerationState::restoreScratch):
        (JSC::AccessGenerationState::succeed):
        (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
        (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
        (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
        (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
        (JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
        (JSC::AccessGenerationState::originalExceptionHandler):
        (JSC::AccessGenerationState::originalCallSiteIndex):
        (JSC::AccessCase::getIntrinsic):
        (JSC::AccessCase::clone):
        (JSC::AccessCase::visitWeak):
        (JSC::AccessCase::generate):
        (WTF::printInternal):
        (JSC::AccessCase::AccessCase): Deleted.
        (JSC::AccessCase::get): Deleted.
        (JSC::AccessCase::replace): Deleted.
        (JSC::AccessCase::transition): Deleted.
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::isGet):
        (JSC::AccessCase::isPut):
        (JSC::AccessCase::isIn):
        (JSC::AccessCase::intrinsicFunction):
        (JSC::AccessCase::intrinsic):
        (JSC::AccessGenerationState::AccessGenerationState):
        (JSC::AccessGenerationState::liveRegistersForCall):
        (JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
        (JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation):
        (JSC::AccessGenerationState::needsToRestoreRegistersIfException):
        (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * bytecode/PutByIdVariant.h:
        (JSC::PutByIdVariant::intrinsic):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::alreadyChecked):
        (JSC::DFG::arrayTypeToString):
        (JSC::DFG::toTypedArrayType):
        (JSC::DFG::refineTypedArrayType):
        (JSC::DFG::permitsBoundsCheckLowering):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::supportsLength):
        (JSC::DFG::ArrayMode::isSomeTypedArrayView):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
        (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
        (JSC::DFG::ByteCodeParser::load):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::presenceLike): Deleted.
        (JSC::DFG::ByteCodeParser::store): Deleted.
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::convertToGetArrayLength): Deleted.
        (JSC::DFG::FixupPhase::prependGetArrayLength): Deleted.
        (JSC::DFG::FixupPhase::fixupChecksInBlock): Deleted.
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::tryGetFoldableView):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetArrayLength):
        * jit/IntrinsicEmitter.cpp: Added.
        (JSC::AccessCase::canEmitIntrinsicGetter):
        (JSC::AccessCase::emitIntrinsicGetter):
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        * runtime/Intrinsic.h:
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::put):
        (JSC::JSArrayBufferView::defineOwnProperty):
        (JSC::JSArrayBufferView::deleteProperty):
        (JSC::JSArrayBufferView::getOwnNonIndexPropertyNames):
        (JSC::JSArrayBufferView::getOwnPropertySlot): Deleted.
        (JSC::JSArrayBufferView::finalize): Deleted.
        * runtime/JSDataView.cpp:
        (JSC::JSDataView::getOwnPropertySlot):
        (JSC::JSDataView::put):
        (JSC::JSDataView::defineOwnProperty):
        (JSC::JSDataView::deleteProperty):
        (JSC::JSDataView::getOwnNonIndexPropertyNames):
        * runtime/JSDataView.h:
        * runtime/JSFunction.h:
        * runtime/JSFunctionInlines.h:
        (JSC::JSFunction::intrinsic):
        * runtime/JSGenericTypedArrayView.h:
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
        (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
        (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex): Deleted.
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Deleted.
        * runtime/JSObject.cpp:
        (JSC::JSObject::putDirectNativeIntrinsicGetter):
        * runtime/JSObject.h:
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        * tests/stress/typedarray-add-property-to-base-object.js: Added.
        (body.foo):
        (body):
        * tests/stress/typedarray-bad-getter.js: Added.
        (body.foo):
        (body.get Bar):
        (body):
        * tests/stress/typedarray-getter-on-self.js: Added.
        (body.foo):
        (body.bar):
        (body.baz):
        (body.get for):
        (body):
        * tests/stress/typedarray-intrinsic-getters-change-prototype.js: Added.
        (body.foo):
        (body.bar):
        (body.baz):
        (body):

2015-10-16  Keith Miller  <keith_miller@apple.com>

        Fix some issues with TypedArrays
        https://bugs.webkit.org/show_bug.cgi?id=150216

        Reviewed by Geoffrey Garen.

        This fixes a couple of issues:
        1) The DFG had a separate case for creating new typedarrays in the dfg when the first argument is an object.
           Since the code for creating a Typedarray in the dfg is almost the same as the code in Baseline/LLInt
           the two cases have been merged.
        2) If the length property on an object was unset then the construction could crash.
        3) The TypedArray.prototype.set function and the TypedArray constructor should not call [[Get]] for the
           length of the source object when the source object is a TypedArray.
        4) The conditions that were used to decide if the iterator could be skipped were incorrect.
           Instead of checking for have a bad time we should have checked the Indexing type did not allow for
           indexed accessors.

        * dfg/DFGOperations.cpp:
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewWithArguments):
        (JSC::constructGenericTypedArrayView):
        (JSC::constructGenericTypedArrayViewWithFirstArgument): Deleted.

2015-10-16  Anders Carlsson  <andersca@apple.com>

        Fix Windows build.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:

2015-10-16  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r191175): Still crashing when clicking back button on netflix.com
        https://bugs.webkit.org/show_bug.cgi?id=150251

        Rubber stamped by Filip Pizlo.

        Turning off Tail Calls and disabling tests until the crash is fixed.

        * runtime/Options.h:
        * tests/es6.yaml:
        * tests/stress/dfg-tail-calls.js:
        (nonInlinedTailCall.callee):
        * tests/stress/mutual-tail-call-no-stack-overflow.js:
        (shouldThrow):
        * tests/stress/tail-call-in-inline-cache.js:
        (tail):
        * tests/stress/tail-call-no-stack-overflow.js:
        (shouldThrow):
        * tests/stress/tail-call-recognize.js:
        (callerMustBeRun):
        * tests/stress/tail-call-varargs-no-stack-overflow.js:
        (shouldThrow):

2015-10-16  Mark Lam  <mark.lam@apple.com>

        Add MacroAssembler::callProbe() for supporting lambda JIT probes.
        https://bugs.webkit.org/show_bug.cgi?id=150186

        Reviewed by Geoffrey Garen.

        With callProbe(), we can now make probes that are lambdas.  For example, we can
        now conveniently add probes like so: 

            // When you know exactly which register you want to inspect:
            jit.callProbe([] (MacroAssembler::ProbeContext* context) {
                intptr_t value = reinterpret_cast<intptr_t>(context->cpu.eax);
                dataLogF("eax %p\n", context->cpu.eax); // Inspect the register.
                ASSERT(value > 10); // Add test code for debugging.
            });

            // When you want to inspect whichever register the JIT allocated:
            auto reg = op1.gpr();
            jit.callProbe([reg] (MacroAssembler::ProbeContext* context) {
                intptr_t value = reinterpret_cast<intptr_t>(context->gpr(reg));
                dataLogF("reg %s: %ld\n", context->gprName(reg), value);
                ASSERT(value > 10);
            });

        callProbe() is only meant to be used for debugging sessions.  It is not
        appropriate to use it in permanent code (even for debug builds).
        This is because:
        1. The probe mechanism saves and restores all (and I really mean "all")
           registers, and is inherently slow.
        2. callProbe() currently works by allocating (via new) a std::function to
           guarantee that it is persisted for the duration that the JIT generated code is
           live.  We don't currently delete it ever i.e. it leaks a bit of memory each
           time the JIT generates code that contains such a lambda probe.

        These limitations are acceptable for a debugging session (assuming you're not
        debugging a memory leak), but not for deployment code.  If there's a need, we can
        plug that leak in another patch.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::CPUState::fpr):
        - Removed an unnecessary empty line.
        (JSC::AbstractMacroAssembler::ProbeContext::gpr):
        (JSC::AbstractMacroAssembler::ProbeContext::fpr):
        (JSC::AbstractMacroAssembler::ProbeContext::gprName):
        (JSC::AbstractMacroAssembler::ProbeContext::fprName):
        - Added some convenience functions that will make using the probe mechanism
          easier.

        * assembler/MacroAssembler.cpp:
        (JSC::StdFunctionData::StdFunctionData):
        (JSC::stdFunctionCallback):
        (JSC::MacroAssembler::callProbe):
        * assembler/MacroAssembler.h:

2015-10-16  Andreas Kling  <akling@apple.com>

        Remove unused StructureRareData::m_cachedGenericPropertyNameEnumerator.
        <https://webkit.org/b/150244>

        Reviewed by Geoffrey Garen.

        Remove an unused field from StructureRareData.

        * runtime/StructureRareData.cpp:
        (JSC::StructureRareData::visitChildren): Deleted.
        * runtime/StructureRareData.h:

2015-10-16  Keith Miller  <keith_miller@apple.com>

        Unreviewed, rolling out r191190.

        Patch needs some design changes.

        Reverted changeset:

        "Fix some issues with TypedArrays"
        https://bugs.webkit.org/show_bug.cgi?id=150216
        http://trac.webkit.org/changeset/191190

2015-10-16  Mark Lam  <mark.lam@apple.com>

        Move all the probe trampolines into their respective MacroAssembler files.
        https://bugs.webkit.org/show_bug.cgi?id=150239

        Reviewed by Saam Barati.

        This patch does not introduce any behavior changes.  It only moves the
        ctiMasmProbeTrampoline implementations from the respective JITStubs<CPU>.h
        files to the corresponding MacroAssembler<CPU>.cpp files. 

        I also had to make some minor changes to get the code to build after this move:
        1. Added #include <wtf/InlineASM.h> in the MacroAssembler<CPU>.cpp files
           because the ctiMasmProbeTrampoline is an inline assembly blob.
        2. In the moved code, convert MacroAssembler:: qualifiers to the CPU specific
           MacroAssembler equivalent.  The referenced entities were always defined in
           the CPU specific MacroAssembler anyway, and indirectly referenced through
           the generic MacroAssembler.

        With this, we can get rid of all the JITStubs<CPU>.cpp files.  There is one
        exception: JITStubsMSVC64.asm.  However, that one is unrelated to the probe
        mechanism.  So, I'll leave it as is.

        We can also remove JITStubs.cpp and JITStubs.h which are now empty except for
        some stale unused code.

        This patch has been build tested for x86, x86_64, armv7, and arm64.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerARM.cpp:
        (JSC::MacroAssemblerARM::probe):
        * assembler/MacroAssemblerARM64.cpp:
        (JSC::arm64ProbeTrampoline):
        (JSC::MacroAssemblerARM64::probe):
        * assembler/MacroAssemblerARMv7.cpp:
        (JSC::MacroAssemblerARMv7::probe):
        * assembler/MacroAssemblerX86Common.cpp:
        * bytecode/CodeBlock.cpp:
        * ftl/FTLCompile.cpp:
        * ftl/FTLLink.cpp:
        * jit/JITArithmetic.cpp:
        * jit/JITArithmetic32_64.cpp:
        * jit/JITCode.h:
        * jit/JITExceptions.cpp:
        * jit/JITStubs.cpp: Removed.
        * jit/JITStubs.h: Removed.
        * jit/JITStubsARM.h: Removed.
        * jit/JITStubsARM64.h: Removed.
        * jit/JITStubsARMv7.h: Removed.
        * jit/JITStubsX86.h: Removed.
        * jit/JITStubsX86Common.h: Removed.
        * jit/JITStubsX86_64.h: Removed.
        * jit/JSInterfaceJIT.h:
        * llint/LLIntOffsetsExtractor.cpp:
        * runtime/CommonSlowPaths.cpp:

2015-10-16  Keith Miller  <keith_miller@apple.com>

        Fix some issues with TypedArrays
        https://bugs.webkit.org/show_bug.cgi?id=150216

        Reviewed by Michael Saboff.

        This fixes a couple of issues:
        1) The DFG had a separate case for creating new typedarrays in the dfg when the first argument is an object.
           Since the code for creating a Typedarray in the dfg is almost the same as the code in Baseline/LLInt
           the two cases have been merged.
        2) If the length property on an object was unset then the construction could crash.
        3) The TypedArray.prototype.set function and the TypedArray constructor should not call [[Get]] for the
           length of the source object when the source object is a TypedArray.
        4) The conditions that were used to decide if the iterator could be skipped were incorrect.
           Instead of checking for have a bad time we should have checked the Indexing type did not allow for
           indexed accessors.

        * dfg/DFGOperations.cpp:
        (JSC::DFG::newTypedArrayWithOneArgument): Deleted.
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::constructGenericTypedArrayViewFromIterator):
        (JSC::constructGenericTypedArrayViewWithFirstArgument):
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncSet):
        * tests/stress/typedarray-construct-iterator.js: Added.
        (iterator.return.next):
        (iterator):
        (body):

2015-10-15  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r190289): Repro crash clicking back button on netflix.com
        https://bugs.webkit.org/show_bug.cgi?id=150220

        Reviewed by Geoffrey Garen.

        Since constructors check for a valid new "this" object and return it, we can't make
        a tail call to another function from within a constructor.

        Re-enabled the tail calls and the related tail call tests.

        Did some other miscellaneous clean up in the tail call code as part of the debugging.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
        * interpreter/Interpreter.h:
        (JSC::calleeFrameForVarargs):
        * runtime/Options.h:
        * tests/es6.yaml:
        * tests/stress/dfg-tail-calls.js:
        (nonInlinedTailCall.callee):
        * tests/stress/mutual-tail-call-no-stack-overflow.js:
        (shouldThrow):
        * tests/stress/tail-call-in-inline-cache.js:
        (tail):
        * tests/stress/tail-call-no-stack-overflow.js:
        (shouldThrow):
        * tests/stress/tail-call-recognize.js:
        (callerMustBeRun):
        * tests/stress/tail-call-varargs-no-stack-overflow.js:
        (shouldThrow):

2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed. Attempted EFL build fix 2 after r191159.

        * PlatformEfl.cmake:

2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed. Attempted EFL build fix after r191159.

        * PlatformEfl.cmake:

2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed. Build fix after r191160.

        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::didGarbageCollect):

2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed. Revert part of r191159 which caused ASSERTs.

        A review comment suggested using WeakPtr. It is not suitable
        here and causes ASSERTs across threads. Will address separately.

        * inspector/agents/InspectorHeapAgent.h:
        * inspector/agents/InspectorHeapAgent.cpp:
        (Inspector::InspectorHeapAgent::didGarbageCollect):
        (Inspector::InspectorHeapAgent::InspectorHeapAgent): Deleted.

2015-10-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Include Garbage Collection Event in Timeline
        https://bugs.webkit.org/show_bug.cgi?id=142510

        Reviewed by Geoffrey Garen and Brian Burg.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        Include new files in the build.

        * heap/HeapObserver.h:
        (JSC::HeapObserver::~HeapObserver):
        * heap/Heap.cpp:
        (JSC::Heap::willStartCollection):
        (JSC::Heap::didFinishCollection):
        * heap/Heap.h:
        (JSC::Heap::addObserver):
        (JSC::Heap::removeObserver):
        Allow observers on heap to add hooks for starting / ending garbage collection.

        * inspector/InspectorEnvironment.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::vm):
        * inspector/JSGlobalObjectInspectorController.h:
        Access the VM through the InspectorEnvironment as it won't change.

        * inspector/agents/InspectorHeapAgent.cpp: Added.
        (Inspector::InspectorHeapAgent::InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::didCreateFrontendAndBackend):
        (Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
        (Inspector::InspectorHeapAgent::enable):
        (Inspector::InspectorHeapAgent::disable):
        (Inspector::InspectorHeapAgent::gc):
        (Inspector::protocolTypeForHeapOperation):
        (Inspector::InspectorHeapAgent::willGarbageCollect):
        (Inspector::InspectorHeapAgent::didGarbageCollect):
        * inspector/agents/InspectorHeapAgent.h: Added.
        * inspector/protocol/Heap.json: Added.
        New domain and agent to handle tasks related to the JavaScriptCore heap.

2015-10-15  Commit Queue  <commit-queue@webkit.org>

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

        This patch causes 50+ LayoutTest crashes related to the
        inspector (Requested by ryanhaddad on #webkit).

        Reverted changeset:

        "Web Inspector: JavaScriptCore should parse sourceURL and
        sourceMappingURL directives"
        https://bugs.webkit.org/show_bug.cgi?id=150096
        http://trac.webkit.org/changeset/191135

2015-10-15  Geoffrey Garen  <ggaren@apple.com>

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

        We're seeing some crashes in GC beneath speculationFromCell. Maybe this
        patch caused them?

        Reverted changeset:

        CodeBlock write barriers should be precise
        https://bugs.webkit.org/show_bug.cgi?id=150042
        http://trac.webkit.org/changeset/191003

2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: JavaScriptCore should parse sourceURL and sourceMappingURL directives
        https://bugs.webkit.org/show_bug.cgi?id=150096

        Reviewed by Geoffrey Garen.

        * inspector/ContentSearchUtilities.cpp:
        (Inspector::ContentSearchUtilities::scriptCommentPattern): Deleted.
        (Inspector::ContentSearchUtilities::findScriptSourceURL): Deleted.
        (Inspector::ContentSearchUtilities::findScriptSourceMapURL): Deleted.
        * inspector/ContentSearchUtilities.h:
        No longer need to search script content.

        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::dispatchDidParseSource):
        Carry over the sourceURL and sourceMappingURL from the SourceProvider.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::sourceMapURLForScript):
        (Inspector::InspectorDebuggerAgent::didParseSource):
        No longer do content searching.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::setCode):
        (JSC::Lexer<T>::skipWhitespace):
        (JSC::Lexer<T>::parseCommentDirective):
        (JSC::Lexer<T>::parseCommentDirectiveValue):
        (JSC::Lexer<T>::consume):
        (JSC::Lexer<T>::lex):
        * parser/Lexer.h:
        (JSC::Lexer::sourceURL):
        (JSC::Lexer::sourceMappingURL):
        (JSC::Lexer::sourceProvider): Deleted.
        Give lexer the ability to detect script comment directives.
        This just consumes characters in single line comments and
        ultimately sets the sourceURL or sourceMappingURL found.

        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        * parser/SourceProvider.h:
        (JSC::SourceProvider::url):
        (JSC::SourceProvider::sourceURL):
        (JSC::SourceProvider::sourceMappingURL):
        (JSC::SourceProvider::setSourceURL):
        (JSC::SourceProvider::setSourceMappingURL):
        After parsing a script, update the Source Provider with the
        value of directives that may have been found in the script.

2015-10-15  Filip Pizlo  <fpizlo@apple.com>

        InferredTypeTable should ref its keys
        https://bugs.webkit.org/show_bug.cgi?id=150138
        rdar://problem/23080555

        Reviewed by Michael Saboff.

        InferredTypeTable was incorrectly using a key hash traits that caused the underlying HashTable to
        store keys as UniquedStringImpl* rather than RefPtr<UniquedStringImpl>, even though the HashMap's
        nominal key type was RefPtr<UniquedStringImpl>. This arose because I copy-pasted the HashMap type
        instantiation from other places and then made random changes to adapt it to my needs, rather than
        actually thinking about what I was doing. The solution is to remove the key hash traits argument,
        since all it accomplishes is to produce this bug.

        The way this bug manifested is probably best described in http://webkit.org/b/150008. After a while
        the InferredTypeTable would have dangling references to its strings, if some recompilation or other
        thing caused us to drop all other references to those strings. InferredTypeTable is particularly
        susceptible to this because it is designed to know about a superset of the property names that its
        client Structures know about. The debug assert would then happen when we rehashed the
        InferredTypeTable's HashMap, because we'd try to get the hashes of strings that were already
        deleted. AFAICT, we didn't have release crashes arising from those strings' memory being returned
        to the OS - but it's totally possible that this could have happened. So, we definitely should treat
        this bug as more than just a debug issue.

        Interestingly, we could have also solved this problem by changing the hash function to use PtrHash.
        In all other ways, it's OK for InferredTypeTable to hold dangling references, since it uses the
        address of the UniquedStringImpl as a way to name an abstract heap. It's fine if the name of an
        abstract heap is a bogus memory address, and it's also fine if that name referred to an entirely
        different UniquedStringImpl at some point in the past. That's a nice benefit of any data structure
        that keys by abstract heap - if two of them get unified then it's no big deal. I've filed another
        bug, http://webkit.org/b/150137 about changing all of our UniquedStringImpl* hashing to use
        PtrHash.

        * runtime/Identifier.h: Add a comment about http://webkit.org/b/150137.
        * runtime/InferredTypeTable.h: Fix the bug.
        * tests/stress/inferred-type-table-stale-identifiers.js: Added. I couldn't get this to cause a crash before my change, but it's an interesting test nonetheless.

2015-10-15  Mark Lam  <mark.lam@apple.com>

        Add MASM_PROBE support for ARM64.
        https://bugs.webkit.org/show_bug.cgi?id=150128

        Reviewed by Michael Saboff.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARM64Assembler.h:
        - Convert the ARM64 registers enum list into a macro list so that we can use
          it elsewhere e.g. to declare fields in the probe CPUState.
          Also de-tabbed the contents of the ARM64Registers namespace since the enum
          list change touches almost all of it anyway. This reduces the amount of
          complaints from the style checker.

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::CPUState::registerName):
        (JSC::AbstractMacroAssembler::CPUState::registerValue):
        - Change CPUState methods to allow for registers ID that do not map to one of
          its fields. This is needed because ARM64's registers include aliases for some
          register names. The CPUState will not allocate separate storage for the
          aliases. 

        * assembler/MacroAssemblerARM64.cpp: Added.
        (JSC::arm64ProbeTrampoline):
        - Unlike the probe mechanism for other CPUs, the ARM64 implementation does not
          allow the probe function to modify the sp and pc registers.  We insert this
          wrapper function between ctiMasmProbeTrampoline() and the user's probe function
          so that we can check if the user tried to modify sp and pc.  If so, we will
          print an error message so that we can alert the user that we don't support
          that on ARM64.

          See the comment in ctiMasmProbeTrampoline() in JITStubsARM64.h for details
          on why we cannot support sp and pc modifications by the probe function.

        (JSC::MacroAssemblerARM64::probe):

        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::repatchCall):
        (JSC::MacroAssemblerARM64::makeBranch):
        * jit/JITStubs.cpp:
        * jit/JITStubsARM64.h: Added.

2015-10-15  Mark Lam  <mark.lam@apple.com>

        Fix some typos in comments.
        https://bugs.webkit.org/show_bug.cgi?id=150181

        Rubber stamped by Michael Saboff.

        * jit/JITStubsARM.h:
        * jit/JITStubsARMv7.h:

2015-10-15  Mark Lam  <mark.lam@apple.com>

        Refactoring: give the MASM probe CPUState methods shorter names.
        https://bugs.webkit.org/show_bug.cgi?id=150177

        Reviewed by Michael Saboff.

        The existing names are longer than they need to be.  Renaming them as follows:
            For GPR, registerName ==> gprName
            For GPR, registerValue ==> gpr
            For FPR, registerName ==> fprName
            For FPR, registerValue ==> fpr

        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::CPUState::gprName):
        (JSC::AbstractMacroAssembler::CPUState::fprName):
        (JSC::AbstractMacroAssembler::CPUState::gpr):
        (JSC::AbstractMacroAssembler::CPUState::fpr):
        (JSC::AbstractMacroAssembler::CPUState::registerName): Deleted.
        (JSC::AbstractMacroAssembler::CPUState::registerValue): Deleted.

        * assembler/MacroAssemblerPrinter.cpp:
        (JSC::printRegister):
        (JSC::printMemory):
        - Updated to use the new names.

2015-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Class expression should have lexical environment that has itself as an imutable binding
        https://bugs.webkit.org/show_bug.cgi?id=150089

        Reviewed by Geoffrey Garen.

        According to ES6 spec, class expression has its own lexical environment that holds itself
        as an immutable binding[1] (section 14.5.14 step 2, 3, 4, 23)

        As a result, even if the binding declared in the outer scope is overridden, methods inside
        class expression can refer its class by the class name.

        [1]: http://ecma-international.org/ecma-262/6.0/#sec-runtime-semantics-classdefinitionevaluation

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ClassExprNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createClassExpr):
        * parser/NodeConstructors.h:
        (JSC::ClassExprNode::ClassExprNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createClassExpr):
        * tests/es6.yaml:
        * tests/stress/class-expression-generates-environment.js: Added.
        (shouldBe):
        (shouldThrow):
        (prototype.method):
        (staticMethod):
        (A.prototype.method):
        (A.staticMethod):
        (A):
        * tests/stress/class-expression-should-be-tdz-in-heritage.js: Added.
        (shouldThrow):
        (shouldThrow.A):

2015-10-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Class method should not declare any variables to upper scope.
        https://bugs.webkit.org/show_bug.cgi?id=150115

        Reviewed by Geoffrey Garen.

        In the current implementation, class methods attempt to declare variables to an upper scope with their method names.
        But this is not specified behavior in the ES6 spec.

        And as a result, previously, we attempted to declare variables with invalid identifiers.
        For example, `class A { 1() { } }` attempt to declare a variable with name `1`.
        This (declaring variables with incorrect names) is not allowed in the lexical environment.
        And it fires assertions in https://bugs.webkit.org/show_bug.cgi?id=150089.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass): Deleted.
        * tests/stress/class-method-does-not-declare-variable-to-upper-scope.js: Added.
        (shouldBe):
        (A.prototype.method):
        (A.staticMethod):
        (A):

2015-10-14  Joseph Pecoraro  <pecoraro@apple.com>

        REGRESSION: Web Inspector hangs for many seconds when trying to reload page
        https://bugs.webkit.org/show_bug.cgi?id=150065

        Reviewed by Mark Lam.

        When debugging Web Pages, the same Debugger (PageScriptDebugServer) is
        attached to each of the different JSGlobalObjects on the page. This could
        mean multiple frames or isolated scripting contexts. Therefore we should
        only need to send sourceParsed events to the frontend for scripts within
        this new JSGlobalObject, not any JSGlobalObject that has this debugger.

        * debugger/Debugger.cpp:
        (JSC::Debugger::attach):
        Only send sourceParsed events for Scripts in this JSGlobalObject.

2015-10-14  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unimplemented methods in CopiedSpace
        https://bugs.webkit.org/show_bug.cgi?id=150143

        Reviewed by Andreas Kling.

        * heap/CopiedSpace.h:

2015-10-14  Brent Fulgham  <bfulgham@apple.com>

        [Win] Enforce launcher/library naming scheme
        https://bugs.webkit.org/show_bug.cgi?id=150124

        Reviewed by Alex Christensen.

        * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Look for
        {name}Lib.dll instead of {name}.dll.
        (wWinMain):
        * shell/PlatformWin.cmake: Add 'Lib' suffix to DLLs.

2015-10-14  Keith Miller  <keith_miller@apple.com>

        ES6 Fix TypedArray constructors.
        https://bugs.webkit.org/show_bug.cgi?id=149975

        Reviewed by Geoffrey Garen.

        The ES6 spec requires that any object argument passed to a TypedArray constructor that is not a TypedArray
        and has an iterator should use the iterator to construct the TypedArray. To avoid performance regressions related
        to iterating we check if the iterator attached to the object points to the generic array iterator and length is a value.
        If so, we do not use the iterator since there should be no observable difference. Another other interesting note is
        that the ES6 spec has the of and from functions on a shared constructor between all the TypedArray constructors.
        When the TypedArray is constructed the expectation is to crawl the prototype chain of the this value
        passed to the function. If the function finds a known TypedArray constructor (Int32Array, Float64Array,...) then
        it creates a TypedArray of that type. This is implemented by adding a private function (@allocateTypedArray) to each
        of the constructors that can be called in order to construct the array. By using the private functions the JIT should
        hopefully be able to optimize this to a direct call.

        * CMakeLists.txt:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/TypedArrayConstructor.js: Added.
        (of):
        (from):
        (allocateInt8Array):
        (allocateInt16Array):
        (allocateInt32Array):
        (allocateUint32Array):
        (allocateUint16Array):
        (allocateUint8Array):
        (allocateUint8ClampedArray):
        (allocateFloat32Array):
        (allocateFloat64Array):
        * runtime/CommonIdentifiers.h:
        * runtime/JSDataView.cpp:
        (JSC::JSDataView::setIndex):
        * runtime/JSDataView.h:
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
        * runtime/JSGenericTypedArrayViewConstructor.h:
        * runtime/JSGenericTypedArrayViewConstructorInlines.h:
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
        (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::create):
        (JSC::constructGenericTypedArrayViewFromIterator):
        (JSC::constructGenericTypedArrayView):
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSTypedArrayViewConstructor.cpp: Added.
        (JSC::JSTypedArrayViewConstructor::JSTypedArrayViewConstructor):
        (JSC::JSTypedArrayViewConstructor::finishCreation):
        (JSC::JSTypedArrayViewConstructor::create):
        (JSC::JSTypedArrayViewConstructor::createStructure):
        (JSC::constructTypedArrayView):
        (JSC::JSTypedArrayViewConstructor::getConstructData):
        (JSC::JSTypedArrayViewConstructor::getCallData):
        * runtime/JSTypedArrayViewConstructor.h: Copied from Source/JavaScriptCore/runtime/JSGenericTypedArrayViewConstructor.h.
        * runtime/JSTypedArrayViewPrototype.cpp:
        (JSC::JSTypedArrayViewPrototype::create):
        * tests/es6.yaml:
        * tests/stress/resources/typedarray-constructor-helper-functions.js: Added.
        (forEachTypedArray):
        (hasSameValues):
        (foo):
        (testConstructorFunction):
        (testConstructor):
        * tests/stress/typedarray-constructor.js: Added.
        (A):
        (iterator.return.next):
        (iterator):
        (obj.valueOf):
        (iterator2.return.next):
        (iterator2):
        * tests/stress/typedarray-from.js: Added.
        (even):
        (isBigEnoughAndException):
        * tests/stress/typedarray-of.js: Added.

2015-10-14  Mark Lam  <mark.lam@apple.com>

        Rename some JSC option names to be more uniform.
        https://bugs.webkit.org/show_bug.cgi?id=150127

        Reviewed by Geoffrey Garen.

        Renaming JSC_enableXXX options to JSC_useXXX, and JSC_showXXX options to JSC_dumpXXX.
        Also will renaming a few other miscellaneous to options, to abide by this scheme.

        Also renaming some functions to match the option names where relevant.

        * API/tests/ExecutionTimeLimitTest.cpp:
        (testExecutionTimeLimit):
        * assembler/AbstractMacroAssembler.h:
        (JSC::optimizeForARMv7IDIVSupported):
        (JSC::optimizeForARM64):
        (JSC::optimizeForX86):
        * assembler/LinkBuffer.cpp:
        (JSC::shouldDumpDisassemblyFor):
        (JSC::LinkBuffer::finalizeCodeWithoutDisassembly):
        (JSC::shouldShowDisassemblyFor): Deleted.
        * assembler/LinkBuffer.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::jettison):
        * bytecode/CodeBlockJettisoningWatchpoint.cpp:
        (JSC::CodeBlockJettisoningWatchpoint::fireInternal):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
        (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire):
        * dfg/DFGAdaptiveStructureWatchpoint.cpp:
        (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGCommon.h:
        (JSC::DFG::leastUpperBound):
        (JSC::DFG::shouldDumpDisassembly):
        (JSC::DFG::shouldShowDisassembly): Deleted.
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compileImpl):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::JITCompiler):
        (JSC::DFG::JITCompiler::disassemble):
        * dfg/DFGJumpReplacement.cpp:
        (JSC::DFG::JumpReplacement::fire):
        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitFuzz.h:
        (JSC::DFG::doOSRExitFuzzing):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileArithSqrt):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::~JITCode):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        (JSC::FTL::compileFTLOSRExit):
        * ftl/FTLState.h:
        (JSC::FTL::verboseCompilationEnabled):
        (JSC::FTL::shouldDumpDisassembly):
        (JSC::FTL::shouldShowDisassembly): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::addToRememberedSet):
        (JSC::Heap::didFinishCollection):
        (JSC::Heap::shouldDoFullCollection):
        * heap/Heap.h:
        (JSC::Heap::isDeferred):
        (JSC::Heap::structureIDTable):
        * heap/HeapStatistics.cpp:
        (JSC::StorageStatistics::storageCapacity):
        (JSC::HeapStatistics::dumpObjectStatistics):
        (JSC::HeapStatistics::showObjectStatistics): Deleted.
        * heap/HeapStatistics.h:
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::Frame::createArguments):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::callExceptionFuzz):
        * jit/ExecutableAllocationFuzz.cpp:
        (JSC::doExecutableAllocationFuzzing):
        * jit/ExecutableAllocationFuzz.h:
        (JSC::doExecutableAllocationFuzzingIfEnabled):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JITCode.cpp:
        (JSC::JITCodeWithCodeRef::~JITCodeWithCodeRef):
        * jit/PolymorphicCallStubRoutine.cpp:
        (JSC::PolymorphicCallNode::unlink):
        (JSC::PolymorphicCallNode::clearCallLinkInfo):
        (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
        * jit/Repatch.cpp:
        (JSC::linkFor):
        (JSC::unlinkFor):
        (JSC::linkVirtualFor):
        * jsc.cpp:
        (functionEnableExceptionFuzz):
        (jscmain):
        * llvm/InitializeLLVM.cpp:
        (JSC::initializeLLVMImpl):
        * runtime/ExceptionFuzz.cpp:
        (JSC::doExceptionFuzzing):
        * runtime/ExceptionFuzz.h:
        (JSC::doExceptionFuzzingIfEnabled):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        (JSC::Options::initialize):
        (JSC::Options::dumpOptionsIfNeeded):
        (JSC::Options::setOption):
        (JSC::Options::dumpAllOptions):
        (JSC::Options::dumpAllOptionsInALine):
        (JSC::Options::dumpOption):
        * runtime/Options.h:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::exceptionFuzzingBuffer):
        * runtime/WriteBarrierInlines.h:
        (JSC::WriteBarrierBase<T>::set):
        (JSC::WriteBarrierBase<Unknown>::set):
        * tests/executableAllocationFuzz.yaml:
        * tests/stress/arrowfunction-typeof.js:
        * tests/stress/disable-function-dot-arguments.js:
        (foo):
        * tests/stress/math-sqrt-basics-disable-architecture-specific-optimizations.js:
        (sqrtOnInteger):
        * tests/stress/regress-148564.js:

2015-10-14  Mark Lam  <mark.lam@apple.com>

        Speculative build fix: the CallSiteIndex constructor is explicit and requires an uint32_t.

        Not Reviewed.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):

2015-10-14  Commit Queue  <commit-queue@webkit.org>

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

        caused js/class-syntax-method-names.html to crash on debug
        builds (Requested by alexchristensen_ on #webkit).

        Reverted changeset:

        "[ES6] Class expression should have lexical environment that
        has itself as an imutable binding"
        https://bugs.webkit.org/show_bug.cgi?id=150089
        http://trac.webkit.org/changeset/191030

2015-10-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Class expression should have lexical environment that has itself as an imutable binding
        https://bugs.webkit.org/show_bug.cgi?id=150089

        Reviewed by Geoffrey Garen.

        According to ES6 spec, class expression has its own lexical environment that holds itself
        as an immutable binding[1] (section 14.5.14 step 2, 3, 4, 23)

        As a result, even if the binding declared in the outer scope is overridden, methods inside
        class expression can refer its class by the class name.

        [1]: http://ecma-international.org/ecma-262/6.0/#sec-runtime-semantics-classdefinitionevaluation

        * bytecompiler/NodesCodegen.cpp:
        (JSC::ClassExprNode::emitBytecode):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createClassExpr):
        * parser/NodeConstructors.h:
        (JSC::ClassExprNode::ClassExprNode):
        * parser/Nodes.h:
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createClassExpr):
        * tests/es6.yaml:
        * tests/stress/class-expression-generates-environment.js: Added.
        (shouldBe):
        (shouldThrow):
        (prototype.method):
        (staticMethod):
        (A.prototype.method):
        (A.staticMethod):
        (A):
        * tests/stress/class-expression-should-be-tdz-in-heritage.js: Added.
        (shouldThrow):
        (shouldThrow.A):

2015-10-13  Saam barati  <sbarati@apple.com>

        We were creating a GCAwareJITStubRoutineWithExceptionHandler when we didn't actually have an exception handler in the CodeBlock's exception handler table
        https://bugs.webkit.org/show_bug.cgi?id=150016

        Reviewed by Geoffrey Garen.

        There was a bug where we created a GCAwareJITStubRoutineWithExceptionHandler
        for inline caches that were custom setters/getters (but not JS getters/setters).
        This is wrong; we only create GCAwareJITStubRoutineWithExceptionHandler when we have
        an inline cache with a JS getter/setter call which causes the inline cache to add itself
        to the CodeBlock's exception handling table. The problem was that we created
        a GCAwareJITStubRoutineWithExceptionHandler that tried to remove itself from
        the exception handler table only to find out that it didn't have an entry in the table.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerate):

2015-10-13  Joseph Pecoraro  <pecoraro@apple.com>

        Simplify WeakBlock visit and reap phases
        https://bugs.webkit.org/show_bug.cgi?id=150045

        Reviewed by Geoffrey Garen.

        WeakBlock visiting and reaping both happen after MarkedBlock marking.
        All the MarkedBlocks we encounter should be either Marked or Retired.

        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::isMarkedOrRetired):
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::visit):
        (JSC::WeakBlock::reap):
        * heap/WeakBlock.h:

2015-10-12  Geoffrey Garen  <ggaren@apple.com>

        CodeBlock write barriers should be precise
        https://bugs.webkit.org/show_bug.cgi?id=150042

        Reviewed by Saam Barati.

        CodeBlock performs lots of unnecessary write barriers. This wastes
        performance and makes the code a bit harder to follow, and it might mask
        important bugs. Now is a good time to unmask important bugs.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlockSet::mark): Don't write barrier all CodeBlocks on the
        stack. Only CodeBlocks that do value profiling need write barriers, and
        they do those themselves.

        In steady state, when most of our CodeBlocks are old and FTL-compiled,
        and we're doing eden GC's, we should almost never visit a CodeBlock.

        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::osrWriteBarrier):
        (JSC::DFG::adjustAndJumpToTarget): Don't write barrier all inlined
        CodeBlocks on exit. That's not necessary. Instead, write barrier the 
        CodeBlock(s) we will exit to, along with the one we will write a value
        profile to.

2015-10-13  Yusuke Suzuki  <utatane.tea@gmail.com>

        REGRESSION: ASSERT (impl->isAtomic()) @ facebook.com
        https://bugs.webkit.org/show_bug.cgi?id=149965

        Reviewed by Geoffrey Garen.

        Edge filtering for CheckIdent ensures that a given value is either Symbol or StringIdent.
        However, this filtering is not applied to CheckIdent when propagating a constant value in
        the constant folding phase. As a result, it is not guaranteeed that a constant value
        propagated in constant folding is Symbol or StringIdent.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):

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

        Unreviewed, register symbol structure to fix Debug build
        https://bugs.webkit.org/show_bug.cgi?id=149622

        Since InferredTypes for String or Symbol claim that they don't have any structure,
        `registerInferredType` does not register the structure for Symbol.
        We take the similar way to String to fix this issue; Registering Symbol structure
        explicitly in DFGStructureRegisterationPhase. Because,

        1. InferredType::structure is only allowed for ObjectWithStructure / ObjectWithStructureOrOther.
           It looks clear to me that only ObjectWithStructure has structure.
        2. Symbol is similar primitive value to String. So handling its structure in similar way to String is nice.

        * dfg/DFGStructureRegistrationPhase.cpp:
        (JSC::DFG::StructureRegistrationPhase::run):

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

        Iterator loops over key twice after delete
        https://bugs.webkit.org/show_bug.cgi?id=149811

        Reviewed by Geoffrey Garen.

        When an object is the dictionary mode, JSPropertyNameEnumerator collects property names through generic property name enumeration `getPropertyNames`.
        The result vector contains indexed property names. But in this case, `publicLength()` may not be 0.
        So without disabling indexed names enumeration phase explicitly, JSPropertyNameEnumerator produces indexed property names twice.
        One in indexed name enumeration phase, and another in generic property name enumeration phase.
        This patch disables indexed names enumeration by setting `indexedLength` to 0 when collecting names through generic property name enumeration.

        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):
        * tests/stress/property-name-enumerator-should-not-look-into-indexed-values-when-it-is-a-dictionary.js: Added.
        (shouldBe):
        (col2.of.Reflect.enumerate):

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

        Introduce Symbol type for property type inference
        https://bugs.webkit.org/show_bug.cgi?id=149622

        Reviewed by Geoffrey Garen.

        This patch introduces Symbol type into property type inference.
        One of the use cases of ES6 Symbol is enum value. In this case,
        we may hold different symbols as the same property of the same structure.
        Current property type inference does not support Symbol type, so in the
        above case, the property will be inferred as Top type.

        * bytecode/PutByIdFlags.h:
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::set):
        * dfg/DFGInferredTypeCheck.cpp:
        (JSC::DFG::insertInferredTypeCheck):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::checkInferredType):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::branchIfNotType):
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/InferredType.cpp:
        (JSC::InferredType::kindForFlags):
        (JSC::InferredType::Descriptor::forValue):
        (JSC::InferredType::Descriptor::putByIdFlags):
        (JSC::InferredType::Descriptor::merge):
        (WTF::printInternal):
        * runtime/InferredType.h:
        * tests/stress/prop-type-symbol-then-object.js: Added.
        (foo):
        (bar):
        (toString):
        * tests/stress/prop-type-symbol-then-string.js: Added.
        (foo):
        (bar):

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

        Web Inspector: Rebaseline Inspector generator tests and make better use of RWIProtocol constant
        https://bugs.webkit.org/show_bug.cgi?id=150044

        Reviewed by Brian Burg.

        * inspector/scripts/codegen/generate_objc_configuration_header.py:
        (ObjCConfigurationHeaderGenerator.generate_output):
        (ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
        * inspector/scripts/codegen/generate_objc_configuration_implementation.py:
        (ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
        * inspector/scripts/codegen/generate_objc_header.py:
        (ObjCHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_internal_header.py:
        (ObjCInternalHeaderGenerator.generate_output):
        * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
        * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
        * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
        * inspector/scripts/tests/expected/enum-values.json-result:
        * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
        * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
        * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
        * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
        * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
        * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
        * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:

2015-10-12  Myles C. Maxfield  <mmaxfield@apple.com>

        Unreviewed build fix

        * runtime/JSObject.cpp:
        (JSC::JSObject::reallocateAndShrinkButterfly):

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

        GC should have a Baker barrier for concurrent copying
        https://bugs.webkit.org/show_bug.cgi?id=149852

        Reviewed by Geoffrey Garen.

        This adds a Baker-style read barrier [1] to copied space accesses. This barrier incurs some
        overhead (0%-2% depending on benchmark suite), but what it buys is the ability to make the GC copy
        phase concurrent.

        The barrier relies on copied space pointers having two "space bits" in the low pointer bits. The
        space bits indicate whether the backing store is being copied right now or not, and if it is being
        copied, what stage of copying it's in. Two barrier variants are supported:

        Read only barrier: if you load a backing store and immediately load from it without doing anything
        else, you can just mask off the bits. In the worst case, you'll get the old backing store while
        some copying thread is already allocating and populating the new version of the backing store. But
        in that case, forwarding to the new backing store will not enable you to load a more up-to-date
        value from the backing store. So, just masking the bits is enough. The read-only barrier is only
        used in ICs where we know that we are only reading, and opportunistically within the DFG and FTL
        thanks to the CopyBarrierOptimizationPhase. We never explicitly emit a read-only barrier in those
        compilers; instead the phase will turn a GetButterfly into GetButterflyReadOnly if it proves that a
        bunch of requirements are met.

        Normal barrier: if the space bits are non-zero, call a slow path. The slow path will either do
        nothing (if the copy phase hasn't started yet), or it will copy the backing store and update the
        pointer (if the copy phase hasn't gotten around to copying this particular backing store), or it
        will wait for the copying thread to finish (if some thread is copying this backing store right
        now), or it will do nothing (if by the time we called into the slow path the backing store was
        already copied). This is just like Baker's CAR/CDR barrier, but with a lock thrown in to handle
        concurrent execution.

        This is a 1% slow-down on SunSpider, a 1.5% slow-down on Octane, a 1.5% slow-down on Kraken, and a
        0% slow-down on AsmBench. Note that the Octane slow-down is excluding the SplayLatency benchmark.
        That benchmark will eventually speed up a lot once we finish doing all of this stuff. Probably, the
        JetStream splay-latency will see an even larger speed-up, since our version of the latency tests do
        a better job of punishing bad worst-case behavior.

        [1] http://dspace.mit.edu/bitstream/handle/1721.1/41976/AI_WP_139.pdf, look for the CAR and CDR
        procedures on page 9.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGCopyBarrierOptimizationPhase.cpp: Added.
        (JSC::DFG::performCopyBarrierOptimization):
        * dfg/DFGCopyBarrierOptimizationPhase.h: Added.
        * dfg/DFGDoesGC.cpp:
        (JSC::DFG::doesGC):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGHeapLocation.cpp:
        (WTF::printInternal):
        * dfg/DFGHeapLocation.h:
        * dfg/DFGLICMPhase.cpp:
        (JSC::DFG::LICMPhase::run):
        * dfg/DFGNodeType.h:
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
        (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetButterfly):
        (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGTypeCheckHoistingPhase.cpp:
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
        (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetButterfly):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetButterflyReadOnly):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileConstantStoragePointer):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckArray):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetTypedArrayByteOffset):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiGetByOffset):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiPutByOffset):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileGetDirectPname):
        (JSC::FTL::DFG::LowerDFGToLLVM::storageForTransition):
        (JSC::FTL::DFG::LowerDFGToLLVM::getById):
        (JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyWithBarrier):
        (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorWithBarrier):
        (JSC::FTL::DFG::LowerDFGToLLVM::copyBarrier):
        (JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyReadOnly):
        (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorReadOnly):
        (JSC::FTL::DFG::LowerDFGToLLVM::removeSpaceBits):
        (JSC::FTL::DFG::LowerDFGToLLVM::baseIndex):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationNewObjectWithButterfly):
        (JSC::FTL::operationPopulateObjectInOSR):
        * ftl/FTLOutput.h:
        (JSC::FTL::Output::testNonZero32):
        (JSC::FTL::Output::testIsZero64):
        (JSC::FTL::Output::testNonZero64):
        (JSC::FTL::Output::testIsZeroPtr):
        (JSC::FTL::Output::testNonZeroPtr):
        (JSC::FTL::Output::select):
        (JSC::FTL::Output::extractValue):
        * heap/CopyBarrier.h: Copied from Source/JavaScriptCore/heap/CopyWriteBarrier.h.
        (JSC::CopyBarrierBase::CopyBarrierBase):
        (JSC::CopyBarrierBase::operator!):
        (JSC::CopyBarrierBase::operator bool):
        (JSC::CopyBarrierBase::getWithoutBarrier):
        (JSC::CopyBarrierBase::get):
        (JSC::CopyBarrierBase::copyState):
        (JSC::CopyBarrierBase::setCopyState):
        (JSC::CopyBarrierBase::clear):
        (JSC::CopyBarrierBase::set):
        (JSC::CopyBarrierBase::setWithoutBarrier):
        (JSC::CopyBarrierBase::weakCASWithoutBarrier):
        (JSC::CopyBarrier::CopyBarrier):
        (JSC::CopyBarrier::getWithoutBarrier):
        (JSC::CopyBarrier::get):
        (JSC::CopyBarrier::set):
        (JSC::CopyBarrier::setWithoutBarrier):
        (JSC::CopyBarrier::weakCASWithoutBarrier):
        (JSC::CopyWriteBarrier::CopyWriteBarrier): Deleted.
        (JSC::CopyWriteBarrier::operator!): Deleted.
        (JSC::CopyWriteBarrier::operator bool): Deleted.
        (JSC::CopyWriteBarrier::get): Deleted.
        (JSC::CopyWriteBarrier::operator*): Deleted.
        (JSC::CopyWriteBarrier::operator->): Deleted.
        (JSC::CopyWriteBarrier::set): Deleted.
        (JSC::CopyWriteBarrier::setWithoutWriteBarrier): Deleted.
        (JSC::CopyWriteBarrier::clear): Deleted.
        * heap/CopyVisitorInlines.h:
        (JSC::CopyVisitor::checkIfShouldCopy):
        * heap/CopyWriteBarrier.h: Removed.
        * heap/Heap.cpp:
        (JSC::Heap::addToRememberedSet):
        (JSC::Heap::copyBarrier):
        (JSC::Heap::collectAndSweep):
        * heap/Heap.h:
        (JSC::Heap::writeBarrierBuffer):
        * heap/HeapInlines.h:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchStructure):
        (JSC::AssemblyHelpers::branchIfNotToSpace):
        (JSC::AssemblyHelpers::removeSpaceBits):
        (JSC::AssemblyHelpers::addressForByteOffset):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitSlow_op_has_indexed_property):
        (JSC::JIT::emit_op_get_direct_pname):
        (JSC::JIT::emitSlow_op_get_direct_pname):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_get_direct_pname):
        (JSC::JIT::emitSlow_op_get_direct_pname):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitDoubleLoad):
        (JSC::JIT::emitContiguousLoad):
        (JSC::JIT::emitArrayStorageLoad):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::emitSlow_op_put_by_val):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/DirectArguments.cpp:
        (JSC::DirectArguments::visitChildren):
        (JSC::DirectArguments::copyBackingStore):
        (JSC::DirectArguments::overrideThings):
        (JSC::DirectArguments::overrideThingsIfNecessary):
        (JSC::DirectArguments::overrideArgument):
        (JSC::DirectArguments::copyToArguments):
        * runtime/DirectArguments.h:
        (JSC::DirectArguments::canAccessIndexQuickly):
        (JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG):
        * runtime/JSArray.cpp:
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::fastSlice):
        (JSC::JSArray::fastConcatWith):
        (JSC::JSArray::shiftCountWithArrayStorage):
        (JSC::JSArray::shiftCountWithAnyIndexingType):
        (JSC::JSArray::unshiftCountWithAnyIndexingType):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        * runtime/JSArrayBufferView.cpp:
        (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
        (JSC::JSArrayBufferView::JSArrayBufferView):
        (JSC::JSArrayBufferView::finishCreation):
        (JSC::JSArrayBufferView::finalize):
        * runtime/JSArrayBufferView.h:
        (JSC::JSArrayBufferView::vector):
        (JSC::JSArrayBufferView::length):
        * runtime/JSArrayBufferViewInlines.h:
        (JSC::JSArrayBufferView::neuter):
        (JSC::JSArrayBufferView::byteOffset):
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::typedVector):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
        (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore):
        (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
        * runtime/JSMap.h:
        (JSC::JSMap::JSMap):
        * runtime/JSObject.cpp:
        (JSC::JSObject::copyButterfly):
        (JSC::JSObject::visitChildren):
        (JSC::JSObject::copyBackingStore):
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::enterDictionaryIndexingMode):
        (JSC::JSObject::createInitialIndexedStorage):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::convertUndecidedToInt32):
        (JSC::JSObject::convertUndecidedToDouble):
        (JSC::JSObject::convertUndecidedToContiguous):
        (JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements):
        (JSC::JSObject::convertUndecidedToArrayStorage):
        (JSC::JSObject::convertInt32ToDouble):
        (JSC::JSObject::convertInt32ToContiguous):
        (JSC::JSObject::convertInt32ToArrayStorage):
        (JSC::JSObject::convertDoubleToContiguous):
        (JSC::JSObject::convertDoubleToArrayStorage):
        (JSC::JSObject::convertContiguousToArrayStorage):
        (JSC::JSObject::setIndexQuicklyToUndecided):
        (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::putIndexedDescriptor):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::ensureLengthSlow):
        (JSC::JSObject::reallocateAndShrinkButterfly):
        (JSC::JSObject::growOutOfLineStorage):
        (JSC::JSObject::getOwnPropertyDescriptor):
        (JSC::JSObject::getEnumerableLength):
        * runtime/JSObject.h:
        (JSC::JSObject::getArrayLength):
        (JSC::JSObject::getVectorLength):
        (JSC::JSObject::canGetIndexQuickly):
        (JSC::JSObject::getIndexQuickly):
        (JSC::JSObject::tryGetIndexQuickly):
        (JSC::JSObject::canSetIndexQuickly):
        (JSC::JSObject::canSetIndexQuicklyForPutDirect):
        (JSC::JSObject::setIndexQuickly):
        (JSC::JSObject::initializeIndex):
        (JSC::JSObject::hasSparseMap):
        (JSC::JSObject::inSparseIndexingMode):
        (JSC::JSObject::inlineStorage):
        (JSC::JSObject::butterfly):
        (JSC::JSObject::outOfLineStorage):
        (JSC::JSObject::locationForOffset):
        (JSC::JSObject::ensureInt32):
        (JSC::JSObject::ensureDouble):
        (JSC::JSObject::ensureContiguous):
        (JSC::JSObject::ensureArrayStorage):
        (JSC::JSObject::arrayStorage):
        (JSC::JSObject::arrayStorageOrNull):
        (JSC::JSObject::ensureLength):
        (JSC::JSObject::putDirectWithoutTransition):
        * runtime/JSSet.h:
        (JSC::JSSet::JSSet):
        * runtime/MapData.h:
        (JSC::JSIterator>::MapDataImpl):
        (JSC::JSIterator>::IteratorData::next):
        (JSC::JSIterator>::IteratorData::refreshCursor):
        * runtime/MapDataInlines.h:
        (JSC::JSIterator>::clear):
        (JSC::JSIterator>::find):
        (JSC::JSIterator>::add):
        (JSC::JSIterator>::remove):
        (JSC::JSIterator>::replaceAndPackBackingStore):
        (JSC::JSIterator>::replaceBackingStore):
        (JSC::JSIterator>::ensureSpaceForAppend):
        (JSC::JSIterator>::visitChildren):
        (JSC::JSIterator>::copyBackingStore):
        * runtime/Options.h:

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

        Update JSC features.json
        https://bugs.webkit.org/show_bug.cgi?id=150043

        Reviewed by Mark Lam.

        There were a lot of things implemented that weren't in
        the list. We should be better about updating the list
        as we land patches for new ES6 features.

        * features.json:

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

        Cleanup Heap.h and some related headers
        https://bugs.webkit.org/show_bug.cgi?id=149981

        Reviewed by Geoffrey Garen.

        * heap/Heap.h:
        - Some functions did not need export.
        - threadDupStrings never had an implementation.

        * heap/ConservativeRoots.cpp:
        * heap/ConservativeRoots.h:
        * heap/Heap.cpp:
        * heap/ListableHandler.h:
        * heap/WeakReferenceHarvester.h:
        * jit/Repatch.cpp:
        * runtime/JSONObject.h:
        * runtime/VM.h:
        - Stale forward declarations / includes.

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

        Each *ById inline cache in the FTL must have its own CallSiteIndex
        https://bugs.webkit.org/show_bug.cgi?id=150039

        Reviewed by Geoffrey Garen and Filip Pizlo.

        When lowering to LLVM, we create a patchpoint intrinsic for each
        *ById in DFG IR. LLVM may choose to duplicate these patchpoints.
        Therefore, we want each resulting inline cache to have a unique
        CallSiteIndex because each inline cache will have its own set of 
        used registers. This change is necessary when we implement try/catch 
        in the FTL because an inline cache will ask for the set of used 
        registers it will need to restore in the event of an exception 
        being thrown. It asks for this set of registers by giving JITCode
        a CallSiteIndex. Because each corresponding inline cache that results
        from a duplicated patchpoint may all ask this for this set of registers, 
        we must assign each inline cache a unique CallSiteIndex.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::addCodeOrigin):
        (JSC::DFG::CommonData::addUniqueCallSiteIndex):
        (JSC::DFG::CommonData::addCodeOriginUnconditionally): Deleted.
        * dfg/DFGCommonData.h:
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLInlineCacheDescriptor.h:
        (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
        (JSC::FTL::InlineCacheDescriptor::stackmapID):
        (JSC::FTL::InlineCacheDescriptor::codeOrigin):
        (JSC::FTL::InlineCacheDescriptor::uid):
        (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
        (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
        (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
        (JSC::FTL::LazySlowPathDescriptor::LazySlowPathDescriptor):
        (JSC::FTL::InlineCacheDescriptor::callSiteIndex): Deleted.
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
        (JSC::FTL::DFG::LowerDFGToLLVM::getById):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):

2015-10-12  Andreas Kling  <akling@apple.com>

        "A + B" with strings shouldn't copy if A or B is empty.
        <https://webkit.org/b/150034>

        Reviewed by Anders Carlsson.

        * runtime/JSStringBuilder.h:
        (JSC::jsMakeNontrivialString):
        * runtime/Lookup.cpp:
        (JSC::reifyStaticAccessor):
        * runtime/ObjectPrototype.cpp:
        (JSC::objectProtoFuncToString):

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

        VisitedValueCount GC Counter misses parallel SlotVisitors
        https://bugs.webkit.org/show_bug.cgi?id=149980

        Reviewed by Geoffrey Garen.

        * heap/Heap.cpp:
        (JSC::Heap::updateObjectCounts):
        Include threaded slot visitor's object counts in the debugging value.

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

        Unreviewed, fix non-FTL build for real.

        * ftl/FTLLazySlowPath.h:

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

        Unreviewed, clarify a comment. The example code had a bug.

        * ftl/FTLLowerDFGToLLVM.cpp:

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

        Unreviewed, fix no-FTL build.

        * ftl/FTLLazySlowPath.cpp:

2015-10-12  Philip Chimento  <philip.chimento@gmail.com>

        webkit-gtk 2.3.3 fails to build on OS X - Conflicting type "Fixed"
        https://bugs.webkit.org/show_bug.cgi?id=126433

        Reviewed by Philippe Normand

        Don't include CoreFoundation.h when building the GTK port.

        * Source/JavaScriptCore/API/WebKitAvailability.h: Add !defined(BUILDING_GTK__) to defined(__APPLE__).

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

        FTL should generate code to call slow paths lazily
        https://bugs.webkit.org/show_bug.cgi?id=149936

        Reviewed by Saam Barati.

        We often have complex slow paths in FTL-generated code. Those slow paths may never run. Even
        if they do run, they don't need stellar performance. So, it doesn't make sense to have LLVM
        worry about compiling such slow path code.

        This patch enables us to use our own MacroAssembler for compiling the slow path inside FTL
        code. It does this by using a crazy lambda thingy (see FTLLowerDFGToLLVM.cpp's lazySlowPath()
        and its documentation). The result is quite natural to use.

        Even for straight slow path calls via something like vmCall(), the lazySlowPath offers the
        benefit that the call marshalling and the exception checking are not expressed using LLVM IR
        and do not require LLVM to think about it. It also has the benefit that we never generate the
        code if it never runs. That's great, since function calls usually involve ~10 instructions
        total (move arguments to argument registers, make the call, check exception, etc.).

        This patch adds the lazy slow path abstraction and uses it for some slow paths in the FTL.
        The code we generate with lazy slow paths is worse than the code that LLVM would have
        generated. Therefore, a lazy slow path only makes sense when we have strong evidence that
        the slow path will execute infrequently relative to the fast path. This completely precludes
        the use of lazy slow paths for out-of-line Nodes that unconditionally call a C++ function.
        It also precludes their use for the GetByVal out-of-bounds handler, since when we generate
        a GetByVal with an out-of-bounds handler it means that we only know that the out-of-bounds
        case executed at least once. So, for all we know, it may actually be the common case. So,
        this patch just deployed the lazy slow path for GC slow paths and masquerades-as-undefined
        slow paths. It makes sense for GC slow paths because those have a statistical guarantee of
        slow path frequency - probably bounded at less than 1/10. It makes sense for masquerades-as-
        undefined because we can say quite confidently that this is an uncommon scenario on the
        modern Web.

        Something that's always been challenging about abstractions involving the MacroAssembler is
        that linking is a separate phase, and there is no way for someone who is just given access to
        the MacroAssembler& to emit code that requires linking, since linking happens once we have
        emitted all code and we are creating the LinkBuffer. Moreover, the FTL requires that the
        final parts of linking happen on the main thread. This patch ran into this issue, and solved
        it comprehensively, by introducing MacroAssembler::addLinkTask(). This takes a lambda and
        runs it at the bitter end of linking - when performFinalization() is called. This ensure that
        the task added by addLinkTask() runs on the main thread. This patch doesn't replace all of
        the previously existing idioms for dealing with this issue; we can do that later.

        This shows small speed-ups on a bunch of things. No big win on any benchmark aggregate. But
        mainly this is done for https://bugs.webkit.org/show_bug.cgi?id=149852, where we found that
        outlining the slow path in this way was a significant speed boost.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::replaceWithAddressComputation):
        (JSC::AbstractMacroAssembler::addLinkTask):
        (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
        * assembler/LinkBuffer.cpp:
        (JSC::LinkBuffer::linkCode):
        (JSC::LinkBuffer::allocate):
        (JSC::LinkBuffer::performFinalization):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::wasAlreadyDisassembled):
        (JSC::LinkBuffer::didAlreadyDisassemble):
        (JSC::LinkBuffer::vm):
        (JSC::LinkBuffer::executableOffsetFor):
        * bytecode/CodeOrigin.h:
        (JSC::CodeOrigin::CodeOrigin):
        (JSC::CodeOrigin::isSet):
        (JSC::CodeOrigin::operator bool):
        (JSC::CodeOrigin::isHashTableDeletedValue):
        (JSC::CodeOrigin::operator!): Deleted.
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLInlineCacheDescriptor.h:
        (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
        (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
        (JSC::FTL::LazySlowPathDescriptor::LazySlowPathDescriptor):
        * ftl/FTLJITCode.h:
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * ftl/FTLJITFinalizer.h:
        * ftl/FTLLazySlowPath.cpp: Added.
        (JSC::FTL::LazySlowPath::LazySlowPath):
        (JSC::FTL::LazySlowPath::~LazySlowPath):
        (JSC::FTL::LazySlowPath::generate):
        * ftl/FTLLazySlowPath.h: Added.
        (JSC::FTL::LazySlowPath::createGenerator):
        (JSC::FTL::LazySlowPath::patchpoint):
        (JSC::FTL::LazySlowPath::usedRegisters):
        (JSC::FTL::LazySlowPath::callSiteIndex):
        (JSC::FTL::LazySlowPath::stub):
        * ftl/FTLLazySlowPathCall.h: Added.
        (JSC::FTL::createLazyCallGenerator):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateActivation):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateDirectArguments):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileMakeRope):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNotifyWrite):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileIsObjectOrNull):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileIsFunction):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeNewObject):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckWatchdogTimer):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocatePropertyStorageWithSizeImpl):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateObject):
        (JSC::FTL::DFG::LowerDFGToLLVM::allocateJSArray):
        (JSC::FTL::DFG::LowerDFGToLLVM::buildTypeOf):
        (JSC::FTL::DFG::LowerDFGToLLVM::sensibleDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
        (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
        * ftl/FTLOperations.cpp:
        (JSC::FTL::operationMaterializeObjectInOSR):
        (JSC::FTL::compileFTLLazySlowPath):
        * ftl/FTLOperations.h:
        * ftl/FTLSlowPathCall.cpp:
        (JSC::FTL::SlowPathCallContext::SlowPathCallContext):
        (JSC::FTL::SlowPathCallContext::~SlowPathCallContext):
        (JSC::FTL::SlowPathCallContext::keyWithTarget):
        (JSC::FTL::SlowPathCallContext::makeCall):
        (JSC::FTL::callSiteIndexForCodeOrigin):
        (JSC::FTL::storeCodeOrigin): Deleted.
        (JSC::FTL::callOperation): Deleted.
        * ftl/FTLSlowPathCall.h:
        (JSC::FTL::callOperation):
        * ftl/FTLState.h:
        * ftl/FTLThunks.cpp:
        (JSC::FTL::genericGenerationThunkGenerator):
        (JSC::FTL::osrExitGenerationThunkGenerator):
        (JSC::FTL::lazySlowPathGenerationThunkGenerator):
        (JSC::FTL::registerClobberCheck):
        * ftl/FTLThunks.h:
        * interpreter/CallFrame.h:
        (JSC::CallSiteIndex::CallSiteIndex):
        (JSC::CallSiteIndex::operator bool):
        (JSC::CallSiteIndex::bits):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::setupArgument):
        (JSC::CCallHelpers::setupArgumentsWithExecState):
        * jit/JITOperations.cpp:

2015-10-12  Philip Chimento  <philip.chimento@gmail.com>

        webkit-gtk-2.3.4 fails to link JavaScriptCore, missing symbols add_history and readline
        https://bugs.webkit.org/show_bug.cgi?id=127059

        Reviewed by Philippe Normand.

        * shell/CMakeLists.txt: Link JSC with -ledit on Mac OSX.

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

        ES6 classes: When a class extends B, super() invokes B.prototype.constructor() instead of B()
        https://bugs.webkit.org/show_bug.cgi?id=149001

        Reviewed by Saam Barati.

        This patch matches the `super()` call in the constructor to the latest spec.
        Before this patch, when calling `super()`, it loads `callee.[[HomeObject]].__proto__.constructor`
        as a super constructor. But after this patch, it loads `callee.__proto__` as a super constructor.
        This behavior corresponds to the section 12.3.5.2[1].

        [1]: http://www.ecma-international.org/ecma-262/6.0/#sec-getsuperconstructor

        * bytecompiler/NodesCodegen.cpp:
        (JSC::SuperNode::emitBytecode):
        * tests/stress/super-call-does-not-look-up-constructor.js: Added.
        (shouldBe):
        (B):
        (C):
        (B.prototype):

2015-10-10  Andreas Kling  <akling@apple.com>

        Reduce pointless malloc traffic in CodeBlock construction.
        <https://webkit.org/b/149999>

        Reviewed by Antti Koivisto.

        Create the RefCountedArray<Instruction> for CodeBlock's m_instructions directly
        instead of first creating a Vector<Instruction> and then creating a RefCountedArray
        from that. None of the Vector functionality is needed here anyway.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finishCreation):
        (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
        * bytecode/CodeBlock.h:

2015-10-10  Dan Bernstein  <mitz@apple.com>

        [iOS] Remove unnecessary iOS version checks
        https://bugs.webkit.org/show_bug.cgi?id=150002

        Reviewed by Alexey Proskuryakov.

        * llvm/library/LLVMExports.cpp:
        (initializeAndGetJSCLLVMAPI):

2015-10-10  Dan Bernstein  <mitz@apple.com>

        [iOS] Remove project support for iOS 8
        https://bugs.webkit.org/show_bug.cgi?id=149993

        Reviewed by Alexey Proskuryakov.

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

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

        Modernize and cleanup an NSNumber constant
        https://bugs.webkit.org/show_bug.cgi?id=149962

        Reviewed by Andreas Kling.

        * API/JSVirtualMachine.mm:
        (-[JSVirtualMachine addExternalRememberedObject:]):

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

        No need to keep setting needsVisit flag in SmallStrings
        https://bugs.webkit.org/show_bug.cgi?id=149961

        Reviewed by Andreas Kling.

        SmallStrings are all initialized at once privately before the VM
        enables Garbage Collection. There is no need to keep updating
        this flag, as it couldn't have changed.

        * runtime/SmallStrings.cpp:
        (JSC::SmallStrings::createEmptyString):
        (JSC::SmallStrings::createSingleCharacterString):
        (JSC::SmallStrings::initialize):
        * runtime/SmallStrings.h:

2015-10-09  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling back in r190694
        https://bugs.webkit.org/show_bug.cgi?id=149727

        This time for double sure?

        The cause of the crash was an incorrect write barrier.

        OSR exit was barriering the baseline codeblock for the top of the stack
        twice, missing the baseline codeblock for the bottom of the stack.

        Restored changesets:

        "CodeBlock should be a GC object"
        https://bugs.webkit.org/show_bug.cgi?id=149727
        http://trac.webkit.org/changeset/r190694

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

        Remove unused RecursiveAllocationScope
        https://bugs.webkit.org/show_bug.cgi?id=149967

        Reviewed by Csaba Osztrogonác.

        RecursiveAllocationScope has been unused since r163691.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        * heap/Heap.h:
        * heap/RecursiveAllocationScope.h: Removed.
        * runtime/VM.h:

2015-10-09  Geoffrey Garen  <ggaren@apple.com>

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

        Crashes seen on PLT bots and facebook.com.

        Reverted changesets:

        "CodeBlock should be a GC object"
        https://bugs.webkit.org/show_bug.cgi?id=149727
        http://trac.webkit.org/changeset/190694

2015-10-09  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>

        Automate WebCore JS builtins generation and build system
        https://bugs.webkit.org/show_bug.cgi?id=149751

        Reviewed by Darin Adler.

        * generate-js-builtins: updating the part related to WebCore JS binding.

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

        DFG SSA should remove unreachable code
        https://bugs.webkit.org/show_bug.cgi?id=149931

        Reviewed by Geoffrey Garen.

        Rolled back in with a call to m_state.reset(), which fixes the debug asserts.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run): Remove unreachable code.
        * dfg/DFGObjectAllocationSinkingPhase.cpp: Deal with the CFG changing.
        * dfg/DFGPutStackSinkingPhase.cpp: Deal with the CFG changing.

2015-10-08  Daniel Bates  <dabates@apple.com>

        Add LLVM binaries for iOS 9 device
        https://bugs.webkit.org/show_bug.cgi?id=149913

        Reviewed by Filip Pizlo.

        Look for locally built/binary dropped LLVM headers and libraries when building for iOS device
        in WebKitBuild/usr/local.

        Currently Mac and iOS look for the locally built/binary dropped LLVM in different directories:
        WebKitBuild/usr/local and /usr/local/LLVMForJavaScriptCore, respectively. This difference is
        due to dependencies with the Apple internal build system. We should look to resolve the
        Apple internal dependencies and standardize on one location for both platforms.

        * Configurations/Base.xcconfig:

2015-10-08  Commit Queue  <commit-queue@webkit.org>

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

        Caused 50+ layout test failures
        https://build.webkit.org/results/Apple%20El%20Capitan%20Debug%20WK1%20(Tests)/r190749%20(213)/results.html
        (Requested by litherum1 on #webkit).

        Reverted changeset:

        "DFG SSA should remove unreachable code"
        https://bugs.webkit.org/show_bug.cgi?id=149931
        http://trac.webkit.org/changeset/190749

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

        DFG SSA should remove unreachable code
        https://bugs.webkit.org/show_bug.cgi?id=149931

        Reviewed by Geoffrey Garen.

        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::run): Remove unreachable code.
        * dfg/DFGObjectAllocationSinkingPhase.cpp: Deal with the CFG changing.
        * dfg/DFGPutStackSinkingPhase.cpp: Deal with the CFG changing.

2015-10-08  Joseph Pecoraro  <pecoraro@apple.com>

        Unreviewed build fix. Missing forward declaration.

        * heap/Heap.h:

2015-10-08  Saam barati  <sbarati@apple.com>

        Unreviewed Cloop build fix after bug: https://bugs.webkit.org/show_bug.cgi?id=149601

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
        * jit/JITCode.cpp:
        (JSC::NativeJITCode::addressForCall):
        (JSC::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * jit/JITCode.h:

2015-10-08  Joseph Pecoraro  <pecoraro@apple.com>

        Clean up Marked classes
        https://bugs.webkit.org/show_bug.cgi?id=149853

        Reviewed by Darin Adler.

        * heap/Heap.h:
        Move include here where it is really needed.

        * heap/HeapStatistics.cpp:
        * heap/HeapStatistics.h:
        Simplify includes.

        * heap/MarkedAllocator.h:
        Add missing copyright header.

        * heap/MarkedBlock.cpp:
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::needsSweeping):
        Remove unused constants. Add some static asserts. Add some `const` ness.

        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::isIterating):
        Update comments to better reflect actual values.
        Remove unimplemented method (moved to Heap).

        * heap/MarkedSpace.cpp:
        (JSC::Free::Free):
        (JSC::Free::operator()):
        (JSC::Free::returnValue): Deleted.
        (JSC::FreeOrShrink::FreeOrShrink):
        (JSC::FreeOrShrink::operator()):
        (JSC::MarkedSpace::~MarkedSpace):
        (JSC::MarkedSpace::shrink):
        Replace conditional Functor that was not using return value
        with simplified targeted VoidFunctors.

        (JSC::Shrink::operator()): Deleted.
        Remove unused functor.

        * heap/WeakBlock.cpp:
        * heap/WeakBlock.h:
        * runtime/Options.cpp:
        Remove dead code.

2015-10-08  Saam barati  <sbarati@apple.com>

        We should be able to inline getter/setter calls inside an inline cache even when the SpillRegistersMode is NeedsToSpill
        https://bugs.webkit.org/show_bug.cgi?id=149601

        Reviewed by Filip Pizlo.

        Before, if we had a PolymorphicAccess with and a StructureStubInfo
        with a NeedToSpill spillMode, we wouldn't generate getter/setter
        calls. This patch changes it such that we will generate the
        getter/setter call and do the necessary register spilling/filling
        around the getter/setter call to preserve any "usedRegisters".

        This has an interesting story with how it relates to exception handling 
        inside the DFG. Because the GetById variants are considered a throwing call 
        site, we must make sure that we properly restore the registers spilled to the stack 
        in case of an exception being thrown inside the getter/setter call. We do 
        this by having the inline cache register itself as a new exception handling 
        call site. When the inline cache "catches" the exception (i.e, genericUnwind 
        will jump to this code), it will restore the registers it spilled that are 
        live inside the original catch handler, and then jump to the original catch 
        handler. We make sure to only generate this makeshift catch handler when we 
        actually need to do any cleanup. If we determine that we don't need to restore 
        any registers, we don't bother generating this makeshift catch handler.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::~CodeBlock):
        (JSC::CodeBlock::handlerForIndex):
        (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
        (JSC::CodeBlock::removeExceptionHandlerForCallSite):
        (JSC::CodeBlock::lineNumberForBytecodeOffset):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::appendExceptionHandler):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::AccessGenerationState):
        (JSC::AccessGenerationState::restoreScratch):
        (JSC::AccessGenerationState::succeed):
        (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
        (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
        (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
        (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
        (JSC::AccessGenerationState::liveRegistersForCall):
        (JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
        (JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
        (JSC::AccessGenerationState::originalExceptionHandler):
        (JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation):
        (JSC::AccessGenerationState::needsToRestoreRegistersIfException):
        (JSC::AccessGenerationState::originalCallSiteIndex):
        (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
        (JSC::AccessCase::AccessCase):
        (JSC::AccessCase::generate):
        (JSC::PolymorphicAccess::regenerateWithCases):
        (JSC::PolymorphicAccess::regenerate):
        (JSC::PolymorphicAccess::aboutToDie):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::doesCalls):
        (JSC::AccessCase::isGetter):
        (JSC::AccessCase::callLinkInfo):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::deref):
        (JSC::StructureStubInfo::aboutToDie):
        (JSC::StructureStubInfo::addAccessCase):
        * bytecode/StructureStubInfo.h:
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::isInJSValueRegs):
        (JSC::ValueRecovery::fpr):
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::addCodeOrigin):
        (JSC::DFG::CommonData::addCodeOriginUnconditionally):
        (JSC::DFG::CommonData::lastCallSite):
        (JSC::DFG::CommonData::removeCallSiteIndex):
        (JSC::DFG::CommonData::shrinkToFit):
        * dfg/DFGCommonData.h:
        * dfg/DFGJITCode.cpp:
        (JSC::DFG::JITCode::reconstruct):
        (JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::osrEntryBlock):
        (JSC::DFG::JITCode::setOSREntryBlock):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIn):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::validateReferences):
        (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * ftl/FTLJITCode.h:
        (JSC::FTL::JITCode::handles):
        (JSC::FTL::JITCode::dataSections):
        * jit/GCAwareJITStubRoutine.cpp:
        (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
        (JSC::GCAwareJITStubRoutine::~GCAwareJITStubRoutine):
        (JSC::GCAwareJITStubRoutine::observeZeroRefCount):
        (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal):
        (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
        (JSC::GCAwareJITStubRoutineWithExceptionHandler::aboutToDie):
        (JSC::GCAwareJITStubRoutineWithExceptionHandler::~GCAwareJITStubRoutineWithExceptionHandler):
        (JSC::createJITStubRoutine):
        * jit/GCAwareJITStubRoutine.h:
        * jit/JITCode.cpp:
        (JSC::NativeJITCode::addressForCall):
        (JSC::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
        * jit/JITCode.h:
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITByIdGenerator::JITByIdGenerator):
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
        * jit/JITInlineCacheGenerator.h:
        (JSC::JITByIdGenerator::reportSlowPathCall):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emit_op_put_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emit_op_put_by_id):
        * jit/JITStubRoutine.h:
        (JSC::JITStubRoutine::createSelfManagedRoutine):
        (JSC::JITStubRoutine::aboutToDie):
        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
        (JSC::RegisterSet::registersToNotSaveForCall):
        (JSC::RegisterSet::allGPRs):
        * jit/RegisterSet.h:
        (JSC::RegisterSet::set):
        (JSC::RegisterSet::clear):
        * jit/ScratchRegisterAllocator.cpp:
        (JSC::ScratchRegisterAllocator::allocateScratchGPR):
        (JSC::ScratchRegisterAllocator::allocateScratchFPR):
        (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
        (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
        (JSC::ScratchRegisterAllocator::usedRegistersForCall):
        (JSC::ScratchRegisterAllocator::preserveUsedRegistersToScratchBufferForCall):
        (JSC::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBufferForCall):
        (JSC::ScratchRegisterAllocator::preserveRegistersToStackForCall):
        (JSC::ScratchRegisterAllocator::restoreRegistersFromStackForCall):
        * jit/ScratchRegisterAllocator.h:
        (JSC::ScratchRegisterAllocator::numberOfReusedRegisters):
        (JSC::ScratchRegisterAllocator::usedRegisters):
        * jsc.cpp:
        (WTF::CustomGetter::CustomGetter):
        (WTF::CustomGetter::createStructure):
        (WTF::CustomGetter::create):
        (WTF::CustomGetter::getOwnPropertySlot):
        (WTF::CustomGetter::customGetter):
        (WTF::Element::handleOwner):
        (GlobalObject::finishCreation):
        (functionCreateImpureGetter):
        (functionCreateCustomGetterObject):
        (functionSetImpureGetterDelegate):
        * tests/stress/try-catch-custom-getter-as-get-by-id.js: Added.
        (assert):
        (bar):
        (foo):
        * tests/stress/try-catch-getter-as-get-by-id-register-restoration.js: Added.
        (assert):
        (o1.get f):
        (bar):
        (foo):
        * tests/stress/try-catch-getter-as-get-by-id.js: Added.
        (assert):
        (o1.get f):
        (bar):
        (foo):
        * tests/stress/try-catch-setter-as-put-by-id.js: Added.
        (assert):
        (o1.set f):
        (bar):
        (foo):
        * tests/stress/try-catch-stub-routine-replaced.js: Added.
        (assert):
        (arr):
        (hello):
        (foo):
        (objChain.get f):
        (fakeOut.get f):
        (o.get f):

2015-10-08  Commit Queue  <commit-queue@webkit.org>

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

        broke mac build from time to time (Requested by youenn on
        #webkit).

        Reverted changeset:

        "Automate WebCore JS builtins generation and build system"
        https://bugs.webkit.org/show_bug.cgi?id=149751
        http://trac.webkit.org/changeset/190716

2015-10-08  Csaba Osztrogonác  <ossy@webkit.org>

        Fix the WASM build on Linux
        https://bugs.webkit.org/show_bug.cgi?id=149919

        Reviewed by Mark Lam.

        * inspector/ScriptCallStackFactory.cpp:
        * wasm/JSWASMModule.cpp:
        * wasm/WASMFunctionCompiler.h:
        (JSC::sizeOfMemoryType):
        * wasm/WASMFunctionLLVMIRGenerator.h:

2015-10-08  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed CLOOP buildfix after r190718.

        * jit/Repatch.h:
        (JSC::resetGetByID): Deleted.
        (JSC::resetPutByID): Deleted.
        (JSC::resetIn): Deleted.

2015-10-08  Joseph Pecoraro  <pecoraro@apple.com>

        Remove references to removed class RepatchBuffer
        https://bugs.webkit.org/show_bug.cgi?id=149909

        Reviewed by Csaba Osztrogonác.

        * assembler/AbstractMacroAssembler.h:
        * assembler/MacroAssemblerARM.h:
        * assembler/MacroAssemblerARM64.h:
        * assembler/MacroAssemblerARMv7.h:
        * assembler/MacroAssemblerMIPS.h:
        * assembler/MacroAssemblerSH4.h:
        * assembler/MacroAssemblerX86.h:
        * assembler/MacroAssemblerX86_64.h:
        * jit/JITStubRoutine.h:
        * jit/Repatch.h:

2015-10-08  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>

        Automate WebCore JS builtins generation and build system
        https://bugs.webkit.org/show_bug.cgi?id=149751

        Reviewed by Darin Adler.

        * generate-js-builtins: updating the part related to WebCore JS binding.

2015-10-07  Joseph Pecoraro  <pecoraro@apple.com>

        Clean up Copied classes
        https://bugs.webkit.org/show_bug.cgi?id=149863

        Reviewed by Saam Barati.

        * heap/CopiedAllocator.h:
        (JSC::CopiedAllocator::isValid):
        * heap/CopiedBlock.h:
        * heap/CopiedBlockInlines.h:
        * heap/CopiedSpace.cpp:
        * heap/CopiedSpace.h:
        (JSC::CopiedSpace::isInCopyPhase):
        (JSC::CopiedSpace::shouldDoCopyPhase):
        * heap/CopiedSpaceInlines.h:
        * heap/CopyToken.h:
        * heap/CopyVisitor.cpp:
        * heap/CopyVisitor.h:
        * heap/CopyVisitorInlines.h:
        * heap/CopyWorkList.h:
        * heap/HandleBlock.h:
        * heap/HandleSet.h:
        * heap/HeapHelperPool.cpp:
        * heap/HeapHelperPool.h:

2015-10-07  Mark Lam  <mark.lam@apple.com>

        [Follow up 2] Disable tail calls because it is breaking some sites.
        https://bugs.webkit.org/show_bug.cgi?id=149900

        Rubber stamped by Saam Barati.

        Also need to surpress JSC tail call tests.

        * tests/es6.yaml:
        * tests/stress/dfg-tail-calls.js:
        (nonInlinedTailCall.callee):
        * tests/stress/mutual-tail-call-no-stack-overflow.js:
        (shouldThrow):
        * tests/stress/tail-call-in-inline-cache.js:
        (tail):
        * tests/stress/tail-call-no-stack-overflow.js:
        (shouldThrow):
        * tests/stress/tail-call-recognize.js:
        (callerMustBeRun):
        * tests/stress/tail-call-varargs-no-stack-overflow.js:
        (shouldThrow):

2015-10-07  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling back in r190450
        https://bugs.webkit.org/show_bug.cgi?id=149727

        This time for sure?

        The cause of the leak was an invalidated compilation.

        There was vestigial manual memory management code that eagerly removed
        a CodeBlock from the set of CodeBlocks if compilation was invalidated.
        That's not cool since we rely on the set of CodeBlocks when we run
        destructors.

        The fix is to remove the vestigial code.

        I ran the leaks, correctness, and performance tests locally and did not
        see any problems.

        Restored changesets:

        "CodeBlock should be a GC object"
        https://bugs.webkit.org/show_bug.cgi?id=149727
        http://trac.webkit.org/changeset/190450

2015-10-07  Mark Lam  <mark.lam@apple.com>

        Disable tail calls because it is breaking some sites.
        https://bugs.webkit.org/show_bug.cgi?id=149900

        Reviewed by Saam Barati.

        This is until we fix whatever the breakage is.

        * runtime/Options.h:

2015-10-07  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Add an LLVM IR generator for WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149486

        Reviewed by Mark Lam.

        This patch adds initial support for an LLVM IR generator in WebAssembly
        (polyfill-prototype-1 format). All the methods will be implemented in
        subsequent patches.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * wasm/WASMFunctionLLVMIRGenerator.h: Added.
        (JSC::WASMFunctionLLVMIRGenerator::MemoryAddress::MemoryAddress):
        (JSC::WASMFunctionLLVMIRGenerator::startFunction):
        (JSC::WASMFunctionLLVMIRGenerator::endFunction):
        (JSC::WASMFunctionLLVMIRGenerator::buildSetLocal):
        (JSC::WASMFunctionLLVMIRGenerator::buildSetGlobal):
        (JSC::WASMFunctionLLVMIRGenerator::buildReturn):
        (JSC::WASMFunctionLLVMIRGenerator::buildImmediateI32):
        (JSC::WASMFunctionLLVMIRGenerator::buildImmediateF32):
        (JSC::WASMFunctionLLVMIRGenerator::buildImmediateF64):
        (JSC::WASMFunctionLLVMIRGenerator::buildGetLocal):
        (JSC::WASMFunctionLLVMIRGenerator::buildGetGlobal):
        (JSC::WASMFunctionLLVMIRGenerator::buildConvertType):
        (JSC::WASMFunctionLLVMIRGenerator::buildLoad):
        (JSC::WASMFunctionLLVMIRGenerator::buildStore):
        (JSC::WASMFunctionLLVMIRGenerator::buildUnaryI32):
        (JSC::WASMFunctionLLVMIRGenerator::buildUnaryF32):
        (JSC::WASMFunctionLLVMIRGenerator::buildUnaryF64):
        (JSC::WASMFunctionLLVMIRGenerator::buildBinaryI32):
        (JSC::WASMFunctionLLVMIRGenerator::buildBinaryF32):
        (JSC::WASMFunctionLLVMIRGenerator::buildBinaryF64):
        (JSC::WASMFunctionLLVMIRGenerator::buildRelationalI32):
        (JSC::WASMFunctionLLVMIRGenerator::buildRelationalF32):
        (JSC::WASMFunctionLLVMIRGenerator::buildRelationalF64):
        (JSC::WASMFunctionLLVMIRGenerator::buildMinOrMaxI32):
        (JSC::WASMFunctionLLVMIRGenerator::buildMinOrMaxF64):
        (JSC::WASMFunctionLLVMIRGenerator::buildCallInternal):
        (JSC::WASMFunctionLLVMIRGenerator::buildCallIndirect):
        (JSC::WASMFunctionLLVMIRGenerator::buildCallImport):
        (JSC::WASMFunctionLLVMIRGenerator::appendExpressionList):
        (JSC::WASMFunctionLLVMIRGenerator::discard):
        (JSC::WASMFunctionLLVMIRGenerator::linkTarget):
        (JSC::WASMFunctionLLVMIRGenerator::jumpToTarget):
        (JSC::WASMFunctionLLVMIRGenerator::jumpToTargetIf):
        (JSC::WASMFunctionLLVMIRGenerator::startLoop):
        (JSC::WASMFunctionLLVMIRGenerator::endLoop):
        (JSC::WASMFunctionLLVMIRGenerator::startSwitch):
        (JSC::WASMFunctionLLVMIRGenerator::endSwitch):
        (JSC::WASMFunctionLLVMIRGenerator::startLabel):
        (JSC::WASMFunctionLLVMIRGenerator::endLabel):
        (JSC::WASMFunctionLLVMIRGenerator::breakTarget):
        (JSC::WASMFunctionLLVMIRGenerator::continueTarget):
        (JSC::WASMFunctionLLVMIRGenerator::breakLabelTarget):
        (JSC::WASMFunctionLLVMIRGenerator::continueLabelTarget):
        (JSC::WASMFunctionLLVMIRGenerator::buildSwitch):
        * wasm/WASMFunctionParser.cpp:

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

        Get rid of LLInt inline/out-of-line storage helpers, they are unused
        https://bugs.webkit.org/show_bug.cgi?id=149892

        Reviewed by Mark Lam.

        Just killing dead code.

        * llint/LowLevelInterpreter.asm:

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

        Don't setOutOfBounds in JIT code for PutByVal, since the C++ slow path already does it
        https://bugs.webkit.org/show_bug.cgi?id=149885

        Reviewed by Geoffrey Garen.

        This simplifies the slow path code, which will make it easier to put read barriers on all of
        the butterflies.

        * jit/JITOperations.cpp:
        (JSC::getByVal):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_put_by_val):

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

        Get rid of JIT::compilePutDirectOffset
        https://bugs.webkit.org/show_bug.cgi?id=149884

        Reviewed by Andreas Kling.

        I'm finding more dead code.

        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_put_by_id):
        (JSC::JIT::emitVarInjectionCheck):
        (JSC::JIT::compilePutDirectOffset): Deleted.

2015-10-07  Joseph Pecoraro  <pecoraro@apple.com>

        Heap::isWriteBarrierEnabled is unused
        https://bugs.webkit.org/show_bug.cgi?id=149881

        Reviewed by Geoffrey Garen.

        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::isWriteBarrierEnabled): Deleted.

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

        JIT::emitGetGlobalProperty/emitPutGlobalProperty are only called from one place
        https://bugs.webkit.org/show_bug.cgi?id=149879

        Reviewed by Saam Barati.

        To simplify my work to insert barriers on loads of the butterfly, I want to reduce the amount
        of abstraction we have around code that loads the butterfly.

        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitLoadWithStructureCheck):
        (JSC::JIT::emitGetVarFromPointer):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emitPutGlobalVariable):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitGetGlobalProperty): Deleted.
        (JSC::JIT::emitPutGlobalProperty): Deleted.
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitLoadWithStructureCheck):
        (JSC::JIT::emitGetVarFromPointer):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emitPutGlobalVariable):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitGetGlobalProperty): Deleted.
        (JSC::JIT::emitPutGlobalProperty): Deleted.

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

        JIT::compileGetDirectOffset is useless
        https://bugs.webkit.org/show_bug.cgi?id=149878

        Reviewed by Mark Lam.

        Two of the overloads of this method were never called. The other was called only from one
        place, in a manner that rendered most of its code dead. This change removes the dead code and
        folds the method into its one caller.

        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::compilePutDirectOffset):
        (JSC::JIT::emitVarInjectionCheck):
        (JSC::JIT::emitGetGlobalProperty):
        (JSC::JIT::emitGetVarFromPointer):
        (JSC::JIT::compileGetDirectOffset): Deleted.
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::compilePutDirectOffset):
        (JSC::JIT::emitVarInjectionCheck):
        (JSC::JIT::emitGetGlobalProperty):
        (JSC::JIT::emitGetVarFromPointer):
        (JSC::JIT::compileGetDirectOffset): Deleted.

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

        Inline caches should handle out-of-line offsets out-of-line
        https://bugs.webkit.org/show_bug.cgi?id=149869

        Reviewed by Saam Barati.

        If we want to have a concurrent copying GC, then we need a read barrier on copied space
        pointers. That makes the convertible load portion of the get_by_id/put_by_id inline caches
        rather challenging. Currently we have a load instruction that we can turn into an add
        instruction - the add case is when we have an inline offset, and the load case is when we
        have an out-of-line offset and we need to load a copied space pointer. But if the load from
        copied space requires a barrier, then there is no easy way to convert that back to the inline
        case.

        This patch removes the convertible load. The inline path of get_by_id/put_by_id only handles
        the inline offsets. Out-of-line offsets are now handled using out-of-line stubs.

        * bytecode/StructureStubInfo.h:
        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfGetById):
        (JSC::FTL::sizeOfPutById):
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::JITByIdGenerator::finalize):
        (JSC::JITByIdGenerator::generateFastPathChecks):
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        (JSC::JITGetByIdGenerator::generateFastPath):
        (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
        (JSC::JITPutByIdGenerator::generateFastPath):
        * jit/JITInlineCacheGenerator.h:
        * jit/Repatch.cpp:
        (JSC::repatchByIdSelfAccess):
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        * runtime/JSObject.h:
        (JSC::JSObject::butterflyTotalSize):
        (JSC::indexRelativeToBase):
        (JSC::offsetRelativeToBase):
        (JSC::maxOffsetRelativeToBase):
        (JSC::makeIdentifier):
        (JSC::offsetRelativeToPatchedStorage): Deleted.
        (JSC::maxOffsetRelativeToPatchedStorage): Deleted.

2015-10-07  Commit Queue  <commit-queue@webkit.org>

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

        mac build is sometimes borken due to missing generated header
        file (Requested by youenn on #webkit).

        Reverted changeset:

        "Automate WebCore JS builtins generation and build system"
        https://bugs.webkit.org/show_bug.cgi?id=149751
        http://trac.webkit.org/changeset/190664

2015-10-07  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>

        Automate WebCore JS builtins generation and build system
        https://bugs.webkit.org/show_bug.cgi?id=149751

        Reviewed by Darin Adler.

        * generate-js-builtins: updating the part related to WebCore JS binding.

2015-10-06  Mark Lam  <mark.lam@apple.com>

        Factoring out op_sub baseline code generation into JITSubGenerator.
        https://bugs.webkit.org/show_bug.cgi?id=149600

        Reviewed by Geoffrey Garen.

        We're going to factor out baseline code generation into snippet generators so
        that we can later use them in the DFG and FTL to emit code for to perform the
        JS operations where the operand types are predicted to be polymorphic.
        We are starting in this patch with the implementation of op_sub.

        What was done in this patch:
        1. Created JITSubGenerator based on the baseline implementation of op_sub as
           expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase().
           I did not attempt to do write a more optimal version of op_sub.  I'll
           leave that to a later patch.

        2. Convert the 32-bit op_sub baseline implementation to use the same
           JITSubGenerator which was based on the 64-bit implementation.  The
           pre-existing 32-bit baseline op_sub had handling for more optimization cases.
           However, a benchmark run shows that simply going with the 64-bit version
           (foregoing those extra optimizations) did not change the performance.

           Also, previously, the 32-bit version was able to move double results directly
           into the result location on the stack directly.  By using JITSubGenerator,
           we now always move that result into a pair of GPRs before storing it into
           the stack location.

        3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::boxDouble):
        (JSC::AssemblyHelpers::unboxDouble):
        (JSC::AssemblyHelpers::boxBooleanPayload):
        * jit/JIT.h:
        (JSC::JIT::linkDummySlowCase):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::compileBinaryArithOp):
        (JSC::JIT::compileBinaryArithOpSlowCase):
        (JSC::JIT::emitSlow_op_div):
        (JSC::JIT::emit_op_sub):
        (JSC::JIT::emitSlow_op_sub):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emitBinaryDoubleOp):
        (JSC::JIT::emit_op_sub): Deleted.
        (JSC::JIT::emitSub32Constant): Deleted.
        (JSC::JIT::emitSlow_op_sub): Deleted.
        * jit/JITInlines.h:
        (JSC::JIT::linkSlowCaseIfNotJSCell):
        (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
        (JSC::JIT::addSlowCase):
        (JSC::JIT::emitLoad):
        (JSC::JIT::emitGetVirtualRegister):
        (JSC::JIT::emitPutVirtualRegister):
        * jit/JITSubGenerator.h: Added.
        (JSC::JITSubGenerator::JITSubGenerator):
        (JSC::JITSubGenerator::generateFastPath):
        (JSC::JITSubGenerator::slowPathJumpList):

2015-10-06  Daniel Bates  <dbates@webkit.org>

        Enable XSLT when building WebKit for iOS using the public iOS SDK
        https://bugs.webkit.org/show_bug.cgi?id=149827

        Reviewed by Alexey Proskuryakov.

        * Configurations/FeatureDefines.xcconfig:

2015-10-05  Commit Queue  <commit-queue@webkit.org>

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

        Made perf tests randomly crash (Requested by ap on #webkit).

        Reverted changeset:

        "GC shouldn't cancel every FTL compilation"
        https://bugs.webkit.org/show_bug.cgi?id=149821
        http://trac.webkit.org/changeset/190599

2015-10-05  Commit Queue  <commit-queue@webkit.org>

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

        Caused lots of leaks, and possibly crashes (Requested by ap on
        #webkit).

        Reverted changeset:

        "Unreviewed, rolling back in r190450"
        https://bugs.webkit.org/show_bug.cgi?id=149727
        http://trac.webkit.org/changeset/190589

2015-10-05  Geoffrey Garen  <ggaren@apple.com>

        Remove a few includes from JSGlobalObject.h
        https://bugs.webkit.org/show_bug.cgi?id=148004

        Reviewed by Saam Barati.

        * parser/VariableEnvironment.cpp:
        * parser/VariableEnvironment.h:
        * runtime/JSGlobalObject.h:
        * runtime/JSString.cpp:
        (JSC::JSString::createStructure):
        (JSC::JSRopeString::RopeBuilder::expand):
        * runtime/JSString.h:
        (JSC::JSString::canGetIndex):
        (JSC::JSString::offsetOfLength):
        (JSC::JSString::offsetOfFlags):
        (JSC::JSString::createStructure): Deleted.
        * runtime/Structure.h:
        * runtime/StructureInlines.h:
        * runtime/StructureRareDataInlines.h:

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

        GC shouldn't cancel every FTL compilation
        https://bugs.webkit.org/show_bug.cgi?id=149821

        Reviewed by Saam Barati.

        During one of the CodeBlock GC refactorings, we messed up the GC's compilation cancellation
        code. The GC should be able to cancel compilation plans if it determines that the plan will
        be DOA. But, prior to this fix, that code was killing every FTL compilation. This happened
        because the meaning of CodeBlock::isKnownToBeLiveDuringGC() changed.

        It's funny that this didn't show up as a bigger slow-down. Basically, those benchmarks that
        GC a lot usually don't rely on good compilation, while those benchmarks that do rely on good
        compilation usually don't GC a lot. That's probably why this wasn't super obvious when we
        broke it.

        This change just changes the cancellation logic so that it only cancels plans if the owning
        executable is dead. This is safe; in fact the relevant method would be correct even if it
        always returned true. It would also be correct if it always returned false. So, compared to
        what we had before we changed isKnownToBeLiveDuringGC(), this new code will cancel fewer
        compilations. But, that's better than cancelling every compilation. I've filed a bug and
        written a FIXME for investigating ways to resurrect the old behavior:
        https://bugs.webkit.org/show_bug.cgi?id=149823

        Nonetheless, this change looks like it might be a 1% speed-up on Octane. It improves earley
        and gbemu.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::isKnownToBeLiveDuringGC):

2015-10-05  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        [Intl] Change the return type of canonicalizeLocaleList() from JSArray* to Vector<String>
        https://bugs.webkit.org/show_bug.cgi?id=149807

        Reviewed by Benjamin Poulain.

        From ECMA-402, 9.2.1, the abstract operation CanonicalizeLocaleList
        returns a List of Strings. From the spec, we never modify the result
        from CanonicalizeLocaleList(). We never expose it to the user either.
        This patch changes the return type of canonicalizeLocaleList() from
        JSArray* to Vector<String>. This should ease the workload of the GC and
        make the code a bit easier to read.

        * runtime/IntlCollatorConstructor.cpp:
        (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
        * runtime/IntlObject.cpp:
        (JSC::canonicalizeLocaleList):
        (JSC::lookupSupportedLocales):
        (JSC::bestFitSupportedLocales):
        (JSC::supportedLocales):
        * runtime/IntlObject.h:

2015-10-01  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling back in r190450
        https://bugs.webkit.org/show_bug.cgi?id=149727

        The cause of the leak was VM shutdown, which happens in workers.

        The fix is for CodeBlockSet to participate in lastChanceToFinalize,
        since it's responsible for running CodeBlock destructors.

        I ran the leaks tests locally and did not see any CodeBlock-related leaks.

        Restored changesets:

        "CodeBlock should be a GC object"
        https://bugs.webkit.org/show_bug.cgi?id=149727
        http://trac.webkit.org/changeset/190450

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

        Allow an object's marking state to track The Three Colors
        https://bugs.webkit.org/show_bug.cgi?id=149654

        Reviewed by Geoffrey Garen.

        I want to make GC marking concurrent (see https://bugs.webkit.org/show_bug.cgi?id=149432).
        Concurrent GC require barriers to be executed during certain heap operations. We already have a
        generational GC. Generational GCs also need barriers, and we already have those. The generational
        GC barrier that we use is the "sticky mark bit" barrier. Ordinarily, mark bits get reset after a
        collection. In our collector, there is a secondary mark bit that "sticks" - i.e. it does not get
        reset. If the sticky mark bit is set in between two collections, then we know that the object is in
        old space. This is sufficient to determine when to put things into remembered sets. Additionally,
        the sticky mark bit is actually a tri-state that can also tell us if the object has been placed on
        a remembered set.

        This is awfully similar to what you want in a concurrent GC. Concurrent GCs typically want writes
        to the heap that change the object graph to do different things depending on an object's marking
        state, which is usually referred to as its color. White means that the object has never been seen
        by the collector. All white objects are presumed dead at the flip. Grey objects are those that are
        known to the collector but have not been scanned. Black objects are those that have been scanned,
        and will not be scanned again. White is exactly just "not being marked", and both grey and black
        mean "marked" - with "black" meaning "marked but not on any worklist". That's quite a bit like the
        current "Marked" and "MarkedAndRemembered" states that we have for generational GC.
        "MarkedAndRemembered" is a lot like "grey", and "Marked" is a lot like "black".

        I want to make a concurrent GC that unifies the generational and concurrent barriers into a single
        fast path check. Even better if the two barriers are entirely identical. You can do this using
        Pirinen's technique #2 [1], originally due to Guy Steele [2]: when doing o.f=v where o is black and
        v is white, turn o grey again. This is like remembering an object, in the sense that our gen GC
        "rememberes" o when o is old and v is new. It remembers objects by putting them on the mark stack,
        setting the generational state to MarkedAndRemembered, and doing nothing to the primary mark bit.

        This makes our concurrent GC approach pretty obvious. We want to use one barrier for concurrent and
        generational, and we want to basically keep our current barriers unchanged. The only things missing
        are just some small changes to allow the concurrent GC to know precisely when an object is black,
        and to know during object visiting if we are visiting the object for the first time during a
        collection or a subsequent time due to barrier re-greying (concurrent GC) or barrier remembering
        (generational GC). So, this patch does the following:

        - Changes the terminology used for the gcData header byte in JSCell. This changes the name of this
          to cellState, and introduces a new enumeration called CellState. This new enumeration behaves a
          lot like the old GCData did. It has the following members, with the following correspondence to
          the old GCData:

          OldBlack: this is like Marked, with the exception that we ensure that an object becomes OldBlack
              as soon as the object starts to be scanned. Previously, an object might be
              MarkedAndRemembered during scanning and we'd turn all MarkedAndRemembered objects into Marked
              objects during a post-processing step at the end of GC. This patch gets rid of that
              post-processing. The act of visiting an object unconditionally makes it OldBlack. Note that
              our definition of "black" is not that the object is done being scanned, but that it is either
              being scanned right now or it has already been scanned. This is like a combination of
              Siebert's anthracite and black states [3].

          NewWhite: this is exactly NotMarked. It's the state that objects get when they are allocated.
              It's impossible for an object to return to this state.

          OldGrey: the object is on the mark stack and will be scanned at some point in the future. This
              also means that this isn't the first time in this cycle that the object has been grey. In an
              eden collection, an old object that has been remembered is thought of as being OldGrey, even
              if this is the first time during this eden collection that it is grey. That's because an eden
              collection must behave "as if" the grey->black transition for old objects magically happened
              at the start of GC. Remembered objects are like old objects that underwent a concurrent
              barrier re-greying just after the magical old object grey->black transition at the start of
              GC. This state is almost exactly like MarkedAndRemembered, except that an object now
              transitions from OldGrey to OldBlack at the beginning of visiting, rather than how previously
              we transitioned from MarkedAndRemembered to Marked at the bitter end of GC.

          NewGray: the object is on the mark stack and will be scanned at some point in the future. This
              state has no clear relative in the old state system. It means that the object became grey due
              to ordinary marking. Previously, ordinary marking would make the object Marked.

        - Removal of the post-processing phase that "clears" the remembered set by moving all remembered
          objects to the Marked state. This now happens magically during visiting, as described above.

        - SlotVisitor now remembers the state that the object did have just before visiting. While visiting
          that object, it's possible to query what the state was. This is used for copy space decisions and
          for extra memory usage accounting. We don't want to put the backing store on the copy worklist,
          and we don't want to count extra memory usage, if the object was OldGrey at the start of
          visiting. Previously, we would be able to just ask if the object was MarkedAndRemembered since
          that state wouldn't get cleared until after all marking finished. This change also simplifies
          some APIs, because there is no need to pass the JSCell* pointer, since these SlotVisitor methods
          no longer ask the cell for its state - instead they use the saved pre-visiting state.

        - Removal of a bunch of helpers and abstractions. Previously we had various methods for asking if
          an object was "marked" and if an object was "remembered". We had helpers for adjusting these
          states, and those helpers would assert that they were being used the right way. This is not very
          useful for concurrent GC, since now the set of possible state transitions is much larger. Also,
          the previous use of the word "marked" was pretty bad - for example in Heap, "marked" refers to
          the primary mark bit (that gets cleared at the flip), while in JSCell, "marked" refers to the
          sticky mark bit (that does not get cleared, ever). This change gets rid of a lot of those helpers
          and inlines their logic. This actually makes the code easier and more fun to read, since you can
          now look at the marking and barrier code and see how that code uses the four CellStates. For
          example, it's fun to see that the barrier gets fired for o.f=v exactly when o is OldBlack and v
          is NewWhite.

        This change shouldn't have any effect on performance or GC behavior. It does put our code in a
        weird state where we now have states and comments referencing a concurrent GC that doesn't exist
        yet.

        Finally, some thoughts about the concurrent GC barrier and its implications for performance. This
        barrier exhibits very poor guarantees about collector progress, but maximizes throughput by just
        reusing the existing barrier code we already emit and optimize. I believe that even our epoch-based
        barrier insertion DFG phase is correct for the concurrent interpretation of our existing barrier.
        But, the barrier can regress the progress that the collector has made for two reasons:

        Incremental update: you don't want to use this barrier with a black stack, since that would mean
        that heap loads of white objects will have to explicitly re-grey the stack. The way you implement
        this kind of collector is that collector termination will rescan the stack. Termination is reached
        only if the at-termination re-scan greys no objects. This means that the collector is a fixpoint.
        Luckily, our collector is already a fixpoint because of opaque roots and structure transitions.

        Marking ain't monotonic: normally, once an object is black, it stays that way. In this collector,
        black objects may become grey again. I don't have personal experience with such concurrent GCs, but
        I suspect that this will basically be fine. Concurrent collections finish pretty quickly, and the
        mutator usually touches only a subset of the heap. Only that subset of the heap that the mutator is
        touching could be re-greyed. Probably, the GC will have to be hybrid incremental and concurrent,
        and towards the end of GC when we do the termination stack re-scan, we can ensure that the
        collector does some minimal amount of marking. If the minimal amount of marking done by the
        collector is large enough, we can ensure that we reach termination before the mutator can regress
        progress. The barrier cannot un-terminate the collector; if the collector reaches termination and
        the barrier re-greys an object then it's actually doing a generational remembering rather than a
        concurrent re-greying.

        That's sort of the cute thing about the barrier - it is exactly a re-greying barrier during GC and
        it is exactly a remembering barrier in between GCs.

        [1] http://www.cs.utexas.edu/ftp/garbage/submit/readable/ppirinen11.ps
        [2] http://dl.acm.org/citation.cfm?id=361005
        [3] http://www.aicas.com/papers/ISMM132-siebert.pdf

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitChildren):
        * ftl/FTLAbstractHeapRepository.cpp:
        (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
        * ftl/FTLAbstractHeapRepository.h:
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIsStillValid):
        (JSC::FTL::DFG::LowerDFGToLLVM::loadCellState):
        (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
        (JSC::FTL::DFG::LowerDFGToLLVM::loadMarkByte): Deleted.
        * heap/CellState.h: Added.
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
        * heap/CopiedBlock.h:
        * heap/CopiedBlockInlines.h:
        (JSC::CopiedBlock::reportLiveBytes):
        (JSC::CopiedBlock::shouldReportLiveBytes): Deleted.
        * heap/GCLogging.cpp:
        (JSC::LoggingFunctor::reviveCells):
        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::visitWeakHandles):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::addToRememberedSet):
        (JSC::Heap::clearRememberedSet): Deleted.
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::isLive):
        (JSC::Heap::isMarked):
        (JSC::Heap::writeBarrier):
        (JSC::Heap::reportExtraMemoryAllocated):
        (JSC::Heap::reportExtraMemoryVisited):
        (JSC::Heap::isRemembered): Deleted.
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::visitChildren):
        (JSC::SlotVisitor::donateKnownParallel):
        (JSC::SlotVisitor::drain):
        (JSC::visitChildren): Deleted.
        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::childCount):
        (JSC::SlotVisitor::incrementChildCount):
        (JSC::SlotVisitor::dataBeforeVisitingCurrentObject):
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::internalAppend):
        (JSC::SlotVisitor::copyLater):
        (JSC::SlotVisitor::reportExtraMemoryVisited):
        (JSC::SlotVisitor::heap):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSCell.h:
        (JSC::JSCell::cellState):
        (JSC::JSCell::setCellState):
        (JSC::JSCell::structureIDOffset):
        (JSC::JSCell::indexingTypeOffset):
        (JSC::JSCell::cellStateOffset):
        (JSC::JSCell::setMarked): Deleted.
        (JSC::JSCell::setRemembered): Deleted.
        (JSC::JSCell::isMarked): Deleted.
        (JSC::JSCell::isRemembered): Deleted.
        (JSC::JSCell::gcDataOffset): Deleted.
        * runtime/JSCellInlines.h:
        (JSC::JSCell::JSCell):
        * runtime/JSGenericTypedArrayViewInlines.h:
        (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
        * runtime/JSObject.cpp:
        (JSC::JSObject::copyBackingStore):
        * runtime/JSString.cpp:
        (JSC::JSString::visitChildren):
        * runtime/StructureIDBlob.h:
        (JSC::StructureIDBlob::StructureIDBlob):
        (JSC::StructureIDBlob::operator=):
        * runtime/WeakMapData.cpp:
        (JSC::WeakMapData::visitChildren):
        (JSC::WeakMapData::set):
        * tests/stress/basic-eden-gc-test.js: Added.
            Hilariously, an earlier version of this patch that didn't have the NewGrey/OldGrey distinction
            would only crash super-big tests that GCd twice but it didn't crash any small focused test. All
            it took to show the need for the NewGrey/OldGrey distinction was this super simple test.

2015-10-05  Geoffrey Garen  <ggaren@apple.com>

        JSC::SlotVisitor should not be a hot mess
        https://bugs.webkit.org/show_bug.cgi?id=149798

        Reviewed by Andreas Kling.

        I had to debug JSC::SlotVisitor the other day. It was hard to follow.
        Let's make it easy to follow.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::resetVisitors):
        (JSC::Heap::objectCount):
        (JSC::Heap::addToRememberedSet):
        (JSC::Heap::collectAndSweep):
        * heap/Heap.h: Deleted the string hash-consing code. It
        was dead code.

        Since no benchmark noticed the commit that broke this feature, perhaps
        it's not worth having.

        Either way, the best thing to do with dead code is to delete it.
        It's still there in svn if we ever want to pick it up again.

        * heap/HeapRootVisitor.h:
        (JSC::HeapRootVisitor::visit):
        (JSC::HeapRootVisitor::visitor): Removed the private append functions
        for unsafe pointers and switched HeapRootVisitor over to the public
        specially named functions for unsafe pointers.

        In future, we should either remove the public specially named functions
        or remove HeapRootVisitor, since they serve the same purpose. At least
        for now we don't have pairs of functions on SlotVisitor that do the
        exact same thing.

        * heap/SlotVisitor.cpp:
        (JSC::validate): Moved this static function to the top of the file.

        (JSC::SlotVisitor::SlotVisitor):
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::reset): More hash cons removal.

        (JSC::SlotVisitor::append):

        (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
        (JSC::SlotVisitor::appendToMarkStack): Renamed these functions to 
        distinguish them from the up-front helper functions that just do type
        conversions. These are the functions that actually do stuff.

        Moved these functions out of line to make it easier to set breakpoints,
        and to enable code changes for debugging, like printf and synchronous
        marking, without recompiling the world.

        setMarkedAndAppendToMarkStack is roughly 258 bytes long (not including
        function prologue and epilogue), so inlining it was probably not a
        great idea in the first place.

        (JSC::SlotVisitor::donateKnownParallel):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::drainFromShared): Removed some stack probing code.
        It was also dead.

        (JSC::SlotVisitor::addOpaqueRoot):
        (JSC::SlotVisitor::containsOpaqueRoot):
        (JSC::SlotVisitor::containsOpaqueRootTriState):
        (JSC::SlotVisitor::opaqueRootCount):
        (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
        (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable):
        (JSC::SlotVisitor::donate):
        (JSC::SlotVisitor::donateAndDrain):
        (JSC::SlotVisitor::copyLater):
        (JSC::SlotVisitor::mergeOpaqueRoots):
        (JSC::SlotVisitor::harvestWeakReferences):
        (JSC::SlotVisitor::finalizeUnconditionalFinalizers):
        (JSC::SlotVisitor::dump): Moved more code out-of-line. These code paths
        are not hot and/or not small, so we need more evidence before we inline
        them. The SlotVisitor headers are included everywhere, so we should
        make them include less.

        Removed "internal" from all function names because it wasn't applied in
        any consistent way that would mean anything.

        (JSC::JSString::tryHashConsLock): Deleted.
        (JSC::JSString::releaseHashConsLock): Deleted.
        (JSC::JSString::shouldTryHashCons): Deleted.
        (JSC::SlotVisitor::internalAppend): Deleted.
        (JSC::SlotVisitor::validate): Deleted.

        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::resetChildCount): Deleted.
        (JSC::SlotVisitor::childCount): Deleted.
        (JSC::SlotVisitor::incrementChildCount): Deleted. Removed this child
        count thing. It was dead code.

        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::appendUnbarrieredPointer):
        (JSC::SlotVisitor::appendUnbarrieredReadOnlyPointer):
        (JSC::SlotVisitor::appendUnbarrieredValue):
        (JSC::SlotVisitor::appendUnbarrieredReadOnlyValue): Some renaming and un-inlining.

        (JSC::SlotVisitor::appendUnbarrieredWeak): Don't null check our input.
        The one true place where null checking happens is our out-of-line
        code. All inline functions do only type conversions.

        (JSC::SlotVisitor::append):
        (JSC::SlotVisitor::appendValues):
        (JSC::SlotVisitor::addWeakReferenceHarvester):
        (JSC::SlotVisitor::addUnconditionalFinalizer):
        (JSC::SlotVisitor::reportExtraMemoryVisited): Some renaming and un-inlining.

        (JSC::SlotVisitor::internalAppend): Deleted.
        (JSC::SlotVisitor::unconditionallyAppend): Deleted.
        (JSC::SlotVisitor::addOpaqueRoot): Deleted.
        (JSC::SlotVisitor::containsOpaqueRoot): Deleted.
        (JSC::SlotVisitor::containsOpaqueRootTriState): Deleted.
        (JSC::SlotVisitor::opaqueRootCount): Deleted.
        (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): Deleted.
        (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable): Deleted.
        (JSC::SlotVisitor::donate): Deleted.
        (JSC::SlotVisitor::donateAndDrain): Deleted.
        (JSC::SlotVisitor::copyLater): Deleted.

        * runtime/JSString.h:
        (JSC::JSString::finishCreation):
        (JSC::JSString::setIs8Bit):
        (JSC::JSString::isHashConsSingleton): Deleted.
        (JSC::JSString::clearHashConsSingleton): Deleted.
        (JSC::JSString::setHashConsSingleton): Deleted. More hash cons removal.

        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::currentThreadIsHoldingAPILock):
        (JSC::VM::apiLock):
        (JSC::VM::haveEnoughNewStringsToHashCons): Deleted.
        (JSC::VM::resetNewStringsSinceLastHashCons): Deleted. More hash cons removal.

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

        Inline cache repatching should be throttled if it happens a lot
        https://bugs.webkit.org/show_bug.cgi?id=149796
        rdar://problem/22674436

        Reviewed by Saam Barati.

        We noticed a slight PLT regression from http://trac.webkit.org/changeset/189586. It's because
        some pages do things that our inline caches mishandle, in the sense that some ICs end up
        repatching themselves very frequently. The cost of repatching outweighs the speed-up on those
        pages. There are probably super smart things we could do to tune the IC heuristics to make the
        ICs do the right thing on those pages. But more fundamentally, we should ensure that our ICs
        back off from continuous repatching if they repatch a lot. That's what this change does.

        With this change, StructureStubInfo counts the number of repatchings. If that exceeds a
        threshold, we put the IC into a cool-down mode, where some number of future repatch events do
        nothing but decrement the cool-down counter. The duration of cool-down increases exponentially
        every time we have to do it.

        This change also outlines a lot of code. The fact that StructureStubInfo had a lot of inline
        methods was starting to get on my nerves. Now it only has inline methods for things that need
        to be inlined. Also, I changed StructureStubInfo to be a class rather than a struct. Maybe
        with enough such incremental changes, eventually StructureStubInfo will actually behave like a
        proper class.

        This has no effect on JSC benchmarks. It progresses one of the pages that was hit by the
        regression by 15%. It's hard to see if this totally fixes the entire PLT regression since the
        geomean regression was very close to noise.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdCacheStatus):
        (JSC::CodeBlock::printPutByIdCacheStatus):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::checkIfOptimizationThresholdReached):
        * bytecode/CodeBlock.h:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/StructureStubClearingWatchpoint.h:
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::StructureStubInfo):
        (JSC::StructureStubInfo::~StructureStubInfo):
        (JSC::StructureStubInfo::initGetByIdSelf):
        (JSC::StructureStubInfo::initPutByIdReplace):
        (JSC::StructureStubInfo::initStub):
        (JSC::StructureStubInfo::deref):
        (JSC::StructureStubInfo::addAccessCase):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::considerCaching):
        (JSC::StructureStubInfo::willRepatch):
        (JSC::StructureStubInfo::willCoolDown):
        (JSC::getStructureStubInfoCodeOrigin):
        (JSC::StructureStubInfo::StructureStubInfo): Deleted.
        (JSC::StructureStubInfo::initGetByIdSelf): Deleted.
        (JSC::StructureStubInfo::initPutByIdReplace): Deleted.
        (JSC::StructureStubInfo::initStub): Deleted.
        (JSC::StructureStubInfo::seenOnce): Deleted.
        (JSC::StructureStubInfo::setSeen): Deleted.
        * jit/JIT.h:
        * jit/JITOperations.cpp:
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::tryRepatchIn):
        * runtime/Options.h:

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

        CodeBlock.h shouldn't be included from everywhere
        https://bugs.webkit.org/show_bug.cgi?id=149785

        Reviewed by Andreas Kling.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
        * dfg/DFGAdaptiveStructureWatchpoint.cpp:
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
        (JSC::CallFrame::callSiteBitsAreCodeOriginIndex):
        (JSC::CallFrame::callSiteAsRawBits):
        (JSC::CallFrame::callSiteIndex):
        (JSC::CallFrame::hasActivation):
        (JSC::CallFrame::uncheckedActivation):
        (JSC::CallFrame::stack):
        * interpreter/CallFrameInlines.h: Removed.
        * interpreter/Interpreter.cpp:
        * interpreter/StackVisitor.cpp:
        * runtime/DirectArguments.cpp:
        * runtime/ErrorInstance.cpp:
        * runtime/JSArray.cpp:
        * runtime/JSCInlines.h:
        * runtime/LiteralParser.cpp:
        * runtime/NullSetterFunction.cpp:
        * tools/JSDollarVMPrototype.cpp:

2015-10-03  Commit Queue  <commit-queue@webkit.org>

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

        Caused a lot of leaks (Requested by ap on #webkit).

        Reverted changeset:

        "Unreviewed, rolling back in r190450"
        https://bugs.webkit.org/show_bug.cgi?id=149727
        http://trac.webkit.org/changeset/190522

2015-10-02  Matt Baker  <mattbaker@apple.com>

        Web Inspector: Add breakpoint option to ignore n times before stopping
        https://bugs.webkit.org/show_bug.cgi?id=147664

        Reviewed by Timothy Hatcher.

        * debugger/Breakpoint.h:
        (JSC::Breakpoint::Breakpoint):
        Added ignoreCount and hitCount fields. Cleaned up initializers.

        * debugger/Debugger.cpp:
        (JSC::Debugger::hasBreakpoint):
        If a breakpoint matches the current text position, increment breakpoint hit count and
        compare with ignore count before testing the breakpoint condition.

        * inspector/ScriptBreakpoint.h:
        (Inspector::ScriptBreakpoint::ScriptBreakpoint):
        Added ignoreCount field. Cleaned up initializers.

        * inspector/ScriptDebugServer.cpp:
        (Inspector::ScriptDebugServer::setBreakpoint):
        Added ignoreCount field.

        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::buildObjectForBreakpointCookie):
        (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
        (Inspector::InspectorDebuggerAgent::setBreakpoint):
        (Inspector::InspectorDebuggerAgent::continueToLocation):
        (Inspector::InspectorDebuggerAgent::didParseSource):
        Plumbing for ignoreCount property.

        * inspector/protocol/Debugger.json:
        Added optional ignoreCount property to BreakpointOptions object.

2015-10-02  Filip Pizlo <fpizlo@apple.com> and Mark Lam <mark.lam@apple.com>

        We should not add InferredTypeTables to old Structures
        https://bugs.webkit.org/show_bug.cgi?id=149767
        rdar://problem/22825526

        Reviewed by Saam Barati.

        Our property type inference has an optimization where the absence of an InferredTypeTable is
        taken to mean that all properties are TOP. This is great because most Structures come into
        existence through reflective stores, and we don't want to waste time inferring types for
        those.

        But our code was not obeying this rule properly. If we were doing a transition, we would
        assume that this meant that we were creating a new structure, and so we would give it an
        InferredTypeTable if we were doing a non-reflective store (i.e. context = PutById). But that
        same structure could already have been in use prior to us giving it an InferredTypeTable. At
        that point bad things will start to happen because the objects created before we created the
        table, and the inline caches compiled before then, will have types that disagree with the new
        objects and inline caches despite them sharing the same structure and property names.

        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::putDirectWithoutTransition):
        * runtime/Structure.h:
        * tests/stress/add-inferred-type-table-to-existing-structure.js: Added.
        (foo):
        (bar):
        (baz):

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

        Unreviewed, rolling out r190520, some tests assert / crash.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/Heap.cpp:
        (JSC::Heap::willStartCollection): Deleted.
        (JSC::Heap::didFinishCollection): Deleted.
        * heap/Heap.h:
        (JSC::Heap::addObserver): Deleted.
        (JSC::Heap::removeObserver): Deleted.
        * heap/HeapObserver.h: Removed.
        * heap/MarkedSpace.h:
        * inspector/InspectorEnvironment.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::vm): Deleted.
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/agents/InspectorHeapAgent.cpp: Removed.
        * inspector/agents/InspectorHeapAgent.h: Removed.
        * inspector/protocol/Heap.json: Removed.

2015-10-01  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling back in r190450
        https://bugs.webkit.org/show_bug.cgi?id=149727

        The cause of the crash was a CodeBlock, after surviving a call to
        deleteAllCode by virtue of being in the remembered set, trying to mark
        its inlined CodeBlocks via pointers from its inlined executables.
        Since deleteAllCode clears those pointers, the CodeBlock would ASSERT.
        (Any other choice to retain a CodeBlock after deleteAllCode -- for
        example, conservative marking -- could trigger the same bug.)

        The fix is for InlineCallFrame to point directly to its inlined CodeBlock
        instead of pointing indirectly via an executable. This guarantees that
        CodeBlocks are GC safe regardless of whether we've called deleteAllCode.

        Restored changesets:

        "CodeBlock should be a GC object"
        https://bugs.webkit.org/show_bug.cgi?id=149727
        http://trac.webkit.org/changeset/190450

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

        Web Inspector: Include Garbage Collection Event in Timeline
        https://bugs.webkit.org/show_bug.cgi?id=142510

        Reviewed by Geoffrey Garen.

        * CMakeLists.txt:
        * DerivedSources.make:
        * JavaScriptCore.xcodeproj/project.pbxproj:

        * heap/HeapObserver.h:        
        * heap/Heap.cpp:
        (JSC::Heap::willStartCollection):
        (JSC::Heap::didFinishCollection):
        * heap/Heap.h:
        (JSC::Heap::addObserver):
        (JSC::Heap::removeObserver):
        Allow observers on heap to add hooks for starting / ending garbage collection.

        * inspector/InspectorEnvironment.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::vm):
        * inspector/JSGlobalObjectInspectorController.h:
        Access the VM through the InspectorEnvironment as it won't change.

        * inspector/agents/InspectorHeapAgent.cpp: Added.
        (Inspector::InspectorHeapAgent::InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
        (Inspector::InspectorHeapAgent::didCreateFrontendAndBackend):
        (Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
        (Inspector::InspectorHeapAgent::enable):
        (Inspector::InspectorHeapAgent::disable):
        (Inspector::InspectorHeapAgent::gc):
        (Inspector::protocolTypeForHeapOperation):
        (Inspector::InspectorHeapAgent::willGarbageCollect):
        (Inspector::InspectorHeapAgent::didGarbageCollect):
        * inspector/agents/InspectorHeapAgent.h: Added.
        * inspector/protocol/Heap.json: Added.
        New domain and agent to handle tasks related to the JavaScriptCore heap.

2015-10-01  Geoffrey Garen  <ggaren@apple.com>

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

        Crashes seen on el cap wk1 bots.

        Reverted changesets:

        "CodeBlock should be a GC object"
        https://bugs.webkit.org/show_bug.cgi?id=149727
        http://trac.webkit.org/changeset/190450

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::inferredName):
        (JSC::CodeBlock::dumpAssumingJITType):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::~CodeBlock):
        (JSC::CodeBlock::setNumParameters):
        (JSC::CodeBlock::specialOSREntryBlockOrNull):
        (JSC::CodeBlock::visitStrongly):
        (JSC::CodeBlock::visitAggregate):
        (JSC::CodeBlock::shouldVisitStrongly):
        (JSC::CodeBlock::isKnownToBeLiveDuringGC):
        (JSC::CodeBlock::shouldJettisonDueToWeakReference):
        (JSC::CodeBlock::shouldJettisonDueToOldAge):
        (JSC::CodeBlock::determineLiveness):
        (JSC::CodeBlock::visitWeakReferences):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        (JSC::CodeBlock::finalizeBaselineJITInlineCaches):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::visitOSRExitTargets):
        (JSC::CodeBlock::unlinkIncomingCalls):
        (JSC::CodeBlock::linkIncomingCall):
        (JSC::CodeBlock::newReplacement):
        (JSC::ProgramCodeBlock::replacement):
        (JSC::ModuleProgramCodeBlock::replacement):
        (JSC::EvalCodeBlock::replacement):
        (JSC::FunctionCodeBlock::replacement):
        (JSC::ProgramCodeBlock::capabilityLevelInternal):
        (JSC::ModuleProgramCodeBlock::capabilityLevelInternal):
        (JSC::EvalCodeBlock::capabilityLevelInternal):
        (JSC::FunctionCodeBlock::capabilityLevelInternal):
        (JSC::WebAssemblyCodeBlock::replacement):
        (JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
        (JSC::CodeBlock::jettison):
        (JSC::CodeBlock::capabilityLevel):
        (JSC::FunctionCodeBlock::destroy): Deleted.
        (JSC::WebAssemblyCodeBlock::destroy): Deleted.
        (JSC::ProgramCodeBlock::destroy): Deleted.
        (JSC::ModuleProgramCodeBlock::destroy): Deleted.
        (JSC::EvalCodeBlock::destroy): Deleted.
        (JSC::CodeBlock::finishCreation): Deleted.
        (JSC::CodeBlock::setAlternative): Deleted.
        (JSC::CodeBlock::visitWeakly): Deleted.
        (JSC::CodeBlock::visitChildren): Deleted.
        (JSC::timeToLive): Deleted.
        (JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences): Deleted.
        (JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
        (JSC::CodeBlock::replacement): Deleted.
        (JSC::CodeBlock::computeCapabilityLevel): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::unlinkedCodeBlock):
        (JSC::CodeBlock::addressOfNumParameters):
        (JSC::CodeBlock::offsetOfNumParameters):
        (JSC::CodeBlock::alternative):
        (JSC::CodeBlock::setAlternative):
        (JSC::CodeBlock::forEachRelatedCodeBlock):
        (JSC::CodeBlock::specializationKind):
        (JSC::CodeBlock::instructionCount):
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::hasBaselineJITProfiling):
        (JSC::CodeBlock::capabilityLevelState):
        (JSC::CodeBlock::addConstant):
        (JSC::CodeBlock::appendExceptionHandler):
        (JSC::CodeBlock::setConstantRegisters):
        (JSC::CodeBlock::replaceConstant):
        (JSC::GlobalCodeBlock::GlobalCodeBlock):
        (JSC::ProgramCodeBlock::ProgramCodeBlock):
        (JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
        (JSC::EvalCodeBlock::EvalCodeBlock):
        (JSC::EvalCodeBlock::variable):
        (JSC::EvalCodeBlock::numVariables):
        (JSC::EvalCodeBlock::unlinkedEvalCodeBlock):
        (JSC::FunctionCodeBlock::FunctionCodeBlock):
        (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
        (JSC::ExecState::uncheckedR):
        (JSC::CodeBlock::clearMarks):
        (JSC::CodeBlockSet::mark):
        (JSC::ScriptExecutable::forEachCodeBlock):
        (JSC::ProgramCodeBlock::create): Deleted.
        (JSC::ProgramCodeBlock::createStructure): Deleted.
        (JSC::ModuleProgramCodeBlock::create): Deleted.
        (JSC::ModuleProgramCodeBlock::createStructure): Deleted.
        (JSC::EvalCodeBlock::create): Deleted.
        (JSC::EvalCodeBlock::createStructure): Deleted.
        (JSC::FunctionCodeBlock::create): Deleted.
        (JSC::FunctionCodeBlock::createStructure): Deleted.
        (JSC::WebAssemblyCodeBlock::create): Deleted.
        (JSC::WebAssemblyCodeBlock::createStructure): Deleted.
        (JSC::CodeBlock::clearVisitWeaklyHasBeenCalled): Deleted.
        * bytecode/DeferredCompilationCallback.cpp:
        (JSC::DeferredCompilationCallback::DeferredCompilationCallback):
        (JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
        (JSC::DeferredCompilationCallback::compilationDidComplete):
        * bytecode/DeferredCompilationCallback.h:
        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGDesiredTransitions.cpp:
        (JSC::DFG::DesiredTransition::reallyAdd):
        * dfg/DFGDesiredWeakReferences.cpp:
        (JSC::DFG::DesiredWeakReferences::reallyAdd):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph):
        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::osrEntryBlock): Deleted.
        (JSC::DFG::JITCode::setOSREntryBlock): Deleted.
        (JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        (JSC::DFG::JITFinalizer::finalizeCommon):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGOperations.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::reallyAdd):
        (JSC::DFG::Plan::notifyReady):
        (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
        (JSC::DFG::Plan::finalizeAndNotifyCallback):
        (JSC::DFG::Plan::key):
        (JSC::DFG::Plan::clearCodeBlockMarks):
        (JSC::DFG::Plan::checkLivenessAndVisitChildren):
        (JSC::DFG::Plan::rememberCodeBlocks): Deleted.
        * dfg/DFGPlan.h:
        * dfg/DFGToFTLDeferredCompilationCallback.cpp:
        (JSC::DFG::ToFTLDeferredCompilationCallback::ToFTLDeferredCompilationCallback):
        (JSC::DFG::ToFTLDeferredCompilationCallback::~ToFTLDeferredCompilationCallback):
        (JSC::DFG::ToFTLDeferredCompilationCallback::create):
        (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
        (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
        * dfg/DFGToFTLDeferredCompilationCallback.h:
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::~ToFTLForOSREntryDeferredCompilationCallback):
        (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::completeAllPlansForVM):
        (JSC::DFG::Worklist::clearCodeBlockMarks):
        (JSC::DFG::completeAllPlansForVM):
        (JSC::DFG::clearCodeBlockMarks):
        (JSC::DFG::Worklist::rememberCodeBlocks): Deleted.
        (JSC::DFG::rememberCodeBlocks): Deleted.
        * dfg/DFGWorklist.h:
        (JSC::DFG::worklistForIndexOrNull):
        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::~CodeBlockSet):
        (JSC::CodeBlockSet::add):
        (JSC::CodeBlockSet::clearMarksForFullCollection):
        (JSC::CodeBlockSet::clearMarksForEdenCollection):
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
        (JSC::CodeBlockSet::remove):
        (JSC::CodeBlockSet::traceMarked):
        (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
        (JSC::CodeBlockSet::dump):
        * heap/CodeBlockSet.h:
        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::clearLivenessData):
        (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
        (JSC::Heap::deleteAllCodeBlocks):
        (JSC::Heap::deleteAllUnlinkedCodeBlocks):
        (JSC::Heap::clearUnmarkedExecutables):
        (JSC::Heap::willStartCollection):
        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * jit/GCAwareJITStubRoutine.h:
        * jit/JITCode.h:
        (JSC::JITCode::isJIT):
        (JSC::JITCode::timeToLive):
        (JSC::JITCode::isLowerTier):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_enter):
        * jit/JITOperations.cpp:
        * jit/JITToDFGDeferredCompilationCallback.cpp:
        (JSC::JITToDFGDeferredCompilationCallback::create):
        (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
        (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
        * jit/JITToDFGDeferredCompilationCallback.h:
        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::tryRepatchIn):
        (JSC::linkFor):
        (JSC::linkPolymorphicCall):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::setUpCall):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/Executable.cpp:
        (JSC::ExecutableBase::clearCode):
        (JSC::ScriptExecutable::installCode):
        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ScriptExecutable::newReplacementCodeBlockFor):
        (JSC::ScriptExecutable::prepareForExecutionImpl):
        (JSC::EvalExecutable::visitChildren):
        (JSC::EvalExecutable::clearCode):
        (JSC::ProgramExecutable::checkSyntax):
        (JSC::ProgramExecutable::visitChildren):
        (JSC::ProgramExecutable::clearCode):
        (JSC::ModuleProgramExecutable::visitChildren):
        (JSC::ModuleProgramExecutable::clearCode):
        (JSC::FunctionExecutable::baselineCodeBlockFor):
        (JSC::FunctionExecutable::visitChildren):
        (JSC::FunctionExecutable::clearCode):
        (JSC::FunctionExecutable::fromGlobalCode):
        (JSC::WebAssemblyExecutable::visitChildren):
        (JSC::WebAssemblyExecutable::clearCode):
        (JSC::WebAssemblyExecutable::prepareForExecution):
        * runtime/Executable.h:
        (JSC::ExecutableBase::generatedJITCodeForCall):
        (JSC::ScriptExecutable::prepareForExecution):
        (JSC::ExecutableBase::clearCodeVirtual):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:

2015-10-01  Geoffrey Garen  <ggaren@apple.com>

        CodeBlock should be a GC object
        https://bugs.webkit.org/show_bug.cgi?id=149727

        Reviewed by Filip Pizlo.

        We want CodeBlock to be a GC object:

        (1) Sane write barriers. Because CodeBlock wasn't a GC object, we couldn't
        execute a write barrier on it. This caused us to do weird things that
        were hard to reason about, like executing a barrier on a related executable
        (even though the executable might stop pointing to the CodeBlock before
        the next GC), or pretending that an object had written to itself. Now,
        when we write to a CodeBlock, we barrier the CodeBlock, and that's that.

        (2) Simpler marking and destruction logic. There's no need to have a
        custom remembered set or a destruction fixpoint if we just obey normal
        GC rules.

        * bytecode/CodeBlock.cpp:
        (JSC::FunctionCodeBlock::destroy):
        (JSC::WebAssemblyCodeBlock::destroy):
        (JSC::ProgramCodeBlock::destroy):
        (JSC::ModuleProgramCodeBlock::destroy):
        (JSC::EvalCodeBlock::destroy): Add ClassInfo and destroy functions
        because our GC object model requires them.

        Note that we do not set the needsDestruction flag. Since CodeBlock needs
        eager destruction, it runs its destructors through CodeBlockSet,
        and not through normal object sweeping.

        (JSC::CodeBlock::finishCreation): Factor out finishCreation from the
        constructor because our GC object model requires it. Change write
        barriers to note the CodeBlock as the owner.

        (JSC::CodeBlock::~CodeBlock): Refactor to use the shared
        unlinkIncomingCalls() function instead of rolling a copy by hand.

        (JSC::CodeBlock::visitWeakly): New helper function for owner executables
        to do weak marking that might jettison a CodeBlock. Our new GC logic
        says that a CodeBlock pointer is a strong reference by default, and
        clients need to opt in if they want to allow a CodeBlock to jettison.
        This is easier to get right because it means that only those
        specific owners that want jettison behavior need to worry about it,
        while all other pointers are valid by default.

        (JSC::CodeBlock::visitChildren): The default visit function keeps
        everything alive.

        (JSC::CodeBlock::shouldVisitStrongly):
        (JSC::CodeBlock::isKnownToBeLiveDuringGC): No need to keep special state
        anymore. If we're marked, we're live -- just like any other object.

        (JSC::timeToLive): Move this code into CodeBlock.cpp so you can mess
        with it without recompiling, and also because it's really a CodeBlock
        policy.

        (JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences):
        (JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Use
        internal objects for virtual callbacks because GC objects can't have
        vtables.

        (JSC::CodeBlock::unlinkIncomingCalls): Remove a fast path check that does
        not exist in the copy of this code in ~CodeBlock because it is not
        actually an optimization.

        (JSC::CodeBlock::replacement):
        (JSC::CodeBlock::computeCapabilityLevel): Make these functions generic
        instead of virtual because GC objects can't have vtables.

        (JSC::CodeBlock::visitStrongly): Deleted.
        (JSC::CodeBlock::visitAggregate): Deleted.
        (JSC::CodeBlock::visitWeakReferences): Deleted.
        (JSC::CodeBlock::finalizeUnconditionally): Deleted.
        (JSC::ProgramCodeBlock::replacement): Deleted.
        (JSC::ModuleProgramCodeBlock::replacement): Deleted.
        (JSC::EvalCodeBlock::replacement): Deleted.
        (JSC::FunctionCodeBlock::replacement): Deleted.
        (JSC::ProgramCodeBlock::capabilityLevelInternal): Deleted.
        (JSC::ModuleProgramCodeBlock::capabilityLevelInternal): Deleted.
        (JSC::EvalCodeBlock::capabilityLevelInternal): Deleted.
        (JSC::FunctionCodeBlock::capabilityLevelInternal): Deleted.
        (JSC::WebAssemblyCodeBlock::replacement): Deleted.
        (JSC::WebAssemblyCodeBlock::capabilityLevelInternal): Deleted.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::unlinkedCodeBlock):
        (JSC::CodeBlock::addressOfNumParameters):
        (JSC::CodeBlock::offsetOfNumParameters):
        (JSC::CodeBlock::alternative):
        (JSC::CodeBlock::forEachRelatedCodeBlock):
        (JSC::CodeBlock::specializationKind):
        (JSC::CodeBlock::instructionCount):
        (JSC::CodeBlock::setJITCode):
        (JSC::CodeBlock::hasBaselineJITProfiling):
        (JSC::CodeBlock::capabilityLevelState):
        (JSC::CodeBlock::addConstant):
        (JSC::CodeBlock::appendExceptionHandler):
        (JSC::CodeBlock::setConstantRegisters):
        (JSC::CodeBlock::replaceConstant):
        (JSC::GlobalCodeBlock::GlobalCodeBlock):
        (JSC::ProgramCodeBlock::create):
        (JSC::ProgramCodeBlock::createStructure):
        (JSC::ProgramCodeBlock::ProgramCodeBlock):
        (JSC::ModuleProgramCodeBlock::create):
        (JSC::ModuleProgramCodeBlock::createStructure):
        (JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
        (JSC::EvalCodeBlock::create):
        (JSC::EvalCodeBlock::createStructure):
        (JSC::EvalCodeBlock::variable):
        (JSC::EvalCodeBlock::numVariables):
        (JSC::EvalCodeBlock::EvalCodeBlock):
        (JSC::EvalCodeBlock::unlinkedEvalCodeBlock):
        (JSC::FunctionCodeBlock::create):
        (JSC::FunctionCodeBlock::createStructure):
        (JSC::FunctionCodeBlock::FunctionCodeBlock):
        (JSC::WebAssemblyCodeBlock::create):
        (JSC::WebAssemblyCodeBlock::createStructure):
        (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
        (JSC::ExecState::uncheckedR):
        (JSC::CodeBlock::clearVisitWeaklyHasBeenCalled):
        (JSC::CodeBlockSet::mark):
        (JSC::ScriptExecutable::forEachCodeBlock):
        (JSC::CodeBlock::setAlternative): Deleted.
        (JSC::CodeBlock::clearMarks): Deleted. Lots of mechanical changes to
        match the logic changes above.

        * bytecode/DeferredCompilationCallback.cpp:
        (JSC::DeferredCompilationCallback::DeferredCompilationCallback):
        (JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
        (JSC::DeferredCompilationCallback::compilationDidComplete):
        * bytecode/DeferredCompilationCallback.h: Provide a profiledDFGCodeBlock
        to all compilation callbacks instead of requiring the callback to
        store the profiledDFGCodeBlock. This is how the rest of compilation
        around the callback works anyway, and it is easier to do things this
        way than to think about how a non-GC malloc'd object should keep its
        CodeBlock alive.

        * bytecode/EvalCodeCache.h:
        (JSC::EvalCodeCache::tryGet):
        (JSC::EvalCodeCache::getSlow):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::addAccessCase): Change the owner for write
        barrier purposes to CodeBlock.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parse):
        * dfg/DFGDesiredTransitions.cpp:
        (JSC::DFG::DesiredTransition::reallyAdd):
        * dfg/DFGDesiredWeakReferences.cpp:
        (JSC::DFG::DesiredWeakReferences::reallyAdd):
        * dfg/DFGDriver.cpp:
        (JSC::DFG::compile):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::Graph): Ditto.

        * dfg/DFGJITCode.h:
        (JSC::DFG::JITCode::osrEntryBlock):
        (JSC::DFG::JITCode::setOSREntryBlock):
        (JSC::DFG::JITCode::clearOSREntryBlock): Use helper functions for 
        accessing osrEntryBlock to help with write barrier stuff.

        * dfg/DFGJITFinalizer.cpp:
        (JSC::DFG::JITFinalizer::finalize):
        (JSC::DFG::JITFinalizer::finalizeFunction):
        (JSC::DFG::JITFinalizer::finalizeCommon):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::adjustAndJumpToTarget): Use CodeBlock as owner instead of
        executable.

        * dfg/DFGOperations.cpp:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::Plan):
        (JSC::DFG::Plan::reallyAdd):
        (JSC::DFG::Plan::notifyReady):
        (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
        (JSC::DFG::Plan::finalizeAndNotifyCallback):
        (JSC::DFG::Plan::key):
        (JSC::DFG::Plan::rememberCodeBlocks):
        (JSC::DFG::Plan::checkLivenessAndVisitChildren):
        (JSC::DFG::Plan::clearCodeBlockMarks): Deleted.
        * dfg/DFGPlan.h: Use normal GC write barrier concepts to model the fact
        that the compiler writes to CodeBlocks.

        * dfg/DFGToFTLDeferredCompilationCallback.cpp:
        (JSC::DFG::ToFTLDeferredCompilationCallback::ToFTLDeferredCompilationCallback):
        (JSC::DFG::ToFTLDeferredCompilationCallback::~ToFTLDeferredCompilationCallback):
        (JSC::DFG::ToFTLDeferredCompilationCallback::create):
        (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
        (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
        * dfg/DFGToFTLDeferredCompilationCallback.h:
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::~ToFTLForOSREntryDeferredCompilationCallback):
        (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
        (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
        * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h: We always have
        a profiledDFGCodeBlock passed to use -- see above.

        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::completeAllPlansForVM):
        (JSC::DFG::Worklist::rememberCodeBlocks):
        (JSC::DFG::completeAllPlansForVM):
        (JSC::DFG::rememberCodeBlocks):
        (JSC::DFG::Worklist::clearCodeBlockMarks): Deleted.
        (JSC::DFG::clearCodeBlockMarks): Deleted.
        * dfg/DFGWorklist.h:
        (JSC::DFG::worklistForIndexOrNull): Renamed to use remembered set terminology.

        * ftl/FTLJITFinalizer.cpp:
        (JSC::FTL::JITFinalizer::finalizeFunction):

        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::~CodeBlockSet):
        (JSC::CodeBlockSet::add):
        (JSC::CodeBlockSet::clearMarksForFullCollection):
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced): No need for a fixpoint
        anymore since the GC can tell us if we are live.

        (JSC::CodeBlockSet::remove):
        (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
        (JSC::CodeBlockSet::dump):
        (JSC::CodeBlockSet::clearMarksForEdenCollection): Deleted. No need for
        this logic anymore since the GC will clear our mark bit.

        (JSC::CodeBlockSet::traceMarked): Deleted. No need for this marking
        fixpoint anymore either.

        * heap/CodeBlockSet.h:

        * heap/Heap.cpp:
        (JSC::Heap::markRoots): Moved some of this logic around to make the
        algorithm clearer. 

        (JSC::Heap::deleteAllCodeBlocks): Deleting CodeBlocks can only clear
        pointers immediately; they won't fully delete until the next GC and sweep.

        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * jit/GCAwareJITStubRoutine.h: CodeBlock is owner now.

        * jit/JITCode.h:
        (JSC::JITCode::isJIT):
        (JSC::JITCode::isLowerTier):
        (JSC::JITCode::timeToLive): Deleted.

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_enter): CodeBlock is owner now.

        * jit/JITOperations.cpp:
        * jit/JITToDFGDeferredCompilationCallback.cpp:
        (JSC::JITToDFGDeferredCompilationCallback::create):
        (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
        (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
        * jit/JITToDFGDeferredCompilationCallback.h:

        * jit/Repatch.cpp:
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::tryRepatchIn):
        (JSC::linkFor):
        (JSC::linkPolymorphicCall):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::setUpCall):
        * runtime/CommonSlowPaths.cpp:
        (JSC::SLOW_PATH_DECL): 
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): CodeBlock is owner now.

        * runtime/Executable.cpp:
        (JSC::ExecutableBase::clearCode): Provide a generic clearCode() so that
        it can be used on any Executable. This fixes a very subtle bug where
        deleteAllCode() does not remove CodeBlocks from non-function executables
        that have been saved in stack traces.

        (JSC::ScriptExecutable::installCode): WriteBarrier requires special
        handling for pointers that may be null.

        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ScriptExecutable::newReplacementCodeBlockFor):
        (JSC::ScriptExecutable::prepareForExecutionImpl): Update for interface
        changes.

        (JSC::EvalExecutable::visitChildren):
        (JSC::ProgramExecutable::visitChildren):
        (JSC::ModuleProgramExecutable::visitChildren):
        (JSC::FunctionExecutable::visitChildren):
        (JSC::WebAssemblyExecutable::visitChildren): Visit weakly because we want
        to participate in jettisoning.

        (JSC::WebAssemblyExecutable::prepareForExecution):
        (JSC::EvalExecutable::clearCode): Deleted.
        (JSC::ProgramExecutable::clearCode): Deleted.
        (JSC::ModuleProgramExecutable::clearCode): Deleted.
        (JSC::FunctionExecutable::clearCode): Deleted.
        (JSC::WebAssemblyExecutable::clearCode): Deleted.

        * runtime/Executable.h:
        (JSC::ExecutableBase::generatedJITCodeForCall):
        (JSC::ScriptExecutable::prepareForExecution):
        (JSC::ExecutableBase::clearCodeVirtual): Deleted.

        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h: Provide structures because our GC requires it.

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

        Remove unnecessary SpecialFastCaseProfiles.
        https://bugs.webkit.org/show_bug.cgi?id=149729

        Reviewed by Saam Barati.

        The current baseline code creates special fast case profiles records for
        bytecodes that don't need them.  This was done to keep the DFG from crashing when
        it searches for such a profile and don't find one.  Instead, we will fix the code
        to check for the existence of the profile before dereferencing it to get a count.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::couldTakeSpecialFastCase):
        (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
        (JSC::CodeBlock::numberOfArrayProfiles):
        (JSC::CodeBlock::arrayProfiles):
        (JSC::CodeBlock::addArrayProfile):
        (JSC::CodeBlock::likelyToTakeSpecialFastCase): Deleted.  Not used.
        (JSC::CodeBlock::likelyToTakeAnySlowCase): Deleted.   Not used.
        * jit/JITArithmetic.cpp:

        (JSC::JIT::compileBinaryArithOp):
        - Only op_mul needs the profile.  So, only allocate it in the op_mul case.

        (JSC::JIT::emit_op_mul):
        - These op_mul cases create the profile but never increments its counter.
          Hence, we can get rid of these.

2015-10-01  Keith Miller  <keith_miller@apple.com>

        [ES6] Add TypedArray.prototype functionality.
        https://bugs.webkit.org/show_bug.cgi?id=148035

        Reviewed by Geoffrey Garen.

        This patch should add most of the functionality for
        the prototype properties of TypedArray objects in ES6.
        There are a few exceptions to this, which will be added
        in upcoming patches:

        1) First we do not use the species constructor for some
        of the TypedArray prototype functions (namely: map, filter,
        slice, and subarray). That will need to be added when
        species constructors are finished.

        2) TypedArrays still have a length, byteOffset, byteLength,
        and buffer are still attached to the TypedArray instance (in
        the spec they are on the TypedArray.prototype instance object)
        since the JIT currently assumes those properties are fixed.

        3) The TypedArray.constructor property is not added yet
        as it should point to the TypedArray instance object,
        which will be added in a future patch.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/TypedArray.prototype.js: Added.
        (every):
        (find):
        (findIndex):
        (forEach):
        (some):
        (sort.min):
        (sort.merge):
        (sort.mergeSort):
        (sort):
        (reduce):
        (reduceRight):
        (map):
        (filter):
        (toLocaleString):
        * runtime/ArrayPrototype.cpp:
        * runtime/ArrayPrototype.h:
        * runtime/CommonIdentifiers.h:
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
        (JSC::JSGenericTypedArrayView::setRangeToValue):
        (JSC::JSGenericTypedArrayView::sort):
        (JSC::JSGenericTypedArrayView::purifyArray):
        (JSC::JSGenericTypedArrayView::sortComparison):
        (JSC::JSGenericTypedArrayView::sortFloat):
        * runtime/JSGenericTypedArrayViewInlines.h:
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
        (JSC::argumentClampedIndexFromStartOrEnd):
        (JSC::genericTypedArrayViewProtoFuncSet):
        (JSC::genericTypedArrayViewProtoFuncEntries):
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncFill):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncJoin):
        (JSC::genericTypedArrayViewProtoFuncKeys):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewProtoGetterFuncLength):
        (JSC::genericTypedArrayViewProtoGetterFuncByteLength):
        (JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
        (JSC::genericTypedArrayViewProtoFuncReverse):
        (JSC::genericTypedArrayViewPrivateFuncSort):
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewProtoFuncSubarray):
        (JSC::typedArrayViewProtoFuncValues):
        * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
        (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
        (JSC::genericTypedArrayViewProtoFuncSet): Deleted.
        (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSObject.h:
        * runtime/JSTypedArrayPrototypes.cpp:
        * runtime/JSTypedArrayPrototypes.h:
        * runtime/JSTypedArrayViewPrototype.cpp: Added.
        (JSC::typedArrayViewPrivateFuncLength):
        (JSC::typedArrayViewPrivateFuncSort):
        (JSC::typedArrayViewProtoFuncSet):
        (JSC::typedArrayViewProtoFuncEntries):
        (JSC::typedArrayViewProtoFuncCopyWithin):
        (JSC::typedArrayViewProtoFuncFill):
        (JSC::typedArrayViewProtoFuncLastIndexOf):
        (JSC::typedArrayViewProtoFuncIndexOf):
        (JSC::typedArrayViewProtoFuncJoin):
        (JSC::typedArrayViewProtoFuncKeys):
        (JSC::typedArrayViewProtoGetterFuncLength):
        (JSC::typedArrayViewProtoGetterFuncByteLength):
        (JSC::typedArrayViewProtoGetterFuncByteOffset):
        (JSC::typedArrayViewProtoFuncReverse):
        (JSC::typedArrayViewProtoFuncSubarray):
        (JSC::typedArrayViewProtoFuncSlice):
        (JSC::typedArrayViewProtoFuncValues):
        (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::JSTypedArrayViewPrototype::create):
        (JSC::JSTypedArrayViewPrototype::createStructure):
        * runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
        * tests/es6.yaml:
        * tests/stress/resources/standalone-pre.js: Added.
        (description):
        (debug):
        (escapeString):
        (testPassed):
        (testFailed):
        (areNumbersEqual):
        (areArraysEqual):
        (isMinusZero):
        (isTypedArray):
        (isResultCorrect):
        (stringify):
        (shouldBe):
        (dfgShouldBe):
        (shouldBeType):
        (shouldBeTrue):
        (shouldBeFalse):
        (shouldBeNaN):
        (shouldBeNull):
        (shouldBeEqualToString):
        (shouldBeUndefined):
        (shouldNotThrow):
        (shouldThrow):
        (dfgCompiled):
        (dfgIncrement):
        (noInline):
        (finishJSTest):
        * tests/stress/resources/typedarray-test-helper-functions.js: Added.
        (forEachTypedArray):
        (isSameFunctionForEachTypedArrayPrototype.eq):
        (isSameFunctionForEachTypedArrayPrototype):
        (hasSameValues):
        (foo):
        (testPrototypeFunctionHelper):
        (testPrototypeFunctionOnSigned):
        (testPrototypeFunctionOnFloat):
        (testPrototypeFunction):
        (tester):
        (testPrototypeReceivesArray):
        * tests/stress/typedarray-copyWithin.js: Added.
        * tests/stress/typedarray-every.js: Added.
        (isBigEnough):
        (isBigEnoughAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-fill.js: Added.
        * tests/stress/typedarray-filter.js: Added.
        (keepEven):
        (keepEvenAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-find.js: Added.
        (keepEven):
        (keepEvenAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-findIndex.js: Added.
        (keepEven):
        (keepEvenAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-forEach.js: Added.
        (checkCorrect.let.list):
        (checkCorrect):
        (createChecker):
        (foo):
        (changeArray):
        (isBigEnoughAndException):
        * tests/stress/typedarray-indexOf.js: Added.
        (keepEven):
        * tests/stress/typedarray-lastIndexOf.js: Added.
        * tests/stress/typedarray-map.js: Added.
        (even):
        (evenAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-reduce.js: Added.
        (createArray):
        (sum):
        (createArrayAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-reduceRight.js: Added.
        (createArray):
        (sum):
        (createArrayAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-slice.js: Added.
        * tests/stress/typedarray-some.js: Added.
        (isBigEnough):
        (isBigEnoughAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-sort.js: Added.
        (sortBackwards):
        (compareException):

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

        Introduce SymbolUse optimization into CompareEq and CompareStrictEq
        https://bugs.webkit.org/show_bug.cgi?id=149616

        Reviewed by Saam Barati.

        Since ES6 Symbols are used as an enum value[1] (And WebKit inspector do so for Esprima's type of nodes),
        optimizing equality comparison for symbols makes much sense.

        This patch leverages SymbolUse for CompareEq and CompareStrictEq.
        Optimizations for both DFG and FTL are implemented.

        [1]: http://www.2ality.com/2014/12/es6-symbols.html

        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::shouldSpeculateSymbol):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
        (JSC::DFG::SpeculativeJIT::compare):
        (JSC::DFG::SpeculativeJIT::compileStrictEq):
        (JSC::DFG::SpeculativeJIT::extractStringImplFromBinarySymbols):
        (JSC::DFG::SpeculativeJIT::compileSymbolEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleSymbolEquality):
        * dfg/DFGSpeculativeJIT.h:
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEq):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareStrictEq):
        * tests/stress/symbol-equality.js: Added.
        (shouldBe):
        (equal):
        (strictEqual):
        (list.forEach.result.set 1):

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

        [Streams API] Add support for private WebCore JS builtins functions
        https://bugs.webkit.org/show_bug.cgi?id=149518

        Reviewed by Darin Adler.

        Adding API to add private identifiers on the fly.
        This is used to support private JS Builtin functions/private JS Builtin names in WebCore.

        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::appendExternalName):
        * runtime/CommonIdentifiers.cpp:
        (JSC::CommonIdentifiers::appendExternalName):
        * runtime/CommonIdentifiers.h:

2015-09-30  Jaehun Lim  <ljaehun.lim@samsung.com>

        Unreviewed, cleanup after r190385

        TypedArray.prototype.js is removed at r190385.
        Remove it from CMakeLists.txt as well.

        * CMakeLists.txt:

2015-09-30  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r190367 and r190373.
        https://bugs.webkit.org/show_bug.cgi?id=149694

        Windows build broken (Requested by smfr on #webkit).

        Reverted changesets:

        "[ES6] Add TypedArray.prototype functionality."
        https://bugs.webkit.org/show_bug.cgi?id=148035
        http://trac.webkit.org/changeset/190367

        "Unreviewed Windows buildfix."
        http://trac.webkit.org/changeset/190373

2015-09-30  Keith Miller  <keith_miller@apple.com>

        Unreviewed Windows buildfix.

        * CMakeLists.txt:

2015-09-30  Michael Saboff  <msaboff@apple.com>

        Relanding r190289 with the following two fixes:

         1. REGRESSION(r190289): It made Speedometer/Full.html performance test fail
            https://bugs.webkit.org/show_bug.cgi?id=149621

            Reviewed by Saam Barati.

            We need to restore callee saves for both the fast and slow paths before making a
            tail call in the FTL.

            * ftl/FTLJSCallBase.cpp:
            (JSC::FTL::JSCallBase::emit):

         2. [ARM] REGRESSION(r190289): It made 374 tests crash on 32 bit ARM Linux
            https://bugs.webkit.org/show_bug.cgi?id=149619

            Reviewed by Filip Pizlo.

            Need to check for ARMv7_TRADITIONAL and ARMv7 in addition to ARM in "if"
            statement to handle platforms with a link register.
            
            * llint/LowLevelInterpreter.asm:
            (prepareForTailCall):

2015-09-30  Keith Miller  <keith_miller@apple.com>

        [ES6] Add TypedArray.prototype functionality.
        https://bugs.webkit.org/show_bug.cgi?id=148035

        Reviewed by Geoffrey Garen.

        This patch should add most of the functionality for
        the prototype properties of TypedArray objects in ES6.
        There are a few exceptions to this, which will be added
        in upcoming patches:

        1) First we do not use the species constructor for some
        of the TypedArray prototype functions (namely: map, filter,
        slice, and subarray). That will need to be added when
        species constructors are finished.

        2) TypedArrays still have a length, byteOffset, byteLength,
        and buffer are still attached to the TypedArray instance (in
        the spec they are on the TypedArray.prototype instance object)
        since the JIT currently assumes those properties are fixed.

        3) The TypedArray.constructor property is not added yet
        as it should point to the TypedArray instance object,
        which will be added in a future patch.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/TypedArray.prototype.js: Added.
        (every):
        (find):
        (findIndex):
        (forEach):
        (some):
        (sort.min):
        (sort.merge):
        (sort.mergeSort):
        (sort):
        (reduce):
        (reduceRight):
        (map):
        (filter):
        (toLocaleString):
        * runtime/ArrayPrototype.cpp:
        * runtime/ArrayPrototype.h:
        * runtime/CommonIdentifiers.h:
        * runtime/JSGenericTypedArrayView.h:
        (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
        (JSC::JSGenericTypedArrayView::setRangeToValue):
        (JSC::JSGenericTypedArrayView::sort):
        (JSC::JSGenericTypedArrayView::purifyArray):
        (JSC::JSGenericTypedArrayView::sortComparison):
        (JSC::JSGenericTypedArrayView::sortFloat):
        * runtime/JSGenericTypedArrayViewInlines.h:
        * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
        (JSC::argumentClampedIndexFromStartOrEnd):
        (JSC::genericTypedArrayViewProtoFuncSet):
        (JSC::genericTypedArrayViewProtoFuncEntries):
        (JSC::genericTypedArrayViewProtoFuncCopyWithin):
        (JSC::genericTypedArrayViewProtoFuncFill):
        (JSC::genericTypedArrayViewProtoFuncIndexOf):
        (JSC::genericTypedArrayViewProtoFuncJoin):
        (JSC::genericTypedArrayViewProtoFuncKeys):
        (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
        (JSC::genericTypedArrayViewProtoGetterFuncLength):
        (JSC::genericTypedArrayViewProtoGetterFuncByteLength):
        (JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
        (JSC::genericTypedArrayViewProtoFuncReverse):
        (JSC::genericTypedArrayViewPrivateFuncSort):
        (JSC::genericTypedArrayViewProtoFuncSlice):
        (JSC::genericTypedArrayViewProtoFuncSubarray):
        (JSC::typedArrayViewProtoFuncValues):
        * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
        (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
        (JSC::genericTypedArrayViewProtoFuncSet): Deleted.
        (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        * runtime/JSObject.h:
        * runtime/JSTypedArrayPrototypes.cpp:
        * runtime/JSTypedArrayPrototypes.h:
        * runtime/JSTypedArrayViewPrototype.cpp: Added.
        (JSC::typedArrayViewPrivateFuncLength):
        (JSC::typedArrayViewPrivateFuncSort):
        (JSC::typedArrayViewProtoFuncSet):
        (JSC::typedArrayViewProtoFuncEntries):
        (JSC::typedArrayViewProtoFuncCopyWithin):
        (JSC::typedArrayViewProtoFuncFill):
        (JSC::typedArrayViewProtoFuncLastIndexOf):
        (JSC::typedArrayViewProtoFuncIndexOf):
        (JSC::typedArrayViewProtoFuncJoin):
        (JSC::typedArrayViewProtoFuncKeys):
        (JSC::typedArrayViewProtoGetterFuncLength):
        (JSC::typedArrayViewProtoGetterFuncByteLength):
        (JSC::typedArrayViewProtoGetterFuncByteOffset):
        (JSC::typedArrayViewProtoFuncReverse):
        (JSC::typedArrayViewProtoFuncSubarray):
        (JSC::typedArrayViewProtoFuncSlice):
        (JSC::typedArrayViewProtoFuncValues):
        (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
        (JSC::JSTypedArrayViewPrototype::finishCreation):
        (JSC::JSTypedArrayViewPrototype::create):
        (JSC::JSTypedArrayViewPrototype::createStructure):
        * runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
        * tests/stress/resources/standalone-pre.js: Added.
        (description):
        (debug):
        (escapeString):
        (testPassed):
        (testFailed):
        (areNumbersEqual):
        (areArraysEqual):
        (isMinusZero):
        (isTypedArray):
        (isResultCorrect):
        (stringify):
        (shouldBe):
        (dfgShouldBe):
        (shouldBeType):
        (shouldBeTrue):
        (shouldBeFalse):
        (shouldBeNaN):
        (shouldBeNull):
        (shouldBeEqualToString):
        (shouldBeUndefined):
        (shouldNotThrow):
        (shouldThrow):
        (dfgCompiled):
        (dfgIncrement):
        (noInline):
        (finishJSTest):
        * tests/stress/resources/typedarray-test-helper-functions.js: Added.
        (forEachTypedArray):
        (isSameFunctionForEachTypedArrayPrototype.eq):
        (isSameFunctionForEachTypedArrayPrototype):
        (hasSameValues):
        (.foo):
        (testPrototypeFunctionHelper):
        (testPrototypeFunctionOnSigned):
        (testPrototypeFunctionOnFloat):
        (testPrototypeFunction):
        (.tester):
        (testPrototypeReceivesArray):
        * tests/stress/typedarray-copyWithin.js: Added.
        * tests/stress/typedarray-every.js: Added.
        (isBigEnough):
        (isBigEnoughAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-fill.js: Added.
        * tests/stress/typedarray-filter.js: Added.
        (keepEven):
        (keepEvenAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-find.js: Added.
        (keepEven):
        (keepEvenAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-findIndex.js: Added.
        (keepEven):
        (keepEvenAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-forEach.js: Added.
        (.checkCorrect.let.list):
        (.checkCorrect):
        (createChecker):
        (foo):
        (changeArray):
        (isBigEnoughAndException):
        * tests/stress/typedarray-indexOf.js: Added.
        (keepEven):
        * tests/stress/typedarray-lastIndexOf.js: Added.
        * tests/stress/typedarray-map.js: Added.
        (even):
        (evenAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-reduce.js: Added.
        (createArray):
        (sum):
        (createArrayAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-reduceRight.js: Added.
        (createArray):
        (sum):
        (createArrayAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-slice.js: Added.
        * tests/stress/typedarray-some.js: Added.
        (isBigEnough):
        (isBigEnoughAndChange):
        (isBigEnoughAndException):
        * tests/stress/typedarray-sort.js: Added.
        (sortBackwards):
        (compareException):

2015-09-30  Commit Queue  <commit-queue@webkit.org>

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

        Caused flaky crashes, rdar://problem/22916304 (Requested by ap
        on #webkit).

        Reverted changeset:

        "ParallelHelperPool::runFunctionInParallel() shouldn't
        allocate, and ParallelHelperPool.h shouldn't be included
        everywhere"
        https://bugs.webkit.org/show_bug.cgi?id=149635
        http://trac.webkit.org/changeset/190324

2015-09-29  Commit Queue  <commit-queue@webkit.org>

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

        Crashing speedometer and some ARM32 tests (Requested by
        msaboff on #webkit).

        Reverted changeset:

        "[ES6] Implement tail calls in the FTL"
        https://bugs.webkit.org/show_bug.cgi?id=148664
        http://trac.webkit.org/changeset/190289

2015-09-29  Filip Pizlo  <fpizlo@apple.com>

        ParallelHelperPool::runFunctionInParallel() shouldn't allocate, and ParallelHelperPool.h shouldn't be included everywhere
        https://bugs.webkit.org/show_bug.cgi?id=149635

        Reviewed by Saam Barati.

        It bugged me that this change caused a whole-world recompile. So, I changed the code so
        that ParallelHelperPool.h is only included by Heap.cpp and not by Heap.h.

        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::markRoots):
        (JSC::Heap::copyBackingStores):
        * heap/Heap.h:

2015-09-29  Filip Pizlo  <fpizlo@apple.com>

        GC copy phase spans too many files
        https://bugs.webkit.org/show_bug.cgi?id=149586

        Reviewed by Andreas Kling.

        This puts the core logic of the copy phase into Heap::copyBackingStores(). Now, instead of
        using many helpers in many places, the actual algorithm is all in one place.

        This lets me do a lot of simplification.

        - CopyVisitor no longer requires that you call startCopying() before, and doneCopying() and
          WTF::releaseFastMallocFreeMemoryForThisThread() after. The constructor and destructor now
          do this for you.

        - CopyVisitor no longer contains the algorithm that drives copying. That's all in
          Heap::copyBackingStores() now. Basically, copyBackingStores() glues together the new
          WTF::ParallelVectorIterator with the copying algorithm that we used to have in
          CopyVisitor::copyFromShared().

        - Lots of stuff that was in headers is now in .cpp files. That includes all non-hot-path
          code in CopyVisitor. Also, the code for copying in HeapInlines.h is now in
          ParallelVectorVisotor, and it's only included by Heap.cpp.

        Overall, I like this direction for the GC. I don't think it's useful for Heap.cpp to have
        calls to algorithms in some other file, unless those algorithms are either reusable or just
        very dense. That's not actually true for the copy phase, and it's probably not true for
        some other stuff like marking. I'll probably do the same refactoring for marking in another
        bug.

        This should have no effect on performance.

        * heap/CopyVisitor.cpp:
        (JSC::CopyVisitor::CopyVisitor):
        (JSC::CopyVisitor::~CopyVisitor):
        (JSC::CopyVisitor::copyFromShared): Deleted.
        * heap/CopyVisitor.h:
        * heap/CopyVisitorInlines.h:
        (JSC::CopyVisitor::checkIfShouldCopy):
        (JSC::CopyVisitor::allocateNewSpaceSlow):
        (JSC::CopyVisitor::didCopy):
        (JSC::CopyVisitor::visitItem): Deleted.
        (JSC::CopyVisitor::startCopying): Deleted.
        (JSC::CopyVisitor::doneCopying): Deleted.
        * heap/Heap.cpp:
        (JSC::Heap::copyBackingStores):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::unregisterWeakGCMap):
        (JSC::Heap::getNextBlocksToCopy): Deleted.

2015-09-29  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        Add support for WebIDL JSBuiltin attributes
        https://bugs.webkit.org/show_bug.cgi?id=149554

        Reviewed by Darin Adler.

        * runtime/Lookup.cpp:
        (JSC::reifyStaticAccessor): Adding support for creating attribute getter from JS builtin functions.
        * runtime/Lookup.h:
        (JSC::HashTableValue::builtinAccessorGetterGenerator):
        (JSC::HashTableValue::builtinAccessorSetterGenerator):
        (JSC::reifyStaticProperties): Ensuring that builtin attributes are not treated as Builtin functions.

2015-09-28  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unused parseMemoryAmount
        https://bugs.webkit.org/show_bug.cgi?id=149611

        Reviewed by Mark Lam.

        * heap/HeapStatistics.cpp:
        (JSC::HeapStatistics::parseMemoryAmount): Deleted.
        * heap/HeapStatistics.h:

2015-09-28  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: JSGlobalRuntimeAgent unintentionally overrides InspectorRuntimeAgent destruction handling
        https://bugs.webkit.org/show_bug.cgi?id=149537

        Reviewed by Darin Adler.

        * inspector/agents/JSGlobalObjectRuntimeAgent.h:
        * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
        (Inspector::JSGlobalObjectRuntimeAgent::willDestroyFrontendAndBackend): Deleted.
        Do not override method, super class implementation is sufficient.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        Fix file ordering.

        * inspector/agents/InspectorDebuggerAgent.h:
        Remove unused member variable.

2015-09-28  basile_clement@apple.com  <basile_clement@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>

        [ES6] Implement tail calls in the FTL
        https://bugs.webkit.org/show_bug.cgi?id=148664

        Reviewed by Filip Pizlo.

        This patch implements the tail call opcodes in the FTL, making tail
        calls available through all tiers. The changes are relatively
        straightforward, although the frame shuffler had to be extended to
        handle the possibility of running out of stack when spilling or
        building a slow path frame. The other tiers always ensure that we have
        enough stack space to build the new frame at the bottom of the old one,
        but that is not true for the FTL.

        Moreover, for efficiency, this adds to the shuffler the ability to
        record the state of the TagTypeNumber, and to re-use the same register
        when doing several consecutive integer boxings with no spilling in
        between.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::inRegister):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleInlining):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGClobberize.h:
        (JSC::DFG::clobberize):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::isFunctionTerminal):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * ftl/FTLInlineCacheSize.cpp:
        (JSC::FTL::sizeOfTailCallVarargs):
        (JSC::FTL::sizeOfTailCallForwardVarargs):
        (JSC::FTL::sizeOfICFor):
        * ftl/FTLInlineCacheSize.h:
        * ftl/FTLJSCall.cpp:
        (JSC::FTL::JSCall::JSCall):
        * ftl/FTLJSCallBase.cpp:
        (JSC::FTL::JSCallBase::emit):
        (JSC::FTL::JSCallBase::link):
        * ftl/FTLJSCallBase.h:
        * ftl/FTLJSCallVarargs.cpp:
        (JSC::FTL::JSCallVarargs::JSCallVarargs):
        (JSC::FTL::JSCallVarargs::emit):
        * ftl/FTLJSTailCall.cpp: Added.
        (JSC::FTL::getRegisterWithAddend):
        (JSC::FTL::recoveryFor):
        (JSC::FTL::sizeFor):
        (JSC::FTL::JSTailCall::JSTailCall):
        (JSC::FTL::m_instructionOffset):
        (JSC::FTL::JSTailCall::emit):
        * ftl/FTLJSTailCall.h: Copied from Source/JavaScriptCore/ftl/FTLJSCallBase.h.
        (JSC::FTL::JSTailCall::stackmapID):
        (JSC::FTL::JSTailCall::estimatedSize):
        (JSC::FTL::JSTailCall::numArguments):
        (JSC::FTL::JSTailCall::operator<):
        * ftl/FTLLocation.h:
        (JSC::FTL::Location::operator bool):
        (JSC::FTL::Location::operator!):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::lower):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
        (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
        (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForTailCall):
        * ftl/FTLState.h:
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitExceptionCheck):
        * jit/CallFrameShuffleData.h:
        * jit/CallFrameShuffler.cpp:
        (JSC::CallFrameShuffler::CallFrameShuffler):
        (JSC::CallFrameShuffler::dump):
        (JSC::CallFrameShuffler::spill):
        (JSC::CallFrameShuffler::extendFrameIfNeeded):
        (JSC::CallFrameShuffler::prepareForSlowPath):
        (JSC::CallFrameShuffler::prepareAny):
        * jit/CallFrameShuffler.h:
        (JSC::CallFrameShuffler::restoreGPR):
        (JSC::CallFrameShuffler::getFreeRegister):
        (JSC::CallFrameShuffler::getFreeTempGPR):
        (JSC::CallFrameShuffler::ensureTempGPR):
        (JSC::CallFrameShuffler::addNew):
        * jit/CallFrameShuffler64.cpp:
        (JSC::CallFrameShuffler::emitBox):
        (JSC::CallFrameShuffler::tryAcquireTagTypeNumber):
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        * jit/Reg.h:
        (JSC::Reg::Reg):
        (JSC::Reg::isHashTableDeletedValue):
        (JSC::Reg::deleted):
        (JSC::RegHash::hash):
        (JSC::RegHash::equal):
        * test/es6.yaml:

2015-09-28  Keith Miller  <keith_miller@apple.com>

        ObjectPropertyConditionSet::mergedWith does not produce a minimal intersection.
        https://bugs.webkit.org/show_bug.cgi?id=149598

        Reviewed by Michael Saboff.

        mergedWith sometimes creates duplicates of an ObjectPropertyCondition, which causes GetByIdVariant
        in believe that the condition has more than one slotBaseCondition when only one was necessary.

        * bytecode/ObjectPropertyConditionSet.cpp:
        (JSC::ObjectPropertyConditionSet::mergedWith):

2015-09-26  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix debug tests. Before marking, we need to call registerGCThreads().

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):

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

        VMs should share GC threads
        https://bugs.webkit.org/show_bug.cgi?id=149433
        rdar://problem/12859344

        Reviewed by Geoffrey Garen.

        This changes the GC to use a new WTF abstraction for parallelism called ParallelHelperPool.
        This allows us to remove GCThread and all of the GCPhase machinery. This kills a lot of
        code and also gives our GC magical thread sharing powers. If two GCs in two different VMs
        fire at the same time, then they will both get a random subset of the available shared GC
        threads. If one GC happens before the other, then it will probably get all of the available
        threads. If a GC happens while another VM already started GCing, then it will probably not
        get any helper threads. This is probably fine, since in multi-VM scenarios we have no
        reason to optimize for anything other than total throughput.

        The GC has one static helper pool. This pool is available via JSC::heapHelperPool(). It
        would be OK for other parts of JSC to use it in the future for parallel tasks. Each Heap
        instance has a helper client attached to the pool.

        The marking phase tells the ParallelHelperClient to asynchronously run a function that
        joins parallel marking and finishes once marking reaches termination. It uses the
        client.setFunction() idiom where the threads share work with each other using a specialized
        worklist. The ParallelHelperPool is not involved in deciding when threads should terminate.

        The copying phase tells the ParallelHelperClient to run a copying function in parallel. It
        uses the client.runFunctionInParallel() idiom. The copying function gets work from the
        m_blocksToCopy worklist inside Heap.

        To test that multiple VMs work properly, this adds a multi-VM test to testapi.mm. This test
        creates five concurrent VMs and has each of them allocate about 30MB of memory before doing
        a full GC. I've confirmed that this tests uses only 6 total GC threads on my 8-core
        computer (this is correct since we are currently configured for 7-way parallelism).

        This shouldn't affect performance on benchmarks, but it will sure help apps with a lot of
        VM instances.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbstractMacroAssembler.h:
        * heap/GCThread.cpp: Removed.
        * heap/GCThread.h: Removed.
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::~Heap):
        (JSC::Heap::isPagedOut):
        (JSC::Heap::markRoots):
        (JSC::Heap::copyBackingStores):
        (JSC::Heap::resetVisitors):
        (JSC::Heap::threadVisitCount):
        (JSC::Heap::threadBytesVisited):
        (JSC::Heap::threadBytesCopied):
        (JSC::Heap::startNextPhase): Deleted.
        (JSC::Heap::endCurrentPhase): Deleted.
        * heap/Heap.h:
        * heap/HeapHelperPool.cpp: Added.
        (JSC::heapHelperPool):
        * heap/HeapHelperPool.h: Added.
        * heap/MarkStack.cpp:
        (JSC::MarkStackArray::stealSomeCellsFrom):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::reset):
        (JSC::SlotVisitor::drainFromShared):
        * jit/BinarySwitch.h:
        * runtime/CodeCache.h:
        * runtime/VM.h:
        * runtime/WeakRandom.h: Removed.
        * API/tests/testapi.mm:

2015-09-25  Saam barati  <sbarati@apple.com>

        DFG should use PhantomLocal instead of Flush as liveness preservation mechanism in LiveCatchVariablesPreservationPhase
        https://bugs.webkit.org/show_bug.cgi?id=149575

        Reviewed by Geoffrey Garen.

        LiveCatchVariablesPreservationPhase is no longer forcing all live-at-catch 
        variables to be flushed to the stack. They are now kept alive to OSR exit 
        through PhantomLocal. This gives us a speed improvement for try-catch 
        programs (especially those that don't throw errors very often) because
        we can keep locals in registers instead of forcing them onto the stack.

        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::LiveCatchVariablePreservationPhase::LiveCatchVariablePreservationPhase):
        (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
        (JSC::DFG::performLiveCatchVariablePreservationPhase):
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase): Deleted.
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock): Deleted.

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

        FTLOSRExitCompiler incorrectly excludes FPR registers in callee saves loop
        https://bugs.webkit.org/show_bug.cgi?id=149540

        Reviewed by Saam Barati.

        Eliminated the incorrect check that callee saves registers are only GPRs.

        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):

2015-09-25  Alex Christensen  <achristensen@webkit.org>

        [Win] Switch to CMake
        https://bugs.webkit.org/show_bug.cgi?id=148111

        Reviewed by Brent Fulgham.

        * JavaScriptCore.vcxproj/JavaScriptCore.proj:

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

        Remove the use of "Immediate" in JIT function names.
        https://bugs.webkit.org/show_bug.cgi?id=149542

        Reviewed by Geoffrey Garen.

        We will rename the following:
            isOperandConstantImmediateDouble => isOperandConstantDouble
            isOperandConstantImmediateInt => isOperandConstantInt
            isOperandConstantImmediateChar => isOperandConstantChar

            getOperandConstantImmediateInt => getOperandConstantInt
            getConstantOperandImmediateInt => getOperandConstantInt

            emitJumpIfImmediateInteger => emitJumpIfInt
            emitJumpIfNotImmediateInteger => emitJumpIfNotInt
            emitJumpIfNotImmediateIntegers => emitJumpIfNotInt
            emitPatchableJumpIfNotImmediateInteger => emitPatchableJumpIfNotInt
            emitJumpSlowCaseIfNotImmediateInteger => emitJumpSlowCaseIfNotInt
            emitJumpSlowCaseIfNotImmediateNumber => emitJumpSlowCaseIfNotNumber
            emitJumpSlowCaseIfNotImmediateIntegers => emitJumpSlowCaseIfNotInt
            emitFastArithReTagImmediate => emitTagInt
            emitTagAsBoolImmediate => emitTagBool
            emitJumpIfImmediateNumber => emitJumpIfNumber
            emitJumpIfNotImmediateNumber => emitJumpIfNotNumber
            emitFastArithImmToInt - Deleted because this is an empty function.
            emitFastArithIntToImmNoCheck => emitTagInt
            emitPutImmediateToCallFrameHeader => emitPutToCallFrameHeader

        This is purely a refactoring patch to do the renaming.  There is no behavior
        change.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileEntry):
        (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitPutToCallFrameHeader):
        (JSC::AssemblyHelpers::emitPutImmediateToCallFrameHeader): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        (JSC::JIT::emitStoreCell):
        (JSC::JIT::getSlowCase):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_negate):
        (JSC::JIT::emit_op_lshift):
        (JSC::JIT::emit_op_rshift):
        (JSC::JIT::emitSlow_op_rshift):
        (JSC::JIT::emit_op_urshift):
        (JSC::JIT::emitSlow_op_urshift):
        (JSC::JIT::emit_op_unsigned):
        (JSC::JIT::emit_compareAndJump):
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emit_op_bitand):
        (JSC::JIT::emit_op_inc):
        (JSC::JIT::emit_op_dec):
        (JSC::JIT::emit_op_mod):
        (JSC::JIT::compileBinaryArithOp):
        (JSC::JIT::compileBinaryArithOpSlowCase):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emit_op_mul):
        (JSC::JIT::emitSlow_op_mul):
        (JSC::JIT::emit_op_div):
        (JSC::JIT::emitSlow_op_div):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_compareAndJump):
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emit_op_lshift):
        (JSC::JIT::emitSlow_op_lshift):
        (JSC::JIT::emitRightShift):
        (JSC::JIT::emitRightShiftSlowCase):
        (JSC::JIT::emit_op_bitand):
        (JSC::JIT::emitSlow_op_bitand):
        (JSC::JIT::emit_op_bitor):
        (JSC::JIT::emitSlow_op_bitor):
        (JSC::JIT::emit_op_bitxor):
        (JSC::JIT::emitSlow_op_bitxor):
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        (JSC::JIT::emit_op_sub):
        (JSC::JIT::emitSlow_op_sub):
        * jit/JITInlines.h:
        (JSC::JIT::emitArrayStorageGetByVal):
        (JSC::JIT::isOperandConstantDouble):
        (JSC::JIT::isOperandConstantChar):
        (JSC::JIT::emitJumpSlowCaseIfNotJSCell):
        (JSC::JIT::isOperandConstantInt):
        (JSC::JIT::getOperandConstantInt):
        (JSC::JIT::emitGetVirtualRegisters):
        (JSC::JIT::emitLoadInt32ToDouble):
        (JSC::JIT::emitJumpIfInt):
        (JSC::JIT::emitJumpIfNotInt):
        (JSC::JIT::emitPatchableJumpIfNotInt):
        (JSC::JIT::emitJumpSlowCaseIfNotInt):
        (JSC::JIT::emitJumpSlowCaseIfNotNumber):
        (JSC::JIT::emitTagBool):
        (JSC::JIT::isOperandConstantImmediateDouble): Deleted.
        (JSC::JIT::isOperandConstantImmediateChar): Deleted.
        (JSC::JIT::isOperandConstantImmediateInt): Deleted.
        (JSC::JIT::getOperandConstantImmediateInt): Deleted.
        (JSC::JIT::getConstantOperandImmediateInt): Deleted.
        (JSC::JIT::emitJumpIfImmediateInteger): Deleted.
        (JSC::JIT::emitJumpIfNotImmediateInteger): Deleted.
        (JSC::JIT::emitPatchableJumpIfNotImmediateInteger): Deleted.
        (JSC::JIT::emitJumpIfNotImmediateIntegers): Deleted.
        (JSC::JIT::emitJumpSlowCaseIfNotImmediateInteger): Deleted.
        (JSC::JIT::emitJumpSlowCaseIfNotImmediateIntegers): Deleted.
        (JSC::JIT::emitJumpSlowCaseIfNotImmediateNumber): Deleted.
        (JSC::JIT::emitFastArithReTagImmediate): Deleted.
        (JSC::JIT::emitTagAsBoolImmediate): Deleted.
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_is_boolean):
        (JSC::JIT::emit_op_is_number):
        (JSC::JIT::emit_op_is_string):
        (JSC::JIT::emit_op_is_object):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_eq):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_neq):
        (JSC::JIT::emit_op_bitxor):
        (JSC::JIT::emit_op_bitor):
        (JSC::JIT::compileOpStrictEq):
        (JSC::JIT::emit_op_to_number):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        (JSC::JIT::emitSlow_op_eq):
        (JSC::JIT::emitSlow_op_neq):
        (JSC::JIT::emit_op_profile_type):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::emitGenericContiguousPutByVal):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::emitIntTypedArrayPutByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::emitJumpIfNotJSCell):
        (JSC::JSInterfaceJIT::emitJumpIfNumber):
        (JSC::JSInterfaceJIT::emitJumpIfNotNumber):
        (JSC::JSInterfaceJIT::emitLoadDouble):
        (JSC::JSInterfaceJIT::emitTagInt):
        (JSC::JSInterfaceJIT::emitPutToCallFrameHeader):
        (JSC::JSInterfaceJIT::emitJumpIfImmediateNumber): Deleted.
        (JSC::JSInterfaceJIT::emitJumpIfNotImmediateNumber): Deleted.
        (JSC::JSInterfaceJIT::emitFastArithImmToInt): Deleted.
        (JSC::JSInterfaceJIT::emitFastArithIntToImmNoCheck): Deleted.
        (JSC::JSInterfaceJIT::emitPutImmediateToCallFrameHeader): Deleted.
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):
        (JSC::WASMFunctionCompiler::endFunction):

2015-09-24  Michael Saboff  <msaboff@apple.com>

        [ES6] Implement tail calls in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=148663

        Reviewed by Filip Pizlo.

        jsc-tailcall: Implement the tail call opcodes in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=146850

        This patch adds support for tail calls in the DFG. This requires a slightly high number of nodes:

         - TailCall and TailCallVarargs are straightforward. They are terminal
           nodes and have the semantics of an actual tail call.

         - TailCallInlinedCaller and TailCallVarargsInlinedCaller are here to perform a
           tail call inside an inlined function. They are non terminal nodes,
           and are performing the call as a regular call after popping an
           appropriate number of inlined tail call frames.

         - TailCallForwardVarargs and TailCallForwardVarargsInlinedCaller are the
           extension of TailCallVarargs and TailCallVarargsInlinedCaller to enable
           the varargs forwarding optimization so that we don't lose
           performance with a tail call instead of a regular call.

        This also required two broad kind of changes:

         - Changes in the JIT itself (DFGSpeculativeJIT) are pretty
           straightforward since they are just an extension of the baseline JIT
           changes introduced previously.

         - Changes in the runtime are mostly related with handling inline call
           frames. The idea here is that we have a special TailCall type for
           call frames that indicates to the various pieces of code walking the
           inline call frame that they should (recursively) skip the caller in
           their analysis.

        * bytecode/CallMode.h:
        (JSC::specializationKindFor):
        * bytecode/CodeOrigin.cpp:
        (JSC::CodeOrigin::inlineDepthForCallFrame):
        (JSC::CodeOrigin::isApproximatelyEqualTo):
        (JSC::CodeOrigin::approximateHash):
        (JSC::CodeOrigin::inlineStack):
        * bytecode/CodeOrigin.h:
        * bytecode/InlineCallFrame.cpp:
        (JSC::InlineCallFrame::dumpInContext):
        (WTF::printInternal):
        * bytecode/InlineCallFrame.h:
        (JSC::InlineCallFrame::callModeFor):
        (JSC::InlineCallFrame::kindFor):
        (JSC::InlineCallFrame::varargsKindFor):
        (JSC::InlineCallFrame::specializationKindFor):
        (JSC::InlineCallFrame::isVarargs):
        (JSC::InlineCallFrame::isTail):
        (JSC::InlineCallFrame::computeCallerSkippingDeadFrames):
        (JSC::InlineCallFrame::getCallerSkippingDeadFrames):
        (JSC::InlineCallFrame::getCallerInlineFrameSkippingDeadFrames):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGArgumentsEliminationPhase.cpp:
        * dfg/DFGBasicBlock.h:
        (JSC::DFG::BasicBlock::findTerminal):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::inlineCallFrame):
        (JSC::DFG::ByteCodeParser::allInlineFramesAreTailCalls):
        (JSC::DFG::ByteCodeParser::currentCodeOrigin):
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        (JSC::DFG::ByteCodeParser::addCall):
        (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
        (JSC::DFG::ByteCodeParser::getPrediction):
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleVarargsCall):
        (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
        (JSC::DFG::ByteCodeParser::inliningCost):
        (JSC::DFG::ByteCodeParser::inlineCall):
        (JSC::DFG::ByteCodeParser::attemptToInlineCall):
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * 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/DFGGraph.cpp:
        (JSC::DFG::Graph::isLiveInBytecode):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
        * dfg/DFGInPlaceAbstractState.cpp:
        (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasCallVarargsData):
        (JSC::DFG::Node::isTerminal):
        (JSC::DFG::Node::hasHeapPrediction):
        * dfg/DFGNodeType.h:
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::handleExitCounts):
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::osrWriteBarrier):
        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGPreciseLocalClobberize.h:
        (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validateSSA):
        * dfg/DFGVarargsForwardingPhase.cpp:
        * interpreter/CallFrame.cpp:
        (JSC::CallFrame::bytecodeOffset):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::gotoNextFrame):

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

        Remove special case code for the no-parallel-GC case
        https://bugs.webkit.org/show_bug.cgi?id=149512

        Reviewed by Mark Lam.

        Make serial GC just a parallel GC where the helper threads don't do anything. Also make the
        idle thread calculation a bit more explicit.

        The main outcome is that we no longer use Options::numberOfGCMarkers() as much, so the code is
        resilient against the number of GC markers changing.

        * heap/Heap.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::donateKnownParallel):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::drainFromShared):

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

        PolymorphicAccess should remember that it checked an ObjectPropertyCondition with a check on some structure
        https://bugs.webkit.org/show_bug.cgi?id=149514

        Reviewed by Oliver Hunt.

        When we checked an ObjectPropertyCondition using an explicit structure check, we would forget to
        note the structure in any weak reference table and we would attempt to regenerate the condition
        check even if the condition became invalid.

        We need to account for this better and we need to prune AccessCases that have an invalid condition
        set. This change does both.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessGenerationState::addWatchpoint):
        (JSC::AccessCase::alternateBase):
        (JSC::AccessCase::couldStillSucceed):
        (JSC::AccessCase::canReplace):
        (JSC::AccessCase::generate):
        (JSC::PolymorphicAccess::regenerateWithCases):
        (JSC::PolymorphicAccess::visitWeak):
        (JSC::PolymorphicAccess::regenerate):
        * bytecode/PolymorphicAccess.h:
        (JSC::AccessCase::callLinkInfo):
        * tests/stress/make-dictionary-repatch.js: Added. This used to crash on a release assert. If we removed the release assert, this would return bad results.

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

        We should only expect a RareCaseProfile to exist if the rare case actually exists.
        https://bugs.webkit.org/show_bug.cgi?id=149531

        Reviewed by Saam Barati.

        The current code that calls rareCaseProfileForBytecodeOffset() assumes that it
        will always return a non-null RareCaseProfile.  As a result, op_add in the
        baseline JIT is forced to add a dummy slow case that will never be taken, only to
        ensure that the RareCaseProfile for that bytecode is created.  This profile will
        always produce a counter value of 0 (since that path will never be taken).

        Instead, we'll make the callers of rareCaseProfileForBytecodeOffset() check if
        the profile actually exist before dereferencing it.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
        (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
        (JSC::CodeBlock::capabilityLevel):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::addRareCaseProfile):
        (JSC::CodeBlock::numberOfRareCaseProfiles):
        (JSC::CodeBlock::likelyToTakeSlowCase):
        (JSC::CodeBlock::couldTakeSlowCase):
        (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
        (JSC::CodeBlock::likelyToTakeAnySlowCase):
        (JSC::CodeBlock::rareCaseProfile): Deleted.
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):
        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_op_add):
        (JSC::JIT::emitSlow_op_add):

2015-09-24  Ryosuke Niwa  <rniwa@webkit.org>

        Ran sort-Xcode-project-file.

        * JavaScriptCore.xcodeproj/project.pbxproj:

2015-09-24  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        [Streams API] Add support for JS builtins constructor
        https://bugs.webkit.org/show_bug.cgi?id=149497

        Reviewed by Darin Adler.

        * runtime/JSFunction.h: exporting createBuiltinFunction.

2015-09-23  Saam barati  <sbarati@apple.com>

        JSC allows invalid var declarations when the declared name is the same as a let/const variable
        https://bugs.webkit.org/show_bug.cgi?id=147600

        Reviewed by Yusuke Suzuki.

        We had an ordering bug where if you first declared a "let"
        variable then a "var" variable with the same name, you wouldn't
        get a syntax error. But, if you did it in the reverse order,
        you would. This patch fixes this syntax error to be order independent.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseVariableDeclarationList):
        (JSC::Parser<LexerType>::createBindingPattern):
        (JSC::Parser<LexerType>::parseFunctionDeclaration):
        * parser/Parser.h:
        (JSC::Scope::declareVariable):

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

        Parallel copy phase synchronization should be simplified
        https://bugs.webkit.org/show_bug.cgi?id=149509

        Reviewed by Mark Lam.

        Before this change, we didn't wait for the copy phase to finish before starting to do things to
        copied space that presumed that copying was done. Copied space would "detect" that nobody was
        copying anymore by waiting for all loaned blocks to be returned. But that would succeed if some
        thread had not yet started copying. So, we had weird hacks to ensure that a block was loaned
        before any threads started. It also meant that we had two separate mechanisms for waiting for
        copying threads to finish - one mechanism in the Heap phase logic and another in the
        CopiedSpace::doneCopying() method.

        We can get rid of a lot of the weirdness by just having a sound shutdown sequence:

        1) Threads concur on when there is no more work. We already have this; once
           Heap::getNextBlocksToCopy() returns no work in any thread, it will also return no work in
           any other thread that asks for work.
        2) Main thread waits for the threads to not be copying anymore.
        3) Do whatever we need to do after copying finishes.

        Currently, we do (3) before (2) and so we have weird problems. This just changes the code to do
        (3) after (2), and so we can get rid of the synchronization in doneCopying() and we can safely
        call startCopying() inside GCThread. This also means that we don't need to make CopyVisitor a
        property of GCThread. Instead, GCThread just instantiates its own CopyVisitor when it needs to.

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::doneCopying):
        * heap/GCThread.cpp:
        (JSC::GCThread::GCThread):
        (JSC::GCThread::slotVisitor):
        (JSC::GCThread::waitForNextPhase):
        (JSC::GCThread::gcThreadMain):
        (JSC::GCThread::copyVisitor): Deleted.
        * heap/GCThread.h:
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::copyBackingStores):
        (JSC::Heap::gatherStackRoots):

2015-09-23  Joseph Pecoraro  <pecoraro@apple.com>

        Remove unimplemented method Heap::showStatistics
        https://bugs.webkit.org/show_bug.cgi?id=149507

        Reviewed by Darin Adler.

        * heap/Heap.h:

2015-09-23  Tim Horton  <timothy_horton@apple.com>

        Hopefully fix the production build.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * PlatformWin.cmake:

2015-09-23  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        [Streams API] Implement ReadableStream pipeThrough
        https://bugs.webkit.org/show_bug.cgi?id=147556

        Reviewed by Darin Adler.

        Updating BuiltIns infrastructure to make it reusable from WebCore.
        Extracting macros from BuiltinNames and createBuiltinExecutable from BuiltinExecutables.
        Updated generate-js-builtins to allow generating builtin CPP/H files in WebCore namespace.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::createDefaultConstructor):
        (JSC::BuiltinExecutables::createBuiltinExecutable):
        (JSC::createBuiltinExecutable):
        (JSC::createExecutableInternal):
        * builtins/BuiltinExecutables.h:
        * builtins/BuiltinNames.h:
        (JSC::BuiltinNames::BuiltinNames): Deleted.
        * builtins/BuiltinUtils.h: Extracting code from BuiltinNames and BuiltinExecutables.h.
        * bytecode/UnlinkedFunctionExecutable.h:
        * generate-js-builtins:
        (getFunctions):
        (writeIncludeDirectives):

2015-09-22  Mark Lam  <mark.lam@apple.com>

        Gardening: speculative non-JIT build fix after r189999.

        Not reviewed.

        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::jsValueRegs):

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

        GCThreadSharedData is just a bad way of saying Heap
        https://bugs.webkit.org/show_bug.cgi?id=149435

        Reviewed by Mark Lam.

        This removes the GCThreadSharedData class and moves its members into Heap. This is a net
        simplification since GCThreadSharedData had a 1-to-1 mapping to Heap and the two classes had a
        vast contract with a lot of interdependencies. Heap would call a lot of GCThreadSharedData
        methods; now a lot of those are inlined since they were only called from the one place in Heap.
        This makes it a lot easier to see what is going on. For example, you no longer have to look at
        code in two places (Heap and GCThreadSharedData) to figure out the timing and synchronization
        of GC phases - all of that code is in Heap now.

        This also removes weird indirections in other places. It used to be that a lot of GC helper
        classes woud have a pointer to GCThreadSharedData, and then would use that to get to Heap, VM,
        and the visitors. Now these helpers just point to Heap.

        I think that GCThreadSharedData was only useful for defining the set of things that we need to
        know to collect garbage. That's how we decided if something would go into GCThreadSharedData
        instead of Heap. But I think that separating things into multiple classes usually makes the
        code less hackable, so there should be a very high bar for doing this in a way that produces a
        1-to-1 mapping between two classes - where one instance of one of the classes is always paired
        with exactly one instance of the other class and vice-versa.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/CopiedSpace.h:
        * heap/CopyVisitor.cpp:
        (JSC::CopyVisitor::CopyVisitor):
        (JSC::CopyVisitor::copyFromShared):
        * heap/CopyVisitor.h:
        * heap/CopyVisitorInlines.h:
        (JSC::CopyVisitor::allocateNewSpaceSlow):
        (JSC::CopyVisitor::startCopying):
        (JSC::CopyVisitor::doneCopying):
        (JSC::CopyVisitor::didCopy):
        * heap/GCThread.cpp:
        (JSC::GCThread::GCThread):
        (JSC::GCThread::waitForNextPhase):
        (JSC::GCThread::gcThreadMain):
        * heap/GCThread.h:
        * heap/GCThreadSharedData.cpp: Removed.
        * heap/GCThreadSharedData.h: Removed.
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::~Heap):
        (JSC::Heap::isPagedOut):
        (JSC::Heap::markRoots):
        (JSC::Heap::copyBackingStores):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::resetVisitors):
        (JSC::Heap::objectCount):
        (JSC::Heap::sweepNextLogicallyEmptyWeakBlock):
        (JSC::Heap::threadVisitCount):
        (JSC::Heap::threadBytesVisited):
        (JSC::Heap::threadBytesCopied):
        (JSC::Heap::startNextPhase):
        (JSC::Heap::endCurrentPhase):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::unregisterWeakGCMap):
        (JSC::Heap::getNextBlocksToCopy):
        * heap/ListableHandler.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::SlotVisitor):
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::reset):
        (JSC::SlotVisitor::donateKnownParallel):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::drainFromShared):
        (JSC::SlotVisitor::mergeOpaqueRoots):
        (JSC::SlotVisitor::harvestWeakReferences):
        (JSC::SlotVisitor::finalizeUnconditionalFinalizers):
        * heap/SlotVisitor.h:
        (JSC::SlotVisitor::markStack):
        (JSC::SlotVisitor::isEmpty):
        (JSC::SlotVisitor::sharedData): Deleted.
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::addWeakReferenceHarvester):
        (JSC::SlotVisitor::addUnconditionalFinalizer):
        (JSC::SlotVisitor::addOpaqueRoot):
        (JSC::SlotVisitor::containsOpaqueRoot):
        (JSC::SlotVisitor::containsOpaqueRootTriState):
        (JSC::SlotVisitor::opaqueRootCount):
        (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
        (JSC::SlotVisitor::copyLater):
        (JSC::SlotVisitor::heap):
        (JSC::SlotVisitor::vm):

2015-09-22  Saam barati  <sbarati@apple.com>

        Web Inspector: [ES6] Improve Type Profiler Support for Arrow Functions
        https://bugs.webkit.org/show_bug.cgi?id=143171

        Reviewed by Joseph Pecoraro.

        We now need to take into account TypeProfilerSearchDescriptor when
        hashing results for type profiler queries. Before, we've gotten
        away with not doing this because before we would never have a text 
        collision between a return type text offset and a normal expression text
        offset. But, with arrow functions, we will have collisions when
        the arrow function doesn't have parens around its single parameter.
        I.e: "param => { ... };"

        * runtime/TypeProfiler.cpp:
        (JSC::TypeProfiler::findLocation):
        * runtime/TypeProfiler.h:
        (JSC::QueryKey::QueryKey):
        (JSC::QueryKey::isHashTableDeletedValue):
        (JSC::QueryKey::operator==):
        (JSC::QueryKey::hash):
        * tests/typeProfiler/arrow-functions.js: Added.

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

        Get rid of ENABLE(PARALLEL_GC)
        https://bugs.webkit.org/show_bug.cgi?id=149436

        Reviewed by Mark Lam.

        We always enable parallel GC everywhere but Windows, and it doesn't look like it was disabled
        there for any good reason. So, get rid of the flag.

        The only effect of this change is that parallel GC will now be enabled on Windows, provided
        that the CPU detection finds more than one.

        * heap/GCThread.cpp:
        (JSC::GCThread::gcThreadMain):
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::resetChildren):
        (JSC::GCThreadSharedData::childBytesCopied):
        (JSC::GCThreadSharedData::GCThreadSharedData):
        (JSC::GCThreadSharedData::~GCThreadSharedData):
        (JSC::GCThreadSharedData::reset):
        (JSC::GCThreadSharedData::didStartMarking):
        * heap/Heap.cpp:
        (JSC::Heap::converge):
        (JSC::Heap::visitWeakHandles):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::resetVisitors):
        * heap/MarkedBlock.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::didStartMarking):
        (JSC::SlotVisitor::reset):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::drainFromShared):
        (JSC::SlotVisitor::mergeOpaqueRoots):
        (JSC::JSString::tryHashConsLock):
        (JSC::JSString::releaseHashConsLock):
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::addOpaqueRoot):
        (JSC::SlotVisitor::containsOpaqueRoot):
        (JSC::SlotVisitor::containsOpaqueRootTriState):
        (JSC::SlotVisitor::opaqueRootCount):
        (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
        * runtime/Options.cpp:
        (JSC::computeNumberOfGCMarkers):

2015-09-22  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement min and max instructions in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149454

        Reviewed by Geoffrey Garen.

        This patch implements min and max instructions in WebAssembly.

        * tests/stress/wasm-arithmetic-float64.js:
        * tests/stress/wasm-arithmetic-int32.js:
        * tests/stress/wasm/arithmetic-float64.wasm:
        * tests/stress/wasm/arithmetic-int32.wasm:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildMinOrMaxI32):
        (JSC::WASMFunctionCompiler::buildMinOrMaxF64):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseMinOrMaxExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseMinOrMaxExpressionF64):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxI32):
        (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxF64):

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

        Get rid of ENABLE(GGC)
        https://bugs.webkit.org/show_bug.cgi?id=149472

        Reviewed by Mark Hahnenberg and Mark Lam.

        Getting rid of this feature flag allows us to remove a lot of yuck.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlockSet::mark):
        (JSC::ScriptExecutable::forEachCodeBlock):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::osrWriteBarrier):
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::linkBranches):
        (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
        (JSC::DFG::SpeculativeJIT::writeBarrier):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid):
        (JSC::DFG::SpeculativeJIT::selectScratchGPR):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::writeBarrier):
        (JSC::DFG::SpeculativeJIT::moveTrueTo):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compile):
        (JSC::DFG::SpeculativeJIT::writeBarrier):
        (JSC::DFG::SpeculativeJIT::moveTrueTo):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
        (JSC::CodeBlockSet::dump):
        * heap/Heap.cpp:
        (JSC::Heap::Heap):
        (JSC::Heap::markRoots):
        (JSC::Heap::clearRememberedSet):
        (JSC::Heap::updateObjectCounts):
        (JSC::Heap::flushWriteBarrierBuffer):
        (JSC::Heap::shouldDoFullCollection):
        (JSC::Heap::addLogicallyEmptyWeakBlock):
        * heap/HeapInlines.h:
        (JSC::Heap::isWriteBarrierEnabled):
        (JSC::Heap::writeBarrier):
        (JSC::Heap::reportExtraMemoryAllocated):
        (JSC::Heap::reportExtraMemoryVisited):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::clearMarks):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::visitWeakSets):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::didAllocateInBlock):
        (JSC::MarkedSpace::objectCount):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitWriteBarrier):
        (JSC::JIT::emitIdentifierCheck):
        (JSC::JIT::privateCompilePutByVal):
        * llint/LLIntOfflineAsmConfig.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2015-09-22  Saam barati  <sbarati@apple.com>

        the toInt32 operation inside DFGSpeculativeJIT.cpp can't throw so we shouldn't emit an exceptionCheck after it.
        https://bugs.webkit.org/show_bug.cgi?id=149467

        Reviewed by Mark Lam.

        The callOperation for toInt32 won't store a call site index in the call frame.
        Therefore, if this is the first callOperation in the current compilation, 
        and we emit an exception check inside a try block, we will hit an assertion 
        saying that we must have DFGCommonData::codeOrigins.size() be > 0 inside
        DFGCommonData::lastCallSite(). Therefore, it is imperative that we don't 
        emit exception checks for callOperations that don't throw exceptions and 
        don't store a call site index in the call frame.

        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::lastCallSite):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):

2015-09-22  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement the conditional instruction in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149451

        Reviewed by Geoffrey Garen.

        This patch implements the conditional (ternary) instruction in WebAssembly.
        This is basically "condition ? exp1 : exp2" in JavaScript.
        
        The use of context.discard() in WASMFunctionParser::parseConditional()
        is not ideal. We don't discard anything. We just use it to decrement the
        stack top in the WebAssembly baseline JIT. When we optimize the JIT by
        storing results directly into the destination like the JavaScript
        baseline JIT, the code will look like this:

            ContextExpression temp = context.newTemporary();
            ContextExpression condition = parseExpressionI32(context);
            context.jumpToTargetIf(Context::JumpCondition::Zero, condition, elseTarget);

            parseExpression(context, temp, expressionType);
            context.jumpToTarget(end);

            context.linkTarget(elseTarget);
            parseExpression(context, temp, expressionType);
            context.linkTarget(end);

            return temp;

        which looks cleaner than using discard().

        * tests/stress/wasm-control-flow.js:
        * tests/stress/wasm/control-flow.wasm:
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseConditional):
        * wasm/WASMFunctionParser.h:

2015-09-22  Commit Queue  <commit-queue@webkit.org>

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

        suspected cause of multiple regressions (Requested by kling on
        #webkit).

        Reverted changeset:

        "[JSC] Weak should only accept cell pointees."
        https://bugs.webkit.org/show_bug.cgi?id=148955
        http://trac.webkit.org/changeset/189616

2015-09-22  Saam barati  <sbarati@apple.com>

        Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script with "class" with default constructor
        https://bugs.webkit.org/show_bug.cgi?id=149248

        Reviewed by Mark Lam.

        We keep track of which functions have and have not
        executed so we can show visually, inside the inspector,
        which functions have and have not executed. With a default
        constructor, our parser parses code that isn't in the actual
        JavaScript source code of the user. Our parser would then
        give us a range of starting at "1" to "1 + default constructor length"
        as being the text range of a function. But, this would then pollute
        actual source code that was at these ranges.

        Therefore, we should treat these default constructor source 
        codes as having "invalid" ranges. We use [UINT_MAX, UINT_MAX] 
        as the invalid range. This range has the effect of not polluting 
        valid ranges inside the source code.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        (JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewDefaultConstructor):

2015-09-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement the comma instruction in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149425

        Reviewed by Geoffrey Garen.

        This patch implements the comma instruction in WebAssembly. The comma
        instruction evaluates the left operand and then the right operand and
        returns the value of the right operand.

        * tests/stress/wasm-comma.js: Added.
        (shouldBe):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::discard):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseComma):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::discard):

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

        Always use the compiler's CAS implementation and get rid of ENABLE(COMPARE_AND_SWAP)
        https://bugs.webkit.org/show_bug.cgi?id=149438

        Reviewed by Mark Lam.

        * heap/HeapInlines.h:
        (JSC::Heap::reportExtraMemoryVisited):
        (JSC::Heap::deprecatedReportExtraMemory):

2015-09-21  Saam barati  <sbarati@apple.com>

        functionProtoFuncToString should not rely on typeProfilingEndOffset()
        https://bugs.webkit.org/show_bug.cgi?id=149429

        Reviewed by Geoffrey Garen.

        We should be able to freely change typeProfilingEndOffset()
        without worrying we will break Function.prototype.toString.

        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncToString):

2015-09-21  Commit Queue  <commit-queue@webkit.org>

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

        Broke LayoutTests/inspector/model/remote-object.htm (Requested
        by saamyjoon on #webkit).

        Reverted changeset:

        "Web Inspector: Basic Block Annotations and Type Profiler
        annotations wrong for script with "class" with default
        constructor"
        https://bugs.webkit.org/show_bug.cgi?id=149248
        http://trac.webkit.org/changeset/190086

2015-09-21  Saam barati  <sbarati@apple.com>

        Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script with "class" with default constructor
        https://bugs.webkit.org/show_bug.cgi?id=149248

        Reviewed by Mark Lam.

        We keep track of which functions have and have not
        executed so we can show visually, inside the inspector,
        which functions have and have not executed. With a default
        constructor, our parser parses code that isn't in the actual
        JavaScript source code of the user. Our parser would then
        give us a range of starting at "1" to "1 + default constructor length"
        as being the text range of a function. But, this would then pollute
        actual source code that was at these ranges.

        Therefore, we should treat these default constructor source 
        codes as having "invalid" ranges. We use [UINT_MAX, UINT_MAX] 
        as the invalid range. This range has the effect of not polluting 
        valid ranges inside the source code.

        * bytecode/UnlinkedFunctionExecutable.cpp:
        (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
        (JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets):
        * bytecode/UnlinkedFunctionExecutable.h:
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitNewDefaultConstructor):

2015-09-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement call statements and call expressions of type void in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149411

        Reviewed by Mark Lam.

        Call instructions in WebAssembly can be both statements and expressions.
        This patch implements call statements. It also implements call
        expressions of type void. The only place where call expressions of type
        void can occur is the left-hand side of the comma (,) operator, which
        will be implemented in a subsequent patch. The comma operator requires
        both of its operands to be expressions.

        * tests/stress/wasm-calls.js:
        * tests/stress/wasm/calls.wasm:
        * wasm/WASMConstants.h:
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseStatement):
        (JSC::WASMFunctionParser::parseExpression):
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseExpressionVoid):
        (JSC::WASMFunctionParser::parseCallInternal):
        (JSC::WASMFunctionParser::parseCallIndirect):
        (JSC::WASMFunctionParser::parseCallImport):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMReader.cpp:
        (JSC::WASMReader::readOpExpressionVoid):
        * wasm/WASMReader.h:

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

        JSC should infer property types
        https://bugs.webkit.org/show_bug.cgi?id=148610

        Reviewed by Geoffrey Garen.

        This change brings recursive type inference to JavaScript object properties in JSC. We check that a
        value being stored into a property obeys a property's type before we do the store. If it doesn't,
        we broaden the property's type to include the new value. If optimized code was relying on the old
        type, we deoptimize that code.

        The type system that this supports includes important primitive types like Int32 and Boolean. But
        it goes further and also includes a type kind called ObjectWithStructure, which means that we
        expect the property to always point to objects with a particular structure. This only works for
        leaf structures (i.e. structures that have a valid transition watchpoint set). Invalidation of the
        transition set causes the property type to become Object (meaning an object with any structure).
        This capability gives us recursive type inference. It's possible for an expression like "o.f.g.h"
        to execute without any type checks if .f and .g are both ObjectWithStructure.

        The type inference of a property is tracked by an InferredType instance, which is a JSCell. This
        means that it manages its own memory. That's convenient. For example, when the DFG is interested in
        one of these, it can just list the InferredType as a weak reference in addition to setting a
        watchpoint. This ensures that even if the InferredType is dropped by the owning structure, the DFG
        won't read a dangling pointer. A mapping from property name to InferredType is implemented by
        InferredTypeTable, which is also a JSCell. Each Structure may point to some InferredTypeTable.

        This feature causes programs to be happier (run faster without otherwise doing bad things like
        using lots of memory) when four conditions hold:

        1) A property converges to one of the types that we support.
        2) The property is loaded from more frequently than it is stored to.
        3) The stores are all cached, so that we statically emit a type check.
        4) We don't allocate a lot of meta-data for the property's type.

        We maximize the likelihood of (1) by having a rich type system. But having a rich type system means
        that a reflective put to a property has to have a large switch over the inferred type to decide how
        to do the type check. That's why we need (3). We ensure (3) by having every reflective property
        store (i.e. putDirectInternal in any context that isn't PutById) force the inferred type to become
        Top. We don't really worry about ensuring (2); this is statistically true for most programs
        already.

        Probably the most subtle trickery goes into (4). Logically we'd like to say that each
        (Structure, Property) maps to its own InferredType. If structure S1 has a transition edge to S2,
        then we could ensure that the InferredType I1 where (S1, Property)->I1 has a data flow constraint
        to I2 where (S2, Property)->I2. That would work, but it would involve a lot of memory. And when I1
        gets invalidated in some way, it would have to tell I2 about it, and then I2 might tell other
        InferredType objects downstream. That's madness. So, the first major compromise that we make here
        is to say that if some property has some InferredType at some Structure, then anytime we
        transition from that Structure, the new Structure shares the same InferredType for that property.
        This unifies the type of the property over the entire transition tree starting at the Structure at
        which the property was added. But this would still mean that each Structure would have its own
        InferredTypeTable. We don't want that because experience with PropertyTable shows that this can be
        a major memory hog. So, we don't create an InferredTypeTable until someone adds a property that is
        subject to type inference (i.e. it was added non-reflectively), and we share that InferredTypeTable
        with the entire structure transition tree rooted at the Structure that had the first inferred
        property. We also drop the InferredTypeTable anytime that we do a dictionary transition, and we
        don't allow further property type inference if a structure had ever been a dictionary.

        This is a 3% speed-up on Octane and a 12% speed-up on Kraken on my setup. It's not a significant
        slow-down on any benchmark I ran.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::branchTest64):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::branchTest64):
        (JSC::MacroAssemblerX86_64::test64):
        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate):
        * bytecode/PutByIdFlags.cpp:
        (WTF::printInternal):
        * bytecode/PutByIdFlags.h:
        (JSC::encodeStructureID):
        (JSC::decodeStructureID):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        (JSC::PutByIdStatus::computeFor):
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/PutByIdVariant.cpp:
        (JSC::PutByIdVariant::operator=):
        (JSC::PutByIdVariant::replace):
        (JSC::PutByIdVariant::transition):
        (JSC::PutByIdVariant::setter):
        (JSC::PutByIdVariant::attemptToMerge):
        (JSC::PutByIdVariant::dumpInContext):
        * bytecode/PutByIdVariant.h:
        (JSC::PutByIdVariant::newStructure):
        (JSC::PutByIdVariant::requiredType):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedInstruction::UnlinkedInstruction):
        * bytecode/Watchpoint.h:
        (JSC::InlineWatchpointSet::touch):
        (JSC::InlineWatchpointSet::isBeingWatched):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addConstantValue):
        (JSC::BytecodeGenerator::emitPutById):
        (JSC::BytecodeGenerator::emitDirectPutById):
        * dfg/DFGAbstractInterpreter.h:
        (JSC::DFG::AbstractInterpreter::filter):
        (JSC::DFG::AbstractInterpreter::filterByValue):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::filter):
        * dfg/DFGAbstractValue.cpp:
        (JSC::DFG::AbstractValue::setType):
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::fixTypeForRepresentation):
        (JSC::DFG::AbstractValue::mergeOSREntryValue):
        (JSC::DFG::AbstractValue::isType):
        (JSC::DFG::AbstractValue::filter):
        (JSC::DFG::AbstractValue::filterValueByType):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::setType):
        (JSC::DFG::AbstractValue::isType):
        (JSC::DFG::AbstractValue::validate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        (JSC::DFG::ByteCodeParser::handlePutByOffset):
        (JSC::DFG::ByteCodeParser::load):
        (JSC::DFG::ByteCodeParser::store):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::handlePutById):
        * dfg/DFGClobbersExitState.cpp:
        (JSC::DFG::clobbersExitState):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
        (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
        (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
        * dfg/DFGDesiredInferredType.h: Added.
        (JSC::DFG::DesiredInferredType::DesiredInferredType):
        (JSC::DFG::DesiredInferredType::operator bool):
        (JSC::DFG::DesiredInferredType::object):
        (JSC::DFG::DesiredInferredType::expected):
        (JSC::DFG::DesiredInferredType::isStillValid):
        (JSC::DFG::DesiredInferredType::add):
        (JSC::DFG::DesiredInferredType::operator==):
        (JSC::DFG::DesiredInferredType::operator!=):
        (JSC::DFG::DesiredInferredType::isHashTableDeletedValue):
        (JSC::DFG::DesiredInferredType::hash):
        (JSC::DFG::DesiredInferredType::dumpInContext):
        (JSC::DFG::DesiredInferredType::dump):
        (JSC::DFG::DesiredInferredTypeHash::hash):
        (JSC::DFG::DesiredInferredTypeHash::equal):
        * dfg/DFGDesiredWatchpoints.cpp:
        (JSC::DFG::AdaptiveStructureWatchpointAdaptor::add):
        (JSC::DFG::InferredTypeAdaptor::add):
        (JSC::DFG::DesiredWatchpoints::DesiredWatchpoints):
        (JSC::DFG::DesiredWatchpoints::~DesiredWatchpoints):
        (JSC::DFG::DesiredWatchpoints::addLazily):
        (JSC::DFG::DesiredWatchpoints::consider):
        (JSC::DFG::DesiredWatchpoints::reallyAdd):
        (JSC::DFG::DesiredWatchpoints::areStillValid):
        (JSC::DFG::DesiredWatchpoints::dumpInContext):
        * dfg/DFGDesiredWatchpoints.h:
        (JSC::DFG::AdaptiveStructureWatchpointAdaptor::dumpInContext):
        (JSC::DFG::InferredTypeAdaptor::hasBeenInvalidated):
        (JSC::DFG::InferredTypeAdaptor::dumpInContext):
        (JSC::DFG::DesiredWatchpoints::isWatched):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        (JSC::DFG::Graph::isSafeToLoad):
        (JSC::DFG::Graph::inferredTypeFor):
        (JSC::DFG::Graph::livenessFor):
        (JSC::DFG::Graph::tryGetConstantProperty):
        (JSC::DFG::Graph::inferredValueForProperty):
        (JSC::DFG::Graph::tryGetConstantClosureVar):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::registerInferredType):
        (JSC::DFG::Graph::inferredTypeForProperty):
        * dfg/DFGInferredTypeCheck.cpp: Added.
        (JSC::DFG::insertInferredTypeCheck):
        * dfg/DFGInferredTypeCheck.h: Added.
        * dfg/DFGNode.h:
        * dfg/DFGObjectAllocationSinkingPhase.cpp:
        * dfg/DFGPropertyTypeKey.h: Added.
        (JSC::DFG::PropertyTypeKey::PropertyTypeKey):
        (JSC::DFG::PropertyTypeKey::operator bool):
        (JSC::DFG::PropertyTypeKey::structure):
        (JSC::DFG::PropertyTypeKey::uid):
        (JSC::DFG::PropertyTypeKey::operator==):
        (JSC::DFG::PropertyTypeKey::operator!=):
        (JSC::DFG::PropertyTypeKey::hash):
        (JSC::DFG::PropertyTypeKey::isHashTableDeletedValue):
        (JSC::DFG::PropertyTypeKey::dumpInContext):
        (JSC::DFG::PropertyTypeKey::dump):
        (JSC::DFG::PropertyTypeKey::deletedUID):
        (JSC::DFG::PropertyTypeKeyHash::hash):
        (JSC::DFG::PropertyTypeKeyHash::equal):
        * dfg/DFGSafeToExecute.h:
        (JSC::DFG::SafeToExecuteEdge::operator()):
        (JSC::DFG::safeToExecute):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileTypeOf):
        (JSC::DFG::SpeculativeJIT::compileCheckStructure):
        (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
        (JSC::DFG::SpeculativeJIT::speculateCell):
        (JSC::DFG::SpeculativeJIT::speculateCellOrOther):
        (JSC::DFG::SpeculativeJIT::speculateObject):
        (JSC::DFG::SpeculativeJIT::speculate):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * dfg/DFGStructureAbstractValue.h:
        (JSC::DFG::StructureAbstractValue::at):
        (JSC::DFG::StructureAbstractValue::operator[]):
        (JSC::DFG::StructureAbstractValue::onlyStructure):
        (JSC::DFG::StructureAbstractValue::forEach):
        * dfg/DFGUseKind.cpp:
        (WTF::printInternal):
        * dfg/DFGUseKind.h:
        (JSC::DFG::typeFilterFor):
        * dfg/DFGValidate.cpp:
        (JSC::DFG::Validate::validate):
        * ftl/FTLCapabilities.cpp:
        (JSC::FTL::canCompile):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckStructure):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckCell):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiPutByOffset):
        (JSC::FTL::DFG::LowerDFGToLLVM::numberOrNotCellToInt32):
        (JSC::FTL::DFG::LowerDFGToLLVM::checkInferredType):
        (JSC::FTL::DFG::LowerDFGToLLVM::loadProperty):
        (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
        (JSC::FTL::DFG::LowerDFGToLLVM::speculateCell):
        (JSC::FTL::DFG::LowerDFGToLLVM::speculateCellOrOther):
        (JSC::FTL::DFG::LowerDFGToLLVM::speculateMachineInt):
        (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::decodedCodeMapFor):
        (JSC::AssemblyHelpers::branchIfNotType):
        (JSC::AssemblyHelpers::purifyNaN):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfEqual):
        (JSC::AssemblyHelpers::branchIfNotCell):
        (JSC::AssemblyHelpers::branchIfCell):
        (JSC::AssemblyHelpers::branchIfNotOther):
        (JSC::AssemblyHelpers::branchIfInt32):
        (JSC::AssemblyHelpers::branchIfNotInt32):
        (JSC::AssemblyHelpers::branchIfNumber):
        (JSC::AssemblyHelpers::branchIfNotNumber):
        (JSC::AssemblyHelpers::branchIfEmpty):
        (JSC::AssemblyHelpers::branchStructure):
        * jit/Repatch.cpp:
        (JSC::tryCachePutByID):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/InferredType.cpp: Added.
        (JSC::InferredType::create):
        (JSC::InferredType::destroy):
        (JSC::InferredType::createStructure):
        (JSC::InferredType::visitChildren):
        (JSC::InferredType::kindForFlags):
        (JSC::InferredType::Descriptor::forValue):
        (JSC::InferredType::Descriptor::forFlags):
        (JSC::InferredType::Descriptor::putByIdFlags):
        (JSC::InferredType::Descriptor::merge):
        (JSC::InferredType::Descriptor::removeStructure):
        (JSC::InferredType::Descriptor::subsumes):
        (JSC::InferredType::Descriptor::dumpInContext):
        (JSC::InferredType::Descriptor::dump):
        (JSC::InferredType::InferredType):
        (JSC::InferredType::~InferredType):
        (JSC::InferredType::canWatch):
        (JSC::InferredType::addWatchpoint):
        (JSC::InferredType::dump):
        (JSC::InferredType::willStoreValueSlow):
        (JSC::InferredType::makeTopSlow):
        (JSC::InferredType::set):
        (JSC::InferredType::removeStructure):
        (JSC::InferredType::InferredStructureWatchpoint::fireInternal):
        (JSC::InferredType::InferredStructureFinalizer::finalizeUnconditionally):
        (JSC::InferredType::InferredStructure::InferredStructure):
        (WTF::printInternal):
        * runtime/InferredType.h: Added.
        * runtime/InferredTypeTable.cpp: Added.
        (JSC::InferredTypeTable::create):
        (JSC::InferredTypeTable::destroy):
        (JSC::InferredTypeTable::createStructure):
        (JSC::InferredTypeTable::visitChildren):
        (JSC::InferredTypeTable::get):
        (JSC::InferredTypeTable::willStoreValue):
        (JSC::InferredTypeTable::makeTop):
        (JSC::InferredTypeTable::InferredTypeTable):
        (JSC::InferredTypeTable::~InferredTypeTable):
        * runtime/InferredTypeTable.h: Added.
        * runtime/JSObject.h:
        (JSC::JSObject::putDirectInternal):
        (JSC::JSObject::putDirectWithoutTransition):
        * runtime/Structure.cpp:
        (JSC::Structure::materializePropertyMap):
        (JSC::Structure::addPropertyTransition):
        (JSC::Structure::removePropertyTransition):
        (JSC::Structure::startWatchingInternalProperties):
        (JSC::Structure::willStoreValueSlow):
        (JSC::Structure::visitChildren):
        (JSC::Structure::prototypeChainMayInterceptStoreTo):
        * runtime/Structure.h:
        (JSC::PropertyMapEntry::PropertyMapEntry):
        * runtime/StructureInlines.h:
        (JSC::Structure::get):
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        * tests/stress/prop-type-boolean-then-string.js: Added.
        * tests/stress/prop-type-int32-then-string.js: Added.
        * tests/stress/prop-type-number-then-string.js: Added.
        * tests/stress/prop-type-object-or-other-then-string.js: Added.
        * tests/stress/prop-type-object-then-string.js: Added.
        * tests/stress/prop-type-other-then-string.js: Added.
        * tests/stress/prop-type-string-then-object.js: Added.
        * tests/stress/prop-type-struct-or-other-then-string.js: Added.
        * tests/stress/prop-type-struct-then-object.js: Added.
        * tests/stress/prop-type-struct-then-object-opt.js: Added.
        * tests/stress/prop-type-struct-then-object-opt-fold.js: Added.
        * tests/stress/prop-type-struct-then-object-opt-multi.js: Added.

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

        WebCore shouldn't have to include DFG headers
        https://bugs.webkit.org/show_bug.cgi?id=149337

        Reviewed by Michael Saboff.

        This does some simple rewiring and outlining of CodeBlock/Heap functionality so that
        those headers don't have to include DFG headers. As a result, WebCore no longer includes
        DFG headers, except for two fairly innocent ones (DFGCommon.h and DFGCompilationMode.h).
        This also changes the Xcode project file so that all but those two headers are Project
        rather than Private. So, if WebCore accidentally includes any of them, we'll get a build
        error.

        The main group of headers that this prevents WebCore from including are the DFGDesired*.h
        files and whatever those include. Those headers used to be fairly simple, but now they
        are growing in complexity (especially with things like http://webkit.org/b/148610). So,
        it makes sense to make sure they don't leak out of JSC.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CallLinkInfo.cpp:
        (JSC::CallLinkInfo::CallLinkInfo):
        (JSC::CallLinkInfo::~CallLinkInfo):
        (JSC::CallLinkInfo::clearStub):
        (JSC::CallLinkInfo::visitWeak):
        (JSC::CallLinkInfo::setFrameShuffleData):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::isVarargsCallType):
        (JSC::CallLinkInfo::specializationKindFor):
        (JSC::CallLinkInfo::frameShuffleData):
        (JSC::CallLinkInfo::CallLinkInfo): Deleted.
        (JSC::CallLinkInfo::~CallLinkInfo): Deleted.
        (JSC::CallLinkInfo::setFrameShuffleData): Deleted.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::getOrAddArrayProfile):
        (JSC::CodeBlock::codeOrigins):
        (JSC::CodeBlock::numberOfDFGIdentifiers):
        (JSC::CodeBlock::identifier):
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::hasExpressionInfo):
        (JSC::CodeBlock::hasCodeOrigins):
        (JSC::CodeBlock::numberOfIdentifiers):
        (JSC::CodeBlock::identifier):
        (JSC::CodeBlock::codeOrigins): Deleted.
        (JSC::CodeBlock::numberOfDFGIdentifiers): Deleted.
        * bytecode/CodeOrigin.h:
        * dfg/DFGDesiredIdentifiers.cpp:
        * heap/Heap.cpp:
        (JSC::Heap::didFinishIterating):
        (JSC::Heap::completeAllDFGPlans):
        (JSC::Heap::markRoots):
        (JSC::Heap::deleteAllCodeBlocks):
        * heap/Heap.h:
        * heap/HeapInlines.h:
        (JSC::Heap::deprecatedReportExtraMemory):
        (JSC::Heap::forEachCodeBlock):
        (JSC::Heap::forEachProtectedCell):
        * runtime/Executable.h:
        * runtime/JSCInlines.h:
        (JSC::Heap::forEachCodeBlock): Deleted.

2015-09-21 Aleksandr Skachkov   <gskachkov@gmail.com>

        Web Inspector: arrow function names are never inferred, call frames are labeled (anonymous function)
        https://bugs.webkit.org/show_bug.cgi?id=148318

        Reviewed by Saam Barati.

        Tiny change to support of the inferred name in arrow function
 
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createAssignResolve):

2015-09-19 Aleksandr Skachkov   <gskachkov@gmail.com>

        New tests introduced in r188545 fail on 32 bit ARM
        https://bugs.webkit.org/show_bug.cgi?id=148376

        Reviewed by Saam Barati.

        Added correct support of the ARM CPU in JIT functions that are related to arrow function.


        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileNewFunction):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emitNewFuncExprCommon):

2015-09-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement Store expressions in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149395

        Reviewed by Geoffrey Garen.

        The Store instruction in WebAssembly stores a value in the linear memory
        at the given index. It can be both a statement and an expression. When
        it is an expression, it returns the assigned value. This patch
        implements Store as an expression.

        Since Store uses two operands, which are the index and the value, we
        need to pop the two operands from the stack and push the value back to
        the stack. We can simply implement this by copying the value to where
        the index is in the stack.

        * tests/stress/wasm-linear-memory.js:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildStore):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseStatement):
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseStore):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildStore):

2015-09-20  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement SetLocal and SetGlobal expressions in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149383

        Reviewed by Saam Barati.

        SetLocal and SetGlobal in WebAssembly can be both statements and
        expressions. We have implemented the statement version. This patch
        implements the expression version.

        SetLocal and SetGlobal expressions return the assigned value.
        Since SetLocal and SetGlobal use only one operand, which is the assigned
        value, we can simply implement them by not removing the value from the
        top of the stack.

        * tests/stress/wasm-globals.js:
        * tests/stress/wasm-locals.js:
        * tests/stress/wasm/globals.wasm:
        * tests/stress/wasm/locals.wasm:
        * wasm/WASMConstants.h:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildSetLocal):
        (JSC::WASMFunctionCompiler::buildSetGlobal):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseStatement):
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseSetLocal):
        (JSC::WASMFunctionParser::parseSetGlobal):
        (JSC::WASMFunctionParser::parseSetLocalStatement): Deleted.
        (JSC::WASMFunctionParser::parseSetGlobalStatement): Deleted.
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildSetLocal):
        (JSC::WASMFunctionSyntaxChecker::buildSetGlobal):

2015-09-19 Aleksandr Skachkov    <gskachkov@gmail.com>

        [ES6] Added controlFlowProfiler test for arrow function
        https://bugs.webkit.org/show_bug.cgi?id=145638

        Reviewed by Saam Barati.

        * Source/JavaScriptCore/tests/controlFlowProfiler/arrowfunction-expression.js: added

2015-09-20  Youenn Fablet  <youenn.fablet@crf.canon.fr>

        Remove XHR_TIMEOUT compilation guard
        https://bugs.webkit.org/show_bug.cgi?id=149260

        Reviewed by Benjamin Poulain.

        * Configurations/FeatureDefines.xcconfig:

2015-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>

        [GTK] Unreviewed, should check the result of fread
        https://bugs.webkit.org/show_bug.cgi?id=148917

        Suppress the build warning on GTK with GCC.

        * jsc.cpp:
        (fillBufferWithContentsOfFile):
        (fetchModuleFromLocalFileSystem):

2015-09-19  Saam barati  <sbarati@apple.com>

        VariableEnvironmentNode should inherit from ParserArenaDeletable because VariableEnvironment's must have their destructors run
        https://bugs.webkit.org/show_bug.cgi?id=149359

        Reviewed by Andreas Kling.

        VariableEnvironment must have its destructor run.
        Therefore, VariableEnvironmentNode should inherit from ParserArenaDeletable.
        Also, anything that inherits from VariableEnvironmentNode must use
        ParserArenaDeletable's operator new. Also, any other nodes that own
        a VariableEnvironment must also have their destructors run.

        * parser/Nodes.h:
        (JSC::VariableEnvironmentNode::VariableEnvironmentNode):

2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Remove duplicate code in the WebAssembly parser
        https://bugs.webkit.org/show_bug.cgi?id=149361

        Reviewed by Saam Barati.

        Refactor the methods for parsing GetLocal and GetGlobal in WebAssembly
        to remove duplicate code.

        * wasm/WASMFunctionParser.cpp:
        (JSC::nameOfType):
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseUnaryExpressionF64):
        (JSC::WASMFunctionParser::parseBinaryExpressionF64):
        (JSC::WASMFunctionParser::parseGetLocalExpression):
        (JSC::WASMFunctionParser::parseGetGlobalExpression):
        (JSC::WASMFunctionParser::parseGetLocalExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseGetGlobalExpressionI32): Deleted.
        (JSC::WASMFunctionParser::parseGetLocalExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseGetGlobalExpressionF32): Deleted.
        (JSC::WASMFunctionParser::parseGetLocalExpressionF64): Deleted.
        (JSC::WASMFunctionParser::parseGetGlobalExpressionF64): Deleted.
        * wasm/WASMFunctionParser.h:

2015-09-18  Saam barati  <sbarati@apple.com>

        Refactor common code between GetCatchHandlerFunctor and UnwindFunctor
        https://bugs.webkit.org/show_bug.cgi?id=149276

        Reviewed by Mark Lam.

        There is currently code copy-pasted between these
        two functors. Lets not do that. It's better to write
        a function, even if the function is small.

        I also did a bit of renaming to make the intent of the
        unwindCallFrame function clear. The name of the function
        didn't really indicate what it did. It decided if it was
        okay to unwind further, and it also notified the debugger.
        I've renamed the function to notifyDebuggerOfUnwinding.
        And I've inlined the logic of deciding if it's okay
        to unwind further into UnwindFunctor itself.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::isOpcode):
        (JSC::getStackFrameCodeType):
        (JSC::Interpreter::stackTraceAsString):
        (JSC::findExceptionHandler):
        (JSC::GetCatchHandlerFunctor::GetCatchHandlerFunctor):
        (JSC::GetCatchHandlerFunctor::operator()):
        (JSC::notifyDebuggerOfUnwinding):
        (JSC::UnwindFunctor::UnwindFunctor):
        (JSC::UnwindFunctor::operator()):
        (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
        (JSC::unwindCallFrame): Deleted.

2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement the arithmetic instructions for doubles in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=148945

        Reviewed by Geoffrey Garen.

        This patch implements the arithmetic instructions for doubles (float64)
        in WebAssembly.

        * tests/stress/wasm-arithmetic-float64.js:
        * tests/stress/wasm/arithmetic-float64.wasm:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildUnaryF64):
        (JSC::WASMFunctionCompiler::buildBinaryF64):
        (JSC::WASMFunctionCompiler::callOperation):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseUnaryExpressionF64):
        (JSC::WASMFunctionParser::parseBinaryExpressionF64):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildUnaryF64):
        (JSC::WASMFunctionSyntaxChecker::buildBinaryF32):
        (JSC::WASMFunctionSyntaxChecker::buildBinaryF64):

2015-09-18  Basile Clement  <basile_clement@apple.com>

        [ES6] Tail call fast path should efficiently reuse the frame's stack space
        https://bugs.webkit.org/show_bug.cgi?id=148662

        Reviewed by Geoffrey Garen.

        This introduces a new class (CallFrameShuffler) that is responsible for
        efficiently building the new frames when performing a tail call. In
        order for Repatch to know about the position of arguments on the
        stack/registers (e.g. for polymorphic call inline caches), we store a
        CallFrameShuffleData in the CallLinkInfo. Otherwise, the JIT and DFG
        compiler are now using CallFrameShuffler instead of
        CCallHelpers::prepareForTailCallSlow() to build the frame for a tail
        call.

        When taking a slow path, we still build the frame as if doing a regular
        call, because we could throw an exception and need the caller's frame
        at that point. This means that for virtual calls, we don't benefit from
        the efficient frame move for now.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/ARMv7Assembler.h:
        (JSC::ARMv7Assembler::firstRegister):
        (JSC::ARMv7Assembler::lastRegister):
        (JSC::ARMv7Assembler::firstFPRegister):
        (JSC::ARMv7Assembler::lastFPRegister):
        * assembler/AbortReason.h:
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::setFrameShuffleData):
        (JSC::CallLinkInfo::frameShuffleData):
        * bytecode/ValueRecovery.h:
        (JSC::ValueRecovery::inRegister):
        * dfg/DFGGenerationInfo.h:
        (JSC::DFG::GenerationInfo::recovery):
        * jit/CachedRecovery.cpp: Added.
        (JSC::CachedRecovery::loadsIntoFPR):
        (JSC::CachedRecovery::loadsIntoGPR):
        * jit/CachedRecovery.h: Added.
        (JSC::CachedRecovery::CachedRecovery):
        (JSC::CachedRecovery::targets):
        (JSC::CachedRecovery::addTarget):
        (JSC::CachedRecovery::removeTarget):
        (JSC::CachedRecovery::clearTargets):
        (JSC::CachedRecovery::setWantedJSValueRegs):
        (JSC::CachedRecovery::setWantedFPR):
        (JSC::CachedRecovery::boxingRequiresGPR):
        (JSC::CachedRecovery::boxingRequiresFPR):
        (JSC::CachedRecovery::recovery):
        (JSC::CachedRecovery::setRecovery):
        (JSC::CachedRecovery::wantedJSValueRegs):
        (JSC::CachedRecovery::wantedFPR):
        * jit/CallFrameShuffleData.cpp: Added.
        (JSC::CallFrameShuffleData::setupCalleeSaveRegisters):
        * jit/CallFrameShuffleData.h: Added.
        * jit/CallFrameShuffler.cpp: Added.
        (JSC::CallFrameShuffler::CallFrameShuffler):
        (JSC::CallFrameShuffler::dump):
        (JSC::CallFrameShuffler::getCachedRecovery):
        (JSC::CallFrameShuffler::setCachedRecovery):
        (JSC::CallFrameShuffler::spill):
        (JSC::CallFrameShuffler::emitDeltaCheck):
        (JSC::CallFrameShuffler::prepareForSlowPath):
        (JSC::CallFrameShuffler::prepareForTailCall):
        (JSC::CallFrameShuffler::tryWrites):
        (JSC::CallFrameShuffler::performSafeWrites):
        (JSC::CallFrameShuffler::prepareAny):
        * jit/CallFrameShuffler.h: Added.
        (JSC::CallFrameShuffler::lockGPR):
        (JSC::CallFrameShuffler::acquireGPR):
        (JSC::CallFrameShuffler::releaseGPR):
        (JSC::CallFrameShuffler::snapshot):
        (JSC::CallFrameShuffler::setCalleeJSValueRegs):
        (JSC::CallFrameShuffler::assumeCalleeIsCell):
        (JSC::CallFrameShuffler::canBox):
        (JSC::CallFrameShuffler::ensureBox):
        (JSC::CallFrameShuffler::ensureLoad):
        (JSC::CallFrameShuffler::canLoadAndBox):
        (JSC::CallFrameShuffler::updateRecovery):
        (JSC::CallFrameShuffler::clearCachedRecovery):
        (JSC::CallFrameShuffler::addCachedRecovery):
        (JSC::CallFrameShuffler::numLocals):
        (JSC::CallFrameShuffler::getOld):
        (JSC::CallFrameShuffler::setOld):
        (JSC::CallFrameShuffler::firstOld):
        (JSC::CallFrameShuffler::lastOld):
        (JSC::CallFrameShuffler::isValidOld):
        (JSC::CallFrameShuffler::argCount):
        (JSC::CallFrameShuffler::getNew):
        (JSC::CallFrameShuffler::setNew):
        (JSC::CallFrameShuffler::addNew):
        (JSC::CallFrameShuffler::firstNew):
        (JSC::CallFrameShuffler::lastNew):
        (JSC::CallFrameShuffler::isValidNew):
        (JSC::CallFrameShuffler::newAsOld):
        (JSC::CallFrameShuffler::getFreeRegister):
        (JSC::CallFrameShuffler::getFreeGPR):
        (JSC::CallFrameShuffler::getFreeFPR):
        (JSC::CallFrameShuffler::hasFreeRegister):
        (JSC::CallFrameShuffler::ensureRegister):
        (JSC::CallFrameShuffler::ensureGPR):
        (JSC::CallFrameShuffler::ensureFPR):
        (JSC::CallFrameShuffler::addressForOld):
        (JSC::CallFrameShuffler::isUndecided):
        (JSC::CallFrameShuffler::isSlowPath):
        (JSC::CallFrameShuffler::addressForNew):
        (JSC::CallFrameShuffler::dangerFrontier):
        (JSC::CallFrameShuffler::isDangerNew):
        (JSC::CallFrameShuffler::updateDangerFrontier):
        (JSC::CallFrameShuffler::hasOnlySafeWrites):
        * jit/CallFrameShuffler32_64.cpp: Added.
        (JSC::CallFrameShuffler::emitStore):
        (JSC::CallFrameShuffler::emitBox):
        (JSC::CallFrameShuffler::emitLoad):
        (JSC::CallFrameShuffler::canLoad):
        (JSC::CallFrameShuffler::emitDisplace):
        * jit/CallFrameShuffler64.cpp: Added.
        (JSC::CallFrameShuffler::emitStore):
        (JSC::CallFrameShuffler::emitBox):
        (JSC::CallFrameShuffler::emitLoad):
        (JSC::CallFrameShuffler::canLoad):
        (JSC::CallFrameShuffler::emitDisplace):
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        * jit/RegisterMap.cpp:
        (JSC::RegisterMap::RegisterMap):
        (JSC::GPRMap::GPRMap):
        (JSC::FPRMap::FPRMap):
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):

2015-09-18  Saam barati  <sbarati@apple.com>

        Implement try/catch in the DFG.
        https://bugs.webkit.org/show_bug.cgi?id=147374

        Reviewed by Filip Pizlo.

        This patch implements try/catch inside the DFG JIT.
        It also prevents tier up to the FTL for any functions
        that have an op_catch in them that are DFG compiled.

        This patch accomplishes implementing try/catch inside
        the DFG by OSR exiting to op_catch when an exception is thrown.
        We can OSR exit from an exception inside the DFG in two ways:
        1) We have a JS call (can also be via implicit getter/setter in GetById/PutById)
        2) We have an exception when returing from a callOperation

        In the case of (1), we get to the OSR exit from genericUnwind because
        the exception was thrown in a child call frame. This means these
        OSR exits must act as defacto op_catches (even though we will still OSR
        exit to a baseline op_catch). That means they must restore the stack pointer
        and call frame.

        In the case of (2), we can skip genericUnwind because we know the exception 
        check will take us to a particular OSR exit. Instead, we link these
        exception checks as jumps to a particular OSR exit.

        Both types of OSR exits will exit into op_catch inside the baseline JIT.
        Because they exit to op_catch, these OSR exits must set callFrameForCatch
        to the proper call frame pointer.

        We "handle" all exceptions inside the machine frame of the DFG code
        block. This means the machine code block is responsible for "catching"
        exceptions of any inlined frames' try/catch. OSR exit will then exit to 
        the proper baseline CodeBlock after reifying the inlined frames
        (DFG::OSRExit::m_codeOrigin corresponds to the op_catch we will exit to). 
        Also, genericUnwind will never consult an inlined call frame's CodeBlock to 
        see if they can catch the exception because they can't. We always unwind to the 
        next machine code block frame. The DFG CodeBlock changes how the exception 
        handler table is keyed: it is now keyed by CallSiteIndex for DFG code blocks. 

        So, when consulting call sites that throw, we keep track of the CallSiteIndex,
        and the HandlerInfo for the corresponding baseline exception handler for
        that particular CallSiteIndex (if an exception at that call site will be caught). 
        Then, when we're inside DFG::JITCompiler::link(), we install new HandlerInfo's
        inside the DFG CodeBlock and key it by the corresponding CallSiteIndex.
        (The CodeBlock only has HandlerInfos for the OSR exits that are to be arrived
        at from genericUnwind).

        Also, each OSR exit will know if it acting as an exception handler, and
        whether or not it will be arrived at from genericUnwind. When we know we 
        will arrive at an OSR exit from genericUnwind, we set the corresponding 
        HandlerInfo's nativeCode CodeLocationLabel field to be the OSR exit.

        This patch also introduces a new Phase inside the DFG that ensures
        that DFG CodeBlocks that handle exceptions take the necessary
        steps to keep live variables at "op_catch" live according the
        OSR exit value recovery machinery. We accomplish this by flushing
        all live op_catch variables to the stack when inside a "try" block.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::handlerForBytecodeOffset):
        (JSC::CodeBlock::handlerForIndex):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::clearExceptionHandlers):
        (JSC::CodeBlock::appendExceptionHandler):
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::computePreciseJumpTargets):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getLocal):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::addCodeOrigin):
        (JSC::DFG::CommonData::lastCallSite):
        (JSC::DFG::CommonData::shrinkToFit):
        * dfg/DFGCommonData.h:
        * dfg/DFGGraph.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::noticeOSREntry):
        (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
        (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
        (JSC::DFG::JITCompiler::exceptionCheck):
        (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
        (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
        (JSC::DFG::JITCompiler::appendCall):
        (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
        (JSC::DFG::JITCompiler::blockHeads):
        (JSC::DFG::JITCompiler::exceptionCheck): Deleted.
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp: Added.
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase):
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::run):
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock):
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::newVariableAccessData):
        (JSC::DFG::performLiveCatchVariablePreservationPhase):
        * dfg/DFGLiveCatchVariablePreservationPhase.h: Added.
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        (JSC::DFG::OSRExit::setPatchableCodeOffset):
        * dfg/DFGOSRExit.h:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::osrWriteBarrier):
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGOSRExitCompilerCommon.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGSlowPathGenerator.h:
        (JSC::DFG::SlowPathGenerator::SlowPathGenerator):
        (JSC::DFG::SlowPathGenerator::~SlowPathGenerator):
        (JSC::DFG::SlowPathGenerator::generate):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * interpreter/Interpreter.cpp:
        (JSC::GetCatchHandlerFunctor::operator()):
        (JSC::UnwindFunctor::operator()):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::gotoNextFrame):
        (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
        (JSC::StackVisitor::readFrame):
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::operator*):
        (JSC::StackVisitor::operator->):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitExceptionCheck):
        (JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
        (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitCount):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_catch):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::clearException):
        (JSC::VM::clearLastException):
        (JSC::VM::addressOfCallFrameForCatch):
        (JSC::VM::exception):
        (JSC::VM::addressOfException):
        * tests/stress/dfg-exception-try-catch-in-constructor-with-inlined-throw.js: Added.
        (f):
        (bar):
        (Foo):
        * tests/stress/es6-for-of-loop-exception.js: Added.
        (assert):
        (shouldThrowInvalidConstAssignment):
        (baz):
        (foo):
        * tests/stress/exception-dfg-inlined-frame-not-strict-equal.js: Added.
        (assert):
        (o.valueOf):
        (o.toString):
        (read):
        (bar):
        (foo):
        * tests/stress/exception-dfg-not-strict-equal.js: Added.
        (foo):
        (o.valueOf):
        (o.toString):
        (assert):
        (shouldDoSomethingInFinally):
        (catch):
        * tests/stress/exception-dfg-operation-read-value.js: Added.
        (assert):
        (o.valueOf):
        (o.toString):
        (read):
        (foo):
        * tests/stress/exception-dfg-throw-from-catch-block.js: Added.
        (assert):
        (baz):
        (bar):
        (foo):

2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement linear memory instructions in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149326

        Reviewed by Geoffrey Garen.

        This patch implements linear memory instructions in WebAssembly.[1] To
        use the linear memory, an ArrayBuffer must be passed to loadWebAssembly().

        Notes:
        - We limit the ArrayBuffer's byte length to 2^31 - 1. This enables us to
          use only one comparison (unsigned greater than) to check for
          out-of-bounds access.
        - There is no consensus yet on what should happen when an out-of-bounds
          access occurs.[2] For now, we throw an error when that happens.
        - In asm.js, a heap access looks like this: int32Array[i >> 2]. Note
          that ">> 2" is part of the syntax and is required. pack-asmjs will
          produce bytecodes that look something like "LoadI32, i" (not
          "LoadI32, ShiftRightI32, i, 2"). The requirement of the shift operator
          prevents unaligned accesses in asm.js. (There is a proposal to support
          unaligned accesses in the future version of asm.js using DataView.[3])
          The WebAssembly spec allows unaligned accesses.[4] But since we use
          asm.js for testing, we follow asm.js's behaviors for now.

        [1]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#linear-memory
        [2]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#out-of-bounds
        [3]: https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#Possible_asm.js_extensions_that_don.27t_require_new_JS_features
        [4]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#alignment

        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionLoadWebAssembly):
        * tests/stress/wasm-linear-memory.js: Added.
        (shouldBe):
        (shouldThrow):
        * tests/stress/wasm/linear-memory.wasm: Added.
        * wasm/JSWASMModule.cpp:
        (JSC::JSWASMModule::JSWASMModule):
        (JSC::JSWASMModule::visitChildren):
        * wasm/JSWASMModule.h:
        (JSC::JSWASMModule::create):
        (JSC::JSWASMModule::arrayBuffer):
        (JSC::JSWASMModule::JSWASMModule): Deleted.
        * wasm/WASMConstants.h:
        * wasm/WASMFunctionCompiler.h:
        (JSC::sizeOfMemoryType):
        (JSC::WASMFunctionCompiler::MemoryAddress::MemoryAddress):
        (JSC::WASMFunctionCompiler::endFunction):
        (JSC::WASMFunctionCompiler::buildLoad):
        (JSC::WASMFunctionCompiler::buildStore):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseStatement):
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseMemoryAddress):
        (JSC::WASMFunctionParser::parseLoad):
        (JSC::WASMFunctionParser::parseStore):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::MemoryAddress::MemoryAddress):
        (JSC::WASMFunctionSyntaxChecker::buildLoad):
        (JSC::WASMFunctionSyntaxChecker::buildStore):
        * wasm/WASMModuleParser.cpp:
        (JSC::WASMModuleParser::WASMModuleParser):
        (JSC::WASMModuleParser::parseModule):
        (JSC::parseWebAssembly):
        (JSC::WASMModuleParser::parse): Deleted.
        * wasm/WASMModuleParser.h:

2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement type conversion instructions in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149340

        Reviewed by Mark Lam.

        This patch implements some type conversion instructions in WebAssembly.
        The WebAssembly spec has a lot more type conversion instructions than
        what are available in asm.js.[1] We only implement the ones that are in
        asm.js for now because we can only test those.

        [1]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md

        * tests/stress/wasm-type-conversion.js:
        * tests/stress/wasm/type-conversion.wasm:
        * wasm/WASMConstants.h:
        * wasm/WASMFunctionCompiler.h:
        (JSC::operationConvertUnsignedInt32ToDouble):
        (JSC::WASMFunctionCompiler::buildConvertType):
        (JSC::WASMFunctionCompiler::callOperation):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseConvertType):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildConvertType):

2015-09-18  Alex Christensen  <achristensen@webkit.org>

        Fix tests on Windows after switching to CMake.
        https://bugs.webkit.org/show_bug.cgi?id=149339

        Reviewed by Brent Fulgham.

        * shell/PlatformWin.cmake:
        Build testapi and testRegExp (which doesn't seem to be used any more).

2015-09-17  Brian Burg  <bburg@apple.com>

        ASSERT(!m_frontendRouter->hasLocalFrontend()) when running Web Inspector tests
        https://bugs.webkit.org/show_bug.cgi?id=149006

        Reviewed by Joseph Pecoraro.

        Prior to disconnecting, we need to know how many frontends remain connected.

        * inspector/InspectorFrontendRouter.h: Add frontendCount().

2015-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>

        Explicitly specify builtin JS files dependency
        https://bugs.webkit.org/show_bug.cgi?id=149323

        Reviewed by Alex Christensen.

        JSCBuiltins.{h,cpp} in CMakeLists.txt and DerivedSources.make just depend on the builtins directory.
        As a result, even if we modify builtins/*.js code, regenerating JSCBuiltins.{h,cpp} does not occur.
        As the same to the cpp sources, let's list up the JS files explicitly.

        * CMakeLists.txt:
        * DerivedSources.make:

2015-09-18  Michael Saboff  <msaboff@apple.com>

        Remove register preservation and restoration stub code
        https://bugs.webkit.org/show_bug.cgi?id=149335

        Reviewed by Mark Lam.

        Delete the register preservation and restoration thunks and related plumbing.

        Much of this change is removing the unneeded RegisterPreservationMode parameter
        from various functions.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::isVarargsCallType):
        (JSC::CallLinkInfo::CallLinkInfo):
        (JSC::CallLinkInfo::isVarargs):
        (JSC::CallLinkInfo::isLinked):
        (JSC::CallLinkInfo::setUpCallFromFTL):
        (JSC::CallLinkInfo::registerPreservationMode): Deleted.
        * ftl/FTLJITCode.cpp:
        (JSC::FTL::JITCode::initializeAddressForCall):
        (JSC::FTL::JITCode::addressForCall):
        * ftl/FTLJITCode.h:
        * ftl/FTLOSREntry.cpp:
        (JSC::FTL::prepareOSREntry):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * jit/JITCode.cpp:
        (JSC::JITCode::execute):
        (JSC::DirectJITCode::initializeCodeRef):
        (JSC::DirectJITCode::addressForCall):
        (JSC::NativeJITCode::initializeCodeRef):
        (JSC::NativeJITCode::addressForCall):
        (JSC::DirectJITCode::ensureWrappers): Deleted.
        * jit/JITCode.h:
        (JSC::JITCode::jitTypeFor):
        (JSC::JITCode::executableAddress):
        * jit/JITOperations.cpp:
        * jit/RegisterPreservationWrapperGenerator.cpp: Removed.
        * jit/RegisterPreservationWrapperGenerator.h: Removed.
        * jit/Repatch.cpp:
        (JSC::linkPolymorphicCall):
        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):
        * jit/ThunkGenerators.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::setUpCall):
        * runtime/Executable.cpp:
        (JSC::ExecutableBase::clearCode):
        (JSC::ScriptExecutable::installCode):
        (JSC::WebAssemblyExecutable::prepareForExecution):
        * runtime/Executable.h:
        (JSC::ExecutableBase::generatedJITCodeFor):
        (JSC::ExecutableBase::entrypointFor):
        (JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor):
        * runtime/RegisterPreservationMode.h: Removed.

2015-09-17  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Remove unused canClearBrowserCookies / canClearBrowserCache protocol methods
        https://bugs.webkit.org/show_bug.cgi?id=149307

        Reviewed by Brian Burg.

        * inspector/protocol/Network.json:
        Remove unused protocol methods.

2015-09-17  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r189938, r189952, and r189956.
        https://bugs.webkit.org/show_bug.cgi?id=149329

        Broke Web Workers (Requested by ap on #webkit).

        Reverted changesets:

        "Implement try/catch in the DFG."
        https://bugs.webkit.org/show_bug.cgi?id=147374
        http://trac.webkit.org/changeset/189938

        "CLoop build fix after r189938."
        http://trac.webkit.org/changeset/189952

        "add a regress test for richards with try/catch."
        https://bugs.webkit.org/show_bug.cgi?id=149301
        http://trac.webkit.org/changeset/189956

2015-09-17  Ryosuke Niwa  <rniwa@webkit.org>

        CLoop build fix after r189938.

        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::unwindToMachineCodeBlockFrame):

2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Convert return values from JavaScript functions to the expected types in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149200

        Reviewed by Mark Lam.

        When a WebAssembly function calls a JavaScript function, there is no
        guarantee that the JavaScript function will always return values of the
        type we expect. This patch converts the return values to the expected
        types.

        (The reverse is also true: When a WebAssembly function is called from a
        JavaScript function, there is no guarantee that the arguments to the
        WebAssembly function will always be of the types we expect. We have
        fixed this in Bug 149033.)

        We don't need to type check the return values if the callee is a
        WebAssembly function. We don't need to type check the arguments if the
        caller is a WebAssembly function. This optimization will be
        implemented in the future. See https://bugs.webkit.org/show_bug.cgi?id=149310

        * tests/stress/wasm-type-conversion.js:
        * tests/stress/wasm/type-conversion.wasm:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):
        (JSC::WASMFunctionCompiler::buildReturn):
        (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
        (JSC::WASMFunctionCompiler::callAndUnboxResult):
        (JSC::WASMFunctionCompiler::convertValueToInt32):
        (JSC::WASMFunctionCompiler::convertValueToDouble):
        (JSC::WASMFunctionCompiler::convertDoubleToValue):
        (JSC::WASMFunctionCompiler::loadValueAndConvertToInt32): Deleted.
        (JSC::WASMFunctionCompiler::loadValueAndConvertToDouble): Deleted.
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseCallInternalExpressionI32): Deleted.
        * wasm/WASMFunctionParser.h:

2015-09-17  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Add more fine-grained APIs and additional hooks to control module loader from WebCore
        https://bugs.webkit.org/show_bug.cgi?id=149129

        Reviewed by Saam Barati.

        No behavior change.

        Module tag `<script type="module>` will be executed asynchronously.
        But we would like to fetch the resources before when the postTask-ed task is performed.
        So instead of 1 API that fetch, instantiate and execute the module,
        we need 2 fine-grained APIs.

        1. Fetch and initialize a module, but not execute it yet.
        2. Link and execute a module specified by the key (this will be invoked asynchronously).

        And to instrument the script execution (like reporting the execution time of the module to
        the inspector), we need a hook to inject code around an execution of a module body.

        * builtins/ModuleLoaderObject.js:
        (moduleEvaluation):
        (loadAndEvaluateModule):
        (loadModule):
        (linkAndEvaluateModule):
        * jsc.cpp:
        (functionLoadModule):
        (runWithScripts):
        * runtime/Completion.cpp:
        (JSC::identifierToJSValue):
        (JSC::createSymbolForEntryPointModule):
        (JSC::rejectPromise):
        (JSC::loadAndEvaluateModule):
        (JSC::loadModule):
        (JSC::linkAndEvaluateModule):
        (JSC::evaluateModule): Deleted.
        * runtime/Completion.h:
        * runtime/JSGlobalObject.cpp:
        * runtime/JSGlobalObject.h:
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::evaluate):
        (JSC::JSModuleRecord::execute): Deleted.
        * runtime/JSModuleRecord.h:
        * runtime/ModuleLoaderObject.cpp:
        (JSC::ModuleLoaderObject::loadAndEvaluateModule):
        (JSC::ModuleLoaderObject::linkAndEvaluateModule):
        (JSC::ModuleLoaderObject::evaluate):
        (JSC::moduleLoaderObjectEvaluate):
        * runtime/ModuleLoaderObject.h:

2015-09-17  Saam barati  <sbarati@apple.com>

        Implement try/catch in the DFG.
        https://bugs.webkit.org/show_bug.cgi?id=147374

        Reviewed by Filip Pizlo.

        This patch implements try/catch inside the DFG JIT.
        It also prevents tier up to the FTL for any functions
        that have an op_catch in them that are DFG compiled.

        This patch accomplishes implementing try/catch inside
        the DFG by OSR exiting to op_catch when an exception is thrown.
        We can OSR exit from an exception inside the DFG in two ways:
        1) We have a JS call (can also be via implicit getter/setter in GetById/PutById)
        2) We have an exception when returing from a callOperation

        In the case of (1), we get to the OSR exit from genericUnwind because
        the exception was thrown in a child call frame. This means these
        OSR exits must act as defacto op_catches (even though we will still OSR
        exit to a baseline op_catch). That means they must restore the stack pointer
        and call frame.

        In the case of (2), we can skip genericUnwind because we know the exception 
        check will take us to a particular OSR exit. Instead, we link these
        exception checks as jumps to a particular OSR exit.

        Both types of OSR exits will exit into op_catch inside the baseline JIT.
        Because they exit to op_catch, these OSR exits must set callFrameForCatch
        to the proper call frame pointer.

        We "handle" all exceptions inside the machine frame of the DFG code
        block. This means the machine code block is responsible for "catching"
        exceptions of any inlined frames' try/catch. OSR exit will then exit to 
        the proper baseline CodeBlock after reifying the inlined frames
        (DFG::OSRExit::m_codeOrigin corresponds to the op_catch we will exit to). 
        Also, genericUnwind will never consult an inlined call frame's CodeBlock to 
        see if they can catch the exception because they can't. We always unwind to the 
        next machine code block frame. The DFG CodeBlock changes how the exception 
        handler table is keyed: it is now keyed by CallSiteIndex for DFG code blocks. 

        So, when consulting call sites that throw, we keep track of the CallSiteIndex,
        and the HandlerInfo for the corresponding baseline exception handler for
        that particular CallSiteIndex (if an exception at that call site will be caught). 
        Then, when we're inside DFG::JITCompiler::link(), we install new HandlerInfo's
        inside the DFG CodeBlock and key it by the corresponding CallSiteIndex.
        (The CodeBlock only has HandlerInfos for the OSR exits that are to be arrived
        at from genericUnwind).

        Also, each OSR exit will know if it acting as an exception handler, and
        whether or not it will be arrived at from genericUnwind. When we know we 
        will arrive at an OSR exit from genericUnwind, we set the corresponding 
        HandlerInfo's nativeCode CodeLocationLabel field to be the OSR exit.

        This patch also introduces a new Phase inside the DFG that ensures
        that DFG CodeBlocks that handle exceptions take the necessary
        steps to keep live variables at "op_catch" live according the
        OSR exit value recovery machinery. We accomplish this by flushing
        all live op_catch variables to the stack when inside a "try" block.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::handlerForBytecodeOffset):
        (JSC::CodeBlock::handlerForIndex):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::clearExceptionHandlers):
        (JSC::CodeBlock::appendExceptionHandler):
        * bytecode/PreciseJumpTargets.cpp:
        (JSC::computePreciseJumpTargets):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getLocal):
        (JSC::DFG::ByteCodeParser::setLocal):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * dfg/DFGCommonData.cpp:
        (JSC::DFG::CommonData::addCodeOrigin):
        (JSC::DFG::CommonData::lastCallSite):
        (JSC::DFG::CommonData::shrinkToFit):
        * dfg/DFGCommonData.h:
        * dfg/DFGGraph.h:
        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::linkOSRExits):
        (JSC::DFG::JITCompiler::link):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::noticeOSREntry):
        (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
        (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
        (JSC::DFG::JITCompiler::exceptionCheck):
        (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
        * dfg/DFGJITCompiler.h:
        (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
        (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
        (JSC::DFG::JITCompiler::appendCall):
        (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
        (JSC::DFG::JITCompiler::blockHeads):
        (JSC::DFG::JITCompiler::exceptionCheck): Deleted.
        * dfg/DFGLiveCatchVariablePreservationPhase.cpp: Added.
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase):
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::run):
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock):
        (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::newVariableAccessData):
        (JSC::DFG::performLiveCatchVariablePreservationPhase):
        * dfg/DFGLiveCatchVariablePreservationPhase.h: Added.
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        (JSC::DFG::OSRExit::setPatchableCodeOffset):
        * dfg/DFGOSRExit.h:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::osrWriteBarrier):
        (JSC::DFG::adjustAndJumpToTarget):
        * dfg/DFGOSRExitCompilerCommon.h:
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGSlowPathGenerator.h:
        (JSC::DFG::SlowPathGenerator::SlowPathGenerator):
        (JSC::DFG::SlowPathGenerator::~SlowPathGenerator):
        (JSC::DFG::SlowPathGenerator::generate):
        * dfg/DFGSpeculativeJIT.h:
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::emitCall):
        * dfg/DFGTierUpCheckInjectionPhase.cpp:
        (JSC::DFG::TierUpCheckInjectionPhase::run):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * interpreter/Interpreter.cpp:
        (JSC::GetCatchHandlerFunctor::operator()):
        (JSC::UnwindFunctor::operator()):
        * interpreter/StackVisitor.cpp:
        (JSC::StackVisitor::gotoNextFrame):
        (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
        (JSC::StackVisitor::readFrame):
        * interpreter/StackVisitor.h:
        (JSC::StackVisitor::operator*):
        (JSC::StackVisitor::operator->):
        * jit/AssemblyHelpers.cpp:
        (JSC::AssemblyHelpers::emitExceptionCheck):
        (JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
        (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitCount):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_catch):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/VM.h:
        (JSC::VM::clearException):
        (JSC::VM::clearLastException):
        (JSC::VM::addressOfCallFrameForCatch):
        (JSC::VM::exception):
        (JSC::VM::addressOfException):
        * tests/stress/dfg-exception-try-catch-in-constructor-with-inlined-throw.js: Added.
        (f):
        (bar):
        (Foo):
        * tests/stress/es6-for-of-loop-exception.js: Added.
        (assert):
        (shouldThrowInvalidConstAssignment):
        (baz):
        (foo):
        * tests/stress/exception-dfg-inlined-frame-not-strict-equal.js: Added.
        (assert):
        (o.valueOf):
        (o.toString):
        (read):
        (bar):
        (foo):
        * tests/stress/exception-dfg-not-strict-equal.js: Added.
        (foo):
        (o.valueOf):
        (o.toString):
        (assert):
        (shouldDoSomethingInFinally):
        (catch):
        * tests/stress/exception-dfg-operation-read-value.js: Added.
        (assert):
        (o.valueOf):
        (o.toString):
        (read):
        (foo):
        * tests/stress/exception-dfg-throw-from-catch-block.js: Added.
        (assert):
        (baz):
        (bar):
        (foo):

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

        0.0 should really be 0.0
        https://bugs.webkit.org/show_bug.cgi?id=149283

        Reviewed by Mark Lam.

        A while ago (http://trac.webkit.org/changeset/180813) we introduced the idea that if the
        user wrote a number with a decimal point (like "0.0") then we should treat that number as
        a double. That's probably a pretty good idea. But, we ended up doing it inconsistently.
        The DFG would indeed treat such a number as a double by consulting the
        SourceCodeRepresentation, but the other execution engines would still see Int32:0.

        This patch makes it consistent.

        This is necessary for property type inference to perform well. Otherwise, a store of a
        constant would change type from the baseline engine to the DFG, which would then cause
        a storm of property type invalidations and recompilations.

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

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

        stress/exit-from-getter.js.ftl-eager occasionally traps in debug
        https://bugs.webkit.org/show_bug.cgi?id=149096

        Reviewed by Geoffrey Garen.

        JS calls to getters/setters in get/put inline caches need to reset SP after the call, as our
        calling convention requires.

        * bytecode/PolymorphicAccess.cpp:
        (JSC::AccessCase::generate): Fix the bug.
        * ftl/FTLLink.cpp:
        (JSC::FTL::link): Adds some verbiage about why the FTL stack offset logic is correct.
        * tests/stress/getter-arity.js: Added. Other tests would flaky crash before the patch. This test instacrashes before the patch.

2015-09-17  Saam barati  <sbarati@apple.com>

        Interpreter::unwind() shouldn't be responsible for filtering out uncatchable exceptions
        https://bugs.webkit.org/show_bug.cgi?id=149228

        Reviewed by Mark Lam.

        op_catch is now responsible for filtering exceptions that
        aren't catchable. When op_catch encounters an uncatchable
        exception, it will call back into genericUnwind and throw
        the exception further down the call stack. This is necessary
        in a later patch that will implement exception handling
        in the DFG, and part of that patch includes exception
        handling that doesn't go through genericUnwind. The DFG try/catch
        patch will not go through genericUnwind when it knows that
        an exception check after a callOperation will be caught inside the 
        machine frame or any inlined frames. This patch enables that 
        patch by destroying the notion that all exception handling must 
        filter through genericUnwind.

        This patch maintains compatibility with the debugger and
        profiler by ensuring we notify the debugger when an
        exception is thrown inside VM::throwException and not
        in genericUnwind. It also notifies the profiler that we've
        potentially changed call frames inside op_catch.

        * debugger/Debugger.cpp:
        (JSC::Debugger::pauseIfNeeded):
        * interpreter/Interpreter.cpp:
        (JSC::unwindCallFrame):
        (JSC::getStackFrameCodeType):
        (JSC::UnwindFunctor::operator()):
        (JSC::Interpreter::unwind):
        (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
        (JSC::checkedReturn):
        * interpreter/Interpreter.h:
        (JSC::SuspendExceptionScope::SuspendExceptionScope):
        (JSC::SuspendExceptionScope::~SuspendExceptionScope):
        (JSC::Interpreter::sampler):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        (JSC::JIT::callOperationNoExceptionCheck):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        (JSC::LLInt::llint_throw_stack_overflow_error):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/ExceptionHelpers.cpp:
        (JSC::isTerminatedExecutionException):
        * runtime/VM.cpp:
        (JSC::VM::throwException):
        * runtime/VM.h:
        (JSC::VM::targetMachinePCForThrowOffset):
        (JSC::VM::restorePreviousException):
        (JSC::VM::clearException):
        (JSC::VM::clearLastException):
        (JSC::VM::exception):
        (JSC::VM::addressOfException):
        (JSC::VM::setException):

2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Calling a float function on x86 in WebAssembly incorrectly returns a double
        https://bugs.webkit.org/show_bug.cgi?id=149254

        Reviewed by Michael Saboff.

        In WebAssembly on x86 (32-bit), when we call a function that returns a
        float or a double, we use the FSTP instruction to read the return value
        from the FPU register stack. The FSTP instruction converts the value to
        single-precision or double-precision floating-point format, depending on
        the destination operand. Currently, we always use double as the
        destination, which is wrong. This patch uses the correct return type.
        This should fix the test errors in tests/stress/wasm-arithmetic-float32.js

        * assembler/X86Assembler.h:
        (JSC::X86Assembler::fstps):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::appendCallSetResult):
        (JSC::WASMFunctionCompiler::callOperation):

2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Save and restore callee save registers in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149247

        Reviewed by Michael Saboff.

        Save callee save registers when entering WebAssembly functions
        and restore them when returning.

        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
        * jit/RegisterSet.h:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):
        (JSC::WASMFunctionCompiler::endFunction):
        (JSC::WASMFunctionCompiler::buildReturn):
        (JSC::WASMFunctionCompiler::localAddress):
        (JSC::WASMFunctionCompiler::temporaryAddress):
        (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
        (JSC::WASMFunctionCompiler::callAndUnboxResult):

2015-09-16  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement indirect calls in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149100

        Reviewed by Geoffrey Garen.

        This patch implement indirect calls for WebAssembly files generated by
        pack-asmjs <https://github.com/WebAssembly/polyfill-prototype-1>.
        pack-asmjs uses the same indirect call model as asm.js. In asm.js, an
        indirect call looks like this:
            t[i & n](...)
        where t is a variable referring to an array of functions with the same
        signature, i is an integer expression, n is an integer that is equal to
        (t.length - 1), and t.length is a power of two. pack-asmjs does not
        use the '&' operator nor n in the WebAssembly output, but the semantics
        is still the same as asm.js.

        * tests/stress/wasm-calls.js:
        * tests/stress/wasm/calls.wasm:
        * wasm/WASMFormat.h:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildCallIndirect):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseCallIndirect):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildCallIndirect):
        * wasm/WASMModuleParser.cpp:
        (JSC::WASMModuleParser::parseFunctionPointerTableSection):
        (JSC::WASMModuleParser::parseFunctionDefinitionSection):

2015-09-16  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Fix 32-bit build issues in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149240

        Reviewed by Geoffrey Garen.

        Fix the syntax error and replace the instructions that are not available on
        64-bit platforms.

        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):
        (JSC::WASMFunctionCompiler::endFunction):
        (JSC::WASMFunctionCompiler::buildReturn):
        (JSC::WASMFunctionCompiler::callAndUnboxResult):
        (JSC::WASMFunctionCompiler::loadValueAndConvertToDouble):

2015-09-16  Geoffrey Garen  <ggaren@apple.com>

        JavaScriptCore should discard baseline code after some time
        https://bugs.webkit.org/show_bug.cgi?id=149220

        Reviewed by Saam Barati.

        This is a bit more complicated than discarding optimized code because
        the engine previously assumed that we would never discard baseline code.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock): Record creation time (and compute time since
        creation) instead of install time because CodeBlocks can be installed
        more than once, and we don't want to have to worry about edge cases
        created by CodeBlocks seeming to get younger.

        (JSC::CodeBlock::visitAggregate): Be explicit about only doing the 
        weak reference fixpoint for optimized CodeBlocks. We used to avoid the
        fixpoint for baseline CodeBlocks implicitly, since they would always
        visit themselves strongly right away. But now baseline CodeBlocks might
        not visit themselves strongly, since they might choose to jettison due
        to old age.

        (JSC::CodeBlock::shouldVisitStrongly): Add old age as a reason not to
        visit ourselves strongly, so that baseline CodeBlocks can jettison due
        to old age.

        (JSC::CodeBlock::shouldJettisonDueToWeakReference): Be explicit about
        only jettisoning optimized CodeBlocks due to weak references so that we
        don't confuse ourselves into thinking that we will jettison a baseline
        CodeBlock due to weak references.

        (JSC::CodeBlock::shouldJettisonDueToOldAge): Updated to use creation time.

        (JSC::CodeBlock::visitOSRExitTargets): Clarify a comment and add an
        ASSERT to help record some things I discovered while debugging.

        (JSC::CodeBlock::jettison): Allow a baseline CodeBlock to jettison. Don't
        assume that we have an alternative or a profiler.

        (JSC::CodeBlock::install): Deleted.
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::releaseAlternative): Deleted.
        (JSC::CodeBlock::setInstallTime): Deleted.
        (JSC::CodeBlock::timeSinceInstall): Deleted.

        * dfg/DFGOSRExitPreparation.cpp:
        (JSC::DFG::prepareCodeOriginForOSRExit): Simplified the computation of
        baseline CodeBlock.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::checkLivenessAndVisitChildren): Be sure to strongly
        visit our inline callframes because we assume that an optimized CodeBlock
        will keep its OSR exit targets alive, but the CodeBlock object won't be
        able to mark them for itself until compilation has completed (since it
        won't have a JITCode object yet).

        * dfg/DFGToFTLDeferredCompilationCallback.cpp:
        (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
        Updated for interface change.

        * jit/JITCode.h:
        (JSC::JITCode::timeToLive): Provide a time to live for interpreter and
        baseline code, so they will jettison when old. Use seconds in our
        code so that we don't need comments. Make DFG 2X interpreter+baseline,
        and FTL 2X DFG+interpreter+baseline, also matching the time we allot
        before throwing away all code.

        * jit/JITToDFGDeferredCompilationCallback.cpp:
        (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::jitCompileAndSetHeuristics): Updated for interface change.

        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::installCode): Allow our caller to install nullptr,
        since we need to do this when jettisoning a baseline CodeBlock. Require
        our caller to specify the details of the installation because we can't
        rely on a non-null CodeBlock in order to compute them.

        (JSC::ScriptExecutable::newCodeBlockFor):
        (JSC::ScriptExecutable::prepareForExecutionImpl):
        * runtime/Executable.h:
        (JSC::ScriptExecutable::recordParse): Updated for interface change.

        * runtime/Options.h: Renamed the CodeBlock liveness option since it now
        controls baseline and optimized code.

2015-09-16  Geoffrey Garen  <ggaren@apple.com>

        Remove obsolete code for deleting CodeBlocks
        https://bugs.webkit.org/show_bug.cgi?id=149231

        Reviewed by Mark Lam.

        * heap/Heap.cpp:
        (JSC::Heap::deleteAllCodeBlocks): ASSERT that we're called in a valid
        state, and do the compiler waiting ourselves instead of having our
        caller do it. This is more appropriate to our new limited use.

        (JSC::Heap::collectImpl):
        (JSC::Heap::deleteOldCode): Deleted. Don't call deleteAllCodeBlocks
        periodically because it's not such a good idea to delete everything
        at once, and CodeBlocks now have a more precise individual policy for
        when to delete. Also, this function used to fail all or nearly all of
        the time because its invariants that we were not executing or compiling
        could not be met.

        * heap/Heap.h:

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionDeleteAllCompiledCode): Deleted.
        * tests/stress/deleteAllCompiledCode.js: Removed. Removed this testing
        code because it did not do what it thought it did. All of this code
        was guaranteed to no-op since it would run JavaScript to call a function
        that would return early because JavaScript was running.

        * runtime/VM.cpp:
        (JSC::VM::deleteAllCode): This code is simpler now becaue 
        heap.deleteAllCodeBlocks does some work for us.

        * runtime/VMEntryScope.cpp:
        (JSC::VMEntryScope::VMEntryScope): Don't delete code on VM entry. This
        policy was old, and it dated back to a time when we 

            (a) couldn't run in the interpreter if compilation failed;

            (b) didn't reduce the rate of compilation in response to executable
            memory pressure;

            (c) didn't throw away individual CodeBlocks automatically.

2015-09-16  Michael Saboff  <msaboff@apple.com>

        [ES6] Implement tail calls in the LLInt and Baseline JIT
        https://bugs.webkit.org/show_bug.cgi?id=148661

        Fix for the breakage of Speedometer/Full.html (https://bugs.webkit.org/show_bug.cgi?id=149162).

        Reviewed by Filip Pizlo.
        Changed SetupVarargsFrame.cpp::emitSetVarargsFrame to align the callframe size to be a
        multiple of stackAlignmentRegisters() in addition to the location of the new frame.

        Fixed Reviewed by Filip Pizlo.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbortReason.h:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::Call::Call):
        (JSC::AbstractMacroAssembler::repatchNearCall):
        (JSC::AbstractMacroAssembler::repatchCompact):
        * assembler/CodeLocation.h:
        (JSC::CodeLocationNearCall::CodeLocationNearCall):
        (JSC::CodeLocationNearCall::callMode):
        (JSC::CodeLocationCommon::callAtOffset):
        (JSC::CodeLocationCommon::nearCallAtOffset):
        (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::locationOfNearCall):
        (JSC::LinkBuffer::locationOf):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::nearCall):
        (JSC::MacroAssemblerARM::nearTailCall):
        (JSC::MacroAssemblerARM::call):
        (JSC::MacroAssemblerARM::linkCall):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::nearCall):
        (JSC::MacroAssemblerARM64::nearTailCall):
        (JSC::MacroAssemblerARM64::ret):
        (JSC::MacroAssemblerARM64::linkCall):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::nearCall):
        (JSC::MacroAssemblerARMv7::nearTailCall):
        (JSC::MacroAssemblerARMv7::call):
        (JSC::MacroAssemblerARMv7::linkCall):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::nearCall):
        (JSC::MacroAssemblerMIPS::nearTailCall):
        (JSC::MacroAssemblerMIPS::call):
        (JSC::MacroAssemblerMIPS::linkCall):
        (JSC::MacroAssemblerMIPS::repatchCall):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::call):
        (JSC::MacroAssemblerSH4::nearTailCall):
        (JSC::MacroAssemblerSH4::nearCall):
        (JSC::MacroAssemblerSH4::linkCall):
        (JSC::MacroAssemblerSH4::repatchCall):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::linkCall):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::breakpoint):
        (JSC::MacroAssemblerX86Common::nearTailCall):
        (JSC::MacroAssemblerX86Common::nearCall):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::linkCall):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::callTypeFor):
        (JSC::CallLinkInfo::isVarargsCallType):
        (JSC::CallLinkInfo::CallLinkInfo):
        (JSC::CallLinkInfo::specializationKind):
        (JSC::CallLinkInfo::callModeFor):
        (JSC::CallLinkInfo::callMode):
        (JSC::CallLinkInfo::isTailCall):
        (JSC::CallLinkInfo::isVarargs):
        (JSC::CallLinkInfo::registerPreservationMode):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromLLInt):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCallInTailPosition):
        (JSC::BytecodeGenerator::emitCallEval):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallArguments::CallArguments):
        (JSC::LabelNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::isCallBytecode):
        (JSC::calleeFrameForVarargs):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::jumpToExceptionHandler):
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::emit_op_call):
        (JSC::JIT::emit_op_tail_call):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_tail_call_varargs):
        (JSC::JIT::emit_op_construct_varargs):
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_tail_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_varargs):
        (JSC::JIT::emitSlow_op_construct_varargs):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_tail_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_varargs):
        (JSC::JIT::emitSlow_op_construct_varargs):
        (JSC::JIT::emit_op_call):
        (JSC::JIT::emit_op_tail_call):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_tail_call_varargs):
        (JSC::JIT::emit_op_construct_varargs):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        * jit/JITInlines.h:
        (JSC::JIT::emitNakedCall):
        (JSC::JIT::emitNakedTailCall):
        (JSC::JIT::updateTopCallFrame):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/Repatch.cpp:
        (JSC::linkVirtualFor):
        (JSC::linkPolymorphicCall):
        * jit/SetupVarargsFrame.cpp:
        (JSC::emitSetVarargsFrame):
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::slowPathFor):
        (JSC::linkCallThunkGenerator):
        (JSC::virtualThunkFor):
        (JSC::arityFixupGenerator):
        (JSC::unreachableGenerator):
        (JSC::baselineGetterReturnThunkGenerator):
        * jit/ThunkGenerators.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        (JSC::CommonSlowPaths::opIn):

2015-09-15  Michael Saboff  <msaboff@apple.com>

        Rollout r189774 and 189818.

        Broke Speedometer/Full.html

        Not reviewed.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbortReason.h:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::Call::Call):
        (JSC::AbstractMacroAssembler::repatchNearCall):
        (JSC::AbstractMacroAssembler::repatchCompact):
        * assembler/CodeLocation.h:
        (JSC::CodeLocationNearCall::CodeLocationNearCall):
        (JSC::CodeLocationCommon::callAtOffset):
        (JSC::CodeLocationCommon::nearCallAtOffset):
        (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
        (JSC::CodeLocationNearCall::callMode): Deleted.
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::locationOfNearCall):
        (JSC::LinkBuffer::locationOf):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::nearCall):
        (JSC::MacroAssemblerARM::call):
        (JSC::MacroAssemblerARM::linkCall):
        (JSC::MacroAssemblerARM::nearTailCall): Deleted.
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::nearCall):
        (JSC::MacroAssemblerARM64::ret):
        (JSC::MacroAssemblerARM64::linkCall):
        (JSC::MacroAssemblerARM64::nearTailCall): Deleted.
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::nearCall):
        (JSC::MacroAssemblerARMv7::call):
        (JSC::MacroAssemblerARMv7::linkCall):
        (JSC::MacroAssemblerARMv7::nearTailCall): Deleted.
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::nearCall):
        (JSC::MacroAssemblerMIPS::call):
        (JSC::MacroAssemblerMIPS::linkCall):
        (JSC::MacroAssemblerMIPS::repatchCall):
        (JSC::MacroAssemblerMIPS::nearTailCall): Deleted.
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::call):
        (JSC::MacroAssemblerSH4::nearCall):
        (JSC::MacroAssemblerSH4::linkCall):
        (JSC::MacroAssemblerSH4::repatchCall):
        (JSC::MacroAssemblerSH4::nearTailCall): Deleted.
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::linkCall):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::breakpoint):
        (JSC::MacroAssemblerX86Common::nearCall):
        (JSC::MacroAssemblerX86Common::nearTailCall): Deleted.
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::linkCall):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::callTypeFor):
        (JSC::CallLinkInfo::CallLinkInfo):
        (JSC::CallLinkInfo::specializationKind):
        (JSC::CallLinkInfo::registerPreservationMode):
        (JSC::CallLinkInfo::isVarargsCallType): Deleted.
        (JSC::CallLinkInfo::callModeFor): Deleted.
        (JSC::CallLinkInfo::callMode): Deleted.
        (JSC::CallLinkInfo::isTailCall): Deleted.
        (JSC::CallLinkInfo::isVarargs): Deleted.
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromLLInt):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCallInTailPosition):
        (JSC::BytecodeGenerator::emitCallEval):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallArguments::CallArguments):
        (JSC::LabelNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::isCallBytecode):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::jumpToExceptionHandler):
        (JSC::CCallHelpers::prepareForTailCallSlow): Deleted.
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::emit_op_call):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_construct_varargs):
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_construct_varargs):
        (JSC::JIT::emit_op_tail_call): Deleted.
        (JSC::JIT::emit_op_tail_call_varargs): Deleted.
        (JSC::JIT::emitSlow_op_tail_call): Deleted.
        (JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_construct_varargs):
        (JSC::JIT::emit_op_call):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_construct_varargs):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::emitSlow_op_tail_call): Deleted.
        (JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
        (JSC::JIT::emit_op_tail_call): Deleted.
        (JSC::JIT::emit_op_tail_call_varargs): Deleted.
        * jit/JITInlines.h:
        (JSC::JIT::emitNakedCall):
        (JSC::JIT::updateTopCallFrame):
        (JSC::JIT::emitNakedTailCall): Deleted.
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/Repatch.cpp:
        (JSC::linkVirtualFor):
        (JSC::linkPolymorphicCall):
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::slowPathFor):
        (JSC::linkCallThunkGenerator):
        (JSC::virtualThunkFor):
        (JSC::arityFixupGenerator):
        (JSC::baselineGetterReturnThunkGenerator):
        (JSC::unreachableGenerator): Deleted.
        * jit/ThunkGenerators.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        (JSC::CommonSlowPaths::opIn):
        * tests/stress/mutual-tail-call-no-stack-overflow.js: Removed.
        * tests/stress/tail-call-no-stack-overflow.js: Removed.
        * tests/stress/tail-call-recognize.js: Removed.
        * tests/stress/tail-call-varargs-no-stack-overflow.js: Removed.
        * tests/stress/tail-calls-dont-overwrite-live-stack.js: Removed.

2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement imported global variables in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149206

        Reviewed by Filip Pizlo.

        Values can now be imported to a WebAssembly module through properties of
        the imports object that is passed to loadWebAssembly(). In order to
        avoid any side effect when accessing the imports object, we check that
        the properties are data properties. We also check that each value is a
        primitive and is not a Symbol. According to the ECMA262 6.0 spec,
        calling ToNumber() on a primitive that is not a Symbol should not cause
        any side effect.[1]

        [1]: http://www.ecma-international.org/ecma-262/6.0/#sec-tonumber

        * tests/stress/wasm-globals.js:
        * tests/stress/wasm/globals.wasm:
        * wasm/WASMModuleParser.cpp:
        (JSC::WASMModuleParser::parseModule):
        (JSC::WASMModuleParser::parseGlobalSection):
        * wasm/WASMModuleParser.h:

2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Fix asm.js errors in WebAssembly tests
        https://bugs.webkit.org/show_bug.cgi?id=149203

        Reviewed by Geoffrey Garen.

        Our WebAssembly implementation uses asm.js for testing. Using Firefox to
        parse asm.js reveals many errors that are not caught by pack-asmjs. For
        example,
        - asm.js does not allow the use of the multiplication operator (*) to
          multiply two integers, because the result can be so large that some
          lower bits of precision are lost. Math.imul is used instead.
        - an int variable must be coerced to either signed (via x|0) or unsigned
          (via x>>>0) before it's returned.

        * tests/stress/wasm-arithmetic-int32.js:
        * tests/stress/wasm-calls.js:
        * tests/stress/wasm-control-flow.js:
        * tests/stress/wasm-globals.js:
        * tests/stress/wasm-locals.js:
        * tests/stress/wasm-relational.js:
        * tests/stress/wasm/control-flow.wasm:

2015-09-15  Ryosuke Niwa  <rniwa@webkit.org>

        Add ShadowRoot interface and Element.prototype.attachShadow
        https://bugs.webkit.org/show_bug.cgi?id=149187

        Reviewed by Antti Koivisto.

        * Configurations/FeatureDefines.xcconfig:

2015-09-15  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: Paused Debugger prevents page reload
        https://bugs.webkit.org/show_bug.cgi?id=148174

        Reviewed by Brian Burg.

        * debugger/Debugger.h:
        (JSC::Debugger::suppressAllPauses):
        (JSC::Debugger::setSuppressAllPauses):
        * debugger/Debugger.cpp:
        (JSC::Debugger::Debugger):
        (JSC::Debugger::pauseIfNeeded):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::setSuppressAllPauses):
        Provide a way to suppress pauses.

2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement calls to JavaScript functions in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149093

        Reviewed by Filip Pizlo.

        This patch implements calls to JavaScript functions in WebAssembly.
        WebAssembly functions can only call JavaScript functions that are
        imported to their module via an object that is passed into
        loadWebAssembly(). References to JavaScript functions are resolved at
        the module's load time, just like asm.js.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionLoadWebAssembly):
        * tests/stress/wasm-calls.js:
        * tests/stress/wasm/calls.wasm:
        * wasm/JSWASMModule.cpp:
        (JSC::JSWASMModule::visitChildren):
        * wasm/JSWASMModule.h:
        (JSC::JSWASMModule::importedFunctions):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildCallImport):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseCallImport):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildCallInternal):
        (JSC::WASMFunctionSyntaxChecker::buildCallImport):
        (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall):
        * wasm/WASMModuleParser.cpp:
        (JSC::WASMModuleParser::WASMModuleParser):
        (JSC::WASMModuleParser::parse):
        (JSC::WASMModuleParser::parseModule):
        (JSC::WASMModuleParser::parseFunctionImportSection):
        (JSC::WASMModuleParser::getImportedValue):
        (JSC::parseWebAssembly):
        * wasm/WASMModuleParser.h:

2015-09-15  Csaba Osztrogonác  <ossy@webkit.org>

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

        Reviewed by Yusuke Suzuki.

        * bytecode/GetByIdStatus.cpp:
        * bytecode/GetByIdStatus.h:

2015-09-15  Saam barati  <sbarati@apple.com>

        functions that use try/catch will allocate a top level JSLexicalEnvironment even when it is not necessary
        https://bugs.webkit.org/show_bug.cgi?id=148169

        Reviewed by Geoffrey Garen.

        We used to do this before we had proper lexical scoping
        in the bytecode generator. There is absolutely no reason
        why need to allocate a top-level "var" activation when a
        function/program uses a "catch" block.

        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createTryStatement):
        (JSC::ASTBuilder::incConstants):
        (JSC::ASTBuilder::usesThis):
        (JSC::ASTBuilder::usesArguments):
        (JSC::ASTBuilder::usesWith):
        (JSC::ASTBuilder::usesEval):
        (JSC::ASTBuilder::usesCatch): Deleted.
        * parser/Nodes.h:
        (JSC::ScopeNode::isStrictMode):
        (JSC::ScopeNode::setUsesArguments):
        (JSC::ScopeNode::usesThis):
        (JSC::ScopeNode::needsActivation):
        (JSC::ScopeNode::hasCapturedVariables):
        (JSC::ScopeNode::captures):
        (JSC::ScopeNode::needsActivationForMoreThanVariables): Deleted.
        * parser/ParserModes.h:
        * runtime/Executable.h:
        (JSC::ScriptExecutable::usesEval):
        (JSC::ScriptExecutable::usesArguments):
        (JSC::ScriptExecutable::needsActivation):
        (JSC::ScriptExecutable::isStrictMode):
        (JSC::ScriptExecutable::ecmaMode):

2015-09-15  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r189774): CLoop doesn't build after r189774
        https://bugs.webkit.org/show_bug.cgi?id=149171

        Unreviewed build fix for the C Loop.

        Added needed C Loop label opcodes.

        * bytecode/BytecodeList.json:

2015-09-15  Andy VanWagoner  <thetalecrafter@gmail.com>

        [INTL] Implement supportedLocalesOf on Intl Constructors
        https://bugs.webkit.org/show_bug.cgi?id=147599

        Reviewed by Benjamin Poulain.

        Implements all of the abstract operations used by supportedLocalesOf,
        except during canonicalization it does not replace redundant tags,
        or subtags with their preferred values.

        * icu/unicode/ucal.h: Added.
        * icu/unicode/udat.h: Added.
        * icu/unicode/umisc.h: Added.
        * icu/unicode/unum.h: Added.
        * icu/unicode/utypes.h: Clear the U_SHOW_CPLUSPLUS_API flag to prevent C++ headers from being included.
        * runtime/CommonIdentifiers.h: Adde localeMatcher.
        * runtime/IntlCollatorConstructor.cpp:
        (JSC::IntlCollatorConstructorFuncSupportedLocalesOf): Implemented.
        * runtime/IntlDateTimeFormatConstructor.cpp:
        (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): Implemented.
        * runtime/IntlNumberFormatConstructor.cpp:
        (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): Implemented.
        * runtime/IntlObject.cpp:
        (JSC::canonicalizeLanguageTag):
        (JSC::getCanonicalLangTag):
        (JSC::getPrivateUseLangTag):
        (JSC::getGrandfatheredLangTag):
        (JSC::canonicalizeLocaleList):
        (JSC::bestAvailableLocale):
        (JSC::lookupSupportedLocales):
        (JSC::bestFitSupportedLocales):
        (JSC::supportedLocales):
        (JSC::getIntlStringOption):
        (JSC::getIntlBooleanOption):
        * runtime/IntlObject.h:
        * runtime/JSCJSValue.h: Added toLength.
        * runtime/JSCJSValue.cpp: Added toLength.
        (JSC::JSValue::toLength): Implement ToLength from ECMA 262 6.0 7.1.15
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::intlCollatorAvailableLocales): Added lazy locale list.
        (JSC::JSGlobalObject::intlDateTimeFormatAvailableLocales): Added lazy locale list.
        (JSC::JSGlobalObject::intlNumberFormatAvailableLocales): Added lazy locale list.
        * runtime/JSGlobalObject.h:

2015-09-14  Saam barati  <sbarati@apple.com>

        rename callFrameForThrow to callFrameForCatch
        https://bugs.webkit.org/show_bug.cgi?id=149136

        Reviewed by Michael Saboff.

        We use "callFrameForThrow" to mean the call frame in
        which we're catching the exception. The field name
        should accurately represent its purpose by being
        named "callFrameForCatch".

        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::jumpToExceptionHandler):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOperations.cpp:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/VM.h:
        (JSC::VM::exceptionOffset):
        (JSC::VM::callFrameForCatchOffset):
        (JSC::VM::targetMachinePCForThrowOffset):
        (JSC::VM::callFrameForThrowOffset): Deleted.

2015-09-14  Basile Clement  <basile_clement@apple.com>

        [ES6] Implement tail calls in the LLInt and Baseline JIT
        https://bugs.webkit.org/show_bug.cgi?id=148661

        Reviewed by Filip Pizlo.

        This patch introduces two new opcodes, op_tail_call and
        op_tail_call_varargs, to perform tail calls, and implements them in the
        LLInt and baseline JIT. Their use prevents DFG and FTL compilation for
        now. They are currently implemented by sliding the call frame and
        masquerading as our own caller right before performing an actual call.

        This required to change the operationLink family of operation to return
        a SlowPathReturnType instead of a char* in order to distinguish between
        exception cases and actual call cases. We introduce a new FrameAction
        enum that indicates whether to reuse (non-exceptional tail call) or
        keep the current call frame (non-tail call, and exceptional cases).

        This is also a semantics change, since the Function.caller property is
        now leaking tail calls. Since tail calls are only used in strict mode,
        which poisons this property, the only way of seeing this semantics
        change is when a sloppy function calls a strict function that then
        tail-calls a sloppy function. Previously, the second sloppy function's
        caller would have been the strict function (i.e. raises a TypeError
        when the .caller attribute is accessed), while it is now the first
        sloppy function. Tests have been updated to reflect that.

        This also changes the assumptions we make about call frames. In order
        to be relatively efficient, we want to be able to compute the frame
        size based only on the argument count, which was not possible
        previously. To enable this, we now enforce at the bytecode generator,
        DFG and FTL level that any space reserved for a call frame is
        stack-aligned, which allows to easily compute its size when performing
        a tail call. In all the "special call cases" (calls from native code,
        inlined cache calls, etc.), we are starting the frame at the current
        stack pointer and thus will always have a stack-aligned frame size.

        Finally, this patch adds a couple of tests to check that tail calls run
        in constant stack space, as well as tests checking that tail calls are
        recognized correctly. Those tests use the handy aforementioned leaking
        of tail calls through Function.caller to detect tail calls. 

        Given that this patch only implements tail calls for the LLInt and
        Baseline JIT, tail calls are disabled by default.  Until changes are
        landed for all tiers, tail call testing and use requires the
        --enableTailCalls=true or equivalent.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/AbortReason.h:
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::Call::Call):
        (JSC::AbstractMacroAssembler::repatchNearCall):
        (JSC::AbstractMacroAssembler::repatchCompact):
        * assembler/CodeLocation.h:
        (JSC::CodeLocationNearCall::CodeLocationNearCall):
        (JSC::CodeLocationNearCall::callMode):
        (JSC::CodeLocationCommon::callAtOffset):
        (JSC::CodeLocationCommon::nearCallAtOffset):
        (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
        * assembler/LinkBuffer.h:
        (JSC::LinkBuffer::locationOfNearCall):
        (JSC::LinkBuffer::locationOf):
        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::nearCall):
        (JSC::MacroAssemblerARM::nearTailCall):
        (JSC::MacroAssemblerARM::call):
        (JSC::MacroAssemblerARM::linkCall):
        * assembler/MacroAssemblerARM64.h:
        (JSC::MacroAssemblerARM64::nearCall):
        (JSC::MacroAssemblerARM64::nearTailCall):
        (JSC::MacroAssemblerARM64::ret):
        (JSC::MacroAssemblerARM64::linkCall):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::nearCall):
        (JSC::MacroAssemblerARMv7::nearTailCall):
        (JSC::MacroAssemblerARMv7::call):
        (JSC::MacroAssemblerARMv7::linkCall):
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::nearCall):
        (JSC::MacroAssemblerMIPS::nearTailCall):
        (JSC::MacroAssemblerMIPS::call):
        (JSC::MacroAssemblerMIPS::linkCall):
        (JSC::MacroAssemblerMIPS::repatchCall):
        * assembler/MacroAssemblerSH4.h:
        (JSC::MacroAssemblerSH4::call):
        (JSC::MacroAssemblerSH4::nearTailCall):
        (JSC::MacroAssemblerSH4::nearCall):
        (JSC::MacroAssemblerSH4::linkCall):
        (JSC::MacroAssemblerSH4::repatchCall):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::linkCall):
        * assembler/MacroAssemblerX86Common.h:
        (JSC::MacroAssemblerX86Common::breakpoint):
        (JSC::MacroAssemblerX86Common::nearTailCall):
        (JSC::MacroAssemblerX86Common::nearCall):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::linkCall):
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::callTypeFor):
        (JSC::CallLinkInfo::isVarargsCallType):
        (JSC::CallLinkInfo::CallLinkInfo):
        (JSC::CallLinkInfo::specializationKind):
        (JSC::CallLinkInfo::callModeFor):
        (JSC::CallLinkInfo::callMode):
        (JSC::CallLinkInfo::isTailCall):
        (JSC::CallLinkInfo::isVarargs):
        (JSC::CallLinkInfo::registerPreservationMode):
        * bytecode/CallLinkStatus.cpp:
        (JSC::CallLinkStatus::computeFromLLInt):
        * bytecode/CallMode.cpp: Added.
        (WTF::printInternal):
        * bytecode/CallMode.h: Added.
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::emitCallInTailPosition):
        (JSC::BytecodeGenerator::emitCallEval):
        (JSC::BytecodeGenerator::emitCall):
        (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
        (JSC::BytecodeGenerator::emitConstructVarargs):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::CallArguments::CallArguments):
        (JSC::LabelNode::emitBytecode):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::isCallBytecode):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::jumpToExceptionHandler):
        (JSC::CCallHelpers::prepareForTailCallSlow):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        * jit/JITCall.cpp:
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        (JSC::JIT::emit_op_call):
        (JSC::JIT::emit_op_tail_call):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_tail_call_varargs):
        (JSC::JIT::emit_op_construct_varargs):
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_tail_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_varargs):
        (JSC::JIT::emitSlow_op_construct_varargs):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emitSlow_op_call):
        (JSC::JIT::emitSlow_op_tail_call):
        (JSC::JIT::emitSlow_op_call_eval):
        (JSC::JIT::emitSlow_op_call_varargs):
        (JSC::JIT::emitSlow_op_tail_call_varargs):
        (JSC::JIT::emitSlow_op_construct_varargs):
        (JSC::JIT::emit_op_call):
        (JSC::JIT::emit_op_tail_call):
        (JSC::JIT::emit_op_call_eval):
        (JSC::JIT::emit_op_call_varargs):
        (JSC::JIT::emit_op_tail_call_varargs):
        (JSC::JIT::emit_op_construct_varargs):
        (JSC::JIT::compileOpCall):
        (JSC::JIT::compileOpCallSlowCase):
        * jit/JITInlines.h:
        (JSC::JIT::emitNakedCall):
        (JSC::JIT::emitNakedTailCall):
        (JSC::JIT::updateTopCallFrame):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/Repatch.cpp:
        (JSC::linkVirtualFor):
        (JSC::linkPolymorphicCall):
        * jit/ThunkGenerators.cpp:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::slowPathFor):
        (JSC::linkCallThunkGenerator):
        (JSC::virtualThunkFor):
        (JSC::arityFixupGenerator):
        (JSC::unreachableGenerator):
        (JSC::baselineGetterReturnThunkGenerator):
        * jit/ThunkGenerators.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        (JSC::CommonSlowPaths::opIn):
        * runtime/Options.h:
        * tests/stress/mutual-tail-call-no-stack-overflow.js: Added.
        (shouldThrow):
        (sloppyCountdown.even):
        (sloppyCountdown.odd):
        (strictCountdown.even):
        (strictCountdown.odd):
        (strictCountdown):
        (odd):
        (even):
        * tests/stress/tail-call-no-stack-overflow.js: Added.
        (shouldThrow):
        (strictLoop):
        (strictLoopArityFixup1):
        (strictLoopArityFixup2):
        * tests/stress/tail-call-recognize.js: Added.
        (callerMustBeRun):
        (callerMustBeStrict):
        (runTests):
        * tests/stress/tail-call-varargs-no-stack-overflow.js: Added.
        (shouldThrow):
        (strictLoop):
        * tests/stress/tail-calls-dont-overwrite-live-stack.js: Added.
        (tail):
        (obj.method):
        (obj.get fromNative):
        (getThis):

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

        LLInt get/put inline caches shouldn't use tons of opcodes
        https://bugs.webkit.org/show_bug.cgi?id=149106

        Reviewed by Geoffrey Garen.

        Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
        example, instead of having get_by_id branch on the kind of offset (inline or
        out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
        But the problem with this approach is that it doesn't scale. In the property type
        inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
        inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
        new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
        checks, we'd have 6 * 11 = 66 variants of put_by_id).

        So, this patch completely changes the strategy to mostly using branching inside the
        opcode implementation. It's unlikely to have a performance effect. For example, the long
        road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
        and yet nobody noticed. The regression was because the inline cache was in terms of the
        structure, not the structure ID, so the code was doing a structure ID table lookup. If we
        didn't notice that, then we probably won't notice a couple new branches. (Also, this
        patch fixes that regression - the code no longer does such lookups except in the one
        unavoidable case in put_by_id transition chain checking.)

        This patch also turns the isDirect operand of put_by_id into a flags field. I will use
        this flags field to encode the desired type check in bug 148610.

        This patch has no effect on performance according to run-jsc-benchmarks.

        Relanding this patch with LLInt fixes for non-x86. Previous attempts to fix non-x86 LLInt
        build also caused every 64-bit test to crash on every platform. So the patch got rolled
        out. This fixes the non-x86 LLInt build while also ensuring that 64-bit platforms don't
        crash.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::printGetByIdCacheStatus):
        (JSC::CodeBlock::printPutByIdCacheStatus):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/CodeBlock.h:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        * bytecode/PutByIdFlags.cpp: Added.
        (WTF::printInternal):
        * bytecode/PutByIdFlags.h: Added.
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedInstruction::UnlinkedInstruction):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPutById):
        (JSC::BytecodeGenerator::emitDirectPutById):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_by_id):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2015-09-14  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r189751, r189752, and r189754.
        https://bugs.webkit.org/show_bug.cgi?id=149143

        caused crashes everywhere (Requested by alexchristensen on
        #webkit).

        Reverted changesets:

        "LLInt get/put inline caches shouldn't use tons of opcodes"
        https://bugs.webkit.org/show_bug.cgi?id=149106
        http://trac.webkit.org/changeset/189751

        "Unreviewed, fix non-x86 LLInt build."
        http://trac.webkit.org/changeset/189752

        "Unreviewed, really fix non-x86 LLInt build without also
        breaking everything else."
        http://trac.webkit.org/changeset/189754

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

        Unreviewed, really fix non-x86 LLInt build without also breaking everything else.

        * llint/LowLevelInterpreter64.asm:

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

        Unreviewed, fix non-x86 LLInt build.

        * llint/LowLevelInterpreter64.asm:

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

        LLInt get/put inline caches shouldn't use tons of opcodes
        https://bugs.webkit.org/show_bug.cgi?id=149106

        Reviewed by Geoffrey Garen.

        Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
        example, instead of having get_by_id branch on the kind of offset (inline or
        out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
        But the problem with this approach is that it doesn't scale. In the property type
        inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
        inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
        new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
        checks, we'd have 6 * 11 = 66 variants of put_by_id).

        So, this patch completely changes the strategy to mostly using branching inside the
        opcode implementation. It's unlikely to have a performance effect. For example, the long
        road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
        and yet nobody noticed. The regression was because the inline cache was in terms of the
        structure, not the structure ID, so the code was doing a structure ID table lookup. If we
        didn't notice that, then we probably won't notice a couple new branches. (Also, this
        patch fixes that regression - the code no longer does such lookups except in the one
        unavoidable case in put_by_id transition chain checking.)

        This patch also turns the isDirect operand of put_by_id into a flags field. I will use
        this flags field to encode the desired type check in bug 148610.

        This patch has no effect on performance according to run-jsc-benchmarks.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdOp):
        (JSC::CodeBlock::printGetByIdCacheStatus):
        (JSC::CodeBlock::printPutByIdCacheStatus):
        (JSC::CodeBlock::dumpBytecode):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::finalizeLLIntInlineCaches):
        * bytecode/CodeBlock.h:
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFromLLInt):
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        * bytecode/PutByIdFlags.cpp: Added.
        (WTF::printInternal):
        * bytecode/PutByIdFlags.h: Added.
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFromLLInt):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedInstruction::UnlinkedInstruction):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPutById):
        (JSC::BytecodeGenerator::emitDirectPutById):
        * dfg/DFGAbstractInterpreterInlines.h:
        (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCapabilities.cpp:
        (JSC::DFG::capabilityLevel):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_by_id):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2015-09-14  Alex Christensen  <achristensen@webkit.org>

        Progress towards CMake on Mac.
        https://bugs.webkit.org/show_bug.cgi?id=149123

        Reviewed by Chris Dumez.

        * CMakeLists.txt:
        Make forwarding headers for the replay subdirectory.
        * PlatformMac.cmake:
        Make forwarding headers for the generated inspector headers. 
        They should eventually either be packaged correctly with JavaScriptCore headers and included correctly.

2015-09-14  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Cache the resolution result in JSModuleRecord
        https://bugs.webkit.org/show_bug.cgi?id=148896

        Reviewed by Saam Barati.

        The resolveExport operation is frequently called. For example,
        1. When instantiating the module environment, we call it for each exported name and imported
           name.
        2. When linking the imported module environment to the code block, we call it to resolve the
           resolution.
        3. When looking up the property from the namespace object, we call it to look up the original
           module for the imported binding.
        4. When creating the namespace object, we need to collect all the exported names from the module
           and need to resolve them by calling resolveExport.

        However, resolveExport takes some cost. It traces the imported modules and resolves the reference
        queried by the original module.

        The resolveExport operation is pure function; given a module record and an export name,
        it always returns the same result. So we cache resolution results in the module record to avoid
        repeated resolveExport calls with the same arguments.
        Here, we only cache the correctly resolved references, since,
        1. We rarely looked up the non-correctly-resolved ones. In the linking phase, attempting to
           resolve non-correctly-resolved ones throws a syntax error. So only namespace object creation
           phase does it in a syntax valid script.
        2. This strategy limits the size of the cache map. The number of the correctly exported bindings
           is defined by the modules' code. So the size does not become infinitely large.

        Currently, the all modules cannot be linked twice. For example,

          graph 1

          -> (A) -> (B)

          graph 2

          -> (C) -> (A) -> (B)

        We cannot test the behavior now because when executing the graph 2, (A) and (B) are already linked,
        it raises an error in the current loader spec. But it should be allowed[1] since it will occur when
        there is multiple module tag in WebCore.

        [1]: https://github.com/whatwg/loader/issues/41

        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::ResolveQuery::Hash::hash):
        (JSC::JSModuleRecord::ResolveQuery::Hash::equal):
        (JSC::JSModuleRecord::cacheResolution):
        (JSC::ResolveQueryHash::hash): Deleted.
        (JSC::ResolveQueryHash::equal): Deleted.
        (JSC::resolveExportLoop): Deleted.
        * runtime/JSModuleRecord.h:
        * tests/modules/caching-should-not-make-ambiguous.js: Added.
        * tests/modules/caching-should-not-make-ambiguous/A.js: Added.
        * tests/modules/caching-should-not-make-ambiguous/B.js: Added.
        * tests/modules/caching-should-not-make-ambiguous/C.js: Added.
        * tests/modules/caching-should-not-make-ambiguous/D.js: Added.
        * tests/modules/caching-should-not-make-ambiguous/main.js: Added.
        * tests/modules/different-view.js: Added.
        (from.string_appeared_here.shouldThrow):
        * tests/modules/different-view/A.js: Added.
        * tests/modules/different-view/B.js: Added.
        * tests/modules/different-view/C.js: Added.
        * tests/modules/different-view/D.js: Added.
        * tests/modules/different-view/E.js: Added.
        * tests/modules/different-view/main.js: Added.
        * tests/modules/fallback-ambiguous.js: Added.
        (from.string_appeared_here.shouldThrow):
        * tests/modules/fallback-ambiguous/A.js: Added.
        * tests/modules/fallback-ambiguous/B.js: Added.
        * tests/modules/fallback-ambiguous/C.js: Added.
        * tests/modules/fallback-ambiguous/D.js: Added.
        * tests/modules/fallback-ambiguous/E.js: Added.
        * tests/modules/fallback-ambiguous/main.js: Added.
        * tests/modules/self-star-link.js: Added.
        * tests/modules/self-star-link/A.js: Added.
        * tests/modules/self-star-link/B.js: Added.
        * tests/modules/self-star-link/C.js: Added.
        * tests/modules/self-star-link/D.js: Added.
        * tests/modules/self-star-link/E.js: Added.
        * tests/modules/uncacheable-when-see-star.js: Added.
        * tests/modules/uncacheable-when-see-star/A-pre.js: Added.
        * tests/modules/uncacheable-when-see-star/A.js: Added.
        * tests/modules/uncacheable-when-see-star/B.js: Added.
        * tests/modules/uncacheable-when-see-star/C.js: Added.
        * tests/modules/uncacheable-when-see-star/D.js: Added.
        * tests/modules/uncacheable-when-see-star/E-pre.js: Added.
        * tests/modules/uncacheable-when-see-star/E.js: Added.
        * tests/modules/uncacheable-when-see-star/main1.js: Added.
        * tests/modules/uncacheable-when-see-star/main2.js: Added.

2015-09-14  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement the arithmetic instructions for floats in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149102

        Reviewed by Geoffrey Garen.

        This patch implements the arithmetic instructions for floats (float32)
        in WebAssembly by converting the float operands to doubles, performing
        the equivalent double instructions, and converting the result back to
        float. The asm.js spec says that "As proved in 'When is double rounding
        innocuous?' (Figueroa 1995), both the 32- and 64-bit versions of
        standard arithmetic operations produce equivalent results when given
        32-bit inputs and coerced to 32-bit outputs."
        (http://asmjs.org/spec/latest/#floatish)

        This patch also pads WebAssembly call frames by maxFrameExtentForSlowPathCall,
        so that there is no need to adjust the stack pointer every time we make
        a slow path call.

        * tests/stress/wasm-arithmetic-float32.js:
        * tests/stress/wasm/arithmetic-float32.wasm:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::startFunction):
        (JSC::WASMFunctionCompiler::buildUnaryF32):
        (JSC::WASMFunctionCompiler::buildBinaryF32):
        (JSC::WASMFunctionCompiler::callOperation):
        (JSC::WASMFunctionCompiler::callAndUnboxResult):
        (JSC::WASMFunctionCompiler::endFunction): Deleted.
        (JSC::WASMFunctionCompiler::buildBinaryI32): Deleted.
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseUnaryExpressionF32):
        (JSC::WASMFunctionParser::parseBinaryExpressionF32):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildUnaryF32):
        (JSC::WASMFunctionSyntaxChecker::buildBinaryF32):

2015-09-13  Geoffrey Garen  <ggaren@apple.com>

        Eden GC should not try to jettison old CodeBlocks in the remembered set
        https://bugs.webkit.org/show_bug.cgi?id=149108

        Reviewed by Saam Barati.

        All we know about objects in the remembered set is that they must be
        visited. We don't know whether they're referenced or not because we
        won't mark the objects that point to them.

        Therefore, it's incorrect for a CodeBlock to consider jettisoning
        itself when it's marked as a part of the remembered set: Some
        old object might have visited the CodeBlock strongly if given the chance.

        I believe this doesn't cause any problems currently because we happen
        to visit all strong references to all CodeBlocks elligible for jettison
        during every GC.

        However, this behavior is a logical oddity that tripped me up, and I
        believe it will start causing real problems once we start to jettison
        baseline CodeBlocks, since we do not visit all strong references to all
        baseline CodeBlocks during every GC.

        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::clearMarksForEdenCollection):
        (JSC::CodeBlockSet::traceMarked): Be sure to visit the remembered set
        strongly, in order to prohibit jettisoning.

        (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
        * heap/CodeBlockSet.h: Track the remembered set during eden GCs.

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

        REGRESSION(r189585): run-perf-tests Speedometer fails with a console error
        https://bugs.webkit.org/show_bug.cgi?id=149066

        Reviewed by Michael Saboff.

        The bug here was that the new IC code was calling actionForCell() more than once. That's
        illegal, since when actionForCell() returns RetryCacheLater, it means that it changed some
        object's Structure. The Repatch code was doing things like "if (actionForCell(blah) ==
        AttemptToCache)" in more than one place, so that if the first such expression was false, then
        we'd fall through to the next one. It's possible for the first call to return RetryCacheLater,
        in which case our view of the world just got clobbered and we need to return, and then the
        second call will probably return AttemptToCache because it *thinks* that we had bailed the last
        time and we're now in a future IC invocation.

        The solution is to cache the actionForCell() result. This is a bit tricky, because we need to
        do this after we check if we're in a proxy.

        Debugging bugs like these requires adding ad hoc bisection code in various places. We already
        had the basic hooks for this. This patch makes those hooks a bit more useful. In the case of
        the LLInt->JIT tier-up hooks, it adds a CodeBlock* argument so that we can bisect based on the
        CodeBlock. In the case of Repatch, it puts the Options::forceICFailure() check in a helper
        function that also takes ExecState*, which allows us to bisect on either CodeBlock or
        CodeOrigin.

        * jit/Repatch.cpp:
        (JSC::actionForCell):
        (JSC::forceICFailure):
        (JSC::tryCacheGetByID):
        (JSC::tryCachePutByID):
        (JSC::tryRepatchIn):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::shouldJIT):
        (JSC::LLInt::jitCompileAndSetHeuristics):
        (JSC::LLInt::entryOSR):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * tests/stress/retry-cache-later.js:

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

        Implement the relational instructions for floats in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149080

        Reviewed by Geoffrey Garen.

        This patch implements the relational instructions for floats (float32)
        in WebAssembly by converting float operands to doubles and then
        comparing them using the existing double comparison instructions in the
        macro assembler.

        * tests/stress/wasm-relational.js:
        * tests/stress/wasm/relational.wasm:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildRelationalF32):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseRelationalF32ExpressionI32):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildRelationalF32):

2015-09-11  Nan Wang  <n_wang@apple.com>

        AX: ARIA 1.1 @aria-current
        https://bugs.webkit.org/show_bug.cgi?id=146012

        Reviewed by Chris Fleizach.

        Updated inspector to support aria-current.

        * inspector/protocol/DOM.json:

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

        Add initial support for floats in WebAsssembly
        https://bugs.webkit.org/show_bug.cgi?id=149062

        Reviewed by Geoffrey Garen.

        Implement the ConstantPoolIndex, Immediate, GetLocal, and GetGlobal
        instructions for floats (float32) in WebAssembly.

        * tests/stress/wasm-arithmetic-float32.js: Added.
        (shouldBe):
        * tests/stress/wasm-globals.js:
        * tests/stress/wasm-type-conversion.js:
        * tests/stress/wasm/arithmetic-float32.wasm: Added.
        * tests/stress/wasm/globals.wasm:
        * tests/stress/wasm/type-conversion.wasm:
        * wasm/WASMConstants.h:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildSetLocal):
        (JSC::WASMFunctionCompiler::buildReturn):
        (JSC::WASMFunctionCompiler::buildImmediateF32):
        (JSC::WASMFunctionCompiler::buildGetLocal):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpression):
        (JSC::WASMFunctionParser::parseExpressionF32):
        (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF32):
        (JSC::WASMFunctionParser::parseImmediateExpressionF32):
        (JSC::WASMFunctionParser::parseGetLocalExpressionF32):
        (JSC::WASMFunctionParser::parseGetGlobalExpressionF32):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildImmediateF32):
        * wasm/WASMReader.cpp:
        (JSC::WASMReader::readOpExpressionF32):
        * wasm/WASMReader.h:

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

        Try to fix the CLOOP build.

        Unreviewed.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeBaselineJITInlineCaches):
        (JSC::CodeBlock::finalizeUnconditionally):

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

        [EFL] Fix WASM build
        https://bugs.webkit.org/show_bug.cgi?id=149065

        Reviewed by Darin Adler.

        * wasm/WASMFunctionParser.cpp:

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

        JavaScriptCore should discard optimized code after some time
        https://bugs.webkit.org/show_bug.cgi?id=149048

        Reviewed by Michael Saboff.

        This patch adds a new jettison type -- JettisonDueToOldAge -- and starts
        using it for DFG and FTL code. Baseline and LLInt code will come in a
        follow-up patch.

        The primary goal is to save memory. Some popular websites leave about 10MB
        of dead code sitting around immediately after they finish loading.

        Throwing away code periodically might also save us from profiling
        pathologies that lead to performance dead ends.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitAggregate): Updated for rename, and removed a
        stale comment.

        (JSC::CodeBlock::shouldVisitStrongly): Renamed to shouldVisitStrongly
        because the practical effect of this function is to trigger a call to
        visitStrongly.

        (JSC::CodeBlock::isKnownToBeLiveDuringGC): Check the
        m_visitStronglyHasBeenCalled flag instead of
        shouldImmediatelyAssumeLivenessDuringScan / shouldVisitStrongly because
        m_visitStronglyHasBeenCalled can be set by anybody even if the CodeBlock
        would not otherwise visit itself strongly.

        (JSC::CodeBlock::shouldJettisonDueToWeakReference): New helper function
        for readability.

        (JSC::CodeBlock::shouldJettisonDueToOldAge): New helper function that
        tells if a CodeBlock is old enough for deletion.

        (JSC::CodeBlock::determineLiveness): There's no need to check
        shouldImmediatelyAssumeLivenessDuringScan here because we will not call
        this function if shouldImmediatelyAssumeLivenessDuringScan is true.
        Also, it's just not clear -- if someone chooses to call this function --
        that it would be safe to ignore them simply because
        shouldImmediatelyAssumeLivenessDuringScan was true.

        (JSC::CodeBlock::finalizeLLIntInlineCaches): Moved code out into a helper
        function to make the main function more readable.

        (JSC::CodeBlock::finalizeBaselineJITInlineCaches): Ditto.

        (JSC::CodeBlock::finalizeUnconditionally): Added code for jettisoning a
        CodeBlock if it is too old. Moved large sections of code into helper
        functions to aid readability in this function.

        (JSC::CodeBlock::jettison): Account for the fact that we might jettison
        a CodeBlock without OSR exit and without requiring a stack shoot-down.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setInstallTime):
        (JSC::CodeBlock::timeSinceInstall): Track CodeBlock age to help us
        decide when to delete.

        * jit/JITCode.h:
        (JSC::JITCode::timeToLive): Static limits on CodeBlock lifetime. I got
        these numbers from the place where numbers come from. 

        * profiler/ProfilerJettisonReason.cpp:
        (WTF::printInternal):
        * profiler/ProfilerJettisonReason.h: Updated for new jettison type.

        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::installCode): Record install time so that we
        can measure how old a CodeBlock is.

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

        [JSC] Weak should only accept cell pointees.
        <https://webkit.org/b/148955>

        Reviewed by Geoffrey Garen.

        Since WeakImpls only support pointing to JSCell derived objects,
        enforce that at compile time by having the API use JSCell* instead of JSValue.

        WeakHandleOwner callbacks now get JSCell& and JSCell*& respectively instead
        of wrapping the cell pointer in a Handle<Unknown>.

        Also added a static_assert so Weak<T> can't be instantiated with a T that's
        not convertible to JSCell.

        * API/JSAPIWrapperObject.mm:
        (JSAPIWrapperObjectHandleOwner::finalize):
        (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
        (JSC::JSAPIWrapperObject::finishCreation):
        * API/JSManagedValue.mm:
        (JSManagedValueHandleOwner::isReachableFromOpaqueRoots):
        (JSManagedValueHandleOwner::finalize):
        * builtins/BuiltinExecutables.cpp:
        (JSC::BuiltinExecutables::finalize):
        * builtins/BuiltinExecutables.h:
        * heap/Heap.cpp:
        (JSC::Heap::addFinalizer):
        (JSC::Heap::FinalizerOwner::finalize):
        * heap/Heap.h:
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::visit):
        (JSC::WeakBlock::reap):
        * heap/WeakHandleOwner.cpp:
        (JSC::WeakHandleOwner::isReachableFromOpaqueRoots):
        (JSC::WeakHandleOwner::finalize):
        * heap/WeakHandleOwner.h:
        * heap/WeakImpl.h:
        (JSC::WeakImpl::WeakImpl):
        (JSC::WeakImpl::state):
        (JSC::WeakImpl::cell):
        (JSC::WeakImpl::asWeakImpl):
        (JSC::WeakImpl::jsValue): Deleted.
        * heap/WeakInlines.h:
        (JSC::Weak<T>::Weak):
        (JSC::>):
        (JSC::Weak<T>::operator):
        (JSC::Weak<T>::get):
        (JSC::Weak<T>::was):
        * heap/WeakSet.h:
        * heap/WeakSetInlines.h:
        (JSC::WeakSet::allocate):
        (JSC::WeakBlock::finalize):
        * jit/JITThunks.cpp:
        (JSC::JITThunks::finalize):
        * jit/JITThunks.h:
        * jsc.cpp:
        (WTF::ElementHandleOwner::isReachableFromOpaqueRoots): Deleted.
        * runtime/JSCell.h:
        (JSC::jsCast):
        * runtime/RegExpCache.cpp:
        (JSC::RegExpCache::finalize):
        * runtime/RegExpCache.h:
        * runtime/Structure.cpp:
        (JSC::StructureTransitionTable::singleTransition):
        (JSC::StructureTransitionTable::setSingleTransition):

2015-09-10  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement switch statements in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149051

        Reviewed by Geoffrey Garen.

        This patch implements switch statements in WebAssembly using the
        JSC::BinarySwitch class.

        * tests/stress/wasm-control-flow.js:
        * tests/stress/wasm/control-flow.wasm:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildSwitch):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseSwitchStatement):
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildSwitch):

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

        Structure should be able to tell you if it had ever been a dictionary
        https://bugs.webkit.org/show_bug.cgi?id=149047

        Reviewed by Mark Lam.

        Introduces the hasBeenDictionary flag to Structure, which tells you if this structure or
        any of its ancestors is a dictionary. We already implicitly tracked this for DFG
        watchpoint optimizations, so this is mainly just decoupling that existing logic from
        watchpoints. Having Structure::hasBeenDictionary() enables some of the heuristics in the
        property type inference work (https://bugs.webkit.org/show_bug.cgi?id=148610).

        * runtime/Structure.cpp:
        (JSC::Structure::Structure):
        (JSC::Structure::toDictionaryTransition):
        (JSC::Structure::dump):
        * runtime/Structure.h:

2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, fix Windows file loading in JSC shell after r189583
        https://bugs.webkit.org/show_bug.cgi?id=148917

        Should load the script files with the binary mode.
        Since these loading functions are only used for the simple test scripts,
        we just use ftell / fseek now.

        * jsc.cpp:
        (fillBufferWithContentsOfFile):

2015-09-10  Michael Saboff  <msaboff@apple.com>

        REGRESSION(r189575): Appears to break ARM64 linux builds
        https://bugs.webkit.org/show_bug.cgi?id=149044

        Reviewed by Filip Pizlo.

        Changed the use of the ARM64 "fp", a register alias, to be "x29", the real register name.

        * llint/LowLevelInterpreter.asm:

2015-09-09  Filip Pizlo  <fpizlo@apple.com>

        There should be one stub hanging off an inline cache that contains code for all of the cases, rather than forming a linked list consisting of one stub per case
        https://bugs.webkit.org/show_bug.cgi?id=148717

        Reviewed by Michael Saboff.

        This is a major rewrite of the JSC get/put/in inline caches (ICs), motivated by the need to add
        fancy new kinds of inline caches for property type inference (https://webkit.org/b/148610).

        Previously, our inline caches had some problems that made them difficult to work with. It was
        impossible to change any code that was previously generated by the IC except by blowing the
        whole IC away, the ICs scaled poorly if there were many cases, and there was a lot of duplicate
        and ad hoc code.

        Impossible to regenerate a previously generated stub: Say that some access (o.f = v) causes our
        IC code to emit some stub; let's call it stub1. Then later we find that we need to emit a
        different stub, stub2, where we think that stub2 might subsume stub1. We say that stub2
        subsumes stub1 if failing to execute stub2 to completion means that we are guaranteed to fail
        to execute stub1 to completion. This could happen in trunk if stub2 has the same base structure
        as stub1 but different prototype conditions. It could happen with property type inference if
        stub2 has a looser type check on v than stub1 did. Currently, if this happened, we would emit
        stub2 and have its slow path jump to stub1. Hence, we would still end up executing the checks
        of stub1 before falling through to the slow path. This gets bad when there are many stubs.
        Stub1 might be in front of a bunch of other stubs, so when we add stub2, we will end up
        executing both stub2's and stub1's checks before falling through to the other stubs. It would
        be better if we could remove stub1 from the list at this point. But since stub1 could be linked
        to from a different stub that we had already generated, we'd have to have a way of patching
        stubs or regenerating them from scratch. This is currenty impossible because we just don't keep
        around enough meta-data to mess with a stub after it's generated. After this change, we never
        link new stubs onto a linked list of pre-existing stubs; instead each IC will have one stub
        hanging off of it and we always regenerate that one stub from scratch. That one stub contains
        either a BinarySwitch or a branch cascade to select one of the AccessCases. Each AccessCase is
        an object that describes everything we need to regenerate it in the future. This means that
        when we add a new case to an IC stub, we can figure out which previous cases this one subsumes.

        Poor scalability when there are many cases: Previously, the cases of a polymorphic inline cache
        formed a linked list of branches. This meant that the complexity of an inline cache grew
        linearly with the number of cases. This change turns this into a BinarySwitch in most cases,
        leading to logarithmic scaling.

        Duplicate code between get, put, and in: The code for op_get_by_id, op_put_by_id, and op_in
        inline caches grew independently and ended up having a lot of duplicate code. We had the worst
        kinds of duplicate code. In some cases, the code was copy-pasted. In other cases, we wrote code
        that felt like it was new despite the fact that it was logically identical to code that was
        already written elsewhere. The main sources of duplication were in selecting a scratch
        register, checking all of the ObjectPropertyConditions and the base structure, the pro forma
        involved in generating a stub, and the data structures needed to describe all of the access
        cases. This change deduplicates all of that code. Now, all of those ICs use the same classes:
        the PolymorphicAccess and AccessCase. There is code in those classes that handles all of the
        common things, and for the most part the only code that actually specializes for the kind of
        access is in some switch statement in AccessCase::generate().

        Special-casing of array length and string length: Previously, array.length and string.length
        were handled in an ad hoc manner in the get_by_id repatching code. The handling was separate
        from the polymorphic get_by_id handling, which meant that we could not handle polymorphic
        length accesses if one of the length cases was either array or string length. For example, if
        you had "o.length" where the length was either array length or a vanilla length property, then
        the get_by_id inline cache would either emit a monomorphic stub for array length, or a
        monomorphic stub for the vanilla length property, but never a polymorphic stub (or list) that
        could do both. This change addresses this problem by folding array length and string length
        into the polymorphic get_by_id code.

        This was meant to be a perf-neutral change to enable property type inference, but it ended up
        being a 1% Octane speed-up, mainly because of a 14% speed-up in raytrace. This isn't too
        surprising, since that test does use inline caches a lot and this change makes inline caches
        more scalable.

        This also fixes and adds a test for a BinarySwitch bug. BinarySwitch had an optimization for
        consecutive integer cases. Using it on typed array structures triggers this bug. It's a hard
        bug to trigger any other way because our other switch optimizations will usually use a jump
        table in case of consecutive integers.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * assembler/MacroAssemblerCodeRef.h:
        (JSC::MacroAssemblerCodePtr::dumpWithName):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printGetByIdCacheStatus):
        (JSC::CodeBlock::printPutByIdCacheStatus):
        (JSC::CodeBlock::propagateTransitions):
        (JSC::CodeBlock::getByValInfoMap):
        (JSC::CodeBlock::addStubInfo):
        (JSC::CodeBlock::findStubInfo):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::stubInfoBegin):
        (JSC::CodeBlock::stubInfoEnd):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
        * bytecode/PolymorphicAccess.cpp: Copied from Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.cpp.
        (JSC::AccessGenerationState::addWatchpoint):
        (JSC::AccessGenerationState::restoreScratch):
        (JSC::AccessGenerationState::succeed):
        (JSC::AccessCase::AccessCase):
        (JSC::AccessCase::get):
        (JSC::AccessCase::replace):
        (JSC::AccessCase::transition):
        (JSC::AccessCase::setter):
        (JSC::AccessCase::in):
        (JSC::AccessCase::getLength):
        (JSC::AccessCase::~AccessCase):
        (JSC::AccessCase::fromStructureStubInfo):
        (JSC::AccessCase::clone):
        (JSC::AccessCase::guardedByStructureCheck):
        (JSC::AccessCase::alternateBase):
        (JSC::AccessCase::canReplace):
        (JSC::AccessCase::dump):
        (JSC::AccessCase::visitWeak):
        (JSC::AccessCase::generateWithGuard):
        (JSC::AccessCase::generate):
        (JSC::PolymorphicAccess::PolymorphicAccess):
        (JSC::PolymorphicAccess::~PolymorphicAccess):
        (JSC::PolymorphicAccess::regenerateWithCases):
        (JSC::PolymorphicAccess::regenerateWithCase):
        (JSC::PolymorphicAccess::visitWeak):
        (JSC::PolymorphicAccess::dump):
        (JSC::PolymorphicAccess::regenerate):
        (WTF::printInternal):
        (JSC::GetByIdAccess::GetByIdAccess): Deleted.
        (JSC::GetByIdAccess::~GetByIdAccess): Deleted.
        (JSC::GetByIdAccess::fromStructureStubInfo): Deleted.
        (JSC::GetByIdAccess::visitWeak): Deleted.
        (JSC::PolymorphicGetByIdList::PolymorphicGetByIdList): Deleted.
        (JSC::PolymorphicGetByIdList::from): Deleted.
        (JSC::PolymorphicGetByIdList::~PolymorphicGetByIdList): Deleted.
        (JSC::PolymorphicGetByIdList::currentSlowPathTarget): Deleted.
        (JSC::PolymorphicGetByIdList::addAccess): Deleted.
        (JSC::PolymorphicGetByIdList::isFull): Deleted.
        (JSC::PolymorphicGetByIdList::isAlmostFull): Deleted.
        (JSC::PolymorphicGetByIdList::didSelfPatching): Deleted.
        (JSC::PolymorphicGetByIdList::visitWeak): Deleted.
        * bytecode/PolymorphicAccess.h: Copied from Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.h.
        (JSC::AccessCase::isGet):
        (JSC::AccessCase::isPut):
        (JSC::AccessCase::isIn):
        (JSC::AccessCase::type):
        (JSC::AccessCase::offset):
        (JSC::AccessCase::viaProxy):
        (JSC::AccessCase::structure):
        (JSC::AccessCase::newStructure):
        (JSC::AccessCase::conditionSet):
        (JSC::AccessCase::additionalSet):
        (JSC::AccessCase::customSlotBase):
        (JSC::AccessCase::doesCalls):
        (JSC::AccessCase::callLinkInfo):
        (JSC::AccessCase::RareData::RareData):
        (JSC::PolymorphicAccess::isEmpty):
        (JSC::PolymorphicAccess::size):
        (JSC::PolymorphicAccess::at):
        (JSC::PolymorphicAccess::operator[]):
        (JSC::GetByIdAccess::GetByIdAccess): Deleted.
        (JSC::GetByIdAccess::isSet): Deleted.
        (JSC::GetByIdAccess::operator!): Deleted.
        (JSC::GetByIdAccess::type): Deleted.
        (JSC::GetByIdAccess::structure): Deleted.
        (JSC::GetByIdAccess::conditionSet): Deleted.
        (JSC::GetByIdAccess::stubRoutine): Deleted.
        (JSC::GetByIdAccess::doesCalls): Deleted.
        (JSC::PolymorphicGetByIdList::isEmpty): Deleted.
        (JSC::PolymorphicGetByIdList::size): Deleted.
        (JSC::PolymorphicGetByIdList::at): Deleted.
        (JSC::PolymorphicGetByIdList::operator[]): Deleted.
        * bytecode/PolymorphicAccessStructureList.h: Removed.
        * bytecode/PolymorphicGetByIdList.cpp: Removed.
        * bytecode/PolymorphicGetByIdList.h: Removed.
        * bytecode/PolymorphicPutByIdList.cpp: Removed.
        * bytecode/PolymorphicPutByIdList.h: Removed.
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeForStubInfo):
        * bytecode/StructureStubInfo.cpp:
        (JSC::StructureStubInfo::deref):
        (JSC::StructureStubInfo::addAccessCase):
        (JSC::StructureStubInfo::reset):
        (JSC::StructureStubInfo::visitWeakReferences):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::StructureStubInfo):
        (JSC::StructureStubInfo::initGetByIdSelf):
        (JSC::StructureStubInfo::initPutByIdReplace):
        (JSC::StructureStubInfo::initStub):
        (JSC::StructureStubInfo::setSeen):
        (JSC::getStructureStubInfoCodeOrigin):
        (JSC::isGetByIdAccess): Deleted.
        (JSC::isPutByIdAccess): Deleted.
        (JSC::isInAccess): Deleted.
        (JSC::StructureStubInfo::initGetByIdList): Deleted.
        (JSC::StructureStubInfo::initPutByIdTransition): Deleted.
        (JSC::StructureStubInfo::initPutByIdList): Deleted.
        (JSC::StructureStubInfo::initInList): Deleted.
        (JSC::StructureStubInfo::addWatchpoint): Deleted.
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileIn):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::mmAllocateDataSection):
        * jit/AccessorCallJITStubRoutine.cpp: Removed.
        * jit/AccessorCallJITStubRoutine.h: Removed.
        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::branchIfEmpty):
        (JSC::AssemblyHelpers::branchStructure):
        (JSC::AssemblyHelpers::boxBooleanPayload):
        (JSC::AssemblyHelpers::boxBoolean):
        (JSC::AssemblyHelpers::boxInt32):
        * jit/BinarySwitch.cpp:
        (JSC::BinarySwitch::BinarySwitch):
        (JSC::BinarySwitch::build):
        (JSC::BinarySwitch::Case::dump):
        (JSC::BinarySwitch::BranchCode::dump):
        * jit/BinarySwitch.h:
        (JSC::BinarySwitch::Case::operator<):
        (JSC::BinarySwitch::BranchCode::BranchCode):
        * jit/JIT.h:
        * jit/JITInlineCacheGenerator.cpp:
        (JSC::garbageStubInfo):
        (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
        (JSC::JITByIdGenerator::JITByIdGenerator):
        (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
        (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
        * jit/JITInlineCacheGenerator.h:
        (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
        (JSC::JITInlineCacheGenerator::stubInfo):
        (JSC::JITByIdGenerator::JITByIdGenerator):
        (JSC::JITByIdGenerator::reportSlowPathCall):
        * jit/JITOperations.cpp:
        * jit/Repatch.cpp:
        (JSC::repatchCall):
        (JSC::repatchByIdSelfAccess):
        (JSC::resetGetByIDCheckAndLoad):
        (JSC::resetPutByIDCheckAndLoad):
        (JSC::replaceWithJump):
        (JSC::tryCacheGetByID):
        (JSC::repatchGetByID):
        (JSC::appropriateGenericPutByIdFunction):
        (JSC::appropriateOptimizingPutByIdFunction):
        (JSC::tryCachePutByID):
        (JSC::repatchPutByID):
        (JSC::tryRepatchIn):
        (JSC::repatchIn):
        (JSC::resetGetByID):
        (JSC::resetPutByID):
        (JSC::checkObjectPropertyCondition): Deleted.
        (JSC::checkObjectPropertyConditions): Deleted.
        (JSC::emitRestoreScratch): Deleted.
        (JSC::linkRestoreScratch): Deleted.
        (JSC::toString): Deleted.
        (JSC::kindFor): Deleted.
        (JSC::customFor): Deleted.
        (JSC::generateByIdStub): Deleted.
        (JSC::patchJumpToGetByIdStub): Deleted.
        (JSC::tryBuildGetByIDList): Deleted.
        (JSC::buildGetByIDList): Deleted.
        (JSC::appropriateListBuildingPutByIdFunction): Deleted.
        (JSC::emitPutReplaceStub): Deleted.
        (JSC::emitPutTransitionStub): Deleted.
        (JSC::tryBuildPutByIdList): Deleted.
        (JSC::buildPutByIdList): Deleted.
        * jit/ScratchRegisterAllocator.cpp:
        (JSC::ScratchRegisterAllocator::lock):
        (JSC::ScratchRegisterAllocator::allocateScratch):
        * jit/ScratchRegisterAllocator.h:
        (JSC::ScratchRegisterAllocator::ScratchRegisterAllocator):
        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionQuit):
        (functionAbort):
        (functionFalse1):
        (functionFalse2):
        * runtime/Options.h:
        * tests/stress/array-message-passing.js: Added.
        (window.addEventListener):
        (window.postMessage):
        (window._handleEvents):
        (testPassed):
        (testFailed):
        (classCompare):
        (bufferCompare):
        (viewCompare):
        (typedArrayCompare):
        (dataViewCompare):
        (dataViewCompare2):
        (dataViewCompare3):
        (createBuffer):
        (createTypedArray):
        (createTypedArrayOverBuffer):
        (new.DataView):
        (testList.testList.concat.basicBufferTypes.map):
        (doneTest):

2015-09-10  Geoffrey Garen  <ggaren@apple.com>

        CodeBlock::codeType() doesn't need to compute anything
        https://bugs.webkit.org/show_bug.cgi?id=149039

        Reviewed by Michael Saboff.

        CodeBlock already has an m_codeType data member.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::codeType):
        (JSC::CodeBlock::putByIdContext):

2015-09-10  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement global variables in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=149031

        Reviewed by Geoffrey Garen.

        This patch implements global variables in WebAssembly. There are two
        types of global variables in the current format that we use (the format
        used by <https://github.com/WebAssembly/polyfill-prototype-1>): internal
        global variables and imported global variables. This patch does not yet
        import values for imported global variables. It will be done in a
        subsequent patch.

        * tests/stress/wasm-globals.js: Added.
        (shouldBe):
        * tests/stress/wasm/globals.wasm: Added.
        * wasm/JSWASMModule.h:
        (JSC::JSWASMModule::globalVariables):
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildSetGlobal):
        (JSC::WASMFunctionCompiler::buildGetGlobal):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseStatement):
        (JSC::WASMFunctionParser::parseSetGlobalStatement):
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseGetGlobalExpressionI32):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseGetGlobalExpressionF64):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildSetGlobal):
        (JSC::WASMFunctionSyntaxChecker::buildGetGlobal):
        * wasm/WASMModuleParser.cpp:
        (JSC::WASMModuleParser::parseGlobalSection):

2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        Consider long module path name case in Windows
        https://bugs.webkit.org/show_bug.cgi?id=148917

        Reviewed by Alex Christensen.

        The local file system module loader in the JSC shell manages the module files by the absolute path.
        However, in Windows, _MAX_PATH is defined as 260. So if the path like the current working directory or the path to the module is long,
        it will be truncated by the API and it fail to open the file.
        In JSC tests in Apple Windows buildbot, since the current working directory is long enough, the tests failed.

        This patch introduces the following 3 tweaks.

        1. When retrieving the current working path, we use GetCurrentDirectoryW instead of _getcwd.
           GetCurrentDirectoryW allows the long path while _getcwd automatically truncate the result by the _MAX_PATH.

        2. Before opening the module file, we prepend "\\?\" to the path. It converts the local file path to the long UNC path
           which allows longer path names.

        3. Since Windows ASCII API accepts the characters in the current code page, we use the Unicode APIs like _wfopen instead.

        And enable the once disabled module tests in Windows.

        Since this functionality is the part of the JSC shell to run the module tests, it is now implemented in jsc.cpp.

        * jsc.cpp:
        (stringFromUTF):
        (jscSource):
        (extractDirectoryName):
        (currentWorkingDirectory):
        (convertShebangToJSComment):
        (fillBufferWithContentsOfFile):
        (fetchScriptFromLocalFileSystem):
        (fetchModuleFromLocalFileSystem):
        (GlobalObject::moduleLoaderFetch):
        (functionRun):
        (functionLoad):
        (functionReadFile):
        (functionCheckSyntax):
        (functionLoadModule):
        (runWithScripts):
        (runInteractive):
        * tests/modules.yaml:

2015-09-10  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Convert arguments to WebAssembly functions to the declared types
        https://bugs.webkit.org/show_bug.cgi?id=149033

        Reviewed by Geoffrey Garen.

        This patch checks the types of arguments to WebAssembly functions and
        converts them to the declared types. This is necessary because:
        - For example, if a function expects an argument of type double and we
          pass 1.0 to it, it will get a JSValue of an integer, not a double.
        - We should follow asm.js's behavior for now, because we want to be able
          to test WebAssembly apps against asm.js apps. asm.js does type
          coercion on arguments by using int|0, Math.fround(float), and +double.

        * jit/JITOperations.h:
        * tests/stress/wasm-type-conversion.js: Added.
        (shouldBe):
        (two.valueOf):
        * tests/stress/wasm/type-conversion.wasm: Added.
        * wasm/WASMFunctionCompiler.h:
        (JSC::operationConvertJSValueToInt32):
        (JSC::operationConvertJSValueToDouble):
        (JSC::WASMFunctionCompiler::startFunction):
        (JSC::WASMFunctionCompiler::appendCallSetResult):
        (JSC::WASMFunctionCompiler::callOperation):
        (JSC::WASMFunctionCompiler::loadValueAndConvertToInt32):
        (JSC::WASMFunctionCompiler::loadValueAndConvertToDouble):

2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        JSInternalPromiseDeferred should inherit JSPromiseDeferred
        https://bugs.webkit.org/show_bug.cgi?id=149027

        Reviewed by Darin Adler.

        JSInternalPromiseDeferred is constructed by using JSPromiseDeferred implementation.
        So the class info of JSInternalPromiseDeferred should inherit JSPromiseDeferred.

        * runtime/JSInternalPromiseDeferred.cpp:

2015-09-10  Michael Saboff  <msaboff@apple.com>

        Add support for Callee-Saves registers
        https://bugs.webkit.org/show_bug.cgi?id=148666

        Reviewed by Filip Pizlo.

        We save platform callee save registers right below the call frame header,
        in the location(s) starting with VirtualRegister 0.  This local space is
        allocated in the bytecode compiler.  This space is the maximum space
        needed for the callee registers that the LLInt and baseline JIT use,
        rounded up to a stack aligned number of VirtualRegisters.
        The LLInt explicitly saves and restores the registers in the macros
        preserveCalleeSavesUsedByLLInt and restoreCalleeSavesUsedByLLInt.
        The JITs saves and restores callee saves registers by what registers
        are included in m_calleeSaveRegisters in the code block.

        Added handling of callee save register restoration to exception handling.
        The basic flow is when an exception is thrown or one is recognized to
        have been generated in C++ code, we save the current state of all
        callee save registers to VM::calleeSaveRegistersBuffer.  As we unwind
        looking for the corresponding catch, we copy the callee saves from call 
        frames to the same VM::calleeSaveRegistersBuffer.  This is done for all
        call frames on the stack up to but not including the call frame that has
        the corresponding catch block.  When we process the catch, we restore
        the callee save registers with the contents of VM::calleeSaveRegistersBuffer.
        If there isn't a catch, then handleUncaughtException will restore callee
        saves before it returns back to the calling C++.

        Eliminated callee saves registers as free registers for various thunk
        generators as the callee saves may not have been saved by the function
        calling the thunk.

        Added code to transition callee saves from one VM's format to the another
        as part of OSR entry and OSR exit.

        Cleaned up the static RegisterSet's including adding one for LLInt and 
        baseline JIT callee saves and one to be used to allocate local registers
        not including the callee saves or other special registers.

        Moved ftl/FTLRegisterAtOffset.{cpp,h} to jit/RegisterAtOffset.{cpp,h}.
        Factored out the vector of RegisterAtOffsets in ftl/FTLUnwindInfo.{cpp,h}
        into a new class in jit/RegisterAtOffsetList.{cpp,h}.
        Eliminted UnwindInfo and changed UnwindInfo::parse() into a standalone
        function named parseUnwindInfo.  That standalone function now returns
        the callee saves RegisterAtOffsetList.  This is stored in the CodeBlock
        and used instead of UnwindInfo.

        Turned off register preservation thunks for outgoing calls from FTL
        generated code.  THey'll be removed in a subsequent patch.

        Changed specialized thinks to save and restore the contents of
        tagTypeNumberRegister and tagMaskRegister as they can be called by FTL
        compiled functions.  We materialize those tag registers for the thunk's
        use and then restore the prior contents on function exit.

        Also removed the arity check fail return thunk since it is now the
        caller's responsibility to restore the stack pointer.

        Removed saving of callee save registers and materialization of special
        tag registers for 64 bit platforms from vmEntryToJavaScript and
        vmEntryToNative.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * ftl/FTLJITCode.h:
        * ftl/FTLRegisterAtOffset.cpp: Removed.
        * ftl/FTLRegisterAtOffset.h: Removed.
        * ftl/FTLUnwindInfo.cpp:
        (JSC::FTL::parseUnwindInfo):
        (JSC::FTL::UnwindInfo::UnwindInfo): Deleted.
        (JSC::FTL::UnwindInfo::~UnwindInfo): Deleted.
        (JSC::FTL::UnwindInfo::parse): Deleted.
        (JSC::FTL::UnwindInfo::dump): Deleted.
        (JSC::FTL::UnwindInfo::find): Deleted.
        (JSC::FTL::UnwindInfo::indexOf): Deleted.
        * ftl/FTLUnwindInfo.h:
        (JSC::RegisterAtOffset::dump):
        * jit/RegisterAtOffset.cpp: Added.
        * jit/RegisterAtOffset.h: Added.
        (JSC::RegisterAtOffset::RegisterAtOffset):
        (JSC::RegisterAtOffset::operator!):
        (JSC::RegisterAtOffset::reg):
        (JSC::RegisterAtOffset::offset):
        (JSC::RegisterAtOffset::offsetAsIndex):
        (JSC::RegisterAtOffset::operator==):
        (JSC::RegisterAtOffset::operator<):
        (JSC::RegisterAtOffset::getReg):
        * jit/RegisterAtOffsetList.cpp: Added.
        (JSC::RegisterAtOffsetList::RegisterAtOffsetList):
        (JSC::RegisterAtOffsetList::sort):
        (JSC::RegisterAtOffsetList::dump):
        (JSC::RegisterAtOffsetList::find):
        (JSC::RegisterAtOffsetList::indexOf):
        * jit/RegisterAtOffsetList.h: Added.
        (JSC::RegisterAtOffsetList::clear):
        (JSC::RegisterAtOffsetList::size):
        (JSC::RegisterAtOffsetList::at):
        (JSC::RegisterAtOffsetList::append):
        Move and refactored use of FTLRegisterAtOffset to RegisterAtOffset.
        Added RegisterAtOffset and RegisterAtOffsetList to build configurations.
        Remove FTLRegisterAtOffset files.

        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::setUpCallFromFTL):
        Turned off FTL register preservation thunks.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::setCalleeSaveRegisters):
        (JSC::roundCalleeSaveSpaceAsVirtualRegisters):
        (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
        (JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters):
        (JSC::CodeBlock::calleeSaveRegisters):
        (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
        (JSC::CodeBlock::optimizeAfterWarmUp):
        (JSC::CodeBlock::numberOfDFGCompiles):
        Methods to manage a set of callee save registers.  Also to allocate the appropriate
        number of VirtualRegisters for callee saves.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::allocateCalleeSaveSpace):
        * bytecompiler/BytecodeGenerator.h:
        Allocate the appropriate number of VirtualRegisters for callee saves needed by LLInt or baseline JIT.

        * dfg/DFGJITCompiler.cpp:
        (JSC::DFG::JITCompiler::compileEntry):
        (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
        (JSC::DFG::JITCompiler::compileBody):
        (JSC::DFG::JITCompiler::compileExceptionHandlers):
        (JSC::DFG::JITCompiler::compile):
        (JSC::DFG::JITCompiler::compileFunction):
        * dfg/DFGJITCompiler.h:
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::operator()):
        (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer):
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::usedRegisters):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStackLayoutPhase.cpp:
        (JSC::DFG::StackLayoutPhase::run):
        * ftl/FTLCompile.cpp:
        (JSC::FTL::fixFunctionBasedOnStackMaps):
        (JSC::FTL::compile):
        * ftl/FTLLink.cpp:
        (JSC::FTL::link):
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::compileStub):
        * ftl/FTLThunks.cpp:
        (JSC::FTL::osrExitGenerationThunkGenerator):
        * jit/ArityCheckFailReturnThunks.cpp: Removed.
        * jit/ArityCheckFailReturnThunks.h: Removed.
        * jit/JIT.cpp:
        (JSC::JIT::emitEnterOptimizationCheck):
        (JSC::JIT::privateCompile):
        (JSC::JIT::privateCompileExceptionHandlers):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::emit_op_ret):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITExceptions.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_ret):
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_enter):
        (JSC::JIT::emitSlow_op_loop_hint):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_end):
        (JSC::JIT::emit_op_throw):
        (JSC::JIT::emit_op_catch):
        * jit/JITOperations.cpp:
        * jit/Repatch.cpp:
        (JSC::generateByIdStub):
        * jit/ThunkGenerators.cpp:
        * llint/LLIntData.cpp:
        (JSC::LLInt::Data::performAssertions):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        (JSC::throwExceptionFromCallSlowPathGenerator):
        (JSC::arityFixupGenerator):
        * runtime/CommonSlowPaths.cpp:
        (JSC::setupArityCheckData):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::arityCheckFor):
        Emit code to save and restore callee save registers and materialize tagTypeNumberRegister
        and tagMaskRegister.
        Handle callee saves when tiering up.
        Copy callee saves register contents to VM::calleeSaveRegistersBuffer at beginning of
        exception processing.
        Process callee save registers in frames when unwinding from an exception.
        Restore callee saves register contents from VM::calleeSaveRegistersBuffer on catch.
        Use appropriate register set to make sure we don't allocate a callee save register when
        compiling a thunk.
        Helper to populate tagTypeNumberRegister and tagMaskRegister with the appropriate
        constants.
        Removed arity fixup return thunks.

        * dfg/DFGOSREntry.cpp:
        (JSC::DFG::prepareOSREntry):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompilerCommon.cpp:
        (JSC::DFG::reifyInlinedCallFrames):
        (JSC::DFG::adjustAndJumpToTarget):
        Restore callee saves from the DFG and save the appropriate ones for the baseline JIT.
        Materialize the tag registers on 64 bit platforms.

        * jit/AssemblyHelpers.h:
        (JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
        (JSC::AssemblyHelpers::emitRestoreCalleeSavesFor):
        (JSC::AssemblyHelpers::emitSaveCalleeSaves):
        (JSC::AssemblyHelpers::emitRestoreCalleeSaves):
        (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer):
        (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer):
        (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer):
        (JSC::AssemblyHelpers::emitMaterializeTagCheckRegisters):
        New helpers to save and restore callee saves as well as materialize the tag registers
        contents.

        * jit/FPRInfo.h:
        * jit/GPRInfo.h:
        (JSC::GPRInfo::toRegister):
        Updated to include FP callee save registers.  Added number of callee saves registers and
        cleanup register aliases that collide with callee save registers.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emit_op_put_by_id):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emitGetByValWithCachedId):
        (JSC::JIT::emitPutByValWithCachedId):
        (JSC::JIT::emit_op_get_by_id):
        (JSC::JIT::emit_op_put_by_id):
        Uses new stubUnavailableRegisters register set to limit what registers are available for 
        temporaries.

        * jit/RegisterSet.cpp:
        (JSC::RegisterSet::stubUnavailableRegisters):
        (JSC::RegisterSet::calleeSaveRegisters):
        (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
        (JSC::RegisterSet::dfgCalleeSaveRegisters):
        (JSC::RegisterSet::ftlCalleeSaveRegisters):
        * jit/RegisterSet.h:
        New register sets with the callee saves used by various tiers as well as one listing registers
        not availble to stub code.

        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
        (JSC::SpecializedThunkJIT::loadDoubleArgument):
        (JSC::SpecializedThunkJIT::returnJSValue):
        (JSC::SpecializedThunkJIT::returnDouble):
        (JSC::SpecializedThunkJIT::returnInt32):
        (JSC::SpecializedThunkJIT::returnJSCell):
        (JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn):
        (JSC::SpecializedThunkJIT::emitSaveThenMaterializeTagRegisters):
        (JSC::SpecializedThunkJIT::emitRestoreSavedTagRegisters):
        (JSC::SpecializedThunkJIT::tagReturnAsInt32):
        * jit/ThunkGenerators.cpp:
        (JSC::nativeForGenerator):
        Changed to save and restore existing tag register contents as the may contain other values.
        After saving the existing values, we materialize the tag constants.

        * jit/TempRegisterSet.h:
        (JSC::TempRegisterSet::getFPRByIndex):
        (JSC::TempRegisterSet::getFreeFPR):
        (JSC::TempRegisterSet::setByIndex):
        * offlineasm/arm64.rb:
        * offlineasm/registers.rb:
        Added methods for floating point registers to support callee save FP registers.

        * jit/JITArithmetic32_64.cpp:
        (JSC::JIT::emit_op_mod):
        Removed unnecessary #if CPU(X86_64) check to this 32 bit only file.

        * offlineasm/x86.rb:
        Fixed Windows callee saves naming.

        * runtime/VM.cpp:
        (JSC::VM::VM):
        * runtime/VM.h:
        (JSC::VM::calleeSaveRegistersBufferOffset):
        (JSC::VM::getAllCalleeSaveRegistersMap):
        Provide a RegisterSaveMap that has all registers that might be saved.  Added a callee save buffer to be
        used for OSR exit and for exception processing in a future patch.

2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>

        ModuleProgramExecutable should provide CodeBlock to ScriptExecutable::forEachCodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=149028

        Reviewed by Michael Saboff.

        ModuleProgramExecutable should provide CodeBlock since ModuleProgramExecutable inherits
        ScriptExecutable.

        * bytecode/CodeBlock.h:
        (JSC::ScriptExecutable::forEachCodeBlock):

2015-09-09  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement internal calls in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=148998

        Reviewed by Filip Pizlo.

        This patch implements internal calls to functions that return a 32-bit
        integer in WebAssembly.

        * tests/stress/wasm-calls.js: Added.
        (shouldBe):
        * tests/stress/wasm/calls.wasm: Added.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::WASMFunctionCompiler):
        (JSC::WASMFunctionCompiler::endFunction):
        (JSC::WASMFunctionCompiler::buildCallInternal):
        (JSC::WASMFunctionCompiler::appendExpressionList):
        (JSC::WASMFunctionCompiler::emitNakedCall):
        (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
        (JSC::WASMFunctionCompiler::callAndUnboxResult):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::compile):
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseCallInternalExpressionI32):
        (JSC::WASMFunctionParser::parseCallArguments):
        (JSC::WASMFunctionParser::parseCallInternal):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildCallInternal):
        (JSC::WASMFunctionSyntaxChecker::appendExpressionList):

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

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

        "Caused a ~4% Speedometer regression" (Requested by cdumez on
        #webkit).

        Reverted changeset:

        "Function.prototype.bind: Bound functions must use the
        [[Prototype]] of their target function instead of
        Function.prototype"
        https://bugs.webkit.org/show_bug.cgi?id=145605
        http://trac.webkit.org/changeset/189522

2015-09-09  Geoffrey Garen  <ggaren@apple.com>

        Fix the no-DFG build.

        Unreviewed.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::visitOSRExitTargets):
        (JSC::CodeBlock::stronglyVisitStrongReferences):

2015-09-09  Geoffrey Garen  <ggaren@apple.com>

        CodeBlocks should strongly visit their OSR exit targets
        https://bugs.webkit.org/show_bug.cgi?id=148988

        Reviewed by Saam Barati.

        CodeBlocks jump to their OSR exit targets, so we need to keep them alive
        explicitly.

        This is a step toward throwing away CodeBlocks, which is only safe
        if we keep alive logically in-use CodeBlocks.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::visitStrongly): Added a flag to indicate if visit
        strongly had been performed yet, since we are likely to revisit
        the same CodeBlock many times now.

        (JSC::CodeBlock::visitOSRExitTargets):
        (JSC::CodeBlock::stronglyVisitStrongReferences): Do the visiting.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::clearMarks):
        (JSC::CodeBlockSet::mark): Added a helper function for clearing out
        two flags.

2015-09-09  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolling back in r189516.
        https://bugs.webkit.org/show_bug.cgi?id=148989

        Restored changeset:

        "GC should be able to discover new strong CodeBlock references
        during marking"
        https://bugs.webkit.org/show_bug.cgi?id=148981
        http://trac.webkit.org/changeset/189516

        This patch caused infinite recursion on Windows because of a pre-existing
        logical error in the non-parallel GC configuration. Even in non-parallel
        GC, we must set the mark bit on a CodeBlock to avoid marking it twice
        (or, in the case of our crash, infinitely recursively).

2015-09-09  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement the relational instructions for doubles in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=148999

        Reviewed by Filip Pizlo.

        Implements the relational instructions for doubles (float64) in
        WebAssembly. Also pass the values into the test functions as Mark Lam
        suggested in https://bugs.webkit.org/show_bug.cgi?id=148882#c3

        * tests/stress/wasm-relational.js:
        * tests/stress/wasm/relational.wasm:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildRelationalF64):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseRelationalF64ExpressionI32):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildRelationalI32):
        (JSC::WASMFunctionSyntaxChecker::buildRelationalF64):

2015-09-09  Saam barati  <sbarati@apple.com>

        DFG should have a debugging option that runs a phase that flushes all locals
        https://bugs.webkit.org/show_bug.cgi?id=148916

        Reviewed by Filip Pizlo.

        There is now an option to enable the DFG's new MaximalFlushInsertionPhase
        phase to run. This phase ensures that we keep all locals and arguments flushed
        to the stack at all places in the CFG. This phase is helpful for finding
        a class of bugs where enabling this phase to run removes the bug.
        This may also be useful in the development of a faster debugger
        that doesn't capture all variables.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGMaximalFlushInsertionPhase.cpp: Added.
        (JSC::DFG::MaximalFlushInsertionPhase::MaximalFlushInsertionPhase):
        (JSC::DFG::MaximalFlushInsertionPhase::run):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
        (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
        (JSC::DFG::MaximalFlushInsertionPhase::newVariableAccessData):
        (JSC::DFG::performMaximalFlushInsertion):
        * dfg/DFGMaximalFlushInsertionPhase.h: Added.
        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::compileInThreadImpl):
        * runtime/Options.cpp:
        (JSC::recomputeDependentOptions):
        * runtime/Options.h:

2015-09-08  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Refactor the test for the arithmetic instructions in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=148983

        Reviewed by Mark Lam.

        Pass the values into the test functions as Mark Lam suggested in
        https://bugs.webkit.org/show_bug.cgi?id=148882#c3

        * tests/stress/wasm-arithmetic-int32.js: Added.
        (shouldBe):
        (shouldThrow):
        * tests/stress/wasm-arithmetic.js: Removed.
        (shouldBe): Deleted.
        (shouldThrow): Deleted.
        * tests/stress/wasm/arithmetic-int32.wasm: Added.
        * tests/stress/wasm/arithmetic.wasm: Removed.

2015-09-08  Benjamin Poulain  <bpoulain@apple.com>

        [JSC] reduce the amount of memory access needed for LivenessAnalysisPhase
        https://bugs.webkit.org/show_bug.cgi?id=148414

        Reviewed by Mark Lam.

        LivenessAnalysisPhase still causes a huge number of cache miss.
        This patch reduces the amount of accesses needed by the HashTables.

        * dfg/DFGBasicBlock.h:
        * dfg/DFGLivenessAnalysisPhase.cpp:
        (JSC::DFG::LivenessAnalysisPhase::run):
        (JSC::DFG::LivenessAnalysisPhase::process):

2015-09-08  Myles C. Maxfield  <mmaxfield@apple.com>

        Prospective build fix after r189517

        Unreviewed.

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::Thread::captureStack):

2015-09-08  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unify symbolTableGet and Put in JSLexicalEnvironment and JSSymbolTableObject
        https://bugs.webkit.org/show_bug.cgi?id=148783

        Reviewed by Geoffrey Garen.

        Unify the symbolTableGet and symbolTablePut into JSSymbolTableObject's one.
        Since symbolTablePutWithAttributes in JSLexicalEnvironment is not used, we drop that function.

        * runtime/JSEnvironmentRecord.h:
        (JSC::JSEnvironmentRecord::isValidScopeOffset):
        (JSC::JSEnvironmentRecord::variableAt):
        (JSC::JSEnvironmentRecord::isValid): Deleted.
        * runtime/JSGlobalLexicalEnvironment.cpp:
        (JSC::JSGlobalLexicalEnvironment::put):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::put):
        * runtime/JSLexicalEnvironment.cpp:
        (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
        (JSC::JSLexicalEnvironment::getOwnPropertySlot):
        (JSC::JSLexicalEnvironment::put):
        (JSC::JSLexicalEnvironment::symbolTableGet): Deleted.
        (JSC::JSLexicalEnvironment::symbolTablePut): Deleted.
        (JSC::JSLexicalEnvironment::symbolTablePutWithAttributes): Deleted.
        * runtime/JSLexicalEnvironment.h:
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::instantiateDeclarations):
        * runtime/JSSegmentedVariableObject.h:
        (JSC::JSSegmentedVariableObject::isValidScopeOffset):
        * runtime/JSSymbolTableObject.h:
        (JSC::symbolTableGet):
        (JSC::symbolTablePut):
        (JSC::symbolTablePutTouchWatchpointSet):
        (JSC::symbolTablePutInvalidateWatchpointSet):
        (JSC::symbolTablePutWithAttributesTouchWatchpointSet):
        (JSC::symbolTablePutWithAttributes): Deleted.

2015-09-08  Commit Queue  <commit-queue@webkit.org>

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

        broke tests on windows (Requested by alexchristensen on
        #webkit).

        Reverted changeset:

        "GC should be able to discover new strong CodeBlock references
        during marking"
        https://bugs.webkit.org/show_bug.cgi?id=148981
        http://trac.webkit.org/changeset/189516

2015-09-08  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Remove unused DFG::dfgConvertJSValueToInt32()
        https://bugs.webkit.org/show_bug.cgi?id=148986

        Reviewed by Geoffrey Garen.

        Remove unused DFG::dfgConvertJSValueToInt32() and also remove
        DFG::JITCompiler::callOperation(D_JITOperation_EJ operation, ...) which
        was introduced in Bug 69806 for dfgConvertJSValueToNumber() and is no
        longer used.

        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation): Deleted.

2015-09-08  Matthew Hill  <matthew.jh@outlook.com>

        Function.prototype.bind: Bound functions must use the [[Prototype]] of their target function instead of Function.prototype
        https://bugs.webkit.org/show_bug.cgi?id=145605

        Reviewed by Geoffrey Garen.

        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::create):
        * tests/es6.yaml:

2015-09-08  Mark Lam  <mark.lam@apple.com>

        Fixed a bad comment r189517.

        Not reviewed.

        * heap/MachineStackMarker.cpp:
        (JSC::osRedZoneAdjustment):

2015-09-08  Geoffrey Garen  <ggaren@apple.com>

        InlineCallFrames shouldn't be strongly marked by CodeBlock
        https://bugs.webkit.org/show_bug.cgi?id=146613

        Reviewed by Saam Barati.

        This code was vestigial an unnecessary, so I removed it.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        * bytecode/InlineCallFrame.cpp:
        (JSC::InlineCallFrame::calleeConstant):
        (JSC::InlineCallFrame::calleeForCallFrame):
        (JSC::InlineCallFrame::visitAggregate): Deleted.
        * bytecode/InlineCallFrame.h:
        (JSC::InlineCallFrame::specializationKind):
        * bytecode/InlineCallFrameSet.cpp:
        (JSC::InlineCallFrameSet::add):
        (JSC::InlineCallFrameSet::visitAggregate): Deleted.
        * bytecode/InlineCallFrameSet.h:
        (JSC::InlineCallFrameSet::begin):
        (JSC::InlineCallFrameSet::end):

2015-09-08  Mark Lam  <mark.lam@apple.com>

        GC stack scan should include ABI red zone.
        https://bugs.webkit.org/show_bug.cgi?id=148976

        Reviewed by Geoffrey Garen and Benjamin Poulain.

        The x86_64 ABI section 3.2.2[1] and ARM64 ABI[2] both state that there is a
        128 byte red zone below the stack pointer (reserved by the OS), and that
        "functions may use this area for temporary data that is not needed across
        function calls".

        Hence, it is possible for a thread to store JSCell pointers in the red zone
        area, and the conservative GC thread scanner needs to scan that area as well.

        Note: the red zone should not be scanned for the GC thread itself (in
        gatherFromCurrentThread()).  This because we're guaranteed that there will
        be GC frames below the lowest (top of stack) frame that we need to scan.
        Hence, we are guaranteed that there are no red zone areas there containing
        JSObject pointers of relevance.

        No test added for this issue because the issue relies on:
        1. the compiler tool chain generating code that stores local variables
           containing the sole reference to a JS object (that needs to be kept
           alive) in the stack red zone, and
        2. GC has to run on another thread while that red zone containing the
           JS object reference is in use. 

        These conditions require a race that cannot be reliably reproduced.

        [1]: http://people.freebsd.org/~obrien/amd64-elf-abi.pdf
        [2]: https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html#//apple_ref/doc/uid/TP40013702-SW7

        * heap/MachineStackMarker.cpp:
        (JSC::MachineThreads::Thread::Thread):
        (JSC::MachineThreads::Thread::createForCurrentThread):
        (JSC::MachineThreads::Thread::freeRegisters):
        (JSC::osRedZoneAdjustment):
        (JSC::MachineThreads::Thread::captureStack):

2015-09-08  Geoffrey Garen  <ggaren@apple.com>

        GC should be able to discover new strong CodeBlock references during marking
        https://bugs.webkit.org/show_bug.cgi?id=148981

        Reviewed by Mark Lam.

        Previously, we required a strong reference to register itself before the
        first visit to a CodeBlock. Now, we can discover a strong reference at
        any time during the marking phase.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock): Remove the two strong reference state
        variables from CodeBlock. Now, a strong reference immediately marks
        the CodeBlock and its references at the moment of its discovery, and no
        separate state is required.

        (JSC::CodeBlock::visitStrongly): New helper function for establishing
        a strong reference to a CodeBlock.

        (JSC::CodeBlock::visitAggregate): Adopt helper function above.

        (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan): Updated
        for state removal.

        (JSC::CodeBlock::isKnownToBeLiveDuringGC): Ditto.

        (JSC::CodeBlock::stronglyVisitWeakReferences): Be sure to record that
        we have proven liveness (by virtue of marking all the references the
        proof would check). This is required so that the CodeBlock knows itself
        to be live, and it is also an optimization to avoid testing weak references
        after we have already visited them.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::clearMarks):
        (JSC::CodeBlockSet::mark):
        (JSC::CodeBlockSet::clearMarks): Deleted. Updated for state removal.

        * dfg/DFGPlan.cpp:
        (JSC::DFG::Plan::clearCodeBlockMarks):
        (JSC::DFG::Plan::checkLivenessAndVisitChildren):
        * dfg/DFGPlan.h: No need to use a CodeBlockSet in order to mark anymore.

        * dfg/DFGWorklist.cpp:
        (JSC::DFG::Worklist::completeAllPlansForVM):
        (JSC::DFG::Worklist::clearCodeBlockMarks):
        (JSC::DFG::Worklist::resumeAllThreads):
        (JSC::DFG::Worklist::visitWeakReferences):
        (JSC::DFG::completeAllPlansForVM):
        (JSC::DFG::clearCodeBlockMarks):
        * dfg/DFGWorklist.h:
        (JSC::DFG::worklistForIndexOrNull): No need to use a CodeBlockSet in order
        to mark anymore.

        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::clearMarksForFullCollection):
        (JSC::CodeBlockSet::clearMarksForEdenCollection):
        (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
        (JSC::CodeBlockSet::traceMarked):
        (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
        (JSC::CodeBlockSet::dump):
        * heap/CodeBlockSet.h: Keep the currently executing CodeBlocks in RefPtrs
        since we can no longer rely on the m_currentlyExecuting bit to keep them
        alive. (A currently executing CodeBlock may not be referenced by its
        Executable because it may since have been replaced by another CodeBlock.
        This is common in the cases of OSR entry and exit.)

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::visitCompilerWorklistWeakReferences):
        (JSC::Heap::visitWeakHandles): No need to trace the list of CodeBlocks
        on the stack in the weak reference fixpoint because we no longer overload
        "on the stack" to include CodeBlocks referenced by the compiler.

2015-09-08  Andreas Kling  <akling@apple.com>

        [JSC] Remove unused Heap::getConservativeRegisterRoots().
        <https://webkit.org/b/148974>

        Reviewed by Geoffrey Garen.

        Spotted this unused stack root gathering helper in Heap. Let's lose it.

        * heap/Heap.cpp:
        (JSC::Heap::getConservativeRegisterRoots): Deleted.
        * interpreter/JSStack.cpp:
        (JSC::JSStack::gatherConservativeRoots): Deleted.
        * interpreter/JSStack.h:
        (JSC::JSStack::gatherConservativeRoots): Deleted.

2015-09-08  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement control flow statements in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=148934

        Reviewed by Geoffrey Garen.

        This patch implements if, while, do, label, break, and continue
        statements in WebAssembly. Switches will be implemented in a subsequent
        patch.

        * tests/stress/wasm-control-flow.js: Added.
        (shouldBe):
        * tests/stress/wasm/control-flow.wasm: Added.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::linkTarget):
        (JSC::WASMFunctionCompiler::jumpToTarget):
        (JSC::WASMFunctionCompiler::jumpToTargetIf):
        (JSC::WASMFunctionCompiler::startLoop):
        (JSC::WASMFunctionCompiler::endLoop):
        (JSC::WASMFunctionCompiler::startSwitch):
        (JSC::WASMFunctionCompiler::endSwitch):
        (JSC::WASMFunctionCompiler::startLabel):
        (JSC::WASMFunctionCompiler::endLabel):
        (JSC::WASMFunctionCompiler::breakTarget):
        (JSC::WASMFunctionCompiler::continueTarget):
        (JSC::WASMFunctionCompiler::breakLabelTarget):
        (JSC::WASMFunctionCompiler::continueLabelTarget):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseIfStatement):
        (JSC::WASMFunctionParser::parseIfElseStatement):
        (JSC::WASMFunctionParser::parseWhileStatement):
        (JSC::WASMFunctionParser::parseDoStatement):
        (JSC::WASMFunctionParser::parseLabelStatement):
        (JSC::WASMFunctionParser::parseBreakStatement):
        (JSC::WASMFunctionParser::parseBreakLabelStatement):
        (JSC::WASMFunctionParser::parseContinueStatement):
        (JSC::WASMFunctionParser::parseContinueLabelStatement):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::linkTarget):
        (JSC::WASMFunctionSyntaxChecker::jumpToTarget):
        (JSC::WASMFunctionSyntaxChecker::jumpToTargetIf):
        (JSC::WASMFunctionSyntaxChecker::startLoop):
        (JSC::WASMFunctionSyntaxChecker::endLoop):
        (JSC::WASMFunctionSyntaxChecker::startSwitch):
        (JSC::WASMFunctionSyntaxChecker::endSwitch):
        (JSC::WASMFunctionSyntaxChecker::startLabel):
        (JSC::WASMFunctionSyntaxChecker::endLabel):
        (JSC::WASMFunctionSyntaxChecker::breakTarget):
        (JSC::WASMFunctionSyntaxChecker::continueTarget):
        (JSC::WASMFunctionSyntaxChecker::breakLabelTarget):
        (JSC::WASMFunctionSyntaxChecker::continueLabelTarget):

2015-09-08  Per Arne Vollan  <peavo@outlook.com>

        [Win] Compile errors in inspector code.
        https://bugs.webkit.org/show_bug.cgi?id=148977

        Reviewed by Alex Christensen.

        Include definition of class FrontendRouter before use.

        * inspector/InspectorBackendDispatcher.h:
        * inspector/JSGlobalObjectInspectorController.h:

2015-09-08  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement computed accessors
        https://bugs.webkit.org/show_bug.cgi?id=147883

        Reviewed by Geoffrey Garen.

        Patch by Yusuke Suzuki <utatane.tea@gmail.com> and Matthew Mirman <mmirman@apple.com>.

        Implement the computed accessors functionality for class syntax and object literal syntax.
        Added new opcodes, op_put_getter_by_val and op_put_setter_by_val. LLInt and baseline JIT support them.
        As the same to the other accessor opcodes (like op_put_getter_by_id etc.), DFG / FTL does not support
        them. This is handled here[1].

        [1]: https://bugs.webkit.org/show_bug.cgi?id=148860

        * bytecode/BytecodeList.json:
        * bytecode/BytecodeUseDef.h:
        (JSC::computeUsesForBytecodeOffset):
        (JSC::computeDefsForBytecodeOffset):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitPutGetterByVal):
        (JSC::BytecodeGenerator::emitPutSetterByVal):
        * bytecompiler/BytecodeGenerator.h:
        * bytecompiler/NodesCodegen.cpp:
        (JSC::PropertyListNode::emitBytecode):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        * jit/JIT.h:
        * jit/JITInlines.h:
        (JSC::JIT::callOperation):
        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_getter_by_val):
        (JSC::JIT::emit_op_put_setter_by_val):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_getter_by_val):
        (JSC::JIT::emit_op_put_setter_by_val):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        * llint/LowLevelInterpreter.asm:
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseClass):
        (JSC::Parser<LexerType>::parseGetterSetter):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::createGetterOrSetterProperty):
        * tests/es6.yaml:
        * tests/stress/computed-accessor-parsing.js: Added.
        (testShouldNotThrow):
        (testShouldThrow):
        (Val.prototype.get string_appeared_here):
        (Val):
        * tests/stress/computed-accessor.js: Added.
        (shouldBe):
        (.):
        * tests/stress/duplicate-computed-accessors.js: Added.
        (shouldBe):

2015-09-08  Saam barati  <sbarati@apple.com>

        baseline JIT should emit better code for UnresolvedProperty in resolve_scope/get_from_scope/put_to_scope
        https://bugs.webkit.org/show_bug.cgi?id=148895

        Reviewed by Geoffrey Garen.

        Previously, if a resolve_scope/get_from_scope/put_to_scope with
        UnresolvedProperty made it to the baseline JIT, we would hard compile
        a jump to the slow path. This is bad and slow. Because UnresolvedProperty
        tries to update itself to something more useful, and succeeds at doing so
        with high probability, we should be emitting code that checks to see if the 
        slow path has performed an update, and if it has, execute more efficient code 
        and not go to the slow path (unless it needs to for var injection check failure, 
        or other check failures). This increases the speed of this code greatly because 
        we may decide to compile a program/function before certain resolve_scope/get_from_scope/put_to_scope 
        operations ever execute. And now, the baseline JIT code better adapts to such
        compilation scenarios.

        * bytecode/Watchpoint.h:
        (JSC::WatchpointSet::isBeingWatched):
        (JSC::WatchpointSet::addressOfState):
        (JSC::WatchpointSet::offsetOfState):
        (JSC::WatchpointSet::addressOfSetIsNotEmpty):
        * jit/JIT.cpp:
        (JSC::JIT::emitNotifyWrite):
        (JSC::JIT::assertStackPointerOffset):
        * jit/JIT.h:
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emitSlow_op_resolve_scope):
        (JSC::JIT::emitGetGlobalProperty):
        (JSC::JIT::emitGetVarFromPointer):
        (JSC::JIT::emitGetVarFromIndirectPointer):
        (JSC::JIT::emitGetClosureVar):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emitPutGlobalProperty):
        (JSC::JIT::emitPutGlobalVariable):
        (JSC::JIT::emitPutGlobalVariableIndirect):
        (JSC::JIT::emitPutClosureVar):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_resolve_scope):
        (JSC::JIT::emitSlow_op_resolve_scope):
        (JSC::JIT::emitGetGlobalProperty):
        (JSC::JIT::emitGetVarFromPointer):
        (JSC::JIT::emitGetVarFromIndirectPointer):
        (JSC::JIT::emitGetClosureVar):
        (JSC::JIT::emit_op_get_from_scope):
        (JSC::JIT::emitSlow_op_get_from_scope):
        (JSC::JIT::emitPutGlobalProperty):
        (JSC::JIT::emitPutGlobalVariable):
        (JSC::JIT::emitPutGlobalVariableIndirect):
        (JSC::JIT::emitPutClosureVar):
        (JSC::JIT::emit_op_put_to_scope):
        (JSC::JIT::emitSlow_op_put_to_scope):
        * runtime/CommonSlowPaths.h:
        (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
        (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
        * runtime/JSScope.cpp:
        (JSC::abstractAccess):
        * tests/stress/multiple-files-tests/global-lexical-variable-unresolved-property/first.js:
        (foo):

2015-09-08  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement all the arithmetic and logical instructions in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=148882

        Reviewed by Mark Lam.

        This patch implements all the arithmetic and logical instructions for
        32-bit integers in WebAssembly.

        * tests/stress/wasm-arithmetic.js:
        * tests/stress/wasm/arithmetic.wasm:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildUnaryI32):
        (JSC::WASMFunctionCompiler::buildBinaryI32):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseUnaryExpressionI32):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildUnaryI32):

2015-09-08  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix debug by removing an assertion that is not correct anymore.

        * jit/Repatch.cpp:
        (JSC::linkFor):

2015-09-08  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Add initial support for doubles in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=148913

        Reviewed by Filip Pizlo.

        Implement the ConstantPoolIndex, Immediate, and GetLocal instructions
        for doubles (float64) in WebAssembly.

        * tests/stress/wasm-arithmetic-float64.js: Added.
        (shouldBe):
        * tests/stress/wasm/arithmetic-float64.wasm: Added.
        * wasm/WASMConstants.h:
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildSetLocal):
        (JSC::WASMFunctionCompiler::buildReturn):
        (JSC::WASMFunctionCompiler::buildImmediateI32):
        (JSC::WASMFunctionCompiler::buildImmediateF64):
        (JSC::WASMFunctionCompiler::buildGetLocal):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpression):
        (JSC::WASMFunctionParser::parseExpressionF64):
        (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF64):
        (JSC::WASMFunctionParser::parseImmediateExpressionF64):
        (JSC::WASMFunctionParser::parseGetLocalExpressionF64):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildImmediateF64):
        * wasm/WASMReader.cpp:
        (JSC::WASMReader::readOpExpressionF64):
        * wasm/WASMReader.h:

2015-09-06  Filip Pizlo  <fpizlo@apple.com>

        CallLinkInfo inside StructureStubInfo should not use polymorphic stubs
        https://bugs.webkit.org/show_bug.cgi?id=148915

        Reviewed by Mark Lam.

        There is a subtle bug where if we reset a get_by_id IC that had a getter stub that in
        turn had a polymorphic call stub, then the GC won't know to keep the getter stub alive.
        This patch documents the bug in a FIXME and disables polymorphic call optimizations for
        getters. It also just so happens that the polymorphic call optimizations usually don't
        benefit getters, since it's hard to create polymorphism at the point of call without also
        introducing polymorphism in the base object's structure.

        The added test doesn't reproduce the problem, because it's hard to get the GC to delete
        all of the stubs.

        * bytecode/CallLinkInfo.h:
        (JSC::CallLinkInfo::CallLinkInfo):
        (JSC::CallLinkInfo::setCallLocations):
        (JSC::CallLinkInfo::allowStubs):
        (JSC::CallLinkInfo::disallowStubs):
        (JSC::CallLinkInfo::setUpCallFromFTL):
        * jit/Repatch.cpp:
        (JSC::generateByIdStub):
        (JSC::linkFor):
        (JSC::linkPolymorphicCall):
        * tests/stress/poly-call-stub-in-getter-stub.js: Added.
        (foo):
        (makeGetter):

2015-09-07  Filip Pizlo  <fpizlo@apple.com>

        The put_by_id IC store barrier contract should benefit transition over replace
        https://bugs.webkit.org/show_bug.cgi?id=148943

        Reviewed by Mark Lam.

        Previously, we would only emit a barrier if the value being stored was possibly a cell, so
        the transition stub code generator would have to emit a barrier for the store of the
        structure, just in case the structure was newer than the base object.

        This changes the contract so that the put_by_id callsite would always have a barrier on the
        base (except if it proved that the base was brand new). That way, the transition doesn't have
        to have a barrier unless it allocates.

        This is meant to be a perf-neutral change that I need for the IC refactoring in
        https://bugs.webkit.org/show_bug.cgi?id=148717.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGStoreBarrierInsertionPhase.cpp:
        * jit/Repatch.cpp:
        (JSC::emitPutTransitionStub):

2015-09-07  Alex Christensen  <achristensen@webkit.org>

        Windows non-cygwin build fix after r189333.

        SVN on Windows (non-cygwin) doesn't like having the * character in file names.
        I replaced "*" with "star" in some of Geoff's new tests.

        * tests/es6.yaml:
        Changed all _*_ to _star_
        * tests/es6/generators_yield_*_arrays.js: Removed.
        * tests/es6/generators_yield_*_astral_plane_strings.js: Removed.
        * tests/es6/generators_yield_*_generator_instances.js: Removed.
        * tests/es6/generators_yield_*_generic_iterables.js: Removed.
        * tests/es6/generators_yield_*_instances_of_iterables.js: Removed.
        * tests/es6/generators_yield_*_iterator_closing.js: Removed.
        * tests/es6/generators_yield_*_iterator_closing_via_throw.js: Removed.
        * tests/es6/generators_yield_*_on_non-iterables_is_a_runtime_error.js: Removed.
        * tests/es6/generators_yield_*_sparse_arrays.js: Removed.
        * tests/es6/generators_yield_*_strings.js: Removed.
        * tests/es6/generators_yield_star_arrays.js: Copied from tests/es6/generators_yield_*_arrays.js.
        * tests/es6/generators_yield_star_astral_plane_strings.js: Copied from tests/es6/generators_yield_*_astral_plane_strings.js.
        * tests/es6/generators_yield_star_generator_instances.js: Copied from tests/es6/generators_yield_*_generator_instances.js.
        * tests/es6/generators_yield_star_generic_iterables.js: Copied from tests/es6/generators_yield_*_generic_iterables.js.
        * tests/es6/generators_yield_star_instances_of_iterables.js: Copied from tests/es6/generators_yield_*_instances_of_iterables.js.
        * tests/es6/generators_yield_star_iterator_closing.js: Copied from tests/es6/generators_yield_*_iterator_closing.js.
        * tests/es6/generators_yield_star_iterator_closing_via_throw.js: Copied from tests/es6/generators_yield_*_iterator_closing_via_throw.js.
        * tests/es6/generators_yield_star_on_non-iterables_is_a_runtime_error.js: Copied from tests/es6/generators_yield_*_on_non-iterables_is_a_runtime_error.js.
        * tests/es6/generators_yield_star_sparse_arrays.js: Copied from tests/es6/generators_yield_*_sparse_arrays.js.
        * tests/es6/generators_yield_star_strings.js: Copied from tests/es6/generators_yield_*_strings.js.

2015-09-06  Mark Lam  <mark.lam@apple.com>

        Gardening: fix broken Windows build after r189454.

        Not reviewed.

        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
        * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:

2015-09-06  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement the relational instructions in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=148838

        Reviewed by Saam Barati.

        This patch implements the relational instructions for 32-bit integers in
        WebAssembly.

        * tests/stress/wasm-arithmetic.js:
        * tests/stress/wasm-locals.js:
        * tests/stress/wasm-relational.js: Added.
        (shouldBe):
        * tests/stress/wasm/arithmetic.wasm: Renamed from Source/JavaScriptCore/tests/stress/wasm-arithmetic.wasm.
        * tests/stress/wasm/locals.wasm: Renamed from Source/JavaScriptCore/tests/stress/wasm-locals.wasm.
        * tests/stress/wasm/relational.wasm: Added.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildRelationalI32):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseRelationalI32ExpressionI32):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildRelationalI32):

2015-09-06  Mark Lam  <mark.lam@apple.com>

        StackOverflow stack unwinding should stop at native frames.
        https://bugs.webkit.org/show_bug.cgi?id=148749

        Reviewed by Michael Saboff.

        In the present code, after ping-pong'ing back and forth between native and JS
        code a few times, if we have a stack overflow on re-entry into the VM to run
        JS code's whose stack frame would overflow the JS stack, the code will end up
        unwinding past the native function that is making the call to re-enter the VM.
        As a result, any clean up code (e.g. destructors for stack variables) in the
        skipped native function frame (and its chain of native function callers) will
        not be called.

        This patch is based on the Michael Saboff's fix of this issue landed on the
        jsc-tailcall branch: http://trac.webkit.org/changeset/188555

        We now check for the case where there are no JS frames to unwind since the
        last native frame, and treat the exception as an unhandled exception.  The
        native function is responsible for further propagating the exception if needed.

        Other supporting work:
        1. Remove vm->vmEntryFrameForThrow.  It should always be the same as
           vm->topVMEntryFrame.
        2. Change operationThrowStackOverflowError() to use the throwStackOverflowError()
           helper function instead of rolling its own.
        3. Added a test that exercises this edge case.  The test should not hang or crash.

        * API/tests/PingPongStackOverflowTest.cpp: Added.
        (PingPongStackOverflowObject_hasInstance):
        (testPingPongStackOverflow):
        * API/tests/PingPongStackOverflowTest.h: Added.
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/CallFrame.h:
        (JSC::ExecState::operator=):
        (JSC::ExecState::callerFrame):
        (JSC::ExecState::callerFrameOrVMEntryFrame):
        (JSC::ExecState::argIndexForRegister):
        (JSC::ExecState::callerFrameAndPC):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::UnwindFunctor):
        (JSC::UnwindFunctor::operator()):
        (JSC::Interpreter::unwind):
        * interpreter/Interpreter.h:
        (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
        (JSC::Interpreter::sampler):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::jumpToExceptionHandler):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITExceptions.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOperations.cpp:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/VM.h:
        (JSC::VM::exceptionOffset):
        (JSC::VM::callFrameForThrowOffset):
        (JSC::VM::vmEntryFrameForThrowOffset): Deleted.
        (JSC::VM::topVMEntryFrameOffset): Deleted.

2015-09-06  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, disable module tests in Windows until name resolution is fixed
        https://bugs.webkit.org/show_bug.cgi?id=148689

        Until bug[1] is fixed, we disable the module tests.
        Since the local file system name resolution is just implemented in jsc.cpp and
        is intended to be used for the module tests, it does not affect JSC framework
        and WebKit itself.

        [1]: https://bugs.webkit.org/show_bug.cgi?id=148917

        * tests/modules.yaml:

2015-09-06  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Simplify JIT::emit_op_mod()
        https://bugs.webkit.org/show_bug.cgi?id=148908

        Reviewed by Michael Saboff.

        The IDIV instruction on x86 divides the value in the EDX:EAX registers
        by the source operand and stores the quotient in EAX and the remainder
        in EDX. Therefore, we store the values that we don't want to be
        overwritten by IDIV in registers that are not EAX or EDX. This patch
        makes the intention clearer and makes the code easier to read.

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

2015-09-05  Mark Lam  <mark.lam@apple.com>

        Fix JSDollarVMPrototype after r189160.
        https://bugs.webkit.org/show_bug.cgi?id=148900

        Reviewed by Michael Saboff.

        JSDollarVMPrototype needs to be updated to match http://trac.webkit.org/changeset/189160 i.e.
        remove the use of JSC::Function bit in its property attributes.

        * tools/JSDollarVMPrototype.cpp:
        (JSC::JSDollarVMPrototype::finishCreation):

2015-09-05  Yusuke Suzuki  <utatane.tea@gmail.com>

        Unreviewed, fix the module name resolution in Windows
        https://bugs.webkit.org/show_bug.cgi?id=148689

        Attempt to fix the module name resolution in Windows.
        A module name is represented as the UNIX path under the current module tests.
        This fix split the module name with '/' instead of pathSeparator().

        This is only utilized by the jsc.cpp for the local module tests.
        So, WebKit production and JavaScriptCore framework are not affected by this change.

        * jsc.cpp:
        (ModuleName::startsWithRoot):
        (ModuleName::ModuleName):
        (resolvePath):
        (GlobalObject::moduleLoaderResolve):

2015-09-05  Brian Burg  <bburg@apple.com>

        Web Inspector: tighten up lifetimes for Agent-owned objects, and initialize agents using contexts
        https://bugs.webkit.org/show_bug.cgi?id=148625

        Reviewed by Joseph Pecoraro.

        All agents own their domain-specific frontend and backend dispatchers. Change so that
        they are initialized in constructors rather than when a frontend connects or disconnects.
        This may cause additional memory use, but this can be counteracted by lazily creating
        some agents that are not required for other agents to function (i.e., runtime and page agents).

        To avoid adding frontend/backend dispatcher arguments to every single agent constructor,
        change agent construction to take a AgentContext or a subclass of it. This provides agents with
        references to objects in the owning InspectorEnvironment subclass that are guaranteed to
        outlive all agents. AgentContext and its subclasses follow the existing Agent class hierarchy.

        * inspector/InspectorAgentBase.h:
        (Inspector::JSAgentContext::JSAgentContext):
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
        (Inspector::JSGlobalObjectInspectorController::disconnectAllFrontends):
        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::InspectorAgent):
        (Inspector::InspectorAgent::didCreateFrontendAndBackend):
        (Inspector::InspectorAgent::willDestroyFrontendAndBackend):
        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
        (Inspector::InspectorConsoleAgent::didCreateFrontendAndBackend):
        (Inspector::InspectorConsoleAgent::willDestroyFrontendAndBackend):
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
        (Inspector::InspectorDebuggerAgent::didCreateFrontendAndBackend):
        (Inspector::InspectorDebuggerAgent::willDestroyFrontendAndBackend):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        (Inspector::InspectorRuntimeAgent::InspectorRuntimeAgent):
        * inspector/agents/InspectorRuntimeAgent.h:
        * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
        (Inspector::JSGlobalObjectConsoleAgent::JSGlobalObjectConsoleAgent):
        * inspector/agents/JSGlobalObjectConsoleAgent.h:
        * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
        (Inspector::JSGlobalObjectDebuggerAgent::JSGlobalObjectDebuggerAgent):
        * inspector/agents/JSGlobalObjectDebuggerAgent.h:
        * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
        (Inspector::JSGlobalObjectRuntimeAgent::JSGlobalObjectRuntimeAgent):
        (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend):
        * inspector/agents/JSGlobalObjectRuntimeAgent.h:
        * inspector/augmentable/AlternateDispatchableAgent.h:
        * inspector/augmentable/AugmentableInspectorController.h: Alternate agents should
        have access to frontend router and backend dispatcher at construction time.
        
        * inspector/scripts/codegen/cpp_generator_templates.py:
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
        * inspector/scripts/codegen/objc_generator_templates.py:

2015-09-04  Brian Burg  <bburg@apple.com>

        Web Inspector: agents should send messages through FrontendRouter instead of FrontendChannel
        https://bugs.webkit.org/show_bug.cgi?id=148492

        Reviewed by Joseph Pecoraro.

        Replace uses of FrontendChannel with FrontendRouter. Minor cleanups along the way.  

        Make AgentRegistry automatically signal discardAgent() in its destructor, since it always
        gets executed in the owning controller's destructor anyway.

        * inspector/InspectorAgentBase.h:
        * inspector/InspectorAgentRegistry.cpp:
        (Inspector::AgentRegistry::~AgentRegistry):
        (Inspector::AgentRegistry::didCreateFrontendAndBackend):
        (Inspector::AgentRegistry::willDestroyFrontendAndBackend):
        (Inspector::AgentRegistry::discardAgents): Deleted.
        * inspector/InspectorAgentRegistry.h:
        * inspector/InspectorBackendDispatcher.cpp:
        * inspector/InspectorFrontendRouter.cpp:
        (Inspector::FrontendRouter::leakChannel): Deleted, no longer necessary.
        * inspector/InspectorFrontendRouter.h:
        * inspector/JSGlobalObjectInspectorController.cpp:
        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
        (Inspector::JSGlobalObjectInspectorController::~JSGlobalObjectInspectorController):
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/agents/InspectorAgent.cpp:
        (Inspector::InspectorAgent::didCreateFrontendAndBackend):
        * inspector/agents/InspectorAgent.h:
        * inspector/agents/InspectorConsoleAgent.cpp:
        (Inspector::InspectorConsoleAgent::didCreateFrontendAndBackend):
        * inspector/agents/InspectorConsoleAgent.h:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        (Inspector::InspectorDebuggerAgent::didCreateFrontendAndBackend):
        * inspector/agents/InspectorDebuggerAgent.h:
        * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
        (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend):
        * inspector/agents/JSGlobalObjectRuntimeAgent.h:
        * inspector/augmentable/AlternateDispatchableAgent.h:
        * inspector/remote/RemoteInspectorDebuggable.cpp:
        * inspector/scripts/codegen/cpp_generator_templates.py:
        * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
        (CppBackendDispatcherImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
        (CppFrontendDispatcherHeaderGenerator.generate_output.FrontendRouter):
        (CppFrontendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
        (CppFrontendDispatcherImplementationGenerator.generate_output):
        (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
        * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
        (ObjCConfigurationImplementationGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator.generate_output):

2015-09-05  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Enable ES6 Module in JSC shell by default
        https://bugs.webkit.org/show_bug.cgi?id=148689

        Reviewed by Geoffrey Garen.

        Enable ES6 Modules in JSC shell by default. Compile time flag is left for WebCore.
        Since the entry point to evaluate the modules are completely separated from the usual
        entry point to evaluate the script, we can safely enable ES6 modules in JSC shell.

        And add bunch of tests for ES6 Modules.

        * jsc.cpp:
        (GlobalObject::finishCreation):
        (functionLoadModule):
        (runWithScripts):
        (printUsageStatement): Deleted.
        (CommandLine::parseArguments): Deleted.
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseInner): Deleted.
        * tests/modules.yaml: Added.
        * tests/modules/aliasing.js: Added.
        * tests/modules/aliasing/drink-2.js: Added.
        (export.let.Cappuccino.string_appeared_here.export.changeCappuccino):
        * tests/modules/aliasing/drink.js: Added.
        (export.changeCocoa):
        * tests/modules/cyclic-may-produce-tdz.js: Added.
        * tests/modules/cyclic-may-produce-tdz/1.js: Added.
        * tests/modules/cyclic-may-produce-tdz/2.js: Added.
        * tests/modules/default-error/main.js: Added.
        * tests/modules/default-value-case-should-be-copied.js: Added.
        * tests/modules/default-value-case-should-be-copied/module.js: Added.
        (export.changeValue):
        * tests/modules/defaults.js: Added.
        * tests/modules/defaults/Cappuccino.js: Added.
        * tests/modules/defaults/Cocoa.js: Added.
        (export.default.Cocoa):
        * tests/modules/defaults/Matcha.js: Added.
        * tests/modules/destructuring-export.js: Added.
        * tests/modules/destructuring-export/array.js: Added.
        * tests/modules/destructuring-export/main.js: Added.
        * tests/modules/execution-order-cyclic.js: Added.
        * tests/modules/execution-order-cyclic/1.js: Added.
        * tests/modules/execution-order-cyclic/10.js: Added.
        * tests/modules/execution-order-cyclic/11.js: Added.
        * tests/modules/execution-order-cyclic/2.js: Added.
        * tests/modules/execution-order-cyclic/3.js: Added.
        * tests/modules/execution-order-cyclic/4.js: Added.
        * tests/modules/execution-order-cyclic/5.js: Added.
        * tests/modules/execution-order-cyclic/6.js: Added.
        * tests/modules/execution-order-cyclic/7.js: Added.
        * tests/modules/execution-order-cyclic/8.js: Added.
        * tests/modules/execution-order-cyclic/9.js: Added.
        * tests/modules/execution-order-dag.js: Added.
        * tests/modules/execution-order-dag/1.js: Added.
        * tests/modules/execution-order-dag/10.js: Added.
        * tests/modules/execution-order-dag/2.js: Added.
        * tests/modules/execution-order-dag/3.js: Added.
        * tests/modules/execution-order-dag/4.js: Added.
        * tests/modules/execution-order-dag/5.js: Added.
        * tests/modules/execution-order-dag/6.js: Added.
        * tests/modules/execution-order-dag/7.js: Added.
        * tests/modules/execution-order-dag/8.js: Added.
        * tests/modules/execution-order-dag/9.js: Added.
        * tests/modules/execution-order-depth.js: Added.
        * tests/modules/execution-order-depth/1.js: Added.
        * tests/modules/execution-order-depth/2.js: Added.
        * tests/modules/execution-order-depth/3.js: Added.
        * tests/modules/execution-order-self.js: Added.
        * tests/modules/execution-order-sibling.js: Added.
        * tests/modules/execution-order-sibling/1.js: Added.
        * tests/modules/execution-order-sibling/2.js: Added.
        * tests/modules/execution-order-sibling/3.js: Added.
        * tests/modules/execution-order-tree.js: Added.
        * tests/modules/execution-order-tree/1.js: Added.
        * tests/modules/execution-order-tree/10.js: Added.
        * tests/modules/execution-order-tree/11.js: Added.
        * tests/modules/execution-order-tree/2.js: Added.
        * tests/modules/execution-order-tree/3.js: Added.
        * tests/modules/execution-order-tree/4.js: Added.
        * tests/modules/execution-order-tree/5.js: Added.
        * tests/modules/execution-order-tree/6.js: Added.
        * tests/modules/execution-order-tree/7.js: Added.
        * tests/modules/execution-order-tree/8.js: Added.
        * tests/modules/execution-order-tree/9.js: Added.
        * tests/modules/export-conflict-ok.js: Added.
        * tests/modules/export-conflict-ok/A.js: Added.
        * tests/modules/export-conflict-ok/B.js: Added.
        * tests/modules/export-conflict-ok/main.js: Added.
        * tests/modules/export-from.js: Added.
        * tests/modules/export-from/main.js: Added.
        * tests/modules/export-from/second.js: Added.
        * tests/modules/export-with-declarations-list.js: Added.
        * tests/modules/export-with-declarations-list/main.js: Added.
        * tests/modules/exported-function-may-be-called-before-module-is-executed.js: Added.
        * tests/modules/exported-function-may-be-called-before-module-is-executed/1.js: Added.
        * tests/modules/exported-function-may-be-called-before-module-is-executed/2.js: Added.
        (export.add):
        (export.raise):
        * tests/modules/import-error.js: Added.
        * tests/modules/import-error/export-ambiguous-1.js: Added.
        * tests/modules/import-error/export-ambiguous-2.js: Added.
        * tests/modules/import-error/export-ambiguous.js: Added.
        * tests/modules/import-error/export-default-from-star-2.js: Added.
        (export.default.Cocoa):
        * tests/modules/import-error/export-default-from-star.js: Added.
        * tests/modules/import-error/export-not-found.js: Added.
        * tests/modules/import-error/import-ambiguous.js: Added.
        * tests/modules/import-error/import-default-from-star.js: Added.
        * tests/modules/import-error/import-not-found.js: Added.
        * tests/modules/imported-bindings-are-immutable.js: Added.
        * tests/modules/imported-bindings-are-immutable/bindings.js: Added.
        (export.functionDeclaration):
        (export.classDeclaration):
        * tests/modules/imported-bindings-can-be-changed-in-original-module.js: Added.
        * tests/modules/imported-bindings-can-be-changed-in-original-module/bindings.js: Added.
        * tests/modules/indirect-export-error.js: Added.
        * tests/modules/indirect-export-error/indirect-export-ambiguous-2.js: Added.
        * tests/modules/indirect-export-error/indirect-export-ambiguous-3.js: Added.
        * tests/modules/indirect-export-error/indirect-export-ambiguous-4.js: Added.
        * tests/modules/indirect-export-error/indirect-export-ambiguous.js: Added.
        * tests/modules/indirect-export-error/indirect-export-default-2.js: Added.
        * tests/modules/indirect-export-error/indirect-export-default-3.js: Added.
        (export.default.Cocoa):
        * tests/modules/indirect-export-error/indirect-export-default.js: Added.
        * tests/modules/indirect-export-error/indirect-export-not-found-2.js: Added.
        * tests/modules/indirect-export-error/indirect-export-not-found.js: Added.
        * tests/modules/module-eval.js: Added.
        * tests/modules/module-eval/A.js: Added.
        * tests/modules/module-eval/B.js: Added.
        * tests/modules/module-eval/drink.js: Added.
        * tests/modules/module-is-strict-code.js: Added.
        * tests/modules/namespace-ambiguous.js: Added.
        * tests/modules/namespace-ambiguous/ambiguous-2.js: Added.
        * tests/modules/namespace-ambiguous/ambiguous-3.js: Added.
        * tests/modules/namespace-ambiguous/ambiguous-4.js: Added.
        * tests/modules/namespace-ambiguous/ambiguous.js: Added.
        * tests/modules/namespace-error.js: Added.
        * tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-2.js: Added.
        * tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-3.js: Added.
        * tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-4.js: Added.
        * tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-5.js: Added.
        * tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-6.js: Added.
        * tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity-7.js: Added.
        * tests/modules/namespace-error/namespace-local-error-should-hide-global-ambiguity.js: Added.
        * tests/modules/namespace-tdz.js: Added.
        * tests/modules/namespace-tdz/A.js: Added.
        * tests/modules/namespace-tdz/B.js: Added.
        (export.later):
        * tests/modules/namespace-tdz/main.js: Added.
        * tests/modules/namespace.js: Added.
        * tests/modules/namespace/additional-drink.js: Added.
        * tests/modules/namespace/drink.js: Added.
        (export.default.changeCappuccino):
        * tests/modules/namespace/more-additional-drink.js: Added.
        * tests/modules/resources/assert.js: Added.
        (export.shouldBe):
        (export.shouldThrow):
        * tests/modules/scopes.js: Added.
        * tests/modules/scopes/additional-drink.js: Added.
        * tests/modules/scopes/drink.js: Added.
        (export.default.changeCappuccino):
        * tests/modules/scopes/more-additional-drink.js: Added.
        * tests/modules/this-should-be-undefined.js: Added.
        * tests/stress/modules-syntax-error-with-names.js:
        * tests/stress/modules-syntax-error.js:
        * tests/stress/modules-syntax.js:

2015-09-05  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Implement ModuleNamespaceObject
        https://bugs.webkit.org/show_bug.cgi?id=148705

        Reviewed by Geoffrey Garen.

        Implement Module namespace object.
        That is used when importing the module with the form `import * as namespace from "mod"`.
        The module namespace object is non-extensible object that has the bindings to the original module
        as the property.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::init):
        (JSC::JSGlobalObject::visitChildren):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::moduleNamespaceObjectStructure):
        * runtime/JSModuleNamespaceObject.cpp: Added.
        (JSC::JSModuleNamespaceObject::JSModuleNamespaceObject):
        (JSC::JSModuleNamespaceObject::finishCreation):
        (JSC::JSModuleNamespaceObject::destroy):
        (JSC::JSModuleNamespaceObject::visitChildren):
        (JSC::callbackGetter):
        (JSC::JSModuleNamespaceObject::getOwnPropertySlot):
        (JSC::JSModuleNamespaceObject::put):
        (JSC::JSModuleNamespaceObject::putByIndex):
        (JSC::JSModuleNamespaceObject::deleteProperty):
        (JSC::JSModuleNamespaceObject::getOwnPropertyNames):
        (JSC::JSModuleNamespaceObject::defineOwnProperty):
        (JSC::moduleNamespaceObjectSymbolIterator):
        * runtime/JSModuleNamespaceObject.h: Added.
        (JSC::JSModuleNamespaceObject::create):
        (JSC::JSModuleNamespaceObject::createStructure):
        (JSC::JSModuleNamespaceObject::moduleRecord):
        * runtime/JSModuleRecord.cpp:
        (JSC::JSModuleRecord::visitChildren):
        (JSC::getExportedNames):
        (JSC::JSModuleRecord::getModuleNamespace):
        (JSC::JSModuleRecord::instantiateDeclarations):
        * runtime/JSModuleRecord.h:

2015-09-04  Mark Lam  <mark.lam@apple.com>

        Rollout r189411, r189413: Broke JSC tests.

        Not reviewed.

        * API/tests/PingPongStackOverflowTest.cpp: Removed.
        * API/tests/PingPongStackOverflowTest.h: Removed.
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/CallFrame.h:
        (JSC::ExecState::operator=):
        (JSC::ExecState::callerFrame):
        (JSC::ExecState::argIndexForRegister):
        (JSC::ExecState::callerFrameOrVMEntryFrame):
        (JSC::ExecState::callerFrameAndPC):
        * interpreter/Interpreter.cpp:
        (JSC::UnwindFunctor::UnwindFunctor):
        (JSC::UnwindFunctor::operator()):
        (JSC::Interpreter::unwind):
        * interpreter/Interpreter.h:
        (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
        (JSC::Interpreter::sampler):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::jumpToExceptionHandler):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITExceptions.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOperations.cpp:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/VM.h:
        (JSC::VM::exceptionOffset):
        (JSC::VM::vmEntryFrameForThrowOffset):
        (JSC::VM::topVMEntryFrameOffset):
        (JSC::VM::callFrameForThrowOffset):

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

        Web Inspector: Test Runtime.saveResult and $n values
        https://bugs.webkit.org/show_bug.cgi?id=148837

        Reviewed by Timothy Hatcher.

        * inspector/InjectedScriptSource.js:
        (InjectedScript.prototype._evaluateOn):
        We don't need to be in the console object group to put the value
        in the saved results list. That strong reference will ensure $n
        values are always alive even if other object groups were used
        when creating and subsequently released.

2015-09-04  Mark Lam  <mark.lam@apple.com>

        [Follow up] StackOverflow stack unwinding should stop at native frames.
        https://bugs.webkit.org/show_bug.cgi?id=148749

        Rubber stamped by Michael Saboff.

        Speculative fix for jsc test failure.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwind):

2015-09-04  Mark Lam  <mark.lam@apple.com>

        StackOverflow stack unwinding should stop at native frames.
        https://bugs.webkit.org/show_bug.cgi?id=148749

        Reviewed by Michael Saboff.

        In the present code, after ping-pong'ing back and forth between native and JS
        code a few times, if we have a stack overflow on re-entry into the VM to run
        JS code's whose stack frame would overflow the JS stack, the code will end up
        unwinding past the native function that is making the call to re-enter the VM.
        As a result, any clean up code (e.g. destructors for stack variables) in the
        skipped native function frame (and its chain of native function callers) will
        not be called.

        This patch is based on the Michael Saboff's fix of this issue landed on the
        jsc-tailcall branch: http://trac.webkit.org/changeset/188555

        We now check for the case where there are no JS frames to unwind since the
        last native frame, and treat the exception as an unhandled exception.  The
        native function is responsible for further propagating the exception if needed.

        Other supporting work:
        1. Remove vm->vmEntryFrameForThrow.  It should always be the same as
           vm->topVMEntryFrame.
        2. Change operationThrowStackOverflowError() to use the throwStackOverflowError()
           helper function instead of rolling its own.
        3. In the LLINT vm entry, set vm->topVMEntryFrame as soon as the entry frame is
           fully initialized (instead of waiting).  With this, we can always reliably
           tell which VMEntryFrame is on top.
        4. Added a test that exercises this edge case.  The test should not hang or crash.

        * API/tests/PingPongStackOverflowTest.cpp: Added.
        (PingPongStackOverflowObject_hasInstance):
        (testPingPongStackOverflow):
        * API/tests/PingPongStackOverflowTest.h: Added.
        * API/tests/testapi.c:
        (main):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/Interpreter.cpp:
        (JSC::unwindCallFrame):
        (JSC::getStackFrameCodeType):
        (JSC::UnwindFunctor::UnwindFunctor):
        (JSC::UnwindFunctor::operator()):
        (JSC::Interpreter::unwind):
        * interpreter/Interpreter.h:
        (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
        (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
        (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
        (JSC::Interpreter::sampler):
        * jit/CCallHelpers.h:
        (JSC::CCallHelpers::jumpToExceptionHandler):
        * jit/JITExceptions.cpp:
        (JSC::genericUnwind):
        * jit/JITExceptions.h:
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_catch):
        * jit/JITOperations.cpp:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/VM.h:
        (JSC::VM::exceptionOffset):
        (JSC::VM::callFrameForThrowOffset):
        (JSC::VM::vmEntryFrameForThrowOffset): Deleted.
        (JSC::VM::topVMEntryFrameOffset): Deleted.

2015-09-04  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement the division and modulo instructions in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=148791

        Reviewed by Geoffrey Garen.

        This patch implements the unsigned division, signed modulo, and unsigned
        modulo instructions for 32-bit integers in WebAssembly. It also
        implements the context pool index instructions, which are needed for
        testing. (pack-asmjs puts numbers that are used more than once in the
        constant pool.)

        * assembler/X86Assembler.h:
        (JSC::X86Assembler::divl_r):
        * tests/stress/wasm-arithmetic.js:
        * tests/stress/wasm-arithmetic.wasm:
        * wasm/WASMFunctionCompiler.h:
        (JSC::operationMod):
        (JSC::operationUnsignedDiv):
        (JSC::operationUnsignedMod):
        (JSC::WASMFunctionCompiler::buildBinaryI32):
        (JSC::WASMFunctionCompiler::callOperation):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionI32):
        * wasm/WASMFunctionParser.h:

2015-09-04  Basile Clement  <basile_clement@apple.com>

        Fix debug output for an eval call
        https://bugs.webkit.org/show_bug.cgi?id=148839

        Reviewed by Filip Pizlo.

        * jit/ThunkGenerators.cpp:
        (JSC::virtualThunkFor):

2015-09-04  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement the signed division instruction in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=148772

        Reviewed by Geoffrey Garen.

        This patch implements the signed division instruction in WebAssembly
        for 32-bit integers. We use the IDIV instruction on x86 and x86-64 and
        use a C function on all other platforms. We throw an exception if
        - the denominator is zero, or
        - the numerator is -2^31 and the denominator is -1.

        * jit/JITOperations.cpp:
        * jit/JITOperations.h:
        * tests/stress/wasm-arithmetic.js:
        (shouldBe):
        (shouldThrow):
        * tests/stress/wasm-arithmetic.wasm:
        * wasm/WASMFunctionCompiler.h:
        (JSC::operationDiv):
        (JSC::WASMFunctionCompiler::endFunction):
        (JSC::WASMFunctionCompiler::buildBinaryI32):
        (JSC::WASMFunctionCompiler::appendCall):
        (JSC::WASMFunctionCompiler::appendCallWithExceptionCheck):
        (JSC::WASMFunctionCompiler::callOperation):
        (JSC::WASMFunctionCompiler::throwStackOverflowError): Deleted.
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseExpressionI32):

2015-09-04  Sukolsak Sakshuwong  <sukolsak@gmail.com>

        Implement the GetLocal and SetLocal instructions in WebAssembly
        https://bugs.webkit.org/show_bug.cgi?id=148793

        Reviewed by Saam Barati.

        This patch implements the GetLocal and SetLocal instructions for locals
        of type int32 in WebAssembly. A "local" in this context is either an
        argument or a local variable.

        * tests/stress/wasm-locals.js: Added.
        (shouldBe):
        * tests/stress/wasm-locals.wasm: Added.
        * wasm/WASMFunctionCompiler.h:
        (JSC::WASMFunctionCompiler::buildSetLocal):
        (JSC::WASMFunctionCompiler::buildGetLocal):
        * wasm/WASMFunctionParser.cpp:
        (JSC::WASMFunctionParser::parseSetLocalStatement):
        (JSC::WASMFunctionParser::parseExpressionI32):
        (JSC::WASMFunctionParser::parseGetLocalExpressionI32):
        * wasm/WASMFunctionParser.h:
        * wasm/WASMFunctionSyntaxChecker.h:
        (JSC::WASMFunctionSyntaxChecker::buildSetLocal):
        (JSC::WASMFunctionSyntaxChecker::buildGetLocal):

2015-09-04  Basile Clement  <basile_clement@apple.com>

        Unreviewed, add missing copyright to file from r189336

        * bytecompiler/SetForScope.h:

2015-09-04  Brian Burg  <bburg@apple.com>

        Web Inspector: InspectorController should support multiple frontend channels
        https://bugs.webkit.org/show_bug.cgi?id=148538

        Reviewed by Joseph Pecoraro.

        Instead of a singleton, it should be possible to have multiple channels open
        at the same time and to individually close channels as frontends come and go.

        The FrontendRouter class keeps a list of open FrontendChannels and sends messages
        to the appropriate frontends based on whether the message is a response or event.
        Each InspectorController owns a single FrontendRouter and BackendDispatcher instance.
        Inspector backend code that sends messages to the frontend should switch over to
        using the router rather than directly using a FrontendChannel.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * inspector/InspectorBackendDispatcher.cpp: Move constructors/destructors out of the header
        to avoid including InspectorFrontendRouter everywhere. Use the router instead of a
        specific frontend channel. Remove guards that are no longer necessary since the router
        is guaranteed to outlive the backend dispatcher.

        (Inspector::SupplementalBackendDispatcher::SupplementalBackendDispatcher):
        (Inspector::SupplementalBackendDispatcher::~SupplementalBackendDispatcher):
        (Inspector::BackendDispatcher::BackendDispatcher):
        (Inspector::BackendDispatcher::create):
        (Inspector::BackendDispatcher::isActive):
        (Inspector::BackendDispatcher::registerDispatcherForDomain):
        (Inspector::BackendDispatcher::sendResponse):
        (Inspector::BackendDispatcher::sendPendingErrors):
        * inspector/InspectorBackendDispatcher.h:
        (Inspector::SupplementalBackendDispatcher::SupplementalBackendDispatcher): Deleted.
        (Inspector::SupplementalBackendDispatcher::~SupplementalBackendDispatcher): Deleted.
        (Inspector::BackendDispatcher::clearFrontend): Deleted, no longer necessary.
        (Inspector::BackendDispatcher::isActive): Moved to implementation file.
        (Inspector::BackendDispatcher::BackendDispatcher): Moved to implementation file.
        * inspector/InspectorFrontendRouter.cpp: Added.
        (Inspector::FrontendRouter::create):
        (Inspector::FrontendRouter::connectFrontend):
        (Inspector::FrontendRouter::disconnectFrontend):
        (Inspector::FrontendRouter::disconnectAllFrontends):
        (Inspector::FrontendRouter::leakChannel):
        (Inspector::FrontendRouter::hasLocalFrontend):
        (Inspector::FrontendRouter::hasRemoteFrontend):
        (Inspector::FrontendRouter::sendEvent):
        (Inspector::FrontendRouter::sendResponse):
        * inspector/InspectorFrontendRouter.h: Added.
        * inspector/JSGlobalObjectInspectorController.cpp: Remove guards that are no longer necessary.
        The frontend router and backend dispatcher now have the same lifetime as the controller.
        Explicitly connect/disconnect the frontend channel.

        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
        (Inspector::JSGlobalObjectInspectorController::globalObjectDestroyed):
        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
        (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
        (Inspector::JSGlobalObjectInspectorController::disconnectAllFrontends):
        (Inspector::JSGlobalObjectInspectorController::dispatchMessageFromFrontend):
        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
        (Inspector::JSGlobalObjectInspectorController::pause): Deleted.
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/agents/InspectorAgent.cpp:
        * inspector/agents/InspectorConsoleAgent.cpp:
        * inspector/agents/InspectorDebuggerAgent.cpp:
        * inspector/agents/InspectorRuntimeAgent.cpp:
        * inspector/augmentable/AugmentableInspectorController.h:
        (Inspector::AugmentableInspectorController::connected):
        * inspector/remote/RemoteInspectorDebuggable.h:
        * inspector/remote/RemoteInspectorDebuggableConnection.mm:
        (Inspector::RemoteInspectorDebuggableConnection::close):
        * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
        (CppAlternateBackendDispatcherHeaderGenerator.generate_output):
        * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
        (ObjCFrontendDispatcherImplementationGenerator._generate_event): Use the router.
        * runtime/JSGlobalObjectDebuggable.cpp:
        (JSC::JSGlobalObjectDebuggable::disconnect):
        * runtime/JSGlobalObjectDebuggable.h:

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

        Web Inspector: Expand Console domain test coverage
        https://bugs.webkit.org/show_bug.cgi?id=148740

        Reviewed by Brian Burg.

        * inspector/protocol/Console.json:
        Update the description of this command now that it only
        manipulates $0, and not $1, $2, .. $n.

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

        Web Inspector: Test RuntimeAgent.parse, detecting if a script parse error is recoverable
        https://bugs.webkit.org/show_bug.cgi?id=148790

        Reviewed by Timothy Hatcher.

        * parser/Lexer.cpp:
        (JSC::Lexer<T>::lex):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::printUnexpectedTokenText):
        * parser/ParserTokens.h:
        More consistently name and treat unterminated numeric literals.

        * parser/Parser.h:
        (JSC::Parser<LexerType>::parse):
        Treat multiline capable unterminated literals as recoverable.

2015-08-25  Basile Clement  <basile_clement@apple.com>

        Get rid of FTLValueFormat
        https://bugs.webkit.org/show_bug.cgi?id=148448

        Reviewed by Michael Saboff.

        FTL::ValueFormat is nothing more than DataFormat (and is actually
        slightly less). Let's get rid of it.

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/DataFormat.cpp: Renamed from Source/JavaScriptCore/ftl/FTLValueFormat.h.
        (WTF::printInternal):
        * bytecode/DataFormat.h:
        * ftl/FTLAvailableRecovery.h:
        (JSC::FTL::AvailableRecovery::AvailableRecovery):
        (JSC::FTL::AvailableRecovery::format):
        * ftl/FTLExitArgument.h:
        (JSC::FTL::ExitArgument::ExitArgument):
        (JSC::FTL::ExitArgument::operator!):
        (JSC::FTL::ExitArgument::format):
        (JSC::FTL::ExitArgument::withFormat):
        * ftl/FTLExitValue.cpp:
        (JSC::FTL::ExitValue::dataFormat):
        * ftl/FTLExitValue.h:
        (JSC::FTL::ExitValue::recovery):
        (JSC::FTL::ExitValue::recoveryFormat):
        * ftl/FTLFormattedValue.h:
        (JSC::FTL::FormattedValue::FormattedValue):
        (JSC::FTL::FormattedValue::operator!):
        (JSC::FTL::FormattedValue::format):
        (JSC::FTL::int32Value):
        (JSC::FTL::booleanValue):
        (JSC::FTL::jsValueValue):
        (JSC::FTL::doubleValue):
        * ftl/FTLLowerDFGToLLVM.cpp:
        (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
        (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
        (JSC::FTL::DFG::LowerDFGToLLVM::convertDoubleToInt32):
        (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForNode):
        (JSC::FTL::DFG::LowerDFGToLLVM::exitArgument):
        (JSC::FTL::DFG::LowerDFGToLLVM::addAvailableRecovery):
        * ftl/FTLOSRExit.cpp:
        (JSC::FTL::OSRExit::OSRExit):
        * ftl/FTLOSRExit.h:
        * ftl/FTLOSRExitCompiler.cpp:
        (JSC::FTL::reboxAccordingToFormat):
        (JSC::FTL::compileRecovery):
        (JSC::FTL::compileStub):
        * ftl/FTLValueFormat.cpp: Removed.

2015-09-04  Basile Clement  <basile_clement@apple.com>

        Introduce RegisterMap<T>
        https://bugs.webkit.org/show_bug.cgi?id=148335

        Reviewed by Michael Saboff.

        Introduce RegisterMap<T>, GPRMap<T> and FPRMap<T> dense mappings for
        Reg, GPRReg and FPRReg.

        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * jit/RegisterMap.h: Added.
        (JSC::RegisterMap::operator[]):
        (JSC::GPRMap::operator[]):
        (JSC::FPRMap::operator[]):

2015-09-04  Andreas Kling  <akling@apple.com>

        Remove some unused functions from MarkedBlock and MarkedSpace.
        <https://webkit.org/b/148748>

        Reviewed by Darin Adler.

        * ftl/FTLAbstractHeapRepository.h:
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::offsetOfMarks): Deleted.
        (JSC::MarkedBlock::didConsumeEmptyFreeList): Deleted.
        * heap/MarkedSpace.h:

2015-09-04  Basile Clement  <basile_clement@apple.com>

        Make a bunch of MacroAssembler operations constexpr
        https://bugs.webkit.org/show_bug.cgi?id=148334

        Reviewed by Saam Barati.

        This is in preparation of https://bugs.webkit.org/show_bug.cgi?id=148335 .

        * assembler/ARM64Assembler.h:
        (JSC::ARM64Registers::isSp):
        (JSC::ARM64Registers::isZr):
        (JSC::ARM64Assembler::firstRegister):
        (JSC::ARM64Assembler::lastRegister):
        (JSC::ARM64Assembler::firstFPRegister):
        (JSC::ARM64Assembler::lastFPRegister):
        (JSC::ARM64Assembler::isSp):
        (JSC::ARM64Assembler::isZr):
        * assembler/ARMAssembler.h:
        (JSC::ARMAssembler::firstRegister):
        (JSC::ARMAssembler::lastRegister):
        (JSC::ARMAssembler::firstFPRegister):
        (JSC::ARMAssembler::lastFPRegister):
        * assembler/AbstractMacroAssembler.h:
        (JSC::AbstractMacroAssembler::firstRegister):
        (JSC::AbstractMacroAssembler::lastRegister):
        (JSC::AbstractMacroAssembler::firstFPRegister):
        (JSC::AbstractMacroAssembler::lastFPRegister):
        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::firstRegister):
        (JSC::MIPSAssembler::lastRegister):
        (JSC::MIPSAssembler::firstFPRegister):
        (JSC::MIPSAssembler::lastFPRegister):
        * assembler/MacroAssembler.h:
        (JSC::MacroAssembler::nextRegister):
        (JSC::MacroAssembler::nextFPRegister):
        (JSC::MacroAssembler::numberOfRegisters):
        (JSC::MacroAssembler::registerIndex):
        (JSC::MacroAssembler::numberOfFPRegisters):
        (JSC::MacroAssembler::fpRegisterIndex):
        (JSC::MacroAssembler::totalNumberOfRegisters):
        * assembler/SH4Assembler.h:
        (JSC::SH4Assembler::firstRegister):
        (JSC::SH4Assembler::lastRegister):
        (JSC::SH4Assembler::firstFPRegister):
        (JSC::SH4Assembler::lastFPRegister):
        * assembler/X86Assembler.h:
        (JSC::X86Assembler::firstRegister):
        (JSC::X86Assembler::lastRegister):
        (JSC::X86Assembler::firstFPRegister):
        (JSC::X86Assembler::lastFPRegister):

2015-08-24  Basile Clement  <basile_clement@apple.com>

        Add a bunch of operators
        https://bugs.webkit.org/show_bug.cgi?id=148337

        Reviewed by Saam Barati.

        * jit/GPRInfo.h:
        (JSC::JSValueRegs::operator bool):
        (JSC::JSValueRegs::operator==):
        (JSC::JSValueRegs::operator!=):
        (JSC::JSValueSource::operator bool):
        (JSC::JSValueRegs::operator!):
        (JSC::JSValueSource::operator!):
        * jit/Reg.h:
        (JSC::Reg::operator bool):

2015-09-04  Basile Clement  <basile_clement@apple.com>

        Since r189341, es6.yaml/es6/arrow_functions_no_prototype_property.js is expected to succeed

        Rubber stamped by Michael Saboff.

        * tests/es6.yaml:

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

        [ARM] Fix the ARM Traditional build after r189288
        https://bugs.webkit.org/show_bug.cgi?id=148792

        Reviewed by Zoltan Herczeg.

        * assembler/MacroAssemblerARM.h: Make repatchCall public similar to changes in r189288.
        (JSC::MacroAssemblerARM::repatchCall):

2015-09-03 Aleksandr Skachkov   <gskachkov@gmail.com>

        [ES6] Implement ES6 arrow function syntax. Prototype of arrow function should be undefined
        https://bugs.webkit.org/show_bug.cgi?id=147742

        Reviewed by Saam Barati.

        Added correct support of prototype property for arrow function. Arrow function 
        doesn’t have own prototype property, so (() => {}).hasOwnProperty('prototype') === false.
        Changes prevent from creation of 'prototype' property automatically during initialization 
        of arrow function and allow to assign & delete it later in js code. 


        * runtime/JSFunction.cpp:
        (JSC::JSFunction::getOwnPropertySlot):
        (JSC::JSFunction::deleteProperty):
        * tests/stress/arrowfunction-prototype.js: Added.

2015-09-03  Commit Queue  <commit-queue@webkit.org>

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

        Caused tons of crashes (Requested by cdumez on #webkit).

        Reverted changeset:

        "Web Inspector: InspectorController should support multiple
        frontend channels"
        https://bugs.webkit.org/show_bug.cgi?id=148538
        http://trac.webkit.org/changeset/189338

2015-09-03  Yusuke Suzuki  <utatane.tea@gmail.com>

        [ES6] Instantiate Module Environment bindings and execute module
        https://bugs.webkit.org/show_bug.cgi?id=148053

        Reviewed by Saam Barati.

        This patch implements Module Environment binding instantiation.
        And since the layout of the module environment is tightly coupled with the variable
        look up in LLInt / Baseline / DFG, we implement the execution part at the same time.

        For the instantiation, we implement the several operations (like resolveExport)
        specified in the spec. The original algorithm contains the recursive call, but it is not
        good for C++ code. We flatten the algorithm by using the manual frames to avoid recursions.
        By leveraging the information retrieved by the above operations, we instantiate and
        initialize the slots of the module environment.

        The module namespace object is not implemented yet in this patch. It will be implemented
        and instantiated in the module environment in the subsequent patch[1].

        To look up the imported module bindings in the JS code, we introduce the "ModuleVar" resolve
        type for resolve_scope, get_from_scope and put_to_scope. This "ModuleVar" will be filled
        when linking the CodeBlock. This type is used when treating the imported bindings.

        1. For resolve_scope, when linking, we resolve the actual module environment where
            looked up variable resides and store it directly to the instruction. And resolve_scope
            simply retrieve the stored pointer from the instruction.

        2. For get_from_scope, since "ModuleVar" behavior for get_from_scope is completely same
            to the "ClosureVar", we just store "ClosureVar" for get_from_scope to eliminate
            unnecessary branch in LLInt layer.

        3. For put_to_scope, we always emit the function call that immediately raises the error.
            Because all the imported bindings are immutable and module code is always strict code.
            In DFG, we just emit the ForceOSRExit. We don't make put_to_scope with "ModuleVar"
            "CannotCompile" because it disables DFG compiling for the function even if this
            problematic instruction is never executed.

        Exported module variables inside the original module environment are just treated as the
        usual heap variables. So the types for closure variables are just used. ("ClosureVar" etc.)

        [1]: https://bugs.webkit.org/show_bug.cgi?id=148705

        * CMakeLists.txt:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted.
        * bytecode/UnlinkedCodeBlock.h:
        * bytecompil