2014-01-28 Filip Pizlo FTL should support ArrayPop https://bugs.webkit.org/show_bug.cgi?id=127749 Reviewed by Geoffrey Garen. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileArrayPush): (JSC::FTL::LowerDFGToLLVM::compileArrayPop): * tests/stress/array-pop-contiguous.js: Added. (foo): * tests/stress/array-pop-double.js: Added. (foo): * tests/stress/array-pop-int32.js: Added. (foo): 2014-01-28 Filip Pizlo DFG ArrayPop double array mishandles the NaN hole installation https://bugs.webkit.org/show_bug.cgi?id=127813 Reviewed by Mark Rowe. Our object model for arrays inferred double dictates that we use quiet NaN (QNaN) to mark holes. Holes, in this context, are any entries in the allocated array buffer (i.e. from index 0 up to the vectorLength) that don't currently hold a value. Popping creates a hole, since it deletes the value at publicLength - 1. But, because of some sloppy copy-and-paste, we were storing (int64_t)0 when creating the hole, instead of storing QNaN. That's likely because for other kinds of arrays, 64-bit zero is the hole marker, instead of QNaN. The attached test case illustrates the problem. In the LLInt and Baseline JIT, the result returned from foo() is "1.5,2.5,,4.5", since array.pop() removes 3.5 and replaces it with a hole and then the assignment "array[3] = 4.5" creates an element just beyond that hole. But, once we tier-up to the DFG, the result previously became "1.5,2.5,0,4.5", which is wrong. The 0 appeared because the IEEE double interpretation of 64-bit zero is simply zero. This patch fixes that problem. Now the DFG agrees with the other engines. This patch also fixes style. For some reason that copy-pasted code wasn't even indented correctly. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * tests/stress/array-pop-double-hole.js: Added. (foo): 2014-01-28 Filip Pizlo FTL should support ArrayPush https://bugs.webkit.org/show_bug.cgi?id=127748 Not reviewed, remove some debug code. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileArrayPush): 2014-01-27 Filip Pizlo FTL should support ArrayPush https://bugs.webkit.org/show_bug.cgi?id=127748 Reviewed by Oliver Hunt. * ftl/FTLAbstractHeapRepository.h: (JSC::FTL::AbstractHeapRepository::forArrayType): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileArrayPush): * tests/stress/array-push-contiguous.js: Added. (foo): * tests/stress/array-push-double.js: Added. (foo): 2014-01-28 Filip Pizlo Arity fixup clobbers callee-saves, causing FTL->FTL arity fixed-up calls to corrupt state https://bugs.webkit.org/show_bug.cgi?id=127791 Reviewed by Michael Saboff. Make the 64-bit path - i.e. the only path where the FTL matters - use regT6 instead of regT3. regT6 is not a callee save. * jit/ThunkGenerators.cpp: (JSC::arityFixup): * tests/stress/ftl-to-ftl-arity-fixup.js: Added. (foo): (bar): 2014-01-28 Filip Pizlo FTL should really, *really* support NotCellUse https://bugs.webkit.org/show_bug.cgi?id=127790 Reviewed by Mark Hahnenberg. It's easy to forget about Phantoms. Any use kind that appears in any node can eventually appear in a Phantom. This was covered by Octane/mandreel. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::speculate): (JSC::FTL::LowerDFGToLLVM::speculateNotCell): 2014-01-28 Filip Pizlo FTL should really support NotCellUse https://bugs.webkit.org/show_bug.cgi?id=127789 Reviewed by Mark Hahnenberg. This is for ValueToInt32(NotCell:). That support was added ages ago, and it even works as demonstrated by the new test case. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * tests/stress/not-cell-use.js: Added. (foo): (bar): 2014-01-28 Michael Saboff CStack Branch: Some LLInt symbols not declared extern "C" https://bugs.webkit.org/show_bug.cgi?id=127782 Reviewed by Geoffrey Garen. Added 'extern "C"' to the definitions of llint_throw_stack_overflow_error() and llint_stack_check_at_vm_entry(). Added WTF_INTERNAL to their declarations. * JavaScriptCore.xcodeproj/project.pbxproj: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_throw_stack_overflow_error): (JSC::LLInt::llint_stack_check_at_vm_entry): * llint/LLIntSlowPaths.h: 2014-01-27 Mark Hahnenberg Merge branch up to ToT r162909. 2014-01-27 Filip Pizlo DFG ArrayPush implementation does strange things to the result register on the slow path https://bugs.webkit.org/show_bug.cgi?id=127754 Reviewed by Michael Saboff. This told the slow path machinery that there was NoResult, which then sort of worked by accident because it would invoke a callOperation and pass the result register (i.e. storageLengthGPR) thinking it was giving it the first argument when in reality that callOperation would use it as the result register. The downside is that we would probably fail to omit the result register from silent spilling, but that probably doesn't even matter since storageLengthGPR doesn't appear as an in-use register (it's locked, but not attached to a Node, and so it's not "in use"). * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * tests/stress/array-push.js: Added. (foo): 2014-01-27 Mark Hahnenberg Getting all layout tests passing on the branch. 2014-01-27 Filip Pizlo Structure::dump() should say things about specific values https://bugs.webkit.org/show_bug.cgi?id=127741 Reviewed by Michael Saboff. * runtime/Structure.cpp: (JSC::Structure::dump): 2014-01-27 Filip Pizlo FTL ArithMod case needs to be factored for hackability and correctness rather than just minimizing the amount of code https://bugs.webkit.org/show_bug.cgi?id=127709 Rubber stamped by Mark Hahnenberg. Roll out part of r156784. 60% progression on Kraken/audio-oscillator. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileArithDiv): (JSC::FTL::LowerDFGToLLVM::compileArithMod): 2014-01-27 Mark Hahnenberg Added missing files to the branch. 2014-01-27 Filip Pizlo FTL should support NewArrayWithSize https://bugs.webkit.org/show_bug.cgi?id=127698 Reviewed by Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileNewArrayWithSize): * tests/stress/new-array-storage-array-with-size.js: Added. (foo): (test): * tests/stress/new-array-with-size-with-bad-time.js: Added. (foo): * tests/stress/new-contiguous-array-with-size.js: Added. (foo): (test): * tests/stress/new-double-array-with-size.js: Added. (foo): (test): * tests/stress/new-int32-array-with-size.js: Added. (foo): (test): * tests/stress/new-undecided-array-with-size.js: Added. (foo): (test): 2014-01-27 Michael Saboff CStack Branch: [X86-32] testapi crashes in gatherConservativeRoots() https://bugs.webkit.org/show_bug.cgi?id=127699 Reviewed by Mark Hahnenberg. sanitizeStackForVMImpl was using "t4" (edi) which is a callee save register, which trashed its prior contents. Change to use t2 (ecx) on X86 which is a scratch register. * llint/LowLevelInterpreter.asm: 2014-01-23 Mark Hahnenberg Merge branch up to ToT r162844. 2014-01-27 Filip Pizlo FTL should do polyvariant PutById inlining https://bugs.webkit.org/show_bug.cgi?id=127692 Reviewed by Mark Hahnenberg. Expanded the existign GetById polyvariance support to include PutByIds as well. * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::hasExitSite): (JSC::PutByIdStatus::computeFor): (JSC::PutByIdStatus::computeForStubInfo): * bytecode/PutByIdStatus.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * tests/stress/simple-polyvariant-put-by-id-inlining-example.js: Added. (foo): (fuzz): (bar): 2014-01-26 Filip Pizlo FTL should do polyvariant GetById inlining https://bugs.webkit.org/show_bug.cgi?id=127639 Reviewed by Oliver Hunt. This does polyvariant inlining for GetByIds. It's pretty easy to do this, now that we have all of that infrastructure from polyvariant Call/Construct inlining. Basically we just keep around the StubInfoMaps of the DFG code block when compiling the FTL code block. The combination of Call, Construct, and GetById inlining causes a 17% speed-up on V8v7/raytrace. GetById inlining alone appears to be a speed-up on other benchmarks as well. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeDFGStatuses): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::getStubInfoMap): (JSC::CodeBlock::addStubInfo): * bytecode/CodeBlock.h: * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::hasExitSite): (JSC::GetByIdStatus::computeFor): (JSC::GetByIdStatus::computeForStubInfo): * bytecode/GetByIdStatus.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parse): * runtime/Options.h: * tests/stress/simple-polyvariant-get-by-id-inlining-example.js: Added. (foo): (fuzz): (bar): 2014-01-25 Filip Pizlo StubInfoMap should use CodeOriginApproximateHash https://bugs.webkit.org/show_bug.cgi?id=127646 Reviewed by Sam Weinig. * bytecode/StructureStubInfo.h: 2014-01-25 Filip Pizlo FTL should do polyvariant Call/Construct inlining https://bugs.webkit.org/show_bug.cgi?id=127335 Reviewed by Oliver Hunt. Imagine that you have a call stack like foo calls bar, which calls baz. Lets say that there's another call stack where bar calls something other than baz at the same callsite, but whenver bar is called from foo, it always calls baz. This bar->baz callsite can be said to be polymorphic, because it may call things other than baz in some cases. But if we conduct a polyvariant analysis - that is, one that accounts for the call stack when reporting results - then this call appears monomorphic whenever bar gets called from foo. A polyvariant analysis of callsites will report results of the form "when statement S ran on a call stack that included functions f, g, etc then the set of possible callees is bounded by ...". This is in contrast to a monovariant analysis that will attempt to construct a bounding set of callees without adding the call stack as a contingency. Prior to this patch, all inlining decisions were made based on a monovariant dynamic analysis. This patch allows the FTL to make its Call/Construct inlining decisions based on a polyvariant analysis. That analysis is cleverly simple: we just ask the DFG to do the same "analysis" that the LLInt and Baseline JIT perform. That "analysis" is just an inline cache plus a slow-path count. But the DFG has performed inlining. Hence each callsite that the DFG reports information for is actually sitting on a static call stack. When the DFG reports the status of its call inline caches, it can report the information with a (short) snippet of call stack as a kind of contingency, much like a polyvariant analysis would. Consider the foo->bar->baz example. Lets say that foo's call to bar is trivially monomorphic, and the DFG inlines it. The DFG won't be able to then inline the call from foo->bar to baz because when we ask the Baseline JIT profiling what the status of the bar->baz call is, the profiling will say "polymorphic". That's because that profiling doesn't have any context sensitivity, and so it doesn't know that the call would be monomorphic if foo was bar's caller. But, with this patch, once we tier-up from the DFG to the FTL, the FTL will be able to ask the DFG: "hey, what do you know about the callsite to baz in foo->bar?" The DFG had, as we said above, inlined bar into foo and so it sees that callsite in its proper context. That call inline cache would be monomorphic. The FTL would then be able to inline baz into foo->bar. This will eventually benefit V8v7/raytrace, but we still have some more things to do before we can close the loop on this. Right now, the callsite in question is not an inlining candidate because it's op_call_varargs. We'll fix that eventually. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFor): (JSC::CallLinkStatus::computeDFGStatuses): * bytecode/CallLinkStatus.h: (JSC::CallLinkStatus::makeClosureCall): * bytecode/CodeBlock.h: (JSC::CodeBlock::specialFastCaseProfileForBytecodeOffset): * bytecode/CodeOrigin.cpp: (JSC::CodeOrigin::isApproximatelyEqualTo): (JSC::CodeOrigin::approximateHash): * bytecode/CodeOrigin.h: (JSC::CodeOrigin::CodeOrigin): (JSC::CodeOrigin::deletedMarker): (JSC::CodeOriginApproximateHash::hash): (JSC::CodeOriginApproximateHash::equal): * bytecode/DFGExitProfile.cpp: (JSC::DFG::ExitProfile::add): (JSC::DFG::ExitProfile::hasExitSite): * bytecode/DFGExitProfile.h: (JSC::DFG::FrequentExitSite::FrequentExitSite): (JSC::DFG::FrequentExitSite::operator==): (JSC::DFG::FrequentExitSite::subsumes): (JSC::DFG::FrequentExitSite::hash): (JSC::DFG::FrequentExitSite::jitType): (JSC::DFG::FrequentExitSite::withJITType): (JSC::DFG::QueryableExitProfile::hasExitSite): * bytecode/ExitKind.h: * bytecode/ExitingJITType.h: Added. (JSC::exitingJITTypeFor): * bytecode/ProfiledCodeBlockJettisoningWatchpoint.cpp: (JSC::ProfiledCodeBlockJettisoningWatchpoint::fireInternal): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGCapabilities.h: (JSC::DFG::inlineFunctionForCallCapabilityLevel): (JSC::DFG::inlineFunctionForClosureCallCapabilityLevel): (JSC::DFG::inlineFunctionForConstructCapabilityLevel): (JSC::DFG::inlineFunctionForCapabilityLevel): * dfg/DFGCommon.h: * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): (JSC::DFG::compile): * dfg/DFGDriver.h: * dfg/DFGFailedFinalizer.cpp: (JSC::DFG::FailedFinalizer::codeSize): * dfg/DFGFailedFinalizer.h: * dfg/DFGFinalizer.h: * dfg/DFGJITCode.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::currentJSCallIndex): * dfg/DFGJITFinalizer.cpp: (JSC::DFG::JITFinalizer::codeSize): * dfg/DFGJITFinalizer.h: * dfg/DFGOSRExit.h: (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite): * dfg/DFGOSRExitBase.cpp: (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow): * dfg/DFGOSRExitBase.h: (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite): * dfg/DFGOperations.cpp: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::Plan): (JSC::DFG::Plan::compileInThread): * dfg/DFGPlan.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::prepareJITCodeForTierUp): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::codeSize): * ftl/FTLJITFinalizer.h: * ftl/FTLOSRExit.h: (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite): * jit/JITCode.h: * jit/JITOperations.cpp: * runtime/Options.h: * tests/stress/simple-polyvariant-call-inlining-example.js: Added. (foo): (fuzz): (bar): (baz1): (baz2): 2014-01-24 Filip Pizlo DFG should allow inlining of op_call_varargs calls https://bugs.webkit.org/show_bug.cgi?id=127538 Reviewed by Michael Saboff and Mark Hahnenberg. Previously, op_call_varargs was directly lowered to a Call by the ByteCodeParser and we bypassed all of the call optimizations (intrinsics, inlining) provided by ByteCodeParser::handleCall(). This changes op_call_varargs handling so that it first sets up the stack to look like it would have if it had been a normal call, and then it calls handleCall(). This gives us inlining of op_call_varargs. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFromLLInt): * bytecode/CodeOrigin.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addCall): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::isLiveInBytecode): * tests/stress/inline-call-varargs-and-call.js: Added. (foo): (bar): (baz): * tests/stress/inline-call-varargs.js: Added. (foo): (bar): (baz): 2014-01-24 Mark Hahnenberg Merge branch up to ToT r162711. 2014-01-24 Matthew Mirman PutByIdDirect in FTL https://bugs.webkit.org/show_bug.cgi?id=127442 Reviewed by Filip Pizlo. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): * tests/stress/ftl-putbyid.js: Added. * tests/stress/ftl-putbyiddirect.js: Added. (foo): 2014-01-24 Michael Saboff CStack Branch: Get ARM working https://bugs.webkit.org/show_bug.cgi?id=127510 Reviewed by Geoffrey Garen. Fixed nativeCallTrampoline in the LLInt to account for the prior changes made for running on the C stack. Updated maxFrameExtentForSlowPathCall to take into account the stack aligning that needs to happen as well. In LowLevelInterpreter.asm::callToJavaScriptPrologue() for 32 bit variants of ARM, we align the stack to a 16 byte boundary since the ARM calling convention allows any 4 byte alignment. Added code in callToJavaScriptEpilogue() to restore the unaligned stack pointer before returning. Added pop and push register list opcodes to ARMv7 assember and added popPair and pushPair in the ARMv7 macro assembler for use saving and restoring lr & fp. Also add the ARM only "clrbp" (stands for clear bits for pointer) that maps to the bic (bit clear) instruction used to align the stack. Fixed ARMv7 add instructions where the destination is the stack pointer. Some instructions only allow the "Rn" source to be the stack pointer. In those cases, the source register is moved into the stack pointer and then an "add sp, ..." or "add sp, sp, ..." instruction is used. Fixed the test32 macro instruction handle the case where we want to test the stack pointer. The instruction set doesn't allow that directly, so we move the stack pointer into a temp register first. Reviewed by Geoffrey Garen. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::add): (JSC::ARMv7Assembler::pop): (JSC::ARMv7Assembler::push): (JSC::ARMv7Assembler::ARMInstructionFormatter::twoWordOp16Imm16): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::add32): (JSC::MacroAssemblerARMv7::popPair): (JSC::MacroAssemblerARMv7::pushPair): (JSC::MacroAssemblerARMv7::test32): * assembler/MaxFrameExtentForSlowPathCall.h: * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * offlineasm/arm.rb: * offlineasm/instructions.rb: 2014-01-24 Michael Saboff Merge trunk change set r162701. 2014-01-23 Mark Hahnenberg Merge branch up to ToT r162666. 2014-01-23 Filip Pizlo 3x splay regression in FTL with experimental coverage that is entirely due to Bartlett weirdness https://bugs.webkit.org/show_bug.cgi?id=127463 Reviewed by Mark Hahnenberg. This turned out to be entirely due to misuse of the scratch buffer in an FTL thunk. We need to mark a scratch buffer as unused after we're done with it or else the GC will have a bad time. But, this also introduces some debugging-related things that were useful on my journey. Finally, this turns all experimental FTL coverage into non-experimental coverage for now. I'm keeping the option because we will probably make other things "experimental" in the near future, if they cause regressions. * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): Made it possible to disable FTL OSR entry. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): Make the new NodeTypes non-experimental. * ftl/FTLThunks.cpp: (JSC::FTL::osrExitGenerationThunkGenerator): Fix the actual bug. * llint/LowLevelInterpreter.asm: * runtime/Options.h: * runtime/VM.cpp: (JSC::logSanitizeStack): * runtime/VM.h: (JSC::sanitizeStackForVM): This is all about making it possible to print things when the stack is sanitized. 2014-01-23 Mark Hahnenberg Merge branch up to ToT r161658. 2014-01-23 Mark Hahnenberg Merge branch up to ToT r160556. * API/JSBasePrivate.h: * API/JSContext.h: * API/JSContext.mm: (-[JSContext init]): (-[JSContext initWithVirtualMachine:]): (-[JSContext initWithGlobalContextRef:]): * API/JSContextRef.h: * API/JSContextRefPrivate.h: * API/JSManagedValue.h: * API/JSManagedValue.mm: (-[JSManagedValue init]): (-[JSManagedValue initWithValue:]): * API/JSObjectRef.h: * API/JSStringRefCF.h: * API/JSValue.h: * API/JSValueRef.h: * API/JSVirtualMachine.h: * API/JSVirtualMachine.mm: (-[JSVirtualMachine init]): (-[JSVirtualMachine initWithContextGroupRef:]): * API/tests/testapi.c: (globalContextNameTest): (main): * API/tests/testapi.mm: * CMakeLists.txt: * Configurations/Version.xcconfig: * DerivedSources.make: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: * JavaScriptCore.vcxproj/build-generated-files.sh: * JavaScriptCore.vcxproj/copy-files.cmd: * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bindings: Added. * bindings/ScriptFunctionCall.cpp: Added. (Deprecated::ScriptCallArgumentHandler::appendArgument): (Deprecated::ScriptFunctionCall::ScriptFunctionCall): (Deprecated::ScriptFunctionCall::call): * bindings/ScriptFunctionCall.h: Added. * bindings/ScriptObject.cpp: Added. (Deprecated::ScriptObject::ScriptObject): * bindings/ScriptObject.h: Added. (Deprecated::ScriptObject::ScriptObject): (Deprecated::ScriptObject::jsObject): (Deprecated::ScriptObject::scriptState): * bindings/ScriptValue.cpp: Added. (Deprecated::ScriptValue::~ScriptValue): (Deprecated::ScriptValue::getString): (Deprecated::ScriptValue::toString): (Deprecated::ScriptValue::isEqual): (Deprecated::ScriptValue::isNull): (Deprecated::ScriptValue::isUndefined): (Deprecated::ScriptValue::isObject): (Deprecated::ScriptValue::isFunction): (Deprecated::jsToInspectorValue): (Deprecated::ScriptValue::toInspectorValue): * bindings/ScriptValue.h: Added. * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::CodeBlockHash): (JSC::CodeBlockHash::dump): * bytecode/Opcode.cpp: (JSC::OpcodeStats::~OpcodeStats): * dfg/DFGCSEPhase.cpp: * docs/make-bytecode-docs.pl: * ftl/FTLAbstractHeap.h: * heap/Heap.cpp: (JSC::Heap::collect): * heap/Heap.h: * heap/MarkedSpace.h: * heap/RecursiveAllocationScope.h: Added. (JSC::RecursiveAllocationScope::RecursiveAllocationScope): (JSC::RecursiveAllocationScope::~RecursiveAllocationScope): * inspector/InspectorAgentBase.h: Added. (Inspector::InspectorAgentBase::~InspectorAgentBase): (Inspector::InspectorAgentBase::discardAgent): (Inspector::InspectorAgentBase::InspectorAgentBase): * inspector/InspectorAgentRegistry.cpp: Added. (Inspector::InspectorAgentRegistry::append): (Inspector::InspectorAgentRegistry::didCreateFrontendAndBackend): (Inspector::InspectorAgentRegistry::willDestroyFrontendAndBackend): (Inspector::InspectorAgentRegistry::discardAgents): * inspector/InspectorAgentRegistry.h: Added. * inspector/InspectorBackendDispatcher.cpp: Added. (Inspector::InspectorBackendDispatcher::CallbackBase::CallbackBase): (Inspector::InspectorBackendDispatcher::CallbackBase::isActive): (Inspector::InspectorBackendDispatcher::CallbackBase::sendFailure): (Inspector::InspectorBackendDispatcher::CallbackBase::sendIfActive): (Inspector::InspectorBackendDispatcher::create): (Inspector::InspectorBackendDispatcher::registerDispatcherForDomain): (Inspector::InspectorBackendDispatcher::dispatch): (Inspector::InspectorBackendDispatcher::sendResponse): (Inspector::InspectorBackendDispatcher::reportProtocolError): (Inspector::getPropertyValue): (Inspector::AsMethodBridges::asInt): (Inspector::AsMethodBridges::asDouble): (Inspector::AsMethodBridges::asString): (Inspector::AsMethodBridges::asBoolean): (Inspector::AsMethodBridges::asObject): (Inspector::AsMethodBridges::asArray): (Inspector::InspectorBackendDispatcher::getInt): (Inspector::InspectorBackendDispatcher::getDouble): (Inspector::InspectorBackendDispatcher::getString): (Inspector::InspectorBackendDispatcher::getBoolean): (Inspector::InspectorBackendDispatcher::getObject): (Inspector::InspectorBackendDispatcher::getArray): * inspector/InspectorBackendDispatcher.h: Added. (Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher): (Inspector::InspectorSupplementalBackendDispatcher::~InspectorSupplementalBackendDispatcher): * inspector/InspectorTypeBuilder.h: Added. (Inspector::TypeBuilder::OptOutput::OptOutput): (Inspector::TypeBuilder::OptOutput::operator=): (Inspector::TypeBuilder::OptOutput::isAssigned): (Inspector::TypeBuilder::OptOutput::getValue): (Inspector::TypeBuilder::ExactlyInt::ExactlyInt): (Inspector::TypeBuilder::ExactlyInt::operator int): (Inspector::TypeBuilder::ExactlyInt::cast_to_int): (Inspector::TypeBuilder::int): (Inspector::TypeBuilder::RuntimeCastHelper::assertType): (Inspector::TypeBuilder::RuntimeCastHelper::assertAny): (Inspector::TypeBuilder::RuntimeCastHelper::assertInt): (Inspector::TypeBuilder::Array::Array): (Inspector::TypeBuilder::Array::openAccessors): (Inspector::TypeBuilder::Array::addItem): (Inspector::TypeBuilder::Array::create): (Inspector::TypeBuilder::Array::runtimeCast): (Inspector::TypeBuilder::Array::assertCorrectValue): (Inspector::TypeBuilder::StructItemTraits::pushRefPtr): (Inspector::TypeBuilder::StructItemTraits::assertCorrectValue): * inspector/InspectorValues.cpp: Added. (Inspector::InspectorValue::asBoolean): (Inspector::InspectorValue::asNumber): (Inspector::InspectorValue::asString): (Inspector::InspectorValue::asValue): (Inspector::InspectorValue::asObject): (Inspector::InspectorValue::asArray): (Inspector::InspectorValue::parseJSON): (Inspector::InspectorValue::toJSONString): (Inspector::InspectorValue::writeJSON): (Inspector::InspectorBasicValue::asBoolean): (Inspector::InspectorBasicValue::asNumber): (Inspector::InspectorBasicValue::writeJSON): (Inspector::InspectorString::asString): (Inspector::InspectorString::writeJSON): (Inspector::InspectorObjectBase::~InspectorObjectBase): (Inspector::InspectorObjectBase::asObject): (Inspector::InspectorObjectBase::openAccessors): (Inspector::InspectorObjectBase::getBoolean): (Inspector::InspectorObjectBase::getString): (Inspector::InspectorObjectBase::getObject): (Inspector::InspectorObjectBase::getArray): (Inspector::InspectorObjectBase::get): (Inspector::InspectorObjectBase::remove): (Inspector::InspectorObjectBase::writeJSON): (Inspector::InspectorObjectBase::InspectorObjectBase): (Inspector::InspectorArrayBase::~InspectorArrayBase): (Inspector::InspectorArrayBase::asArray): (Inspector::InspectorArrayBase::writeJSON): (Inspector::InspectorArrayBase::InspectorArrayBase): (Inspector::InspectorArrayBase::get): (Inspector::InspectorObject::create): (Inspector::InspectorArray::create): (Inspector::InspectorValue::null): (Inspector::InspectorString::create): (Inspector::InspectorBasicValue::create): * inspector/InspectorValues.h: Added. (Inspector::InspectorObjectBase::find): (Inspector::InspectorObjectBase::setBoolean): (Inspector::InspectorObjectBase::setNumber): (Inspector::InspectorObjectBase::setString): (Inspector::InspectorObjectBase::setValue): (Inspector::InspectorObjectBase::setObject): (Inspector::InspectorObjectBase::setArray): (Inspector::InspectorArrayBase::pushBoolean): (Inspector::InspectorArrayBase::pushInt): (Inspector::InspectorArrayBase::pushNumber): (Inspector::InspectorArrayBase::pushString): (Inspector::InspectorArrayBase::pushValue): (Inspector::InspectorArrayBase::pushObject): (Inspector::InspectorArrayBase::pushArray): * inspector/scripts: Added. * jit/JITOperations.cpp: * jsc.cpp: * make-generated-sources.sh: * offlineasm/mips.rb: * offlineasm/sh4.rb: * 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::::parseFunctionBody): (JSC::::parseFunctionInfo): (JSC::::parseFunctionDeclaration): (JSC::::parseProperty): (JSC::::parseObjectLiteral): (JSC::::parseStrictObjectLiteral): (JSC::::parseMemberExpression): * parser/Parser.h: * parser/ParserArena.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createProperty): (JSC::SyntaxChecker::createGetterOrSetterProperty): * 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: * runtime/VM.h: * testRegExp.cpp: 2014-01-22 Filip Pizlo Unreviewed, fix style. This slipped past code review. The following is wrong: void compileArithSin(){ for two reasons: 1. There should be a space between ) and {. 2. For function bodies, we always put the { on the next line, like: void compileArithSin() { I fixed this by putting these function bodies all on one line, since they are very small anyway. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileArithSin): (JSC::FTL::LowerDFGToLLVM::compileArithCos): (JSC::FTL::LowerDFGToLLVM::compileArithSqrt): 2014-01-22 Filip Pizlo FTL should support MakeRope https://bugs.webkit.org/show_bug.cgi?id=127462 Reviewed by Geoffrey Garen. * ftl/FTLAbstractHeap.cpp: (JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap): (JSC::FTL::IndexedAbstractHeap::baseIndex): (JSC::FTL::IndexedAbstractHeap::initialize): (JSC::FTL::NumberedAbstractHeap::NumberedAbstractHeap): (JSC::FTL::AbsoluteAbstractHeap::AbsoluteAbstractHeap): * ftl/FTLAbstractHeap.h: * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileMakeRope): (JSC::FTL::LowerDFGToLLVM::speculate): * tests/stress/make-rope-2.js: Added. (foo): * tests/stress/make-rope-3.js: Added. (foo): 2014-01-22 Filip Pizlo FTL should support ToString https://bugs.webkit.org/show_bug.cgi?id=127460 Reviewed by Geoffrey Garen. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileToString): (JSC::FTL::LowerDFGToLLVM::speculate): (JSC::FTL::LowerDFGToLLVM::speculateStringObject): (JSC::FTL::LowerDFGToLLVM::speculateStringOrStringObject): (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForCell): (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructure): * tests/stress/to-string-on-object-or-string.js: Added. (Foo): (Foo.prototype.toString): (foo): * tests/stress/to-string-on-object.js: Added. (Foo): (Foo.prototype.toString): (foo): * tests/stress/to-string-on-string-object.js: Added. (foo): * tests/stress/to-string-on-string-or-string-object.js: Added. (foo): * tests/stress/to-string-on-string-or-string-object-then-object.js: Added. (foo): (Foo): (Foo.prototype.toString): * tests/stress/to-string-on-value-or-string.js: Added. (foo): * tests/stress/to-string-on-value.js: Added. (foo): 2014-01-22 Filip Pizlo FTL should support GetCallee https://bugs.webkit.org/show_bug.cgi?id=127459 Reviewed by Geoffrey Garen. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetCallee): 2014-01-22 Mark Lam Switching Windows port to using the C Loop LLINT. https://bugs.webkit.org/show_bug.cgi?id=127228. Reviewed by Geoffrey Garen. With the switch to using the C stack for the JS stack, the LLINT becomes a mandatory component for providing trampoline glue code to enter JIT code. Since the Windows port does not currently have a LLINT implementation that can generate assembly code for Windows, we'll switch the Windows port to using the C Loop LLINT. Note: We're opting to not continue using hand-written glue code for the Windows port because they can easily bit rot relative to the LLINT asm source. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * jit/JITStubsMSVC64.asm: Removed. * jit/JITStubsX86.h: - Removing these hand-written pieces of glue code that are no longer needed with the switch to using the C Loop LLINT. 2014-01-21 Filip Pizlo FTL should support CheckArgumentsNotCreated https://bugs.webkit.org/show_bug.cgi?id=127384 Reviewed by Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLCompile.cpp: (JSC::FTL::fixFunctionBasedOnStackMaps): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileCheckArgumentsNotCreated): 2014-01-22 Michael Saboff CStack Branch: Fix DFG for X86-32 https://bugs.webkit.org/show_bug.cgi?id=127407 Reviewed by Filip Pizlo. Made DFG calling convention changes. Change frameRegisterCount() to appropriately round so the stack pointer will end up being properly aligned. Removed some stack pointer alignment checks that are before setting the stack pointer. Fixed maxFrameExtentForSlowPathCall to account that the most arguments we actually use when calling a helper is 7. Added a compile assert to make sure that maxFrameExtentForSlowPathCall has the right padding. Made the corresponding changes in the LLInt. Moved the stack pointer down by maxFrameExtentForSlowPathCall before calling a helper when the stack pointer hasn't been properly set up. Eliminated emitGetReturnPCFromCallFrameHeaderPtr() since it is no longer called. Moved the stack pointer down in ThunkGenerators::defineUnaryDoubleOpWrapper() to align it for storing xmm arguments and making a call to the helper. Fixed an issue where ArityCheckFailReturnThunks was clobbering edx. Changed it to use regT4 (edi) instead of regT1 (edx). Made temporary space on the stack for in the LLInt when calling out to C code when the stack ponter hasn't been properly set up for a code block. * assembler/MaxFrameExtentForSlowPathCall.h: * dfg/DFGGraph.cpp: (JSC::DFG::Graph::frameRegisterCount): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * jit/ArityCheckFailReturnThunks.cpp: (JSC::ArityCheckFailReturnThunks::returnPCsFor): * jit/AssemblyHelpers.h: * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JITCall32_64.cpp: (JSC::JIT::compileOpCall): * jit/JITInlines.h: (JSC::JIT::emitNakedCall): * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: 2014-01-22 Michael Saboff Unreviewed build fix for non FTL platforms. * ftl/FTLValueRange.cpp: Encapsulated code within #if ENABLE(FTL_JIT) / #endif 2014-01-21 Filip Pizlo Add a --enableExperimentalFTLCoverage option and use it to protect recently added features. Rubber stamped by Mark Hahnenberg. We're still in a mode where adding new FTL features can cause performance regressions. This allows us to add them and get them to be tested for correctness while we still continue to track progress on performance work. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * runtime/Options.h: 2014-01-21 Filip Pizlo FTL should support AllocationProfileWatchpoint https://bugs.webkit.org/show_bug.cgi?id=127383 Rubber stamped by Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): 2014-01-20 Filip Pizlo IC status classes should directly query exit site information https://bugs.webkit.org/show_bug.cgi?id=127326 Reviewed by Geoffrey Garen. This consolidates all of the reasoning about whether or not to inline an IC at the IR level. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFromLLInt): (JSC::CallLinkStatus::computeFor): * bytecode/CallLinkStatus.h: * bytecode/CodeBlock.h: (JSC::CodeBlock::hasExitSite): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::hasExitSite): (JSC::GetByIdStatus::computeFor): * bytecode/GetByIdStatus.h: * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::hasExitSite): (JSC::PutByIdStatus::computeFor): * bytecode/PutByIdStatus.h: * bytecode/StructureSet.h: (JSC::StructureSet::StructureSet): (JSC::StructureSet::add): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validate): 2014-01-20 Matthew Mirman ArithSqrt in FTL https://bugs.webkit.org/show_bug.cgi?id=127320 Reviewed by Filip Pizlo. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): Added (JSC::FTL::LowerDFGToLLVM::compileArithSin): Simplified implementation (JSC::FTL::LowerDFGToLLVM::compileArithCos): Simplified implementation (JSC::FTL::LowerDFGToLLVM::compileArithSqrt): Added * ftl/FTLOutput.h: (JSC::FTL::Output::doubleSqrt): Added * tests/stress/ftl-arithsqrt.js: Added. (foo): 2014-01-20 Matthew Mirman ArithCos in FTL https://bugs.webkit.org/show_bug.cgi?id=127136 Reviewed by Filip Pizlo. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileArithCos): * ftl/FTLOutput.h: (JSC::FTL::Output::doubleCos): * tests/stress/ftl-arithcos.js: Added. (foo): 2014-01-19 Filip Pizlo FTL should ascribe range meta-data when loading array.length https://bugs.webkit.org/show_bug.cgi?id=126543 Reviewed by Geoffrey Garen. The main thing this accomplishes is we now have Output::load32NonNegative() which is a 32-bit integer load that promises that the value is not negative. We then use that for all length loads. But underneath that, we have the notion of ValueRange, which is a simplified encapsulation of LLVM "range" metadata. I considered making the range meta-data part of AbstractHeap. It would make sense there. But considering that we just use this for basically one thing (the length), it feels like conflating this with the AbstractHeap would result in some overengineering. We should revisit this if we ever have other ranges. * JavaScriptCore.xcodeproj/project.pbxproj: * ftl/FTLCommonValues.cpp: (JSC::FTL::CommonValues::CommonValues): * ftl/FTLCommonValues.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compileStringCharAt): (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt): (JSC::FTL::LowerDFGToLLVM::compileSwitch): (JSC::FTL::LowerDFGToLLVM::typedArrayLength): (JSC::FTL::LowerDFGToLLVM::boolify): (JSC::FTL::LowerDFGToLLVM::contiguousPutByValOutOfBounds): * ftl/FTLOutput.h: (JSC::FTL::Output::ascribeRange): (JSC::FTL::Output::nonNegative32): (JSC::FTL::Output::load32NonNegative): * ftl/FTLValueRange.cpp: Added. (JSC::FTL::ValueRange::decorateInstruction): * ftl/FTLValueRange.h: Added. (JSC::FTL::ValueRange::ValueRange): (JSC::FTL::ValueRange::begin): (JSC::FTL::ValueRange::end): 2014-01-16 Mark Lam Fix 32-bit C loop LLINT. https://bugs.webkit.org/show_bug.cgi?id=127086. Reviewed by Geoffrey Garen. * llint/LowLevelInterpreter32_64.asm: 2014-01-17 Filip Pizlo FTL mishandles (-2147483648 % 0) | 0 https://bugs.webkit.org/show_bug.cgi?id=127215 Reviewed by Sam Weinig. This fixes: jsc-layout-tests.yaml/js/script-tests/dfg-mod-neg2tothe31-by-one-and-then-or-zero-with-interesting-reg-alloc.js.layout-ftl-eager-no-cjit Now the FTL passes all JSC layout tests. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileArithDivMod): 2014-01-17 Filip Pizlo FTL should update machine virtual registers in runtime meta-data according to the captured stackmap https://bugs.webkit.org/show_bug.cgi?id=125725 Reviewed by Michael Saboff. This is pretty awesome - it closes the loop on our FTL stackwalking story. We use an alloca for storing all of the things that the runtime will want to discover during a stack walk, like the closure pointer for inlined closure calls and the arguments to inlined functions. We then pass that alloca as an argument to a stackmap in the prologue, and LLVM reports the alloca's frame offset using a stackmap direct entry. We call this the "localsOffset". Previously we just used this to update some OSR exit meta-data. Now we also use it to properly adjust the ValueRecovery meta-data in inline call frames. Currently we only have to do this for inline call frames and OSR exits, but in the future we'll use similar techniques for activations. This bug doesn't cover that since the FTL doesn't support compiling functions that create activations, yet. This change makes us incorporate localsOffset into all of the relevant things that the FTL supports. This fixes: jsc-layout-tests.yaml/js/script-tests/dfg-inline-arguments-use-from-all-the-places.js.layout-ftl-eager-no-cjit With this fix, the FTL only fails one of the JSC layout tests. * bytecode/ValueRecovery.h: (JSC::ValueRecovery::withLocalsOffset): * ftl/FTLCompile.cpp: (JSC::FTL::fixFunctionBasedOnStackMaps): 2014-01-17 Michael Saboff CStack Branch: Fix Baseline JIT for X86-32 https://bugs.webkit.org/show_bug.cgi?id=127201 Reviewed by Geoffrey Garen. Most of the changes are to follow calling convention (emiting function prologues and epilogues) and making room on the stack for outgoing arguments. * interpreter/Interpreter.cpp: (JSC::Interpreter::unwind): * jit/JIT.cpp: (JSC::JIT::privateCompile): Eliminated stack alignment check before moving the stack pointer down for locals since it will not be aligned at that time. The move will align the stack pointer. (JSC::JIT::frameRegisterCountFor): Changed to allocate the outgoing register space after rounding the number of local registers as the outgoing register count will properly align the local registers. * jit/JITCall32_64.cpp: (JSC::JIT::emit_op_ret): Changed to emit epilogue. (JSC::JIT::emit_op_ret_object_or_this): Changed to emit epilogue. (JSC::JIT::compileLoadVarargs): Alignment changes matching what is in JITCall.cpp::JIT::compileLoadVarargs. (JSC::JIT::compileCallEvalSlowCase): Changed to use the stack pointer to fill-in the new callee frame. (JSC::JIT::compileOpCall): Changed to use the stack pointer to fill-in the new callee frame. (JSC::JIT::compileOpCallSlowCase): Code to restore the stack pointer after the call. * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_ret_object_or_this): Remove dead code in 64 bit path found while working on this patch. * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): Changes to follow native calling convention, allocate space and populate outgoing args and pass the caller to operationVMHandleException. (JSC::JIT::emit_op_end): Emit the epilogue. * jit/ThunkGenerators.cpp: (JSC::slowPathFor): Allocate stack space for arguments. (JSC::arityFixup): Changes to match 64 bit code. * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): Whitespace cleanup. 2014-01-17 Michael Saboff CStack Branch: X86-32 Fix LLInt https://bugs.webkit.org/show_bug.cgi?id=127071 Reviewed by Filip Pizlo. This fixes X86-32 compilation issues in JITCall32_64.cpp and JITPropertyAccess32_64.cpp. Fixed the 32 bit LLInt to work with X86. Since X86 passes arguments on the stack, calls (e.g. LLInt CCall2, JITOperations::getHostCallReturnValue) need to make an outgoing argument area on the stack, populate the arguments and then make the call. Much of the argument and call logic is based on the alignment of the stack pointer and call frame register. The stack pointer at the time of a call needs to be stackAlignmentBytes() (16 byte) aligned. The call frame register, which points at the current call frame will be at an alignment that is stackAlignmentBytes() minus what gets pushed on the stack as part of the call, i.e. the caller PC and caller frame pointer. For us this is JSStack::CallerFrameAndPCSize * sizeof(Register). Using roundLocalRegisterCountForFramePointerOffset() eliminates the need for maxFrameExtentForSlowPathCall needing additional bytes to pad out the stack to be aligned. Tested on X86-32 with LLInt only testapi. Tested on X86-64 with all javascript tests. * assembler/MaxFrameExtentForSlowPathCall.h: * interpreter/ProtoCallFrame.cpp: (JSC::ProtoCallFrame::init): * interpreter/ProtoCallFrame.h: (JSC::ProtoCallFrame::setPaddedArgCount): * jit/JITCall32_64.cpp: (JSC::JIT::compileCallEval): (JSC::JIT::compileOpCallSlowCase): * jit/JITOperations.cpp: * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_put_by_id): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntEntrypoint.cpp: (JSC::LLInt::frameRegisterCountFor): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/StackAlignment.h: (JSC::roundArgumentCountToAlignFrame): (JSC::roundLocalRegisterCountForFramePointerOffset): 2014-01-16 Filip Pizlo FTL watchpoint tests that use dfgIncrement() and friends fail because numberOfDFGCompiles() returns zero with --testTheFTL=true and right after the first FTL OSR exit but just before recompilation is triggered https://bugs.webkit.org/show_bug.cgi?id=127163 Reviewed by Michael Saboff. We just need to track if we had ever compiled with the FTL. Also rework the various bool's in CodeBlock so that they are bitfields if possible. To that end, make sure we only write to them from the main thread. This fixes a bunch of LayoutTests with --ftl-jit. Now only two fail. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpAssumingJITType): (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::numberOfDFGCompiles): * bytecode/CodeBlock.h: * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult): * dfg/DFGJITFinalizer.cpp: (JSC::DFG::JITFinalizer::finalizeCommon): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::Plan): * dfg/DFGPlan.h: * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): 2014-01-16 Filip Pizlo JSC layout tests should run with the FTL https://bugs.webkit.org/show_bug.cgi?id=127144 Reviewed by Sam Weinig. Note that this currently leads to the following failures with --ftl-jit. I will fix them in future commits. jsc-layout-tests.yaml/js/script-tests/dfg-call-function-hit-watchpoint.js.layout-ftl jsc-layout-tests.yaml/js/script-tests/dfg-call-function-hit-watchpoint.js.layout-ftl-no-cjit jsc-layout-tests.yaml/js/script-tests/dfg-call-function-hit-watchpoint.js.layout-ftl-eager-no-cjit jsc-layout-tests.yaml/js/script-tests/dfg-call-method-hit-watchpoint.js.layout-ftl jsc-layout-tests.yaml/js/script-tests/dfg-call-method-hit-watchpoint.js.layout-ftl-no-cjit jsc-layout-tests.yaml/js/script-tests/dfg-inline-arguments-use-from-all-the-places.js.layout-ftl-eager-no-cjit jsc-layout-tests.yaml/js/script-tests/dfg-mod-neg2tothe31-by-one-and-then-or-zero-with-interesting-reg-alloc.js.layout-ftl-eager-no-cjit * bytecode/CodeBlock.cpp: (JSC::CodeBlock::numberOfDFGCompiles): * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): * runtime/Options.h: 2014-01-16 Matthew Mirman ArithSin in FTL https://bugs.webkit.org/show_bug.cgi?id=127129 Reviewed by Filip Pizlo. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileArithSin): * ftl/FTLOutput.h: (JSC::FTL::Output::doubleSin): * tests/stress/ftl-arithsin.js: Added. 2014-01-15 Filip Pizlo reentrant-caching sometimes fails with LLInt disabled https://bugs.webkit.org/show_bug.cgi?id=126781 Reviewed by Michael Saboff. The lookupExceptionHandler->genericUnwind->handleUncaughtException paths need to be resilient against the frame from which we claim to be throwing the exception being the sentinel frame. Also attempted to add a test that pinpoints the problem, but it didn't cause a crash either before or after my change. That's fine, I figured it would be good to have more coverage for madness like this. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileExceptionHandlers): * ftl/FTLCompile.cpp: (JSC::FTL::fixFunctionBasedOnStackMaps): * interpreter/Interpreter.cpp: (JSC::Interpreter::unwind): * interpreter/Interpreter.h: (JSC::NativeCallFrameTracer::NativeCallFrameTracer): * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArguments): * jit/JIT.cpp: (JSC::JIT::privateCompileExceptionHandlers): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/Repatch.cpp: (JSC::tryBuildGetByIDList): * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromCallSlowPathGenerator): * llint/LowLevelInterpreter64.asm: * tests/stress/recurse-infinitely-on-getter.js: Added. (.var): 2014-01-14 Filip Pizlo FTL slow path calls in inline caches should be down with exceptions https://bugs.webkit.org/show_bug.cgi?id=127020 Reviewed by Geoffrey Garen. This just adds the relatively straight-forward glue code for emitting an exception check on FTL IC slow paths and then jumping to the exception handling path. Note that half of the attached tests failed before this change, often in very funny ways, since the FTL IC slow paths previously just ignored exceptions. The other half of the tests were some combination of accidental passes (because if you ignore the exception but someone else along some path checks it then it will be thrown and things will seem OK) and inadequate FTL coverage (so they would have failed if the FTL supported GetByIdFlush for example). Also updated some copyright notices that I previously forgot about. * ftl/FTLCompile.cpp: (JSC::FTL::fixFunctionBasedOnStackMaps): * ftl/FTLJITFinalizer.cpp: * ftl/FTLSlowPathCall.cpp: (JSC::FTL::storeCodeOrigin): (JSC::FTL::callOperation): * ftl/FTLSlowPathCall.h: * ftl/FTLState.h: * tests/stress/get-by-id-throw-from-getter-through-optimized-code.js: Added. (foo): (makeWithGetter.return): (makeWithGetter): * tests/stress/get-by-id-throw-from-unexpected-getter-through-optimized-code-that-does-not-exit.js: Added. (foo): (makeWithGetter.return): (makeWithGetter): * tests/stress/get-by-id-throw-from-unexpected-getter-through-optimized-code.js: Added. (foo): (makeWithGetter.return): (makeWithGetter): * tests/stress/ic-throw-through-optimized-code.js: Added. (foo): * tests/stress/put-by-id-throw-through-optimized-code.js: Added. (foo): 2014-01-14 Filip Pizlo FTL should be cool with runtime functions throwing exceptions https://bugs.webkit.org/show_bug.cgi?id=127018 Reviewed by Geoffrey Garen. This just adds the appropriate exception throwing off-ramp to the FTL. There's no way to express that off-ramp in LLVM IR, so we just use a stackmap that we fill with a jump to our own off-ramp. It's easy! The throw-through-optimized-code test already worked because the architecture of the FTL allows our existing unwinding to "just work". The runtime-throw-through-optimized-code test used to crash but now works. The empty-function test currently covers the case where there won't be any exception handlers, though that will cease to be the case once we have real stack checks. But even then the test will be useful - an overly optimizable function leads to many otherwise-needed stackmaps not being emitted, so this will always test some fun corner cases in FTL::fixFunctionBasedOnStackMaps(). * assembler/LinkBuffer.h: (JSC::LinkBuffer::entrypoint): * ftl/FTLCompile.cpp: (JSC::FTL::fixFunctionBasedOnStackMaps): * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::finalizeFunction): * ftl/FTLJITFinalizer.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::lower): (JSC::FTL::LowerDFGToLLVM::callCheck): * ftl/FTLState.h: * tests/stress/empty-function.js: Added. (foo): * tests/stress/runtime-throw-through-optimized-code.js: Added. (foo): (bar): * tests/stress/throw-through-optimized-code.js: Added. (foo): (bar): 2014-01-13 Mark Lam Fix 64-bit C Loop LLINT for !ENABLE(COMPUTED_GOTO_OPCODES). https://bugs.webkit.org/show_bug.cgi?id=126959. Reviewed by Michael Saboff. * llint/LowLevelInterpreter.asm: - The LLINT sanitizeStackForVM() is not needed by the C loop, and will cause a build failure in the non-computed goto C loop build. This is now fixed by excluding the LLINT sanitizeStackForVM() from the C loop build. 2014-01-13 Filip Pizlo FTL PutByVal should have a complete story for OOB https://bugs.webkit.org/show_bug.cgi?id=126961 Reviewed by Michael Saboff. Previously, the DFG would handle OOB by just ignoring the store, while the FTL would handle it by speculating. This blind speculation in the FTL caused many recompiles in Octane/gbemu. This patch makes both the DFG and FTL speculate on OOB, but we switch to ignoring the store if we have a frequent exit site. Speculating is slightly better because it allows us to hoist and fold the checks. It also makes it easier to reason about the store (that is, we know that it must have happened). This also fixes the handling of FTL OSR exits in the profiler. * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine): * dfg/DFGArrayMode.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength): * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::SSALoweringPhase::handleNode): (JSC::DFG::SSALoweringPhase::lowerBoundsCheck): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): * ftl/FTLCompile.cpp: (JSC::FTL::fixFunctionBasedOnStackMaps): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compilePutByVal): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * tests/stress/int16-put-by-val-in-and-out-of-bounds.js: Added. (foo): (test): * tests/stress/int16-put-by-val-in-bounds-then-exit-out-of-bounds.js: Added. (foo): (test): * tests/stress/int16-put-by-val-out-of-bounds-bounds-then-do-in-bounds.js: Added. (foo): (test): 2014-01-13 Mark Lam Gardening: fix bad merge of https://bugs.webkit.org/show_bug.cgi?id=126790 on top of https://bugs.webkit.org/show_bug.cgi?id=126932. Not reviewed. * llint/LowLevelInterpreter.asm: - the 2 patches implemented the same change in callToJavaScriptPrologue() and callToJavaScriptEpilogue(), but svn merged the changes without reporting a conflict. The result is a redundant push of lr and pop of cfr. This is now fixed. 2014-01-13 Mark Lam CStack: Fix 64-bit C Loop LLINT. https://bugs.webkit.org/show_bug.cgi?id=126790. Reviewed by Geoffrey Garen. 1. Fixed miscellaneous bugs relevant for the C Loop LLINT (details below). 2. Simplified CLoop::execute() by making it more emulate CPU calls as well. This is done by automatically synthesizing an opcode label at the return point after the call to JS code. The "lr" register (named after the ARM link register) will be set to that return opcode label before the call. The call itself is implemented as an opcode dispatch. * heap/Heap.cpp: (JSC::Heap::markRoots): - Fixed typo: LLINT_CLOOP ==> LLINT_C_LOOP. * interpreter/JSStack.cpp: (JSC::JSStack::gatherConservativeRoots): - Previously, we were declaring a span from baseOfStack() to topOfStack(). baseOfStack() points to the highest slot in the stack. topOfStack() points to the word below the lowest slot in the stack. The ConservativeRoots class will invert the high and low pointers to ensure that it iterates from low to high. However, with this span, the GC will miss not scan the highest slot in the stack, and will instead scan the slot below the stack which is technically outside the stack. The span is now fixed to be from topOfStack() + 1 to highAddress(). highAddress() points at the slot above the highest slot in the stack. This means GC will now correctly scan the stack from its lowest to its highest slots (inclusive). (JSC::JSStack::sanitizeStack): - Similar to the gatherConservativeRoots() case, sanitizeStack() is nullifying a span of stack that starts at 2 past the lowest slot in the stack. This is because topOfStack() points at the slot below the lowest slot in the stack. m_lastStackTop() points to an old topOfStack() i.e. it potentially points to a slot that is not in the region of memory allocated for the stack. We now add 1 to both of these values to ensure that we're zeroing a region that is in the stack's allocated memory, and stop at the slot (inclusive) just below the stack's current lowest used slot. * interpreter/JSStack.h: * interpreter/JSStackInlines.h: - Made topOfStack() public because CLoop::execute() needs it. - The LLINT assembly (in CLoop::execute()) now takes care of pushing and popping the stack. Hence, we no longer need JSStack's pushFrame, popFrame, and stack fence infrastruture which relies on pushFrame and popFrame. These are now removed. * llint/LLIntOpcode.h: - Added new pseudo opcodes: - llint_return_to_host: this is the pseudo return address for returning to the host i.e. return from CLoop::execute(). - llint_cloop_did_return_from_js_X: these are synthesized by the cloop offlineasm as needed i.e. every time it needs to generate code for a cloopCallJSFunction "instruction". These are the opcodes that will serve as the return point that we store in lr and return to when we see a "ret" opcode. While the offlineasm automatically generates these in LLIntAssembly.h, we have to manually add the declaration of these opcodes here. If we end up generating more or less in the future (due to changes in the LLINT assembly code), then we'll get compiler errors that will tell us to update this list. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_stack_check_at_vm_entry): * llint/LLIntSlowPaths.h: - This slow path isn't needed for the non C loop build because the stack is finite sized and grows itself on access. For the C loop, we need this check function to give the JSStack a chance to grow the stack. * llint/LowLevelInterpreter64.asm: - Added call to llint_stack_check_at_vm_entry in doCallToJavaScript(). - Fixed up calls and stack adjustments. - In makeHostFunctionCall(), the non C loop build will push lr and cfr when we call the host function. That's why we adjust the sp by 16 before the call. For the C loop build, we need to set the lr and cfr ourselves here. - In nativeCallTrampoline(), unlike makeHostFunctionCall(), the return address and cfr has already been set in the frame. Hence, we didn't have to do anything extra. Also got rid of the distinct block for the C_LOOP and just reuse the block for ARM64 since it is exactly what the C_LOOP needs for the most part. * llint/LowLevelInterpreter.asm: - Added push/pop or lr and cfr as needed. - In callTargetFunction(), make the C_LOOP use the same code as other targets except for the call instruction. - Same for slowPathForCall(). - In prologue(), exclude the OSR check code for the C_LOOP build since it is not needed. Also added popping of cfr and lr since I'm working through this logic already. * llint/LowLevelInterpreter.cpp: (JSC::CLoopRegister::operator Register*): (JSC::CLoop::execute): - Added TRACE_OPCODE() for debugging use only. - Simplified some CLoopRegister names. - Initialize the needed registers and incoming arguments before entering the interpreter loop. - Added llint_return_to_host as the exit opcode for returning from CLoop::execute(). We set it as the value for lr (the return address) before we enter the interpreter loop. - Updated the getHostCallReturnValue opcode handler to match the current getHostCallReturnValue and getHostCallReturnValueWithExecState code in JITOperations.cpp. * offlineasm/cloop.rb: - Updated C loop register names. - Added tracking of the number of cloop_did_return_from_js labels. - Added push, pop, and change the implementation of the cloopCallJSFunction pseudo instruction to use synthesized cloop_did_return_from_js opcodes / labels as return addresses. * runtime/Executable.cpp: - Fix C loop build breaker by a prior patch. * runtime/VM.cpp: (JSC::VM::VM): - Fixed typo: LLINT_CLOOP ==> LLINT_C_LOOP. 2014-01-13 Michael Saboff CStack Branch: Fix unwind on branch for X86-64 https://bugs.webkit.org/show_bug.cgi?id=126932 Reviewed by Geoffrey Garen. Added code to push bp ; move sp, bp as the first instructions in callToJavaScript. This complies with what happens at the top of most functions. This added push is used to restore bp in the prologue. The values for the return PC and save BP in the sentinel frame are only used for unwinding. Made similar mods to other platforms. Added eh_frame directives to LLInt global labels to get unwinding through them working as well. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: * llint/LowLevelInterpreter64.asm: 2014-01-12 Filip Pizlo internal-js-tests.yaml/Octane/mandreel.js.default-ftl fails about 1/30 times with "TypeError: undefined is not an object" https://bugs.webkit.org/show_bug.cgi?id=126797 Reviewed by Michael Saboff. This bug was a hilarious combination of concurrent JIT (making it a flake), LLInt->JIT OSR, and the FTL's register preservation wrapper. Consider that a CodeBlock with a LLInt JITCode may get called, and while running, it may decide to tier up to the baseline JIT. At that point, the old JITCode gets summarily deleted and replaced by the baseline JITCode. This used to be "correct" because the LLInt's JITCode only held a reference to an immortal entrypoint thunk. But not anymore: now the LLInt's JITCode may also hold references to register preservation wrappers, which get generated lazily. So consider that the FTL calls a LLInt'd CodeBlock and that LLInt JITCode lazily creates a register preservation wrapper. That register preservation wrapper is on the stack and the stack will have a return PC that points to it. Then the LLInt code decides to tier up to the baseline JIT. This causes the LLInt JITCode to get deleted. That means that the register preservation wrapper also gets deleted. Now all it takes is for some more executable memory to get allocated, and when that baseline JIT frame (that used to be a LLInt frame) returns, it returns into what it *thinks* is a register preservation wrapper - except now it's something else! Hilariously, the thing that we'd return into in mandreel was a PutByVal stub. When the concurrent JIT interleaved itself in such a way as to make this case happen (i.e. the FTL code for runMandreel was compiled just as some mandreel init routine was *about* to get tiered up to baseline JIT), then the baseline code would *always* allocate a PutByVal stub right where the register preservation wrapper's return site used to be. Thus, returning from the baseline code for that initialization function would cause it to jump to a PutByVal stub for one of the PutByVal's in that same function. Somehow, we'd always end up returning to a valid instruction rather than into the middle of something. That PutByVal stub would then do a type check on some random variable that it thought was the base - it would of course fail - and then the slow path would try to do conversions - that would result in it seeing undefined - and then usually we would crash while trying to throw the exception. The solution is to make the return site of the register preservation thunk be always immortal. We already had a standalone immortal return ramp for that thunk for use by FTL OSR exit. I figure it doesn't hurt to just always use that immortal return site. This bug took several days to track down. I don't think I can add more tests for this, although I'll think about it. Basically the lesson here is that running big tests like Mandreel over and over again with the concurrent JIT enabled shakes out interesting bugs. This change also adds some useful debug flags, like --breakOnThrow=true, which causes us to CRASH() whenever an exception is thrown. Without this, this bug was basically impossible to figure out: we would wind up somewhere in handleUncaughtException and then that code would go *completely berserk* because the stack is of course totally screwed up once we "returned" into that PutByVal stub. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpAssumingJITType): (JSC::CodeBlock::CodeBlock): * dfg/DFGCompilationMode.h: (JSC::DFG::isFTL): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::reportCompileTimes): (JSC::DFG::Plan::compileInThread): (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPlan.h: * ftl/FTLCompile.cpp: (JSC::FTL::compile): * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/RegisterPreservationWrapperGenerator.cpp: (JSC::generateRegisterPreservationWrapper): (JSC::generateRegisterRestoration): * jit/RegisterPreservationWrapperGenerator.h: * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/Options.h: * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::throwException): 2014-01-11 Filip Pizlo Eliminate obviously redundant InvalidationPoints https://bugs.webkit.org/show_bug.cgi?id=126825 Reviewed by Geoff Garen. * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::invalidationPointElimination): (JSC::DFG::CSEPhase::performNodeCSE): 2014-01-11 Filip Pizlo Unreviewed, add a test for InvalidationPoint in the FTL. Probably there are other tests that cover this in various ways and it's possible that we're just not running those tests in the FTL, yet. But anyway I think it's good to have an FTL-specific test for this. * tests/stress/invalidation-point.js: Added. (foo): (Thingy): (Thingy.prototype.f): (possiblyDoBadThings.Thingy.prototype.f): (possiblyDoBadThings): 2014-01-11 Filip Pizlo FTL tier-up should behave the same with CountExecution's as it does without https://bugs.webkit.org/show_bug.cgi?id=126822 Reviewed by Sam Weinig. CountExecution nodes are inserted by the profiler. Prior to this change, their presence would change how we inserted CheckTierUp nodes, since a CountExecution might be inserted before a LoopHint thereby making it so the LoopHint was no longer at the top of a loop header. This makes the code resilient against such things. The result is that when you enable the profiler, you get the same OSR behavior as with the profiler disabled. * dfg/DFGNode.h: (JSC::DFG::Node::isSemanticallySkippable): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): 2014-01-10 Filip Pizlo FTL should work with the bytecode profiler https://bugs.webkit.org/show_bug.cgi?id=126804 Reviewed by Sam Weinig. Implement CountExecution in FTL and make the FTL report a compilation with some kind of description to the database. This still leaves a lot to be desired; for example the descriptions we report don't have disassembly. But, this small step already allows for some basic profiling. * dfg/DFGPlan.cpp: (JSC::DFG::profilerCompilationKindForMode): (JSC::DFG::Plan::Plan): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::finalizeFunction): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileCountExecution): * profiler/ProfilerCompilation.cpp: (JSC::Profiler::Compilation::addDescription): * profiler/ProfilerCompilation.h: * profiler/ProfilerCompilationKind.cpp: (WTF::printInternal): * profiler/ProfilerCompilationKind.h: 2014-01-10 Filip Pizlo Unreviewed, unbreak all tests by undoing some assertions junk in http://trac.webkit.org/changeset/161732 and changing typo "node->function()" which should have been "node->executable()". * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileCheckExecutable): * runtime/Options.cpp: (JSC::recomputeDependentOptions): (JSC::Options::initialize): 2014-01-10 Filip Pizlo FTL should enough things to compile inlined closure calls (like CheckExecutable and GetScope) https://bugs.webkit.org/show_bug.cgi?id=126799 Reviewed by Oliver Hunt. Added FTL support for CheckExecutable and GetScope because I wanted to compile closure calls. But then I realized that closure call inlining was broken because the baseline JIT would link the closure stubs to the slow path, thereby causing the DFG's profiling to think that all closure calls are actually virtual calls. Also fixed some hash() computing stuff to make debugging easier. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileCheckExecutable): (JSC::FTL::LowerDFGToLLVM::compileGetScope): * jit/Repatch.cpp: (JSC::linkClosureCall): * runtime/Options.cpp: (JSC::recomputeDependentOptions): (JSC::Options::initialize): (JSC::Options::setOption): * tests/stress/inline-closure-call.js: Added. (bar): 2014-01-10 Filip Pizlo It should be easier to diagnose FTL performance issues due to register preservation thunks https://bugs.webkit.org/show_bug.cgi?id=126798 Reviewed by Geoff Garen. You can now use --verboseFTLToJSThunk=true --verboseFTLFailure=true to figure out which code blocks are rejected by the FTL and yet get called from functions that were FTL compiled. Any such rejections in major benchmarks should be fixed. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): * ftl/FTLCapabilities.cpp: (JSC::FTL::verboseCapabilities): (JSC::FTL::canCompile): * jit/RegisterPreservationWrapperGenerator.cpp: (JSC::generateRegisterPreservationWrapper): * runtime/Executable.cpp: (JSC::ExecutableBase::dump): * runtime/Executable.h: * runtime/Options.cpp: (JSC::Options::initialize): * runtime/Options.h: 2014-01-10 Filip Pizlo Unreviewed, add a test for the case where LLVM finds a constant folding opportunity that the DFG missed, and it involves a large constant, and then we exit with the large constant folded into a stackmap for an OSR exit. We fixed this incidentally as part of http://trac.webkit.org/changeset/161543, but it only showed up as part of new tests specific to add/sub recovery and as a Octane/gbemu *slow-down* because gbemu had such a constant. It seems like we should have an explicit test for this since it's a really gross bug to have in a rather critical code path. * tests/stress/exit-after-llvm-folds-large-int-constant.js: Added. (foo): 2014-01-10 Filip Pizlo DFG should insert Phantoms when it uses conversion nodes https://bugs.webkit.org/show_bug.cgi?id=126777 Reviewed by Oliver Hunt. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupSetLocalsInBlock): (JSC::DFG::FixupPhase::fixupUntypedSetLocalsInBlock): (JSC::DFG::FixupPhase::fixEdge): (JSC::DFG::FixupPhase::fixIntEdge): (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): (JSC::DFG::FixupPhase::addPhantomsIfNecessary): * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validate): * tests/stress/exit-after-int32-to-double.js: Added. (foo): * tests/stress/exit-after-int52-to-double.js: Added. (foo): * tests/stress/exit-after-int52-to-value.js: Added. (foo): (makeWeirdObject): 2014-01-09 Mark Lam Merge trunk r161446. 2014-01-09 Filip Pizlo DFG and FTL should have separate compilation worklists https://bugs.webkit.org/show_bug.cgi?id=126722 Reviewed by Mark Hahnenberg. There are a number of architectural changes here: - DFGDriver.cpp is now the only place that decides whether or not to do a concurrent compile. Previously this decision was oddly squirreled away in VM.cpp. - VM no longer points to a worklist. That was always kind of weird since there was only one worklist per process anyway. - There are now two worklists: one for all DFG compiles and one for all FTL compiles. - The FTL worklist is now parallel by default. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::checkIfOptimizationThresholdReached): * dfg/DFGCommon.h: * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): (JSC::DFG::compile): * dfg/DFGDriver.h: * dfg/DFGOperations.cpp: * dfg/DFGWorklist.cpp: (JSC::DFG::initializeGlobalDFGWorklistOnce): (JSC::DFG::ensureGlobalDFGWorklist): (JSC::DFG::existingGlobalDFGWorklistOrNull): (JSC::DFG::initializeGlobalFTLWorklistOnce): (JSC::DFG::ensureGlobalFTLWorklist): (JSC::DFG::existingGlobalFTLWorklistOrNull): (JSC::DFG::ensureGlobalWorklistFor): * dfg/DFGWorklist.h: * jit/JITOperations.cpp: * runtime/Options.h: * runtime/VM.cpp: (JSC::cleanWorklist): (JSC::VM::~VM): (JSC::prepareToDiscardCodeFor): (JSC::VM::prepareToDiscardCode): (JSC::VM::gatherConservativeRoots): * runtime/VM.h: 2014-01-09 Mark Lam CStack: Rename "host zone" to "reserved zone". https://bugs.webkit.org/show_bug.cgi?id=126716. Reviewed by Michael Saboff. The "zone" is used as a reserve of stack memory for: 1. nominal host code stack usage. 2. stack space for error handling. 3. initial stack space for pushing VMEntrySentinel frames. The "zone" may reside on the C stack and on the C loop JSStack depending on context. Hence, the name "host zone" is not quite accurate, and we'll rename it to "reserved zone". * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::growSlowCase): (JSC::JSStack::releaseExcessCapacity): (JSC::JSStack::setReservedZoneSize): * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::shrink): * runtime/ErrorHandlingScope.cpp: (JSC::ErrorHandlingScope::ErrorHandlingScope): (JSC::ErrorHandlingScope::~ErrorHandlingScope): * runtime/ErrorHandlingScope.h: * runtime/JSLock.cpp: (JSC::JSLock::DropAllLocks::DropAllLocks): (JSC::JSLock::DropAllLocks::~DropAllLocks): * runtime/JSLock.h: * runtime/Options.h: * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::updateStackLimitWithReservedZoneSize): * runtime/VM.h: (JSC::VM::reservedZoneSize): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::~VMEntryScope): * runtime/VMEntryScope.h: 2014-01-09 Mark Lam CStack: Need a separate stack limit for the JS stack and the C stack. https://bugs.webkit.org/show_bug.cgi?id=126320. Reviewed by Geoffrey Garen. The purpose of this patch is mainly to change the way we compute the stack limit for JS stack checks. Previously, we tally up the stack usage per session of VM re-entry as tracked by the VMEntryScope, and we ensure that the total usage does not exceed Options::maxStackSize(), and of course, is also capped by the amount of native C stack available. The usage tracking here does not count host / native function stack usage against the max stack usage. The new way is to compute a limit as an offset from the VMEntryScope of the first entry into the VM. Options::maxPerThreadStackUsage() will provide that offset. Any host / native function stack usage after we've entered the VM will be counted against the max stack usage. This patch supplants parts or all of the following previously committed patches: r161104: https://bugs.webkit.org/show_bug.cgi?id=126266 Rename VM::entryScope to firstEntryScope. r161232: https://bugs.webkit.org/show_bug.cgi?id=126321 Introducing Options::maxStackSize(). r161172: https://bugs.webkit.org/show_bug.cgi?id=126331 Refactor to split the tracking of the jsStackLimit from the native stackLimit. r161174: https://bugs.webkit.org/show_bug.cgi?id=126334 Introduce tracking of the top VMEntryScope. r161361: https://bugs.webkit.org/show_bug.cgi?id=126487 The fixed up jsStackLimit in doCallToJavaScript should not exceed the native stack limit. r161180: https://bugs.webkit.org/show_bug.cgi?id=126320 Need a separate stack limit for the JS stack and the C stack. This was for the old way of tracking chunks of stack usage per VMEntryScope. Details of this patch: 1. Renamed VM::firstEntryScope back to VM::entryScope. Removed the tracking of topEntryScope and related code. 2. Renamed Options::maxStackSize() to maxPerThreadStackUsage(). Added Options::hostZoneSize() and Options::errorModeHostZoneSize(). 3. The VM now tracks its current hostZoneSize and stack limits. VM::m_stackLimit is computed when the hostZoneSize is set via VM::updateStackLimitWithHostZoneSize(). In the C Loop LLINT case, the VM also provides a setJSStackLimit() since VM::m_stackLimit and VM::m_jsStackLimit are 2 different values in that case. 4. Replaced Interpreter::ErrorHandlingMode with ErrorHandlingScope. The ErrorHandlingScope constructor will set the VM host zone size to Options::errorModeHostZoneSize(), and restore the previous host zone size. The destructor for ErrorHandlingScope will restore the previous stack limit. We can enter multiple ErrorHandlingScopes. Only the destruction of the very first one will restore the stack limit with the non-error mode host zone. 5. LLINT C loop JSStack changes: 5.1 Replaced calls to roundUpToAllocationSize() with WTF::roundUpToMultipleOf(). roundUpToAllocationSize() is redundant and is now removed. 5.2 Removed enable/disableErrorStackReserve() and updateStackLimit(). Their function is now handled by JSStack::setHostZoneSize(). 5.3 Added accounting for a host zone in the LLINT C loop JSStack. This includes growing the JS stack to allow space for the host zone whenever the host zone size is adjusted via JSStack::setHostZoneSize(). Note: though setHostZoneSize() is based on disableErrorStackReserve(), we don't retain the logic to shrink the stack there. That logic was always dead code: we only call shrink() if m_end + 1 < m_useableTop, but shrink() will only shrink the stack if m_end is pointing to the base of the stack i.e. the 2 conditions are mutually exclusive, and no work to shrink the stack will ever be done here. m_useableTop is no longer needed and is now removed. 5.4 Change all non C loop code to reference VM::stackLimit() instead of VM::jsStackLimit(). Though the 2 are the same for non C loop builds, this makes it more straightforward. We now only reference the jsStackLimit in 2 cases: a. LLINT and JIT code performing stack checks where they expect the jsStackLimit to be a pseudonym for the stackLimit in non C loop builds. b. In the C loop build, the JSStack itself sets VM::m_jsStackLimit() when it adjusts its host zone size. In all other cases, we work directly with VM::stackLimit(). 6. Simplify the tracking of VM::stackPointerAtVMEntry. We now set VM::stackPointerAtVMEntry when we install a VMEntryScope if and only if it isn't already set. When we drop the API locks, we'll save the current stackPointerAtVMEntry and stack limit value, and clear stackPointerAtVMEntry to allow a new thread acquiring the API locks to re-set it when it installs a VMEntryScope. When we re-acquire the API locks again, we'll restore the previously saved stackPointerAtVMEntry and stack limit. With this change, we also no longer need the stackPointerAtVMEntry fix up code in doCallToJavaScript(). That code is now removed. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * debugger/Debugger.cpp: (JSC::Debugger::recompileAllJSFunctions): * debugger/DebuggerCallFrame.cpp: * heap/Heap.cpp: (JSC::Heap::lastChanceToFinalize): (JSC::Heap::deleteAllCompiledCode): * interpreter/CallFrame.cpp: (JSC::CallFrame::vmEntryGlobalObject): * interpreter/Interpreter.cpp: * interpreter/Interpreter.h: * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::~JSStack): (JSC::JSStack::growSlowCase): (JSC::JSStack::releaseExcessCapacity): (JSC::JSStack::setHostZoneSize): (JSC::JSStack::lowAddress): * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::ensureCapacityFor): (JSC::JSStack::shrink): * jit/ExecutableAllocator.h: * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter64.asm: * parser/ParserError.h: (JSC::ParserError::toErrorObject): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/ErrorHandlingScope.cpp: Added. (JSC::ErrorHandlingScope::ErrorHandlingScope): (JSC::ErrorHandlingScope::~ErrorHandlingScope): * runtime/ErrorHandlingScope.h: Added. * runtime/ExceptionHelpers.cpp: (JSC::throwStackOverflowError): (JSC::throwTerminatedExecutionException): * runtime/JSLock.cpp: (JSC::JSLock::DropAllLocks::DropAllLocks): (JSC::JSLock::DropAllLocks::~DropAllLocks): * runtime/JSLock.h: * runtime/Options.h: * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::releaseExecutableMemory): (JSC::VM::updateStackLimitWithHostZoneSize): * runtime/VM.h: * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::~VMEntryScope): * runtime/VMEntryScope.h: 2014-01-08 Filip Pizlo FTL should be able to be parallel https://bugs.webkit.org/show_bug.cgi?id=126679 Reviewed by Oliver Hunt. Fix some bugs that got in the way of saying JSC_numberOfCompilerThreads=7 or some such. * bytecode/CodeBlock.h: (JSC::CodeBlock::livenessAnalysis): This wasn't thread-safe. Now it is. * dfg/DFGWorklist.cpp: (JSC::DFG::initializeGlobalWorklistOnce): FTL is now parallelizable. * llvm/library/LLVMExports.cpp: (initializeAndGetJSCLLVMAPI): Make LLVM parallelizable. 2014-01-08 Filip Pizlo FTL should not use the inputs of an add or sub as the live-at-exit values in an overflow check, if the values aren't live after https://bugs.webkit.org/show_bug.cgi?id=126545 Reviewed by Oliver Hunt. Introduces the notion of an ExitValue that is computed by doing some math on two exit arguments. This gets used by LowerDFGToLLVM by tracking the AvailableRecoveries - i.e. the set of ways we know how to recover the value of a node by performing math on LValue's - and then trying to pick an AvailableRecovery if we try to exit with an Availability pointing to a Node that isn't a constant. The compileArithAddOrSub() code adds AvailableRecoveries for the ways you could recovery the left or right operand by using the result. Doing this uncovered a bug in stackmap constant parsing where we were casting a 32-bit value to 16-bit, thereby losing the top bits. * JavaScriptCore.xcodeproj/project.pbxproj: * ftl/FTLAvailableRecovery.cpp: Added. (JSC::FTL::AvailableRecovery::dump): * ftl/FTLAvailableRecovery.h: Added. (JSC::FTL::AvailableRecovery::AvailableRecovery): (JSC::FTL::AvailableRecovery::node): (JSC::FTL::AvailableRecovery::format): (JSC::FTL::AvailableRecovery::opcode): (JSC::FTL::AvailableRecovery::left): (JSC::FTL::AvailableRecovery::right): * ftl/FTLExitValue.cpp: (JSC::FTL::ExitValue::dumpInContext): * ftl/FTLExitValue.h: (JSC::FTL::ExitValue::recovery): (JSC::FTL::ExitValue::isRecovery): (JSC::FTL::ExitValue::leftRecoveryArgument): (JSC::FTL::ExitValue::rightRecoveryArgument): (JSC::FTL::ExitValue::recoveryFormat): (JSC::FTL::ExitValue::recoveryOpcode): (JSC::FTL::ExitValue::valueFormat): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub): (JSC::FTL::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): (JSC::FTL::LowerDFGToLLVM::doesKill): (JSC::FTL::LowerDFGToLLVM::addAvailableRecovery): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLRecoveryOpcode.cpp: Added. (WTF::printInternal): * ftl/FTLRecoveryOpcode.h: Added. * ftl/FTLStackMaps.h: * tests/stress/add-constant-overflow-recovery.js: Added. (foo): * tests/stress/add-int52-constant-overflow-recovery.js: Added. (foo): * tests/stress/add-int52-large-constant-overflow-recovery.js: Added. (foo): * tests/stress/add-overflow-recovery.js: Added. (foo): * tests/stress/add-small-constant-overflow-recovery.js: Added. (foo): 2014-01-08 Michael Saboff CStack: stack frame gets unaligned before call to operationVMHandleException https://bugs.webkit.org/show_bug.cgi?id=126673 Reviewed by Mark Lam. Moves the epilogue to after the check for an exception. Modified the call to operationVMHandleException() to take the caller's frame since the callee frame hasn't been popped off yet. * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): 2014-01-08 Filip Pizlo Make it possible to disable the disabling of AVX https://bugs.webkit.org/show_bug.cgi?id=126652 Reviewed by Geoffrey Garen. Who knows, maybe some newer Intel chips will actually run AVX code properly. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::lower): * runtime/Options.h: 2014-01-07 Michael Saboff CStack Branch: ARM64 DFG produces the wrong answer for X % 0 https://bugs.webkit.org/show_bug.cgi?id=126612 Reviewed by Geoffrey Garen. Added check for zero divisor. If shouldCheckOverflow() is true, the zero divisor check is an overflow speculation check. If shouldCheckOverflow() is false, a zero divisor causes us to set the result to 0. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithMod): 2014-01-07 Filip Pizlo Disable AVX in the FTL https://bugs.webkit.org/show_bug.cgi?id=126620 Reviewed by Geoffrey Garen. * ftl/FTLAbbreviations.h: (JSC::FTL::addTargetDependentFunctionAttr): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::lower): 2014-01-07 Filip Pizlo CStack: Call linking should log call linking for DFG and FTL code blocks if --showDFGDisassembly=true https://bugs.webkit.org/show_bug.cgi?id=126617 Rreviewed by Oliver Hunt. * jit/Repatch.cpp: (JSC::linkFor): 2014-01-07 Filip Pizlo Merge trunk r161465. 2014-01-07 Filip Pizlo Add a test that got lost in some merge. * tests/stress/phantom-arguments-set-local-then-exit-in-same-block.js: Added. 2014-01-07 Filip Pizlo --showDFGDisassembly=true shouldn't show baseline JIT stubs https://bugs.webkit.org/show_bug.cgi?id=126593 Reviewed by Oliver Hunt. * assembler/LinkBuffer.cpp: (JSC::shouldShowDisassemblyFor): * assembler/LinkBuffer.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::privateCompileGetByVal): (JSC::JIT::privateCompilePutByVal): * jit/JITStubRoutine.h: * jit/Repatch.cpp: (JSC::generateProtoChainAccessStub): (JSC::tryCacheGetByID): (JSC::tryBuildGetByIDList): (JSC::emitPutReplaceStub): (JSC::emitPutTransitionStub): (JSC::tryRepatchIn): (JSC::linkClosureCall): 2014-01-07 Filip Pizlo Merge trunk r161438. 2014-01-07 Filip Pizlo FTL OSR entry should only check input variable types after it has set up OSR exit availability of those OSR entry values https://bugs.webkit.org/show_bug.cgi?id=126587 Reviewed by Geoffrey Garen. At the prologue of OSR entry, DFG IR knows where the arguments are but has no idea where the locals are. So, before OSR entry starts doing speculation checks, it should establish (via MovHints) where the locals are. Then it can do the checks (namely, the SetArgument/SetLocal's). Also make things a bit easier to debug by making verboseOSR() print OSR exit disassemblies. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::finalizeCodeWithDisassembly): * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::OSRAvailabilityAnalysisPhase::run): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGOSRExitCompiler.cpp: * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): 2014-01-07 Michael Saboff CStack Branch: ARM64 Crash running ecma/FunctionObjects/15.3.1.1-3.js https://bugs.webkit.org/show_bug.cgi?id=126585 Reviewed by Geoffrey Garen. We were improperly using a shifted add/subtract for operations with the stack pointer as the destination. Broadened the cases where we use the extended register version of add/subtract to include when the destination is the stack pointer. In the ARM64 documentation, the immediate and extended register forms of add and subtract are the right variants to manipulate the stack pointer. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::add): (JSC::ARM64Assembler::sub): 2014-01-07 Filip Pizlo Merge trunk r161411. 2014-01-07 Filip Pizlo Really merge r161399. * dfg/DFGArithMode.cpp: Added. * dfg/DFGArithMode.h: Added. 2014-01-07 Michael Saboff CStack Branch: Disable JIT stack alignment check for ARM64 https://bugs.webkit.org/show_bug.cgi?id=126550 Unreviewed comment only change. Added comment to checkStackPointerAlignment() suggested by Darin Adler. 2014-01-06 Filip Pizlo Merge trunk r161072, r161126, r161218, r161353, r161356, r161364, 161399. 2014-01-06 Michael Saboff CStack Branch: ARM64 Crash in llint_function_for_call_arity_check running 3d-raytrace.js https://bugs.webkit.org/show_bug.cgi?id=126557 Reviewed by Geoffrey Garen. We were crashing due the to definition of t5 in the offline assembler not matching the definition of regT5 in GPRInfo.h. The crash was due to passing the stub return address to the fixup thunk in regT5, but it contained garbage. I changed the definitions of t4, t5 and t6 in the ARM64 back end of the offline assembler to match GPRInfo.h. * offlineasm/arm64.rb: 2014-01-06 Michael Saboff CStack Branch: Fix nativeForGenerator() for non-X86 platforms https://bugs.webkit.org/show_bug.cgi?id=126551 Reviewed by Geoffrey Garen. Removed the explicit saving and restoring of the return address and call frame register from the non-X86 paths of nativeForGenerator() as these are no longer needed. The function prologue and epilogue now perform calling convention consistent saving and restoring of these values. * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): 2014-01-06 Filip Pizlo Merge trunk r160394, r160407, r160411, r160587. 2014-01-06 Michael Saboff Merge of trunk r160493 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): 2014-01-06 Filip Pizlo Merge trunk r160294, r160295, r160328, r160347, r160348. 2014-01-06 Filip Pizlo Finish merging r160292: add more forgotten files. * tests/stress/fold-typed-array-properties.js: Added. 2014-01-06 Filip Pizlo Finish merging r160292: add forgotten files. * dfg/DFGStrengthReductionPhase.cpp: Added. * dfg/DFGStrengthReductionPhase.h: Added. 2014-01-06 Filip Pizlo Merge trunk r160292. 2014-01-06 Filip Pizlo Merge trunk r160238, r160242, r160246, r160252, r160257. 2014-01-06 Michael Saboff CStack Branch: Disable JIT stack alignment check for ARM64 https://bugs.webkit.org/show_bug.cgi?id=126550 Reviewed by Mark Lam. Since ARM64 enforces strict stack alignment, the need for checkStackPointerAlignment() is not needed. Also, the implementation of checkStackPointerAlignment() would need to be reworked given the limits on the operations that can be done with the stack pointer register in ARM64. Therefore conditionally disabled checkStackPointerAlignment() for ARM64. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::checkStackPointerAlignment): 2014-01-06 Mark Lam CStack: JSLock drop and grab lock APIs should be private. https://bugs.webkit.org/show_bug.cgi?id=126539. Reviewed by Mark Hahnenberg. We want the dropping and re-acquisition of the VM API lock to be via the DropAllLocks raii object. Hence, we should not publicly publishing the APIs for dropping and re-acquiring the locks. * runtime/JSLock.h: 2014-01-06 Mark Lam Follow up patch to remove the need for VMEntryScope::m_prevFirstEntryScope. https://bugs.webkit.org/show_bug.cgi?id=126266. Reviewed by Geoffrey Garen. There can only be one firstEntryScope. Instead of saving the previous value of VM::firstEntryScope, we now check if the firstEntryScope is the same as this VMEntryScope in its destructor. If so, we will set VM::firstEntryScope to 0. * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::~VMEntryScope): * runtime/VMEntryScope.h: 2014-01-06 Mark Lam CStack: jsStackLimit fixup should not exceed native stack limit. https://bugs.webkit.org/show_bug.cgi?id=126487. Reviewed by Michael Saboff. Update: this is supplanted by the 2014-01-08 patch for https://bugs.webkit.org/show_bug.cgi?id=126320. In doCallToJavaScript, we fixup VM::m_jsStackLimit once we know what the stackPointerAtVMEntry is. However, we also need to ensure that the fixed up jsStackLimit does not exceed the native stack limit. This check was missing, and resulted in an assertion failure when running testapi on platforms that have smaller stacks. This is now fixed. * llint/LowLevelInterpreter64.asm: 2014-01-05 Michael Saboff CStack Branch: ARM64 Fix other prologue and epilogue macros in LLInt https://bugs.webkit.org/show_bug.cgi?id=126507 Reviewed by Mark Lam. Fixed preserveCallerPCAndCFR() and restoreCallerPCAndCFR() for ARM64. Fixed functionPrologue() so that the new callframe is set up from the stack pointer. * llint/LowLevelInterpreter.asm: 2014-01-04 Michael Saboff CStack Branch: ARM64 needs push/pop pair macro assembler instructions https://bugs.webkit.org/show_bug.cgi?id=126474 Reviewed by Mark Lam. Added templated ldp() and stp() instruction generators to the ARM64 assembler. Added popPair() and pushPair() to the ARM64 macro assembler. Added ARM64 version of emitFunctionPrologue() and emitFunctionEpilogue() to AssemblyHelpers.h that use the pushPair() and popPair() macro instructions. Added disassembler support for the newly added load/store pair instructions. Verified that we correctly generate the new instructions and that they disassemble the same as what the debugger shows. * assembler/ARM64Assembler.h: (JSC::isInt7): (JSC::isInt11): (JSC::PairPostIndex::PairPostIndex): (JSC::PairPostIndex::operator int): (JSC::PairPreIndex::PairPreIndex): (JSC::PairPreIndex::operator int): (JSC::ARM64Assembler::memPairOffsetShift): (JSC::ARM64Assembler::ldp): (JSC::ARM64Assembler::stp): (JSC::ARM64Assembler::loadStoreRegisterPairPostIndex): (JSC::ARM64Assembler::loadStoreRegisterPairPreIndex): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::popPair): (JSC::MacroAssemblerARM64::pushPair): * disassembler/ARM64/A64DOpcode.cpp: (JSC::ARM64Disassembler::A64DOpcode::appendRegisterName): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::opName): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::format): * disassembler/ARM64/A64DOpcode.h: (JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::rt2): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::immediate7): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::offsetMode): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::lBit): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitFunctionPrologue): (JSC::AssemblyHelpers::emitFunctionEpilogue): 2014-01-04 Michael Saboff CStack Branch: ARM64 add of stack pointer not valid as second source operand https://bugs.webkit.org/show_bug.cgi?id=126486 Reviewed by Mark Lam. Swap the source operands in add64() if the second argument is the stack pointer to work around ARM64 limitations for using the stack pointer as a second source operand. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::add64): 2014-01-04 Michael Saboff CStack Branch: slowPathFor() should emit an epilogue instead of popping the callFrameRegister https://bugs.webkit.org/show_bug.cgi?id=126478 Reviewed by Mark Lam. Changed the pop(callFrameRegister) to emitFunctionEpilogue(). * jit/ThunkGenerators.cpp: (JSC::slowPathFor): 2014-01-03 Michael Saboff cstack Branch: ARM64 LLInt fails to compile due to instructions limitations with sp https://bugs.webkit.org/show_bug.cgi?id=126423 Reviewed by Filip Pizlo. Disabled the checkStackPointerAlignment macro for ARM64 since it will fault on any improper changes to the stack pointer that result in bad alignment. Changed uses of sp to either move into a temp register for certain operations, or changed the order of subtract operands. The operand ordering includes branch compare pseudo ops. In the process discovered that sanitizeStackForVM was plain wrong and never executed the clear loop, so I fixed that while changing the operand ordering of the compares. The ARM64 build also complains that we are doing a compare and branch to a non-local label so I changed branchIfException to branch around a jmp to a possible global label. Tested on X86-64. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: 2014-01-03 Michael Saboff CStack Branch: Make emitPutToCallFrameHeaderBeforePrologue and friends work for all platforms https://bugs.webkit.org/show_bug.cgi?id=126421 Reviewed by Filip Pizlo. Added new helper prologueStackPointerDelta() that returns the amount the stack pointer should be adjusted when accessing a CallFrame via the stack pointer before the function prologue has been executed. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::prologueStackPointerDelta): (JSC::AssemblyHelpers::emitFunctionEpilogue): (JSC::AssemblyHelpers::emitPutToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::emitPutPayloadToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::emitPutTagToCallFrameHeaderBeforePrologue): 2014-01-03 Filip Pizlo Unreviewed, some trivial 32-bit build fixes. 32-bit is still broken but this takes care of some easy things. This is part of the work for https://bugs.webkit.org/show_bug.cgi?id=116888. * assembler/MacroAssembler.h: (JSC::MacroAssembler::storePtr): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedPutById): * jit/RegisterPreservationWrapperGenerator.cpp: (JSC::generateRegisterRestoration): 2014-01-02 Mark Lam Addressed review comments in https://bugs.webkit.org/show_bug.cgi?id=126393#c5. Reviewed by Michael Saboff. * offlineasm/cloop.rb: 2014-01-02 Filip Pizlo Address review comments in https://bugs.webkit.org/show_bug.cgi?id=126409#c3 * llint/LowLevelInterpreter32_64.asm: 2014-01-02 Filip Pizlo CStack LLInt 32-bit should build https://bugs.webkit.org/show_bug.cgi?id=126409 Reviewed by Michael Saboff. This attempst to get the 32-bit LLInt to do the same things that the 64-bit LLInt does for the C stack. This was mostly just mechanical. Only one part of the code didn't port cleanly, and that was the use of t6 in handleUncaughtException. I changed it to t5 because as far as I can tell, t5 is not live at that point in either version of the LLInt. Note that we still can't build 32-bit yet so these changes are being done blind. * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2014-01-02 Mark Lam CStack: Interpreter::executeCall() should check for exceptions after calling callToNativeFunction(). https://bugs.webkit.org/show_bug.cgi?id=126405. Reviewed by Michael Saboff. * interpreter/Interpreter.cpp: (JSC::Interpreter::executeCall): - executeCall() was expecting to return a non-null JSValue but neglected to check if an exception was thrown during a call to callToNativeFunction. We now check if an exception was thrown, and if so, we set the result to jsNull() the same way that JITCode::execute() does. 2014-01-02 Filip Pizlo Address review feedback in https://bugs.webkit.org/show_bug.cgi?id=126387#c3 * llint/LowLevelInterpreter.asm: 2014-01-02 Mark Lam CStack: Get the C Loop LLINT to build again. https://bugs.webkit.org/show_bug.cgi?id=126393. Reviewed by Michael Saboff. * jit/JITCode.cpp: (JSC::DirectJITCode::addressForCall): - #if ENABLE(JIT) out the use of RegisterPreservationWrappers. * llint/LLIntCLoop.cpp: (JSC::LLInt::CLoop::initialize): - Update CLoop::initialize() to call the new CLoop::execute(). * llint/LLIntCLoop.h: - CLoop::execute() now takes the arguments for callToJavaScript, and it effectively acts as the gateway for re-entering the VM in place for callToJavaScript (and callToNativeFunction). CLoop::execute() should set up the "CPU" execution environment i.e. CLoopRegisters should be initialized with the incoming args, stack pointer, base pointer, and return address. We'll take care of this part in a subsequent patch. * llint/LLIntOpcode.h: - Added C loop only llint opcodes llint_call_to_javascript, and llint_call_to_native_function. These will be used as the opcodeID for the llint interpreter blob for callToJavaScript and callToNativeFunction. Meanwhile, the LLINT thunk will provide C functions for callToJavaScript and callToNativeFunction which calls CLoop::execute() with the opcodeID for llint_call_to_javascript and llint_call_to_native_function respectively. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_throw_stack_overflow_error): - Changed llint_throw_stack_overflow_error()'s return type so that it is easier for the C Loop LLINT to generate boilerplate code to call it. The return value is not used by anyone. But since this is code that rarely executed, we'll opt to take this small hit of returning an unused value rather than having to spin some way to make the C Loop offlineasm smarter only for handling this one case. * llint/LLIntSlowPaths.h: * llint/LLIntThunks.cpp: (JSC::callToJavaScript): (JSC::callToNativeFunction): - Updated to call the new CLoop::execute(). We're going to try to use the doCallToJavaScript code defined in the LLINT assembly instead of spinning our own version in C++ as we did previously. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: (JSC::CLoopRegister::operator ExecState*): (JSC::CLoopRegister::operator Instruction*): (JSC::CLoopRegister::operator VM*): (JSC::CLoopRegister::operator ProtoCallFrame*): - Added these cast operators to the CLoopRegister to simplify the C Loop call slow path boilerplate. (JSC::CLoop::execute): * llint/LowLevelInterpreter64.asm: * offlineasm/cloop.rb: - Define C Loop registers to match ARM as expected by the code. - Replaced a #error with a RELEASE_ASSERT_NOT_REACHED(). - Reworked the call slow path boilerplate to take advantage of the CLoopRegister cast operators. We need this in order to be able to call slow path functions that take different argument types e.g. llint_throw_stack_overflow_error(). * runtime/CommonSlowPaths.cpp: (JSC::setupArityCheckData): * runtime/VM.cpp: (JSC::VM::getHostFunction): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::requiredCapacity): 2014-01-02 Filip Pizlo Some crashes in C stack on Mountain Lion, for example on crypto-aes, due to misaligned stack https://bugs.webkit.org/show_bug.cgi?id=126394 Reviewed by Michael Saboff. The specialized math thunks currently ensure that inside the thunk, the stack is aligned. But when they call the wrapper, the wrapper previously didn't align the stack. This patch fixes that. I think that we can drop the wrappers on X86-64 and maybe on other platforms as well. I'll leave that to a future patch. * jit/ThunkGenerators.cpp: 2014-01-02 Filip Pizlo Refactor LLInt C stack frame munging helpers so that 32-bit code paths can use them https://bugs.webkit.org/show_bug.cgi?id=126387 Reviewed by Michael Saboff. This gets us closer to the 32-bit LLInt working on the C stack by enabling the 32-bit code paths to use the low-level stack/frame pointer munging helpers. This patch doesn't completely ensure that these helpers actually work - the 32-bit build is still broken - but it's a good change to land separately since it affects 64-bit code paths as well. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2013-12-31 Mark Lam CStack: Need a separate stack limit for the JS stack and the C stack. https://bugs.webkit.org/show_bug.cgi?id=126320. Rejected by Geoffrey Garen. Update: this is supplanted by the 2014-01-08 patch for https://bugs.webkit.org/show_bug.cgi?id=126320. With this patch, we now accurately track how much JS stack space the VM has used, and cap that at the value specified by Options::maxStackSize(). The JS stack space is measured in chunks, one for each VMEntryScope. Each VMEntryScope will also keep a running total of the sum of all the stack usage of previous VMEntryScopes to simplify the calculation of the total usage. * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): - In Interpreter::execute() for programs, we were installing the VMEntryScope even if we end up only processing a JSON object. This poses a problem because the code that processes the JSON object will call functions that will re-enter the VM thereby installing another VMEntryScope. Each VMEntryScope expects VM.topCallFrame and VM.stackPointerAtVMEntry to be set up properly for the previous VMEntryScope. However, in this case, we've installed the VMEntryScope for a potential ProgramExecutable but never executed a program to initialize its values for VM.topCallFrame and VM.stackPointerAtVMEntry. This in turn causes a crash when the second VMEntryScope makes use of VM.topCallFrame. The fix is simply to defer installation of the VMEntryScope for the program till we are actually sure that we will attempt to execute a program. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL(stack_check)): - In llint_stack_check(), we pop the frame that we failed to set up before throwing the StackOverflowError. Added an update of topCallFrame here to reflect this popping action. * llint/LowLevelInterpreter64.asm: - The VMEntryScope will have to calculate and set up a jsStackLimit value before we actually know what the stack pointer is at the point when we re-enter the VM. So, instead of using the real stackPointerAtVMEntry for the jsStackLimit calculation, we use an estimate. doCallToJavaScript() here will set VM.stackPointerAtVMEntry to its real value. But before it does that, it needs to adjust VM.jsStackLimit by the delta between the estimate and the real stackPointerAtVMEntry. - If doCallToJavaScript() fails its stack check for incoming args, it also needs to clear VM.stackPointerAtVMEntry so that C code can assert that the various pointers into the stack remain consistent. By consistent, I mean that, given that the stack grows down, and that VM.stackPointerAtVMEntry and VM.topCallFrame are properly initialized, then the following should always be true: let topOfStack = VM.topCallFrame->topOfFrame(); stackPointerAtVMEntry >= topOfStack >= stack pointer in a C helper function and JSStack.containsAddress(stackPointerAtVMEntry) and JSStack.containsAddress(topOfStack) Clearing VM.stackPointerAtVMEntry, if the stack check in doCallToJavaScript() fails, indicates we failed to enter the current VMEntryScope and that we should be using the previous VMEntryScope's stackPointerAtVMEntry and topCallFrame for the above assertions. NOTE: These assertions are done in VMEntryScope::updateStackLimits(). * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::~VMEntryScope): (JSC::VMEntryScope::stackUsageFor): (JSC::VMEntryScope::updateStackLimits): (JSC::VMEntryScope::currentStackPointer): (JSC::VMEntryScope::requiredCapacity): - requiredCapacity() now computes the excess amount C stack capacity that we have available, and discount it in the computation of the JS stack limit. By excess, I mean the amount of unused C stack space that exceeds the amount of unused JS stack space capacity. * runtime/VMEntryScope.h: 2013-12-30 Mark Lam CStack: the GC should not be assuming any limit on the stack size. https://bugs.webkit.org/show_bug.cgi?id=126335. Reviewed by Geoffrey Garen. We cannot do a meaningful assertion here on the size of the stack span because we don't know the stack bounds that the span came from. Hence, the assertion is now removed. * heap/ConservativeRoots.cpp: (JSC::ConservativeRoots::genericAddSpan): 2013-12-30 Mark Lam CStack: Introduce tracking of the top VMEntryScope. https://bugs.webkit.org/show_bug.cgi?id=126334. Reviewed by Geoffrey Garen. Update: this is supplanted by the 2014-01-08 patch for https://bugs.webkit.org/show_bug.cgi?id=126320. When we start measuring the stack usage of each VMEntryScope, we'll need to know which VMEntryScope is the top (most recent) one, not just the first one. Also, for correctness, in JSStack::updateStackLimit(), when we set a new jsStackLimit, we should set it on the top VMEntryScope, and not on the first (oldest) one. This is because the 2 scopes may be on 2 different thread stacks, and the most present stack limits only apply to the most recent scope. That said, presently, VMEntryScope::updateStackLimits() does not rely on any scope specific data yet. So, calling updateStackLimits() on the oldest VMEntryScope hasn't manifested any issues yet. Regardless, this is now fixed. * interpreter/JSStack.cpp: (JSC::JSStack::updateStackLimit): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::~VMEntryScope): * runtime/VMEntryScope.h: 2013-12-30 Mark Lam CStack: Refactor to split the tracking of the jsStackLimit from the native stackLimit. https://bugs.webkit.org/show_bug.cgi?id=126331. Rejected by Geoffrey Garen. Update: this is supplanted by the 2014-01-08 patch for https://bugs.webkit.org/show_bug.cgi?id=126320. Previously, when using the C stack for the JS stack, VM::m_jsStackLimit is a union with VM::m_stackLimit. We now separate them into 2 distinct fields but haven't yet changed the computation of the limit values to set them with. * interpreter/JSStack.cpp: (JSC::JSStack::updateStackLimit): * runtime/VM.h: * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::~VMEntryScope): (JSC::VMEntryScope::updateStackLimits): (JSC::VMEntryScope::requiredCapacity): * runtime/VMEntryScope.h: 2013-12-30 Mark Lam CStack: Fix JSStack::ensureCapacity() to match LLINT and JIT stack checks. https://bugs.webkit.org/show_bug.cgi?id=126328. Reviewed by Geoffrey Garen. Also removed the now unused JSSTack::topOfStackForCapacityCheck(). * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::ensureCapacityFor): 2013-12-30 Mark Lam CStack: Introducing Options::maxStackSize(). https://bugs.webkit.org/show_bug.cgi?id=126321. Reviewed by Geoffrey Garen. Update: this is supplanted by the 2014-01-08 patch for https://bugs.webkit.org/show_bug.cgi?id=126320. We need an option to limit the JS stack size. Currently, we just change the JSStack class to use this limit. * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): * interpreter/JSStack.h: * runtime/Options.h: 2013-12-29 Filip Pizlo CStack branch with --ftl-jit should fail no more tests than without FTL as of r161113 https://bugs.webkit.org/show_bug.cgi?id=126280 Reviewed by Michael Saboff. This change fixes erroneous results in 3d-raytrace in FTL-eager mode. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): Reject code that uses activations since the FTL doesn't support it yet. Previously it would *sometimes* slip by in OSR entry situations. * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): Fix stack alignment. 2013-12-27 Mark Lam CStack: Cosmetic: rename VM::entryScope to firstEntryScope. https://bugs.webkit.org/show_bug.cgi?id=126266. Rejected by Geoffrey Garen. Update: this is supplanted by the 2014-01-08 patch for https://bugs.webkit.org/show_bug.cgi?id=126320. This patch is so that we can distinguish firstEntryScope from topEntryScope which will be introduced later in https://bugs.webkit.org/show_bug.cgi?id=126334. Also renamed VMEntryScope::m_prev to m_prevFirstEntryScope. * debugger/Debugger.cpp: (JSC::Debugger::recompileAllJSFunctions): * heap/Heap.cpp: (JSC::Heap::lastChanceToFinalize): (JSC::Heap::deleteAllCompiledCode): * interpreter/CallFrame.cpp: (JSC::CallFrame::vmEntryGlobalObject): * interpreter/JSStack.cpp: (JSC::JSStack::updateStackLimit): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::releaseExecutableMemory): * runtime/VM.h: * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::~VMEntryScope): * runtime/VMEntryScope.h: 2013-12-25 Mark Lam jsc-layout-tests.yaml/js/script-tests/function-apply-aliased.js.layout-no-cjit is failing. https://bugs.webkit.org/show_bug.cgi?id=126174. Reviewed by Geoff Garen. When we do a stack check in a function prologue, the activation object in the frame hasn't been set yet. The test failures came from the stack unwinding code trying to tear off the frame to a non-existant activation object. Since we haven't entered the function yet and the frame is technically not fully "pushed" yet, we can throw i.e. start the unwinding from the caller frame instead. This fixes the issue. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): - When we have a StackOverflowError, return the caller's CallFrame in the second value in the SlowPathReturnType. * llint/LowLevelInterpreter.asm: - Check if the second value of the SlowPathReturnType from the stack check is 0. If not 0, set the cfr to the returned CallFrame* before we start handling the StackOverflowError and unwinding the stack. 2013-12-24 Michael Saboff CStack Branch: ecma/ExecutionContexts/10.1.4-2.js test fails https://bugs.webkit.org/show_bug.cgi?id=126213 Reviewed by Filip Pizlo. Fixed setting and restoring of stack pointer in JIT::compileCallEval() and its slow path. Changed the exception check to simplify when the stack pointer is set to the before call versus after the call values. * jit/JITCall.cpp: (JSC::JIT::compileCallEval): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCall): 2013-12-23 Michael Saboff CStack Branch: throwExceptionFromCallSlowPathGenerator() shouldn't pop frame https://bugs.webkit.org/show_bug.cgi?id=126204 Reviewed by Filip Pizlo. Given that the function epilogue pops the callee frame, there is no need to pop a frame in throwExceptionFromCallSlowPathGenerator(). * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromCallSlowPathGenerator): 2013-12-23 Mark Lam CStack:Fixed JSStack::disableErrorStackReserve() and JSStack::installTrapsAfterFrame(). https://bugs.webkit.org/show_bug.cgi?id=126191. Update: This is supplanted by https://bugs.webkit.org/show_bug.cgi?id=126790. 1. JSStack::disableErrorStackReserve() was wrongly comparing m_end with m_useableTop. Fixed the comparison. 2. JSStack::installTrapsAfterFrame() was wrongly overwriting the top slot of the top frame. Fixed to start the trap words at the slot below the top slot in the top frame (as in at lower memory below the allocated stack memory above it). * interpreter/JSStack.cpp: (JSC::JSStack::disableErrorStackReserve): * interpreter/JSStackInlines.h: (JSC::JSStack::installTrapsAfterFrame): 2013-12-23 Mark Lam CStack: Fix JSStack::grow(), shrink(), growSlowCase(), and setStackLimit(). https://bugs.webkit.org/show_bug.cgi?id=126188. Reviewed by Geoffrey Garen. These functions were inappropriately mixing "end" and "top" pointer idioms. Specifically: 1. growSlowCase() was comparing a newEnd pointer against m_commitTop, and using this to compute the size that the stack needs to grow. 2. shrink() was wrongly computing excess capacity by subtracting baseOfStack() (which is at high memory) from m_commitTop (which points to lower memory). Also, baseOfStack() is an "end" pointer while m_commitTop is a "top" pointer. This is a mismatch. To fix this and simplify the code a bit, I changed all of these functions to take a newTopOfStack pointer instead of a newEnd pointer, and adjusted their callers where needed to pass the appropropriate pointer values. * interpreter/JSStack.cpp: (JSC::JSStack::growSlowCase): * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::popFrame): (JSC::JSStack::shrink): (JSC::JSStack::grow): (JSC::JSStack::setStackLimit): 2013-12-23 Mark Lam CStack: Cosmetic: rename JSStack::m_commitEnd to m_commitTop. https://bugs.webkit.org/show_bug.cgi?id=126186 Reviewed by Geoffrey Garen. In the JSStack constructor, m_commitEnd is initialized to highAddress() which is the address just above the start of the stack. This is appropriate because no memory has been committed for the stack yet i.e. highAddress() - m_commitEnd should equal 0. When we grow the stack in growSlowCase, we set m_commitEnd to m_commitEnd - delta, where delta is some even multiple of commitSize (some units of page size). This means that if there is memory committed, m_commitEnd would point to an allocatable slot in the stack, not past it. Hence, m_commitEnd should more appropriately be named m_commitTop. * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::~JSStack): (JSC::JSStack::growSlowCase): (JSC::JSStack::releaseExcessCapacity): * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::shrink): (JSC::JSStack::installTrapsAfterFrame): 2013-12-23 Mark Lam CStack: Cosmetic: rename JSStack::m_useableEnd to m_useableTop. https://bugs.webkit.org/show_bug.cgi?id=126184. Reviewed by Geoffrey Garen. In JSStack::enableErrorStackReserve() and disableErrorStackReserve(), m_useableEnd is initialize to reservationTop() or reservationTop() + commitSize. Hence, it points to an allocatable slot in the stack, not past it. Naming it m_useableTop is more correct. * interpreter/JSStack.cpp: (JSC::JSStack::growSlowCase): (JSC::JSStack::enableErrorStackReserve): (JSC::JSStack::disableErrorStackReserve): * interpreter/JSStack.h: 2013-12-23 Mark Lam CStack: Cosmetic: rename reservationEnd() to reservationTop(). https://bugs.webkit.org/show_bug.cgi?id=126181. Reviewed by Michael Saboff. reservationEnd() computes the end of the stack at the top. The value is computed as: char* reservationEnd = static_cast(m_reservation.base()); return reinterpret_cast_ptr(reservationEnd); Since m_reservation.base() points at a slot of memory that is within the allocatable range of the stack, naming this function reservationEnd() is inappropriate. Per Geoff's input, "end" usually refers to the slot past the end of a buffer. Calling it "top" is more appropriate. Hence, I'm renaming it to reservationTop(). * interpreter/JSStack.cpp: (JSC::JSStack::enableErrorStackReserve): (JSC::JSStack::disableErrorStackReserve): * interpreter/JSStack.h: (JSC::JSStack::reservationTop): 2013-12-23 Filip Pizlo CStack Branch: Several dfg-arguments-osr-exit tests fail https://bugs.webkit.org/show_bug.cgi?id=126170 Reviewed by Michael Saboff. OSR exit makes calls. It makes those calls after putting things into the stack at offsets that make sense in the baseline JIT. That means that if those calls spill things to the stack, they'll overwrite what the OSR exit had recovered for the baseline JIT. Need to adjust SP to a conservative value for the baseline JIT at the top of exit. Note that the FTL OSR exit already does this. * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): 2013-12-23 Filip Pizlo cStack branch doesn't run navier-stokes because closure calls aren't implemented yet https://bugs.webkit.org/show_bug.cgi?id=126141 Reviewed by Michael Saboff. Add a bunch of assertions regarding the sanity of argument counts. This is a great way of making sure that SP/BP point to the right place. Used that to diagnose problems with closure calls. Closure call linking expects that SP is set up correctly very early on. The DFG JIT was doing this correctly, but the baseline JIT wasn't: it was setting up T1 as a fake SP and then setting up SP for real very late. This wasn't doing us any good and it was making closure calls fail. Also, closure calls were still referring to BP instead of SP and assuming that the caller was adjusting BP. Obviously, that's not what we do anymore. These fixes make navier-stokes run. It probably fixes other bugs, but I haven't looked at those yet. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::jitAssertArgumentCountSane): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::jitAssertArgumentCountSane): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JITCall.cpp: (JSC::JIT::compileLoadVarargs): (JSC::JIT::compileCallEval): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCall): (JSC::JIT::compileOpCallSlowCase): * jit/Repatch.cpp: (JSC::linkClosureCall): 2013-12-22 Mark Lam CStack: Add #if ENABLE(LLINT_C_LOOP) to C loop LLINT only parts of JSStack. https://bugs.webkit.org/show_bug.cgi?id=126140. Reviewed by Oliver Hunt. Also moved startOfFrameFor() to the ENABLE(DEBUG_JSSTACK) section because it's only needed there. * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::gatherConservativeRoots): (JSC::JSStack::sanitizeStack): * interpreter/JSStack.h: (JSC::JSStack::gatherConservativeRoots): (JSC::JSStack::sanitizeStack): (JSC::JSStack::initializeThreading): * interpreter/JSStackInlines.h: (JSC::JSStack::topOfFrameFor): 2013-12-22 Mark Lam CStack: Fixed some JSStack on C Stack boundary computations. https://bugs.webkit.org/show_bug.cgi?id=126139. Reviewed by Michael Saboff. 1. Implement committedByteCount() for JSStack on the C stack using the current stack usage as an estimate of committed stack memory. 2. Implement lowAddress() and highAddress() for JSStack on the C stack for containsAddress(). lowAddress() will be the top of the JS stack. highAddress() will be 1 past the end of the JS stack. 3. Moved some functions around in preparation for an upcoming patch to #if out code which is only used when ENABLE(LLINT_C_LOOP) * interpreter/JSStack.cpp: (JSC::JSStack::lowAddress): (JSC::JSStack::highAddress): (JSC::JSStack::committedByteCount): * interpreter/JSStack.h: (JSC::JSStack::containsAddress): (JSC::JSStack::lowAddress): 2013-12-22 Filip Pizlo It should be possible to run the full version of V8v7/crypto with the FTL and call IC's https://bugs.webkit.org/show_bug.cgi?id=126116 Reviewed by Sam Weinig. This involved a number of minor fixes: - CallLinkInfo::unlink() was assuming that repatchBuffer.codeBlock() is the caller. It's actually the callee. So, to determine if the caller requires register preservation, we need an extra bit to say whether the CallLinkInfo belongs to an FTL JITCode. - A lot of bugs arise from us incorrectly preserving (or failing to preserve) registers. This adds a bunch of jitAssertTagsInPlace() assertion that helps to catch a bunch of those bugs. - Apparently the __compact_unwind sometimes has garbage after its one entry. This changes our unwind parser so that it doesn't assert that the second entry is null, but it does assert that the first entry corresponds to our generated function. - The native function thunks assume that tags are set up and that they can clobber any registers. This breaks if we call the thunks from the FTL. This patch fixes the bug by wrapping just those thunks in a DirectJITCode, which has the register preservation wrappers. This probably ends up making sense because the FTL *really* should have intrinsics for all of those thunks. As part of this change, I refactored how NativeExecutable gets its JITCode to make things somewhat more explicit. We still have a bunch of known performance bugs to fix, but the FTL is already at near parity with the DFG on V8v7/crypto. This is pretty cool considering the FTL's other speed-ups, and the fact that crypto has been our primary DFG tuning test for the past 2.5 years. * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::unlink): * bytecode/CallLinkInfo.h: (JSC::CallLinkInfo::CallLinkInfo): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileEntry): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLJSCall.cpp: (JSC::FTL::JSCall::link): * ftl/FTLUnwindInfo.cpp: (JSC::FTL::UnwindInfo::parse): * ftl/FTLUnwindInfo.h: * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::jitAssertTagsInPlace): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::jitAssertTagsInPlace): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JITCode.cpp: * jit/JITCode.h: * jit/JITThunks.cpp: (JSC::JITThunks::hostFunctionStub): * jit/RegisterPreservationWrapperGenerator.cpp: (JSC::generateRegisterPreservationWrapper): * runtime/Executable.h: (JSC::NativeExecutable::create): 2013-12-21 Mark Lam CStack: Update the VMEntryScope's stack limit when the VM enters/exits ErrorMode. https://bugs.webkit.org/show_bug.cgi?id=126009. Reviewed by Michael Saboff. 1. Renamed JSStack::updateStackLimit() to setStackLimit() because that is what it actually does. We're going to repurpose the updateStackLimit name for another function. 2. Fixed a bug in setStackLimit() where setJSStackLimit() was called with the value of newEnd which points past the end of the stack. The fix is to add 1 to point at the last slot at top of the stack. This is what is the users of the jsStackLimit value expects. 3. Introduce the new JSStack::updateStackLimit() which is responsible for re-setting the current stack limit. updateStackLimit() will handle both cases of the JS stack being on the C stack or a separate stack. For the C stack case, JStack::updateStackLimit() will check if a VMEntryScope has been installed in the VM. If so, it will tell the VMEntryScope to do the real work of updating the stack limit. The VMEntryScope will take into account whether the VM's Interpreter is in an error handling mode or not when determining the amount of host zone space to reserve on the stack for computing the stack limit value. 4. Interpreter::ErrorHandlingMode now calls JSStack::updateStackLimit whenever it enters / exit error handling mode. This allows the stack limit to change with the error mode change. 5. A lot of places in the code were throwing StackOverflowErrors by creating and throwing the error themselves instead of using the throwStackOverflowError() helper function. As a result, the VM never got the chance to enter error mode. This is a bug and is now fixed by making all these sites use throwStackOverflowError() instead. For sites that can't use throwStackOverflowError(), I updated them to instantiate Interpreter::ErrorHandlingMode to set the error mode appropriately. 6. Made JSStack::enableErrorStackReserve() and disableErrorStackReserve() private. They are no longer called from outside of JSStack. * interpreter/Interpreter.cpp: (JSC::Interpreter::ErrorHandlingMode::ErrorHandlingMode): (JSC::Interpreter::ErrorHandlingMode::~ErrorHandlingMode): (JSC::sizeFrameForVarargs): * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::growSlowCase): (JSC::JSStack::updateStackLimit): * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::shrink): (JSC::JSStack::setStackLimit): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * parser/ParserError.h: (JSC::ParserError::toErrorObject): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/StringRecursionChecker.cpp: (JSC::StringRecursionChecker::throwStackOverflowError): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::updateStackLimit): * runtime/VMEntryScope.h: 2013-12-21 Filip Pizlo Register restoration thunk should restore the ArgumentCount after it restores registers https://bugs.webkit.org/show_bug.cgi?id=126115 Reviewed by Geoff Garen. Just getting us further along in V8/crypto... * ftl/FTLJSCall.cpp: (JSC::FTL::JSCall::JSCall): (JSC::FTL::JSCall::link): * ftl/FTLJSCall.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct): * jit/RegisterPreservationWrapperGenerator.cpp: (JSC::generateRegisterRestoration): 2013-12-20 Mark Lam CStack: Introduce JSStack::ensureCapacityFor(). https://bugs.webkit.org/show_bug.cgi?id=126109. Reviewed by Michael Saboff. Client code should use JSStack::ensureCapacityFor() when checking for available stack space for pushing JS frames or making arity adjustments. JSStack::ensureCapacityFor() works for both cases of the JS stack on the C stack or as a sperate stack. JSStack::grow() is now private, and is only used by the C Loop LLINT. Also made some other JSStack methods private as they are not needed outside of the JSSTack class. * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): * interpreter/Interpreter.cpp: (JSC::sizeFrameForVarargs): * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::ensureCapacityFor): (JSC::JSStack::topOfStackForCapacityCheck): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::arityCheckFor): 2013-12-20 Filip Pizlo FTL OSR exit should be able to handle the arity check fail case https://bugs.webkit.org/show_bug.cgi?id=126111 Reviewed by Geoff Garen. * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * jit/RegisterPreservationWrapperGenerator.cpp: (JSC::generateRegisterRestoration): * tests/stress: Added. * tests/stress/exit-from-ftl-with-arity-check-fail.js: Added. (foo): (bar): * tests/stress/repeated-arity-check-fail.js: Added. (bar): 2013-12-20 Filip Pizlo Arity check stack restoration should preserve the ArgumentCount in case there is a register restoration thunk below it https://bugs.webkit.org/show_bug.cgi?id=126106 Reviewed by Geoff Garen. * assembler/MacroAssemblerCodeRef.h: (JSC::ReturnAddressPtr::dump): * jit/ArityCheckFailReturnThunks.cpp: (JSC::ArityCheckFailReturnThunks::returnPCsFor): 2013-12-20 Mark Lam CStack: callToJavaScript should do stack check for incoming args. https://bugs.webkit.org/show_bug.cgi?id=126088. Reviewed by Michael Saboff. 1. Change callToJavaScript()'s prototype to: EncodedJSValue callToJavaScript(void*, VM*, ProtoCallFrame*); We now pass VM* instead of &vm.topCallFrame for the second argument. This gives us greater utility out of that arg. We also now save the VM* in the VMEntrySentinelFrame instead of &vm.topCallFrame. 2. Change callToJavaScript() to do a stack check to ensure that we have adequate stack space to copy all the args from the protoCallFrame. If not, it'll throw a StackOverflowError. 3. Removed JSStack::entryCheck() and calls to it. callToJavaScript now takes care of the stack check that ensures adequate stack space for incoming args. callToJavaScript does assume that we have adequate stack space for the VMEntrySentinelFrame, but that is ensured by our stack host zone. Changes to callToJavaScript are done in the doCallToJavaScript macro. Hence, all the changes apply to callToNativeFunction as well. * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): * interpreter/JSStack.h: * interpreter/JSStackInlines.h: * jit/JITCode.cpp: (JSC::JITCode::execute): * jit/JITStubs.h: * jit/JITStubsMSVC64.asm: Added a FIXME. * jit/JITStubsX86.h: Added a FIXME. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_throw_stack_overflow_error): * llint/LLIntSlowPaths.h: * llint/LLIntThunks.h: * llint/LowLevelInterpreter64.asm: 2013-12-20 Filip Pizlo Arity check slow path should ensure that when we return, we restore SP back to what the caller expects https://bugs.webkit.org/show_bug.cgi?id=126043 Reviewed by Geoff Garen. Implements proper stack restoration after return from a function that failed arity check. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileFunction): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLOSRExit.h: * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * jit/ArityCheckFailReturnThunks.cpp: Added. (JSC::ArityCheckFailReturnThunks::ArityCheckFailReturnThunks): (JSC::ArityCheckFailReturnThunks::~ArityCheckFailReturnThunks): (JSC::ArityCheckFailReturnThunks::returnPCsFor): (JSC::ArityCheckFailReturnThunks::returnPCFor): * jit/ArityCheckFailReturnThunks.h: Added. * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JITCode.cpp: (JSC::DirectJITCode::addressForCall): * jit/RegisterPreservationWrapperGenerator.cpp: (JSC::generateRegisterPreservationWrapper): (JSC::generateRegisterRestoration): (JSC::registerRestorationThunkGenerator): * jit/RegisterPreservationWrapperGenerator.h: * jit/ThunkGenerators.cpp: (JSC::arityFixup): * llint/LLIntOffsetsExtractor.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/x86.rb: * runtime/CommonSlowPaths.cpp: (JSC::setupArityCheckData): (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::arityCheckFor): * runtime/StackAlignment.h: (JSC::logStackAlignmentRegisters): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2013-12-20 Mark Lam Fix broken non-FTL build. Not reviewed. * jit/RegisterPreservationWrapperGenerator.cpp: (JSC::generateRegisterPreservationWrapper): 2013-12-20 Michael Saboff CStack Branch: CodeBlocks aren't being marked by garbage collector https://bugs.webkit.org/show_bug.cgi?id=126084 Reviewed by Filip Pizlo. Changed the native stack marking to include marking CodeBlocks and JITStubRoutines. Patterned the code after what was in JSStack::gatherConservativeRoots() * heap/Heap.cpp: (JSC::Heap::markRoots): * heap/MachineStackMarker.cpp: (JSC::MachineThreads::gatherFromCurrentThread): (JSC::MachineThreads::gatherFromOtherThread): (JSC::MachineThreads::gatherConservativeRoots): * heap/MachineStackMarker.h: 2013-12-20 Michael Saboff Unreviewed build fix for building without the FTL. * jit/RegisterPreservationWrapperGenerator.cpp: (JSC::generateRegisterPreservationWrapper): 2013-12-18 Filip Pizlo FTL should be able to do call ICs https://bugs.webkit.org/show_bug.cgi?id=125811 Reviewed by Geoffrey Garen. Add Call/Construct inline caching to the FTL. That part is super easy. But to make it possible for the FTL (which preserves system ABI callee-save registers and expects calls to preserve them) to call into non-FTL JSC JITs (which don't preserve any registers), we need to have some special thunks. That's most of the patch. In particular, all JITCode's can now give you entrypoints with or without register preservation and this may mean lazily creating wrapper thunks that preserve registers. FTL OSR exit may involve exiting into a register restoration thunk and it may also involve decoding FTL unwind info in order to figure out where registers were preserved. * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssemblerCodeRef.h: (JSC::MacroAssemblerCodePtr::operator UnspecifiedBoolType*): (JSC::MacroAssemblerCodeRef::operator UnspecifiedBoolType*): * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::unlink): * bytecode/CallLinkInfo.h: (JSC::CallLinkInfo::CallLinkInfo): * bytecode/CodeBlock.h: (JSC::CodeBlock::setJITCode): (JSC::CodeBlock::jitCode): * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITFinalizer.cpp: (JSC::DFG::JITFinalizer::finalize): (JSC::DFG::JITFinalizer::finalizeFunction): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLCompile.cpp: (JSC::FTL::mmAllocateCodeSection): (JSC::FTL::fixFunctionBasedOnStackMaps): (JSC::FTL::compile): * ftl/FTLInlineCacheSize.cpp: (JSC::FTL::sizeOfCall): * ftl/FTLInlineCacheSize.h: * ftl/FTLIntrinsicRepository.h: * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::initializeArityCheckEntrypoint): (JSC::FTL::JITCode::addressForCall): (JSC::FTL::JITCode::executableAddressAtOffset): (JSC::FTL::JITCode::dataAddressAtOffset): (JSC::FTL::JITCode::offsetOf): (JSC::FTL::JITCode::size): (JSC::FTL::JITCode::contains): * ftl/FTLJITCode.h: * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::finalizeFunction): * ftl/FTLJSCall.cpp: Added. (JSC::FTL::JSCall::JSCall): (JSC::FTL::JSCall::emit): (JSC::FTL::JSCall::link): * ftl/FTLJSCall.h: Added. (JSC::FTL::JSCall::stackmapID): (JSC::FTL::JSCall::operator<): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::lower): (JSC::FTL::LowerDFGToLLVM::compileGetById): (JSC::FTL::LowerDFGToLLVM::compilePutById): (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct): (JSC::FTL::LowerDFGToLLVM::callStackmap): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLRegisterAtOffset.cpp: Added. (JSC::FTL::RegisterAtOffset::dump): * ftl/FTLRegisterAtOffset.h: Added. (JSC::FTL::RegisterAtOffset::RegisterAtOffset): (JSC::FTL::RegisterAtOffset::operator!): (JSC::FTL::RegisterAtOffset::gpr): (JSC::FTL::RegisterAtOffset::offset): (JSC::FTL::RegisterAtOffset::operator==): (JSC::FTL::RegisterAtOffset::operator<): (JSC::FTL::RegisterAtOffset::getGPR): * ftl/FTLStackMaps.cpp: (JSC::FTL::StackMaps::Record::parse): * ftl/FTLState.cpp: (JSC::FTL::State::State): * ftl/FTLState.h: * ftl/FTLUnwindInfo.cpp: Added. (JSC::FTL::UnwindInfo::UnwindInfo): (JSC::FTL::UnwindInfo::~UnwindInfo): (JSC::FTL::UnwindInfo::parse): (JSC::FTL::UnwindInfo::dump): (JSC::FTL::UnwindInfo::find): (JSC::FTL::UnwindInfo::indexOf): * ftl/FTLUnwindInfo.h: Added. * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::compileOpCallSlowCase): * jit/JITCall32_64.cpp: (JSC::JIT::compileOpCallSlowCase): * jit/JITCode.cpp: (JSC::JITCode::hostFunction): (JSC::JITCodeWithCodeRef::JITCodeWithCodeRef): (JSC::JITCodeWithCodeRef::~JITCodeWithCodeRef): (JSC::JITCodeWithCodeRef::executableAddressAtOffset): (JSC::JITCodeWithCodeRef::dataAddressAtOffset): (JSC::JITCodeWithCodeRef::offsetOf): (JSC::JITCodeWithCodeRef::size): (JSC::JITCodeWithCodeRef::contains): (JSC::DirectJITCode::DirectJITCode): (JSC::DirectJITCode::~DirectJITCode): (JSC::DirectJITCode::initializeCodeRef): (JSC::DirectJITCode::ensureWrappers): (JSC::DirectJITCode::addressForCall): (JSC::NativeJITCode::NativeJITCode): (JSC::NativeJITCode::~NativeJITCode): (JSC::NativeJITCode::initializeCodeRef): (JSC::NativeJITCode::addressForCall): * jit/JITCode.h: * jit/JITOperations.cpp: * jit/JITOperations.h: (JSC::operationLinkFor): (JSC::operationVirtualFor): (JSC::operationLinkClosureCallFor): * jit/RegisterPreservationWrapperGenerator.cpp: Added. (JSC::registersToPreserve): (JSC::registerPreservationOffset): (JSC::generateWrapper): (JSC::generateRegisterRestoration): (JSC::registerRestorationThunkGenerator): * jit/RegisterPreservationWrapperGenerator.h: Added. * jit/Repatch.cpp: (JSC::linkSlowFor): (JSC::linkFor): (JSC::linkClosureCall): * jit/Repatch.h: * jit/ThunkGenerators.cpp: (JSC::linkForThunkGenerator): (JSC::linkCallThunkGenerator): (JSC::linkConstructThunkGenerator): (JSC::linkCallThatPreservesRegsThunkGenerator): (JSC::linkConstructThatPreservesRegsThunkGenerator): (JSC::linkClosureCallForThunkGenerator): (JSC::linkClosureCallThunkGenerator): (JSC::linkClosureCallThatPreservesRegsThunkGenerator): (JSC::virtualForThunkGenerator): (JSC::virtualCallThunkGenerator): (JSC::virtualConstructThunkGenerator): (JSC::virtualCallThatPreservesRegsThunkGenerator): (JSC::virtualConstructThatPreservesRegsThunkGenerator): * jit/ThunkGenerators.h: (JSC::linkThunkGeneratorFor): (JSC::linkClosureCallThunkGeneratorFor): (JSC::virtualThunkGeneratorFor): * llint/LLIntEntrypoint.cpp: (JSC::LLInt::setFunctionEntrypoint): (JSC::LLInt::setEvalEntrypoint): (JSC::LLInt::setProgramEntrypoint): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::entryOSR): (JSC::LLInt::setUpCall): * llint/LowLevelInterpreter.asm: * runtime/ArityCheckMode.h: Added. * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/Executable.cpp: (JSC::ScriptExecutable::installCode): * runtime/Executable.h: (JSC::ExecutableBase::entrypointFor): (JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor): (JSC::NativeExecutable::finishCreation): * runtime/RegisterPreservationMode.h: Added. 2013-12-19 Mark Lam CStack: The JIT does not need a slow path stack check. https://bugs.webkit.org/show_bug.cgi?id=126036. Reviewed by Geoffrey Garen. The JIT uses the C stack which is not growable. If we fail a stack check in the function header, then a stack overflow is imminent, and there's no need to redo the check in the slow path helper. Hence, renamed operationStackCheck() to operationThrowStackOverflowError() and change the JIT and DFG code to use this appropriately. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileFunction): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JITOperations.cpp: * jit/JITOperations.h: 2013-12-19 Michael Saboff CStack Branch: Fix call operationStackCheck to check the proper stack https://bugs.webkit.org/show_bug.cgi?id=126026 Unreviewed change suggested by Geoff Garen post landing. Change from using codeBlock->stackPointerOffset to using codeBlock->frameRegisterCount() to caclulate the needed stack space. * jit/JITOperations.cpp: 2013-12-19 Michael Saboff CStack Branch: Fix call operationStackCheck to check the proper stack https://bugs.webkit.org/show_bug.cgi?id=126026 Reviewed by Mark Lam. Changed operationStackCheck() to check the appropriate stack based on the compile flag ENABLE(LLINT_CLOOP). * jit/JITOperations.cpp: 2013-12-19 Michael Saboff CStack Branch: Fix call eval in baseline JIT https://bugs.webkit.org/show_bug.cgi?id=126020 Reviewed by Geoffrey Garen. Added code to properly set and restore the stack pointer around the call to operationCallEval. Due to the state the stack is in when the exception check in the call is done, I changed callOperationWithCallFrameRollbackOnException() to be callOperationNoExceptionCheck() and check for an exception after the caller's stack has been restored. Changed operationCallEval() to take a second argument for the execCallee, given that we always pass the caller's exec as the first arguement. * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::compileCallEval): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCallSlowCase): * jit/JITInlines.h: (JSC::JIT::callOperationNoExceptionCheck): * jit/JITOperations.cpp: * jit/JITOperations.h: 2013-12-18 Geoffrey Garen Clarified stack maintainence code https://bugs.webkit.org/show_bug.cgi?id=125979 Reviewed by Phil Pizlo. Our idiom is: * frameRegisterCount() is the distance between BP and SP * stackPointerOffset() is frameRegisterCount() converted to a stack offset * Stack checks don't need to check the stack used by C helper functions, since our reserved host zone will cover that. * assembler/MaxFrameExtentForSlowPathCall.h: Reverted some pieces of . We don't consider our callee's saved PC and BP a part of our stack frame because they lie beneath our SP. * bytecode/CodeBlock.cpp: * bytecode/CodeBlock.h: (JSC::CodeBlock::stackPointerOffset): New helper function. Lots of callers were duplicating this, so I made a helper function. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addCall): (JSC::DFG::ByteCodeParser::parseBlock): Fixed a bug in the calculation of m_parameterSlots. Within our stack frame, we don't reserve space for our callee's saved PC and BP, so we don't need to add them to m_parameterSlots. * dfg/DFGGraph.cpp: * dfg/DFGGraph.h: (JSC::DFG::Graph::stackPointerOffset): New helper function. Lots of callers were duplicating this, so I made a helper function. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::adjustAndJumpToTarget): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct): * interpreter/CallFrame.cpp: (JSC::CallFrame::topOfFrameInternal): Use the new helper function, so everybody calculates SP the same way. This removes the two idiosyncratic places that reserved extra space for our callee's CallerFrameAndPCSize. * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::entryCheck): (JSC::JSStack::pushFrame): (JSC::JSStack::grow): Changed the interface here to accept a top-of-stack pointer instead of a past-the-end pointer. The engine no longer computes a past-the-end pointer, so this is more convenient. * jit/JIT.cpp: (JSC::JIT::privateCompile): (JSC::JIT::stackPointerOffsetFor): Use the helper function, fixing a bug where, incorrectly, we subtracted out maxFrameExtentForSlowPathCall. * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::compileOpCall): (JSC::JIT::compileOpCallSlowCase): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_catch): * jit/JITOperations.cpp: Use the helper function, so everybody does this calculation the same way. * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): Reverted some pieces of , as above. * llint/LLIntEntrypoint.cpp: * llint/LLIntEntrypoint.h: (JSC::LLInt::stackPointerOffsetFor): Helper function, as above. * llint/LowLevelInterpreter.asm: Reverted some pieces of , as above. 2013-12-19 Michael Saboff CStack Branch: Remove "AndAlloc" from sizeAndAllocFrameForVarargs and friends https://bugs.webkit.org/show_bug.cgi?id=125980 Reviewed by Mark Lam. Renamed sizeAndAllocFrameForVarargs to sizeFrameForVarargs along with removing "and alloc" from all related callers. This was done because sizeAndAllocFrameForVarargs, didn't really allocate but just sized the new call frame. * interpreter/Interpreter.cpp: (JSC::sizeFrameForVarargs): * interpreter/Interpreter.h: * jit/JITCall.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITCall32_64.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: 2013-12-18 Mark Lam CStack: Rename functions in JSStack to fit WebKit Coding Style. https://bugs.webkit.org/show_bug.cgi?id=125974. Reviewed by Filip Pizlo. This is a purely cosmetic change. There are no semantic changes. * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::gatherConservativeRoots): (JSC::JSStack::sanitizeStack): * interpreter/JSStack.h: (JSC::JSStack::baseOfStack): * interpreter/JSStackInlines.h: (JSC::JSStack::topOfFrameFor): (JSC::JSStack::topOfStack): (JSC::JSStack::startOfFrameFor): (JSC::JSStack::entryCheck): (JSC::JSStack::pushFrame): (JSC::JSStack::popFrame): (JSC::JSStack::shrink): (JSC::JSStack::installFence): (JSC::JSStack::validateFence): (JSC::JSStack::installTrapsAfterFrame): 2013-12-18 Mark Lam CStack: Fix baseline to DFG JIT OSR. https://bugs.webkit.org/show_bug.cgi?id=125969. Reviewed by Filip Pizlo. 1. Change operationOptimize() to return a tuple of OSR target address and new topOfFrame value (as opposed to just the OSR target address). 2. Change emitEnterOptimizationCheck() and emitSlow_op_loop_hint() to emit code to set the stackPointer with the returned topOfFrame value if we take the OSR path. * jit/JIT.cpp: (JSC::JIT::emitEnterOptimizationCheck): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOpcodes.cpp: (JSC::JIT::emitSlow_op_loop_hint): * jit/JITOperations.cpp: * jit/JITOperations.h: * runtime/Options.h: 2013-12-18 Michael Saboff CStack Branch: Stop threading callFrameRegister through LLIntSlowCalls https://bugs.webkit.org/show_bug.cgi?id=125964 Reviewed by Geoffrey Garen. Removed the general restoring of the call frame registers (cfr) after the return from a LLInt slow calls. In most cases, the "exec" value of the LLInt slow path return pair is set to 0. For llint_slow_path_call/construct and llint_slow_path_size_and_alloc_frame_for_varargs the execCallee is returned in the "exec" value. When an exception happens in a slow path handler we return 0, because the llint_throw_from_slow_path_trampoline path will properly unwind by making a slow call that will invoke genericUnwind() to do the real unwinding. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: 2013-12-18 Mark Lam CStack: Fix LLINT to baseline JIT OSR. https://bugs.webkit.org/show_bug.cgi?id=125957. Reviewed by Michael Saboff. 1. In LLINT prologue code, when taking the OSR path, we don't actually need the OSR slow path function to return the new stackPointer value. Instead, the OSR prep code in the prologue needs to restore the previous sp because we are going to jump to the prologue of the target codeBlock, which will assume that the stack pointer to be pointing to the top of the caller frame. To do this, we simply set stackPointer to the "new" callFrameRegister before we pop the "old" callFrame address into the callFrameRegister. 2. In the LLINT checkSwitchToJITForLoop() macro, if we're going to take the OSR path, we'll need to set the stackPointer to the new topOfFrame for the target codeBlock. Hence, we make llint_loop_osr return exec->topOfFrame() for this purpose. 3. Previously, CallFrame::topOfFrame() (renamed from CallFrame::frameExtent()) would return the address of the slot past the top of the frame. It now returns the slot at the top of the frame as it should. * interpreter/CallFrame.cpp: (JSC::CallFrame::topOfFrameInternal): * interpreter/CallFrame.h: (JSC::ExecState::topOfFrame): * interpreter/JSStack.cpp: (JSC::JSStack::disableErrorStackReserve): * interpreter/JSStackInlines.h: (JSC::JSStack::getTopOfFrame): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::entryOSR): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2013-12-18 Michael Saboff CStack Branch: getHostCallReturnValue shouldn't pop the callFrame https://bugs.webkit.org/show_bug.cgi?id=125931 Reviewed by Geoffrey Garen. Since getHostCallReturnValue() is called after a call to a slow path function and the return from the slow patch pops the call frame there is no need for getHostCallReturnValue() to pop the frame. Removed the popping of the call frame getHostCallReturnValue() for all CPU platforms. * jit/JITOperations.cpp: 2013-12-18 Michael Saboff CStack Branch: Exceptions in LLIntSlowPaths shouldn't pop call frame https://bugs.webkit.org/show_bug.cgi?id=125932 Reviewed by Mark Lam. Removed the unwinding of the call frame in LLINT_CALL_RETURN(). Since llint_slow_path_handle_exception will unwind to the proper callFrame via genericUnwind() there is no need for the frame to be unwound in llint slow paths. * llint/LLIntSlowPaths.cpp: 2013-12-17 Michael Saboff CStack Branch: Fix varargs calls to work on C stack https://bugs.webkit.org/show_bug.cgi?id=125903 Reviewed by Filip Pizlo. Fixed up the stack pointer after the sizeAndAllocFrameForVarargs() has been called in both the LLInt and baseline JIT code. Adjusted the callee frame calculations in sizeAndAllocFrameForVarargs() and compileLoadVarargs() to create aligned callee frames. * interpreter/Interpreter.cpp: (JSC::sizeAndAllocFrameForVarargs): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JITCall.cpp: (JSC::JIT::compileLoadVarargs): * llint/LowLevelInterpreter.asm: 2013-12-17 Mark Lam frameRegisterCount() should include maxFrameExtentForSlowPathCall. https://bugs.webkit.org/show_bug.cgi?id=125881. Reviewed by Geoffrey Garen, Michael Saboff, and Filip Pizlo. * assembler/MaxFrameExtentForSlowPathCall.h: - Added CallerFrameAndPCSize to all the maxFrameExtentForSlowPathCall values. * bytecode/VirtualRegister.h: (JSC::VirtualRegister::offsetInBytes): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::frameRegisterCount): * jit/JIT.cpp: (JSC::JIT::privateCompile): (JSC::JIT::frameRegisterCountFor): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_catch): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): - Adjusted maxFrameExtentForSlowPathCall values for CallerFrameAndPCSize. * llint/LLIntEntrypoint.cpp: (JSC::LLInt::frameRegisterCountFor): * llint/LowLevelInterpreter.asm: - Adjusted maxFrameExtentForSlowPathCall values for CallerFrameAndPCSize. 2013-12-17 Mark Lam Introduce a maxFrameExtentForSlowPathCallInRegisters value. https://bugs.webkit.org/show_bug.cgi?id=125877. Reviewed by Michael Saboff. Sometimes, we need this max frame extent value in units of Registers. So, might as well provide it at the source. * assembler/MaxFrameExtentForSlowPathCall.h: 2013-12-16 Michael Saboff CStack Branch: Fix callee frame access in virtualForThunkGenerator when we don't emit prologue code https://bugs.webkit.org/show_bug.cgi?id=125828 Reviewed by Geoffrey Garen. Added helpers to access the callee frame using the stack pointer taking into account that the caller frame hasn't been pushed onto the stack. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitPutToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::emitPutPayloadToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::emitPutTagToCallFrameHeaderBeforePrologue): * jit/ThunkGenerators.cpp: (JSC::virtualForThunkGenerator): 2013-12-16 Michael Saboff CStack Branch: Need an implementation of sanitizeStack for C stack https://bugs.webkit.org/show_bug.cgi?id=125719 Reviewed by Geoffrey Garen. Implemented sanitizeStackForVM() as a LLInt stub. It clears memory beyond the top of stack through the last stack top, which is stored in the VM. * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * heap/Heap.cpp: (JSC::Heap::markRoots): * interpreter/JSStack.cpp: (JSC::JSStack::sanitizeStack): * llint/LowLevelInterpreter.asm: * runtime/VM.cpp: (JSC::VM::VM): (JSC::sanitizeStackForVM): * runtime/VM.h: (JSC::VM::lastStackTop): (JSC::VM::setLastStackTop): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::~VMEntryScope): * runtime/VMEntryScope.h: 2013-12-16 Mark Lam Merged r160665 from trunk. 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 Michael Saboff CStack Branch: Eliminate topOfStack parameter from callToJavaScript() and callToNativeFunction() https://bugs.webkit.org/show_bug.cgi?id=125791 Reviewed by Geoffrey Garen. Eliminated topOfStack from the callToJavaScript() and callToNativeFunction() calling chains. * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): * jit/JITCode.cpp: (JSC::JITCode::execute): * jit/JITCode.h: * jit/JITStubs.h: * llint/LLIntThunks.h: * llint/LowLevelInterpreter.asm: 2013-12-16 Michael Saboff CStack Branch: REGRESSION(r160600) ASSERT failure in Heap::collect() https://bugs.webkit.org/show_bug.cgi?id=125789 Reviewed by Geoffrey Garen. Restored the shouldCollect() check so we don't collect on start up. Eliminated the Options::disableGC() check since it is part of the isDeferred() check. * heap/Heap.cpp: (JSC::Heap::collectIfNecessaryOrDefer): 2013-12-14 Mark Lam Fix exception handling for the baseline JIT. https://bugs.webkit.org/show_bug.cgi?id=125736. Reviewed by Geoffrey Garen. * interpreter/Interpreter.cpp: (JSC::unwindCallFrame): Removed some unneeded code. 1. Removed use of the oldCodeBlock variable which is only a copy of the codeBlock variable. There is no longer any reason to use a copy. Just use codeBlock directly instead. 2. There's no need to set VM::topCallFrame. The UnwindFunctor automatically updates the incoming callFrame pointer reference to the frame that should be catching / handling the exception, and that is adequate for what we need. * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): - Restored sp. * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): (JSC::JIT::emit_op_catch): * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): Fixed 2 issues: 1. After returning from a native / host function, the thunk did not pop the native / host frame before executing exception handling code. This resulted in the VM trying to "unwind" the native / host frame which is not possible, and crashes ensue. 2. After returning from a native / host function and discovering the need to handle an exception, the thunk was wrongly popping a non-existant return address off the stack. This caused the callerFrame pointer of the current frame to be popped off the stack, and havoc ensues. * llint/LowLevelInterpreter32_64.asm: - Updated to match exception handling code in LowLevelInterpreter64.asm. * runtime/VM.h: - Removed dead code. 2013-12-14 Filip Pizlo FTL should *really* know when things are flushed https://bugs.webkit.org/show_bug.cgi?id=125747 Reviewed bu 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 Filip Pizlo Unreviewed, revert r156746, "FTL: split overflow checks into non-overflow arithmetic and an additional call to the overflow intrinsic check." This introduces redundancies that LLVM can't handle. Reverting this change brings the FTL up to being on-par with the DFG on V8v7/encrypt. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileAddSub): (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileArithNegate): 2013-12-14 Filip Pizlo cStack: Calling into FTL-generated code should be fast https://bugs.webkit.org/show_bug.cgi?id=125649 Reviewed by Geoffrey Garen. * assembler/AbstractMacroAssembler.h: * bytecode/StructureStubInfo.h: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedPutById): * ftl/FTLAbbreviations.h: (JSC::FTL::arrayType): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLCompile.cpp: (JSC::FTL::fixFunctionBasedOnStackMaps): * ftl/FTLExitValue.h: (JSC::FTL::ExitValue::withVirtualRegister): * ftl/FTLIntrinsicRepository.h: * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::initializeEntrypoint): (JSC::FTL::JITCode::initializeAddressForCall): (JSC::FTL::JITCode::addressForCall): (JSC::FTL::JITCode::executableAddressAtOffset): * ftl/FTLJITCode.h: * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::finalizeFunction): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::lower): (JSC::FTL::LowerDFGToLLVM::compileGetById): (JSC::FTL::LowerDFGToLLVM::compilePutById): (JSC::FTL::LowerDFGToLLVM::buildExitArguments): (JSC::FTL::LowerDFGToLLVM::payloadFor): (JSC::FTL::LowerDFGToLLVM::tagFor): (JSC::FTL::LowerDFGToLLVM::addressFor): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLOutput.h: (JSC::FTL::Output::ptrToInt): * ftl/FTLSlowPathCall.cpp: (JSC::FTL::callOperation): * ftl/FTLSlowPathCall.h: * ftl/FTLState.h: * ftl/FTLThunks.cpp: (JSC::FTL::osrExitGenerationThunkGenerator): * ftl/FTLThunks.h: * heap/Heap.cpp: (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: (JSC::Heap::isDeferred): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::tagFor): (JSC::AssemblyHelpers::payloadFor): * jit/JITInlineCacheGenerator.cpp: (JSC::JITByIdGenerator::JITByIdGenerator): (JSC::JITPutByIdGenerator::JITPutByIdGenerator): * jit/JITInlineCacheGenerator.h: (JSC::JITGetByIdGenerator::JITGetByIdGenerator): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_put_by_id): * jit/Repatch.cpp: (JSC::tryBuildGetByIDList): (JSC::emitPutTransitionStub): * runtime/JSCJSValue.h: * runtime/Options.h: 2013-12-13 Michael Saboff CStack Branch: Remove WTF_USE_SEPARATE_C_AND_JS_STACK https://bugs.webkit.org/show_bug.cgi?id=125733 Reviewed by Mark Lam. WTF_USE_SEPARATE_C_AND_JS_STACK is only set for ENABLE(LLINT_C_LOOP) and is therefore not needed. Replaced #if USE(SEPARATE_C_AND_JS_STACK) with #if ENABLE(LLINT_C_LOOP) and eliminated WTF_USE_SEPARATE_C_AND_JS_STACK. * assembler/MaxFrameExtentForSlowPathCall.h: * heap/Heap.cpp: (JSC::Heap::markRoots): * interpreter/JSStack.cpp: (JSC::JSStack::gatherConservativeRoots): * interpreter/JSStackInlines.h: (JSC::JSStack::updateStackLimit): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::arityCheckFor): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2013-12-13 Michael Saboff cStack: Crypto crashes in GC https://bugs.webkit.org/show_bug.cgi?id=125730 Reviewed by Filip Pizlo. Need to disable visiting the JSStack when we are on the C stack. Made visiting the JSStack conditional on USE(SEPARATE_C_AND_JS_STACK) and then turned off WTF_USE_SEPARATE_C_AND_JS_STACK in platform.h. * heap/Heap.cpp: (JSC::Heap::markRoots): * interpreter/JSStack.cpp: (JSC::JSStack::gatherConservativeRoots): 2013-12-13 Michael Saboff cStack: Crypto doesn't work at all unless LLInt is disabled https://bugs.webkit.org/show_bug.cgi?id=125729 Reviewed by Filip Pizlo. At the end of the functionArityCheck() macro, updated the stack pointer with the amount the frame moved. This change has already been made in the arityFixup thunk generator. * llint/LowLevelInterpreter64.asm: 2013-12-13 Mark Lam Fix exception handling for the LLINT. https://bugs.webkit.org/show_bug.cgi?id=125672. Reviewed by Geoffrey Garen. The baseline JIT exception handling is still broken. * JavaScriptCore.order: * llint/LLIntSlowPaths.cpp: * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: - updated the 32bit file with some of the changes to keep track with the 64bit one though it doesn't build yet. The build failure will clearly tell us some of the things that need to be fixed later. * llint/LowLevelInterpreter64.asm: - Called restoreStackPointerAfterCall() in op_catch and nativeCallTrampoline to restore the appropriate stack pointer. - Renamed the restoreStackPointerAfterJSCall() macro to restoreStackPointerAfterCall because we also need to call it after a call to a native / host function. - Removed llint_throw_from_native_call because it no longer does anything useful. - Moved call to functionEpilogue() in nativeCallTrampoline before the exception check because we should have returned from the native / host function already. The Interpreter::unwind() code also relies on this. The VM will unwind and "pop" JS frames, but will stop at host frames. The host frame should pop itself. Then, we call Interpreter::unwind() again to continue for caller frames further up the stack. - Removed the check for the sentinel frame in handleUncaughtException because we're guaranteed to be at the frame above the sentinel frame. 2013-12-13 Michael Saboff jsCStack:REGRESSION: "print(“My object: “ + { });” crashes LLINT in op_call https://bugs.webkit.org/show_bug.cgi?id=125694 Reviewed by Filip Pizlo. We were clobbering the rbx value saved on the stack at the top of callToJavaScript and callToNativeFunction. This is due to a difference between the JSStack's notion of top of stack being the first usable location and the stack pointer register pointing to the last used location. I changed the allocation of the sentinel frame accordingly. In the process I cleaned up the rounding of paddedArgsCount in ProtoCallFrame::init to use WTF::roundUpToMultipleOf<> since the rounding had to change to keep the stack pointer aligned. * interpreter/ProtoCallFrame.cpp: (JSC::ProtoCallFrame::init): * llint/LowLevelInterpreter64.asm: 2013-12-12 Michael Saboff CStack Branch: Use proper values for stack checks https://bugs.webkit.org/show_bug.cgi?id=125677 Reviewed by Filip Pizlo. For the LLInt using CodeBlock::m_numCalleeRegisters + maxFrameExtentForSlowPathCall. For the baseline JIT using frameRegisterCountFor(). For the DFG using Graph::requiredRegisterCountForExecutionAndExit(). Using virtualRegisterForLocal().offset() to get the register offset given a count. Note that for N registers, the value passed into virtualRegisterForLocal() needs to be N-1, since we are trying to check to see if there is space for registers 0..N-1. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileFunction): * jit/JIT.cpp: (JSC::JIT::privateCompile): * llint/LowLevelInterpreter.asm: 2013-12-12 Michael Saboff CStack Branch: Add equivalent values from MaxFrameExtentForSlowPathCall.h to lint files https://bugs.webkit.org/show_bug.cgi?id=125669 Reviewed by Mark Lam. Added platform specific value of maxFrameExtentForSlowPathCall to llint code. Also added ASSERTs to check that we are using the save value in both places. Per review comments, I also updated the CPU(ARM) || ... in MaxFrameExtentForSlowPathCall.h to be just CPU(ARM) since it covers all ARM 32 bit variants. * assembler/MaxFrameExtentForSlowPathCall.h: * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: 2013-12-12 Michael Saboff CStack Branch: Add the new assembler/MaxFrameExtentForSlowPathCall.h to build files https://bugs.webkit.org/show_bug.cgi?id=125668 Reviewed by Mark Lam. Added assembler/MaxFrameExtentForSlowPathCall.h to Xcode, Visual Studio and GNUmake build files. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: 2013-12-12 Michael Saboff CStack Branch: Put all stack saving and restoring callToJavaScript in {push/pop}CalleeSaves https://bugs.webkit.org/show_bug.cgi?id=125666 Reviewed by Geoffrey Garen. Eliminated "extraStack" arguments and related stack pointer manipulation for 64 bit platforms. Both ARM64 and X86_64 already have aligned stacks. Eliminated some related commented out code. * llint/LowLevelInterpreter64.asm: 2013-12-12 Michael Saboff CStack Branch: Eliminate unnecessary add/sub 16 to stack pointer https://bugs.webkit.org/show_bug.cgi?id=125653 Reviewed by Geoffrey Garen. Changes as a result of review. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::frameRegisterCount): Changed c-style cast to static_cast. Changed rounding for stack alignment to use WTF::roundUpToMultipleOf * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): Added assertion for JSStack::CallerFrameAndPCSize 2013-12-12 Michael Saboff CStack Branch: Eliminate unnecessary add/sub 16 to stack pointer https://bugs.webkit.org/show_bug.cgi?id=125653 Reviewed by Geoffrey Garen. Changed the DFG stack frame to include outgoing space for at least the two pointers for returnPC and callerFrame. Changed the setting of the stack pointer to not include the space for the outgoing returnPC and callerFrame. Eliminated the add/sub 16 around calls in the DFG. Adjusted the LLInt and baseline JIT calculation of the stack pointer for calls. In both cases, the frame is set up with temp that points to the base of the callee frame. The space for the outgoing returnPC and callerFrame is added to the temp to create the stack pointer for the call. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::frameRegisterCount): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * interpreter/JSStack.h: * jit/JITCall.cpp: (JSC::JIT::compileOpCall): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: 2013-12-12 Mark Lam Fix handling of uncaught exceptions. https://bugs.webkit.org/show_bug.cgi?id=125648. Reviewed by Geoffrey Garen. * llint/LowLevelInterpreter64.asm: - handleUncaughtException should load the "catch" callFrame instead of assuming that the current one is appropriate. This is now fixed. 2013-12-12 Michael Saboff CStack Branch: Change the disabling of DFG OSR entry to be based on an option https://bugs.webkit.org/show_bug.cgi?id=125645 Rubber stamped by Filip Pizlo. Added a new enableOSREntryToDFG option and set the default value to false. If the option is false, prepareOSREntry() will return 0 which disables OSR entry, as the return value is the address to jump to or 0 if we can't OSR enter. Restored the code in emitEnterOptimizationCheck() and emitSlow_op_loop_hint() that checks the exit value from operationOptimize(). Per a discussion with Filip, removed the enableOSREntryInLoops option and associated use. All OSR entry to the DFG is now controlled with the new option. * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * jit/JIT.cpp: (JSC::JIT::emitEnterOptimizationCheck): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_loop_hint): (JSC::JIT::emitSlow_op_loop_hint): * runtime/Options.h: 2013-12-12 Mark Lam Rename returnFromJavaScript to handleUncaughtException. https://bugs.webkit.org/show_bug.cgi?id=125613. Reviewed by Filip Pizlo. Also did a few minor fixes to get the C Loop LLINT offline asm stage to build properly, and also some trivial changes to minimize the compile errors for LowLevelInterpreter.cpp. It doesn't build completely and run yet since we'll need to update it for CStack changes that have not been implemented for the C Loop LLINT yet. * interpreter/Interpreter.cpp: (JSC::unwindCallFrame): * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/JITStubs.h: * jit/JITStubsMSVC64.asm: * jit/JITStubsX86.h: * llint/LLIntOpcode.h: * llint/LLIntThunks.h: * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/cloop.rb: 2013-12-11 Michael Saboff CStack Branch: Set stack pointer in OSR exit handler https://bugs.webkit.org/show_bug.cgi?id=125617 Reviewed by Oliver Hunt. Set the stack pointer off of the callFrameRegister just like at the top of the function. * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::adjustAndJumpToTarget): 2013-12-11 Mark Lam Introducing MaxFrameExtentForSlowPathCall.h. https://bugs.webkit.org/show_bug.cgi?id=125609. Reviewed by Mark Hahnenberg. * assembler/MaxFrameExtentForSlowPath.h: Added. - defines a constant for the max amount of stack space that we need to allocate (per JS frame) for holding the outgoing args for slow path calls from JS to C functions. 2013-12-11 Michael Saboff CStack Branch: enable use of DFG for simple JavaScript https://bugs.webkit.org/show_bug.cgi?id=125599 Reviewed by Filip Pizlo. Added code to set up the stack pointer on entry and for call for the DFG. Changed the SpeculativeJIT::calleeFrame*() helpers to use the stack pointer instead of the call frame register to build the callee frame relative to the stack. Disabled JSStack::sanitizeStack(). Removed some calls to checkStackPointerAlignment() used for earlier debugging. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::frameRegisterCount): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileEntry): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::calleeFrameOffset): (JSC::DFG::SpeculativeJIT::calleeFrameSlot): (JSC::DFG::SpeculativeJIT::calleeArgumentSlot): (JSC::DFG::SpeculativeJIT::calleeFrameTagSlot): (JSC::DFG::SpeculativeJIT::calleeFramePayloadSlot): (JSC::DFG::SpeculativeJIT::calleeArgumentTagSlot): (JSC::DFG::SpeculativeJIT::calleeArgumentPayloadSlot): (JSC::DFG::SpeculativeJIT::calleeFrameCallerFrame): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * ftl/FTLThunks.cpp: (JSC::FTL::osrExitGenerationThunkGenerator): (JSC::FTL::slowPathCallThunkGenerator): * interpreter/JSStack.cpp: (JSC::JSStack::sanitizeStack): * interpreter/JSStack.h: * interpreter/ProtoCallFrame.cpp: (JSC::ProtoCallFrame::init): * jit/JIT.cpp: (JSC::JIT::emitEnterOptimizationCheck): (JSC::JIT::privateCompile): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_ret): (JSC::JIT::emit_op_enter): (JSC::JIT::emitSlow_op_loop_hint): * jit/Repatch.cpp: (JSC::linkClosureCall): * jit/ThunkGenerators.cpp: (JSC::slowPathFor): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: 2013-12-09 Michael Saboff CStack Branch: ctiNativeCallFallback and friends should renamed ...NativeTailCall https://bugs.webkit.org/show_bug.cgi?id=125485 Reviewed by Geoffrey Garen. Changed ctiNativeCallFallback to ctiNativeTailCall and nativeCallFallbackGenerator to nativeTailCallGenerator to be more descriptive of what is happening. * jit/JITThunks.cpp: (JSC::JITThunks::ctiNativeTailCall): * jit/JITThunks.h: * jit/ThunkGenerators.cpp: (JSC::nativeTailCallGenerator): (JSC::charCodeAtThunkGenerator): (JSC::charAtThunkGenerator): (JSC::fromCharCodeThunkGenerator): (JSC::sqrtThunkGenerator): (JSC::floorThunkGenerator): (JSC::ceilThunkGenerator): (JSC::roundThunkGenerator): (JSC::expThunkGenerator): (JSC::logThunkGenerator): (JSC::absThunkGenerator): (JSC::powThunkGenerator): (JSC::imulThunkGenerator): (JSC::arrayIteratorNextThunkGenerator): * jit/ThunkGenerators.h: 2013-12-09 Michael Saboff CStack Branch: Change nativeForGenerator fallBack bool to an enum https://bugs.webkit.org/show_bug.cgi?id=125473 Reviewed by Filip Pizlo. Change the "bool fallBack" to an enum name ThunkEntryType with values EnterViaCall and EnterViaJump to indicate how the thunk will be entered. * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): (JSC::nativeCallFallbackGenerator): 2013-12-09 Michael Saboff CStack Branch: Fix baseline JIT for basic operation https://bugs.webkit.org/show_bug.cgi?id=125470 Reviewed by Geoff Garen. Fixed compileOpCall and its slow case to properly adjust the stack pointer before and after a call. Cleaned up the calling convention in the various thunks. Adjusted the stack pointer at the end of the arity fixup thunk to account for the frame moving. Added ctiNativeCallFallback() thunk generator for when another thunk that can't perform its operation inline needs to make a native call. This thunk generator differes from ctiNativeCall() in that it doesn't emit a function prologue, thus allowing the original thunk to jump to the "fallback" thunk. I'm open to another name beside "fallback". Maybe "ctiNativeTailCall()". Fixed the OSR entry handling in the LLInt prologue macro to properly account for the callee saving the caller frame pointer. Added stack alignement check function for use in debug builds to find and break if the stack pointer is not appropriately aligned. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::checkStackPointerAlignment): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JIT.h: (JSC::JIT::frameRegisterCountFor): * jit/JITCall.cpp: (JSC::JIT::compileOpCall): (JSC::JIT::compileOpCallSlowCase): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_ret): (JSC::JIT::emit_op_enter): * jit/JITThunks.cpp: (JSC::JITThunks::ctiNativeCallFallback): * jit/JITThunks.h: * jit/ThunkGenerators.cpp: (JSC::slowPathFor): (JSC::nativeForGenerator): (JSC::nativeCallFallbackGenerator): (JSC::arityFixup): (JSC::charCodeAtThunkGenerator): (JSC::charAtThunkGenerator): (JSC::fromCharCodeThunkGenerator): (JSC::sqrtThunkGenerator): (JSC::floorThunkGenerator): (JSC::ceilThunkGenerator): (JSC::roundThunkGenerator): (JSC::expThunkGenerator): (JSC::logThunkGenerator): (JSC::absThunkGenerator): (JSC::powThunkGenerator): (JSC::imulThunkGenerator): (JSC::arrayIteratorNextThunkGenerator): * jit/ThunkGenerators.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: 2013-12-06 Michael Saboff CStack Branch: Fix Specialized Thunks to use function prologues and epilogues https://bugs.webkit.org/show_bug.cgi?id=125381 Reviewed by Geoffrey Garen. Changed the entry / exit sequences to use emitFunctionPrologue() and functionEpilogue(). * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::SpecializedThunkJIT): (JSC::SpecializedThunkJIT::returnJSValue): (JSC::SpecializedThunkJIT::returnDouble): (JSC::SpecializedThunkJIT::returnInt32): (JSC::SpecializedThunkJIT::returnJSCell): 2013-12-06 Michael Saboff CStack Branch: Enable basic JavaScript functionality in LLInt https://bugs.webkit.org/show_bug.cgi?id=125378 Reviewed by Filip Pizlo. This provides basic LLInt only functionality for X86_64. It runs simple scripts. There are several places where the code is tagged with "&&&& FIXME: ..." comments as placeholders where more work needs to be done. Added X86 compliant prologue / epilogues at the head and tail of functions. Changed LLInt calls to leave the caller framePointer in callFrame register and pass the callee framePointer (-16) in SP so that the callee receiving prologue will make store the ReturnPC and CallerFrame at the right location in the call frame header. Created a stack pointer sanity check macro (checkStackPointerAlignment) in the LLInt that will cause a breakpoint on failure. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileEntry): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLink.cpp: (JSC::FTL::compileEntry): (JSC::FTL::link): * ftl/FTLThunks.cpp: (JSC::FTL::osrExitGenerationThunkGenerator): (JSC::FTL::slowPathCallThunkGenerator): * interpreter/Interpreter.cpp: (JSC::unwindCallFrame): * interpreter/ProtoCallFrame.cpp: (JSC::ProtoCallFrame::init): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitFunctionPrologue): (JSC::AssemblyHelpers::emitFunctionEpilogue): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JITCall.cpp: (JSC::JIT::privateCompileClosureCall): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_ret): (JSC::JIT::emit_op_ret_object_or_this): * jit/Repatch.cpp: (JSC::linkClosureCall): * jit/ThunkGenerators.cpp: (JSC::slowPathFor): (JSC::nativeForGenerator): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: 2013-12-06 Michael Saboff Merged from trunk r160244: 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 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 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 peavo@outlook.com 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 peavo@outlook.com 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 >::parseUnaryExpression(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