2014-01-14 Lucas Forschler Merge r161574 2014-01-09 Filip Pizlo AI for CreateArguments should pass through non-SpecEmpty input values https://bugs.webkit.org/show_bug.cgi?id=126709 Reviewed by Mark Hahnenberg. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * tests/stress/use-arguments-as-object-pointer.js: Added. (foo): 2014-01-05 Sam Weinig [JS] Implement Promise.race() https://bugs.webkit.org/show_bug.cgi?id=126506 Reviewed by Oliver Hunt. * runtime/CommonIdentifiers.h: Add identifier for "cast". * runtime/JSPromiseConstructor.cpp: (JSC::abruptRejection): Helper for the RejectIfAbrupt abstract operation. (JSC::JSPromiseConstructorFuncRace): Add implementation of Promise.race() 2014-01-05 Martin Robinson [GTK] [CMake] Ensure that the autotools build and the CMake install the same files https://bugs.webkit.org/show_bug.cgi?id=116379 Reviewed by Gustavo Noronha Silva. * PlatformGTK.cmake: Install API headers, gir files, and the pkg-config file. 2014-01-04 Yusuke Suzuki Use Compiler macros instead of raw "final" and "override" https://bugs.webkit.org/show_bug.cgi?id=126490 Reviewed by Sam Weinig. * runtime/JSPromiseReaction.cpp: 2014-01-04 Martin Robinson [GTK] [CMake] Improve the way we locate gobject-introspection https://bugs.webkit.org/show_bug.cgi?id=126452 Reviewed by Philippe Normand. * PlatformGTK.cmake: Use the new introspection variables. 2014-01-04 Zan Dobersek Explicitly use the std:: nested name specifier when using std::pair, std::make_pair https://bugs.webkit.org/show_bug.cgi?id=126439 Reviewed by Andreas Kling. Instead of relying on std::pair and std::make_pair symbols being present in the current scope through the pair and make_pair symbols, the std:: specifier should be used explicitly. * bytecode/Opcode.cpp: (JSC::compareOpcodePairIndices): (JSC::OpcodeStats::~OpcodeStats): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * parser/ASTBuilder.h: (JSC::ASTBuilder::makeBinaryNode): * parser/Parser.cpp: (JSC::Parser::parseIfStatement): * runtime/Structure.cpp: (JSC::StructureTransitionTable::contains): (JSC::StructureTransitionTable::get): (JSC::StructureTransitionTable::add): 2014-01-03 David Farler [super dealloc] missing in Source/JavaScriptCore/API/tests/testapi.mm, fails to build with -Werror,-Wobjc-missing-super-calls https://bugs.webkit.org/show_bug.cgi?id=126454 Reviewed by Geoffrey Garen. * API/tests/testapi.mm: (-[TextXYZ dealloc]): add [super dealloc] (-[EvilAllocationObject dealloc]): add [super dealloc] 2014-01-02 Carlos Garcia Campos REGRESSION(r160304): [GTK] Disable libtool fast install https://bugs.webkit.org/show_bug.cgi?id=126381 Reviewed by Martin Robinson. Remove -no-fast-install ld flag since fast install is now disabled globally. * GNUmakefile.am: 2014-01-02 Sam Weinig Update Promises to the https://github.com/domenic/promises-unwrapping spec https://bugs.webkit.org/show_bug.cgi?id=120954 Reviewed by Filip Pizlo. Update Promises to the revised spec. Notable changes: - JSPromiseResolver is gone. - TaskContext has been renamed Microtask and now has a virtual run() function. - Instead of using custom InternalFunction subclasses, JSFunctions are used with PrivateName properties for internal slots. * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * interpreter/CallFrame.h: (JSC::ExecState::promiseConstructorTable): * runtime/CommonIdentifiers.cpp: (JSC::CommonIdentifiers::CommonIdentifiers): * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): (JSC::JSGlobalObject::visitChildren): (JSC::JSGlobalObject::queueMicrotask): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::promiseConstructor): (JSC::JSGlobalObject::promisePrototype): (JSC::JSGlobalObject::promiseStructure): * runtime/JSPromise.cpp: (JSC::JSPromise::create): (JSC::JSPromise::JSPromise): (JSC::JSPromise::finishCreation): (JSC::JSPromise::visitChildren): (JSC::JSPromise::reject): (JSC::JSPromise::resolve): (JSC::JSPromise::appendResolveReaction): (JSC::JSPromise::appendRejectReaction): (JSC::triggerPromiseReactions): * runtime/JSPromise.h: (JSC::JSPromise::status): (JSC::JSPromise::result): (JSC::JSPromise::constructor): * runtime/JSPromiseCallback.cpp: Removed. * runtime/JSPromiseCallback.h: Removed. * runtime/JSPromiseConstructor.cpp: (JSC::constructPromise): (JSC::JSPromiseConstructor::getCallData): (JSC::JSPromiseConstructorFuncCast): (JSC::JSPromiseConstructorFuncResolve): (JSC::JSPromiseConstructorFuncReject): * runtime/JSPromiseConstructor.h: * runtime/JSPromiseDeferred.cpp: Added. (JSC::JSPromiseDeferred::create): (JSC::JSPromiseDeferred::JSPromiseDeferred): (JSC::JSPromiseDeferred::finishCreation): (JSC::JSPromiseDeferred::visitChildren): (JSC::createJSPromiseDeferredFromConstructor): (JSC::updateDeferredFromPotentialThenable): * runtime/JSPromiseDeferred.h: Added. (JSC::JSPromiseDeferred::createStructure): (JSC::JSPromiseDeferred::promise): (JSC::JSPromiseDeferred::resolve): (JSC::JSPromiseDeferred::reject): * runtime/JSPromiseFunctions.cpp: Added. (JSC::deferredConstructionFunction): (JSC::createDeferredConstructionFunction): (JSC::identifyFunction): (JSC::createIdentifyFunction): (JSC::promiseAllCountdownFunction): (JSC::createPromiseAllCountdownFunction): (JSC::promiseResolutionHandlerFunction): (JSC::createPromiseResolutionHandlerFunction): (JSC::rejectPromiseFunction): (JSC::createRejectPromiseFunction): (JSC::resolvePromiseFunction): (JSC::createResolvePromiseFunction): (JSC::throwerFunction): (JSC::createThrowerFunction): * runtime/JSPromiseFunctions.h: Added. * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototypeFuncThen): (JSC::JSPromisePrototypeFuncCatch): * runtime/JSPromiseReaction.cpp: Added. (JSC::createExecutePromiseReactionMicroTask): (JSC::ExecutePromiseReactionMicroTask::run): (JSC::JSPromiseReaction::create): (JSC::JSPromiseReaction::JSPromiseReaction): (JSC::JSPromiseReaction::finishCreation): (JSC::JSPromiseReaction::visitChildren): * runtime/JSPromiseReaction.h: Added. (JSC::JSPromiseReaction::createStructure): (JSC::JSPromiseReaction::deferred): (JSC::JSPromiseReaction::handler): * runtime/JSPromiseResolver.cpp: Removed. * runtime/JSPromiseResolver.h: Removed. * runtime/JSPromiseResolverConstructor.cpp: Removed. * runtime/JSPromiseResolverConstructor.h: Removed. * runtime/JSPromiseResolverPrototype.cpp: Removed. * runtime/JSPromiseResolverPrototype.h: Removed. * runtime/Microtask.h: Added. * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): * runtime/VM.h: 2014-01-02 Mark Hahnenberg Add support for StoreBarrier and friends to the FTL https://bugs.webkit.org/show_bug.cgi?id=126040 Reviewed by Filip Pizlo. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileStoreBarrier): (JSC::FTL::LowerDFGToLLVM::compileConditionalStoreBarrier): (JSC::FTL::LowerDFGToLLVM::compileStoreBarrierWithNullCheck): (JSC::FTL::LowerDFGToLLVM::loadMarkByte): (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier): * heap/Heap.cpp: (JSC::Heap::Heap): * heap/Heap.h: (JSC::Heap::writeBarrierBuffer): 2014-01-02 Mark Hahnenberg Storing new CopiedSpace memory into a JSObject should fire a write barrier https://bugs.webkit.org/show_bug.cgi?id=126025 Reviewed by Filip Pizlo. Technically this is creating a pointer between a (potentially) old generation object and a young generation chunk of memory, thus there needs to be a barrier. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGOperations.cpp: * heap/CopyWriteBarrier.h: Added. This class functions similarly to the WriteBarrier class. It acts as a proxy for pointers to CopiedSpace. Assignments to the field cause a write barrier to fire for the object that is the owner of the CopiedSpace memory. This is to ensure during nursery collections that objects with new backing stores are visited, even if they are old generation objects. (JSC::CopyWriteBarrier::CopyWriteBarrier): (JSC::CopyWriteBarrier::operator!): (JSC::CopyWriteBarrier::operator UnspecifiedBoolType*): (JSC::CopyWriteBarrier::get): (JSC::CopyWriteBarrier::operator*): (JSC::CopyWriteBarrier::operator->): (JSC::CopyWriteBarrier::set): (JSC::CopyWriteBarrier::setWithoutWriteBarrier): (JSC::CopyWriteBarrier::clear): * heap/Heap.h: * runtime/JSArray.cpp: (JSC::JSArray::unshiftCountSlowCase): (JSC::JSArray::shiftCountWithArrayStorage): (JSC::JSArray::unshiftCountWithArrayStorage): * runtime/JSCell.h: (JSC::JSCell::unvalidatedStructure): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::slowDownAndWasteMemory): * runtime/JSObject.cpp: (JSC::JSObject::copyButterfly): (JSC::JSObject::getOwnPropertySlotByIndex): (JSC::JSObject::putByIndex): (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): (JSC::JSObject::createInitialIndexedStorage): (JSC::JSObject::createArrayStorage): (JSC::JSObject::deletePropertyByIndex): (JSC::JSObject::getOwnPropertyNames): (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): (JSC::JSObject::countElements): (JSC::JSObject::increaseVectorLength): (JSC::JSObject::ensureLengthSlow): * runtime/JSObject.h: (JSC::JSObject::butterfly): (JSC::JSObject::setStructureAndButterfly): (JSC::JSObject::setButterflyWithoutChangingStructure): (JSC::JSObject::JSObject): (JSC::JSObject::putDirectInternal): (JSC::JSObject::putDirectWithoutTransition): * runtime/MapData.cpp: (JSC::MapData::ensureSpaceForAppend): * runtime/Structure.cpp: (JSC::Structure::materializePropertyMap): 2013-12-23 Oliver Hunt Refactor PutPropertySlot to be aware of custom properties https://bugs.webkit.org/show_bug.cgi?id=126187 Reviewed by Antti Koivisto. Refactor PutPropertySlot, making the constructor take the thisValue used as a target. This results in a wide range of boilerplate changes to pass the new parameter. * API/JSObjectRef.cpp: (JSObjectSetProperty): * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Arguments.cpp: (JSC::Arguments::putByIndex): * runtime/ArrayPrototype.cpp: (JSC::putProperty): (JSC::arrayProtoFuncPush): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCell.cpp: (JSC::JSCell::putByIndex): * runtime/JSFunction.cpp: (JSC::JSFunction::put): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::putByIndex): * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::putByIndex): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::deleteProperty): * runtime/JSObject.h: (JSC::JSObject::putDirect): * runtime/Lookup.h: (JSC::putEntry): (JSC::lookupPut): * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::setCustomProperty): (JSC::PutPropertySlot::thisValue): (JSC::PutPropertySlot::isCacheable): 2014-01-01 Filip Pizlo Rationalize DFG DCE https://bugs.webkit.org/show_bug.cgi?id=125523 Reviewed by Mark Hahnenberg. Adds the ability to DCE more things. It's now the case that if a node is completely pure, we clear NodeMustGenerate and the node becomes a DCE candidate. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDCEPhase.cpp: (JSC::DFG::DCEPhase::cleanVariables): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.h: (JSC::DFG::Graph::clobbersWorld): * dfg/DFGNodeType.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileAdd): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileValueAdd): 2014-01-02 Benjamin Poulain Attempt to fix the build of WebCore's code generator on CMake based system https://bugs.webkit.org/show_bug.cgi?id=126271 Reviewed by Sam Weinig. * CMakeLists.txt: 2013-12-30 Commit Queue Unreviewed, rolling out r161157, r161158, r161160, r161161, r161163, and r161165. http://trac.webkit.org/changeset/161157 http://trac.webkit.org/changeset/161158 http://trac.webkit.org/changeset/161160 http://trac.webkit.org/changeset/161161 http://trac.webkit.org/changeset/161163 http://trac.webkit.org/changeset/161165 https://bugs.webkit.org/show_bug.cgi?id=126332 Broke WebKit2 on Mountain Lion (Requested by ap on #webkit). * heap/BlockAllocator.cpp: (JSC::BlockAllocator::~BlockAllocator): (JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock): (JSC::BlockAllocator::waitForRelativeTime): (JSC::BlockAllocator::blockFreeingThreadMain): * heap/BlockAllocator.h: (JSC::BlockAllocator::deallocate): 2013-12-30 Anders Carlsson Fix build. * heap/BlockAllocator.h: 2013-12-30 Anders Carlsson Stop using ThreadCondition in BlockAllocator https://bugs.webkit.org/show_bug.cgi?id=126313 Reviewed by Sam Weinig. * heap/BlockAllocator.cpp: (JSC::BlockAllocator::~BlockAllocator): (JSC::BlockAllocator::waitForDuration): (JSC::BlockAllocator::blockFreeingThreadMain): * heap/BlockAllocator.h: (JSC::BlockAllocator::deallocate): 2013-12-30 Anders Carlsson Stop using ThreadCondition in jsc.cpp https://bugs.webkit.org/show_bug.cgi?id=126311 Reviewed by Sam Weinig. * jsc.cpp: (timeoutThreadMain): (main): 2013-12-30 Anders Carlsson Replace WTF::ThreadingOnce with std::call_once https://bugs.webkit.org/show_bug.cgi?id=126215 Reviewed by Sam Weinig. * dfg/DFGWorklist.cpp: (JSC::DFG::globalWorklist): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): 2013-12-30 Martin Robinson [CMake] [GTK] Add support for GObject introspection https://bugs.webkit.org/show_bug.cgi?id=126162 Reviewed by Daniel Bates. * PlatformGTK.cmake: Add the GIR targets. 2013-12-28 Filip Pizlo Get rid of DFG forward exiting https://bugs.webkit.org/show_bug.cgi?id=125531 Reviewed by Oliver Hunt. This finally gets rid of forward exiting. Forward exiting was always a fragile concept since it involved the compiler trying to figure out how to "roll forward" the execution from some DFG node to the next bytecode index. It was always easy to find counterexamples where it broke, and it has always served as an obstacle to adding compiler improvements - the latest being http://webkit.org/b/125523, which tried to make DCE work for more things. This change finishes the work of removing forward exiting. A lot of forward exiting was already removed in some other bugs, but SetLocal still did forward exits. SetLocal is in many ways the hardest to remove, since the forward exiting of SetLocal also implied that any conversion nodes inserted before the SetLocal would then also be marked as forward-exiting. Hence SetLocal's forward-exiting made a bunch of other things also forward-exiting, and this was always a source of weirdo bugs. SetLocal must be able to exit in case it performs a hoisted type speculation. Nodes inserted just before SetLocal must also be able to exit - for example type check hoisting may insert a CheckStructure, or fixup phase may insert something like Int32ToDouble. But if any of those nodes tried to backward exit, then this could lead to the reexecution of a side-effecting operation, for example: a: Call(...) b: SetLocal(@a, r1) For a long time it seemed like SetLocal *had* to exit forward because of this. But this change side-steps the problem by changing the ByteCodeParser to always emit a kind of "two-phase commit" for stores to local variables. Now when the ByteCodeParser wishes to store to a local, it first emits a MovHint and then enqueues a SetLocal. The SetLocal isn't actually emitted until the beginning of the next bytecode instruction (which the exception of op_enter and op_ret, which emit theirs immediately since it's always safe to reexecute those bytecode instructions and since deferring SetLocals would be weird there - op_enter has many SetLocals and op_ret is a set followed by a jump in case of inlining, so we'd have to emit the SetLocal "after" the jump and that would be awkward). This means that the above IR snippet would look something like: a: Call(..., bc#42) b: MovHint(@a, r1, bc#42) c: SetLocal(@a, r1, bc#47) Where the SetLocal exits "backwards" but appears at the beginning of the next bytecode instruction. This means that by the time we get to that SetLocal, the OSR exit analysis already knows that r1 is associated with @a, and it means that the SetLocal or anything hoisted above it can exit backwards as normal. This change also means that the "forward rewiring" can be killed. Previously, we might have inserted a conversion node on SetLocal and then the SetLocal died (i.e. turned into a MovHint) and the conversion node either died completely or had its lifetime truncated to be less than the actual value's bytecode lifetime. This no longer happens since conversion nodes are only inserted at SetLocals. More precisely, this change introduces two laws that we were basically already following anyway: 1) A MovHint's child should never be changed except if all other uses of that child are also replaced. Specifically, this prohibits insertion of conversion nodes at MovHints. 2) Anytime any child is replaced with something else, and all other uses aren't also replaced, we must insert a Phantom use of the original child. This is a slight compile-time regression but has no effect on code-gen. It unlocks a bunch of optimization opportunities so I think it's worth it. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpAssumingJITType): * bytecode/CodeBlock.h: (JSC::CodeBlock::instructionCount): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): * dfg/DFGArrayifySlowPathGenerator.h: (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::setDirect): (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::eliminate): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGCommon.h: * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDCEPhase.cpp: (JSC::DFG::DCEPhase::run): (JSC::DFG::DCEPhase::fixupBlock): (JSC::DFG::DCEPhase::cleanVariables): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixEdge): (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::run): (JSC::DFG::LICMPhase::attemptHoist): * dfg/DFGMinifiedNode.cpp: (JSC::DFG::MinifiedNode::fromNode): * dfg/DFGMinifiedNode.h: (JSC::DFG::belongsInMinifiedGraph): (JSC::DFG::MinifiedNode::constantNumber): (JSC::DFG::MinifiedNode::weakConstant): * dfg/DFGNode.cpp: (JSC::DFG::Node::hasVariableAccessData): * dfg/DFGNode.h: (JSC::DFG::Node::convertToPhantom): (JSC::DFG::Node::convertToPhantomUnchecked): (JSC::DFG::Node::convertToIdentity): (JSC::DFG::Node::containsMovHint): (JSC::DFG::Node::hasUnlinkedLocal): (JSC::DFG::Node::willHaveCodeGenOrOSR): * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): * dfg/DFGNodeFlags.h: * dfg/DFGNodeType.h: * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::OSRAvailabilityAnalysisPhase::run): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGOSRExit.cpp: * dfg/DFGOSRExit.h: * dfg/DFGOSRExitBase.cpp: * dfg/DFGOSRExitBase.h: (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): (JSC::DFG::PredictionPropagationPhase::doDoubleVoting): * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculationCheck): (JSC::DFG::SpeculativeJIT::emitInvalidationPoint): (JSC::DFG::SpeculativeJIT::typeCheck): (JSC::DFG::SpeculativeJIT::compileMovHint): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::checkArgumentTypes): (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch): (JSC::DFG::SpeculativeJIT::needsTypeCheck): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validateCPS): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::VariableAccessData): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetArgument): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (JSC::FTL::LowerDFGToLLVM::compileMovHint): (JSC::FTL::LowerDFGToLLVM::compileZombieHint): (JSC::FTL::LowerDFGToLLVM::compileInt32ToDouble): (JSC::FTL::LowerDFGToLLVM::speculate): (JSC::FTL::LowerDFGToLLVM::typeCheck): (JSC::FTL::LowerDFGToLLVM::appendTypeCheck): (JSC::FTL::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall): * ftl/FTLOSRExit.cpp: * ftl/FTLOSRExit.h: * tests/stress/dead-int32-to-double.js: Added. (foo): * tests/stress/dead-uint32-to-number.js: Added. (foo): 2013-12-25 Commit Queue Unreviewed, rolling out r161033 and r161074. http://trac.webkit.org/changeset/161033 http://trac.webkit.org/changeset/161074 https://bugs.webkit.org/show_bug.cgi?id=126240 Oliver says that a rollout would be better (Requested by ap on #webkit). * API/JSObjectRef.cpp: (JSObjectSetProperty): * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Arguments.cpp: (JSC::Arguments::putByIndex): * runtime/ArrayPrototype.cpp: (JSC::putProperty): (JSC::arrayProtoFuncPush): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCell.cpp: (JSC::JSCell::putByIndex): * runtime/JSFunction.cpp: (JSC::JSFunction::put): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::putByIndex): * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::putByIndex): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::deleteProperty): * runtime/JSObject.h: (JSC::JSObject::putDirect): * runtime/Lookup.h: (JSC::putEntry): (JSC::lookupPut): * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::setNewProperty): (JSC::PutPropertySlot::isCacheable): 2013-12-25 Filip Pizlo DFG PhantomArguments shouldn't rely on a dead Phi graph https://bugs.webkit.org/show_bug.cgi?id=126218 Reviewed by Oliver Hunt. This change dramatically rationalizes our handling of PhantomArguments (i.e. speculative elision of arguments object allocation). It's now the case that if we decide that we can elide arguments allocation, we just turn the arguments-creating node into a PhantomArguments and mark all locals that it's stored to as being arguments aliases. Being an arguments alias and being a PhantomArguments means basically the same thing: in DFG execution you have the empty value, on OSR exit an arguments object is allocated in your place, and all operations that use the value now just refer directly to the actual arguments in the call frame header (or the arguments we know that we passed to the call, in case of inlining). This means that we no longer have arguments simplification creating a dead Phi graph that then has to be interpreted by the OSR exit logic. That sort of never made any sense. This means that PhantomArguments now has a clear story in SSA: basically SSA just gets rid of the "locals" but everything else is the same. Finally, this means that we can more easily get rid of forward exiting. As I was working on the code to get rid of forward exiting, I realized that I'd have to carefully preserve the special meanings of MovHint and SetLocal in the case of PhantomArguments. It was really bizarre: even the semantics of MovHint were tied to our specific treatment of PhantomArguments. After this change this is no longer the case. One of the really cool things about this change is that arguments reification now just becomes a special kind of FlushFormat. This further unifies things: it means that a MovHint(PhantomArguments) and a SetLocal(PhantomArguments) both have the same meaning, since both of them dictate that the way we recover the local on exit is by reifying arguments. Previously, the SetLocal(PhantomArguments) case needed some special handling to accomplish this. A downside of this approach is that we will now emit code to store the empty value into aliased arguments variables, and we will even emit code to load that empty value as well. As far as I can tell this doesn't cost anything, since PhantomArguments are most profitable in cases where it allows us to simplify control flow and kill the arguments locals entirely. Of course, this isn't an issue in SSA form since SSA form also eliminates the locals. * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): (JSC::DFG::ArgumentsSimplificationPhase::detypeArgumentsReferencingPhantomChild): * dfg/DFGFlushFormat.cpp: (WTF::printInternal): * dfg/DFGFlushFormat.h: (JSC::DFG::resultFor): (JSC::DFG::useKindFor): (JSC::DFG::dataFormatFor): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValueSource.h: (JSC::DFG::ValueSource::ValueSource): (JSC::DFG::ValueSource::forFlushFormat): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::flushFormat): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::buildExitArguments): 2013-12-23 Oliver Hunt Refactor PutPropertySlot to be aware of custom properties https://bugs.webkit.org/show_bug.cgi?id=126187 Reviewed by msaboff. Refactor PutPropertySlot, making the constructor take the thisValue used as a target. This results in a wide range of boilerplate changes to pass the new parameter. * API/JSObjectRef.cpp: (JSObjectSetProperty): * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Arguments.cpp: (JSC::Arguments::putByIndex): * runtime/ArrayPrototype.cpp: (JSC::putProperty): (JSC::arrayProtoFuncPush): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCell.cpp: (JSC::JSCell::putByIndex): * runtime/JSFunction.cpp: (JSC::JSFunction::put): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::putByIndex): * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::putByIndex): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::deleteProperty): * runtime/JSObject.h: (JSC::JSObject::putDirect): * runtime/Lookup.h: (JSC::putEntry): (JSC::lookupPut): * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::setCustomProperty): (JSC::PutPropertySlot::thisValue): (JSC::PutPropertySlot::isCacheable): 2013-12-23 Benjamin Poulain Add class matching to the Selector Code Generator https://bugs.webkit.org/show_bug.cgi?id=126176 Reviewed by Antti Koivisto and Oliver Hunt. Add test and branch based on BaseIndex addressing for x86_64. Fast loops are needed to compete with clang on tight loops. * assembler/MacroAssembler.h: * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::branch64): (JSC::MacroAssemblerX86_64::branchPtr): * assembler/X86Assembler.h: (JSC::X86Assembler::cmpq_rm): 2013-12-23 Oliver Hunt Update custom setter implementations to perform type checks https://bugs.webkit.org/show_bug.cgi?id=126171 Reviewed by Daniel Bates. Modify the setter function signature to take encoded values as we're changing the setter usage everywhere anyway. * runtime/Lookup.h: (JSC::putEntry): 2013-12-23 Lucas Forschler Update copyright strings Reviewed by Dan Bernstein. * Info.plist: * JavaScriptCore.vcxproj/JavaScriptCore.resources/Info.plist: 2013-12-23 Zan Dobersek [GTK] Clean up compiler optimizations flags for libWTF, libJSC https://bugs.webkit.org/show_bug.cgi?id=126157 Reviewed by Gustavo Noronha Silva. * GNUmakefile.am: Remove the -fstrict-aliasing and -O3 compiler flags for libWTF.la. -O3 gets overridden by -O2 that's listed in CXXFLAGS (or -O0 in case of debug builds) and -fstrict-aliasing is enabled when -O2 is used (and shouldn't be enabled in debug builds anyway). 2013-12-22 Martin Robinson [CMake] Fix typo from r160812 https://bugs.webkit.org/show_bug.cgi?id=126145 Reviewed by Gustavo Noronha Silva. * CMakeLists.txt: Fix typo when detecting the type of library. 2013-12-22 Martin Robinson [GTK][CMake] libtool-compatible soversion calculation https://bugs.webkit.org/show_bug.cgi?id=125511 Reviewed by Gustavo Noronha Silva. * CMakeLists.txt: Use the POPULATE_LIBRARY_VERSION macro and the library-specific version information. 2013-12-23 Gustavo Noronha Silva [GTK] [CMake] Generate pkg-config files https://bugs.webkit.org/show_bug.cgi?id=125685 Reviewed by Martin Robinson. * PlatformGTK.cmake: Added. Generate javascriptcoregtk-3.0.pc. 2013-12-22 Benjamin Poulain Create a skeleton for CSS Selector code generation https://bugs.webkit.org/show_bug.cgi?id=126044 Reviewed by Antti Koivisto and Gavin Barraclough. * assembler/LinkBuffer.h: Add a new owner UID for code compiled for CSS. Export the symbols needed to link code from WebCore. 2013-12-19 Mark Hahnenberg Clean up DFG write barriers https://bugs.webkit.org/show_bug.cgi?id=126047 Reviewed by Filip Pizlo. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Use the register allocator to determine which registers need saving instead of saving every single one of them. (JSC::DFG::SpeculativeJIT::osrWriteBarrier): We don't need to save live register state because the write barriers during OSR execute when there are no live registers. Also we don't need to use pushes to pad the stack pointer for pokes on x86; we can just use an add. (JSC::DFG::SpeculativeJIT::writeBarrier): * dfg/DFGSpeculativeJIT.h: * jit/Repatch.cpp: (JSC::emitPutReplaceStub): (JSC::emitPutTransitionStub): * runtime/VM.h: Get rid of writeBarrierRegisterBuffer since it's no longer used. 2013-12-20 Balazs Kilvady [MIPS] Missing MacroAssemblerMIPS::branchTest8(ResultCondition, BaseIndex, TrustedImm32) https://bugs.webkit.org/show_bug.cgi?id=126062 Reviewed by Mark Hahnenberg. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchTest8): 2013-12-20 Julien Brianceau [sh4] Add missing implementation in MacroAssembler to fix build. https://bugs.webkit.org/show_bug.cgi?id=126063 Reviewed by Mark Hahnenberg. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::branchTest8): 2013-12-20 Julien Brianceau [arm] Add missing implementation in MacroAssembler to fix CPU(ARM_TRADITIONAL) build. https://bugs.webkit.org/show_bug.cgi?id=126064 Reviewed by Mark Hahnenberg. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::branchTest8): 2013-12-19 Joseph Pecoraro Web Inspector: Add InspectorFrontendHost.debuggableType to let the frontend know it's backend is JavaScript or Web https://bugs.webkit.org/show_bug.cgi?id=126016 Reviewed by Timothy Hatcher. * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::listingForDebuggable): * inspector/remote/RemoteInspectorConstants.h: Include a debuggable type identifier in the debuggable listing, so the remote frontend can know if it is debugging a Web Page or JS Context. 2013-12-19 Benjamin Poulain Add an utility class to simplify generating function calls https://bugs.webkit.org/show_bug.cgi?id=125972 Reviewed by Geoffrey Garen. Split branchTest32 in two functions: test32AndSetFlags and branchOnFlags. This is done to allow code where the flags are set, multiple operation that do not modify the flags occur, then the flags are used. This is used for function calls to test the return value while discarding the return register. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::test32AndSetFlags): (JSC::MacroAssemblerX86Common::branchOnFlags): (JSC::MacroAssemblerX86Common::branchTest32): 2013-12-19 Mark Hahnenberg Put write barriers in the right places in the baseline JIT https://bugs.webkit.org/show_bug.cgi?id=125975 Reviewed by Filip Pizlo. * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::callOperation): (JSC::JIT::emitArrayProfilingSite): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_enter): (JSC::JIT::emitSlow_op_enter): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_enter): (JSC::JIT::emitSlow_op_enter): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitPutGlobalProperty): (JSC::JIT::emitPutGlobalVar): (JSC::JIT::emitPutClosureVar): (JSC::JIT::emit_op_init_global_const): (JSC::JIT::checkMarkWord): (JSC::JIT::emitWriteBarrier): (JSC::JIT::privateCompilePutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emitPutGlobalProperty): (JSC::JIT::emitPutGlobalVar): (JSC::JIT::emitPutClosureVar): (JSC::JIT::emit_op_init_global_const): * jit/Repatch.cpp: (JSC::emitPutReplaceStub): (JSC::emitPutTransitionStub): (JSC::repatchPutByID): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2013-12-19 Brent Fulgham Implement ArrayBuffer.isView https://bugs.webkit.org/show_bug.cgi?id=126004 Reviewed by Filip Pizlo. Test coverage in webgl/1.0.2/resources/webgl_test_files/conformance/typedarrays/array-unit-tests.html * runtime/JSArrayBufferConstructor.cpp: (JSC::JSArrayBufferConstructor::finishCreation): Add 'isView' to object constructor. (JSC::arrayBufferFuncIsView): New method. 2013-12-19 Mark Lam Fix broken C loop LLINT build. https://bugs.webkit.org/show_bug.cgi?id=126024. Reviewed by Oliver Hunt. * runtime/VM.h: 2013-12-18 Mark Hahnenberg DelayedReleaseScope is in the wrong place https://bugs.webkit.org/show_bug.cgi?id=125876 Reviewed by Geoffrey Garen. The DelayedReleaseScope needs to be around the free list sweeping in MarkedAllocator::tryAllocateHelper. This location gives us a good safe point between getting ready to allocate (i.e. identifying a non-empty free list) and doing the actual allocation (popping the free list). * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateHelper): (JSC::MarkedAllocator::allocateSlowCase): (JSC::MarkedAllocator::addBlock): * runtime/JSCellInlines.h: (JSC::allocateCell): 2013-12-18 Gustavo Noronha Silva [GTK][CMake] make libjavascriptcoregtk a public shared library again https://bugs.webkit.org/show_bug.cgi?id=125512 Reviewed by Martin Robinson. * CMakeLists.txt: use target type instead of SHARED_CORE to decide whether JavaScriptCore is a shared library, since it's always shared for GTK+ regardless of SHARED_CORE. 2013-12-18 Benjamin Poulain Add a simple stack abstraction for x86_64 https://bugs.webkit.org/show_bug.cgi?id=125908 Reviewed by Geoffrey Garen. * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::addPtrNoFlags): Add an explicit abstraction for the "lea" instruction. This is needed by the experimental JIT to have add and substract without changing the flags. This is useful for function calls to test the return value, restore the registers, then branch on the flags from the return value. 2013-12-18 Mark Hahnenberg DFG should have a separate StoreBarrier node https://bugs.webkit.org/show_bug.cgi?id=125530 Reviewed by Filip Pizlo. This is in preparation for GenGC. We use a separate StoreBarrier node instead of making them implicitly part of other nodes so that it's easier to run analyses on them, e.g. for the StoreBarrierElisionPhase. They are inserted during the fixup phase. Initially they do not generate any code. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractHeap.h: * dfg/DFGAbstractInterpreter.h: (JSC::DFG::AbstractInterpreter::isKnownNotCell): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberizeForAllocation): (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): Whenever we insert new nodes that require StoreBarriers, we have to add those new StoreBarriers too. It's important to note that AllocatePropertyStorage and ReallocatePropertyStorage nodes require their StoreBarriers to come after them since they allocate first, which could cause a GC, and then store the resulting buffer into their JSCell, which requires the barrier. If we ever require that write barriers occur before stores, we'll have to split these nodes into AllocatePropertyStorage + StoreBarrier + PutPropertyStorage. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::insertStoreBarrier): * dfg/DFGNode.h: (JSC::DFG::Node::isStoreBarrier): * dfg/DFGNodeType.h: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): (JSC::DFG::SpeculativeJIT::compileStoreBarrier): (JSC::DFG::SpeculativeJIT::genericWriteBarrier): The fast path write barrier check. It loads the byte that contains the mark bit of the object. (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): If the fast path check fails we try to store the cell in the WriteBarrierBuffer so as to avoid frequently flushing all registers in order to make a C call. (JSC::DFG::SpeculativeJIT::writeBarrier): (JSC::DFG::SpeculativeJIT::osrWriteBarrier): More barebones version of the write barrier to be executed during an OSR exit into baseline code. We must do this so that the baseline JIT object and array profiles are properly cleared during GC. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::writeBarrier): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::writeBarrier): * dfg/DFGStoreBarrierElisionPhase.cpp: Added. New DFG phase that does block-local elision of redundant StoreBarriers. Every time a StoreBarrier on a particular object is executed, a bit is set indicating that that object doesn't need any more StoreBarriers. (JSC::DFG::StoreBarrierElisionPhase::StoreBarrierElisionPhase): (JSC::DFG::StoreBarrierElisionPhase::couldCauseGC): Nodes that could cause a GC reset the bits for all of the objects known in the current block. (JSC::DFG::StoreBarrierElisionPhase::allocatesFreshObject): A node that creates a new object automatically sets the bit for that object since if a GC occurred as the result of that object's allocation then that object would not need a barrier since it would be guaranteed to be a young generation object until the next GC point. (JSC::DFG::StoreBarrierElisionPhase::noticeFreshObject): (JSC::DFG::StoreBarrierElisionPhase::getBaseOfStore): (JSC::DFG::StoreBarrierElisionPhase::shouldBeElided): (JSC::DFG::StoreBarrierElisionPhase::elideBarrier): (JSC::DFG::StoreBarrierElisionPhase::handleNode): (JSC::DFG::StoreBarrierElisionPhase::handleBlock): (JSC::DFG::StoreBarrierElisionPhase::run): (JSC::DFG::performStoreBarrierElision): * dfg/DFGStoreBarrierElisionPhase.h: Added. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::flushWriteBarrierBuffer): * heap/Heap.h: (JSC::Heap::writeBarrier): * heap/MarkedBlock.h: (JSC::MarkedBlock::offsetOfMarks): * heap/WriteBarrierBuffer.cpp: Added. The WriteBarrierBuffer buffers a set of JSCells that are awaiting a pending WriteBarrier. This buffer is used by the DFG to avoid the overhead of calling out to C repeatedly to invoke a write barrier on a single JSCell. Instead the DFG has inline code to fill the WriteBarrier buffer until its full, and then to call out to C to flush it. The WriteBarrierBuffer will also be flushed prior to each EdenCollection. (JSC::WriteBarrierBuffer::WriteBarrierBuffer): (JSC::WriteBarrierBuffer::~WriteBarrierBuffer): (JSC::WriteBarrierBuffer::flush): (JSC::WriteBarrierBuffer::reset): (JSC::WriteBarrierBuffer::add): * heap/WriteBarrierBuffer.h: Added. (JSC::WriteBarrierBuffer::currentIndexOffset): (JSC::WriteBarrierBuffer::capacityOffset): (JSC::WriteBarrierBuffer::bufferOffset): * jit/JITOperations.cpp: * jit/JITOperations.h: * runtime/VM.h: 2013-12-18 Carlos Garcia Campos Unreviewed. Fix make distcheck. * GNUmakefile.am: 2013-12-17 Julien Brianceau Fix armv7 and sh4 builds. https://bugs.webkit.org/show_bug.cgi?id=125848 Reviewed by Csaba Osztrogonác. * assembler/ARMv7Assembler.h: Include limits.h for INT_MIN. * assembler/SH4Assembler.h: Include limits.h for INT_MIN. 2013-12-16 Oliver Hunt Avoid indirect function calls for custom getters https://bugs.webkit.org/show_bug.cgi?id=125821 Reviewed by Mark Hahnenberg. Rather than invoking a helper function to perform an indirect call through a function pointer, just have the JIT call the function directly. Unfortunately this only works in JSVALUE64 at the moment as there is not an obvious way to pass two EncodedJSValues uniformly over the various effected JITs. * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArguments): * jit/Repatch.cpp: (JSC::generateProtoChainAccessStub): (JSC::tryBuildGetByIDList): 2013-12-16 Joseph Pecoraro Fix some whitespace issues in inspector code https://bugs.webkit.org/show_bug.cgi?id=125814 Reviewed by Darin Adler. * inspector/protocol/Debugger.json: * inspector/protocol/Runtime.json: * inspector/scripts/CodeGeneratorInspector.py: (Generator.process_command): 2013-12-16 Mark Hahnenberg Add some missing functions to MacroAssembler https://bugs.webkit.org/show_bug.cgi?id=125809 Reviewed by Oliver Hunt. * assembler/AbstractMacroAssembler.h: * assembler/AssemblerBuffer.h: * assembler/LinkBuffer.cpp: * assembler/MacroAssembler.h: (JSC::MacroAssembler::storePtr): (JSC::MacroAssembler::andPtr): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::and64): (JSC::MacroAssemblerARM64::branchTest8): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::branchTest8): * assembler/X86Assembler.h: 2013-12-16 Brent Fulgham [Win] Remove dead code after conversion to VS2013 https://bugs.webkit.org/show_bug.cgi?id=125795 Reviewed by Darin Adler. * API/tests/testapi.c: Remove local nan implementation 2013-12-16 Oliver Hunt Cache getters and custom accessors on the prototype chain https://bugs.webkit.org/show_bug.cgi?id=125602 Reviewed by Michael Saboff. Support caching of custom getters and accessors on the prototype chain. This is relatively trivial and just requires a little work compared to the direct access mode as we're under more register pressure. * bytecode/StructureStubInfo.h: Removed the unsued initGetByIdProto as it was confusing to still have it present. * jit/Repatch.cpp: (JSC::generateProtoChainAccessStub): (JSC::tryCacheGetByID): (JSC::tryBuildGetByIDList): 2013-12-16 Mark Lam Change slow path result to take a void* instead of a ExecState*. https://bugs.webkit.org/show_bug.cgi?id=125802. Reviewed by Filip Pizlo. This is in preparation for C Stack OSR entry work that is coming soon. In the OSR entry case, we'll be returning a topOfFrame pointer value instead of the ExecState*. * offlineasm/cloop.rb: * runtime/CommonSlowPaths.h: (JSC::encodeResult): (JSC::decodeResult): 2013-12-16 Alex Christensen Fixed Win64 build on VS2013. https://bugs.webkit.org/show_bug.cgi?id=125753 Reviewed by Brent Fulgham. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Added correct PlatformToolset for 64-bit builds. 2013-12-16 Peter Szanka Delete RVCT related code parts. https://bugs.webkit.org/show_bug.cgi?id=125626 Reviewed by Darin Adler. * assembler/ARMAssembler.cpp: * assembler/ARMAssembler.h: (JSC::ARMAssembler::cacheFlush): * assembler/MacroAssemblerARM.cpp: (JSC::isVFPPresent): * jit/JITStubsARM.h: * jit/JITStubsARMv7.h: 2013-12-15 Ryosuke Niwa REGRESSION: 2x regression on Dromaeo DOM query tests https://bugs.webkit.org/show_bug.cgi?id=125377 Reviewed by Filip Pizlo. The bug was caused by JSC not JIT'ing property access on "document" due to its type info having HasImpureGetOwnPropertySlot flag. Fixed the bug by new type info flag NewImpurePropertyFiresWatchpoints, which allows the baseline JIT to generate byte code for access properties on an object with named properties (a.k.a. custom name getter) in DOM. When a new named property appears on the object, VM is notified via VM::addImpureProperty and fires StructureStubClearingWatchpoint added during the repatch. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): Take the slow path if we have any object with impure properties in the prototype chain. (JSC::GetByIdStatus::computeForChain): Ditto. * jit/Repatch.cpp: (JSC::repatchByIdSelfAccess): Throw away the byte code when a new impure property is added on any object in the prototype chain via StructureStubClearingWatchpoint. (JSC::generateProtoChainAccessStub): Ditto. (JSC::tryCacheGetByID): (JSC::tryBuildGetByIDList): (JSC::tryRepatchIn): Ditto. * runtime/JSTypeInfo.h: Added NewImpurePropertyFiresWatchpoints. (JSC::TypeInfo::newImpurePropertyFiresWatchpoints): Added. * runtime/Operations.h: (JSC::normalizePrototypeChainForChainAccess): Don't exit early if VM will be notified of new impure property even if the object had impure properties. * runtime/Structure.h: (JSC::Structure::takesSlowPathInDFGForImpureProperty): Added. Wraps hasImpureGetOwnPropertySlot and asserts that newImpurePropertyFiresWatchpoints is true whenever hasImpureGetOwnPropertySlot is true. * runtime/VM.cpp: (JSC::VM::registerWatchpointForImpureProperty): Added. (JSC::VM::addImpureProperty): Added. HTMLDocument calls it to notify JSC of a new impure property. * runtime/VM.h: 2013-12-15 Andy Estes [iOS] Upstream changes to FeatureDefines.xcconfig https://bugs.webkit.org/show_bug.cgi?id=125742 Reviewed by Dan Bernstein. * Configurations/FeatureDefines.xcconfig: 2013-12-14 Filip Pizlo FTL should *really* know when things are flushed https://bugs.webkit.org/show_bug.cgi?id=125747 Reviewed by Sam Weinig. Fix more codegen badness. This makes V8v7's crypto am3() function run faster in the FTL than in DFG. This means that even if we just compile those functions in V8v7 that don't make calls, the FTL gives us a 2% speed-up over the DFG. That's pretty good considering that we have still more optimizations to fix and we can make calls work. * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * ftl/FTLCompile.cpp: (JSC::FTL::fixFunctionBasedOnStackMaps): 2013-12-14 Andy Estes Unify FeatureDefines.xcconfig https://bugs.webkit.org/show_bug.cgi?id=125741 Rubber-stamped by Dan Bernstein. * Configurations/FeatureDefines.xcconfig: Enable ENABLE_MEDIA_SOURCE. 2013-12-14 Mark Rowe Build fix after r160557. r160557 added the first generated header to JavaScriptCore that needs to be installed in to the framework wrapper. Sadly JavaScriptCore's Derived Sources target was not set to generate headers when invoked as part of the installhdrs action. This resulted in the build failing due to Xcode being unable to find the header file to install. The fix for this is to configure the Derived Sources target to use JavaScriptCore.xcconfig, which sets INSTALLHDRS_SCRIPT_PHASE to YES and allows Xcode to generate derived sources during the installhdrs action. Enabling INSTALLHDRS_SCRIPT_PHASE required tweaking the Generate Derived Sources script build phase to skip running code related to offlineasm that depends on JSCLLIntOffsetExtractor having been compiled, which isn't the case at installhdrs time. * JavaScriptCore.xcodeproj/project.pbxproj: 2013-12-13 Joseph Pecoraro Some Set and Map prototype functions have incorrect function lengths https://bugs.webkit.org/show_bug.cgi?id=125732 Reviewed by Oliver Hunt. * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): 2013-12-13 Joseph Pecoraro Web Inspector: Move Inspector and Debugger protocol domains into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=125707 Reviewed by Timothy Hatcher. * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.am: * inspector/protocol/Debugger.json: Renamed from Source/WebCore/inspector/protocol/Debugger.json. * inspector/protocol/GenericTypes.json: Added. * inspector/protocol/InspectorDomain.json: Renamed from Source/WebCore/inspector/protocol/InspectorDomain.json. Add new files to inspector generation. * inspector/scripts/CodeGeneratorInspector.py: (Generator.go): Only build TypeBuilder output if the domain only has types. Avoid backend/frontend dispatchers and backend commands. (TypeBindings.create_type_declaration_.EnumBinding.get_setter_value_expression_pattern): (format_setter_value_expression): (Generator.process_command): (Generator.generate_send_method): * inspector/scripts/CodeGeneratorInspectorStrings.py: Export and name the get{JS,Web}EnumConstant function. 2013-12-11 Filip Pizlo Get rid of forward exit on UInt32ToNumber by adding an op_unsigned bytecode instruction https://bugs.webkit.org/show_bug.cgi?id=125553 Reviewed by Oliver Hunt. UInt32ToNumber was a super complicated node because it had to do a speculation, but it would do it after we already had computed the urshift. It couldn't just back to the beginning of the urshift because the inputs to the urshift weren't necessarily live anymore. We couldn't jump forward to the beginning of the next instruction because the result of the urshift was not yet unsigned-converted. For a while we solved this by forward-exiting in UInt32ToNumber. But that's really gross and I want to get rid of all forward exits. They cause a lot of bugs. We could also have turned UInt32ToNumber to a backwards exit by forcing the inputs to the urshift to be live. I figure that this might be a bit too extreme. So, I just created a new place that we can exit to: I split op_urshift into op_urshift followed by op_unsigned. op_unsigned is an "unsigned cast" along the lines of what UInt32ToNumber does. This allows me to get rid of all of the nastyness in the DFG for forward exiting in UInt32ToNumber. This patch enables massive code carnage in the DFG and FTL, and brings us closer to eliminating one of the DFG's most confusing concepts. On the flipside, it does make the bytecode slightly more complex (one new instruction). This is a profitable trade. We want the DFG and FTL to trend towards simplicity, since they are both currently too complicated. * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/ValueRecovery.cpp: (JSC::ValueRecovery::dumpInContext): * bytecode/ValueRecovery.h: (JSC::ValueRecovery::gpr): * bytecompiler/NodesCodegen.cpp: (JSC::BinaryOpNode::emitBytecode): (JSC::emitReadModifyAssignment): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::toInt32): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGNodeType.h: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileMovHint): (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: * dfg/DFGSpeculativeJIT64.cpp: * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild): (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild1): (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild2): * ftl/FTLFormattedValue.h: (JSC::FTL::int32Value): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber): * ftl/FTLValueFormat.cpp: (JSC::FTL::reboxAccordingToFormat): (WTF::printInternal): * ftl/FTLValueFormat.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_urshift): (JSC::JIT::emitSlow_op_urshift): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emitSlow_op_unsigned): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitRightShift): (JSC::JIT::emitRightShiftSlowCase): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emitSlow_op_unsigned): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2013-12-13 Mark Hahnenberg LLInt should not conditionally branch to to labels outside of its function https://bugs.webkit.org/show_bug.cgi?id=125713 Reviewed by Geoffrey Garen. Conditional branches are insufficient for jumping to out-of-function labels. The fix is to use an unconditional jmp to the label combined with a conditional branch around the jmp. * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2013-12-13 Joseph Pecoraro [GTK] Remove Warnings in building about duplicate INSPECTOR variables https://bugs.webkit.org/show_bug.cgi?id=125710 Reviewed by Tim Horton. * GNUmakefile.am: 2013-12-13 Joseph Pecoraro Cleanup CodeGeneratorInspectorStrings a bit https://bugs.webkit.org/show_bug.cgi?id=125705 Reviewed by Timothy Hatcher. * inspector/scripts/CodeGeneratorInspectorStrings.py: Use ${foo} variable syntax and add an ASCIILiteral. 2013-12-13 Brent Fulgham [Win] Unreviewed build fix after r160563 * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Missed the Debug target in my last patch. 2013-12-13 Brent Fulgham [Win] Unreviewed build fix after r160548 * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Specify that we are using the vs12_xp target for Makefile-based projects. * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Ditto * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Ditto. 2013-12-13 Joseph Pecoraro Make inspector folder groups smarter in JavaScriptCore.xcodeproj https://bugs.webkit.org/show_bug.cgi?id=125663 Reviewed by Darin Adler. * JavaScriptCore.xcodeproj/project.pbxproj: 2013-12-13 Joseph Pecoraro Web Inspector: Add Inspector Code Generation to JavaScriptCore for Runtime Domain https://bugs.webkit.org/show_bug.cgi?id=125595 Reviewed by Timothy Hatcher. - Move CodeGeneration scripts from WebCore into JavaScriptCore/inspector/scripts - For ports that build WebKit frameworks separately, export the scripts as PrivateHeaders - Update CodeGeneratorInspector.py in a few ways: - output dynamic filenames, so JavaScriptCore generates InspectorJSFoo.* and WebCore generates InspectorWebFoo.* - take in more then one protocol JSON file. The first contains domains to generate, the others are dependencies that are generated elsewhere that we can depend on for Types. - Add DerivedSources build step to generate the Inspector Interfaces * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.vcxproj/copy-files.cmd: * JavaScriptCore.xcodeproj/project.pbxproj: Add scripts and code generation. * inspector/protocol/Runtime.json: Renamed from Source/WebCore/inspector/protocol/Runtime.json. Move protocol file into JavaScriptCore so its types will be generated in JavaScriptCore. * inspector/scripts/CodeGeneratorInspector.py: Renamed from Source/WebCore/inspector/CodeGeneratorInspector.py. Updates to the script as listed above. * inspector/scripts/CodeGeneratorInspectorStrings.py: Renamed from Source/WebCore/inspector/CodeGeneratorInspectorStrings.py. * inspector/scripts/generate-combined-inspector-json.py: Renamed from Source/WebCore/inspector/Scripts/generate-combined-inspector-json.py. Moved from WebCore into JavaScriptCore for code generation. 2013-12-13 Peter Szanka Delete INTEL C compiler related code parts. https://bugs.webkit.org/show_bug.cgi?id=125625 Reviewed by Darin Adler. * jsc.cpp: * testRegExp.cpp: 2013-12-13 Brent Fulgham [Win] Switch WebKit solution to Visual Studio 2013 https://bugs.webkit.org/show_bug.cgi?id=125192 Reviewed by Anders Carlsson. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Update for VS2013 * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Ditto * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Ditto * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Ditto * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Ditto 2013-12-12 Joseph Pecoraro Add a few more ASCIILiterals https://bugs.webkit.org/show_bug.cgi?id=125662 Reviewed by Darin Adler. * inspector/InspectorBackendDispatcher.cpp: (Inspector::InspectorBackendDispatcher::dispatch): 2013-12-12 Joseph Pecoraro Test new JSContext name APIs https://bugs.webkit.org/show_bug.cgi?id=125607 Reviewed by Darin Adler. * API/JSContext.h: * API/JSContextRef.h: Fix whitespace issues. * API/tests/testapi.c: (globalContextNameTest): (main): * API/tests/testapi.mm: Add tests for JSContext set/get name APIs. 2013-12-11 Filip Pizlo ARM64: Hang running pdfjs test, suspect DFG generated code for "in" https://bugs.webkit.org/show_bug.cgi?id=124727 Reviewed by Michael Saboff. Get rid of In's hackish use of StructureStubInfo. Previously it was using hotPathBegin, and it was the only IC that used that field, which was wasteful. Moreover, it used it to store two separate locations: the label for patching the jump and the label right after the jump. The code was relying on those two being the same label, which is true on X86 and some other platforms, but it isn't true on ARM64. This gets rid of hotPathBegin and makes In express those two locations as offsets from the callReturnLocation, which is analogous to what the other IC's do. This fixes a bug where any successful In patching would result in a trivially infinite loop - and hence a hang - on ARM64. * bytecode/StructureStubInfo.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::InRecord::InRecord): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileIn): * jit/JITInlineCacheGenerator.cpp: (JSC::JITByIdGenerator::finalize): * jit/Repatch.cpp: (JSC::replaceWithJump): (JSC::patchJumpToGetByIdStub): (JSC::tryCachePutByID): (JSC::tryBuildPutByIdList): (JSC::tryRepatchIn): (JSC::resetGetByID): (JSC::resetPutByID): (JSC::resetIn): 2013-12-11 Joseph Pecoraro Web Inspector: Push More Inspector Required Classes Down into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=125324 Reviewed by Timothy Hatcher. * CMakeLists.txt: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: * JavaScriptCore.vcxproj/copy-files.cmd: * JavaScriptCore.xcodeproj/project.pbxproj: * bindings/ScriptFunctionCall.cpp: Renamed from Source/WebCore/bindings/js/ScriptFunctionCall.cpp. * bindings/ScriptFunctionCall.h: Renamed from Source/WebCore/bindings/js/ScriptFunctionCall.h. * bindings/ScriptObject.cpp: Copied from Source/WebCore/inspector/WorkerConsoleAgent.cpp. * bindings/ScriptObject.h: Renamed from Source/WebCore/inspector/InspectorBaseAgent.h. * bindings/ScriptValue.cpp: Renamed from Source/WebCore/bindings/js/ScriptValue.cpp. * bindings/ScriptValue.h: Renamed from Source/WebCore/bindings/js/ScriptValue.h. * inspector/InspectorAgentBase.h: Copied from Source/WebCore/inspector/InspectorAgentRegistry.h. * inspector/InspectorAgentRegistry.cpp: Renamed from Source/WebCore/inspector/InspectorAgentRegistry.cpp. * inspector/InspectorBackendDispatcher.h: Renamed from Source/WebCore/inspector/InspectorBackendDispatcher.h. (Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher): (Inspector::InspectorSupplementalBackendDispatcher::~InspectorSupplementalBackendDispatcher): * inspector/InspectorValues.cpp: Renamed from Source/WebCore/inspector/InspectorValues.cpp. * inspector/InspectorValues.h: Renamed from Source/WebCore/inspector/InspectorValues.h. 2013-12-11 Laszlo Vidacs Store SHA1 hash in std::array https://bugs.webkit.org/show_bug.cgi?id=125446 Reviewed by Darin Adler. Change Vector to std::array and use typedef. * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::CodeBlockHash): 2013-12-11 Mark Rowe Modernize the JavaScriptCore API headers This consists of three main changes: 1) Converting the return type of initializer methods to instancetype. 2) Declaring properties rather than getters and setters. 3) Tagging C API methods with information about their memory management semantics. Changing the declarations from getters and setters to properties also required updating the headerdoc in a number of places. Reviewed by Anders Carlsson. * API/JSContext.h: * API/JSContext.mm: * API/JSManagedValue.h: * API/JSManagedValue.mm: * API/JSStringRefCF.h: * API/JSValue.h: * API/JSVirtualMachine.h: * API/JSVirtualMachine.mm: 2013-12-11 Mark Rowe Move JavaScriptCore off the legacy WebKit availability macros The legacy WebKit availability macros are verbose, confusing, and provide no benefit over using the system availability macros directly. The original vision was that they'd serve a cross-platform purpose but that never came to be. Map from WebKit version to OS X version based on the mapping in WebKitAvailability.h. All iOS versions are specified as 7.0 as that is when the JavaScriptCore C API was made public. Part of . Reviewed by Anders Carlsson. * API/JSBasePrivate.h: * API/JSContextRef.h: * API/JSContextRefPrivate.h: * API/JSObjectRef.h: * API/JSValueRef.h: 2013-12-10 Filip Pizlo Get rid of forward exit on DoubleAsInt32 https://bugs.webkit.org/show_bug.cgi?id=125552 Reviewed by Oliver Hunt. The forward exit was just there so that we wouldn't have to keep the inputs alive up to the DoubleAsInt32. That's dumb. Forward exits are a complicated piece of machinery and we shouldn't have it just for a bit of liveness micro-optimization. Also add a bunch of machinery to test this case on X86. * assembler/AbstractMacroAssembler.h: (JSC::optimizeForARMv7s): (JSC::optimizeForARM64): (JSC::optimizeForX86): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32): * runtime/Options.h: * tests/stress/double-as-int32.js: Added. (foo): (test): 2013-12-10 Filip Pizlo Simplify CSE's treatment of NodeRelevantToOSR https://bugs.webkit.org/show_bug.cgi?id=125538 Reviewed by Oliver Hunt. Make the NodeRelevantToOSR thing obvious: if there is any MovHint on a node then the node is relevant to OSR. * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::run): (JSC::DFG::CSEPhase::performNodeCSE): (JSC::DFG::CSEPhase::performBlockCSE): 2013-12-10 Filip Pizlo Get rid of forward exit in GetByVal on Uint32Array https://bugs.webkit.org/show_bug.cgi?id=125543 Reviewed by Oliver Hunt. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetByVal): 2013-12-10 Balazs Kilvady [MIPS] Redundant instructions in code generated from offlineasm. https://bugs.webkit.org/show_bug.cgi?id=125528 Reviewed by Michael Saboff. Optimize lowering of offlineasm BaseIndex Addresses. * offlineasm/mips.rb: 2013-12-10 Oliver Hunt Reduce the mass templatizing of the JS parser https://bugs.webkit.org/show_bug.cgi?id=125535 Reviewed by Michael Saboff. The various caches we have now have removed the need for many of the template vs. regular parameters. This patch converts those template parameters to regular parameters and updates the call sites. This reduces the code size of the parser by around 15%. * parser/ASTBuilder.h: (JSC::ASTBuilder::createGetterOrSetterProperty): (JSC::ASTBuilder::createProperty): * parser/Parser.cpp: (JSC::::parseInner): (JSC::::parseSourceElements): (JSC::::parseVarDeclarationList): (JSC::::createBindingPattern): (JSC::::tryParseDeconstructionPatternExpression): (JSC::::parseDeconstructionPattern): (JSC::::parseSwitchClauses): (JSC::::parseSwitchDefaultClause): (JSC::::parseBlockStatement): (JSC::::parseFormalParameters): (JSC::::parseFunctionInfo): (JSC::::parseFunctionDeclaration): (JSC::::parseProperty): (JSC::::parseObjectLiteral): (JSC::::parseStrictObjectLiteral): (JSC::::parseMemberExpression): * parser/Parser.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createProperty): (JSC::SyntaxChecker::createGetterOrSetterProperty): 2013-12-10 Mark Hahnenberg ASSERT !heap.vm()->isInitializingObject() when finishing DFG compilation at beginning of GC https://bugs.webkit.org/show_bug.cgi?id=125472 Reviewed by Geoff Garen. This patch makes it look like it's okay to allocate so that the DFG plan finalization stuff can do what it needs to do. We already expected that we might do allocation during plan finalization and we increased the deferral depth to handle this, but we need to fix this other ASSERT stuff too. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/Heap.cpp: (JSC::Heap::collect): * heap/Heap.h: * heap/RecursiveAllocationScope.h: Added. (JSC::RecursiveAllocationScope::RecursiveAllocationScope): (JSC::RecursiveAllocationScope::~RecursiveAllocationScope): * runtime/VM.h: 2013-12-09 Filip Pizlo Impose and enforce some basic rules of sanity for where Phi functions are allowed to occur and where their (optional) corresponding MovHints can be https://bugs.webkit.org/show_bug.cgi?id=125480 Reviewed by Geoffrey Garen. Previously, if you wanted to insert some speculation right after where a value was produced, you'd get super confused if that value was produced by a Phi node. You can't necessarily insert speculations after a Phi node because Phi nodes appear in this special sequence of Phis and MovHints that establish the OSR exit state for a block. So, you'd probably want to search for the next place where it's safe to insert things. We already do this "search for beginning of next bytecode instruction" search by looking at the next node that has a different CodeOrigin. But this would be hard for a Phi because those Phis and MovHints have basically random CodeOrigins and they can all have different CodeOrigins. This change imposes some sanity for this situation: - Phis must have unset CodeOrigins. - In each basic block, all nodes that have unset CodeOrigins must come before all nodes that have set CodeOrigins. This all ends up working out just great because prior to this change we didn't have a use for unset CodeOrigins. I think it's appropriate to make "unset CodeOrigin" mean that we're in the prologue of a basic block. It's interesting what this means for block merging, which we don't yet do in SSA. Consider merging the edge A->B. One possibility is that the block merger is now required to clean up Phi/Upsilons, and reascribe the MovHints to have the CodeOrigin of the A's block terminal. But an answer that might be better is that the originless nodes at the top of the B are just given the origin of the terminal and we keep the Phis. That would require changing the above rules. We'll see how it goes, and what we end up picking... Overall, this special-things-at-the-top rule is analogous to what other SSA-based compilers do. For example, LLVM has rules mandating that Phis appear at the top of a block. * bytecode/CodeOrigin.cpp: (JSC::CodeOrigin::dump): * dfg/DFGOSRExitBase.h: (JSC::DFG::OSRExitBase::OSRExitBase): * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validate): (JSC::DFG::Validate::validateSSA): 2013-12-08 Filip Pizlo Reveal array bounds checks in DFG IR https://bugs.webkit.org/show_bug.cgi?id=125253 Reviewed by Oliver Hunt and Mark Hahnenberg. In SSA mode, this reveals array bounds checks and the load of array length in DFG IR, making this a candidate for LICM. This also fixes a long-standing performance bug where the JSObject slow paths would always create contiguous storage, rather than type-specialized storage, when doing a "storage creating" storage, like: var o = {}; o[0] = 42; * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/ExitKind.cpp: (JSC::exitKindToString): (JSC::exitKindIsCountable): * bytecode/ExitKind.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGArrayMode.cpp: (JSC::DFG::permitsBoundsCheckLowering): (JSC::DFG::ArrayMode::permitsBoundsCheckLowering): * dfg/DFGArrayMode.h: (JSC::DFG::ArrayMode::lengthNeedsStorage): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSSALoweringPhase.cpp: Added. (JSC::DFG::SSALoweringPhase::SSALoweringPhase): (JSC::DFG::SSALoweringPhase::run): (JSC::DFG::SSALoweringPhase::handleNode): (JSC::DFG::SSALoweringPhase::lowerBoundsCheck): (JSC::DFG::performSSALowering): * dfg/DFGSSALoweringPhase.h: Added. * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileCheckInBounds): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::contiguousPutByValOutOfBounds): * runtime/JSObject.cpp: (JSC::JSObject::convertUndecidedForValue): (JSC::JSObject::createInitialForValueAndSet): (JSC::JSObject::putByIndexBeyondVectorLength): (JSC::JSObject::putDirectIndexBeyondVectorLength): * runtime/JSObject.h: * tests/stress/float32array-out-of-bounds.js: Added. (make): (foo): (test): * tests/stress/int32-object-out-of-bounds.js: Added. (make): (foo): (test): * tests/stress/int32-out-of-bounds.js: Added. (foo): (test): 2013-12-09 Sam Weinig Replace use of WTF::FixedArray with std::array https://bugs.webkit.org/show_bug.cgi?id=125475 Reviewed by Anders Carlsson. * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::dump): * bytecode/Opcode.cpp: (JSC::OpcodeStats::~OpcodeStats): * dfg/DFGCSEPhase.cpp: * ftl/FTLAbstractHeap.h: * heap/MarkedSpace.h: * parser/ParserArena.h: * runtime/CodeCache.h: * runtime/DateInstanceCache.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): * runtime/JSGlobalObject.h: * runtime/JSString.h: * runtime/LiteralParser.h: * runtime/NumericStrings.h: * runtime/RegExpCache.h: * runtime/SmallStrings.h: 2013-12-09 Joseph Pecoraro Remove miscellaneous unnecessary build statements https://bugs.webkit.org/show_bug.cgi?id=125466 Reviewed by Darin Adler. * DerivedSources.make: * JavaScriptCore.vcxproj/build-generated-files.sh: * JavaScriptCore.xcodeproj/project.pbxproj: * make-generated-sources.sh: 2013-12-08 Filip Pizlo CSE should work in SSA https://bugs.webkit.org/show_bug.cgi?id=125430 Reviewed by Oliver Hunt and Mark Hahnenberg. * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::run): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): 2013-12-09 Joseph Pecoraro Remove docs/make-bytecode-docs.pl https://bugs.webkit.org/show_bug.cgi?id=125462 This sript is very old and no longer outputs useful data since the op code definitions have moved from Interpreter.cpp. Reviewed by Darin Adler. * DerivedSources.make: * docs/make-bytecode-docs.pl: Removed. 2013-12-09 Julien Brianceau Fix sh4 LLINT build. https://bugs.webkit.org/show_bug.cgi?id=125454 Reviewed by Michael Saboff. In LLINT, sh4 backend implementation didn't handle properly conditional jumps using a LabelReference instance. This patch fixes it through sh4LowerMisplacedLabels phase. Also, to avoid the need of a 4th temporary gpr, this phase is triggered later in getModifiedListSH4. * offlineasm/sh4.rb: 2013-12-08 Filip Pizlo Add the notion of ConstantStoragePointer to DFG IR https://bugs.webkit.org/show_bug.cgi?id=125395 Reviewed by Oliver Hunt. This pushes more typed array folding into StrengthReductionPhase, and enables CSE on storage pointers. Previously, you might have separate nodes for the same storage pointer and this would cause some bad register pressure in the DFG. Note that this was really a theoretical problem and not, to my knowledge a practical one - so this patch is basically just a clean-up. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::constantStoragePointerCSE): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::convertToConstantStoragePointer): (JSC::DFG::Node::hasStoragePointer): (JSC::DFG::Node::storagePointer): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileConstantStoragePointer): (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant): (JSC::DFG::StrengthReductionPhase::prepareToFoldTypedArray): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileConstantStoragePointer): (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage): 2013-12-08 Filip Pizlo FTL should support UntypedUse versions of Compare nodes https://bugs.webkit.org/show_bug.cgi?id=125426 Reviewed by Oliver Hunt. This adds UntypedUse versions of all comparisons except CompareStrictEq, which is sufficiently different that I thought I'd do it in another patch. This also extends our ability to abstract over comparison kind and removes a bunch of copy-paste code. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileCompareEq): (JSC::FTL::LowerDFGToLLVM::compileCompareLess): (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq): (JSC::FTL::LowerDFGToLLVM::compileCompareGreater): (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq): (JSC::FTL::LowerDFGToLLVM::compare): (JSC::FTL::LowerDFGToLLVM::nonSpeculativeCompare): * ftl/FTLOutput.h: (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::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): * tests/stress/untyped-equality.js: Added. (foo): * tests/stress/untyped-less-than.js: Added. (foo): 2013-12-07 Filip Pizlo Fold typedArray.length if typedArray is constant https://bugs.webkit.org/show_bug.cgi?id=125252 Reviewed by Sam Weinig. This was meant to be easy. The problem is that there was no good place for putting the folding of typedArray.length to a constant. You can't quite do it in the bytecode parser because at that point you don't yet know if typedArray is really a typed array. You can't do it as part of constant folding because the folder assumes that it can opportunistically forward-flow a constant value without changing the IR; this doesn't work since we need to first change the IR to register a desired watchpoint and only after that can we introduce that constant. We could have done it in Fixup but that would have been awkward since Fixup's code for turning a GetById of "length" into GetArrayLength is already somewhat complex. We could have done it in CSE but CSE is already fairly gnarly and will probably get rewritten. So I introduced a new phase, called StrengthReduction. This phase should have any transformations that don't requite CFA or CSE and that it would be weird to put into those other phases. I also took the opportunity to refactor some of the other folding code. This also adds a test, but the test couldn't quite be a LayoutTests/js/regress so I introduced the notion of JavaScriptCore/tests/stress. The goal of this patch isn't really to improve performance or anything like that. It adds an optimization for completeness, and in doing so it unlocks a bunch of new possibilities. The one that I'm most excited about is revealing array length checks in DFG IR, which will allow for array bounds check hoisting and elimination. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetFoldableView): (JSC::DFG::Graph::tryGetFoldableViewForChild1): * dfg/DFGGraph.h: * dfg/DFGNode.h: (JSC::DFG::Node::hasTypedArray): (JSC::DFG::Node::typedArray): * dfg/DFGNodeType.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds): (JSC::DFG::SpeculativeJIT::compileConstantIndexedPropertyStorage): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: Added. (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase): (JSC::DFG::StrengthReductionPhase::run): (JSC::DFG::StrengthReductionPhase::handleNode): (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant): (JSC::DFG::performStrengthReduction): * dfg/DFGStrengthReductionPhase.h: Added. * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::typedArrayLength): * jsc.cpp: (GlobalObject::finishCreation): (functionTransferArrayBuffer): * runtime/ArrayBufferView.h: * tests/stress: Added. * tests/stress/fold-typed-array-properties.js: Added. (foo): 2013-12-07 [email protected] [Win][64-bit] Hitting breakpoint assembler instruction in callToJavaScript. https://bugs.webkit.org/show_bug.cgi?id=125382 Reviewed by Michael Saboff. The WinCairo results from run-javascriptcore-tests are the same as the WinCairo 32-bits results, when removing these breakpoints. * jit/JITStubsMSVC64.asm: Remove breakpoint instructions. 2013-12-06 Filip Pizlo FTL should support all of Branch/LogicalNot https://bugs.webkit.org/show_bug.cgi?id=125370 Reviewed by Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::boolify): 2013-12-06 Roger Fong and Brent Fulgham [Win] Support compiling with VS2013 https://bugs.webkit.org/show_bug.cgi?id=125353 Reviewed by Anders Carlsson. * API/tests/testapi.c: Use C99 defines if available. * jit/JITOperations.cpp: Don't attempt to define C linkage when returning a C++ object. 2013-12-06 Filip Pizlo FTL should support generic ByVal accesses https://bugs.webkit.org/show_bug.cgi?id=125368 Reviewed by Mark Hahnenberg. * dfg/DFGGraph.h: (JSC::DFG::Graph::isStrictModeFor): (JSC::DFG::Graph::ecmaModeFor): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): 2013-12-06 Filip Pizlo FTL should support hole/OOB array accesses https://bugs.webkit.org/show_bug.cgi?id=118077 Reviewed by Oliver Hunt and Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::baseIndex): 2013-12-06 Michael Saboff Split sizing of VarArgs frames from loading arguments for the frame https://bugs.webkit.org/show_bug.cgi?id=125331 Reviewed by Filip Pizlo. Split loadVarargs into sizeAndAllocFrameForVarargs() and loadVarargs() in preparation for moving onto the C stack. sizeAndAllocFrameForVarargs() will compute the size of the callee frame and allocate it, while loadVarargs() actually loads the argument values. As part of moving onto the C stack, sizeAndAllocFrameForVarargs() will be changed to a function that just computes the size. The caller will use that size to allocate the new frame on the stack before calling loadVargs() and actually making the call. * interpreter/Interpreter.cpp: (JSC::sizeAndAllocFrameForVarargs): (JSC::loadVarargs): * interpreter/Interpreter.h: * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITCall32_64.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/VM.h: 2013-12-06 Filip Pizlo FTL should support all of ValueToInt32 https://bugs.webkit.org/show_bug.cgi?id=125283 Reviewed by Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileValueToInt32): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::lowCell): (JSC::FTL::LowerDFGToLLVM::isCell): 2013-12-06 Filip Pizlo FTL shouldn't have a doubleToUInt32 path https://bugs.webkit.org/show_bug.cgi?id=125360 Reviewed by Mark Hahnenberg. This code existed because I incorrectly thought it was necessary. It's now basically dead. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compilePutByVal): 2013-12-06 Laszlo Vidacs Define SHA1 hash size in SHA1.h and use it at various places. https://bugs.webkit.org/show_bug.cgi?id=125345 Reviewed by Darin Adler. Use SHA1::hashSize instead of local variables. * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::CodeBlockHash): use SHA1::hashSize 2013-12-05 Michael Saboff REGRESSION(r160213): Crash in js/dom/JSON-parse.html https://bugs.webkit.org/show_bug.cgi?id=125335 Reviewed by Mark Lam. Changed _llint_op_catch to materialize the VM via the scope chain instead of the CodeBlock. CallFrames always have a scope chain, but may have a null CodeBlock. * llint/LowLevelInterpreter32_64.asm: (_llint_op_catch): * llint/LowLevelInterpreter64.asm: (_llint_op_catch): 2013-12-05 Michael Saboff JSC: Simplify interface between throw and catch handler https://bugs.webkit.org/show_bug.cgi?id=125328 Reviewed by Geoffrey Garen. Simplified the throw - catch interface. The throw side is only responsible for jumping to the appropriate op_catch handler or returnFromJavaScript for uncaught exceptions. The handler uses the exception values like VM.callFrameForThrow as appropriate and no longer relies on the throw side putting anything in registers. * jit/CCallHelpers.h: (JSC::CCallHelpers::jumpToExceptionHandler): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_catch): * llint/LowLevelInterpreter32_64.asm: (_llint_op_catch): (_llint_throw_from_slow_path_trampoline): * llint/LowLevelInterpreter64.asm: (_llint_op_catch): (_llint_throw_from_slow_path_trampoline): 2013-12-04 Oliver Hunt Refactor static getter function prototype to include thisValue in addition to the base object https://bugs.webkit.org/show_bug.cgi?id=124461 Reviewed by Geoffrey Garen. Add thisValue parameter to static getter prototype, and switch from JSValue to EncodedJSValue for parameters and return value. Currently none of the static getters use the thisValue, but separating out the refactoring will prevent future changes from getting lost in the noise of refactoring. This means that this patch does not result in any change in behaviour. * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::::asCallbackObject): (JSC::::staticFunctionGetter): (JSC::::callbackGetter): * jit/JITOperations.cpp: * runtime/JSActivation.cpp: (JSC::JSActivation::argumentsGetter): * runtime/JSActivation.h: * runtime/JSFunction.cpp: (JSC::JSFunction::argumentsGetter): (JSC::JSFunction::callerGetter): (JSC::JSFunction::lengthGetter): (JSC::JSFunction::nameGetter): * runtime/JSFunction.h: * runtime/JSObject.h: (JSC::PropertySlot::getValue): * runtime/NumberConstructor.cpp: (JSC::numberConstructorNaNValue): (JSC::numberConstructorNegInfinity): (JSC::numberConstructorPosInfinity): (JSC::numberConstructorMaxValue): (JSC::numberConstructorMinValue): * runtime/PropertySlot.h: * runtime/RegExpConstructor.cpp: (JSC::asRegExpConstructor): (JSC::regExpConstructorDollar1): (JSC::regExpConstructorDollar2): (JSC::regExpConstructorDollar3): (JSC::regExpConstructorDollar4): (JSC::regExpConstructorDollar5): (JSC::regExpConstructorDollar6): (JSC::regExpConstructorDollar7): (JSC::regExpConstructorDollar8): (JSC::regExpConstructorDollar9): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): * runtime/RegExpObject.cpp: (JSC::asRegExpObject): (JSC::regExpObjectGlobal): (JSC::regExpObjectIgnoreCase): (JSC::regExpObjectMultiline): (JSC::regExpObjectSource): 2013-12-04 Filip Pizlo FTL should use cvttsd2si directly for double-to-int32 conversions https://bugs.webkit.org/show_bug.cgi?id=125275 Reviewed by Michael Saboff. Wow. This was an ordeal. Using cvttsd2si was actually easy, but I learned, and sometimes even fixed, some interesting things: - The llvm.x86.sse2.cvttsd2si intrinsic can actually result in LLVM emitting a vcvttsd2si. I guess the intrinsic doesn't actually imply the instruction. - That whole thing about branchTruncateDoubleToUint32? Yeah we don't need that. It's better to use branchTruncateDoubleToInt32 instead. It has the right semantics for all of its callers (err, its one-and-only caller), and it's more likely to take fast path. This patch kills branchTruncateDoubleToUint32. - "a[i] = v; v = a[i]". Does this change v? OK, assume that 'a[i]' is a pure-ish operation - like an array access with 'i' being an integer index and we're not having a bad time. Now does this change v? CSE assumes that it doesn't. That's wrong. If 'a' is a typed array - the most sensible and pure kind of array - then this can be a truncating cast. For example 'v' could be a double and 'a' could be an integer array. - "v1 = a[i]; v2 = a[i]". Is v1 === v2 assuming that 'a[i]' is pure-ish? The answer is no. You could have a different arrayMode in each access. I know this sounds weird, but with concurrent JIT that might happen. This patch adds tests for all of this stuff, except for the first issue (it's weird but probably doesn't matter) and the last issue (it's too much of a freakshow). * assembler/MacroAssemblerARM64.h: * assembler/MacroAssemblerARMv7.h: * assembler/MacroAssemblerX86Common.h: * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::getByValLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): * ftl/FTLAbbreviations.h: (JSC::FTL::vectorType): (JSC::FTL::getUndef): (JSC::FTL::buildInsertElement): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::doubleToInt32): (JSC::FTL::LowerDFGToLLVM::doubleToUInt32): (JSC::FTL::LowerDFGToLLVM::sensibleDoubleToInt32): * ftl/FTLOutput.h: (JSC::FTL::Output::insertElement): (JSC::FTL::Output::hasSensibleDoubleToInt): (JSC::FTL::Output::sensibleDoubleToInt): 2013-12-05 Commit Queue Unreviewed, rolling out r160133. http://trac.webkit.org/changeset/160133 https://bugs.webkit.org/show_bug.cgi?id=125325 broke bindings tests on all the bots (Requested by thorton on #webkit). * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::::staticFunctionGetter): (JSC::::callbackGetter): * jit/JITOperations.cpp: * runtime/JSActivation.cpp: (JSC::JSActivation::argumentsGetter): * runtime/JSActivation.h: * runtime/JSFunction.cpp: (JSC::JSFunction::argumentsGetter): (JSC::JSFunction::callerGetter): (JSC::JSFunction::lengthGetter): (JSC::JSFunction::nameGetter): * runtime/JSFunction.h: * runtime/JSObject.h: (JSC::PropertySlot::getValue): * runtime/NumberConstructor.cpp: (JSC::numberConstructorNaNValue): (JSC::numberConstructorNegInfinity): (JSC::numberConstructorPosInfinity): (JSC::numberConstructorMaxValue): (JSC::numberConstructorMinValue): * runtime/PropertySlot.h: * runtime/RegExpConstructor.cpp: (JSC::regExpConstructorDollar1): (JSC::regExpConstructorDollar2): (JSC::regExpConstructorDollar3): (JSC::regExpConstructorDollar4): (JSC::regExpConstructorDollar5): (JSC::regExpConstructorDollar6): (JSC::regExpConstructorDollar7): (JSC::regExpConstructorDollar8): (JSC::regExpConstructorDollar9): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): * runtime/RegExpObject.cpp: (JSC::regExpObjectGlobal): (JSC::regExpObjectIgnoreCase): (JSC::regExpObjectMultiline): (JSC::regExpObjectSource): 2013-12-05 Mark Lam Make the C Loop LLINT work with callToJavaScript. https://bugs.webkit.org/show_bug.cgi?id=125294. Reviewed by Michael Saboff. 1. Changed the C Loop LLINT to dispatch to an Executable via its JITCode instance which is consistent with how the ASM LLINT works. 2. Changed CLoop::execute() to take an Opcode instead of an OpcodeID. This makes it play nice with the use of JITCode for dispatching. 3. Introduce a callToJavaScript and callToNativeFunction for the C Loop LLINT. These will call JSStack::pushFrame() and popFrame() to setup and teardown the CallFrame. 4. Also introduced a C Loop returnFromJavaScript which is just a replacement for ctiOpThrowNotCaught which had the same function. 5. Remove a lot of #if ENABLE(LLINT_C_LOOP) code now that the dispatch mechanism is consistent. This patch has been tested with both configurations of COMPUTED_GOTOs on and off. * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): (JSC::CachedCall::call): (JSC::CachedCall::setArgument): * interpreter/CallFrameClosure.h: (JSC::CallFrameClosure::setThis): (JSC::CallFrameClosure::setArgument): (JSC::CallFrameClosure::resetCallFrame): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): * interpreter/Interpreter.h: * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::pushFrame): * interpreter/ProtoCallFrame.h: (JSC::ProtoCallFrame::scope): (JSC::ProtoCallFrame::callee): (JSC::ProtoCallFrame::thisValue): (JSC::ProtoCallFrame::argument): (JSC::ProtoCallFrame::setArgument): * jit/JITCode.cpp: (JSC::JITCode::execute): * jit/JITCode.h: * jit/JITExceptions.cpp: (JSC::genericUnwind): * llint/LLIntCLoop.cpp: (JSC::LLInt::CLoop::initialize): * llint/LLIntCLoop.h: * llint/LLIntEntrypoint.cpp: (JSC::LLInt::setFunctionEntrypoint): (JSC::LLInt::setEvalEntrypoint): (JSC::LLInt::setProgramEntrypoint): - Inverted the check for vm.canUseJIT(). This allows the JIT case to be #if'd out nicely when building the C Loop LLINT. * llint/LLIntOpcode.h: * llint/LLIntThunks.cpp: (JSC::doCallToJavaScript): (JSC::executeJS): (JSC::callToJavaScript): (JSC::executeNative): (JSC::callToNativeFunction): * llint/LLIntThunks.h: * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): * runtime/Executable.h: (JSC::ExecutableBase::offsetOfNumParametersFor): (JSC::ExecutableBase::hostCodeEntryFor): (JSC::ExecutableBase::jsCodeEntryFor): (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor): (JSC::NativeExecutable::create): (JSC::NativeExecutable::finishCreation): (JSC::ProgramExecutable::generatedJITCode): * runtime/JSArray.cpp: (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): * runtime/StringPrototype.cpp: (JSC::replaceUsingRegExpSearch): * runtime/VM.cpp: (JSC::VM::getHostFunction): 2013-12-05 Laszlo Vidacs Fix JavaScriptCore build if cloop is enabled after r160094 https://bugs.webkit.org/show_bug.cgi?id=125292 Reviewed by Michael Saboff. Move ProtoCallFrame outside the JIT guard. * jit/JITCode.h: 2013-12-04 Filip Pizlo Fold constant typed arrays https://bugs.webkit.org/show_bug.cgi?id=125205 Reviewed by Oliver Hunt and Mark Hahnenberg. If by some other mechanism we have a typed array access on a compile-time constant typed array pointer, then fold: - Array bounds checks. Specifically, fold the load of length. - Loading the vector. This needs to install a watchpoint on the array itself because of the possibility of neutering. Neutering is ridiculous. We do this without bloating the size of ArrayBuffer or JSArrayBufferView in the common case (i.e. the case where you allocated an array that didn't end up becoming a compile-time constant). To install the watchpoint, we slowDownAndWasteMemory and then create an incoming reference to the ArrayBuffer, where that incoming reference is from a watchpoint object. The ArrayBuffer already knows about such incoming references and can fire the watchpoints that way. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGDesiredWatchpoints.cpp: (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add): (JSC::DFG::DesiredWatchpoints::addLazily): * dfg/DFGDesiredWatchpoints.h: (JSC::DFG::GenericSetAdaptor::add): (JSC::DFG::GenericSetAdaptor::hasBeenInvalidated): (JSC::DFG::ArrayBufferViewWatchpointAdaptor::hasBeenInvalidated): (JSC::DFG::GenericDesiredWatchpoints::reallyAdd): (JSC::DFG::GenericDesiredWatchpoints::areStillValid): (JSC::DFG::GenericDesiredWatchpoints::isStillValid): (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState): (JSC::DFG::DesiredWatchpoints::isStillValid): (JSC::DFG::DesiredWatchpoints::shouldAssumeMixedState): (JSC::DFG::DesiredWatchpoints::isValidOrMixed): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetFoldableView): * dfg/DFGGraph.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds): (JSC::DFG::SpeculativeJIT::emitTypedArrayBoundsCheck): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): (JSC::DFG::SpeculativeJIT::compileConstantIndexedPropertyStorage): (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): * dfg/DFGSpeculativeJIT.h: * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): (JSC::DFG::WatchpointCollectionPhase::addLazily): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::typedArrayLength): * runtime/ArrayBuffer.cpp: (JSC::ArrayBuffer::transfer): * runtime/ArrayBufferNeuteringWatchpoint.cpp: Added. (JSC::ArrayBufferNeuteringWatchpoint::ArrayBufferNeuteringWatchpoint): (JSC::ArrayBufferNeuteringWatchpoint::~ArrayBufferNeuteringWatchpoint): (JSC::ArrayBufferNeuteringWatchpoint::finishCreation): (JSC::ArrayBufferNeuteringWatchpoint::destroy): (JSC::ArrayBufferNeuteringWatchpoint::create): (JSC::ArrayBufferNeuteringWatchpoint::createStructure): * runtime/ArrayBufferNeuteringWatchpoint.h: Added. (JSC::ArrayBufferNeuteringWatchpoint::set): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2013-12-04 Commit Queue Unreviewed, rolling out r160116. http://trac.webkit.org/changeset/160116 https://bugs.webkit.org/show_bug.cgi?id=125264 Change doesn't work as intended. See bug comments for details. (Requested by bfulgham on #webkit). * runtime/InitializeThreading.cpp: (JSC::initializeThreading): 2013-12-04 Oliver Hunt Refactor static getter function prototype to include thisValue in addition to the base object https://bugs.webkit.org/show_bug.cgi?id=124461 Reviewed by Geoffrey Garen. Add thisValue parameter to static getter prototype, and switch from JSValue to EncodedJSValue for parameters and return value. Currently none of the static getters use the thisValue, but separating out the refactoring will prevent future changes from getting lost in the noise of refactoring. This means that this patch does not result in any change in behaviour. * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::::asCallbackObject): (JSC::::staticFunctionGetter): (JSC::::callbackGetter): * jit/JITOperations.cpp: * runtime/JSActivation.cpp: (JSC::JSActivation::argumentsGetter): * runtime/JSActivation.h: * runtime/JSFunction.cpp: (JSC::JSFunction::argumentsGetter): (JSC::JSFunction::callerGetter): (JSC::JSFunction::lengthGetter): (JSC::JSFunction::nameGetter): * runtime/JSFunction.h: * runtime/JSObject.h: (JSC::PropertySlot::getValue): * runtime/NumberConstructor.cpp: (JSC::numberConstructorNaNValue): (JSC::numberConstructorNegInfinity): (JSC::numberConstructorPosInfinity): (JSC::numberConstructorMaxValue): (JSC::numberConstructorMinValue): * runtime/PropertySlot.h: * runtime/RegExpConstructor.cpp: (JSC::asRegExpConstructor): (JSC::regExpConstructorDollar1): (JSC::regExpConstructorDollar2): (JSC::regExpConstructorDollar3): (JSC::regExpConstructorDollar4): (JSC::regExpConstructorDollar5): (JSC::regExpConstructorDollar6): (JSC::regExpConstructorDollar7): (JSC::regExpConstructorDollar8): (JSC::regExpConstructorDollar9): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): * runtime/RegExpObject.cpp: (JSC::asRegExpObject): (JSC::regExpObjectGlobal): (JSC::regExpObjectIgnoreCase): (JSC::regExpObjectMultiline): (JSC::regExpObjectSource): 2013-12-04 Daniel Bates [iOS] Enable Objective-C ARC when building JSC tools for iOS simulator https://bugs.webkit.org/show_bug.cgi?id=125170 Reviewed by Geoffrey Garen. * API/tests/testapi.mm: * Configurations/ToolExecutable.xcconfig: 2013-12-04 [email protected] Use ThreadingOnce class to encapsulate pthread_once functionality. https://bugs.webkit.org/show_bug.cgi?id=125228 Reviewed by Brent Fulgham. * runtime/InitializeThreading.cpp: (JSC::initializeThreading): 2013-12-04 Mark Lam Remove unneeded semicolons. https://bugs.webkit.org/show_bug.cgi?id=125083. Rubber-stamped by Filip Pizlo. * debugger/Debugger.h: (JSC::Debugger::detach): (JSC::Debugger::sourceParsed): (JSC::Debugger::exception): (JSC::Debugger::atStatement): (JSC::Debugger::callEvent): (JSC::Debugger::returnEvent): (JSC::Debugger::willExecuteProgram): (JSC::Debugger::didExecuteProgram): (JSC::Debugger::didReachBreakpoint): 2013-12-04 Andy Estes [iOS] Build projects with $(ARCHS_STANDARD_32_64_BIT) https://bugs.webkit.org/show_bug.cgi?id=125236 Reviewed by Sam Weinig. $(ARCHS_STANDARD_32_64_BIT) is what we want for both device and simulator builds. * Configurations/DebugRelease.xcconfig: 2013-12-03 Filip Pizlo Infer constant closure variables https://bugs.webkit.org/show_bug.cgi?id=124630 Reviewed by Geoffrey Garen. Captured variables that are assigned once (not counting op_enter's Undefined initialization) and that are contained within a function that has thus far only been entered once are now constant folded. It's pretty awesome. This involves a watchpoint on the assignment to variables and a watchpoint on entry into the function. The former is reused from global variable constant inference and the latter is reused from one-time closure inference. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): * bytecode/Instruction.h: (JSC::Instruction::Instruction): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedInstruction::UnlinkedInstruction): * bytecode/VariableWatchpointSet.h: (JSC::VariableWatchpointSet::invalidate): * bytecode/Watchpoint.h: (JSC::WatchpointSet::invalidate): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::addVar): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitInitLazyRegister): (JSC::BytecodeGenerator::emitMove): (JSC::BytecodeGenerator::emitNewFunctionInternal): (JSC::BytecodeGenerator::createArgumentsIfNecessary): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::addVar): (JSC::BytecodeGenerator::watchableVariable): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getLocal): (JSC::DFG::ByteCodeParser::inferredConstant): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetActivation): (JSC::DFG::Graph::tryGetRegisters): * dfg/DFGGraph.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_captured_mov): (JSC::JIT::emit_op_new_captured_func): (JSC::JIT::emitSlow_op_captured_mov): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_captured_mov): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/ConstantMode.h: Added. * runtime/JSGlobalObject.h: * runtime/JSScope.cpp: (JSC::abstractAccess): * runtime/SymbolTable.cpp: (JSC::SymbolTableEntry::prepareToWatch): 2013-12-04 Brent Fulgham [Win] Unreviewed project file gardening. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Remove deleted files from project. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Put files in proper directory folders to match the directory structure of the source code. 2013-12-04 Joseph Pecoraro Unreviewed Windows Build Fix attempt after r160099. * JavaScriptCore.vcxproj/copy-files.cmd: 2013-12-04 Julien Brianceau REGRESSION (r160094): Fix lots of crashes for sh4 architecture. https://bugs.webkit.org/show_bug.cgi?id=125227 Reviewed by Michael Saboff. * llint/LowLevelInterpreter32_64.asm: Do not use t4 and t5 as they match a0 and a1. * offlineasm/registers.rb: Add t7, t8 and t9 in register list for sh4 port. * offlineasm/sh4.rb: Rearrange RegisterID list and add the missing ones. 2013-12-03 Joseph Pecoraro Web Inspector: Push Remote Inspector debugging connection management into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=124613 Reviewed by Timothy Hatcher. Move the ENABLE(REMOTE_INSPECTOR) remote debugger connection management into JavaScriptCore (originally from WebKit/mac). Include enhancements: * allow for different types of remote debuggable targets, eventually at least a JSContext, WebView, WKView. * allow debuggables to be registered and debugged on any thread. Unlike WebViews, JSContexts may be run entirely off of the main thread. * move the remote connection (XPC connection) itself off of the main thread, it doesn't need to be on the main thread. Make JSContext @class and JavaScriptCore::JSContextRef "JavaScript" Remote Debuggables. * inspector/remote/RemoteInspectorDebuggable.h: Added. * inspector/remote/RemoteInspectorDebuggable.cpp: Added. (Inspector::RemoteInspectorDebuggable::RemoteInspectorDebuggable): (Inspector::RemoteInspectorDebuggable::~RemoteInspectorDebuggable): (Inspector::RemoteInspectorDebuggable::init): (Inspector::RemoteInspectorDebuggable::update): (Inspector::RemoteInspectorDebuggable::setRemoteDebuggingAllowed): (Inspector::RemoteInspectorDebuggable::info): RemoteInspectorDebuggable defines a debuggable target. As long as something creates a debuggable and is set to allow remote inspection it will be listed in remote debuggers. For the different types of debuggables (JavaScript and Web) there is different basic information that may be listed. * inspector/InspectorFrontendChannel.h: Added. (Inspector::InspectorFrontendChannel::~InspectorFrontendChannel): The only thing a debuggable needs for remote debugging is an InspectorFrontendChannel a way to send messages to a remote frontend. This class provides that method, and is vended to the RemoteInspectorDebuggable when a remote connection is setup. * inspector/remote/RemoteInspector.h: Added. * inspector/remote/RemoteInspector.mm: Added. Singleton, created at least when the first Debuggable is created. This class manages the list of debuggables, any connection to a remote debugger proxy (XPC service "com.apple.webinspector"). (Inspector::dispatchAsyncOnQueueSafeForAnyDebuggable): (Inspector::RemoteInspector::shared): (Inspector::RemoteInspector::RemoteInspector): (Inspector::RemoteInspector::nextAvailableIdentifier): (Inspector::RemoteInspector::registerDebuggable): (Inspector::RemoteInspector::unregisterDebuggable): (Inspector::RemoteInspector::updateDebuggable): Debuggable management. When debuggables are added, removed, or updated we stash a copy of the debuggable information and push an update to debuggers. Stashing a copy of the information in the RemoteInspector is a thread safe way to avoid walking over all debuggables to gather the information when it is needed. (Inspector::RemoteInspector::start): (Inspector::RemoteInspector::stop): Runtime API to enable / disable the feature. (Inspector::RemoteInspector::listingForDebuggable): (Inspector::RemoteInspector::pushListingNow): (Inspector::RemoteInspector::pushListingSoon): Pushing a listing to remote debuggers. (Inspector::RemoteInspector::sendMessageToRemoteFrontend): (Inspector::RemoteInspector::setupXPCConnectionIfNeeded): (Inspector::RemoteInspector::xpcConnectionReceivedMessage): (Inspector::RemoteInspector::xpcConnectionFailed): (Inspector::RemoteInspector::xpcConnectionUnhandledMessage): XPC setup, send, and receive handling. (Inspector::RemoteInspector::updateHasActiveDebugSession): Applications being debugged may want to know when a debug session is active. This provides that notification. (Inspector::RemoteInspector::receivedSetupMessage): (Inspector::RemoteInspector::receivedDataMessage): (Inspector::RemoteInspector::receivedDidCloseMessage): (Inspector::RemoteInspector::receivedGetListingMessage): (Inspector::RemoteInspector::receivedIndicateMessage): (Inspector::RemoteInspector::receivedConnectionDiedMessage): Dispatching incoming remote debugging protocol messages. These are wrapping above the inspector protocol messages. * inspector/remote/RemoteInspectorConstants.h: Added. Protocol messages and dictionary keys inside the messages. (Inspector::RemoteInspectorDebuggableInfo::RemoteInspectorDebuggableInfo): * inspector/remote/RemoteInspectorDebuggableConnection.h: Added. * inspector/remote/RemoteInspectorDebuggableConnection.mm: Added. This is a connection between the RemoteInspector singleton and a RemoteInspectorDebuggable. (Inspector::RemoteInspectorDebuggableConnection::RemoteInspectorDebuggableConnection): (Inspector::RemoteInspectorDebuggableConnection::~RemoteInspectorDebuggableConnection): Allow for dispatching messages on JavaScript debuggables on a dispatch_queue instead of the main queue. (Inspector::RemoteInspectorDebuggableConnection::destination): (Inspector::RemoteInspectorDebuggableConnection::connectionIdentifier): Needed in the remote debugging protocol to identify the remote debugger. (Inspector::RemoteInspectorDebuggableConnection::dispatchSyncOnDebuggable): (Inspector::RemoteInspectorDebuggableConnection::dispatchAsyncOnDebuggable): (Inspector::RemoteInspectorDebuggableConnection::setup): (Inspector::RemoteInspectorDebuggableConnection::closeFromDebuggable): (Inspector::RemoteInspectorDebuggableConnection::close): (Inspector::RemoteInspectorDebuggableConnection::sendMessageToBackend): (Inspector::RemoteInspectorDebuggableConnection::sendMessageToFrontend): The connection is a thin channel between the two sides that can be closed from either side, so there is some logic around multi-threaded access. * inspector/remote/RemoteInspectorXPCConnection.h: Added. (Inspector::RemoteInspectorXPCConnection::Client::~Client): * inspector/remote/RemoteInspectorXPCConnection.mm: Added. (Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection): (Inspector::RemoteInspectorXPCConnection::~RemoteInspectorXPCConnection): (Inspector::RemoteInspectorXPCConnection::close): (Inspector::RemoteInspectorXPCConnection::deserializeMessage): (Inspector::RemoteInspectorXPCConnection::handleEvent): (Inspector::RemoteInspectorXPCConnection::sendMessage): This is a connection between the RemoteInspector singleton and an XPC service named "com.apple.webinspector". This handles serialization of the dictionary messages to and from the service. The receiving is done on a non-main queue. * API/JSContext.h: * API/JSContext.mm: (-[JSContext name]): (-[JSContext setName:]): ObjC API to enable/disable JSContext remote inspection and give a name. * API/JSContextRef.h: * API/JSContextRef.cpp: (JSGlobalContextGetName): (JSGlobalContextSetName): C API to give a JSContext a name. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::setName): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::name): Shared handling of the APIs above. * runtime/JSGlobalObjectDebuggable.cpp: Added. (JSC::JSGlobalObjectDebuggable::JSGlobalObjectDebuggable): (JSC::JSGlobalObjectDebuggable::name): (JSC::JSGlobalObjectDebuggable::connect): (JSC::JSGlobalObjectDebuggable::disconnect): (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemoteFrontend): * runtime/JSGlobalObjectDebuggable.h: Added. Stub for the actual remote debugging implementation. We will push down the appropriate WebCore/inspector peices suitable for debugging just a JavaScript context. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Update build files. 2013-12-04 Michael Saboff Move the setting up of callee's callFrame from pushFrame to callToJavaScript thunk https://bugs.webkit.org/show_bug.cgi?id=123999 Reviewed by Filip Pizlo. Changed LLInt and/or JIT enabled ports to allocate the stack frame in the callToJavaScript stub. Added an additional stub, callToNativeFunction that allocates a stack frame in a similar way for calling native entry points that take a single ExecState* argument. These stubs are implemented using common macros in LowLevelInterpreter{32_64,64}.asm. There are also Windows X86 and X86-64 versions in the corresponding JitStubsXX.h. The stubs allocate and create a sentinel frame, then create the callee's frame, populating the header and arguments from the passed in ProtoCallFrame*. It is assumed that the caller of either stub does a check for enough stack space via JSStack::entryCheck(). For ports using the C-Loop interpreter, the prior method for allocating stack frame and invoking functions is used, namely with JSStack::pushFrame() and ::popFrame(). Made spelling changes "sentinal" -> "sentinel". * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): (JSC::CachedCall::setThis): (JSC::CachedCall::setArgument): * interpreter/CallFrameClosure.h: (JSC::CallFrameClosure::resetCallFrame): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): * interpreter/Interpreter.h: * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::entryCheck): (JSC::JSStack::pushFrame): (JSC::JSStack::popFrame): * interpreter/ProtoCallFrame.cpp: Added. (JSC::ProtoCallFrame::init): * interpreter/ProtoCallFrame.h: Added. (JSC::ProtoCallFrame::codeBlock): (JSC::ProtoCallFrame::setCodeBlock): (JSC::ProtoCallFrame::setScope): (JSC::ProtoCallFrame::setCallee): (JSC::ProtoCallFrame::argumentCountIncludingThis): (JSC::ProtoCallFrame::argumentCount): (JSC::ProtoCallFrame::setArgumentCountIncludingThis): (JSC::ProtoCallFrame::setPaddedArgsCount): (JSC::ProtoCallFrame::clearCurrentVPC): (JSC::ProtoCallFrame::setThisValue): (JSC::ProtoCallFrame::setArgument): * jit/JITCode.cpp: (JSC::JITCode::execute): * jit/JITCode.h: * jit/JITOperations.cpp: * jit/JITStubs.h: * jit/JITStubsMSVC64.asm: * jit/JITStubsX86.h: * llint/LLIntOffsetsExtractor.cpp: * llint/LLIntThunks.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArgList.h: (JSC::ArgList::data): * runtime/JSArray.cpp: (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): * runtime/StringPrototype.cpp: (JSC::replaceUsingRegExpSearch): 2013-12-04 László Langó Remove stdio.h from JSC files. https://bugs.webkit.org/show_bug.cgi?id=125220 Reviewed by Michael Saboff. * interpreter/VMInspector.cpp: * jit/JITArithmetic.cpp: * jit/JITArithmetic32_64.cpp: * jit/JITCall.cpp: * jit/JITCall32_64.cpp: * jit/JITPropertyAccess.cpp: * jit/JITPropertyAccess32_64.cpp: * runtime/Completion.cpp: * runtime/IndexingType.cpp: * runtime/Lookup.h: * runtime/Operations.cpp: * runtime/Options.cpp: * runtime/RegExp.cpp: 2013-12-04 László Langó Avoid to add zero offset in BaseIndex. https://bugs.webkit.org/show_bug.cgi?id=125215 Reviewed by Michael Saboff. When using cloop do not generate offsets additions for BaseIndex if the offset is zero. * offlineasm/cloop.rb: 2013-12-04 Peter Molnar Fix !ENABLE(JAVASCRIPT_DEBUGGER) build. https://bugs.webkit.org/show_bug.cgi?id=125083 Reviewed by Mark Lam. * debugger/Debugger.cpp: * debugger/Debugger.h: (JSC::Debugger::Debugger): (JSC::Debugger::needsOpDebugCallbacks): (JSC::Debugger::needsExceptionCallbacks): (JSC::Debugger::detach): (JSC::Debugger::sourceParsed): (JSC::Debugger::exception): (JSC::Debugger::atStatement): (JSC::Debugger::callEvent): (JSC::Debugger::returnEvent): (JSC::Debugger::willExecuteProgram): (JSC::Debugger::didExecuteProgram): (JSC::Debugger::didReachBreakpoint): * debugger/DebuggerPrimitives.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_debug): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_debug): * llint/LLIntOfflineAsmConfig.h: * llint/LowLevelInterpreter.asm: 2013-12-03 Mark Lam testapi test crashes on Windows in WTF::Vector::size(). https://bugs.webkit.org/show_bug.cgi?id=121972. Reviewed by Brent Fulgham. * interpreter/JSStack.cpp: (JSC::JSStack::~JSStack): - Reverting the change from r160004 since it's better to fix OSAllocatorWin to be consistent with OSAllocatorPosix. 2013-12-03 Mark Lam Fix LLINT_C_LOOP build for Win64. https://bugs.webkit.org/show_bug.cgi?id=125186. Reviewed by Michael Saboff. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * jit/JITOperationsMSVC64.cpp: Added. (JSC::getHostCallReturnValueWithExecState): - Win64 will build JITStubMSVC64.asm even when !ENABLE(JIT). This results in a linkage error due to a missing getHostCallReturnValueWithExecState(). So, we add a stub getHostCallReturnValueWithExecState() here to satisfy that linkage. This function will never be called. The alternative to providing such a stub is to make the MSVC project recognize if the JIT is enabled or not, and exclude JITStubMSVC64.asm if it's not enabled. We don't currently set ENABLE(JIT) via the MSVC project and the work to do that is too much trouble for what we're trying to achieve here. So, we're opting for this simpler workaround instead. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): - Don't build callToJavaScript if we're building the C loop. Otherwise, the C loop won't build if !ENABLE(COMPUTE_GOTO_OPCODES). 2013-12-03 Michael Saboff ARM64: Crash in JIT code due to improper reuse of cached memory temp register https://bugs.webkit.org/show_bug.cgi?id=125181 Reviewed by Geoffrey Garen. Changed load8() and load() to invalidate the memory temp CachedTempRegister when the destination of an absolute load is the memory temp register since the source address is also the memory temp register. Change branch{8,32,64} of an AbsoluteAddress with a register to use the dataTempRegister as the destinate of the absolute load to reduce the chance that we need to invalidate the memory temp register cache. In the process, found and fixed an outright bug in branch8() where we'd load into the data temp register and then compare and branch on the memory temp register. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load8): (JSC::MacroAssemblerARM64::branch32): (JSC::MacroAssemblerARM64::branch64): (JSC::MacroAssemblerARM64::branch8): (JSC::MacroAssemblerARM64::load): 2013-12-03 Michael Saboff jit/JITArithmetic.cpp doesn't build for non-X86 ports https://bugs.webkit.org/show_bug.cgi?id=125185 Rubber stamped by Mark Hahnenberg. Removed unused declarations and related UNUSED_PARAM(). * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_mod): 2013-12-03 Filip Pizlo ObjectAllocationProfile is racy and the DFG should be cool with that https://bugs.webkit.org/show_bug.cgi?id=125172 Reviewed by Mark Hahnenberg. We would previously sometimes get a null Structure because checking if the profile is non-null and loading the structure from it were two separate operations. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::setFuturePossibleStructure): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * runtime/JSFunction.h: (JSC::JSFunction::allocationProfile): (JSC::JSFunction::allocationStructure): 2013-12-03 [email protected] testapi test crashes on Windows in WTF::Vector::size() https://bugs.webkit.org/show_bug.cgi?id=121972 Reviewed by Michael Saboff. The reason for the crash is that the wrong memory block is decommitted. This can happen if no memory has been committed in the reserved block before the JSStack object is destroyed. In the JSStack destructor, the pointer to decommit then points to the end of the block (or the start of the next), and the decommit size is zero. If there is a block just after the block we are trying to decommit, this block will be decommitted, since Windows will decommit the whole block, if the decommit size is zero (see VirtualFree). When somebody tries to read/write to this block later, we crash. * interpreter/JSStack.cpp: (JSC::JSStack::~JSStack): Don't decommit memory if nothing has been committed. 2013-12-03 László Langó Guard JIT include. https://bugs.webkit.org/show_bug.cgi?id=125063 Reviewed by Filip Pizlo. * llint/LLIntThunks.cpp: 2013-12-03 Julien Brianceau Merge mips and arm/sh4 paths in nativeForGenerator and privateCompileCTINativeCall functions. https://bugs.webkit.org/show_bug.cgi?id=125067 Reviewed by Michael Saboff. * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): 2013-12-02 Mark Lam Build failure when disabling JIT, YARR_JIT, and ASSEMBLER. https://bugs.webkit.org/show_bug.cgi?id=123809. Reviewed by Geoffrey Garen. Also fixed build when disabling the DISASSEMBLER. Added some needed #if's and some comments. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::finalizeCodeWithDisassembly): * dfg/DFGDisassembler.cpp: * dfg/DFGDisassembler.h: (JSC::DFG::Disassembler::Disassembler): (JSC::DFG::Disassembler::setStartOfCode): (JSC::DFG::Disassembler::setForBlockIndex): (JSC::DFG::Disassembler::setForNode): (JSC::DFG::Disassembler::setEndOfMainPath): (JSC::DFG::Disassembler::setEndOfCode): (JSC::DFG::Disassembler::dump): (JSC::DFG::Disassembler::reportToProfiler): * disassembler/Disassembler.cpp: * disassembler/X86Disassembler.cpp: * jit/FPRInfo.h: * jit/GPRInfo.h: * jit/JITDisassembler.cpp: * jit/JITDisassembler.h: (JSC::JITDisassembler::JITDisassembler): (JSC::JITDisassembler::setStartOfCode): (JSC::JITDisassembler::setForBytecodeMainPath): (JSC::JITDisassembler::setForBytecodeSlowPath): (JSC::JITDisassembler::setEndOfSlowPath): (JSC::JITDisassembler::setEndOfCode): (JSC::JITDisassembler::dump): (JSC::JITDisassembler::reportToProfiler): 2013-12-02 Filip Pizlo Baseline JIT calls to CommonSlowPaths shouldn't restore the last result https://bugs.webkit.org/show_bug.cgi?id=125107 Reviewed by Mark Hahnenberg. Just killing dead code. * jit/JITArithmetic.cpp: (JSC::JIT::emitSlow_op_negate): (JSC::JIT::emitSlow_op_lshift): (JSC::JIT::emitSlow_op_rshift): (JSC::JIT::emitSlow_op_urshift): (JSC::JIT::emitSlow_op_bitand): (JSC::JIT::emitSlow_op_inc): (JSC::JIT::emitSlow_op_dec): (JSC::JIT::emitSlow_op_mod): (JSC::JIT::emit_op_mod): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitSlow_op_negate): (JSC::JIT::emitSlow_op_lshift): (JSC::JIT::emitRightShiftSlowCase): (JSC::JIT::emitSlow_op_bitand): (JSC::JIT::emitSlow_op_bitor): (JSC::JIT::emitSlow_op_bitxor): (JSC::JIT::emitSlow_op_inc): (JSC::JIT::emitSlow_op_dec): (JSC::JIT::emitSlow_op_add): (JSC::JIT::emitSlow_op_sub): (JSC::JIT::emitSlow_op_mul): (JSC::JIT::emitSlow_op_div): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_strcat): (JSC::JIT::emitSlow_op_get_callee): (JSC::JIT::emitSlow_op_create_this): (JSC::JIT::emitSlow_op_to_this): (JSC::JIT::emitSlow_op_to_primitive): (JSC::JIT::emitSlow_op_not): (JSC::JIT::emitSlow_op_bitxor): (JSC::JIT::emitSlow_op_bitor): (JSC::JIT::emitSlow_op_stricteq): (JSC::JIT::emitSlow_op_nstricteq): (JSC::JIT::emitSlow_op_to_number): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emitSlow_op_to_primitive): (JSC::JIT::emitSlow_op_not): (JSC::JIT::emitSlow_op_stricteq): (JSC::JIT::emitSlow_op_nstricteq): (JSC::JIT::emitSlow_op_to_number): (JSC::JIT::emitSlow_op_get_callee): (JSC::JIT::emitSlow_op_create_this): (JSC::JIT::emitSlow_op_to_this): 2013-12-01 Filip Pizlo Stores to local captured variables should be intercepted https://bugs.webkit.org/show_bug.cgi?id=124883 Reviewed by Mark Hahnenberg. Previously, in bytecode, you could assign to a captured variable just as you would assign to any other kind of variable. This complicates closure variable constant inference because we don't have any place where we can intercept stores to captured variables in the LLInt. This patch institutes a policy that only certain instructions can store to captured variables. If you interpret those instructions and you are required to notifyWrite() then you need to check if the relevant variable is captured. Those instructions are tracked in CodeBlock.cpp's VerifyCapturedDef. The main one is simply op_captured_mov. In the future, we'll probably modify those instructions to have a pointer directly to the VariableWatchpointSet; but for now we just introduce the captured instructions as placeholders. In order to validate that the placeholders are inserted correctly, this patch improves the CodeBlock validation to be able to inspect every def in the bytecode. To do that, this patch refactors the liveness analysis' use/def calculator to be reusable; it now takes a functor for each use or def. In the process of refactoring the liveness analysis, I noticed that op_enter was claiming to def all callee registers. That's wrong; it only defs the non-temporary variables. Making that change revealed preexisting bugs in the liveness analysis, since now the validator would pick up cases where the bytecode claimed to use a temporary and the def calculator never noticed the definition (or the converse - where the bytecode was actually not using a temporary but the liveness analysis thought that it was a use). This patch fixes a few of those bugs. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::stepOverInstruction): * bytecode/BytecodeUseDef.h: Added. (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::isCaptured): (JSC::CodeBlock::validate): * bytecode/CodeBlock.h: * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::resolveCallee): (JSC::BytecodeGenerator::emitMove): (JSC::BytecodeGenerator::isCaptured): (JSC::BytecodeGenerator::local): (JSC::BytecodeGenerator::constLocal): (JSC::BytecodeGenerator::emitNewFunction): (JSC::BytecodeGenerator::emitLazyNewFunction): (JSC::BytecodeGenerator::emitNewFunctionInternal): * bytecompiler/BytecodeGenerator.h: (JSC::Local::Local): (JSC::Local::isCaptured): (JSC::Local::captureMode): (JSC::BytecodeGenerator::captureMode): (JSC::BytecodeGenerator::emitNode): (JSC::BytecodeGenerator::pushOptimisedForIn): * bytecompiler/NodesCodegen.cpp: (JSC::PostfixNode::emitResolve): (JSC::PrefixNode::emitResolve): (JSC::ReadModifyResolveNode::emitBytecode): (JSC::AssignResolveNode::emitBytecode): (JSC::ConstDeclNode::emitCodeSingle): (JSC::ForInNode::emitBytecode): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/SymbolTable.h: (JSC::SymbolTable::isCaptured): 2013-12-02 Filip Pizlo Instead of watchpointing activation allocation, we should watchpoint entry into functions that have captured variables https://bugs.webkit.org/show_bug.cgi?id=125052 Reviewed by Mark Hahnenberg. This makes us watch function entry rather than activation creation. We only incur the costs of doing so for functions that have captured variables, and only on the first two entries into the function. This means that closure variable constant inference will naturally work even for local uses of the captured variable, like: (function(){ var blah = 42; ... // stuff function () { ... blah /* we can fold this to 42 */ } ... blah // we can also fold this to 42. })(); Previously, only the nested use would have been foldable. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/Watchpoint.h: (JSC::WatchpointSet::touch): (JSC::InlineWatchpointSet::touch): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasSymbolTable): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_touch_entry): * llint/LowLevelInterpreter.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/JSActivation.h: (JSC::JSActivation::create): * runtime/SymbolTable.cpp: (JSC::SymbolTable::SymbolTable): * runtime/SymbolTable.h: 2013-12-02 Nick Diego Yamane [JSC] Get rid of some unused parameters in LLIntSlowPaths.cpp macros https://bugs.webkit.org/show_bug.cgi?id=125075 Reviewed by Michael Saboff. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::handleHostCall): added UNUSED_PARAM(pc). (JSC::LLInt::setUpCall): Doesn't pass 'pc' to LLINT_CALL macros. (JSC::LLInt::LLINT_SLOW_PATH_DECL): Ditto. 2013-12-02 László Langó Remove stdio.h from JSC files. https://bugs.webkit.org/show_bug.cgi?id=125066 Reviewed by Michael Saboff. Remove stdio.h, when it is not necessary to be included. * bytecode/CodeBlock.cpp: * bytecode/StructureSet.h: * profiler/LegacyProfiler.cpp: * profiler/Profile.cpp: * profiler/ProfileNode.cpp: * yarr/YarrInterpreter.cpp: 2013-12-02 László Langó Unused include files when building without JIT. https://bugs.webkit.org/show_bug.cgi?id=125062 Reviewed by Michael Saboff. We should organize the includes, and guard JIT methods in ValueRecovery. * bytecode/ValueRecovery.cpp: Guard include files. * bytecode/ValueRecovery.h: Guard JIT methods. 2013-12-02 Balazs Kilvady [MIPS] Small stack frame causes regressions. https://bugs.webkit.org/show_bug.cgi?id=124945 Reviewed by Michael Saboff. Fix stack space for LLInt on MIPS. * llint/LowLevelInterpreter32_64.asm: 2013-12-02 Brian J. Burg jsc: implement a native readFile function https://bugs.webkit.org/show_bug.cgi?id=125059 Reviewed by Filip Pizlo. This adds a native readFile() function to jsc, used to slurp an entire file into a JavaScript string. * jsc.cpp: (GlobalObject::finishCreation): Add readFile() to globals. (functionReadFile): Added. 2013-12-02 László Langó JSC does not build if OPCODE_STATS is enabled. https://bugs.webkit.org/show_bug.cgi?id=125011 Reviewed by Filip Pizlo. * bytecode/Opcode.cpp: 2013-11-29 Filip Pizlo Finally remove those DFG_ENABLE things https://bugs.webkit.org/show_bug.cgi?id=125025 Rubber stamped by Sam Weinig. This removes a bunch of unused and untested insanity. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::tallyFrequentExitSites): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): (JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath): (JSC::DFG::ByteCodeParser::makeSafe): (JSC::DFG::ByteCodeParser::makeDivSafe): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::linkBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): (JSC::DFG::ByteCodeParser::parseCodeBlock): (JSC::DFG::ByteCodeParser::parse): (JSC::DFG::parse): * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::run): (JSC::DFG::CFGSimplificationPhase::convertToJump): (JSC::DFG::CFGSimplificationPhase::fixJettisonedPredecessors): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::endIndexForPureCSE): (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren): (JSC::DFG::CSEPhase::setReplacement): (JSC::DFG::CSEPhase::eliminate): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGCommon.h: (JSC::DFG::verboseCompilationEnabled): (JSC::DFG::logCompilationChanges): (JSC::DFG::shouldDumpGraphAtEachPhase): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::initialize): (JSC::DFG::InPlaceAbstractState::endBasicBlock): (JSC::DFG::InPlaceAbstractState::mergeStateAtTail): (JSC::DFG::InPlaceAbstractState::mergeToSuccessors): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileBody): (JSC::DFG::JITCompiler::link): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::run): (JSC::DFG::PredictionPropagationPhase::propagate): (JSC::DFG::PredictionPropagationPhase::propagateForward): (JSC::DFG::PredictionPropagationPhase::propagateBackward): (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): * dfg/DFGScoreBoard.h: (JSC::DFG::ScoreBoard::use): * dfg/DFGSlowPathGenerator.h: (JSC::DFG::SlowPathGenerator::generate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): (JSC::DFG::SpeculativeJIT::runSlowPathGenerators): (JSC::DFG::SpeculativeJIT::dump): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * dfg/DFGVariableEventStream.h: (JSC::DFG::VariableEventStream::appendAndLog): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): * jit/JIT.cpp: (JSC::JIT::privateCompile): 2013-11-29 Filip Pizlo FTL IC should nop-fill to make up the difference between the actual IC size and the requested patchpoint size https://bugs.webkit.org/show_bug.cgi?id=124960 Reviewed by Sam Weinig. * assembler/LinkBuffer.h: (JSC::LinkBuffer::size): * assembler/X86Assembler.h: (JSC::X86Assembler::fillNops): * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::dumpHeader): * ftl/FTLCompile.cpp: (JSC::FTL::generateICFastPath): * jit/JITDisassembler.cpp: (JSC::JITDisassembler::dumpHeader): 2013-11-29 Julien Brianceau Use moveDoubleToInts in SpecializedThunkJIT::returnDouble for non-X86 JSVALUE32_64 ports. https://bugs.webkit.org/show_bug.cgi?id=124936 Reviewed by Zoltan Herczeg. The moveDoubleToInts implementations in ARM, MIPS and SH4 macro assemblers do not clobber src FPRegister and are likely to be more efficient than the current generic implementation using the stack. * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::returnDouble): 2013-11-29 Julien Brianceau Merge arm and sh4 paths in nativeForGenerator and privateCompileCTINativeCall functions. https://bugs.webkit.org/show_bug.cgi?id=124892 Reviewed by Zoltan Herczeg. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::call): Pick a scratch register instead of getting it as a parameter. The sh4 port was the only one to have this call(Address, RegisterID) prototype. * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): Use argumentGPRx and merge arm and sh4 paths. * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): Use argumentGPRx and merge arm and sh4 paths. 2013-11-28 Nadav Rotem Revert the X86 assembler peephole changes https://bugs.webkit.org/show_bug.cgi?id=124988 Reviewed by Csaba Osztrogonác. * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::add32): (JSC::MacroAssemblerX86::add64): (JSC::MacroAssemblerX86::or32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::add32): (JSC::MacroAssemblerX86Common::or32): (JSC::MacroAssemblerX86Common::branchAdd32): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::add32): (JSC::MacroAssemblerX86_64::or32): (JSC::MacroAssemblerX86_64::add64): (JSC::MacroAssemblerX86_64::or64): (JSC::MacroAssemblerX86_64::xor64): 2013-11-28 Antti Koivisto Remove feature: CSS variables https://bugs.webkit.org/show_bug.cgi?id=114119 Reviewed by Andreas Kling. * Configurations/FeatureDefines.xcconfig: 2013-11-28 Peter Gal Typo fix after r159834 to fix 32 bit builds. Reviewed by Csaba Osztrogonác. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2013-11-27 Nadav Rotem Add a bunch of early exits and local optimizations to the x86 assembler. https://bugs.webkit.org/show_bug.cgi?id=124904 Reviewed by Filip Pizlo. * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::add32): (JSC::MacroAssemblerX86::add64): (JSC::MacroAssemblerX86::or32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::add32): (JSC::MacroAssemblerX86Common::or32): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::add32): (JSC::MacroAssemblerX86_64::or32): (JSC::MacroAssemblerX86_64::add64): (JSC::MacroAssemblerX86_64::or64): (JSC::MacroAssemblerX86_64::xor64): 2013-11-27 Filip Pizlo Infer one-time scopes https://bugs.webkit.org/show_bug.cgi?id=124812 Reviewed by Oliver Hunt. This detects JSActivations that are created only once. The JSActivation pointer is then baked into the machine code. This takes advantage of the one-time scope inference to reduce the number of indirections needed to get to a closure variable in case where the scope is only allocated once. This isn't really a speed-up since in the common case the total number of instruction bytes needed to load the scope from the stack is about equal to the number of instruction bytes needed to materialize the absolute address of a scoped variable. But, this is a necessary prerequisite to https://bugs.webkit.org/show_bug.cgi?id=124630, so it's probably a good idea anyway. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::finalizeUnconditionally): * bytecode/Instruction.h: * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/Watchpoint.h: (JSC::WatchpointSet::notifyWrite): (JSC::InlineWatchpointSet::notifyWrite): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitResolveScope): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::scopedVarLoadElimination): (JSC::DFG::CSEPhase::scopedVarStoreElimination): (JSC::DFG::CSEPhase::getLocalLoadElimination): (JSC::DFG::CSEPhase::setLocalStoreElimination): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetRegisters): * dfg/DFGGraph.h: * dfg/DFGNode.h: (JSC::DFG::Node::varNumber): (JSC::DFG::Node::hasSymbolTable): (JSC::DFG::Node::symbolTable): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetClosureRegisters): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSActivation.h: (JSC::JSActivation::create): * runtime/JSScope.cpp: (JSC::abstractAccess): (JSC::JSScope::abstractResolve): * runtime/JSScope.h: (JSC::ResolveOp::ResolveOp): * runtime/JSVariableObject.h: (JSC::JSVariableObject::registers): * runtime/SymbolTable.cpp: (JSC::SymbolTable::SymbolTable): * runtime/SymbolTable.h: 2013-11-27 Filip Pizlo Finally fix some obvious Bartlett bugs https://bugs.webkit.org/show_bug.cgi?id=124951 Reviewed by Mark Hahnenberg. Sanitize the stack (i.e. zero parts of it known to be dead) at three key points: - GC. - At beginning of OSR entry. - Just as we finish preparing OSR entry. This clears those slots on the stack that could have been live in baseline but that are known to be dead in DFG. This is as much as a 2x speed-up on splay if you run it in certain modes, and run it for a long enough interval. It appears to fix all instances of the dreaded exponential heap growth that splay gets into when some stale pointer stays around. This doesn't have much of an effect on real-world programs. This bug has only ever manifested in splay and for that reason we thus far opted against fixing it. But splay is, for what it's worth, the premiere GC stress test in JavaScript - so making sure we can run it without pathologies - even when you tweak its configuration - is probably fairly important. * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::noticeOSREntry): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSREntry.h: * heap/Heap.cpp: (JSC::Heap::markRoots): * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::sanitizeStack): * interpreter/JSStack.h: 2013-11-26 Filip Pizlo Do bytecode validation as part of testing https://bugs.webkit.org/show_bug.cgi?id=124913 Reviewed by Oliver Hunt. Also fix some small bugs in the bytecode liveness analysis that I found by doing this validation thingy. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::isValidRegisterForLiveness): (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::validate): (JSC::CodeBlock::beginValidationDidFail): (JSC::CodeBlock::endValidationDidFail): * bytecode/CodeBlock.h: * runtime/Executable.cpp: (JSC::ScriptExecutable::prepareForExecutionImpl): * runtime/Options.h: 2013-11-27 Andreas Kling Structure::m_staticFunctionReified should be a single bit. Shave 8 bytes off of JSC::Structure by jamming m_staticFunctionReified into the bitfield just above. Reviewed by Antti Koivisto. 2013-11-27 Andreas Kling JSActivation constructor should use NotNull placement new. Knock a null check outta the storage initialization loop. Reviewed by Antti Koivisto. 2013-11-26 Filip Pizlo Restructure global variable constant inference so that it could work for any kind of symbol table variable https://bugs.webkit.org/show_bug.cgi?id=124760 Reviewed by Oliver Hunt. This changes the way global variable constant inference works so that it can be reused for closure variable constant inference. Some of the premises that originally motivated this patch are somewhat wrong, but it led to some simplifications anyway and I suspect that we'll be able to fix those premises in the future. The main point of this patch is to make it easy to reuse global variable constant inference for closure variable constant inference, and this will be possible provided we can also either (a) infer one-shot closures (easy) or (b) infer closure variables that are always assigned prior to first use. One of the things that this patch is meant to enable is constant inference for closure variables that may be part of a multi-shot closure. Closure variables may be instantiated multiple times, like: function foo() { var WIDTH = 45; function bar() { ... use WIDTH ... } ... } Even if foo() is called many times and WIDTH is assigned to multiple times, that doesn't change the fact that it's a constant. The goal of closure variable constant inference is to catch any case where a closure variable has been assigned at least once and its value has never changed. This patch doesn't implement that, but it does change global variable constant inference to have most of the powers needed to do that. Note that most likely we will use this functionality only to implement constant inference for one-shot closures, but the resulting machinery is still simpler than what we had before. This involves three changes: - The watchpoint object now contains the inferred value. This involves creating a new kind of watchpoint set, the VariableWatchpointSet. We will reuse this object for closure variables. - Writing to a variable that is watchpointed still involves these three states that we proceed through monotonically (Uninitialized->Initialized->Invalidated) but now, the Initialized->Invalidated state transition only happens if we change the variable's value, rather than store to the variable. Repeatedly storing the same value won't change the variable's state. - On 64-bit systems (the only systems on which we do concurrent JIT), you no longer need fancy fencing to get a consistent view of the watchpoint in the JIT. The state of the VariableWatchpointSet for the purposes of constant folding is entirely encapsulated in the VariableWatchpointSet::m_inferredValue. If that is JSValue() then you cannot fold (either because the set is uninitialized or because it's invalidated - doesn't matter which); on the other hand if the value is anything other than JSValue() then you can fold, and that's the value you fold to. Simple! This also changes the way that DFG IR deals with variable watchpoints. It's now oblivious to global variables. You install a watchpoint using VariableWatchpoint and you notify write using NotifyWrite. Easy! Note that this will requires some more tweaks because of the fact that op_enter will store Undefined into every captured variable. Hence it won't even work for one-shot closures. One-shot closures are easily fixed by introducing another state (so we'll have Uninitialized->Undefined->Initialized->Invalidated). Multi-shot closures will require static analysis. One-shot closures are clearly a higher priority. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/Instruction.h: * bytecode/VariableWatchpointSet.h: Added. (JSC::VariableWatchpointSet::VariableWatchpointSet): (JSC::VariableWatchpointSet::~VariableWatchpointSet): (JSC::VariableWatchpointSet::inferredValue): (JSC::VariableWatchpointSet::notifyWrite): (JSC::VariableWatchpointSet::invalidate): (JSC::VariableWatchpointSet::finalizeUnconditionally): (JSC::VariableWatchpointSet::addressOfInferredValue): * bytecode/Watchpoint.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasRegisterPointer): (JSC::DFG::Node::hasVariableWatchpointSet): (JSC::DFG::Node::variableWatchpointSet): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithMod): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileNotifyWrite): * jit/JIT.h: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitNotifyWrite): (JSC::JIT::emitPutGlobalVar): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitNotifyWrite): (JSC::JIT::emitPutGlobalVar): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addGlobalVar): (JSC::JSGlobalObject::addFunction): * runtime/JSGlobalObject.h: * runtime/JSScope.h: (JSC::ResolveOp::ResolveOp): * runtime/JSSymbolTableObject.h: (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/SymbolTable.cpp: (JSC::SymbolTableEntry::inferredValue): (JSC::SymbolTableEntry::prepareToWatch): (JSC::SymbolTableEntry::addWatchpoint): (JSC::SymbolTableEntry::notifyWriteSlow): (JSC::SymbolTable::visitChildren): (JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup): (JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup): (JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally): * runtime/SymbolTable.h: (JSC::SymbolTableEntry::watchpointSet): (JSC::SymbolTableEntry::notifyWrite): 2013-11-24 Filip Pizlo Create a new SymbolTable every time code is loaded so that the watchpoints don't get reused https://bugs.webkit.org/show_bug.cgi?id=124824 Reviewed by Oliver Hunt. This helps with one shot closure inference as well as closure variable constant inference, since without this, if code was reloaded from the cache then we would think that the first run was actually an Nth run. This would cause us to think that the watchpoint(s) should all be invalidated. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::stronglyVisitStrongReferences): * bytecode/CodeBlock.h: (JSC::CodeBlock::symbolTable): * runtime/Executable.cpp: (JSC::FunctionExecutable::symbolTable): * runtime/Executable.h: * runtime/SymbolTable.cpp: (JSC::SymbolTable::clone): * runtime/SymbolTable.h: 2013-11-26 Oliver Hunt Crash in JSC::ASTBuilder::Expression JSC::Parser<:lexer char> >::parseUnaryExpression<:astbuilder>(JSC::ASTBuilder&) https://bugs.webkit.org/show_bug.cgi?id=124886 Reviewed by Sam Weinig. Make sure the error macros propagate an existing error before trying to create a new error message. We need to do this as the parser state may not be safe for any specific error message if we are already unwinding due to an error. * parser/Parser.cpp: 2013-11-26 Nadav Rotem Optimize away OR with zero - a common ASM.js pattern. https://bugs.webkit.org/show_bug.cgi?id=124869 Reviewed by Filip Pizlo. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): 2013-11-25 Julien Brianceau [arm][mips] Fix crash in dfg-arrayify-elimination layout jsc test. https://bugs.webkit.org/show_bug.cgi?id=124839 Reviewed by Michael Saboff. In ARM EABI and MIPS, 64-bit values have to be aligned on stack too. * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArgumentsWithExecState): * jit/JITInlines.h: (JSC::JIT::callOperation): Add missing EABI_32BIT_DUMMY_ARG. 2013-11-23 Filip Pizlo Fix more fallout from failed attempts at div/mod DFG strength reductions https://bugs.webkit.org/show_bug.cgi?id=124813 Reviewed by Geoffrey Garen. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithMod): 2013-11-22 Mark Hahnenberg JSC Obj-C API should have real documentation https://bugs.webkit.org/show_bug.cgi?id=124805 Reviewed by Geoffrey Garen. Massaging the header comments into proper headerdocs. * API/JSContext.h: * API/JSExport.h: * API/JSManagedValue.h: * API/JSValue.h: * API/JSVirtualMachine.h: 2013-11-22 Filip Pizlo CodeBlock::m_numCalleeRegisters shouldn't also mean frame size, frame size needed for exit, or any other unrelated things https://bugs.webkit.org/show_bug.cgi?id=124793 Reviewed by Mark Hahnenberg. Now m_numCalleeRegisters always refers to the number of locals that the attached bytecode uses. It never means anything else. For frame size, we now have it lazily computed from m_numCalleeRegisters for the baseline engines and we have it stored in DFG::CommonData for the optimizing JITs. For frame-size-needed-at-exit, we store that in DFG::CommonData, too. The code no longer implies that there is any arithmetic relationship between m_numCalleeRegisters and frameSize. Previously it implied that the latter is greater than the former. The code no longer implies that there is any arithmetic relationship between the frame Size and the frame-size-needed-at-exit. Previously it implied that the latter is greater that the former. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::frameRegisterCount): * bytecode/CodeBlock.h: * dfg/DFGCommonData.h: (JSC::DFG::CommonData::CommonData): (JSC::DFG::CommonData::requiredRegisterCountForExecutionAndExit): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::frameRegisterCount): (JSC::DFG::Graph::requiredRegisterCountForExit): (JSC::DFG::Graph::requiredRegisterCountForExecutionAndExit): * dfg/DFGGraph.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::SpeculativeJIT): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): * interpreter/CallFrame.cpp: (JSC::CallFrame::frameExtentInternal): * interpreter/JSStackInlines.h: (JSC::JSStack::pushFrame): * jit/JIT.h: (JSC::JIT::frameRegisterCountFor): * jit/JITOperations.cpp: * llint/LLIntEntrypoint.cpp: (JSC::LLInt::frameRegisterCountFor): * llint/LLIntEntrypoint.h: 2013-11-21 Filip Pizlo Combine SymbolTable and SharedSymbolTable https://bugs.webkit.org/show_bug.cgi?id=124761 Reviewed by Geoffrey Garen. SymbolTable was never used directly; we now always used SharedSymbolTable. So, this gets rid of SymbolTable and renames SharedSymbolTable to SymbolTable. * bytecode/CodeBlock.h: (JSC::CodeBlock::symbolTable): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedFunctionExecutable::symbolTable): (JSC::UnlinkedCodeBlock::symbolTable): (JSC::UnlinkedCodeBlock::finishCreation): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::symbolTable): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::StackLayoutPhase::run): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::symbolTableFor): * runtime/Arguments.h: (JSC::Arguments::finishCreation): * runtime/Executable.h: (JSC::FunctionExecutable::symbolTable): * runtime/JSActivation.h: (JSC::JSActivation::create): (JSC::JSActivation::JSActivation): (JSC::JSActivation::registersOffset): (JSC::JSActivation::allocationSize): * runtime/JSSymbolTableObject.h: (JSC::JSSymbolTableObject::symbolTable): (JSC::JSSymbolTableObject::JSSymbolTableObject): (JSC::JSSymbolTableObject::finishCreation): * runtime/JSVariableObject.h: (JSC::JSVariableObject::JSVariableObject): * runtime/SymbolTable.cpp: (JSC::SymbolTable::destroy): (JSC::SymbolTable::SymbolTable): * runtime/SymbolTable.h: (JSC::SymbolTable::create): (JSC::SymbolTable::createStructure): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2013-11-22 Mark Lam Remove residual references to "dynamicGlobalObject". https://bugs.webkit.org/show_bug.cgi?id=124787. Reviewed by Filip Pizlo. * JavaScriptCore.order: * interpreter/CallFrame.h: 2013-11-22 Mark Lam Ensure that arity fixups honor stack alignment requirements. https://bugs.webkit.org/show_bug.cgi?id=124756. Reviewed by Geoffrey Garen. The LLINT and all the JITs rely on CommonSlowPaths::arityCheckFor() to compute the arg count adjustment for the arity fixup. We take advantage of this choke point and introduce the stack alignment padding there in the guise of additional args. The only cost of this approach is that the padding will also be initialized to undefined values as if they were args. Since arity fixups are considered a slow path that is rarely taken, this cost is not a concern. * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::arityCheckFor): * runtime/VM.h: (JSC::VM::isSafeToRecurse): 2013-11-21 Filip Pizlo BytecodeGenerator should align the stack according to native conventions https://bugs.webkit.org/show_bug.cgi?id=124735 Reviewed by Mark Lam. Rolling this back in because it actually fixed fast/dom/gc-attribute-node.html, but our infrastructure misleads peole into thinking that fixing a test constitutes breaking it. * bytecompiler/BytecodeGenerator.h: (JSC::CallArguments::registerOffset): (JSC::CallArguments::argumentCountIncludingThis): * bytecompiler/NodesCodegen.cpp: (JSC::CallArguments::CallArguments): 2013-11-21 Filip Pizlo Get rid of CodeBlock::dumpStatistics() https://bugs.webkit.org/show_bug.cgi?id=124762 Reviewed by Mark Hahnenberg. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::~CodeBlock): * bytecode/CodeBlock.h: 2013-11-22 Commit Queue Unreviewed, rolling out r159652. http://trac.webkit.org/changeset/159652 https://bugs.webkit.org/show_bug.cgi?id=124778 broke fast/dom/gc-attribute-node.html (Requested by ap on #webkit). * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitCall): (JSC::BytecodeGenerator::emitConstruct): * bytecompiler/BytecodeGenerator.h: (JSC::CallArguments::registerOffset): (JSC::CallArguments::argumentCountIncludingThis): * bytecompiler/NodesCodegen.cpp: (JSC::CallArguments::CallArguments): (JSC::CallArguments::newArgument): 2013-11-21 Filip Pizlo Fix a typo (requriements->requirements). * runtime/StackAlignment.h: 2013-11-21 Mark Lam CodeBlock::m_numCalleeRegisters need to honor native stack alignment. https://bugs.webkit.org/show_bug.cgi?id=124754. Reviewed by Filip Pizlo. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::newRegister): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): 2013-11-21 Mark Rowe Stop overriding VALID_ARCHS. All modern versions of Xcode set it appropriately for our needs. Reviewed by Alexey Proskuryakov. * Configurations/Base.xcconfig: 2013-11-21 Mark Rowe Fix an error in a few Xcode configuration setting files. Reviewed by Alexey Proskuryakov. * Configurations/Base.xcconfig: 2013-11-21 Michael Saboff ARM64: Implement push/pop equivalents in LLInt https://bugs.webkit.org/show_bug.cgi?id=124721 Reviewed by Filip Pizlo. Added pushLRAndFP and popLRAndFP that push and pop the link register and frame pointer register. These ops emit code just like what the compiler emits in the prologue and epilogue. Also changed pushCalleeSaves and popCalleeSaves to use the same store pair and load pair instructions to do the actually pushing and popping. Finally changed the implementation of push and pop to raise an exception since we don't have (or need) a single register push or pop. * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/instructions.rb: 2013-11-21 Michael Saboff JSC: Removed unused opcodes from offline assembler https://bugs.webkit.org/show_bug.cgi?id=124749 Reviewed by Mark Hahnenberg. Removed the unused, X86 only peekq and pokeq. * offlineasm/instructions.rb: * offlineasm/x86.rb: 2013-11-21 Michael Saboff REGRESSION(159395) Fix branch8(…, AbsoluteAddress, …) in ARM64 MacroAssembler https://bugs.webkit.org/show_bug.cgi?id=124688 Reviewed by Geoffrey Garen. Changed handling of the address for the load8() in the branch8(AbsoluteAddress) to be like the rest of the branchXX(AbsoluteAddress) fucntions. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::branch8): 2013-11-21 Filip Pizlo BytecodeGenerator should align the stack according to native conventions https://bugs.webkit.org/show_bug.cgi?id=124735 Reviewed by Mark Lam. * bytecompiler/BytecodeGenerator.h: (JSC::CallArguments::registerOffset): (JSC::CallArguments::argumentCountIncludingThis): * bytecompiler/NodesCodegen.cpp: (JSC::CallArguments::CallArguments): 2013-11-21 Filip Pizlo Unreviewed, preemptive build fix. * runtime/StackAlignment.h: (JSC::stackAlignmentBytes): (JSC::stackAlignmentRegisters): 2013-11-21 Filip Pizlo JSC should know what the stack alignment conventions are https://bugs.webkit.org/show_bug.cgi?id=124736 Reviewed by Mark Lam. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/StackAlignment.h: Added. (JSC::stackAlignmentBytes): (JSC::stackAlignmentRegisters): 2013-11-21 Balazs Kilvady [MIPS] Build fails since r159545. https://bugs.webkit.org/show_bug.cgi?id=124716 Reviewed by Michael Saboff. Add missing implementations in MacroAssembler and LLInt for MIPS. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::sync): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::store8): (JSC::MacroAssemblerMIPS::memoryFence): * offlineasm/mips.rb: 2013-11-21 Julien Brianceau Fix sh4 build after r159545. https://bugs.webkit.org/show_bug.cgi?id=124713 Reviewed by Michael Saboff. Add missing implementations in macro assembler and LLINT for sh4. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::load8): (JSC::MacroAssemblerSH4::store8): (JSC::MacroAssemblerSH4::memoryFence): * assembler/SH4Assembler.h: (JSC::SH4Assembler::synco): * offlineasm/sh4.rb: Handle "memfence" opcode. 2013-11-20 Mark Lam Introducing VMEntryScope to update the VM stack limit. https://bugs.webkit.org/show_bug.cgi?id=124634. Reviewed by Geoffrey Garen. 1. Introduced USE(SEPARATE_C_AND_JS_STACK) (defined in Platform.h). Currently, it is hardcoded to use separate C and JS stacks. Once we switch to using the C stack for JS frames, we'll need to fix this to only be enabled when ENABLE(LLINT_C_LOOP). 2. Stack limits are now tracked in the VM. Logically, there are 2 stack limits: a. m_stackLimit for the native C stack, and b. m_jsStackLimit for the JS stack. If USE(SEPARATE_C_AND_JS_STACK), then the 2 limits are the same value, and are implemented as 2 fields in a union. 3. The VM native stackLimit is set as follows: a. Initially, the VM sets it to the limit of the stack of the thread that instantiated the VM. This allows the parser and bytecode generator to run before we enter the VM to execute JS code. b. Upon entry into the VM to execute JS code (via one of the Interpreter::execute...() functions), we instantiate a VMEntryScope that sets the VM's stackLimit to the limit of the current thread's stack. The VMEntryScope will automatically restore the previous entryScope and stack limit upon destruction. If USE(SEPARATE_C_AND_JS_STACK), the JSStack's methods will set the VM's jsStackLimit whenever it grows or shrinks. 4. The VM now provides a isSafeToRecurse() function that compares the current stack pointer against its native stackLimit. This subsumes and obsoletes the VMStackBounds class. 5. The VMEntryScope class also subsumes DynamicGlobalObjectScope for tracking the JSGlobalObject that we last entered the VM with. 6. Renamed dynamicGlobalObject() to vmEntryGlobalObject() since that is the value that the function retrieves. 7. Changed JIT and LLINT code to do stack checks against the jsStackLimit in the VM class instead of the JSStack. * API/JSBase.cpp: (JSEvaluateScript): (JSCheckScriptSyntax): * API/JSContextRef.cpp: (JSGlobalContextRetain): (JSGlobalContextRelease): * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitNode): (JSC::BytecodeGenerator::emitNodeInConditionContext): * debugger/Debugger.cpp: (JSC::Debugger::detach): (JSC::Debugger::recompileAllJSFunctions): (JSC::Debugger::pauseIfNeeded): * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::vmEntryGlobalObject): * debugger/DebuggerCallFrame.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGOSREntry.cpp: * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLOSREntry.cpp: * heap/Heap.cpp: (JSC::Heap::lastChanceToFinalize): (JSC::Heap::deleteAllCompiledCode): * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): * interpreter/CallFrame.cpp: (JSC::CallFrame::vmEntryGlobalObject): * interpreter/CallFrame.h: * interpreter/Interpreter.cpp: (JSC::unwindCallFrame): (JSC::Interpreter::unwind): (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): (JSC::Interpreter::debug): * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::growSlowCase): * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::shrink): (JSC::JSStack::grow): - Moved these inlined functions here from JSStack.h. It reduces some #include dependencies of JSSTack.h which had previously resulted in some EWS bots' unhappiness with this patch. (JSC::JSStack::updateStackLimit): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JITCall.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITCall32_64.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: * llint/LowLevelInterpreter.asm: * parser/Parser.cpp: (JSC::::Parser): * parser/Parser.h: (JSC::Parser::canRecurse): * runtime/CommonSlowPaths.h: * runtime/Completion.cpp: (JSC::evaluate): * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/JSGlobalObject.cpp: * runtime/JSGlobalObject.h: * runtime/StringRecursionChecker.h: (JSC::StringRecursionChecker::performCheck): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::releaseExecutableMemory): (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::addressOfJSStackLimit): (JSC::VM::jsStackLimit): (JSC::VM::setJSStackLimit): (JSC::VM::stackLimit): (JSC::VM::setStackLimit): (JSC::VM::isSafeToRecurse): * runtime/VMEntryScope.cpp: Added. (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::~VMEntryScope): (JSC::VMEntryScope::requiredCapacity): * runtime/VMEntryScope.h: Added. (JSC::VMEntryScope::globalObject): * runtime/VMStackBounds.h: Removed. 2013-11-20 Michael Saboff [Win] JavaScript JIT crash (with DFG enabled). https://bugs.webkit.org/show_bug.cgi?id=124675 Reviewed by Geoffrey Garen. Similar to the change in r159427, changed linkClosureCall to use regT0/regT1 (payload/tag) for the callee. linkForThunkGenerator already expected the callee in regT0/regT1, but changed the comment to reflect that. * jit/Repatch.cpp: (JSC::linkClosureCall): * jit/ThunkGenerators.cpp: (JSC::linkForThunkGenerator): 2013-11-20 Michael Saboff ARMv7: Crash due to use after free of AssemblerBuffer https://bugs.webkit.org/show_bug.cgi?id=124611 Reviewed by Geoffrey Garen. Changed JITFinalizer constructor to take a MacroAssemblerCodePtr instead of a Label. In finalizeFunction(), we use that value instead of calculating it from the label. * assembler/MacroAssembler.cpp: * dfg/DFGJITFinalizer.cpp: (JSC::DFG::JITFinalizer::JITFinalizer): (JSC::DFG::JITFinalizer::finalizeFunction): * dfg/DFGJITFinalizer.h: 2013-11-20 Julien Brianceau Fix CPU(ARM_TRADITIONAL) build after r159545. https://bugs.webkit.org/show_bug.cgi?id=124649 Reviewed by Michael Saboff. Add missing memoryFence, load8 and store8 implementations in macro assembler. * assembler/ARMAssembler.h: (JSC::ARMAssembler::dmbSY): * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::load8): (JSC::MacroAssemblerARM::store8): (JSC::MacroAssemblerARM::memoryFence): 2013-11-20 Julien Brianceau [armv7][arm64] Speculative build fix after r159545. https://bugs.webkit.org/show_bug.cgi?id=124646 Reviewed by Filip Pizlo. * assembler/ARMv7Assembler.h: * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::memoryFence): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::memoryFence): 2013-11-19 Ryosuke Niwa Enable HTMLTemplateElement on Mac port https://bugs.webkit.org/show_bug.cgi?id=124637 Reviewed by Tim Horton. * Configurations/FeatureDefines.xcconfig: 2013-11-19 Filip Pizlo Unreviewed, remove completely bogus assertion. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addFunction): 2013-11-19 Filip Pizlo Unreviewed, debug build fix. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addFunction): 2013-11-19 Filip Pizlo Infer constant global variables https://bugs.webkit.org/show_bug.cgi?id=124464 Reviewed by Sam Weinig. All global variables that are candidates for watchpoint-based constant inference (i.e. not 'const' variables) will now have WatchpointSet's associated with them and those are used to drive the inference by tracking three states of each variable: Uninitialized: the variable's value is Undefined and the WatchpointSet state is ClearWatchpoint. Initialized: the variable's value was set to something (could even be explicitly set to Undefined) and the WatchpointSet state is IsWatching. Invalidated: the variable's value was set to something else (could even be the same thing as before but the point is that a put operation did execute again) and the WatchpointSet is IsInvalidated. If the compiler tries to compile a GetGlobalVar and the WatchpointSet state is IsWatching, then the current value of the variable can be folded in place of the get, and a watchpoint on the variable can be registered. We handle race conditions between the mutator and compiler by mandating that: - The mutator changes the WatchpointSet state after executing the put. - There is no opportunity to install code or call functions between when the mutator executes a put and changes the WatchpointSet state. - The compiler checks the WatchpointSet state prior to reading the value. The concrete algorithm used by the mutator is: 1. Store the new value into the variable. --- Execute a store-store fence. 2. Bump the state (ClearWatchpoing becomes IsWatching, IsWatching becomes IsInvalidated); the IsWatching->IsInvalidated transition may end up firing watchpoints. The concrete algorithm that the compiler uses is: 1. Load the state. If it's *not* IsWatching, then give up on constant inference. --- Execute a load-load fence. 2. Load the value of the variable and use that for folding, while also registering a DesiredWatchpoint. The various parts of this step can be done in any order. The desired watchpoint registration will fail if the watchpoint set is already invalidated. Now consider the following interesting interleavings: Uninitialized->M1->M2->C1->C2: Compiler sees IsWatching because of the mutator's store operation, and the variable is folded. The fencing ensures that C2 sees the value stored in M1 - i.e. we fold on the value that will actually be watchpointed. If before the compilation is installed the mutator executes another store then we will be sure that it will be a complete sequence of M1+M2 since compilations get installed at safepoints and never "in the middle" of a put_to_scope. Hence that compilation installation will be invalidated. If the M1+M2 sequence happens after the code is installed, then the code will be invalidated by triggering a jettison. Uninitialized->M1->C1->C2->M2: Compiler sees Uninitialized and will not fold. This is a sensible outcome since if the compiler read the variable's value, it would have seen Undefined. Uninitialized->C1->C2->M1->M2: Compiler sees Uninitialized and will not fold. Uninitialized->C1->M1->C2->M2: Compiler sees Uninitialized and will not fold. Uninitialized->C1->M1->M2->C2: Compiler sees Uninitialized and will not fold. Uninitialized->M1->C1->M2->C2: Compiler sees Uninitialized and will not fold. IsWatched->M1->M2->C1->C2: Compiler sees IsInvalidated and will not fold. IsWatched->M1->C1->C2->M2: Compiler will fold, but will also register a desired watchpoint, and that watchpoint will get invalidated before the code is installed. IsWatched->M1->C1->M2->C2: As above, will fold but the code will get invalidated. IsWatched->C1->C2->M1->M2: As above, will fold but the code will get invalidated. IsWatched->C1->M1->C2->M2: As above, will fold but the code will get invalidated. IsWatched->C1->M1->M2->C2: As above, will fold but the code will get invalidated. Note that this kind of reasoning shows why having the mutator first bump the state and then store the new value would be wrong. If we had done that (M1 = bump state, M2 = execute put) then we could have the following deadly interleavings: Uninitialized->M1->C1->C2->M2: Uninitialized->M1->C1->M2->C2: Mutator bumps the state to IsWatched and then the compiler folds Undefined, since M2 hasn't executed yet. Although C2 will set the watchpoint, M1 didn't notify it - it mearly initiated watching. M2 then stores a value other than Undefined, and you're toast. You could fix this sort of thing by making the Desired Watchpoints machinery more sophisticated, for example having it track the value that was folded; if the global variable's value was later found to be different then we could invalidate the compilation. You could also fix it by having the compiler also check that the value of the variable is not Undefined before folding. While those all sound great, I decided to instead just use the right interleaving since that results in less code and feels more intuitive. This is a 0.5% speed-up on SunSpider, mostly due to a 20% speed-up on math-cordic. It's a 0.6% slow-down on LongSpider, mostly due to a 25% slow-down on 3d-cube. This is because 3d-cube takes global variable assignment slow paths very often. Note that this 3d-cube slow-down doesn't manifest as much in SunSpider (only 6% there). This patch is also a 1.5% speed-up on V8v7 and a 2.8% speed-up on Octane v1, mostly due to deltablue (3.7%), richards (4%), and mandreel (26%). This is a 2% speed-up on Kraken, mostly due to a 17.5% speed-up on imaging-gaussian-blur. Something that really illustrates the slam-dunk-itude of this patch is the wide range of speed-ups on JSRegress. Casual JS programming often leads to global-var-based idioms and those variables tend to be assigned once, leading to excellent constant folding opportunities in an optimizing JIT. This is very evident in the speed-ups on JSRegress. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::dmbSY): * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::dmbSY): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::memfence): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::load8): (JSC::MacroAssemblerARMv7::memfence): * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::load8): (JSC::MacroAssemblerX86::store8): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::getUnusedRegister): (JSC::MacroAssemblerX86Common::store8): (JSC::MacroAssemblerX86Common::memoryFence): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::load8): (JSC::MacroAssemblerX86_64::store8): * assembler/X86Assembler.h: (JSC::X86Assembler::movb_rm): (JSC::X86Assembler::movzbl_mr): (JSC::X86Assembler::mfence): (JSC::X86Assembler::X86InstructionFormatter::threeByteOp): (JSC::X86Assembler::X86InstructionFormatter::oneByteOp8): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): * bytecode/Watchpoint.cpp: (JSC::WatchpointSet::WatchpointSet): (JSC::WatchpointSet::add): (JSC::WatchpointSet::notifyWriteSlow): * bytecode/Watchpoint.h: (JSC::WatchpointSet::state): (JSC::WatchpointSet::isStillValid): (JSC::WatchpointSet::addressOfSetIsNotEmpty): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getJSConstantForValue): (JSC::DFG::ByteCodeParser::getJSConstant): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::isStronglyProvedConstantIn): (JSC::DFG::Node::hasIdentifierNumberForCheck): (JSC::DFG::Node::hasRegisterPointer): * dfg/DFGNodeFlags.h: * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNotifyPutGlobalVar): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbbreviatedTypes.h: * ftl/FTLAbbreviations.h: (JSC::FTL::buildFence): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileNotifyPutGlobalVar): * ftl/FTLOutput.h: (JSC::FTL::Output::fence): * jit/JIT.h: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitPutGlobalVar): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitSlow_op_put_to_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitPutGlobalVar): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitSlow_op_put_to_scope): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * llvm/LLVMAPIFunctions.h: * offlineasm/arm.rb: * offlineasm/arm64.rb: * offlineasm/cloop.rb: * offlineasm/instructions.rb: * offlineasm/x86.rb: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addGlobalVar): (JSC::JSGlobalObject::addFunction): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::addVar): (JSC::JSGlobalObject::addConst): * runtime/JSScope.cpp: (JSC::abstractAccess): * runtime/JSSymbolTableObject.h: (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/SymbolTable.cpp: (JSC::SymbolTableEntry::couldBeWatched): (JSC::SymbolTableEntry::prepareToWatch): (JSC::SymbolTableEntry::notifyWriteSlow): * runtime/SymbolTable.h: 2013-11-19 Michael Saboff REGRESSION(158384) ARMv7 point checks too restrictive for native calls to traditional ARM code https://bugs.webkit.org/show_bug.cgi?id=124612 Reviewed by Geoffrey Garen. Removed ASSERT checks (i.e. lower bit set) for ARM Thumb2 destination addresses related to calls since we are calling native ARM traditional functions like sin() and cos(). * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::linkCall): (JSC::ARMv7Assembler::relinkCall): * assembler/MacroAssemblerCodeRef.h: 2013-11-19 Commit Queue Unreviewed, rolling out r159459. http://trac.webkit.org/changeset/159459 https://bugs.webkit.org/show_bug.cgi?id=124616 tons of assertions on launch (Requested by thorton on #webkit). * API/JSContext.mm: (-[JSContext setException:]): (-[JSContext wrapperForObjCObject:]): (-[JSContext wrapperForJSObject:]): * API/JSContextRef.cpp: (JSContextGroupRelease): (JSGlobalContextRelease): * API/JSManagedValue.mm: (-[JSManagedValue initWithValue:]): (-[JSManagedValue value]): * API/JSObjectRef.cpp: (JSObjectIsFunction): (JSObjectCopyPropertyNames): * API/JSValue.mm: (containerValueToObject): * API/JSWrapperMap.mm: (tryUnwrapObjcObject): 2013-11-19 Filip Pizlo Rename WatchpointSet::notifyWrite() should be renamed to WatchpointSet::fireAll() https://bugs.webkit.org/show_bug.cgi?id=124609 Rubber stamped by Mark Lam. notifyWrite() is a thing that SymbolTable does. WatchpointSet uses that terminology because it was original designed to match exactly SymbolTable's semantics. But now it's a confusing term. * bytecode/Watchpoint.cpp: (JSC::WatchpointSet::fireAllSlow): * bytecode/Watchpoint.h: (JSC::WatchpointSet::fireAll): (JSC::InlineWatchpointSet::fireAll): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * runtime/JSFunction.cpp: (JSC::JSFunction::put): (JSC::JSFunction::defineOwnProperty): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::haveABadTime): * runtime/Structure.h: (JSC::Structure::notifyTransitionFromThisStructure): * runtime/SymbolTable.cpp: (JSC::SymbolTableEntry::notifyWriteSlow): 2013-11-18 Michael Saboff REGRESSION (r159395): Error compiling for ARMv7 https://bugs.webkit.org/show_bug.cgi?id=124552 Reviewed by Geoffrey Garen. Fixed the implementation of branch8(RelationalCondition cond, AbsoluteAddress address, TrustedImm32 right) to materialize and use address similar to other ARMv7 branchXX() functions. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::branch8): 2013-11-19 Mark Lam Add tracking of endColumn for Executables. https://bugs.webkit.org/show_bug.cgi?id=124245. Reviewed by Geoffrey Garen. 1. Fixed computation of columns to take into account the startColumn from