2013-05-02 Filip Pizlo fourthTier: Structure transition table keys don't have to ref their StringImpl's https://bugs.webkit.org/show_bug.cgi?id=115525 Reviewed by Geoffrey Garen. The structure transition table basically maps string to structure. The string is always also stored, and ref'd, in the structure in Structure::m_nameInPrevious. m_nameInPrevious is never mutated, and never cleared. The string cannot die unless the structure dies. If the structure dies, then that entry in the transition map becomes a zombie anyway and we will detect this separately. So, we don't need to use RefPtr. We can just use StringImpl*. This also fixes a goof where we were getting the StringImpl's hash rather than using a pointer hash. Not only is the latter faster, but it prevents my change from leading to crashes: with my change we can have zombie keys, not just zombie values. They will exist only until the next map mutation, which will clear them. Lookups will work fine because the lookup routine will reject zombies. But it does mean that the HashMap will have to deal with dangling StringImpl*'s; all it takes to make this work is to ensure that the HashMap itself never dereferences them. Using a pointer hash rather than StringImpl::existingHash() accomplishes this. This also ensures that we don't accidentally call ref() or deref() from the compilation thread, if the compilation thread inspects the transition table. And no, we wouldn't have been able to use the HashMap, ...> specialization, because the transition table is actually HashMap, unsigned>, ...>: hence that specialization doesn't kick in. We could have written a new specialization or something, but that seemed like a lot of work given that we don't need the table to be ref'ing the strings anyways. * runtime/Structure.cpp: (JSC::StructureTransitionTable::add): * runtime/StructureTransitionTable.h: (StructureTransitionTable): (Hash): (JSC::StructureTransitionTable::Hash::hash): 2013-05-01 Filip Pizlo fourthTier: Structure::addPropertyTransitionToExistingStructure should be thread-safe https://bugs.webkit.org/show_bug.cgi?id=115468 Reviewed by Geoffrey Garen. This makes the main thread modify the transition table while holding a lock. Note that the GC might modify its weak pointers without locking, but the GC will lock out the compilation thread anyway. The map will then only reshape in response to add() and set(), which happen while holding a lock. This allows the compilation thread to now query transition tables safely, provided it holds a lock when doing so. Also changed LLVM asm printer initialization to just initialize the X86 one. It makes sense for us to just initialize the asm printer(s) that we actually use; you could imagine us being linked to a system LLVM that has cross-compilation support; there is no point in the WebKit or JSC process doing work to initialize all of those targets. That part was rubber stamped by Mark Hahnenberg. * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): * runtime/InitializeThreading.cpp: (JSC::initializeThreadingOnce): * runtime/Structure.cpp: (JSC::Structure::addPropertyTransitionToExistingStructureImpl): (JSC::Structure::addPropertyTransitionToExistingStructure): (JSC): (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently): (JSC::Structure::addPropertyTransition): (JSC::Structure::nonPropertyTransition): * runtime/Structure.h: (Structure): 2013-04-30 Filip Pizlo fourthTier: Structure::getConcurrently() may be called from for uncacheable dictionaries, and this is safe https://bugs.webkit.org/show_bug.cgi?id=115464 Reviewed by Oliver Hunt and Geoffrey Garen. This can happen for example transitively from JSObject::put(). getCurrently() does work for uncacheable dictionaries; it just has the obvious race that right after it returns, the result it returned may no longer be right. This isn't an issue if it was called on the main thread, and may not be an issue in some other situations. So, we should just remove the assertion, since the only thing it buys us is crashes. * runtime/Structure.cpp: (JSC::Structure::getConcurrently): 2013-04-30 Filip Pizlo fourthTier: Don't link gtest into JavaScriptCore Rubber stamped by Mark Rowe. * Configurations/JavaScriptCore.xcconfig: 2013-04-29 Filip Pizlo fourthTier: String::utf8() should also be available as StringImpl::utf8() so that you don't have to ref() a StringImpl just to get its utf8() https://bugs.webkit.org/show_bug.cgi?id=115393 Reviewed by Geoffrey Garen. * runtime/JSGlobalObjectFunctions.cpp: (JSC::encode): 2013-07-16 Oliver Hunt Merge dfgFourthTier r149301 2013-04-28 Filip Pizlo fourthTier: ASSERT that commonly used not-thread-safe methods in the runtime are not being called during compilation https://bugs.webkit.org/show_bug.cgi?id=115297 Reviewed by Geoffrey Garen. Put in assertions that we're not doing bad things in compilation threads. Also factored compilation into compile+link so that even though we don't yet have concurrent compilation, we can be explicit about which parts of DFG work are meant to be concurrent, and which aren't. Also fix a handful of bugs found by these assertions. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/ResolveGlobalStatus.cpp: (JSC::computeForStructure): * bytecode/Watchpoint.cpp: (JSC::WatchpointSet::add): (JSC::InlineWatchpointSet::inflateSlow): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::~JITCompiler): (DFG): (JSC::DFG::JITCompiler::compileBody): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compileFunction): (JSC::DFG::JITCompiler::linkFunction): * dfg/DFGJITCompiler.h: (JITCompiler): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLCompile.h: (FTL): * ftl/FTLLink.cpp: Added. (FTL): (JSC::FTL::compileEntry): (JSC::FTL::link): * ftl/FTLLink.h: Added. (FTL): * ftl/FTLState.cpp: (JSC::FTL::State::State): * ftl/FTLState.h: (FTL): (State): * runtime/Structure.cpp: (JSC::Structure::get): (JSC::Structure::prototypeChainMayInterceptStoreTo): * runtime/Structure.h: (JSC::Structure::materializePropertyMapIfNecessary): * runtime/StructureInlines.h: (JSC::Structure::get): 2013-04-27 Filip Pizlo FTL should support double variables https://bugs.webkit.org/show_bug.cgi?id=113624 Reviewed by Geoffrey Garen. Made all of the operations that the FTL already supports, also support doubles. OSR exit already basically had everything it needed, so no changes there. This mostly just glues together bits of DFG IR to LLVM IR, in a straight-forward way. * ftl/FTLAbbreviations.h: (FTL): (JSC::FTL::doubleType): (JSC::FTL::constReal): (JSC::FTL::buildPhi): (JSC::FTL::addIncoming): (JSC::FTL::buildFAdd): (JSC::FTL::buildFSub): (JSC::FTL::buildFMul): (JSC::FTL::buildFNeg): (JSC::FTL::buildSIToFP): (JSC::FTL::buildUIToFP): (JSC::FTL::buildBitCast): (JSC::FTL::buildFCmp): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLCommonValues.cpp: (JSC::FTL::CommonValues::CommonValues): * ftl/FTLCommonValues.h: (CommonValues): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::lower): (JSC::FTL::LowerDFGToLLVM::compileGetLocal): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (JSC::FTL::LowerDFGToLLVM::compileAdd): (JSC::FTL::LowerDFGToLLVM::compileArithSub): (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileArithNegate): (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compileCompareEq): (JSC::FTL::LowerDFGToLLVM::compileCompareLess): (JSC::FTL::LowerDFGToLLVM::lowDouble): (LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::lowJSValue): (JSC::FTL::LowerDFGToLLVM::isCellOrMisc): (JSC::FTL::LowerDFGToLLVM::unboxDouble): (JSC::FTL::LowerDFGToLLVM::boxDouble): (JSC::FTL::LowerDFGToLLVM::speculate): (JSC::FTL::LowerDFGToLLVM::speculateNumber): (JSC::FTL::LowerDFGToLLVM::speculateRealNumber): (JSC::FTL::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): * ftl/FTLOutput.h: (JSC::FTL::Output::constDouble): (Output): (JSC::FTL::Output::phi): (JSC::FTL::Output::doubleAdd): (JSC::FTL::Output::doubleSub): (JSC::FTL::Output::doubleMul): (JSC::FTL::Output::doubleNeg): (JSC::FTL::Output::intToFP): (JSC::FTL::Output::intToDouble): (JSC::FTL::Output::unsignedToFP): (JSC::FTL::Output::unsignedToDouble): (JSC::FTL::Output::bitCast): (JSC::FTL::Output::loadDouble): (JSC::FTL::Output::storeDouble): (JSC::FTL::Output::doubleEqual): (JSC::FTL::Output::doubleNotEqualOrUnordered): (JSC::FTL::Output::doubleLessThan): (JSC::FTL::Output::doubleLessThanOrEqual): (JSC::FTL::Output::doubleGreaterThan): (JSC::FTL::Output::doubleGreaterThanOrEqual): (JSC::FTL::Output::doubleEqualOrUnordered): (JSC::FTL::Output::doubleNotEqual): (JSC::FTL::Output::doubleLessThanOrUnordered): (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered): (JSC::FTL::Output::doubleGreaterThanOrUnordered): (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered): (JSC::FTL::Output::testIsZero64): 2013-04-27 Filip Pizlo fourthTier: SymbolTable should be thread-safe https://bugs.webkit.org/show_bug.cgi?id=115301 Reviewed by Geoffrey Garen. Makes SymbolTable thread-safe. Relies on SymbolTableEntry already being immutable, other than the WatchpointSet; but the WatchpointSet already has a righteous concurrency protocol. So, this patch just protects the SymbolTable's HashMap. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::nameForRegister): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::addVar): * runtime/Executable.cpp: (JSC::ProgramExecutable::addGlobalVar): * runtime/JSActivation.cpp: (JSC::JSActivation::getOwnNonIndexPropertyNames): (JSC::JSActivation::symbolTablePutWithAttributes): * runtime/JSSymbolTableObject.cpp: (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames): * runtime/JSSymbolTableObject.h: (JSC::symbolTableGet): (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/SymbolTable.cpp: (JSC::SymbolTable::SymbolTable): (JSC::SymbolTable::~SymbolTable): * runtime/SymbolTable.h: (JSC::SymbolTable::find): (JSC::SymbolTable::get): (JSC::SymbolTable::inlineGet): (JSC::SymbolTable::begin): (JSC::SymbolTable::end): (JSC::SymbolTable::size): (JSC::SymbolTable::add): (JSC::SymbolTable::set): (JSC::SymbolTable::contains): 2013-04-26 Filip Pizlo fourthTier: WatchpointSet should make racy uses easier to reason about https://bugs.webkit.org/show_bug.cgi?id=115299 Reviewed by Anders Carlsson. The compiler often does things like: 1c) Observe something that would imply that a WatchpointSet ought to be invalid 2c) Check that it is invalid The main thread often does things like: 1m) Fire the watchpoint set 2m) Do some other thing that would cause the compiler to assume that the WatchpointSet ought to be invalid An example is structure transitions, where (1c) is the compiler noticing that a put_by_id inline cache is in a transition state, with the source structure being S; (2c) is the compiler asserting that S's watchpoint set is invalid; (1m) is the main thread firing S's watchpoint set before it does the first transition away from S; and (2m) is the main thread caching the put_by_id transition away from S. This is totally fine, except that (1c) and (2c), and (1m) and (2m) could be reordered. Probably, in most cases, this ought to do enough things that the main thread probably already has some fencing. But the compiler thread definitely doesn't have fencing. In any case, we should play it safe and just have additional fencing in all of the relevant places. We already have some idioms to put load-load and store-store fences in the right places. But this change just makes WatchpointSet take care of this for us, thus reducing the chances of us getting this wrong. * bytecode/Watchpoint.cpp: (JSC::WatchpointSet::notifyWriteSlow): * bytecode/Watchpoint.h: (WatchpointSet): (JSC::WatchpointSet::isStillValid): (JSC::WatchpointSet::hasBeenInvalidated): (JSC::InlineWatchpointSet::hasBeenInvalidated): (JSC::InlineWatchpointSet::notifyWrite): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGDesiredWatchpoints.h: (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState): 2013-07-16 Oliver Hunt Merge dfgFourthTier r149233 2013-04-26 Filip Pizlo fourthTier: CFA should defend against results seeming inconsistent due to a watchpoint firing during compilation https://bugs.webkit.org/show_bug.cgi?id=115083 Reviewed by Geoffrey Garen. This ruggedizes our racyness with respect to watchpoints. We want to be able to assert, in some places, that a watchpoint-based optimization has only occurred if the watchpoint set was still valid. But currently we *can* soundly do watchpoint-based optimizations even for invalid watchpoints, so long as we recorded in the IR that we had done so; this will then lead to the code being insta-jettisoned after compilation completes. Obviously, we don't want this to happen often - but we do want to allow it precisely in the case of watchpoint races. This adds the ability to assert that we hadn't over-watchpointed ourselves, with and exemption for races. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::setFuturePossibleStructure): (JSC::DFG::AbstractValue::filterFuturePossibleStructure): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addStructureTransitionCheck): (JSC::DFG::ByteCodeParser::parseResolveOperations): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck): * dfg/DFGDesiredWatchpoints.h: (GenericDesiredWatchpoints): (JSC::DFG::GenericDesiredWatchpoints::isStillValid): (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState): (JSC::DFG::GenericDesiredWatchpoints::isValidOrMixed): (JSC::DFG::DesiredWatchpoints::isStillValid): (JSC::DFG::DesiredWatchpoints::shouldAssumeMixedState): (JSC::DFG::DesiredWatchpoints::isValidOrMixed): (DesiredWatchpoints): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess): * dfg/DFGGraph.h: (JSC::DFG::Graph::masqueradesAsUndefinedWatchpointIsStillValid): (Graph): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::addLazily): (JITCompiler): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): (JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid): (JSC::DFG::SpeculativeJIT::speculationWatchpointForMasqueradesAsUndefined): (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLState.h: (State): 2013-04-23 Filip Pizlo fourthTier: AbstractValue methods that deal with watchpoints should have access to Graph, so that in debug mode, Graph can track the history of watchpoint states and detect races https://bugs.webkit.org/show_bug.cgi?id=115084 Reviewed by Geoffrey Garen. The idea is that as part of https://bugs.webkit.org/show_bug.cgi?id=115083, I'll have Graph record the initial state of a watchpoint at the time that we decide to take advantage of it; then I will use this to disable any watchpoint-related assertions in debug mode. Note that this "watchpoint cache" will only be maintained in debug mode, so there will be no release performance implications. But to do this, I need to ensure that all of the places that reason about watchpoints have access to Graph. For example, I'll want AbstractValue::setFuturePossibleStructure to record the state of the watchpoint in Graph so that subsequent assertions can check if the watchpoint's state had changed since that decision was made. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::initialize): (JSC::DFG::AbstractState::executeEffects): (JSC::DFG::AbstractState::mergeStateAtTail): * dfg/DFGAbstractState.h: (JSC::DFG::AbstractState::trySetConstant): * dfg/DFGAbstractValue.cpp: Added. (DFG): (JSC::DFG::AbstractValue::setMostSpecific): (JSC::DFG::AbstractValue::set): (JSC::DFG::AbstractValue::filter): (JSC::DFG::AbstractValue::setFuturePossibleStructure): (JSC::DFG::AbstractValue::filterFuturePossibleStructure): (JSC::DFG::AbstractValue::dump): * dfg/DFGAbstractValue.h: (DFG): (AbstractValue): (JSC::DFG::AbstractValue::setType): (JSC::DFG::AbstractValue::filterByValue): 2013-07-16 Oliver Hunt Merge dfgFourthTier r148936 2013-04-22 Filip Pizlo fourthTier: Create an equivalent of Structure::get() that can work from a compilation thread https://bugs.webkit.org/show_bug.cgi?id=114987 Reviewed by Geoffrey Garen. This completes the work started by r148570. That patch made it possible to do Structure::get() without modifying Structure. This patch takes this further, and makes this thread-safe (for non-uncacheable-dictionaries) via Structure::getConcurrently(). This method not only doesn't modify Structure, but also ensures that any concurrent attempts to add to, remove from, or steal the table from that structure doesn't mess up the result of the call. The call may return invalidOffset even if a property is *just* about to be added, but it will never do the reverse: if it returns a property then you can be sure that the structure really does have that property and always will have it. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): (JSC::GetByIdStatus::computeForChain): (JSC::GetByIdStatus::computeFor): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): (JSC::PutByIdStatus::computeFor): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::isStringPrototypeMethodSane): * runtime/PropertyMapHashTable.h: (PropertyTable): (JSC::PropertyTable::findConcurrently): (JSC): (JSC::PropertyTable::add): (JSC::PropertyTable::remove): (JSC::PropertyTable::reinsert): (JSC::PropertyTable::rehash): * runtime/PropertyTable.cpp: (JSC::PropertyTable::PropertyTable): * runtime/Structure.cpp: (JSC::Structure::findStructuresAndMapForMaterialization): (JSC::Structure::getConcurrently): * runtime/Structure.h: (Structure): * runtime/StructureInlines.h: (JSC::Structure::getConcurrently): 2013-07-16 Oliver Hunt Merge dfgFourthTier r148850 2013-04-21 Filip Pizlo fourthTier: WebKit's build system should relink JavaScriptCore if LLVM's libraries changed but its headers didn't https://bugs.webkit.org/show_bug.cgi?id=114926 Reviewed by Geoffrey Garen. Use a phony file that includes a phony header to force JavaScriptCore to be relinked if necessary. The external LLVM-importing scripts will touch the header if the libraries are known to have changed. * JavaScriptCore.xcodeproj/project.pbxproj: * ftl/WebKitLLVMLibraryAnchor.cpp: Added. 2013-07-16 Oliver Hunt Merge dfgFourthTier r148836 2013-04-21 Filip Pizlo fourthTier: It should be possible to query WatchpointSets, and add Watchpoints, even if the compiler is running in another thread https://bugs.webkit.org/show_bug.cgi?id=114909 Reviewed by Oliver Hunt. The idea here is that a concurrent compiler will use watchpoint sets as follows: During concurrent compilation: It will create Watchpoints, and query WatchpointSets only for the purpose of profiling. That is, it will use decide whether it is profitable to compile the code "as if" the watchpoint sets are valid. During synchronous linking: By "linking" I don't necessarily mean the LinkBuffer stuff, but just the very bitter end of compilation where we make the JIT code callable. This can happen after LinkBuffer stuff. Anyway, this will have to happen synchronously, and at that point we can (a) check that all WatchpointSets that we assumed were valid are still valid and (b) if they are then we add the watchpoints to those sets. If any of the sets are invalid, we give up on this compilation and try again later. The querying of WatchpointSets is engineered to say that the set is still valid if it is so *right now*, but this is done in a racy way and so it may say so spuriously: we may, with hopefully low probability, have a set that says it is valid even though it was just invalidated. The goal is only to ensure that (i) a set never claims to be invalid if it is actually valid, (ii) a set doesn't claim to be valid if it was invalidated before compilation even began, and (iii) querying the validity of a set doesn't cause us to crash. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/Watchpoint.cpp: (JSC::InlineWatchpointSet::inflateSlow): * bytecode/Watchpoint.h: (WatchpointSet): (InlineWatchpointSet): (JSC::InlineWatchpointSet::hasBeenInvalidated): (JSC::InlineWatchpointSet::isThin): (JSC::InlineWatchpointSet::isFat): (JSC::InlineWatchpointSet::fat): * dfg/DFGDesiredWatchpoints.cpp: Added. (DFG): (JSC::DFG::DesiredWatchpoints::DesiredWatchpoints): (JSC::DFG::DesiredWatchpoints::~DesiredWatchpoints): (JSC::DFG::DesiredWatchpoints::addLazily): (JSC::DFG::DesiredWatchpoints::reallyAdd): (JSC::DFG::DesiredWatchpoints::areStillValid): * dfg/DFGDesiredWatchpoints.h: Added. (DFG): (JSC::DFG::WatchpointForGenericWatchpointSet::WatchpointForGenericWatchpointSet): (WatchpointForGenericWatchpointSet): (GenericDesiredWatchpoints): (JSC::DFG::GenericDesiredWatchpoints::GenericDesiredWatchpoints): (JSC::DFG::GenericDesiredWatchpoints::addLazily): (JSC::DFG::GenericDesiredWatchpoints::reallyAdd): (JSC::DFG::GenericDesiredWatchpoints::areStillValid): (DesiredWatchpoints): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::addLazily): (JITCompiler): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLCompile.h: (FTL): * ftl/FTLState.h: (State): * runtime/JSFunction.h: (JSFunction): (JSC::JSFunction::allocationProfileWatchpointSet): * runtime/Structure.h: (Structure): (JSC::Structure::transitionWatchpointSet): 2013-07-16 Oliver Hunt Merge dfgFourthTier r148804 2013-04-20 Filip Pizlo fourthTier: value profiles and array profiles should be thread-safe enough to be accessible in a concurrent compilation thread https://bugs.webkit.org/show_bug.cgi?id=114906 Reviewed by Oliver Hunt. This introduces thread safety to value profiles, array profiles, and array allocation profiles. We already have three separate operations that happen on profiles: (1) writing, which the JIT, LLInt, and OSR exit do; (2) updating, which happens during GC, from OSR entry slow-paths, and in the DFG; and (3) reading, which happens in the DFG. For example, the JIT/LLInt and OSR exit write to ValueProfile::m_buckets, which gets synthesized into ValueProfile::m_prediction (and other fields) during update, and the latter gets read by the DFG. Note that (2) must also happen in the DFG since only the DFG knows which code blocks it will inline, and those blocks' profiles may not have otherwise been updated via any other mechanism. I refer to these three operations as writing, updating, and reading. Consequently, both profile updating and profile reading may happen asynchronously, if the JIT is asynchronous. The locking protocol for profiles works as follows: - Writing does not require locking, but is only allowed on the main thread. We require that these fields can be stored atomically by the profiling code, even without locks. For value profiles, this only works on 64-bit platforms, currently. For array profiles, which consist of multiple separate fields, this means that an asynchronous update of the profile may see slight inconsistencies (like a structure that doesn't quite match the array modes bits), but these should be harmless: at worst, the DFG will specialize too much and we'll have OSR exits. - Updating a value profile requires holding a lock, but must assume that the fields written by the profiling code in JIT/LLInt may be written to without locking. - Reading a value profile requires holding a lock. The one major exception to these rules is the ArrayAllocationProfile, which requires no locking. We do this because it's used so often and in places where we don't necessarily have access to the owning CodeBlock, so if we did want it to be locked it would have to have its own lock. Also, I believe that it is sound to just make this profile racy and not worry about locking at all. All that was needed were some changes to ensure that we explicitly read some raced-over fields only once. Two additional interesting things in this change: - To make it easy to see which profile methods require locking, they take a const CodeBlockLocker& as an argument. I saw this idiom for identifying which methods require which locks to be held being used in LLVM, and I quite like it. - Lazy operand value profiles, which are created lazily and at any time, require the CodeBlockLock to be held when they are being created. Writes to them are lockless and main-thread-only, but as with other profiles, updates and reads require locking. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/ArrayAllocationProfile.cpp: (JSC::ArrayAllocationProfile::updateIndexingType): * bytecode/ArrayAllocationProfile.h: (JSC::ArrayAllocationProfile::selectIndexingType): * bytecode/ArrayProfile.cpp: (JSC::ArrayProfile::computeUpdatedPrediction): (JSC::ArrayProfile::briefDescription): * bytecode/ArrayProfile.h: (ArrayProfile): (JSC::ArrayProfile::expectedStructure): (JSC::ArrayProfile::structureIsPolymorphic): (JSC::ArrayProfile::hasDefiniteStructure): (JSC::ArrayProfile::observedArrayModes): (JSC::ArrayProfile::mayInterceptIndexedAccesses): (JSC::ArrayProfile::mayStoreToHole): (JSC::ArrayProfile::outOfBounds): (JSC::ArrayProfile::usesOriginalArrayStructures): * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFor): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpValueProfiling): (JSC::CodeBlock::dumpArrayProfiling): (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): (JSC::CodeBlock::updateAllArrayPredictions): * bytecode/CodeBlock.h: (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): (JSC::CodeBlock::updateAllPredictionsAndCheckIfShouldOptimizeNow): (CodeBlock): * bytecode/CodeBlockLock.h: Added. (JSC): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFor): * bytecode/LazyOperandValueProfile.cpp: (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions): (JSC::CompressedLazyOperandValueProfileHolder::add): (JSC::LazyOperandValueProfileParser::LazyOperandValueProfileParser): (JSC::LazyOperandValueProfileParser::~LazyOperandValueProfileParser): (JSC): (JSC::LazyOperandValueProfileParser::initialize): (JSC::LazyOperandValueProfileParser::prediction): * bytecode/LazyOperandValueProfile.h: (CompressedLazyOperandValueProfileHolder): (LazyOperandValueProfileParser): * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::getSpecFailBucket): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): * bytecode/ResolveGlobalStatus.cpp: (JSC::ResolveGlobalStatus::computeFor): * bytecode/ValueProfile.h: (JSC::ValueProfileBase::briefDescription): (ValueProfileBase): (JSC::ValueProfileBase::computeUpdatedPrediction): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::fromObserved): * dfg/DFGArrayMode.h: (ArrayMode): (JSC::DFG::ArrayMode::withProfile): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): (JSC::DFG::ByteCodeParser::getArrayMode): (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): (JSC::DFG::ByteCodeParser::parseResolveOperations): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGOSRExitPreparation.cpp: (JSC::DFG::prepareCodeOriginForOSRExit): * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * jit/JITInlines.h: (JSC::JIT::chooseArrayMode): * jit/JITStubs.cpp: (JSC::tryCachePutByID): (JSC::tryCacheGetByID): (JSC::DEFINE_STUB_FUNCTION): (JSC::lazyLinkFor): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::setUpCall): * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::BytecodeSequence): * runtime/JSScope.cpp: (JSC::JSScope::resolveContainingScopeInternal): (JSC::JSScope::resolvePut): 2013-04-17 Filip Pizlo fourthTier: all inline caches should thread-safe enough to allow a concurrent compilation thread to read them safely https://bugs.webkit.org/show_bug.cgi?id=114762 Reviewed by Mark Hahnenberg. For most inline caches this is easy: the inline cache has a clean temporal separation between doing the requested action (which may take an unbounded amount of time, may recurse, and may do arbitrary things) and recording the relevant information in the cache. So, we just put locks around the recording bit. That part is always O(1) and does not recurse. The lock we use is per-CodeBlock to achieve a good balance between locking granularity and low space overhead. So a concurrent compilation thread will only block if an inline cache ping-pongs in the code block being compiled (or inlined) and never when other inline caches do things. For resolve operations, it's a bit tricky. The global resolve bit works like any other IC in that it has the clean temporal separation. But the operations vector itself doesn't have this separation, since we will be filling it in tandem with actions that may take a long time. This patch gets around this by having a m_ready bit in the ResolveOperations and PutToBaseOperation. This is set while holding the CodeBlock's lock. If the DFG observes the m_ready bit not set (while holding the lock) then it conservatively assumes that the resolve hasn't happened yet and just plants a ForceOSRExit. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFor): * bytecode/CodeBlock.h: (CodeBlock): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFor): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): * bytecode/ResolveGlobalStatus.cpp: (JSC::ResolveGlobalStatus::computeFor): * bytecode/ResolveOperation.h: (JSC::ResolveOperations::ResolveOperations): (ResolveOperations): (JSC::PutToBaseOperation::PutToBaseOperation): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseResolveOperations): (JSC::DFG::ByteCodeParser::parseBlock): * jit/JITStubs.cpp: (JSC::tryCachePutByID): (JSC::tryCacheGetByID): (JSC::DEFINE_STUB_FUNCTION): (JSC::lazyLinkFor): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::setUpCall): * runtime/JSScope.cpp: (JSC::JSScope::resolveContainingScopeInternal): (JSC::JSScope::resolveContainingScope): (JSC::JSScope::resolvePut): 2013-04-16 Filip Pizlo fourthTier: DFG should be able to query Structure without modifying it https://bugs.webkit.org/show_bug.cgi?id=114708 Reviewed by Oliver Hunt. This is work towards allowing the DFG, and FTL, to run on a separate thread. The idea is that the most evil thing that the DFG does that has thread-safety issues is fiddling with Structures by calling Structure::get(). This can lead to rematerialization of property tables, which is definitely not thread-safe due to how StringImpl works. So, this patch completely side-steps the problem by creating a new version of Structure::get, called Structure::getWithoutMaterializing, which may choose to do an O(n) search if necessary to avoid materialization. I believe this should be fine - the DFG does't call into these code path often enough for this to matter, and most of the time, the Structure that we call this on will already have a property table because some inline cache would have already called ::get() on that Structure. Also cleaned up the materialization logic: we can stop the search as soon as we find any Structure with a property table rather than searching all the way for a pinned one. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFor): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): (JSC::PutByIdStatus::computeFor): * runtime/Structure.cpp: (JSC::Structure::findStructuresAndMapForMaterialization): (JSC::Structure::materializePropertyMap): (JSC::Structure::getWithoutMaterializing): (JSC): * runtime/Structure.h: (Structure): * runtime/StructureInlines.h: (JSC::Structure::getWithoutMaterializing): (JSC): 2013-04-13 Filip Pizlo fourthTier: Fix release build. * dfg/DFGOSRExitCompilerCommon.cpp: * ftl/FTLExitValue.cpp: * ftl/FTLOSRExitCompiler.cpp: 2013-04-13 Filip Pizlo fourthTier: FTL should have OSR exit https://bugs.webkit.org/show_bug.cgi?id=113623 Reviewed by Oliver Hunt. This implements OSR exit, and hilariously, it actually works. The idea is to have LLVM call a no-return function on the off-ramp, passing it everything we know about bytecode state that isn't already flushed to the call frame. Our own JIT takes care of the rest. We can now run all of SunSpider, V8, and Kraken with the FTL enabled. The details are described in FTLOSRExit.h. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * assembler/AbstractMacroAssembler.h: (Address): (JSC::AbstractMacroAssembler::Address::withOffset): * assembler/LinkBuffer.h: (JSC::LinkBuffer::offsetOf): (LinkBuffer): * assembler/MacroAssemblerX86Common.h: * assembler/RepatchBuffer.h: (JSC::RepatchBuffer::RepatchBuffer): (JSC::RepatchBuffer::~RepatchBuffer): (RepatchBuffer): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::tallyFrequentExitSites): * bytecode/Operands.h: (Operands): (JSC): (JSC::::dump): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::initialize): * dfg/DFGGPRInfo.h: (DFG): (GPRInfo): * dfg/DFGMinifiedNode.h: (JSC::DFG::belongsInMinifiedGraph): * dfg/DFGNodeType.h: (JSC::DFG::needsOSRBackwardRewiring): (DFG): (JSC::DFG::needsOSRForwardRewiring): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::OSRExit): (DFG): (JSC::DFG::OSRExit::convertToForward): * dfg/DFGOSRExit.h: (OSRExit): * dfg/DFGOSRExitBase.cpp: Added. (DFG): (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow): (JSC::DFG::OSRExitBase::doSearchForForwardConversion): * dfg/DFGOSRExitBase.h: Added. (DFG): (JSC::DFG::OSRExitBase::OSRExitBase): (OSRExitBase): (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::handleExitCounts): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGOSRExitCompilerCommon.h: (DFG): * dfg/DFGOSRExitPreparation.cpp: Added. (DFG): (JSC::DFG::prepareCodeOriginForOSRExit): * dfg/DFGOSRExitPreparation.h: Added. (DFG): * dfg/DFGOperations.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkArgumentTypes): * dfg/DFGValueSource.h: (JSC::DFG::ValueSource::forSpeculation): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * ftl/FTLAbbreviations.h: (JSC::FTL::functionType): (FTL): (JSC::FTL::typeOf): (JSC::FTL::appendBasicBlock): (JSC::FTL::insertBasicBlock): (JSC::FTL::buildCall): (JSC::FTL::setTailCall): * ftl/FTLCArgumentGetter.cpp: Added. (FTL): (JSC::FTL::CArgumentGetter::loadNextAndBox): * ftl/FTLCArgumentGetter.h: Added. (FTL): (JSC::FTL::isArgumentRegister): (CArgumentGetter): (JSC::FTL::CArgumentGetter::CArgumentGetter): (JSC::FTL::CArgumentGetter::loadNext8): (JSC::FTL::CArgumentGetter::loadNext32): (JSC::FTL::CArgumentGetter::loadNext64): (JSC::FTL::CArgumentGetter::loadNextPtr): (JSC::FTL::CArgumentGetter::loadNextDouble): (JSC::FTL::CArgumentGetter::nextAddress): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLExitArgument.cpp: Added. (FTL): (JSC::FTL::ExitArgument::dump): * ftl/FTLExitArgument.h: Added. (FTL): (ExitArgumentRepresentation): (ExitArgument): (JSC::FTL::ExitArgument::ExitArgument): (JSC::FTL::ExitArgument::operator!): (JSC::FTL::ExitArgument::format): (JSC::FTL::ExitArgument::argument): (JSC::FTL::ExitArgument::withFormat): (JSC::FTL::ExitArgument::representation): * ftl/FTLExitArgumentForOperand.cpp: Added. (FTL): (JSC::FTL::ExitArgumentForOperand::dump): * ftl/FTLExitArgumentForOperand.h: Added. (FTL): (ExitArgumentForOperand): (JSC::FTL::ExitArgumentForOperand::ExitArgumentForOperand): (JSC::FTL::ExitArgumentForOperand::operator!): (JSC::FTL::ExitArgumentForOperand::exitArgument): (JSC::FTL::ExitArgumentForOperand::operand): (JSC::FTL::lesserArgumentIndex): * ftl/FTLExitArgumentList.h: Added. (FTL): * ftl/FTLExitThunkGenerator.cpp: Added. (FTL): (JSC::FTL::ExitThunkGenerator::ExitThunkGenerator): (JSC::FTL::ExitThunkGenerator::~ExitThunkGenerator): (JSC::FTL::ExitThunkGenerator::emitThunk): * ftl/FTLExitThunkGenerator.h: Added. (FTL): (ExitThunkGenerator): (JSC::FTL::ExitThunkGenerator::didThings): * ftl/FTLExitValue.cpp: Added. (FTL): (JSC::FTL::ExitValue::dump): * ftl/FTLExitValue.h: Added. (FTL): (ExitValue): (JSC::FTL::ExitValue::ExitValue): (JSC::FTL::ExitValue::operator!): (JSC::FTL::ExitValue::dead): (JSC::FTL::ExitValue::inJSStack): (JSC::FTL::ExitValue::inJSStackAsInt32): (JSC::FTL::ExitValue::inJSStackAsDouble): (JSC::FTL::ExitValue::constant): (JSC::FTL::ExitValue::exitArgument): (JSC::FTL::ExitValue::kind): (JSC::FTL::ExitValue::isDead): (JSC::FTL::ExitValue::isInJSStackSomehow): (JSC::FTL::ExitValue::isConstant): (JSC::FTL::ExitValue::isArgument): * ftl/FTLFormattedValue.h: (FTL): (JSC::FTL::noValue): (JSC::FTL::int32Value): (JSC::FTL::uInt32Value): (JSC::FTL::booleanValue): (JSC::FTL::jsValueValue): (JSC::FTL::doubleValue): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::initializeExitThunks): (FTL): (JSC::FTL::JITCode::exitThunks): * ftl/FTLJITCode.h: (JITCode): * ftl/FTLLowerDFGToLLVM.cpp: (FTL): (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::lower): (JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments): (JSC::FTL::LowerDFGToLLVM::compileBlock): (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetLocal): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::compileMovHint): (JSC::FTL::LowerDFGToLLVM::compileZombieHint): (JSC::FTL::LowerDFGToLLVM::compileMovHintAndCheck): (JSC::FTL::LowerDFGToLLVM::compileAdd): (JSC::FTL::LowerDFGToLLVM::compileArithSub): (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileArithNegate): (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber): (JSC::FTL::LowerDFGToLLVM::compileCheckStructure): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::speculateBackward): (JSC::FTL::LowerDFGToLLVM::speculateForward): (JSC::FTL::LowerDFGToLLVM::speculate): (JSC::FTL::LowerDFGToLLVM::terminate): (JSC::FTL::LowerDFGToLLVM::backwardTypeCheck): (JSC::FTL::LowerDFGToLLVM::forwardTypeCheck): (JSC::FTL::LowerDFGToLLVM::typeCheck): (JSC::FTL::LowerDFGToLLVM::appendTypeCheck): (JSC::FTL::LowerDFGToLLVM::lowInt32): (JSC::FTL::LowerDFGToLLVM::lowCell): (JSC::FTL::LowerDFGToLLVM::lowBoolean): (JSC::FTL::LowerDFGToLLVM::speculateObject): (JSC::FTL::LowerDFGToLLVM::isLive): (JSC::FTL::LowerDFGToLLVM::use): (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock): (JSC::FTL::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode): (JSC::FTL::LowerDFGToLLVM::tryToSetConstantExitArgument): (JSC::FTL::LowerDFGToLLVM::addExitArgument): (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks): (JSC::FTL::LowerDFGToLLVM::observeMovHint): * ftl/FTLOSRExit.cpp: Added. (FTL): (JSC::FTL::OSRExit::OSRExit): (JSC::FTL::OSRExit::codeLocationForRepatch): (JSC::FTL::OSRExit::convertToForward): * ftl/FTLOSRExit.h: Added. (FTL): (OSRExit): * ftl/FTLOSRExitCompilationInfo.h: Added. (FTL): (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo): (OSRExitCompilationInfo): * ftl/FTLOSRExitCompiler.cpp: Added. (FTL): (JSC::FTL::compileStub): (JSC::FTL::compileFTLOSRExit): * ftl/FTLOSRExitCompiler.h: Added. (FTL): * ftl/FTLOutput.h: (JSC::FTL::Output::newBlock): (JSC::FTL::Output::intToPtr): (JSC::FTL::Output::load): (JSC::FTL::Output::store): (Output): (JSC::FTL::Output::call): (JSC::FTL::Output::convertToTailCall): (FTL): * ftl/FTLState.h: (State): * ftl/FTLThunks.cpp: Added. (FTL): (JSC::FTL::osrExitGenerationThunkGenerator): * ftl/FTLThunks.h: Added. (JSC): (FTL): * ftl/FTLValueFormat.cpp: Added. (WTF): (WTF::printInternal): * ftl/FTLValueFormat.h: Added. (FTL): (WTF): * ftl/FTLValueSource.cpp: Added. (FTL): (JSC::FTL::ValueSource::dump): * ftl/FTLValueSource.h: Added. (FTL): (ValueSource): (JSC::FTL::ValueSource::ValueSource): (JSC::FTL::ValueSource::kind): (JSC::FTL::ValueSource::operator!): (JSC::FTL::ValueSource::node): 2013-04-12 Filip Pizlo fourthTier: switch to using MCJIT and disable frame pointer elimination https://bugs.webkit.org/show_bug.cgi?id=114542 Reviewed by Oliver Hunt and Michael Saboff. * ftl/FTLCompile.cpp: (JSC::FTL::compile): * runtime/InitializeThreading.cpp: (JSC::initializeThreadingOnce): 2013-04-09 Filip Pizlo fourthTier: DFG should provide utilities for common OSR exit tasks https://bugs.webkit.org/show_bug.cgi?id=114306 Reviewed by Mark Hahnenberg. Just abstract out some things that the FTL will want to use as well. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler.h: (OSRExitCompiler): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: Added. (DFG): (JSC::DFG::handleExitCounts): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGOSRExitCompilerCommon.h: Added. (DFG): 2013-04-09 Filip Pizlo fourthTier: DFG should better abstract floating point arguments https://bugs.webkit.org/show_bug.cgi?id=114300 Reviewed by Mark Hahnenberg. * dfg/DFGFPRInfo.h: (FPRInfo): (JSC::DFG::FPRInfo::toArgumentRegister): 2013-04-05 Filip Pizlo fourthTier: DFG should better abstract arguments https://bugs.webkit.org/show_bug.cgi?id=114073 Reviewed by Mark Hahnenberg. * dfg/DFGGPRInfo.h: (GPRInfo): (JSC::DFG::GPRInfo::toArgumentRegister): 2013-04-03 Filip Pizlo fourthTier: put DFG data into a DFG::JITCode, and put common DFG and FTL data into something accessible from both DFG::JITCode and FTL::JITCode https://bugs.webkit.org/show_bug.cgi?id=113905 Reviewed by Geoffrey Garen. This removes one pointer from CodeBlock. It also gives us a framework for having JITType-specific data in CodeBlock, by putting it into the appropriate JITCode class (either DFG::JITCode or FTL::JITCode). And it allows us to have DFG and FTL share some common data, via DFG::CommonData, which is stored in both DFG::JITCode and FTL::JITCode and always accessible via JITCode::dfgCommon(). * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CodeBlock.cpp: (JSC): (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::visitAggregate): (JSC::CodeBlock::performTracingFixpointIteration): (JSC::CodeBlock::finalizeUnconditionally): (JSC::CodeBlock::stronglyVisitWeakReferences): (JSC::CodeBlock::shrinkToFit): (JSC::CodeBlock::tallyFrequentExitSites): * bytecode/CodeBlock.h: (CodeBlock): (JSC::CodeBlock::setJITCode): (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan): (JSC::DFGCodeBlocks::mark): * dfg/DFGAssemblyHelpers.h: * dfg/DFGCommonData.cpp: Added. (DFG): (JSC::DFG::CommonData::notifyCompilingStructureTransition): (JSC::DFG::CommonData::shrinkToFit): * dfg/DFGCommonData.h: Added. (JSC): (DFG): (JSC::DFG::WeakReferenceTransition::WeakReferenceTransition): (WeakReferenceTransition): (CommonData): (JSC::DFG::CommonData::CommonData): * dfg/DFGDriver.cpp: (JSC::DFG::compile): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGDriver.h: (DFG): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGGraph.h: (Graph): * dfg/DFGJITCode.cpp: Added. (DFG): (JSC::DFG::JITCode::JITCode): (JSC::DFG::JITCode::~JITCode): (JSC::DFG::JITCode::dfgCommon): (JSC::DFG::JITCode::dfg): (JSC::DFG::JITCode::shrinkToFit): * dfg/DFGJITCode.h: Added. (DFG): (JITCode): (JSC::DFG::JITCode::appendOSREntryData): (JSC::DFG::JITCode::osrEntryDataForBytecodeIndex): (JSC::DFG::JITCode::appendOSRExit): (JSC::DFG::JITCode::lastOSRExit): (JSC::DFG::JITCode::appendSpeculationRecovery): (JSC::DFG::JITCode::appendWatchpoint): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::JITCompiler): (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JITCompiler): (JSC::DFG::JITCompiler::addWeakReference): (JSC::DFG::JITCompiler::noticeOSREntry): (JSC::DFG::JITCompiler::jitCode): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExit.h: (OSRExit): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::SpeculativeJIT): (JSC::DFG::SpeculativeJIT::backwardSpeculationCheck): (JSC::DFG::SpeculativeJIT::speculationWatchpoint): (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGVariableEventStream.cpp: * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::JITCode): (JSC::FTL::JITCode::~JITCode): (FTL): (JSC::FTL::JITCode::initializeCode): (JSC::FTL::JITCode::addressForCall): (JSC::FTL::JITCode::executableAddressAtOffset): (JSC::FTL::JITCode::dataAddressAtOffset): (JSC::FTL::JITCode::offsetOf): (JSC::FTL::JITCode::size): (JSC::FTL::JITCode::contains): (JSC::FTL::JITCode::ftl): (JSC::FTL::JITCode::dfgCommon): * ftl/FTLJITCode.h: (JITCode): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint): (JSC::FTL::LowerDFGToLLVM::compilePutStructure): (JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure): (JSC::FTL::LowerDFGToLLVM::addWeakReference): (LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::weakPointer): * ftl/FTLState.cpp: (FTL): (JSC::FTL::State::State): (JSC::FTL::State::dumpState): * ftl/FTLState.h: (State): * heap/DFGCodeBlocks.cpp: (JSC::DFGCodeBlocks::~DFGCodeBlocks): (JSC::DFGCodeBlocks::jettison): (JSC::DFGCodeBlocks::clearMarks): (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks): (JSC::DFGCodeBlocks::traceMarkedCodeBlocks): * jit/JITCode.cpp: (JSC::JITCode::dfgCommon): (JSC): (JSC::JITCode::dfg): (JSC::JITCode::ftl): (JSC::DirectJITCode::DirectJITCode): (JSC::DirectJITCode::initializeCodeRef): (JSC::DirectJITCode::addressForCall): (JSC::DirectJITCode::executableAddressAtOffset): (JSC::DirectJITCode::dataAddressAtOffset): (JSC::DirectJITCode::offsetOf): (JSC::DirectJITCode::size): (JSC::DirectJITCode::contains): * jit/JITCode.h: (DFG): (FTL): (JSC): (JITCode): (DirectJITCode): 2013-04-03 Filip Pizlo fourthTier: Include LLVM headers with surrounding #pragmas instead of using my #define https://bugs.webkit.org/show_bug.cgi?id=113921 Reviewed by Oliver Hunt. The LLVM community wants us to continue including all of LLVM's C++ headers. Change to using #pragma's to disable warnings that they cannot handle. * ftl/FTLLLVMHeaders.h: 2013-04-03 Filip Pizlo fourthTier: Everyone should know about the FTL https://bugs.webkit.org/show_bug.cgi?id=113897 Reviewed by Mark Hahnenberg. In order to get OSR exit to work right, we need the distinction between DFG and FTL to be clear even after compilation finishes, since they will have subtly different OSR stories and likely use different data structures. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resetStubInternal): (JSC::ProgramCodeBlock::compileOptimized): (JSC::EvalCodeBlock::compileOptimized): (JSC::FunctionCodeBlock::compileOptimized): (JSC::CodeBlock::adjustedExitCountThreshold): (JSC::CodeBlock::tallyFrequentExitSites): * bytecode/CodeBlock.h: (JSC::CodeBlock::setJITCode): (JSC::CodeBlock::hasOptimizedReplacement): (JSC::ExecState::isInlineCallFrame): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::JITCode): * ftl/FTLState.cpp: (JSC::FTL::State::dumpState): * heap/DFGCodeBlocks.cpp: (JSC::DFGCodeBlocks::jettison): * interpreter/Interpreter.cpp: (JSC::getLineNumberForCallFrame): (JSC::getCallerInfo): * jit/JITCode.cpp: (WTF::printInternal): * jit/JITCode.h: (JSC::JITCode::topTierJIT): (JSC::JITCode::nextTierJIT): (JITCode): (JSC::JITCode::isJIT): (JSC::JITCode::isLowerTier): (JSC::JITCode::isHigherTier): (JSC::JITCode::isLowerOrSameTier): (JSC::JITCode::isHigherOrSameTier): (JSC::JITCode::isOptimizingJIT): * jit/JITDriver.h: (JSC::jitCompileIfAppropriate): (JSC::jitCompileFunctionIfAppropriate): * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * runtime/Executable.cpp: (JSC::EvalExecutable::compileOptimized): (JSC::samplingDescription): (JSC::ProgramExecutable::compileOptimized): (JSC::FunctionExecutable::compileOptimizedForCall): (JSC::FunctionExecutable::compileOptimizedForConstruct): 2013-04-03 Filip Pizlo fourthTier: DFG should abstract out how it does forward exits, and that code should be simplified https://bugs.webkit.org/show_bug.cgi?id=113894 Reviewed by Mark Hahnenberg. 1) We previously had two different ways of convertingToForward, one path for where we had a ValueRecovery for the current node and one where we didn't. But the paths were doing exactly the same thing except that if you have a ValueRecovery, you also find the last applicable mov hint and do some extra things. This patch combines the two paths and bases both of them on the previous no-ValueRecovery path, which was simpler to begin with. 2) This moves the logic into DFG::OSRExit, which further simplifies the code and makes the logic available to the FTL. * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::convertToForward): (DFG): * dfg/DFGOSRExit.h: (DFG): (OSRExit): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): 2013-04-02 Filip Pizlo fourthTier: FTL should have the equivalent of a ValueRecovery https://bugs.webkit.org/show_bug.cgi?id=113819 Reviewed by Mark Hahnenberg. This adds a way of saying that we have a value, we don't want to say what node the value came from, but we know specifics of how the value is formatted. This is the LLVM equivalent of DFG's ValueRecovery. * JavaScriptCore.xcodeproj/project.pbxproj: * ftl/FTLFormattedValue.h: Added. (FTL): (FormattedValue): (JSC::FTL::FormattedValue::FormattedValue): (JSC::FTL::FormattedValue::operator!): (JSC::FTL::FormattedValue::format): (JSC::FTL::FormattedValue::value): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber): (JSC::FTL::LowerDFGToLLVM::speculateForward): (JSC::FTL::LowerDFGToLLVM::weakPointer): 2013-04-02 Filip Pizlo fourthTier: FTL should use the right abstract heap for Int32 array accesses https://bugs.webkit.org/show_bug.cgi?id=113759 Reviewed by Mark Hahnenberg. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetByVal): 2013-04-02 Filip Pizlo fourthTier: FTL should support fast property stores https://bugs.webkit.org/show_bug.cgi?id=113757 Reviewed by Oliver Hunt. Simplified the task of handling property transitions and reduced amount of code duplication between the JITs. Added PutByOffset, PutStructure, PhantomPutStructure, WeakJSConstant, and a stub form of StructureTransitionWatchpoint to the FTL. Also simplified the creation of pointer constants, and fixed a bug in speculateObject(). * dfg/DFGGraph.h: (JSC::DFG::Graph::notifyCompilingStructureTransition): (Graph): * dfg/DFGJITCompiler.h: (JITCompiler): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::lower): (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileWeakJSConstant): (LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint): (JSC::FTL::LowerDFGToLLVM::compilePutStructure): (JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure): (JSC::FTL::LowerDFGToLLVM::compilePutByOffset): (JSC::FTL::LowerDFGToLLVM::speculateObject): (JSC::FTL::LowerDFGToLLVM::weakPointer): * ftl/FTLOutput.h: (Output): (JSC::FTL::Output::constIntPtr): (JSC::FTL::Output::absolute): 2013-04-01 Filip Pizlo fourthTier: FTL should support some more integer arithmetic ops (negate, xor, urshift) https://bugs.webkit.org/show_bug.cgi?id=113740 Reviewed by Geoffrey Garen. * ftl/FTLAbbreviations.h: (JSC::FTL::buildNeg): (JSC::FTL::buildLShr): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileArithNegate): (LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::compileBitXor): (JSC::FTL::LowerDFGToLLVM::compileBitURShift): (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber): * ftl/FTLOutput.h: (JSC::FTL::Output::neg): (JSC::FTL::Output::lShr): 2013-04-01 Filip Pizlo fourthTier: FTL should support GetGlobalVar/PutGlobalVar https://bugs.webkit.org/show_bug.cgi?id=113728 Reviewed by Gavin Barraclough. Removed the macro magic for the globals absolute abstract heap, since for anything with absolute addresses we can just share a common absolute abstract heap. It would only be a problem if we for example were emitting an access to a global but not using an absolute address, and then wanted to say that this access was constrained to global variables. I don't believe we do that, and I don't believe we ever will. Then added Output::absolute(), a convenient way of building a typed pointer for an absolute address. Then added GetGlobalVar/PutGlobalVar. * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository): * ftl/FTLAbstractHeapRepository.h: (FTL): (AbstractHeapRepository): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetGlobalVar): (LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar): * ftl/FTLOutput.h: (JSC::FTL::Output::absolute): (Output): 2013-03-31 Filip Pizlo fourthTier: FTL should support ArithSub https://bugs.webkit.org/show_bug.cgi?id=113675 Reviewed by Oliver Hunt. This does the obvious bit of implementing ArithSub, but it also takes this as an opportunity to clean up how intrinsics and common values (common types and constants) are handled. Previously they were all lumped together in FTL::Output. Now, in an effort to split up the files and make FTL::Output less big, I created a thing called FTL::CommonValues which just tracks the common values, and a thing called FTL::IntrinsicRepository which just tracks intrinsics. These and FTL::Output are all related to each other in a linear hierarchy. Moreover, IntrinsicRepository uses macro-fu to make it easy to declare new intrinsics in the future. I also out-of-lined some things and made .cpp files for each of these classes. Initialize I wasn't going to do this but then I realized that FTL::Output is already included in multiple places. Probably it's better if some of its guts are not inline, and it's also good to now have .cpp "landing pads" if we ever want to add more things to that class. Note that a lot of how these things are designed has to do with the fact that pretty soon here I'll have to switch us from using the LLVM global context to using a context that we create. When that happens, anyone who creates anything will have to know the context; that's why FTL::CommonValues already knows the module but doesn't use it - in the future it will have to do things with it. * JavaScriptCore.xcodeproj/project.pbxproj: * ftl/FTLAbbreviations.h: (JSC::FTL::buildSub): * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLCommonValues.cpp: Added. (FTL): (JSC::FTL::CommonValues::CommonValues): * ftl/FTLCommonValues.h: Added. (FTL): (CommonValues): (JSC::FTL::CommonValues::initialize): * ftl/FTLIntrinsicRepository.cpp: Added. (FTL): (JSC::FTL::IntrinsicRepository::IntrinsicRepository): * ftl/FTLIntrinsicRepository.h: Added. (FTL): (IntrinsicRepository): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileArithSub): (LowerDFGToLLVM): * ftl/FTLOutput.cpp: Added. (FTL): (JSC::FTL::Output::Output): (JSC::FTL::Output::~Output): * ftl/FTLOutput.h: (Output): (JSC::FTL::Output::initialize): (JSC::FTL::Output::sub): (JSC::FTL::Output::addWithOverflow32): (JSC::FTL::Output::subWithOverflow32): (JSC::FTL::Output::mulWithOverflow32): 2013-03-31 Filip Pizlo fourthTier: FTL doesn't need virtual register allocation https://bugs.webkit.org/show_bug.cgi?id=113679 Reviewed by Mark Hahnenberg. * dfg/DFGDriver.cpp: (JSC::DFG::dumpAndVerifyGraph): (DFG): (JSC::DFG::compile): 2013-03-31 Filip Pizlo https://bugs.webkit.org/show_bug.cgi?id=113656 Fix Sam's nits. Unreviewed. * ftl/FTLAbstractHeap.cpp: (JSC::FTL::IndexedAbstractHeap::initialize): * ftl/FTLAbstractHeap.h: (IndexedAbstractHeap): (AbsoluteAbstractHeap): * ftl/FTLAbstractHeapRepository.h: (AbstractHeapRepository): 2013-03-31 Filip Pizlo fourthTier: FTL JIT should support GetByVal on Int32 arrays https://bugs.webkit.org/show_bug.cgi?id=113668 Reviewed by Sam Weinig. It actually already supported this, but needed to be told that it did. Also adds an option to enable LICM (loop-invariant code motion, i.e. http://llvm.org/docs/Passes.html#licm-loop-invariant-code-motion). LICM isn't doing me any good right now, but I guess I'll have to play with it more. And this adds the ability to tweak the LLVM optimization level from the command-line. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetByVal): * runtime/Options.h: (JSC): 2013-03-31 Filip Pizlo fourthTier: FTL JIT should supply TBAA meta-data to LLVM https://bugs.webkit.org/show_bug.cgi?id=113656 Reviewed by Oliver Hunt. This adds support for performing strong typing on the LLVM IR that the FTL generates, by using TBAA meta-data. This will permit LLVM to do aggressive GVN, load elimination, and LICM optimization even if it sees pointer store side-effects. The goal is to precisely model all loads and stores we emit, except for the super crazy ones (GetById that can go all-out polymorphic, or for example a Call where we know nothing). This is accomplished by introducing the notion of an AbstractHeap typesystem. An AbstractHeap is a subset of all possible memory locations that we might store to. For example, JSCell::m_structure and JSObject::m_butterfly are two disjoint AbstractHeaps because we know that a store to one cannot clobber the other. AbstractHeaps follow a single-inheritance hierarchy. There is the root heap, which corresponds to any possible memory location accessible to the JS engine, and then there are heaps for all internal object fields, a heap for each global object, and so on. There are three other tidbits here that make this somewhat more interesting. We have a notion of an AbstractHeap-with-offset, called AbstractField. JSCell::m_structure is actually an AbstractField. This allows us to say things like m_out.loadPtr(base, m_heaps.JSCell_structure); this both gives you the offset of JSCell::m_structure and ascribes TBAA meta-data for the JSCell::m_structure heap to the generated load instrction. Another fun tidbit is the notion of Indexed, Numbered, and Absolute abstract heaps. An indexed abstract heap corresponds to a set of locations that you might access by index from some base. Virtual registers are a great example. Though I call them just "variables" in the FTL. When we access a virtual register, we know that we aren't interfering with accesses to Structure-managed named properties, or with JSCell::m_structure, or with other such disjoint heaps. But we also know that if we access a variable at offset X and then another variable at offset Y and we know that X and Y are unequal, then these two accesses are on disjoint subheaps of the variables heap. This works out naturally for interference between, say, scoped variable access and local variable access: if you access scoped variable r5 and then access a local variable r5, these might interfere - and they will get the same abstract subheap of the variables heap. IndexedAbstractHeaps conveniently remember the size of the elements and will give you an AbstractField (i.e. heap-with-offset) if you give it an index. This is great for conveniently writing code that accesses contiguous arrays of well-typed things. This allows you to literally do things like m_out.load64(callFrameRegister, m_heaps.variables[operand]) and the right thing will happen. You can also get the heap variables.atAnyIndex(), if you're doing an access with an unknown index. Numbered and Absolute abstract heaps are related except that they don't assume that the value used to get the abstract subheap corresponds to any meaningful offset from any base. Numbered heaps, like the properties heap (for named properties tracked by Structure), are "numbered" (not indexed) by the propertyNumber. So you can emit a GetByOffset by separately computing the offset and the propertyNumber (both values are stored in the StorageAccessData), and passing the offset directly to Output::address() and passing m_heaps.properties[propertyNumber] as the field. Absolute heaps are similar, but are keyed on absolute address. This is appropriate for global variables, and possibly other things. Finally, FTL::Output understands the notion of a pointer-with-TBAA-data, and calls it a TypedPointer. TypedPointer is a tuple of a LLVMValueRef referencing an intptr value and a pointer to an AbstractHeap. All load() and store() operations now take a TypedPointer, and will perform the access by casting the intptr to a pointer of the right type and then ascribing the TBAA meta-data from the AbstractHeap. * JavaScriptCore.xcodeproj/project.pbxproj: * ftl/FTLAbbreviations.h: (JSC::FTL::mdKindID): (JSC::FTL::mdString): (JSC::FTL::mdNode): (FTL): (JSC::FTL::setMetadata): * ftl/FTLAbstractHeap.cpp: Added. (FTL): (JSC::FTL::AbstractHeap::tbaaMetadataSlow): (JSC::FTL::AbstractHeap::decorateInstruction): (JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap): (JSC::FTL::IndexedAbstractHeap::~IndexedAbstractHeap): (JSC::FTL::IndexedAbstractHeap::baseIndex): (JSC::FTL::IndexedAbstractHeap::atSlow): (JSC::FTL::IndexedAbstractHeap::initialize): (JSC::FTL::NumberedAbstractHeap::NumberedAbstractHeap): (JSC::FTL::NumberedAbstractHeap::~NumberedAbstractHeap): (JSC::FTL::AbsoluteAbstractHeap::AbsoluteAbstractHeap): (JSC::FTL::AbsoluteAbstractHeap::~AbsoluteAbstractHeap): * ftl/FTLAbstractHeap.h: Added. (FTL): (AbstractHeap): (JSC::FTL::AbstractHeap::AbstractHeap): (JSC::FTL::AbstractHeap::isInitialized): (JSC::FTL::AbstractHeap::initialize): (JSC::FTL::AbstractHeap::parent): (JSC::FTL::AbstractHeap::heapName): (JSC::FTL::AbstractHeap::tbaaMetadata): (AbstractField): (JSC::FTL::AbstractField::AbstractField): (JSC::FTL::AbstractField::initialize): (JSC::FTL::AbstractField::offset): (IndexedAbstractHeap): (JSC::FTL::IndexedAbstractHeap::atAnyIndex): (JSC::FTL::IndexedAbstractHeap::at): (JSC::FTL::IndexedAbstractHeap::operator[]): (JSC::FTL::IndexedAbstractHeap::returnInitialized): (JSC::FTL::IndexedAbstractHeap::MyHashTraits::constructDeletedValue): (JSC::FTL::IndexedAbstractHeap::MyHashTraits::isDeletedValue): (NumberedAbstractHeap): (JSC::FTL::NumberedAbstractHeap::atAnyNumber): (JSC::FTL::NumberedAbstractHeap::at): (JSC::FTL::NumberedAbstractHeap::operator[]): (AbsoluteAbstractHeap): (JSC::FTL::AbsoluteAbstractHeap::atAnyAddress): (JSC::FTL::AbsoluteAbstractHeap::at): (JSC::FTL::AbsoluteAbstractHeap::operator[]): * ftl/FTLAbstractHeapRepository.cpp: Added. (FTL): (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository): (JSC::FTL::AbstractHeapRepository::~AbstractHeapRepository): * ftl/FTLAbstractHeapRepository.h: Added. (FTL): (AbstractHeapRepository): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::lower): (JSC::FTL::LowerDFGToLLVM::compileCheckStructure): (JSC::FTL::LowerDFGToLLVM::compileGetButterfly): (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compileGetByOffset): (JSC::FTL::LowerDFGToLLVM::speculateObject): (JSC::FTL::LowerDFGToLLVM::addressFor): (JSC::FTL::LowerDFGToLLVM::payloadFor): (JSC::FTL::LowerDFGToLLVM::tagFor): (LowerDFGToLLVM): * ftl/FTLOutput.h: (FTL): (JSC::FTL::Output::Output): (JSC::FTL::Output::initialize): (JSC::FTL::Output::set): (JSC::FTL::Output::load): (JSC::FTL::Output::store): (Output): (JSC::FTL::Output::load32): (JSC::FTL::Output::load64): (JSC::FTL::Output::loadPtr): (JSC::FTL::Output::store32): (JSC::FTL::Output::store64): (JSC::FTL::Output::storePtr): (JSC::FTL::Output::addPtr): (JSC::FTL::Output::address): (JSC::FTL::Output::baseIndex): * ftl/FTLTypedPointer.h: Added. (FTL): (TypedPointer): (JSC::FTL::TypedPointer::TypedPointer): (JSC::FTL::TypedPointer::operator!): (JSC::FTL::TypedPointer::heap): (JSC::FTL::TypedPointer::value): * runtime/Options.h: (JSC): 2013-03-30 Filip Pizlo fourthTier: FTL JIT should be able to compile the Array.prototype.findGraphNode function in Kraken/ai-astar https://bugs.webkit.org/show_bug.cgi?id=113646 Reviewed by Oliver Hunt. This adds enough FTL support to compile Array.prototype.findGraphNode. This isn't a speed-up, yet, because findGraphNode tends to be aggressively inlined by the DFG, and the FTL can't yet compile the things into which it was inlined. In future patches we will get to a point where we can compile the callers, and then we'll be able to see what the performance effects are. But the interesting thing is that it isn't a slow-down, either. This implies that even if we FTL compile a CodeBlock that we shouldn't have (the fact that we compiling things that end up being inlined is dumb, and the fact that the current FTL tiering strategy launches LLVM for those things is even dumber), we still run at OK performance. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments): (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileCheckStructure): (LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::compileGetButterfly): (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compileGetByOffset): (JSC::FTL::LowerDFGToLLVM::compileCompareEq): (JSC::FTL::LowerDFGToLLVM::lowInt32): (JSC::FTL::LowerDFGToLLVM::lowCell): (JSC::FTL::LowerDFGToLLVM::lowObject): (JSC::FTL::LowerDFGToLLVM::lowBoolean): (JSC::FTL::LowerDFGToLLVM::lowJSValue): (JSC::FTL::LowerDFGToLLVM::lowStorage): (JSC::FTL::LowerDFGToLLVM::isNotInt32): (JSC::FTL::LowerDFGToLLVM::isNotCell): (JSC::FTL::LowerDFGToLLVM::isNotBoolean): (JSC::FTL::LowerDFGToLLVM::speculate): (JSC::FTL::LowerDFGToLLVM::speculateCell): (JSC::FTL::LowerDFGToLLVM::speculateObject): (JSC::FTL::LowerDFGToLLVM::accountedPointer): (JSC::FTL::LowerDFGToLLVM::weakPointer): * ftl/FTLOutput.h: (JSC::FTL::Output::Output): (JSC::FTL::Output::insertNewBlocksBefore): (JSC::FTL::Output::appendTo): (Output): (JSC::FTL::Output::baseIndex): 2013-03-29 Filip Pizlo fourthTier: FTL JIT should be able to compile the Marsaglia random number generator https://bugs.webkit.org/show_bug.cgi?id=113635 Reviewed by Oliver Hunt. Just adding missing functionality. Also "fixed" OSR exit to use a call to abort() in addition to using Unreachable since the latter doesn't actually mean trap - quite the opposite, it tells LLVM that the code can never be reached. The Marsaglia function runs ~60% faster with FTL, than DFG. Not a terrible start. * JavaScriptCore.xcodeproj/project.pbxproj: * ftl/FTLAbbreviations.h: (FTL): (JSC::FTL::voidType): (JSC::FTL::structType): (JSC::FTL::functionType): (JSC::FTL::addFunction): (JSC::FTL::setLinkage): (JSC::FTL::setFunctionCallingConv): (JSC::FTL::addExternFunction): (JSC::FTL::constIntToPtr): (JSC::FTL::constBitCast): (JSC::FTL::buildMul): (JSC::FTL::buildOr): (JSC::FTL::buildShl): (JSC::FTL::buildAShr): (JSC::FTL::buildCall): (JSC::FTL::buildExtractValue): (JSC::FTL::dumpModule): (JSC::FTL::verifyModule): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::lower): (JSC::FTL::LowerDFGToLLVM::compileBlock): (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileAdd): (LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileBitAnd): (JSC::FTL::LowerDFGToLLVM::compileBitOr): (JSC::FTL::LowerDFGToLLVM::compileBitRShift): (JSC::FTL::LowerDFGToLLVM::compileBitLShift): (JSC::FTL::LowerDFGToLLVM::compileCompareLess): (JSC::FTL::LowerDFGToLLVM::compileBranch): (JSC::FTL::LowerDFGToLLVM::speculateBackward): (JSC::FTL::LowerDFGToLLVM::lowBoolean): * ftl/FTLOutput.h: (JSC::FTL::Output::Output): (JSC::FTL::Output::initialize): (JSC::FTL::Output::appendTo): (Output): (JSC::FTL::Output::mul): (JSC::FTL::Output::bitOr): (JSC::FTL::Output::shl): (JSC::FTL::Output::aShr): (JSC::FTL::Output::addWithOverflow32): (JSC::FTL::Output::mulWithOverflow32): (JSC::FTL::Output::extractValue): (JSC::FTL::Output::call): (JSC::FTL::Output::addWithOverflow32Function): (JSC::FTL::Output::mulWithOverflow32Function): * ftl/FTLState.cpp: Added. (FTL): (JSC::FTL::State::dumpState): * ftl/FTLState.h: (State): 2013-03-29 Filip Pizlo Unreviewed, release mode build fix. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::lowInt32): (JSC::FTL::LowerDFGToLLVM::lowCell): (JSC::FTL::LowerDFGToLLVM::lowBoolean): (JSC::FTL::LowerDFGToLLVM::lowJSValue): 2013-03-29 Filip Pizlo fourthTier: Change DO_NOT_INCLUDE_LLVM_CPP_HEADERS to LLVM_DO_NOT_INCLUDE_CPP_HEADERS https://bugs.webkit.org/show_bug.cgi?id=113634 Reviewed by Dan Bernstein. * ftl/FTLLLVMHeaders.h: 2013-03-29 Filip Pizlo fourthTier: FTL JIT should be able run some simple function https://bugs.webkit.org/show_bug.cgi?id=113481 Reviewed by Geoffrey Garen. I forgot to make a couple of the requested review changes, so I'm making them now! * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLJITCode.h: 2013-03-29 Filip Pizlo fourthTier: FTL JIT should be able run some simple function https://bugs.webkit.org/show_bug.cgi?id=113481 Reviewed by Geoffrey Garen. This is the initial version of the FTL JIT (Fourth Tier LLVM JIT). It includes a lowering from the DFG IR to LLVM IR (FTL::lowerDFGToLLVM) and a "backend" step that invokes the LLVM and wraps the resulting function in a thunk (FTL::compile). All LLVM IR building functions are wrapped up into a nicer FTL API. First they're wrapped in an abbreviated API (FTLAbbreviations.h) and then again into an object-oriented IR builder (FTLOutput.h). This runs things. I don't know how fast it runs things. And I don't make any claims of stability. The FTL is runtime-disabled by default; you will enable it by doing --useExperimentalFTL=true. Probably if you do this, you will run slower, because of the heavy thunking we do, the fact that we don't have anything resembling a sensible tiering story, and because we only compile ridiculously tiny functions. Finally, this still requires a custom set of LLVM headers to build. I am working on getting that up-streamed to LLVM, and separately I'll make sure that we have a build checked into this branch. * Configurations/JavaScriptCore.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/Operands.h: (Operands): (JSC::Operands::Operands): * dfg/DFGAbstractState.h: (JSC::DFG::AbstractState::needsTypeCheck): (AbstractState): (JSC::DFG::AbstractState::filterEdgeByUse): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkArgumentTypes): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::needsTypeCheck): (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand): (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand): (DFG): * dfg/DFGUseKind.h: (JSC::DFG::shouldNotHaveTypeCheck): (DFG): (JSC::DFG::mayHaveTypeCheck): (JSC::DFG::isDouble): (JSC::DFG::isCell): * ftl: Added. * ftl/FTLAbbreviations.h: Added. (FTL): (JSC::FTL::int1Type): (JSC::FTL::int32Type): (JSC::FTL::int64Type): (JSC::FTL::intPtrType): (JSC::FTL::pointerType): (JSC::FTL::getParam): (JSC::FTL::constInt): (JSC::FTL::appendBasicBlock): (JSC::FTL::insertBasicBlock): (JSC::FTL::buildAlloca): (JSC::FTL::buildAdd): (JSC::FTL::buildAnd): (JSC::FTL::buildXor): (JSC::FTL::buildLoad): (JSC::FTL::buildStore): (JSC::FTL::buildZExt): (JSC::FTL::buildIntCast): (JSC::FTL::buildIntToPtr): (JSC::FTL::buildPtrToInt): (JSC::FTL::buildICmp): (JSC::FTL::buildSelect): (JSC::FTL::buildBr): (JSC::FTL::buildCondBr): (JSC::FTL::buildRet): (JSC::FTL::buildUnreachable): * ftl/FTLCapabilities.cpp: Added. (FTL): (JSC::FTL::canCompile): * ftl/FTLCapabilities.h: Added. (FTL): * ftl/FTLCompile.cpp: Added. (FTL): (JSC::FTL::compileEntry): (JSC::FTL::compile): * ftl/FTLCompile.h: Added. (FTL): * ftl/FTLJITCode.cpp: Added. (FTL): (JSC::FTL::JITCode::JITCode): (JSC::FTL::JITCode::~JITCode): (JSC::FTL::JITCode::addressForCall): (JSC::FTL::JITCode::executableAddressAtOffset): (JSC::FTL::JITCode::dataAddressAtOffset): (JSC::FTL::JITCode::offsetOf): (JSC::FTL::JITCode::size): (JSC::FTL::JITCode::contains): * ftl/FTLJITCode.h: Added. (FTL): (JITCode): * ftl/FTLLLVMHeaders.h: Added. * ftl/FTLLowerDFGToLLVM.cpp: Added. (FTL): (LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM): (JSC::FTL::LowerDFGToLLVM::lower): (JSC::FTL::LowerDFGToLLVM::addFlushedLocalOpRoots): (JSC::FTL::LowerDFGToLLVM::closeOverFlushedLocalOps): (JSC::FTL::LowerDFGToLLVM::addFlushedLocalOp): (JSC::FTL::LowerDFGToLLVM::addFlushedLocalEdge): (JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments): (JSC::FTL::LowerDFGToLLVM::compileBlock): (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileJSConstant): (JSC::FTL::LowerDFGToLLVM::compileGetLocal): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (JSC::FTL::LowerDFGToLLVM::compileMovHintAndCheck): (JSC::FTL::LowerDFGToLLVM::compilePhantom): (JSC::FTL::LowerDFGToLLVM::compileReturn): (JSC::FTL::LowerDFGToLLVM::speculateBackward): (JSC::FTL::LowerDFGToLLVM::speculateForward): (JSC::FTL::LowerDFGToLLVM::speculate): (JSC::FTL::LowerDFGToLLVM::terminate): (JSC::FTL::LowerDFGToLLVM::backwardTypeCheck): (JSC::FTL::LowerDFGToLLVM::forwardTypeCheck): (JSC::FTL::LowerDFGToLLVM::typeCheck): (JSC::FTL::LowerDFGToLLVM::lowInt32): (JSC::FTL::LowerDFGToLLVM::lowCell): (JSC::FTL::LowerDFGToLLVM::lowBoolean): (JSC::FTL::LowerDFGToLLVM::lowJSValue): (JSC::FTL::LowerDFGToLLVM::checkNotInt32): (JSC::FTL::LowerDFGToLLVM::unboxInt32): (JSC::FTL::LowerDFGToLLVM::boxInt32): (JSC::FTL::LowerDFGToLLVM::checkNotCell): (JSC::FTL::LowerDFGToLLVM::checkNotBoolean): (JSC::FTL::LowerDFGToLLVM::unboxBoolean): (JSC::FTL::LowerDFGToLLVM::boxBoolean): (JSC::FTL::LowerDFGToLLVM::speculateInt32): (JSC::FTL::LowerDFGToLLVM::addressFor): (JSC::FTL::LowerDFGToLLVM::payloadFor): (JSC::FTL::LowerDFGToLLVM::tagFor): (JSC::FTL::LowerDFGToLLVM::globalData): (JSC::FTL::LowerDFGToLLVM::codeBlock): (JSC::FTL::lowerDFGToLLVM): * ftl/FTLLowerDFGToLLVM.h: Added. (FTL): * ftl/FTLOutput.h: Added. (FTL): (Output): (JSC::FTL::Output::Output): (JSC::FTL::Output::~Output): (JSC::FTL::Output::initialize): (JSC::FTL::Output::appendTo): (JSC::FTL::Output::newBlock): (JSC::FTL::Output::param): (JSC::FTL::Output::constBool): (JSC::FTL::Output::constInt32): (JSC::FTL::Output::constIntPtr): (JSC::FTL::Output::constInt64): (JSC::FTL::Output::add): (JSC::FTL::Output::bitAnd): (JSC::FTL::Output::bitXor): (JSC::FTL::Output::zeroExt): (JSC::FTL::Output::intCast): (JSC::FTL::Output::castToInt32): (JSC::FTL::Output::get): (JSC::FTL::Output::set): (JSC::FTL::Output::load): (JSC::FTL::Output::store): (JSC::FTL::Output::load32): (JSC::FTL::Output::load64): (JSC::FTL::Output::loadPtr): (JSC::FTL::Output::store32): (JSC::FTL::Output::store64): (JSC::FTL::Output::storePtr): (JSC::FTL::Output::equal): (JSC::FTL::Output::notEqual): (JSC::FTL::Output::above): (JSC::FTL::Output::aboveOrEqual): (JSC::FTL::Output::below): (JSC::FTL::Output::belowOrEqual): (JSC::FTL::Output::greaterThan): (JSC::FTL::Output::greaterThanOrEqual): (JSC::FTL::Output::lessThan): (JSC::FTL::Output::lessThanOrEqual): (JSC::FTL::Output::isZero64): (JSC::FTL::Output::notZero64): (JSC::FTL::Output::testNonZero64): (JSC::FTL::Output::select): (JSC::FTL::Output::jump): (JSC::FTL::Output::branch): (JSC::FTL::Output::ret): (JSC::FTL::Output::unreachable): * ftl/FTLState.h: Added. (FTL): (State): (JSC::FTL::State::State): * runtime/InitializeThreading.cpp: (JSC::initializeThreadingOnce): * runtime/Options.h: (JSC): 2013-03-27 Filip Pizlo fourthTier: JITCode should abstract exactly how the JIT code is structured and where it was allocated https://bugs.webkit.org/show_bug.cgi?id=113437 Reviewed by Mark Hahnenberg. JITCode is now a virtual base class, which will allow different JITs to have radically different memory allocation and management conventions in the future. It will also make it easier to store JIT-specific meta-data in CodeBlock just by putting it into an appropriate JITCode subclass. For now there is one subclass, DirectJITCode, which just behaves like JITCode used to behave. * assembler/RepatchBuffer.h: (JSC::RepatchBuffer::RepatchBuffer): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resetStubInternal): (JSC::CodeBlock::bytecodeOffset): (JSC::CodeBlock::codeOriginForReturn): * bytecode/CodeBlock.h: (JSC::CodeBlock::setJITCode): (JSC::CodeBlock::getJITCode): (JSC::CodeBlock::getJITType): (CodeBlock): * dfg/DFGDriver.cpp: (JSC::DFG::compile): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGDriver.h: (DFG): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JITCompiler): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::codeLocationForRepatch): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOperations.cpp: * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JIT.h: (JSC::JIT::compile): (JIT): * jit/JITCode.cpp: (JSC): (JSC::JITCode::JITCode): (JSC::JITCode::~JITCode): (JSC::JITCode::execute): (JSC::JITCode::hostFunction): (JSC::DirectJITCode::DirectJITCode): (JSC::DirectJITCode::~DirectJITCode): (JSC::DirectJITCode::addressForCall): (JSC::DirectJITCode::executableAddressAtOffset): (JSC::DirectJITCode::dataAddressAtOffset): (JSC::DirectJITCode::offsetOf): (JSC::DirectJITCode::size): (JSC::DirectJITCode::contains): * jit/JITCode.h: (JSC): (JITCode): (JSC::JITCode::bottomTierJIT): (JSC::JITCode::topTierJIT): (JSC::JITCode::nextTierJIT): (JSC::JITCode::isOptimizingJIT): (JSC::JITCode::isBaselineCode): (JSC::JITCode::jitType): (JSC::JITCode::jitTypeFor): (JSC::JITCode::executableAddress): (JSC::JITCode::start): (JSC::JITCode::end): (DirectJITCode): * jit/JITDriver.h: (JSC::jitCompileIfAppropriate): (JSC::jitCompileFunctionIfAppropriate): * jit/JITStubs.cpp: (JSC::lazyLinkFor): (JSC::DEFINE_STUB_FUNCTION): * jit/ThunkGenerators.cpp: (JSC::virtualForGenerator): * llint/LLIntEntrypoints.cpp: (JSC::LLInt::getFunctionEntrypoint): (JSC::LLInt::getEvalEntrypoint): (JSC::LLInt::getProgramEntrypoint): * llint/LLIntEntrypoints.h: (JSC): (LLInt): (JSC::LLInt::getEntrypoint): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): (JSC::LLInt::entryOSR): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Executable.cpp: (JSC::EvalExecutable::compileInternal): (JSC::ProgramExecutable::compileInternal): (JSC::FunctionExecutable::compileForCallInternal): (JSC::FunctionExecutable::compileForConstructInternal): * runtime/Executable.h: (JSC::ExecutableBase::generatedJITCodeForCall): (JSC::ExecutableBase::generatedJITCodeForConstruct): (JSC::ExecutableBase::generatedJITCodeFor): (ExecutableBase): (JSC::ExecutableBase::hostCodeEntryFor): (JSC::ExecutableBase::jsCodeEntryFor): (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor): (JSC::NativeExecutable::create): (JSC::NativeExecutable::finishCreation): (JSC::EvalExecutable::generatedJITCode): (JSC::ProgramExecutable::generatedJITCode): * runtime/ExecutionHarness.h: (JSC::prepareForExecution): (JSC::prepareFunctionForExecution): 2013-07-16 Oliver Hunt Merged dfgFourthTier r148570 2013-04-16 Filip Pizlo fourthTier: DFG should be able to query Structure without modifying it https://bugs.webkit.org/show_bug.cgi?id=114708 Reviewed by Oliver Hunt. This is work towards allowing the DFG, and FTL, to run on a separate thread. The idea is that the most evil thing that the DFG does that has thread-safety issues is fiddling with Structures by calling Structure::get(). This can lead to rematerialization of property tables, which is definitely not thread-safe due to how StringImpl works. So, this patch completely side-steps the problem by creating a new version of Structure::get, called Structure::getWithoutMaterializing, which may choose to do an O(n) search if necessary to avoid materialization. I believe this should be fine - the DFG does't call into these code path often enough for this to matter, and most of the time, the Structure that we call this on will already have a property table because some inline cache would have already called ::get() on that Structure. Also cleaned up the materialization logic: we can stop the search as soon as we find any Structure with a property table rather than searching all the way for a pinned one. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFor): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): (JSC::PutByIdStatus::computeFor): * runtime/Structure.cpp: (JSC::Structure::findStructuresAndMapForMaterialization): (JSC::Structure::materializePropertyMap): (JSC::Structure::getWithoutMaterializing): (JSC): * runtime/Structure.h: (Structure): * runtime/StructureInlines.h: (JSC::Structure::getWithoutMaterializing): (JSC): 2013-07-15 Oliver Hunt Merged dfgFourthTier r148047 2013-04-09 Filip Pizlo fourthTier: DFG should provide utilities for common OSR exit tasks https://bugs.webkit.org/show_bug.cgi?id=114306 Reviewed by Mark Hahnenberg. Just abstract out some things that the FTL will want to use as well. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler.h: (OSRExitCompiler): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: Added. (DFG): (JSC::DFG::handleExitCounts): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGOSRExitCompilerCommon.h: Added. (DFG): 2013-07-15 Oliver Hunt Merged dfgFourthTier r148037 2013-04-09 Filip Pizlo fourthTier: DFG should better abstract floating point arguments https://bugs.webkit.org/show_bug.cgi?id=114300 Reviewed by Mark Hahnenberg. * dfg/DFGFPRInfo.h: (FPRInfo): (JSC::DFG::FPRInfo::toArgumentRegister): 2013-07-15 Oliver Hunt Merged dfgFourthTier r147821 2013-04-05 Filip Pizlo fourthTier: DFG should better abstract arguments https://bugs.webkit.org/show_bug.cgi?id=114073 Reviewed by Mark Hahnenberg. * dfg/DFGGPRInfo.h: (GPRInfo): (JSC::DFG::GPRInfo::toArgumentRegister): 2013-07-15 Oliver Hunt Merged dfgFourthTier r147609 2013-04-03 Filip Pizlo fourthTier: put DFG data into a DFG::JITCode, and put common DFG and FTL data into something accessible from both DFG::JITCode and FTL::JITCode https://bugs.webkit.org/show_bug.cgi?id=113905 Reviewed by Geoffrey Garen. This removes one pointer from CodeBlock. It also gives us a framework for having JITType-specific data in CodeBlock, by putting it into the appropriate JITCode class (either DFG::JITCode or FTL::JITCode). And it allows us to have DFG and FTL share some common data, via DFG::CommonData, which is stored in both DFG::JITCode and FTL::JITCode and always accessible via JITCode::dfgCommon(). * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CodeBlock.cpp: (JSC): (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::visitAggregate): (JSC::CodeBlock::performTracingFixpointIteration): (JSC::CodeBlock::finalizeUnconditionally): (JSC::CodeBlock::stronglyVisitWeakReferences): (JSC::CodeBlock::shrinkToFit): (JSC::CodeBlock::tallyFrequentExitSites): * bytecode/CodeBlock.h: (CodeBlock): (JSC::CodeBlock::setJITCode): (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan): (JSC::DFGCodeBlocks::mark): * dfg/DFGAssemblyHelpers.h: * dfg/DFGCommonData.cpp: Added. (DFG): (JSC::DFG::CommonData::notifyCompilingStructureTransition): (JSC::DFG::CommonData::shrinkToFit): * dfg/DFGCommonData.h: Added. (JSC): (DFG): (JSC::DFG::WeakReferenceTransition::WeakReferenceTransition): (WeakReferenceTransition): (CommonData): (JSC::DFG::CommonData::CommonData): * dfg/DFGDriver.cpp: (JSC::DFG::compile): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGDriver.h: (DFG): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGGraph.h: (Graph): * dfg/DFGJITCode.cpp: Added. (DFG): (JSC::DFG::JITCode::JITCode): (JSC::DFG::JITCode::~JITCode): (JSC::DFG::JITCode::dfgCommon): (JSC::DFG::JITCode::dfg): (JSC::DFG::JITCode::shrinkToFit): * dfg/DFGJITCode.h: Added. (DFG): (JITCode): (JSC::DFG::JITCode::appendOSREntryData): (JSC::DFG::JITCode::osrEntryDataForBytecodeIndex): (JSC::DFG::JITCode::appendOSRExit): (JSC::DFG::JITCode::lastOSRExit): (JSC::DFG::JITCode::appendSpeculationRecovery): (JSC::DFG::JITCode::appendWatchpoint): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::JITCompiler): (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JITCompiler): (JSC::DFG::JITCompiler::addWeakReference): (JSC::DFG::JITCompiler::noticeOSREntry): (JSC::DFG::JITCompiler::jitCode): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExit.h: (OSRExit): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::SpeculativeJIT): (JSC::DFG::SpeculativeJIT::backwardSpeculationCheck): (JSC::DFG::SpeculativeJIT::speculationWatchpoint): (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGVariableEventStream.cpp: * heap/DFGCodeBlocks.cpp: (JSC::DFGCodeBlocks::~DFGCodeBlocks): (JSC::DFGCodeBlocks::jettison): (JSC::DFGCodeBlocks::clearMarks): (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks): (JSC::DFGCodeBlocks::traceMarkedCodeBlocks): * jit/JITCode.cpp: (JSC::JITCode::dfgCommon): (JSC): (JSC::JITCode::dfg): (JSC::JITCode::ftl): (JSC::DirectJITCode::DirectJITCode): (JSC::DirectJITCode::initializeCodeRef): (JSC::DirectJITCode::addressForCall): (JSC::DirectJITCode::executableAddressAtOffset): (JSC::DirectJITCode::dataAddressAtOffset): (JSC::DirectJITCode::offsetOf): (JSC::DirectJITCode::size): (JSC::DirectJITCode::contains): * jit/JITCode.h: (DFG): (FTL): (JSC): (JITCode): (DirectJITCode): 2013-07-15 Oliver Hunt Merge dfgFourthTier r147587 2013-04-03 Filip Pizlo fourthTier: Everyone should know about the FTL https://bugs.webkit.org/show_bug.cgi?id=113897 Reviewed by Mark Hahnenberg. In order to get OSR exit to work right, we need the distinction between DFG and FTL to be clear even after compilation finishes, since they will have subtly different OSR stories and likely use different data structures. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resetStubInternal): (JSC::ProgramCodeBlock::compileOptimized): (JSC::EvalCodeBlock::compileOptimized): (JSC::FunctionCodeBlock::compileOptimized): (JSC::CodeBlock::adjustedExitCountThreshold): (JSC::CodeBlock::tallyFrequentExitSites): * bytecode/CodeBlock.h: (JSC::CodeBlock::setJITCode): (JSC::CodeBlock::hasOptimizedReplacement): (JSC::ExecState::isInlineCallFrame): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::JITCode): * ftl/FTLState.cpp: (JSC::FTL::State::dumpState): * heap/DFGCodeBlocks.cpp: (JSC::DFGCodeBlocks::jettison): * interpreter/Interpreter.cpp: (JSC::getLineNumberForCallFrame): (JSC::getCallerInfo): * jit/JITCode.cpp: (WTF::printInternal): * jit/JITCode.h: (JSC::JITCode::topTierJIT): (JSC::JITCode::nextTierJIT): (JITCode): (JSC::JITCode::isJIT): (JSC::JITCode::isLowerTier): (JSC::JITCode::isHigherTier): (JSC::JITCode::isLowerOrSameTier): (JSC::JITCode::isHigherOrSameTier): (JSC::JITCode::isOptimizingJIT): * jit/JITDriver.h: (JSC::jitCompileIfAppropriate): (JSC::jitCompileFunctionIfAppropriate): * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * runtime/Executable.cpp: (JSC::EvalExecutable::compileOptimized): (JSC::samplingDescription): (JSC::ProgramExecutable::compileOptimized): (JSC::FunctionExecutable::compileOptimizedForCall): (JSC::FunctionExecutable::compileOptimizedForConstruct): 2013-04-03 Filip Pizlo fourthTier: DFG should abstract out how it does forward exits, and that code should be simplified https://bugs.webkit.org/show_bug.cgi?id=113894 Reviewed by Mark Hahnenberg. 1) We previously had two different ways of convertingToForward, one path for where we had a ValueRecovery for the current node and one where we didn't. But the paths were doing exactly the same thing except that if you have a ValueRecovery, you also find the last applicable mov hint and do some extra things. This patch combines the two paths and bases both of them on the previous no-ValueRecovery path, which was simpler to begin with. 2) This moves the logic into DFG::OSRExit, which further simplifies the code and makes the logic available to the FTL. * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::convertToForward): (DFG): * dfg/DFGOSRExit.h: (DFG): (OSRExit): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): 2013-07-15 Oliver Hunt Merge dfgFourthTier r147582 2013-07-15 Oliver Hunt Merge dfgFourthTier r147014 2013-03-27 Filip Pizlo fourthTier: JITCode should abstract exactly how the JIT code is structured and where it was allocated https://bugs.webkit.org/show_bug.cgi?id=113437 Reviewed by Mark Hahnenberg. JITCode is now a virtual base class, which will allow different JITs to have radically different memory allocation and management conventions in the future. It will also make it easier to store JIT-specific meta-data in CodeBlock just by putting it into an appropriate JITCode subclass. For now there is one subclass, DirectJITCode, which just behaves like JITCode used to behave. * assembler/RepatchBuffer.h: (JSC::RepatchBuffer::RepatchBuffer): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resetStubInternal): (JSC::CodeBlock::bytecodeOffset): (JSC::CodeBlock::codeOriginForReturn): * bytecode/CodeBlock.h: (JSC::CodeBlock::setJITCode): (JSC::CodeBlock::getJITCode): (JSC::CodeBlock::getJITType): (CodeBlock): * dfg/DFGDriver.cpp: (JSC::DFG::compile): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGDriver.h: (DFG): (JSC::DFG::tryCompile): (JSC::DFG::tryCompileFunction): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JITCompiler): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::codeLocationForRepatch): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOperations.cpp: * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JIT.h: (JSC::JIT::compile): (JIT): * jit/JITCode.cpp: (JSC): (JSC::JITCode::JITCode): (JSC::JITCode::~JITCode): (JSC::JITCode::execute): (JSC::JITCode::hostFunction): (JSC::DirectJITCode::DirectJITCode): (JSC::DirectJITCode::~DirectJITCode): (JSC::DirectJITCode::addressForCall): (JSC::DirectJITCode::executableAddressAtOffset): (JSC::DirectJITCode::dataAddressAtOffset): (JSC::DirectJITCode::offsetOf): (JSC::DirectJITCode::size): (JSC::DirectJITCode::contains): * jit/JITCode.h: (JSC): (JITCode): (JSC::JITCode::bottomTierJIT): (JSC::JITCode::topTierJIT): (JSC::JITCode::nextTierJIT): (JSC::JITCode::isOptimizingJIT): (JSC::JITCode::isBaselineCode): (JSC::JITCode::jitType): (JSC::JITCode::jitTypeFor): (JSC::JITCode::executableAddress): (JSC::JITCode::start): (JSC::JITCode::end): (DirectJITCode): * jit/JITDriver.h: (JSC::jitCompileIfAppropriate): (JSC::jitCompileFunctionIfAppropriate): * jit/JITStubs.cpp: (JSC::lazyLinkFor): (JSC::DEFINE_STUB_FUNCTION): * jit/ThunkGenerators.cpp: (JSC::virtualForGenerator): * llint/LLIntEntrypoints.cpp: (JSC::LLInt::getFunctionEntrypoint): (JSC::LLInt::getEvalEntrypoint): (JSC::LLInt::getProgramEntrypoint): * llint/LLIntEntrypoints.h: (JSC): (LLInt): (JSC::LLInt::getEntrypoint): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): (JSC::LLInt::entryOSR): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Executable.cpp: (JSC::EvalExecutable::compileInternal): (JSC::ProgramExecutable::compileInternal): (JSC::FunctionExecutable::compileForCallInternal): (JSC::FunctionExecutable::compileForConstructInternal): * runtime/Executable.h: (JSC::ExecutableBase::generatedJITCodeForCall): (JSC::ExecutableBase::generatedJITCodeForConstruct): (JSC::ExecutableBase::generatedJITCodeFor): (ExecutableBase): (JSC::ExecutableBase::hostCodeEntryFor): (JSC::ExecutableBase::jsCodeEntryFor): (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor): (JSC::NativeExecutable::create): (JSC::NativeExecutable::finishCreation): (JSC::EvalExecutable::generatedJITCode): (JSC::ProgramExecutable::generatedJITCode): * runtime/ExecutionHarness.h: (JSC::prepareForExecution): (JSC::prepareFunctionForExecution): 2013-07-24 Filip Pizlo It should be possible to hijack IndexingHeader for things other than lengths https://bugs.webkit.org/show_bug.cgi?id=119065 Reviewed by Mark Hahnenberg. Made the body of IndexingHeader be a union. Modified the offlineasm so that you can say IndexingHeader::u.lengths.publicLength. Previously those dots would cause parse errors. Now an identifier in offlineasm can have a dot anywhere except the first character. * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/parser.rb: * runtime/IndexingHeader.h: (JSC::IndexingHeader::offsetOfPublicLength): (JSC::IndexingHeader::offsetOfVectorLength): (JSC::IndexingHeader::IndexingHeader): (JSC::IndexingHeader::vectorLength): (JSC::IndexingHeader::setVectorLength): (JSC::IndexingHeader::publicLength): (JSC::IndexingHeader::setPublicLength): 2013-07-24 Mark Hahnenberg JIT::updateTopCallFrame doesn't update the CallFrame's bytecodeOffset if bytecodeOffset == 0 https://bugs.webkit.org/show_bug.cgi?id=118923 Reviewed by Filip Pizlo. This bug causes the CallFrame's bytecodeOffset to not be properly set when we enter, e.g., cti_optimize from an op_enter. * jit/JITInlines.h: (JSC::JIT::updateTopCallFrame): 2013-07-23 Filip Pizlo DFG string concatenation optimizations might emit speculative nodes after emitting nodes that kill the original inputs https://bugs.webkit.org/show_bug.cgi?id=119032 Reviewed by Oliver Hunt. It just needs some Phantom action. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd): 2013-07-10 Mark Lam Need ExpressionRangeInfo before ResolveForPuts in strict mode. https://bugs.webkit.org/show_bug.cgi?id=118997. Reviewed by Oliver Hunt. If we add an assertion in UnlinkedCodeBlock::expressionRangeForBytecodeOffset() to ensure that we are able to find an ExpressionRangeInfo for any given bytecode offset, the following tests will fails: fast/js/basic-strict-mode.html fast/js/mozilla/strict/8.7.2.html With this fix, those tests will no longer fail. * bytecompiler/NodesCodegen.cpp: (JSC::AssignResolveNode::emitBytecode): (JSC::ForInNode::emitBytecode): - Emit expression info before calls to emitResolveBaseForPut() when in strict mode. 2013-07-23 Mark Lam Added ExpressionRangeInfo for BinaryOpNodes that can throw exceptions due to type coersion. https://bugs.webkit.org/show_bug.cgi?id=116853. Reviewed by Geoffrey Garen. * bytecompiler/NodesCodegen.cpp: (JSC::BinaryOpNode::emitBytecode): - Added expression info for the strcat and the general binary op cases. I did not add expression info for the "compare with null" case because that comparison cannot trigger type coersion, and hence it won't throw any exceptions and doesn't need the expression info. 2013-07-23 Mark Lam Removed unused sourceOffset from JSTokenLocation. https://bugs.webkit.org/show_bug.cgi?id=118996. Reviewed by Geoffrey Garen. This also removes the assertion reported in the bug because it is now moot, thereby resolving the assertion failure issue on Windows. * bytecompiler/NodesCodegen.cpp: (JSC::ArrayNode::toArgumentList): (JSC::ApplyFunctionCallDotNode::emitBytecode): * parser/Lexer.cpp: (JSC::::lex): * parser/Lexer.h: (JSC::::lexExpectIdentifier): * parser/Nodes.h: * parser/Parser.cpp: (JSC::::Parser): (JSC::::parseFunctionInfo): (JSC::::parseExpressionOrLabelStatement): (JSC::::parseMemberExpression): * parser/Parser.h: (JSC::::parse): * parser/ParserTokens.h: (JSC::JSTokenLocation::JSTokenLocation): 2013-07-22 Alex Christensen Added assembly files to Windows 64-bit builds. https://bugs.webkit.org/show_bug.cgi?id=118931 Reviewed by Brent Fulgham. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Added JITStubsMSVC64.asm for x64 and enabled MASM. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Added JITStubsMSVC64.asm. 2013-07-20 Brent Fulgham [Windows] Remove unneeded custom stdint.h now that we build on VS2010. https://bugs.webkit.org/show_bug.cgi?id=118868. Reviewed by Anders Carlsson. * os-win32/stdint.h: Removed. * GNUmakefile.list.am: Removed reference to os-win32/stdint.h 2013-07-19 Alex Christensen Added x64 configuration to Visual Studio build. https://bugs.webkit.org/show_bug.cgi?id=118888 Reviewed by Brent Fulgham. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: 2013-07-18 Andreas Kling CodeBlock DFG entry list isn't getting shrunk-to-fit after linking. Reviewed by Geoffrey Garen. Move the CodeBlock::shrinkToFit() call out of JITCompiler::link() and to the call sites so SpeculativeJIT::linkOSREntries() can fill in CodeBlock::m_dfgData->osrEntry first. 886 kB progression on * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): 2013-07-18 Chris Curtis Fixed ASSERTION FAILED: callFrame == globalData->topCallFrame in JSC::Interpreter::addStackTraceIfNecessary https://bugs.webkit.org/show_bug.cgi?id=118498 Reviewed by Geoffrey Garen. * jit/JITStubs.cpp: (throwExceptionFromOpCall): Created new throwExceptionFromOpCall that takes in a functor that contains a function pointer (to create the errorObject) instead of a JSValue. Inside of throwExceptionFromOpCall the topCallFrame is being rolled back in order to handle the error throw. By passing the function pointer in, we can defer the creation of the error object until after topCallFrame has been rolled back. This allows the error object to be created with the appropriate top frame. DEFINE_STUB_FUNCTION(void*, stack_check): DEFINE_STUB_FUNCTION(void*, op_call_arityCheck): DEFINE_STUB_FUNCTION(void*, op_construct_arityCheck): DEFINE_STUB_FUNCTION(EncodedJSValue, op_call_NotJSFunction): DEFINE_STUB_FUNCTION(EncodedJSValue, op_construct_NotJSConstruct): (JSC::ErrorFunctor::~ErrorFunctor): (JSC::ErrorWithExecFunctor::ErrorWithExecFunctor): (JSC::ErrorWithExecFunctor::operator()): (JSC::ErrorWithExecAndCalleeFunctor::ErrorWithExecAndCalleeFunctor): (JSC::ErrorWithExecAndCalleeFunctor::operator()): (JSC::ErrorWithExceptionFunctor::ErrorWithExceptionFunctor): (JSC::ErrorWithExceptionFunctor::operator()): (JSC::throwExceptionFromOpCall): In order to eliminate the need to duplicate code, an error functor was created for the 3 different throwExceptionFromOpCall handles. 1. The exception needs to be created, and the function pointer takes 1 parameter(callFrame->callerFrame()). 2. The exception needs to be created, and the function pointer takes 2 parameters (callFrame->callerFrame(), callFrame.calleeAsValue()). 3. The exception is already created. In this case, At the time when the error functor is called, globalData.exception is returned. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/ExceptionHelpers.cpp: (JSC::errorDescriptionForValue): (JSC::createError): (JSC::createInvalidParameterError): (JSC::createNotAConstructorError): (JSC::createNotAFunctionError): (JSC::createNotAnObjectError): * runtime/ExceptionHelpers.h: The function toString() was being used to stringify an object for an exception message. If the user wrote a toString() for that object, then the system would continue to evaluate that code. A new helper function was created to prevent the system to continue execution and exception creation from that execution. 2013-07-18 Filip Pizlo LLInt get_argument_by_val for JSVALUE64 stores into the array profile when it meant to store into the value profile https://bugs.webkit.org/show_bug.cgi?id=118865 Reviewed by Mark Hahnenberg. * llint/LowLevelInterpreter64.asm: 2013-07-18 Andreas Kling CodeBlock::m_argumentValueProfiles wastes a lot of memory. Reviewed by Anders Carlsson. Use Vector::resizeToFit() for CodeBlock::m_argumentValueProfiles. We don't need any padding for growth, since we won't be appending to it anyway. 921 KB progression on * bytecode/CodeBlock.cpp: (JSC::CodeBlock::setNumParameters): 2013-07-17 Filip Pizlo Unreviewed, fix 32-bit after http://trac.webkit.org/changeset/152813 * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2013-07-17 Geoffrey Garen API tests should test for JSStringCreateWithCFString with empty string https://bugs.webkit.org/show_bug.cgi?id=118819 Reviewed by Mark Hahnenberg. * API/tests/testapi.c: (main): Test! 2013-07-17 Filip Pizlo DFG assumes that NewFunction will never pass its input through https://bugs.webkit.org/show_bug.cgi?id=118798 Reviewed by Sam Weinig. Previously the DFG was assuming that NewFunction always returns a function. That's not the case. It may return whatever was passed to it, if it wasn't passed SpecEmpty. This fact needed to be wired through the compiler. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::executeEffects): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::makeTop): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2013-07-17 Geoffrey Garen JSStringCreateWithCFString should not convert the empty string into the NULL string https://bugs.webkit.org/show_bug.cgi?id=118816 Reviewed by Sam Weinig. * API/JSStringRef.cpp: (JSStringCreateWithUTF8CString): Removed an extraneous comment, which a previous version of the patch made incorrect. * API/JSStringRefCF.cpp: (JSStringCreateWithCFString): Don't convert the empty string into the null string. 2013-07-17 Chris Curtis Naming convention on createInvalidParamError is incorrect. https://bugs.webkit.org/show_bug.cgi?id=118756 Reviewed by Geoffrey Garen. Changed the naming of createInvalidParamError to createInvalidParameterError. This corrects the naming convention for the function listed in the WebKit code styling. * interpreter/Interpreter.cpp: (JSC::loadVarargs): * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::opIn): * runtime/ExceptionHelpers.cpp: (JSC::createInvalidParameterError): * runtime/ExceptionHelpers.h: * runtime/JSObject.cpp: (JSC::JSObject::hasInstance): 2013-07-16 David Farler Typo in DFGInsertionSet.h header guard: "DFGInsectionSet_h" -> "DFGInsertionSet_h" https://bugs.webkit.org/show_bug.cgi?id=118753 Reviewed by Geoffrey Garen. * dfg/DFGInsertionSet.h: "DFGInsectionSet_h" -> "DFGInsertionSet_h" 2013-07-16 Filip Pizlo MakeRope fixup shouldn't lead to an Identity without kids https://bugs.webkit.org/show_bug.cgi?id=118745 Reviewed by Mark Hahnenberg. Make the empty string pruning part of fixupMakeRope() stop if it's on the last child. Make Node::convertToIdentity release-assert that it has exactly one kid. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupMakeRope): * dfg/DFGNode.h: (JSC::DFG::Node::convertToIdentity): 2013-07-16 Mark Hahnenberg Remove reference to JSValueStructSupport.h from JSExport.h https://bugs.webkit.org/show_bug.cgi?id=118746 Reviewed by Filip Pizlo. * API/JSExport.h: No such header exists, so it doesn't make sense to reference it. 2013-07-13 Commit Queue Unreviewed, rolling out r151978. http://trac.webkit.org/changeset/151978 https://bugs.webkit.org/show_bug.cgi?id=118651 Caused regressions at least 3 websites (Requested by rniwa on #webkit). * runtime/JSCJSValue.h: * runtime/JSString.h: 2013-07-12 Chris Curtis Optimize addStrackTraceIfNecessary to be faster in the case when it's not necessary https://bugs.webkit.org/show_bug.cgi?id=118328 Reviewed by Geoffrey Garen. Retrieving the stack is costly. We want to get it only once. By moving the check for the .stack property above the code to retrieve the stack, we ensure this. * interpreter/Interpreter.cpp: (JSC::Interpreter::addStackTraceIfNecessary): 2013-07-12 Brent Fulgham [Windows] Build correction after r152573/r152577. https://bugs.webkit.org/show_bug.cgi?id=118610 Reviewed by Oliver Hunt. * jit/JITThunks.cpp: (JSC::JITThunks::hostFunctionStub): Hand-feed MSVC++ the fact that we want the second argument of the make_pair to be a function pointer. 2013-07-11 Oliver Hunt Attempt to fix the windows build. * jit/JITThunks.cpp: (JSC::JITThunks::hostFunctionStub): * jit/JITThunks.h: 2013-07-10 Oliver Hunt NativeExecutable cache needs to use both call and construct functions for key https://bugs.webkit.org/show_bug.cgi?id=118545 Reviewed by Geoffrey Garen. Make the native executable cache make use a key pair so we don't decide to treat all subsequent functions as not being constructors. * jit/JITThunks.cpp: (JSC::JITThunks::hostFunctionStub): * jit/JITThunks.h: * runtime/JSBoundFunction.cpp: (JSC::JSBoundFunction::create): * runtime/JSCell.cpp: (JSC::JSCell::getCallData): (JSC::JSCell::getConstructData): 2013-07-09 Mark Lam Gardening to unbreak builds on the Windows bot. Not reviewed. * parser/ParserTokens.h: 2013-07-09 Mark Lam Fix 30% JSBench regression (caused by adding column numbers to stack traces). https://bugs.webkit.org/show_bug.cgi?id=118481. Reviewed by Mark Hahnenberg and Geoffrey Garen. Previously, we already capture ExpressionRangeInfo that provides a divot for each bytecode that can potentially throw an exception (and therefore generate a stack trace). On first attempt to compute column numbers, we then do a walk of the source string to record all line start positions in a table associated with the SourceProvider. The column number can then be computed as divot - lineStartFor(bytecodeOffset). The computation of this lineStarts table is the source of the 30% JSBench performance regression. The new code now records lineStarts as the lexer and parser scans the source code. These lineStarts are then used to compute the column number for the given divot, and stored in the ExpressionRangeInfo. Similarly, we also capture the line number at the divot point and store that in the ExpressionRangeInfo. Hence, to look up line and column numbers, we now lookup the ExpressionRangeInfo for the bytecodeOffset, and then compute the line and column from the values stored in the expression info. The strategy: 1. We want to minimize perturbations to the lexer and parser. Specifically, the changes added should not change how it scans code, and generate bytecode. 2. We regard the divot as the source character position we are interested in. As such, we'll capture line and lineStart (for column) at the point when we capture the divot information. This ensures that the 3 values are consistent. How the change is done: 1. Change the lexer to track lineStarts. 2. Change the parser to capture line and lineStarts at the point of capturing divots. 3. Change the parser and associated code to plumb these values all the way to the point that the correspoinding ExpressionRangeInfo is emitted. 4. Propagate and record SourceCode firstLine and firstLineColumnOffset to the the necessary places so that we can add them as needed when reifying UnlinkedCodeBlocks into CodeBlocks. 5. Compress the line and column number values in the ExpressionRangeInfo. In practice, we seldom have both large line and column numbers. Hence, we can encode both in an uint32_t most of the time. For the times when we encounter both large line and column numbers, we have a fallback to store the "fat" position info. 6. Emit an ExpressionRangeInfo for UnaryOp nodes to get more line and column number coverage. 7. Change the interpreter to use the new way of computing line and column. 8. Delete old line and column computation code that is now unused. Misc details: - the old lexer was tracking both a startOffset and charPosition where charPosition equals startOffset - SourceCode.startOffset. We now use startOffset exclusively throughout the system for consistency. All offset values (including lineStart) are relative to the start of the SourceProvider string. These values will only be converted to be relative to the SourceCode.startOffset at the very last minute i.e. when the divot is stored into the ExpressionRangeInfo. This change to use the same offset system everywhere reduces confusion from having to convert back and forth between the 2 systems. It also enables a lot of assertions to be used. - Also fixed some bugs in the choice of divot positions to use. For example, both Eval and Function expressions previously used column numbers from the start of the expression but used the line number at the end of the expression. This is now fixed to use either the start or end positions as appropriate, but not a mix of line and columns from both. - Why use ints instead of unsigneds for offsets and lineStarts inside the lexer and parser? Some tests (e.g. fast/js/call-base-resolution.html and fast/js/eval-cross-window.html) has shown that lineStart offsets can be prior to the SourceCode.startOffset. Keeping the lexer offsets as ints simplifies computations and makes it easier to maintain the assertions that (startOffset >= lineStartOffset). However, column and line numbers are always unsigned when we publish them to the ExpressionRangeInfo. The ints are only used inside the lexer and parser ... well, and bytecode generator. - For all cases, lineStart is always captured where the divot is captured. However, some sputnik conformance tests have shown that we cannot honor line breaks for assignment statements like the following: eval("x\u000A*=\u000A-1;"); In this case, the lineStart is expected to be captured at the start of the assignment expression instead of at the divot point in the middle. The assignment expression is the only special case for this. This patch has been tested against the full layout tests both with release and debug builds with no regression. * API/JSContextRef.cpp: (JSContextCreateBacktrace): - Updated to use the new StackFrame::computeLineAndColumn(). * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): - Added m_firstLineColumnOffset initialization. - Plumbed the firstLineColumnOffset into the SourceCode. - Initialized column for op_debug using the new way. (JSC::CodeBlock::lineNumberForBytecodeOffset): - Changed to compute line number using the ExpressionRangeInfo. (JSC::CodeBlock::columnNumberForBytecodeOffset): Added - Changed to compute column number using the ExpressionRangeInfo. (JSC::CodeBlock::expressionRangeForBytecodeOffset): * bytecode/CodeBlock.h: (JSC::CodeBlock::firstLineColumnOffset): (JSC::GlobalCodeBlock::GlobalCodeBlock): - Plumbed firstLineColumnOffset through to the super class. (JSC::ProgramCodeBlock::ProgramCodeBlock): - Plumbed firstLineColumnOffset through to the super class. (JSC::EvalCodeBlock::EvalCodeBlock): - Plumbed firstLineColumnOffset through to the super class. But for EvalCodeBlocks, the firstLineColumnOffset is always 1 because we're starting with a new source string with no start offset. (JSC::FunctionCodeBlock::FunctionCodeBlock): - Plumbed firstLineColumnOffset through to the super class. * bytecode/ExpressionRangeInfo.h: - Added modes for encoding line and column into a single 30-bit unsigned. The encoding is in 1 of 3 modes: 1. FatLineMode: 22-bit line, 8-bit column 2. FatColumnMode: 8-bit line, 22-bit column 3. FatLineAndColumnMode: 32-bit line, 32-bit column (JSC::ExpressionRangeInfo::encodeFatLineMode): Added. - Encodes line and column into the 30-bit position using FatLine mode. (JSC::ExpressionRangeInfo::encodeFatColumnMode): Added. - Encodes line and column into the 30-bit position using FatColumn mode. (JSC::ExpressionRangeInfo::decodeFatLineMode): Added. - Decodes the FatLine mode 30-bit position into line and column. (JSC::ExpressionRangeInfo::decodeFatColumnMode): Added. - Decodes the FatColumn mode 30-bit position into line and column. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): - Plumbed startColumn through. (JSC::UnlinkedFunctionExecutable::link): - Plumbed startColumn through. (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset): - Computes a line number using the new way. (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): - Added decoding of line and column. - Added handling of the case when we do not find a fitting expression range info for a specified bytecodeOffset. This only happens if the bytecodeOffset is below the first expression range info. In that case, we'll use the first expression range info entry. (JSC::UnlinkedCodeBlock::addExpressionInfo): - Added encoding of line and column. * bytecode/UnlinkedCodeBlock.h: - Added m_expressionInfoFatPositions in RareData. (JSC::UnlinkedFunctionExecutable::functionStartColumn): (JSC::UnlinkedCodeBlock::shrinkToFit): - Removed obsoleted m_lineInfo. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitCall): Plumbed line and lineStart through. (JSC::BytecodeGenerator::emitCallEval): Plumbed line and lineStart through. (JSC::BytecodeGenerator::emitCallVarargs): Plumbed line and lineStart through. (JSC::BytecodeGenerator::emitConstruct): Plumbed line and lineStart through. (JSC::BytecodeGenerator::emitDebugHook): Plumbed lineStart through. * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitNode): (JSC::BytecodeGenerator::emitNodeInConditionContext): - Removed obsoleted m_lineInfo. (JSC::BytecodeGenerator::emitExpressionInfo): - Plumbed line and lineStart through. - Compute the line and column to be added to the expression range info. * bytecompiler/NodesCodegen.cpp: (JSC::ThrowableExpressionData::emitThrowReferenceError): (JSC::ResolveNode::emitBytecode): (JSC::ArrayNode::toArgumentList): (JSC::BracketAccessorNode::emitBytecode): (JSC::DotAccessorNode::emitBytecode): (JSC::NewExprNode::emitBytecode): (JSC::EvalFunctionCallNode::emitBytecode): (JSC::FunctionCallValueNode::emitBytecode): (JSC::FunctionCallResolveNode::emitBytecode): (JSC::FunctionCallBracketNode::emitBytecode): (JSC::FunctionCallDotNode::emitBytecode): (JSC::CallFunctionCallDotNode::emitBytecode): (JSC::ApplyFunctionCallDotNode::emitBytecode): (JSC::PostfixNode::emitResolve): (JSC::PostfixNode::emitBracket): (JSC::PostfixNode::emitDot): (JSC::DeleteResolveNode::emitBytecode): (JSC::DeleteBracketNode::emitBytecode): (JSC::DeleteDotNode::emitBytecode): (JSC::PrefixNode::emitResolve): (JSC::PrefixNode::emitBracket): (JSC::PrefixNode::emitDot): - Plumbed line and lineStart through the above as needed. (JSC::UnaryOpNode::emitBytecode): - Added emission of an ExpressionRangeInfo for the UnaryOp node. (JSC::BinaryOpNode::emitStrcat): (JSC::ThrowableBinaryOpNode::emitBytecode): (JSC::InstanceOfNode::emitBytecode): (JSC::emitReadModifyAssignment): (JSC::ReadModifyResolveNode::emitBytecode): (JSC::AssignResolveNode::emitBytecode): (JSC::AssignDotNode::emitBytecode): (JSC::ReadModifyDotNode::emitBytecode): (JSC::AssignBracketNode::emitBytecode): (JSC::ReadModifyBracketNode::emitBytecode): - Plumbed line and lineStart through the above as needed. (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): - Plumbed line and lineStart through the above as needed. * interpreter/Interpreter.cpp: (JSC::appendSourceToError): - Added line and column arguments for expressionRangeForBytecodeOffset(). (JSC::StackFrame::computeLineAndColumn): - Replaces StackFrame::line() and StackFrame::column(). (JSC::StackFrame::expressionInfo): - Added line and column arguments. (JSC::StackFrame::toString): - Changed to use the new StackFrame::computeLineAndColumn(). (JSC::Interpreter::getStackTrace): - Added the needed firstLineColumnOffset arg for the StackFrame. * interpreter/Interpreter.h: * parser/ASTBuilder.h: (JSC::ASTBuilder::BinaryOpInfo::BinaryOpInfo): (JSC::ASTBuilder::AssignmentInfo::AssignmentInfo): (JSC::ASTBuilder::createResolve): (JSC::ASTBuilder::createBracketAccess): (JSC::ASTBuilder::createDotAccess): (JSC::ASTBuilder::createRegExp): (JSC::ASTBuilder::createNewExpr): (JSC::ASTBuilder::createAssignResolve): (JSC::ASTBuilder::createFunctionExpr): (JSC::ASTBuilder::createFunctionBody): (JSC::ASTBuilder::createGetterOrSetterProperty): (JSC::ASTBuilder::createFuncDeclStatement): (JSC::ASTBuilder::createBlockStatement): (JSC::ASTBuilder::createExprStatement): (JSC::ASTBuilder::createIfStatement): (JSC::ASTBuilder::createForLoop): (JSC::ASTBuilder::createForInLoop): (JSC::ASTBuilder::createVarStatement): (JSC::ASTBuilder::createReturnStatement): (JSC::ASTBuilder::createBreakStatement): (JSC::ASTBuilder::createContinueStatement): (JSC::ASTBuilder::createTryStatement): (JSC::ASTBuilder::createSwitchStatement): (JSC::ASTBuilder::createWhileStatement): (JSC::ASTBuilder::createDoWhileStatement): (JSC::ASTBuilder::createLabelStatement): (JSC::ASTBuilder::createWithStatement): (JSC::ASTBuilder::createThrowStatement): (JSC::ASTBuilder::createDebugger): (JSC::ASTBuilder::createConstStatement): (JSC::ASTBuilder::appendBinaryExpressionInfo): (JSC::ASTBuilder::appendUnaryToken): (JSC::ASTBuilder::unaryTokenStackLastStart): (JSC::ASTBuilder::unaryTokenStackLastLineStartPosition): Added. (JSC::ASTBuilder::assignmentStackAppend): (JSC::ASTBuilder::createAssignment): (JSC::ASTBuilder::setExceptionLocation): (JSC::ASTBuilder::makeDeleteNode): (JSC::ASTBuilder::makeFunctionCallNode): (JSC::ASTBuilder::makeBinaryNode): (JSC::ASTBuilder::makeAssignNode): (JSC::ASTBuilder::makePrefixNode): (JSC::ASTBuilder::makePostfixNode):. - Plumbed line, lineStart, and startColumn through the above as needed. * parser/Lexer.cpp: (JSC::::currentSourcePtr): (JSC::::setCode): - Added tracking for sourceoffset and lineStart. (JSC::::internalShift): (JSC::::parseIdentifier): - Added tracking for lineStart. (JSC::::parseIdentifierSlowCase): (JSC::::parseString): - Added tracking for lineStart. (JSC::::parseStringSlowCase): (JSC::::lex): - Added tracking for sourceoffset. (JSC::::sourceCode): * parser/Lexer.h: (JSC::Lexer::currentOffset): (JSC::Lexer::currentLineStartOffset): (JSC::Lexer::setOffset): - Added tracking for lineStart. (JSC::Lexer::offsetFromSourcePtr): Added. conversion function. (JSC::Lexer::sourcePtrFromOffset): Added. conversion function. (JSC::Lexer::setOffsetFromSourcePtr): (JSC::::lexExpectIdentifier): - Added tracking for sourceoffset and lineStart. * parser/NodeConstructors.h: (JSC::Node::Node): (JSC::ResolveNode::ResolveNode): (JSC::EvalFunctionCallNode::EvalFunctionCallNode): (JSC::FunctionCallValueNode::FunctionCallValueNode): (JSC::FunctionCallResolveNode::FunctionCallResolveNode): (JSC::FunctionCallBracketNode::FunctionCallBracketNode): (JSC::FunctionCallDotNode::FunctionCallDotNode): (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode): (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode): (JSC::PostfixNode::PostfixNode): (JSC::DeleteResolveNode::DeleteResolveNode): (JSC::DeleteBracketNode::DeleteBracketNode): (JSC::DeleteDotNode::DeleteDotNode): (JSC::PrefixNode::PrefixNode): (JSC::ReadModifyResolveNode::ReadModifyResolveNode): (JSC::ReadModifyBracketNode::ReadModifyBracketNode): (JSC::AssignBracketNode::AssignBracketNode): (JSC::AssignDotNode::AssignDotNode): (JSC::ReadModifyDotNode::ReadModifyDotNode): (JSC::AssignErrorNode::AssignErrorNode): (JSC::WithNode::WithNode): (JSC::ForInNode::ForInNode): - Plumbed line and lineStart through the above as needed. * parser/Nodes.cpp: (JSC::StatementNode::setLoc): Plumbed lineStart. (JSC::ScopeNode::ScopeNode): Plumbed lineStart. (JSC::ProgramNode::ProgramNode): Plumbed startColumn. (JSC::ProgramNode::create): Plumbed startColumn. (JSC::EvalNode::create): (JSC::FunctionBodyNode::FunctionBodyNode): Plumbed startColumn. (JSC::FunctionBodyNode::create): Plumbed startColumn. * parser/Nodes.h: (JSC::Node::startOffset): (JSC::Node::lineStartOffset): Added. (JSC::StatementNode::firstLine): (JSC::StatementNode::lastLine): (JSC::ThrowableExpressionData::ThrowableExpressionData): (JSC::ThrowableExpressionData::setExceptionSourceCode): (JSC::ThrowableExpressionData::divotStartOffset): (JSC::ThrowableExpressionData::divotEndOffset): (JSC::ThrowableExpressionData::divotLine): (JSC::ThrowableExpressionData::divotLineStart): (JSC::ThrowableSubExpressionData::ThrowableSubExpressionData): (JSC::ThrowableSubExpressionData::setSubexpressionInfo): (JSC::ThrowableSubExpressionData::subexpressionDivot): (JSC::ThrowableSubExpressionData::subexpressionStartOffset): (JSC::ThrowableSubExpressionData::subexpressionEndOffset): (JSC::ThrowableSubExpressionData::subexpressionLine): (JSC::ThrowableSubExpressionData::subexpressionLineStart): (JSC::ThrowablePrefixedSubExpressionData::ThrowablePrefixedSubExpressionData): (JSC::ThrowablePrefixedSubExpressionData::setSubexpressionInfo): (JSC::ThrowablePrefixedSubExpressionData::subexpressionDivot): (JSC::ThrowablePrefixedSubExpressionData::subexpressionStartOffset): (JSC::ThrowablePrefixedSubExpressionData::subexpressionEndOffset): (JSC::ThrowablePrefixedSubExpressionData::subexpressionLine): (JSC::ThrowablePrefixedSubExpressionData::subexpressionLineStart): (JSC::ScopeNode::startStartOffset): (JSC::ScopeNode::startLineStartOffset): (JSC::ProgramNode::startColumn): (JSC::EvalNode::startColumn): (JSC::FunctionBodyNode::startColumn): - Plumbed line and lineStart through the above as needed. * parser/Parser.cpp: (JSC::::Parser): (JSC::::parseSourceElements): (JSC::::parseVarDeclarationList): (JSC::::parseConstDeclarationList): (JSC::::parseForStatement): (JSC::::parseBreakStatement): (JSC::::parseContinueStatement): (JSC::::parseReturnStatement): (JSC::::parseThrowStatement): (JSC::::parseWithStatement): - Plumbed line and lineStart through the above as needed. (JSC::::parseFunctionBody): - Plumbed startColumn. (JSC::::parseFunctionInfo): (JSC::::parseFunctionDeclaration): (JSC::LabelInfo::LabelInfo): (JSC::::parseExpressionOrLabelStatement): (JSC::::parseAssignmentExpression): (JSC::::parseBinaryExpression): (JSC::::parseProperty): (JSC::::parseObjectLiteral): (JSC::::parsePrimaryExpression): (JSC::::parseMemberExpression): (JSC::::parseUnaryExpression): - Plumbed line, lineStart, startColumn through the above as needed. * parser/Parser.h: (JSC::Parser::next): (JSC::Parser::nextExpectIdentifier): (JSC::Parser::tokenStart): (JSC::Parser::tokenColumn): (JSC::Parser::tokenEnd): (JSC::Parser::tokenLineStart): (JSC::Parser::lastTokenLine): (JSC::Parser::lastTokenLineStart): (JSC::::parse): * parser/ParserTokens.h: (JSC::JSTokenLocation::JSTokenLocation): - Plumbed lineStart. (JSC::JSTokenLocation::lineStartPosition): (JSC::JSTokenLocation::startPosition): (JSC::JSTokenLocation::endPosition): * parser/SourceCode.h: (JSC::SourceCode::SourceCode): (JSC::SourceCode::startColumn): (JSC::makeSource): (JSC::SourceCode::subExpression): * parser/SourceProvider.cpp: delete old code. * parser/SourceProvider.h: delete old code. * parser/SourceProviderCacheItem.h: (JSC::SourceProviderCacheItem::closeBraceToken): (JSC::SourceProviderCacheItem::SourceProviderCacheItem): - Plumbed lineStart. * parser/SyntaxChecker.h: (JSC::SyntaxChecker::makeFunctionCallNode): (JSC::SyntaxChecker::makeAssignNode): (JSC::SyntaxChecker::makePrefixNode): (JSC::SyntaxChecker::makePostfixNode): (JSC::SyntaxChecker::makeDeleteNode): (JSC::SyntaxChecker::createResolve): (JSC::SyntaxChecker::createBracketAccess): (JSC::SyntaxChecker::createDotAccess): (JSC::SyntaxChecker::createRegExp): (JSC::SyntaxChecker::createNewExpr): (JSC::SyntaxChecker::createAssignResolve): (JSC::SyntaxChecker::createFunctionExpr): (JSC::SyntaxChecker::createFunctionBody): (JSC::SyntaxChecker::createFuncDeclStatement): (JSC::SyntaxChecker::createForInLoop): (JSC::SyntaxChecker::createReturnStatement): (JSC::SyntaxChecker::createBreakStatement): (JSC::SyntaxChecker::createContinueStatement): (JSC::SyntaxChecker::createWithStatement): (JSC::SyntaxChecker::createLabelStatement): (JSC::SyntaxChecker::createThrowStatement): (JSC::SyntaxChecker::createGetterOrSetterProperty): (JSC::SyntaxChecker::appendBinaryExpressionInfo): (JSC::SyntaxChecker::operatorStackPop): - Made SyntaxChecker prototype changes to match ASTBuilder due to new args added for plumbing line, lineStart, and startColumn. * runtime/CodeCache.cpp: (JSC::CodeCache::generateBytecode): (JSC::CodeCache::getCodeBlock): - Plumbed startColumn. * runtime/Executable.cpp: (JSC::FunctionExecutable::FunctionExecutable): (JSC::ProgramExecutable::compileInternal): (JSC::FunctionExecutable::produceCodeBlockFor): (JSC::FunctionExecutable::fromGlobalCode): - Plumbed startColumn. * runtime/Executable.h: (JSC::ScriptExecutable::startColumn): (JSC::ScriptExecutable::recordParse): (JSC::FunctionExecutable::create): - Plumbed startColumn. 2013-07-08 Carlos Garcia Campos Unreviewed. Fix make distcheck. * GNUmakefile.list.am: Add missing header files. 2013-07-04 Patrick Gansterer [CMake] Add generation of JITStubs for x86_64 MSVC https://bugs.webkit.org/show_bug.cgi?id=116666 Reviewed by Laszlo Gombos. Also move the generation for ARM CPU into the CMakeLists.txt, since it's compiler specific and not dedicated to Windows CE. * CMakeLists.txt: * PlatformWinCE.cmake: Removed. 2013-07-04 Patrick Gansterer [CMake] Add STATICALLY_LINKED_WITH_WTF to JavaScriptCore project https://bugs.webkit.org/show_bug.cgi?id=118120 Reviewed by Gyuyoung Kim. Since WTF is a static library linked to JavaScriptCore on all CMake ports we need to define STATICALLY_LINKED_WITH_WTF for all of them. This makes only a difference for Windows, since WTF_EXPORT and WTF_IMPORT are the same on all other platforms. * CMakeLists.txt: 2013-07-02 Mark Hahnenberg Replace RELEASE_ASSERT with ASSERT in CodeBlock:: bytecodeOffsetForCallAtIndex https://bugs.webkit.org/show_bug.cgi?id=118316 Reviewed by Geoffrey Garen. This is causing some crashiness in release builds. We should replace it with an ASSERT until we track down all the places that need fixing in bug 118315. * bytecode/CodeBlock.h: (JSC::CodeBlock::bytecodeOffsetForCallAtIndex): 2013-07-02 Brent Fulgham [Windows] Unreviewed build correction for 'DebugSuffix' target. * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Must pass the DEBUGSUFFIX definition to the nmake instance to be available during script processing. 2013-07-01 Sergio Correia [JSC]: Fix maybe-uninitialized gcc 4.8 warning in DFGSpeculativeJIT.cpp https://bugs.webkit.org/show_bug.cgi?id=118278 Reviewed by Filip Pizlo. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): Initialize valueGPR with InvalidGPRReg. 2013-07-01 Csaba Osztrogonác Fix cast-align warnings in JavaScriptCore/heap/HandleBlockInlines.h https://bugs.webkit.org/show_bug.cgi?id=118242 Reviewed by Mark Hahnenberg. * heap/HandleBlockInlines.h: (JSC::HandleBlock::nodes): 2013-06-29 Andreas Kling Follow-up to r152206: also update HashFlags8BitBuffer in the LLInt. * llint/LowLevelInterpreter.asm: 2013-06-28 Andreas Kling Un-crashify JSC tests on debug bots after Anders had his way with StringImpl. * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): 2013-06-28 Anders Carlsson Remove String::deprecatedCharactersWithNullTermination() and related code https://bugs.webkit.org/show_bug.cgi?id=118211 Reviewed by Benjamin Poulain. * API/JSStringRef.cpp: (JSStringCreateWithCharactersNoCopy): Update call to StringImpl::createWithoutCopying. 2013-06-27 Timothy Hatcher Notify the debugger about functions created from source code via new Function() or WebCore::JSLazyEventListener. https://bugs.webkit.org/show_bug.cgi?id=118063 Reviewed by Geoffrey Garen. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedFunctionExecutable::fromGlobalCode): Call Debugger::sourceParsed. 2013-06-26 Anders Carlsson Add JSStringCreateWithCharactersNoCopy SPI https://bugs.webkit.org/show_bug.cgi?id=118074 Reviewed by Geoffrey Garen. * API/JSStringRef.cpp: (JSStringCreateWithCharactersNoCopy): Create a new OpaqueJSString, using the newly added StringImpl::createWithoutCopying function. * API/JSStringRefPrivate.h: Added. Add a home for the JSStringCreateWithCharactersNoCopy function. * API/OpaqueJSString.h: (OpaqueJSString::OpaqueJSString): Just call isolatedCopy on the passed in string. * API/tests/testapi.c: Add an API test for JSStringCreateWithCharactersNoCopy. * JavaScriptCore.xcodeproj/project.pbxproj: Add new files. 2013-06-25 Ryosuke Niwa JSString should remember AtomicString https://bugs.webkit.org/show_bug.cgi?id=117386 Reviewed by Geoffrey Garen. Added JSValue::toAtomicString and JSString::atomicString. These two functions allow WebCore to update JSString's m_value to set isAtomic flag and avoid the AtomicStringTable lookups in subsequent attempts to obtain the AtomicString of the same value. * runtime/JSCJSValue.h: * runtime/JSString.h: (JSC::JSString::atomicString): (JSC::JSValue::toAtomicString): 2013-06-24 Roger Fong Unreviewed. Makefile build fix for AppleWindows. * JavaScriptCore.vcxproj/JavaScriptCore.make: 2013-06-17 Darin Adler Sort all the Xcode project files https://bugs.webkit.org/show_bug.cgi?id=117696 Reviewed by Anders Carlsson. * JavaScriptCore.xcodeproj/project.pbxproj: Ran the sort-Xcode-project-file script. 2013-06-21 Mark Lam Introducing the VMStackBounds class. https://bugs.webkit.org/show_bug.cgi?id=117862. Reviewed by Geoffrey Garen. - Removed Interpreter::StackPolicy. - The new VMStackBounds will take over choosing the appropriate stack size requirements, and invoking the underlying WTF::StackBounds to to the real bounds check. - VMStackBounds will now be used universally throughout JSC instead of WTF::StackBounds. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * bytecompiler/BytecodeGenerator.h: * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): * interpreter/Interpreter.h: (JSC::Interpreter::isInErrorHandlingMode): * parser/Parser.cpp: (JSC::::Parser): * parser/Parser.h: * runtime/StringRecursionChecker.h: (JSC::StringRecursionChecker::performCheck): * runtime/VMStackBounds.h: Added. (JSC::VMStackBounds::VMStackBounds): (JSC::VMStackBounds::isSafeToRecurse): (JSC::VMStackBounds::requiredCapacity): 2013-06-20 Mark Lam Change stack capacity requirement to be more reasonable. https://bugs.webkit.org/show_bug.cgi?id=117801. Reviewed by Geoffrey Garen. Previously, the requiredStack in StackPolicy::StackPolicy() was set to to a high value like 256K to reduce the chances of encountering an undetected stack overflow in a scenario where we have a combination of deeply nested divs and a large amount recursive re-entries into the JSGlobalData. However, this high value of requiredStack still does not completely ensure that we will never encounter an undetected stack overflow. It only lessens the probability of encountering it. Secondly, on some platforms, the total stack size can be less than 256K to start with. Hence, this high value requiredStack renders the JSGlobalData unuseable on those platforms. This patch will fix the requiredStack to be more reasonable based on real world stack usage by the JSGlobalData. We won't (and cannot) try to prevent undetected stack overflows outside of JSC as well. External code that do deep recursion (e.g. Documnet::updateLayout()) should do their own stack checks. From a previous experiment, we measured the following: On a debug build on OSX: 1. Stack usage different between recursive calls to interpreter entry: 7744 bytes On a release build on OSX: 2. Stack usage difference between recursive calls to interpreter entry: 6352 bytes Using these as a guide, we'll pick the following values for the StackPolicy: requiredStack: 32K errorModeRequiredStack: 16K The requiredStack is chosen to be 4x the measured usage above. The additional 3x is a conservative estimate to account for stack space that may be needed by other native functions called while in the interpreter. The errorModeRequiredStack has to be less than the requiredStack or we won't be able to reenter the interpreter to do error handling work when an imminent stack overflow is detected. It is assumed that the error handling code will only do minimal work to allocate an exception and its stack trace, and not run any arbitrary JS code. As such, it is safe to allow re-entry into the interpreter with only 2x the measured usage in this case. * interpreter/Interpreter.cpp: (JSC::Interpreter::StackPolicy::StackPolicy): 2013-06-20 Mikhail Pozdnyakov HashSet: reverse the order of the template arguments at alternate 'find', 'contains' and 'add' methods https://bugs.webkit.org/show_bug.cgi?id=117830 Reviewed by Anders Carlsson. The order of the template arguments at HashSet alternate 'find', 'contains' and 'add' methods is reversed so that callers can just pass the translator and let the compiler deduce input argument type. * runtime/Identifier.h: (JSC::IdentifierTable::add): 2013-06-20 Roger Fong Make Windows makefile copy build output to a different folder. . * JavaScriptCore.vcxproj/JavaScriptCore.make: 2013-06-20 Mark Hahnenberg Improper deallocation of JSManagedValue causes crashes during autorelease pool draining https://bugs.webkit.org/show_bug.cgi?id=117840 Reviewed by Geoffrey Garen. Improperly managing a JSManagedValue can cause a crash when the JSC::Weak inside the JSManagedValue is destroyed upon deallocation. We would rather have improperly maintained JSManagedValues cause memory leaks than take down the whole app. The fix is to use the callback to the JSC::Weak on the destruction of the JSGlobalData so that we can safely null it out. This will prevent ~Weak from crashing. * API/JSManagedValue.mm: (-[JSManagedValue JSC::JSC::]): (JSManagedValueHandleOwner::finalize): * API/tests/testapi.mm: Added a test that crashed prior to this fix due to a leaked managed reference. Also fixed a small style nit I noticed in another test. 2013-06-18 Oliver Hunt Going to google.com/trends causes a crash https://bugs.webkit.org/show_bug.cgi?id=117602 Reviewed by Geoffrey Garen. When handling op_throw, etc we need to flush the variables and arguments for the entire inline stack, not just the top frame. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::flushAllArgumentsAndCapturedVariablesInInlineStack): (JSC::DFG::ByteCodeParser::parseBlock): 2013-06-18 Roger Fong Replace tools32 folder with tools and update WebKit Windows solution accordingly. . Rubberstamped by Brent Fulgham. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCoreDebug.props: * JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props: * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedDebug.props: * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedProduction.props: * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props: * JavaScriptCore.vcxproj/JavaScriptCorePostBuild.cmd: * JavaScriptCore.vcxproj/JavaScriptCoreProduction.props: * JavaScriptCore.vcxproj/JavaScriptCoreRelease.props: * JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props: * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: * JavaScriptCore.vcxproj/jsc/jscDebug.props: * JavaScriptCore.vcxproj/jsc/jscProduction.props: * JavaScriptCore.vcxproj/jsc/jscRelease.props: * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props: * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props: * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props: * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: * JavaScriptCore.vcxproj/testapi/testapiDebug.props: * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: * JavaScriptCore.vcxproj/testapi/testapiProduction.props: * JavaScriptCore.vcxproj/testapi/testapiRelease.props: * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: 2013-06-17 Roger Fong Modify Windows makefiles to copy some bin output into Program Files. https://bugs.webkit.org/show_bug.cgi?id=117714. Reviewed by Brent Fulgham. * JavaScriptCore.vcxproj/JavaScriptCore.make: 2013-06-14 Ryosuke Niwa Function names on Object.prototype should be common identifiers https://bugs.webkit.org/show_bug.cgi?id=117614 Reviewed by Darin Adler. Patch written by Sam Weinig. Make Object's prototype function names common identififers since they're used frequently. * runtime/CommonIdentifiers.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunction): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): * runtime/JSObject.h: * runtime/ObjectPrototype.cpp: (JSC::ObjectPrototype::finishCreation): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): 2013-06-13 Ryosuke Niwa Remove LiteralIdentifierTable https://bugs.webkit.org/show_bug.cgi?id=117613 Reviewed by Geoffrey Garen. Removed LiteralIdentifierTable since it doesn't seem to have any perf. impact now. * runtime/Identifier.cpp: (JSC::Identifier::add): 2013-06-12 Conrad Shultz JSExport header documentation substitutes "semicolon" for "colon" https://bugs.webkit.org/show_bug.cgi?id=117552 Reviewed by Mark Hahnenberg. * API/JSExport.h: Fix a couple typos. 2013-06-10 Raphael Kubo da Costa [JSC] Remove a vestige of wxWidgets support. https://bugs.webkit.org/show_bug.cgi?id=117419 Reviewed by Benjamin Poulain. * runtime/JSExportMacros.h: Remove a check for BUILDING_WX__ that seems to have gone unnoticed when the wxWidgets port was removed. 2013-06-06 Roger Fong Stop copying AAS binaries into build folder. https://bugs.webkit.org/show_bug.cgi?id=117319. Rubberstamped by Darin Adler. * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd: * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd: * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd: * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd: 2013-06-05 Filip Pizlo DFG CFA shouldn't filter ArrayModes with ALL_NON_ARRAY_ARRAY_MODES if the speculated type is not SpecArray https://bugs.webkit.org/show_bug.cgi?id=117279 Reviewed by Mark Hahnenberg. * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::filterArrayModesByType): 2013-06-05 Michael Saboff JSC: Crash beneath cti_op_div @ http://gmailblog.blogspot.com https://bugs.webkit.org/show_bug.cgi?id=117280 Reviewed by Filip Pizlo. Updated the merging of VariableAccessData nodes in ArgumentPosition lists to find the unified VariableAccessData node that is the root of the current node instead of using the current node directly when merging attributes. Added new dump code to dump the ArgumentPosition list. * dfg/DFGArgumentPosition.h: (JSC::DFG::rgumentPosition::mergeArgumentPredictionAwareness): (JSC::DFG::ArgumentPosition::mergeArgumentUnboxingAwareness): (JSC::DFG::ArgumentPosition::dump): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): 2013-06-05 Bear Travis [CSS Exclusions][CSS Shapes] Split CSS Exclusions & Shapes compile & runtime flags https://bugs.webkit.org/show_bug.cgi?id=117172 Reviewed by Alexandru Chiculita. Adding the CSS_SHAPES compile flag. * Configurations/FeatureDefines.xcconfig: 2013-06-05 Balazs Kilvady JSC Assertion tests failures on MIPS. https://bugs.webkit.org/show_bug.cgi?id=116552 Reviewed by Geoffrey Garen. Fix condition handlig in branchAdd32 implemetations. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchAdd32): 2013-06-04 Julien Brianceau [sh4] Add floating point absolute function support in baseline JIT. https://bugs.webkit.org/show_bug.cgi?id=117147 Reviewed by Geoffrey Garen. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::supportsFloatingPointAbs): (JSC::MacroAssemblerSH4::absDouble): * assembler/SH4Assembler.h: (JSC::SH4Assembler::dabs): (JSC::SH4Assembler::printInstr): 2013-06-04 Zan Dobersek [JSC] Test262 15.5.4.9_3 test is failing https://bugs.webkit.org/show_bug.cgi?id=116789 Reviewed by Geoffrey Garen. Bring the String.prototype.localeCompare behavior in line wit ES5 15.9.4.9. If method is not given enough arguments, the minimal amount of arguments must be assumed, with their value being undefined. The first argument to localeCompare, in its string form, is used as the 'that' string that's used in the comparison. Therefor, when calling str.localeCompare() or str.localeCompare(undefined), the first argument is `undefined` and the string "undefined" is used as the string to which value of str is compared. * runtime/StringPrototype.cpp: (JSC::stringProtoFuncLocaleCompare): Remove the early return in case of no given arguments to achieve the desired behavior. 2013-06-03 Hojong Han [EFL] Implement GCActivityCallback https://bugs.webkit.org/show_bug.cgi?id=95923 Reviewed by Geoffrey Garen. Implements the activity triggered garbage collector. Additional GCs can be triggered by platfrom timer. It has sort of compaction effect not to make JSC heap grow fast so that memory usage becomes lower than usual. * PlatformEfl.cmake: Added. * heap/HeapTimer.cpp: (JSC): (JSC::HeapTimer::HeapTimer): (JSC::HeapTimer::~HeapTimer): (JSC::HeapTimer::add): (JSC::HeapTimer::stop): (JSC::HeapTimer::timerEvent): * heap/HeapTimer.h: (HeapTimer): * jsc.cpp: (main): * runtime/GCActivityCallback.cpp: (JSC): (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): (JSC::DefaultGCActivityCallback::scheduleTimer): (JSC::DefaultGCActivityCallback::cancelTimer): (JSC::DefaultGCActivityCallback::didAllocate): * runtime/GCActivityCallback.h: (GCActivityCallback): (JSC::GCActivityCallback::GCActivityCallback): (DefaultGCActivityCallback): 2013-06-03 Roger Fong Nuke VS2005 files from the tree. . Rubberstamped by Brent Fulgham. * JavaScriptCore.vcproj: Removed. * JavaScriptCore.vcproj/JavaScriptCore: Removed. * JavaScriptCore.vcproj/JavaScriptCore.make: Removed. * JavaScriptCore.vcproj/JavaScriptCore.resources: Removed. * JavaScriptCore.vcproj/JavaScriptCore.resources/Info.plist: Removed. * JavaScriptCore.vcproj/JavaScriptCore.sln: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCF.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCFLite.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreDebug.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreDebugAll.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreDebugCairoCFLite.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.make: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGenerated.vcproj: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedCommon.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedDebug.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedDebugAll.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedDebugCairoCFLite.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedProduction.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedRelease.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedReleaseCairoCFLite.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreGeneratedReleasePGO.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePGOOptimize.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePostBuild.cmd: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePreBuild.cmd: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCorePreLink.cmd: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreProduction.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreRelease.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreReleaseCairoCFLite.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreReleasePGO.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreReleasePGOOptimize.vsprops: Removed. * JavaScriptCore.vcproj/JavaScriptCore/build-generated-files.sh: Removed. * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd: Removed. * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Removed. * JavaScriptCore.vcproj/LLIntAssembly: Removed. * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.make: Removed. * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: Removed. * JavaScriptCore.vcproj/LLIntAssembly/build-LLIntAssembly.sh: Removed. * JavaScriptCore.vcproj/LLIntDesiredOffsets: Removed. * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Removed. * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: Removed. * JavaScriptCore.vcproj/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Removed. * JavaScriptCore.vcproj/LLIntOffsetsExtractor: Removed. * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: Removed. * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: Removed. * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.vsprops: Removed. * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugAll.vsprops: Removed. * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugCairoCFLite.vsprops: Removed. * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.vsprops: Removed. * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.vsprops: Removed. * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleaseCairoCFLite.vsprops: Removed. * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleasePGO.vsprops: Removed. * JavaScriptCore.vcproj/jsc: Removed. * JavaScriptCore.vcproj/jsc/jsc.vcproj: Removed. * JavaScriptCore.vcproj/jsc/jscCommon.vsprops: Removed. * JavaScriptCore.vcproj/jsc/jscDebug.vsprops: Removed. * JavaScriptCore.vcproj/jsc/jscDebugAll.vsprops: Removed. * JavaScriptCore.vcproj/jsc/jscDebugCairoCFLite.vsprops: Removed. * JavaScriptCore.vcproj/jsc/jscPostBuild.cmd: Removed. * JavaScriptCore.vcproj/jsc/jscPreBuild.cmd: Removed. * JavaScriptCore.vcproj/jsc/jscPreLink.cmd: Removed. * JavaScriptCore.vcproj/jsc/jscProduction.vsprops: Removed. * JavaScriptCore.vcproj/jsc/jscRelease.vsprops: Removed. * JavaScriptCore.vcproj/jsc/jscReleaseCairoCFLite.vsprops: Removed. * JavaScriptCore.vcproj/jsc/jscReleasePGO.vsprops: Removed. * JavaScriptCore.vcproj/testRegExp: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExp.vcproj: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExpCommon.vsprops: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExpDebug.vsprops: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExpDebugAll.vsprops: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExpDebugCairoCFLite.vsprops: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExpPostBuild.cmd: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExpPreBuild.cmd: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExpPreLink.cmd: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExpProduction.vsprops: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExpRelease.vsprops: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExpReleaseCairoCFLite.vsprops: Removed. * JavaScriptCore.vcproj/testRegExp/testRegExpReleasePGO.vsprops: Removed. * JavaScriptCore.vcproj/testapi: Removed. * JavaScriptCore.vcproj/testapi/testapi.vcproj: Removed. * JavaScriptCore.vcproj/testapi/testapiCommon.vsprops: Removed. * JavaScriptCore.vcproj/testapi/testapiDebug.vsprops: Removed. * JavaScriptCore.vcproj/testapi/testapiDebugAll.vsprops: Removed. * JavaScriptCore.vcproj/testapi/testapiDebugCairoCFLite.vsprops: Removed. * JavaScriptCore.vcproj/testapi/testapiPostBuild.cmd: Removed. * JavaScriptCore.vcproj/testapi/testapiPreBuild.cmd: Removed. * JavaScriptCore.vcproj/testapi/testapiPreLink.cmd: Removed. * JavaScriptCore.vcproj/testapi/testapiProduction.vsprops: Removed. * JavaScriptCore.vcproj/testapi/testapiRelease.vsprops: Removed. * JavaScriptCore.vcproj/testapi/testapiReleaseCairoCFLite.vsprops: Removed. 2013-05-31 Filip Pizlo Incorrect assertion in DFG::Graph::uncheckedActivationRegisterFor() Rubber stamped by Mark Hahnenberg. This has a bogus assertion that checks that the passed CodeOrigin doesn't have an inline call frame. This was well intentioned in the sense that it is true that inlined call frames wouldn't have an activation register. But that doesn't mean that people won't ask. Removing the assertion fixes a debug-only crash and has no impact on production code. This change adds a comment to that effect. * dfg/DFGGraph.h: (JSC::DFG::Graph::uncheckedActivationRegisterFor): 2013-05-31 Julien Brianceau [sh4] Fix Overflow case of branchMul32 in baseline JIT. https://bugs.webkit.org/show_bug.cgi?id=117057 Reviewed by Oliver Hunt. Current implementation of Overflow case in branchMul32 performs an unsigned multiplication whereas a signed multiplication is expected. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::branchMul32): 2013-05-31 Julien Brianceau [sh4] Fix floating point comparisons in baseline JIT. https://bugs.webkit.org/show_bug.cgi?id=117066. Reviewed by Oliver Hunt. Current implementation of branchDouble function in baseline JIT is wrong for some conditions and overkill for others. For instance: - With DoubleGreaterThanOrEqual condition, branch will be taken if either operand is NaN with current implementation whereras it should not. - With DoubleNotEqualOrUnordered condition, performed NaN checks are useless (because comparison result is false if either operand is NaN). * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::branchDouble): 2013-05-31 Julien Brianceau [sh4] Fix double floating point transfer in baseline JIT. https://bugs.webkit.org/show_bug.cgi?id=117054 Reviewed by Oliver Hunt. In current implementation, dmovRegReg function transfers only one single FPRegister as PR=1 and SZ=0 in floating point status/control register. Double transfers must be performed with two fmov.s opcodes. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::moveDouble): (JSC::MacroAssemblerSH4::addDouble): Handle (op2==dest) case properly. (JSC::MacroAssemblerSH4::sqrtDouble): * assembler/SH4Assembler.h: (JSC::SH4Assembler::fmovsRegReg): 2013-05-31 Julien Brianceau [sh4] Handle branchType properly in branchTruncateDoubleToInt32. https://bugs.webkit.org/show_bug.cgi?id=117062 Reviewed by Oliver Hunt. Current implementation of branchTruncateDoubleToInt32 is incorrect when branchType == BranchIfTruncateSuccessful in sh4 baseline JIT. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::branchTruncateDoubleToInt32): 2013-05-31 Brent Fulgham [Windows] Unreviewed build fix for VS2005 builders. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Add missing export for WTF::SHA1::computeHexDigest 2013-05-30 David Farler Fix jscore-test when not using --sdk option with jsDriver.pl https://bugs.webkit.org/show_bug.cgi?id=116339 Reviewed by Joe Pecoraro. * tests/mozilla/jsDriver.pl: (execute_tests): With each test, the shell_command needs to be started from scratch. This fix will clear the shell_command and start over as before with the opt_arch option when not using --sdk with jsDriver.pl. 2013-05-30 Roger Fong Get rid of JavaScript exports file on AppleWin port. https://bugs.webkit.org/show_bug.cgi?id=117050. Reviewed by Darin Adler. Delete the JavaScriptCoreExportGenerator folder and remove dependencies. Start linking in WTF.lib now that it's a shared library. * JavaScriptCore.vcxproj/JavaScriptCore.submit.sln: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorBuildCmd.cmd: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorDebug.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPreBuild.cmd: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorProduction.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/make-export-file-generator: Removed. * JavaScriptCore.vcxproj/jsc/jscCommon.props: * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters: * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: * JavaScriptCore.vcxproj/testapi/testapiCommon.props: 2013-05-22 David Farler Add --sdk option to jsDriver.pl to run with iOS Simulator https://bugs.webkit.org/show_bug.cgi?id=116339 Reviewed by David Kilzer. * tests/mozilla/jsDriver.pl: (execute_tests): Prefix shell command with the path to the "sim" tool. (parse_args): Add -d / --sdk option. (usage): Help message for -d / --sdk option. 2013-05-30 Julien Brianceau [sh4] Optimize NaN checks in LLINT for floating point comparisons. https://bugs.webkit.org/show_bug.cgi?id=117049 Reviewed by Oliver Hunt. Use the fcmp/eq opcode in sh4 LLINT to test if a double is NaN. This is more efficient, doesn't require two tmp registers and requires less code than current implementation (which converts double to float, then checks 'E = Emax + 1' and 'f != 0'). * offlineasm/sh4.rb: 2013-05-30 Oliver Hunt JSCallbackObject does not correctly initialise the PropertySlot for getOwnPropertyDescriptor https://bugs.webkit.org/show_bug.cgi?id=117053 Reviewed by Mark Hahnenberg. Set appropriate thisValue on the PropertySlot * API/JSCallbackObjectFunctions.h: (JSC::::getOwnPropertyDescriptor): * API/tests/testapi.mm: 2013-05-29 Jeffrey Pfau [Mac] Enable cache partitioning and the public suffix list on 10.8 Rubber-stamped by David Kilzer. * Configurations/FeatureDefines.xcconfig: 2013-05-28 Brent Fulgham [Windows] Put correct byteCompile symbol in file. Previous version had an extra 'i' appended to the end. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: 2013-05-28 Brent Fulgham [Windows] Unreviewed build fix. Remove ?byteCompile symbol that is no longer accessible during link. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: 2013-05-28 Gavin Barraclough String(new Date(2010,10,1)) is wrong in KRAT, YAKT https://bugs.webkit.org/show_bug.cgi?id=106750 Reviewed by Darin Adler. * runtime/JSDateMath.cpp: (JSC::msToGregorianDateTime): - Additional review comment fix. 2013-05-28 Brent Fulgham [Windows] Unreviewed build fix after r150833 * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: A CR/LF combination was lost in the file, combining two symbols. 2013-05-27 Gavin Barraclough String(new Date(2010,10,1)) is wrong in KRAT, YAKT https://bugs.webkit.org/show_bug.cgi?id=106750 Reviewed by Darin Adler. First part of a fix, simplfy date handling code, instead of operating separately on the UTC-standard and standard-DST offsets, just generate a combined UTC-local offset (this is what we actually need, and what the OS gives us). * runtime/JSDateMath.cpp: (JSC::getLocalTimeOffset): - removed getUTCOffset, converted getDSTOffset -> getLocalTimeOffset (JSC::gregorianDateTimeToMS): (JSC::msToGregorianDateTime): (JSC::parseDateFromNullTerminatedCharacters): - call getLocalTimeOffset instead of getUTCOffset/getDSTOffset * runtime/JSGlobalData.cpp: (JSC::JSGlobalData::resetDateCache): - removed cachedUTCOffset, converted DSTOffsetCache -> LocalTimeOffsetCache * runtime/JSGlobalData.h: (JSC::LocalTimeOffsetCache::LocalTimeOffsetCache): (JSC::LocalTimeOffsetCache::reset): (LocalTimeOffsetCache): - removed cachedUTCOffset, converted DSTOffsetCache -> LocalTimeOffsetCache 2013-05-28 Mark Hahnenberg r150199 is very wrong https://bugs.webkit.org/show_bug.cgi?id=116876 JSValue needs to protect its internal JSValueRef. Reviewed by Darin Adler. * API/JSValue.mm: (-[JSValue initWithValue:inContext:]): (-[JSValue dealloc]): * API/tests/testapi.mm: Added a simple test to make sure that we protect the underlying JavaScript value across garbage collections. 2013-05-27 Patrick Gansterer Use ICU_INCLUDE_DIRS in BlackBerry CMake files https://bugs.webkit.org/show_bug.cgi?id=116210 Reviewed by Rob Buis. Set and use the ICU_INCLUDE_DIRS variable to avoid duplicated adding of the ICU include directory. * PlatformBlackBerry.cmake: 2013-05-27 Gabor Rapcsanyi MacroAssemblerARM should use xor to swap registers instead of move https://bugs.webkit.org/show_bug.cgi?id=116306 Reviewed by Zoltan Herczeg. Change register swapping to xor from move and this way we don't need temporary register anymore. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::swap): 2013-05-25 Filip Pizlo We broke (-2^31/-1)|0 in the DFG https://bugs.webkit.org/show_bug.cgi?id=116767 Reviewed by Andreas Kling. The bug is that we were assuming that in the -2^31 case, we already had -2^31 in the result register. This was a wrong assumption. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForX86): 2013-05-24 Filip Pizlo We broke !(0/0) https://bugs.webkit.org/show_bug.cgi?id=116736 Reviewed by Gavin Barraclough. * parser/ASTBuilder.h: (JSC::ASTBuilder::createLogicalNot): * runtime/JSCJSValueInlines.h: (JSC::JSValue::pureToBoolean): 2013-05-24 Julien Brianceau [sh4] Optimize LLINT generated code and fix few bugs in baseline JIT. https://bugs.webkit.org/show_bug.cgi?id=116716 Reviewed by Geoffrey Garen. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::mul32): Cosmetic changes. (JSC::MacroAssemblerSH4::convertInt32ToDouble): Absolute address was not dereferenced. (JSC::MacroAssemblerSH4::branch32): Absolute address was not dereferenced. (JSC::MacroAssemblerSH4::revertJumpReplacementToBranchPtrWithPatch): Use all 32 bits of pointer for revertJump call. * assembler/SH4Assembler.h: (JSC::SH4Assembler::revertJump): Use changePCrelativeAddress to patch the whole pointer. (JSC::SH4Assembler::linkJump): Cosmetic change. * offlineasm/sh4.rb: Optimize LLINT generated code. 2013-05-23 Peter Wang CLoop llint backend should not use the d8 register as scratch register https://bugs.webkit.org/show_bug.cgi?id=116019 Reviewed by Csaba Osztrogonác. * offlineasm/cloop.rb: 2013-05-22 Peter Wang Use uninitialized register in "JIT::emit_op_neq_null" and "emit_op_eq_null" https://bugs.webkit.org/show_bug.cgi?id=116593 Reviewed by Filip Pizlo. Generated instructions using uninitialized register. It's caused by a mistake of r126494. * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): 2013-05-22 Filip Pizlo Fix indentation of CodeBlock.h Rubber stampted by Mark Hahnenberg. * bytecode/CodeBlock.h: 2013-05-22 Julien Brianceau [sh4] Remove MacroAssemblerSH4.cpp file. https://bugs.webkit.org/show_bug.cgi?id=116596. Reviewed by Geoffrey Garen. Move linkCall and repatchCall implementations from MacroAssemblerSH4.cpp to MacroAssemblerSH4.h and remove MacroAssemblerSH4.cpp, as it is done for other architectures. * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * assembler/MacroAssemblerSH4.cpp: Removed. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::linkCall): (MacroAssemblerSH4): (JSC::MacroAssemblerSH4::repatchCall): 2013-05-21 Brent Fulgham [Windows] Unreviewed speculative fix for test-bots. Add export declaration for WTFInvokeCrashHook to avoid runtime load error on test bots. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: 2013-05-21 Mark Lam Added missing assert condition for PositiveOrZero in ARM branch32(). https://bugs.webkit.org/show_bug.cgi?id=116538. Reviewed by Geoffrey Garen. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::branchAdd32): 2013-05-20 Mark Hahnenberg Disable SuperRegion https://bugs.webkit.org/show_bug.cgi?id=116362 Rubber stamped by Geoff Garen. * heap/Region.h: 2013-05-20 Oliver Hunt Make C API more robust against null contexts https://bugs.webkit.org/show_bug.cgi?id=116462 Reviewed by Anders Carlsson. Handle null contexts in a non-crashy way. It's a bug to ever call the API with a null context, and the absence of a context means we can't produce a meaningful result, so we still assert in debug builds. Now where possible we detect and early return, returning null for any pointer type, NaN for doubles, and false for any boolean result. * API/JSBase.cpp: (JSEvaluateScript): (JSCheckScriptSyntax): (JSReportExtraMemoryCost): * API/JSContextRef.cpp: (JSContextGetGlobalObject): (JSContextGetGroup): (JSContextGetGlobalContext): (JSContextCreateBacktrace): * API/JSObjectRef.cpp: (JSObjectMake): (JSObjectMakeFunctionWithCallback): (JSObjectMakeConstructor): (JSObjectMakeFunction): (JSObjectMakeArray): (JSObjectMakeDate): (JSObjectMakeError): (JSObjectMakeRegExp): (JSObjectGetPrototype): (JSObjectSetPrototype): (JSObjectHasProperty): (JSObjectGetProperty): (JSObjectSetProperty): (JSObjectGetPropertyAtIndex): (JSObjectSetPropertyAtIndex): (JSObjectDeleteProperty): (JSObjectCopyPropertyNames): * API/JSValueRef.cpp: (JSValueGetType): (JSValueIsUndefined): (JSValueIsNull): (JSValueIsBoolean): (JSValueIsNumber): (JSValueIsString): (JSValueIsObject): (JSValueIsObjectOfClass): (JSValueIsEqual): (JSValueIsStrictEqual): (JSValueIsInstanceOfConstructor): (JSValueMakeUndefined): (JSValueMakeNull): (JSValueMakeBoolean): (JSValueMakeNumber): (JSValueMakeString): (JSValueMakeFromJSONString): (JSValueCreateJSONString): (JSValueToBoolean): (JSValueToNumber): (JSValueToStringCopy): (JSValueToObject): (JSValueProtect): * API/JSWeakObjectMapRefPrivate.cpp: 2013-05-20 David Kilzer Synchronize FeatureDefines.xcconfig * Configurations/FeatureDefines.xcconfig: Remove ENABLE_LINK_PRERENDER. This was missed in r150356. 2013-05-19 Anders Carlsson Remove link prerendering code https://bugs.webkit.org/show_bug.cgi?id=116415 Reviewed by Darin Adler. This code was only used by Chromium and is dead now. * Configurations/FeatureDefines.xcconfig: 2013-05-18 Patrick Gansterer [CMake] Replace *_LIBRARY_NAME with *_OUTPUT_NAME https://bugs.webkit.org/show_bug.cgi?id=114554 Reviewed by Gyuyoung Kim. Using variables as target names is very uncommon in CMake. The usual way to specify the name of the resulting binary is to set the OUTPUT_NAME target property. * CMakeLists.txt: * shell/CMakeLists.txt: 2013-05-17 Patrick Gansterer [CMake] Remove invalid include paths https://bugs.webkit.org/show_bug.cgi?id=116213 Reviewed by Gyuyoung Kim. Since "${JAVASCRIPTCORE_DIR}/wtf" does not exist, it is safe to remove them from the list of include directories. * PlatformEfl.cmake: Removed. * PlatformGTK.cmake: Removed. 2013-05-16 Patrick Gansterer Consolidate lists in JavaScriptCore CMake files https://bugs.webkit.org/show_bug.cgi?id=115992 Reviewed by Gyuyoung Kim. Move common files into the CMakeLists.txt to avoid duplicating the list of files. Also rebase the recently added GTK files to match the other CMake ports, since the submitted patch was based on an older version of the source tree. * CMakeLists.txt: * PlatformEfl.cmake: * PlatformGTK.cmake: * shell/CMakeLists.txt: * shell/PlatformEfl.cmake: * shell/PlatformGTK.cmake: 2013-05-16 Geoffrey Garen JSValue shouldn't protect/unprotect its context https://bugs.webkit.org/show_bug.cgi?id=116234 Reviewed by Mark Hahnenberg. Our retain on _context is sufficient. * API/JSValue.mm: (-[JSValue initWithValue:inContext:]): (-[JSValue dealloc]): 2013-05-15 Ryosuke Niwa Another Windows build fix attempt after r150160. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: 2013-05-15 Oliver Hunt RefCountedArray needs to use vector initialisers for its backing store https://bugs.webkit.org/show_bug.cgi?id=116194 Reviewed by Gavin Barraclough. Use an out of line function to clear the exception stack to avoid needing to include otherwise unnecessary headers all over the place. Everything else is just being updated to use that. * bytecompiler/BytecodeGenerator.cpp: * interpreter/CallFrame.h: (JSC::ExecState::clearSupplementaryExceptionInfo): * interpreter/Interpreter.cpp: (JSC::Interpreter::addStackTraceIfNecessary): (JSC::Interpreter::throwException): * runtime/JSGlobalObject.cpp: (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope): * runtime/JSGlobalData.cpp: (JSC): (JSC::JSGlobalData::clearExceptionStack): * runtime/JSGlobalData.h: (JSGlobalData): (JSC::JSGlobalData::exceptionStack): 2013-05-15 Commit Queue Unreviewed, rolling out r150051. http://trac.webkit.org/changeset/150051 https://bugs.webkit.org/show_bug.cgi?id=116186 Broke all JSC tests on Mac and the author is unresponsive (Requested by rniwa on #webkit). * JavaScriptCore.xcodeproj/project.pbxproj: 2013-05-15 Julien Brianceau Remove savedTimeoutReg from JITStackFrame for sh4 base JIT. https://bugs.webkit.org/show_bug.cgi?id=116143 Reviewed by Geoffrey Garen. Since r148119, timeoutCheckRegister is removed from baseline JIT. So we don't need to save r8 register in JITStackFrame anymore for sh4. * jit/JITStubs.cpp: * jit/JITStubs.h: (JITStackFrame): 2013-05-15 Nico Weber WebKit doesn't support MSVS2003 any more, remove preprocessor checks for older versions. https://bugs.webkit.org/show_bug.cgi?id=116157 Reviewed by Anders Carlsson. Also remove a gcc3.2 workaround. Merges parts of these two commits by the talented Nico Weber: https://chromium.googlesource.com/chromium/blink/+/3677e2f47348daeff405a40b6f90fbdf0654c2f5 https://chromium.googlesource.com/chromium/blink/+/0fcd96c448dc30be1416dcc15713c53710c1a312 * os-win32/inttypes.h: 2013-05-13 Alvaro Lopez Ortega Nightly build's jsc doesn't work without DYLD_FRAMEWORK... https://bugs.webkit.org/show_bug.cgi?id=79065 Reviewed by Darin Adler. Fixes the build process so the depencencies of the jsc binary are modified before its copied to its target directory. In this way jsc should always use relative reference to the JavaScriptCore libraries. * JavaScriptCore.xcodeproj/project.pbxproj: Fixes the commands in the "Copy Into Framework" target. 2013-05-13 Mark Hahnenberg Objective-C API: scanExternalObjectGraph should not create new JSVirtualMachine wrappers https://bugs.webkit.org/show_bug.cgi?id=116074 If scanExternalObjectGraph creates a new JSVirtualMachine wrapper during collection, when the scanExternalObjectGraph call finishes and the autorelease pool is drained we will dealloc the JSVirtualMachine which will cause us to try to take the API lock for the corresponding JSGlobalData. If this happens on a GC thread other than the "main" thread, we will deadlock. The solution is to just check the JSGlobalData cache, and if there is no JSVirtualMachine wrapper, return early. Reviewed by Darin Adler. * API/JSVirtualMachine.mm: (scanExternalObjectGraph): 2013-05-13 Benjamin Poulain Improve stringProtoFuncLastIndexOf for the prefix case https://bugs.webkit.org/show_bug.cgi?id=115952 Reviewed by Geoffrey Garen. * runtime/StringPrototype.cpp: (JSC::stringProtoFuncLastIndexOf): Use the optimized string search when possible. On Joseph Pecoraro's tests, this gives a ~30% speed improvement. 2013-05-13 Zalan Bujtas WebProcess consuming very high CPU on linkedin.com https://bugs.webkit.org/show_bug.cgi?id=115601 Reviewed by Andreas Kling. Disable WEB_TIMING_MINIMAL. Turn off window.performance and performance.now(). Some JS frameworks expect additional Web Timing APIs, when performance.now() is available. * Configurations/FeatureDefines.xcconfig: 2013-05-12 Anders Carlsson Stop including UnusedParam.h https://bugs.webkit.org/show_bug.cgi?id=116003 Reviewed by Sam Weinig. UnusedParam.h is empty now so there's no need to include it anymore. * API/APICast.h: * API/tests/JSNode.c: * API/tests/JSNodeList.c: * API/tests/minidom.c: * API/tests/testapi.c: * assembler/AbstractMacroAssembler.h: * assembler/MacroAssemblerCodeRef.h: * bytecode/CodeBlock.cpp: * heap/HandleStack.h: * interpreter/JSStackInlines.h: * jit/CompactJITCodeMap.h: * jit/ExecutableAllocator.h: * parser/SourceProvider.h: * runtime/DatePrototype.cpp: * runtime/JSNotAnObject.cpp: * runtime/JSSegmentedVariableObject.h: * runtime/JSVariableObject.h: * runtime/Options.cpp: * runtime/PropertyOffset.h: 2013-05-11 Martin Robinson [GTK] Add a basic cmake build for WTF and JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=115967 Reviewed by Laszlo Gombos. * PlatformGTK.cmake: Added. * shell/PlatformGTK.cmake: Added. 2013-05-10 Laszlo Gombos Remove USE(OS_RANDOMNESS) https://bugs.webkit.org/show_bug.cgi?id=108095 Reviewed by Darin Adler. Remove the USE(OS_RANDOMNESS) guard as it is turned on for all ports. * jit/JIT.cpp: (JSC::JIT::JIT): 2013-05-10 Mark Hahnenberg Rename StructureCheckHoistingPhase to TypeCheckHoistingPhase https://bugs.webkit.org/show_bug.cgi?id=115938 We're going to add some more types of check hoisting soon, so let's have the right name here. Rubber stamped by Filip Pizlo. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGStructureCheckHoistingPhase.cpp: Removed. * dfg/DFGStructureCheckHoistingPhase.h: Removed. * dfg/DFGTypeCheckHoistingPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGStructureCheckHoistingPhase.cpp. (JSC::DFG::TypeCheckHoistingPhase::TypeCheckHoistingPhase): (JSC::DFG::performTypeCheckHoisting): * dfg/DFGTypeCheckHoistingPhase.h: Copied from Source/JavaScriptCore/dfg/DFGStructureCheckHoistingPhase.h. 2013-05-09 Christophe Dumez Unreviewed build fix after r149836. It broke at least EFL and GTK builds. Move new static members initialization outside the class. Those need to have a definition outside the class because their address is used (e.g. CodeCacheMap::nonGlobalWorkingSetMaxEntries). * runtime/CodeCache.cpp: (JSC): * runtime/CodeCache.h: (CodeCacheMap): 2013-05-08 Oliver Hunt Code cache stores bogus var references for functions in eval code https://bugs.webkit.org/show_bug.cgi?id=115747 Reviewed by Mark Hahnenberg. Non-global eval now uses a per-CodeBlock cache, and only use it when we're at the top of a function's scope. This means that we will no longer cache the parsing of a single string across multiple functions, and we won't cache when we're nested inside constructs like |with| and |catch| where previously we would, which is good because caching in those cases is unsound. * bytecode/EvalCodeCache.h: (JSC): (JSC::EvalCodeCache::getSlow): (JSC::EvalCodeCache::get): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::codeCacheForEval): (UnlinkedCodeBlock): (RareData): * debugger/Debugger.cpp: (JSC::evaluateInGlobalCallFrame): * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::evaluate): * interpreter/Interpreter.cpp: (JSC::eval): * runtime/CodeCache.cpp: (JSC::CodeCache::CodeCache): (JSC::CodeCache::generateBytecode): (JSC): (JSC::CodeCache::getCodeBlock): * runtime/CodeCache.h: (JSC::CodeCacheMap::CodeCacheMap): (CodeCacheMap): (JSC::CodeCacheMap::canPruneQuickly): (JSC::CodeCacheMap::prune): (JSC::CodeCache::create): (CodeCache): * runtime/Executable.cpp: (JSC::EvalExecutable::EvalExecutable): (JSC::EvalExecutable::compileInternal): * runtime/Executable.h: (JSC::EvalExecutable::create): (EvalExecutable): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::createEvalCodeBlock): * runtime/JSGlobalObject.h: (JSGlobalObject): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncEval): * runtime/JSGlobalData.cpp: (JSC::JSGlobalData::JSGlobalData): * runtime/JSGlobalData.h: (JSGlobalData): 2013-05-08 Mark Hahnenberg DFGArrayMode::fromObserved is too liberal when it sees different Array and NonArray shapes https://bugs.webkit.org/show_bug.cgi?id=115805 Reviewed by Geoffrey Garen. It checks the observed ArrayModes to see if we have seen any ArrayWith* first. If so, it assumes it's an Array::Array, even if we've also observed any NonArrayWith* in the ArrayProfile. This leads to the code generated by jumpSlowForUnwantedArrayMode to check the indexing type against (shape | IsArray) instead of just shape, which can cause us to exit a lot in the case that we saw a NonArray. To fix this we need to add a case that checks for both ArrayWith* and NonArrayWith* cases first, which should then use Array::PossiblyArray, then do the checks we were already doing. * bytecode/ArrayProfile.h: (JSC::hasSeenArray): (JSC::hasSeenNonArray): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::fromObserved): 2013-05-09 Joe Mason [BlackBerry] Set up logging buffer on start of jsc executable https://bugs.webkit.org/show_bug.cgi?id=114688 Reviewed by Rob Buis. Internal PR: 322715 Internally Reviewed By: Jeff Rogers * jsc.cpp: (main): call BB::Platform::setupApplicationLogging 2013-05-08 Michael Saboff JSC: There should be a disassembler for ARM Thumb 2 https://bugs.webkit.org/show_bug.cgi?id=115827 Reviewed by Filip Pizlo. Added a new disassembler for ARMv7 Thumb2 instructions for use by the JSC debugging and profiling code. The opcode coverage is currently not complete. It covers all of the integer instructions JSC currently emits, but only a limited number of floating point opcodes. Currently that is just the 64 bit vmov and vmsr instructions. The disassembler is structured as a base opcode class ARMv7DOpcode with sub-classes for each instruction group. There is a public format method that does the bulk of the disassembly work. There are two broad sub-classes, ARMv7D16BitOpcode and ARMv7D32BitOpcode, for the 16 bit and 32 bit opcodes. There are sub-classes under those two classes for individual and related groups of opcodes. Instructions are "dispatched" to the right subclass via two arrays of linked lists in the inner classes OpcodeGroup. There is one such inner class for each ARMv7D16BitOpcode and ARMv7D32BitOpcode. Each OpcodeGroup has a mask and a pattern that it applies to the instruction to determine that it matches a particular group. OpcodeGroup uses a static method to reinterpret_cast the Opcode object to the right base class for the instruction group for formatting. The cast eliminates the need of allocating an object for each decoded instruction. Unknown instructions are formatted as ".word 1234" or ".long 12345678" depending whether the instruction is 16 or 32 bit. * JavaScriptCore.xcodeproj/project.pbxproj: * disassembler/ARMv7: Added. * disassembler/ARMv7/ARMv7DOpcode.cpp: Added. (ARMv7Disassembler): (OpcodeGroupInitializer): (JSC::ARMv7Disassembler::ARMv7DOpcode::init): (JSC::ARMv7Disassembler::ARMv7DOpcode::startITBlock): (JSC::ARMv7Disassembler::ARMv7DOpcode::saveITConditionAt): (JSC::ARMv7Disassembler::ARMv7DOpcode::fetchOpcode): (JSC::ARMv7Disassembler::ARMv7DOpcode::disassemble): (JSC::ARMv7Disassembler::ARMv7DOpcode::bufferPrintf): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendInstructionName): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendRegisterName): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendRegisterList): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendFPRegisterName): (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::init): (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::doDisassemble): (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::defaultFormat): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddRegisterT2::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSPPlusImmediate::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchConditionalT1::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchExchangeT1::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchT2::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareImmediateT1::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT1::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT2::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeGeneratePCRelativeAddress::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadFromLiteralPool::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscBreakpointT1::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscByteHalfwordOps::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscHint16::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscIfThenT1::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveImmediateT1::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveRegisterT1::format): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::init): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::doDisassemble): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::defaultFormat): (JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::appendModifiedImmediate): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::appendImmShift): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::appendFPRegister): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegShift::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegParallel::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegMisc::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadRegister::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadUnsignedImmediate::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataPushPopSingle::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate12::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleRegister::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::format): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMSR::format): * disassembler/ARMv7/ARMv7DOpcode.h: Added. (ARMv7Disassembler): (ARMv7DOpcode): (JSC::ARMv7Disassembler::ARMv7DOpcode::ARMv7DOpcode): (JSC::ARMv7Disassembler::ARMv7DOpcode::is32BitInstruction): (JSC::ARMv7Disassembler::ARMv7DOpcode::isFPInstruction): (JSC::ARMv7Disassembler::ARMv7DOpcode::conditionName): (JSC::ARMv7Disassembler::ARMv7DOpcode::shiftName): (JSC::ARMv7Disassembler::ARMv7DOpcode::inITBlock): (JSC::ARMv7Disassembler::ARMv7DOpcode::startingITBlock): (JSC::ARMv7Disassembler::ARMv7DOpcode::endITBlock): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendInstructionNameNoITBlock): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendSeparator): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendCharacter): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendString): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendShiftType): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendSignedImmediate): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendUnsignedImmediate): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendPCRelativeOffset): (JSC::ARMv7Disassembler::ARMv7DOpcode::appendShiftAmount): (ARMv7D16BitOpcode): (OpcodeGroup): (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::OpcodeGroup): (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::setNext): (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::next): (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::matches): (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::OpcodeGroup::format): (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::rm): (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::rd): (JSC::ARMv7Disassembler::ARMv7D16BitOpcode::opcodeGroupNumber): (ARMv7DOpcodeAddRegisterT2): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddRegisterT2::rdn): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddRegisterT2::rm): (ARMv7DOpcodeAddSPPlusImmediate): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSPPlusImmediate::rd): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSPPlusImmediate::immediate8): (ARMv7DOpcodeAddSubtract): (ARMv7DOpcodeAddSubtractT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::rm): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractT1::rn): (ARMv7DOpcodeAddSubtractImmediate3): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::immediate3): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::rn): (ARMv7DOpcodeAddSubtractImmediate8): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::rdn): (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate8::immediate8): (ARMv7DOpcodeBranchConditionalT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchConditionalT1::condition): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchConditionalT1::offset): (ARMv7DOpcodeBranchExchangeT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchExchangeT1::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchExchangeT1::rm): (ARMv7DOpcodeBranchT2): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchT2::immediate11): (ARMv7DOpcodeCompareImmediateT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareImmediateT1::rn): (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareImmediateT1::immediate8): (ARMv7DOpcodeCompareRegisterT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT1::rn): (ARMv7DOpcodeCompareRegisterT2): (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT2::rn): (JSC::ARMv7Disassembler::ARMv7DOpcodeCompareRegisterT2::rm): (ARMv7DOpcodeDataProcessingRegisterT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::rm): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegisterT1::rdn): (ARMv7DOpcodeGeneratePCRelativeAddress): (JSC::ARMv7Disassembler::ARMv7DOpcodeGeneratePCRelativeAddress::rd): (JSC::ARMv7Disassembler::ARMv7DOpcodeGeneratePCRelativeAddress::immediate8): (ARMv7DOpcodeLoadFromLiteralPool): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadFromLiteralPool::rt): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadFromLiteralPool::immediate8): (ARMv7DOpcodeLoadStoreRegisterImmediate): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::immediate5): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::rn): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::rt): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale): (ARMv7DOpcodeLoadStoreRegisterImmediateWordAndByte): (ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord): (ARMv7DOpcodeLoadStoreRegisterOffsetT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::opB): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::rm): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::rn): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterOffsetT1::rt): (ARMv7DOpcodeLoadStoreRegisterSPRelative): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::rt): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterSPRelative::immediate8): (ARMv7DOpcodeLogicalImmediateT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeLogicalImmediateT1::immediate5): (ARMv7DOpcodeMiscAddSubSP): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscAddSubSP::immediate7): (ARMv7DOpcodeMiscByteHalfwordOps): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscByteHalfwordOps::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscByteHalfwordOps::op): (ARMv7DOpcodeMiscBreakpointT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscBreakpointT1::immediate8): (ARMv7DOpcodeMiscCompareAndBranch): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::immediate6): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscCompareAndBranch::rn): (ARMv7DOpcodeMiscHint16): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscHint16::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscHint16::opA): (ARMv7DOpcodeMiscIfThenT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscIfThenT1::firstCondition): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscIfThenT1::mask): (ARMv7DOpcodeMiscPushPop): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeMiscPushPop::registerMask): (ARMv7DOpcodeMoveImmediateT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveImmediateT1::rd): (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveImmediateT1::immediate8): (ARMv7DOpcodeMoveRegisterT1): (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveRegisterT1::rd): (JSC::ARMv7Disassembler::ARMv7DOpcodeMoveRegisterT1::rm): (ARMv7D32BitOpcode): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::OpcodeGroup): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::setNext): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::next): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::matches): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::OpcodeGroup::format): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rd): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rm): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rn): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::rt): (JSC::ARMv7Disassembler::ARMv7D32BitOpcode::opcodeGroupNumber): (ARMv7DOpcodeBranchRelative): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::sBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::j1): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::j2): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchRelative::immediate11): (ARMv7DOpcodeConditionalBranchT3): (JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::offset): (JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::condition): (JSC::ARMv7Disassembler::ARMv7DOpcodeConditionalBranchT3::immediate6): (ARMv7DOpcodeBranchOrBranchLink): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::offset): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::immediate10): (JSC::ARMv7Disassembler::ARMv7DOpcodeBranchOrBranchLink::isBL): (ARMv7DOpcodeDataProcessingLogicalAndRithmetic): (ARMv7DOpcodeDataProcessingModifiedImmediate): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::sBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingModifiedImmediate::immediate12): (ARMv7DOpcodeDataProcessingShiftedReg): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::sBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::immediate5): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::type): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::tbBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingShiftedReg::tBit): (ARMv7DOpcodeDataProcessingReg): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingReg::op1): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingReg::op2): (ARMv7DOpcodeDataProcessingRegShift): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegShift::opName): (ARMv7DOpcodeDataProcessingRegExtend): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::opExtendName): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::opExtendAndAddName): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegExtend::rotate): (ARMv7DOpcodeDataProcessingRegParallel): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegParallel::opName): (ARMv7DOpcodeDataProcessingRegMisc): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataProcessingRegMisc::opName): (ARMv7DOpcodeHint32): (JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::isDebugHint): (JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::debugOption): (JSC::ARMv7Disassembler::ARMv7DOpcodeHint32::op): (ARMv7DOpcodeFPTransfer): (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opH): (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opL): (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::rt): (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opC): (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::opB): (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::vd): (JSC::ARMv7Disassembler::ARMv7DOpcodeFPTransfer::vn): (ARMv7DOpcodeDataLoad): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataLoad::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataLoad::op): (ARMv7DOpcodeLoadRegister): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadRegister::immediate2): (ARMv7DOpcodeLoadSignedImmediate): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::pBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::uBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::wBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadSignedImmediate::immediate8): (ARMv7DOpcodeLoadUnsignedImmediate): (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadUnsignedImmediate::immediate12): (ARMv7DOpcodeLongMultipleDivide): (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::smlalOpName): (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::smlaldOpName): (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::smlsldOpName): (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::rdLo): (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::rdHi): (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::op1): (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::op2): (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::nBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeLongMultipleDivide::mBit): (ARMv7DOpcodeDataPushPopSingle): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataPushPopSingle::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataPushPopSingle::op): (ARMv7DOpcodeDataStoreSingle): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataStoreSingle::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeDataStoreSingle::op): (ARMv7DOpcodeStoreSingleImmediate12): (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate12::immediate12): (ARMv7DOpcodeStoreSingleImmediate8): (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::pBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::uBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::wBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleImmediate8::immediate8): (ARMv7DOpcodeStoreSingleRegister): (JSC::ARMv7Disassembler::ARMv7DOpcodeStoreSingleRegister::immediate2): (ARMv7DOpcodeUnmodifiedImmediate): (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::opName): (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::shBit): (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::bitNumOrSatImmediate): (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::immediate5): (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::immediate12): (JSC::ARMv7Disassembler::ARMv7DOpcodeUnmodifiedImmediate::immediate16): (ARMv7DOpcodeVMOVDoublePrecision): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::rt2): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::rt): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVDoublePrecision::globalData): (ARMv7DOpcodeVMOVSinglePrecision): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::op): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::rt2): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::rt): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMOVSinglePrecision::globalData): (ARMv7DOpcodeVMSR): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMSR::opL): (JSC::ARMv7Disassembler::ARMv7DOpcodeVMSR::rt): * disassembler/ARMv7Disassembler.cpp: Added. (JSC::tryToDisassemble): 2013-05-07 Julien Brianceau Take advantage of pre-decrement and post-increment opcodes for sh4 base JIT. https://bugs.webkit.org/show_bug.cgi?id=115722 Reviewed by Oliver Hunt. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::load8PostInc): (MacroAssemblerSH4): (JSC::MacroAssemblerSH4::load16Unaligned): (JSC::MacroAssemblerSH4::load16PostInc): (JSC::MacroAssemblerSH4::storeDouble): (JSC::MacroAssemblerSH4::load32WithUnalignedHalfWords): * assembler/SH4Assembler.h: (JSC::SH4Assembler::movwMemRegIn): (SH4Assembler): (JSC::SH4Assembler::movbMemRegIn): (JSC::SH4Assembler::printInstr): 2013-05-07 Anders Carlsson Remove AlwaysInline.h from WTF https://bugs.webkit.org/show_bug.cgi?id=115727 Reviewed by Brent Fulgham. The macro that used to be in AlwaysInline.h is now in Compiler.h so there's no reason to keep AlwaysInline.h around anymore. * jit/JSInterfaceJIT.h: * parser/Lexer.h: * runtime/JSCJSValue.h: * runtime/SymbolTable.h: 2013-05-07 Mikhail Pozdnyakov HashTraits >::PeekType should be raw pointer for better performance https://bugs.webkit.org/show_bug.cgi?id=115646 Reviewed by Darin Adler. * bytecompiler/StaticPropertyAnalyzer.h: (JSC::StaticPropertyAnalyzer::putById): Updated accordingly to new HashMap<.., RefPtr>::get() semantics. 2013-05-06 Julien Brianceau Misc bugfix and cleaning in sh4 base JIT. https://bugs.webkit.org/show_bug.cgi?id=115627 Reviewed by Oliver Hunt. Get rid of loadX(RegisterID r0, RegisterID src, RegisterID dest) functions. Remove misplaced extuw() implementation from MacroAssemblerSH4. Add movbRegMemr0 and movwRegMemr0 functions in SH4Assembler. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::add32): Skip operation when first operand is a zero immediate. (JSC::MacroAssemblerSH4::sub32): Skip operation when first operand is a zero immediate. (JSC::MacroAssemblerSH4::load32): Fix wrong usage of r0 register. (JSC::MacroAssemblerSH4::load8Signed): Handle "base == r0" case. (MacroAssemblerSH4): (JSC::MacroAssemblerSH4::load16): Handle "base == r0" case. (JSC::MacroAssemblerSH4::load16Unaligned): Use extuw() implementation from SH4Assembler. (JSC::MacroAssemblerSH4::load16Signed): Cosmetic change. (JSC::MacroAssemblerSH4::store8): Fix unhandled BaseIndex offset and handle (base == r0) case. (JSC::MacroAssemblerSH4::store16): Fix unhandled BaseIndex offset and handle (base == r0) case. (JSC::MacroAssemblerSH4::store32): * assembler/SH4Assembler.h: (JSC::SH4Assembler::movwRegMemr0): (SH4Assembler): (JSC::SH4Assembler::movbRegMemr0): (JSC::SH4Assembler::placeConstantPoolBarrier): Cosmetic change. (JSC::SH4Assembler::maxJumpReplacementSize): (JSC::SH4Assembler::replaceWithJump): Correct branch range and save an opcode. (JSC::SH4Assembler::printInstr): 2013-05-06 Anders Carlsson Stop using WTF::deleteAllValues in JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=115670 Reviewed by Oliver Hunt. Change the Vectors used to Vectors of OwnPtrs instead. * heap/DFGCodeBlocks.cpp: (JSC::DFGCodeBlocks::~DFGCodeBlocks): (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks): 2013-05-06 Andras Becsi Build with GCC 4.8 fails because of -Wmaybe-uninitialized https://bugs.webkit.org/show_bug.cgi?id=115648 Reviewed by Michael Saboff. Initialize values in Options::setOption since from there we end up calling OptionRange::init with uninitialized members. * runtime/Options.cpp: 2013-05-06 Gabor Rapcsanyi JSC ARM traditional failing on Octane NavierStokes test https://bugs.webkit.org/show_bug.cgi?id=115626 Reviewed by Zoltan Herczeg. Change the ARM traditional assembler to use double precision on value conversions. * assembler/ARMAssembler.h: 2013-05-03 Michael Saboff There should be a runtime option to constrain what functions get DFG compiled https://bugs.webkit.org/show_bug.cgi?id=115576 Reviewed by Mark Hahnenberg. Added OptionRange to Options to allow checking that something is within an option or not. The new OptionClass supports range strings in the form of [!][:]. If only one value is given, then it will be used for both low and high. A leading '!' inverts the check. If no range is given, then checking for a value within a range will always return true. Added the option "bytecodeRangeToDFGCompile" that takes an OptionRange string to select the bytecode range of code blocks to DFG compile. * dfg/DFGDriver.cpp: (JSC::DFG::compile): Added new check for bytecode count within bytecodeRangeToDFGCompile range. * runtime/Options.cpp: (JSC::parse): Added overloaded parse() for OptionRange. (JSC::OptionRange::init): Parse range string and then initialize the range. (JSC::OptionRange::isInRange): Function used by consumer to check if a value is within the specified range. (JSC::Options::dumpOption): Added code to dump OptionRange options. * runtime/Options.h: (OptionRange): New class. (JSC::OptionRange::operator= ): This is really used as a default ctor for use within the Option static array initialization. (JSC::OptionRange::rangeString): This is used for debug. It assumes that the char* passed into OptionRange::init is valid when this function is called. 2013-05-02 Oliver Hunt Fix potential bug in lookup logic https://bugs.webkit.org/show_bug.cgi?id=115522 Reviewed by Mark Hahnenberg. Though not a problem in practise, it is technically possible to inject an un-proxied global object into the scope chain via the C API. This change makes sure that the scope walk in BytecodeGenerator actually limits itself to scopes that are statically bindable. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::resolve): * runtime/JSObject.h: (JSObject): (JSC): (JSC::JSObject::isStaticScopeObject): 2013-05-01 Roger Fong Set Path in makefile for AppleWin. * JavaScriptCore.vcxproj/JavaScriptCore.make: 2013-05-01 Benjamin Poulain Remove the remaining wscript https://bugs.webkit.org/show_bug.cgi?id=115459 Reviewed by Andreas Kling. * wscript: Removed. 2013-04-30 Mark Lam JSContextGroupSetExecutionTimeLimit() should not pass a callback to the JSGlobalData watchdog if its client did not pass one in. https://bugs.webkit.org/show_bug.cgi?id=115461. Reviewed by Geoffrey Garen. * API/JSContextRef.cpp: (internalScriptTimeoutCallback): (JSContextGroupSetExecutionTimeLimit): * API/tests/testapi.c: (main): - Added test case when the time limit callback is 0. - Also updated a check to verify that a TerminatedExecutionException is thrown when the time out is cancelled. - Also fixed some cosmetic typos. 2013-04-30 Geoffrey Garen Removed op_ensure_property_exists https://bugs.webkit.org/show_bug.cgi?id=115460 Reviewed by Mark Hahnenberg. It was unused, and whatever it was once used for was not optimized. * JavaScriptCore.order: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/Opcode.h: (JSC::padOpcodeName): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: * jit/JITOpcodes32_64.cpp: * jit/JITStubs.cpp: * jit/JITStubs.h: * llint/LLIntSlowPaths.cpp: * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: 2013-04-30 Oliver Hunt JSC Stack walking logic craches in the face of inlined functions triggering JSGlobalData re-entry https://bugs.webkit.org/show_bug.cgi?id=115449 Reviewed by Geoffrey Garen. Rename callframeishost to something that makes sense, and fix getCallerInfo to correctly handle inline functions calling into the JSGlobalData. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::codeOriginForReturn): Make this more robust in the face of incorrect stack walking * interpreter/CallFrame.cpp: (JSC::CallFrame::trueCallerFrame): Everyone has to perform a codeblock() check before calling this so we might as well just do it here. * interpreter/Interpreter.cpp: (JSC::getCallerInfo): 2013-04-30 Julien Brianceau Bug fixing in sh4 base JIT and LLINT. https://bugs.webkit.org/show_bug.cgi?id=115420 Reviewed by Oliver Hunt. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::lshift32): (JSC::MacroAssemblerSH4::rshift32): (JSC::MacroAssemblerSH4::branchMul32): (JSC::MacroAssemblerSH4::urshift32): (JSC::MacroAssemblerSH4::replaceWithJump): (JSC::MacroAssemblerSH4::maxJumpReplacementSize): * assembler/SH4Assembler.h: (JSC::SH4Assembler::shldRegReg): (JSC::SH4Assembler::shadRegReg): (JSC::SH4Assembler::shalImm8r): (SH4Assembler): (JSC::SH4Assembler::sharImm8r): (JSC::SH4Assembler::maxJumpReplacementSize): (JSC::SH4Assembler::replaceWithJump): * offlineasm/sh4.rb: 2013-04-30 Geoffrey Garen Objective-C JavaScriptCore API should publicly support bridging to C https://bugs.webkit.org/show_bug.cgi?id=115447 Reviewed by Mark Hahnenberg. For consistency, I renamed +[JSValue valueWithValue:] => +[JSValue valueWithJSValueRef] +[JSContext contextWithGlobalContextRef] => +[JSContext contextWithJSGlobalContextRef] -[JSContext globalContext] => -[JSContext JSGlobalContextRef] I searched svn to verify that these functions don't have clients yet, so we won't break anything. I also exported as public API +[JSValue valueWithJSValueRef:] +[JSContext contextWithJSGlobalContextRef:] It's hard to integrate with the C API without these. 2013-04-30 Commit Queue Unreviewed, rolling out r149349 and r149354. http://trac.webkit.org/changeset/149349 http://trac.webkit.org/changeset/149354 https://bugs.webkit.org/show_bug.cgi?id=115444 The Thumb version of compileSoftModulo make invalid use of registers (Requested by benjaminp on #webkit). * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/ARMv7Assembler.h: (ARMv7Assembler): * assembler/AbstractMacroAssembler.h: (JSC::isARMv7s): (JSC): * assembler/MacroAssemblerARMv7.cpp: Removed. * assembler/MacroAssemblerARMv7.h: (MacroAssemblerARMv7): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileSoftModulo): (DFG): (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForARMv7s): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): (SpeculativeJIT): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2013-04-30 Zalan Bujtas Animations fail to start on http://www.google.com/insidesearch/howsearchworks/thestory/ https://bugs.webkit.org/show_bug.cgi?id=111244 Reviewed by David Kilzer. Enable performance.now() as a minimal subset of Web Timing API. It returns DOMHighResTimeStamp, a monotonically increasing value representing the number of milliseconds from the start of the navigation of the current document. JS libraries use this API to check against the requestAnimationFrame() timestamp. * Configurations/FeatureDefines.xcconfig: 2013-04-30 Zoltan Arvai Unreviewed. Speculative build fix on Qt Arm and Mips after r149349. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileSoftModulo): 2013-04-29 Cosmin Truta [ARM] Expand the use of integer division https://bugs.webkit.org/show_bug.cgi?id=115138 Reviewed by Benjamin Poulain. If availability of hardware integer division isn't known at compile time, check the CPU flags and decide at runtime whether to fall back to software. Currently, this OS-specific check is implemented on QNX. Moreover, use operator % instead of fmod() in the calculation of the software modulo. Even when it's software-emulated, operator % is faster than fmod(): on ARM v7 QNX, without hardware division, we noticed >3% speedup on SunSpider. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::sdiv): Did not compile conditionally. (JSC::ARMv7Assembler::udiv): Ditto. * assembler/AbstractMacroAssembler.h: (JSC::isARMv7s): Removed. * assembler/MacroAssemblerARMv7.cpp: Added. (JSC::isIntegerDivSupported): Added. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::supportsIntegerDiv): Added. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): Checked MacroAssembler::supportsIntegerDiv() in ArithDiv case. * dfg/DFGOperations.cpp: (JSC::DFG::operationModOnInts): Added. * dfg/DFGOperations.h: (JSC::DFG::Z_DFGOperation_ZZ): Added. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileSoftModulo): Separated the X86-specific and ARM-specific codegen from the common implementation; used operationModOnInts on ARM. (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForARM): Renamed from compileIntegerArithDivForARMv7. (JSC::DFG::SpeculativeJIT::compileArithMod): Allowed run-time detection of integer div on ARM. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): Added overloads with Z_DFGOperation_ZZ arguments. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): Used compileIntegerArithDivForARM. 2013-04-29 Benjamin Poulain Unify the data access of StringImpl members from JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=115320 Reviewed by Andreas Kling. DFG accesses the member infos by directly calling the methods on StringImpl, while the baseline JIT was using helper methods on ThunkHelpers. Cut the middle man, and use StringImpl directly everywhere. * jit/JITInlines.h: (JSC::JIT::emitLoadCharacterString): * jit/JITPropertyAccess.cpp: (JSC::JIT::stringGetByValStubGenerator): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::stringGetByValStubGenerator): * jit/JSInterfaceJIT.h: * jit/ThunkGenerators.cpp: (JSC::stringCharLoad): 2013-04-29 Benjamin Poulain Use push and pop for iOS math function thunks https://bugs.webkit.org/show_bug.cgi?id=115215 Reviewed by Filip Pizlo. The iOS ABI is a little different than regular ARM ABI regarding stack alignment. The requirement is 4 bytes: "The ARM environment uses a stack that—at the point of function calls—is 4-byte aligned, grows downward, and contains local variables and a function’s parameters." Subsequently, we can just use push and pop to preserve the link register. * jit/ThunkGenerators.cpp: 2013-04-29 Brent Fulgham [Windows, WinCairo] Get rid of last few pthread include/link references. https://bugs.webkit.org/show_bug.cgi?id=115375 Reviewed by Tim Horton. * JavaScriptCore.vcproj/jsc/jscPostBuild.cmd: * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: * JavaScriptCore.vcxproj/jsc/jscCommon.props: * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: * JavaScriptCore.vcxproj/testapi/testapiCommon.props: 2013-04-29 Roger Fong Unreviewed. AppleWin VS2010 build fix. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: 2013-04-26 Mark Hahnenberg ~BlockAllocator should ASSERT that it has no more Regions left https://bugs.webkit.org/show_bug.cgi?id=115287 Reviewed by Andreas Kling. * heap/BlockAllocator.cpp: (JSC::BlockAllocator::~BlockAllocator): (JSC::BlockAllocator::allRegionSetsAreEmpty): * heap/BlockAllocator.h: (RegionSet): (JSC::BlockAllocator::RegionSet::isEmpty): (BlockAllocator): 2013-04-29 Mark Hahnenberg IndexingTypes should use hex https://bugs.webkit.org/show_bug.cgi?id=115286 Decimal is kind of confusing/hard to read because they're used as bit masks. Hex seems more appropriate. Reviewed by Geoffrey Garen. * runtime/IndexingType.h: 2013-04-29 Carlos Garcia Campos Unreviewed. Fix make distcheck. * GNUmakefile.list.am: Add missing headers files to compilation and offlineasm/sh4.rb script. 2013-04-28 Dean Jackson [Mac] Disable canvas backing store scaling (HIGH_DPI_CANVAS) https://bugs.webkit.org/show_bug.cgi?id=115310 Reviewed by Simon Fraser. Remove ENABLE_HIGH_DPI_CANVAS_macosx. * Configurations/FeatureDefines.xcconfig: 2013-04-27 Darin Adler Move from constructor and member function adoptCF/NS to free function adoptCF/NS. https://bugs.webkit.org/show_bug.cgi?id=115307 Reviewed by Geoffrey Garen. * heap/HeapTimer.cpp: (JSC::HeapTimer::HeapTimer): * runtime/JSGlobalData.cpp: (JSC::enableAssembler): Use adoptCF free function. 2013-04-27 Anders Carlsson Try to fix the Windows build. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: 2013-04-25 Geoffrey Garen Cleaned up pre/post inc/dec in bytecode https://bugs.webkit.org/show_bug.cgi?id=115222 Reviewed by Filip Pizlo. A few related changes here: (*) Removed post_inc and post_dec. The two-result form was awkward to reason about. Being explicit about the intermediate mov and to_number reduces DFG overhead, removes some fragile ASSERTs from the DFG, and fixes a const bug. Plus, we get to blow away 262 lines of code. (*) Renamed pre_inc and pre_dec to inc and dec, since there's only one version now. (*) Renamed to_jsnumber to to_number, to match the ECMA name. (*) Tightened up the codegen and runtime support for to_number. * JavaScriptCore.order: Order! * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitInc): (JSC::BytecodeGenerator::emitDec): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitToNumber): (BytecodeGenerator): Removed post_inc and post_dec. * bytecompiler/NodesCodegen.cpp: (JSC::emitPreIncOrDec): Updated for rename. (JSC::emitPostIncOrDec): Issue an explicit mov and to_number when needed. These are rare, and they boil away in the DFG. (JSC::PostfixNode::emitResolve): (JSC::PrefixNode::emitResolve): For const, use an explicit mov instead of any special forms. This fixes a bug where we would do string add/subtract instead of number. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.h: (JSC::DFG::canCompileOpcode): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_inc): (JSC::JIT::emitSlow_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emitSlow_op_dec): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_op_inc): (JSC::JIT::emitSlow_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emitSlow_op_dec): Removed post_inc/dec, and updated for renames. * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_to_number): (JSC::JIT::emitSlow_op_to_number): Removed a test for number cells. There's no such thing! * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_to_number): Use LowestTag to avoid making assumptions about the lowest valued tag. (JSC::JIT::emitSlow_op_to_number): Updated for renames. * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * jit/JITStubs.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * parser/NodeConstructors.h: (JSC::UnaryPlusNode::UnaryPlusNode): Removed post_inc/dec, and updated for renames. * runtime/Operations.cpp: (JSC::jsIsObjectType): Removed a test for number cells. There's no such thing! 2013-04-27 Julien Brianceau REGRESSION(r149114): cache flush for SH4 arch may flush an extra page. https://bugs.webkit.org/show_bug.cgi?id=115305 Reviewed by Andreas Kling. * assembler/SH4Assembler.h: (JSC::SH4Assembler::cacheFlush): 2013-04-26 Geoffrey Garen Re-landing Filled out more cases of branch folding in bytecode when emitting expressions into a branching context https://bugs.webkit.org/show_bug.cgi?id=115057 Reviewed by Phil Pizlo. We can't fold the number == 1 case to boolean because all non-zero numbers down-cast to true, but only 1 is == to true. 2013-04-26 Filip Pizlo Correct indentation of SymbolTable.h Rubber stamped by Mark Hahnenberg. * runtime/SymbolTable.h: 2013-04-26 Roger Fong Make Apple Windows VS2010 build results into and get dependencies from __32 suffixed folders. Make the DebugSuffix configuration use _debug dependencies. * JavaScriptCore.vcxproj/JavaScriptCore.make: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.vcxproj/JavaScriptCoreCF.props: * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: * JavaScriptCore.vcxproj/JavaScriptCoreDebug.props: * JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorBuildCmd.cmd: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorDebug.props: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPreBuild.cmd: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorProduction.props: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props: * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make: * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedCommon.props: * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedDebug.props: * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedProduction.props: * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props: * JavaScriptCore.vcxproj/JavaScriptCorePostBuild.cmd: * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd: * JavaScriptCore.vcxproj/JavaScriptCoreProduction.props: * JavaScriptCore.vcxproj/JavaScriptCoreRelease.props: * JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props: * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make: * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh: * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make: * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: * JavaScriptCore.vcxproj/build-generated-files.sh: * JavaScriptCore.vcxproj/copy-files.cmd: * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: * JavaScriptCore.vcxproj/jsc/jscCommon.props: * JavaScriptCore.vcxproj/jsc/jscDebug.props: * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: * JavaScriptCore.vcxproj/jsc/jscProduction.props: * JavaScriptCore.vcxproj/jsc/jscRelease.props: * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters: * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props: * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd: * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd: * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props: * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props: * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: * JavaScriptCore.vcxproj/testapi/testapiCommon.props: * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: * JavaScriptCore.vcxproj/testapi/testapiDebug.props: * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd: * JavaScriptCore.vcxproj/testapi/testapiProduction.props: * JavaScriptCore.vcxproj/testapi/testapiRelease.props: * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: 2013-04-26 Roger Fong Disable sub-pixel layout on mac. https://bugs.webkit.org/show_bug.cgi?id=114999. Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2013-04-26 Oliver Hunt Make stack tracing more robust https://bugs.webkit.org/show_bug.cgi?id=115272 Reviewed by Geoffrey Garen. CallFrame already handles stack walking confusion robustly, so we should make sure that the actual walk handles that as well. * interpreter/Interpreter.cpp: (JSC::getCallerInfo): 2013-04-26 Mark Hahnenberg REGRESSION(r149165): It made many tests crash on 32 bit https://bugs.webkit.org/show_bug.cgi?id=115227 Reviewed by Csaba Osztrogonác. m_reservation is uninitialized when ENABLE(SUPER_REGION) is false. * heap/SuperRegion.cpp: (JSC::SuperRegion::~SuperRegion): 2013-04-26 Julien Brianceau Fix SH4 build broken since r149159. https://bugs.webkit.org/show_bug.cgi?id=115229 Add BranchTruncateType enum in SH4 port and handle it in branchTruncateDoubleToInt32. Reviewed by Allan Sandfeld Jensen. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::branchTruncateDoubleToInt32): 2013-04-25 Mark Hahnenberg SuperRegion doesn't call deallocate() on its PageReservation https://bugs.webkit.org/show_bug.cgi?id=115208 Reviewed by Geoffrey Garen. It should. This doesn't cause us to leak physical memory, but it does cause us to leak virtual address space (and probably mach ports), which is also bad :-( FixedVMPoolExecutableAllocator also has this bug, but it doesn't matter much because there's only one instance of that class throughout the entire lifetime of the process, whereas each JSGlobalData has its own SuperRegion. * heap/SuperRegion.cpp: (JSC::SuperRegion::~SuperRegion): * heap/SuperRegion.h: (SuperRegion): * jit/ExecutableAllocatorFixedVMPool.cpp: (FixedVMPoolExecutableAllocator): (JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator): 2013-04-25 Filip Pizlo DFG doesn't support to_jsnumber https://bugs.webkit.org/show_bug.cgi?id=115129 Reviewed by Geoffrey Garen. Based on Oliver's patch. Implements to_jsnumber as Identity(Number:@thingy), and then does an optimization in Fixup to turn Identity(Number:) into Identity(Int32:) if the predictions tell us to. Identity is later turned into Phantom. Also fixed BackPropMask, which appeared to have NodeDoesNotExit included in it. That's wrong; NodeDoesNotExit is not a backward propagation property. Also fixed Identity to be marked as CanExit (i.e. not NodeDoesNotExit). This more than doubles the FPS on ammo. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.h: (JSC::DFG::canCompileOpcode): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (FixupPhase): (JSC::DFG::FixupPhase::observeUseKindOnNode): (JSC::DFG::FixupPhase::observeUseKindOnEdge): * dfg/DFGNodeFlags.h: (DFG): * dfg/DFGNodeType.h: (DFG): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): 2013-04-24 Oliver Hunt Add support for Math.imul https://bugs.webkit.org/show_bug.cgi?id=115143 Reviewed by Filip Pizlo. Add support for Math.imul, a thunk generator for Math.imul, and an intrinsic. Fairly self explanatory set of changes, DFG intrinsics simply leverages the existing ValueToInt32 nodes. * create_hash_table: * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::executeEffects): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsic): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: (DFG): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithIMul): * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/ThunkGenerators.cpp: (JSC::imulThunkGenerator): (JSC): * jit/ThunkGenerators.h: (JSC): * runtime/Intrinsic.h: * runtime/MathObject.cpp: (JSC): (JSC::mathProtoFuncIMul): * runtime/JSGlobalData.cpp: (JSC::thunkGeneratorForIntrinsic): 2013-04-25 Filip Pizlo Unreviewed, roll out http://trac.webkit.org/changeset/148999 It broke http://kripken.github.io/ammo.js/examples/new/ammo.html * JavaScriptCore.order: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitNewArray): (JSC::BytecodeGenerator::emitThrowReferenceError): (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::shouldEmitProfileHooks): (BytecodeGenerator): * bytecompiler/NodesCodegen.cpp: (JSC): (JSC::NullNode::emitBytecode): (JSC::BooleanNode::emitBytecode): (JSC::NumberNode::emitBytecode): (JSC::StringNode::emitBytecode): (JSC::IfNode::emitBytecode): (JSC::IfElseNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createIfStatement): (ASTBuilder): * parser/NodeConstructors.h: (JSC): (JSC::NullNode::NullNode): (JSC::BooleanNode::BooleanNode): (JSC::NumberNode::NumberNode): (JSC::StringNode::StringNode): (JSC::IfNode::IfNode): (JSC::IfElseNode::IfElseNode): * parser/Nodes.h: (JSC::ExpressionNode::isPure): (JSC::ExpressionNode::isSubtract): (StatementNode): (NullNode): (JSC::NullNode::isNull): (BooleanNode): (JSC::BooleanNode::isPure): (NumberNode): (JSC::NumberNode::value): (JSC::NumberNode::isPure): (StringNode): (JSC::StringNode::isPure): (JSC::StringNode::isString): (BinaryOpNode): (IfNode): (JSC): (IfElseNode): (ContinueNode): (BreakNode): * parser/Parser.cpp: (JSC::::parseIfStatement): * parser/ResultType.h: (ResultType): * runtime/JSCJSValueInlines.h: (JSC::JSValue::pureToBoolean): * runtime/JSCell.h: (JSCell): * runtime/JSCellInlines.h: (JSC): 2013-04-25 Filip Pizlo PreciseJumpTargets should treat loop_hint as a jump target https://bugs.webkit.org/show_bug.cgi?id=115209 Reviewed by Mark Hahnenberg. I didn't add a test but I turned this into a release assertion. Running Octane is enough to trigger it. * bytecode/PreciseJumpTargets.cpp: (JSC::computePreciseJumpTargets): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): 2013-04-25 Roman Zhuykov Fix problems with processing negative zero on DFG. https://bugs.webkit.org/show_bug.cgi?id=113862 Reviewed by Filip Pizlo. Fix NodeNeedsNegZero flag propagation in BackwardPropagationPhase. Function arithNodeFlags should not mask NodeNeedsNegZero flag for ArithNegate and DoubleAsInt32 nodes and this flag should be always used to decide where we need to generate nezative-zero checks. Remove unnecessary negative-zero checks from integer ArithDiv on ARM. Also remove such checks from integer ArithMod on ARM and X86, and make them always to check not only "modulo_result == 0" but also "dividend < 0". Generate faster code for case when ArithMod operation divisor is constant power of 2 on ARMv7 in the same way as on ARMv7s, and add negative-zero checks into this code when needed. Change speculationCheck ExitKind from Overflow to NegativeZero where applicable. This shows 30% speedup of math-spectral-norm, and 5% speedup on SunSpider overall on ARMv7 Linux. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::branchConvertDoubleToInt32): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::branchConvertDoubleToInt32): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchConvertDoubleToInt32): * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::branchConvertDoubleToInt32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::isNotNegZero): (JSC::DFG::BackwardsPropagationPhase::isNotPosZero): (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGNode.h: (JSC::DFG::Node::arithNodeFlags): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32): (JSC::DFG::SpeculativeJIT::compileSoftModulo): (JSC::DFG::SpeculativeJIT::compileArithNegate): 2013-04-25 Oliver Hunt Stack guards are too conservative https://bugs.webkit.org/show_bug.cgi?id=115147 Reviewed by Mark Hahnenberg. Increase stack guard to closer to old size. * interpreter/Interpreter.cpp: (JSC::Interpreter::StackPolicy::StackPolicy): 2013-04-25 Oliver Hunt Stack guards are too conservative https://bugs.webkit.org/show_bug.cgi?id=115147 Reviewed by Geoffrey Garen. Reduce the limits and simplify the decision making. * interpreter/Interpreter.cpp: (JSC::Interpreter::StackPolicy::StackPolicy): 2013-04-25 Nick Diego Yamane JSC: Fix interpreter misbehavior in builds with JIT disabled https://bugs.webkit.org/show_bug.cgi?id=115190 Reviewed by Oliver Hunt. Commit http://trac.webkit.org/changeset/147858 modified some details on how JS stack traces are built. The method "getLineNumberForCallFrame", renamed in that changeset to "getBytecodeOffsetForCallFrame" is always returning `0' when JIT is disabled How to reproduce: - Build webkit with JIT disabled - Open MiniBrowser, for example, with http://google.com - In a debug build, WebProcess will hit the following ASSERT: Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp:279 ASSERT(low); * interpreter/Interpreter.cpp: (JSC::getBytecodeOffsetForCallFrame): 2013-04-25 Oliver Hunt Make checkSyntax take a JSGlobalData instead of an ExecState RS=Tim * jsc.cpp: (runInteractive): * runtime/Completion.cpp: (JSC::checkSyntax): * runtime/Completion.h: (JSC): 2013-04-25 Michael Saboff 32 Bit: Crash due to RegExpTest nodes not setting result type to Boolean https://bugs.webkit.org/show_bug.cgi?id=115188 Reviewed by Geoffrey Garen. Changed the RegExpTest node to set the AbstractValue to boolean, since that what it is. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::executeEffects): 2013-04-25 Julien Brianceau REGRESSION(r137994): Random crashes occur with SH4 JSC. https://bugs.webkit.org/show_bug.cgi?id=115167. Reviewed by Oliver Hunt. Since r137994, uncommited pages could be inside the area of memory in parameter of the cacheFlush function. That's why we have to flush each page separately to avoid a fail of the whole flush, if an uncommited page is in the area. This patch is very similar to changeset 145194 made for ARMv7 architecture, see https://bugs.webkit.org/show_bug.cgi?id=111441 for further information. * assembler/SH4Assembler.h: (JSC::SH4Assembler::cacheFlush): 2013-04-24 Mark Lam Add watchdog timer polling for the DFG. https://bugs.webkit.org/show_bug.cgi?id=115134. Reviewed by Geoffrey Garen. The strategy is to add a speculation check to the DFG generated code to test if the watchdog timer has fired or not. If the watchdog timer has fired, the generated code will do an OSR exit to the baseline JIT, and let it handle servicing the watchdog timer. If the watchdog is not enabled, this speculation check will not be emitted. * API/tests/testapi.c: (currentCPUTime_callAsFunction): (extendTerminateCallback): (main): - removed try/catch statements so that we can test the watchdog on the DFG. - added JS bindings to a native currentCPUTime() function so that the timeout tests can be more accurate. - also shortened the time values so that the tests can complete sooner. * bytecode/ExitKind.h: * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * runtime/Watchdog.cpp: (JSC::Watchdog::setTimeLimit): 2013-04-24 Filip Pizlo Special thunks for math functions should work on ARMv7 https://bugs.webkit.org/show_bug.cgi?id=115144 Reviewed by Gavin Barraclough and Oliver Hunt. The only hard bit here was ensuring that we implemented the very special "cheap C call" convention on ARMv7. * assembler/AbstractMacroAssembler.h: (JSC::isARMv7s): (JSC): (JSC::isX86): * dfg/DFGCommon.h: * jit/SpecializedThunkJIT.h: (SpecializedThunkJIT): (JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn): * jit/ThunkGenerators.cpp: (JSC::floorThunkGenerator): (JSC::ceilThunkGenerator): (JSC::roundThunkGenerator): (JSC::expThunkGenerator): (JSC::logThunkGenerator): 2013-04-24 Julien Brianceau Misc bugfix and cleaning in sh4 base JIT. https://bugs.webkit.org/show_bug.cgi?id=115022. Reviewed by Oliver Hunt. Remove unused add32() and sub32() with scratchreg parameter to avoid confusion as this function prototype means another behaviour. Remove unused "void push(Address)" function which seems quite buggy. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::and32): Cosmetic change. (JSC::MacroAssemblerSH4::lshift32): Cosmetic change. (JSC::MacroAssemblerSH4::or32): Cosmetic change. (JSC::MacroAssemblerSH4::xor32): Cosmetic change. (MacroAssemblerSH4): (JSC::MacroAssemblerSH4::load32): Cosmetic change. (JSC::MacroAssemblerSH4::load8Signed): Fix invalid offset upper limit when using r0 register and cosmetic changes. (JSC::MacroAssemblerSH4::load8): Reuse load8Signed to avoid duplication. (JSC::MacroAssemblerSH4::load16): Fix invalid offset upper limit when using r0 register, fix missing offset shift and cosmetic changes. (JSC::MacroAssemblerSH4::store32): Cosmetic change. (JSC::MacroAssemblerSH4::branchAdd32): Store result value before branch. 2013-04-24 Patrick Gansterer [WIN] Remove pthread from Visual Studio files in JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=114864 Reviewed by Brent Fulgham. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops: * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: * JavaScriptCore.vcproj/jsc/jscCommon.vsprops: * JavaScriptCore.vcproj/testRegExp/testRegExpCommon.vsprops: * JavaScriptCore.vcproj/testapi/testapiCommon.vsprops: * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: * JavaScriptCore.vcxproj/jsc/jscCommon.props: * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: * JavaScriptCore.vcxproj/testapi/testapiCommon.props: * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: 2013-04-24 Filip Pizlo DFG should keep the operand to create_this alive if it's emitting code for create_this https://bugs.webkit.org/show_bug.cgi?id=115133 Reviewed by Mark Hahnenberg. The DFG must model bytecode liveness, or else OSR exit is going to have a really bad time. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): 2013-04-24 Roger Fong Have VS2010 WebKit solution look in WebKit_Libraries/lib32 for dependencies. * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd: * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd: * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters: * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd: * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd: * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd: 2013-04-24 Geoffrey Garen 32-bit build fix. Unreviewed. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch): Explicitly truncate to 32-bit to avoid compiler warnings. It's safe to truncate because the payload of a boolean is the low bits on both 64-bit and 32-bit. 2013-04-23 Geoffrey Garen Filled out more cases of branch folding in the DFG https://bugs.webkit.org/show_bug.cgi?id=115088 Reviewed by Oliver Hunt. No change on the benchmarks we track, but a 3X speedup on a microbenchmark that uses these techniques. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): (!/=)= and (!/=)== can constant fold all types, not just numbers, because true constants have no side effects when type-converted at runtime. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::shouldSpeculateBoolean): Added support for fixing up boolean uses, like we do for other types like number. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch): (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): (JSC::DFG::SpeculativeJIT::compare): (JSC::DFG::SpeculativeJIT::compileStrictEq): (JSC::DFG::SpeculativeJIT::compileBooleanCompare): Peephole fuse boolean compare and/or compare-branch, now that we have the types for them. * dfg/DFGSpeculativeJIT.h: Updated declarations. == Rolled over to ChangeLog-2013-04-24 ==