2013-10-13 Anders Carlsson Try to fix the Lion build. * Configurations/JavaScriptCore.xcconfig: 2013-10-12 Alexey Proskuryakov Add a feature define for SubtleCrypto https://bugs.webkit.org/show_bug.cgi?id=122683 Reviewed by Anders Carlsson. * Configurations/FeatureDefines.xcconfig: 2013-10-12 Julien Brianceau Fix potential register trampling in JIT since r157313. https://bugs.webkit.org/show_bug.cgi?id=122691 Reviewed by Michael Saboff. * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArgumentsWithExecState): 2013-10-12 Julien Brianceau [sh4] Add missing spaces in JITStubsSH4.h https://bugs.webkit.org/show_bug.cgi?id=122690 Reviewed by Andreas Kling. * jit/JITStubsSH4.h: Space between string concatenation is mandatory with C++11 2013-10-12 Julien Brianceau [sh4] Add missing test32 implementation in macro assembler. https://bugs.webkit.org/show_bug.cgi?id=122689 Reviewed by Andreas Kling. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::test32): 2013-10-11 Darin Adler Change most call sites to call ICU directly instead of through WTF::Unicode https://bugs.webkit.org/show_bug.cgi?id=122635 Reviewed by Alexey Proskuryakov. * parser/Lexer.cpp: (JSC::isNonLatin1IdentStart): Take a UChar since that's what the only caller wants to pass. Use U_GET_GC_MASK instead of WTF::Unicode::category. (JSC::isNonLatin1IdentPart): Ditto. * parser/Lexer.h: (JSC::Lexer::isWhiteSpace): Use u_charType instead of WTF::Unicode::isSeparatorSpace. * runtime/JSFunction.cpp: Removed "using namespace" for WTF::Unicode, this will no longer compile since this doesn't include anything that defines that namespace. * runtime/JSGlobalObjectFunctions.cpp: (JSC::isStrWhiteSpace): Use u_charType instead of WTF::Unicode::isSeparatorSpace. * yarr/YarrInterpreter.cpp: (JSC::Yarr::ByteCompiler::atomPatternCharacter): Use u_tolower and u_toupper instead of Unicode::toLower and Unicode::toUpper. Also added some assertions since this code assumes it can convert any UChar to lowercase or uppercase in another UChar, with no risk of needing a UChar32 for the result. I guess that's probably true, but it would be good to know in a debug build if not. 2013-10-11 Nadav Rotem DFG: Add JIT support for LogicalNot(String/StringIdent) https://bugs.webkit.org/show_bug.cgi?id=122627 Reviewed by Filip Pizlo. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileStringZeroLength): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compileLogicalNot): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileLogicalNot): 2013-10-11 Filip Pizlo sunspider-1.0/math-spectral-norm.js.dfg-eager occasionally fails with Trap 5 (i.e int $3) https://bugs.webkit.org/show_bug.cgi?id=122462 Reviewed by Mark Hahnenberg. This fixes two bugs, both of which led to GetByVal on Int32 trapping because the array no longer had Int32 shape but the check wasn't executed: 1) We weren't snapshotting the structures of mustHandleValues. This led to an awesome race where if a mustHandleValue JSValue's structure changed on the main thread between runs of the AI, the AI would contradict each other and things would just get corrupted in funny ways. 2) The constant folder has a long standing bug! It will fold a node to a constant if the AI proved it to be a constant. But it's possible that the original node also proved things about the constant's structure. In that case "folding" to a JSConstant actually loses information since JSConstant doesn't guarantee anything about a constant's structure. There are various things we could do here to ensure that a folded constant's structure doesn't change, and that if it does, we deoptimize the code. But for now we can just make this sound by disabling folding in this pathological case. * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): * dfg/DFGGraph.h: * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::initialize): 2013-10-11 Filip Pizlo Fix handling of indirect stackmap locations in FTL OSR exit https://bugs.webkit.org/show_bug.cgi?id=122666 Reviewed by Mark Hahnenberg. With this change, the llvm.webkit.stackmap-based OSR exit only fails one test, down from five tests previously. * ftl/FTLLocation.cpp: (JSC::FTL::Location::gpr): It's OK to call this method when kind() == Indirect, so asserting that isGPR() is wrong; change to assert that involvesGPR(). (JSC::FTL::Location::restoreInto): Stack-related registers aren't saved to the scratch buffer, so use them directly. * ftl/FTLLocation.h: Add comment about requirements for stack layout. * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStubWithOSRExitStackmap): Make enough room on the stack so that saveAllRegisters() has a scratchpad to save things to. Without this, saveAllRegisters() may clobber a spilled value. 2013-10-11 Commit Queue Unreviewed, rolling out r157307. http://trac.webkit.org/changeset/157307 https://bugs.webkit.org/show_bug.cgi?id=122671 Many assertion failures (Requested by ap on #webkit). * jit/ThunkGenerators.cpp: (JSC::arrayIteratorNextThunkGenerator): * jit/ThunkGenerators.h: * runtime/ArrayIteratorPrototype.cpp: (JSC::ArrayIteratorPrototype::finishCreation): (JSC::createIteratorResult): (JSC::arrayIteratorPrototypeNext): * runtime/Intrinsic.h: * runtime/JSArrayIterator.cpp: (JSC::JSArrayIterator::finishCreation): * runtime/VM.cpp: (JSC::thunkGeneratorForIntrinsic): 2013-10-11 Mark Lam Transition op_new_* JITStubs to JIT operations. https://bugs.webkit.org/show_bug.cgi?id=122460. Reviewed by Michael Saboff. Also: - Removed the redundant operationNewFunctionExpression(). It is identical to operationNewFunctionNoCheck(). - Sorted JIT operation signature keys in the comment in JITOperations.h. - Removed the unused returnValue2Register definition for X86_64. * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression): * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArgumentsWithExecState): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOpcodes.cpp: (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_new_func): (JSC::JIT::emit_op_new_func_exp): (JSC::JIT::emit_op_new_array): (JSC::JIT::emit_op_new_array_with_size): (JSC::JIT::emit_op_new_array_buffer): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emitSlow_op_new_object): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITStubs.cpp: * jit/JITStubs.h: * jit/JSInterfaceJIT.h: 2013-10-11 Oliver Hunt Separate out array iteration intrinsics https://bugs.webkit.org/show_bug.cgi?id=122656 Reviewed by Michael Saboff. Separate out the intrinsics for key and values iteration of arrays. This requires moving moving array iteration into the iterator instance, rather than the prototype, but this is essentially unobservable so we'll live with it for now. * jit/ThunkGenerators.cpp: (JSC::arrayIteratorNextThunkGenerator): (JSC::arrayIteratorNextKeyThunkGenerator): (JSC::arrayIteratorNextValueThunkGenerator): * jit/ThunkGenerators.h: * runtime/ArrayIteratorPrototype.cpp: (JSC::ArrayIteratorPrototype::finishCreation): * runtime/Intrinsic.h: * runtime/JSArrayIterator.cpp: (JSC::JSArrayIterator::finishCreation): (JSC::createIteratorResult): (JSC::arrayIteratorNext): (JSC::arrayIteratorNextKey): (JSC::arrayIteratorNextValue): (JSC::arrayIteratorNextGeneric): * runtime/VM.cpp: (JSC::thunkGeneratorForIntrinsic): 2013-10-11 Andreas Kling Pass VM instead of ExecState to JSGenericTypedArrayViewPrototype. Reviewed by Sam Weinig. This code was only using the ExecState to find the VM. 2013-10-11 Julien Brianceau [sh4] Fix build after r157209. https://bugs.webkit.org/show_bug.cgi?id=122643 Reviewed by Ryosuke Niwa. * assembler/MacroAssemblerSH4.h: Add framePointerRegister declaration. * assembler/SH4Assembler.h: Add firstRegister() declaration. (JSC::SH4Assembler::firstRegister): 2013-10-10 Filip Pizlo FTL shouldn't pass i1's into llvm.webkit.stackmap's https://bugs.webkit.org/show_bug.cgi?id=122629 Reviewed by Sam Weinig and Nadav Rotem. LLVM's stackmap support requires that we only pass operands with legal types (i.e. types that are hardware-representable). i1, which the FTL previously used for Booleans, is not legal. We have two options: either add support in LLVM to legalize stackmap operands, or add support to the FTL to legalize stackmap operands. It's easier to fix this in FTL, and that's what this patch does. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): 2013-10-09 Oliver Hunt Further improve ArrayIterator performance https://bugs.webkit.org/show_bug.cgi?id=122575 Reviewed by Mark Hahnenberg. Add an assembly thunk for ArrayIterator.@@next so that we can avoid marshalling costs when iterating arrays. * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::SpecializedThunkJIT): (JSC::SpecializedThunkJIT::loadSpecificClassArgument): * jit/ThunkGenerators.cpp: (JSC::arrayIteratorNextThunkGenerator): * jit/ThunkGenerators.h: * runtime/ArrayIteratorPrototype.cpp: (JSC::ArrayIteratorPrototype::finishCreation): * runtime/Intrinsic.h: * runtime/JSArrayIterator.h: (JSC::JSArrayIterator::offsetOfIterationKind): (JSC::JSArrayIterator::offsetOfIteratedObject): (JSC::JSArrayIterator::offsetOfNextIndex): * runtime/JSCJSValue.h: (JSC::JSValue::offsetOfPayload): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::iteratorResultStructureOffset): * runtime/VM.cpp: (JSC::thunkGeneratorForIntrinsic): 2013-10-10 Michael Saboff transition cti_op_* methods returning int to JIT operations. https://bugs.webkit.org/show_bug.cgi?id=122563 Reviewed by Oliver Hunt. Moved serveral operationCompare* functions from DFGOperations to JITOperations as well as changing dfgConvertJSValueToBoolean to operationConvertJSValueToBoolean so that they can be shared with the baseline JIT. Added JITOperation operationHasProperty(). Added needed callOperation helpers and transitioned baseline JIT code to use the new operations. * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::emitBranch): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::emitBranch): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emitSlow_op_jless): (JSC::JIT::emitSlow_op_jlesseq): (JSC::JIT::emitSlow_op_jgreater): (JSC::JIT::emitSlow_op_jgreatereq): (JSC::JIT::emitSlow_op_jnless): (JSC::JIT::emitSlow_op_jnlesseq): (JSC::JIT::emitSlow_op_jngreater): (JSC::JIT::emitSlow_op_jngreatereq): (JSC::JIT::emit_compareAndJumpSlow): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_compareAndJumpSlow): * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_next_pname): (JSC::JIT::emitSlow_op_jfalse): (JSC::JIT::emitSlow_op_jtrue): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emitSlow_op_neq): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emitSlow_op_jfalse): (JSC::JIT::emitSlow_op_jtrue): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emit_op_next_pname): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITStubs.cpp: * jit/JITStubs.h: 2013-10-10 Filip Pizlo OSR exit using llvm.webkit.stackmap should pass more tests https://bugs.webkit.org/show_bug.cgi?id=122518 Reviewed by Mark Hahnenberg. - Make the X86Assembler capable of dealing with all XMM registers. - Make the StackMaps code on WebKit's side capable of dealing with XMM registers. - Factor out most of the smarts of StackMaps::Location into a self-contained object. Previously you needed both StackMaps::Location and a StackMaps reference to do most things since the Location might have referred to a constant. Now you can just get a self-contained Location object. - Fix a bug where OSR exit generation thunk generator was assuming that the call frame register is already in argumentGPR0. In the future, the call frame will just be the machine FP and we won't have to do anything special. But for now the "call frame" is just a normal value in LLVM IR and may end up in any register. Make the OSR exit generation thunk generator polymorphic over the call frame argument's Location. - Move the stuff that depends on the polymorphic OSR exit generation thunk generator into the finalizer, since generating and linking one of those thunks requires a cache flush and we need to do that on the main thread. * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::firstRegister): (JSC::ARMv7Assembler::lastRegister): (JSC::ARMv7Assembler::firstFPRegister): (JSC::ARMv7Assembler::lastFPRegister): * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::firstFPRegister): (JSC::AbstractMacroAssembler::lastFPRegister): * assembler/MacroAssembler.h: (JSC::MacroAssembler::nextFPRegister): * assembler/MacroAssemblerARMv7.h: * assembler/MacroAssemblerX86Common.h: * assembler/X86Assembler.h: (JSC::X86Assembler::firstFPRegister): (JSC::X86Assembler::lastFPRegister): * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * ftl/FTLCompile.cpp: (JSC::FTL::fixFunctionBasedOnStackMaps): * ftl/FTLExitThunkGenerator.cpp: (JSC::FTL::ExitThunkGenerator::emitThunk): (JSC::FTL::ExitThunkGenerator::emitThunks): * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::finalizeFunction): * ftl/FTLJITFinalizer.h: * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLocation.cpp: Added. (JSC::FTL::Location::forStackmaps): (JSC::FTL::Location::dump): (JSC::FTL::Location::involvesGPR): (JSC::FTL::Location::isGPR): (JSC::FTL::Location::gpr): (JSC::FTL::Location::isFPR): (JSC::FTL::Location::fpr): (JSC::FTL::Location::restoreInto): (WTF::printInternal): * ftl/FTLLocation.h: Added. (JSC::FTL::Location::Location): (JSC::FTL::Location::forRegister): (JSC::FTL::Location::forIndirect): (JSC::FTL::Location::forConstant): (JSC::FTL::Location::kind): (JSC::FTL::Location::hasDwarfRegNum): (JSC::FTL::Location::dwarfRegNum): (JSC::FTL::Location::hasOffset): (JSC::FTL::Location::offset): (JSC::FTL::Location::hasConstant): (JSC::FTL::Location::constant): (JSC::FTL::Location::operator!): (JSC::FTL::Location::isHashTableDeletedValue): (JSC::FTL::Location::operator==): (JSC::FTL::Location::hash): (JSC::FTL::LocationHash::hash): (JSC::FTL::LocationHash::equal): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks): * ftl/FTLSaveRestore.cpp: (JSC::FTL::bytesForFPRs): (JSC::FTL::requiredScratchMemorySizeInBytes): (JSC::FTL::offsetOfFPR): (JSC::FTL::saveAllRegisters): (JSC::FTL::restoreAllRegisters): * ftl/FTLSaveRestore.h: * ftl/FTLStackMaps.cpp: (JSC::FTL::StackMaps::Location::restoreInto): * ftl/FTLStackMaps.h: * ftl/FTLState.h: * ftl/FTLThunks.cpp: (JSC::FTL::osrExitGenerationWithoutStackMapThunkGenerator): (JSC::FTL::osrExitGenerationWithStackMapThunkGenerator): * ftl/FTLThunks.h: (JSC::FTL::generateIfNecessary): (JSC::FTL::Thunks::getOSRExitGenerationThunk): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2013-10-09 Filip Pizlo FTL: Soft-link LLVM as a workaround for LLVM's static initializers and exit-time destructors https://bugs.webkit.org/show_bug.cgi?id=122566 Reviewed by Mark Rowe. The JSC project now builds a libllvmForJSC.dylib. If FTL is enabled, this gets copied into JavaScriptCore.framework/Versions/A/Libraries. JSC will load the dylib by finding it using NSBundle APIs and then doing dlopen(). That will only happen lazily, when something happens that requires LLVM. This mostly takes care of LLVM static initialization overhead by deferring it until it's really needed. This takes care of LLVM's exit-time destructors because inside libllvmForJSC.dylib, we override __cxa_atexit. * Configurations/JavaScriptCore.xcconfig: * Configurations/LLVMForJSC.xcconfig: Added. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * disassembler/LLVMDisassembler.cpp: (JSC::tryToDisassembleWithLLVM): * ftl/FTLAbbreviatedTypes.h: * ftl/FTLAbbreviations.h: (JSC::FTL::voidType): (JSC::FTL::int1Type): (JSC::FTL::int8Type): (JSC::FTL::int16Type): (JSC::FTL::int32Type): (JSC::FTL::int64Type): (JSC::FTL::intPtrType): (JSC::FTL::floatType): (JSC::FTL::doubleType): (JSC::FTL::pointerType): (JSC::FTL::structType): (JSC::FTL::functionType): (JSC::FTL::typeOf): (JSC::FTL::mdKindID): (JSC::FTL::mdString): (JSC::FTL::mdNode): (JSC::FTL::setMetadata): (JSC::FTL::addFunction): (JSC::FTL::setLinkage): (JSC::FTL::setFunctionCallingConv): (JSC::FTL::getParam): (JSC::FTL::constInt): (JSC::FTL::constReal): (JSC::FTL::constIntToPtr): (JSC::FTL::constBitCast): (JSC::FTL::appendBasicBlock): (JSC::FTL::insertBasicBlock): (JSC::FTL::buildPhi): (JSC::FTL::addIncoming): (JSC::FTL::buildAlloca): (JSC::FTL::buildAdd): (JSC::FTL::buildSub): (JSC::FTL::buildMul): (JSC::FTL::buildDiv): (JSC::FTL::buildRem): (JSC::FTL::buildNeg): (JSC::FTL::buildFAdd): (JSC::FTL::buildFSub): (JSC::FTL::buildFMul): (JSC::FTL::buildFDiv): (JSC::FTL::buildFRem): (JSC::FTL::buildFNeg): (JSC::FTL::buildAnd): (JSC::FTL::buildOr): (JSC::FTL::buildXor): (JSC::FTL::buildShl): (JSC::FTL::buildAShr): (JSC::FTL::buildLShr): (JSC::FTL::buildNot): (JSC::FTL::buildLoad): (JSC::FTL::buildStore): (JSC::FTL::buildSExt): (JSC::FTL::buildZExt): (JSC::FTL::buildFPToSI): (JSC::FTL::buildFPToUI): (JSC::FTL::buildSIToFP): (JSC::FTL::buildUIToFP): (JSC::FTL::buildIntCast): (JSC::FTL::buildFPCast): (JSC::FTL::buildIntToPtr): (JSC::FTL::buildPtrToInt): (JSC::FTL::buildBitCast): (JSC::FTL::buildICmp): (JSC::FTL::buildFCmp): (JSC::FTL::buildCall): (JSC::FTL::setTailCall): (JSC::FTL::buildExtractValue): (JSC::FTL::buildSelect): (JSC::FTL::buildBr): (JSC::FTL::buildCondBr): (JSC::FTL::buildSwitch): (JSC::FTL::addCase): (JSC::FTL::buildRet): (JSC::FTL::buildUnreachable): (JSC::FTL::dumpModule): (JSC::FTL::verifyModule): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLFail.cpp: (JSC::FTL::fail): * ftl/FTLJITCode.h: * ftl/FTLJITFinalizer.h: * ftl/FTLLink.cpp: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::lower): * ftl/FTLOutput.cpp: (JSC::FTL::Output::Output): (JSC::FTL::Output::~Output): * ftl/FTLOutput.h: (JSC::FTL::Output::appendTo): * ftl/FTLState.cpp: (JSC::FTL::State::State): (JSC::FTL::State::~State): * ftl/WebKitLLVMLibraryAnchor.cpp: Removed. * jsc.cpp: (jscmain): * llvm: Added. * llvm/InitializeLLVM.cpp: Added. (JSC::initializeLLVM): * llvm/InitializeLLVM.h: Added. * llvm/InitializeLLVMMac.mm: Added. (JSC::initializeLLVMImpl): * llvm/InitializeLLVMPOSIX.cpp: Added. (JSC::initializeLLVMPOSIX): * llvm/InitializeLLVMPOSIX.h: Added. * llvm/LLVMAPI.cpp: Added. * llvm/LLVMAPI.h: Added. * llvm/LLVMAPIFunctions.h: Added. * llvm/LLVMHeaders.h: Added. * llvm/library: Added. * llvm/library/LLVMAnchor.cpp: Added. * llvm/library/LLVMExports.cpp: Added. (initializeAndGetJSCLLVMAPI): * llvm/library/LLVMOverrides.cpp: Added. (__cxa_atexit): * llvm/library/config_llvm.h: Added. * runtime/InitializeThreading.cpp: (JSC::initializeThreadingOnce): * runtime/Options.h: 2013-10-10 Mark Hahnenberg currentThis and currentArguments crash if called from outside a callback https://bugs.webkit.org/show_bug.cgi?id=122620 Reviewed by Filip Pizlo. The documentation for these methods claims that they will return nil if called from somewhere other than an API callback, but currently they both crash. * API/JSContext.mm: (+[JSContext currentThis]): (+[JSContext currentArguments]): * API/tests/testapi.mm: 2013-10-10 Filip Pizlo Minor clean-ups in the JSC Xcode project. Rubber stamped by Mark Rowe. - When we copy the jsc binary into the framework, $(BUILT_PRODUCTS_DIR)/JavaScriptCore.framework/Resources/jsc is the *output* file not the input file. The input file is $(BUILT_PRODUCTS_DIR)/jsc. - Correct capitalization of "JavaScriptcore.framework" in a comment in a shell script in the project. Roll back in after confirming that Mark's fixes make this work right. * JavaScriptCore.xcodeproj/project.pbxproj: 2013-10-10 Mark Hahnenberg CallbackData unnecessarily caches the JSValue for currentThis https://bugs.webkit.org/show_bug.cgi?id=122616 Reviewed by Oliver Hunt. CallbackData implements its own version of caching the JSValue* for the JSValueRef it stores. +[JSValue valueWithJSValueRef:inContext:] already does caching, thus obviating the need for CallbackData to do its own caching. * API/JSContext.mm: (+[JSContext currentThis]): (-[JSContext beginCallbackWithData:thisValue:argumentCount:arguments:]): (-[JSContext endCallbackWithData:]): * API/JSContextInternal.h: 2013-10-10 Filip Pizlo Unreviewed, roll out r157193. It broke some builds. * JavaScriptCore.xcodeproj/project.pbxproj: 2013-10-10 Mark Rowe WebKit should always build against an SDK. Have all projects default to building against the OS X Internal SDK for the Production configuration. For the Debug and Release configurations, look for UseInternalSDK.xcconfig to determine whether the OS X Internal SDK should be used. If not, use the normal OS X SDK. Reviewed by Dan Bernstein. * Configurations/Base.xcconfig: * Configurations/DebugRelease.xcconfig: 2013-10-10 Mark Rowe JavaScriptCore fails to build with C++ 98 conformance changes Reviewed by Andreas Kling. * heap/VTableSpectrum.cpp: (JSC::VTableSpectrum::dump): strrchr returns a const char* when passed one. Update the type of the local variable to accommodate that. 2013-10-10 Mark Hahnenberg Objective-C API: blocks aren't callable via 'new' https://bugs.webkit.org/show_bug.cgi?id=122561 Reviewed by Oliver Hunt. Currently the only way for clients to vend new native objects to JavaScript code is via factory methods in the form of exported class methods or blocks. Blocks can be called like normal functions from JavaScript code, but they cannot be invoked with 'new'. This would give a simple way for clients to expose constructor-like behavior to their JavaScript code. This patch adds the ability for blocks to be invoked as if they were a constructor. Blocks invoked as constructors are required to return an object. If the block doesn't return an object then an error is thrown. The 'this' object is not provided to the block and must be created within the block itself. This patch also unifies the native 'construct' callback used in both the C and Obj-C APIs under the APICallbackFunction struct, similar to how we unified the 'call' callback between ObjCCallbackFunction and JSCallbackFunction before. This patch also adds tests to make sure that different blocks generate objects that correctly behave when queried with instanceof. It also makes sure that the correct JS exception is thrown when a block fails to return an object. * API/APICallbackFunction.h: (JSC::APICallbackFunction::call): (JSC::APICallbackFunction::construct): * API/JSCallbackConstructor.cpp: (JSC::JSCallbackConstructor::getConstructData): * API/JSCallbackConstructor.h: (JSC::JSCallbackConstructor::constructCallback): * API/JSCallbackFunction.h: (JSC::JSCallbackFunction::functionCallback): * API/ObjCCallbackFunction.h: (JSC::ObjCCallbackFunction::functionCallback): (JSC::ObjCCallbackFunction::constructCallback): * API/ObjCCallbackFunction.mm: (JSC::objCCallbackFunctionCallAsConstructor): (JSC::ObjCCallbackFunction::ObjCCallbackFunction): (JSC::ObjCCallbackFunction::create): (JSC::ObjCCallbackFunction::getConstructData): * API/tests/testapi.mm: 2013-10-08 Filip Pizlo FTL should be able to do simple OSR exits using llvm.webkit.stackmap https://bugs.webkit.org/show_bug.cgi?id=122538 Reviewed by Oliver Hunt. This gives the FTL the ability to OSR exit using the llvm.webkit.stackmap intrinsic. - The FTL compiles all OSR exit calls as calls to llvm.webkit.stackmap with a unique ID, passing a requested size that is big enough for own jump replacement. - After LLVM compilation, we parse the new LLVM stackmap section. - For all llvm.webkit.stackmaps that we used for OSR exits, we do a jumpReplacement, which targets exit thunks that we generate. - If an exit thunk fires, it causes JSC to compile an exit off-ramp that uses a combination of the JSC-internal OSR exit accounting (FTL::ExitValue and friends) and LLVM stackmap's accounting of where data actually ended up (register, indirect, constant) to reconstruct bytecode state. This still has shortcomings; for example it cannot handle XMM or YMM registers. Handling YMM registers will require adding some basic YMM support to our assemblers - really we just need the ability to move a YMM's value into a GPR. This patch preserves all of the old, intrinsic-less, FTL OSR exit support. Hence it manages to pass all existing FTL tests even despite its incompleteness. I think that's the right way to go since this is already a big patch, and anyway it would be great to keep the intrinsic-less FTL OSR exit support so long as the LLVM side of this hasn't landed. * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::firstRegister): (JSC::AbstractMacroAssembler::lastRegister): * assembler/MacroAssembler.h: (JSC::MacroAssembler::isStackRelated): (JSC::MacroAssembler::firstRealRegister): (JSC::MacroAssembler::nextRegister): (JSC::MacroAssembler::secondRealRegister): * assembler/MacroAssemblerX86Common.h: * assembler/X86Assembler.h: (JSC::X86Assembler::firstRegister): (JSC::X86Assembler::lastRegister): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * ftl/FTLCArgumentGetter.cpp: (JSC::FTL::CArgumentGetter::loadNextAndBox): * ftl/FTLCArgumentGetter.h: (JSC::FTL::CArgumentGetter::loadNextDoubleIntoGPR): * ftl/FTLCompile.cpp: (JSC::FTL::mmAllocateCodeSection): (JSC::FTL::mmAllocateDataSection): (JSC::FTL::dumpDataSection): (JSC::FTL::fixFunctionBasedOnStackMaps): (JSC::FTL::compile): * ftl/FTLExitThunkGenerator.cpp: (JSC::FTL::ExitThunkGenerator::emitThunk): (JSC::FTL::ExitThunkGenerator::emitThunks): * ftl/FTLExitThunkGenerator.h: * ftl/FTLExitValue.h: (JSC::FTL::ExitValue::isInJSStackSomehow): (JSC::FTL::ExitValue::valueFormat): * ftl/FTLFail.cpp: (JSC::FTL::fail): * ftl/FTLIntrinsicRepository.h: * ftl/FTLJITCode.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::generateExitThunks): (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall): (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks): * ftl/FTLOSRExit.h: * ftl/FTLOSRExitCompilationInfo.h: (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStubWithOSRExitStackmap): (JSC::FTL::compileStubWithoutOSRExitStackmap): (JSC::FTL::compileFTLOSRExit): * ftl/FTLSaveRestore.cpp: Added. (JSC::FTL::bytesForGPRs): (JSC::FTL::requiredScratchMemorySizeInBytes): (JSC::FTL::offsetOfGPR): (JSC::FTL::saveAllRegisters): (JSC::FTL::restoreAllRegisters): * ftl/FTLSaveRestore.h: Added. * ftl/FTLStackMaps.cpp: Added. (JSC::FTL::readObject): (JSC::FTL::StackMaps::Constant::parse): (JSC::FTL::StackMaps::Constant::dump): (JSC::FTL::StackMaps::Location::parse): (JSC::FTL::StackMaps::Location::dump): (JSC::FTL::StackMaps::Location::involvesGPR): (JSC::FTL::StackMaps::Location::isGPR): (JSC::FTL::StackMaps::Location::gpr): (JSC::FTL::StackMaps::Location::restoreInto): (JSC::FTL::StackMaps::Record::parse): (JSC::FTL::StackMaps::Record::dump): (JSC::FTL::StackMaps::parse): (JSC::FTL::StackMaps::dump): (JSC::FTL::StackMaps::dumpMultiline): (JSC::FTL::StackMaps::getRecordMap): (WTF::printInternal): * ftl/FTLStackMaps.h: Added. * ftl/FTLState.h: * ftl/FTLThunks.cpp: (JSC::FTL::osrExitGenerationThunkGenerator): * ftl/FTLValueFormat.cpp: (JSC::FTL::reboxAccordingToFormat): * ftl/FTLValueFormat.h: * runtime/DataView.cpp: (JSC::DataView::create): * runtime/DataView.h: (JSC::DataView::read): * runtime/Options.h: 2013-10-09 Filip Pizlo Minor clean-ups in the JSC Xcode project. Rubber stamped by Mark Rowe. - When we copy the jsc binary into the framework, $(BUILT_PRODUCTS_DIR)/JavaScriptCore.framework/Resources/jsc is the *output* file not the input file. The input file is $(BUILT_PRODUCTS_DIR)/jsc. - Correct capitalization of "JavaScriptcore.framework" in a comment in a shell script in the project. * JavaScriptCore.xcodeproj/project.pbxproj: 2013-10-09 Julien Brianceau [arm] Inverted src and dest FP registers in DFG speculative JIT when using hardfp. https://bugs.webkit.org/show_bug.cgi?id=122555 Reviewed by Michael Saboff. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult): (JSC::DFG::SpeculativeJIT::appendCallSetResult): 2013-10-08 Michael Saboff Transition call and construct JITStubs to CCallHelper functions https://bugs.webkit.org/show_bug.cgi?id=122453 Reviewed by Geoffrey Garen. Transitioned cti_op_call_eval to operationCallEval. Migrated baseline JIT to use the same call thunks as the DFG. Eliminated all of the "oldStyle" thunks and related functions. * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::unlink): * jit/JIT.cpp: (JSC::JIT::linkFor): (JSC::JIT::linkSlowCall): * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::compileCallEval): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::privateCompileClosureCall): * jit/JITCall32_64.cpp: (JSC::JIT::compileCallEval): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::privateCompileClosureCall): * jit/JITInlines.h: (JSC::JIT::callOperationWithCallFrameRollbackOnException): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITStubs.cpp: * jit/JITStubs.h: * jit/ThunkGenerators.cpp: * jit/ThunkGenerators.h: 2013-10-09 Julien Brianceau [sh4] Fix lots of unused parameter warnings. https://bugs.webkit.org/show_bug.cgi?id=122545 Reviewed by Csaba Osztrogonác. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::revertJumpReplacementToPatchableBranchPtrWithPatch): * assembler/SH4Assembler.h: (JSC::SH4Assembler::andlImm8r): (JSC::SH4Assembler::orlImm8r): (JSC::SH4Assembler::xorlImm8r): (JSC::SH4Assembler::cmpEqImmR0): (JSC::SH4Assembler::testlImm8r): (JSC::SH4Assembler::movwPCReg): (JSC::SH4Assembler::movwMemReg): (JSC::SH4Assembler::movbMemReg): (JSC::SH4Assembler::printInstr): (JSC::SH4Assembler::printBlockInstr): 2013-10-09 Julien Brianceau [sh4] Add sh4 support when building with CMake. https://bugs.webkit.org/show_bug.cgi?id=122542 Reviewed by Csaba Osztrogonác. * CMakeLists.txt: 2013-10-08 Oliver Hunt Convert for-of iteration to in-band signalling so we can trivially avoid unnecessary object allocation https://bugs.webkit.org/show_bug.cgi?id=122532 Reviewed by Michael Saboff. Switch for-of enumeration to use in band signalling to determine the end of iteration. This allows us to trivially remove an otherwise unnecessary object allocation, and paves the way for optimised thunks in future. We can re-add explicit .next() functions in future that would marshall the true iteration functions, but for now we'll ignore them. This results in a huge improvement in the performance of for-of (in the order of 2x) but there's still a long way to go in order to get the performance to a satisfactory level. * bytecompiler/NodesCodegen.cpp: (JSC::ForOfNode::emitBytecode): * runtime/ArrayIteratorPrototype.cpp: (JSC::ArrayIteratorPrototype::finishCreation): (JSC::createIteratorResult): * runtime/CommonIdentifiers.cpp: (JSC::CommonIdentifiers::CommonIdentifiers): * runtime/CommonIdentifiers.h: * runtime/Identifier.cpp: (JSC::Identifier::addSlowCase): * runtime/JSObject.h: (JSC::JSFinalObject::create): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2013-10-08 Alex Christensen Fixed compile errors while compiling without the JIT enabled. https://bugs.webkit.org/show_bug.cgi?id=122530 Reviewed by Brent Fulgham. * jit/JITOperations.cpp: Protected with #if ENABLE(JIT) like the rest of the JIT source. 2013-10-07 Mark Hahnenberg JSManagedValue should be able to store non-object JSValues https://bugs.webkit.org/show_bug.cgi?id=122351 Reviewed by Oliver Hunt. We decided not to support this because we thought it didn't make sense to have a "weak" JSValue that wasn't an object. Our general thought process was if you have a JSObject-ObjC object pair (i.e. an Obj-C object that you exported to JavaScript-land), it makes more sense to store a non-object JSValue on the JavaScript-land version of the object rather than as an ivar in the Objective-C object. In retrospect, this may not have been a good decision at least w.r.t. consistency in client code. If you're storing a bag of JSValues off an Obj-C object, you'd like to store all of them either in ObjC-land or JavaScript-land, but doing some in one and some in the other doesn't sound too good. Also, what if the object you want to hang these values off of doesn't have a corresponding object in JavaScript- land in which to store them? The solution is to fix JSManagedValue to be able to reference non-object JSValues. Right now, all JSManagedValues contain a Weak. We'll change this so that they can contain either a non-cell JSValue or a JSObject*, along with a weak reference to the JSGlobalObject for reconstructing a JSValue later on. * API/JSManagedValue.mm: (PrimitiveOrObject::PrimitiveOrObject): (PrimitiveOrObject::~PrimitiveOrObject): (PrimitiveOrObject::clear): (PrimitiveOrObject::isClear): (PrimitiveOrObject::isSet): (PrimitiveOrObject::isPrimitive): (PrimitiveOrObject::isObject): (PrimitiveOrObject::setPrimitive): (PrimitiveOrObject::setObject): (PrimitiveOrObject::object): (PrimitiveOrObject::primitive): (-[JSManagedValue initWithValue:]): (-[JSManagedValue value]): (-[JSManagedValue disconnectValue]): 2013-10-08 Robert Plociennik JavaScriptCore fails to build https://bugs.webkit.org/show_bug.cgi?id=122440 Reviewed by Darin Adler. Compilation fails in debug due to 'comparison of unsigned expression >= 0 is always true'. * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::positionForCallFrame): Removed the offending ASSERTS. 2013-10-07 Andreas Kling Pass VM instead of ExecState to JSNotAnObject constructor. Reviewed by Sam Weinig. JSNotAnObject was only using the ExecState to find the VM. 2013-10-07 Filip Pizlo FTL memory allocator should be able to allocate data sections in non-executable memory https://bugs.webkit.org/show_bug.cgi?id=116189 Reviewed by Sam Weinig. Use a RefCountedArray for data sections. This works out great because RefCountedArray<> knows its own size and because the reference counting makes passing it around very easy (you don't have to stress out about ownership). * ftl/FTLCompile.cpp: (JSC::FTL::mmAllocateDataSection): (JSC::FTL::compile): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::addDataSection): * ftl/FTLJITCode.h: (JSC::FTL::JITCode::dataSections): 2013-10-07 Roger Fong Modify JavascriptCore makefile for x64 build. https://bugs.webkit.org/show_bug.cgi?id=122467. . Reviewed by Brent Fulgham. * JavaScriptCore.vcxproj/JavaScriptCore.make: 2013-10-07 Nadav Rotem FTL: Optimize IsString(@2) -> JSConst(true) + Phantom() https://bugs.webkit.org/show_bug.cgi?id=122363 Reviewed by Filip Pizlo. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): 2013-10-04 Michael Saboff Transition stack check JITStubs to CCallHelper functions https://bugs.webkit.org/show_bug.cgi?id=122289 Reviewed by Filip Pizlo. Replaced jit stubs cti_stack_check, cti_op_call_arityCheck and cti_op_construct_arityCheck with jit operations operationStackCheck, operationCallArityCheck & operationConstructArityCheck. Added new callOperationWithCallFrameRollbackOnException() in baseline and DFG JITs to call these new functions. Added code to unwind one frame in JIT::privateCompileExceptionHandlers() and JITCompiler::compileExceptionHandlers() for these cases that need to throw exceptions in their caller frame when the stack is exhausted. * assembler/MacroAssembler.h: (JSC::MacroAssembler::andPtr): Added to handle masking a pointer with a literal. * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::and64): Added to handle masking a pointer with a literal. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileExceptionHandlers): (JSC::DFG::JITCompiler::compileFunction): (JSC::DFG::JITCompiler::linkFunction): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperationWithCallFrameRollbackOnException): (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck): (JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnException): (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult): (JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnExceptionSetResult): * ftl/FTLLink.cpp: (JSC::FTL::link): * interpreter/CallFrame.h: (JSC::ExecState::hostCallFrameFlag): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::jitAssertIsNull): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::jitAssertIsNull): * jit/JIT.cpp: (JSC::JIT::privateCompile): (JSC::JIT::privateCompileExceptionHandlers): * jit/JIT.h: (JSC::JIT::exceptionCheckWithCallFrameRollback): * jit/JITInlines.h: (JSC::JIT::appendCallWithCallFrameRollbackOnException): (JSC::JIT::callOperationWithCallFrameRollbackOnException): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITStubs.cpp: * jit/JITStubs.h: 2013-10-07 Filip Pizlo ASSERTION FAILED: isUInt32() in jsc-layout-tests.yaml/js/script-tests/dfg-uint32-to-number-in-middle-of-copy-propagation.js.layout-dfg-eager-no-cjit https://bugs.webkit.org/show_bug.cgi?id=122419 Reviewed by Oliver Hunt. AI was using JSValue::asUInt32() incorrectly. That method presumes that the input is both a int32 and a uint32 (it's in the range [0, 2^31)). The UInt32ToNumber node is instead dealing with an input that is always represented as a int32 but that has the meaning of a uint32 - so AI should use JSValue::asInt32() and then do the cast. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): 2013-10-07 Julien Brianceau [sh4] Jump over maxJumpReplacementSize in revertJumpToMove. https://bugs.webkit.org/show_bug.cgi?id=120007 Reviewed by Oliver Hunt. Jump over maxJumpReplacementSize in revertJumpToMove, even if there is no constant value within the area. This patch fixes debug ASSERTs failures for sh4 architecture. * assembler/SH4Assembler.h: (JSC::SH4Assembler::revertJumpToMove): 2013-10-06 Anders Carlsson Add OVERRIDE and virtual where appropriate https://bugs.webkit.org/show_bug.cgi?id=122439 Reviewed by Antti Koivisto. * API/JSAPIWrapperObject.mm: * API/JSCallbackObject.h: (JSC::JSCallbackObjectData::~JSCallbackObjectData): * API/JSManagedValue.mm: * API/JSScriptRef.cpp: (OpaqueJSScript::~OpaqueJSScript): * bytecode/CodeBlock.h: * bytecode/StructureStubClearingWatchpoint.h: * dfg/DFGArrayifySlowPathGenerator.h: * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: * dfg/DFGFailedFinalizer.h: * dfg/DFGJITCode.h: * dfg/DFGJITFinalizer.h: * dfg/DFGSaneStringGetByValSlowPathGenerator.h: * dfg/DFGSlowPathGenerator.h: * dfg/DFGSpeculativeJIT64.cpp: * heap/Heap.h: * heap/IncrementalSweeper.h: * heap/SuperRegion.h: * jit/ClosureCallStubRoutine.h: * jit/ExecutableAllocatorFixedVMPool.cpp: * jit/GCAwareJITStubRoutine.h: * jit/JITCode.h: * jit/JITStubs.cpp: * jit/JITToDFGDeferredCompilationCallback.h: * jit/JumpReplacementWatchpoint.h: * parser/Nodes.h: * runtime/DataView.h: * runtime/GCActivityCallback.h: * runtime/GenericTypedArrayView.h: * runtime/RegExpCache.h: * runtime/SimpleTypedArrayController.h: * runtime/WeakMapData.h: 2013-10-07 Filip Pizlo Trap 5 (most likely int $3) in jsc-layout-tests.yaml/js/script-tests/integer-division-neg2tothe32-by-neg1.js.layout-dfg-eager-no-cjit https://bugs.webkit.org/show_bug.cgi?id=122420 Reviewed by Michael Saboff. For the (-2^31/-1)|0 case, we were returning the left operand (i.e. -2^31) but we were failing to account for the possibility that this operand has high-bit garbage and int32Result() requires that the high bits are zero. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithDiv): 2013-10-06 Filip Pizlo ASSERTION FAILED: bitwise_cast*>(callFrame) == m_registers in jsc-layout-tests.yaml/js/script-tests/dfg-inline-arguments-capture-throw-exception.js.layout-dfg-eager-no-cjit https://bugs.webkit.org/show_bug.cgi?id=122418 Reviewed by Oliver Hunt. This is pretty awesome. With stack compression, Arguments created in the DFG will point their m_registers pointers into a different slab of stack than they would have in byte code. Hence OSR exit must repoint any Arguments objects' m_registers pointers. It previously neglected to do so. This patch fixes that. Fixing this unveiled another bug: the stack reversal broke the reification of inlined phantom arguments. * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * runtime/Arguments.h: (JSC::Arguments::offsetOfNumArguments): (JSC::Arguments::offsetOfRegisters): (JSC::Arguments::offsetOfSlowArgumentData): (JSC::Arguments::offsetOfOverrodeLength): 2013-10-06 Filip Pizlo Unified test infrastructure via the jsc shell https://bugs.webkit.org/show_bug.cgi?id=120696 Reviewed by Oliver Hunt. Add a mozilla-tests.yaml list. This is autogenerated by create-mozilla-js-test-list. I think it's better to leave this checked in; we may even just edit it directly in the future. Also generating it is not cheap. Fix some low-hanging fruit bugs that I caught by introducing more test coverage. - We were not emitting labels for CFA-unreachable blocks, which caused link errors. It's possible for a CFA-unreachable block to be jumped to, if the thing that causes it to be unreachable is a speculation in a Branch or peephole compare. - The register allocation assertions didn't handle peephole branches correctly. Since the peephole branch handling returns early from compile(), the clearBlahbittyBlah() method wasn't being called. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * tests/mozilla/mozilla-tests.yaml: Added. 2013-10-05 Andreas Kling Pass VM instead of ExecState to StringObject constructor. Reviewed by Sam Weinig. StringObject() only uses the ExecState to find the VM. 2013-10-05 Filip Pizlo Compress DFG stack layout https://bugs.webkit.org/show_bug.cgi?id=122024 Reviewed by Oliver Hunt. The DFG needs to be able to store things at a known offset from frame pointer so that the runtime can read those things. Prior to this patch, the DFG would use the exact offsets that the bytecode asked for, even in the case of inlining, where it would use the callsite stack offset to shift all of the inlined function's variables over just as they would have been if a bytecode interpreter had really made the call. But this won't work once WebKit-LLVM integration is complete. LLVM has no notion of storing things at a fixed offset from the frame pointer. We could try to hack LLVM to do that, but it would seriously complicate LLVM's stack layout. But what we might be able to do is have LLVM tell us (via an addressof intrinsic and a side-channel) where some alloca landed relative to the frame pointer. Hence if the DFG can put all of its flushed variables in a contiguous range that can be expressed to LLVM as a struct that we alloca, then all of this can still work just fine. Previously the flushed variables didn't fit in a contiguous range, but this patch makes them contiguous by allowing the stack layout to be compressed. What this really means is that there is now a distinction between where the DFG saw a variable stored in bytecode and where it will actually store it in the resulting machine code. Henceforth when the DFG says "local" or "virtual register" it means the variable according to bytecode (with the stack offsetting for inlined code as before), but when it says "machine local" or "machine virtual register" it means the actual place where it will store things in the resulting machine code. All of the OSR exit, inlined arguments, captured variables, and various stack unwinding machine now knows about all of this. Note that the DFG's abstract interpretation still uses bytecode variables rather than machine variables. Same for CSE and abstract heaps. This makes sense since it means that we don't have to decide on machine variable allocation just to do those optimizations. The decision of what a local's machine location becomes is deferred to very late in compilation. We only need to assign machine locations to variables that must be stored to the stack. It's now mandatory to run some kind of "stack layout phase" that makes the decision and updates all data structures. So far the way that this is being used is just to compress the DFG stack layout, which is something that we should have done anyway, a long time ago. And the compression isn't even that good - the current StackLayoutPhase just identifies local indices that are unused in machine code and slides all other variables towards zero. This doesn't achieve particularly good compression but it is better than nothing. Note that this phase makes it seem like the bytecode-machine mapping is based on bytecode local indices; for example if bytecode local 4 is mapped to machine local 3 then it always will be. That's true for the current StackLayoutPhase but it _will not_ be true for all possible stack layout phases and it would be incorrect to assume that it should be true. This is why the current data structures have each VariableAccessData hold its own copy of the machine virtual register, and also have each InlineCallFrame report their own machine virtual registers for the various things. The DFG backend is likely to always use the dumb StackLayoutPhase since it is very cheap to run, but the FTL backend is likely to eventually get a better one, where we do some kind of constraint-based coloring: we institute constraints where some VariableAccessData's must have the same indices as some other ones, and also must be right next to some other ones; then we process all VariableAccessData's and attempt to assign them machine locals while preserving those constraints. This could lead to two VariableAccessDatas for the same bytecode local ending up with different machine locals. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::isCaptured): (JSC::CodeBlock::framePointerOffsetToGetActivationRegisters): (JSC::CodeBlock::machineSlowArguments): * bytecode/CodeBlock.h: (JSC::CodeBlock::hasSlowArguments): * bytecode/CodeOrigin.cpp: (JSC::CodeOrigin::dump): (JSC::InlineCallFrame::calleeForCallFrame): (JSC::InlineCallFrame::dumpInContext): * bytecode/CodeOrigin.h: (JSC::InlineCallFrame::InlineCallFrame): (JSC::InlineCallFrame::calleeConstant): * bytecode/Operands.h: (JSC::Operands::indexForOperand): * dfg/DFGBasicBlock.cpp: (JSC::DFG::BasicBlock::SSAData::SSAData): * dfg/DFGBasicBlock.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::ByteCodeParser): (JSC::DFG::ByteCodeParser::get): (JSC::DFG::ByteCodeParser::getLocal): (JSC::DFG::ByteCodeParser::flushDirect): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCommon.h: * dfg/DFGCommonData.h: (JSC::DFG::CommonData::CommonData): * dfg/DFGDesiredWriteBarriers.cpp: (JSC::DFG::DesiredWriteBarrier::trigger): * dfg/DFGDesiredWriteBarriers.h: * dfg/DFGFlushLivenessAnalysisPhase.cpp: (JSC::DFG::FlushLivenessAnalysisPhase::run): (JSC::DFG::FlushLivenessAnalysisPhase::process): (JSC::DFG::FlushLivenessAnalysisPhase::reportError): * dfg/DFGFlushedAt.cpp: Added. (JSC::DFG::FlushedAt::dump): (JSC::DFG::FlushedAt::dumpInContext): * dfg/DFGFlushedAt.h: Added. (JSC::DFG::FlushedAt::FlushedAt): (JSC::DFG::FlushedAt::operator!): (JSC::DFG::FlushedAt::format): (JSC::DFG::FlushedAt::virtualRegister): (JSC::DFG::FlushedAt::operator==): (JSC::DFG::FlushedAt::operator!=): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: (JSC::DFG::Graph::bytecodeRegisterForArgument): (JSC::DFG::Graph::argumentsRegisterFor): (JSC::DFG::Graph::machineArgumentsRegisterFor): (JSC::DFG::Graph::uncheckedArgumentsRegisterFor): (JSC::DFG::Graph::activationRegister): (JSC::DFG::Graph::uncheckedActivationRegister): (JSC::DFG::Graph::machineActivationRegister): (JSC::DFG::Graph::uncheckedMachineActivationRegister): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::noticeOSREntry): * dfg/DFGNode.h: (JSC::DFG::Node::convertToGetLocalUnlinked): (JSC::DFG::Node::convertToGetLocal): (JSC::DFG::Node::machineLocal): (JSC::DFG::Node::hasUnlinkedMachineLocal): (JSC::DFG::Node::setUnlinkedMachineLocal): (JSC::DFG::Node::unlinkedMachineLocal): (JSC::DFG::Node::hasInlineStartData): (JSC::DFG::Node::inlineStartData): * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSREntry.h: (JSC::DFG::OSREntryReshuffling::OSREntryReshuffling): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGScoreBoard.h: (JSC::DFG::ScoreBoard::ScoreBoard): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileInlineStart): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::createOSREntries): (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::calleeFrameOffset): (JSC::DFG::SpeculativeJIT::callFrameSlot): (JSC::DFG::SpeculativeJIT::argumentSlot): (JSC::DFG::SpeculativeJIT::callFrameTagSlot): (JSC::DFG::SpeculativeJIT::callFramePayloadSlot): (JSC::DFG::SpeculativeJIT::argumentTagSlot): (JSC::DFG::SpeculativeJIT::argumentPayloadSlot): (JSC::DFG::SpeculativeJIT::framePointerOffsetToGetActivationRegisters): (JSC::DFG::SpeculativeJIT::callOperation): (JSC::DFG::SpeculativeJIT::recordSetLocal): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStackLayoutPhase.cpp: Added. (JSC::DFG::StackLayoutPhase::StackLayoutPhase): (JSC::DFG::StackLayoutPhase::run): (JSC::DFG::performStackLayout): * dfg/DFGStackLayoutPhase.h: Added. * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validate): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::machineLocal): (JSC::DFG::VariableAccessData::flushedAt): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): * ftl/FTLExitValue.h: (JSC::FTL::ExitValue::inJSStack): (JSC::FTL::ExitValue::inJSStackAsInt32): (JSC::FTL::ExitValue::inJSStackAsInt52): (JSC::FTL::ExitValue::inJSStackAsDouble): (JSC::FTL::ExitValue::virtualRegister): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetArgument): (JSC::FTL::LowerDFGToLLVM::compileGetLocal): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock): (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLValueSource.cpp: (JSC::FTL::ValueSource::dump): * ftl/FTLValueSource.h: (JSC::FTL::ValueSource::ValueSource): (JSC::FTL::ValueSource::kind): (JSC::FTL::ValueSource::operator!): (JSC::FTL::ValueSource::node): (JSC::FTL::ValueSource::virtualRegister): * interpreter/Interpreter.cpp: (JSC::unwindCallFrame): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::readInlinedFrame): (JSC::StackVisitor::Frame::createArguments): (JSC::StackVisitor::Frame::existingArguments): * interpreter/StackVisitor.h: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::addressFor): (JSC::AssemblyHelpers::tagFor): (JSC::AssemblyHelpers::payloadFor): (JSC::AssemblyHelpers::offsetOfArgumentsIncludingThis): * runtime/Arguments.cpp: (JSC::Arguments::tearOff): * runtime/Arguments.h: (JSC::Arguments::allocateSlowArguments): (JSC::Arguments::tryDeleteArgument): (JSC::Arguments::isDeletedArgument): (JSC::Arguments::isArgument): (JSC::Arguments::argument): (JSC::Arguments::finishCreation): * runtime/JSActivation.h: (JSC::JSActivation::create): (JSC::JSActivation::JSActivation): * runtime/JSFunction.cpp: (JSC::RetrieveArgumentsFunctor::operator()): 2013-10-05 Anders Carlsson Remove createOwned https://bugs.webkit.org/show_bug.cgi?id=122388 Reviewed by Darin Adler. * profiler/ProfilerDatabase.cpp: (JSC::Profiler::Database::save): 2013-10-05 Darin Adler Cut down on use of String::number https://bugs.webkit.org/show_bug.cgi?id=122382 Reviewed by Anders Carlsson. * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::putByIndex): Use Identifier::from instead of calling String::number and creating an identifier from that. Can save creating and then destroying a string if an identifier already exists. * runtime/Arguments.cpp: (JSC::Arguments::getOwnPropertySlotByIndex): Ditto. (JSC::Arguments::getOwnPropertyNames): Ditto. (JSC::Arguments::putByIndex): Ditto. * runtime/JSGenericTypedArrayViewInlines.h: (JSC::::getOwnPropertyNames): Ditto. * runtime/StringObject.cpp: (JSC::StringObject::getOwnPropertyNames): Ditto. 2013-10-04 Mark Lam Change ScriptDebugServer to use DebuggerCallFrame instead of JavaScriptCallFrame. https://bugs.webkit.org/show_bug.cgi?id=121969. Reviewed by Geoffrey Garen. 1. Make JavaScriptCallFrame a thin shell around the DebuggerCallFrame. DebuggerCallFrame now tracks whether it is valid instead of needing JavaScriptCallFrame do it. 2. ScriptDebugServer now only instantiates an DebuggerCallFrame when needed just before it pauses and calls back to its client, and then invalidates it immediately when the callback returns. Every subsequent callback to the client will use a new instance of the DebuggerCallFrame. 3. Similarly, ScriptDebugServer now only creates a JavaScriptCallFrame when it "pauses". 4. DebuggerCallFrame only creates its caller DebuggerCallFrame when it is needed i.e. when the client calls callerFrame(). Similarly, JavaScriptCallFrame only creates its caller when it's requested. 5. DebuggerCallFrame's line() and column() now returns a base-zero int. 6. WebScriptDebugDelegate now only caches the functionName of the frame instead of the entire DebuggerCallFrame because that is all that is needed. 7. Also removed evaluateInGlobalCallFrame() which is not used anywhere. * debugger/Debugger.cpp: * debugger/Debugger.h: * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::DebuggerCallFrame): (JSC::DebuggerCallFrame::callerFrame): (JSC::DebuggerCallFrame::dynamicGlobalObject): (JSC::DebuggerCallFrame::sourceId): (JSC::DebuggerCallFrame::functionName): (JSC::DebuggerCallFrame::scope): (JSC::DebuggerCallFrame::type): (JSC::DebuggerCallFrame::thisValue): (JSC::DebuggerCallFrame::evaluate): (JSC::DebuggerCallFrame::evaluateWithCallFrame): (JSC::DebuggerCallFrame::invalidate): (JSC::DebuggerCallFrame::positionForCallFrame): (JSC::DebuggerCallFrame::sourceIdForCallFrame): (JSC::DebuggerCallFrame::thisValueForCallFrame): * debugger/DebuggerCallFrame.h: (JSC::DebuggerCallFrame::create): (JSC::DebuggerCallFrame::exec): (JSC::DebuggerCallFrame::line): (JSC::DebuggerCallFrame::column): (JSC::DebuggerCallFrame::position): (JSC::DebuggerCallFrame::isValid): * interpreter/StackVisitor.cpp: 2013-10-04 Brent Fulgham Silence compiler warning when building 64-bit (on Windows) Reviewed by Geoffrey Garen. * jit/JSInterfaceJIT.h: Add a static cast for assignment. 2013-10-04 Nadav Rotem FTL: Add support for ValueToInt32(bool(x)) https://bugs.webkit.org/show_bug.cgi?id=122346 Reviewed by Geoffrey Garen. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileValueToInt32): 2013-10-04 Oliver Hunt Build fix. * runtime/JSArrayIterator.cpp: 2013-10-04 Oliver Hunt Support for-of syntax https://bugs.webkit.org/show_bug.cgi?id=122339 Reviewed by Geoffrey Garen. Add support for for-of syntax to JSC. As part of doing this I had to make us support unique empty strings as identifiers. In a follow on patch i'm going to remove the distinction entirely as it's purely a complicating separation. Otherwise the logic here is fairly self-explanatory. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::addConstant): (JSC::BytecodeGenerator::emitCall): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::CallArguments::CallArguments): (JSC::ForOfNode::emitBytecode): * jit/JITOperations.cpp: * parser/ASTBuilder.h: (JSC::ASTBuilder::createForOfLoop): * parser/NodeConstructors.h: (JSC::EnumerationNode::EnumerationNode): (JSC::ForInNode::ForInNode): (JSC::ForOfNode::ForOfNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::::parseVarDeclarationList): (JSC::::parseForStatement): * parser/Parser.h: (JSC::Parser::isofToken): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createForOfLoop): * runtime/ArrayIteratorPrototype.cpp: (JSC::ArrayIteratorPrototype::finishCreation): (JSC::arrayIteratorPrototypeIterate): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::create): (JSC::ArrayPrototype::finishCreation): * runtime/ArrayPrototype.h: * runtime/CommonIdentifiers.cpp: (JSC::CommonIdentifiers::CommonIdentifiers): * runtime/CommonIdentifiers.h: * runtime/Identifier.h: (JSC::Identifier::from): * runtime/JSCJSValue.cpp: (JSC::JSValue::dumpInContext): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): * runtime/JSObject.cpp: (JSC::JSObject::putDirectNativeFunction): * runtime/PrivateName.h: (JSC::PrivateName::PrivateName): * runtime/PropertyName.h: (JSC::PropertyName::PropertyName): 2013-10-04 Michael Saboff FTL::OSRExit::convertToForward() shouldn't misuse Operands<>::operator[] https://bugs.webkit.org/show_bug.cgi?id=122336 Reviewed by Geoffrey Garen. Changed code in change set r156900 to use the operand() accessor instead of operator[]. * ftl/FTLOSRExit.cpp: (JSC::FTL::OSRExit::convertToForward): 2013-10-04 Michael Saboff FTL: Crash in OSRExit::convertToForward() using VirtualRegister.offset() as array index https://bugs.webkit.org/show_bug.cgi?id=122332 Reviewed by Oliver Hunt. Changed the uses of .offset(), which returns a negative number for locals, to be toLocal() which returns a local's ordinal number. * ftl/FTLOSRExit.cpp: (JSC::FTL::OSRExit::convertToForward): 2013-10-04 Michael Saboff Add callOperation to Baseline JIT https://bugs.webkit.org/show_bug.cgi?id=122306 Reviewed by Geoffrey Garen. Created baseline JIT compatible versions for a few flavors of callOperation(). Migrated cti_op_new_regexp() and its caller to callOperation(operationNewRegexp()). * dfg/DFGOperations.cpp: Moved operationNewRegexp() to JITOperations * dfg/DFGOperations.h: * jit/JIT.h: (JSC::JIT::appendCall): * jit/JITInlines.h: (JSC::JIT::appendCallWithExceptionCheck): (JSC::JIT::appendCallWithExceptionCheckSetJSValueResult): (JSC::JIT::callOperation): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_new_regexp): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITStubs.cpp: * jit/JITStubs.h: * jit/JSInterfaceJIT.h: 2013-10-03 Mark Rowe REGRESSION (r156811): WebCore rebuilds from scratch when doing an incremental build The change in r156811 resulted in several public headers in the JavaScriptCore framework having their modification date touched on every build, even if their contents had not changed. This resulted in a large portion of WebCore needing to rebuilt after an incremental build of JavaScriptCore. Reviewed by Dan Bernstein. * JavaScriptCore.xcodeproj/project.pbxproj: Have unifdef generate its output to a temporary file. If its exit status indicates that the content did not change, remove the temporary file. If the content changed, moved the temporary file over the destination. 2013-10-03 Brent Fulgham [Win] Unreviewed gardening. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Clean up the paths for various files added outside of Visual Studio. They are all displayed in the root of the project, rather than the proper sub-folder. 2013-10-03 Brent Fulgham [Win] Update solutions and projects to support 64-bit builds. https://bugs.webkit.org/show_bug.cgi?id=122225 Reviewed by Anders Carlsson. Revise ordering of CPU(X86) and CPU(X86_64) tests, because MSVC always defines both when targeting a 64-bit build. * JavaScriptCore.vcxproj/JavaScriptCore.submit.sln: Add an x64 target for 64-bit builds. 2013-10-03 Michael Saboff Eliminate unused JITStub function declarations https://bugs.webkit.org/show_bug.cgi?id=122288 Reviewed by Geoffrey Garen. Removed unused JITStub declarations. * jit/JITStubs.h: 2013-10-03 Sergio Correia [EFL] [DEBUG] JavaScriptCore fails to build https://bugs.webkit.org/show_bug.cgi?id=122267 Reviewed by Michael Saboff. Build fails due to an expression containing comparison between signed and unsigned integer. * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): Add cast to avoid signed vs. unsigned comparison warning. 2013-10-03 Nadav Rotem DFG: ConstProp the pattern ValueToInt32(Bool(x)) -> Int32(x) https://bugs.webkit.org/show_bug.cgi?id=122263 Reviewed by Geoffrey Garen. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): 2013-10-02 Dan Bernstein REGRESSION (r156811): Objective-C JavaScriptCore API test failing on Mountain Lion bots https://bugs.webkit.org/show_bug.cgi?id=122260 Reviewed by Mark Rowe. For the API to work, the tests need to be compiled with a newer version of the LLVM compiler. Until the bots are updated to that version, disable the tests on 10.8. * API/tests/testapi.mm: 2013-10-02 Mark Lam Make LLINT exception stack unwinding consistent with the JIT. https://bugs.webkit.org/show_bug.cgi?id=122255. Reviewed by Filip Pizlo. Previously, the CommonSlowPaths code is expected to behave in an inconsistent way in terms of whether to unwind the stack when handling exceptions or not. For the LLINT, the slow path should unwind the stack before returning. For the JIT, the slow path should not unwind the stack. This can result in the stack being unwound twice when the exception being handled is a TerminationException. This patch fixes the LLINT's expectation so that it expects the same slow path behavior as the JIT does. * llint/LLIntExceptions.cpp: (JSC::LLInt::returnToThrow): (JSC::LLInt::callToThrow): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPathsExceptions.cpp: (JSC::CommonSlowPaths::interpreterThrowInCaller): 2013-10-02 Filip Pizlo The DFG should use always DFG::Graph methods for determining where special registers are https://bugs.webkit.org/show_bug.cgi?id=122248 Reviewed by Michael Saboff. This makes it possible to have the DFG use different registers than the other engines for things like activation and arguments. * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::setLocalStoreElimination): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGGraph.h: (JSC::DFG::Graph::activationRegister): (JSC::DFG::Graph::uncheckedActivationRegister): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::baselineArgumentsRegisterFor): 2013-10-02 Dan Bernstein The Objective-C API should be available in 10.8 builds https://bugs.webkit.org/show_bug.cgi?id=122245 Reviewed by Mark Rowe. Enabled the Objective-C API when building on OS X 10.8 with the modern Objective-C runtime, but kept the availability attributes in API headers for 10.9 and later as they were. * API/JSBase.h: When JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 is defined, made JSC_OBJC_API_ENABLED true on 10.8 and above. * API/JSContext.h: When JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 is defined, marked the class as available on all OS X versions. * API/JSManagedValue.h: Ditto. * API/JSValue.h: Ditto. * API/JSVirtualMachine.h: Ditto. * Configurations/Base.xcconfig: Added JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 to GCC_PREPROCESSOR_DEFINITIONS. * JavaScriptCore.xcodeproj/project.pbxproj: Added a script build phase to unifdef the above header files with JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 either defined or not based on the OS X version we are targeting. 2013-10-02 Michael Saboff Make Baseline JIT exception handling work like the DFG JIT https://bugs.webkit.org/show_bug.cgi?id=122244 Reviewed by Filip Pizlo. Added a jump list (m_exceptionChecks) to JIT as a common place for exception processing within generated code. Added exceptionCheck() helpers that check for an exception which add a branch to the list. * jit/JIT.cpp: (JSC::JIT::privateCompile): (JSC::JIT::privateCompileExceptionHandlers): * jit/JIT.h: (JSC::JIT::exceptionCheck): 2013-10-02 Oliver Hunt Fix MSVC build * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: 2013-10-02 Geoffrey Garen Optimized VM access from C++ code https://bugs.webkit.org/show_bug.cgi?id=122241 Reviewed by Filip Pizlo. * runtime/JSScope.h: (JSC::JSScope::vm): Use MarkedBlock instead of Heap, since both have a pointer to the VM, and Heap is one extra load. 2013-10-02 Michael Saboff The LLInt should not use JITStackFrame https://bugs.webkit.org/show_bug.cgi?id=122231 Reviewed by Filip Pizlo. Replaced uses of JITStackFrame::vm with code to either access the vm via the CodeBlock from known JavaScript call frames or via the JSScope* for host call frames. This eliminates all uses of JITStackFrame from the LLInt. * heap/MarkedBlock.h: Made LLIntOffsetsExtractor a friend to access member offsets. * heap/WeakSet.h: Made LLIntOffsetsExtractor a friend to access member offsets. * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): Added an ASSERT for the newly added MarkedBlockMask * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2013-10-01 Oliver Hunt Implement Array key, value and entries iterators https://bugs.webkit.org/show_bug.cgi?id=122195 Reviewed by Filip Pizlo. Add implementation of ES6 Array iterators for keys(), values() and entries() Fairly self explanatory as we just need a simple implementation so that we can implement and test other features. * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/ArrayIteratorConstructor.cpp: Added. (JSC::ArrayIteratorConstructor::finishCreation): * runtime/ArrayIteratorConstructor.h: Added. (JSC::ArrayIteratorConstructor::create): (JSC::ArrayIteratorConstructor::createStructure): (JSC::ArrayIteratorConstructor::ArrayIteratorConstructor): * runtime/ArrayIteratorPrototype.cpp: Added. (JSC::ArrayIteratorPrototype::finishCreation): (JSC::createIteratorResult): (JSC::arrayIteratorPrototypeNext): * runtime/ArrayIteratorPrototype.h: Added. (JSC::ArrayIteratorPrototype::create): (JSC::ArrayIteratorPrototype::createStructure): (JSC::ArrayIteratorPrototype::ArrayIteratorPrototype): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncValues): (JSC::arrayProtoFuncEntries): (JSC::arrayProtoFuncKeys): * runtime/CommonIdentifiers.h: * runtime/Identifier.h: (JSC::Identifier::createEmptyUnique): * runtime/JSArrayIterator.cpp: Added. (JSC::JSArrayIterator::finishCreation): * runtime/JSArrayIterator.h: Added. (JSC::JSArrayIterator::createStructure): (JSC::JSArrayIterator::create): (JSC::JSArrayIterator::iterationKind): (JSC::JSArrayIterator::iteratedObject): (JSC::JSArrayIterator::nextIndex): (JSC::JSArrayIterator::setNextIndex): (JSC::JSArrayIterator::finish): (JSC::JSArrayIterator::JSArrayIterator): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::iteratorResultStructure): 2013-10-02 Mark Hahnenberg get_callee and to_this aren't properly cleared during finalizeUnconditionally https://bugs.webkit.org/show_bug.cgi?id=122224 Reviewed by Geoffrey Garen. Even though there is code to clear unmarked inline cache objects in finalizeUnconditionally, it will never run because get_callee and to_this weren't added to the proper Vector in the UnlinkedCodeBlock that is iterated during finalizeUnconditionally. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitCreateThis): 2013-09-25 Oliver Hunt Implement prefixed-destructuring assignment https://bugs.webkit.org/show_bug.cgi?id=121930 Reviewed by Mark Hahnenberg. Relanding with fix after rollout - it helps to not completely destroy optimisations for no reason. 2013-10-02 Nadav Rotem FTL: Refactor compileArithDiv and compileArithMod into one function. https://bugs.webkit.org/show_bug.cgi?id=122205 Reviewed by Filip Pizlo. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileAddSub): (JSC::FTL::LowerDFGToLLVM::compileArithDivMod): 2013-10-02 Anders Carlsson Get rid of Qt code from JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=122223 Reviewed by Oliver Hunt. * API/JSStringRefQt.cpp: Removed. * API/JSStringRefQt.h: Removed. * API/OpaqueJSString.h: * DerivedSources.pri: Removed. * JavaScriptCore.pri: Removed. * JavaScriptCore.pro: Removed. * LLIntOffsetsExtractor.pro: Removed. * Target.pri: Removed. * assembler/AbstractMacroAssembler.h: * assembler/MacroAssembler.h: (JSC::MacroAssembler::urshift32): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::shouldBlindForSpecificArch): * assembler/MacroAssemblerX86Common.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithSub): * heap/HeapTimer.cpp: (JSC::HeapTimer::timerEvent): * heap/HeapTimer.h: * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::scheduleTimer): * heap/IncrementalSweeper.h: * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitSub32Constant): * jsc.cpp: (main): * jsc.pro: Removed. * runtime/DateConstructor.cpp: * runtime/GCActivityCallback.cpp: (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): (JSC::DefaultGCActivityCallback::cancelTimer): * runtime/GCActivityCallback.h: * testRegExp.cpp: (main): * yarr/yarr.pri: Removed. 2013-10-01 Filip Pizlo FTL should use the new version of LLVM MCJIT memory manager APIs that take a SectionName https://bugs.webkit.org/show_bug.cgi?id=122193 Reviewed by Geoffrey Garen. Update our usage of the LLVM C API since the API is about to change. * ftl/FTLCompile.cpp: (JSC::FTL::mmAllocateCodeSection): (JSC::FTL::mmAllocateDataSection): 2013-10-01 Filip Pizlo REGRESSION(156464): 50% regression on SunSpider/string-fasta https://bugs.webkit.org/show_bug.cgi?id=122202 Unreviewed, roll out r156464. This is a progression on string-fasta, since it fixes the regression. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedFunctionExecutable::paramString): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitExpressionInfo): * bytecompiler/NodesCodegen.cpp: (JSC::ForInNode::emitBytecode): (JSC::FuncExprNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createFormalParameterList): (JSC::ASTBuilder::createForInLoop): (JSC::ASTBuilder::addVar): * parser/NodeConstructors.h: (JSC::CommaNode::CommaNode): (JSC::ParameterNode::ParameterNode): (JSC::ForInNode::ForInNode): * parser/Nodes.cpp: (JSC::FunctionParameters::create): (JSC::FunctionParameters::FunctionParameters): (JSC::FunctionParameters::~FunctionParameters): * parser/Nodes.h: (JSC::ExpressionNode::isDotAccessorNode): (JSC::CommaNode::append): (JSC::ParameterNode::ident): (JSC::FunctionParameters::at): (JSC::FunctionParameters::identifiers): * parser/Parser.cpp: (JSC::::Parser): (JSC::::parseVarDeclaration): (JSC::::parseVarDeclarationList): (JSC::::parseForStatement): (JSC::::parseFormalParameters): (JSC::::parseAssignmentExpression): * parser/Parser.h: (JSC::Scope::declareParameter): (JSC::Parser::declareParameter): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createFormalParameterList): (JSC::SyntaxChecker::createForInLoop): (JSC::SyntaxChecker::operatorStackPop): * runtime/JSONObject.cpp: * runtime/JSONObject.h: 2013-10-01 Filip Pizlo Variable event stream (for DFG OSR exit) should be explicit about where on the stack a SetLocal put a value https://bugs.webkit.org/show_bug.cgi?id=122178 Reviewed by Geoffrey Garen. Now if the DFG stores the value of a variable into the stack explicitly via a SetLocal, it will record where on the stack it stored the value in addition to recording where on the stack the bytecode would have done the SetLocal. Previously it just recorded the format and the bytecode variable. Recording just the bytecode variable is currently fine since the DFG always executes SetLocal's to the same stack location that the bytecode would have used. But that prevents stack compression (webkit.org/b/122024) so this patch allows the SetLocal to say both the bytecode variable that we're speaking of and the actual stack location to which the SetLocal stored the value. This had to touch a lot of code, so I took the opportunity to also resolve webkit.org/b/108019. * bytecode/Operands.h: (JSC::Operands::hasOperand): * dfg/DFGFlushFormat.h: (JSC::DFG::dataFormatFor): * dfg/DFGMinifiedID.h: (JSC::DFG::MinifiedID::bits): (JSC::DFG::MinifiedID::invalidID): (JSC::DFG::MinifiedID::otherInvalidID): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileMovHint): (JSC::DFG::SpeculativeJIT::compileInlineStart): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::recordSetLocal): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValueSource.cpp: (JSC::DFG::ValueSource::dump): * dfg/DFGValueSource.h: (JSC::DFG::ValueSource::ValueSource): (JSC::DFG::ValueSource::forFlushFormat): (JSC::DFG::ValueSource::forDataFormat): (JSC::DFG::ValueSource::isSet): (JSC::DFG::ValueSource::kind): (JSC::DFG::ValueSource::valueRecovery): (JSC::DFG::ValueSource::id): (JSC::DFG::ValueSource::virtualRegister): * dfg/DFGVariableEvent.cpp: (JSC::DFG::VariableEvent::dump): (JSC::DFG::VariableEvent::dumpSpillInfo): * dfg/DFGVariableEvent.h: (JSC::DFG::VariableEvent::fillGPR): (JSC::DFG::VariableEvent::fillPair): (JSC::DFG::VariableEvent::fillFPR): (JSC::DFG::VariableEvent::spill): (JSC::DFG::VariableEvent::death): (JSC::DFG::VariableEvent::setLocal): (JSC::DFG::VariableEvent::movHint): (JSC::DFG::VariableEvent::id): (JSC::DFG::VariableEvent::gpr): (JSC::DFG::VariableEvent::tagGPR): (JSC::DFG::VariableEvent::payloadGPR): (JSC::DFG::VariableEvent::fpr): (JSC::DFG::VariableEvent::spillRegister): (JSC::DFG::VariableEvent::bytecodeRegister): (JSC::DFG::VariableEvent::machineRegister): (JSC::DFG::VariableEvent::variableRepresentation): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): 2013-10-01 Nadav Rotem FTL: split overflow checks into non-overflow arithmetic and an additional call to the overflow intrinsic check. https://bugs.webkit.org/show_bug.cgi?id=122170 Reviewed by Filip Pizlo. Overflow intrinsics are preventing SCEV and other LLVM analysis passes from analyzing loops. This patch changes the FTL-IR gen by splitting arithmetic calculations into two parts: 1. Generate the arithmetic calculation (that may overflow) 2. Generate the overflow check (that is only used by the OSR-exit logic). We trust LLVM (SelectionDAG) to merge these calculations into a single opcode. This JS function: function foo() { for (i=0; i < 10000000; i++) { } } Is now compiled into this LLVM-IR: "OSR exit continuation for @24": ; preds = %"Block #0", %"OSR exit continuation for @242" %4 = phi i64 [ %10, %"OSR exit continuation for @242" ], [ -281474976710656, %"Block #0" ] %5 = trunc i64 %4 to i32 %6 = add i32 %5, 1 %7 = tail call { i32, i1 } @llvm.sadd.with.overflow.i32(i32 %5, i32 1) %8 = extractvalue { i32, i1 } %7, 1 br i1 %8, label %"OSR exit failCase for @241", label %"OSR exit continuation for @242" And into this assembly: LBB0_1: ## %OSR exit continuation for @24 ## =>This Inner Loop Header: Depth=1 movl %ecx, %esi incl %esi jo LBB0_4 * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileAddSub): (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileArithNegate): 2013-10-01 Nadav Rotem Consolidate multiple OSRExit calls into one. https://bugs.webkit.org/show_bug.cgi?id=122168 Reviewed by Filip Pizlo. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileArithDiv): (JSC::FTL::LowerDFGToLLVM::compileArithMod): 2013-09-30 Filip Pizlo SpeculativeJIT::m_arguments/m_variables are vestiges of a time long gone https://bugs.webkit.org/show_bug.cgi?id=122140 Reviewed by Darin Adler. Just killing code. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::SpeculativeJIT): (JSC::DFG::SpeculativeJIT::compileInlineStart): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::checkArgumentTypes): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::recordSetLocal): 2013-10-01 Daniel Bates [iOS] JavaScriptCore fails to build with newer versions of clang https://bugs.webkit.org/show_bug.cgi?id=122162 Reviewed by Darin Adler. * runtime/GCActivityCallback.cpp: Add !PLATFORM(IOS)-guard around constant pagingTimeOut as we don't compile the code that uses it on iOS. 2013-09-30 Sam Weinig Remove support for DOMFileSystem https://bugs.webkit.org/show_bug.cgi?id=122137 Reviewed by Anders Carlsson. * Configurations/FeatureDefines.xcconfig: 2013-09-30 Dan Bernstein Assertion failure under -[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:] if no classes conform to JSExport https://bugs.webkit.org/show_bug.cgi?id=122124 Reviewed by Darin Adler. * API/JSWrapperMap.mm: Defined an empty class that conforms to the JSExport protocol, to ensure that the protocol is always registered with the runtime by the time getJSExportProtocol() is called. 2013-09-30 Benjamin Poulain Remove the code guarded by STYLE_SCOPED https://bugs.webkit.org/show_bug.cgi?id=122123 Reviewed by Anders Carlsson. * Configurations/FeatureDefines.xcconfig: 2013-09-30 Andreas Kling Pass VM instead of ExecState to ObjectPrototype constructor. Reviewed by Geoffrey Garen. The ObjectPrototype constructor was only using the ExecState to get to the VM. 2013-09-30 Andreas Kling Pass VM instead of JSGlobalObject to MathObject constructor. Reviewed by Geoffrey Garen. The MathObject constructor was only using the global object to get to the VM. finishCreation() still uses it to set up functions. 2013-09-30 Filip Pizlo Get rid of the AlreadyInJSStack recoveries since they are totally redundant with the DisplacedInJSStack recoveries https://bugs.webkit.org/show_bug.cgi?id=122065 Reviewed by Mark Hahnenberg. This mostly just kills a bunch of code. But incidentaly while killing that code, I uncovered a bug in our FTL OSR entrypoint creation phase. The phase inserts a sequence of SetLocal(ExtractOSREntryLocal) nodes. If we hoist some type check into the local, then we might inject a conversion node between the ExtractOSREntryLocal and the SetLocal - for example we might put in a Int32ToDouble node. But currently the FixupPhase will make all conversion nodes placed on an edge of a SetLocal use forward exit. This then confuses the OSR exit machinery. When OSR exit sees a forward exit, it tries to "roll forward" execution from the exiting node to the first node that has a different CodeOrigin. This only works if the nodes after the forward exit are MovHints or other tnings that the OSR exit compiler can forward-execute. But here, it will see a bunch of SetLocal and ExtractOSREntryLocal nodes for the same bytecode index. Two possible solutions exist. We could teach the forward-execution logic how to deal with multiple SetLocals and ExtractOSREntryLocals. This would be a lot of complexity; right now it just needs to deal with exactly one SetLocal-like operation. The alternative is to make sure that the conversion node that we inject ends up exiting *backward* rather than forward. But making the conversion nodes exit backward is somewhat tricky. Before this patch, conversion nodes always exit forward for SetLocals and backwards otherwise. It turns out that the solution is to rationalize how we choose the speculation direciton for a conversion node. The conversion node's speculation direction should be the same as the speculation direction of the node for which it is doing a conversion. Since SetLocal's already exit forward by default, this policy preserves our previous behavior. But it also allows the OSR entrypoint creation phase to make its SetLocals exit backward instead. Of course, if the SetLocal(ExtractOSREntryLocal) sequences exit backward, then we need to make sure that the OSR exit machine knows that the local variables are indeed live. Consider that if we have: a: ExtractOSREntryLocal(loc1) b: SetLocal(@a, loc1) c: ExtractOSRentryLocal(loc2) d: SetLocal(@c, loc2) Without additional magic, the exit at @b will think that loc2 is dead and the OSR exit compiler will clobber loc2 with Undefined. So we need to make sure that we actually emit code like: a: ExtractOSREntryLocal(loc1) b: ExtractOSREntryLocal(loc2) c: SetLocal(@a, loc1) d: SetLocal(@b, loc2) e: SetLocal(@a, loc1) f: SetLocal(@b, loc2) * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CodeOrigin.h: * bytecode/ValueRecovery.cpp: Added. (JSC::ValueRecovery::recover): (JSC::ValueRecovery::dumpInContext): (JSC::ValueRecovery::dump): * bytecode/ValueRecovery.h: * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupSetLocalsInBlock): (JSC::DFG::FixupPhase::fixEdge): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::reconstruct): * dfg/DFGNode.h: (JSC::DFG::Node::speculationDirection): (JSC::DFG::Node::setSpeculationDirection): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileInlineStart): (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): * dfg/DFGValueSource.h: (JSC::DFG::ValueSource::valueRecovery): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::speculate): (JSC::FTL::LowerDFGToLLVM::speculateMachineInt): * interpreter/Register.h: (JSC::Register::unboxedStrictInt52): * runtime/Arguments.cpp: (JSC::Arguments::tearOff): * runtime/Arguments.h: 2013-09-30 Alex Christensen Win64 compile fix after r1256490. https://bugs.webkit.org/show_bug.cgi?id=122117 Reviewed by Michael Saboff. * jit/JITStubsMSVC64.asm: Implemented getHostCallReturnValue for Windows x86_64 processors. 2013-09-30 Andreas Kling Pass VM instead of JSGlobalObject to RegExp constructor. Reviewed by Darin Adler. RegExps don't need anything from the global object during their construction and only use it to get to the VM. Reduce loads by simply passing the VM around instead. JSC release binary size -= 120 bytes(!) 2013-09-30 Patrick Gansterer Fix compilation for COMPILER(MSVC) && !CPU(X86) after r156490. https://bugs.webkit.org/show_bug.cgi?id=122102 Reviewed by Geoffrey Garen. _AddressOfReturnAddress() is supported for all platforms of ths Microsoft compiler, so we can use it for !CPU(X86) too. * jit/JITOperationWrappers.h: 2013-09-30 Gabor Rapcsanyi Unreviewed. Build fix for DEBUG_VERBOSE mode after r156511. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): 2013-09-30 Gabor Rapcsanyi Unreviewed. Speculative build fix on ARMv7 Thumb2 after r156490. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::fmodAsDFGOperation): 2013-09-29 Nadav Rotem FTL: refactor compileAdd and compileArithSub into one function. https://bugs.webkit.org/show_bug.cgi?id=122081 Reviewed by Geoffrey Garen. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileAddSub): 2013-09-29 Andreas Kling Pass VM instead of JSGlobalObject to function constructors. Reviewed by Darin Adler. Functions don't need anything from the global object during their construction and only use it to get to the VM. Reduce loads by simply passing the VM around instead. This patch is mostly mechanical, I just changed the signature of InternalFunction and worked my way from there until it built. JSC release binary size -= 4840 bytes. 2013-09-29 Andreas Kling Pass VM instead of JSGlobalObject to ArrayPrototype constructor. Reviewed by Geoffrey Garen. ArrayPrototype doesn't need the global object for anything during construction, so reduce the amount of loads by just passing the VM. 2013-09-29 Andreas Kling Pass VM instead of ExecState to simple builtin constructors. Reviewed by Sam Weinig. None of the simple builtins need the ExecState for anything during their construction, so reduce the amount of loads by just passing the VM around instead. 2013-09-29 Nadav Rotem Refactor code for finding x86 scratch register. https://bugs.webkit.org/show_bug.cgi?id=122072 Reviewed by Geoffrey Garen. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::getUnusedRegister): (JSC::MacroAssemblerX86Common::store8): (JSC::MacroAssemblerX86Common::store16): 2013-09-28 Mark Rowe Take Xcode's advice and enable some extra warnings. Reviewed by Sam Weinig. * Configurations/Base.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: 2013-09-28 Andreas Kling Pass VM instead of ExecState to JSFunction constructors. Reviewed by Geoffrey Garen. JSFunction doesn't need the ExecState for anything during its construction, so reduce the amount of loads by just passing the VM around instead. Factored out putDirectNonIndexAccessor() from the existing putDirectAccessor() to avoid snowballing the patch (and because it's kinda neat to avoid the extra branch.) JSC release binary size -= 9680 bytes. 2013-09-28 Mark Rowe JavaScriptCore fails to build with newer versions of clang. Reviewed by Sam Weinig. * interpreter/Interpreter.cpp: Remove an unused function. * parser/SourceProvider.cpp: Ditto. * runtime/GCActivityCallback.cpp: #if a constant that's only used on non-CF platforms. * runtime/JSCJSValue.cpp: Remove an unused constant. * runtime/JSString.cpp: Ditto. 2013-09-27 Filip Pizlo Get rid of SetMyScope/SetCallee; use normal variables for the scope and callee of inlined call frames of closures https://bugs.webkit.org/show_bug.cgi?id=122047 Reviewed by Oliver Hunt. Currently we have the DFG reserve space for inline call frames at exactly the same stack offsets that you would have gotten if the baseline interpreter/JIT had made the calls. We need to get rid of that. One of the weirder parts of this is that we have special DFG operations for accessing these inlined call frame headers. It's really hard for any analysis of DFG IR to see what the liveness of any of those frame header "variables" is; the liveness behaves like flushed arguments (it's all live until end of the inlinee) but we don't have anything like a Flush node for those special variables. This patch gets rid of the special operations for accessing inline call frame headers. GetMyScope and GetCallee still remain, and are only for accessing the machine call frame's scope/callee entries. The inline call frame's scope/callee now behave like normal variables, and have Flush behavior just like inline arguments. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getDirect): (JSC::DFG::ByteCodeParser::get): (JSC::DFG::ByteCodeParser::setDirect): (JSC::DFG::ByteCodeParser::set): (JSC::DFG::ByteCodeParser::setLocal): (JSC::DFG::ByteCodeParser::setArgument): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::getScope): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::getCalleeLoadElimination): (JSC::DFG::CSEPhase::getMyScopeLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * 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): 2013-09-27 Filip Pizlo Deoptimize 32-bit deoptimization https://bugs.webkit.org/show_bug.cgi?id=122025 Reviewed by Oliver Hunt. Just simplifying a bunch of code. I don't want the old, super-complicated, deoptimization code to get in the way of changes I'll be making to DFG stack layout. * bytecode/ValueRecovery.h: (JSC::ValueRecovery::inGPR): (JSC::ValueRecovery::isInRegisters): (JSC::ValueRecovery::gpr): (JSC::ValueRecovery::dumpInContext): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): 2013-09-27 Alex Christensen Fixed Win64 build after r156184. https://bugs.webkit.org/show_bug.cgi?id=121994 Reviewed by Oliver Hunt. * jit/CCallHelpers.h: (JSC::CCallHelpers::setupTwoStubArgsGPR): (JSC::CCallHelpers::setupTwoStubArgsFPR): Renamed from setupTwoStubArgs. Visual Studio x64 compiler fails to see that this is an overloaded template function. (JSC::CCallHelpers::setupStubArguments): (JSC::CCallHelpers::setupArguments): (JSC::CCallHelpers::setupArgumentsWithExecState): Use setupTwoStubArgsGPR or setupTwoStubArgsFPR instead of setupTwoStubArgs. 2013-09-27 Gabor Rapcsanyi LLInt alignment problem on ARM in debug mode https://bugs.webkit.org/show_bug.cgi?id=122012 Reviewed by Michael Saboff. Force GCC to put the LLInt code to .text section. * llint/LowLevelInterpreter.cpp: 2013-09-06 Jer Noble [Mac] Implement the media controls in JavaScript. https://bugs.webkit.org/show_bug.cgi?id=120895 Reviewed by Dean Jackson. Define and turn on ENABLE_MEDIA_CONTROLS_SCRIPT. * Configurations/FeatureDefines.xcconfig: 2013-09-27 Andreas Kling Pass VM instead of ExecState to JSDateMath functions. Reviewed by Geoffrey Garen. The JSC date math functions only need the VM, so pass that from callers instead of the whole ExecState. 2013-09-26 Andreas Kling GetterSetter construction should take a VM instead of ExecState. Reviewed by Sam Weinig. Pass VM& instead of ExecState* to GetterSetter. Updated surrounding code at touched sites to cache VM in a local for fewer loads. JSC release binary size -= 4120 bytes. 2013-09-26 Oliver Hunt Make GCC happy * parser/Parser.h: 2013-09-25 Oliver Hunt Implement prefixed-destructuring assignment https://bugs.webkit.org/show_bug.cgi?id=121930 Reviewed by Mark Hahnenberg. Relanding with fix after rollout 2013-09-26 Michael Saboff VirtualRegister should be a class https://bugs.webkit.org/show_bug.cgi?id=121732 Reviewed by Geoffrey Garen. This is a refactoring change. Changed VirtualRegister from an enum to a class. Moved Operands::operandIsArgument(), operandToArgument(), argumentToOperand() and the similar functions for locals to VirtualRegister class. This is in preparation for changing the offset for the first local register from 0 to -1. This is needed since most native calling conventions have the architected frame pointer (e.g. %rbp for X86) point at the slot that stores the previous frame pointer. Local values start below that address. * bytecode/CodeBlock.cpp: * bytecode/CodeBlock.h: * bytecode/Instruction.h: * bytecode/LazyOperandValueProfile.h: * bytecode/MethodOfGettingAValueProfile.cpp: * bytecode/Operands.h: * bytecode/UnlinkedCodeBlock.cpp: * bytecode/UnlinkedCodeBlock.h: * bytecode/ValueRecovery.h: * bytecode/VirtualRegister.h: * bytecompiler/BytecodeGenerator.cpp: * bytecompiler/BytecodeGenerator.h: * bytecompiler/RegisterID.h: * debugger/DebuggerCallFrame.cpp: * dfg/DFGAbstractHeap.h: * dfg/DFGAbstractInterpreterInlines.h: * dfg/DFGArgumentPosition.h: * dfg/DFGArgumentsSimplificationPhase.cpp: * dfg/DFGByteCodeParser.cpp: * dfg/DFGCFGSimplificationPhase.cpp: * dfg/DFGCPSRethreadingPhase.cpp: * dfg/DFGCapabilities.cpp: * dfg/DFGConstantFoldingPhase.cpp: * dfg/DFGFlushLivenessAnalysisPhase.cpp: * dfg/DFGGraph.cpp: * dfg/DFGGraph.h: * dfg/DFGJITCode.cpp: * dfg/DFGNode.h: * dfg/DFGOSREntry.cpp: * dfg/DFGOSREntrypointCreationPhase.cpp: * dfg/DFGOSRExit.h: * dfg/DFGOSRExitCompiler32_64.cpp: * dfg/DFGOSRExitCompiler64.cpp: * dfg/DFGRegisterBank.h: * dfg/DFGScoreBoard.h: * dfg/DFGSpeculativeJIT.cpp: * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: * dfg/DFGSpeculativeJIT64.cpp: * dfg/DFGValidate.cpp: * dfg/DFGValueRecoveryOverride.h: * dfg/DFGVariableAccessData.h: * dfg/DFGVariableEvent.h: * dfg/DFGVariableEventStream.cpp: * dfg/DFGVirtualRegisterAllocationPhase.cpp: * ftl/FTLExitArgumentForOperand.h: * ftl/FTLLink.cpp: * ftl/FTLLowerDFGToLLVM.cpp: * ftl/FTLOSREntry.cpp: * ftl/FTLOSRExit.cpp: * ftl/FTLOSRExit.h: * ftl/FTLOSRExitCompiler.cpp: * interpreter/CallFrame.h: * interpreter/Interpreter.cpp: * jit/AssemblyHelpers.h: * jit/JIT.h: * jit/JITCall.cpp: * jit/JITCall32_64.cpp: * jit/JITInlines.h: * jit/JITOpcodes.cpp: * jit/JITOpcodes32_64.cpp: * jit/JITPropertyAccess32_64.cpp: * jit/JITStubs.cpp: * llint/LLIntSlowPaths.cpp: * profiler/ProfilerBytecodeSequence.cpp: * runtime/CommonSlowPaths.cpp: * runtime/JSActivation.cpp: 2013-09-26 Anders Carlsson Work around another MSVC bug. * runtime/PrototypeMap.cpp: (JSC::PrototypeMap::emptyObjectStructureForPrototype): 2013-09-26 Anders Carlsson Attempt to fix the FTL build. * ftl/FTLAbstractHeap.cpp: (JSC::FTL::IndexedAbstractHeap::atSlow): 2013-09-26 Andreas Kling Pass VM instead of ExecState to many finishCreation() functions. Reviewed by Sam Weinig. Reduce unnecessary loads by passing the VM to object creation functions that don't need the ExecState. There are tons of opportunities in this area, I'm just scratching the surface. 2013-09-26 Commit Queue Unreviewed, rolling out r156464 and r156480. http://trac.webkit.org/changeset/156464 http://trac.webkit.org/changeset/156480 https://bugs.webkit.org/show_bug.cgi?id=121981 Leaking too much and killing buildbot. (Requested by xenon on #webkit). * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedFunctionExecutable::paramString): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitExpressionInfo): * bytecompiler/NodesCodegen.cpp: (JSC::ForInNode::emitBytecode): (JSC::FuncExprNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createFormalParameterList): (JSC::ASTBuilder::createForInLoop): (JSC::ASTBuilder::addVar): * parser/NodeConstructors.h: (JSC::CommaNode::CommaNode): (JSC::ParameterNode::ParameterNode): (JSC::ForInNode::ForInNode): * parser/Nodes.cpp: (JSC::FunctionParameters::create): (JSC::FunctionParameters::FunctionParameters): (JSC::FunctionParameters::~FunctionParameters): * parser/Nodes.h: (JSC::CommaNode::append): (JSC::ParameterNode::ident): (JSC::FunctionParameters::at): (JSC::FunctionParameters::identifiers): * parser/Parser.cpp: (JSC::::Parser): (JSC::::parseVarDeclaration): (JSC::::parseVarDeclarationList): (JSC::::parseForStatement): (JSC::::parseFormalParameters): (JSC::::parseAssignmentExpression): * parser/Parser.h: (JSC::Scope::declareParameter): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createFormalParameterList): (JSC::SyntaxChecker::createForInLoop): (JSC::SyntaxChecker::operatorStackPop): * runtime/JSONObject.cpp: * runtime/JSONObject.h: 2013-09-26 Anders Carlsson Try to fix the Windows build. * jit/JITThunks.cpp: (JSC::JITThunks::hostFunctionStub): * jit/JITThunks.h: 2013-09-26 Anders Carlsson Change a couple of HashMap value types from OwnPtr to std::unique_ptr https://bugs.webkit.org/show_bug.cgi?id=121973 Reviewed by Andreas Kling. * API/JSClassRef.cpp: (OpaqueJSClassContextData::OpaqueJSClassContextData): (OpaqueJSClass::contextData): * API/JSClassRef.h: * bytecode/SamplingTool.h: * ftl/FTLAbstractHeap.h: * parser/Parser.cpp: (JSC::::parseFunctionInfo): * parser/SourceProviderCache.cpp: (JSC::SourceProviderCache::add): * parser/SourceProviderCache.h: * parser/SourceProviderCacheItem.h: (JSC::SourceProviderCacheItem::create): * profiler/ProfilerCompilation.cpp: (JSC::Profiler::Compilation::executionCounterFor): (JSC::Profiler::Compilation::toJS): * profiler/ProfilerCompilation.h: * runtime/JSGlobalObject.h: 2013-09-26 Mark Lam Move DFG inline caching logic into jit/. https://bugs.webkit.org/show_bug.cgi?id=121749. Reviewed by Geoffrey Garen. Relanding http://trac.webkit.org/changeset/156235 after rebasing to latest revision and fixing build breakages on Windows. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::unlink): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resetStubInternal): * bytecode/StructureStubInfo.h: * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator): (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator): * dfg/DFGJITCompiler.h: * dfg/DFGOSRExitCompiler.h: * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * dfg/DFGOperations.h: (JSC::DFG::operationNewTypedArrayWithSizeForType): (JSC::DFG::operationNewTypedArrayWithOneArgumentForType): * dfg/DFGRegisterSet.h: Removed. * dfg/DFGRepatch.cpp: Removed. * dfg/DFGRepatch.h: Removed. * dfg/DFGScratchRegisterAllocator.h: Removed. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeCompare): (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): (JSC::DFG::SpeculativeJIT::compare): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGThunks.cpp: * dfg/DFGThunks.h: * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct): * ftl/FTLOSRExitCompiler.h: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::writeBarrier): * jit/JIT.cpp: (JSC::JIT::linkFor): (JSC::JIT::linkSlowCall): * jit/JITCall.cpp: (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::privateCompileClosureCall): * jit/JITCall32_64.cpp: (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::privateCompileClosureCall): * jit/JITOperationWrappers.h: Copied from Source/JavaScriptCore/jit/JITOperationWrappers.h. * jit/JITOperations.cpp: Copied from Source/JavaScriptCore/jit/JITOperations.cpp. (JSC::getHostCallReturnValueWithExecState): * jit/JITOperations.h: Copied from Source/JavaScriptCore/jit/JITOperations.h. * jit/RegisterSet.h: Copied from Source/JavaScriptCore/jit/RegisterSet.h. * jit/Repatch.cpp: Copied from Source/JavaScriptCore/jit/Repatch.cpp. (JSC::tryBuildGetByIDList): * jit/Repatch.h: Copied from Source/JavaScriptCore/jit/Repatch.h. * jit/ScratchRegisterAllocator.h: Copied from Source/JavaScriptCore/jit/ScratchRegisterAllocator.h. * jit/ThunkGenerators.cpp: (JSC::oldStyleGenerateSlowCaseFor): (JSC::oldStyleLinkForGenerator): (JSC::oldStyleLinkCallGenerator): (JSC::oldStyleLinkConstructGenerator): (JSC::oldStyleLinkClosureCallGenerator): (JSC::oldStyleVirtualForGenerator): (JSC::oldStyleVirtualCallGenerator): (JSC::oldStyleVirtualConstructGenerator): (JSC::emitPointerValidation): (JSC::throwExceptionFromCallSlowPathGenerator): (JSC::slowPathFor): (JSC::linkForThunkGenerator): (JSC::linkCallThunkGenerator): (JSC::linkConstructThunkGenerator): (JSC::linkClosureCallThunkGenerator): (JSC::virtualForThunkGenerator): (JSC::virtualCallThunkGenerator): (JSC::virtualConstructThunkGenerator): * jit/ThunkGenerators.h: 2013-09-26 Anders Carlsson Remove PassWeak.h https://bugs.webkit.org/show_bug.cgi?id=121971 Reviewed by Geoffrey Garen. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/PassWeak.h: Removed. * heap/WeakInlines.h: 2013-09-26 Anders Carlsson Stop using PassWeak https://bugs.webkit.org/show_bug.cgi?id=121968 Reviewed by Sam Weinig. * heap/Weak.h: Remove all knowledge of PassWeak. (JSC::Weak::Weak): These constructors don't need to be explicit. * heap/WeakInlines.h: (JSC::weakAdd): Change Value to be an rvalue reference and use std::forward. * jit/JITThunks.cpp: (JSC::JITThunks::hostFunctionStub): Remove PassWeak. * runtime/RegExpCache.cpp: (JSC::RegExpCache::lookupOrCreate): Use Weak instead of PassWeak. * runtime/SimpleTypedArrayController.cpp: Change add and set to take Weak by value and std::move into place. * runtime/WeakGCMap.h: (JSC::WeakGCMap::get): (JSC::WeakGCMap::set): (JSC::WeakGCMap::add): 2013-09-26 Commit Queue Unreviewed, rolling out r156474. http://trac.webkit.org/changeset/156474 https://bugs.webkit.org/show_bug.cgi?id=121966 Broke the builds. (Requested by xenon on #webkit). * bytecode/CodeBlock.cpp: (JSC::CodeBlock::registerName): (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::createActivation): (JSC::CodeBlock::nameForRegister): * bytecode/CodeBlock.h: (JSC::unmodifiedArgumentsRegister): (JSC::CodeBlock::isKnownNotImmediate): (JSC::CodeBlock::setThisRegister): (JSC::CodeBlock::thisRegister): (JSC::CodeBlock::setArgumentsRegister): (JSC::CodeBlock::argumentsRegister): (JSC::CodeBlock::uncheckedArgumentsRegister): (JSC::CodeBlock::setActivationRegister): (JSC::CodeBlock::activationRegister): (JSC::CodeBlock::uncheckedActivationRegister): (JSC::CodeBlock::usesArguments): (JSC::CodeBlock::isCaptured): * bytecode/Instruction.h: * bytecode/LazyOperandValueProfile.h: (JSC::LazyOperandValueProfileKey::LazyOperandValueProfileKey): (JSC::LazyOperandValueProfileKey::operator!): (JSC::LazyOperandValueProfileKey::hash): (JSC::LazyOperandValueProfileKey::operand): (JSC::LazyOperandValueProfileKey::isHashTableDeletedValue): (JSC::LazyOperandValueProfile::LazyOperandValueProfile): * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::fromLazyOperand): (JSC::MethodOfGettingAValueProfile::getSpecFailBucket): * bytecode/Operands.h: (JSC::localToOperand): (JSC::operandIsLocal): (JSC::operandToLocal): (JSC::operandIsArgument): (JSC::operandToArgument): (JSC::argumentToOperand): (JSC::Operands::operand): (JSC::Operands::hasOperand): (JSC::Operands::setOperand): (JSC::Operands::operandForIndex): (JSC::Operands::setOperandFirstTime): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::setThisRegister): (JSC::UnlinkedCodeBlock::setActivationRegister): (JSC::UnlinkedCodeBlock::setArgumentsRegister): (JSC::UnlinkedCodeBlock::usesArguments): (JSC::UnlinkedCodeBlock::argumentsRegister): (JSC::UnlinkedCodeBlock::usesGlobalObject): (JSC::UnlinkedCodeBlock::setGlobalObjectRegister): (JSC::UnlinkedCodeBlock::globalObjectRegister): (JSC::UnlinkedCodeBlock::thisRegister): (JSC::UnlinkedCodeBlock::activationRegister): * bytecode/ValueRecovery.h: (JSC::ValueRecovery::displacedInJSStack): (JSC::ValueRecovery::virtualRegister): (JSC::ValueRecovery::dumpInContext): * bytecode/VirtualRegister.h: (WTF::printInternal): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::addVar): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::createLazyRegisterIfNecessary): (JSC::BytecodeGenerator::newRegister): (JSC::BytecodeGenerator::emitLoadGlobalObject): (JSC::BytecodeGenerator::emitGetArgumentsLength): (JSC::BytecodeGenerator::emitGetArgumentByVal): (JSC::BytecodeGenerator::createArgumentsIfNecessary): (JSC::BytecodeGenerator::emitReturn): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::registerFor): * bytecompiler/RegisterID.h: (JSC::RegisterID::RegisterID): (JSC::RegisterID::setIndex): (JSC::RegisterID::index): * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::thisObject): * dfg/DFGAbstractHeap.h: (JSC::DFG::AbstractHeap::Payload::Payload): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): (JSC::DFG::::clobberCapturedVars): * dfg/DFGArgumentPosition.h: (JSC::DFG::ArgumentPosition::dump): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::newVariableAccessData): (JSC::DFG::ByteCodeParser::getDirect): (JSC::DFG::ByteCodeParser::get): (JSC::DFG::ByteCodeParser::setDirect): (JSC::DFG::ByteCodeParser::set): (JSC::DFG::ByteCodeParser::getLocal): (JSC::DFG::ByteCodeParser::setLocal): (JSC::DFG::ByteCodeParser::getArgument): (JSC::DFG::ByteCodeParser::setArgument): (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): (JSC::DFG::ByteCodeParser::findArgumentPosition): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::flushDirect): (JSC::DFG::ByteCodeParser::getToInt32): (JSC::DFG::ByteCodeParser::getThis): (JSC::DFG::ByteCodeParser::addCall): (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::emitFunctionChecks): (JSC::DFG::ByteCodeParser::emitArgumentPhantoms): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::handleMinMax): (JSC::DFG::ByteCodeParser::handleIntrinsic): (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor): (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): (JSC::DFG::ByteCodeParser::handleGetByOffset): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCFGSimplificationPhase.cpp: * dfg/DFGCPSRethreadingPhase.cpp: (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocal): (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocal): (JSC::DFG::CPSRethreadingPhase::canonicalizeSetArgument): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::isCapturedAtOrAfter): * dfg/DFGFlushLivenessAnalysisPhase.cpp: (JSC::DFG::FlushLivenessAnalysisPhase::setForNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: (JSC::DFG::Graph::argumentsRegisterFor): (JSC::DFG::Graph::uncheckedArgumentsRegisterFor): (JSC::DFG::Graph::uncheckedActivationRegisterFor): (JSC::DFG::Graph::valueProfileFor): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::reconstruct): * dfg/DFGNode.h: (JSC::DFG::Node::Node): (JSC::DFG::Node::convertToGetLocalUnlinked): (JSC::DFG::Node::hasVirtualRegister): (JSC::DFG::Node::virtualRegister): (JSC::DFG::Node::setVirtualRegister): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGOSRExit.h: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGRegisterBank.h: (JSC::DFG::RegisterBank::tryAllocate): (JSC::DFG::RegisterBank::allocateSpecific): (JSC::DFG::RegisterBank::retain): (JSC::DFG::RegisterBank::isInUse): (JSC::DFG::RegisterBank::dump): (JSC::DFG::RegisterBank::releaseAtIndex): (JSC::DFG::RegisterBank::allocateInternal): (JSC::DFG::RegisterBank::MapEntry::MapEntry): * dfg/DFGScoreBoard.h: (JSC::DFG::ScoreBoard::allocate): (JSC::DFG::ScoreBoard::use): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::SpeculativeJIT): (JSC::DFG::SpeculativeJIT::checkConsistency): (JSC::DFG::SpeculativeJIT::compileMovHint): (JSC::DFG::SpeculativeJIT::compileInlineStart): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::allocate): (JSC::DFG::SpeculativeJIT::fprAllocate): (JSC::DFG::SpeculativeJIT::silentSpillAllRegistersImpl): (JSC::DFG::SpeculativeJIT::flushRegisters): (JSC::DFG::SpeculativeJIT::isFlushed): (JSC::DFG::SpeculativeJIT::argumentSlot): (JSC::DFG::SpeculativeJIT::argumentTagSlot): (JSC::DFG::SpeculativeJIT::argumentPayloadSlot): (JSC::DFG::SpeculativeJIT::valueSourceForOperand): (JSC::DFG::SpeculativeJIT::setNodeForOperand): (JSC::DFG::SpeculativeJIT::valueSourceReferenceForOperand): (JSC::DFG::SpeculativeJIT::recordSetLocal): (JSC::DFG::SpeculativeJIT::generationInfoFromVirtualRegister): (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validate): (JSC::DFG::Validate::validateCPS): (JSC::DFG::Validate::checkOperand): (JSC::DFG::Validate::reportValidationContext): * dfg/DFGValueRecoveryOverride.h: (JSC::DFG::ValueRecoveryOverride::ValueRecoveryOverride): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::operand): (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): (JSC::DFG::VariableAccessData::tallyVotesForShouldUseDoubleFormat): (JSC::DFG::VariableAccessData::flushFormat): * dfg/DFGVariableEvent.h: (JSC::DFG::VariableEvent::spill): (JSC::DFG::VariableEvent::setLocal): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): * ftl/FTLExitArgumentForOperand.h: (JSC::FTL::ExitArgumentForOperand::ExitArgumentForOperand): (JSC::FTL::ExitArgumentForOperand::operand): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::compileGetArgument): (JSC::FTL::LowerDFGToLLVM::compileExtractOSREntryLocal): (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct): (JSC::FTL::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::LowerDFGToLLVM::observeMovHint): (JSC::FTL::LowerDFGToLLVM::addressFor): (JSC::FTL::LowerDFGToLLVM::payloadFor): (JSC::FTL::LowerDFGToLLVM::tagFor): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): * ftl/FTLOSRExit.cpp: (JSC::FTL::OSRExit::convertToForward): * ftl/FTLOSRExit.h: * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * interpreter/CallFrame.h: * interpreter/Interpreter.cpp: (JSC::Interpreter::dumpRegisters): (JSC::unwindCallFrame): (JSC::Interpreter::unwind): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::addressFor): (JSC::AssemblyHelpers::tagFor): (JSC::AssemblyHelpers::payloadFor): (JSC::AssemblyHelpers::argumentsRegisterFor): * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITInlines.h: (JSC::JIT::emitGetVirtualRegister): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_tear_off_arguments): (JSC::JIT::emit_op_get_pnames): (JSC::JIT::emit_op_enter): (JSC::JIT::emit_op_create_arguments): (JSC::JIT::emitSlow_op_get_argument_by_val): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_enter): * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::BytecodeSequence): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSActivation.cpp: (JSC::JSActivation::argumentsGetter): 2013-09-26 Oliver Hunt Attempt to fix MSVC build * parser/Parser.cpp: (JSC::::createBindingPattern): (JSC::::parseDeconstructionPattern): * parser/Parser.h: 2013-09-26 Julien Brianceau [sh4] JSValue* exception is unused since r70703 in JITStackFrame. https://bugs.webkit.org/show_bug.cgi?id=121962 This is a cosmetic change, but it could avoid people reading sh4 part to waste time to understand why there is a JSValue* here. Reviewed by Darin Adler. * jit/JITStubs.h: 2013-09-26 Anders Carlsson WeakGCMap should not inherit from HashMap https://bugs.webkit.org/show_bug.cgi?id=121964 Reviewed by Geoffrey Garen. Add the HashMap as a member variable instead and implement the missing member functions. * runtime/WeakGCMap.h: 2013-09-25 Michael Saboff VirtualRegister should be a class https://bugs.webkit.org/show_bug.cgi?id=121732 Reviewed by Geoffrey Garen. This is a refactoring change. Changed VirtualRegister from an enum to a class. Moved Operands::operandIsArgument(), operandToArgument(), argumentToOperand() and the similar functions for locals to VirtualRegister class. This is in preparation for changing the offset for the first local register from 0 to -1. This is needed since most native calling conventions have the architected frame pointer (e.g. %rbp for X86) point at the slot that stores the previous frame pointer. Local values start below that address. * bytecode/CodeBlock.cpp: * bytecode/CodeBlock.h: * bytecode/Instruction.h: * bytecode/LazyOperandValueProfile.h: * bytecode/MethodOfGettingAValueProfile.cpp: * bytecode/Operands.h: * bytecode/UnlinkedCodeBlock.cpp: * bytecode/UnlinkedCodeBlock.h: * bytecode/ValueRecovery.h: * bytecode/VirtualRegister.h: * bytecompiler/BytecodeGenerator.cpp: * bytecompiler/BytecodeGenerator.h: * bytecompiler/RegisterID.h: * debugger/DebuggerCallFrame.cpp: * dfg/DFGAbstractHeap.h: * dfg/DFGAbstractInterpreterInlines.h: * dfg/DFGArgumentPosition.h: * dfg/DFGArgumentsSimplificationPhase.cpp: * dfg/DFGByteCodeParser.cpp: * dfg/DFGCFGSimplificationPhase.cpp: * dfg/DFGCPSRethreadingPhase.cpp: * dfg/DFGCapabilities.cpp: * dfg/DFGConstantFoldingPhase.cpp: * dfg/DFGFlushLivenessAnalysisPhase.cpp: * dfg/DFGGraph.cpp: * dfg/DFGGraph.h: * dfg/DFGJITCode.cpp: * dfg/DFGNode.h: * dfg/DFGOSREntry.cpp: * dfg/DFGOSREntrypointCreationPhase.cpp: * dfg/DFGOSRExit.h: * dfg/DFGOSRExitCompiler32_64.cpp: * dfg/DFGOSRExitCompiler64.cpp: * dfg/DFGRegisterBank.h: * dfg/DFGScoreBoard.h: * dfg/DFGSpeculativeJIT.cpp: * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT64.cpp: * dfg/DFGValidate.cpp: * dfg/DFGValueRecoveryOverride.h: * dfg/DFGVariableAccessData.h: * dfg/DFGVariableEvent.h: * dfg/DFGVariableEventStream.cpp: * dfg/DFGVirtualRegisterAllocationPhase.cpp: * ftl/FTLExitArgumentForOperand.h: * ftl/FTLLink.cpp: * ftl/FTLLowerDFGToLLVM.cpp: * ftl/FTLOSREntry.cpp: * ftl/FTLOSRExit.cpp: * ftl/FTLOSRExit.h: * ftl/FTLOSRExitCompiler.cpp: * interpreter/CallFrame.h: * interpreter/Interpreter.cpp: * jit/AssemblyHelpers.h: * jit/JIT.h: * jit/JITCall.cpp: * jit/JITInlines.h: * jit/JITOpcodes.cpp: * jit/JITOpcodes32_64.cpp: * jit/JITStubs.cpp: * llint/LLIntSlowPaths.cpp: * profiler/ProfilerBytecodeSequence.cpp: * runtime/CommonSlowPaths.cpp: * runtime/JSActivation.cpp: 2013-09-26 Anders Carlsson Weak should have a move constructor and move assignment operator https://bugs.webkit.org/show_bug.cgi?id=121963 Reviewed by Oliver Hunt. This is the first step towards getting rid of PassWeak. * API/JSClassRef.cpp: (OpaqueJSClass::prototype): * heap/Weak.h: * heap/WeakInlines.h: (JSC::::Weak): (JSC::::leakImpl): * runtime/SimpleTypedArrayController.cpp: (JSC::SimpleTypedArrayController::toJS): 2013-09-26 Mark Hahnenberg op_to_this shouldn't use value profiling https://bugs.webkit.org/show_bug.cgi?id=121920 Reviewed by Geoffrey Garen. Currently it's the only opcode that uses m_singletonValue, which is unnecessary. Our current plan is to remove m_singletonValue so that GenGC can have a simpler story for handling CodeBlocks/FunctionExecutables during nursery collections. This patch adds an inline cache for the Structure of to_this so it no longer depends on the ValueProfile's m_singletonValue. Since nobody uses m_singletonValue now, this patch also removes m_singletonValue from ValueProfile. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::finalizeUnconditionally): (JSC::CodeBlock::stronglyVisitStrongReferences): (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): (JSC::CodeBlock::updateAllValueProfilePredictions): (JSC::CodeBlock::updateAllPredictions): (JSC::CodeBlock::shouldOptimizeNow): * bytecode/CodeBlock.h: (JSC::CodeBlock::updateAllValueProfilePredictions): (JSC::CodeBlock::updateAllPredictions): * bytecode/LazyOperandValueProfile.cpp: (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions): * bytecode/LazyOperandValueProfile.h: * bytecode/ValueProfile.h: (JSC::ValueProfileBase::ValueProfileBase): (JSC::ValueProfileBase::briefDescription): (JSC::ValueProfileBase::dump): (JSC::ValueProfileBase::computeUpdatedPrediction): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_to_this): (JSC::JIT::emitSlow_op_to_this): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_to_this): (JSC::JIT::emitSlow_op_to_this): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): 2013-09-25 Oliver Hunt Implement prefixed-destructuring assignment https://bugs.webkit.org/show_bug.cgi?id=121930 Reviewed by Mark Hahnenberg. This is mostly simple - the semantics of deconstruction are already present in the language, so most of the complexity (if you call it that) is addition of new AST nodes, and parsing the syntax. In order to get correct semantics for the parameter lists, FunctionParameters now needs to store refcounted references to the parameter patterns. There's also a little work to ensure that variable creation and assignment occurs in the correct order while the BytecodeGenerator is being constructed. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedFunctionExecutable::paramString): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitExpressionInfo): * bytecompiler/NodesCodegen.cpp: (JSC::ForInNode::emitBytecode): (JSC::DeconstructingAssignmentNode::emitBytecode): (JSC::DeconstructionPatternNode::~DeconstructionPatternNode): (JSC::ArrayPatternNode::emitBytecode): (JSC::ArrayPatternNode::emitDirectBinding): (JSC::ArrayPatternNode::toString): (JSC::ArrayPatternNode::collectBoundIdentifiers): (JSC::ObjectPatternNode::toString): (JSC::ObjectPatternNode::emitBytecode): (JSC::ObjectPatternNode::collectBoundIdentifiers): (JSC::BindingNode::emitBytecode): (JSC::BindingNode::toString): (JSC::BindingNode::collectBoundIdentifiers): * parser/ASTBuilder.h: (JSC::ASTBuilder::createFormalParameterList): (JSC::ASTBuilder::createForInLoop): (JSC::ASTBuilder::addVar): (JSC::ASTBuilder::createDeconstructingAssignment): (JSC::ASTBuilder::createArrayPattern): (JSC::ASTBuilder::appendArrayPatternSkipEntry): (JSC::ASTBuilder::appendArrayPatternEntry): (JSC::ASTBuilder::createObjectPattern): (JSC::ASTBuilder::appendObjectPatternEntry): (JSC::ASTBuilder::createBindingLocation): * parser/NodeConstructors.h: (JSC::CommaNode::CommaNode): (JSC::ParameterNode::ParameterNode): (JSC::ForInNode::ForInNode): (JSC::DeconstructionPatternNode::DeconstructionPatternNode): (JSC::ArrayPatternNode::ArrayPatternNode): (JSC::ArrayPatternNode::create): (JSC::ObjectPatternNode::ObjectPatternNode): (JSC::ObjectPatternNode::create): (JSC::BindingNode::create): (JSC::BindingNode::BindingNode): (JSC::DeconstructingAssignmentNode::DeconstructingAssignmentNode): * parser/Nodes.cpp: (JSC::FunctionParameters::create): (JSC::FunctionParameters::FunctionParameters): (JSC::FunctionParameters::~FunctionParameters): * parser/Nodes.h: (JSC::ExpressionNode::isDeconstructionNode): (JSC::ArrayNode::elements): (JSC::CommaNode::append): (JSC::ParameterNode::pattern): (JSC::FunctionParameters::at): (JSC::FunctionParameters::patterns): (JSC::DeconstructionPatternNode::isBindingNode): (JSC::DeconstructionPatternNode::emitDirectBinding): (JSC::ArrayPatternNode::appendIndex): (JSC::ObjectPatternNode::appendEntry): (JSC::ObjectPatternNode::Entry::Entry): (JSC::BindingNode::boundProperty): (JSC::BindingNode::isBindingNode): (JSC::DeconstructingAssignmentNode::bindings): (JSC::DeconstructingAssignmentNode::isLocation): (JSC::DeconstructingAssignmentNode::isDeconstructionNode): * parser/Parser.cpp: (JSC::::Parser): (JSC::::parseVarDeclaration): (JSC::::parseVarDeclarationList): (JSC::::createBindingPattern): (JSC::::parseDeconstructionPattern): (JSC::::parseForStatement): (JSC::::parseFormalParameters): (JSC::::parseAssignmentExpression): * parser/Parser.h: (JSC::Scope::declareBoundParameter): (JSC::Parser::declareBoundParameter): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createFormalParameterList): (JSC::SyntaxChecker::addVar): (JSC::SyntaxChecker::operatorStackPop): * runtime/JSONObject.cpp: (JSC::escapeStringToBuilder): * runtime/JSONObject.h: 2013-09-25 Brady Eidson Enable the IndexedDB build on Mac, but leave the feature non-functional https://bugs.webkit.org/show_bug.cgi?id=121918 Reviewed by Alexey Proskuryakov. * Configurations/FeatureDefines.xcconfig: 2013-09-25 Commit Queue Unreviewed, rolling out r156432. http://trac.webkit.org/changeset/156432 https://bugs.webkit.org/show_bug.cgi?id=121932 some integer conversion things that need brady to fix (Requested by thorton on #webkit). * Configurations/FeatureDefines.xcconfig: 2013-09-25 Anders Carlsson Move KeyValuePairTraits inside HashMap https://bugs.webkit.org/show_bug.cgi?id=121931 Reviewed by Sam Weinig. * tools/ProfileTreeNode.h: 2013-09-25 Brady Eidson Enable the IndexedDB build on Mac, but leave the feature non-functional https://bugs.webkit.org/show_bug.cgi?id=121918 Reviewed by Alexey Proskuryakov. * Configurations/FeatureDefines.xcconfig: 2013-09-25 Brady Eidson FeatureDefine.xcconfig cleanup (They should all be identical). https://bugs.webkit.org/show_bug.cgi?id=121921 Reviewed by Mark Rowe. * Configurations/FeatureDefines.xcconfig: 2013-09-25 Patrick Gansterer Build fix for WinCE after r155098. Windows CE does not support getenv(). * jsc.cpp: (main): 2013-09-24 Mark Hahnenberg op_get_callee shouldn't use value profiling https://bugs.webkit.org/show_bug.cgi?id=121821 Reviewed by Filip Pizlo. Currently it's one of the two opcodes that uses m_singletonValue, which is unnecessary. Our current plan is to remove m_singletonValue so that GenGC can have a simpler story for handling CodeBlocks/FunctionExecutables during nursery collections. Instead of using a ValueProfile op_get_callee now has a simple inline cache of the most recent JSFunction that we saw. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::finalizeUnconditionally): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitCreateThis): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_get_callee): (JSC::JIT::emitSlow_op_get_callee): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_get_callee): (JSC::JIT::emitSlow_op_get_callee): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2013-09-24 Mark Lam Change JSC debug hooks to pass a CallFrame* instead of a DebuggerCallFrame. https://bugs.webkit.org/show_bug.cgi?id=121867. Reviewed by Geoffrey Garen. 1. Removed the need for passing the line and column info to the debug hook callbacks. We now get the line and column info from the CallFrame. 2. Simplify BytecodeGenerator::emitDebugHook() to only take 1 line number argument. The caller can determine whether to pass in the first or last line number of the block of source code as appropriate. Note: we still need to pass in the line and column info to emitDebugHook() because it uses this info to emit expression info which is later used by the StackVisitor to determine the line and column info for its "pc". 3. Pass the exceptionValue explicitly to the exception() debug hook callback. It should not be embedded in the CallFrame / DebuggerCallFrame. 4. Change the op_debug opcode size to 2 (from 5) since we've removing 3 arg values. Update the LLINT and JIT code to handle this. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitDebugHook): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::ConstStatementNode::emitBytecode): (JSC::EmptyStatementNode::emitBytecode): (JSC::DebuggerStatementNode::emitBytecode): (JSC::ExprStatementNode::emitBytecode): (JSC::VarStatementNode::emitBytecode): (JSC::IfElseNode::emitBytecode): (JSC::DoWhileNode::emitBytecode): (JSC::WhileNode::emitBytecode): (JSC::ForNode::emitBytecode): (JSC::ForInNode::emitBytecode): (JSC::ContinueNode::emitBytecode): (JSC::BreakNode::emitBytecode): (JSC::ReturnNode::emitBytecode): (JSC::WithNode::emitBytecode): (JSC::SwitchNode::emitBytecode): (JSC::LabelNode::emitBytecode): (JSC::ThrowNode::emitBytecode): (JSC::TryNode::emitBytecode): (JSC::ProgramNode::emitBytecode): (JSC::EvalNode::emitBytecode): (JSC::FunctionBodyNode::emitBytecode): * debugger/Debugger.h: * debugger/DebuggerCallFrame.cpp: (JSC::LineAndColumnFunctor::operator()): (JSC::LineAndColumnFunctor::line): (JSC::LineAndColumnFunctor::column): (JSC::DebuggerCallFrame::DebuggerCallFrame): (JSC::DebuggerCallFrame::clear): * debugger/DebuggerCallFrame.h: (JSC::DebuggerCallFrame::line): (JSC::DebuggerCallFrame::column): * interpreter/Interpreter.cpp: (JSC::unwindCallFrame): (JSC::UnwindFunctor::UnwindFunctor): (JSC::UnwindFunctor::operator()): (JSC::Interpreter::unwind): (JSC::Interpreter::debug): * interpreter/Interpreter.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_debug): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_debug): * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: 2013-09-24 Filip Pizlo Crashing under JSC::DFG::SpeculativeJIT::spill visiting citicards.com https://bugs.webkit.org/show_bug.cgi?id=121844 Reviewed by Mark Hahnenberg. Fix some int52 bugs that caused this. * bytecode/ValueRecovery.h: (JSC::ValueRecovery::dumpInContext): There's no such thing as int53. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::spill): Actually spill int52's, instead of hitting an assert and crashing. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): Use the right format (from before when we clobber it). 2013-09-24 Mark Rowe WebKit should build against the Xcode default toolchain when targeting OS X 10.8 Reviewed by Dan Bernstein. * Configurations/Base.xcconfig: 2013-09-23 Patrick Gansterer use NOMINMAX instead of #define min min https://bugs.webkit.org/show_bug.cgi?id=73563 Reviewed by Brent Fulgham. Use NOMINMAX instead of #define min/max as a cleaner way of ensuring that Windows system header files don't define min/max as macro in the first place. * config.h: 2013-09-23 Filip Pizlo Never use ReturnPC for exception handling and quit using exception check indices as a lame replica of the CodeOrigin index https://bugs.webkit.org/show_bug.cgi?id=121734 Reviewed by Mark Hahnenberg. Exception handling can deduce where the exception was thrown from by looking at the code origin that was stored into the call frame header. There is no need to pass any additional meta-data into the exception throwing logic. But the DFG was still doing it anyway. This removes all of the logic to pass extra meta-data into lookupExceptionHandler() and friends. It simplifies a lot of code. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::shrinkToFit): * bytecode/CodeBlock.h: (JSC::CodeBlock::codeOrigins): (JSC::CodeBlock::hasCodeOrigins): (JSC::CodeBlock::canGetCodeOrigin): (JSC::CodeBlock::codeOrigin): * bytecode/CodeOrigin.h: (JSC::InlineCallFrame::InlineCallFrame): * bytecode/InlineCallFrameSet.cpp: Added. (JSC::InlineCallFrameSet::InlineCallFrameSet): (JSC::InlineCallFrameSet::~InlineCallFrameSet): (JSC::InlineCallFrameSet::add): (JSC::InlineCallFrameSet::shrinkToFit): * bytecode/InlineCallFrameSet.h: Added. (JSC::InlineCallFrameSet::isEmpty): (JSC::InlineCallFrameSet::size): (JSC::InlineCallFrameSet::at): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGCommonData.cpp: (JSC::DFG::CommonData::addCodeOrigin): (JSC::DFG::CommonData::shrinkToFit): * dfg/DFGCommonData.h: * dfg/DFGDesiredWriteBarriers.cpp: (JSC::DFG::DesiredWriteBarrier::DesiredWriteBarrier): (JSC::DFG::DesiredWriteBarrier::trigger): * dfg/DFGDesiredWriteBarriers.h: (JSC::DFG::DesiredWriteBarriers::add): (JSC::DFG::initializeLazyWriteBarrierForInlineCallFrameExecutable): (JSC::DFG::initializeLazyWriteBarrierForInlineCallFrameCallee): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): * dfg/DFGGraph.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::JITCompiler): (JSC::DFG::JITCompiler::compileExceptionHandlers): (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::emitStoreCodeOrigin): (JSC::DFG::JITCompiler::exceptionCheck): (JSC::DFG::JITCompiler::fastExceptionCheck): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGRepatch.cpp: (JSC::DFG::tryBuildGetByIDList): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck): (JSC::DFG::SpeculativeJIT::appendCallSetResult): (JSC::DFG::SpeculativeJIT::appendCall): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::callPreflight): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitExceptionCheck): 2013-09-23 Oliver Hunt CodeLoad performance regression Reviewed by Filip Pizlo. Temporarily remove the ExpressionInfo compression until we can work out how to make it not clobber performance. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): (JSC::UnlinkedCodeBlock::addExpressionInfo): * bytecode/UnlinkedCodeBlock.h: 2013-09-23 Patrick Gansterer Cleanup CMake files in JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=121762 Reviewed by Gyuyoung Kim. Sort files and unify style. * CMakeLists.txt: * shell/CMakeLists.txt: * shell/PlatformBlackBerry.cmake: * shell/PlatformEfl.cmake: 2013-09-22 Filip Pizlo Get rid of CodeBlock::RareData::callReturnIndexVector and most of the evil that it introduced https://bugs.webkit.org/show_bug.cgi?id=121766 Reviewed by Andreas Kling. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::shrinkToFit): * bytecode/CodeBlock.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileExceptionHandlers): (JSC::DFG::JITCompiler::link): * jit/JIT.cpp: (JSC::JIT::privateCompile): 2013-09-21 Filip Pizlo Interpreter::unwind() has no need for the bytecodeOffset https://bugs.webkit.org/show_bug.cgi?id=121755 Reviewed by Oliver Hunt. It was only using the bytecodeOffset for some debugger stuff, but the debugger could just get the bytecodeOffset the same way the rest of the machinery does: by using the CallFrame's location. It turns out that a lot of really ugly code was in place just to supply this bytecodeOffset. This patch kills most of that code, and allows us to kill even more code in a future patch - though most likely that killage will involve further refactorings as well, see https://bugs.webkit.org/show_bug.cgi?id=121734. * dfg/DFGOperations.cpp: * interpreter/CallFrame.cpp: (JSC::CallFrame::bytecodeOffset): (JSC::CallFrame::codeOrigin): * interpreter/CallFrame.h: * interpreter/Interpreter.cpp: (JSC::Interpreter::unwind): * interpreter/Interpreter.h: * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/JITExceptions.h: * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): (JSC::cti_vm_handle_exception): * llint/LLIntExceptions.cpp: (JSC::LLInt::doThrow): (JSC::LLInt::returnToThrow): (JSC::LLInt::callToThrow): * llint/LLIntExceptions.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPathsExceptions.cpp: (JSC::CommonSlowPaths::interpreterThrowInCaller): * runtime/CommonSlowPathsExceptions.h: 2013-09-21 Darin Adler Add ExecState::uncheckedArgument and use where possible to shrink a bit https://bugs.webkit.org/show_bug.cgi?id=121750 Reviewed by Andreas Kling. * interpreter/CallFrame.h: (JSC::ExecState::uncheckedArgument): Added. Like argument, but with an assertion rather than a runtime check. * API/APICallbackFunction.h: (JSC::APICallbackFunction::call): Use uncheckedArgument because we are already in a loop over arguments, so don't need a range check. * API/JSCallbackConstructor.cpp: (JSC::constructJSCallback): Ditto. * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::construct): Ditto. (JSC::JSCallbackObject::call): Ditto. * jsc.cpp: (functionPrint): Ditto. (functionRun): Ditto. (functionSetSamplingFlags): Ditto. (functionClearSamplingFlags): Ditto. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncConcat): Ditto. (JSC::arrayProtoFuncPush): Use uncheckedArgument because there is already code that explicitly checks argumentCount. (JSC::arrayProtoFuncSplice): Ditto. (JSC::arrayProtoFuncUnShift): Ditto. (JSC::arrayProtoFuncReduce): Ditto. (JSC::arrayProtoFuncReduceRight): Ditto. (JSC::arrayProtoFuncLastIndexOf): Ditto. * runtime/DatePrototype.cpp: (JSC::fillStructuresUsingTimeArgs): Ditto. (JSC::fillStructuresUsingDateArgs): Ditto. * runtime/JSArrayBufferConstructor.cpp: (JSC::constructArrayBuffer): Ditto. * runtime/JSArrayBufferPrototype.cpp: (JSC::arrayBufferProtoFuncSlice): Ditto. * runtime/JSBoundFunction.cpp: (JSC::boundFunctionCall): Ditto. (JSC::boundFunctionConstruct): Ditto. * runtime/JSDataViewPrototype.cpp: (JSC::getData): Ditto. (JSC::setData): Ditto. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayView): Ditto. * runtime/JSGenericTypedArrayViewPrototypeInlines.h: (JSC::genericTypedArrayViewProtoFuncSet): Ditto. (JSC::genericTypedArrayViewProtoFuncSubarray): Ditto. * runtime/JSONObject.cpp: (JSC::JSONProtoFuncParse): Ditto. (JSC::JSONProtoFuncStringify): Ditto. * runtime/JSPromiseConstructor.cpp: (JSC::constructPromise): Ditto. (JSC::JSPromiseConstructorFuncFulfill): Ditto. (JSC::JSPromiseConstructorFuncResolve): Ditto. (JSC::JSPromiseConstructorFuncReject): Ditto. * runtime/MathObject.cpp: (JSC::mathProtoFuncMax): Ditto. (JSC::mathProtoFuncMin): Ditto. * runtime/NameConstructor.cpp: (JSC::constructPrivateName): Removed unneeded check of argumentCout that simply repeats what argument already does. * runtime/NativeErrorConstructor.cpp: (JSC::Interpreter::constructWithNativeErrorConstructor): Ditto. (JSC::Interpreter::callNativeErrorConstructor): Ditto. * runtime/NumberConstructor.cpp: (JSC::constructWithNumberConstructor): Use uncheckedArgument since there is already code that explicitly checks argument count. (JSC::callNumberConstructor): Ditto. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorCreate): Small refactoring to not call argument(0) three times. * runtime/SetConstructor.cpp: (JSC::constructSet): Use uncheckedArgument since we are already in a loop over arguments. * runtime/StringConstructor.cpp: (JSC::stringFromCharCodeSlowCase): In a loop. (JSC::stringFromCharCode): Already checked count. (JSC::constructWithStringConstructor): Ditto. (JSC::callStringConstructor): Ditto. * runtime/StringPrototype.cpp: (JSC::stringProtoFuncConcat): Already checked count. * runtime/TestRunnerUtils.cpp: (JSC::numberOfDFGCompiles): Ditto. (JSC::setNeverInline): Ditto. 2013-09-21 Filip Pizlo Remove the notion that a CallFrame can have a pointer to an InlineCallFrame, since that doesn't happen anymore https://bugs.webkit.org/show_bug.cgi?id=121753 Reviewed by Darin Adler. * interpreter/CallFrame.cpp: (JSC::CallFrame::bytecodeOffsetFromCodeOriginIndex): * interpreter/CallFrame.h: * interpreter/Register.h: 2013-09-21 Filip Pizlo Unreviewed, fix the revert. * dfg/DFGRepatch.cpp: 2013-09-21 Filip Pizlo Unreviewed, revert http://trac.webkit.org/changeset/156235. It won't work on Windows. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::unlink): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resetStubInternal): * bytecode/StructureStubInfo.h: * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator): (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator): * dfg/DFGJITCompiler.h: * dfg/DFGOSRExitCompiler.h: * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * dfg/DFGOperations.h: (JSC::DFG::operationNewTypedArrayWithSizeForType): (JSC::DFG::operationNewTypedArrayWithOneArgumentForType): * dfg/DFGRegisterSet.h: Added. (JSC::DFG::RegisterSet::RegisterSet): (JSC::DFG::RegisterSet::asPOD): (JSC::DFG::RegisterSet::copyInfo): (JSC::DFG::RegisterSet::set): (JSC::DFG::RegisterSet::setGPRByIndex): (JSC::DFG::RegisterSet::clear): (JSC::DFG::RegisterSet::get): (JSC::DFG::RegisterSet::getGPRByIndex): (JSC::DFG::RegisterSet::getFreeGPR): (JSC::DFG::RegisterSet::setFPRByIndex): (JSC::DFG::RegisterSet::getFPRByIndex): (JSC::DFG::RegisterSet::setByIndex): (JSC::DFG::RegisterSet::getByIndex): (JSC::DFG::RegisterSet::numberOfSetGPRs): (JSC::DFG::RegisterSet::numberOfSetFPRs): (JSC::DFG::RegisterSet::numberOfSetRegisters): (JSC::DFG::RegisterSet::setBit): (JSC::DFG::RegisterSet::clearBit): (JSC::DFG::RegisterSet::getBit): * dfg/DFGRepatch.cpp: Added. (JSC::DFG::repatchCall): (JSC::DFG::repatchByIdSelfAccess): (JSC::DFG::addStructureTransitionCheck): (JSC::DFG::replaceWithJump): (JSC::DFG::emitRestoreScratch): (JSC::DFG::linkRestoreScratch): (JSC::DFG::generateProtoChainAccessStub): (JSC::DFG::tryCacheGetByID): (JSC::DFG::repatchGetByID): (JSC::DFG::getPolymorphicStructureList): (JSC::DFG::patchJumpToGetByIdStub): (JSC::DFG::tryBuildGetByIDList): (JSC::DFG::buildGetByIDList): (JSC::DFG::appropriateGenericPutByIdFunction): (JSC::DFG::appropriateListBuildingPutByIdFunction): (JSC::DFG::emitPutReplaceStub): (JSC::DFG::emitPutTransitionStub): (JSC::DFG::tryCachePutByID): (JSC::DFG::repatchPutByID): (JSC::DFG::tryBuildPutByIdList): (JSC::DFG::buildPutByIdList): (JSC::DFG::tryRepatchIn): (JSC::DFG::repatchIn): (JSC::DFG::linkSlowFor): (JSC::DFG::linkFor): (JSC::DFG::linkClosureCall): (JSC::DFG::resetGetByID): (JSC::DFG::resetPutByID): (JSC::DFG::resetIn): * dfg/DFGRepatch.h: Added. (JSC::DFG::resetGetByID): (JSC::DFG::resetPutByID): (JSC::DFG::resetIn): * dfg/DFGScratchRegisterAllocator.h: Added. (JSC::DFG::ScratchRegisterAllocator::ScratchRegisterAllocator): (JSC::DFG::ScratchRegisterAllocator::lock): (JSC::DFG::ScratchRegisterAllocator::allocateScratch): (JSC::DFG::ScratchRegisterAllocator::allocateScratchGPR): (JSC::DFG::ScratchRegisterAllocator::allocateScratchFPR): (JSC::DFG::ScratchRegisterAllocator::didReuseRegisters): (JSC::DFG::ScratchRegisterAllocator::preserveReusedRegistersByPushing): (JSC::DFG::ScratchRegisterAllocator::restoreReusedRegistersByPopping): (JSC::DFG::ScratchRegisterAllocator::desiredScratchBufferSize): (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer): (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::writeBarrier): (JSC::DFG::SpeculativeJIT::nonSpeculativeCompare): (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): (JSC::DFG::SpeculativeJIT::compare): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGThunks.cpp: (JSC::DFG::emitPointerValidation): (JSC::DFG::throwExceptionFromCallSlowPathGenerator): (JSC::DFG::slowPathFor): (JSC::DFG::linkForThunkGenerator): (JSC::DFG::linkCallThunkGenerator): (JSC::DFG::linkConstructThunkGenerator): (JSC::DFG::linkClosureCallThunkGenerator): (JSC::DFG::virtualForThunkGenerator): (JSC::DFG::virtualCallThunkGenerator): (JSC::DFG::virtualConstructThunkGenerator): * dfg/DFGThunks.h: * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct): * ftl/FTLOSRExitCompiler.h: * jit/AssemblyHelpers.h: * jit/JIT.cpp: (JSC::JIT::linkFor): (JSC::JIT::linkSlowCall): * jit/JITCall.cpp: (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::privateCompileClosureCall): * jit/JITCall32_64.cpp: (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::privateCompileClosureCall): * jit/JITOperationWrappers.h: Removed. * jit/JITOperations.cpp: Removed. * jit/JITOperations.h: Removed. * jit/RegisterSet.h: Removed. * jit/Repatch.cpp: Removed. * jit/Repatch.h: Removed. * jit/ScratchRegisterAllocator.h: Removed. * jit/ThunkGenerators.cpp: (JSC::generateSlowCaseFor): (JSC::linkForGenerator): (JSC::linkCallGenerator): (JSC::linkConstructGenerator): (JSC::linkClosureCallGenerator): (JSC::virtualForGenerator): (JSC::virtualCallGenerator): (JSC::virtualConstructGenerator): * jit/ThunkGenerators.h: 2013-09-21 Filip Pizlo Move DFG inline caching logic into jit/ https://bugs.webkit.org/show_bug.cgi?id=121749 Rubber stamped by Sam Weinig. We want to get rid of the baseline JIT's inline caching machinery and have it use the DFG's instead. But before we do that we need to move the DFG's inline caching machine out from behind its ENABLE(DFG_JIT) guards and make it available to the whole system. This patch does that: - dfg/DFGRepatch becomes jit/Repatch. - The thunks used by the DFG IC go into jit/ThunkGenerators, instead of dfg/DFGThunks. - The operations used by the DFG IC go into jit/JITOperations, instead of dfg/DFGOperations. - The old JIT's thunk generators for calls are renamed to reduce confusion. Previously it was easy to know which generators belong to which JIT because the old JIT used JSC::virtualCallBlah and the DFG used JSC::DFG::virtualCallBlah, but that's not the case anymore. Note that the old JIT's thunk generators will die in a future patch. No functional changes beyond those moves. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::unlink): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resetStubInternal): * bytecode/StructureStubInfo.h: * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator): (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator): * dfg/DFGJITCompiler.h: * dfg/DFGOSRExitCompiler.h: * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * dfg/DFGOperations.h: (JSC::DFG::operationNewTypedArrayWithSizeForType): (JSC::DFG::operationNewTypedArrayWithOneArgumentForType): * dfg/DFGRegisterSet.h: Removed. * dfg/DFGRepatch.cpp: Removed. * dfg/DFGRepatch.h: Removed. * dfg/DFGScratchRegisterAllocator.h: Removed. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeCompare): (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): (JSC::DFG::SpeculativeJIT::compare): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGThunks.cpp: * dfg/DFGThunks.h: * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::writeBarrier): * jit/JIT.cpp: (JSC::JIT::linkFor): (JSC::JIT::linkSlowCall): * jit/JITCall.cpp: (JSC::JIT::compileCallEval): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::privateCompileClosureCall): * jit/JITCall32_64.cpp: (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::privateCompileClosureCall): * jit/JITOperationWrappers.h: Added. * jit/JITOperations.cpp: Added. * jit/JITOperations.h: Added. * jit/RegisterSet.h: Added. (JSC::RegisterSet::RegisterSet): (JSC::RegisterSet::asPOD): (JSC::RegisterSet::copyInfo): (JSC::RegisterSet::set): (JSC::RegisterSet::setGPRByIndex): (JSC::RegisterSet::clear): (JSC::RegisterSet::get): (JSC::RegisterSet::getGPRByIndex): (JSC::RegisterSet::getFreeGPR): (JSC::RegisterSet::setFPRByIndex): (JSC::RegisterSet::getFPRByIndex): (JSC::RegisterSet::setByIndex): (JSC::RegisterSet::getByIndex): (JSC::RegisterSet::numberOfSetGPRs): (JSC::RegisterSet::numberOfSetFPRs): (JSC::RegisterSet::numberOfSetRegisters): (JSC::RegisterSet::setBit): (JSC::RegisterSet::clearBit): (JSC::RegisterSet::getBit): * jit/Repatch.cpp: Added. (JSC::repatchCall): (JSC::repatchByIdSelfAccess): (JSC::addStructureTransitionCheck): (JSC::replaceWithJump): (JSC::emitRestoreScratch): (JSC::linkRestoreScratch): (JSC::generateProtoChainAccessStub): (JSC::tryCacheGetByID): (JSC::repatchGetByID): (JSC::getPolymorphicStructureList): (JSC::patchJumpToGetByIdStub): (JSC::tryBuildGetByIDList): (JSC::buildGetByIDList): (JSC::appropriateGenericPutByIdFunction): (JSC::appropriateListBuildingPutByIdFunction): (JSC::emitPutReplaceStub): (JSC::emitPutTransitionStub): (JSC::tryCachePutByID): (JSC::repatchPutByID): (JSC::tryBuildPutByIdList): (JSC::buildPutByIdList): (JSC::tryRepatchIn): (JSC::repatchIn): (JSC::linkSlowFor): (JSC::linkFor): (JSC::linkClosureCall): (JSC::resetGetByID): (JSC::resetPutByID): (JSC::resetIn): * jit/Repatch.h: Added. (JSC::resetGetByID): (JSC::resetPutByID): (JSC::resetIn): * jit/ScratchRegisterAllocator.h: Added. (JSC::ScratchRegisterAllocator::ScratchRegisterAllocator): (JSC::ScratchRegisterAllocator::lock): (JSC::ScratchRegisterAllocator::allocateScratch): (JSC::ScratchRegisterAllocator::allocateScratchGPR): (JSC::ScratchRegisterAllocator::allocateScratchFPR): (JSC::ScratchRegisterAllocator::didReuseRegisters): (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing): (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping): (JSC::ScratchRegisterAllocator::desiredScratchBufferSize): (JSC::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer): (JSC::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer): * jit/ThunkGenerators.cpp: (JSC::oldStyleGenerateSlowCaseFor): (JSC::oldStyleLinkForGenerator): (JSC::oldStyleLinkCallGenerator): (JSC::oldStyleLinkConstructGenerator): (JSC::oldStyleLinkClosureCallGenerator): (JSC::oldStyleVirtualForGenerator): (JSC::oldStyleVirtualCallGenerator): (JSC::oldStyleVirtualConstructGenerator): (JSC::emitPointerValidation): (JSC::throwExceptionFromCallSlowPathGenerator): (JSC::slowPathFor): (JSC::linkForThunkGenerator): (JSC::linkCallThunkGenerator): (JSC::linkConstructThunkGenerator): (JSC::linkClosureCallThunkGenerator): (JSC::virtualForThunkGenerator): (JSC::virtualCallThunkGenerator): (JSC::virtualConstructThunkGenerator): * jit/ThunkGenerators.h: 2013-09-21 Anders Carlsson Fix the non-DFG build. * interpreter/Interpreter.cpp: (JSC::unwindCallFrame): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::r): 2013-09-21 Filip Pizlo Get rid of IsInlinedCodeTag and its associated methods since it's unused https://bugs.webkit.org/show_bug.cgi?id=121737 Reviewed by Sam Weinig. This was meant to be easy, but I kept wondering if it was safe to remove the inline call frame check in Arguments::tearOff(). The check was clearly dead since the bit wasn't being set anywhere. It turns out that the unwindCallFrame() function was relying on tearOff() doing the right thing for inlined code, but it wasn't even passing it an inline call frame. I fixed this by having unwindCallFrame() inlining check, while also making sure that the code uses the right operand index for the arguments register. * interpreter/CallFrame.h: * interpreter/CallFrameInlines.h: * interpreter/Interpreter.cpp: (JSC::unwindCallFrame): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::r): * interpreter/StackVisitor.h: * runtime/Arguments.cpp: (JSC::Arguments::tearOff): 2013-09-20 Mark Hahnenberg (un)shiftCountWithAnyIndexingType will start over in the middle of copying if it sees a hole https://bugs.webkit.org/show_bug.cgi?id=121717 Reviewed by Oliver Hunt. This bug caused the array to become corrupted. We now check for holes before we start moving things, and start moving things only once we've determined that there are none. * runtime/JSArray.cpp: (JSC::JSArray::shiftCountWithAnyIndexingType): (JSC::JSArray::unshiftCountWithAnyIndexingType): 2013-09-20 Filip Pizlo REGRESSION(r156047): WebCore hangs inside JSC::toInt32(double) https://bugs.webkit.org/show_bug.cgi?id=121648 Reviewed by Mark Hahnenberg. The Int52<->StrictInt52 conversion did the opposite fill() than what it was supposed to. For example when converting a Int52 to a StrictInt52 it would fill as Int52, and vice-versa. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt52): 2013-09-20 Oliver Hunt REGRESSION(r153215): New iCloud site crashes https://bugs.webkit.org/show_bug.cgi?id=121710 Reviewed by Filip Pizlo. Don't claim to be able to rely on the arguments structure, use the Arguments speculation type * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): 2013-09-20 Mark Hahnenberg Clobberize phase forgets to indicate that it writes GCState for several node types https://bugs.webkit.org/show_bug.cgi?id=121702 Reviewed by Oliver Hunt. Added read and write for GCState to the nodes that could end up allocating (and thereby cause a garbage collection). * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2013-09-19 Filip Pizlo Move CCallHelpers and AssemblyHelpers into jit/ and have JSInterfaceJIT use them https://bugs.webkit.org/show_bug.cgi?id=121637 Rubber stamped by Michael Saboff. Also moved GPRInfo/FPRInfo into jit/. Rolling back in after fixing JIT-only build and tests. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/ValueRecovery.h: (JSC::ValueRecovery::dumpInContext): * dfg/DFGAssemblyHelpers.cpp: Removed. * dfg/DFGAssemblyHelpers.h: Removed. * dfg/DFGBinarySwitch.h: * dfg/DFGByteCodeParser.cpp: * dfg/DFGCCallHelpers.h: Removed. * dfg/DFGDisassembler.cpp: * dfg/DFGFPRInfo.h: Removed. * dfg/DFGGPRInfo.h: Removed. * dfg/DFGGraph.cpp: * dfg/DFGGraph.h: * dfg/DFGJITCompiler.h: * dfg/DFGOSRExit.cpp: * dfg/DFGOSRExit.h: * dfg/DFGOSRExitCompiler.h: * dfg/DFGOSRExitCompilerCommon.h: * dfg/DFGRegisterBank.h: * dfg/DFGRegisterSet.h: * dfg/DFGRepatch.cpp: * dfg/DFGSilentRegisterSavePlan.h: * dfg/DFGThunks.cpp: * dfg/DFGVariableEvent.cpp: * ftl/FTLCArgumentGetter.h: (JSC::FTL::CArgumentGetter::CArgumentGetter): (JSC::FTL::CArgumentGetter::loadNext8): (JSC::FTL::CArgumentGetter::loadNext32): (JSC::FTL::CArgumentGetter::loadNext64): (JSC::FTL::CArgumentGetter::loadNextPtr): (JSC::FTL::CArgumentGetter::loadNextDouble): * ftl/FTLCompile.cpp: * ftl/FTLExitThunkGenerator.h: * ftl/FTLLink.cpp: * ftl/FTLThunks.cpp: * jit/AssemblyHelpers.cpp: Copied from Source/JavaScriptCore/dfg/DFGAssemblyHelpers.cpp. * jit/AssemblyHelpers.h: Copied from Source/JavaScriptCore/dfg/DFGAssemblyHelpers.h. (JSC::AssemblyHelpers::AssemblyHelpers): (JSC::AssemblyHelpers::debugCall): * jit/CCallHelpers.h: Copied from Source/JavaScriptCore/dfg/DFGCCallHelpers.h. * jit/FPRInfo.h: Copied from Source/JavaScriptCore/dfg/DFGFPRInfo.h. (WTF::printInternal): * jit/GPRInfo.h: Copied from Source/JavaScriptCore/dfg/DFGGPRInfo.h. (WTF::printInternal): * jit/JIT.cpp: (JSC::JIT::JIT): * jit/JIT.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::stringGetByValStubGenerator): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::stringGetByValStubGenerator): * jit/JSInterfaceJIT.h: (JSC::JSInterfaceJIT::JSInterfaceJIT): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::SpecializedThunkJIT): (JSC::SpecializedThunkJIT::finalize): * jit/ThunkGenerators.cpp: (JSC::linkForGenerator): (JSC::virtualForGenerator): (JSC::stringLengthTrampolineGenerator): (JSC::nativeForGenerator): (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): * llint/LLIntThunks.cpp: (JSC::LLInt::generateThunkWithJumpTo): * runtime/JSCJSValue.h: 2013-09-20 Allan Sandfeld Jensen Inline method exported https://bugs.webkit.org/show_bug.cgi?id=121664 Reviewed by Darin Adler. WatchDog::didFire() is marked as an exported symbol eventhough it is defined inline. This breaks the build on MinGW since it results in dllimport being declared on a definition. * runtime/Watchdog.h: (JSC::Watchdog::didFire): 2013-09-20 Patrick Gansterer [CMake] Use COMPILE_DEFINITIONS target property for setting BUILDING_* defines https://bugs.webkit.org/show_bug.cgi?id=121672 Reviewed by Gyuyoung Kim. Since the scope of add_definitions() is always a whole file, we need to use target properties instead to set definitions only for specific targets. * CMakeLists.txt: 2013-09-19 Commit Queue Unreviewed, rolling out r156120. http://trac.webkit.org/changeset/156120 https://bugs.webkit.org/show_bug.cgi?id=121651 Broke windows runtime and all tests (Requested by bfulgham on #webkit). * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/ValueRecovery.h: (JSC::ValueRecovery::dumpInContext): * dfg/DFGAssemblyHelpers.cpp: Renamed from Source/JavaScriptCore/jit/AssemblyHelpers.cpp. (JSC::DFG::AssemblyHelpers::executableFor): (JSC::DFG::AssemblyHelpers::decodedCodeMapFor): (JSC::DFG::AssemblyHelpers::setSamplingFlag): (JSC::DFG::AssemblyHelpers::clearSamplingFlag): (JSC::DFG::AssemblyHelpers::jitAssertIsInt32): (JSC::DFG::AssemblyHelpers::jitAssertIsJSInt32): (JSC::DFG::AssemblyHelpers::jitAssertIsJSNumber): (JSC::DFG::AssemblyHelpers::jitAssertIsJSDouble): (JSC::DFG::AssemblyHelpers::jitAssertIsCell): (JSC::DFG::AssemblyHelpers::jitAssertHasValidCallFrame): * dfg/DFGAssemblyHelpers.h: Renamed from Source/JavaScriptCore/jit/AssemblyHelpers.h. (JSC::DFG::AssemblyHelpers::AssemblyHelpers): (JSC::DFG::AssemblyHelpers::codeBlock): (JSC::DFG::AssemblyHelpers::vm): (JSC::DFG::AssemblyHelpers::assembler): (JSC::DFG::AssemblyHelpers::preserveReturnAddressAfterCall): (JSC::DFG::AssemblyHelpers::restoreReturnAddressBeforeReturn): (JSC::DFG::AssemblyHelpers::emitGetFromCallFrameHeaderPtr): (JSC::DFG::AssemblyHelpers::emitPutToCallFrameHeader): (JSC::DFG::AssemblyHelpers::emitPutImmediateToCallFrameHeader): (JSC::DFG::AssemblyHelpers::branchIfNotCell): (JSC::DFG::AssemblyHelpers::addressFor): (JSC::DFG::AssemblyHelpers::tagFor): (JSC::DFG::AssemblyHelpers::payloadFor): (JSC::DFG::AssemblyHelpers::branchIfNotObject): (JSC::DFG::AssemblyHelpers::selectScratchGPR): (JSC::DFG::AssemblyHelpers::debugCall): (JSC::DFG::AssemblyHelpers::jitAssertIsInt32): (JSC::DFG::AssemblyHelpers::jitAssertIsJSInt32): (JSC::DFG::AssemblyHelpers::jitAssertIsJSNumber): (JSC::DFG::AssemblyHelpers::jitAssertIsJSDouble): (JSC::DFG::AssemblyHelpers::jitAssertIsCell): (JSC::DFG::AssemblyHelpers::jitAssertHasValidCallFrame): (JSC::DFG::AssemblyHelpers::boxDouble): (JSC::DFG::AssemblyHelpers::unboxDouble): (JSC::DFG::AssemblyHelpers::boxInt52): (JSC::DFG::AssemblyHelpers::emitExceptionCheck): (JSC::DFG::AssemblyHelpers::emitCount): (JSC::DFG::AssemblyHelpers::globalObjectFor): (JSC::DFG::AssemblyHelpers::strictModeFor): (JSC::DFG::AssemblyHelpers::baselineCodeBlockFor): (JSC::DFG::AssemblyHelpers::baselineCodeBlock): (JSC::DFG::AssemblyHelpers::argumentsRegisterFor): (JSC::DFG::AssemblyHelpers::symbolTableFor): (JSC::DFG::AssemblyHelpers::offsetOfLocals): (JSC::DFG::AssemblyHelpers::offsetOfArgumentsIncludingThis): * dfg/DFGBinarySwitch.h: * dfg/DFGByteCodeParser.cpp: * dfg/DFGCCallHelpers.h: Renamed from Source/JavaScriptCore/jit/CCallHelpers.h. (JSC::DFG::CCallHelpers::CCallHelpers): (JSC::DFG::CCallHelpers::resetCallArguments): (JSC::DFG::CCallHelpers::addCallArgument): (JSC::DFG::CCallHelpers::setupArguments): (JSC::DFG::CCallHelpers::setupArgumentsExecState): (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): (JSC::DFG::CCallHelpers::setupTwoStubArgs): (JSC::DFG::CCallHelpers::setupStubArguments): (JSC::DFG::CCallHelpers::setupResults): * dfg/DFGDisassembler.cpp: * dfg/DFGFPRInfo.h: Renamed from Source/JavaScriptCore/jit/FPRInfo.h. (JSC::DFG::FPRInfo::toRegister): (JSC::DFG::FPRInfo::toIndex): (JSC::DFG::FPRInfo::toArgumentRegister): (JSC::DFG::FPRInfo::debugName): * dfg/DFGGPRInfo.h: Renamed from Source/JavaScriptCore/jit/GPRInfo.h. (JSC::DFG::JSValueRegs::JSValueRegs): (JSC::DFG::JSValueRegs::payloadOnly): (JSC::DFG::JSValueRegs::operator!): (JSC::DFG::JSValueRegs::gpr): (JSC::DFG::JSValueRegs::payloadGPR): (JSC::DFG::JSValueSource::JSValueSource): (JSC::DFG::JSValueSource::unboxedCell): (JSC::DFG::JSValueSource::operator!): (JSC::DFG::JSValueSource::isAddress): (JSC::DFG::JSValueSource::offset): (JSC::DFG::JSValueSource::base): (JSC::DFG::JSValueSource::gpr): (JSC::DFG::JSValueSource::asAddress): (JSC::DFG::JSValueSource::notAddress): (JSC::DFG::JSValueRegs::tagGPR): (JSC::DFG::JSValueSource::tagGPR): (JSC::DFG::JSValueSource::payloadGPR): (JSC::DFG::JSValueSource::hasKnownTag): (JSC::DFG::JSValueSource::tag): (JSC::DFG::GPRInfo::toRegister): (JSC::DFG::GPRInfo::toIndex): (JSC::DFG::GPRInfo::debugName): (JSC::DFG::GPRInfo::toArgumentRegister): * dfg/DFGGraph.cpp: * dfg/DFGGraph.h: * dfg/DFGJITCompiler.h: * dfg/DFGOSRExit.cpp: * dfg/DFGOSRExit.h: * dfg/DFGOSRExitCompiler.h: * dfg/DFGOSRExitCompilerCommon.h: * dfg/DFGRegisterBank.h: * dfg/DFGRegisterSet.h: * dfg/DFGRepatch.cpp: * dfg/DFGSilentRegisterSavePlan.h: * dfg/DFGThunks.cpp: * dfg/DFGVariableEvent.cpp: * ftl/FTLCArgumentGetter.h: (JSC::FTL::CArgumentGetter::CArgumentGetter): (JSC::FTL::CArgumentGetter::loadNext8): (JSC::FTL::CArgumentGetter::loadNext32): (JSC::FTL::CArgumentGetter::loadNext64): (JSC::FTL::CArgumentGetter::loadNextPtr): (JSC::FTL::CArgumentGetter::loadNextDouble): * ftl/FTLCompile.cpp: * ftl/FTLExitThunkGenerator.h: * ftl/FTLLink.cpp: * ftl/FTLThunks.cpp: * jit/JIT.cpp: (JSC::JIT::JIT): * jit/JIT.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::stringGetByValStubGenerator): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::stringGetByValStubGenerator): * jit/JSInterfaceJIT.h: (JSC::JSInterfaceJIT::preserveReturnAddressAfterCall): (JSC::JSInterfaceJIT::restoreReturnAddressBeforeReturn): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::SpecializedThunkJIT): (JSC::SpecializedThunkJIT::finalize): * jit/ThunkGenerators.cpp: (JSC::linkForGenerator): (JSC::virtualForGenerator): (JSC::stringLengthTrampolineGenerator): (JSC::nativeForGenerator): (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): * llint/LLIntThunks.cpp: (JSC::LLInt::generateThunkWithJumpTo): * runtime/JSCJSValue.h: 2013-09-19 Filip Pizlo Unreviewed, fix Windows build part 2. m_jitCodeMap should always be there. * bytecode/CodeBlock.h: (JSC::CodeBlock::jitCodeMap): 2013-09-19 Filip Pizlo Remove some of the tautologies in DFGRepatch function naming. Rubber stamped by Mark Hahnenberg. For example change DFG::dfgLinkFor() to be DFG::linkFor(). * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resetStubInternal): * dfg/DFGOperations.cpp: * dfg/DFGRepatch.cpp: (JSC::DFG::repatchCall): (JSC::DFG::repatchByIdSelfAccess): (JSC::DFG::tryCacheGetByID): (JSC::DFG::repatchGetByID): (JSC::DFG::buildGetByIDList): (JSC::DFG::tryCachePutByID): (JSC::DFG::repatchPutByID): (JSC::DFG::buildPutByIdList): (JSC::DFG::repatchIn): (JSC::DFG::linkFor): (JSC::DFG::linkSlowFor): (JSC::DFG::linkClosureCall): (JSC::DFG::resetGetByID): (JSC::DFG::resetPutByID): (JSC::DFG::resetIn): * dfg/DFGRepatch.h: (JSC::DFG::resetGetByID): (JSC::DFG::resetPutByID): (JSC::DFG::resetIn): 2013-09-19 Filip Pizlo Unreviewed, fix Windows build. ScratchBuffer should always be available regardless of ENABLE_DFG_JIT. * runtime/VM.h: 2013-09-19 Daniel Bates [iOS] Add more iOS logic to the JavaScriptCore build configuration files https://bugs.webkit.org/show_bug.cgi?id=121635 Reviewed by Geoffrey Garen. Towards building JavaScriptCore for both OS X and iOS using the same set of configuration files, add more iOS logic. * Configurations/Base.xcconfig: * Configurations/JSC.xcconfig: * Configurations/JavaScriptCore.xcconfig: * Configurations/ToolExecutable.xcconfig: 2013-09-19 Filip Pizlo Move CCallHelpers and AssemblyHelpers into jit/ and have JSInterfaceJIT use them https://bugs.webkit.org/show_bug.cgi?id=121637 Rubber stamped by Michael Saboff. Also moved GPRInfo/FPRInfo into jit/. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/ValueRecovery.h: (JSC::ValueRecovery::dumpInContext): * dfg/DFGAssemblyHelpers.cpp: Removed. * dfg/DFGAssemblyHelpers.h: Removed. * dfg/DFGBinarySwitch.h: * dfg/DFGByteCodeParser.cpp: * dfg/DFGCCallHelpers.h: Removed. * dfg/DFGDisassembler.cpp: * dfg/DFGFPRInfo.h: Removed. * dfg/DFGGPRInfo.h: Removed. * dfg/DFGGraph.cpp: * dfg/DFGGraph.h: * dfg/DFGJITCompiler.h: * dfg/DFGOSRExit.cpp: * dfg/DFGOSRExit.h: * dfg/DFGOSRExitCompiler.h: * dfg/DFGOSRExitCompilerCommon.h: * dfg/DFGRegisterBank.h: * dfg/DFGRegisterSet.h: * dfg/DFGRepatch.cpp: * dfg/DFGSilentRegisterSavePlan.h: * dfg/DFGThunks.cpp: * dfg/DFGVariableEvent.cpp: * ftl/FTLCArgumentGetter.h: (JSC::FTL::CArgumentGetter::CArgumentGetter): (JSC::FTL::CArgumentGetter::loadNext8): (JSC::FTL::CArgumentGetter::loadNext32): (JSC::FTL::CArgumentGetter::loadNext64): (JSC::FTL::CArgumentGetter::loadNextPtr): (JSC::FTL::CArgumentGetter::loadNextDouble): * ftl/FTLCompile.cpp: * ftl/FTLExitThunkGenerator.h: * ftl/FTLLink.cpp: * ftl/FTLThunks.cpp: * jit/AssemblyHelpers.cpp: Copied from Source/JavaScriptCore/dfg/DFGAssemblyHelpers.cpp. * jit/AssemblyHelpers.h: Copied from Source/JavaScriptCore/dfg/DFGAssemblyHelpers.h. (JSC::AssemblyHelpers::AssemblyHelpers): (JSC::AssemblyHelpers::debugCall): * jit/CCallHelpers.h: Copied from Source/JavaScriptCore/dfg/DFGCCallHelpers.h. * jit/FPRInfo.h: Copied from Source/JavaScriptCore/dfg/DFGFPRInfo.h. (WTF::printInternal): * jit/GPRInfo.h: Copied from Source/JavaScriptCore/dfg/DFGGPRInfo.h. (WTF::printInternal): * jit/JIT.cpp: (JSC::JIT::JIT): * jit/JIT.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::stringGetByValStubGenerator): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::stringGetByValStubGenerator): * jit/JSInterfaceJIT.h: (JSC::JSInterfaceJIT::JSInterfaceJIT): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::SpecializedThunkJIT): (JSC::SpecializedThunkJIT::finalize): * jit/ThunkGenerators.cpp: (JSC::linkForGenerator): (JSC::virtualForGenerator): (JSC::stringLengthTrampolineGenerator): (JSC::nativeForGenerator): (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): * llint/LLIntThunks.cpp: (JSC::LLInt::generateThunkWithJumpTo): * runtime/JSCJSValue.h: 2013-09-19 Daniel Bates [iOS] Substitute UNREACHABLE_FOR_PLATFORM() for RELEASE_ASSERT_NOT_REACHED() Rubber-stamped by Joseph Pecoraro. Use UNREACHABLE_FOR_PLATFORM() instead of RELEASE_ASSERT_NOT_REACHED() in the non-x86/x86-64 variant of JIT::emitSlow_op_mod() so as to avoid a missing noreturn warning in Clang while simultaneously asserting unreachable code. * jit/JITArithmetic.cpp: (JSC::JIT::emitSlow_op_mod): 2013-09-19 Michael Saboff JSC: X86 disassembler shows 16, 32 and 64 bit displacements as unsigned https://bugs.webkit.org/show_bug.cgi?id=121625 Rubber-stamped by Filip Pizlo. Chenged 16, 32 and 64 bit offsets to be signed. Kept the original tab indented spacing to match the rest of the file. * disassembler/udis86/udis86_syn-att.c: (gen_operand): 2013-09-19 Daniel Bates Remove names of unused arguments from the non-x86/x86-64 function prototype for JIT::emitSlow_op_mod() Rubber-stamped by Ryosuke Niwa. * jit/JITArithmetic.cpp: (JSC::JIT::emitSlow_op_mod): 2013-09-18 Sam Weinig Replace use of OwnArrayPtr with std::unique_ptr in JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=121583 Reviewed by Anders Carlsson. * API/JSStringRefCF.cpp: (JSStringCreateWithCFString): * API/JSStringRefQt.cpp: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::dumpDisassembly): * runtime/Arguments.cpp: (JSC::Arguments::tearOff): * runtime/Arguments.h: (JSC::Arguments::isTornOff): (JSC::Arguments::allocateSlowArguments): * runtime/JSPropertyNameIterator.cpp: (JSC::JSPropertyNameIterator::JSPropertyNameIterator): * runtime/JSPropertyNameIterator.h: * runtime/JSSegmentedVariableObject.h: * runtime/JSVariableObject.h: * runtime/PropertyNameArray.h: * runtime/RegExp.cpp: * runtime/StructureChain.h: (JSC::StructureChain::finishCreation): * runtime/SymbolTable.h: (JSC::SharedSymbolTable::setSlowArguments): 2013-09-18 Brent Fulgham [Windows] Unreviewed build fix after r156064. * jsc.cpp: (jscmain): Need a temporary to perform '&' in VS2010. 2013-09-18 Filip Pizlo Give 'jsc' commandline an option to disable deleting the VM. Reviewed by Mark Hahnenberg. * jsc.cpp: (jscmain): * runtime/Options.h: 2013-09-18 Anders Carlsson RefPtrHashMap should work with move only types https://bugs.webkit.org/show_bug.cgi?id=121564 Reviewed by Andreas Kling. * runtime/VM.cpp: (JSC::VM::addSourceProviderCache): 2013-09-17 Mark Hahnenberg Rename OperationInProgress to HeapOperation and move it out of Heap.h into its own header https://bugs.webkit.org/show_bug.cgi?id=121534 Reviewed by Geoffrey Garen. OperationInProgress is a silly name. Many parts of the Heap would like to know what HeapOperation is currently underway, but since they are included in Heap.h they can't directly reference HeapOperation if it also lives in Heap.h. The simplest thing to do is to give HeapOperation its own header. While a bit overkill, it simplifies including it wherever its needed. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): (JSC::CodeBlock::updateAllValueProfilePredictions): (JSC::CodeBlock::updateAllPredictions): * bytecode/CodeBlock.h: (JSC::CodeBlock::updateAllValueProfilePredictions): (JSC::CodeBlock::updateAllPredictions): * bytecode/LazyOperandValueProfile.cpp: (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions): * bytecode/LazyOperandValueProfile.h: * bytecode/ValueProfile.h: (JSC::ValueProfileBase::computeUpdatedPrediction): * heap/Heap.h: * heap/HeapOperation.h: Added. 2013-09-18 Filip Pizlo DFG should support Int52 for local variables https://bugs.webkit.org/show_bug.cgi?id=121064 Reviewed by Oliver Hunt. This adds Int52 support for local variables to the DFG and FTL. It's a speed-up on programs that have local int32 overflows but where a larger int representation can prevent us from having to convert all the way up to double. It's a small speed-up for now. But we're just supporting Int52 for a handful of operations (add, sub, mul, neg, compare, bitops, typed array access) and this lays the groundwork for adding Int52 to JSValue, which will probably be a bigger speed-up. The basic approach is: - We have a notion of Int52 in our typesystem. Int52 doesn't belong to BytecodeTop or HeapTop - i.e. it doesn't arise from JSValues. - DFG treats Int52 as being part of its FullTop and will treat it as being a subtype of double unless instructed otherwise. - Prediction propagator creates Int52s whenever we have a node going doubly but due to large values rather than fractional values, and that node is known to be able to produce Int52 natively in the DFG backend. - Fixup phase converts edges to MachineIntUses in nodes that are known to be able to deal with Int52, and where we have a subtype of Int32|Int52 as the predicted input. - The DFG backend and FTL LLVM IR lowering have two notions of Int52s - ones that are left-shifted by 16 (great for overflow checks) and ones that are sign-extended. Both backends know how to convert between Int52s and the other representations. * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::rshift64): (JSC::MacroAssemblerX86_64::mul64): (JSC::MacroAssemblerX86_64::branchMul64): (JSC::MacroAssemblerX86_64::branchNeg64): (JSC::MacroAssemblerX86_64::convertInt64ToDouble): * assembler/X86Assembler.h: (JSC::X86Assembler::imulq_rr): (JSC::X86Assembler::cvtsi2sdq_rr): * bytecode/DataFormat.h: (JSC::dataFormatToString): * bytecode/ExitKind.cpp: (JSC::exitKindToString): * bytecode/ExitKind.h: * bytecode/OperandsInlines.h: (JSC::::dumpInContext): * bytecode/SpeculatedType.cpp: (JSC::dumpSpeculation): (JSC::speculationToAbbreviatedString): (JSC::speculationFromValue): * bytecode/SpeculatedType.h: (JSC::isInt32SpeculationForArithmetic): (JSC::isInt52Speculation): (JSC::isMachineIntSpeculationForArithmetic): (JSC::isInt52AsDoubleSpeculation): (JSC::isBytecodeRealNumberSpeculation): (JSC::isFullRealNumberSpeculation): (JSC::isBytecodeNumberSpeculation): (JSC::isFullNumberSpeculation): (JSC::isBytecodeNumberSpeculationExpectingDefined): (JSC::isFullNumberSpeculationExpectingDefined): * bytecode/ValueRecovery.h: (JSC::ValueRecovery::alreadyInJSStackAsUnboxedInt52): (JSC::ValueRecovery::inGPR): (JSC::ValueRecovery::displacedInJSStack): (JSC::ValueRecovery::isAlreadyInJSStack): (JSC::ValueRecovery::gpr): (JSC::ValueRecovery::virtualRegister): (JSC::ValueRecovery::dumpInContext): * dfg/DFGAbstractInterpreter.h: (JSC::DFG::AbstractInterpreter::needsTypeCheck): (JSC::DFG::AbstractInterpreter::filterByType): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::set): (JSC::DFG::AbstractValue::checkConsistency): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::couldBeType): (JSC::DFG::AbstractValue::isType): (JSC::DFG::AbstractValue::checkConsistency): (JSC::DFG::AbstractValue::validateType): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine): * dfg/DFGAssemblyHelpers.h: (JSC::DFG::AssemblyHelpers::boxInt52): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeSafe): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::pureCSE): (JSC::DFG::CSEPhase::getByValLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGCommon.h: (JSC::DFG::enableInt52): * dfg/DFGDCEPhase.cpp: (JSC::DFG::DCEPhase::fixupBlock): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::run): (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupSetLocalsInBlock): (JSC::DFG::FixupPhase::fixupUntypedSetLocalsInBlock): (JSC::DFG::FixupPhase::observeUseKindOnNode): (JSC::DFG::FixupPhase::fixEdge): (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd): * dfg/DFGFlushFormat.cpp: (WTF::printInternal): * dfg/DFGFlushFormat.h: (JSC::DFG::resultFor): (JSC::DFG::useKindFor): * dfg/DFGGenerationInfo.h: (JSC::DFG::GenerationInfo::initInt52): (JSC::DFG::GenerationInfo::initStrictInt52): (JSC::DFG::GenerationInfo::isFormat): (JSC::DFG::GenerationInfo::isInt52): (JSC::DFG::GenerationInfo::isStrictInt52): (JSC::DFG::GenerationInfo::fillInt52): (JSC::DFG::GenerationInfo::fillStrictInt52): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: (JSC::DFG::Graph::addShouldSpeculateMachineInt): (JSC::DFG::Graph::mulShouldSpeculateMachineInt): (JSC::DFG::Graph::negateShouldSpeculateMachineInt): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::mergeStateAtTail): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::reconstruct): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::noticeOSREntry): * dfg/DFGMinifiedNode.h: (JSC::DFG::belongsInMinifiedGraph): (JSC::DFG::MinifiedNode::hasChild): * dfg/DFGNode.h: (JSC::DFG::Node::shouldSpeculateNumber): (JSC::DFG::Node::shouldSpeculateNumberExpectingDefined): (JSC::DFG::Node::canSpeculateInt52): * dfg/DFGNodeFlags.h: (JSC::DFG::nodeCanSpeculateInt52): * dfg/DFGNodeType.h: (JSC::DFG::permitsOSRBackwardRewiring): (JSC::DFG::forwardRewiringSelectionScore): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSREntry.h: * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPrediction): (JSC::DFG::PredictionPropagationPhase::propagate): (JSC::DFG::PredictionPropagationPhase::doDoubleVoting): * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): (JSC::DFG::safeToExecute): * dfg/DFGSilentRegisterSavePlan.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR): (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): (JSC::DFG::SpeculativeJIT::compileInlineStart): (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compileAdd): (JSC::DFG::SpeculativeJIT::compileArithSub): (JSC::DFG::SpeculativeJIT::compileArithNegate): (JSC::DFG::SpeculativeJIT::compileArithMul): (JSC::DFG::SpeculativeJIT::compare): (JSC::DFG::SpeculativeJIT::compileStrictEq): (JSC::DFG::SpeculativeJIT::speculateMachineInt): (JSC::DFG::SpeculativeJIT::speculateNumber): (JSC::DFG::SpeculativeJIT::speculateRealNumber): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::canReuse): (JSC::DFG::SpeculativeJIT::isFilled): (JSC::DFG::SpeculativeJIT::isFilledDouble): (JSC::DFG::SpeculativeJIT::use): (JSC::DFG::SpeculativeJIT::isKnownInteger): (JSC::DFG::SpeculativeJIT::isKnownCell): (JSC::DFG::SpeculativeJIT::isKnownNotNumber): (JSC::DFG::SpeculativeJIT::int52Result): (JSC::DFG::SpeculativeJIT::strictInt52Result): (JSC::DFG::SpeculativeJIT::initConstantInfo): (JSC::DFG::SpeculativeJIT::isInteger): (JSC::DFG::SpeculativeJIT::betterUseStrictInt52): (JSC::DFG::SpeculativeJIT::generationInfo): (JSC::DFG::SpeculateInt52Operand::SpeculateInt52Operand): (JSC::DFG::SpeculateInt52Operand::~SpeculateInt52Operand): (JSC::DFG::SpeculateInt52Operand::edge): (JSC::DFG::SpeculateInt52Operand::node): (JSC::DFG::SpeculateInt52Operand::gpr): (JSC::DFG::SpeculateInt52Operand::use): (JSC::DFG::SpeculateStrictInt52Operand::SpeculateStrictInt52Operand): (JSC::DFG::SpeculateStrictInt52Operand::~SpeculateStrictInt52Operand): (JSC::DFG::SpeculateStrictInt52Operand::edge): (JSC::DFG::SpeculateStrictInt52Operand::node): (JSC::DFG::SpeculateStrictInt52Operand::gpr): (JSC::DFG::SpeculateStrictInt52Operand::use): (JSC::DFG::SpeculateWhicheverInt52Operand::SpeculateWhicheverInt52Operand): (JSC::DFG::SpeculateWhicheverInt52Operand::~SpeculateWhicheverInt52Operand): (JSC::DFG::SpeculateWhicheverInt52Operand::edge): (JSC::DFG::SpeculateWhicheverInt52Operand::node): (JSC::DFG::SpeculateWhicheverInt52Operand::gpr): (JSC::DFG::SpeculateWhicheverInt52Operand::use): (JSC::DFG::SpeculateWhicheverInt52Operand::format): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::boxInt52): (JSC::DFG::SpeculativeJIT::fillJSValue): (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateInt52): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compileInt52Compare): (JSC::DFG::SpeculativeJIT::compilePeepHoleInt52Branch): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): (JSC::DFG::isNumerical): * dfg/DFGValueSource.cpp: (JSC::DFG::ValueSource::dump): * dfg/DFGValueSource.h: (JSC::DFG::dataFormatToValueSourceKind): (JSC::DFG::valueSourceKindToDataFormat): (JSC::DFG::ValueSource::forFlushFormat): (JSC::DFG::ValueSource::valueRecovery): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): (JSC::DFG::VariableAccessData::flushFormat): * ftl/FTLCArgumentGetter.cpp: (JSC::FTL::CArgumentGetter::loadNextAndBox): * ftl/FTLCArgumentGetter.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLExitValue.cpp: (JSC::FTL::ExitValue::dumpInContext): * ftl/FTLExitValue.h: (JSC::FTL::ExitValue::inJSStackAsInt52): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::createPhiVariables): (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileUpsilon): (JSC::FTL::LowerDFGToLLVM::compilePhi): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (JSC::FTL::LowerDFGToLLVM::compileAdd): (JSC::FTL::LowerDFGToLLVM::compileArithSub): (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileArithNegate): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::compileCompareEq): (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq): (JSC::FTL::LowerDFGToLLVM::compileCompareLess): (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq): (JSC::FTL::LowerDFGToLLVM::compileCompareGreater): (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq): (JSC::FTL::LowerDFGToLLVM::lowInt32): (JSC::FTL::LowerDFGToLLVM::lowInt52): (JSC::FTL::LowerDFGToLLVM::lowStrictInt52): (JSC::FTL::LowerDFGToLLVM::betterUseStrictInt52): (JSC::FTL::LowerDFGToLLVM::bestInt52Kind): (JSC::FTL::LowerDFGToLLVM::opposite): (JSC::FTL::LowerDFGToLLVM::lowWhicheverInt52): (JSC::FTL::LowerDFGToLLVM::lowCell): (JSC::FTL::LowerDFGToLLVM::lowBoolean): (JSC::FTL::LowerDFGToLLVM::lowDouble): (JSC::FTL::LowerDFGToLLVM::lowJSValue): (JSC::FTL::LowerDFGToLLVM::strictInt52ToInt32): (JSC::FTL::LowerDFGToLLVM::strictInt52ToDouble): (JSC::FTL::LowerDFGToLLVM::strictInt52ToJSValue): (JSC::FTL::LowerDFGToLLVM::setInt52WithStrictValue): (JSC::FTL::LowerDFGToLLVM::strictInt52ToInt52): (JSC::FTL::LowerDFGToLLVM::int52ToStrictInt52): (JSC::FTL::LowerDFGToLLVM::speculateRealNumber): (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock): (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall): (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): (JSC::FTL::LowerDFGToLLVM::setInt52): (JSC::FTL::LowerDFGToLLVM::setStrictInt52): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLOutput.h: (JSC::FTL::Output::addWithOverflow64): (JSC::FTL::Output::subWithOverflow64): (JSC::FTL::Output::mulWithOverflow64): * ftl/FTLValueFormat.cpp: (WTF::printInternal): * ftl/FTLValueFormat.h: * ftl/FTLValueSource.cpp: (JSC::FTL::ValueSource::dump): * ftl/FTLValueSource.h: * interpreter/Register.h: (JSC::Register::unboxedInt52): * runtime/Arguments.cpp: (JSC::Arguments::tearOffForInlineCallFrame): * runtime/IndexingType.cpp: (JSC::leastUpperBoundOfIndexingTypeAndType): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::isMachineInt): (JSC::JSValue::asMachineInt): 2013-09-17 Michael Saboff REGRESSION(r155771): js/stack-overflow-arrity-catch.html is crashing on non-Mac platforms https://bugs.webkit.org/show_bug.cgi?id=121376 Reviewed by Oliver Hunt. Fix stack grow() call for stack growing down. This should catch running out of stack space before we try to move the frame down due to arity mismatch. * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::arityCheckFor): 2013-09-18 Andreas Kling YARR: Put UCS2 canonicalization tables in read-only memory. Reviewed by Sam Weinig. These tables never mutate so mark them const. 2013-09-18 Commit Queue Unreviewed, rolling out r156019 and r156020. http://trac.webkit.org/changeset/156019 http://trac.webkit.org/changeset/156020 https://bugs.webkit.org/show_bug.cgi?id=121540 Broke tests (Requested by ap on #webkit). * assembler/MacroAssemblerX86_64.h: * assembler/X86Assembler.h: * bytecode/DataFormat.h: (JSC::dataFormatToString): * bytecode/ExitKind.cpp: (JSC::exitKindToString): * bytecode/ExitKind.h: * bytecode/OperandsInlines.h: (JSC::::dumpInContext): * bytecode/SpeculatedType.cpp: (JSC::dumpSpeculation): (JSC::speculationToAbbreviatedString): (JSC::speculationFromValue): * bytecode/SpeculatedType.h: (JSC::isInt32SpeculationForArithmetic): (JSC::isInt48Speculation): (JSC::isMachineIntSpeculationForArithmetic): (JSC::isInt48AsDoubleSpeculation): (JSC::isRealNumberSpeculation): (JSC::isNumberSpeculation): (JSC::isNumberSpeculationExpectingDefined): * bytecode/ValueRecovery.h: (JSC::ValueRecovery::inGPR): (JSC::ValueRecovery::displacedInJSStack): (JSC::ValueRecovery::isAlreadyInJSStack): (JSC::ValueRecovery::gpr): (JSC::ValueRecovery::virtualRegister): (JSC::ValueRecovery::dumpInContext): * dfg/DFGAbstractInterpreter.h: (JSC::DFG::AbstractInterpreter::needsTypeCheck): (JSC::DFG::AbstractInterpreter::filterByType): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::set): (JSC::DFG::AbstractValue::checkConsistency): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::validateType): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine): * dfg/DFGAssemblyHelpers.h: (JSC::DFG::AssemblyHelpers::unboxDouble): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeSafe): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::canonicalize): (JSC::DFG::CSEPhase::pureCSE): (JSC::DFG::CSEPhase::getByValLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGCommon.h: * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::run): (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupSetLocalsInBlock): (JSC::DFG::FixupPhase::observeUseKindOnNode): (JSC::DFG::FixupPhase::fixEdge): (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd): * dfg/DFGFlushFormat.cpp: (WTF::printInternal): * dfg/DFGFlushFormat.h: (JSC::DFG::resultFor): (JSC::DFG::useKindFor): * dfg/DFGGenerationInfo.h: (JSC::DFG::GenerationInfo::initInt32): (JSC::DFG::GenerationInfo::fillInt32): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: (JSC::DFG::Graph::addShouldSpeculateMachineInt): (JSC::DFG::Graph::mulShouldSpeculateMachineInt): (JSC::DFG::Graph::negateShouldSpeculateMachineInt): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::mergeStateAtTail): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::reconstruct): * dfg/DFGMinifiedNode.h: (JSC::DFG::belongsInMinifiedGraph): (JSC::DFG::MinifiedNode::hasChild): * dfg/DFGNode.h: (JSC::DFG::Node::shouldSpeculateNumber): (JSC::DFG::Node::shouldSpeculateNumberExpectingDefined): (JSC::DFG::Node::canSpeculateInt48): * dfg/DFGNodeFlags.h: (JSC::DFG::nodeCanSpeculateInt48): * dfg/DFGNodeType.h: (JSC::DFG::forwardRewiringSelectionScore): * dfg/DFGOSRExitCompiler.cpp: (JSC::DFG::shortOperandsDump): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPrediction): (JSC::DFG::PredictionPropagationPhase::propagate): (JSC::DFG::PredictionPropagationPhase::doDoubleVoting): * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): (JSC::DFG::safeToExecute): * dfg/DFGSilentRegisterSavePlan.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR): (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): (JSC::DFG::SpeculativeJIT::compileInlineStart): (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compileAdd): (JSC::DFG::SpeculativeJIT::compileArithSub): (JSC::DFG::SpeculativeJIT::compileArithNegate): (JSC::DFG::SpeculativeJIT::compileArithMul): (JSC::DFG::SpeculativeJIT::compare): (JSC::DFG::SpeculativeJIT::compileStrictEq): (JSC::DFG::SpeculativeJIT::speculateNumber): (JSC::DFG::SpeculativeJIT::speculateRealNumber): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::canReuse): (JSC::DFG::SpeculativeJIT::isFilled): (JSC::DFG::SpeculativeJIT::isFilledDouble): (JSC::DFG::SpeculativeJIT::use): (JSC::DFG::SpeculativeJIT::boxDouble): (JSC::DFG::SpeculativeJIT::isKnownInteger): (JSC::DFG::SpeculativeJIT::isKnownCell): (JSC::DFG::SpeculativeJIT::isKnownNotNumber): (JSC::DFG::SpeculativeJIT::int32Result): (JSC::DFG::SpeculativeJIT::initConstantInfo): (JSC::DFG::SpeculativeJIT::isInteger): (JSC::DFG::SpeculativeJIT::generationInfoFromVirtualRegister): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillJSValue): (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): (JSC::DFG::isNumerical): * dfg/DFGValueSource.cpp: (JSC::DFG::ValueSource::dump): * dfg/DFGValueSource.h: (JSC::DFG::dataFormatToValueSourceKind): (JSC::DFG::valueSourceKindToDataFormat): (JSC::DFG::ValueSource::forFlushFormat): (JSC::DFG::ValueSource::valueRecovery): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): (JSC::DFG::VariableAccessData::flushFormat): * ftl/FTLCArgumentGetter.cpp: (JSC::FTL::CArgumentGetter::loadNextAndBox): * ftl/FTLCArgumentGetter.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLExitValue.cpp: (JSC::FTL::ExitValue::dumpInContext): * ftl/FTLExitValue.h: * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::createPhiVariables): (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileUpsilon): (JSC::FTL::LowerDFGToLLVM::compilePhi): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (JSC::FTL::LowerDFGToLLVM::compileAdd): (JSC::FTL::LowerDFGToLLVM::compileArithSub): (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileArithNegate): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::compileCompareEq): (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq): (JSC::FTL::LowerDFGToLLVM::compileCompareLess): (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq): (JSC::FTL::LowerDFGToLLVM::compileCompareGreater): (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq): (JSC::FTL::LowerDFGToLLVM::lowInt32): (JSC::FTL::LowerDFGToLLVM::lowCell): (JSC::FTL::LowerDFGToLLVM::lowBoolean): (JSC::FTL::LowerDFGToLLVM::lowDouble): (JSC::FTL::LowerDFGToLLVM::lowJSValue): (JSC::FTL::LowerDFGToLLVM::speculateRealNumber): (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock): (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall): (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): (JSC::FTL::LowerDFGToLLVM::setInt32): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLOutput.h: (JSC::FTL::Output::mulWithOverflow32): * ftl/FTLValueFormat.cpp: (WTF::printInternal): * ftl/FTLValueFormat.h: * ftl/FTLValueSource.cpp: (JSC::FTL::ValueSource::dump): * ftl/FTLValueSource.h: * interpreter/Register.h: * runtime/Arguments.cpp: (JSC::Arguments::tearOffForInlineCallFrame): * runtime/IndexingType.cpp: (JSC::leastUpperBoundOfIndexingTypeAndType): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: 2013-09-17 Filip Pizlo Unreviewed, fix 32-bit build. * runtime/JSCJSValue.h: 2013-09-16 Filip Pizlo DFG should support Int52 for local variables https://bugs.webkit.org/show_bug.cgi?id=121064 Reviewed by Oliver Hunt. This adds Int52 support for local variables to the DFG and FTL. It's a speed-up on programs that have local int32 overflows but where a larger int representation can prevent us from having to convert all the way up to double. It's a small speed-up for now. But we're just supporting Int52 for a handful of operations (add, sub, mul, neg, compare, bitops, typed array access) and this lays the groundwork for adding Int52 to JSValue, which will probably be a bigger speed-up. The basic approach is: - We have a notion of Int52 in our typesystem. Int52 doesn't belong to BytecodeTop or HeapTop - i.e. it doesn't arise from JSValues. - DFG treats Int52 as being part of its FullTop and will treat it as being a subtype of double unless instructed otherwise. - Prediction propagator creates Int52s whenever we have a node going doubly but due to large values rather than fractional values, and that node is known to be able to produce Int52 natively in the DFG backend. - Fixup phase converts edges to MachineIntUses in nodes that are known to be able to deal with Int52, and where we have a subtype of Int32|Int52 as the predicted input. - The DFG backend and FTL LLVM IR lowering have two notions of Int52s - ones that are left-shifted by 16 (great for overflow checks) and ones that are sign-extended. Both backends know how to convert between Int52s and the other representations. * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::rshift64): (JSC::MacroAssemblerX86_64::mul64): (JSC::MacroAssemblerX86_64::branchMul64): (JSC::MacroAssemblerX86_64::branchNeg64): (JSC::MacroAssemblerX86_64::convertInt64ToDouble): * assembler/X86Assembler.h: (JSC::X86Assembler::imulq_rr): (JSC::X86Assembler::cvtsi2sdq_rr): * bytecode/DataFormat.h: (JSC::dataFormatToString): * bytecode/OperandsInlines.h: (JSC::::dumpInContext): * bytecode/SpeculatedType.cpp: (JSC::dumpSpeculation): (JSC::speculationToAbbreviatedString): (JSC::speculationFromValue): * bytecode/SpeculatedType.h: (JSC::isInt32SpeculationForArithmetic): (JSC::isMachineIntSpeculationForArithmetic): (JSC::isBytecodeRealNumberSpeculation): (JSC::isFullRealNumberSpeculation): (JSC::isBytecodeNumberSpeculation): (JSC::isFullNumberSpeculation): (JSC::isBytecodeNumberSpeculationExpectingDefined): (JSC::isFullNumberSpeculationExpectingDefined): * bytecode/ValueRecovery.h: (JSC::ValueRecovery::alreadyInJSStackAsUnboxedInt52): (JSC::ValueRecovery::inGPR): (JSC::ValueRecovery::displacedInJSStack): (JSC::ValueRecovery::isAlreadyInJSStack): (JSC::ValueRecovery::gpr): (JSC::ValueRecovery::virtualRegister): (JSC::ValueRecovery::dumpInContext): * dfg/DFGAbstractInterpreter.h: (JSC::DFG::AbstractInterpreter::needsTypeCheck): (JSC::DFG::AbstractInterpreter::filterByType): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::set): (JSC::DFG::AbstractValue::checkConsistency): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::couldBeType): (JSC::DFG::AbstractValue::isType): (JSC::DFG::AbstractValue::checkConsistency): (JSC::DFG::AbstractValue::validateType): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine): * dfg/DFGAssemblyHelpers.h: (JSC::DFG::AssemblyHelpers::boxInt52): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::pureCSE): (JSC::DFG::CSEPhase::getByValLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGCommon.h: (JSC::DFG::enableInt52): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::run): (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupSetLocalsInBlock): (JSC::DFG::FixupPhase::fixupUntypedSetLocalsInBlock): (JSC::DFG::FixupPhase::observeUseKindOnNode): (JSC::DFG::FixupPhase::fixEdge): (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd): * dfg/DFGFlushFormat.cpp: (WTF::printInternal): * dfg/DFGFlushFormat.h: (JSC::DFG::resultFor): (JSC::DFG::useKindFor): * dfg/DFGGenerationInfo.h: (JSC::DFG::GenerationInfo::initInt52): (JSC::DFG::GenerationInfo::initStrictInt52): (JSC::DFG::GenerationInfo::isFormat): (JSC::DFG::GenerationInfo::isInt52): (JSC::DFG::GenerationInfo::isStrictInt52): (JSC::DFG::GenerationInfo::fillInt52): (JSC::DFG::GenerationInfo::fillStrictInt52): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: (JSC::DFG::Graph::addShouldSpeculateMachineInt): (JSC::DFG::Graph::mulShouldSpeculateMachineInt): (JSC::DFG::Graph::negateShouldSpeculateMachineInt): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::mergeStateAtTail): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::reconstruct): * dfg/DFGMinifiedNode.h: (JSC::DFG::belongsInMinifiedGraph): (JSC::DFG::MinifiedNode::hasChild): * dfg/DFGNode.h: (JSC::DFG::Node::shouldSpeculateNumber): (JSC::DFG::Node::shouldSpeculateNumberExpectingDefined): * dfg/DFGNodeFlags.h: * dfg/DFGNodeType.h: (JSC::DFG::forwardRewiringSelectionScore): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPrediction): (JSC::DFG::PredictionPropagationPhase::propagate): (JSC::DFG::PredictionPropagationPhase::doDoubleVoting): * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): (JSC::DFG::safeToExecute): * dfg/DFGSilentRegisterSavePlan.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR): (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): (JSC::DFG::SpeculativeJIT::compileInlineStart): (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compileAdd): (JSC::DFG::SpeculativeJIT::compileArithSub): (JSC::DFG::SpeculativeJIT::compileArithNegate): (JSC::DFG::SpeculativeJIT::compileArithMul): (JSC::DFG::SpeculativeJIT::compare): (JSC::DFG::SpeculativeJIT::compileStrictEq): (JSC::DFG::SpeculativeJIT::speculateMachineInt): (JSC::DFG::SpeculativeJIT::speculateNumber): (JSC::DFG::SpeculativeJIT::speculateRealNumber): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::canReuse): (JSC::DFG::SpeculativeJIT::isFilled): (JSC::DFG::SpeculativeJIT::isFilledDouble): (JSC::DFG::SpeculativeJIT::use): (JSC::DFG::SpeculativeJIT::isKnownInteger): (JSC::DFG::SpeculativeJIT::isKnownCell): (JSC::DFG::SpeculativeJIT::isKnownNotNumber): (JSC::DFG::SpeculativeJIT::int52Result): (JSC::DFG::SpeculativeJIT::strictInt52Result): (JSC::DFG::SpeculativeJIT::initConstantInfo): (JSC::DFG::SpeculativeJIT::isInteger): (JSC::DFG::SpeculativeJIT::betterUseStrictInt52): (JSC::DFG::SpeculativeJIT::generationInfo): (JSC::DFG::SpeculateInt52Operand::SpeculateInt52Operand): (JSC::DFG::SpeculateInt52Operand::~SpeculateInt52Operand): (JSC::DFG::SpeculateInt52Operand::edge): (JSC::DFG::SpeculateInt52Operand::node): (JSC::DFG::SpeculateInt52Operand::gpr): (JSC::DFG::SpeculateInt52Operand::use): (JSC::DFG::SpeculateStrictInt52Operand::SpeculateStrictInt52Operand): (JSC::DFG::SpeculateStrictInt52Operand::~SpeculateStrictInt52Operand): (JSC::DFG::SpeculateStrictInt52Operand::edge): (JSC::DFG::SpeculateStrictInt52Operand::node): (JSC::DFG::SpeculateStrictInt52Operand::gpr): (JSC::DFG::SpeculateStrictInt52Operand::use): (JSC::DFG::SpeculateWhicheverInt52Operand::SpeculateWhicheverInt52Operand): (JSC::DFG::SpeculateWhicheverInt52Operand::~SpeculateWhicheverInt52Operand): (JSC::DFG::SpeculateWhicheverInt52Operand::edge): (JSC::DFG::SpeculateWhicheverInt52Operand::node): (JSC::DFG::SpeculateWhicheverInt52Operand::gpr): (JSC::DFG::SpeculateWhicheverInt52Operand::use): (JSC::DFG::SpeculateWhicheverInt52Operand::format): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::boxInt52): (JSC::DFG::SpeculativeJIT::fillJSValue): (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateInt52): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compileInt52Compare): (JSC::DFG::SpeculativeJIT::compilePeepHoleInt52Branch): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): (JSC::DFG::isNumerical): * dfg/DFGValueSource.cpp: (JSC::DFG::ValueSource::dump): * dfg/DFGValueSource.h: (JSC::DFG::dataFormatToValueSourceKind): (JSC::DFG::valueSourceKindToDataFormat): (JSC::DFG::ValueSource::forFlushFormat): (JSC::DFG::ValueSource::valueRecovery): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): (JSC::DFG::VariableAccessData::flushFormat): * ftl/FTLCArgumentGetter.cpp: (JSC::FTL::CArgumentGetter::loadNextAndBox): * ftl/FTLCArgumentGetter.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLExitValue.cpp: (JSC::FTL::ExitValue::dumpInContext): * ftl/FTLExitValue.h: (JSC::FTL::ExitValue::inJSStackAsInt52): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::createPhiVariables): (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileUpsilon): (JSC::FTL::LowerDFGToLLVM::compilePhi): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (JSC::FTL::LowerDFGToLLVM::compileAdd): (JSC::FTL::LowerDFGToLLVM::compileArithSub): (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileArithNegate): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::compileCompareEq): (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq): (JSC::FTL::LowerDFGToLLVM::compileCompareLess): (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq): (JSC::FTL::LowerDFGToLLVM::compileCompareGreater): (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq): (JSC::FTL::LowerDFGToLLVM::lowInt32): (JSC::FTL::LowerDFGToLLVM::lowInt52): (JSC::FTL::LowerDFGToLLVM::lowStrictInt52): (JSC::FTL::LowerDFGToLLVM::betterUseStrictInt52): (JSC::FTL::LowerDFGToLLVM::bestInt52Kind): (JSC::FTL::LowerDFGToLLVM::opposite): (JSC::FTL::LowerDFGToLLVM::Int52s::operator[]): (JSC::FTL::LowerDFGToLLVM::lowWhicheverInt52): (JSC::FTL::LowerDFGToLLVM::lowWhicheverInt52s): (JSC::FTL::LowerDFGToLLVM::lowOpposingInt52s): (JSC::FTL::LowerDFGToLLVM::lowCell): (JSC::FTL::LowerDFGToLLVM::lowBoolean): (JSC::FTL::LowerDFGToLLVM::lowDouble): (JSC::FTL::LowerDFGToLLVM::lowJSValue): (JSC::FTL::LowerDFGToLLVM::strictInt52ToInt32): (JSC::FTL::LowerDFGToLLVM::strictInt52ToDouble): (JSC::FTL::LowerDFGToLLVM::strictInt52ToJSValue): (JSC::FTL::LowerDFGToLLVM::setInt52WithStrictValue): (JSC::FTL::LowerDFGToLLVM::strictInt52ToInt52): (JSC::FTL::LowerDFGToLLVM::int52ToStrictInt52): (JSC::FTL::LowerDFGToLLVM::speculateRealNumber): (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock): (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall): (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): (JSC::FTL::LowerDFGToLLVM::setInt52): (JSC::FTL::LowerDFGToLLVM::setStrictInt52): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLOutput.h: (JSC::FTL::Output::addWithOverflow64): (JSC::FTL::Output::subWithOverflow64): (JSC::FTL::Output::mulWithOverflow64): * ftl/FTLValueFormat.cpp: (WTF::printInternal): * ftl/FTLValueFormat.h: * ftl/FTLValueSource.cpp: (JSC::FTL::ValueSource::dump): * ftl/FTLValueSource.h: * interpreter/Register.h: (JSC::Register::unboxedInt52): * runtime/Arguments.cpp: (JSC::Arguments::tearOffForInlineCallFrame): * runtime/IndexingType.cpp: (JSC::leastUpperBoundOfIndexingTypeAndType): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::isMachineInt): (JSC::JSValue::asMachineInt): 2013-09-17 Filip Pizlo Use CheckStructure for checking the types of typed arrays whenever possible https://bugs.webkit.org/show_bug.cgi?id=121514 Reviewed by Oliver Hunt. * bytecode/ArrayProfile.cpp: (JSC::ArrayProfile::computeUpdatedPrediction): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::fromObserved): (JSC::DFG::ArrayMode::refine): (JSC::DFG::ArrayMode::originalArrayStructure): (JSC::DFG::arrayClassToString): * dfg/DFGArrayMode.h: (JSC::DFG::ArrayMode::ArrayMode): (JSC::DFG::ArrayMode::arrayModesWithIndexingShape): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::isOriginalTypedArrayStructure): 2013-09-17 Filip Pizlo DFG should use the (x & 0x7fffffff) trick for doing overflow and neg-zero checks on negation in one go https://bugs.webkit.org/show_bug.cgi?id=121520 Reviewed by Oliver Hunt. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithNegate): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileArithNegate): 2013-09-17 Andreas Kling Pack create_hash_table tables better. Reviewed by Sam Weinig. Reduces JavaScriptCore binary size by 4648 bytes. * create_hash_table: * runtime/Lookup.h: Reorder HashTableValue members to avoid unnecessary padding. 2013-09-17 Mark Hahnenberg DFG doesn't properly keep scope alive for op_put_to_scope https://bugs.webkit.org/show_bug.cgi?id=121519 Reviewed by Michael Saboff. This was a latent bug that can't actually occur in ToT. It was uncovered by causing slow path calls in the baseline JIT for op_put_to_scope in places where we couldn't before (but which were necessary for gen GC). * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): 2013-09-17 Filip Pizlo Don't GC while OSR compiling https://bugs.webkit.org/show_bug.cgi?id=121513 Reviewed by Mark Hahnenberg. Fixes some rare crashes that I see in ConservativeRoots, while in a GC from OSR exit compilation. * dfg/DFGOSRExitCompiler.cpp: * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileFTLOSRExit): 2013-09-17 Alberto Garcia Unreviewed make distcheck fix. * GNUmakefile.list.am: 2013-09-13 Mark Hahnenberg MarkedBlocks shouldn't be put in Allocated state if they didn't produce a FreeList https://bugs.webkit.org/show_bug.cgi?id=121236 Reviewed by Geoffrey Garen. Right now, after a collection all MarkedBlocks are in the Marked block state. When lazy sweeping happens, if a block returns an empty free list after being swept, we call didConsumeFreeList(), which moves the block into the Allocated block state. This happens to both the block that was just being allocated out of (i.e. m_currentBlock) as well as any blocks who are completely full. We should distinguish between these two cases: m_currentBlock should transition to Allocated (because we were just allocating out of it) and any subsequent block that returns an empty free list should transition back to the Marked state. This will make the block state more consistent with the actual state the block is in, and it will also allow us to speed up moving all blocks the the Marked state during generational collection. Added new RAII-style HeapIterationScope class that notifies the Heap when it is about to be iterated and when iteration has finished. Any clients that need accurate liveness data when iterating over the Heap now need to use a HeapIterationScope so that the state of Heap can be properly restored after they are done iterating. No new GC-allocated objects can be created until this object goes out of scope. * JavaScriptCore.xcodeproj/project.pbxproj: * debugger/Debugger.cpp: (JSC::Debugger::recompileAllJSFunctions): Added HeapIterationScope for the Recompiler iteration. * heap/Heap.cpp: (JSC::Heap::willStartIterating): Callback used by HeapIterationScope to indicate that iteration of the Heap is about to begin. This will cause cell liveness data to be canonicalized by calling stopAllocating. (JSC::Heap::didFinishIterating): Same, but indicates that iteration has finished. (JSC::Heap::globalObjectCount): Used HeapIterationScope. (JSC::Heap::objectTypeCounts): Ditto. (JSC::Heap::markDeadObjects): Ditto. (JSC::Heap::zombifyDeadObjects): Ditto. * heap/Heap.h: * heap/HeapIterationScope.h: Added. New RAII-style object for indicating to the Heap that it's about to be iterated or that iteration has finished. (JSC::HeapIterationScope::HeapIterationScope): (JSC::HeapIterationScope::~HeapIterationScope): * heap/HeapStatistics.cpp: (JSC::HeapStatistics::showObjectStatistics): Used new HeapIterationScope. * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateHelper): We now treat the case where we have just finished allocating out of the current block differently from the case where we sweep a block and it returns an empty free list. This was the primary point of this patch. (JSC::MarkedAllocator::allocateSlowCase): ASSERT that nobody is currently iterating the Heap when allocating. * heap/MarkedAllocator.h: (JSC::MarkedAllocator::reset): All allocators are reset after every collection. We need to make sure that the m_lastActiveBlock gets cleared, which it might not always because we don't call takeCanonicalizedBlock on blocks in the large allocators. (JSC::MarkedAllocator::stopAllocating): We shouldn't already have a last active block, so ASSERT as much. (JSC::MarkedAllocator::resumeAllocating): Do the opposite of what stopAllocating does. So, if we don't have a m_lastActiveBlock then we don't have to worry about undoing anything done by stopAllocating. If we do, then we call resumeAllocating on the block, which returns the FreeList as it was prior to stopping allocation. We then set the current block to the last active block and clear the last active block. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::resumeAllocating): Any block resuming allocation should be in the Marked state, so ASSERT as much. We always allocate a m_newlyAllocated Bitmap if we're FreeListed, so if we didn't allocate one then we know we were Marked when allocation was stopped, so just return early with an empty FreeList. If we do have a non-null m_newlyAllocated Bitmap then we need to be swept in order to rebuild our FreeList. * heap/MarkedBlock.h: (JSC::MarkedBlock::didConsumeEmptyFreeList): This is called if we ever sweep a block and get back an empty free list. Instead of transitioning to the Allocated state, we now go straight back to the Marked state. This makes sense because we weren't actually allocated out of, so we shouldn't be in the allocated state. Also added some ASSERTs to make sure that we're in the state that we expect: all of our mark bits should be set and we should not have a m_newlyAllocated Bitmap. * heap/MarkedSpace.cpp: (JSC::MarkedSpace::MarkedSpace): (JSC::MarkedSpace::forEachAllocator): Added a new functor-style iteration method so that we can easily iterate over each allocator for, e.g., stopping and resuming allocators without duplicating code. (JSC::StopAllocatingFunctor::operator()): New functors for use with forEachAllocator. (JSC::MarkedSpace::stopAllocating): Ditto. (JSC::ResumeAllocatingFunctor::operator()): Ditto. (JSC::MarkedSpace::resumeAllocating): Ditto. (JSC::MarkedSpace::willStartIterating): Callback that notifies MarkedSpace that it is being iterated. Does some ASSERTs, sets a flag, canonicalizes cell liveness data by calling stopAllocating. (JSC::MarkedSpace::didFinishIterating): Ditto, but to signal that iteration has completed. * heap/MarkedSpace.h: (JSC::MarkedSpace::iterationInProgress): Returns true if a HeapIterationScope is currently active. (JSC::MarkedSpace::forEachLiveCell): Accepts a HeapIterationScope to enforce the rule that you have to create one prior to iterating over the Heap. (JSC::MarkedSpace::forEachDeadCell): Ditto. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::haveABadTime): Changed to use new HeapIterationScope. * runtime/VM.cpp: (JSC::VM::releaseExecutableMemory): Ditto. 2013-09-16 Filip Pizlo Inlining should work in debug mode (i.e. Executable::newCodeBlock() should call recordParse()) https://bugs.webkit.org/show_bug.cgi?id=121444 Reviewed by Mark Hahnenberg. * dfg/DFGArgumentPosition.h: Fix a bug discovered by reenabling inlining. ArgumentPosition may point to the non-canonical VariableAccessData but users of someVariable() want the canonical one. (JSC::DFG::ArgumentPosition::someVariable): * runtime/Executable.cpp: Call recordParse() so that the Executable knows things about itself (like if it has captured variables). Otherwise those fields are uninitialized. (JSC::ScriptExecutable::newCodeBlockFor): 2013-09-16 Balazs Kilvady Aligned argument signatures of setupArgumentsWithExecState are missing on MIPS. https://bugs.webkit.org/show_bug.cgi?id=121439 Reviewed by Geoffrey Garen. Missing implementations of setupArgumentsWithExecState added. * dfg/DFGCCallHelpers.h: (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): 2013-09-16 Julien Brianceau [sh4] Fix typo in subp implementation in LLINT. https://bugs.webkit.org/show_bug.cgi?id=121438 Reviewed by Andreas Kling. * offlineasm/sh4.rb: 2013-09-16 Julien Brianceau [sh4] Handle subp opcode with 3 operands and bpbeq opcode in LLINT. https://bugs.webkit.org/show_bug.cgi?id=121412 Reviewed by Andreas Kling. * offlineasm/sh4.rb: 2013-09-15 Gustavo Noronha Silva Unreviewed make distcheck fix. * GNUmakefile.list.am: 2013-09-15 Filip Pizlo Deoptimize deoptimization: make DFGOSRExitCompiler64.cpp more hackable https://bugs.webkit.org/show_bug.cgi?id=121374 Reviewed by Geoffrey Garen. This reduces the size of DFGOSRExitCompiler64.cpp by almost 50%, and makes it super easy to add new recovery kinds. For recoveries that involve reboxing, it allows you to keep most of the code common between the on-stack and in-reg cases: they all get funneled through the "load from scratch buffer, convert, and then store to stack" logic. This opens up a bunch of possibilities. It'll make adding Int48 much easier, and it probably will come in handy as we do various DFG stack layout changes in support of the FTL. * bytecode/ValueRecovery.h: (JSC::ValueRecovery::dumpInContext): (JSC::ValueRecovery::dump): * dfg/DFGOSRExitCompiler.cpp: (JSC::DFG::shortOperandsDump): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): 2013-09-14 Filip Pizlo It should be easy to add new nodes that do OSR forward rewiring in both DFG and FTL https://bugs.webkit.org/show_bug.cgi?id=121371 Reviewed by Sam Weinig. Forward rewiring is a tricky part of OSR that handles the following: a: Something(...) SetLocal(@a, locX) b: Int32ToDouble(@a) c: SomethingThatExits(@b) Note that at @c, OSR will think that locX->@a, but @a will be dead. So it must be smart enough to find @b, which contains an equivalent value. It must do this for any identity functions we support. Currently we support four such functions. Currently the code for doing this is basically duplicated between the DFG and the FTL. Also both versions of the code have some really weirdly written logic for picking the "best" identity function to use. We should fix this by simply having a way to ask "is this node an identity function, and if so, then how good is it?" Then both the DFG and FTL could use this and have no hard-wired knowledge of those identity functions. While we're at it, this also changes some terminology because I found the use of the word "needs" confusing. Note that this retains the somewhat confusing behavior that we don't search all possible forward/backward uses. We only search one step in each direction. This is because we only need to handle cases that FixupPhase and the parser insert. All other code that tries to insert intermediate conversion nodes should ensure to Phantom the original node. For example, the following transformation is illegal: Before: x: SomethingThatExits(@a) After: w: Conversion(@a) x: SomethingThatExits(@w) The correct form of that transformation is one of these: Correct #1: v: DoAllChecks(@a) // exit here w: Conversion(@a) x: Something(@w) // no exit Correct #2: w: Conversion(@a) x: SomethingThatExits(@w) y: Phantom(@a) Correct #3: w: Conversion(@a) x: SomethingThatExits(@w, @a) Note that we use #3 for some heap accesses, but of course it requires that the node you're using has an extra slot for a "dummy" use child. Broadly speaking though, such transformations should be relegated to something below DFG IR, like LLVM IR. * dfg/DFGNodeType.h: (JSC::DFG::forwardRewiringSelectionScore): (JSC::DFG::needsOSRForwardRewiring): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): 2013-09-14 Filip Pizlo Rename IntegerBranch/IntegerCompare to Int32Branch/Int32Compare. Rubber stamped by Mark Hahnenberg. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePeepHoleInt32Branch): (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): (JSC::DFG::SpeculativeJIT::compare): (JSC::DFG::SpeculativeJIT::compileStrictEq): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compileInt32Compare): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileInt32Compare): 2013-09-13 Filip Pizlo Rename SpeculativeJIT::integerResult() to int32Result(). Rubber stamped by Mark Hahnenberg. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt): (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compileAdd): (JSC::DFG::SpeculativeJIT::compileArithSub): (JSC::DFG::SpeculativeJIT::compileArithNegate): (JSC::DFG::SpeculativeJIT::compileArithIMul): (JSC::DFG::SpeculativeJIT::compileArithMul): (JSC::DFG::SpeculativeJIT::compileArithDiv): (JSC::DFG::SpeculativeJIT::compileArithMod): (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): (JSC::DFG::SpeculativeJIT::compileGetArrayLength): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::int32Result): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2013-09-13 Michael Saboff FTL JIT broke after r155711 https://bugs.webkit.org/show_bug.cgi?id=121332 Reviewed by Geoffrey Garen. Fixed OSR entry to use the local variable's index instead of its VirtualRegister. Initialized ExitArgumentForOperand::m_operand to InvalidVirtualRegister instead of -1. Fixed compileCallOrConstruct() to update locals on callframe going down. Fixed prepareOSREntry() to grow stack down if needed. * ftl/FTLExitArgumentForOperand.h: (JSC::FTL::ExitArgumentForOperand::ExitArgumentForOperand): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileExtractOSREntryLocal): (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): 2013-09-13 Anders Carlsson Avoid a couple of zero-sized fastMalloc calls https://bugs.webkit.org/show_bug.cgi?id=121333 Reviewed by Geoffrey Garen. * API/JSStringRefCF.cpp: (JSStringCopyCFString): Return an empty constant CFStringRef if the JSStringRef is empty. * runtime/JSPropertyNameIterator.cpp: (JSC::JSPropertyNameIterator::JSPropertyNameIterator): Don't allocate an empty m_jsStrings array if m_jsStringsSize is 0. 2013-09-13 Filip Pizlo DFG AI assumes that ToThis can never return non-object if it is passed an object, and operationToThis will get the wrong value of isStrictMode() if there's inlining https://bugs.webkit.org/show_bug.cgi?id=121330 Reviewed by Mark Hahnenberg and Oliver Hunt. Also print whether a function is strict mode in debug dumps. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpAssumingJITType): * bytecode/CodeOrigin.cpp: (JSC::InlineCallFrame::dumpInContext): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2013-09-13 Anders Carlsson Use nullptr instead of 0 in calls to HashMap::add https://bugs.webkit.org/show_bug.cgi?id=121322 Reviewed by Sam Weinig. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitLoad): (JSC::BytecodeGenerator::addStringConstant): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::cellConstant): 2013-09-13 Oliver Hunt Try to kill initialiser expression in for-in statements https://bugs.webkit.org/show_bug.cgi?id=121311 Reviewed by Gavin Barraclough. We'd like to get rid of this pointless initialiser expression in for-in statements. Unfortunately we have to keep the no_in variant of expression parsing to avoid ambiguity in the grammar. There's a possibility that this will need to be rolled out, but we'll need to live on it to see. * bytecompiler/NodesCodegen.cpp: (JSC::ForInNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createForInLoop): * parser/NodeConstructors.h: (JSC::ForInNode::ForInNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::::parseForStatement): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createForInLoop): 2013-09-12 Michael Saboff fourthTier: Change JSStack to grow from high to low addresses https://bugs.webkit.org/show_bug.cgi?id=118758 Reviewed by Oliver Hunt. Changed the JSC stack to grow down. Effectively the JSC stack frame is flipped from what it was. See JSStack.h for the new offsets. Changed JSStack begin() and end() to be getBaseOfStack() and getLimitOfStack(). Most of the changes are address or offset calculation changes. Decoupled a local register ordinal (loop variable or array index) from the offset into the callFrame using localToOperand() and the inverse operandToLocal(). * assembler/MacroAssembler.h: (JSC::MacroAssembler::trustedImm32ForShift): (JSC::MacroAssembler::lshiftPtr): Added to create scaled addresses with a negative index * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::lshift64): Added to create scaled addresses with a negative index * assembler/X86Assembler.h: (JSC::X86Assembler::shlq_i8r): Added to create scaled addresses with a negative index * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/CodeBlock.h: (JSC::unmodifiedArgumentsRegister): (JSC::CodeBlock::isCaptured): * bytecode/CodeOrigin.h: (JSC::CodeOrigin::stackOffset): * bytecode/Operands.h: (JSC::localToOperand): (JSC::operandIsLocal): (JSC::operandToLocal): (JSC::operandIsArgument): (JSC::operandToArgument): (JSC::argumentToOperand): * bytecode/VirtualRegister.h: Made InvalidVirtualRegister a positive value that fits in 31 bits since it can be placed into the 31 bit field "stackOffset" in struct InlineCallFrame. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::addVar): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::createLazyRegisterIfNecessary): (JSC::BytecodeGenerator::newRegister): (JSC::BytecodeGenerator::emitNewArray): * bytecompiler/BytecodeGenerator.h: (JSC::CallArguments::registerOffset): * bytecompiler/NodesCodegen.cpp: (JSC::CallArguments::CallArguments): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): (JSC::DFG::ByteCodeParser::addCall): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOperations.cpp: * dfg/DFGScoreBoard.h: (JSC::DFG::ScoreBoard::allocate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callFrameSlot): (JSC::DFG::SpeculativeJIT::argumentSlot): (JSC::DFG::SpeculativeJIT::callFrameTagSlot): (JSC::DFG::SpeculativeJIT::callFramePayloadSlot): (JSC::DFG::SpeculativeJIT::argumentTagSlot): (JSC::DFG::SpeculativeJIT::argumentPayloadSlot): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::reportValidationContext): * ftl/FTLLink.cpp: (JSC::FTL::link): * heap/ConservativeRoots.cpp: (JSC::ConservativeRoots::genericAddSpan): * interpreter/CallFrame.cpp: (JSC::CallFrame::frameExtentInternal): * interpreter/CallFrame.h: (JSC::ExecState::init): (JSC::ExecState::argumentOffset): (JSC::ExecState::argumentOffsetIncludingThis): (JSC::ExecState::argIndexForRegister): * interpreter/Interpreter.cpp: (JSC::loadVarargs): (JSC::Interpreter::dumpRegisters): * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::~JSStack): (JSC::JSStack::growSlowCase): (JSC::JSStack::gatherConservativeRoots): (JSC::JSStack::releaseExcessCapacity): (JSC::JSStack::disableErrorStackReserve): * interpreter/JSStack.h: (JSC::JSStack::getBaseOfStack): (JSC::JSStack::getLimitOfStack): (JSC::JSStack::size): (JSC::JSStack::end): (JSC::JSStack::containsAddress): (JSC::JSStack::lowAddress): (JSC::JSStack::highAddress): (JSC::JSStack::reservationEnd): (JSC::JSStack::shrink): (JSC::JSStack::grow): * interpreter/JSStackInlines.h: (JSC::JSStack::getTopOfFrame): (JSC::JSStack::pushFrame): (JSC::JSStack::popFrame): (JSC::JSStack::installTrapsAfterFrame): * interpreter/StackVisitor.cpp: (JSC::inlinedFrameOffset): (JSC::StackVisitor::readInlinedFrame): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JITCall.cpp: (JSC::JIT::compileLoadVarargs): (JSC::JIT::compileOpCall): * jit/JITCall32_64.cpp: (JSC::JIT::compileLoadVarargs): (JSC::JIT::compileOpCall): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_create_activation): (JSC::JIT::emit_op_get_argument_by_val): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_get_argument_by_val): * jit/JITStubs.cpp: (JSC::throwExceptionFromOpCall): (JSC::DEFINE_STUB_FUNCTION): * jit/ThunkGenerators.cpp: (JSC::arityFixup): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::genericCall): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArgList.cpp: (JSC::ArgList::getSlice): (JSC::MarkedArgumentBuffer::slowAppend): * runtime/ArgList.h: (JSC::MarkedArgumentBuffer::MarkedArgumentBuffer): (JSC::MarkedArgumentBuffer::slotFor): (JSC::MarkedArgumentBuffer::mallocBase): (JSC::ArgList::at): * runtime/Arguments.cpp: (JSC::Arguments::tearOff): * runtime/ArrayConstructor.cpp: (JSC::constructArrayWithSizeQuirk): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSActivation.h: (JSC::JSActivation::registersOffset): (JSC::JSActivation::tearOff): (JSC::JSActivation::isValidIndex): * runtime/JSArray.h: (JSC::constructArrayNegativeIndexed): New method to create an array from registers that grow down. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::globalExec): * runtime/JSGlobalObject.h: (JSC::constructArrayNegativeIndexed): * runtime/JSString.h: * runtime/Operations.h: (JSC::jsStringFromRegisterArray): * runtime/SymbolTable.h: (JSC::SharedSymbolTable::captureCount): 2013-09-13 Csaba Osztrogonác ARM EABI hardfp buildfix after r155675 https://bugs.webkit.org/show_bug.cgi?id=121287 Reviewed by Geoffrey Garen. * dfg/DFGCCallHelpers.h: (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): 2013-09-13 Youngho Yoo Fixed crash in V8 benchmark suite in ARM,softp,EABI environment. https://bugs.webkit.org/show_bug.cgi?id=117281 Reviewed by Michael Saboff. Fix the missing EABI_32BIT_DUMMY_ARG in FPRReg using callOperation function. Test 1 : fast/js/array-with-double-assign.html Test 2 : fast/js/array-with-double-push.html * dfg/DFGCCallHelpers.h: (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): 2013-09-12 Filip Pizlo DFG::Int32Operand and fillInt32() should go away and all uses should be replaced with SpeculateInt32Operand https://bugs.webkit.org/show_bug.cgi?id=121268 Reviewed by Oliver Hunt. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber): 2013-09-12 Geoffrey Garen Web Inspector shouldn't artificially allocate the arguments object in functions that don't use it https://bugs.webkit.org/show_bug.cgi?id=121206 Reviewed by Joseph Pecoraro. This is a step toward better tools, and a 23% speedup in a simple JavaScript benchmark run with the Web Inspector open. We want the Web Inspector to be fast, and we want it to produce reliable CPU and memory profiles. We can't do that if just opening the Web Inspector incurs huge CPU/memory penalties like the arguments object. Also, since use of the 'arguments' identifier is an API for allocating an object, I think it's good for the UI to let developers know when they've invoked that API and when they haven't. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): No need to allocate the arguments object artificially for the debugger's sake. The activation object no longer assumes that the stack frame is laid out for one. (Long-term, this code will move out of the activation object, into a special object for interfacing with the debugger.) * runtime/JSActivation.cpp: (JSC::JSActivation::getOwnNonIndexPropertyNames): (JSC::JSActivation::getOwnPropertySlot): Don't advertise or provide an arguments object if the user function didn't include one. The bytecode generator will not have laid out the stack frame to support one. (Eventually, we do want the Web Inspector to see an arguments object in scope in the console. That's a one-line change in JSActivation, but it's blocked by https://bugs.webkit.org/show_bug.cgi?id=121208.) (JSC::JSActivation::argumentsGetter): * runtime/JSActivation.h: Removed this obsolete performance work-around. C++ property access to an activation object is no longer hot. 2013-09-12 Mark Hahnenberg Rolling out r155632 Broke some tests. * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateHelper): * heap/MarkedBlock.h: 2013-09-12 Ryosuke Niwa Qt build fix. Add a return to make the compiler happy. * dfg/DFGGPRInfo.h: (JSC::DFG::JSValueRegs::gpr): 2013-09-12 Filip Pizlo DFG::GenerationInfo init/fill methods shouldn't duplicate a bunch of logic https://bugs.webkit.org/show_bug.cgi?id=121253 Reviewed by Oliver Hunt. * dfg/DFGGenerationInfo.h: (JSC::DFG::GenerationInfo::initGPR): (JSC::DFG::GenerationInfo::initInt32): (JSC::DFG::GenerationInfo::initJSValue): (JSC::DFG::GenerationInfo::initCell): (JSC::DFG::GenerationInfo::initBoolean): (JSC::DFG::GenerationInfo::initStorage): (JSC::DFG::GenerationInfo::fillGPR): (JSC::DFG::GenerationInfo::fillJSValue): (JSC::DFG::GenerationInfo::fillCell): (JSC::DFG::GenerationInfo::fillInt32): (JSC::DFG::GenerationInfo::fillBoolean): (JSC::DFG::GenerationInfo::fillStorage): 2013-09-12 Filip Pizlo Unreviewed, fix mispelling (Specualte -> Speculate) that I introduced in an earlier patch. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculateInt32Operand::gpr): (JSC::DFG::SpeculateStrictInt32Operand::gpr): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateInt32): (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Strict): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateInt32): (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Strict): 2013-09-12 Filip Pizlo GPRTemporary's reuse constructor should be templatized to reduce code duplication, and the bool to denote tag or payload should be replaced with an enum https://bugs.webkit.org/show_bug.cgi?id=121250 Reviewed by Oliver Hunt. * dfg/DFGGPRInfo.h: (JSC::DFG::JSValueRegs::gpr): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::GPRTemporary::GPRTemporary): (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileAdd): (JSC::DFG::SpeculativeJIT::compileStringEquality): (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): (JSC::DFG::SpeculativeJIT::compileGetArrayLength): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::JSValueOperand::gpr): (JSC::DFG::GPRTemporary::GPRTemporary): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileIntegerCompare): (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::compile): * runtime/JSCJSValue.h: 2013-09-12 Mark Hahnenberg MarkedBlocks shouldn't be put in Allocated state if they didn't produce a FreeList https://bugs.webkit.org/show_bug.cgi?id=121236 Reviewed by Geoffrey Garen. Right now, after a collection all MarkedBlocks are in the Marked block state. When lazy sweeping happens, if a block returns an empty free list after being swept, we call didConsumeFreeList(), which moves the block into the Allocated block state. This happens to both the block that was just being allocated out of (i.e. m_currentBlock) as well as any blocks who are completely full. We should distinguish between these two cases: m_currentBlock should transition to Allocated (because we were just allocating out of it) and any subsequent block that returns an empty free list should transition back to the Marked state. This will make the block state more consistent with the actual state the block is in, and it will also allow us to speed up moving all blocks to the Marked state during generational collection. * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateHelper): * heap/MarkedBlock.h: (JSC::MarkedBlock::didConsumeEmptyFreeList): 2013-09-12 Mark Lam Change debug hooks to pass sourceID and position info via the DebuggerCallFrame. https://bugs.webkit.org/show_bug.cgi?id=121214. Reviewed by Geoffrey Garen. * debugger/Debugger.h: * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::sourceId): (JSC::DebuggerCallFrame::clear): * debugger/DebuggerCallFrame.h: (JSC::DebuggerCallFrame::DebuggerCallFrame): (JSC::DebuggerCallFrame::line): (JSC::DebuggerCallFrame::column): * interpreter/Interpreter.cpp: (JSC::unwindCallFrame): (JSC::Interpreter::unwind): (JSC::Interpreter::debug): 2013-09-12 Csaba Osztrogonác Add back c++11 features removed by buildfixes after all ports did the switch https://bugs.webkit.org/show_bug.cgi?id=119266 Reviewed by Anders Carlsson. * bytecode/GetByIdStatus.h: (JSC::GetByIdStatus::GetByIdStatus): * dfg/DFGWorklist.cpp: (JSC::DFG::Worklist::~Worklist): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::codeType): (JSC::StackVisitor::Frame::functionName): (JSC::StackVisitor::Frame::sourceURL): (JSC::StackVisitor::Frame::print): 2013-09-12 Mikhail Pozdnyakov Remove home-brewed nullptr https://bugs.webkit.org/show_bug.cgi?id=119624 Reviewed by Anders Carlsson. The standard C++11 nullptr and std::nullptr_t type should be used now. * heap/PassWeak.h: * heap/Weak.h: 2013-09-11 Filip Pizlo Rename initInteger() to initInt32() Rubber stamped by Mark Hahnenberg. * dfg/DFGGenerationInfo.h: (JSC::DFG::GenerationInfo::initInt32): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::integerResult): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2013-09-11 Filip Pizlo Rename IntegerOperand to Int32Operand and fillInteger() to fillInt32(). Rubber stamped by Mark Hahnenberg. * dfg/DFGGenerationInfo.h: (JSC::DFG::GenerationInfo::fillInt32): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::GPRTemporary::GPRTemporary): (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::Int32Operand::Int32Operand): (JSC::DFG::Int32Operand::~Int32Operand): (JSC::DFG::Int32Operand::gpr): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillInt32): (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber): (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillInt32): (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber): (JSC::DFG::SpeculativeJIT::fillSpecualteInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): 2013-09-11 Filip Pizlo FixupPhase should always call fixEdge() exactly once for every edge https://bugs.webkit.org/show_bug.cgi?id=121211 Reviewed by Geoffrey Garen. Previously we only call fixEdge() on edges that we want to make typed. UntypedUse edges don't get fixEdge() called. This makes it difficult to add functionality in fixEdge() that runs for UntypedUses. It's difficult to remember to call fixEdge() for every edge that we don't want to turn into a typed edge; in an alternative universe where we did this, it would mean that every case in FixupPhase would have to make a fixEdge() call for *every* edge even ones that it doesn't want to modify. This patch takes a different path. fixEdge() must never be called explicitly with UntypedUse. fixEdge() should be used to set the UseKind of edges. Consequently, all that FixupPhase has to do is call fixEdge