2015-11-20 Andreas Kling REGRESSION(r192536): Null pointer dereference in JSPropertyNameEnumerator::visitChildren(). 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 GC timers should carry on gracefully when Heap claims it grew from GC. 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 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 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 [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 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::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 Caching of properties on objects that have named property getters is sometimes incorrect https://bugs.webkit.org/show_bug.cgi?id=151453 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 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 [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::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::parseVariableDeclarationList): (JSC::Parser::declareRestOrNormalParameter): (JSC::Parser::createBindingPattern): (JSC::Parser::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 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 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 [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::Parser): (JSC::Parser::createAssignmentElement): (JSC::Parser::parseBindingOrAssignmentElement): (JSC::Parser::parseAssignmentElement): (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::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 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 [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 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 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 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 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 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 Unreviewed CLOOP buildfix after r192624. * runtime/MemoryStatistics.cpp: (JSC::globalMemoryStatistics): * runtime/MemoryStatistics.h: 2015-11-19 Csaba Osztrogonác 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 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 [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 [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 Fix typos in r192605 * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon): 2015-11-18 Filip Pizlo and Benjamin Poulain 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 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::parseVariableDeclarationList): (JSC::Parser::createBindingPattern): (JSC::Parser::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 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 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 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 [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 [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 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 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::parseVariableDeclarationList): (JSC::Parser::createBindingPattern): (JSC::Parser::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 [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 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 FTL::State should be able to refer to B3::Procedure Rubber stamped by Benjamin Poulain. * ftl/FTLState.h: 2015-11-17 Benjamin Poulain [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 [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 [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 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 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 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 [JSC] JSPropertyNameEnumerator could be destructorless. 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 and WriteBarrier 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 to a WriteBarrier 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 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 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. * 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 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 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 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 [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 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 [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 [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 [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 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 [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 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 [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 [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 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 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 [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 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 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 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 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 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 Follow-up for 32-bit test failures after... [JSC] JSPropertyNameEnumerator could be destructorless. 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 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 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::createAssignmentElement): (JSC::Parser::parseDestructuringPattern): * parser/Parser.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::operatorStackPop): 2015-11-13 Yusuke Suzuki 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 [JSC] JSPropertyNameEnumerator could be destructorless. 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 [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 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 but I missed. * bytecode/CodeBlock.cpp: (JSC::timeToLive): (JSC::CodeBlock::shouldJettisonDueToOldAge): 2015-11-12 Filip Pizlo 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 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 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 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 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 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 [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 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 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 [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 [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 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 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 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 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 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 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 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 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 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 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::mayBeCoalescable): (JSC::B3::Air::MoveInstHelper::mayBeCoalescable): (JSC::B3::Air::AbsoluteTmpHelper::absoluteIndex): (JSC::B3::Air::AbsoluteTmpHelper::tmpFromAbsoluteIndex): (JSC::B3::Air::AbsoluteTmpHelper::absoluteIndex): (JSC::B3::Air::AbsoluteTmpHelper::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 Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=151128. * b3/air/AirInstInlines.h: 2015-11-10 Saam barati 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 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 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 [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 [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 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 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 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 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 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 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 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 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 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 [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 [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 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 [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 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 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 [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::Lexer): Deleted. (JSC::Lexer::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 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 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 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 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 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 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 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 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::executeEffects): 2015-11-05 Filip Pizlo 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 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 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 [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 [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 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 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 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 [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 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 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 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 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 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 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 [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 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 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 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 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 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 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 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 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 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 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::lex): * parser/Parser.cpp: (JSC::Parser::parseInner): Deleted. * parser/Parser.h: (JSC::Parser::isArrowFunctionParamters): Deleted. * parser/ParserTokens.h: 2015-11-02 Michael Saboff 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 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 [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 [Win] MiniBrowser unable to use WebInspector https://bugs.webkit.org/show_bug.cgi?id=150810 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 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 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 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 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 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 [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::Parser): (JSC::Parser::parseInner): (JSC::Parser::parseStatementListItem): (JSC::Parser::parseVariableDeclarationList): (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseBreakStatement): (JSC::Parser::parseContinueStatement): (JSC::Parser::parseTryStatement): (JSC::Parser::parseStatement): (JSC::stringForFunctionMode): (JSC::Parser::parseFunctionParameters): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseFunctionDeclaration): (JSC::Parser::parseClass): (JSC::Parser::parseExpressionOrLabelStatement): (JSC::Parser::parseExportDeclaration): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseYieldExpression): (JSC::Parser::parseProperty): (JSC::Parser::parsePropertyMethod): (JSC::Parser::parseGetterSetter): (JSC::Parser::parseFunctionExpression): (JSC::Parser::parsePrimaryExpression): (JSC::Parser::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 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): (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 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::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 [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 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 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 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 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 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 Add a debug overlay with information about web process resource usage. 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 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 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 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 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 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::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 [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 [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 Unreviewed, removing FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=150540. * b3/B3ValueRep.h: 2015-10-30 Michael Saboff 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 Unreviewed, forgot to mark tests as passing for new feature. * tests/es6.yaml: 2015-10-30 Filip Pizlo 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 [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 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 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 [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 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 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 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 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 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 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 Unreviewed, fix iOS build. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::store64): 2015-10-29 Alex Christensen 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 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 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 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 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 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 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 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 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 [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 Unreviewed, fix the build for case sensitive file systems. * b3/air/AirBasicBlock.h: * b3/air/AirStackSlot.h: 2015-10-28 Filip Pizlo 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::forEach): (JSC::B3::Air::ForEach::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::inPriorityOrder): (JSC::B3::Air::RegistersInPriorityOrder::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 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 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 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 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 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 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 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 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 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 [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::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 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 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 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 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 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 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 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 [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::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 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 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 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 [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 [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 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 [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 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 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 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 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 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 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 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 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 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::setCode): (JSC::Lexer::skipWhitespace): (JSC::Lexer::parseCommentDirective): (JSC::Lexer::parseCommentDirectiveValue): (JSC::Lexer::consume): (JSC::Lexer::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::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 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 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 [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 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 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 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 Try to fix the iOS build * Configurations/FeatureDefines.xcconfig: 2015-10-17 Keith Miller 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 Add magnify and rotate gesture event support for Mac https://bugs.webkit.org/show_bug.cgi?id=150179 Reviewed by Darin Adler. * Configurations/FeatureDefines.xcconfig: New feature flag. 2015-10-19 Csaba Osztrogonác 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 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 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 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 [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 [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 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 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 [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 Fixed typos from r191224. Not reviewed. * jit/JITSubGenerator.h: (JSC::JITSubGenerator::generateFastPath): 2015-10-17 Filip Pizlo 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 [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 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 Unreviewed. Fix typo in TypeError messages in TypedArray.prototype.forEach/filter. * builtins/TypedArray.prototype.js: (forEach): (filter): 2015-10-16 Mark Lam 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::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 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::copyBackingStore): (JSC::JSGenericTypedArrayView::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 Unreviewed. Build fix for 191215. * jit/IntrinsicEmitter.cpp: 2015-10-16 Keith Miller 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::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::getOwnPropertySlot): (JSC::JSGenericTypedArrayView::defineOwnProperty): (JSC::JSGenericTypedArrayView::deleteProperty): (JSC::JSGenericTypedArrayView::getOwnPropertySlotByIndex): Deleted. (JSC::JSGenericTypedArrayView::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 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 Fix Windows build. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: 2015-10-16 Michael Saboff 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 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(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(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 Remove unused StructureRareData::m_cachedGenericPropertyNameEnumerator. 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 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 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.h files to the corresponding MacroAssembler.cpp files. I also had to make some minor changes to get the code to build after this move: 1. Added #include in the MacroAssembler.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.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 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 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 Unreviewed. Attempted EFL build fix 2 after r191159. * PlatformEfl.cmake: 2015-10-15 Joseph Pecoraro Unreviewed. Attempted EFL build fix after r191159. * PlatformEfl.cmake: 2015-10-15 Joseph Pecoraro Unreviewed. Build fix after r191160. * inspector/agents/InspectorHeapAgent.cpp: (Inspector::InspectorHeapAgent::didGarbageCollect): 2015-10-15 Joseph Pecoraro 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 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 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 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 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::setCode): (JSC::Lexer::skipWhitespace): (JSC::Lexer::parseCommentDirective): (JSC::Lexer::parseCommentDirectiveValue): (JSC::Lexer::consume): (JSC::Lexer::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::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 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, even though the HashMap's nominal key type was RefPtr. 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 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 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 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 [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::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 [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::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 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 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 [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 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::finishCreation): (JSC::JSGenericTypedArrayViewConstructor::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 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::set): (JSC::WriteBarrierBase::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 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 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 [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::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 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 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 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 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 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 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 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 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 Unreviewed build fix * runtime/JSObject.cpp: (JSC::JSObject::reallocateAndShrinkButterfly): 2015-10-08 Filip Pizlo 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::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::visitChildren): (JSC::JSGenericTypedArrayView::copyBackingStore): (JSC::JSGenericTypedArrayView::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 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 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 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 "A + B" with strings shouldn't copy if A or B is empty. Reviewed by Anders Carlsson. * runtime/JSStringBuilder.h: (JSC::jsMakeNontrivialString): * runtime/Lookup.cpp: (JSC::reifyStaticAccessor): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncToString): 2015-10-12 Joseph Pecoraro 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 Unreviewed, fix non-FTL build for real. * ftl/FTLLazySlowPath.h: 2015-10-12 Filip Pizlo Unreviewed, clarify a comment. The example code had a bug. * ftl/FTLLowerDFGToLLVM.cpp: 2015-10-12 Filip Pizlo Unreviewed, fix no-FTL build. * ftl/FTLLazySlowPath.cpp: 2015-10-12 Philip Chimento 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 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 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 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 Reduce pointless malloc traffic in CodeBlock construction. Reviewed by Antti Koivisto. Create the RefCountedArray for CodeBlock's m_instructions directly instead of first creating a Vector 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 [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 [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 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 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 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 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 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 and Youenn Fablet 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 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 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 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 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 Unreviewed build fix. Missing forward declaration. * heap/Heap.h: 2015-10-08 Saam barati 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 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 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 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 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 Unreviewed CLOOP buildfix after r190718. * jit/Repatch.h: (JSC::resetGetByID): Deleted. (JSC::resetPutByID): Deleted. (JSC::resetIn): Deleted. 2015-10-08 Joseph Pecoraro 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 and Youenn Fablet 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 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 [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 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 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 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 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 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 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 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 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 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 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 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 and Youenn Fablet 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 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 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 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 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 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 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 [Intl] Change the return type of canonicalizeLocaleList() from JSArray* to Vector 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. 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 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 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::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 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 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 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 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 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 and Mark Lam 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 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 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 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 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::RefToFTLForOSREntryDeferredCompilationCallback::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 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::RefToFTLForOSREntryDeferredCompilationCallback::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 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 [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::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 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::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 [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 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 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 Unreviewed Windows buildfix. * CMakeLists.txt: 2015-09-30 Michael Saboff 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 [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::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 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 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 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 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 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 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 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 [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 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 Unreviewed, fix debug tests. Before marking, we need to call registerGCThreads(). * heap/Heap.cpp: (JSC::Heap::markRoots): 2015-09-24 Filip Pizlo 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 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 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 [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 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 [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::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 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 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 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 Ran sort-Xcode-project-file. * JavaScriptCore.xcodeproj/project.pbxproj: 2015-09-24 Youenn Fablet [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 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::parseVariableDeclarationList): (JSC::Parser::createBindingPattern): (JSC::Parser::parseFunctionDeclaration): * parser/Parser.h: (JSC::Scope::declareVariable): 2015-09-23 Filip Pizlo 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 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 Hopefully fix the production build. * JavaScriptCore.xcodeproj/project.pbxproj: * PlatformWin.cmake: 2015-09-23 Youenn Fablet [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 Gardening: speculative non-JIT build fix after r189999. Not reviewed. * bytecode/ValueRecovery.h: (JSC::ValueRecovery::jsValueRegs): 2015-09-22 Filip Pizlo 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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::executeEffects): (JSC::DFG::AbstractInterpreter::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 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 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 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 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 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 [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 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 [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 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 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 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 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 [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 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 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 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 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 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 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 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 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 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 CLoop build fix after r189938. * interpreter/StackVisitor.cpp: (JSC::StackVisitor::unwindToMachineCodeBlockFrame): 2015-09-17 Sukolsak Sakshuwong 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 [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 `