2021-09-23 Philip Chimento Various tweaks in preparation for Temporal.Instant https://bugs.webkit.org/show_bug.cgi?id=230331 Reviewed by Yusuke Suzuki. * runtime/TemporalDuration.cpp: (JSC::TemporalDuration::fromDurationLike): Use temporalUnitPropertyName(). (JSC::TemporalDuration::toISO8601Duration): Improve error message to include the invalid string. (JSC::TemporalDuration::with const): Use temporalUnitPropertyName(). (JSC::TemporalDuration::toString): Use formatSecondsStringFraction(). * runtime/TemporalObject.cpp: (JSC::ellipsizeAt): Add helper to ellipsize string at certain length. (JSC::temporalUnitPropertyName): Move code from TemporalDuration into a function which will be reused in other Temporal types. (JSC::temporalFractionalSecondDigits): Handle NaN as per specification, and improve error message to include the invalid value. (JSC::formatSecondsStringFraction): Move code from TemporalDuration into a function which will be reused in other Temporal types. * runtime/TemporalObject.h: 2021-09-23 Devin Rousso Web Inspector: Graphics: add instrumentation for new `CanvasRenderingContext2DSettings` https://bugs.webkit.org/show_bug.cgi?id=225180 Reviewed by BJ Burg. * inspector/protocol/Canvas.json: Add `colorSpace` and `desynchronized` to `Canvas.ContextAttributes`. 2021-09-23 Ross Kirsling [JSC] Handle syntactic production for `#x in expr` correctly https://bugs.webkit.org/show_bug.cgi?id=230668 Reviewed by Yusuke Suzuki. The production for `#x in expr` is easy to get wrong. RelationalExpression[In, Yield, Await] : ShiftExpression[?Yield, ?Await] RelationalExpression[?In, ?Yield, ?Await] < ShiftExpression[?Yield, ?Await] RelationalExpression[?In, ?Yield, ?Await] > ShiftExpression[?Yield, ?Await] RelationalExpression[?In, ?Yield, ?Await] <= ShiftExpression[?Yield, ?Await] RelationalExpression[?In, ?Yield, ?Await] >= ShiftExpression[?Yield, ?Await] RelationalExpression[?In, ?Yield, ?Await] instanceof ShiftExpression[?Yield, ?Await] [+In] RelationalExpression[+In, ?Yield, ?Await] in ShiftExpression[?Yield, ?Await] [+In] PrivateIdentifier in ShiftExpression[?Yield, ?Await] We were ensuring that a standalone private name `#x` is always followed by operator `in`; this patch further ensures that that particular `in` can't have its LHS misparsed as a RelationalExpression. * parser/Parser.cpp: (JSC::Parser::parseBinaryExpression): Verify the precedence of the topmost operator on the stack (if any) when parsing standalone `#x`. 2021-09-22 Mikhail R. Gadelha Null pointer dereference in JSC::GetByStatus https://bugs.webkit.org/show_bug.cgi?id=229674 Reviewed by Yusuke Suzuki. In GetByStatus::computeForStubInfoWithoutExitSiteFeedback, there are several places that dereference the stubInfo argument when calling the GetByStatus constructor. To prevent a nullptr dereference, the pointer is not dereferenced anymore, and a check was added to check if stubInfo is a valid pointer before accessing it. * bytecode/GetByStatus.cpp: (JSC::GetByStatus::GetByStatus): (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/GetByStatus.h: 2021-09-22 Yusuke Suzuki [JSC] Filter algorithmic numbering systems from enumeration data https://bugs.webkit.org/show_bug.cgi?id=230660 Reviewed by Ross Kirsling. Algorithmic numbering systems' handling is not included in normal ICU build. This patch filters out them from available numbering systems. * runtime/IntlObject.cpp: (JSC::availableNumberingSystems): 2021-09-22 Yusuke Suzuki [JSC] Adjust Intl currency enumeration https://bugs.webkit.org/show_bug.cgi?id=230656 Reviewed by Ross Kirsling. 1. List up all available currencies. 2. Introduce a work-around for VES, LSM, and EQE * runtime/IntlObject.cpp: (JSC::availableCurrencies): 2021-09-22 Yusuke Suzuki [JSC] emoji and eor collations are missing https://bugs.webkit.org/show_bug.cgi?id=230652 Reviewed by Ross Kirsling. Due to ICU's bug, "emoji" and "eor" collations are missing from enumeration. This patch adds work-around for this. * runtime/IntlObject.cpp: (JSC::availableCollations): 2021-09-22 Yusuke Suzuki [JSC] Intl unicode identifier type will reject underscore https://bugs.webkit.org/show_bug.cgi?id=230645 Reviewed by Ross Kirsling. We reject '_' since BCP-47 rejects it and we should follow BCP-47 in all Intl inputs. * runtime/IntlObject.cpp: (JSC::isUnicodeLocaleIdentifierType): 2021-09-21 Alexey Shvayka [WebIDL] DOM constructors should extend InternalFunction https://bugs.webkit.org/show_bug.cgi?id=228763 Reviewed by Sam Weinig. Introduce finishCreation(VM&) overload to preserve the current property order of WebIDL constructors, and to defer a large code change needed for passing through `length` / `name` parameters (bug #230584). * runtime/InternalFunction.cpp: (JSC::InternalFunction::InternalFunction): (JSC::InternalFunction::finishCreation): * runtime/InternalFunction.h: 2021-09-21 Chris Dumez Reduce use of makeRef() and use Ref { } instead https://bugs.webkit.org/show_bug.cgi?id=230585 Reviewed by Alex Christensen. * debugger/Debugger.cpp: (JSC::Debugger::setBreakpoint): (JSC::Debugger::schedulePauseForSpecialBreakpoint): * llint/LLIntEntrypoint.cpp: (JSC::LLInt::setFunctionEntrypoint): (JSC::LLInt::setEvalEntrypoint): (JSC::LLInt::setProgramEntrypoint): (JSC::LLInt::setModuleProgramEntrypoint): * runtime/JSString.cpp: (JSC::JSRopeString::resolveRopeToExistingAtomString const): * runtime/VM.cpp: (JSC::jitCodeForCallTrampoline): (JSC::jitCodeForConstructTrampoline): * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmOMGForOSREntryPlan.cpp: (JSC::Wasm::OMGForOSREntryPlan::OMGForOSREntryPlan): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::OMGPlan): * wasm/WasmSignature.cpp: (JSC::Wasm::SignatureInformation::signatureFor): * wasm/WasmSignatureInlines.h: (JSC::Wasm::SignatureInformation::get): * wasm/WasmSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): * wasm/js/JSWebAssemblyInstance.h: 2021-09-21 Yusuke Suzuki [JSC] CompareStrictEq is omitting String check incorrectly https://bugs.webkit.org/show_bug.cgi?id=230582 rdar://83237121 Reviewed by Mark Lam. 1. Add left and right prefixes to neitherDoubleNorHeapBigIntChild and notDoubleChild edges since registers are named with left and right. Without this prefix, it is hard to follow in the code. 2. Remove leftGPR and rightGPR and use leftRegs.payloadGPR() and rightRegs.payloadGPR() to avoid having different variables pointing to the same registers. 3. DFG needsTypeCheck is done with wrong type filters. As a result, necessary checks are omitted. This patch fixes that. FTL does not have the same problem. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileNeitherDoubleNorHeapBigIntToNotDoubleStrictEquality): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): 2021-09-21 Mark Lam Replace a few ASSERTs with static_asserts in the ARM64 MacroAssemblers. https://bugs.webkit.org/show_bug.cgi?id=230569 Reviewed by Yusuke Suzuki. * assembler/ARM64Assembler.h: * assembler/ARM64EAssembler.h: 2021-09-21 Justin Michaud Differential testing: live statement don't execute https://bugs.webkit.org/show_bug.cgi?id=229939 Reviewed by Saam Barati. In statements are supposed to throw if they are applied to a non-object. We incorrectly converted InByVals into HasIndexedProperty any time they were a cell, so we silently converted non-objects. Before converting an InByVal, we first speculate that the base is an object now. We do not always require an object edge for HasIndexedProperty because enumerator next() does not throw if it encounters a cell that requires conversion during the call to toObject (for example, a string literal). That is, we should silently convert the string during enumeration, but not for an In statement, and so HasIndexedProperty is prepared to handle both cases. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::convertToHasIndexedProperty): 2021-09-21 Mikhail R. Gadelha Prevent test from accessing FP registers if they are not available (e.g., arm softFP) https://bugs.webkit.org/show_bug.cgi?id=230493 Unreviewed gardening. The patch from https://bugs.webkit.org/show_bug.cgi?id=228543 introduced explicity calls to FP registers, however, they are not available in archs that emulate FPs. This patch adds an #ifdef to only enable the test if the arch has FP registers. * assembler/testmasm.cpp: (JSC::testStoreBaseIndex): 2021-09-20 Chris Dumez Stop using makeRef(*this) / makeRefPtr(this) https://bugs.webkit.org/show_bug.cgi?id=230464 Reviewed by Alex Christensen. * inspector/InjectedScriptHost.cpp: (Inspector::InjectedScriptHost::wrapper): * inspector/remote/RemoteConnectionToTarget.cpp: (Inspector::RemoteConnectionToTarget::close): * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm: (Inspector::RemoteConnectionToTarget::setup): (Inspector::RemoteConnectionToTarget::close): (Inspector::RemoteConnectionToTarget::sendMessageToTarget): * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::compileAsync): * wasm/WasmNameSection.h: (JSC::Wasm::NameSection::get): * wasm/WasmStreamingCompiler.cpp: (JSC::Wasm::StreamingCompiler::didReceiveFunctionData): 2021-09-17 Mikhail R. Gadelha Fix CellTag being set 32 bits even if the base is not a cell https://bugs.webkit.org/show_bug.cgi?id=230364 Reviewed by Yusuke Suzuki. Initial patch by Caio Lima. In 32 bits the tag of the base was not being preserved before calling the slow path and was instead being always being set to cellTag. This patch slightly changes the code to instead of setting the cellTag, it now calls the slow path using only the payload if the base is a cell, otherwise it uses tag+payload. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileEnumeratorHasProperty): 2021-09-17 Yusuke Suzuki [JSC] Add fast property enumeration mode for JSON.stringify https://bugs.webkit.org/show_bug.cgi?id=230393 Reviewed by Mark Lam. We collected profiles and found several subtests are using JSON.stringify enough. And generated strings are many serialized leaf objects. This patch adds fast object property enumeration. When we know that source object meets some conditions, we can say that, as long as structure is not changed, we can continue using property names and offset collected from the structure. This way removes non observable [[Get]] operations to accelerate JSON.stringify performance for major object iteration cases. We also extend MarkedArgumentBuffer: introducing MarkedArgumentBufferWithSize which can take default inline capacity as a template parameter. This is used in JSON.stringify to increase the buffer because now we also need to record structures in MarkedArgumentBuffer. This offers 0.4% improvement in Speedometer2 (EmberJS-TodoMVC, Vanilla-XXX, EmberJS-Debug-TodoMVC, they have enough amount of JSON.stringify time). ---------------------------------------------------------------------------------------------------------------------------------- | subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) | ---------------------------------------------------------------------------------------------------------------------------------- | Elm-TodoMVC |117.710000 |117.751667 |1.000354 | 0.883246 | | VueJS-TodoMVC |24.500000 |24.311667 |0.992313 | 0.365130 | | EmberJS-TodoMVC |126.646667 |125.738333 |0.992828 | 0.002587 (significant) | | BackboneJS-TodoMVC |47.873333 |47.911667 |1.000801 | 0.762509 | | Preact-TodoMVC |17.020000 |17.070000 |1.002938 | 0.786799 | | AngularJS-TodoMVC |129.856667 |129.353333 |0.996124 | 0.177632 | | Vanilla-ES2015-TodoMVC |61.698333 |61.120000 |0.990626 | 0.000003 (significant) | | Inferno-TodoMVC |62.840000 |62.496667 |0.994536 | 0.312340 | | Flight-TodoMVC |77.095000 |76.936667 |0.997946 | 0.702724 | | Angular2-TypeScript-TodoMVC |39.740000 |39.191667 |0.986202 | 0.053485 | | VanillaJS-TodoMVC |49.008333 |48.346667 |0.986499 | 0.000638 (significant) | | jQuery-TodoMVC |216.785000 |217.188333 |1.001861 | 0.270747 | | EmberJS-Debug-TodoMVC |344.230000 |342.993333 |0.996407 | 0.012262 (significant) | | React-TodoMVC |85.461667 |85.411667 |0.999415 | 0.758049 | | React-Redux-TodoMVC |140.681667 |140.640000 |0.999704 | 0.871277 | | Vanilla-ES2015-Babel-Webpack-TodoMVC |59.928333 |59.351667 |0.990377 | 0.000000 (significant) | ---------------------------------------------------------------------------------------------------------------------------------- a mean = 264.40650 b mean = 265.51533 pValue = 0.0005567357 (Bigger means are better.) 1.004 times better Results ARE significant * heap/Heap.cpp: (JSC::Heap::addCoreConstraints): * heap/Heap.h: * heap/HeapInlines.h: * runtime/ArgList.cpp: (JSC::MarkedArgumentBufferBase::addMarkSet): (JSC::MarkedArgumentBufferBase::markLists): (JSC::MarkedArgumentBufferBase::slowEnsureCapacity): (JSC::MarkedArgumentBufferBase::expandCapacity): (JSC::MarkedArgumentBufferBase::slowAppend): (JSC::MarkedArgumentBuffer::addMarkSet): Deleted. (JSC::MarkedArgumentBuffer::markLists): Deleted. (JSC::MarkedArgumentBuffer::slowEnsureCapacity): Deleted. (JSC::MarkedArgumentBuffer::expandCapacity): Deleted. (JSC::MarkedArgumentBuffer::slowAppend): Deleted. * runtime/ArgList.h: (JSC::MarkedArgumentBufferWithSize::MarkedArgumentBufferWithSize): (JSC::MarkedArgumentBuffer::MarkedArgumentBuffer): Deleted. (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer): Deleted. (JSC::MarkedArgumentBuffer::size const): Deleted. (JSC::MarkedArgumentBuffer::isEmpty const): Deleted. (JSC::MarkedArgumentBuffer::at const): Deleted. (JSC::MarkedArgumentBuffer::clear): Deleted. (JSC::MarkedArgumentBuffer::appendWithAction): Deleted. (JSC::MarkedArgumentBuffer::append): Deleted. (JSC::MarkedArgumentBuffer::appendWithCrashOnOverflow): Deleted. (JSC::MarkedArgumentBuffer::removeLast): Deleted. (JSC::MarkedArgumentBuffer::last): Deleted. (JSC::MarkedArgumentBuffer::takeLast): Deleted. (JSC::MarkedArgumentBuffer::ensureCapacity): Deleted. (JSC::MarkedArgumentBuffer::hasOverflowed): Deleted. (JSC::MarkedArgumentBuffer::overflowCheckNotNeeded): Deleted. (JSC::MarkedArgumentBuffer::fill): Deleted. (JSC::MarkedArgumentBuffer::slotFor const): Deleted. (JSC::MarkedArgumentBuffer::mallocBase): Deleted. (JSC::MarkedArgumentBuffer::setNeedsOverflowCheck): Deleted. (JSC::MarkedArgumentBuffer::clearNeedsOverflowCheck): Deleted. * runtime/JSONObject.cpp: (JSC::Stringifier::Holder::hasFastObjectProperties const): (JSC::Stringifier::appendStringifiedValue): (JSC::Stringifier::Holder::Holder): (JSC::Stringifier::Holder::appendNextProperty): * runtime/ObjectConstructorInlines.h: (JSC::canPerformFastPropertyEnumerationForJSONStringify): 2021-09-17 Ross Kirsling Unreviewed fix for JSCOnly build with ENABLE_DFG_JIT off. * b3/testb3_1.cpp: * wasm/WasmEntryPlan.cpp: * wasm/WasmLLIntPlan.cpp: * wasm/WasmOperations.cpp: * wasm/WasmSignature.cpp: * wasm/WasmSignature.h: * wasm/generateWasmOpsHeader.py: * wasm/js/JSToWasm.h: 2021-09-17 Angelos Oikonomopoulos Unbreak GCC_OFFLINEASM_SOURCE_MAP when LTO is in use https://bugs.webkit.org/show_bug.cgi?id=230061 Reviewed by Michael Catanzaro. Our ASM postprocessing hack is incompatible with LTO. Unconditionally disable LTO for LowLevelInterpreter.cxx when GCC_OFFLINEASM_SOURCE_MAP is in use. * CMakeLists.txt: 2021-09-17 Justin Michaud Improve access case printing and show inline capacity for structures https://bugs.webkit.org/show_bug.cgi?id=230357 Reviewed by Saam Barati. This just makes the printing of access cases slightly more readable. * bytecode/AccessCase.cpp: (JSC::AccessCase::dump const): * bytecode/AccessCase.h: (JSC::AccessCase::dumpImpl const): * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::dumpImpl const): * bytecode/GetterSetterAccessCase.h: * bytecode/InstanceOfAccessCase.cpp: (JSC::InstanceOfAccessCase::dumpImpl const): * bytecode/InstanceOfAccessCase.h: * bytecode/ProxyableAccessCase.cpp: (JSC::ProxyableAccessCase::dumpImpl const): * bytecode/ProxyableAccessCase.h: * heap/Heap.cpp: (JSC::Heap::runEndPhase): * runtime/JSCJSValue.cpp: (JSC::JSValue::dumpInContextAssumingStructure const): * runtime/Structure.cpp: (JSC::Structure::dump const): 2021-09-17 Justin Michaud PutByVal and PutPrivateName ICs should emit a write barrier if a butterfly might be allocated https://bugs.webkit.org/show_bug.cgi?id=230378 Reviewed by Yusuke Suzuki. Right now, PutByVal and PutPrivateName check the value type to determine if a write barrier is needed. For example, putting a primitive is considered to not require a write barrier. This makes sense, except for the case when we might allocate or re-allocate a butterfly in the IC. This does not emit a write barrier, and so the GC might miss the new butterfly. That is somewhat undesirable. This is a temporary conservative fix. If we don't write to the butterfly pointer, then we still don't need a write barrier; this work is captured by https://bugs.webkit.org/show_bug.cgi?id=230377 * dfg/DFGStoreBarrierInsertionPhase.cpp: 2021-09-16 Saam Barati Don't throw an exception in the middle of linking a CodeBlock https://bugs.webkit.org/show_bug.cgi?id=230367 Reviewed by Yusuke Suzuki. It's cleaner, and probably more correct, to wait until we're done linking the instruction stream before throwing any exceptions from CodeBlock::finishCreation. This guarantees, for example, that all metadata structs are initialized. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::setConstantRegisters): (JSC::CodeBlock::initializeTemplateObjects): * bytecode/CodeBlock.h: * runtime/JSScope.cpp: (JSC::abstractAccess): (JSC::JSScope::abstractResolve): 2021-09-16 Saam Barati Move some profiling to UnlinkedCodeBlock https://bugs.webkit.org/show_bug.cgi?id=230078 Reviewed by Yusuke Suzuki. This patch adds UnlinkedValueProfile and UnlinkedArrayProfile to UnlinkedCodeBlock. These profiles serialize the data in ValueProfile and ArrayProfile. Each time a CodeBlock updates value profiles, it mixes in up to date information from the unlinked profiles, and also writes back data to the unlinked profiles, so the data is shared between CodeBlocks of the same UnlinkedCodeBlock. This patch also fixes a pre-existing bug where we would sometimes think we had more metadata table entries than we really had in practice. This is because MetadataTable::forEach used the next opcode's start pointer. That pointer was aligned to that opcode's metadata alignment. So that might make the previous opcode think it had an extra 1-7 entries (depending on size, alignment, etc). This patch fixes that by having the next opcode's start offset in the table always be the end offset of the previous opcode, and we align the start pointer when using it. This was measured as a ~0.5% speedup on Speedometer2. * bytecode/ArrayProfile.h: (JSC::UnlinkedArrayProfile::update): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::updateAllValueProfilePredictionsAndCountLiveness): (JSC::CodeBlock::updateAllArrayProfilePredictions): (JSC::CodeBlock::updateAllArrayPredictions): * bytecode/CodeBlock.h: (JSC::CodeBlock::metadata): * bytecode/CodeBlockInlines.h: (JSC::CodeBlock::forEachArrayProfile): Deleted. * bytecode/MetadataTable.cpp: (JSC::DeallocTable::withOpcodeType): * bytecode/MetadataTable.h: (JSC::MetadataTable::get): (JSC::MetadataTable::forEach): (JSC::MetadataTable::getWithoutAligning): (JSC::MetadataTable::getImpl): Deleted. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::allocateSharedProfiles): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::unlinkedValueProfile): (JSC::UnlinkedCodeBlock::unlinkedArrayProfile): * bytecode/UnlinkedCodeBlockGenerator.cpp: (JSC::UnlinkedCodeBlockGenerator::finalize): * bytecode/UnlinkedMetadataTable.cpp: (JSC::UnlinkedMetadataTable::finalize): * bytecode/UnlinkedMetadataTable.h: (JSC::UnlinkedMetadataTable::isFinalized): (JSC::UnlinkedMetadataTable::hasMetadata): * bytecode/UnlinkedMetadataTableInlines.h: (JSC::UnlinkedMetadataTable::numEntries): * bytecode/ValueProfile.h: (JSC::UnlinkedValueProfile::update): * bytecompiler/BytecodeGenerator.h: * llint/LowLevelInterpreter.asm: * runtime/CachedTypes.cpp: (JSC::CachedCodeBlock::numValueProfiles const): (JSC::CachedCodeBlock::numArrayProfiles const): (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::CachedCodeBlock::encode): 2021-09-16 Commit Queue Unreviewed, reverting r282478. https://bugs.webkit.org/show_bug.cgi?id=230358 Reverted changeset: "Move some profiling to UnlinkedCodeBlock" https://bugs.webkit.org/show_bug.cgi?id=230078 https://commits.webkit.org/r282478 2021-09-16 Mikhail R. Gadelha Fix crash in 32 bits due to not enough scratch registers available https://bugs.webkit.org/show_bug.cgi?id=230241 Reviewed by Filip Pizlo. Since patch 229229 (Polymorphic PutByVal) landed, jsc is now reaching the case Transition in `AccessCase::generateImpl` which needs three scratch registers when reallocating, but in ARMv7/MIPS, there are only two registers available. So in this patch, `AccessCase::createTransition` is changed to actually check if there are enough registers available before creating the AccessCase object. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): 2021-09-15 Saam Barati Move some profiling to UnlinkedCodeBlock https://bugs.webkit.org/show_bug.cgi?id=230078 Reviewed by Yusuke Suzuki. This patch moves ValueProfiles and ArrayProfiles for non-call opcodes into UnlinkedCodeBlock. This way, the data is shared between the linked CodeBlocks of the same UnlinkedCodeBlock. The profiling bet here is that when the same code runs in a different global object, it largely runs in the same way. We've made this same bet in other ways with our profiling, and it largely makes sense to do for ValueProfile and ArrayProfile since they both hold global object independent data. Because ArrayProfiles are now shared between CodeBlocks, the existing m_usesOriginalArrayStructures bit is slightly harder to track now, since the ArrayProfile may see inputs from a different global object, an array may be an original array in one lexical global object, but not another. So we now track when an ArrayProfile sees a different global object than the lexical global object, and when we observe exits in the DFG, we propagate that bit to the m_usesOriginalArrayStructures bit. This patch also makes it so we no longer hold the CodeBlock lock when processing ValueProfiles and ArrayProfiles. We now allow multiple compiler threads to race against each other when updating these profiles. This is fine. It may end up with incomplete data in the profiles, but it won't corrupt them. This patch also makes it so we finalized visited UnlinkedCodeBlocks to finalize their value profiles. We no longer do that work inside CodeBlock for the ValueProfiles that UnlinkedCodeBlock owns. This also means that we have to WriteBarrier UnlinkedCodeBlock when executing in the LLInt, Baseline, and other areas, such as OSR exit, and in the GC when a CodeBlock was executing. That way we're guaranteed to visit the UnlinkedCodeBlock, add it to the visited set, and then finalize it at the end of GC. This patch also makes it so that inside CodeBlock::finishCreation, we finish linking before we do anything that can throw an exception. It's not valid to finalize a CodeBlock that isn't linked. This was measured as a 0.5-1% speedup on Speedometer2. * bytecode/ArrayProfile.cpp: (JSC::ArrayProfile::computeUpdatedPrediction): (JSC::ArrayProfile::briefDescription): (JSC::ArrayProfile::briefDescriptionWithoutUpdating): * bytecode/ArrayProfile.h: (JSC::ArrayProfile::ArrayProfile): (JSC::ArrayProfile::observedArrayModes const): (JSC::ArrayProfile::mayInterceptIndexedAccesses const): (JSC::ArrayProfile::mayStoreToHole const): (JSC::ArrayProfile::outOfBounds const): (JSC::ArrayProfile::usesOriginalArrayStructures const): (JSC::ArrayProfile::setDoesNotUseOriginalArrayStructures): (JSC::ArrayProfile::observedDifferentGlobalObject const): * bytecode/BytecodeList.rb: * bytecode/BytecodeOperandsForCheckpoint.h: (JSC::valueProfileForImpl): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::setConstantRegisters): (JSC::CodeBlock::initializeTemplateObjects): (JSC::CodeBlock::setNumParameters): (JSC::CodeBlock::visitChildren): (JSC::CodeBlock::finalizeUnconditionally): (JSC::CodeBlock::getArrayProfile): (JSC::CodeBlock::updateAllValueProfilePredictionsAndCountLiveness): (JSC::CodeBlock::updateAllArrayPredictions): (JSC::CodeBlock::tryGetValueProfileForBytecodeIndex): (JSC::CodeBlock::valueProfilePredictionForBytecodeIndex): * bytecode/CodeBlock.h: (JSC::CodeBlock::offsetOfUnlinkedCodeBlock): (JSC::CodeBlock::numberOfArgumentValueProfiles): (JSC::CodeBlock::valueProfileForArgument): (JSC::CodeBlock::metadata): * bytecode/CodeBlockInlines.h: (JSC::CodeBlock::forEachValueProfile): (JSC::CodeBlock::forEachArrayProfile): * bytecode/DFGExitProfile.cpp: (JSC::DFG::ExitProfile::hasAnyExitsAt const): * bytecode/DFGExitProfile.h: * bytecode/GetByIdMetadata.h: (JSC::GetByIdModeMetadata::setArrayLengthMode): * bytecode/LazyOperandValueProfile.cpp: (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions): (JSC::LazyOperandValueProfileParser::prediction const): * bytecode/MetadataTable.cpp: (JSC::DeallocTable::withOpcodeType): * bytecode/MetadataTable.h: (JSC::MetadataTable::get): (JSC::MetadataTable::forEach): (JSC::MetadataTable::getWithoutAligning): (JSC::MetadataTable::getImpl): Deleted. * bytecode/Opcode.h: * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::visitChildrenImpl): (JSC::UnlinkedCodeBlock::allocateSharedProfiles): (JSC::UnlinkedCodeBlock::finalizeUnconditionally): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::hasAnyExitsAt const): (JSC::UnlinkedCodeBlock::hasAnyExitsAt): (JSC::UnlinkedCodeBlock::valueProfile): (JSC::UnlinkedCodeBlock::arrayProfile): (JSC::UnlinkedCodeBlock::numValueProfiles const): (JSC::UnlinkedCodeBlock::numArrayProfiles const): * bytecode/UnlinkedCodeBlockGenerator.cpp: (JSC::UnlinkedCodeBlockGenerator::finalize): * bytecode/UnlinkedMetadataTable.cpp: (JSC::UnlinkedMetadataTable::finalize): * bytecode/UnlinkedMetadataTable.h: (JSC::UnlinkedMetadataTable::isFinalized): (JSC::UnlinkedMetadataTable::hasMetadata): * bytecode/UnlinkedMetadataTableInlines.h: (JSC::UnlinkedMetadataTable::numEntries): * bytecode/ValueProfile.h: (JSC::ValueProfileBase::ValueProfileBase): (JSC::ValueProfileBase::clearBuckets): (JSC::ValueProfileBase::briefDescription): (JSC::ValueProfileBase::computeUpdatedPrediction): (JSC::ValueProfile::offsetOfFirstBucket): (JSC::ValueProfileBase::classInfo const): Deleted. * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::fromObserved): * dfg/DFGArrayMode.h: (JSC::DFG::ArrayMode::withSpeculationFromProfile const): (JSC::DFG::ArrayMode::withProfile const): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): (JSC::DFG::ByteCodeParser::getArrayMode): (JSC::DFG::ByteCodeParser::handleVarargsInlining): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::handlePutByVal): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength): * dfg/DFGGraph.h: * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::osrWriteBarrier): (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * heap/CodeBlockSetInlines.h: (JSC::CodeBlockSet::iterateViaSubspaces): * heap/Heap.cpp: (JSC::Heap::finalizeMarkedUnconditionalFinalizers): (JSC::Heap::finalizeUnconditionalFinalizers): (JSC::Heap::deleteUnmarkedCompiledCode): (JSC::Heap::runEndPhase): (JSC::Heap::addCoreConstraints): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::emitValueProfilingSiteIfProfiledOpcode): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_enter): (JSC::JIT::op_enter_handlerGenerator): * jit/JITOperations.cpp: (JSC::putByValOptimize): (JSC::directPutByValOptimize): (JSC::JSC_DEFINE_JIT_OPERATION): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::generateGetByValSlowCase): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_in_by_val): (JSC::JIT::emitSlow_op_in_by_val): (JSC::JIT::generateOpGetFromScopeThunk): (JSC::JIT::slow_op_get_from_scopeGenerator): (JSC::JIT::emit_op_enumerator_get_by_val): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_in_by_val): (JSC::JIT::emitSlow_op_in_by_val): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::performLLIntGetByID): (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::getByVal): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::BytecodeSequence): * runtime/CachedTypes.cpp: (JSC::CachedCodeBlock::numValueProfiles const): (JSC::CachedCodeBlock::numArrayProfiles const): (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::CachedCodeBlock::encode): * runtime/CommonSlowPaths.cpp: (JSC::iteratorNextTryFastImpl): (JSC::JSC_DEFINE_COMMON_SLOW_PATH): * runtime/JSScope.cpp: (JSC::abstractAccess): (JSC::JSScope::abstractResolve): * runtime/VM.cpp: * runtime/VM.h: (JSC::VM::forEachUnlinkedCodeBlockSpace): (JSC::VM::forEachCodeBlockSpace): Deleted. 2021-09-15 Michael Catanzaro Avoid GCC warnings introduced in r282125 https://bugs.webkit.org/show_bug.cgi?id=230154 Reviewed by Fujii Hironori. Yusuke suggested casting to UChar to avoid -Wswitch-out-of-range. This works! Also, avoid -Wredundant-move by removing one unnecessary WTFMove. * runtime/ISO8601.cpp: (JSC::ISO8601::parseTimeZoneBracketedAnnotation): (JSC::ISO8601::canBeTimeZone): (JSC::ISO8601::parseTimeZone): 2021-09-15 Yusuke Suzuki [JSC] Optimize leaf object creation in JSON.parse https://bugs.webkit.org/show_bug.cgi?id=230298 Reviewed by Keith Miller. This patch optimizes JSON.parse. 1. Use table in isJSONWhiteSpace. 2. Extract primitive value creation as parsePrimitiveValue function to use it in different place. 3. Add leaf-object creation fast path. Previously, when creating a leaf-object from JSON.parse we are too generic and jumping around the code. Instead we add a fast path that does not perform unnecessary operations and code gets tight. It offers 3-4% improvement in microbenchmarks. ToT Patched vanilla-es2015-babel-webpack-todomvc-json-parse 104.7169+-0.1113 ^ 101.4836+-0.2168 ^ definitely 1.0319x faster flight-todomvc-json-parse 53.9074+-0.0957 ^ 52.1347+-0.0802 ^ definitely 1.0340x faster vanilla-es2015-todomvc-json-parse 104.9373+-0.1631 ^ 101.4978+-0.1073 ^ definitely 1.0339x faster vanilla-todomvc-json-parse 79.1330+-0.0963 ^ 76.7568+-0.1606 ^ definitely 1.0310x faster This offers 0.2% improvement in Speedometer2. ---------------------------------------------------------------------------------------------------------------------------------- | subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) | ---------------------------------------------------------------------------------------------------------------------------------- | Elm-TodoMVC |116.860000 |116.825000 |0.999700 | 0.901070 | | VueJS-TodoMVC |24.658333 |24.763333 |1.004258 | 0.571728 | | EmberJS-TodoMVC |126.666667 |126.335000 |0.997382 | 0.289517 | | BackboneJS-TodoMVC |48.435000 |48.523333 |1.001824 | 0.455638 | | Preact-TodoMVC |17.585000 |17.368333 |0.987679 | 0.247658 | | AngularJS-TodoMVC |129.576667 |129.398333 |0.998624 | 0.625634 | | Vanilla-ES2015-TodoMVC |62.746667 |62.241667 |0.991952 | 0.000019 (significant) | | Inferno-TodoMVC |63.741667 |63.495000 |0.996130 | 0.448861 | | Flight-TodoMVC |78.021667 |77.306667 |0.990836 | 0.087137 | | Angular2-TypeScript-TodoMVC |39.823333 |39.923333 |1.002511 | 0.736279 | | VanillaJS-TodoMVC |50.073333 |49.791667 |0.994375 | 0.136495 | | jQuery-TodoMVC |221.300000 |221.586667 |1.001295 | 0.418008 | | EmberJS-Debug-TodoMVC |340.145000 |339.965000 |0.999471 | 0.691490 | | React-TodoMVC |85.698333 |85.650000 |0.999436 | 0.761586 | | React-Redux-TodoMVC |140.510000 |140.785000 |1.001957 | 0.285922 | | Vanilla-ES2015-Babel-Webpack-TodoMVC |60.928333 |60.500000 |0.992970 | 0.000069 (significant) | ---------------------------------------------------------------------------------------------------------------------------------- a mean = 262.15844 b mean = 262.72261 pValue = 0.0428052487 (Bigger means are better.) 1.002 times better Results ARE significant * runtime/LiteralParser.cpp: (JSC::LiteralParser::makeIdentifier): (JSC::isJSONWhiteSpace): (JSC::LiteralParser::Lexer::lex): (JSC::LiteralParser::parsePrimitiveValue): (JSC::LiteralParser::parse): * runtime/LiteralParser.h: 2021-09-14 Don Olmstead Non-unified build fixes, mid September 2021 edition https://bugs.webkit.org/show_bug.cgi?id=230110 Unreviewed non-unified build fixes. * runtime/TemporalPlainTimeConstructor.cpp: * runtime/TemporalPlainTimePrototype.cpp: 2021-09-14 Ross Kirsling [Win] JSRemoteInspector.h missing stdint include https://bugs.webkit.org/show_bug.cgi?id=230275 Reviewed by Don Olmstead. * API/JSRemoteInspector.h: Include stdint for uint8_t definition on Windows. 2021-09-14 Xan Lopez [JSC] Remove unnecessary exception checks in DFGOperations https://bugs.webkit.org/show_bug.cgi?id=230247 Reviewed by Caio Araujo Neponoceno de Lima. JSValue::decode cannot throw an exception, remove a couple of unnecessary RETURN_IF_EXCEPTION() calls. * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): 2021-09-14 Xan López [JSC] ASSERT failed in stress/for-in-tests.js (32bit) https://bugs.webkit.org/show_bug.cgi?id=229543 Reviewed by Yusuke Suzuki. Since r280760 DFG::SpeculativeJIT::compileEnumeratorGetByVal uses too many registers for 32bit. Revert to the slow path as a temporary measure to avoid crashes, we'll try to reenable the optimizations later on (see bug #230189). * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): define a generic call operation for compileEnumeratorGetByVal. * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: move the current version of compileEnumeratorGetByVal to 64bit, since it won't work on 32bit. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compileEnumeratorGetByVal): call the generic call op always. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileEnumeratorGetByVal): use the previous version here. * runtime/CommonSlowPaths.cpp: (JSC::JSC_DEFINE_COMMON_SLOW_PATH): refactor a bit the slow path for enumeratorGetByVal so it can be called from DFG as a call operation. * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::opEnumeratorGetByVal): 2021-09-13 Xan López [JSC][32bit] in-by-val fails inside for-in loop after delete https://bugs.webkit.org/show_bug.cgi?id=230150 Reviewed by Carlos Garcia Campos. The order of payload and tag was reversed when constructing the base value for compileEnumeratorHasProperty. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileEnumeratorHasProperty): 2021-09-10 Stephan Szabo [PlayStation] Support running applications with ENABLE_STATIC_JSC=ON https://bugs.webkit.org/show_bug.cgi?id=230170 Reviewed by Ross Kirsling. Updating loading code to not load libJavaScriptCore shared library if we are using a static version. * shell/playstation/Initializer.cpp: 2021-09-09 Ross Kirsling [JSC] Clean up current state of Temporal API https://bugs.webkit.org/show_bug.cgi?id=230130 Reviewed by Yusuke Suzuki. This patch perfoms a variety of cleanup tasks following the implementation of Temporal.PlainTime. 1. Do away with the alias Subdurations and refer to ISO8601::Duration directly. (But we can still say "subduration" when referring to a single ordered field, as in `largestSubduration`.) 2. Represent ToTemporalDuration, ToTemporalDurationRecord, and ToLimitedTemporalDuration more directly in code, as TemporalDuration::{toTemporalDuration, fromDurationLike, toISO8601Duration}. (Note: The last of these doesn't take a disallowedFields parameter; Temporal.Instant can do this after the fact, since no one else makes use of this functionality.) 3. Extract intlOption into a helper function, `temporalRoundingMode`. 4. Remove largestSubplainTime(), which was declared but not defined. 5. Correct spelling of TemporalPlainTime::constrainTime(). * runtime/TemporalDuration.cpp: (JSC::TemporalDuration::create): (JSC::TemporalDuration::TemporalDuration): (JSC::TemporalDuration::tryCreateIfValid): (JSC::TemporalDuration::fromDurationLike): Added. (JSC::TemporalDuration::toISO8601Duration): Added. (JSC::TemporalDuration::toTemporalDuration): Added. (JSC::TemporalDuration::from): (JSC::totalNanoseconds): (JSC::TemporalDuration::compare): (JSC::TemporalDuration::sign): (JSC::TemporalDuration::with const): (JSC::TemporalDuration::negated const): (JSC::TemporalDuration::abs const): (JSC::largestSubduration): Added. (JSC::TemporalDuration::balance): (JSC::TemporalDuration::add const): (JSC::TemporalDuration::subtract const): (JSC::TemporalDuration::round): (JSC::TemporalDuration::round const): (JSC::TemporalDuration::total const): (JSC::TemporalDuration::toString const): (JSC::TemporalDuration::toString): (JSC::TemporalDuration::fromNonDurationValue): Deleted. (JSC::TemporalDuration::toDuration): Deleted. (JSC::TemporalDuration::toDurationRecord): Deleted. (JSC::TemporalDuration::largestSubduration const): Deleted. * runtime/TemporalDuration.h: * runtime/TemporalDurationConstructor.cpp: * runtime/TemporalDurationPrototype.cpp: * runtime/TemporalObject.cpp: (JSC::temporalRoundingMode): Added. * runtime/TemporalObject.h: * runtime/TemporalPlainTime.cpp: (JSC::TemporalPlainTime::round const): (JSC::TemporalPlainTime::toString const): (JSC::constrainTime): Added. (JSC::regulateTime): (JSC::TemporalPlainTime::add const): (JSC::TemporalPlainTime::subtract const): (JSC::extractDifferenceOptions): (JSC::constraintTime): Deleted. (JSC::toLimitedTemporalDuration): Deleted. * runtime/TemporalPlainTime.h: 2021-09-09 Yusuke Suzuki [JSC] Intl.Locale weekendInfo should list all weekend days instead of range https://bugs.webkit.org/show_bug.cgi?id=230108 Reviewed by Ross Kirsling. We cannot assume that weekend is contiguous. For example, Burnei's weekend is Friday and Sunday. This is raised in [1], and our conclusion in Sep-9 meeting is that we should have an array which includes all the weekend days. The change is merged in [2], and this patch changes our implementation accordingly. [1]: https://github.com/tc39/proposal-intl-locale-info/issues/25 [2]: https://github.com/tc39/proposal-intl-locale-info/commit/afb1e269dd698476a2514129235cdad88af60e6f * runtime/IntlLocale.cpp: (JSC::IntlLocale::weekInfo): * runtime/IntlObjectInlines.h: (JSC::createArrayFromIntVector): 2021-09-09 Darin Adler Improve performance by using StringView, not "const StringView&" https://bugs.webkit.org/show_bug.cgi?id=229834 Reviewed by Anders Carlsson. * parser/Lexer.h: * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::setFormatsFromPattern): * runtime/IntlDateTimeFormat.h: Use StringView, not const StringView&. 2021-09-09 Yusuke Suzuki [JSC] Optimize op_get_property_enumerator further https://bugs.webkit.org/show_bug.cgi?id=230086 Reviewed by Saam Barati. 1. This patch adds fast path of op_get_property_enumerator to LLInt and Baseline. Previously, we only had this fast path in DFG and FTL. 2. From the profiled data, Speedometer2/React-Redux-TodoMVC has GetPropertyEnumerator(CellOrOther). However, DFG and FTL only optimized GetPropertyEnumerator(Cell). We add CellOrOther and Other cases: if the argument is Other, then we can constant fold it to the empty enumerator. If the argument is CellOrOther, we can check first, and return empty enumerator for Other case. 3. This patch also cleans up StructureRareData lookup by introducing StructureType to JSType. ---------------------------------------------------------------------------------------------------------------------------------- | subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) | ---------------------------------------------------------------------------------------------------------------------------------- | Elm-TodoMVC |117.388333 |117.680000 |1.002485 | 0.269607 | | VueJS-TodoMVC |24.918333 |24.651667 |0.989298 | 0.157665 | | EmberJS-TodoMVC |126.430000 |126.296667 |0.998945 | 0.673803 | | BackboneJS-TodoMVC |48.695000 |48.411667 |0.994181 | 0.019164 | | Preact-TodoMVC |17.268333 |17.511667 |1.014091 | 0.199775 | | AngularJS-TodoMVC |130.246667 |129.850000 |0.996954 | 0.261543 | | Vanilla-ES2015-TodoMVC |63.626667 |63.611667 |0.999764 | 0.912112 | | Inferno-TodoMVC |63.881667 |63.600000 |0.995591 | 0.385440 | | Flight-TodoMVC |78.158333 |78.606667 |1.005736 | 0.284177 | | Angular2-TypeScript-TodoMVC |39.448333 |39.411667 |0.999071 | 0.890825 | | VanillaJS-TodoMVC |50.858333 |51.130000 |1.005342 | 0.195409 | | jQuery-TodoMVC |225.318333 |226.256667 |1.004164 | 0.011190 | | EmberJS-Debug-TodoMVC |340.150000 |338.450000 |0.995002 | 0.000063 (significant) | | React-TodoMVC |85.703333 |85.606667 |0.998872 | 0.549298 | | React-Redux-TodoMVC |141.985000 |140.418333 |0.988966 | 0.000000 (significant) | | Vanilla-ES2015-Babel-Webpack-TodoMVC |61.505000 |61.705000 |1.003252 | 0.079817 | ---------------------------------------------------------------------------------------------------------------------------------- a mean = 260.98021 b mean = 261.16020 pValue = 0.4985041089 (Bigger means are better.) 1.001 times better Results ARE NOT significant * bytecode/SpeculatedType.cpp: (JSC::dumpSpeculation): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetPropertyEnumerator): (JSC::DFG::SpeculativeJIT::compileObjectKeysOrObjectGetOwnPropertyNames): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileObjectKeysOrObjectGetOwnPropertyNames): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchIfStructure): (JSC::AssemblyHelpers::branchIfNotStructure): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_property_enumerator): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_property_enumerator): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/BrandedStructure.cpp: (JSC::BrandedStructure::create): * runtime/JSType.cpp: (WTF::printInternal): * runtime/JSType.h: * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::create): * runtime/Structure.h: (JSC::Structure::isRareData): (JSC::Structure::isRareData const): Deleted. * runtime/StructureInlines.h: (JSC::Structure::create): (JSC::Structure::createStructure): * runtime/StructureRareData.h: * runtime/VM.cpp: (JSC::VM::VM): 2021-09-09 Patrick Angle run-webkit-archive crashes with dyld error https://bugs.webkit.org/show_bug.cgi?id=228060 Reviewed by Alex Christensen. Add a compatibility symbol for the old `WTF::Optional` version of `BackendDispatcher::reportProtocolError` in versions of Safari shipping with macOS Big Sur and earlier. This has the side effect of not surfacing protocol errors and instead silently discarding them when crossing this API boundary. Newer versions of macOS ship using the newer symbol and are therefor not affected and will continue to surface protocol errors to the frontend. * runtime/SymbolStubsForSafariCompatibility.mm: (Inspector::BackendDispatcher::reportProtocolError): 2021-09-09 Justin Michaud Differential testing: incorrect constant propagation around Uint8ClampedArray https://bugs.webkit.org/show_bug.cgi?id=229869 We casted int52 values to int32 before clamping, which caused any value with the 32nd bit set to be interpreted as negative. The fix is to check the full-size value when deciding to clamp. Reviewed by Saam Barati. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): 2021-09-09 Robin Morisset Optimize compareStrictEq when neither side is a double and at least one is not a BigInt https://bugs.webkit.org/show_bug.cgi?id=226755 Reviewed by Yusuke Suzuki. This is a very similar patch to https://bugs.webkit.org/show_bug.cgi?id=226676. The difference is that here we allow Strings on both side of the comparison, so we must add code to handle equality among strings. Like for that other patch, the optimization is disabled for BigInt32. Enabling it in that case would either need modifying the speculation (from banning HeapBigInt to banning all BigInts), or ensuring that we can never have a HeapBigInt so small it compares equal to a BigInt32. I only implemented this optimization on 64-bits: it is just painful to write code that handles registers at such a low-level without a 32-bit machine to test things locally. If anyone wants to make this optimization work on 32-bit, I don't foretell any major difficulty. Finally, like quite a few other useKinds already, this case does not make the CompareStrictEq merge with an adjacent Branch. The reason is simply that this patch relies on compileStringEquality, which currently does not support that feature. I intend to fix this (for all useKinds at once) in a separate patch. Effect on microbenchmarks: poly-stricteq-not-double 46.8000+-0.4110 ^ 23.5872+-0.3061 ^ definitely 1.9841x faster poly-stricteq-not-double-nor-string 16.6880+-0.2317 16.3627+-0.3729 might be 1.0199x faster poly-stricteq 49.2175+-0.6047 48.9532+-0.6758 I looked at how many cases of Untyped/Untyped compareStrictEq have been fixed by this patch and two other recent patches. On JetStream2: - https://bugs.webkit.org/show_bug.cgi?id=226621: 731 instances - https://bugs.webkit.org/show_bug.cgi?id=226676: 944 instances - This patch: only 26 instances This leaves 20 instances of Untyped/Untyped. On Speedometer2.0: - https://bugs.webkit.org/show_bug.cgi?id=226621: 1587 instances - https://bugs.webkit.org/show_bug.cgi?id=226676: 2784 instances - This patch: 891 instances This leaves 75 instances of Untyped/Untyped. * bytecode/SpeculatedType.h: (JSC::isNeitherDoubleNorHeapBigIntSpeculation): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue): * dfg/DFGNode.h: (JSC::DFG::Node::shouldSpeculateNeitherDoubleNorHeapBigInt): * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileStrictEq): (JSC::DFG::SpeculativeJIT::emitBitwiseJSValueEquality): (JSC::DFG::SpeculativeJIT::emitBranchOnBitwiseJSValueEquality): (JSC::DFG::SpeculativeJIT::compileNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigInt): (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileNeitherDoubleNorHeapBigIntToNotDoubleStrictEquality): * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): (JSC::DFG::checkMayCrashIfInputIsEmpty): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): 2021-09-07 Yusuke Suzuki Unreviewed, add files to xcodeproj https://bugs.webkit.org/show_bug.cgi?id=229892 * JavaScriptCore.xcodeproj/project.pbxproj: 2021-09-07 Yusuke Suzuki [JSC] Implement Temporal.PlainTime https://bugs.webkit.org/show_bug.cgi?id=229892 Reviewed by Darin Adler. This patch implements Temporal.PlainTime[1]. This is time representation which is not associated to calendars and timezones. This is tuple of hour, minute, second, millisecond, microsecond, and nanosecond. 1. We add full-fledged ISO8601 DateTime / Time parser, so that Temporal.PlainTime.from can extract time as specified. 2. ISO8601::PlainTime is used for already-validated PlainTime data. When performing arithmetics, we first do that in ISO8601::Duration, and then we validate and convert it to PlainTime. We also found several spec issues, and reported in [2,3,4]. [1]: https://tc39.es/proposal-temporal/#sec-temporal-plaintime-objects [2]: https://github.com/tc39/proposal-temporal/issues/1803 [3]: https://github.com/tc39/proposal-temporal/issues/1804 [4]: https://github.com/tc39/proposal-temporal/issues/1805 * CMakeLists.txt: * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: * DerivedSources.make: * Sources.txt: * runtime/CommonIdentifiers.h: * runtime/ISO8601.cpp: (JSC::ISO8601::parseTimeZoneName): (JSC::ISO8601::parseDecimalInt32): (JSC::ISO8601::parseDuration): (JSC::ISO8601::parseTimeSpec): (JSC::ISO8601::parseTimeZoneNumericUTCOffset): (JSC::ISO8601::parseTimeZoneBracketedAnnotation): (JSC::ISO8601::canBeTimeZone): (JSC::ISO8601::parseTimeZone): (JSC::ISO8601::parseTime): (JSC::ISO8601::daysInMonth): (JSC::ISO8601::parseDate): (JSC::ISO8601::parseDateTime): (JSC::ISO8601::formatTimeZoneOffsetString): (JSC::ISO8601::temporalTimeToString): (JSC::ISO8601::isValidDuration): * runtime/ISO8601.h: (JSC::ISO8601::Duration::Duration): (JSC::ISO8601::Duration::operator[]): (JSC::ISO8601::Duration::operator[] const): (JSC::ISO8601::Duration::begin const): (JSC::ISO8601::Duration::end const): (JSC::ISO8601::Duration::clear): (JSC::ISO8601::Duration::operator- const): (JSC::ISO8601::PlainTime::PlainTime): (JSC::ISO8601::PlainTime::operator==): (JSC::ISO8601::PlainDate::PlainDate): (JSC::ISO8601::PlainDate::year const): (JSC::ISO8601::PlainDate::month const): (JSC::ISO8601::PlainDate::day const): * runtime/IntlObject.cpp: (JSC::utcTimeZoneIDSlow): * runtime/IntlObject.h: (JSC::utcTimeZoneID): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildrenImpl): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::plainTimeStructure): * runtime/TemporalCalendarConstructor.cpp: (JSC::TemporalCalendarConstructor::finishCreation): * runtime/TemporalDuration.cpp: (JSC::TemporalDuration::tryCreateIfValid): (JSC::TemporalDuration::fromNonDurationValue): (JSC::TemporalDuration::toDuration): (JSC::TemporalDuration::toDurationRecord): (JSC::TemporalDuration::toString const): (JSC::TemporalDuration::toString): (JSC::isValidDuration): Deleted. (JSC::TemporalDuration::fromObject): Deleted. * runtime/TemporalDuration.h: * runtime/TemporalNow.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/TemporalObject.cpp: (JSC::createPlainTimeConstructor): (JSC::secondsStringPrecision): (JSC::toTemporalOverflow): * runtime/TemporalObject.h: * runtime/TemporalPlainTime.cpp: Added. (JSC::TemporalPlainTime::create): (JSC::TemporalPlainTime::createStructure): (JSC::TemporalPlainTime::TemporalPlainTime): (JSC::TemporalPlainTime::finishCreation): (JSC::TemporalPlainTime::visitChildrenImpl): (JSC::toPlainTime): (JSC::TemporalPlainTime::tryCreateIfValid): (JSC::nonNegativeModulo): (JSC::balanceTime): (JSC::roundTime): (JSC::TemporalPlainTime::round const): (JSC::TemporalPlainTime::toString const): (JSC::propertyName): (JSC::toTemporalTimeRecord): (JSC::toPartialTime): (JSC::constraintTime): (JSC::regulateTime): (JSC::toTemporalCalendarWithISODefault): (JSC::getTemporalCalendarWithISODefault): (JSC::TemporalPlainTime::from): (JSC::TemporalPlainTime::compare): (JSC::toLimitedTemporalDuration): (JSC::addTime): (JSC::TemporalPlainTime::add const): (JSC::TemporalPlainTime::subtract const): (JSC::TemporalPlainTime::with const): (JSC::differenceTime): (JSC::extractDifferenceOptions): (JSC::TemporalPlainTime::until const): (JSC::TemporalPlainTime::since const): * runtime/TemporalPlainTime.h: Added. * runtime/TemporalPlainTimeConstructor.cpp: Added. (JSC::TemporalPlainTimeConstructor::create): (JSC::TemporalPlainTimeConstructor::createStructure): (JSC::TemporalPlainTimeConstructor::TemporalPlainTimeConstructor): (JSC::TemporalPlainTimeConstructor::finishCreation): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/TemporalPlainTimeConstructor.h: Copied from Source/JavaScriptCore/runtime/TemporalTimeZone.h. * runtime/TemporalPlainTimePrototype.cpp: Added. (JSC::TemporalPlainTimePrototype::create): (JSC::TemporalPlainTimePrototype::createStructure): (JSC::TemporalPlainTimePrototype::TemporalPlainTimePrototype): (JSC::TemporalPlainTimePrototype::finishCreation): (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::JSC_DEFINE_CUSTOM_GETTER): * runtime/TemporalPlainTimePrototype.h: Copied from Source/JavaScriptCore/runtime/TemporalTimeZone.h. * runtime/TemporalTimeZone.cpp: (JSC::TemporalTimeZone::from): (JSC::TemporalTimeZone::idForTimeZoneName): Deleted. * runtime/TemporalTimeZone.h: * runtime/TemporalTimeZoneConstructor.cpp: (JSC::TemporalTimeZoneConstructor::finishCreation): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/VM.cpp: * runtime/VM.h: 2021-09-07 Yusuke Suzuki Math.hypot checks for infinite values prematurely https://bugs.webkit.org/show_bug.cgi?id=229843 Reviewed by Ross Kirsling. According to the spec[1], we should throw an error about non finite argument after coercing all arguments to doubles. [1]: https://tc39.es/ecma262/#sec-math.hypot * runtime/MathObject.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): 2021-09-07 Adrian Perez de Castro Non-unified build fixes, early September 2021 edition https://bugs.webkit.org/show_bug.cgi?id=229983 Unreviewed non-unified build fixes. * runtime/TemporalTimeZone.cpp: Add missing JSObjectInlines.h header. 2021-09-03 Yusuke Suzuki [JSC] Make EnumeratorNextUpdateIndexAndMode clobberizing rule precise https://bugs.webkit.org/show_bug.cgi?id=229898 rdar://82714439 Reviewed by Saam Barati. Clobberizing rule and AI does not match for EnumeratorNextUpdateIndexAndMode node. We fix both cases: isSaneChain is not related to this node. So we should use isInBounds as we are doing for HasIndexedProperty node. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2021-09-03 Ross Kirsling Unreviewed, non-unified JSC build fix following 241222@main. * b3/B3ReduceLoopStrength.h: * jit/JITOperations.h: * wasm/WasmOperations.h: 2021-09-03 Ross Kirsling [JSC] Yarr::ByteTerm sometimes leaves fields uninitialized https://bugs.webkit.org/show_bug.cgi?id=229891 Reviewed by Yusuke Suzuki. * yarr/YarrInterpreter.h: (JSC::Yarr::ByteTerm::ByteTerm): Default initialize `frameLocation` and `inputPosition`. (Also, use initializer list where possible.) 2021-09-03 Yusuke Suzuki [JSC] Implement Temporal.TimeZone https://bugs.webkit.org/show_bug.cgi?id=229703 Reviewed by Ross Kirsling. This patch implements Temporal.TimeZone. While this patch does not implement features which requires Temporal.Instant, we implement the core of Temporal.TimeZone, holding UTC offset or IANA TimeZone ID. This patch implements parsing TimeZoneNumericUTCOffset to populate TimeZone from that format. Since Temporal.TimeZone is implemented, we also support `Temporal.Now.timeZone()`, which returns current system TimeZone. We also fix Intl enumeration not including "UTC". Since it is included in IANA TimeZones, we should include that. * CMakeLists.txt: * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * runtime/ISO8601.cpp: (JSC::ISO8601::parseDecimalInt32): (JSC::ISO8601::handleFraction): (JSC::ISO8601::parseTimeZoneNumericUTCOffset): (JSC::ISO8601::formatTimeZoneOffsetString): * runtime/ISO8601.h: * runtime/IntlObject.cpp: (JSC::isValidTimeZoneNameFromICUTimeZone): (JSC::canonicalizeTimeZoneNameFromICUTimeZone): (JSC::intlAvailableTimeZones): (JSC::availableTimeZones): * runtime/IntlObject.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildrenImpl): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::timeZoneStructure): * runtime/TemporalNow.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/TemporalNow.h: * runtime/TemporalObject.cpp: (JSC::createTimeZoneConstructor): * runtime/TemporalTimeZone.cpp: Added. (JSC::TemporalTimeZone::createFromID): (JSC::TemporalTimeZone::createFromUTCOffset): (JSC::TemporalTimeZone::createStructure): (JSC::TemporalTimeZone::TemporalTimeZone): (JSC::TemporalTimeZone::idForTimeZoneName): (JSC::parseTemporalTimeZoneString): (JSC::TemporalTimeZone::from): * runtime/TemporalTimeZone.h: Copied from Source/JavaScriptCore/runtime/ISO8601.h. * runtime/TemporalTimeZoneConstructor.cpp: Added. (JSC::TemporalTimeZoneConstructor::create): (JSC::TemporalTimeZoneConstructor::createStructure): (JSC::TemporalTimeZoneConstructor::TemporalTimeZoneConstructor): (JSC::TemporalTimeZoneConstructor::finishCreation): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/TemporalTimeZoneConstructor.h: Copied from Source/JavaScriptCore/runtime/ISO8601.h. * runtime/TemporalTimeZonePrototype.cpp: Added. (JSC::TemporalTimeZonePrototype::create): (JSC::TemporalTimeZonePrototype::createStructure): (JSC::TemporalTimeZonePrototype::TemporalTimeZonePrototype): (JSC::TemporalTimeZonePrototype::finishCreation): (JSC::JSC_DEFINE_CUSTOM_GETTER): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/TemporalTimeZonePrototype.h: Copied from Source/JavaScriptCore/runtime/ISO8601.h. * runtime/VM.cpp: * runtime/VM.h: 2021-09-02 Yusuke Suzuki [JSC] Validate JSPropertyNameEnumerator via watchpoints https://bugs.webkit.org/show_bug.cgi?id=229846 Reviewed by Keith Miller. Looked into Elm-TodoMVC sampling profiler data and found that op_get_property_enumerator is taking enough amount of time. And Instruments say validating JSPropertyNameEnumerator via traversing StructureChain is costly. We are caching JSPropertyNameEnumerator only when we meet the condition: objects in prototype chain can ensure identity of property names if structure is not changed. So we can use watchpoint based approach to invalidate JSPropertyNameEnumerator. This patch injects structure transition watchpoints if possible. And when watchpoint is fired, we invalidate JSPropertyNameEnumerator cached in StructureRareData, as if we are ensuring prototype chain condition for the other property accesses. This offers 0.6% improvement in Speedometer2. ---------------------------------------------------------------------------------------------------------------------------------- | subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) | ---------------------------------------------------------------------------------------------------------------------------------- | Elm-TodoMVC |121.971667 |117.725000 |0.965183 | 0.000000 (significant) | | VueJS-TodoMVC |26.246667 |26.035000 |0.991935 | 0.360614 | | EmberJS-TodoMVC |126.196667 |126.653333 |1.003619 | 0.103138 | | BackboneJS-TodoMVC |48.976667 |48.881667 |0.998060 | 0.474106 | | Preact-TodoMVC |20.118333 |20.115000 |0.999834 | 0.989038 | | AngularJS-TodoMVC |131.545000 |130.706667 |0.993627 | 0.015344 (significant) | | Vanilla-ES2015-TodoMVC |63.725000 |63.773333 |1.000758 | 0.706560 | | Inferno-TodoMVC |64.231667 |62.653333 |0.975427 | 0.000000 (significant) | | Flight-TodoMVC |77.223333 |77.690000 |1.006043 | 0.268309 | | Angular2-TypeScript-TodoMVC |39.686667 |39.500000 |0.995296 | 0.499678 | | VanillaJS-TodoMVC |52.321667 |51.973333 |0.993342 | 0.077777 | | jQuery-TodoMVC |224.908333 |225.761667 |1.003794 | 0.022136 | | EmberJS-Debug-TodoMVC |339.858333 |339.886667 |1.000083 | 0.950320 | | React-TodoMVC |86.545000 |86.070000 |0.994512 | 0.001518 (significant) | | React-Redux-TodoMVC |146.010000 |142.855000 |0.978392 | 0.000000 (significant) | | Vanilla-ES2015-Babel-Webpack-TodoMVC |61.411667 |61.456667 |1.000733 | 0.631499 | ---------------------------------------------------------------------------------------------------------------------------------- a mean = 255.96543 b mean = 257.53379 pValue = 0.0000034394 (Bigger means are better.) 1.006 times better Results ARE significant * bytecode/Watchpoint.cpp: * bytecode/Watchpoint.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetPropertyEnumerator): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * runtime/JSPropertyNameEnumerator.h: (JSC::propertyNameEnumerator): * runtime/StructureRareData.h: * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::setCachedPropertyNameEnumerator): (JSC::StructureChainInvalidationWatchpoint::install): (JSC::StructureChainInvalidationWatchpoint::fireInternal): (JSC::StructureRareData::tryCachePropertyNameEnumeratorViaWatchpoint): (JSC::StructureRareData::invalidateWatchpointBasedValidation): * tools/JSDollarVM.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::JSDollarVM::finishCreation): 2021-09-03 Yusuke Suzuki [JSC] Fix WebKitAdditions directory traversal in offlineasm part 2 https://bugs.webkit.org/show_bug.cgi?id=229853 Reviewed by Mark Lam. When DEPLOYMENT_LOCATION is YES, WEBKITADDITIONS_HEADERS_FOLDER_PATH is /usr/local/include/WebKitAdditions. However, since Xcode implicitly changes it to ${SDKROOT}/usr/local/include/WebKitAdditions, we need to pass the path with ${SDKROOT} if this path is used by non-Xcode. In this patch, we replace --use-deployment-location with --webkit-additions-path=path and passing WebKitAdditions path directly from Xcode. We define WK_WEBKITADDITIONS_INSTALL_PATH and WK_WEBKITADDITIONS_HEADERS_FOLDER_PATH in JavaScriptCore/Configurations/Base.xcconfig to populate this variable and pass WK_WEBKITADDITIONS_HEADERS_FOLDER_PATH to the scripts. We also fix offlineasm's path concatenation. It was using +, but this does not work if directory doesn't end with '/'. We should use File.join when concatenating file paths. * Configurations/Base.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: * offlineasm/asm.rb: * offlineasm/generate_offset_extractor.rb: * offlineasm/generate_settings_extractor.rb: * offlineasm/parser.rb: 2021-09-03 Michael Catanzaro Silence more -Wreturn-type warnings https://bugs.webkit.org/show_bug.cgi?id=229858 Unreviewed. * runtime/TemporalDuration.cpp: (JSC::propertyName): * runtime/TemporalObject.cpp: (JSC::roundNumberToIncrement): 2021-09-02 Yusuke Suzuki [JSC] Fix WebKitAdditions directory traversal in offlineasm https://bugs.webkit.org/show_bug.cgi?id=229841 Reviewed by Mark Lam. When DEPLOYMENT_LOCATION is YES, WebKitAdditions directory becomes /usr/local/include/WebKitAdditions. This patch adds --use-deployment-location option to generate_offset_extractor.rb, generate_settings_extractor.rb, and asm.rb. And they pass it to parser to change the include directory. * JavaScriptCore.xcodeproj/project.pbxproj: * offlineasm/asm.rb: * offlineasm/generate_offset_extractor.rb: * offlineasm/generate_settings_extractor.rb: * offlineasm/parser.rb: 2021-09-02 Ross Kirsling [JSC] ScriptExecutable::newCodeBlockFor should handle exceptions more predictably https://bugs.webkit.org/show_bug.cgi?id=229787 Reviewed by Mark Lam. ScriptExecutable::newCodeBlockFor has four codepaths -- one for each of EvalExecutable, ProgramExecutable, ModuleProgramExecutable, and FunctionExecutable. These all end up in bool CodeBlock::finishCreation(...), but the first three overwrite the current exception with an OOM error while the last does not. Furthermore, newCodeBlockFor handles exceptions via an out param, which is then returned by its single caller, prepareForExecutionImpl. Altogether, this results in some questionable checking of the returned exception against throwScope.exception() at prepareForExecution's callsites in Interpreter and elsewhere. This patch aims to make this exception handling clearer and more consistent by: 1. not overwriting an existing exception with an OOM error 2. doing away with the out param in favor of RETURN_IF_EXCEPTION * bytecode/CodeBlock.h: (JSC::ScriptExecutable::prepareForExecution): * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * interpreter/Interpreter.cpp: (JSC::Interpreter::executeProgram): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): (JSC::Interpreter::execute): (JSC::Interpreter::executeModuleProgram): * interpreter/InterpreterInlines.h: (JSC::Interpreter::execute): * jit/JITOperations.cpp: (JSC::JSC_DEFINE_JIT_OPERATION): (JSC::virtualForWithFunction): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::setUpCall): * runtime/ScriptExecutable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): (JSC::ScriptExecutable::prepareForExecutionImpl): * runtime/ScriptExecutable.h: 2021-09-02 Mikhail R. Gadelha Fix IndexedDoubleStore InlineAccess for 32 bits https://bugs.webkit.org/show_bug.cgi?id=229772 Reviewed by Caio Araujo Neponoceno de Lima. In IndexedDoubleStore inline access, the path if the value is NaN is only being handled in 64 bits, thus introducing some wrong results in 32 bits. This patch fixes: stress/double-add-sub-mul-can-produce-nan.js stress/pow-stable-results.js stress/math-pow-stable-results.js * bytecode/AccessCase.cpp: (JSC::AccessCase::generateWithGuard): 2021-09-02 Ross Kirsling [JSC] Fix invalid exception checks in Temporal classes https://bugs.webkit.org/show_bug.cgi?id=229793 Reviewed by Yusuke Suzuki. * runtime/TemporalCalendarPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/TemporalDuration.cpp: (JSC::TemporalDuration::fromObject): (JSC::TemporalDuration::toDuration): (JSC::TemporalDuration::with const): * runtime/TemporalDurationPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): 2021-09-02 Yusuke Suzuki Unreviewed, annotate executeJSCJITProbe with REFERENCED_FROM_ASM WTF_INTERNAL * assembler/ProbeContext.h: 2021-09-02 Mark Lam Add more support for JIT operation validation testing. https://bugs.webkit.org/show_bug.cgi?id=229534 rdar://81526335 Reviewed by Saam Barati. 1. Added a JITOperationValidation.h to tidy up the code for supporting JIT operation validation. 2. Introduce a JITOperationAnnotation struct to record JIT operation function pointers, with an extra pointer field for a validation test function. 3. Changed JSC_ANNOTATE_JIT_OPERATION to capture a JITOperationAnnotation struct instead of just a single operation pointer. 4. Converted the static addPointers() function in JITOperationList.cpp into a member function of JITOperationList. This allows for the code to be more terse, as well as enables the use of an inverse map mechanism on debug builds only. 5. Added more macros to help differentiate between different types of JIT operation functions. 6. Made all JIT operation functions use extern "C" linkage to make it possible to write validation tests in assembly so that we can run them on a release build as well without taking too much time. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/JITOperationList.cpp: (JSC::JITOperationList::addInverseMap): (JSC::JITOperationList::addPointers): (JSC::JITOperationList::populatePointersInJavaScriptCore): (JSC::JITOperationList::populatePointersInJavaScriptCoreForLLInt): (JSC::JITOperationList::populatePointersInEmbedder): (JSC::addPointers): Deleted. * assembler/JITOperationList.h: (JSC::JITOperationList::map const): (JSC::JITOperationList::inverseMap const): (JSC::JITOperationList::assertIsJITOperation): (JSC::JITOperationList::assertIsJITOperationWithvalidation): * assembler/JITOperationValidation.h: Added. * assembler/MacroAssemblerARM64.cpp: * assembler/MacroAssemblerARM64.h: * assembler/MacroAssemblerARM64E.h: * assembler/MacroAssemblerARMv7.cpp: * assembler/MacroAssemblerMIPS.cpp: * assembler/MacroAssemblerX86Common.cpp: * b3/testb3.h: * b3/testb3_1.cpp: * b3/testb3_5.cpp: * b3/testb3_7.cpp: * dfg/DFGOSRExit.h: * ftl/FTLLowerDFGToB3.cpp: * jit/ExecutableAllocator.cpp: (JSC::initializeJITPageReservation): * jit/Repatch.cpp: (JSC::retagOperationWithValidation): (JSC::retagCallTargetWithValidation): (JSC::readPutICCallTarget): * jit/ThunkGenerators.cpp: * jsc.cpp: * llint/LLIntData.cpp: * llint/LLIntThunks.cpp: * runtime/CommonSlowPaths.h: * runtime/JSCPtrTag.h: (JSC::tagJSCCodePtrImpl): (JSC::untagJSCCodePtrImpl): (JSC::isTaggedJSCCodePtrImpl): * runtime/MathCommon.h: * runtime/Options.cpp: (JSC::canUseJITCage): * tools/JSDollarVM.cpp: * yarr/YarrJIT.cpp: 2021-09-01 Ross Kirsling Unreviewed exception scope verification fix for r241171. * runtime/TemporalDurationConstructor.cpp: Add missing RELEASE_AND_RETURN. 2021-09-01 Myles C. Maxfield Fix the Xcode build after r281838 Unreviewed. * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: 2021-09-01 Zan Dobersek REGRESSION(r279256): Crash in JSC::FTL::saveAllRegisters https://bugs.webkit.org/show_bug.cgi?id=229235 Reviewed by Mark Lam. Avoid out-of-bounds access into RegisterSet's underlying Bitmap that occurs in FTL::saveAllRegisters() and FTL::restoreAllRegisters(). Helper Regs::nextRegister() and Regs::nextFPRegister() methods can increase the register ID values beyond the valid values, at which point there's a possibility of misuse if these register ID values are used to index into the Bitmap. To avoid this, iterating over RegisterID and FPRegisterID ranges is simplified yet kept efficient, and access into the RegisterSet is now only done if the register ID values are valid. This enables removing Regs::nextFPRegister(). Regs::nextRegister() is still used but is not adjusted to also use a for-loop to iterate across the valid RegisterID values, and only for those values the access into the RegisterSet is possible. * ftl/FTLSaveRestore.cpp: (JSC::FTL::saveAllRegisters): (JSC::FTL::restoreAllRegisters): 2021-08-31 Ross Kirsling [JSC] Implement Temporal.Duration https://bugs.webkit.org/show_bug.cgi?id=228532 Reviewed by Yusuke Suzuki. This patch implements the Duration class for the upcoming Temporal API (currently at stage 3 in TC39). Spec: https://tc39.es/proposal-temporal/#sec-temporal-duration-objects Docs: https://tc39.es/proposal-temporal/docs/duration.html A Duration is ultimately an array of doubles (years, months, weeks, days, hours, minutes, seconds, ms, μs, ns) which can be converted to and from an ISO string representation (e.g. "-P1Y2M3W4DT5H6M7.123456789S") and which supports various calculations. The spec is still in flux and certain issues were identified in the course of preparing this patch. This code aims to be "as correct as possible" for the moment; small corrections are expected in the near future. * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * runtime/CommonIdentifiers.h: * runtime/ISO8601.cpp: Added. * runtime/ISO8601.h: Added. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildrenImpl): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::durationStructure): * runtime/TemporalDuration.cpp: Added. * runtime/TemporalDuration.h: Added. * runtime/TemporalDurationConstructor.cpp: Added. * runtime/TemporalDurationConstructor.h: Added. * runtime/TemporalDurationPrototype.cpp: Added. * runtime/TemporalDurationPrototype.h: Added. * runtime/TemporalObject.cpp: (JSC::createDurationConstructor): (JSC::singularUnit): (JSC::temporalUnitType): (JSC::temporalLargestUnit): (JSC::temporalSmallestUnit): (JSC::temporalFractionalSecondDigits): (JSC::secondsStringPrecision): (JSC::maximumRoundingIncrement): (JSC::temporalRoundingIncrement): (JSC::roundNumberToIncrement): * runtime/TemporalObject.h: * runtime/VM.cpp: * runtime/VM.h: 2021-08-31 Lauro Moura Non-unified build partial fixes, late late August 2021 https://bugs.webkit.org/show_bug.cgi?id=229741 Unreviewed non-unified build fixes. * bytecode/PutByStatus.cpp: Add missing header. * bytecode/PutByVariant.h: Ditto. * runtime/TemporalCalendar.cpp: Ditto. * runtime/TemporalCalendarPrototype.cpp: Ditto. 2021-08-31 Yusuke Suzuki [JSC] Enable Object.hasOwn https://bugs.webkit.org/show_bug.cgi?id=229730 Reviewed by Saam Barati. Enable Object.hasOwn implementation. And cleaning up feature flag list. * runtime/OptionsList.h: 2021-08-31 Saam Barati Baseline JIT's in_by_val and emitHasPrivate should load the property before branching on if the base is a cell https://bugs.webkit.org/show_bug.cgi?id=229725 Reviewed by Keith Miller. If the base isn't a cell, we're calling the slow path with a random value in the property. This works, because the slow paths first branch on if the base is a cell or not, and throw an exception. But we fix this for our own sanity, since it's never a good idea to go to a slow path with a JSValue argument containing unknown bits. * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_in_by_val): (JSC::JIT::emitHasPrivate): 2021-08-31 Aditi Singh Implement Object.hasOwn() https://bugs.webkit.org/show_bug.cgi?id=226291 Reviewed by Alexey Shvayka. This patch implements Object.hasOwn() method which is a stage 3 proposal. The method is disabled by default and can be enabled using the feature flag. The proposal details can be found here: https://github.com/tc39/proposal-accessible-object-hasownproperty. The patch also refines objectPrototypeHasOwnProperty() to accept JSObject* base rather than JSValue. * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * runtime/CommonIdentifiers.h: * runtime/CommonSlowPaths.cpp: (JSC::JSC_DEFINE_COMMON_SLOW_PATH): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/ObjectPrototype.cpp: (JSC::objectPrototypeHasOwnProperty): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/ObjectPrototype.h: * runtime/OptionsList.h: 2021-08-26 Darin Adler Cut down on use of CFGetTypeID, using dynamic_cf_cast instead; related streamlining https://bugs.webkit.org/show_bug.cgi?id=229414 Reviewed by Tim Horton. * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm: (Inspector::RemoteInspectorXPCConnection::deserializeMessage): Use dynamic_cf_cast to check type instead of CFGetTypeID. Also do the check at runtime rather than asserting. Not really sufficient to assert correct type for something that comes over an XPC connection. 2021-08-30 Ross Kirsling [JSC] Host functions and custom getters should be lowerCamelCase https://bugs.webkit.org/show_bug.cgi?id=229695 Reviewed by Yusuke Suzuki. For some reason, the host functions and custom getters for Intl (and JSONObject) were written in UpperCamelCase. * runtime/IntlCollatorConstructor.cpp: * runtime/IntlCollatorPrototype.cpp: * runtime/IntlDateTimeFormatConstructor.cpp: * runtime/IntlDateTimeFormatPrototype.cpp: * runtime/IntlDisplayNamesConstructor.cpp: * runtime/IntlDisplayNamesPrototype.cpp: * runtime/IntlListFormatConstructor.cpp: * runtime/IntlListFormatPrototype.cpp: * runtime/IntlLocalePrototype.cpp: * runtime/IntlNumberFormatConstructor.cpp: * runtime/IntlNumberFormatPrototype.cpp: * runtime/IntlPluralRulesConstructor.cpp: * runtime/IntlPluralRulesPrototype.cpp: * runtime/IntlRelativeTimeFormatConstructor.cpp: * runtime/IntlRelativeTimeFormatPrototype.cpp: * runtime/IntlSegmentIteratorPrototype.cpp: * runtime/IntlSegmenterConstructor.cpp: * runtime/IntlSegmenterPrototype.cpp: * runtime/IntlSegmentsPrototype.cpp: * runtime/JSONObject.cpp: 2021-08-30 Ross Kirsling [JSC][Intl] Errors for .call({}) are too verbose https://bugs.webkit.org/show_bug.cgi?id=229694 Reviewed by Yusuke Suzuki. * runtime/IntlCollatorPrototype.cpp: * runtime/IntlDateTimeFormatPrototype.cpp: * runtime/IntlDisplayNamesPrototype.cpp: * runtime/IntlListFormatPrototype.cpp: * runtime/IntlLocalePrototype.cpp: * runtime/IntlNumberFormatPrototype.cpp: * runtime/IntlPluralRulesPrototype.cpp: * runtime/IntlRelativeTimeFormatPrototype.cpp: * runtime/IntlSegmentIteratorPrototype.cpp: * runtime/IntlSegmenterPrototype.cpp: * runtime/IntlSegmentsPrototype.cpp: 2021-08-30 Yusuke Suzuki [JSC] Implement Temporal.Calendar https://bugs.webkit.org/show_bug.cgi?id=229651 Reviewed by Ross Kirsling. This patch implements Temporal.Calendar's simple part. Currently, we do not implement many part of Temporal.Calendar since we do not have Temporal Date-like structures yet, but this patch implemented core part of Temporal.Calendar: keeping calendar identifier. We also defer implementing Temporal.Calendar.from's calendar ID parsing part since it requires full-fledged ISO 8601 parser, which will be implemented in a separate patch. We use `unsigned` for CalendarID, and this id corresponds to the array index of intlAvailableCalendars, which returns array of String from ICU. * CMakeLists.txt: * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * runtime/CommonIdentifiers.h: * runtime/IntlObject.cpp: (JSC::intlAvailableCalendars): (JSC::iso8601CalendarIDSlow): (JSC::availableCalendars): (JSC::createArrayFromStringVector): Deleted. * runtime/IntlObject.h: (JSC::iso8601CalendarID): * runtime/IntlObjectInlines.h: (JSC::createArrayFromStringVector): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildrenImpl): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::calendarStructure): * runtime/TemporalCalendar.cpp: Added. (JSC::TemporalCalendar::create): (JSC::TemporalCalendar::createStructure): (JSC::TemporalCalendar::TemporalCalendar): (JSC::TemporalCalendar::isBuiltinCalendar): (JSC::parseTemporalCalendarString): (JSC::TemporalCalendar::from): * runtime/TemporalCalendar.h: Added. * runtime/TemporalCalendarConstructor.cpp: Added. (JSC::TemporalCalendarConstructor::create): (JSC::TemporalCalendarConstructor::createStructure): (JSC::TemporalCalendarConstructor::TemporalCalendarConstructor): (JSC::TemporalCalendarConstructor::finishCreation): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/TemporalCalendarConstructor.h: Added. * runtime/TemporalCalendarPrototype.cpp: Added. (JSC::TemporalCalendarPrototype::create): (JSC::TemporalCalendarPrototype::createStructure): (JSC::TemporalCalendarPrototype::TemporalCalendarPrototype): (JSC::TemporalCalendarPrototype::finishCreation): (JSC::JSC_DEFINE_CUSTOM_GETTER): (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::defaultMergeFields): * runtime/TemporalCalendarPrototype.h: Added. * runtime/TemporalObject.cpp: (JSC::createCalendarConstructor): * runtime/VM.cpp: * runtime/VM.h: 2021-08-30 Ross Kirsling Unreviewed, add missing include to pre-empt unified source shift. * runtime/IntlObject.cpp: 2021-08-30 Angelos Oikonomopoulos resolve-asm-file-conflicts.rb build failure after upgrade to CMake 3.21.0; DWARF 5 incompatibility https://bugs.webkit.org/show_bug.cgi?id=228267 Reviewed by Adrian Perez de Castro. Implement the fix suggested by Adrian Vovk: any .file 0 directive should pass through unchanged. While here - if the file path is an absolute path, don't concat it with the working directory - also accept 'md5 0xhash' in the .file directive. * Scripts/resolve-asm-file-conflicts.rb: 2021-08-30 Zan Dobersek RISCV64 support in LLInt https://bugs.webkit.org/show_bug.cgi?id=229035 Reviewed by Yusuke Suzuki. Introduce RISCV64 support at the LLint level. Along with the necessary offlineasm backend, plenty of miscellaneous code around MacroAssembler infrastructure is also introduced. Of the existing supported architectures, RISCV64 is most similar to ARM64, with the same word size and similar register abundance. This is mirrored in most changes around the MacroAssembler infrastructure as well as using same or similar codepaths in LLint for the two ISAs. For the MacroAssembler infrastructure, it won't be used until proper JIT support is introduced, but the basic facilities are still necessary to keep things compiling without complicating the configuration matrix. MacroAssemblerRISCV64 class provides no-op methods through C++ templates while RISCV64Assembler is also added in a limited form. The riscv64 offlineasm backend covers assembly generation for instructions that are exhibited by LLInt in the current configuration. It doesn't cover instructions that e.g. are only used in the WebAssembly opcodes, and WebAssembly won't be enabled until the higher JIT tiers are supported anyway. The offlineasm backend's assembly generation for specific instructions uses pattern matching of operand types for better overview of how resulting assembly is constructed. There's still certain improvements possible, e.g. in how scratch registers for more expansive operations are allocated. * CMakeLists.txt: * Sources.txt: * assembler/AbstractMacroAssembler.h: * assembler/MacroAssembler.h: * assembler/MacroAssemblerRISCV64.cpp: Added. (JSC::MacroAssembler::probe): * assembler/MacroAssemblerRISCV64.h: Added. Distorted auto-generated method list removed. Necessary methods are introduced through no-op templates until actually needed for JIT generation. * assembler/MaxFrameExtentForSlowPathCall.h: * assembler/PerfLog.cpp: * assembler/ProbeContext.h: * assembler/RISCV64Assembler.h: Added. (JSC::RISCV64Assembler::firstRegister): (JSC::RISCV64Assembler::lastRegister): (JSC::RISCV64Assembler::numberOfRegisters): (JSC::RISCV64Assembler::firstSPRegister): (JSC::RISCV64Assembler::lastSPRegister): (JSC::RISCV64Assembler::numberOfSPRegisters): (JSC::RISCV64Assembler::firstFPRegister): (JSC::RISCV64Assembler::lastFPRegister): (JSC::RISCV64Assembler::numberOfFPRegisters): (JSC::RISCV64Assembler::gprName): (JSC::RISCV64Assembler::sprName): (JSC::RISCV64Assembler::fprName): (JSC::RISCV64Assembler::RISCV64Assembler): (JSC::RISCV64Assembler::buffer): (JSC::RISCV64Assembler::invert): (JSC::RISCV64Assembler::getRelocatedAddress): (JSC::RISCV64Assembler::codeSize const): (JSC::RISCV64Assembler::getCallReturnOffset): (JSC::RISCV64Assembler::labelIgnoringWatchpoints): (JSC::RISCV64Assembler::labelForWatchpoint): (JSC::RISCV64Assembler::label): (JSC::RISCV64Assembler::linkJump): (JSC::RISCV64Assembler::linkCall): (JSC::RISCV64Assembler::linkPointer): (JSC::RISCV64Assembler::maxJumpReplacementSize): (JSC::RISCV64Assembler::patchableJumpSize): (JSC::RISCV64Assembler::repatchPointer): (JSC::RISCV64Assembler::relinkJump): (JSC::RISCV64Assembler::relinkJumpToNop): (JSC::RISCV64Assembler::relinkCall): (JSC::RISCV64Assembler::debugOffset): (JSC::RISCV64Assembler::cacheFlush): (JSC::RISCV64Assembler::fillNops): * assembler/RISCV64Registers.h: Added. * jit/FPRInfo.h: (JSC::FPRInfo::toRegister): (JSC::FPRInfo::toArgumentRegister): (JSC::FPRInfo::toIndex): (JSC::FPRInfo::debugName): * jit/GPRInfo.h: (JSC::GPRInfo::toRegister): (JSC::GPRInfo::toArgumentRegister): (JSC::GPRInfo::toIndex): (JSC::GPRInfo::debugName): * jit/RegisterSet.cpp: (JSC::RegisterSet::vmCalleeSaveRegisters): (JSC::RegisterSet::llintBaselineCalleeSaveRegisters): * llint/LLIntData.h: * llint/LLIntOfflineAsmConfig.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/backends.rb: Reference the riscv64 backend as required. * offlineasm/registers.rb: List additional possible registers. * offlineasm/riscv64.rb: Added. 2021-08-29 Keith Miller Add openFile function to jsc.cpp that links to file backed memory https://bugs.webkit.org/show_bug.cgi?id=229621 Reviewed by Saam Barati. This patch uses fopen directly rather than use WTF::MappedFileData so there were less changes to readline. * jsc.cpp: (computeFilePath): (JSC_DEFINE_HOST_FUNCTION): (JSFileDescriptor::subspaceFor): (JSFileDescriptor::createStructure): (JSFileDescriptor::create): (JSFileDescriptor::finishCreation): (JSFileDescriptor::destroy): (JSFileDescriptor::descriptor const): (JSFileDescriptor::JSFileDescriptor): (JSFileDescriptor::~JSFileDescriptor): 2021-08-29 Joonghun Park Unreviewed. Remove the build warning below since r281615. warning: control reaches end of non-void function [-Wreturn-type] * bytecode/PutByStatus.cpp: (JSC::PutByStatus::makesCalls const): 2021-08-28 Cameron McCormack Miscellaneous typo fixes https://bugs.webkit.org/show_bug.cgi?id=229642 Reviewed by Fujii Hironori. * API/JSValue.h: * runtime/RegExp.cpp: (JSC::RegExp::matchCompareWithInterpreter): 2021-08-27 Stephan Szabo [PlayStation][CMake] Add control over whether JavaScriptCore should be shared https://bugs.webkit.org/show_bug.cgi?id=229591 Reviewed by Don Olmstead. Make LowLevelInterpreterLib objects get added via _PRIVATE_LIBRARIES when using JavaScriptCore as an object library in order to propogate them correctly. * CMakeLists.txt: 2021-08-27 Russell Epstein Land Windows build fixes from safari-612.1.29.14-branch. https://bugs.webkit.org/show_bug.cgi?id=229627. Reviewed by Per Arne Vollan. * JavaScriptCore.vcxproj/JavaScriptCore.proj: 2021-08-27 Mark Lam Changed ARM64 probe trampoline to do ptr auth the standard way. https://bugs.webkit.org/show_bug.cgi?id=229629 rdar://problem/82453220 Reviewed by Saam Barati. Also fix a comment, and add back 2 lines that I accidentally deleted in r281718. * assembler/MacroAssemblerARM64.cpp: 2021-08-27 Mark Lam Make ARM64 and X86_64 probe code a little bit more efficient. https://bugs.webkit.org/show_bug.cgi?id=229618 rdar://82445743 Reviewed by Yusuke Suzuki. We were using an unnecessary indirect call to call Probe::executeProbe() when we can be using a direct call, which emits less JIT code. This patch changes the ARM64 and X86_64 ports to use a direct call now. Also rename executeProbe to executeJSCJITProbe to make it more unique since we're switching to extern "C" linkage for this function now. For MacroAssemblerX86Common.cpp, we left the X86 and MSVC implementations unchanged. For X86, I don't know the stack alignment requirements (if any) plus we might want to delete this code eventually since we're not supporting the X86 JIT anymore. For MSVC, I don't know the way to express a direct call in MSVC assembly, and have no way to test it. Will leave that as an exercise for folks working on the Windows ports if they are interested. Also remove JITProbeExecutorPtrTag since it's no longer needed. * assembler/MacroAssemblerARM64.cpp: (JSC::MacroAssembler::probe): * assembler/MacroAssemblerARMv7.cpp: (JSC::MacroAssembler::probe): * assembler/MacroAssemblerMIPS.cpp: (JSC::MacroAssembler::probe): * assembler/MacroAssemblerX86Common.cpp: (JSC::ctiMasmProbeTrampoline): (JSC::MacroAssembler::probe): * assembler/ProbeContext.cpp: (JSC::Probe::executeJSCJITProbe): (JSC::Probe::executeProbe): Deleted. * assembler/ProbeContext.h: * runtime/JSCPtrTag.h: 2021-08-27 Saam Barati Update ARM64EHash https://bugs.webkit.org/show_bug.cgi?id=228962 Reviewed by Mark Lam. * assembler/AssemblerBuffer.h: (JSC::ARM64EHash::ARM64EHash): (JSC::ARM64EHash::update): (JSC::ARM64EHash::makeDiversifier): (JSC::ARM64EHash::nextValue): (JSC::ARM64EHash::bitsForDiversifier): (JSC::ARM64EHash::currentHash): (JSC::ARM64EHash::setUpdatedHash): (JSC::AssemblerBuffer::AssemblerBuffer): (JSC::AssemblerBuffer::putIntegralUnchecked): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): 2021-08-27 Mikhail R. Gadelha Avoid increasing required alignment of target type warning on ARM 32 bits https://bugs.webkit.org/show_bug.cgi?id=229151 Reviewed by Mark Lam. Same approach as https://bugs.webkit.org/show_bug.cgi?id=38045 cast pointers to void* to bypass warning about increasing pointer alingment. reinterpret_cast_ptr has custom behaviour only on ARM and MIPS 32 bits, and doesn't change the behaviour in 64 bits archs (reinterpret_cast_ptr is preprocessed to reinterpret_cast in 64 bits archs) * bytecode/Instruction.h: (JSC::BaseInstruction::asKnownWidth const): * llint/LLIntCommon.h: 2021-08-27 Commit Queue Unreviewed, reverting r281587. https://bugs.webkit.org/show_bug.cgi?id=229609 stress test failed on ARM64 Reverted changeset: "[ARM64] Fix pre-index address mode" https://bugs.webkit.org/show_bug.cgi?id=229175 https://commits.webkit.org/r281587 2021-08-26 Yusuke Suzuki Intl.DateTimeFormat incorrectly parses patterns with 'h' literal https://bugs.webkit.org/show_bug.cgi?id=229313 rdar://82414310 Reviewed by Ross Kirsling. While DateTimeFormat pattern and skeleton can include single-quoted literal texts, we are not respecting that when parsing them to extract information. As a result, we are incorrectly extracting hour-cycle information for "fr" locale since it can include "HH 'h'" pattern text. This patch fixes that by skipping literal text correctly. * runtime/IntlDateTimeFormat.cpp: (JSC::skipLiteralText): (JSC::IntlDateTimeFormat::setFormatsFromPattern): (JSC::IntlDateTimeFormat::hourCycleFromPattern): (JSC::IntlDateTimeFormat::replaceHourCycleInSkeleton): (JSC::IntlDateTimeFormat::replaceHourCycleInPattern): * runtime/IntlDateTimeFormat.h: * runtime/IntlLocale.cpp: (JSC::IntlLocale::hourCycles): 2021-08-26 Yusuke Suzuki Float32Arrays.sort() return undefined when length < 2 https://bugs.webkit.org/show_bug.cgi?id=229575 Reviewed by Saam Barati. TypedArray#sort should return |this| even when we don't perform sorting. * builtins/TypedArrayPrototype.js: (sort): 2021-08-26 Yusuke Suzuki [JSC] op_put_private_name should use modern IC and remove ByValInfo https://bugs.webkit.org/show_bug.cgi?id=229544 Reviewed by Saam Barati. This patch makes op_put_private_name use new PutByVal IC. This allows op_put_private_name to support polymorphic properties, and we can finally remove Baseline's adhoc IC and ByValInfo completely. Added microbenchmark showed 3x improvement due to polymorphic PutPrivateName IC. ToT Patched class-private-field-polymorphic 9.3666+-0.0332 ^ 3.1199+-0.0182 ^ definitely 3.0022x faster * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/ByValInfo.cpp: Removed. * bytecode/ByValInfo.h: Removed. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::getICStatusMap): (JSC::CodeBlock::stronglyVisitStrongReferences): (JSC::CodeBlock::findByValInfo): Deleted. (JSC::CodeBlock::addByValInfo): Deleted. * bytecode/CodeBlock.h: * bytecode/ICStatusMap.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetPrivateName): (JSC::DFG::SpeculativeJIT::compilePutPrivateName): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStoreBarrierInsertionPhase.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compilePutPrivateName): * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): (JSC::JIT::link): (JSC::JIT::privateCompileExceptionHandlers): * jit/JIT.h: (JSC::ByValCompilationInfo::ByValCompilationInfo): Deleted. * jit/JITInlines.h: (JSC::JIT::emitArrayProfileStoreToHoleSpecialCase): Deleted. (JSC::JIT::emitArrayProfileOutOfBoundsSpecialCase): Deleted. * jit/JITOperations.cpp: (JSC::putPrivateNameOptimize): (JSC::putPrivateName): (JSC::JSC_DEFINE_JIT_OPERATION): * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_private_name): (JSC::JIT::emitSlow_op_put_private_name): (JSC::JIT::slow_op_put_private_name_prepareCallGenerator): (JSC::JIT::emitPutByValWithCachedId): Deleted. (JSC::JIT::emitPutPrivateNameWithCachedId): Deleted. (JSC::JIT::emitByValIdentifierCheck): Deleted. (JSC::JIT::privateCompilePutPrivateNameWithCachedId): Deleted. * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_put_private_name): (JSC::JIT::emitSlow_op_put_private_name): * jit/Repatch.cpp: (JSC::appropriateGenericPutByFunction): (JSC::appropriateOptimizingPutByFunction): (JSC::resetPutBy): 2021-08-26 Saam Barati r281485 was not sufficient in where it called disablePeepholeOptimization https://bugs.webkit.org/show_bug.cgi?id=229582 Reviewed by Yusuke Suzuki. r281485 accidentally deleted a place where we called disablePeepholeOptimization that was necessary. Basically, after we seek where the current instruction in BytecodeGenerator is, we need to disablePeepholeOptimization. * bytecompiler/BytecodeGenerator.cpp: (JSC::ForInContext::finalize): 2021-08-26 Per Arne Vollan [AppleWin] JSC build failure https://bugs.webkit.org/show_bug.cgi?id=229578 Reviewed by Don Olmstead. Add new build dependency between LLIntOffsetsExtractor and JSCBuiltins targets. * CMakeLists.txt: 2021-08-26 Yusuke Suzuki [JSC] Segfault in stress/typedarray-every.js (32bit) https://bugs.webkit.org/show_bug.cgi?id=229546 Reviewed by Saam Barati. ARMv7 does not have enough registers. Adding workaround by using getEffectiveAddress. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateWithGuard): 2021-08-26 Yusuke Suzuki [JSC] DataIC should not embed StructureStubInfo pointer https://bugs.webkit.org/show_bug.cgi?id=229541 Reviewed by Mark Lam. We should not embed pointer to StructureStubInfo::countdown if DataIC is used. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::store8): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::offsetOfCountdown): 2021-08-25 Yusuke Suzuki [JSC] Polymorphic PutByVal https://bugs.webkit.org/show_bug.cgi?id=229229 Reviewed by Saam Barati. This patch changes PutByVal IC to modern style. This polymorphic PutByVal can handle multiple array types and multiple identifiers. Also, this removes adhoc IC code in Baseline so that it paves the way to unlinked Baseline JIT by cleaning up IC. Several interesting points of the design. 1. We need to pass ArrayProfile* via GPRReg to IC since we need to profile mayStoreToHole, which is still important to avoid the slow path. 2. Transition / Replace IC need to record propertyRegs if it exists not to clobber these registers. This is important in DFG / FTL since IC should not clobber these registers unless it is flushed. It also makes Baseline code smaller since we do not reload them in the slow path call. 3. Added a path folding String/Symbol when emitting PutByVal in DFG / FTL. This edge-case is found via a microbenchmark. Let's consider the case: one put_by_val site has one identifier "foo", but it has so many different Structures. Previously, we emit JITPutByIdGenerator adhocly, and still we cache this "foo" identifier in cachedId. In DFG / FTL, while we cannot make it PutByOffset, we can emit PutById since we know that identifier is always "foo". But after this patch's change, such a site becomes slow-path. And then this identifier information is missed, and we were emitting PutByVal for that. For now, we attempt to fold to one identifier in DFGByteCodeParser so that we can still attempt to make it PutById, which can be PutByOffset in constant folding phase. We would like to handle this one identifier slow-path case in PutByStatus / GetByStatus in the future patch. 4. Now, DFG OSR exit does not query to ByValInfo for setter calls since JITPutByValGenerator use StructureStubInfo in Baseline. Results of Microbenchmarks look good. ToT Patched put-by-val-direct-large-index 94.6265+-0.9076 93.4550+-0.7121 might be 1.0125x faster inlined-put-by-val-with-string-transition 23.7131+-0.3282 ^ 22.7679+-0.1137 ^ definitely 1.0415x faster put-by-val-with-string-slightly-polymorphic 1.9852+-0.0284 1.9580+-0.0224 might be 1.0139x faster get-and-put-by-val-double-index-dont-fall-off-a-cliff 185.4762+-0.5737 ? 185.6325+-0.5819 ? polymorphic-put-by-val-with-string 30.9903+-0.1207 30.8097+-0.1285 put-by-val-machine-int 1.8803+-0.0384 1.8707+-0.0440 fold-put-by-val-with-symbol-to-multi-put-by-offset 4.8463+-0.1148 4.7839+-0.0547 might be 1.0130x faster put-by-val-with-string-replace-and-transition 8.8730+-1.5934 ^ 6.2276+-0.0585 ^ definitely 1.4248x faster fold-put-by-val-with-string-to-multi-put-by-offset 4.8183+-0.0841 ? 4.8233+-0.0892 ? put-by-val-direct 0.2845+-0.0091 ? 0.2901+-0.0088 ? might be 1.0196x slower put-by-val-with-symbol-replace-and-transition 6.3527+-0.0686 ? 6.3933+-0.0961 ? put-by-val-with-symbol 9.3556+-3.1421 7.1509+-0.1019 might be 1.3083x faster put-by-val-with-symbol-slightly-polymorphic 2.0052+-0.0309 1.9781+-0.0397 might be 1.0137x faster put-by-val-negative-array-index 14.9572+-0.1221 ^ 14.5636+-0.1044 ^ definitely 1.0270x faster put-by-val-with-string 11.6345+-4.3048 ^ 7.0919+-0.0918 ^ definitely 1.6405x faster put-by-val-large-index-blank-indexing-type 3.1425+-0.1165 3.1236+-0.0378 inlined-put-by-val-with-symbol-transition 23.4932+-0.3186 ^ 22.8469+-0.0873 ^ definitely 1.0283x faster polymorphic-put-by-val-with-symbol 36.6046+-1.6519 ^ 30.8597+-0.1474 ^ definitely 1.1862x faster Speedometer2 showed roughly 0.2-0.3% progression. ---------------------------------------------------------------------------------------------------------------------------------- | subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) | ---------------------------------------------------------------------------------------------------------------------------------- | Elm-TodoMVC |121.916667 |121.958333 |1.000342 | 0.876802 | | VueJS-TodoMVC |26.263333 |26.006667 |0.990227 | 0.263868 | | EmberJS-TodoMVC |127.080000 |127.866667 |1.006190 | 0.011497 (significant) | | BackboneJS-TodoMVC |48.920000 |49.318333 |1.008143 | 0.003395 (significant) | | Preact-TodoMVC |19.828333 |19.828333 |1.000000 | 1.000000 | | AngularJS-TodoMVC |134.011667 |132.080000 |0.985586 | 0.000000 (significant) | | Vanilla-ES2015-TodoMVC |63.726667 |63.838333 |1.001752 | 0.408404 | | Inferno-TodoMVC |65.153333 |63.753333 |0.978512 | 0.000000 (significant) | | Flight-TodoMVC |78.133333 |78.780000 |1.008276 | 0.097794 | | Angular2-TypeScript-TodoMVC |40.415000 |40.100000 |0.992206 | 0.287630 | | VanillaJS-TodoMVC |51.931667 |52.500000 |1.010944 | 0.004149 (significant) | | jQuery-TodoMVC |226.056667 |225.073333 |0.995650 | 0.007796 (significant) | | EmberJS-Debug-TodoMVC |341.210000 |340.978333 |0.999321 | 0.623386 | | React-TodoMVC |87.198333 |86.893333 |0.996502 | 0.042189 | | React-Redux-TodoMVC |146.506667 |145.958333 |0.996257 | 0.018801 (significant) | | Vanilla-ES2015-Babel-Webpack-TodoMVC |61.450000 |61.870000 |1.006835 | 0.000049 (significant) | ---------------------------------------------------------------------------------------------------------------------------------- a mean = 254.85111 b mean = 255.25735 pValue = 0.1856561656 (Bigger means are better.) 1.002 times better Results ARE NOT significant * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/AccessCase.cpp: (JSC::AccessCase::create): (JSC::AccessCase::guardedByStructureCheckSkippingConstantIdentifierCheck const): (JSC::AccessCase::requiresIdentifierNameMatch const): (JSC::AccessCase::requiresInt32PropertyCheck const): (JSC::AccessCase::needsScratchFPR const): (JSC::AccessCase::forEachDependentCell const): (JSC::AccessCase::doesCalls const): (JSC::AccessCase::canReplace const): (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generateImpl): (JSC::AccessCase::toTypedArrayType): (JSC::AccessCase::canBeShared): * bytecode/AccessCase.h: (JSC::SharedJITStubSet::Hash::Key::Key): (JSC::SharedJITStubSet::Hash::Key::operator==): (JSC::SharedJITStubSet::Searcher::Translator::equal): * bytecode/ArrayProfile.h: (JSC::ArrayProfile::offsetOfMayStoreToHole): (JSC::ArrayProfile::offsetOfLastSeenStructureID): * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::emitDOMJITGetter): * bytecode/ICStatusMap.h: * bytecode/InlineAccess.cpp: (JSC::getScratchRegister): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): (WTF::printInternal): * bytecode/PutByStatus.cpp: Renamed from Source/JavaScriptCore/bytecode/PutByIdStatus.cpp. (JSC::PutByStatus::appendVariant): (JSC::PutByStatus::shrinkToFit): (JSC::PutByStatus::computeFromLLInt): (JSC::PutByStatus::PutByStatus): (JSC::PutByStatus::computeFor): (JSC::PutByStatus::computeForStubInfo): (JSC::PutByStatus::makesCalls const): (JSC::PutByStatus::slowVersion const): (JSC::PutByStatus::singleIdentifier const): (JSC::PutByStatus::visitAggregateImpl): (JSC::PutByStatus::markIfCheap): (JSC::PutByStatus::finalize): (JSC::PutByStatus::merge): (JSC::PutByStatus::filter): (JSC::PutByStatus::dump const): * bytecode/PutByStatus.h: Renamed from Source/JavaScriptCore/bytecode/PutByIdStatus.h. * bytecode/PutByVariant.cpp: Renamed from Source/JavaScriptCore/bytecode/PutByIdVariant.cpp. (JSC::PutByVariant::PutByVariant): (JSC::PutByVariant::operator=): (JSC::PutByVariant::replace): (JSC::PutByVariant::transition): (JSC::PutByVariant::setter): (JSC::PutByVariant::oldStructureForTransition const): (JSC::PutByVariant::fixTransitionToReplaceIfNecessary): (JSC::PutByVariant::writesStructures const): (JSC::PutByVariant::reallocatesStorage const): (JSC::PutByVariant::makesCalls const): (JSC::PutByVariant::attemptToMerge): (JSC::PutByVariant::attemptToMergeTransitionWithReplace): (JSC::PutByVariant::visitAggregateImpl): (JSC::PutByVariant::markIfCheap): (JSC::PutByVariant::finalize): (JSC::PutByVariant::dump const): (JSC::PutByVariant::dumpInContext const): * bytecode/PutByVariant.h: Renamed from Source/JavaScriptCore/bytecode/PutByIdVariant.h. (JSC::PutByVariant::PutByVariant): (JSC::PutByVariant::identifier const): (JSC::PutByVariant::overlaps): * bytecode/RecordedStatuses.cpp: (JSC::RecordedStatuses::addPutByStatus): (JSC::RecordedStatuses::visitAggregateImpl): (JSC::RecordedStatuses::addPutByIdStatus): Deleted. * bytecode/RecordedStatuses.h: * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::reset): * bytecode/StructureStubInfo.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): (JSC::DFG::AbstractInterpreter::filterICStatus): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::load): (JSC::DFG::ByteCodeParser::store): (JSC::DFG::ByteCodeParser::emitPutById): (JSC::DFG::ByteCodeParser::handlePutById): (JSC::DFG::ByteCodeParser::handlePutPrivateNameById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::handlePutByVal): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGClobbersExitState.cpp: (JSC::DFG::clobbersExitState): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): (JSC::DFG::ConstantFoldingPhase::emitPutByOffset): (JSC::DFG::ConstantFoldingPhase::tryFoldAsPutByOffset): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::addPutByVal): * dfg/DFGMayExit.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::hasPutByStatus): (JSC::DFG::Node::putByStatus): (JSC::DFG::Node::hasPutByIdStatus): Deleted. (JSC::DFG::Node::putByIdStatus): Deleted. * dfg/DFGNodeType.h: * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::callerReturnPC): * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStoreBarrierInsertionPhase.cpp: * dfg/DFGValidate.cpp: * dfg/DFGVarargsForwardingPhase.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset): * generator/DSL.rb: * jit/ICStats.h: * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): (JSC::JIT::link): * jit/JIT.h: * jit/JITInlineCacheGenerator.cpp: (JSC::JITPutByIdGenerator::JITPutByIdGenerator): (JSC::JITPutByValGenerator::JITPutByValGenerator): (JSC::JITPutByValGenerator::generateFastPath): (JSC::JITPutByValGenerator::finalize): * jit/JITInlineCacheGenerator.h: * jit/JITInlines.h: (JSC::JIT::emitArrayProfilingSiteWithCell): (JSC::JIT::chooseArrayMode): Deleted. * jit/JITOperations.cpp: (JSC::JSC_DEFINE_JIT_OPERATION): (JSC::putByVal): (JSC::directPutByVal): (JSC::putByValOptimize): (JSC::directPutByValOptimize): (JSC::tryPutByValOptimize): Deleted. (JSC::tryDirectPutByValOptimize): Deleted. * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::slow_op_put_by_val_prepareCallGenerator): (JSC::JIT::emitSlow_op_put_private_name): (JSC::JIT::slow_op_put_private_name_prepareCallGenerator): (JSC::JIT::emitGenericContiguousPutByVal): Deleted. (JSC::JIT::emitArrayStoragePutByVal): Deleted. (JSC::JIT::privateCompilePutByVal): Deleted. (JSC::JIT::privateCompilePutByValWithCachedId): Deleted. (JSC::JIT::emitIntTypedArrayPutByVal): Deleted. (JSC::JIT::emitFloatTypedArrayPutByVal): Deleted. * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): Deleted. (JSC::JIT::emitArrayStoragePutByVal): Deleted. * jit/Repatch.cpp: (JSC::appropriateGenericPutByFunction): (JSC::appropriateOptimizingPutByFunction): (JSC::tryCachePutBy): (JSC::repatchPutBy): (JSC::tryCacheArrayPutByVal): (JSC::repatchArrayPutByVal): (JSC::tryCacheInBy): (JSC::resetPutBy): (JSC::appropriateGenericPutByIdFunction): Deleted. (JSC::appropriateOptimizingPutByIdFunction): Deleted. (JSC::tryCachePutByID): Deleted. (JSC::repatchPutByID): Deleted. (JSC::resetPutByID): Deleted. * jit/Repatch.h: * llint/LowLevelInterpreter.h: 2021-08-25 Yusuke Suzuki REGRESSION(r281513?): [ JSC Catalina+ Debug ] 16 stress/intl-enumeration.js (JSC Tests) are flaky failing https://bugs.webkit.org/show_bug.cgi?id=229526 Reviewed by Mark Lam. Fix debug JSC test failures by using RELEASE_AND_RETURN. * runtime/IntlObject.cpp: (JSC::availableCalendars): (JSC::availableCollations): (JSC::availableCurrencies): (JSC::availableNumberingSystems): (JSC::availableTimeZones): 2021-08-25 Yijia Huang [ARM64] Fix pre-index address mode https://bugs.webkit.org/show_bug.cgi?id=229175 Reviewed by Saam Barati. This patch fixes the canonicalization phase for pre/post-increment address mode due to the potential bugs commented on in the previous patch https://bugs.webkit.org/show_bug.cgi?id=228538. And this patch removed the temporary fix in https://bugs.webkit.org/show_bug.cgi?id=229211. Previously, the pre-index address mode for Load instruction convert the pattern to the canonical form like this: address = Add(base, offset) address = Add(base, offset) ... --> newMemory = Load(base, offset) ... ... memory = Load(base, offset) memory = Identity(newMemory) which is wrong. Assume "..." contains a store to a memory location that aliases for address: address = Add(base, offset) address = Add(base, offset) ... --> newMemory = Load(base, offset) ... ... Store(value1, address) Store(value1, address) memory = Load(base, offset) memory = Identity(newMemory) The loaded value should always be value1 which is not true after the conversion. So, moving the load above the store is semantically incorrect because it's not identical to the behavior of the original program. In this case, maybe we should apply alias analysis to detect the violations of reference updating. To solve this problem, we moves the address value to just before the memory value instead of moving memory value upward. Convert Pre-Index Load Pattern to the Canonical Form: address = Add(base, offset) address = Nop ... ... ... newAddress = Add(base, offset) memory = Load(base, offset) --> memory = Load(base, offset) ... ... parent = B3Opcode(address, ...) parent = B3Opcode(newAddress, ...) Convert Pre-Index Store Pattern to the Canonical Form: address = Add(base, offset) address = Nop ... ... ... newAddress = Add(base, offset) memory = Store(value1, base, offset) --> memory = Store(value1, base, offset) ... ... parent = B3Opcode(address, ...) parent = B3Opcode(newAddress, ...) To move the address value downward, we need to make sure that no use reference of address between the address and memory values. * b3/B3CanonicalizePrePostIncrements.cpp: (JSC::B3::canonicalizePrePostIncrements): * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3ValueKey.h: * b3/B3ValueKeyInlines.h: (JSC::B3::ValueKey::ValueKey): * b3/testb3.h: * b3/testb3_3.cpp: (testLoadWithStorePreIndex32): (testStorePreIndex32): (testStorePreIndex64): (testStorePostIndex32): (testStorePostIndex64): (addShrTests): * runtime/OptionsList.h: 2021-08-25 Xan Lopez [JSC] Infinite loop in for...in after r280760 https://bugs.webkit.org/show_bug.cgi?id=229493 Reviewed by Yusuke Suzuki. A missing instruction in the 32bit branch can potentially cause infinite loops when using for-in. No new test, this is already covered by (among others) LayoutTests/js/reserved-words.html. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdateIndexAndMode): 2021-08-25 Keith Miller Add for-in OwnStructureMode optimizations to LLInt https://bugs.webkit.org/show_bug.cgi?id=229038 Reviewed by Saam Barati. This patch adds the optimizations we have for OwnStructureMode in the Baseline to the LLInt. The patch also adds redundant self move (i.e. move a, a) elimination to arm64. Finally, a bunch of the property offset functions are now marked constexpr and return intptr_t rather than size_t as the values can be negative. There's also a minor fix to disable MSVC's signed to unsigned cast warning for LLIntOffsetsExtractor as we don't care about signedness for extracting constants. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileEnumeratorGetByVal): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_enumerator_get_by_val): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/generate_offset_extractor.rb: * runtime/Butterfly.h: (JSC::Butterfly::indexOfPropertyStorage): * runtime/JSObject.h: (JSC::offsetInButterfly): * runtime/PropertyOffset.h: (JSC::checkOffset): (JSC::validateOffset): (JSC::isValidOffset): (JSC::isInlineOffset): (JSC::isOutOfLineOffset): (JSC::offsetInInlineStorage): (JSC::offsetInOutOfLineStorage): (JSC::offsetInRespectiveStorage): (JSC::numberOfOutOfLineSlotsForMaxOffset): (JSC::numberOfSlotsForMaxOffset): (JSC::offsetForPropertyNumber): 2021-08-25 Commit Queue Unreviewed, reverting r281523. https://bugs.webkit.org/show_bug.cgi?id=229494 broke cloop build Reverted changeset: "Add for-in OwnStructureMode optimizations to LLInt" https://bugs.webkit.org/show_bug.cgi?id=229038 https://commits.webkit.org/r281523 2021-08-24 Mark Lam Refactor ENABLE(JIT_OPERATION_VALIDATION) code to emit no code when disabled. https://bugs.webkit.org/show_bug.cgi?id=229482 rdar://82318317 Reviewed by Yusuke Suzuki. * assembler/JITOperationList.cpp: (JSC::addPointers): (JSC::JITOperationList::populatePointersInJavaScriptCore): (JSC::JITOperationList::populatePointersInJavaScriptCoreForLLInt): (JSC::JITOperationList::populatePointersInEmbedder): * assembler/JITOperationList.h: (JSC::JITOperationList::map const): (JSC::JITOperationList::assertIsJITOperation): (JSC::JITOperationList::initialize): (JSC::JITOperationList::populatePointersInJavaScriptCore): (JSC::JITOperationList::populatePointersInJavaScriptCoreForLLInt): * runtime/JSCPtrTag.h: (JSC::tagJSCCodePtrImpl): (JSC::untagJSCCodePtrImpl): 2021-08-24 Mark Lam [Re-landing] Add some offlineasm enhancements. https://bugs.webkit.org/show_bug.cgi?id=229332 rdar://82163923 Reviewed by Keith Miller. 1. Enhance "include" offlineasm Instruction to always attempt to include an asm file from /usr/local/include/WebKitAdditions/ first. If the specified file is not available there, then it will attempt to include the file from the same directory as the current source file (which in practice, means Source/JavaScriptCore/llint/). 2. Enhance "include" offlineasm Instruction to allow an optional file to be included if it exists. For example, the following offlineasm code: include? LowLevelInterpreterAdditions ... will attempt to include a file LowLevelInterpreterAdditions.asm. If the file does not exist, this will be a no-op. Note: the "?" after the "include" means the include is optional. 3. Enhanced "emit" offlineasm Instruction to be able to take more than one operand. "emit" used to just copy the string operand that follows into the generated LLIntAssembly.h. Now, "emit" can take multiple comma separated operands, and will concatenate all the operands. Additionally, "emit" can now take a LocalLabelReference as an operand. For example, this offline asm code: emit "b ", .done ... .done: ... will generate this inline asm code in LLIntAssembly.h: "b " LOCAL_LABEL_STRING(_offlineasm_someLabel_done) "\n" This makes it easier to emit branches to local labels. 4. Also fixed LLInt code alignment for ARM_THUMB2 and ARM64. Previously, it was aligned using ".align 4" which means aligned on a 4 instruction boundary. Note: the interpretation of .align varies for different target CPU architectures. Now, we do the alignment using ".balign 4" which means align on a 4 byte boundary. This is the intended alignment because ARM64 instruction size is 4 bytes, and ARM_THUMB2 instruction size is either 2 bytes or 4 bytes. Using .align before was potentially wasting some code space. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: * offlineasm/ast.rb: * offlineasm/parser.rb: 2021-08-24 Mark Lam testb3_6 should be using JSSwitchPtrTag instead of JITCompilationPtrTag. https://bugs.webkit.org/show_bug.cgi?id=229479 rdar://82316967 Reviewed by Yusuke Suzuki. This is in testInterpreter() which is emitting code for a jump table. JSSwitchPtrTag is the right tag to use here. * b3/testb3_6.cpp: (testInterpreter): 2021-08-24 Keith Miller Add for-in OwnStructureMode optimizations to LLInt https://bugs.webkit.org/show_bug.cgi?id=229038 Reviewed by Saam Barati. This patch adds the optimizations we have for OwnStructureMode in the Baseline to the LLInt. The patch also adds redundant self move (i.e. move a, a) elimination to arm64. Finally, a bunch of the property offset functions are now marked constexpr and return intptr_t rather than size_t as the values can be negative. There's also a minor fix to disable MSVC's signed to unsigned cast warning for LLIntOffsetsExtractor as we don't care about signedness for extracting constants. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileEnumeratorGetByVal): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_enumerator_get_by_val): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/generate_offset_extractor.rb: * runtime/Butterfly.h: (JSC::Butterfly::indexOfPropertyStorage): * runtime/JSObject.h: (JSC::offsetInButterfly): * runtime/PropertyOffset.h: (JSC::checkOffset): (JSC::validateOffset): (JSC::isValidOffset): (JSC::isInlineOffset): (JSC::isOutOfLineOffset): (JSC::offsetInInlineStorage): (JSC::offsetInOutOfLineStorage): (JSC::offsetInRespectiveStorage): (JSC::numberOfOutOfLineSlotsForMaxOffset): (JSC::numberOfSlotsForMaxOffset): (JSC::offsetForPropertyNumber): 2021-08-24 Yusuke Suzuki [JSC] Add Intl Enumeration APIs https://bugs.webkit.org/show_bug.cgi?id=214795 Reviewed by Ross Kirsling. This patch implements Intl enumeration API[1] which is in stage-3. Supported keys are, "calendar", "collation", "currency", "numberingSystem", "timeZone", and "unit". [1]: https://github.com/tc39/proposal-intl-enumeration * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::localeData): (JSC::IntlDateTimeFormat::initializeDateTimeFormat): * runtime/IntlLocale.cpp: (JSC::createArrayFromStringVector): Deleted. * runtime/IntlNumberFormat.cpp: (JSC::sanctionedSimpleUnitIdentifier): * runtime/IntlObject.cpp: (JSC::IntlObject::finishCreation): (JSC::mapICUCalendarKeywordToBCP47): (JSC::availableCalendars): (JSC::availableCollations): (JSC::availableCurrencies): (JSC::availableNumberingSystems): (JSC::canonicalizeTimeZoneNameFromICUTimeZone): (JSC::availableTimeZones): (JSC::availableUnits): (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::createArrayFromStringVector): * runtime/IntlObject.h: * runtime/OptionsList.h: 2021-08-24 Keith Miller (r281473) stress/for-in-has-own-property-shouldnt-flush-registers.js failing on Debug https://bugs.webkit.org/show_bug.cgi?id=229448 Reviewed by Mark Lam. Add missing exception checks. * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): 2021-08-24 Commit Queue Unreviewed, reverting r281321. https://bugs.webkit.org/show_bug.cgi?id=229449 causes crashes on ARM64 Reverted changeset: "Add some offlineasm enhancements." https://bugs.webkit.org/show_bug.cgi?id=229332 https://commits.webkit.org/r281321 2021-08-23 Saam Barati Disable peephole optimizations in the byte code generator after rewriting instructions for for-in https://bugs.webkit.org/show_bug.cgi?id=229420 Reviewed by Keith Miller. The final instruction in a for-in loop might be the get by val that we're rewriting because there was an escape. We won't ever actually do peephole optimizations on this get_by_val today, but it breaks some bookkeeping that the bytecode generator does. This patch makes sure the bookkeeping is up to date. * bytecompiler/BytecodeGenerator.cpp: (JSC::ForInContext::finalize): 2021-08-23 Saam Barati compileEnumeratorHasProperty uses flushRegisters incorrectly https://bugs.webkit.org/show_bug.cgi?id=229412 Reviewed by Keith Miller. We were calling flushRegisters() inside code that isn't always runs inside the EnumeratorInByVal/EnumeratorHasOwnProperty nodes. That is a violation of how flushRegisters() must be used, since flushRegisters() updates global register allocation state, and therefore must run each time a node is run. To fix, we move flushRegisters() before the code starts emitting branches. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileEnumeratorHasProperty): 2021-08-23 Yusuke Suzuki [JSC] emitArrayProfilingSiteWithCell should not load indexingType unnecessarily https://bugs.webkit.org/show_bug.cgi?id=229396 Reviewed by Saam Barati. emitArrayProfilingSiteWithCell is always loading indexingType after profiling a cell. But (possibly) this is old code, and there is no reason to do that. This patch removes it. * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::emitArrayProfilingSiteWithCell): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_in_by_val): (JSC::JIT::emit_op_enumerator_get_by_val): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_in_by_val): 2021-08-22 Yusuke Suzuki [JSC] Remove already-shipped wasm option flags https://bugs.webkit.org/show_bug.cgi?id=229386 Reviewed by Ross Kirsling. This patch removes some wasm option flags which are already shipped. * runtime/OptionsList.h: * wasm/WasmFormat.h: (JSC::Wasm::isValueType): * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::parseExpression): (JSC::Wasm::FunctionParser::parseUnreachableExpression): * wasm/WasmOperations.cpp: (JSC::Wasm::JSC_DEFINE_JIT_OPERATION): * wasm/WasmParser.h: (JSC::Wasm::Parser::parseBlockSignature): * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseType): (JSC::Wasm::SectionParser::parseElement): (JSC::Wasm::SectionParser::parseData): (JSC::Wasm::SectionParser::parseDataCount): * wasm/js/JSWebAssembly.cpp: (JSC::JSWebAssembly::finishCreation): * wasm/js/WebAssemblyGlobalConstructor.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * wasm/js/WebAssemblyTablePrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): 2021-08-22 Yusuke Suzuki [JSC] Remove already-shipped JS feature flags https://bugs.webkit.org/show_bug.cgi?id=229387 Reviewed by Ross Kirsling. These features are already shipped. So removing these runtime flags to clean up source code and remove untested path. * API/JSObjectRef.cpp: (JSObjectMakeError): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallValueNode::emitBytecode): * parser/Lexer.cpp: (JSC::Lexer::lexWithoutClearingLineTerminator): * parser/Parser.cpp: (JSC::Parser::parseInner): (JSC::Parser::parseForStatement): (JSC::Parser::parseClass): (JSC::Parser::parseBinaryExpression): (JSC::Parser::parseGetterSetter): (JSC::Parser::parsePrimaryExpression): (JSC::Parser::parseUnaryExpression): * runtime/AggregateErrorConstructor.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/ErrorConstructor.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/JSGlobalObject.h: * runtime/NativeErrorConstructor.cpp: (JSC::NativeErrorConstructor::constructImpl): (JSC::NativeErrorConstructor::callImpl): * runtime/Options.cpp: (JSC::Options::recomputeDependentOptions): * runtime/OptionsList.h: * wasm/js/WebAssemblyCompileErrorConstructor.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * wasm/js/WebAssemblyLinkErrorConstructor.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): 2021-08-22 Commit Queue Unreviewed, reverting r280984 and r280996. https://bugs.webkit.org/show_bug.cgi?id=229384 Speedometer2 0.3-0.5% regression Reverted changesets: "Update ARM64EHash" https://bugs.webkit.org/show_bug.cgi?id=228962 https://commits.webkit.org/r280984 "Refactor some ARM64EHash code." https://bugs.webkit.org/show_bug.cgi?id=229054 https://commits.webkit.org/r280996 2021-08-21 Yusuke Suzuki [JSC] Remove Intl runtime feature flags for already shipped ones https://bugs.webkit.org/show_bug.cgi?id=229371 Reviewed by Ross Kirsling. Since they are already shipped, we should remove these runtime flags. * builtins/DatePrototype.js: (globalPrivate.toDateTimeOptionsAnyAll): (globalPrivate.toDateTimeOptionsTimeTime): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * runtime/IntlDateTimeFormat.cpp: (JSC::toDateTimeOptionsAnyDate): (JSC::IntlDateTimeFormat::initializeDateTimeFormat): (JSC::IntlDateTimeFormat::resolvedOptions const): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototype::finishCreation): * runtime/OptionsList.h: 2021-08-21 Yusuke Suzuki [JSC] Intl.DisplayNames v2 https://bugs.webkit.org/show_bug.cgi?id=227832 Reviewed by Ross Kirsling. This patch implements Intl.DisplayNames v2[1]. Newly added names are calendar names and date time field names. For the language name, language display option is added. [1]: https://github.com/tc39/intl-displaynames-v2 * runtime/CommonIdentifiers.h: * runtime/IntlCache.cpp: (JSC::IntlCache::getFieldDisplayName): * runtime/IntlCache.h: * runtime/IntlDisplayNames.cpp: (JSC::IntlDisplayNames::initializeDisplayNames): (JSC::IntlDisplayNames::of const): (JSC::IntlDisplayNames::resolvedOptions const): (JSC::IntlDisplayNames::typeString): (JSC::IntlDisplayNames::languageDisplayString): * runtime/IntlDisplayNames.h: * runtime/IntlObject.cpp: (JSC::isUnicodeLocaleIdentifierType): (JSC::canonicalizeUnicodeLocaleID): (JSC::canonicalizeLocaleList): (JSC::defaultLocale): (JSC::mapBCP47ToICUCalendarKeyword): (JSC::mapICUCollationKeywordToBCP47): (JSC::canonicalizeLanguageTag): Deleted. * runtime/IntlObject.h: 2021-08-21 Yusuke Suzuki [JSC] Intl Locale Info https://bugs.webkit.org/show_bug.cgi?id=227830 Reviewed by Ross Kirsling. This patch implements Intl.Locale's extension (Intl Locale Info proposal)[1], which is already stage 3. Intl.Locale#{calendars,collations,hourCycles,numberingSystems,timeZones} can return array of preferred configuration for the given locale. And Intl.Locale#textInfo can return text layout direction and Intl.Locale#weekInfo can return weekday information (e.g. when weekend starts). [1]: https://github.com/tc39/proposal-intl-locale-info * runtime/IntlLocale.cpp: (JSC::createArrayFromStringVector): (JSC::IntlLocale::calendars): (JSC::IntlLocale::collations): (JSC::IntlLocale::hourCycles): (JSC::IntlLocale::numberingSystems): (JSC::IntlLocale::timeZones): (JSC::IntlLocale::textInfo): (JSC::IntlLocale::weekInfo): * runtime/IntlLocale.h: * runtime/IntlLocalePrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): 2021-08-21 Yusuke Suzuki [JSC] Extend Intl TimeZoneName Option https://bugs.webkit.org/show_bug.cgi?id=227831 Reviewed by Ross Kirsling. https://github.com/tc39/proposal-intl-extend-timezonename This patch implements Extend Intl TimeZoneName proposal, which adds "shortOffset", "longOffset", "shortGeneric", "longGeneric" timeZoneName variants. * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::setFormatsFromPattern): (JSC::IntlDateTimeFormat::initializeDateTimeFormat): (JSC::IntlDateTimeFormat::timeZoneNameString): * runtime/IntlDateTimeFormat.h: 2021-08-21 Yusuke Suzuki [JSC] Enable String,TypedArray#at https://bugs.webkit.org/show_bug.cgi?id=229354 Reviewed by Saam Barati. Enable String and TypedArray's `at` method. * runtime/OptionsList.h: 2021-08-21 Yusuke Suzuki [JSC] Enable Array#findLast method https://bugs.webkit.org/show_bug.cgi?id=229355 Reviewed by Saam Barati. This patch enables Array#findLast and Array#findLastIndex methods. * runtime/ArrayPrototype.cpp: Order of unscopables is alphabet ordering (https://tc39.es/ecma262/#sec-array.prototype-@@unscopables) (JSC::ArrayPrototype::finishCreation): * runtime/OptionsList.h: 2021-08-20 Yusuke Suzuki [JSC] Simplify moveIntsToDouble https://bugs.webkit.org/show_bug.cgi?id=229351 Reviewed by Saam Barati. MacroAssembler::moveIntsToDouble required scratch FPRReg. But it was only required for MacroAssemblerX86, and it is already removed. This means that we no longer need this scratch FPRReg. This change makes a lot of IC code, property access code simpler. This patch removes that scratch FPRReg, and removed scratch FPRReg of many arithmetic ICs. This patch is important for PutByVal modern IC since some of property access requires FPRReg because of MacroAssembler::moveIntsToDouble, and it requires adding new m_scratch2FPR to AccessCase. But after this simplification, this is no longer necessary. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::moveIntsToDouble): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::moveIntsToDouble): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileDoubleRep): (JSC::DFG::SpeculativeJIT::emitUntypedOrBigIntRightShiftBitOp): (JSC::DFG::SpeculativeJIT::compileValueAdd): (JSC::DFG::SpeculativeJIT::compileValueSub): (JSC::DFG::SpeculativeJIT::compileMathIC): (JSC::DFG::SpeculativeJIT::compileValueNegate): (JSC::DFG::SpeculativeJIT::compileValueMul): (JSC::DFG::SpeculativeJIT::speculateRealNumber): (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::unboxDouble): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitConvertValueToBoolean): (JSC::AssemblyHelpers::branchIfValue): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::unboxDoubleNonDestructive): (JSC::AssemblyHelpers::unboxDouble): * jit/JITAddGenerator.cpp: (JSC::JITAddGenerator::generateFastPath): * jit/JITAddGenerator.h: (JSC::JITAddGenerator::JITAddGenerator): * jit/JITArithmetic.cpp: (JSC::JIT::emitRightShiftFastPath): (JSC::JIT::emitMathICFast): * jit/JITDivGenerator.cpp: (JSC::JITDivGenerator::loadOperand): * jit/JITMulGenerator.cpp: (JSC::JITMulGenerator::generateInline): (JSC::JITMulGenerator::generateFastPath): * jit/JITMulGenerator.h: (JSC::JITMulGenerator::JITMulGenerator): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitFloatTypedArrayPutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitGenericContiguousPutByVal): * jit/JITRightShiftGenerator.cpp: (JSC::JITRightShiftGenerator::generateFastPath): * jit/JITRightShiftGenerator.h: (JSC::JITRightShiftGenerator::JITRightShiftGenerator): * jit/JITSubGenerator.cpp: (JSC::JITSubGenerator::generateInline): (JSC::JITSubGenerator::generateFastPath): * jit/JITSubGenerator.h: (JSC::JITSubGenerator::JITSubGenerator): 2021-08-20 Yusuke Suzuki [JSC] Remove unnecessary moves in Yarr's sub32 / add32 related code https://bugs.webkit.org/show_bug.cgi?id=228813 Reviewed by Mark Lam. This patch adds three operand sub32 to X64 masm so that we can use it in all masms. We use add32 and sub32 in YarrJIT to remove unnecessary mov instructions in ARM64. * assembler/MacroAssembler.h: (JSC::MacroAssembler::sub32): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::sub32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::sub32): * assembler/testmasm.cpp: (JSC::testSub32ArgImm): * yarr/YarrJIT.cpp: 2021-08-20 Yusuke Suzuki [JSC] Remove MacroAssemblerX86 https://bugs.webkit.org/show_bug.cgi?id=229331 Reviewed by Mark Lam. This patch removes MacroAssemblerX86, which allows simplifying some 32bit MacroAssembler code in a subsequent patch. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssembler.h: * assembler/MacroAssemblerX86.h: Removed. 2021-08-20 Mikhail R. Gadelha Fix DFG compilation of StringCharAt in 32 bits jsc debug build https://bugs.webkit.org/show_bug.cgi?id=229293 Reviewed by Keith Miller. In SpeculativeJIT::compileGetByValOnString the format can be either DataFormatJS or DataFormatCell so assert either value when compiling it in 32 bits. It's the same assert already present in the DFG 64 bits counterpart * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2021-08-20 Mark Lam Add some offlineasm enhancements. https://bugs.webkit.org/show_bug.cgi?id=229332 rdar://82163923 Reviewed by Keith Miller. 1. Enhance "include" offlineasm Instruction to always attempt to include an asm file from /usr/local/include/WebKitAdditions/ first. If the specified file is not available there, then it will attempt to include the file from the same directory as the current source file (which in practice, means Source/JavaScriptCore/llint/). 2. Enhance "include" offlineasm Instruction to allow an optional file to be included if it exists. For example, the following offlineasm code: include? LowLevelInterpreterAdditions ... will attempt to include a file LowLevelInterpreterAdditions.asm. If the file does not exist, this will be a no-op. Note: the "?" after the "include" means the include is optional. 3. Enhanced "emit" offlineasm Instruction to be able to take more than one operand. "emit" used to just copy the string operand that follows into the generated LLIntAssembly.h. Now, "emit" can take multiple comma separated operands, and will concatenate all the operands. Additionally, "emit" can now take a LocalLabelReference as an operand. For example, this offline asm code: emit "b ", .done ... .done: ... will generate this inline asm code in LLIntAssembly.h: "b " LOCAL_LABEL_STRING(_offlineasm_someLabel_done) "\n" This makes it easier to emit branches to local labels. 4. Also fixed LLInt code alignment for ARM_THUMB2 and ARM64. Previously, it was aligned using ".align 4" which means aligned on a 4 instruction boundary. Note: the interpretation of .align varies for different target CPU architectures. Now, we do the alignment using ".balign 4" which means align on a 4 byte boundary. This is the intended alignment because ARM64 instruction size is 4 bytes, and ARM_THUMB2 instruction size is either 2 bytes or 4 bytes. Using .align before was potentially wasting some code space. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: * offlineasm/ast.rb: * offlineasm/parser.rb: 2021-08-20 Mark Lam Reduce StructureID entropy bits to 5 to make room for more StructureIDs. https://bugs.webkit.org/show_bug.cgi?id=229326 rdar://60141624 Reviewed by Yusuke Suzuki. * runtime/StructureIDTable.h: 2021-08-19 Tim Nguyen Implement ::backdrop pseudo element https://bugs.webkit.org/show_bug.cgi?id=227801 Reviewed by Antti Koivisto. This adds UA styles, RenderTreeBuilder support and WebInspector support for ::backdrop. Some imported blink tests now start passing, some still need proper top layer support. * inspector/protocol/CSS.json: 2021-08-18 Yusuke Suzuki [JSC] Remove op_has_indexed_property related code https://bugs.webkit.org/show_bug.cgi?id=229271 Reviewed by Saam Barati. After our new for-in protocol, op_has_indexed_property is removed. As a result, we can remove many ByValInfo code that is used only for op_has_indexed_property. * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::emitLoadForArrayMode): Deleted. * jit/JITOpcodes.cpp: (JSC::JIT::privateCompileHasIndexedProperty): Deleted. * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileHasIndexedProperty): Deleted. * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitDoubleLoad): Deleted. (JSC::JIT::emitContiguousLoad): Deleted. (JSC::JIT::emitArrayStorageLoad): Deleted. 2021-08-18 Michael Catanzaro REGRESSION(r280382): [GTK] 2.33.3 does not build with gtk-doc enabled, installs broken pkg-config files https://bugs.webkit.org/show_bug.cgi?id=229152 Reviewed by Philippe Normand. * PlatformGTK.cmake: * javascriptcoregtk.pc.in: 2021-08-17 Saam Barati Add an option for canonicalizePrePostIncrements https://bugs.webkit.org/show_bug.cgi?id=229211 Reviewed by Mark Lam. The current phase has bugs. Let's disable it for now until the bugs are fixed. See discussion about the bugs I spotted in: https://bugs.webkit.org/show_bug.cgi?id=228538 * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/testb3_3.cpp: (addShrTests): * runtime/OptionsList.h: 2021-08-16 Mark Lam Ensure that unused LLInt opcodes are not inadvertently used. https://bugs.webkit.org/show_bug.cgi?id=229161 Reviewed by Robin Morisset. The op macro is used for generating LLInt asm code for some entry points to the LLInt, where we don't need 16 bits and 32 bit wide versions of the entry point. For example, we use it for llint_program_prologue. Note that llint_program_prologue is generated using: op(llint_program_prologue, macro () ... where op is: macro op(l, fn) commonOp(l, macro () end, macro (size) size(fn, macro() end, macro() end, macro(gen) gen() end) # ^ ^----- wide32 generator # `------------------ wide16 generator end) end Note that the generators for the wide16 and wide32 versions of the entry point currently emit nothing. As a result, if we ever have a bug that ends up dispatching to llint_program_prologue_wide16 or llint_program_prologue_wide32, we'll end up falling thru to llint_module_program_prologue, which just happens to be the entry point positioned after those labels. This patch adds breakpoints in those 2 unused generators so that we won't inadvertently execute code for something else. * llint/LowLevelInterpreter.asm: 2021-08-15 Yijia Huang [ARM64] Add Pre/Post-Indexed Address Mode to Air for ARM64 (Store Instruction) https://bugs.webkit.org/show_bug.cgi?id=228538 Reviewed by Filip Pizlo. The previous patch has introduced the pre/post-index address mode for Load instruction, which benefits loop program. Here, this patch adds the corresponding mode for Store instruction. Store Register (immediate) stores a word or a doubleword from a register to memory. The address that is used for the store is calculated from a base register and an immediate offset. ###################################### ## Pre-Index Address Mode For Store ## ###################################### STR Wt, [Xn, #imm]! In B3 Reduction Strength, since we have this reduction rule: Turns this: Store(value, Add(address, offset1), offset = offset2) Into this: Store(value, address, offset = offset1 + offset2) The equivalent pattern is: address = Add(base, offset) ... memory = Store(value, base, offset) Here, we only consider the pattern: address = Add(base, offset) memory = Store(value, base, offset) And, this patch directly treats it as the canonical form. Ideally, we should move memory to just after the address like what we did for PreIndex Load in the previous patch. But, we cannot provide a better way to do that since the value may be used between address and memory. To move value upward, we must move all descendants of the value along with it to prevent B3 IR index violations, which is risky and expensive. Next, lower to Air: Move %base, %address Move %value, (%address, prefix(offset)) ###################################### ## Post-Index Address Mode For Load ## ###################################### STR Wt, [Xn], #imm Then, the equivalent pattern is: memory = Store(value, base, 0) ... address = Add(base, offset) First, we convert it to the canonical form: newOffset = Constant newAddress = Add(base, offset) memory = Store(value, base, 0) // move the offset and address to just before the memory ... offset = Identity(newOffset) address = Identity(newAddress) Next, lower to Air: Move %base, %newAddress Move %value, (%newAddress, postfix(offset)) ############################################## ## Test for Pre/Post-Increment Address Mode ## ############################################## B3 IR: ------------------------------------------------------ Int64 b@0 = ArgumentReg(%x0) Int64 b@1 = ArgumentReg(%x1) Int64 b@2 = Const64(8) Int64 b@3 = Add(b@0, $8(b@2)) Void b@4 = Store(b@1, b@3, ControlDependent|Writes:Top) Void b@5 = Return(b@3, Terminal) ------------------------------------------------------ W/O Pre-Increment Address Mode: ------------------------------------------------------ Move %x0, %x2, b@0 Add64 $8, %x2, %x0, b@3 Move %x1, 8(%x2), b@4 Ret64 %x0, b@5 ------------------------------------------------------ W/ Pre-Increment Address Mode: ------------------------------------------------------ MoveWithIncrement64 %x1, (%x0,Pre($8)), b@4 Ret64 %x0, b@5 ------------------------------------------------------ B3 IR: ------------------------------------------------------ Int64 b@0 = ArgumentReg(%x0) Int64 b@1 = ArgumentReg(%x1) Void b@2 = Store(b@1, b@0, ControlDependent|Writes:Top) Int64 b@3 = Const64(8) Int64 b@4 = Add(b@0, $8(b@3)) Void b@5 = Return(b@4, Terminal) ------------------------------------------------------ W/O Post-Increment Address Mode: ------------------------------------------------------ Move %x1, (%x0), b@2 Add64 $8, %x0, %x0, b@4 Ret64 %x0, b@5 ------------------------------------------------------ W/ Post-Increment Address Mode: ------------------------------------------------------ MoveWithIncrement64 %x1, (%x0,Post($8)), b@2 Ret64 %x0, b@5 ------------------------------------------------------ * b3/B3CanonicalizePrePostIncrements.cpp: (JSC::B3::canonicalizePrePostIncrements): * b3/B3LowerToAir.cpp: * b3/testb3.h: * b3/testb3_3.cpp: (testStorePreIndex32): (testStorePreIndex64): (testStorePostIndex32): (testStorePostIndex64): (addShrTests): 2021-08-13 Keith Miller EnumeratorNextUpdatePropertyName always needs to be able to handle IndexedMode https://bugs.webkit.org/show_bug.cgi?id=229087 Reviewed by Filip Pizlo. Right now, this operation incorrectly assumes that EnumeratorNextUpdateIndexAndMode will guarantee the mode matches the seen mode set. But no speculation is guaranteed and adding such a guarantee would require adding checkpoints, which is likely not worth it. Instead, this patch just makes sure we always handle the allocation for IndexedMode. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdatePropertyName): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): 2021-08-12 Mark Lam Refactor some ARM64EHash code. https://bugs.webkit.org/show_bug.cgi?id=229054 Reviewed by Keith Miller and Robin Morisset. This patch only refactors ARM64EHash code by moving some methods into the private section, and removing some unneeded static_casts. Verified with a diff of `otool -tv` dumps of the built JavaScriptCore binaries, that there are no diffs in the generated code from this change. * assembler/AssemblerBuffer.h: (JSC::ARM64EHash::ARM64EHash): (JSC::ARM64EHash::update): (JSC::ARM64EHash::makeDiversifier): (JSC::ARM64EHash::nextValue): (JSC::ARM64EHash::bitsForDiversifier): (JSC::ARM64EHash::currentHash): 2021-08-12 Saam Barati Update ARM64EHash https://bugs.webkit.org/show_bug.cgi?id=228962 Reviewed by Mark Lam. * assembler/AssemblerBuffer.h: (JSC::ARM64EHash::makeDiversifier): (JSC::ARM64EHash::nextValue): (JSC::ARM64EHash::bitsForDiversifier): (JSC::ARM64EHash::currentHash): (JSC::ARM64EHash::setUpdatedHash): (JSC::ARM64EHash::ARM64EHash): (JSC::ARM64EHash::update): (JSC::ARM64EHash::finalize): (JSC::AssemblerBuffer::AssemblerBuffer): (JSC::AssemblerBuffer::putIntegralUnchecked): (JSC::AssemblerBuffer::hash const): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): 2021-08-11 Yusuke Suzuki WTFCrash in JSC::Lexer::append8 https://bugs.webkit.org/show_bug.cgi?id=228982 Reviewed by Mark Lam. sourceURL / sourceMapURL directive should not assume Latin1 characters. * parser/Lexer.cpp: (JSC::Lexer::parseCommentDirectiveValue): 2021-08-10 Keith Miller CallFrame::returnPC should untag the return address before passing it to ReturnAddressPtr https://bugs.webkit.org/show_bug.cgi?id=228931 Reviewed by Mark Lam. Right now current debugging code expects that the JS return PC on the stack is already unsigned. This is not true on arm64e. This patch now properly unsigns the return PC before passing it to the ReturnAddressPC constructor. * assembler/MacroAssemblerCodeRef.h: (JSC::ReturnAddressPtr::fromTaggedPC): * interpreter/AbstractPC.cpp: (JSC::AbstractPC::AbstractPC): * interpreter/AbstractPC.h: (JSC::AbstractPC::AbstractPC): (JSC::AbstractPC::jitReturnAddress const): * interpreter/CallFrame.h: (JSC::CallFrame::returnPC const): 2021-08-10 Kimmo Kinnunen Scripts/generate-derived-sources.sh: line 19: [: binary operator expected while building Source/WebKit https://bugs.webkit.org/show_bug.cgi?id=228908 Reviewed by Per Arne Vollan. * Scripts/generate-derived-sources.sh: Quote the use of CC so that future copy-paste does not make the same mistake as this bug. 2021-08-09 Yusuke Suzuki [JSC] super-Latin1 white space and line terminator after regular expression literal misinterpreted as flags https://bugs.webkit.org/show_bug.cgi?id=227944 Reviewed by Alexey Shvayka. There are non-Latin1 white-spaces and line-terminators, but Lexer::scanRegExp's code did not assume that. As a result, if there is a non-Latin1 white-spaces or line-terminators after RegExp, we raise SyntaxError while this is valid. This patch fixes that. * parser/Lexer.cpp: (JSC::Lexer::scanRegExp): 2021-08-09 Michael Catanzaro Fix yet another -Wreturn-type warning https://bugs.webkit.org/show_bug.cgi?id=228928 Unreviewed. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByValImpl): 2021-08-09 Yijia Huang [ARM64] Clean up and fix Pre/Post-Indexed Address Mode to Air for ARM64 (Load Instruction) https://bugs.webkit.org/show_bug.cgi?id=228890 Reviewed by Keith Miller. This patch cleans up and does minor fix to the previous patch (https://bugs.webkit.org/show_bug.cgi?id=228047). For the modifications in b3/B3Generate.cpp and b3/B3CanonicalizePrePostIncrements.cpp, we need to convert post-index candidates to the canonical form. So, the address value needs to be moved immediately before the load. This is subject to the dominance constraints that add must be controlled equivalent to the load. So, similarly, if we need to move the offset to just before the load, the dominance constraints must be satisfied. Since it is a constant value, a better approach is to add a new constant value before the memory value. Then, eliminate the dead code. There is a bug in b3/B3CanonicalizePrePostIncrements.cpp. The insertionSet.execute(BasicBlock) will reorder value indexes in the basic block. So, we should re-search for the value index in the block every time after the execution. In b3/B3LowerToAir.cpp, we need m_locked checks on address and base values. If they are already locked, there is no need to convert the Load instruction to the pre/post-increment form. * b3/B3CanonicalizePrePostIncrements.cpp: (JSC::B3::canonicalizePrePostIncrements): * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3LowerToAir.cpp: * b3/air/AirArg.h: (JSC::B3::Air::Arg::isValidIncrementIndexForm): (JSC::B3::Air::Arg::isValidForm const): (JSC::B3::Air::Arg::isValidPreIndexForm): Deleted. (JSC::B3::Air::Arg::isValidPostIndexForm): Deleted. * b3/air/opcode_generator.rb: 2021-08-09 Keith Miller Revert bad assert about the number of upsilons going into a phi https://bugs.webkit.org/show_bug.cgi?id=228922 Reviewed by Yusuke Suzuki. This assert was invalid because we sometimes emit unreachable phis that don't have any incoming upsilons. Specifically for MultiGetByOffset. * ftl/FTLOutput.h: (JSC::FTL::Output::phi): 2021-08-09 Michael Catanzaro Adding missing REFERENCED_FROM_ASM annotations to facilitate LTO https://bugs.webkit.org/show_bug.cgi?id=228865 Reviewed by Yusuke Suzuki. When investigating why WebKitGTK fails to build with LTO (link-time optimization) enabled, one of the GCC developers noticed that we are missing __attribute__ (("used")) on several C++ functions declared in LLIntSlowPaths.h and WasmSlowPaths.h that are called only from asm. Without this attribute, GCC assumes the functions are unused and drops them, then linking fails because they really are used. * llint/LLIntSlowPaths.h: * wasm/WasmSlowPaths.h: 2021-08-07 Michael Catanzaro Fix ODR violations in JSC https://bugs.webkit.org/show_bug.cgi?id=228876 Reviewed by Yusuke Suzuki. When built with LTO enabled, GCC will warn about violations of C++'s one-definition rule. JSC currently has two violations. The first is JSC::SpeciesConstructResult, which has two different declarations, one in ArrayPrototype.cpp and the other in JSArrayBufferPrototype.cpp. I decided to change the version in ArrayPrototype.cpp to make the declarations match. The next problem is JSC::SignalContext. We have two different versions of this struct, one in VMTraps.cpp and the other in SigillCrashAnalyzer.cpp. In this case, I decided to change the one in VMTraps.cpp from JSC::SignalContext to JSC::VMTraps::SignalContext. * runtime/ArrayPrototype.cpp: * runtime/VMTraps.cpp: (JSC::VMTraps::tryInstallTrapBreakpoints): * runtime/VMTraps.h: 2021-08-07 Keith Miller for-in should only emit one loop in bytecode https://bugs.webkit.org/show_bug.cgi?id=227989 Reviewed by Yusuke Suzuki. This patch redesigns how we implement for-in loops. Before this patch we would emit three copies of the for-in loop body. One for the indexed properties, one for the named-own properties, and one for generic properties (anything else). This had a couple of problems. Firstly, it meant bytecode size grew exponentially to number of nested for-in loops. This in turn meant DFG/FTL compilation took much longer. Going off our experience with fast for-of, this patch turns for-in loops specializations into a "fused" opcode that internally switches on the enumeration mode it currently sees. For example, if we are enumerating an own-named property, the new enumerator_get_by_val bytecode will check the enumerator cell's cached structure matches the base's then load the property offset directly. There are four new opcodes this patch adds, which replace the various operations we had for the specialized loops previously. The new opcodes are EnumeratorGetByVal, EnumeratorInByVal, EnumeratorHasOwnProperty, and EnumeratorNext. The first three correspond to GetByVal, InByVal, and HasOwnProperty respectively. The EnumeratorNext opcode has three results in bytecode, the next enumeration value's mode, the index of the property name, and the property name string itself. When enumeration is done EnumeratorNext returns JS null as the property name string. Since the DFG doesn't support tuples yet this opcode is spilt into four new nodes. The first computes the updated index and mode for the next enumeration key, which is encoded into a single JS number. Then there are two nodes that extract the mode and index. Finally, the last new node produces the property name string or null based on the extracted mode and index. Since, in most benchmarks, any given enumeration opcode tends to profile exactly one enumeration mode. This patch focuses primarily on reimplementing all the optimizations we have for any one specific mode. This means there are still potential optimizations for the multi-mode flavors of each new opcode. The main optimizations implemented for each new opcode are: EnumeratorNext: 1) IndexedMode loops are loaded and checked for presence inline (DFG/FTL). 2) NamedMode is computed inline as long as the cached structure on the enumerator cell matches the base (Baseline+). This can only differ if there's a transition. 3) property names are extracted from the cached buffer inline (Baseline+). EnumeratorGetByVal: EnumeratorInByVal: EnumeratorHasOwnProperty: 1) IndexedMode has all the optimizations of a normal XByVal on indexed properties (DFG/FTL). 2) NamedMode will extract the value directly from the inline/out-of-line offset if the structure matches the enumerator's (Baseline+). There are also a few interesting changes worth mentioning here: 1) If a for-in loop would produce an empty enumerator we now always return the VMs empty enumerator. This has two benefits, most importantly, it distingishes between an unprofiled for-in loop and empty enumeration, which prevents OSR exit loops. Also, it means that the various Enumerator opcodes no longer need to handle undefined/null when `toObject`ing the base value. 2) The enumerator now contains a bit set of all the modes it will produce. This removes a few extra branches when speculating on the modes we will see in EnumeratorNext. 3) In the DFG, enumerator GetByVal relies on compileGetByVal to set the result it also passes a prefix callback which emits code after the various cases set up their operands but before code is emitting to help satisfy the branch over register allocation validation. Also, the array mode branch in compileGetByVal passes the data format that it would prefer, which for normal GetByVal is returned. For EnumeratorGetByVal, that preference is completely ignored and it always returns DataFormatJS. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::or8): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::or8): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::rshift64): (JSC::MacroAssemblerX86_64::or8): Deleted. * builtins/BuiltinNames.h: * bytecode/BytecodeList.rb: * bytecode/BytecodeUseDef.cpp: (JSC::computeUsesForBytecodeIndexImpl): (JSC::computeDefsForBytecodeIndexImpl): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecode/LinkTimeConstant.h: * bytecode/Opcode.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::recordHasOwnPropertyInForInLoop): (JSC::BytecodeGenerator::emitInByVal): (JSC::BytecodeGenerator::emitGetByVal): (JSC::BytecodeGenerator::emitEnumeratorNext): (JSC::BytecodeGenerator::emitEnumeratorHasOwnProperty): (JSC::BytecodeGenerator::pushForInScope): (JSC::BytecodeGenerator::popForInScope): (JSC::rewriteOp): (JSC::ForInContext::finalize): (JSC::BytecodeGenerator::findForInContext): (JSC::BytecodeGenerator::recordHasOwnStructurePropertyInForInLoop): Deleted. (JSC::BytecodeGenerator::emitGetEnumerableLength): Deleted. (JSC::BytecodeGenerator::emitHasEnumerableIndexedProperty): Deleted. (JSC::BytecodeGenerator::emitHasEnumerableStructureProperty): Deleted. (JSC::BytecodeGenerator::emitHasEnumerableProperty): Deleted. (JSC::BytecodeGenerator::emitHasOwnStructureProperty): Deleted. (JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName): Deleted. (JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName): Deleted. (JSC::BytecodeGenerator::emitToIndexString): Deleted. (JSC::BytecodeGenerator::pushIndexedForInScope): Deleted. (JSC::BytecodeGenerator::popIndexedForInScope): Deleted. (JSC::BytecodeGenerator::pushStructureForInScope): Deleted. (JSC::BytecodeGenerator::popStructureForInScope): Deleted. (JSC::StructureForInContext::finalize): Deleted. (JSC::IndexedForInContext::finalize): Deleted. (JSC::BytecodeGenerator::findStructureForInContext): Deleted. * bytecompiler/BytecodeGenerator.h: (JSC::ForInContext::isValid const): (JSC::ForInContext::invalidate): (JSC::ForInContext::local const): (JSC::ForInContext::propertyName const): (JSC::ForInContext::propertyOffset const): (JSC::ForInContext::enumerator const): (JSC::ForInContext::mode const): (JSC::ForInContext::ForInContext): (JSC::ForInContext::bodyBytecodeStartOffset const): (JSC::ForInContext::type const): Deleted. (JSC::ForInContext::isIndexedForInContext const): Deleted. (JSC::ForInContext::isStructureForInContext const): Deleted. (JSC::ForInContext::asIndexedForInContext): Deleted. (JSC::ForInContext::asStructureForInContext): Deleted. (JSC::StructureForInContext::StructureForInContext): Deleted. (JSC::StructureForInContext::index const): Deleted. (JSC::StructureForInContext::property const): Deleted. (JSC::StructureForInContext::enumerator const): Deleted. (JSC::StructureForInContext::baseVariable const): Deleted. (JSC::StructureForInContext::addGetInst): Deleted. (JSC::StructureForInContext::addInInst): Deleted. (JSC::StructureForInContext::addHasOwnPropertyJump): Deleted. (JSC::IndexedForInContext::IndexedForInContext): Deleted. (JSC::IndexedForInContext::index const): Deleted. (JSC::IndexedForInContext::addGetInst): Deleted. * bytecompiler/NodesCodegen.cpp: (JSC::HasOwnPropertyFunctionCallDotNode::emitBytecode): (JSC::ForInNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArrayMode.h: (JSC::DFG::ArrayMode::isSaneChain const): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCFAPhase.cpp: (JSC::DFG::CFAPhase::injectOSR): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::setJSArraySaneChainIfPossible): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGMayExit.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): (JSC::DFG::Node::hasStorageChild const): (JSC::DFG::Node::storageChildIndex): (JSC::DFG::Node::hasArrayMode): (JSC::DFG::Node::hasEnumeratorMetadata const): (JSC::DFG::Node::enumeratorMetadata): * dfg/DFGNodeType.h: * dfg/DFGOpInfo.h: (JSC::DFG::OpInfo::OpInfo): * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::SSALoweringPhase::handleNode): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary): (JSC::DFG::SpeculativeJIT::compileGetByValOnString): (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString): (JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol): (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments): (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments): (JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdateIndexAndMode): (JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractIndex): (JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractMode): (JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdatePropertyName): (JSC::DFG::SpeculativeJIT::compileEnumeratorGetByVal): (JSC::DFG::SpeculativeJIT::compileEnumeratorHasProperty): (JSC::DFG::SpeculativeJIT::compileEnumeratorInByVal): (JSC::DFG::SpeculativeJIT::compileEnumeratorHasOwnProperty): (JSC::DFG::SpeculativeJIT::compileHasIndexedProperty): (JSC::DFG::SpeculativeJIT::compileGetEnumerableLength): Deleted. (JSC::DFG::SpeculativeJIT::compileHasEnumerableProperty): Deleted. (JSC::DFG::SpeculativeJIT::compileToIndexString): Deleted. (JSC::DFG::SpeculativeJIT::compileHasEnumerableStructureProperty): Deleted. (JSC::DFG::SpeculativeJIT::compileHasOwnStructurePropertyImpl): Deleted. (JSC::DFG::SpeculativeJIT::compileHasOwnStructureProperty): Deleted. (JSC::DFG::SpeculativeJIT::compileInStructureProperty): Deleted. (JSC::DFG::SpeculativeJIT::compileGetEnumeratorPname): Deleted. (JSC::DFG::SpeculativeJIT::compileGetDirectPname): Deleted. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::allocate): (JSC::DFG::JSValueOperand::regs): (JSC::DFG::JSValueOperand::gpr): (JSC::DFG::StorageOperand::StorageOperand): (JSC::DFG::StorageOperand::~StorageOperand): (JSC::DFG::StorageOperand::emplace): (JSC::DFG::JSValueRegsTemporary::operator bool): (JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compileGetByVal): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileGetByVal): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileGetByValImpl): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAtImpl): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * ftl/FTLOutput.h: (JSC::FTL::Output::phi): * generator/DSL.rb: * interpreter/Register.h: * interpreter/RegisterInlines.h: (JSC::Register::operator=): * jit/AssemblyHelpers.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::privateCompileHasIndexedProperty): (JSC::JIT::emit_op_has_structure_propertyImpl): Deleted. (JSC::JIT::emit_op_has_enumerable_structure_property): Deleted. (JSC::JIT::emit_op_has_own_structure_property): Deleted. (JSC::JIT::emit_op_in_structure_property): Deleted. (JSC::JIT::emit_op_has_enumerable_indexed_property): Deleted. (JSC::JIT::emitSlow_op_has_enumerable_indexed_property): Deleted. (JSC::JIT::emit_op_get_direct_pname): Deleted. (JSC::JIT::emit_op_enumerator_structure_pname): Deleted. (JSC::JIT::emit_op_enumerator_generic_pname): Deleted. * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileHasIndexedProperty): (JSC::JIT::emit_op_has_structure_propertyImpl): Deleted. (JSC::JIT::emit_op_has_enumerable_structure_property): Deleted. (JSC::JIT::emit_op_has_own_structure_property): Deleted. (JSC::JIT::emit_op_in_structure_property): Deleted. (JSC::JIT::emit_op_has_enumerable_indexed_property): Deleted. (JSC::JIT::emitSlow_op_has_enumerable_indexed_property): Deleted. (JSC::JIT::emit_op_get_direct_pname): Deleted. (JSC::JIT::emit_op_enumerator_structure_pname): Deleted. (JSC::JIT::emit_op_enumerator_generic_pname): Deleted. * jit/JITPropertyAccess.cpp: (JSC::JIT::generateGetByValSlowCase): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_enumerator_next): (JSC::JIT::emit_op_enumerator_get_by_val): (JSC::JIT::emitSlow_op_enumerator_get_by_val): (JSC::JIT::emit_enumerator_has_propertyImpl): (JSC::JIT::emit_op_enumerator_in_by_val): (JSC::JIT::emit_op_enumerator_has_own_property): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_enumerator_next): (JSC::JIT::emit_op_enumerator_get_by_val): (JSC::JIT::emitSlow_op_enumerator_get_by_val): (JSC::JIT::emit_op_enumerator_in_by_val): (JSC::JIT::emit_op_enumerator_has_own_property): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::JSC_DEFINE_COMMON_SLOW_PATH): * runtime/CommonSlowPaths.h: * runtime/FileBasedFuzzerAgent.cpp: (JSC::FileBasedFuzzerAgent::getPredictionInternal): * runtime/FileBasedFuzzerAgentBase.cpp: (JSC::FileBasedFuzzerAgentBase::opcodeAliasForLookupKey): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSPropertyNameEnumerator.cpp: (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator): (JSC::JSPropertyNameEnumerator::computeNext): * runtime/JSPropertyNameEnumerator.h: (JSC::propertyNameEnumerator): * runtime/PredictionFileCreatingFuzzerAgent.cpp: (JSC::PredictionFileCreatingFuzzerAgent::getPredictionInternal): 2021-08-06 Yusuke Suzuki Unreviewed, build fix on Debug build https://bugs.webkit.org/show_bug.cgi?id=228810 * yarr/YarrJIT.h: (JSC::Yarr::BoyerMooreBitmap::addCharacters): (JSC::Yarr::BoyerMooreBitmap::addRanges): 2021-08-06 Yusuke Suzuki [JSC] Yarr's character tracking for BoyerMoore search should be more precise https://bugs.webkit.org/show_bug.cgi?id=228810 Reviewed by Saam Barati. We should track up to 2 candidate characters without masking, so that we can search a character without masking. To track candidates, we introduce BoyerMooreCharacterCandidates. We also add support for m_table because m_table can be used for important CharacterClass like `\s`, and still that does not have many character candidates if the mode is Char8. To make `\s` work on Char8 case, we use Char8 / Char16 information to filter characters that never appears in BoyreMoore search bitmap construction. * yarr/YarrJIT.cpp: (JSC::Yarr::BoyerMooreInfo::BoyerMooreInfo): (JSC::Yarr::BoyerMooreInfo::set): (JSC::Yarr::BoyerMooreInfo::addCharacters): (JSC::Yarr::BoyerMooreInfo::addRanges): (JSC::Yarr::BoyerMooreInfo::create): (JSC::Yarr::BoyerMooreInfo::createCandidateBitmap const): * yarr/YarrJIT.h: (JSC::Yarr::BoyerMooreCharacterCandidates::isValid const): (JSC::Yarr::BoyerMooreCharacterCandidates::invalidate): (JSC::Yarr::BoyerMooreCharacterCandidates::isEmpty const): (JSC::Yarr::BoyerMooreCharacterCandidates::size const): (JSC::Yarr::BoyerMooreCharacterCandidates::at const): (JSC::Yarr::BoyerMooreCharacterCandidates::add): (JSC::Yarr::BoyerMooreCharacterCandidates::merge): (JSC::Yarr::BoyerMooreBitmap::characterCandidates const): (JSC::Yarr::BoyerMooreBitmap::add): (JSC::Yarr::BoyerMooreBitmap::addCharacters): (JSC::Yarr::BoyerMooreBitmap::addRanges): (JSC::Yarr::BoyerMooreBitmap::isMaskEffective const): Deleted. 2021-08-05 Mikhail R. Gadelha Assertion failure when checking array in DFG (32 bits) https://bugs.webkit.org/show_bug.cgi?id=228839 Reviewed by Yusuke Suzuki. Since empty values don't pass the cell check in 32 bits, we need to guard the SpecEmpty check to only happen in 64 bits archs * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkArray): 2021-08-05 Robin Morisset REGRESSION (r280507): ASSERTION FAILED: !undominatedPhis.contains(value) in JSC::B3::(anonymous namespace)::Validater::validatePhisAreDominatedByUpsilons() https://bugs.webkit.org/show_bug.cgi?id=228838 Reviewed by Geoffrey Garen. When I added validation of the dominance of Phis by their Upsilons, I checked two things: - There is no path from the entry point to a Phi without going through a corresponding Upsilon (the actual dominance check) - There is no way to execute a Phi twice without going through a corresponding Upsilon in between The second property is not actually true in B3 IR, I had misunderstood that part of the meaning of Phis/Upsilons. So this patch just removes this second check. It has no security/stability/performance implication: this is validation code, which runs automatically in debug mode, but should not run at all on customer machines. * b3/B3Validate.cpp: 2021-08-05 Michael Catanzaro GCC 11 builds should use -Wno-array-bounds, -Wno-nonnull https://bugs.webkit.org/show_bug.cgi?id=228601 Reviewed by Carlos Garcia Campos. * b3/air/AirAllocateRegistersByGraphColoring.cpp: * jit/JITCall.cpp: (JSC::JIT::compileOpCall): 2021-08-05 Zan Dobersek Use reinterpret_cast_ptr in KeywordLookupGenerator, PropertyMapHashTable https://bugs.webkit.org/show_bug.cgi?id=228819 Reviewed by Adrian Perez de Castro. Switch to using reinterpret_cast_ptr in KeywordLookupGenerator (which generates the KeywordLookup.h header) and PropertyMapHashTable, reducing a bit the GCC warning spewage when compiling for targets benefitting from the reinterpret_cast_ptr workaround. * KeywordLookupGenerator.py: * runtime/PropertyMapHashTable.h: (JSC::PropertyTable::table): (JSC::PropertyTable::table const): 2021-08-04 Yijia Huang [ARM64] Fix Zoom black screen during video meeting on Safari https://bugs.webkit.org/show_bug.cgi?id=228776 Reviewed by Saam Barati. The problem (rdar://81434487) reports that Zoom turns to a black screen during the video meeting on Safari. The reproduction of this problem is verified and bisected to the previous patch (https://bugs.webkit.org/show_bug.cgi?id=228057). Previously, we introduce a pattern matching for instruction EON-with-shift on ARM64, where the pattern is d = n ^ ((m ShiftType amount) ^ -1). x = m ShiftType amount y = x ^ -1 z = n ^ y We check canBeInternal() on x but not on y based on the computing cost analysis in that patch, which is totally wrong. If the pattern matching is triggered, then the compiler would not emit the corresponding Air of x after lowering, leading to data corruption or system crash since y depends on x. In the real world example (Zoom video meeting), we find the B3 IR: ... Int32 b@528 = SShr(b@526, $31(b@527), Wasm: {opcode: I32ShrS, location: 0x26b}) Int32 b@529 = BitXor(b@528, $-1(b@144), Wasm: {opcode: I32Xor, location: 0x26e}) ... Int32 b@551 = BitXor(b@446, b@529, Wasm: {opcode: I32Xor, location: 0x28e}) ... After Lowering to Air: ... Not32 %fp, %x2, b@529 ... XorNotRightShift32 %tmp199, %tmp211, $31, %tmp209, b@551 ... Since the implementation of the previous patch does commitInternal() on b@528, the operand of b@529 turns to a frame pointer. To resolve this problem, we should either check canBeInternal() on both b@528 and b@529 or not at all. * b3/B3LowerToAir.cpp: 2021-08-04 Commit Queue Unreviewed, reverting r280609. https://bugs.webkit.org/show_bug.cgi?id=228791 Broke JSC tests on iOS. Reverted changeset: "[ARM64] Use link register instead of pinning a register for materializing big load constants" https://bugs.webkit.org/show_bug.cgi?id=228710 https://commits.webkit.org/r280609 2021-08-03 Yijia Huang [ARM64] Use link register instead of pinning a register for materializing big load constants https://bugs.webkit.org/show_bug.cgi?id=228710 Reviewed by Mark Lam. Previously, we pin a register as a temp for materializing a large constant that cannot fit in Load/Store imm form. This is not efficient since the register allocator has one less register to allocate from. To solve this problem, we should switch to using the link register as the temp on ARM64. * b3/B3Common.cpp: (JSC::B3::linkRegister): (JSC::B3::pinnedExtendedOffsetAddrRegister): Deleted. * b3/B3Common.h: * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: (JSC::B3::Air::callFrameAddr): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): * b3/air/AirLowerStackArgs.cpp: (JSC::B3::Air::lowerStackArgs): 2021-08-02 Yijia Huang Add a new pattern to instruction selector to utilize UMULL supported by ARM64 https://bugs.webkit.org/show_bug.cgi?id=228721 Reviewed by Saam Barati. Unsigned Multiply Long (UMULL) multiplies two 32-bit register values, and writes the result to the destination register. This instruction is an alias of the UMADDL instruction. umull xd wn wm The equivalent pattern is: d = ZExt32(n) * ZExt32(m) Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = Trunc(@0) Int @2 = ArgumentReg(%x1) Int @3 = Trunc(@2) Int @4 = ZExt32(@1) Int @5 = ZExt32(@3) Int @6 = Mul(@4, @5) Void@7 = Return(@6, Terminal) // Old optimized AIR Move %x0, %x0, @4 Move %x1, %x1, @5 Mul %x0, %x1, %x0, @6 Ret %x0, @7 // New optimized AIR MultiplyZeroExtend %x0, %x1, %x0, @6 Ret %x0, @7 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::multiplyZeroExtend32): * assembler/testmasm.cpp: (JSC::testMultiplyZeroExtend32): * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testMulArgs32SignExtend): (testMulArgs32ZeroExtend): * b3/testb3_3.cpp: (addArgTests): 2021-08-02 Yijia Huang Add new patterns to instruction selector to utilize AND/EOR/ORR-with-shift supported by ARM64 https://bugs.webkit.org/show_bug.cgi?id=228675 Reviewed by Saam Barati. Bitwise AND (shifted register) performs a bitwise AND of a register value and an optionally-shifted register value, and writes the result to the destination register. and wd wn wm ShiftType #amount The equivalent pattern is: n & (m ShiftType amount) Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = ArgumentReg(%x1) Int @2 = Const32(63) Int @3 = Shl(@1, $63(@2)) Int @4 = BitAnd(@0, @3) Void@5 = Return(@4, Terminal) // Old optimized AIR Lshift %x1, $63, %x1, @3 And %x0, %x1, %x0, @4 Ret %x0, @5 // New optimized AIR AndLeftShift %x0, %x1, $63, %x0, @4 Ret %x0, @5 Bitwise Exclusive OR (shifted register) performs a bitwise Exclusive OR of a register value and an optionally-shifted register value, and writes the result to the destination register. eor wd wn wm ShiftType #amount The equivalent pattern is: n ^ (m ShiftType amount) Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = ArgumentReg(%x1) Int @2 = Const32(63) Int @3 = Shl(@1, $63(@2)) Int @4 = BitXor(@0, @3) Void@5 = Return(@4, Terminal) // Old optimized AIR Lshift %x1, $63, %x1, @3 Xor %x0, %x1, %x0, @4 Ret %x0, @5 // New optimized AIR XorLeftShift %x0, %x1, $63, %x0, @4 Ret %x0, @5 Bitwise OR (shifted register) performs a bitwise (inclusive) OR of a register value and an optionally-shifted register value, and writes the result to the destination register. orr wd wn wm ShiftType #amount The equivalent pattern is: n | (m ShiftType amount) Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = ArgumentReg(%x1) Int @2 = Const32(63) Int @3 = Shl(@1, $63(@2)) Int @4 = BitOr(@0, @3) Void@5 = Return(@4, Terminal) // Old optimized AIR Lshift %x1, $63, %x1, @3 Or %x0, %x1, %x0, @4 Ret %x0, @5 // New optimized AIR OrLeftShift %x0, %x1, $63, %x0, @4 Ret %x0, @5 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::andLeftShift32): (JSC::MacroAssemblerARM64::andRightShift32): (JSC::MacroAssemblerARM64::andUnsignedRightShift32): (JSC::MacroAssemblerARM64::andLeftShift64): (JSC::MacroAssemblerARM64::andRightShift64): (JSC::MacroAssemblerARM64::andUnsignedRightShift64): (JSC::MacroAssemblerARM64::xorLeftShift32): (JSC::MacroAssemblerARM64::xorRightShift32): (JSC::MacroAssemblerARM64::xorUnsignedRightShift32): (JSC::MacroAssemblerARM64::xorLeftShift64): (JSC::MacroAssemblerARM64::xorRightShift64): (JSC::MacroAssemblerARM64::xorUnsignedRightShift64): (JSC::MacroAssemblerARM64::orLeftShift32): (JSC::MacroAssemblerARM64::orRightShift32): (JSC::MacroAssemblerARM64::orUnsignedRightShift32): (JSC::MacroAssemblerARM64::orLeftShift64): (JSC::MacroAssemblerARM64::orRightShift64): (JSC::MacroAssemblerARM64::orUnsignedRightShift64): * assembler/testmasm.cpp: (JSC::testAndLeftShift32): (JSC::testAndRightShift32): (JSC::testAndUnsignedRightShift32): (JSC::testAndLeftShift64): (JSC::testAndRightShift64): (JSC::testAndUnsignedRightShift64): (JSC::testXorLeftShift32): (JSC::testXorRightShift32): (JSC::testXorUnsignedRightShift32): (JSC::testXorLeftShift64): (JSC::testXorRightShift64): (JSC::testXorUnsignedRightShift64): (JSC::testOrLeftShift32): (JSC::testOrRightShift32): (JSC::testOrUnsignedRightShift32): (JSC::testOrLeftShift64): (JSC::testOrRightShift64): (JSC::testOrUnsignedRightShift64): * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testAndLeftShift32): (testAndRightShift32): (testAndUnsignedRightShift32): (testAndLeftShift64): (testAndRightShift64): (testAndUnsignedRightShift64): (testXorLeftShift32): (testXorRightShift32): (testXorUnsignedRightShift32): (testXorLeftShift64): (testXorRightShift64): (testXorUnsignedRightShift64): (testOrLeftShift32): (testOrRightShift32): (testOrUnsignedRightShift32): (testOrLeftShift64): (testOrRightShift64): (testOrUnsignedRightShift64): (addBitTests): 2021-08-02 Yusuke Suzuki [JSC] Use loadPair / storePair in YarrJIT https://bugs.webkit.org/show_bug.cgi?id=228687 Reviewed by Mark Lam. Use loadPair / storePair if possible in YarrJIT. Currently, we are not deploying Spooler in YarrJIT, but we should do that in the future too. In this patch, we also add appropriate fallback code in loadPair / storePair: the offset of these functions are small enough so that we should consider overflowing case. If it overflows, we use two loads or stores. This patch also adds loadPair32 and storePair32 to all macro assembler so that we can call it without CPU(ARM64). Internally, two loads or stores are combined. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::loadPair32): (JSC::MacroAssemblerARM64::loadPair64): (JSC::MacroAssemblerARM64::loadPair64WithNonTemporalAccess): (JSC::MacroAssemblerARM64::storePair32): (JSC::MacroAssemblerARM64::storePair64): (JSC::MacroAssemblerARM64::storePair64WithNonTemporalAccess): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::loadPair32): (JSC::MacroAssemblerARMv7::storePair32): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::loadPair32): (JSC::MacroAssemblerMIPS::storePair32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::loadPair32): (JSC::MacroAssemblerX86Common::storePair32): * assembler/testmasm.cpp: (JSC::testLoadStorePair32): (JSC::testLoadStorePair64Int64): * yarr/YarrJIT.cpp: 2021-08-02 Yusuke Suzuki Unreviewed, fix accidental narrowing https://bugs.webkit.org/show_bug.cgi?id=228613 Note that this narrowing does not matter semantically since we mask this value with 0x7f. * yarr/YarrJIT.h: (JSC::Yarr::BoyerMooreBitmap::addCharacters): 2021-08-02 Yusuke Suzuki [JSC] Yarr BoyerMoore search should support character-class https://bugs.webkit.org/show_bug.cgi?id=228613 Reviewed by Saam Barati. This patch adds character-class support for BoyerMoore lookahead search in Yarr. Currently, we only support fixed-sized character-class. We can extend it for repeat cases in the future. To apply this character-class thing to jQuery's RegExp, we also allow non-fixed-sized disjunction. For example, /aaaa.*|bbbb/'s disjunction is not fixed-sized. But still we can use (aaaa|bbbb) prefix since this part is fixed-sized and we know minimum-size of this disjunction is 4. Plus, instead of giving up BoyerMoore search when we found non-supported terms, we shorten BoyerMoore search length not to include this term so that we can still have a chance to leverage BoyerMoore search. In the case of /aaaa|bbbb|ccc(d|e|f)/, we previously gave up since it finds `(d|e|f)`. But now, instead we shorten the length from 4 to 3, and construct search pattern with `aaa|bbb|ccc`. This patch improves jquery-todomvc-regexp by 20%. ToT Patched jquery-todomvc-regexp 545.3561+-0.6968 ^ 451.6117+-0.4613 ^ definitely 1.2076x faster This improves Speedometer2/jQuery-TodoMVC by 2%. ---------------------------------------------------------------------------------------------------------------------------------- | subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) | ---------------------------------------------------------------------------------------------------------------------------------- | Elm-TodoMVC |123.470833 |123.550000 |1.000641 | 0.841600 | | VueJS-TodoMVC |26.883333 |26.950000 |1.002480 | 0.846732 | | EmberJS-TodoMVC |127.708333 |127.754167 |1.000359 | 0.934206 | | BackboneJS-TodoMVC |50.545833 |50.445833 |0.998022 | 0.679610 | | Preact-TodoMVC |20.879167 |20.791667 |0.995809 | 0.796541 | | AngularJS-TodoMVC |137.479167 |137.275000 |0.998515 | 0.729817 | | Vanilla-ES2015-TodoMVC |69.079167 |68.912500 |0.997587 | 0.524325 | | Inferno-TodoMVC |65.604167 |66.120833 |1.007876 | 0.145549 | | Flight-TodoMVC |77.029167 |76.708333 |0.995835 | 0.518562 | | Angular2-TypeScript-TodoMVC |40.516667 |40.812500 |1.007302 | 0.513386 | | VanillaJS-TodoMVC |54.762500 |54.895833 |1.002435 | 0.647381 | | jQuery-TodoMVC |255.950000 |250.425000 |0.978414 | 0.000000 (significant) | | EmberJS-Debug-TodoMVC |341.745833 |342.804167 |1.003097 | 0.219937 | | React-TodoMVC |88.854167 |88.700000 |0.998265 | 0.568405 | | React-Redux-TodoMVC |151.266667 |150.804167 |0.996942 | 0.256403 | | Vanilla-ES2015-Babel-Webpack-TodoMVC |65.783333 |65.645833 |0.997910 | 0.437464 | ---------------------------------------------------------------------------------------------------------------------------------- a mean = 246.52898 b mean = 246.85128 pValue = 0.3927330278 (Bigger means are better.) 1.001 times better Results ARE NOT significant * yarr/YarrJIT.cpp: (JSC::Yarr::BoyerMooreInfo::shortenLength): (JSC::Yarr::BoyerMooreInfo::setAll): (JSC::Yarr::BoyerMooreInfo::addCharacters): (JSC::Yarr::BoyerMooreInfo::addRanges): * yarr/YarrJIT.h: (JSC::Yarr::BoyerMooreBitmap::add): (JSC::Yarr::BoyerMooreBitmap::addCharacters): (JSC::Yarr::BoyerMooreBitmap::addRanges): (JSC::Yarr::BoyerMooreBitmap::setAll): (JSC::Yarr::BoyerMooreBitmap::isAllSet const): 2021-08-02 Stephan Szabo [PlayStation] Make C files in testapi compile with a C standard rather than C++ one https://bugs.webkit.org/show_bug.cgi?id=228701 Reviewed by Ross Kirsling. * shell/PlatformPlayStation.cmake: Set standard for C files in testapi 2021-08-02 Yusuke Suzuki [JSC] Yarr should use Bitmap instead of ByteVector for BoyerMoore search https://bugs.webkit.org/show_bug.cgi?id=228676 Reviewed by Saam Barati. We observed that using Bitmap instead of ByteVector does not pose performance issue. It was neutral in jquery-todomvc-regexp.js. In that case, we should use Bitmap since it is 8x smaller. We also search reusable Bitmap from Vector since comparing 128bit Bitmap is super fast so we do not need to bother about linear search here (# of Bitmap is currently up to 4). To make code simplified, we add regT2 to ARMv7 and MIPS backend of YarrJIT. ToT Patched jquery-todomvc-regexp 555.9566+-0.8856 555.0737+-0.9717 * yarr/YarrJIT.cpp: (JSC::Yarr::BoyerMooreInfo::index const): Deleted. (JSC::Yarr::BoyerMooreInfo::setIndex): Deleted. * yarr/YarrJIT.h: (JSC::Yarr::YarrCodeBlock::set8BitCode): (JSC::Yarr::YarrCodeBlock::set16BitCode): (JSC::Yarr::YarrCodeBlock::set8BitCodeMatchOnly): (JSC::Yarr::YarrCodeBlock::set16BitCodeMatchOnly): (JSC::Yarr::YarrCodeBlock::tryReuseBoyerMooreBitmap const): (JSC::Yarr::BoyerMooreByteVector::BoyerMooreByteVector): Deleted. (JSC::Yarr::YarrCodeBlock::tryReuseBoyerMooreByteVector const): Deleted. 2021-07-31 Yusuke Suzuki [JSC] Move JIT_UNICODE_EXPRESSIONS to ENABLE(YARR_JIT_UNICODE_EXPRESSIONS) in PlatformEnable.h https://bugs.webkit.org/show_bug.cgi?id=228669 Reviewed by Alexey Shvayka. Move JIT_UNICODE_EXPRESSIONS to PlatformEnable.h to align to the other YarrJIT flags. This makes it easy to read that this is enabled on ARM64 and X86_64. * yarr/YarrJIT.cpp: 2021-07-31 Yusuke Suzuki [JSC] Clean up Yarr by using `static constexpr` https://bugs.webkit.org/show_bug.cgi?id=228678 Reviewed by Alexey Shvayka. Modernize Yarr code by using static constexpr. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::TrustedImm32::TrustedImm32): * yarr/YarrCanonicalizeUCS2.cpp: * yarr/YarrCanonicalizeUCS2.js: (set characters.hex.set string_appeared_here): * yarr/YarrErrorCode.cpp: (JSC::Yarr::errorMessage): * yarr/YarrJIT.cpp: 2021-07-31 Joonghun Park Unreviewed. Remove the build warning below since r280493. warning: variable ‘block’ set but not used [-Wunused-but-set-variable] * b3/B3CanonicalizePrePostIncrements.cpp: (JSC::B3::canonicalizePrePostIncrements): 2021-07-30 Yusuke Suzuki [JSC] branchTest8 should not emit tst for Zero/NonZero cases https://bugs.webkit.org/show_bug.cgi?id=228674 Reviewed by Mark Lam. Previously, branchTest8(NonZero, BaseIndex) emits `tst` instruction unnecessarily. This is because the mask is truncated into 8bit, which makes branchTest32 (which is internally used in branchTest8) emits tst. We observed many unnecessary tst in YarrJIT. This patch removes this unnecessary truncation since Zero/NonZero does not care high bits of mask in branchTest8. This is ok because the ResultCondition version of mask8OnCondition() is always used to generate a mask that is only used against a value that is loaded with MacroAssemblerHelpers::load8OnCondition(). For Zero/NonZero conditions, load8OnCondition() will always zero fill the upper bytes. The 0 filled upper bytes will not affect the result of a branch on zero or branch on not zero. Before: 0x10a8068b0: ldrb w16, [x7, x6] 0x10a8068b4: tst w16, #0xff 0x10a8068b8: b.ne 0x10a8068cc After: 0x1070068b0: ldrb w16, [x7, x6] 0x1070068b4: cbnz w16, 0x1070068c8 * assembler/MacroAssemblerHelpers.h: (JSC::MacroAssemblerHelpers::mask8OnCondition): 2021-07-30 Robin Morisset Improve OSR entry into Wasm loops with arguments https://bugs.webkit.org/show_bug.cgi?id=228595 Reviewed by Yusuke Suzuki. This patch has two parts: - improve the Wasm OSR code to fully support loop arguments (just some plumbing to make sure that the right values are propagated) - improve the B3 validator to fix a hole I noticed while writing the first part: we were not detecting code that introduce Upsilons in the wrong blocks. Naturally, this caused hard to debug issues, as B3 has no well-defined semantics for a Phi that is reached before the corresponding Upsilon(s). * b3/B3Validate.cpp: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck): (JSC::Wasm::AirIRGenerator::addLoop): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck): (JSC::Wasm::B3IRGenerator::addLoop): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::addLoop): 2021-07-30 Philip Chimento [JSC] Rename Temporal.now to Temporal.Now https://bugs.webkit.org/show_bug.cgi?id=228658 Reviewed by Yusuke Suzuki. See https://github.com/tc39/proposal-temporal/pull/1645. In the July 2021 meeting TC39 achieved consensus to rename Temporal.now to Temporal.Now since it is a namespace. * runtime/TemporalNow.cpp: Change Now[@@toStringTag] accordingly. * runtime/TemporalObject.cpp: Rename now property to Now. 2021-07-30 Tadeu Zagallo putInlineFastReplacingStaticPropertyIfNeeded should handle custom values https://bugs.webkit.org/show_bug.cgi?id=227963 Reviewed by Alexey Shvayka. Follow up after r280463: as it turns out, putInlineFastReplacingStaticPropertyIfNeeded also needs to handle custom values, similar to how definePropertyOnReceiverSlow was updated. This function will be called when the target property of the receiver is a custom value and isn't reified. The previous test case was expanded to test both the reified and non-reified cases. * runtime/JSObject.cpp: (JSC::JSObject::putInlineFastReplacingStaticPropertyIfNeeded): * tools/JSDollarVM.cpp: 2021-07-30 Yusuke Suzuki Unreviewed, fix wrong access width https://bugs.webkit.org/show_bug.cgi?id=228301 rdar://81341472 * yarr/YarrJIT.cpp: 2021-07-30 Yijia Huang Add Pre/Post-Indexed Address Mode to Air for ARM64 https://bugs.webkit.org/show_bug.cgi?id=228047 Reviewed by Phil Pizlo. Pre-indexed addressing means that the address is the sum of the value in the 64-bit base register and an offset, and the address is then written back to the base register. And post-indexed addressing means that the address is the value in the 64-bit base register, and the sum of the address and the offset is then written back to the base register. They are relatively common for loops to iterate over an array by increasing/decreasing a pointer into the array at each iteration. With such an addressing mode, the instruction selector can merge the increment and access the array. ##################################### ## Pre-Index Address Mode For Load ## ##################################### LDR Wt, [Xn, #imm]! In B3 Reduction Strength, since we have this reduction rule: Turn this: Load(Add(address, offset1), offset = offset2) Into this: Load(address, offset = offset1 + offset2) Then, the equivalent pattern is: address = Add(base, offset) ... memory = Load(base, offset) First, we convert it to the canonical form: address = Add(base, offset) newMemory = Load(base, offset) // move the memory to just after the address ... memory = Identity(newMemory) Next, lower to Air: Move %base, %address Move (%address, prefix(offset)), %newMemory ###################################### ## Post-Index Address Mode For Load ## ###################################### LDR Wt, [Xn], #imm Then, the equivalent pattern is: memory = Load(base, 0) ... address = Add(base, offset) First, we convert it to the canonical form: newOffset = Constant newAddress = Add(base, offset) memory = Load(base, 0) // move the offset and address to just before the memory ... offset = Identity(newOffset) address = Identity(newAddress) Next, lower to Air: Move %base, %newAddress Move (%newAddress, postfix(offset)), %memory ############################# ## Pattern Match Algorithm ## ############################# To detect the pattern for prefix/postfix increment address is tricky due to the structure in B3 IR. The algorithm used in this patch is to collect the first valid values (add/load), then search for any paired value (load/add) to match all of them. In worst case, the runtime complexity is O(n^2) when n is the number of all values. After collecting two sets of candidates, we match the prefix incremental address first since it seems more beneficial to the compiler (shown in the next section). And then, go for the postfix one. ############################################## ## Test for Pre/Post-Increment Address Mode ## ############################################## Given Loop with Pre-Increment: int64_t ldr_pre(int64_t *p) { int64_t res = 0; while (res < 10) res += *++p; return res; } B3 IR: ------------------------------------------------------ BB#0: ; frequency = 1.000000 Int64 b@0 = Const64(0) Int64 b@2 = ArgumentReg(%x0) Void b@20 = Upsilon($0(b@0), ^18, WritesLocalState) Void b@21 = Upsilon(b@2, ^19, WritesLocalState) Void b@4 = Jump(Terminal) Successors: #1 BB#1: ; frequency = 1.000000 Predecessors: #0, #2 Int64 b@18 = Phi(ReadsLocalState) Int64 b@19 = Phi(ReadsLocalState) Int64 b@7 = Const64(10) Int32 b@8 = AboveEqual(b@18, $10(b@7)) Void b@9 = Branch(b@8, Terminal) Successors: Then:#3, Else:#2 BB#2: ; frequency = 1.000000 Predecessors: #1 Int64 b@10 = Const64(8) Int64 b@11 = Add(b@19, $8(b@10)) Int64 b@13 = Load(b@11, ControlDependent|Reads:Top) Int64 b@14 = Add(b@18, b@13) Void b@22 = Upsilon(b@14, ^18, WritesLocalState) Void b@23 = Upsilon(b@11, ^19, WritesLocalState) Void b@16 = Jump(Terminal) Successors: #1 BB#3: ; frequency = 1.000000 Predecessors: #1 Void b@17 = Return(b@18, Terminal) Variables: Int64 var0 Int64 var1 ------------------------------------------------------ W/O Pre-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 Move $8, %x3, $8(b@12) Add64 $8, %x0, %x1, b@11 Move (%x0,%x3), %x0, b@13 Add64 %x0, %x2, %x2, b@14 Move %x1, %x0, b@23 Jump b@16 Successors: #1 ... ------------------------------------------------------ W/ Pre-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 MoveWithIncrement64 (%x0,Pre($8)), %x2, b@13 Add64 %x2, %x1, %x1, b@14 Jump b@16 Successors: #1 ... ------------------------------------------------------ Given Loop with Post-Increment: int64_t ldr_pre(int64_t *p) { int64_t res = 0; while (res < 10) res += *p++; return res; } B3 IR: ------------------------------------------------------ BB#0: ; frequency = 1.000000 Int64 b@0 = Const64(0) Int64 b@2 = ArgumentReg(%x0) Void b@20 = Upsilon($0(b@0), ^18, WritesLocalState) Void b@21 = Upsilon(b@2, ^19, WritesLocalState) Void b@4 = Jump(Terminal) Successors: #1 BB#1: ; frequency = 1.000000 Predecessors: #0, #2 Int64 b@18 = Phi(ReadsLocalState) Int64 b@19 = Phi(ReadsLocalState) Int64 b@7 = Const64(10) Int32 b@8 = AboveEqual(b@18, $10(b@7)) Void b@9 = Branch(b@8, Terminal) Successors: Then:#3, Else:#2 BB#2: ; frequency = 1.000000 Predecessors: #1 Int64 b@10 = Load(b@19, ControlDependent|Reads:Top) Int64 b@11 = Add(b@18, b@10) Int64 b@12 = Const64(8) Int64 b@13 = Add(b@19, $8(b@12)) Void b@22 = Upsilon(b@11, ^18, WritesLocalState) Void b@23 = Upsilon(b@13, ^19, WritesLocalState) Void b@16 = Jump(Terminal) Successors: #1 BB#3: ; frequency = 1.000000 Predecessors: #1 Void b@17 = Return(b@18, Terminal) Variables: Int64 var0 Int64 var1 ------------------------------------------------------ W/O Post-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 Move (%x0), %x2, b@10 Add64 %x2, %x1, %x1, b@11 Add64 $8, %x0, %x0, b@13 Jump b@16 Successors: #1 ... ------------------------------------------------------ W/ Post-Increment Address Mode: ------------------------------------------------------ ... BB#2: ; frequency = 1.000000 Predecessors: #1 MoveWithIncrement64 (%x0,Post($8)), %x2, b@10 Add64 %x2, %x1, %x1, b@11 Jump b@16 Successors: #1 ... ------------------------------------------------------ * Sources.txt: * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::PreIndexAddress::PreIndexAddress): (JSC::AbstractMacroAssembler::PostIndexAddress::PostIndexAddress): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load64): (JSC::MacroAssemblerARM64::load32): (JSC::MacroAssemblerARM64::store64): (JSC::MacroAssemblerARM64::store32): * assembler/testmasm.cpp: (JSC::testStorePrePostIndex32): (JSC::testStorePrePostIndex64): (JSC::testLoadPrePostIndex32): (JSC::testLoadPrePostIndex64): * b3/B3CanonicalizePrePostIncrements.cpp: Added. (JSC::B3::canonicalizePrePostIncrements): * b3/B3CanonicalizePrePostIncrements.h: Copied from Source/JavaScriptCore/b3/B3ValueKeyInlines.h. * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3LowerToAir.cpp: * b3/B3ValueKey.h: * b3/B3ValueKeyInlines.h: (JSC::B3::ValueKey::ValueKey): * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::jsHash const): (JSC::B3::Air::Arg::dump const): (WTF::printInternal): * b3/air/AirArg.h: (JSC::B3::Air::Arg::preIndex): (JSC::B3::Air::Arg::postIndex): (JSC::B3::Air::Arg::isPreIndex const): (JSC::B3::Air::Arg::isPostIndex const): (JSC::B3::Air::Arg::isMemory const): (JSC::B3::Air::Arg::base const): (JSC::B3::Air::Arg::offset const): (JSC::B3::Air::Arg::isGP const): (JSC::B3::Air::Arg::isFP const): (JSC::B3::Air::Arg::isValidPreIndexForm): (JSC::B3::Air::Arg::isValidPostIndexForm): (JSC::B3::Air::Arg::isValidForm const): (JSC::B3::Air::Arg::forEachTmpFast): (JSC::B3::Air::Arg::forEachTmp): (JSC::B3::Air::Arg::asPreIndexAddress const): (JSC::B3::Air::Arg::asPostIndexAddress const): * b3/air/AirOpcode.opcodes: * b3/air/opcode_generator.rb: * b3/testb3.h: * b3/testb3_3.cpp: (testLoadPreIndex32): (testLoadPreIndex64): (testLoadPostIndex32): (testLoadPostIndex64): (addShrTests): * jit/ExecutableAllocator.cpp: (JSC::jitWriteThunkGenerator): 2021-07-30 Alexey Shvayka REGRESSION (r280460): 42 JSC test failures on Debug arm64 with ASSERTION FAILED: !m_needExceptionCheck https://bugs.webkit.org/show_bug.cgi?id=228652 Unreviewed unchecked exception fix. Release scope before calling RegExpGlobalData::getBackref(). * runtime/RegExpConstructor.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): 2021-07-30 Yusuke Suzuki [JSC] Use UCPURegister argument to remove zero extension in JIT code https://bugs.webkit.org/show_bug.cgi?id=228625 Reviewed by Robin Morisset. Yarr JIT code emits zeroExtend32ToWord for some arguments, but this is not necessary if argument is defined as UCPURegister. In that case, caller guarantees that top 32bits are cleared. * yarr/YarrJIT.cpp: * yarr/YarrJIT.h: 2021-07-29 Myles C. Maxfield Stop building WebGPU and the WHLSL compiler to decrease binary size https://bugs.webkit.org/show_bug.cgi?id=228179 Reviewed by Dean Jackson, Robin Morisset, and Devin Rousso. This patch deletes the existing implementation just to reduce binary size in releases of WebKit which don't enable WebGPU by default. It doesn't represent a change in direction or policy or anything regarding WebGPU. It's a (somewhat temporary) pragmatic change. Our current implementation of WebGPU: 1. Is off by default on all platforms 2. Is extremely outdated 3. Has no notion of the GPU Process, and therefore needs to be redesigned and largely rewritten 4. Only implements a fraction of what is in the spec Removing the code from the tree doesn't delete it from existence; it's still in source control. The benefit of reducing binary size seems to outweigh having this code in the tree. * inspector/protocol/Canvas.json: * inspector/scripts/codegen/generator.py: 2021-07-29 Carlos Alberto Lopez Perez [WPE][GTK] build broken with python2 after r280382 https://bugs.webkit.org/show_bug.cgi?id=228629 Reviewed by Philippe Normand. Call {PYTHON_EXECUTABLE} instead of python3. * PlatformGTK.cmake: 2021-07-29 Tadeu Zagallo definePropertyOnReceiver should check if receiver canPerformFastPutInline https://bugs.webkit.org/show_bug.cgi?id=227963 Reviewed by Alexey Shvayka. definePropertyOnReceiver has a fast path if the slot is not opaque and the receiver doesn't have a custom defineOwnProperty implementation, in which case it calls putInlineFast (and transitively putDirectInternal). The issue is that putDirectInternal does not handle customValues correctly: it just overwrites the property without changing the attributes. To fix that, we should first check if the property might be a custom value, and if that's the case we now call `definePropertyOnReceiverSlow`, which has been updated to handle custom values correctly. I also added assertions to putInlineFastReplacingStaticPropertyIfNeeded and putDirectInternal to make sure we don't accidentally overwrite custom values in the future. * runtime/JSObject.cpp: (JSC::definePropertyOnReceiverSlow): (JSC::JSObject::definePropertyOnReceiver): (JSC::JSObject::putInlineFastReplacingStaticPropertyIfNeeded): * runtime/JSObjectInlines.h: (JSC::JSObject::putDirectInternal): 2021-07-29 Yusuke Suzuki and Alexey Shvayka [JSC] Legacy RegExp fields should be accessors https://bugs.webkit.org/show_bug.cgi?id=220233 Reviewed by Tadeu Zagallo. This patch implements a part of Legacy RegExp features proposal [1], replacing custom values with custom accessors that require |this| value to be RegExp constructor of the same realm. Apart from fixing property descriptors, this change brings legacy RegExpConstructor fields in compliance with invariants of internal methods [2] (described in #151348), aligning JSC with V8 and SpiderMonkey. It doesn't, however, implement [[LegacyFeaturesEnabled]] and RegExp.prototype.compile changes. [1]: https://github.com/tc39/proposal-regexp-legacy-features [2]: https://tc39.es/ecma262/#sec-invariants-of-the-essential-internal-methods * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * runtime/RegExpConstructor.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): (JSC::JSC_DEFINE_CUSTOM_SETTER): (JSC::regExpConstructorDollarImpl): Deleted. * tools/JSDollarVM.cpp: 2021-07-29 Myles C. Maxfield Add WebGPU to webkit.org/status https://bugs.webkit.org/show_bug.cgi?id=228623 Reviewed by Robin Morisset. * features.json: 2021-07-28 Yusuke Suzuki [JSC] Yarr should perform BoyerMoore search https://bugs.webkit.org/show_bug.cgi?id=228301 Reviewed by Saam Barati. This patch emits skipping fast-path at the beginning of body alternatives with a large stride. So we can quickly discard unrelated characters and attempt to find possibly related sequence in the long sequence. The method is derived from V8's implementation (with some extensions). If we have a searching pattern /abcdef/, then we can check the 6th character against a set of {a, b, c, d, e, f}. If it does not match, we can shift 6 characters. We use this strategy since this way can be extended easily to support disjunction, character-class, and ignore-cases. For example, in the case of /(?:abc|def)/, we can check 3rd character against {a, b, c, d, e, f} and shift 3 characters if it does not match. Then, the best way to perform the above shifting is that finding the longest character sequence which does not have many candidates. In the case of /[a-z]aaaaaaa[a-z]/, we can extract "aaaaaaa" sequence and check 8th character against {a}. If it does not match, then we can shift 7 characters (length of "aaaaaaa"). This shifting is better than using "[a-z]aaaaaaa[a-z]" sequence and {a-z} set since {a-z} set will almost always match. We first collect possible characters for each character position. Then, apply heuristics to extract good character sequence from that and construct fast searching with long stride. Microbenchmark which performs RegExp ops in Speedometer2/jQuery-TodoMVC shows 25% improvement. ToT Patched jquery-todomvc-regexp 723.9739+-1.3997 ^ 579.1698+-1.2505 ^ definitely 1.2500x faster This improves Speedometer2/jQuery-TodoMVC by 3%. ---------------------------------------------------------------------------------------------------------------------------------- | subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) | ---------------------------------------------------------------------------------------------------------------------------------- | Elm-TodoMVC |123.365625 |123.456250 |1.000735 | 0.804077 | | VueJS-TodoMVC |26.912500 |26.925000 |1.000464 | 0.969603 | | EmberJS-TodoMVC |127.540625 |127.562500 |1.000172 | 0.960474 | | BackboneJS-TodoMVC |50.606250 |50.518750 |0.998271 | 0.670313 | | Preact-TodoMVC |21.018750 |20.850000 |0.991971 | 0.563818 | | AngularJS-TodoMVC |136.943750 |137.271875 |1.002396 | 0.531513 | | Vanilla-ES2015-TodoMVC |68.521875 |68.593750 |1.001049 | 0.701376 | | Inferno-TodoMVC |65.559375 |65.803125 |1.003718 | 0.414418 | | Flight-TodoMVC |77.284375 |76.715625 |0.992641 | 0.219870 | | Angular2-TypeScript-TodoMVC |40.725000 |40.318750 |0.990025 | 0.281212 | | VanillaJS-TodoMVC |55.209375 |54.715625 |0.991057 | 0.056921 | | jQuery-TodoMVC |266.396875 |258.471875 |0.970251 | 0.000000 (significant) | | EmberJS-Debug-TodoMVC |341.550000 |341.856250 |1.000897 | 0.618140 | | React-TodoMVC |88.731250 |88.871875 |1.001585 | 0.512407 | | React-Redux-TodoMVC |150.340625 |150.065625 |0.998171 | 0.412940 | | Vanilla-ES2015-Babel-Webpack-TodoMVC |65.390625 |65.362500 |0.999570 | 0.834760 | ---------------------------------------------------------------------------------------------------------------------------------- a mean = 245.96997 b mean = 246.86366 pValue = 0.0061448402 (Bigger means are better.) 1.004 times better Results ARE significant * runtime/OptionsList.h: * yarr/YarrJIT.cpp: (JSC::Yarr::BoyerMooreInfo::BoyerMooreInfo): (JSC::Yarr::BoyerMooreInfo::length const): (JSC::Yarr::BoyerMooreInfo::set): (JSC::Yarr::BoyerMooreInfo::index const): (JSC::Yarr::BoyerMooreInfo::setIndex): (JSC::Yarr::BoyerMooreInfo::create): (JSC::Yarr::BoyerMooreInfo::findBestCharacterSequence const): (JSC::Yarr::BoyerMooreInfo::findWorthwhileCharacterSequenceForLookahead const): (JSC::Yarr::BoyerMooreInfo::createCandidateBitmap const): * yarr/YarrJIT.h: (JSC::Yarr::BoyerMooreBitmap::count const): (JSC::Yarr::BoyerMooreBitmap::map const): (JSC::Yarr::BoyerMooreBitmap::isMaskEffective const): (JSC::Yarr::BoyerMooreBitmap::add): (JSC::Yarr::BoyerMooreByteVector::BoyerMooreByteVector): (JSC::Yarr::YarrCodeBlock::set8BitCode): (JSC::Yarr::YarrCodeBlock::set16BitCode): (JSC::Yarr::YarrCodeBlock::set8BitCodeMatchOnly): (JSC::Yarr::YarrCodeBlock::set16BitCodeMatchOnly): (JSC::Yarr::YarrCodeBlock::clear): (JSC::Yarr::YarrCodeBlock::findSameVector const): 2021-07-28 Yusuke Suzuki [JSC] load/store with BaseIndex is inefficient in ARM64 https://bugs.webkit.org/show_bug.cgi?id=228543 Reviewed by Mark Lam. While we are frequently using load + BaseIndex (with offset) in RegExp code, we emit 3 instructions in ARM64. This can be represented in 2 instructions. This patch adds that path to make generated code tight in ARM64 RegExp. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load64): (JSC::MacroAssemblerARM64::load32): (JSC::MacroAssemblerARM64::load16): (JSC::MacroAssemblerARM64::load16SignedExtendTo32): (JSC::MacroAssemblerARM64::load8): (JSC::MacroAssemblerARM64::load8SignedExtendTo32): (JSC::MacroAssemblerARM64::store64): (JSC::MacroAssemblerARM64::store32): (JSC::MacroAssemblerARM64::store16): (JSC::MacroAssemblerARM64::store8): (JSC::MacroAssemblerARM64::loadDouble): (JSC::MacroAssemblerARM64::loadFloat): (JSC::MacroAssemblerARM64::storeDouble): (JSC::MacroAssemblerARM64::storeFloat): (JSC::MacroAssemblerARM64::tryFoldBaseAndOffsetPart): * assembler/testmasm.cpp: (JSC::testLoadBaseIndex): (JSC::testStoreBaseIndex): 2021-07-28 Philippe Normand [WPE][GTK] SVN_REVISION drifting away if bots don't re-run cmake https://bugs.webkit.org/show_bug.cgi?id=228290 Reviewed by Michael Catanzaro. * PlatformGTK.cmake: Expand ${BUILD_REVISION} with apply-build-revision-to-files.py for non-tarball builds, or let CMake do it for tarball builds. * javascriptcoregtk.pc.in: Switch revision var to ${} format, so that we can choose to either let CMake expand it or do it ourselves. 2021-07-27 Patrick Angle Web Inspector: [Cocoa] "RemoteInspector XPC connection to relay failed." messages are confusing in StdErr https://bugs.webkit.org/show_bug.cgi?id=228303 Reviewed by Darin Adler. Remove overly verbose and confusing `WTFLogAlways` messages added in r278413, which can confuse applications listening to stderr of a process using JavaScriptCore. * inspector/remote/cocoa/RemoteInspectorCocoa.mm: (Inspector::RemoteInspector::xpcConnectionFailed): 2021-07-27 Alexey Shvayka ProxyObject callees should be skipped during Function.prototype.caller resolution https://bugs.webkit.org/show_bug.cgi?id=228341 Reviewed by Yusuke Suzuki. Just like a bound function, a Proxy with nullish "apply" handler merely forwards [[Call]] to its target [1], without pushing onto the execution context stack. This fact is also noted in Function.prototype.{caller,arguments} reflection proposal [2]. This patch aligns JSC with V8 and SpiderMonkey if Proxy's "apply" handler is userland or nullish. However, since JSC implements proper tail calls, `Function.prototype.caller` result is divergent from other engines if the handler is `Reflect.apply`, which performs a tail call that gets optimized away [2] (unless called by another Proxy). [1]: https://tc39.es/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-call-thisargument-argumentslist (step 8) [2]: https://github.com/claudepache/es-legacy-function-reflection/blob/master/spec.md#get-functionprototypecaller (see notes) * runtime/FunctionPrototype.cpp: (JSC::RetrieveCallerFunctionFunctor::operator() const): 2021-07-26 Yusuke Suzuki Add Temporal to features.json https://bugs.webkit.org/show_bug.cgi?id=228292 Reviewed by Myles C. Maxfield. * features.json: 2021-07-25 Alexey Shvayka Partly implement Function.prototype.{caller,arguments} reflection proposal https://bugs.webkit.org/show_bug.cgi?id=158116 Reviewed by Yusuke Suzuki. To ensure web-compatibility, only the safe subset of Function.prototype.{caller,arguments} reflection proposal [1] is implemented, which is currently shipped in SpiderMonkey. Complete list of differences from the proposed spec: 1. Cross-realm receiver function is allowed instead of throwing a TypeError. Throwing is likely safe to ship, but #225997 needs to be fixed first for custom properties to receive correct global object. 2. Cross-realm caller function is returned instead of `null`. Hiding cross-realm caller may break things: we currently have a test for the opposite behavior. 3. Defines "caller" and "arguments" setters that throw for disallowed receivers, instead failing silently in sloppy mode. This is actually more restrictive than the spec, which is preferable, and aligns with V8 and SM. Most importantly, this patch removes own "caller" and "arguments" properties from sloppy mode ES5 functions. They were non-configurable, making it harder to use their holder as a [[ProxyTarget]]. They were also non-writable, with a constantly changing [[Value]], which violated the invariants of internal methods [2]. As a result, JSFunction methods are greatly simplified, especially defineOwnProperty() and getOwnSpecialPropertyNames(). The latter is now 2.1x faster according to the provided microbenchmark. Also, removes double "prototype" lookup from [[Get]], which is a 10% progression. [1]: https://github.com/claudepache/es-legacy-function-reflection [2]: https://tc39.es/ecma262/#sec-invariants-of-the-essential-internal-methods * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::getOwnPropertySlot): (JSC::ClonedArguments::materializeSpecials): * runtime/FunctionExecutable.h: * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::addFunctionProperties): (JSC::isAllowedReceiverFunctionForCallerAndArguments): (JSC::RetrieveArgumentsFunctor::RetrieveArgumentsFunctor): (JSC::RetrieveArgumentsFunctor::result const): (JSC::RetrieveArgumentsFunctor::operator() const): (JSC::retrieveArguments): (JSC::JSC_DEFINE_CUSTOM_GETTER): (JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor): (JSC::RetrieveCallerFunctionFunctor::result const): (JSC::RetrieveCallerFunctionFunctor::operator() const): (JSC::retrieveCallerFunction): (JSC::JSC_DEFINE_CUSTOM_SETTER): (JSC::FunctionPrototype::initRestrictedProperties): Deleted. * runtime/FunctionPrototype.h: * runtime/JSFunction.cpp: (JSC::JSFunction::getOwnPropertySlot): (JSC::JSFunction::getOwnSpecialPropertyNames): (JSC::JSFunction::put): (JSC::JSFunction::deleteProperty): (JSC::JSFunction::defineOwnProperty): (JSC::RetrieveArgumentsFunctor::RetrieveArgumentsFunctor): Deleted. (JSC::RetrieveArgumentsFunctor::result const): Deleted. (JSC::RetrieveArgumentsFunctor::operator() const): Deleted. (JSC::retrieveArguments): Deleted. (JSC::JSC_DEFINE_CUSTOM_GETTER): Deleted. (JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor): Deleted. (JSC::RetrieveCallerFunctionFunctor::result const): Deleted. (JSC::RetrieveCallerFunctionFunctor::operator() const): Deleted. (JSC::retrieveCallerFunction): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildrenImpl): * runtime/JSGlobalObject.h: Remove unused m_throwTypeErrorGetterSetter and make [[ThrowTypeError]] lazily-created. * runtime/JSGlobalObjectFunctions.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/JSGlobalObjectFunctions.h: * runtime/JSObject.cpp: (JSC::JSObject::putDirectCustomGetterSetterWithoutTransition): * runtime/JSObject.h: 2021-07-24 Yusuke Suzuki [JSC] Change most of enum in Yarr to enum-class https://bugs.webkit.org/show_bug.cgi?id=228264 Reviewed by Mark Lam. This patch simply changes most of enum to enum-class in Yarr. We also remove YarrJIT YarrGenerator's template parameter since it is not worth doubling code. We can just hold Yarr::JITCompileMode as m_compileMode. * runtime/RegExp.cpp: (JSC::RegExp::compile): (JSC::RegExp::matchConcurrently): (JSC::RegExp::compileMatchOnly): * runtime/RegExp.h: * runtime/RegExpInlines.h: (JSC::RegExp::hasCodeFor): (JSC::RegExp::compileIfNecessary): (JSC::RegExp::matchInline): (JSC::RegExp::hasMatchOnlyCodeFor): (JSC::RegExp::compileIfNecessaryMatchOnly): * yarr/Yarr.h: (): Deleted. * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::backtrackPatternCharacter): (JSC::Yarr::Interpreter::backtrackPatternCasedCharacter): (JSC::Yarr::Interpreter::matchCharacterClass): (JSC::Yarr::Interpreter::backtrackCharacterClass): (JSC::Yarr::Interpreter::matchBackReference): (JSC::Yarr::Interpreter::backtrackBackReference): (JSC::Yarr::Interpreter::parenthesesDoBacktrack): (JSC::Yarr::Interpreter::matchParenthesesOnceBegin): (JSC::Yarr::Interpreter::matchParenthesesOnceEnd): (JSC::Yarr::Interpreter::backtrackParenthesesOnceBegin): (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd): (JSC::Yarr::Interpreter::matchParenthesesTerminalBegin): (JSC::Yarr::Interpreter::matchParenthesesTerminalEnd): (JSC::Yarr::Interpreter::backtrackParenthesesTerminalBegin): (JSC::Yarr::Interpreter::matchParentheticalAssertionBegin): (JSC::Yarr::Interpreter::matchParentheticalAssertionEnd): (JSC::Yarr::Interpreter::backtrackParentheticalAssertionBegin): (JSC::Yarr::Interpreter::backtrackParentheticalAssertionEnd): (JSC::Yarr::Interpreter::matchParentheses): (JSC::Yarr::Interpreter::backtrackParentheses): (JSC::Yarr::Interpreter::matchDisjunction): (JSC::Yarr::Interpreter::matchNonZeroDisjunction): (JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin): (JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin): (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin): (JSC::Yarr::ByteCompiler::atomParentheticalAssertionBegin): (JSC::Yarr::ByteCompiler::atomParentheticalAssertionEnd): (JSC::Yarr::ByteCompiler::closeAlternative): (JSC::Yarr::ByteCompiler::closeBodyAlternative): (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd): (JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd): (JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd): (JSC::Yarr::ByteCompiler::emitDisjunction): (JSC::Yarr::ByteCompiler::dumpDisjunction): * yarr/YarrInterpreter.h: (JSC::Yarr::ByteTerm::ByteTerm): (JSC::Yarr::ByteTerm::BOL): (JSC::Yarr::ByteTerm::CheckInput): (JSC::Yarr::ByteTerm::UncheckInput): (JSC::Yarr::ByteTerm::EOL): (JSC::Yarr::ByteTerm::WordBoundary): (JSC::Yarr::ByteTerm::BackReference): (JSC::Yarr::ByteTerm::BodyAlternativeBegin): (JSC::Yarr::ByteTerm::BodyAlternativeDisjunction): (JSC::Yarr::ByteTerm::BodyAlternativeEnd): (JSC::Yarr::ByteTerm::AlternativeBegin): (JSC::Yarr::ByteTerm::AlternativeDisjunction): (JSC::Yarr::ByteTerm::AlternativeEnd): (JSC::Yarr::ByteTerm::SubpatternBegin): (JSC::Yarr::ByteTerm::SubpatternEnd): (JSC::Yarr::ByteTerm::DotStarEnclosure): * yarr/YarrJIT.cpp: (JSC::Yarr::jitCompile): * yarr/YarrJIT.h: * yarr/YarrParser.h: (JSC::Yarr::Parser::CharacterClassParserDelegate::CharacterClassParserDelegate): (JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter): (JSC::Yarr::Parser::CharacterClassParserDelegate::atomBuiltInCharacterClass): (JSC::Yarr::Parser::CharacterClassParserDelegate::end): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin): (JSC::Yarr::YarrPatternConstructor::atomParentheticalAssertionBegin): (JSC::Yarr::YarrPatternConstructor::atomBackReference): (JSC::Yarr::YarrPatternConstructor::copyTerm): (JSC::Yarr::YarrPatternConstructor::quantifyAtom): (JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses): (JSC::Yarr::YarrPatternConstructor::containsCapturingTerms): (JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions): (JSC::Yarr::PatternTerm::dumpQuantifier): (JSC::Yarr::PatternTerm::dump): * yarr/YarrPattern.h: (JSC::Yarr::PatternTerm::PatternTerm): (JSC::Yarr::PatternTerm::ForwardReference): (JSC::Yarr::PatternTerm::BOL): (JSC::Yarr::PatternTerm::EOL): (JSC::Yarr::PatternTerm::WordBoundary): (JSC::Yarr::PatternTerm::isFixedWidthCharacterClass const): (JSC::Yarr::PatternTerm::containsAnyCaptures): (JSC::Yarr::PatternTerm::quantify): 2021-07-23 Alexey Shvayka [WebIDL] Properly validate and merge descriptors in [Replaceable] setter https://bugs.webkit.org/show_bug.cgi?id=227662 Reviewed by Sam Weinig. Extracts createDataProperty() method to keep WebIDL code generator as simple as possible, and also to emphasize a subtle difference between { [[Value]]: X } and { [[Value]]: X, [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true }. * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::definePropertyOnReceiverSlow): * runtime/JSObject.h: * runtime/JSObjectInlines.h: (JSC::JSObject::createDataProperty): * runtime/Lookup.h: (JSC::replaceStaticPropertySlot): Deleted. 2021-07-23 Alexey Shvayka [JSC] Call custom accessors / values with their holder's global object https://bugs.webkit.org/show_bug.cgi?id=225997 Reviewed by Yusuke Suzuki. Just like JS built-ins, getter / setter functions of WebIDL attributes are created in realm of their holder interface [1][2], which is their _current_ realm for throwing an error [3]. With this patch, custom properties get correct global object instead of lexical, including when inline cached, aligning them with functions and regular accessors. The latter allowed switching JS built-ins to CustomAccessor (e.g. Symbol#description), which is slightly more efficient to call from C++, doesn't need reification on first access, and has nicer signature. Also, renames WASM accessors to drop "func" and removes unused function length parameter. [1]: https://heycam.github.io/webidl/#dfn-attribute-getter (step 2) [2]: https://heycam.github.io/webidl/#dfn-attribute-setter (step 5) [3]: https://heycam.github.io/webidl/#ecmascript-throw * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * create_hash_table: * interpreter/CallFrame.cpp: (JSC::CallFrame::globalObjectOfClosestCodeBlock): * interpreter/CallFrame.h: * runtime/IntlCollatorPrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): * runtime/IntlLocalePrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): * runtime/IntlNumberFormatPrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): * runtime/JSDataViewPrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): * runtime/PropertySlot.cpp: (JSC::PropertySlot::customGetter const): * runtime/PropertySlot.h: (JSC::PropertySlot::getValue const): * runtime/SymbolPrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): * tools/JSDollarVM.cpp: * wasm/js/WebAssemblyInstancePrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): (JSC::JSC_DEFINE_HOST_FUNCTION): Deleted. * wasm/js/WebAssemblyMemoryPrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): * wasm/js/WebAssemblyTablePrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): 2021-07-22 Saam Barati AirStackSlot's uint16_t byte size is too small https://bugs.webkit.org/show_bug.cgi?id=228193 Reviewed by Mark Lam. * b3/B3Procedure.cpp: (JSC::B3::Procedure::addStackSlot): * b3/B3Procedure.h: * b3/air/AirCode.cpp: (JSC::B3::Air::Code::addStackSlot): * b3/air/AirCode.h: * b3/air/AirStackSlot.cpp: (JSC::B3::Air::StackSlot::StackSlot): * b3/air/AirStackSlot.h: (JSC::B3::Air::StackSlot::ensureSize): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * ftl/FTLOutput.cpp: (JSC::FTL::Output::lockedStackSlot): * ftl/FTLOutput.h: 2021-07-22 Saam Barati Fix uses of Dependency::fence with respect to the compiler outsmarting us https://bugs.webkit.org/show_bug.cgi?id=227757 Reviewed by Robin Morisset. We were running into issues on arm64 with respect to the memory model ordering of loads, and how the compiler optimized code around Dependency::fence. The issue manifested as calls to isMarked incorrectly returning true. To see the issue, let's consider a program like this: a = load(p1) b = load(p2) if (a != b) return; d = Dependency::fence(b) At the point of defining the dependency, the compiler has proven a == b. So, instead of building the dependency on the register used for b, we end up using the register for a. So the actual compiled code ends up with a dependency on load(p1), not load(p2). To fix this, we end up adding a new API, Dependency::loadEndFence(pointer, result), which is defined as: template static Dependency loadAndFence(T* pointer, T& output) { T value = *opaque(pointer); Dependency dependency = Dependency::fence(value); output = opaque(value); return dependency; } The reason for this is that it split "b" in the above program into two values, and the "b" the program compares against is not known to the compiler to be the same value that we build a dependency on. * heap/MarkedBlock.h: (JSC::MarkedBlock::aboutToMark): (JSC::MarkedBlock::isMarked): * runtime/JSObject.cpp: (JSC::JSObject::visitButterflyImpl): * runtime/JSObject.h: (JSC::JSObject::fencedButterfly): * runtime/SparseArrayValueMap.cpp: (JSC::SparseArrayEntry::getConcurrently): (JSC::SparseArrayEntry::getConcurrently const): Deleted. * runtime/SparseArrayValueMap.h: * runtime/Structure.h: (JSC::Structure::fencedIndexingMode): * runtime/StructureIDBlob.h: (JSC::StructureIDBlob::fencedIndexingModeIncludingHistory): 2021-07-22 Keith Miller useProfiler option should automatically disable concurrent JIT https://bugs.webkit.org/show_bug.cgi?id=228152 Reviewed by Saam Barati. The bytecode profiler is not thread safe so we should have recomputeDependentOptions() disable concurrent JIT. Also, fix the jsc CLI to set the useProfiler option rather than have its own state. Note, we call Options::setOption() rather than setting the Options::useProfiler() option directly as setOption calls recomputeDependentOptions() for us. * jsc.cpp: (CommandLine::parseArguments): (runJSC): * runtime/Options.cpp: (JSC::Options::recomputeDependentOptions): (JSC::Options::ensureOptionsAreCoherent): 2021-07-21 Yijia Huang Fix type check error in testb3 https://bugs.webkit.org/show_bug.cgi?id=228166 Reviewed by Saam Barati. * b3/testb3_2.cpp: (testXorNotWithLeftShift32): (testXorNotWithRightShift32): (testXorNotWithUnsignedRightShift32): 2021-07-21 Keith Miller speculateNeitherDoubleNorStringNorHeapBigInt should only have a single JSType branch https://bugs.webkit.org/show_bug.cgi?id=228146 Reviewed by Robin Morisset. Since StringType and HeapBigIntType are adjacent JSTypes we can do an integer range check rather than two separate JSType checks. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): 2021-07-20 Yijia Huang Add ARM64 EON opcode and select it in AIR https://bugs.webkit.org/show_bug.cgi?id=228057 Reviewed by Saam Barati. EON Rd Rn Rm #amount Bitwise Exclusive OR NOT (shifted register) performs a bitwise Exclusive OR NOT of a register value Rn and an optionally-shifted register value Rm, and writes the result to the destination register. The instruction selector can utilize this to lowering certain patterns in B3 IR before further Air optimization. The equivalent pattern of EON Rd Rn Rm is d = n ^ (m ^ -1) Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = ArgumentReg(%x1) Int @2 = -1 Int @3 = BitXor(@1, @2) Int @4 = BitXor(@0, b@3) Void@5 = Return(@4, Terminal) // Old optimized AIR Not %x1, %x1, @3 Xor %x0, %x1, %x0, @4 Ret %x0, @5 // New optimized AIR XorNot %x0, %x1, %x0, @4 Ret %x0, @5 The equivalent pattern of EON-with-shift is d = n ^ ((m ShiftType amount) ^ -1) Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = ArgumentReg(%x1) Int @2 = amount Int @3 = -1 Int @4 = Shl(@1, @2) Int @5 = BitXor(@4, @3) Int @6 = BitXor(@0, @5) Void b@7 = Return(b@6, Terminal) // Old optimized AIR Lshift %x1, amount, %x1, @4 Not %x1, %x1, @5 Xor %x0, %x1, %x0, @6 Ret %x0, @7 // New optimized AIR XorNotLeftShift %x0, %x1, $63, %x0, @6 Ret %x0, @7 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::xorNot32): (JSC::MacroAssemblerARM64::xorNot64): (JSC::MacroAssemblerARM64::xorNotLeftShift32): (JSC::MacroAssemblerARM64::xorNotRightShift32): (JSC::MacroAssemblerARM64::xorNotUnsignedRightShift32): (JSC::MacroAssemblerARM64::xorNotLeftShift64): (JSC::MacroAssemblerARM64::xorNotRightShift64): (JSC::MacroAssemblerARM64::xorNotUnsignedRightShift64): * assembler/testmasm.cpp: (JSC::testXorNot32): (JSC::testXorNot64): (JSC::testXorNotWithLeftShift32): (JSC::testXorNotWithRightShift32): (JSC::testXorNotWithUnsignedRightShift32): (JSC::testXorNotWithLeftShift64): (JSC::testXorNotWithRightShift64): (JSC::testXorNotWithUnsignedRightShift64): * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testXorNot32): (testXorNot64): (testXorNotWithLeftShift32): (testXorNotWithRightShift32): (testXorNotWithUnsignedRightShift32): (testXorNotWithLeftShift64): (testXorNotWithRightShift64): (testXorNotWithUnsignedRightShift64): (addBitTests): 2021-07-20 Yusuke Suzuki [JSC] invalidParameterInstanceofSourceAppender should care direct call of Symbol.hasInstance https://bugs.webkit.org/show_bug.cgi?id=228075 rdar://80762879 Reviewed by Frédéric Wang. invalidParameterInstanceofSourceAppender can be invoked without `instanceof` expression since we can call `[Symbol.hasInstance]` function directly, but the implementation did not assume that. This patch fixes it to handle this direct call. * runtime/ExceptionHelpers.cpp: (JSC::invalidParameterInstanceofSourceAppender): 2021-07-19 Yusuke Suzuki [JSC] StructureStubInfo's m_identifier should follow to the same protocol of inlineAccessBaseStructure https://bugs.webkit.org/show_bug.cgi?id=228092 Reviewed by Saam Barati. In r279813, we fixed a race condition related to inlineAccessBaseStructure: while we clear inlineAccessBaseStructure, we still run code relying on this field's value until stub version of the code is generated. As a result, we run the code which relies on the cells that are already collected. And we have the same problem with m_identifier field too. This patch makes m_identifier follow to the same protocol of inlineAccessBaseStructure so that we fix this race issue too: both fields will be alive until we switch to the code that are not relying on these fields. We also make inlineAccessBaseStructure to m_inlineAccessBaseStructure to easily find that this is member field. And we also use setWithoutWriteBarrier for m_inlineAccessBaseStructure since we emit codeBlock->vm().heap.writeBarrier(codeBlock) immediately after that. * bytecode/AccessCase.cpp: (JSC::AccessCase::fromStructureStubInfo): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/InByStatus.cpp: (JSC::InByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeForStubInfo): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::initGetByIdSelf): (JSC::StructureStubInfo::initArrayLength): (JSC::StructureStubInfo::initStringLength): (JSC::StructureStubInfo::initPutByIdReplace): (JSC::StructureStubInfo::initInByIdSelf): (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::reset): (JSC::StructureStubInfo::visitAggregateImpl): (JSC::StructureStubInfo::visitWeakReferences): (JSC::StructureStubInfo::propagateTransitions): (JSC::StructureStubInfo::setCacheType): Deleted. * bytecode/StructureStubInfo.h: 2021-07-19 Mark Lam DFG's parseIntResult() should check for negative zero. https://bugs.webkit.org/show_bug.cgi?id=228068 rdar://80788603 Reviewed by Yusuke Suzuki. We have to check for negative zero explicitly because C++ evaluates 0.0 == -0.0 as true. * dfg/DFGOperations.cpp: (JSC::DFG::parseIntResult): 2021-07-19 Yusuke Suzuki [JSC] InByStatus / InByVariant should visit CacheableIdentifier https://bugs.webkit.org/show_bug.cgi?id=228088 rdar://80794604 Reviewed by Mark Lam. After r278445, InByVariant holds CacheableIdentifier. And this can have String/Symbol cells if this variant is generated by in_by_val. In that case, we must visit this cell as GetByStatus / GetByVariant are doing. * bytecode/InByStatus.cpp: (JSC::InByStatus::visitAggregateImpl): * bytecode/InByStatus.h: * bytecode/InByVariant.cpp: (JSC::InByVariant::visitAggregateImpl): * bytecode/InByVariant.h: * bytecode/RecordedStatuses.cpp: (JSC::RecordedStatuses::visitAggregateImpl): 2021-07-16 Yijia Huang Add ExtendType to Air::Arg Index to fully utilize address computation in memory instruction for ARM64 https://bugs.webkit.org/show_bug.cgi?id=227970 Reviewed by Saam Barati. The pattern recognition of address computation in the instructions, e.g., Load Resistor (LDR), Store Register (STR), etc., can benefit the instruction selector. Then, the Air operand BaseIndex containing base, index, and scale is introduced to Air opcode. However, the option of index address is not fully leveraged in the previous implementation. To fill that gap, this patch adds a new member, MacroAssembler::Extend, to the current design of BaseIndex to trigger zero/sign extension on the Index address. And this is enabled for Store/Load with valid index address and shift amount. Maybe, the ideal approach is to introduce a decorator (Index@EXT) to the Air operand to provide an extension opportunity for the specific form of the Air opcode. Load Register (LDR) calculates an address from a base register value and an offset register value, loads a word from memory, and writes it to a register. The offset register value can optionally be shifted and extended. Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = Z/SExt32(Trunc(ArgumentReg(%x1))) Int @2 = scale Int @3 = Shl(@1, @2) Int @4 = Add(@0, @3) Int @5 = Load(@4, ControlDependent|Reads:Top) Void@6 = Return(@5, Terminal) // Old optimized AIR Move %x1, %x1, @1 Move (%x0,%x1,2^scale), %x0, @5 Ret %x0, @6 // New optimized AIR Move (%x0,%x1,2^scale), %x0, @5 Ret %x0, @6 Store Register (STR) calculates an address from a base register value and an offset register value, and stores a 32-bit word or a 64-bit doubleword to the calculated address, from a register. Given B3 IR: Int @0 = value Int @1 = ArgumentReg(%x0) Int @2 = Z/SExt32(Trunc(ArgumentReg(%x1)) Int @3 = scale Int @4 = Shl(@2, @3) Int @5 = Add(@1, @4) Void@6 = Store(@0, @5, ControlDependent|Writes:Top) Void@7 = Return(@0, Terminal) // Old optimized AIR Move32 %x1, %x1, @2 Store32 %xzr, (%x0,%x1,2^scale), @6 Move $0, %x0, @7 Ret32 %x0, @7 // New optimized AIR Store32 %xzr, (%x0,%x1,2^scale), @6 Move $0, %x0, @7 Ret32 %x0, @7 * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::BaseIndex::BaseIndex): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::indexExtendType): (JSC::MacroAssemblerARM64::load64): (JSC::MacroAssemblerARM64::load32): (JSC::MacroAssemblerARM64::load16): (JSC::MacroAssemblerARM64::load16SignedExtendTo32): (JSC::MacroAssemblerARM64::load8): (JSC::MacroAssemblerARM64::load8SignedExtendTo32): (JSC::MacroAssemblerARM64::store64): (JSC::MacroAssemblerARM64::store32): (JSC::MacroAssemblerARM64::store16): (JSC::MacroAssemblerARM64::store8): (JSC::MacroAssemblerARM64::loadDouble): (JSC::MacroAssemblerARM64::loadFloat): (JSC::MacroAssemblerARM64::storeDouble): (JSC::MacroAssemblerARM64::storeFloat): * b3/B3LowerToAir.cpp: * b3/air/AirArg.h: (JSC::B3::Air::Arg::index): (JSC::B3::Air::Arg::asBaseIndex const): * b3/testb3.h: * b3/testb3_2.cpp: (testLoadZeroExtendIndexAddress): (testLoadSignExtendIndexAddress): (testStoreZeroExtendIndexAddress): (testStoreSignExtendIndexAddress): (addBitTests): 2021-07-16 Saam Barati Grab the lock in FTL::Thunks::keyForSlowPathCallThunk https://bugs.webkit.org/show_bug.cgi?id=227988 Reviewed by Mark Lam. Both FTL::Thunks::keyForSlowPathCallThunk and FTL::Thunks::getSlowPathCallThunk both touch the thunks hash map. In r278030, when I added the lock, I grabbed it in getSlowPathCallThunk, but forgot to also grab it in keyForSlowPathCallThunk. * ftl/FTLThunks.h: (JSC::FTL::Thunks::keyForSlowPathCallThunk): 2021-07-16 Commit Queue Unreviewed, reverting r279916. https://bugs.webkit.org/show_bug.cgi?id=228037 some of tests are timing out Reverted changeset: "Convert small JIT pool tests into executable fuzzing" https://bugs.webkit.org/show_bug.cgi?id=226279 https://commits.webkit.org/r279916 2021-07-16 Yusuke Suzuki [JSC] RegExp::dumpToStream must not ref Strings since it is called concurrently https://bugs.webkit.org/show_bug.cgi?id=228031 rdar://80686425 Reviewed by Mark Lam. RegExp::dumpToStream's escapedPattern can return m_pattern. In that case, it is refed in the concurrent thread. This is wrong since StringImpl must not be ref-ed concurrently. This patch just revert this function to the old behavior. * runtime/RegExp.cpp: (JSC::RegExp::dumpToStream): 2021-07-15 Keith Miller Alias JSC graph dumping options https://bugs.webkit.org/show_bug.cgi?id=228015 Reviewed by Yusuke Suzuki. My brain seems to associate the phases with the tier we are compiling in rather than the type of graph we are processing. At this point it's probably easier to just add an alias rather than convince me otherwise. * runtime/OptionsList.h: 2021-07-15 Yusuke Suzuki [JSC] SamplingProfiler should recognize RegExp execution https://bugs.webkit.org/show_bug.cgi?id=201702 Reviewed by Saam Barati. This patch extends SamplingProfiler to recognize RegExp execution. We record executing RegExp in VM via MatchingContextHolder so that SamplingProfiler can detect it. We use MatchingContextHolder even if the RegExp is interpreter mode so that we can still catch non-JIT RegExp in SamplingProfiler. The example output is the following. Sampling rate: 1000.000000 microseconds. Total samples: 1830 Top functions as 466 'Exec#:4' 225 '/(^|[^\\])\"\\\/Qngr\((-?[0-9]+)\)\\\/\"/g#:-1' 173 'runBlock1#:4' 88 '/NQ_VQ/g#:-1' 83 '/d2/g#:-1' 78 '/d1/g#:-1' 70 '/\s?;\s?/#:-1' 68 'replace#:3' 50 '/(((\w+):\/\/)([^\/:]*)(:(\d+))?)?([^#?]*)(\?([^#]*))?(#(.*))?/#:-1' 49 'runBlock0#:4' 46 '#:-1' 24 '/^\s*|\s*$/g#:-1' Sampling rate: 1000.000000 microseconds. Total samples: 1830 Tier breakdown: ----------------------------------- LLInt: 13 (0.710383%) Baseline: 54 (2.950820%) DFG: 187 (10.218579%) FTL: 612 (33.442623%) js builtin: 73 (3.989071%) Wasm: 0 (0.000000%) Host: 0 (0.000000%) RegExp: 907 (49.562842%) C/C++: 0 (0.000000%) Unknown Executable: 57 (3.114754%) Hottest bytecodes as 378 'Exec#:FTL:bc#27' 225 '/(^|[^\\])\"\\\/Qngr\((-?[0-9]+)\)\\\/\"/g#:RegExp:' 88 '/NQ_VQ/g#:RegExp:' 83 '/d2/g#:RegExp:' 78 '/d1/g#:RegExp:' 70 '/\s?;\s?/#:RegExp:' 62 'replace#:FTL:bc#63' 53 'Exec#:DFG:bc#27' 50 '/(((\w+):\/\/)([^\/:]*)(:(\d+))?)?([^#?]*)(\?([^#]*))?(#(.*))?/#:RegExp:' 46 '#:None:' 42 'runBlock1#:FTL:bc#1795' 29 'runBlock1#:FTL:bc#1849' 29 'runBlock1#:FTL:bc#1741' 24 '/^\s*|\s*$/g#:RegExp:' 17 'runBlock1#:DFG:bc#1741' 17 'runBlock1#:DFG:bc#1795' 16 '/\b\w+\b/g#:RegExp:' 14 '/TNQP=([^;]*)/i#:RegExp:' 13 '/%\w?$/#:RegExp:' 12 '/^ba/#:RegExp:' 11 '/^\s*(\S*(\s+\S+)*)\s*$/#:RegExp:' 10 'runBlock0#:FTL:bc#400' 10 'runBlock1#:DFG:bc#1849' 10 'Exec#:DFG:bc#16' 9 '/(?:ZFVR.(\d+\.\d+))|(?:(?:Sversbk|TenaCnenqvfb|Vprjrnfry).(\d+\.\d+))|(?:Bcren.(\d+\.\d+))|(?:NccyrJroXvg.(\d+(?:\.\d+)?))/#:RegExp:' 8 '/##yv18##/gi#:RegExp:' 8 '/([a-zA-Z]|\s)+/#:RegExp:' 7 '/JroXvg\/(\S+)/#:RegExp:' 7 'runBlock0#:FTL:bc#2671' 7 '/^([#.]?)((?:[\w\u0128-\uffff*_-]|\\.)*)/#:RegExp:' 6 '/##oe##/gi#:RegExp:' 6 'runBlock1#:FTL:bc#124' 6 '/[+, ]/#:RegExp:' 6 'runBlock1#:FTL:bc#1903' 6 'replace#:DFG:bc#63' 5 'runBlock0#:FTL:bc#3378' 5 '/'/g#:RegExp:' 5 '/##yv20##/gi#:RegExp:' 4 '/\?[\w\W]*(sevraqvq|punaaryvq|tebhcvq)=([^\&\?#]*)/i#:RegExp:' 4 'load#:None:' * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/RegExp.cpp: (JSC::RegExp::matchCompareWithInterpreter): (JSC::RegExp::dumpToStream): (JSC::appendLineTerminatorEscape): (JSC::appendLineTerminatorEscape): (JSC::escapePattern): (JSC::RegExp::escapedPattern const): Moved from RegExpPrototype.cpp to implement RegExp::toSourceString and RegExp::escapedPattern. (JSC::RegExp::toSourceString const): (JSC::regexpToSourceString): Deleted. * runtime/RegExp.h: * runtime/RegExpInlines.h: (JSC::RegExp::matchInline): * runtime/RegExpPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::appendLineTerminatorEscape): Deleted. (JSC::appendLineTerminatorEscape): Deleted. (JSC::regExpProtoGetterSourceInternal): Deleted. * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::takeSample): (JSC::SamplingProfiler::processUnverifiedStackTraces): (JSC::SamplingProfiler::StackFrame::nameFromCallee): (JSC::SamplingProfiler::StackFrame::displayName): (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests): (JSC::SamplingProfiler::StackFrame::functionStartLine): (JSC::SamplingProfiler::StackFrame::functionStartColumn): (JSC::SamplingProfiler::StackFrame::sourceID): (JSC::SamplingProfiler::StackFrame::url): (JSC::SamplingProfiler::reportTopBytecodes): (WTF::printInternal): * runtime/SamplingProfiler.h: * runtime/VM.h: * yarr/YarrJIT.cpp: (JSC::Yarr::MatchingContextHolder::MatchingContextHolder): Deleted. (JSC::Yarr::MatchingContextHolder::~MatchingContextHolder): Deleted. * yarr/YarrJIT.h: (JSC::Yarr::MatchingContextHolder::offsetOfStackLimit): Deleted. (JSC::Yarr::MatchingContextHolder::offsetOfPatternContextBuffer): Deleted. (JSC::Yarr::MatchingContextHolder::offsetOfPatternContextBufferSize): Deleted. * yarr/YarrMatchingContextHolder.h: Added. (JSC::Yarr::MatchingContextHolder::offsetOfStackLimit): (JSC::Yarr::MatchingContextHolder::offsetOfPatternContextBuffer): (JSC::Yarr::MatchingContextHolder::offsetOfPatternContextBufferSize): (JSC::Yarr::MatchingContextHolder::MatchingContextHolder): (JSC::Yarr::MatchingContextHolder::~MatchingContextHolder): 2021-07-15 Yusuke Suzuki [JSC] Harden defaultTimeZone retrieval https://bugs.webkit.org/show_bug.cgi?id=227996 rdar://80540300 Reviewed by Mark Lam. We received the report that "UTC" can appear in Intl.DateTimeFormat's default timezone. While we cannot reproduce it, this patch attempts to avoid using TimeZone from UCalendar so that the code gets the same to the old defaultTimeZone implementation. * runtime/JSDateMath.cpp: (JSC::DateCache::defaultTimeZone): (JSC::DateCache::timeZoneCacheSlow): 2021-07-15 Mark Lam JITWorklist::waitUntilAllPlansForVMAreReady() should also be notified when plans are cancelled. https://bugs.webkit.org/show_bug.cgi?id=228003 rdar://78314543 Reviewed by Yusuke Suzuki. Previously, it only gets notified when plans are done compiling. As a result, if JITWorklist::waitUntilAllPlansForVMAreReady() found non-ready plans and started waiting, and those plans were canceled, then JITWorklist::waitUntilAllPlansForVMAreReady() can hang indefinitely. This patch renames JITWorklist::::m_planCompiled to m_planCompiledOrCancelled, and notifies it also when plans are cancelled. * jit/JITWorklist.cpp: (JSC::JITWorklist::waitUntilAllPlansForVMAreReady): (JSC::JITWorklist::removeMatchingPlansForVM): * jit/JITWorklist.h: * jit/JITWorklistThread.cpp: (JSC::JITWorklistThread::work): 2021-07-15 Yusuke Suzuki [JSC] Add samplingProfilerIgnoreExternalSourceID option https://bugs.webkit.org/show_bug.cgi?id=227985 Reviewed by Mark Lam. We can ignore sourceID when aggregating samples. By doing so, we can open Speedometer2 style iframes and still aggregate all the functions even though each script in iframe has different source ID. * runtime/OptionsList.h: * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::StackFrame::sourceID): (JSC::SamplingProfiler::reportTopFunctions): * runtime/SamplingProfiler.h: 2021-07-15 Adrian Perez de Castro Non-unified build fixes, mid-July 2021 edition https://bugs.webkit.org/show_bug.cgi?id=227981 Unreviewed non-unified build fixes. * ftl/FTLState.cpp: Add missing B3ValueInlines.h header. * runtime/TemporalNow.cpp: Add missing JSCJSValueInlines.h and JSObjectInlines.h headers. * runtime/TemporalObject.cpp: Ditto. 2021-07-14 Devin Rousso Implement Array.prototype.findLast and Array.prototype.findLastIndex https://bugs.webkit.org/show_bug.cgi?id=227939 Reviewed by Yusuke Suzuki. * builtins/ArrayPrototype.js: (findLast): Added. (findLastIndex): Added. (JSC::ArrayPrototype::finishCreation): * runtime/JSTypedArrayViewPrototype.cpp: * builtins/TypedArrayPrototype.js: (findLast): Added. (findLastIndex): Added. * runtime/ArrayPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): * runtime/OptionsList.h: 2021-07-14 Michael Saboff [macOS] Add new entitlement to limit process to a single JIT region https://bugs.webkit.org/show_bug.cgi?id=227956 Reviewed by Mark Lam. This macOS entitlement limits a process to a single JIT region. This matches the behavior on iOS. * Scripts/process-entitlements.sh: * entitlements.plist: 2021-07-14 Mark Lam Speculative fix for failed scope.releaseAssertNoException() after calls to JSMap::create(). https://bugs.webkit.org/show_bug.cgi?id=227964 rdar://78013960 Reviewed by Yusuke Suzuki. There have been reports of flaky failures on the scope.releaseAssertNoException() after the call to JSMap::create() in JSModuleLoader::finishCreation(). The scope.releaseAssertNoException() says that we don't expect the JSMap::create() to ever throw an exception. If the assertion is true, the only way that we can see an exception there is if we're throwing an asynchronous TerminationException. Since JSModuleLoader::finishCreation() does not have any long running loops, we can just DeferTerminationForAWhile and let the next exception check site throw the asynchronous TerminationException. We don't want to just use DeferTermination because it will throw the TerminationException right at the end of JSModuleLoader::finishCreation(), and the caller of JSModuleLoader::finishCreation() may be similarly not expecting an exception to be thrown there. Also apply the same treatment to AbstractModuleRecord::finishCreation(), and getBackingMap() in WebCore for the same reason. Other than those, other sites that call JSMap::create() already check for exceptions. So, those sites do not need to DeferTerminationForAWhile. * runtime/AbstractModuleRecord.cpp: (JSC::AbstractModuleRecord::finishCreation): * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::finishCreation): 2021-07-14 Keith Miller Convert small JIT pool tests into executable fuzzing https://bugs.webkit.org/show_bug.cgi?id=226279 Right now, we try to test our engine on a small JIT pool. This isn't a known configuration for any actual ports and causes issues if we run out of JIT memory when we need to compile an OSR exit. Instead of testing such a small pool we should just fuzz each executable allocation that says it can fail. The current fuzzing doesn't do a good job tracking the number of DFG/FTL compiles when allocations fail, so when enabled those tests will just exit early. Also, right now we use a random seed picked by the engine for these tests, which makes it hard to reproduce crashes on the bots. If we see flakiness on the bots we can have the harness pass in a number so it gets logged in the repro command. Reviewed by Michael Saboff. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::numberOfDFGCompiles): * jit/ExecutableAllocationFuzz.cpp: (JSC::doExecutableAllocationFuzzing): * jsc.cpp: (runJSC): 2021-07-14 Mark Lam Check for out of memory in JSC::globalFuncEscape() and JSC::globalFuncUnescape(). https://bugs.webkit.org/show_bug.cgi?id=227962 rdar://78392251 Reviewed by Yusuke Suzuki. * runtime/JSGlobalObjectFunctions.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): 2021-07-14 Yusuke Suzuki libpas executable-allocator should reserve more than 256KB for non-fail region at least https://bugs.webkit.org/show_bug.cgi?id=227927 Reviewed by Keith Miller. libpas jit_heap has mediam allocator which allocates 128KB pages at once. However, our JSC stress tests are setting 100KB for small executable memory tests. As a result, under this configuration, we fail immediately after using medium allocator. But this test's "total size of executable memory is 100KB" is unrealistic: it is possible that only 100KB memory remains, but it is impossible that we reserve only 25KB for non-fail reservation. In production, we are always reserving 128MB. So this configuration is not realistic actually. So, this patch changes, 1. If non-fail region is less than 256KB, then we add 256KB and keep this 256KB as non-fail executable allocation. If not, use 0.25 ratio as we are doing. This means that Options::jitMemoryReservationSize configures failable region of executable memory. 2. We also revive bytesReserved and bytesAllocated to make memoryPressureMultiplier and early-fail allocation (when there is not enough memory and allocation can fail, then we should fail). * jit/ExecutableAllocator.cpp: (JSC::initializeJITPageReservation): (JSC::ExecutableAllocator::underMemoryPressure): (JSC::ExecutableAllocator::memoryPressureMultiplier): (JSC::ExecutableAllocator::allocate): (JSC::ExecutableMemoryHandle::createImpl): (JSC::ExecutableMemoryHandle::~ExecutableMemoryHandle): (JSC::ExecutableMemoryHandle::shrink): (JSC::ExecutableMemoryHandle::sizeInBytes const): Deleted. * jit/ExecutableMemoryHandle.h: (JSC::ExecutableMemoryHandle::sizeInBytes const): (JSC::ExecutableMemoryHandle::ExecutableMemoryHandle): 2021-07-14 Mark Lam Placate exception checker validation in operationObjectAssignUntyped. https://bugs.webkit.org/show_bug.cgi?id=227955 rdar://80503746 Reviewed by Michael Saboff. * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): 2021-07-13 Robin Morisset Invalid machine code emitted by SpeculativeJIT::emitObjectOrOtherBranch https://bugs.webkit.org/show_bug.cgi?id=227869 Reviewed by Mark Lam. SpeculativeJIT::emitObjectOrOtherBranch used to check the validity of the masqueradesAsUndefined watchpoint twice, and assumed that it could not change in between. That is clearly incorrect as the main thread is running concurrently with it, and so the watchpoint could fire at any time. The fix is trivial: just check the validity once, and store the result in a boolean. If the watchpoint triggers later that is fine: we'll notice and cancel the compilation (see WatchpointCollectionPhase, Plan::isStillValid() and Plan::finalize()). The change only protects us from rare and hard-to-reproduce crashes on debug builds caused by an ASSERT firing. I did not add a testcase, as I can only reproduce the bug by adding an extra wait in the middle of emitObjectOrOtherBranch. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): 2021-07-13 Yijia Huang Add a new Air::Arg kind ZeroReg to let AIR recognise the new instructions/forms accepting zero register in ARM64 https://bugs.webkit.org/show_bug.cgi?id=227510 Reviewed by Saam Barati. B3 is designed to be portable to many kinds of CPUs. However, to effectively compile code to different CPUs, the compiler must eventually make explicit instruction set details. Then, Air is introduced, and it is designed to target individual CPU architectures and generate instructions specific to those CPUs. Previously, Air don't recognize the zero register. This problem has been pointed out in #174821, which was trying to introduce the new opcodes to handle the zero register. To solve this problem in a modular reasoning approach, a new Air operand ZeroReg should be introduced. Its goal is to closely match the CPU instructions accepting the zero register in ARM64. Another reason is that the new overloads of the instructions taking the zero register can benefit instruction selection with this implementation. Here, the ZeroReg is added as a new kind for Air::Arg, which acts as a "high level" operand to be emitted with the associative opcodes. In ARM64, the ZeroReg would be emitted as a zero register. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::storeZero64): Deleted. (JSC::MacroAssemblerARM64::storeZero32): Deleted. (JSC::MacroAssemblerARM64::storeZero16): Deleted. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::storeZero32): Deleted. (JSC::MacroAssemblerX86Common::storeZero16): Deleted. * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::storeZero64): Deleted. * b3/B3LowerToAir.cpp: * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::jsHash const): (JSC::B3::Air::Arg::dump const): (WTF::printInternal): * b3/air/AirArg.h: (JSC::B3::Air::Arg::zeroReg): (JSC::B3::Air::Arg::isZeroReg const): (JSC::B3::Air::Arg::isGP const): (JSC::B3::Air::Arg::isFP const): (JSC::B3::Air::Arg::isValidForm const): (JSC::B3::Air::Arg::asZeroReg const): * b3/air/AirLowerStackArgs.cpp: (JSC::B3::Air::lowerStackArgs): * b3/air/AirOpcode.opcodes: * b3/air/opcode_generator.rb: * b3/testb3.h: * b3/testb3_1.cpp: (run): * b3/testb3_3.cpp: (testStoreZeroReg): 2021-07-12 Filip Pizlo and Yusuke Suzuki New malloc algorithm https://bugs.webkit.org/show_bug.cgi?id=226404 Reviewed by Yusuke Suzuki. Switch the ExecutableAllocator to the libpas jit_heap. The libpas jit_heap uses two size categories of bitfit and a large heap, and is happy to do its approximate first-fit in any ranges of memory you give it. Jit_heap never allocates metadata inside the memory it manages. Allocations and deallocations take a constant-bounded amount of time except for unusual situations, and are protected by fine-grained locking in most cases. Decommit follows libpas scavenging policy. This alone is a speed-up on Speedometer (probably about 1% or more). Also expose some libpas introspection via $vm. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssemblerCodeRef.h: * jit/ExecutableAllocator.cpp: (JSC::ExecutableAllocator::underMemoryPressure): (JSC::ExecutableAllocator::memoryPressureMultiplier): (JSC::ExecutableAllocator::allocate): (JSC::ExecutableAllocator::committedByteCount): (JSC::ExecutableMemoryHandle::createImpl): (JSC::ExecutableMemoryHandle::~ExecutableMemoryHandle): (JSC::ExecutableMemoryHandle::sizeInBytes const): (JSC::ExecutableMemoryHandle::shrink): * jit/ExecutableAllocator.h: * jit/ExecutableMemoryHandle.h: Added. (JSC::ExecutableMemoryHandle::start const): (JSC::ExecutableMemoryHandle::end const): (JSC::ExecutableMemoryHandle::startAsInteger const): (JSC::ExecutableMemoryHandle::endAsInteger const): (JSC::ExecutableMemoryHandle::containsIntegerAddress const): (JSC::ExecutableMemoryHandle::contains const): (JSC::ExecutableMemoryHandle::key const): (JSC::ExecutableMemoryHandle::dump const): (JSC::ExecutableMemoryHandle::ExecutableMemoryHandle): * tools/JSDollarVM.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::JSDollarVM::finishCreation): 2021-07-12 Mark Lam Revert r277027: breaks GC. https://bugs.webkit.org/show_bug.cgi?id=227888 Reviewed by Saam Barati. The patch in r277027 to make deletion of GCAwareJITStubRoutines incremental has a bug: the routine may not be deleted yet by the incremental sweeper before the next GC cycle, and the GC will not be happy visiting dead cell pointers in that routine. There is also another bug with the triggering of sweeping. For now, we're reverting the patch, and will revisit this at a later time. * CMakeLists.txt: * heap/Heap.cpp: (JSC::Heap::deleteUnmarkedCompiledCode): (JSC::Heap::sweepSynchronously): * heap/Heap.h: * heap/HeapInlines.h: (JSC::Heap::mayHaveJITStubRoutinesToDelete): Deleted. (JSC::Heap::deleteDeadJITStubRoutines): Deleted. * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::doSweep): * heap/JITStubRoutineSet.cpp: (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): * heap/JITStubRoutineSet.h: (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): (JSC::JITStubRoutineSet::traceMarkedStubRoutines): (JSC::JITStubRoutineSet::mayHaveRoutinesToDelete): Deleted. (JSC::JITStubRoutineSet::notifyHaveRoutinesToDelete): Deleted. * jit/GCAwareJITStubRoutine.cpp: (JSC::GCAwareJITStubRoutine::observeZeroRefCount): * jit/JITStubRoutine.h: (JSC::JITStubRoutine::createSelfManagedRoutine): 2021-07-12 Yijia Huang Add SMNEGL, UMNEGL, UMADDL, and UMSUBL for ARM64 and select this instruction in Air https://bugs.webkit.org/show_bug.cgi?id=227857 Reviewed by Robin Morisset. The previous patches have already added MNEG, MADD, MSUB, SMADDL, and SMSUBL. This patch completes the corresponding signed or unsigned variants (SMNEGL, UMNEGL, UMADDL, and UMSUBL) of them. In addition, this patch refactors the implementation and the associative test cases of MADD, MSUB, and MNEG to be more readable and maintainable w.r.t their variants. ------------------------------ ### SMNEGL/UMNEGL Xd Wn Wm ### ------------------------------ Signed/Unsigned Multiply-Negate Long multiplies two 32-bit register values, negates the product, and writes the result to the 64-bit destination register. The equivalent patterns are d = -(SExt32(n) * SExt32(m)) and d = -(ZExt32(n) * ZExt32(m)) respectively. Given B3 IR: Int @0 = S/ZExt32(Trunc(ArgumentReg(%x0))) Int @1 = S/ZExt32(Trunc(ArgumentReg(%x1))) Int @2 = Mul(@0, @1) Int @3 = Neg(@2) Void@4 = Return(@3, Terminal) // Old optimized AIR Move32 %x0, %x0, @0 Move32 %x1, %x1, @1 MultiplyNeg %x0, %x1, %x0, @3 Ret %x0, @4 // New optimized AIR MultiplyNegSign/ZeroExtend %x0, %x1, %x0, @3 Ret %x0, @4 -------------------------- ### UMADDL Xd Wn Wm Xa ### -------------------------- Unsigned Multiply-Add Long multiplies two 32-bit register values, adds a 64-bit register value, and writes the result to the 64-bit destination register. The equivalent patterns are d = ZExt32(n) * ZExt32(m) + a or d = a + ZExt32(n) * ZExt32(m) Given B3 IR: Int @0 = ZExt32(Trunc(ArgumentReg(%x0))) Int @1 = ZExt32(Trunc(ArgumentReg(%x1))) Int @2 = ArgumentReg(%x2) Int @3 = Mul(@0, @1) Int @4 = Add(@3, @2) Void@5 = Return(@4, Terminal) // Old optimized AIR Move32 %x0, %x0, @1 Move32 %x1, %x1, @2 MultiplyAdd %x0, %x1, %x2, %x0, @4 Ret64 %x0, @5 // New optimized AIR MultiplyAddZeroExtend %x0, %x1, %x2, %x0, @8 Ret %x0, @9 -------------------------- ### UMSUBL Xd Wn Wm Xa ### -------------------------- Unsigned Multiply-Subtract Long multiplies two 32-bit register values, subtracts the product from a 64-bit register value, and writes the result to the 64-bit destination register. The equivalent patterns are d = a - ZExt32(n) * ZExt32(m) Given B3 IR: Int @0 = ZExt32(Trunc(ArgumentReg(%x0))) Int @1 = ZExt32(Trunc(ArgumentReg(%x1))) Int @2 = ArgumentReg(%x2) Int @3 = Mul(@0, @1) Int @4 = Sub(@2, @3) Void@5 = Return(@4, Terminal) // Old optimized AIR Move32 %x0, %x0, @1 Move32 %x1, %x1, @2 MultiplySub %x0, %x1, %x2, %x0, @4 Ret64 %x0, @5 // New optimized AIR MultiplySubZeroExtend %x0, %x1, %x2, %x0, @8 Ret %x0, @9 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::multiplyNeg32): (JSC::MacroAssemblerARM64::multiplyAddZeroExtend32): (JSC::MacroAssemblerARM64::multiplySubZeroExtend32): (JSC::MacroAssemblerARM64::multiplyNeg64): (JSC::MacroAssemblerARM64::multiplyNegSignExtend32): (JSC::MacroAssemblerARM64::multiplyNegZeroExtend32): * assembler/testmasm.cpp: (JSC::testMultiplyAddSignExtend32): (JSC::testMultiplyAddZeroExtend32): (JSC::testMultiplySubSignExtend32): (JSC::testMultiplySubZeroExtend32): (JSC::testMultiplyNegSignExtend32): (JSC::testMultiplyNegZeroExtend32): (JSC::testMultiplyAddSignExtend32Left): Deleted. (JSC::testMultiplyAddSignExtend32Right): Deleted. * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testMulAddArgsLeft): (testMulAddArgsRight): (testMulAddSignExtend32ArgsLeft): (testMulAddZeroExtend32ArgsLeft): (testMulAddZeroExtend32ArgsRight): (testMulSubArgsLeft): (testMulSubArgsRight): (testMulSubArgsRight32): (testMulSubSignExtend32): (testMulSubZeroExtend32): (testMulNegArgArg): (testMulNegArgs): (testMulNegArgs32): (testMulNegSignExtend32): (testMulNegZeroExtend32): (testMulSubSignExtend32Args): Deleted. * b3/testb3_3.cpp: (addArgTests): 2021-07-12 Yusuke Suzuki [JSC] JITCage already includes guard pages https://bugs.webkit.org/show_bug.cgi?id=227867 Reviewed by Mark Lam. Since JITCage already includes guard pages, we do not need to allocate that additionally. * jit/ExecutableAllocator.cpp: (JSC::initializeJITPageReservation): 2021-07-10 Saam Barati Continue to consult InlineAccess's Structure even after switching to a stub IC https://bugs.webkit.org/show_bug.cgi?id=227785 Reviewed by Yusuke Suzuki. This patch fixes a crash in: stress/class-subclassing-function.js The bug is this: 1. We initialize a StructureStubInfo to be an inline self access doing a load based on structure S. 2. We transition to being a PolymorphicAccess based StructureStubInfo. But, we haven't generated code yet. We're in the buffered state. So we are still running the inline access from (1). But the StructureStubInfo thinks it's a "Stub". 3. S is collected 4. We continue to run code from (1), because when we finalize the IC during GC, it doesn't think it's an inline access. The fix is to always track the structure S that we used when generating the inline access, and to only stop tracking it once we've generated code for the Stub. * bytecode/AccessCase.cpp: (JSC::AccessCase::fromStructureStubInfo): (JSC::AccessCase::propagateTransitions const): * bytecode/AccessCase.h: * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/InByStatus.cpp: (JSC::InByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::propagateTransitions const): * bytecode/PolymorphicAccess.h: * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeForStubInfo): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::initGetByIdSelf): (JSC::StructureStubInfo::initPutByIdReplace): (JSC::StructureStubInfo::initInByIdSelf): (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::reset): (JSC::StructureStubInfo::visitWeakReferences): (JSC::StructureStubInfo::propagateTransitions): * bytecode/StructureStubInfo.h: 2021-07-10 Yusuke Suzuki [JSC] Workaround test262.report bug by making $ properties enumerable https://bugs.webkit.org/show_bug.cgi?id=227855 Reviewed by Alexey Shvayka. test262.report's harness has a bug and it reports incorrect results for JSC on tests using $262 properties. This patch introduces a workaround which makes properties of $ enumerable. * jsc.cpp: 2021-07-08 Yijia Huang Add Air opcode add/sub-and-shift for ARM64 and select this instruction in Air https://bugs.webkit.org/show_bug.cgi?id=227509 Reviewed by Saam Barati. This patch includes two modifications: 1. Add add/sub-with-shift to Air opcode and the corresponding pattern match for instruction selection. 2. Minor fix in disassembler. Given the operation: add/sub Rd, Rn, Rm, ShiftType, amount ADD/SUB (shifted register), adds/subs a register value Rn and an optionally-shifted register value Rm, and writes the result to the destination register Rd. The instruction selector can utilize this to lowering certain patterns in B3 IR before further Air optimization. The equivalent pattern would be: d = n +/- (m ShiftType amount) Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = ArgumentReg(%x1) Int @2 = amount Int @3 = ZShr(@1, @2) Int @4 = Add/Sub(@0, @3) Void@5 = Return(@4, Terminal) // Old optimized AIR Shift %x1, amount, %x1, @3 Add/Sub %x0, %x1, %x0, @4 Ret %x0, @5 // New optimized AIR Add(Sub)Shift %x0, %x1, amount, %x0, @4 Ret %x0, @5 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::addLeftShift32): (JSC::MacroAssemblerARM64::addRightShift32): (JSC::MacroAssemblerARM64::addUnsignedRightShift32): (JSC::MacroAssemblerARM64::addLeftShift64): (JSC::MacroAssemblerARM64::addRightShift64): (JSC::MacroAssemblerARM64::addUnsignedRightShift64): (JSC::MacroAssemblerARM64::subLeftShift32): (JSC::MacroAssemblerARM64::subRightShift32): (JSC::MacroAssemblerARM64::subUnsignedRightShift32): (JSC::MacroAssemblerARM64::subLeftShift64): (JSC::MacroAssemblerARM64::subRightShift64): (JSC::MacroAssemblerARM64::subUnsignedRightShift64): * assembler/testmasm.cpp: (JSC::testAddWithLeftShift32): (JSC::testAddWithRightShift32): (JSC::testAddWithUnsignedRightShift32): (JSC::testAddWithLeftShift64): (JSC::testAddWithRightShift64): (JSC::testAddWithUnsignedRightShift64): (JSC::testSubWithLeftShift32): (JSC::testSubWithRightShift32): (JSC::testSubWithUnsignedRightShift32): (JSC::testSubWithLeftShift64): (JSC::testSubWithRightShift64): (JSC::testSubWithUnsignedRightShift64): * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: (checkUsesInstruction): * b3/testb3_2.cpp: (testAddWithLeftShift32): (testAddWithRightShift32): (testAddWithUnsignedRightShift32): (testAddWithLeftShift64): (testAddWithRightShift64): (testAddWithUnsignedRightShift64): (testSubWithLeftShift32): (testSubWithRightShift32): (testSubWithUnsignedRightShift32): (testSubWithLeftShift64): (testSubWithRightShift64): (testSubWithUnsignedRightShift64): (addBitTests): * disassembler/ARM64/A64DOpcode.cpp: * disassembler/ARM64/A64DOpcode.h: (JSC::ARM64Disassembler::A64DOpcodeAddSubtractShiftedRegister::immediate6): (JSC::ARM64Disassembler::A64DOpcodeLogicalShiftedRegister::immediate6): 2021-07-08 Keith Miller display-profiler-output should be able to print disassembly for the FTL https://bugs.webkit.org/show_bug.cgi?id=227798 Reviewed by Saam Barati. Right now running JSC with the bytecode profiler will not print disassembly for FTL code. This patch adds this support. In order to get execution counts there is a callback at the transition between each DFG node in the Air disassembler. Since B3 code move parts of DFG nodes to different basic blocks we don't include execution counts in the dump. However, the DFG-only graph printed before the disassembly will still have the counts. * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLState.cpp: (JSC::FTL::State::dumpDisassembly): * ftl/FTLState.h: (JSC::FTL::State::dumpDisassembly): 2021-07-08 Yusuke Suzuki Use JSC::Yarr::flagsString to get string representation of RegExp flags https://bugs.webkit.org/show_bug.cgi?id=227790 Reviewed by Keith Miller. * yarr/YarrFlags.h: 2021-07-07 Yusuke Suzuki [JSC] Clean up RegExp flag code https://bugs.webkit.org/show_bug.cgi?id=227786 Reviewed by Filip Pizlo. I found a bug in regexpToSourceString (used for RegExp's dump code), and it motivates me to clean up all RegExp flag handling code. We define RegExp flags as a macro and updating that macro updates all RegExp flag handling code too. * runtime/RegExp.cpp: (JSC::RegExpFunctionalTestCollector::outputOneTest): (JSC::regexpToSourceString): * runtime/RegExp.h: * runtime/RegExpPrototype.cpp: (JSC::flagsString): * yarr/YarrFlags.cpp: (JSC::Yarr::parseFlags): (JSC::Yarr::flagsString): * yarr/YarrFlags.h: 2021-07-07 Saam Barati JSArrayBufferView::byteOffsetConcurrently has a race when using PAC https://bugs.webkit.org/show_bug.cgi?id=227765 Reviewed by Mark Lam. We were calling JSArrayBufferView::vector(), which does PAC validation using the length() of the array. However, this can race with JSArrayBufferView::detach, which sets the length to zero, leading to sadness on the compiler thread. * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::vectorWithoutPACValidation const): * runtime/JSArrayBufferViewInlines.h: (JSC::JSArrayBufferView::byteOffsetImpl): 2021-07-07 Yusuke Suzuki [JSC] Fix Object.assign fast path to accept undefined/null https://bugs.webkit.org/show_bug.cgi?id=227769 rdar://80264271 Reviewed by Saam Barati. Object.assign can accept undefined or null as a second (or latter) parameters. If it is passed, the parameter is just ignored. Previous DFG / FTL optimization patch does not handle this case. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileObjectAssign): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileObjectAssign): * runtime/ObjectConstructor.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/ObjectConstructorInlines.h: (JSC::objectAssignFast): 2021-07-07 Mark Lam Heap::waitForCollector() needs to set m_mutatorDidRun. https://bugs.webkit.org/show_bug.cgi?id=227782 rdar://78326474 Reviewed by Saam Barati. Heap::waitForCollector() is one of 2 clients of Heap::stopIfNecessarySlow(unsigned oldState). The other client, Heap::stopIfNecessarySlow() sets m_mutatorDidRun to true after calling Heap::stopIfNecessarySlow(unsigned oldState). Heap::waitForCollector() needs to do the same. Constraint solvers rely on this. Without this, one fall out we've seen is that DOMGCOutputConstraint fails to visitOutputConstraints, and as a result, opaqueRoots may not get updated. This issue was caught by the GC verifier. * heap/Heap.cpp: (JSC::Heap::waitForCollector): 2021-07-07 Michael Saboff fitcored crashes at JavaScriptCore: JSC::Heap::releaseAccessSlow https://bugs.webkit.org/show_bug.cgi?id=227767 Reviewed by Geoffrey Garen. Speculative fix for this crash. We are crashing while destroying the VM as we are about to release the JSLock. In JSLock::willReleaseLock(), we release heap access. Therefore we don't need to release it again when undertaking the various shutdown steps in the VM destructor. Added a new scope class that will only release and then acquire heap access if the caller currently has heap access. * heap/ReleaseHeapAccessScope.h: (JSC::ReleaseHeapAccessIfNeededScope::ReleaseHeapAccessIfNeededScope): (JSC::ReleaseHeapAccessIfNeededScope::~ReleaseHeapAccessIfNeededScope): * jit/JITWorklist.cpp: (JSC::JITWorklist::waitUntilAllPlansForVMAreReady): 2021-07-07 Yusuke Suzuki [JSC] Do not allocate JITWorklist if JIT is disabled https://bugs.webkit.org/show_bug.cgi?id=227734 Reviewed by Mark Lam. Previously, this code was doing, if (Options::useJIT()) DFG::iterateCodeBlocksForGC(visitor, m_vm, func); But r278082 changed it to JITWorklist::ensureGlobalWorklist().iterateCodeBlocksForGC(visitor, m_vm, func); As a result, we are always allocating JITWorklist even JIT is not enabled. This patch fixes the behavior not to allocate JITWorklist. * heap/Heap.cpp: (JSC::Heap::iterateExecutingAndCompilingCodeBlocks): 2021-07-06 Yusuke Suzuki r270214 broke testb3 on arm64e https://bugs.webkit.org/show_bug.cgi?id=227713 Reviewed by Saam Barati. ARM64E CAS lacks isBranch case. This patch adds isBranch implementation. We also adjust disasm scanning test to support CAS in ARM64E. * assembler/testmasm.cpp: (JSC::testAtomicStrongCASFill8): (JSC::testAtomicStrongCASFill16): * b3/B3LowerToAir.cpp: * b3/testb3_8.cpp: (testAtomicWeakCAS): (testAtomicStrongCAS): (testAtomicXchg): 2021-07-06 Yusuke Suzuki Unreviewed, build fix after r279630 https://bugs.webkit.org/show_bug.cgi?id=223166 * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: 2021-07-06 Commit Queue Unreviewed, reverting r279546, r279554, r279558 and r279567. https://bugs.webkit.org/show_bug.cgi?id=227732 Speedometer/jQuery-TodoMVC 2-3% regression Reverted changesets: "[WebIDL] Rework runtime enabled properties leveraging PropertyCallback" https://bugs.webkit.org/show_bug.cgi?id=227275 https://commits.webkit.org/r279546 "[WebIDL] Generate constructor's hash table in GenerateConstructorHelperMethods" https://bugs.webkit.org/show_bug.cgi?id=227668 https://commits.webkit.org/r279554 "[WebIDL] Simplify generation of runtime conditionally read- write attributes" https://bugs.webkit.org/show_bug.cgi?id=227672 https://commits.webkit.org/r279558 "Use AbortSignal's [PrivateIdentifier] whenSignalAborted() static method" https://bugs.webkit.org/show_bug.cgi?id=227673 https://commits.webkit.org/r279567 2021-07-06 Philip Chimento [JSC] Implement Temporal https://bugs.webkit.org/show_bug.cgi?id=223166 Reviewed by Yusuke Suzuki. Intended to be the first patch in a stack. Adds boilerplate for Temporal in order to unblock further parallelizable work on this bug. This patch adds a feature flag for Temporal, and a toplevel Temporal global containing only Temporal.now, which is itself an empty object. These objects will be further populated in later patches. * CMakeLists.txt: Add TemporalObject and TemporalNow. Property lookup table in TemporalObject. * DerivedSources.make: Add TemporalObject property lookup table header. * JavaScriptCore.xcodeproj/project.pbxproj: Add new files. * Sources.txt: Add TemporalObject and TemporalNow. * runtime/CommonIdentifiers.h: Add 'Temporal' property key. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): Create the Temporal global if the feature flag is enabled. * runtime/OptionsList.h: Add useTemporal feature flag. * runtime/TemporalNow.cpp: Added. (JSC::TemporalNow::TemporalNow): (JSC::TemporalNow::create): (JSC::TemporalNow::createStructure): (JSC::TemporalNow::finishCreation): * runtime/TemporalNow.h: Added. * runtime/TemporalObject.cpp: Added. (JSC::createNowObject): (JSC::TemporalObject::TemporalObject): (JSC::TemporalObject::create): (JSC::TemporalObject::createStructure): (JSC::TemporalObject::finishCreation): * runtime/TemporalObject.h: Added. 2021-07-06 Yijia Huang Fix type error in testb3 https://bugs.webkit.org/show_bug.cgi?id=227722 Reviewed by Mark Lam. Fix type error in testb3. Shift amount should be 32-bit constant. * b3/testb3_3.cpp: (testInsertSignedBitfieldInZero64): (testExtractSignedBitfield64): 2021-07-05 Yusuke Suzuki [JSC] Optimize Object.assign and putDirectInternal https://bugs.webkit.org/show_bug.cgi?id=227677 Reviewed by Filip Pizlo. This patch improves Object.assign performance (and this requires putDirectInternal improvement). 1. Object.assign is handled by DFG / FTL as ObjectAssign node 2. We found that putDirectInternal is suboptimal. This patch removes several bottlenecks. They are super critical from the measurement of microbenchmarks. 2.1. Creating and destroying DeferredStructureTransitionWatchpointFire is not free. We should do that only when we need it. 2.2. Before r277620, we are checking m_replacementWatchpointSets's nullptr and that was fast. But after that, we are always calling HashMap::get, and it is not inlined. This means that if we have StructureRareData, we are always calling HashMap::get even though there is no m_replacementWatchpointSets set. This patch adds HashMap::isNullStorage to avoid this call by inlinely check this via `LIKELY(m_replacementWatchpointSets.isNullStorage())`. 2.3. Structure::addPropertyTransitionToExistingStructure has very cheap fast path and we must inline them to get performance benefit for major single-transition case. Added microbenchmarks show significant performance improvements. And Speedometer2 shows 0.6 - 1.0% improvement. ToT Patched object-assign-transition 105.2539+-0.2970 ^ 88.8046+-0.2029 ^ definitely 1.1852x faster object-assign-replace 116.1568+-0.0905 ^ 75.0673+-0.0658 ^ definitely 1.5474x faster * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/Watchpoint.cpp: (JSC::DeferredWatchpointFire::fireAllSlow): (JSC::DeferredWatchpointFire::DeferredWatchpointFire): Deleted. (JSC::DeferredWatchpointFire::~DeferredWatchpointFire): Deleted. (JSC::DeferredWatchpointFire::fireAll): Deleted. * bytecode/Watchpoint.h: (JSC::DeferredWatchpointFire::DeferredWatchpointFire): (JSC::DeferredWatchpointFire::fireAll): (JSC::FireDetail::FireDetail): Deleted. (JSC::FireDetail::~FireDetail): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGMayExit.cpp: * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileObjectAssign): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileObjectAssign): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/JSObject.cpp: (JSC::JSObject::deleteProperty): * runtime/JSObjectInlines.h: (JSC::JSObject::putDirectInternal): * runtime/ObjectConstructor.cpp: (JSC::objectAssignGeneric): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/ObjectConstructor.h: * runtime/ObjectConstructorInlines.h: Added. (JSC::canPerformFastPropertyEnumerationForObjectAssign): * runtime/Structure.cpp: (JSC::StructureTransitionTable::singleTransition const): Deleted. (JSC::StructureTransitionTable::get const): Deleted. (JSC::Structure::addPropertyTransitionToExistingStructureImpl): Deleted. (JSC::Structure::addPropertyTransitionToExistingStructure): Deleted. (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently): Deleted. * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::didReplaceProperty): (JSC::Structure::propertyReplacementWatchpointSet): (JSC::Structure::addPropertyTransitionToExistingStructureImpl): (JSC::Structure::addPropertyTransitionToExistingStructure): (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently): (JSC::StructureTransitionTable::singleTransition const): (JSC::StructureTransitionTable::get const): 2021-07-06 Yijia Huang Fix instruction check failure of UBFX and SBFIZ in testb3 due to the speculative fix in bug 227554 https://bugs.webkit.org/show_bug.cgi?id=227563 Reviewed by Filip Pizlo. This patch includes two modifications to resolve rdar://79978150: 1. Fix the bug caused by the patch introducing BFI. 2. Discard the corresponding speculative fix in https://bugs.webkit.org/show_bug.cgi?id=227554. The previous patch, added bit field insert (BFI) to AIR opcode, causes the Gmail page hanging issue on Safari. The root cause is the incorrect definition of register role in BFI's AIR opcode. Since BFI inserts a bit field at the low end of the destination register while keeping the high bit unchanged, the destination register should have both roles of use and define simultaneously, which is not (missing use) in the previous patch. This will result in the loss of preserving the value of the destination register, which does happen when browsing the Gmail page on Safari. // B3 IR snippets from Gmail Int32 b@23 = Add(b@104, b@111, D@100) ... Int32 b@55 = Const32(65535, D@50) Int32 b@137 = BitAnd(b@118, $65535(b@55), D@160) Int32 b@168 = Const32(16, D@40) Int32 b@141 = Shl(b@137, $16(b@168), D@163) Int32 b@143 = BitAnd(b@23, $65535(b@55), D@166) Int32 b@144 = BitOr(b@141, b@143, D@169) The pattern of BFI is d = ((n & mask1) << lsb) | (d & mask2). So, it is obvious that BFI can be utilized in b@144 where the d is b@23. // Incorrect AIR opcode of BFI arm64: InsertBitField32 U:G:32, U:G:32, U:G:32, ZD:G:32 Tmp, Imm, Imm, Tmp // Air w/o use role Add32 %x3, %x7, %x7, b@23 ... InsertBitField32 %x3, $16, $16, %x4, b@144 // Generated code w/o use role add w7, w3, w7 ... bfi w4, w3, #16, #16 In Air, the added value is stored in the w7. But the value is not preserved after lowering with BFI. To fix this, the use role should be enabled for the destination register. // Correnct AIR opcode of BFI arm64: InsertBitField32 U:G:32, U:G:32, U:G:32, UZD:G:32 Tmp, Imm, Imm, Tmp // Air w/ use role Add32 %x3, %x7, %x7, b@23 ... Move32 %x7, %x4, b@144 InsertBitField32 %x3, $16, $16, %x4, b@144 // Generated code w/ use role add w7, w3, w7 ... ubfx x4, x7, #0, #32 bfi w4, w3, #16, #16 In addition, BFXIL, which has pattern d = ((n >> lsb) & mask1) | (d & mask2), also needs the similar update. * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3_2.cpp: (testInsertBitField32): (testInsertBitField64): (testExtractInsertBitfieldAtLowEnd32): (testExtractInsertBitfieldAtLowEnd64): * runtime/OptionsList.h: 2021-07-04 Robin Morisset ActiveScratchBufferScope should take the buffer as argument https://bugs.webkit.org/show_bug.cgi?id=227670 rdar://80011612 Reviewed by Mark Lam. https://bugs.webkit.org/show_bug.cgi?id=227013 created ActiveScratchBufferScope. It is used by operations that can cause the GC to run, to mark as roots the contents of the scratch buffer that is live during that time (if any). The bug is that it simply asks the VM for a scratch buffer of the right size, but this will always return the last scratch buffer, and not necessarily the one that the operation is actually using. A fairly simple fix is to pass it directly the scratch buffer, since the operation normally can get it easily enough. In most cases the operation has access to the m_buffer field of the ScratchBuffer, but getting a pointer to the entire structure from that is fairly simple (I added ScratchBuffer::fromData() to do so). * dfg/DFGOSRExit.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * dfg/DFGOSRExit.h: * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewArray): * dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::haveABadTime): * runtime/VM.h: (JSC::ScratchBuffer::fromData): * runtime/VMInlines.h: (JSC::ActiveScratchBufferScope::ActiveScratchBufferScope): (JSC::ActiveScratchBufferScope::~ActiveScratchBufferScope): 2021-07-04 Alexey Shvayka [WebIDL] Simplify generation of runtime conditionally read-write attributes https://bugs.webkit.org/show_bug.cgi?id=227672 Reviewed by Sam Weinig. * runtime/Lookup.h: (JSC::HashTableValue::makeReadOnlyCopy const): 2021-07-03 Alexey Shvayka [WebIDL] Rework runtime enabled properties leveraging PropertyCallback https://bugs.webkit.org/show_bug.cgi?id=227275 Reviewed by Saam Barati. To make the implementation of WebIDL runtime enabled properties independent of eager property reification, this change: 1. Introduces IsLazyPropertyEnabledCallback, which is needed separately from existing value callback to maintain the invariant that reifyStaticProperty() always puts a property, and to keep enumeration fast. Calling disableCaching() isn't enough to achieve correct [[Get]] inline caching, so isTaintedByOpaqueObject() is leveraged to prohibit caching of runtime disabled properties, just like in operationTryGetByIdOptimize(). The only case that might seem weird is runtime disabled properties, which were enabled after all static properties were reified via [[Delete]], are not appearing. It's fixable, yet there is currently no demand for it. 2. Adds support for LazyPropertyCallback returning GetterSetter / CustomGetterSetter, ensuring correct structure flags and slot initialization. Previously, the callback was used to init only objects and constructors, using putDirect() unconditionally. To avoid mixing other non-basic attributes with PropertyCallback, which would require hoisting of checks against PropertyCallback and complicating attribute validation in HashTableValue methods, this patch checks the type of callback's return value instead. In the future, sticking to this approach will make returning CustomValue impossible as it can't be distinguished from CustomAccessor. That's fine because all present CustomValue usages merely do lazy init, which PropertyCallback is better suited for. Also, this patch: 3. Expands setUpStaticFunctionSlot() to handle constant integers so the code using `Node.ELEMENT_NODE` & friends doesn't regress (proven by attached microbenchmark). 4. Removes extra checks from setUpStaticPropertySlot(), which is called only on non-reified properties. 5. Removes invariant that DOMJITAttribute property is read-only, which was broken by `document.body` having a non-JIT custom setter. This aligns non-reified properties with structure ones. * jit/Repatch.cpp: (JSC::tryCacheGetBy): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::setupGetByIdPrototypeCache): * runtime/HasOwnPropertyCache.h: (JSC::HasOwnPropertyCache::tryAdd): * runtime/JSObject.cpp: (JSC::lookupPropertyForPut): (JSC::JSObject::putInlineSlow): (JSC::JSObject::reifyAllStaticProperties): * runtime/JSObject.h: (JSC::JSObject::getOwnNonIndexPropertySlot): (JSC::JSObject::fillStructurePropertySlot): * runtime/JSObjectInlines.h: (JSC::JSObject::getNonReifiedStaticPropertyNames): * runtime/Lookup.cpp: (JSC::setUpStaticPropertySlot): (JSC::setUpStaticFunctionSlot): Deleted. * runtime/Lookup.h: (JSC::HashTableValue::isLazyPropertyEnabled const): (JSC::getStaticPropertySlotFromTable): (JSC::reifyStaticProperty): (JSC::reifyStaticProperties): * tools/JSDollarVM.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::JSDollarVM::finishCreation): 2021-07-02 Keith Miller Add 10 more unified source cpp files for JSC https://bugs.webkit.org/show_bug.cgi?id=227643 Reviewed by Alex Christensen. * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/generate-unified-sources.sh: * UnifiedSources-output.xcfilelist: 2021-07-02 Philippe Normand [GTK] Add new revision variable in pkgconfig file https://bugs.webkit.org/show_bug.cgi?id=227629 Reviewed by Michael Catanzaro. * javascriptcoregtk.pc.in: Include SVN_REVISION as revision variable, useful for apps to know on which upstream SVN revision their WebKitGTK-based app is built on. 2021-07-01 Yijia Huang Remove unnecessary canBeInternal invocations to mitigate the cost of potential unmatched patterns in B3LowerToAir https://bugs.webkit.org/show_bug.cgi?id=227508 Reviewed by Filip Pizlo. The bit pattern doesn't cause worse code generation in the all-internals-are-captured case. So, they don't need canBeInternal checks which might terminate potential matched scenarios. The equivalent pattern of SBFIZ is ((src << amount) >> amount) << lsb. Given the code: a = x << C b = a >> C c = b << D print(a) print(b) print(c) The pattern won't match because of !canBeInternal for a and b (useCounts > 1). So, this would emit three separate instructions. But if we removed canBeInternal, it would still be just three separate instructions, and they wouldn't be any more expensive. Suppose the print(b) is removed, above. Then, with the canBeInternal check, it is emitting three instructions. Without the canBeInternal check, it would emit only two (x << C and SBFIZ to compute c). And that would be less expensive. * b3/B3LowerToAir.cpp: 2021-07-01 Yijia Huang Add a new pattern to instruction selector to use EXTR supported by ARM64 https://bugs.webkit.org/show_bug.cgi?id=227171 Reviewed by Robin Morisset. This patch includes two modifications: 1. Introduce a strength reduction rule to zero extend bitfield. 2. Add Extract Register (EXTR) to Air opcode to serve instruction selector. ------------------------------------------------------- ### Part A zero extend bitfield ### ------------------------------------------------------- A new strength reduction rule is added for the canonical form of the zero-extend bitfield. Turn this: ZShr(Shl(value, amount)), amount) Into this: BitAnd(value, mask) with constraints: 1. 0 <= amount < datasize 2. width = datasize - amount 3. mask is !(mask & (mask + 1)) where bitCount(mask) == width ------------------- ### Part B EXTR ### ------------------- Given instruction: extr Rd, Rn, Rm, lowWidth Extract register (EXTR) extracts a register from a pair of registers, where concat = Rn:Rm and Rd = concat. The equivalent pattern of this instruction is: d = ((n & mask) << highWidth) | (m >> lowWidth) highWidth = datasize - lowWidth mask = (1 << lowWidth) - 1 Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = ArgumentReg(%x1) Int @2 = mask Int @3 = BitAnd(@0, @2) Int @4 = highWidth Int @5 = Shl(@3, @4) Int @6 = lowWidth Int @7 = ZShr(@1, @6) Int @8 = BitOr(@7, @5) Void@9 = Return(@10, Terminal) Before Adding BIC: // Old optimized AIR InsertUnsignedBitfieldInZero %x0, highWidth, lowWidth, %x0, @5 Urshift %x1, lowWidth, %x1, @7 Or %x0, %x1, %x0, @8 Ret %x0, @9 After Adding BIC: // New optimized AIR ExtractRegister %x0, %x1, lowWidth, %x0, @8 Ret %x0, @9 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::extractRegister32): (JSC::MacroAssemblerARM64::extractRegister64): * assembler/testmasm.cpp: (JSC::testExtractRegister32): (JSC::testExtractRegister64): * b3/B3LowerToAir.cpp: * b3/B3ReduceStrength.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testBitfieldZeroExtend32): (testBitfieldZeroExtend64): (testExtractRegister32): (testExtractRegister64): (addBitTests): 2021-06-30 Saam Barati Turn off data ICs by default https://bugs.webkit.org/show_bug.cgi?id=227334 Reviewed by Yusuke Suzuki. There are GC crashes that are caused by access data IC sharing. This patch is both turning off data IC sharing by default, and turning off data ICs by default. We should re-enable this once we figure out the issue: https://bugs.webkit.org/show_bug.cgi?id=227551 Some of our testing modes are still running with data ICs on, so the code doesn't bit rot. And a select few tests are running with data IC sharing on, for similar reasons, even though we know it has issues. If those tests start crashing, we'll just disable sharing completely until the issue is resolved. * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * runtime/OptionsList.h: 2021-06-30 Yusuke Suzuki [JSC] Stop generating default parameter code if class constructor is called without 'new' https://bugs.webkit.org/show_bug.cgi?id=227547 rdar://78821453 Reviewed by Mark Lam. We already do not generate body bytecode when class constructor is called without 'new' because many features including "super()" assume that they generate bytecode only when it is called as a constructor. But we are not doing that for default parameters' bytecode generation. This patch stops generating bytecode for default parameters if class constructor is called without 'new'. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): * runtime/ConstructorKind.h: 2021-06-30 Yusuke Suzuki [JSC] Private names should be handled by usedVariables mechanism https://bugs.webkit.org/show_bug.cgi?id=227476 rdar://76049469 Reviewed by Saam Barati. Private name handling in the current parser has many problems. 1. The parser backtracks when it sees destructuring assignment, arrow function etc. In that case, the discarded code must not have any effect on the outside of that code. However, private name handling is annotating "used" of the upper scopes, which is wrong. 2. In class expression, private name lookup intentionally skips the class-scope when parsing class heritage. But this is not correct since CodeBlock will perform lookup on the normal scope chain and this will look into the class-scope inconsistently. This means that we could encounter different private name at runtime. (it is tested in the added test). 3. We skip inner function parsing when it is parsed previously. At that case, we must preserve private name annotation, but restored function information does not preserve that. This patch changes how private name is handled. 1. We were anyway defining #XXX variables which holds private symbols. So we track "use" information by the mechanism used for usual variables. We remove Used / Declared bits from PrivateNameEntry since they are not necessary at runtime, and these information is handled / tracked in Parser's Scope. For backtracking, we already have a mechanism to roll-back m_usedVariables, so using variable mechanism automatically fixes the problem. 2. We define class-head-scope separately from class-scope. class-heritage expression can see class name, but it cannot use private names. Previously, our implementation attempted to achieve that by hacky way: skipping this class-scope for private names only while parsing class-heritage. But this was wrong since it does not consider CodeBlock's linking phase as described in the problem (2). Instead, we just define class-head-scope which holds class constructor name. 3. We clean up popScopeInternal to populate lexical-variables and function-stack. Previously, we are stealing them before popping the scope when necessary, but this is a hack and a bit wrong since scope's popping operation needs to access these information in some cases. Instead, popScopeInternal populates them after popping the scope. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::pushClassHeadLexicalScope): (JSC::BytecodeGenerator::popClassHeadLexicalScope): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::ClassExprNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createClassExpr): (JSC::ASTBuilder::createBlockStatement): (JSC::ASTBuilder::createForLoop): (JSC::ASTBuilder::createForInLoop): (JSC::ASTBuilder::createForOfLoop): (JSC::ASTBuilder::createTryStatement): (JSC::ASTBuilder::createSwitchStatement): * parser/NodeConstructors.h: (JSC::ForNode::ForNode): (JSC::TryNode::TryNode): (JSC::ClassExprNode::ClassExprNode): (JSC::SwitchNode::SwitchNode): (JSC::BlockNode::BlockNode): (JSC::EnumerationNode::EnumerationNode): (JSC::ForInNode::ForInNode): (JSC::ForOfNode::ForOfNode): * parser/Nodes.cpp: (JSC::ScopeNode::ScopeNode): (JSC::ProgramNode::ProgramNode): (JSC::ModuleProgramNode::ModuleProgramNode): (JSC::EvalNode::EvalNode): (JSC::FunctionNode::FunctionNode): (JSC::VariableEnvironmentNode::VariableEnvironmentNode): * parser/Nodes.h: (JSC::VariableEnvironmentNode::VariableEnvironmentNode): Deleted. * parser/Parser.cpp: (JSC::isPrivateFieldName): (JSC::Parser::parseInner): (JSC::Parser::parseForStatement): (JSC::Parser::parseSwitchStatement): (JSC::Parser::parseTryStatement): (JSC::Parser::parseBlockStatement): (JSC::Parser::parseFunctionDeclarationStatement): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseClass): (JSC::Parser::parseBinaryExpression): (JSC::Parser::parseMemberExpression): (JSC::Parser::usePrivateName): Deleted. * parser/Parser.h: (JSC::Scope::finalizeLexicalEnvironment): (JSC::Scope::takeLexicalEnvironment): (JSC::Scope::takeDeclaredVariables): (JSC::Scope::takeFunctionDeclarations): (JSC::Scope::forEachUsedVariable): (JSC::Scope::usePrivateName): (JSC::Scope::currentUsedVariablesSize): (JSC::Parser::popScopeInternal): (JSC::Parser::popScope): (JSC::Parser::parse): (JSC::Scope::copyUndeclaredPrivateNamesTo): Deleted. (JSC::Scope::hasUsedButUndeclaredPrivateNames const): Deleted. (JSC::Parser::privateNameScope): Deleted. (JSC::Parser::copyUndeclaredPrivateNamesToOuterScope): Deleted. * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createClassExpr): (JSC::SyntaxChecker::createBlockStatement): (JSC::SyntaxChecker::createForLoop): (JSC::SyntaxChecker::createForInLoop): (JSC::SyntaxChecker::createForOfLoop): (JSC::SyntaxChecker::createTryStatement): (JSC::SyntaxChecker::createSwitchStatement): * parser/VariableEnvironment.cpp: (JSC::VariableEnvironmentEntry::dump const): (JSC::VariableEnvironment::declarePrivateField): (JSC::VariableEnvironment::declarePrivateAccessor): (JSC::VariableEnvironment::declarePrivateMethod): (JSC::VariableEnvironment::dump const): * parser/VariableEnvironment.h: (JSC::VariableEnvironment::declarePrivateField): (JSC::VariableEnvironment::privateNameEnvironment): (JSC::VariableEnvironment::addPrivateNamesFrom): (JSC::PrivateNameEntry::isUsed const): Deleted. (JSC::PrivateNameEntry::isDeclared const): Deleted. (JSC::PrivateNameEntry::setIsUsed): Deleted. (JSC::PrivateNameEntry::setIsDeclared): Deleted. (JSC::VariableEnvironment::usePrivateName): Deleted. (JSC::VariableEnvironment::copyPrivateNamesTo const): Deleted. (JSC::VariableEnvironment::copyUndeclaredPrivateNamesTo const): Deleted. 2021-06-30 Mark Lam ARM64: Disable selection of BFI instruction variants by default. https://bugs.webkit.org/show_bug.cgi?id=227554 rdar://79978150 Reviewed by Saam Barati. We suspect that this may have caused some hangs. Disabling while we investigate. * b3/B3LowerToAir.cpp: * b3/testb3_2.cpp: (testInsertBitField32): (testInsertBitField64): * runtime/OptionsList.h: 2021-06-29 Joonghun Park Remove "function declared ‘static’ but never defined" build warnings since r278971. https://bugs.webkit.org/show_bug.cgi?id=227436 This patch removes the build warnings below. warning: ‘bool JSC::cannotBeIdentPartOrEscapeStart(LChar)’ declared ‘static’ but never defined [-Wunused-function] Reviewed by Michael Catanzaro. * runtime/LiteralParser.cpp: Add definitions for cannotBeIdentPartOrEscapeStart. (JSC::cannotBeIdentPartOrEscapeStart): 2021-06-29 Yijia Huang Add a new pattern to instruction selector to use SBX and SBFIZ supported by ARM64 https://bugs.webkit.org/show_bug.cgi?id=227203 Reviewed by Filip Pizlo. This patch includes two modifications: 1. Introduce a strength reduction rule for sign extending bitfield. 2. Add Signed Bitfield Extract (SBFX) and Signed Bitfield Insert in Zero (SBFIZ) to Air opcode to serve instruction selector. ------------------------------------------------------- ### Part A Sign extending from a variable bit-width ### ------------------------------------------------------- According to Bit Twiddling Hacks, there are two ways to sign extend bitfield. (https://graphics.stanford.edu/~seander/bithacks.html#VariableSignExtend) int bf; // sign extend this width-bit number to bfsx int width; // number of bits representing the number in bf int bfsx; // resulting sign-extended number Approach 1 mask1 = (1 << width) - 1 mask2 = 1 << (width - 1) bf = bf & mask1 // zero bits in bf above position width bfsx = (bf ^ mask2) - mask2 Approach 2 amount = CHAR_BIT * sizeof(bf) - width bfsx = (bf << amount) >> amount Then, a new strength reduction rule is introduced: Turn this: ((bf & mask1) ^ mask2) - mask2 Into this: (bf << amount) >> amount ------------------- ### Part B SBFX ### ------------------- Given instruction: sbfx Rd, Rn, lsb, width Signed Bitfield Extract (SBFX) extracts width number of adjacent bits at lsb position from a register Rn, sign-extends them to the size of the register, and writes the result to the destination register Rd. The equivalent patterns of this instruction are: Pattern 1: bf = src >> lsb dst = ((bf & mask1) ^ mask2) - mask2 mask1 = (1 << width) - 1 mask2 = 1 << (width - 1) // (mask2 << 1) - 1 = mask1 Pattern 2: bf = src >> lsb amount = CHAR_BIT * sizeof(bf) - width dst = (bf << amount) >> amount Then, (bf << amount) >> amount is selected as the canonical form with the strength reduction rule introduced above. Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = lsb Int @2 = amount Int @3 = ZShr(@0, @1) Int @4 = Shl(@3, @2) Int @5 = SShr(@4, @2) Void@6 = Return(@5, Terminal) Before Adding BIC: // Old optimized AIR Urshift %x0, lsb, %x0, @3 Lshift %x0, amount, %x0, @4 Rshift %x0, amount, %x0, @5 Ret %x0, @6 After Adding BIC: // New optimized AIR ExtractSignedBitfield %x0, lsb, width, %x0, @5 Ret %x0, @6 -------------------- ### Part B SBFIZ ### -------------------- Given instruction: sbfiz Rd, Rn, lsb, width Signed Bitfield Insert in Zero (SBFIZ) zeroes the destination register Rd and copies width number of contiguous bits from a source register Rn into lsb position in the destination register, sign-extending the most significant bit of the transferred value. The equivalent patterns of this instruction are: Pattern 1: bfsx = ((src & mask1) ^ mask2) - mask2 dst = bfsx << lsb mask1 = (1 << width) - 1 mask2 = 1 << (width - 1) // (mask2 << 1) - 1 = mask1 Pattern 2: amount = CHAR_BIT * sizeof(bf) - width bfsx = (src << amount) >> amount dst = bfsx << lsb Then, ((src << amount) >> amount) << lsb is selected as the canonical form with the strength reduction rule introduced above. Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = lsb Int @2 = amount Int @3 = Shl(@0, @2) Int @4 = SShr(@3, @2) Int @5 = Shl(@4, @1) Void@6 = Return(@5, Terminal) Before Adding BIC: // Old optimized AIR Lshift %x0, amount, %x0, @3 Rshift %x0, amount, %x0, @4 Lshift %x0, lsb, %x0, @5 Ret %x0, @6 After Adding BIC: // New optimized AIR InsertSignedBitfieldInZero %x0, lsb, width, %x0, @5 Ret %x0, @6 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::insertSignedBitfieldInZero32): (JSC::MacroAssemblerARM64::insertSignedBitfieldInZero64): (JSC::MacroAssemblerARM64::extractSignedBitfield32): (JSC::MacroAssemblerARM64::extractSignedBitfield64): * assembler/testmasm.cpp: (JSC::testInsertSignedBitfieldInZero32): (JSC::testInsertSignedBitfieldInZero64): (JSC::testExtractSignedBitfield32): (JSC::testExtractSignedBitfield64): * b3/B3LowerToAir.cpp: * b3/B3ReduceStrength.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (addBitTests): * b3/testb3_3.cpp: (testInsertSignedBitfieldInZero32): (testInsertSignedBitfieldInZero64): (testExtractSignedBitfield32): (testExtractSignedBitfield64): 2021-06-28 Yijia Huang Add a new pattern to instruction selector to use BIC supported by ARM64 https://bugs.webkit.org/show_bug.cgi?id=227202 Reviewed by Filip Pizlo. This patch includes three modifications: 1. Add bit clear (BIC), or not (ORN), and extract and insert bitfield at the lower end (BFXIL) to Air opcode to serve instruction selector. 2. Add bitfield clear (BFC) to MacroAssembler. 4. Do refactoring - rename Air opcodes added in the previous patches. ------------------ ### Part A BIC ### ------------------ Given the operation: bic Rd, Rn, Rm The BIC (Bit Clear) instruction performs an AND operation on the bits in Rn with the complements of the corresponding bits in the value of Rm. The instruction selector can utilize this to lowering certain patterns in B3 IR before further Air optimization. The equivalent patterns of this instruction are: Pattern 1: d = n & (-m - 1) Pattern 2: d = n & (m ^ -1) In order to get benefits for complement operation, the current instruction selector uses mvn instruction to lower the pattern value ^ -1. Then, a new strength reduction rule is introduced: Turn this: -value - 1 Into this: value ^ -1 So, d = n & (m ^ -1) is selected as the canonical form. Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = ArgumentReg(%x1) Int @2 = -1 Int @3 = BitXor(@1, @2) Int @4 = BitAnd(@0, @3) Void@5 = Return(@4, Terminal) Before Adding BIC: // Old optimized AIR Not %x1, %x1, @3 And %x0, %x1, %x0, @4 Ret %x0, @5 After Adding BIC: // New optimized AIR Bic %x0, %x1, %x0, @4 Ret %x0, @5 ------------------ ### Part A ORN ### ------------------ Given the operation: orn Rd, Rn, Rm Bitwise OR NOT (shifted register) performs a bitwise (inclusive) OR of a register value Rn and the complement of an optionally-shifted register value Rm, and writes the result to the destination register Rd. The equivalent patterns of this instruction are: Pattern 1: d = n | (-m - 1) Pattern 2: d = n | (m ^ -1) Then, d = n | (m ^ -1) is selected as the canonical form. Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = ArgumentReg(%x1) Int @2 = -1 Int @3 = BitXor(@1, @2) Int @4 = BitOr(@0, @3) Void@5 = Return(@4, Terminal) Before Adding BIC: // Old optimized AIR Not %x1, %x1, @3 Or %x0, %x1, %x0, @4 Ret %x0, @5 After Adding BIC: // New optimized AIR Orn %x0, %x1, %x0, @4 Ret %x0, @5 -------------------- ### Part A BFXIL ### -------------------- Given the operation: bfxil Rd, Rn, lsb, width Bitfield extract and insert at low end(BFXIL) copies any number of low-order bits from a source register into the same number of adjacent bits at the low end in the destination register, leaving other bits unchanged. The equivalent patterns of this instruction are: Pattern 1: mask1 = (1 << width) - 1 mask2 = ~mask1 ((n >> lsb) & mask1) | (d & mask2) Pattern 2: mask1 = ((1 << width) - 1) << lsb mask2 = ~(mask1 >> lsb) ((n & mask1) >> lsb) | (d & mask2) Then, introduce a strength reduction rule for easier recognization. Turn this: (v & maskShift) >> shiftAmount Into this: (v >> shiftAmount) & mask with constraints: 1. maskShift = mask << lsb 2. mask = (1 << width) - 1 3. 0 <= shiftAmount < datasize 4. 0 < width < datasize 5. shiftAmount + width <= datasize The canonical form to match BFXIL is d = ((n >> lsb) & mask1) | (d & mask2). Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = ArgumentReg(%x1) Int @2 = lsb Int @3 = mask1 Int @4 = mask2 Int @5 = BitAnd(@1, @3) Int @6 = BitAnd(@0, @4)) Int @7 = ZShr(@5, @2) Int @8 = BitOr(@7, @6) Void@9 = Return(@8, Terminal) Before Adding BIC: // Old optimized AIR And mask2, %x0, %x0, @6 ExtractUnsignedBitfield %x1, lsb, width, %x1, @7 Or %x0, %x1, %x0, @8 Ret %x0, @9 After Adding BIC: // New optimized AIR ExtractInsertBitfieldAtLowEnd %x1, lsb, width, %x0, @8 Ret64 %x0, @9 -------------- ### Part B ### -------------- The Bitfield Clear (BFC), leaving other bits unchanged, is similar to BFI which is an alias of BFM. Given the operation: bfc Rd, lsb, width The equivalent pattern of this instruction is: mask = ((1 << width) - 1) << lsb d = d & ~mask Since mask is a constant and B3 performs constant fold in the optimization phase, this pattern will directly lower to the BitAnd binary operation. So, no need to match this pattern. -------------- ### Part C ### -------------- At MacroAssembler level, the emitters are exepected to be expressed in english (e.g. something like clearBitField for BFC). Do refactoring to rename Air opcode for UBFX, UBFIZ, BFI, and BIC. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::bfc): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::extractUnsignedBitfield32): (JSC::MacroAssemblerARM64::extractUnsignedBitfield64): (JSC::MacroAssemblerARM64::insertUnsignedBitfieldInZero32): (JSC::MacroAssemblerARM64::insertUnsignedBitfieldInZero64): (JSC::MacroAssemblerARM64::insertBitField32): (JSC::MacroAssemblerARM64::insertBitField64): (JSC::MacroAssemblerARM64::clearBitField32): (JSC::MacroAssemblerARM64::clearBitField64): (JSC::MacroAssemblerARM64::clearBitsWithMask32): (JSC::MacroAssemblerARM64::clearBitsWithMask64): (JSC::MacroAssemblerARM64::orNot32): (JSC::MacroAssemblerARM64::orNot64): (JSC::MacroAssemblerARM64::ubfx32): Deleted. (JSC::MacroAssemblerARM64::ubfx64): Deleted. (JSC::MacroAssemblerARM64::ubfiz32): Deleted. (JSC::MacroAssemblerARM64::ubfiz64): Deleted. (JSC::MacroAssemblerARM64::bitFieldInsert32): Deleted. (JSC::MacroAssemblerARM64::bitFieldInsert64): Deleted. * assembler/testmasm.cpp: (JSC::testMultiplySignExtend32): (JSC::testMultiplySubSignExtend32): (JSC::testExtractUnsignedBitfield32): (JSC::testExtractUnsignedBitfield64): (JSC::testInsertUnsignedBitfieldInZero32): (JSC::testInsertUnsignedBitfieldInZero64): (JSC::testInsertBitField32): (JSC::testInsertBitField64): (JSC::testClearBitField32): (JSC::testClearBitField64): (JSC::testClearBitsWithMask32): (JSC::testClearBitsWithMask64): (JSC::testOrNot32): (JSC::testOrNot64): (JSC::testMul32SignExtend): Deleted. (JSC::testMulSubSignExtend32): Deleted. (JSC::testUbfx32): Deleted. (JSC::testUbfx64): Deleted. (JSC::testUbfiz32): Deleted. (JSC::testUbfiz64): Deleted. (JSC::testBitFieldInsert32): Deleted. (JSC::testBitFieldInsert64): Deleted. * b3/B3LowerToAir.cpp: * b3/B3ReduceStrength.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testInsertBitField32): (testInsertBitField64): (testBIC32): (testBIC64): (testOrNot32): (testOrNot64): (addBitTests): (testBitFieldInsert32): Deleted. (testBitFieldInsert64): Deleted. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::cageWithoutUntagging): (JSC::AssemblyHelpers::cageConditionallyAndUntag): 2021-06-28 Mikhail R. Gadelha Add LLInt fast path for less, lesseq, greater and greatereq https://bugs.webkit.org/show_bug.cgi?id=226266 Reviewed by Tadeu Zagallo. The motivation is to add fast path for integers and doubles in LLInt, so we don't need to go to slow path for those cases. This patch implements the less, lesseq, greater, greatereq instruction for ARMv7, MIPS and CLoop. Microbenchmarking results: * x86_64: number-comparison-inline definitely 1.3520x faster * ARMv7: number-comparison-inline definitely 1.3520x faster JetStream2 results: * x86_64 jit: 1.015 times better * x86_64 no-jit: 1.018 times better * ARMv7 no-jit: 1.004 times worse * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm.rb: * offlineasm/cloop.rb: * offlineasm/mips.rb: 2021-06-28 Mikhail R. Gadelha Prevent sign-extended casts for 32 bits arch https://bugs.webkit.org/show_bug.cgi?id=227170 Reviewed by Yusuke Suzuki. In a number of places, addresses are reinterpreted as uint64, which can lead to wrong addresses in 32 bits arch. * assembler/testmasm.cpp: (JSC::testBranchTruncateDoubleToInt32): * disassembler/ARM64/A64DOpcode.h: (JSC::ARM64Disassembler::A64DOpcode::appendPCRelativeOffset): * runtime/JSCell.cpp: (JSC::reportZappedCellAndCrash): * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::emitEntryTierUpCheck): (JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::emitEntryTierUpCheck): (JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck): 2021-06-25 Commit Queue Unreviewed, reverting r279266. https://bugs.webkit.org/show_bug.cgi?id=227402 Causes crash loop Reverted changeset: "Remove references to order files" https://bugs.webkit.org/show_bug.cgi?id=227377 https://trac.webkit.org/changeset/279266 2021-06-24 Sihui Liu Remove references to order files https://bugs.webkit.org/show_bug.cgi?id=227377 rdar://76070556 Reviewed by Mark Lam. * Configurations/JavaScriptCore.xcconfig: 2021-06-24 Asumu Takikawa [WASM-Function-References] Add support for (ref null? $t) type constructor https://bugs.webkit.org/show_bug.cgi?id=226296 Reviewed by Yusuke Suzuki. Adds the `ref` type constructor from the typed function references proposal: https://github.com/WebAssembly/function-references/blob/master/proposals/function-references/Overview.md It's also required for the type imports and GC proposals as well. Ref types represent references to any heap type (including existing funcref and externref) with a specified nullability. This requires a new isNullable flag in the type representation. This flag also enables non-null externref and funcrefs, and hence this commit also adds the necessary checks at Wasm/JS boundaries. Non-null reference types also generally cannot be used as function locals. * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::gTypeIdx): (JSC::Wasm::AirIRGenerator::tmpForType): (JSC::Wasm::AirIRGenerator::emitCCall): (JSC::Wasm::AirIRGenerator::moveOpForValueType): (JSC::Wasm::AirIRGenerator::AirIRGenerator): (JSC::Wasm::AirIRGenerator::addLocal): (JSC::Wasm::AirIRGenerator::addConstant): (JSC::Wasm::AirIRGenerator::addRefFunc): * wasm/WasmCallingConvention.h: (JSC::Wasm::WasmCallingConvention::marshallLocation const): (JSC::Wasm::JSCallingConvention::marshallLocation const): * wasm/WasmFormat.h: (JSC::Wasm::isSubtype): (JSC::Wasm::isValidHeapTypeKind): (JSC::Wasm::isDefaultableType): * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::parse): (JSC::Wasm::FunctionParser::parseAnnotatedSelectImmediates): (JSC::Wasm::FunctionParser::checkBranchTarget): (JSC::Wasm::FunctionParser::parseExpression): * wasm/WasmGlobal.cpp: (JSC::Wasm::Global::get const): (JSC::Wasm::Global::set): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::callInformationForCaller): (JSC::Wasm::LLIntGenerator::callInformationForCallee): (JSC::Wasm::LLIntGenerator::addArguments): * wasm/WasmParser.h: (JSC::Wasm::Parser::parseBlockSignature): (JSC::Wasm::Parser::parseValueType): (JSC::Wasm::Parser::parseRefType): * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseType): (JSC::Wasm::SectionParser::parseElement): (JSC::Wasm::SectionParser::parseInitExpr): (JSC::Wasm::SectionParser::parseElementSegmentVectorOfExpressions): (JSC::Wasm::SectionParser::parseGlobalType): * wasm/WasmSignature.cpp: (JSC::Wasm::computeHash): * wasm/generateWasmOpsHeader.py: * wasm/js/WasmToJS.cpp: (JSC::Wasm::wasmToJS): * wasm/js/WebAssemblyFunction.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::WebAssemblyFunction::jsCallEntrypointSlow): * wasm/js/WebAssemblyFunctionBase.h: (JSC::WebAssemblyFunctionBase::offsetOfSignatureIndex): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::linkImpl): * wasm/wasm.json: 2021-06-24 Mark Lam Use ldp and stp more for saving / restoring registers on ARM64. https://bugs.webkit.org/show_bug.cgi?id=227039 rdar://79354736 Reviewed by Saam Barati. This patch introduces a spooler abstraction in AssemblyHelpers. The spooler basically batches up load / store operations and emit them as pair instructions if appropriate. There are 4 spooler classes: a. Spooler - template base class for LoadRegSpooler and StoreRegSpooler. - encapsulates the batching strategy for load / store pairs. b. LoadRegSpooler - specializes Spooler to handle load pairs. b. StoreRegSpooler - specializes Spooler to handle store pairs. d. CopySpooler - handles matching loads with stores. - tries to emit loads as load pairs if possible. - tries to emot stores as store pairs if possible. - ensures that pre-requisite loads are emitted before stores are emitted. - other than loads, also support constants and registers as sources of values to be stored. This is useful in OSR exit ramps where we may materialize a stack value to store from constants or registers in addition to values we load from the old stack frame or from a scratch buffer. In this patch, we also do the following: 1. Use spoolers in many places so that we can emit load / store pairs instead of single load / stores. This helps shrink JIT code side, and also potentially improves performance. 2. In DFG::OSRExit::compileExit(), we used to recover constants into a scratch buffer, and then later, load from that scratch buffer to store into the new stack frame(s). This patch changes it so that we defer constant recovery until the final loop where we store the recovered value directly into the new stack frame(s). This saves us the work (and JIT code space) for storing into a scratch buffer and then reloading from the scratch buffer. There is one exception: tmp values used by active checkpoints. We need to call operationMaterializeOSRExitSideState() to materialize the active checkpoint side state before the final loop where we now recover constants. Hence, we need these tmp values recovered before hand. So, we check upfront if we have active checkpoint side state to materialize. If so, we'll eagerly recover the constants for initializing those tmps. We also use the CopySpooler in the final loop to emit load / store pairs for filling in the new stack frame(s). One more thing: it turns out that the vast majority of constants to be recovered is simply the undefined value. So, as an optimization, the final loop keeps the undefined value in a register, and has the spooler store directly from that register when appropriate. This saves on JIT code to repeatedly materialize the undefined JSValue constant. 3. In reifyInlinedCallFrames(), replace the use of GPRInfo::nonArgGPR0 with GPRInfo::regT4. nonArgGPRs are sometimes map to certain regTXs on certain ports. Replacing with regT4 makes it easier to ensure that we're not trashing the register when we use more temp registers. reifyInlinedCallFrames() will be using emitSaveOrCopyLLIntBaselineCalleeSavesFor() later where we need more temp registers. 4. Move the following functions to AssemblyHelpers.cpp. They don't need to be inline functions. Speedometer2 and JetStream2 shows that making these non inline does not hurt performance: AssemblyHelpers::emitSave(const RegisterAtOffsetList&); AssemblyHelpers::emitRestore(const RegisterAtOffsetList&); AssemblyHelpers::emitSaveCalleeSavesFor(const RegisterAtOffsetList*); AssemblyHelpers::emitSaveOrCopyCalleeSavesFor(...); AssemblyHelpers::emitRestoreCalleeSavesFor(const RegisterAtOffsetList*); AssemblyHelpers::copyLLIntBaselineCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer(...); Also renamed emitSaveOrCopyCalleeSavesFor() to emitSaveOrCopyLLIntBaselineCalleeSavesFor() because it is only used with baseline codeBlocks. Results: Cummulative LinkBuffer profile sizes shrunk by ~2M in aggregate: base new ==== === BaselineJIT: 83827048 (79.943703 MB) => 83718736 (79.840408 MB) DFG: 56594836 (53.973042 MB) => 56603508 (53.981312 MB) InlineCache: 33923900 (32.352352 MB) => 33183156 (31.645924 MB) FTL: 6770956 (6.457287 MB) => 6568964 (6.264652 MB) DFGOSRExit: 5212096 (4.970642 MB) => 3728088 (3.555382 MB) CSSJIT: 748428 (730.886719 KB) => 748428 (730.886719 KB) FTLOSRExit: 692276 (676.050781 KB) => 656884 (641.488281 KB) YarrJIT: 445280 (434.843750 KB) => 512988 (500.964844 KB) FTLThunk: 22908 (22.371094 KB) => 22556 (22.027344 KB) BoundFunctionThunk: 8400 (8.203125 KB) => 10088 (9.851562 KB) ExtraCTIThunk: 6952 (6.789062 KB) => 6824 (6.664062 KB) SpecializedThunk: 4508 (4.402344 KB) => 4508 (4.402344 KB) Thunk: 3912 (3.820312 KB) => 3784 (3.695312 KB) LLIntThunk: 2908 (2.839844 KB) => 2908 (2.839844 KB) VirtualThunk: 1248 (1.218750 KB) => 1248 (1.218750 KB) DFGThunk: 1084 (1.058594 KB) => 444 DFGOSREntry: 216 => 184 JumpIsland: 0 WasmThunk: 0 Wasm: 0 Uncategorized: 0 Total: 188266956 (179.545361 MB) => 185773296 (177.167221 MB) Speedometer2 and JetStream2 results shows that performance is neutral for this patch (as measured on an M1 Mac): Speedometer2: ---------------------------------------------------------------------------------------------------------------------------------- | subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) | ---------------------------------------------------------------------------------------------------------------------------------- | Elm-TodoMVC |129.037500 |127.212500 |0.985857 | 0.012706 | | VueJS-TodoMVC |28.312500 |27.525000 |0.972185 | 0.240315 | | EmberJS-TodoMVC |132.550000 |132.025000 |0.996039 | 0.538034 | | Flight-TodoMVC |80.762500 |80.875000 |1.001393 | 0.914749 | | BackboneJS-TodoMVC |51.637500 |51.175000 |0.991043 | 0.285427 | | Preact-TodoMVC |21.025000 |22.075000 |1.049941 | 0.206140 | | AngularJS-TodoMVC |142.900000 |142.887500 |0.999913 | 0.990681 | | Inferno-TodoMVC |69.300000 |69.775000 |1.006854 | 0.505201 | | Vanilla-ES2015-TodoMVC |71.500000 |71.225000 |0.996154 | 0.608650 | | Angular2-TypeScript-TodoMVC |43.287500 |43.275000 |0.999711 | 0.987926 | | VanillaJS-TodoMVC |57.212500 |57.812500 |1.010487 | 0.333357 | | jQuery-TodoMVC |276.150000 |276.775000 |1.002263 | 0.614404 | | EmberJS-Debug-TodoMVC |353.612500 |352.762500 |0.997596 | 0.518836 | | React-TodoMVC |93.637500 |92.637500 |0.989321 | 0.036277 | | React-Redux-TodoMVC |158.237500 |156.587500 |0.989573 | 0.042154 | | Vanilla-ES2015-Babel-Webpack-TodoMVC |68.050000 |68.087500 |1.000551 | 0.897149 | ---------------------------------------------------------------------------------------------------------------------------------- a mean = 236.26950 b mean = 236.57964 pValue = 0.7830785938 (Bigger means are better.) 1.001 times better Results ARE NOT significant JetStream2: ------------------------------------------------------------------------------------------------------------------------- | subtest | pts | pts | b / a | pValue (significance using False Discovery Rate) | ------------------------------------------------------------------------------------------------------------------------- | gaussian-blur |542.570057 |542.671885 |1.000188 | 0.982573 | | HashSet-wasm |57.710498 |64.406371 |1.116025 | 0.401424 | | gcc-loops-wasm |44.516009 |44.453535 |0.998597 | 0.973651 | | json-parse-inspector |241.275085 |240.720491 |0.997701 | 0.704732 | | prepack-wtb |62.640114 |63.754878 |1.017796 | 0.205840 | | date-format-xparb-SP |416.976817 |448.921409 |1.076610 | 0.052977 | | WSL |1.555257 |1.570233 |1.009629 | 0.427924 | | OfflineAssembler |177.052352 |179.746511 |1.015217 | 0.112114 | | cdjs |192.517586 |194.598906 |1.010811 | 0.025807 | | UniPoker |514.023694 |526.111500 |1.023516 | 0.269892 | | json-stringify-inspector |227.584725 |223.619390 |0.982576 | 0.102714 | | crypto-sha1-SP |980.728788 |984.192104 |1.003531 | 0.838618 | | Basic |685.148483 |711.590247 |1.038593 | 0.142952 | | chai-wtb |106.256376 |106.590318 |1.003143 | 0.865894 | | crypto-aes-SP |722.308829 |728.702310 |1.008851 | 0.486766 | | Babylon |655.857561 |654.204901 |0.997480 | 0.931520 | | string-unpack-code-SP |407.837271 |405.710752 |0.994786 | 0.729122 | | stanford-crypto-aes |456.906021 |449.993856 |0.984872 | 0.272994 | | raytrace |883.911335 |902.887238 |1.021468 | 0.189785 | | multi-inspector-code-load |409.997347 |405.643639 |0.989381 | 0.644447 | | hash-map |593.590160 |601.576332 |1.013454 | 0.249414 | | stanford-crypto-pbkdf2 |722.178638 |728.283532 |1.008453 | 0.661195 | | coffeescript-wtb |42.393544 |41.869545 |0.987640 | 0.197441 | | Box2D |452.034685 |454.104868 |1.004580 | 0.535342 | | richards-wasm |140.873688 |148.394050 |1.053384 | 0.303651 | | lebab-wtb |61.671318 |62.119403 |1.007266 | 0.620998 | | tsf-wasm |108.592794 |119.498398 |1.100427 | 0.504710 | | base64-SP |629.744643 |603.425565 |0.958207 | 0.049997 | | navier-stokes |740.588523 |739.951662 |0.999140 | 0.871445 | | jshint-wtb |51.938359 |52.651104 |1.013723 | 0.217137 | | regex-dna-SP |459.251148 |463.492489 |1.009235 | 0.371891 | | async-fs |235.853820 |236.031189 |1.000752 | 0.938459 | | first-inspector-code-load |275.298325 |274.172125 |0.995909 | 0.623403 | | segmentation |44.002842 |43.445960 |0.987344 | 0.207134 | | typescript |26.360161 |26.458820 |1.003743 | 0.609942 | | octane-code-load |1126.749036 |1087.132024 |0.964840 | 0.524171 | | float-mm.c |16.691935 |16.721354 |1.001762 | 0.194425 | | quicksort-wasm |461.630091 |450.161127 |0.975156 | 0.371394 | | Air |392.442375 |412.201810 |1.050350 | 0.046887 | | splay |510.111886 |475.131657 |0.931426 | 0.024732 | | ai-astar |607.966974 |626.573181 |1.030604 | 0.468711 | | acorn-wtb |67.510766 |68.143956 |1.009379 | 0.481663 | | gbemu |144.133842 |145.620304 |1.010313 | 0.802154 | | richards |963.475078 |946.658879 |0.982546 | 0.231189 | | 3d-cube-SP |549.426784 |550.479154 |1.001915 | 0.831307 | | espree-wtb |68.707483 |73.762202 |1.073569 | 0.033603 | | bomb-workers |96.882596 |96.116121 |0.992089 | 0.687952 | | tagcloud-SP |309.888767 |303.538511 |0.979508 | 0.187768 | | mandreel |133.667031 |135.009929 |1.010047 | 0.075232 | | 3d-raytrace-SP |491.967649 |492.528992 |1.001141 | 0.957842 | | delta-blue |1066.718312 |1080.230772 |1.012667 | 0.549382 | | ML |139.617293 |140.088630 |1.003376 | 0.661651 | | regexp |351.773956 |351.075935 |0.998016 | 0.769250 | | crypto |1510.474663 |1519.218842 |1.005789 | 0.638420 | | crypto-md5-SP |795.447899 |774.082493 |0.973140 | 0.079728 | | earley-boyer |812.574545 |870.678372 |1.071506 | 0.044081 | | octane-zlib |25.162470 |25.660261 |1.019783 | 0.554591 | | date-format-tofte-SP |395.296135 |398.008992 |1.006863 | 0.650475 | | n-body-SP |1165.386611 |1150.525110 |0.987248 | 0.227908 | | pdfjs |189.060252 |191.015628 |1.010343 | 0.633777 | | FlightPlanner |908.426192 |903.636642 |0.994728 | 0.838821 | | uglify-js-wtb |34.029399 |34.164342 |1.003965 | 0.655652 | | babylon-wtb |81.329869 |80.855680 |0.994170 | 0.854393 | | stanford-crypto-sha256 |826.850533 |838.494164 |1.014082 | 0.579636 | ------------------------------------------------------------------------------------------------------------------------- a mean = 237.91084 b mean = 239.92670 pValue = 0.0657710897 (Bigger means are better.) 1.008 times better Results ARE NOT significant * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssembler.h: (JSC::MacroAssembler::pushToSaveByteOffset): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::pushToSaveByteOffset): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): * dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator): * ftl/FTLSaveRestore.cpp: (JSC::FTL::saveAllRegisters): (JSC::FTL::restoreAllRegisters): * ftl/FTLSaveRestore.h: * ftl/FTLThunks.cpp: (JSC::FTL::genericGenerationThunkGenerator): (JSC::FTL::slowPathCallThunkGenerator): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl): (JSC::AssemblyHelpers::emitSave): (JSC::AssemblyHelpers::emitRestore): (JSC::AssemblyHelpers::emitSaveCalleeSavesFor): (JSC::AssemblyHelpers::emitRestoreCalleeSavesFor): (JSC::AssemblyHelpers::copyLLIntBaselineCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::emitSaveOrCopyLLIntBaselineCalleeSavesFor): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::copyLLIntBaselineCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::emitSave): Deleted. (JSC::AssemblyHelpers::emitRestore): Deleted. (JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor): Deleted. * jit/AssemblyHelpersSpoolers.h: Added. (JSC::AssemblyHelpers::Spooler::Spooler): (JSC::AssemblyHelpers::Spooler::handleGPR): (JSC::AssemblyHelpers::Spooler::finalizeGPR): (JSC::AssemblyHelpers::Spooler::handleFPR): (JSC::AssemblyHelpers::Spooler::finalizeFPR): (JSC::AssemblyHelpers::Spooler::op): (JSC::AssemblyHelpers::LoadRegSpooler::LoadRegSpooler): (JSC::AssemblyHelpers::LoadRegSpooler::loadGPR): (JSC::AssemblyHelpers::LoadRegSpooler::finalizeGPR): (JSC::AssemblyHelpers::LoadRegSpooler::loadFPR): (JSC::AssemblyHelpers::LoadRegSpooler::finalizeFPR): (JSC::AssemblyHelpers::LoadRegSpooler::handlePair): (JSC::AssemblyHelpers::LoadRegSpooler::handleSingle): (JSC::AssemblyHelpers::StoreRegSpooler::StoreRegSpooler): (JSC::AssemblyHelpers::StoreRegSpooler::storeGPR): (JSC::AssemblyHelpers::StoreRegSpooler::finalizeGPR): (JSC::AssemblyHelpers::StoreRegSpooler::storeFPR): (JSC::AssemblyHelpers::StoreRegSpooler::finalizeFPR): (JSC::AssemblyHelpers::StoreRegSpooler::handlePair): (JSC::AssemblyHelpers::StoreRegSpooler::handleSingle): (JSC::RegDispatch::get): (JSC::RegDispatch::temp1): (JSC::RegDispatch::temp2): (JSC::RegDispatch::regToStore): (JSC::RegDispatch::invalid): (JSC::RegDispatch::regSize): (JSC::RegDispatch::isValidLoadPairImm): (JSC::RegDispatch::isValidStorePairImm): (JSC::RegDispatch::get): (JSC::RegDispatch::temp1): (JSC::RegDispatch::temp2): (JSC::RegDispatch::regToStore): (JSC::RegDispatch::invalid): (JSC::RegDispatch::regSize): (JSC::RegDispatch::isValidLoadPairImm): (JSC::RegDispatch::isValidStorePairImm): (JSC::AssemblyHelpers::CopySpooler::Source::getReg): (JSC::AssemblyHelpers::CopySpooler::CopySpooler): (JSC::AssemblyHelpers::CopySpooler::temp1 const): (JSC::AssemblyHelpers::CopySpooler::temp2 const): (JSC::AssemblyHelpers::CopySpooler::regToStore): (JSC::AssemblyHelpers::CopySpooler::invalid): (JSC::AssemblyHelpers::CopySpooler::regSize): (JSC::AssemblyHelpers::CopySpooler::isValidLoadPairImm): (JSC::AssemblyHelpers::CopySpooler::isValidStorePairImm): (JSC::AssemblyHelpers::CopySpooler::load): (JSC::AssemblyHelpers::CopySpooler::move): (JSC::AssemblyHelpers::CopySpooler::copy): (JSC::AssemblyHelpers::CopySpooler::store): (JSC::AssemblyHelpers::CopySpooler::flush): (JSC::AssemblyHelpers::CopySpooler::loadGPR): (JSC::AssemblyHelpers::CopySpooler::copyGPR): (JSC::AssemblyHelpers::CopySpooler::moveConstant): (JSC::AssemblyHelpers::CopySpooler::storeGPR): (JSC::AssemblyHelpers::CopySpooler::finalizeGPR): (JSC::AssemblyHelpers::CopySpooler::loadFPR): (JSC::AssemblyHelpers::CopySpooler::copyFPR): (JSC::AssemblyHelpers::CopySpooler::storeFPR): (JSC::AssemblyHelpers::CopySpooler::finalizeFPR): (JSC::AssemblyHelpers::CopySpooler::loadPair): (JSC::AssemblyHelpers::CopySpooler::storePair): * jit/ScratchRegisterAllocator.cpp: (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing): (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping): (JSC::ScratchRegisterAllocator::preserveRegistersToStackForCall): (JSC::ScratchRegisterAllocator::restoreRegistersFromStackForCall): * jit/ScratchRegisterAllocator.h: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::addReturn): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addReturn): 2021-06-24 Yusuke Suzuki Unreviewed, build fix for ARM64 https://bugs.webkit.org/show_bug.cgi?id=227201 * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::cageWithoutUntagging): (JSC::AssemblyHelpers::cageConditionallyAndUntag): 2021-06-24 Yijia Huang Add a new pattern to instruction selector to utilize BFI supported by ARM64 https://bugs.webkit.org/show_bug.cgi?id=227201 Reviewed by Filip Pizlo. Bitfield insert(BFI), leaving other bits unchanged. The instruction selector can utilize this to lowering certain patterns in B3 IR before further Air optimization. Given the operation: bfi d, n, lsb, width The equivalent pattern would be: Pattern 1: mask1 = ((1 << width) - 1) << lsb mask2 = ~mask1 d = ((n << lsb) & mask1) | (d & mask2); Pattern 2: mask1 = (1 << width) - 1 mask2 = ~(mask1 << lsb) d = ((n & mask1) << lsb) | (d & mask2) Current optimizer already has the strength reduction rule: Turn This: (n << lsb) & mask1) Into This: (n & mask1) << lsb) Then, d = ((n & mask1) << lsb) | (d & mask2) is the canonical form. With constraints: 1. 0 <= lsb < datasize 2. 0 < width < datasize 3. lsb + width <= dataszie Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = ArgumentReg(%x1) Int @2 = lsb Int @3 = mask Int @4 = BitAnd(@1, @3) Int @5 = Shl(@4, @2) Int @6 = BitOr(@0, @5) Int @7 = Return(@6, Terminal) Before Adding BFI: // Old optimized AIR And mask, %x1, %x1, @4 Lshift %x1, lsb, %x1, @5 Or %x1, %x0, %x0, @6 Ret %x0, @7 After Adding BFI: // New optimized AIR BitFieldInsert %x1, lsb, width, %x0, @6 Ret %x0, @7 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::bitFieldInsert32): (JSC::MacroAssemblerARM64::bitFieldInsert64): * assembler/testmasm.cpp: (JSC::testUbfx32): (JSC::testUbfx64): (JSC::testUbfiz32): (JSC::testUbfiz64): (JSC::testBitFieldInsert32): (JSC::testBitFieldInsert64): * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testBitFieldInsert32): (testBitFieldInsert64): (addBitTests): 2021-06-24 Xan López [JSC] Implement returnEarlyFromInfiniteLoopsForFuzzing for 32bits https://bugs.webkit.org/show_bug.cgi?id=227290 Reviewed by Mark Lam. Mostly a matter of changing the counter type to uintptr_t and making the baseline/dfg/ftl code generation work on both 32 and 64bits, most of it can be shared with minor tweaks. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileLoopHint): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_loop_hint): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter32_64.asm: * runtime/VM.cpp: (JSC::VM::addLoopHintExecutionCounter): (JSC::VM::getLoopHintExecutionCounter): * runtime/VM.h: 2021-06-23 Mark Lam Base Options::useWebAssemblyFastMemory's default value on Gigacage::hasCapacityToUseLargeGigacage. https://bugs.webkit.org/show_bug.cgi?id=227328 Reviewed by Saam Barati. Gigacage::hasCapacityToUseLargeGigacage is determined based on EFFECTIVE_ADDRESS_WIDTH. If we have enough address range to potentially use a large gigacage, then we have enough address range to useWebAssemblyFastMemory. * runtime/Options.cpp: (JSC::canUseWebAssemblyFastMemory): * runtime/OptionsList.h: 2021-06-23 Yijia Huang Add a new pattern to instruction selector to utilize UBFIZ supported by ARM64 https://bugs.webkit.org/show_bug.cgi?id=227204 Reviewed by Filip Pizlo. This patch includes three parts: A) Add UBFIZ to instruction selector. B) Fix UBFX, introduced in https://bugs.webkit.org/show_bug.cgi?id=226984, to match all patterns. C) Fix error condition in one strength reduction rule introduced in https://bugs.webkit.org/show_bug.cgi?id=227138. Part A Unsigned Bitfield Insert in Zero(UBFIZ), supported by ARM64, zeros the destination register and copies any number of contiguous bits from a source register into any position in the destination register. The instruction selector can utilize this to lowering certain patterns in B3 IR before further Air optimization. Given the operation: ubfiz d, n, lsb, width This is equivalent to "d = (n << lsb) & (((1 << width) - 1) << lsb)". Since wasm introduces constant folding, then the matched patterns would be: 1.1 d = (n << lsb) & maskShift 1.2 d = maskShift & (n << lsb) 2.1 d = (n & mask) << lsb 2.2 d = (mask & n) << lsb Where: maskShift = mask << lsb mask = (1 << width) - 1 To make the pattern matching in instruction selection beneficial to JIT, these constraints should be introduced: 1. 0 <= lsb < datasize 2. 0 < width < datasize 3. lsb + width <= datasize Choose (n & mask) << lsb as the canonical form and introduce a strength reduction. Turn this: (n << lsb) & maskShift Into this: (n & mask) << lsb Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = lsb Int @2 = 0b0110 Int @3 = Shl(@0, @1) Int @4 = BitAnd(@3, @2) Void@5 = Return(@4, Terminal) Before Adding UBFIZ Pattern: // Old optimized AIR Lshift %x0, $62, %x0, @3 And 0b0110, %x0, %x0, @4 Ret %x0, @5 After Adding UBFIZ Pattern: // New optimized AIR Ubfiz %x0, lsb, 2, %x0, @4 Ret %x0, @5 Part B Fix UBFX to match both patterns: dest = (src >> lsb) & mask dest = mask & (src >> lsb) Where: 1. mask = (1 << width) - 1 2. 0 <= lsb < datasize 3. 0 < width < datasize 4. lsb + width <= datasize Part C Fix one B3 strength reduction. Turn this: (src >> shiftAmount) & mask Into this: src >> shiftAmount With updated constraints: 1. mask = (1 << width) - 1 2. 0 <= shiftAmount < datasize 3. 0 < width < datasize 4. shiftAmount + width >= datasize * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::ubfiz32): (JSC::MacroAssemblerARM64::ubfiz64): * assembler/testmasm.cpp: (JSC::testUbfiz32): (JSC::testUbfiz64): * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testUbfx32ArgLeft): (testUbfx32ArgRight): (testUbfx64ArgLeft): (testUbfx64ArgRight): (testUbfiz32ArgLeft): (testUbfiz32ArgRight): (testUbfiz64ArgLeft): (testUbfiz64ArgRight): (addBitTests): (testUbfx32): Deleted. (testUbfx32PatternMatch): Deleted. (testUbfx64): Deleted. (testUbfx64PatternMatch): Deleted. 2021-06-23 Keith Miller add/removeManagedReference:withOwner: should have autoreleasepools https://bugs.webkit.org/show_bug.cgi?id=227308 Reviewed by Darin Adler. Since these APIs create autoreleased objects as an implementation detail but don't return any to the caller there's no indication such autoreleased objects could be accumulating. Additionally, it's entirely reasonable to call these methods in a loop an a large set of objects, which further exacerbates the problem. * API/JSVirtualMachine.mm: (-[JSVirtualMachine addManagedReference:withOwner:]): (-[JSVirtualMachine removeManagedReference:withOwner:]): 2021-06-23 Saam Barati Run lazy properties initializers under a DeferTerminationForAWhile scope https://bugs.webkit.org/show_bug.cgi?id=227271 Reviewed by Mark Lam. We don't expect that exceptions can be thrown when initializing a lazy property. Termination exceptions were preventing this from being true. The latest example found is inside JSModuleLoader when it asserts that no exception is thrown when creating its JSMap field. This patch makes it so termination exceptions can't be thrown when running lazy property initializers. * runtime/LazyPropertyInlines.h: (JSC::ElementType>::initLater): (JSC::ElementType>::callFunc): 2021-06-22 Yijia Huang Add a new pattern to instruction selector to utilize SMADDL supported by ARM64 https://bugs.webkit.org/show_bug.cgi?id=227188 Reviewed by Saam Barati. Signed Multiply-Add Long(SMADDL), supported by ARM64, multiplies two 32-bit register values, adds a 64-bit register value, and writes the result to the 64-bit destination register. The instruction selector can utilize this to lowering certain patterns in B3 IR before further Air optimization. Given the operation: smaddl d, n, m, a The equivalent patterns would be: d = a + SExt32(n) * SExt32(m) d = SExt32(n) * SExt32(m) + a Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = SExt32(Trunc(ArgumentReg(%x1))) Int @2 = SExt32(Trunc(ArgumentReg(%x2))) Int @3 = Mul(@1, @2) Int @4 = Add(@0, @3) Void@5 = Return(@4, Terminal) Before Adding SMADDL: // Old optimized AIR SignExtend32ToPtr %x1, %x1, @1 SignExtend32ToPtr %x2, %x2, @2 MultiplyAdd64 %x1, %x2, %x0, %x0, @4 Ret64 %x0, @5 After Adding SMADDL: // New optimized AIR MultiplyAddSignExtend32 %x1, %x2, %x0, %x0, @8 Ret64 %x0, @9 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::multiplyAddSignExtend32): * assembler/testmasm.cpp: (JSC::testMultiplyAddSignExtend32Left): (JSC::testMultiplyAddSignExtend32Right): * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testMulAddArg): (testMulAddArgsLeft): (testMulAddArgsRight): (testMulAddSignExtend32ArgsLeft): (testMulAddSignExtend32ArgsRight): (testMulAddArgsLeft32): (testMulAddArgsRight32): * b3/testb3_3.cpp: (addArgTests): 2021-06-22 Saam Barati jitCompileAndSetHeuristics shouldn't return true when we fail to compile https://bugs.webkit.org/show_bug.cgi?id=227155 Reviewed by Tadeu Zagallo. jitCompileAndSetHeuristics should only return true when we've successfully compiled a baseline JIT CodeBlock. However, with the rewrite to using a unified JIT worklist, the code was changed to returning true when a compilation finished, regardless of it being successful or not. This patch fixes that error. This bug was found by our existing executable allocation fuzzer, but at a low hit rate. That fuzzer only ran a single test case. This patch also introduces a new form of the executable fuzzer where we fail to allocate JIT code randomly, and the crash manifests more reliably. And this patch also hooks the new fuzzer into more JSC stress tests. * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::run): * jit/ExecutableAllocationFuzz.cpp: (JSC::doExecutableAllocationFuzzing): * jsc.cpp: (runJSC): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/OptionsList.h: 2021-06-22 Angelos Oikonomopoulos Properly set numFPRs on ARM with NEON/VFP_V3_D32 https://bugs.webkit.org/show_bug.cgi?id=227212 Reviewed by Filip Pizlo. Don't hardcode the number of FP regs on ARMv7 to 16; when targetting a CPU with NEON or VFP_V3_d32, the number of FP regs is 32. This also reverts the recent change to add an extra word to RegisterSet which essentially covered up for this mismatch. The reason this bug only manifested on certain compiler versions was that GCC 8.4/8.5 where built using our buildroot infrastructure, whereas the other GCC versions we tested with were debian system toolchains, targetting a lowest common denominator. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::std::initializer_list): * jit/RegisterSet.h: 2021-06-21 Ross Kirsling [JSC] Add JIT ICs for `#x in obj` feature https://bugs.webkit.org/show_bug.cgi?id=226146 Reviewed by Saam Barati. This patch implements JIT ICs for the new `#x in obj` feature and turns the feature on by default. Implementation closely follows InByVal, though HasPrivateBrand has a few subtleties (namely, it cannot be viewed in terms of a PropertySlot and should not be converted to InById). Microbenchmarks: has-private-name 46.5777+-0.1374 ^ 6.0589+-0.0296 ^ definitely 7.6875x faster has-private-brand 25.8823+-0.0561 ^ 19.1509+-0.0447 ^ definitely 1.3515x faster * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::reset): * bytecode/StructureStubInfo.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleInByAsMatchStructure): (JSC::DFG::ByteCodeParser::handleInById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileInByVal): (JSC::DFG::SpeculativeJIT::compileHasPrivate): (JSC::DFG::SpeculativeJIT::compileHasPrivateName): (JSC::DFG::SpeculativeJIT::compileHasPrivateBrand): * dfg/DFGSpeculativeJIT.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITInlineCacheGenerator.cpp: (JSC::JITInByValGenerator::JITInByValGenerator): * jit/JITInlineCacheGenerator.h: * jit/JITOperations.cpp: (JSC::JSC_DEFINE_JIT_OPERATION): * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_in_by_val): (JSC::JIT::emitHasPrivate): (JSC::JIT::emitHasPrivateSlow): (JSC::JIT::emit_op_has_private_name): (JSC::JIT::emitSlow_op_has_private_name): (JSC::JIT::emit_op_has_private_brand): (JSC::JIT::emitSlow_op_has_private_brand): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_in_by_val): (JSC::JIT::emitHasPrivate): (JSC::JIT::emitHasPrivateSlow): (JSC::JIT::emit_op_has_private_name): (JSC::JIT::emitSlow_op_has_private_name): (JSC::JIT::emit_op_has_private_brand): (JSC::JIT::emitSlow_op_has_private_brand): * jit/Repatch.cpp: (JSC::appropriateOptimizingInByFunction): (JSC::appropriateGenericInByFunction): (JSC::tryCacheInBy): (JSC::repatchInBy): (JSC::tryCacheHasPrivateBrand): (JSC::repatchHasPrivateBrand): (JSC::resetInBy): (JSC::resetHasPrivateBrand): * jit/Repatch.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * runtime/CommonSlowPaths.cpp: * runtime/CommonSlowPaths.h: * runtime/OptionsList.h: 2021-06-21 Don Olmstead Non-unified build fixes late June 2021 edition https://bugs.webkit.org/show_bug.cgi?id=227241 Unreviewed non-unified build fixes. * dfg/DFGDriver.h: 2021-06-21 Xan Lopez [JSC] Fix consistency check during stack splitting in Wasm::LLIntGenerator::addLoop https://bugs.webkit.org/show_bug.cgi?id=226012 Reviewed by Tadeu Zagallo. It is possible for the wasm llint generator to call checkConsistency() on a stack that is only halfway through being properly setup. Specifically, when generating a loop block, we use splitStack() to pop the arguments for the loop into a new stack, and materializeConstantsAndLocals() to materialize the constants and aliases in the loop arguments, but the arguments won't be added back to the stack until the very end of the loop code generation. Since materializeConstantsAndLocals() will check the correctness of the expression stack, which isn't yet fully formed, we'll fail its ASSERT. To workaround this, we create a variant of materializeConstantsAndLocals() that does not check for correctness (similar to what we do in push()), and manually check the correctness of the new split stack in Wasm::LLIntGenerator::addLoop(), which is the place that knows the details of this intermediate state. For more details, see: https://bugs.webkit.org/show_bug.cgi?id=226012#c8 * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::checkConsistencyOfExpressionStack): (JSC::Wasm::LLIntGenerator::checkConsistency): (JSC::Wasm::LLIntGenerator::materializeConstantsAndLocals): (JSC::Wasm::LLIntGenerator::addLoop): 2021-06-21 Yusuke Suzuki Release assert memory in JSC::Wasm::Memory::growShared(JSC::Wasm::PageCount):: https://bugs.webkit.org/show_bug.cgi?id=227180 Reviewed by Keith Miller. When Wasm.Memory is shared, we should allocate bound growable memory even if initial size is 0 bytes, since this range can be later extended by mprotect. If maximum size is also 0 byte, we already have a path that does not allocate anything. * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::tryCreate): 2021-06-21 Yijia Huang Add a new pattern to instruction selector to utilize SMSUBL supported by ARM64 https://bugs.webkit.org/show_bug.cgi?id=227195 Reviewed by Keith Miller. Signed Multiply-Subtract Long(SMSUBL), supported by ARM64, multiplies two 32-bit register values, subtracts the product from a 64-bit register value, and writes the result 64-bit destination register. The instruction selector can utilize this to lowering certain patterns in B3 IR before further Air optimization. Given the operation: smsubl d, n, m, a The equivalent pattern would be: d = a - SExt32(n) * SExt32(m) Given B3 IR: Int @0 = ArgumentReg(%x0) Int @1 = SExt32(Trunc(ArgumentReg(%x1))) Int @2 = SExt32(Trunc(ArgumentReg(%x2))) Int @3 = Mul(@1, @2) Int @4 = Sub(@0, @3) Void@5 = Return(@4, Terminal) Before Adding SMSUBL: // Old optimized AIR SignExtend32ToPtr %x1, %x1, @1 SignExtend32ToPtr %x2, %x2, @2 MultiplySub64 %x1, %x2, %x0, %x0, @4 Ret64 %x0, @5 After Adding SMSUBL: // New optimized AIR MultiplySubSignExtend32 %x1, %x2, %x0, %x0, @4 Ret64 %x0, @5 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::multiplySubSignExtend32): * assembler/testmasm.cpp: (JSC::testMulSubSignExtend32): * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testMulSubArgsLeft): (testMulSubArgsRight): (testMulSubArgsLeft32): (testMulSubArgsRight32): (testMulSubSignExtend32Args): * b3/testb3_3.cpp: (addArgTests): 2021-06-21 Kimmo Kinnunen makeUnique cannot be used to instantiate function-local classes https://bugs.webkit.org/show_bug.cgi?id=227163 Reviewed by Antti Koivisto. Make JSC_MAKE_PARSER_ARENA_DELETABLE_ALLOCATED consistent with WTF_MAKE_FAST_ALLOCATED behavior with respect to unused typedefs inside the macro. * parser/Nodes.h: 2021-06-20 Yusuke Suzuki [JSC] Add ValueOf fast path in toPrimitive https://bugs.webkit.org/show_bug.cgi?id=226948 Reviewed by Ross Kirsling. Add fast path for Object.prototype.valueOf function call since we sometimes encounter this case in Speedometer2/EmberJS-Debug-TodoMVC. ToT Patched value-of-call 65.7169+-0.6192 ^ 45.0986+-0.0830 ^ definitely 1.4572x faster * runtime/JSCJSValue.cpp: (JSC::JSValue::toStringSlowCase const): * runtime/JSObject.cpp: (JSC::callToPrimitiveFunction): 2021-06-20 Robin Morisset Fix speculated type in the one-argument overload of speculateNeitherDoubleNorHeapBigIntNorString https://bugs.webkit.org/show_bug.cgi?id=227119 Reviewed by Yusuke Suzuki. Same problem as bug 226786: a missing check for HeapBigInt in the speculateNeitherDoubleNorHeapBigIntNorString function introduced in 226676. I also rewrote the SpeculatedType for NeitherDoubleNorHeapBigIntNorString in typeFilterFor for readability. The old and the new SpeculatedType are perfectly identical, it is just a different (and in my view more readable) way of writing it. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): 2021-06-19 Mark Lam [Revert r278576] Put the Baseline JIT prologue and op_loop_hint code in JIT thunks. https://bugs.webkit.org/show_bug.cgi?id=226375 Not reviewed. Suspect regresses Speedometer2. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::untagReturnAddress): (JSC::AbstractMacroAssembler::untagReturnAddressWithoutExtraValidation): Deleted. * assembler/MacroAssemblerARM64E.h: (JSC::MacroAssemblerARM64E::untagReturnAddress): (JSC::MacroAssemblerARM64E::untagReturnAddressWithoutExtraValidation): Deleted. * assembler/MacroAssemblerARMv7.h: * assembler/MacroAssemblerMIPS.h: * bytecode/CodeBlock.h: (JSC::CodeBlock::addressOfNumParameters): (JSC::CodeBlock::offsetOfNumParameters): (JSC::CodeBlock::offsetOfInstructionsRawPointer): (JSC::CodeBlock::offsetOfNumCalleeLocals): Deleted. (JSC::CodeBlock::offsetOfNumVars): Deleted. (JSC::CodeBlock::offsetOfArgumentValueProfiles): Deleted. (JSC::CodeBlock::offsetOfShouldAlwaysBeInlined): Deleted. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitSaveCalleeSavesFor): (JSC::AssemblyHelpers::emitSaveCalleeSavesForBaselineJIT): Deleted. (JSC::AssemblyHelpers::emitRestoreCalleeSavesForBaselineJIT): Deleted. * jit/JIT.cpp: (JSC::JIT::compileAndLinkWithoutFinalizing): (JSC::JIT::privateCompileExceptionHandlers): (JSC::prologueGeneratorSelector): Deleted. (JSC::JIT::prologueGenerator): Deleted. (JSC::JIT::arityFixupPrologueGenerator): Deleted. * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::emitNakedNearCall): * jit/JITOpcodes.cpp: (JSC::JIT::op_ret_handlerGenerator): (JSC::JIT::emit_op_enter): (JSC::JIT::op_enter_handlerGenerator): (JSC::JIT::emit_op_loop_hint): (JSC::JIT::emitSlow_op_loop_hint): (JSC::JIT::op_enter_Generator): Deleted. (JSC::JIT::op_enter_canBeOptimized_Generator): Deleted. (JSC::JIT::op_enter_cannotBeOptimized_Generator): Deleted. (JSC::JIT::op_loop_hint_Generator): Deleted. * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_enter): * jit/ThunkGenerators.cpp: (JSC::popThunkStackPreservesAndHandleExceptionGenerator): 2021-06-19 Commit Queue Unreviewed, reverting r278699. https://bugs.webkit.org/show_bug.cgi?id=227174 Regressed JetStream2/WSL Reverted changeset: "[JSC] Remove useDataICInOptimizingJIT option" https://bugs.webkit.org/show_bug.cgi?id=226862 https://trac.webkit.org/changeset/278699 2021-06-18 Yijia Huang Add a new pattern to B3ReduceStrength based on Bug 226984 https://bugs.webkit.org/show_bug.cgi?id=227138 Reviewed by Filip Pizlo. In the previous patch bug 226984, a new pattern could be introduced to B3ReduceStrength.cpp for further optimization, which is that: dest = (src >> shiftAmount) & mask is equivalent to src >> shiftAmount under these constraints: 1. shiftAmount >= 0 2. mask has a binary format in contiguous ones starting from the least significant bit. 3. shiftAmount + bitCount(mask) == maxBitWidth For instance (32-bit): (src >> 12) & 0x000fffff == src >> 12 This reduction is more beneficial than UBFX in this case. // B3 IR Int @0 = ArgumentReg(%0) Int @1 = 12 Int @2 = ZShr(@0, @1) Int @3 = 0x000fffff Int @4 = BitAnd(@2, @3)) Void@5 = Return(@4, Terminal) w/o the pattern: // Old optimized AIR Ubfx %0, $12, $20, %0, @4 Ret %0, @5 w/ the pattern: // New optimized AIR Urshift %0, $12, %0, @3 Ret32 %0, @6 * b3/B3ReduceStrength.cpp: * b3/testb3.h: * b3/testb3_2.cpp: (testBitAndZeroShiftRightImmMask32): (testBitAndZeroShiftRightImmMask64): (addBitTests): 2021-06-18 Robin Morisset [DFG] Untyped branches should eliminate checks based on results from the AbstractInterpreter https://bugs.webkit.org/show_bug.cgi?id=227159 Reviewed by Filip Pizlo. We currently emit a ton of code for Untyped branches, as we use branchIfTruthy which does not know anything about the abstract interpreter. Even worse: we call branchIfTruthy after emitting some fast paths, and branchIfTruthy replicates these fast paths (Int32 and Booleans). While I plan to reduce the number of Untyped branches in some separate patches, there is a very long tail of predicted types visible in benchmarks, so I expect some of them to remain no matter what, justifying making the code emitted in that case more reasonable. The implementation in this patch is fairly straightforward, as it follows very closely branchOnValue() from AssemblyHelpers (which was previously called through branchIfTruthy). It was tested on the JSC stress tests, as well as on JetStream2. On JetStream2, it reduced the average number of bytes emitted for Branch by the DFG from 30.1 to 27.5 (highly significant, it only changes by about 0.1 between runs). Since only about 1.5k branches are untyped out of 34k in that benchmark, it means that this patch reduces the amount of code emitted for untyped branches by about 50 bytes on average. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::branchDoubleZeroOrNaN): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitUntypedBranch): (JSC::DFG::SpeculativeJIT::emitBranch): 2021-06-17 Mark Lam Rename numberOfPACBits to maxNumberOfAllowedPACBits. https://bugs.webkit.org/show_bug.cgi?id=227156 Reviewed by Saam Barati. Just renaming the constant to better describe what it represents. There are no behavior changes. * assembler/MacroAssemblerARM64E.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::cageWithoutUntagging): (JSC::AssemblyHelpers::cageConditionallyAndUntag): * llint/LowLevelInterpreter64.asm: 2021-06-17 Mark Lam Define MacroAssemblerARM64E::numberOfPACBits based on OS_CONSTANT(EFFECTIVE_ADDRESS_WIDTH). https://bugs.webkit.org/show_bug.cgi?id=227147 rdar://78785309 Reviewed by Saam Barati. * assembler/MacroAssemblerARM64E.h: * bytecode/CodeOrigin.h: * runtime/JSString.h: * runtime/OptionsList.h: 2021-06-17 Fujii Hironori Reimplement JSC::CachePayload without FileSystem::unmapViewOfFile and FileSystem::MappedFileData::leakHandle https://bugs.webkit.org/show_bug.cgi?id=227014 Reviewed by Yusuke Suzuki. r247542 (Bug 199759) added FileSystem::unmapViewOfFile and FileSystem::MappedFileData::leakHandle for JSC::CachePayload to get the mapped address and to free the address. However, Bug 227011 is going to add a file mapping handle to FileSystem::MappedFileData for Windows port to create a SharedMemory from a MappedFileData. Destruction of MappedFileData should be done only by MappedFileData dtor. * runtime/CachePayload.cpp: (JSC::CachePayload::makeMappedPayload): (JSC::CachePayload::makeMallocPayload): (JSC::CachePayload::makeEmptyPayload): (JSC::CachePayload::CachePayload): (JSC::CachePayload::data const): (JSC::CachePayload::size const): (JSC::CachePayload::~CachePayload): Deleted. (JSC::CachePayload::operator=): Deleted. (JSC::CachePayload::freeData): Deleted. * runtime/CachePayload.h: Use Variant for data. (JSC::CachePayload::data const): Deleted. (JSC::CachePayload::size const): Deleted. (JSC::CachePayload::CachePayload): Deleted. 2021-06-17 Yijia Huang Add a new pattern to instruction selector to utilize UBFX supported by ARM64 https://bugs.webkit.org/show_bug.cgi?id=226984 Reviewed by Filip Pizlo. UBFX, supported by ARM64, copies adjacent bits from the source register into the least significant bits of a destination register in zero extension. The instruction selector can utilize this to lowering certain patterns in B3 IR before further Air optimization. ubfx dest, src, lsb, width tmp, tmp, imm, imm This is equivalent to "dest = (src >> lsb) & ((1 << width) - 1)". Since wasm introduces constant folding, then the pattern would be: dest = (src >> lsb) & mask where the mask should have a binary format in contiguous ones starting from the least significant bit. For example: 0b00111111 To make the pattern matching in instruction selection beneficial to JIT, these constraints should be introduced: 1. lsb >= 0 2. width > 0 3. lsb + width <= bit field limit (32 or 64) Given: // B3 IR Int @0 = ArgumentReg(%0) Int @1 = lsb Int @2 = 0b0011 Int @3 = ZShr(@0, @1) Int @4 = BitAnd(@3, @2) Void@5 = Return(@4, Terminal) w/o UBFX Pattern: // Old optimized AIR Urshift %x0, lsb, %x0, @3 And 0b0011, %x0, %x0, @4 Ret %x0, @5 w/ UBFX Pattern: // New optimized AIR Ubfx %x0, lsb, 2, %x0, @4 Ret %x0, @5 Note: Suppose a 32-bit version of (src >> 20) & 0x0FFF, it is equivalent to src >> 20. In this case, Logical Shift Right should be utilized instead when: lsb + width == bit field limit (32 or 64) This case/pattern should be added and upadated in the future patch. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::ubfx32): (JSC::MacroAssemblerARM64::ubfx64): * assembler/testmasm.cpp: (JSC::testUbfx32): (JSC::testUbfx64): * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testUbfx64PatternMatch): (testUbfx32PatternMatch): (addBitTests): 2021-06-17 Angelos Oikonomopoulos [JSC] Work around apparent miscompilation on ARM/GCC >=8.4 https://bugs.webkit.org/show_bug.cgi?id=227125 Reviewed by Filip Pizlo. This seems to be a GCC miscompilation, revealed by https://bugs.webkit.org/show_bug.cgi?id=227078. Introduce a workaround for the GCC versions that seem to be affected. * jit/RegisterSet.h: 2021-06-16 Yusuke Suzuki [JSC] Optimize JSON.parse with small data by changing Identifier pool mechanism https://bugs.webkit.org/show_bug.cgi?id=227101 Reviewed by Mark Lam. Found that std::array pool in LiteralParser is too costly for construction and destruction if JSON.parse is invoked for small data. This patch changes this pool mechanism so that we do not waste effort allocating null Identifiers to pre-populate the recent identifiers pool. Instead, we now use a m_recentIdentifiersIndex uint8_t array to indicate whether there's a cached recent identifier for each given first character. We also use KeywordLookup.h's COMPARE_XCHARS to perform "true" / "false" / "null" lexing in JSON parser. Roughly 20% improvement in microbenchmark. And roughly 2-3% improvement in Speedometer2/Flight-TodoMVC. ToT Patched flight-todomvc-json 67.8755+-1.1202 ^ 56.7114+-0.5048 ^ definitely 1.1969x faster * runtime/Identifier.cpp: (JSC::Identifier::add): (JSC::Identifier::add8): * runtime/Identifier.h: (JSC::Identifier::Identifier): (JSC::Identifier::add): * runtime/IdentifierInlines.h: (JSC::Identifier::add): (JSC::Identifier::fromString): * runtime/LiteralParser.cpp: (JSC::compare3Chars): (JSC::compare4Chars): (JSC::LiteralParser::makeIdentifier): (JSC::LiteralParser::Lexer::lex): * runtime/LiteralParser.h: 2021-06-16 Mark Lam Adopt com.apple.security.cs.jit-write-allowlist on internal builds. https://bugs.webkit.org/show_bug.cgi?id=222148 rdar://74284026 Reviewed by Per Arne Vollan. This will prevent various pthread permissions switching APIs from working. We only want to adopt this for internal builds where we use the fast permission switching macro instead. We can't adopt it for open source builds, where we still rely on the pthread API. * Scripts/process-entitlements.sh: 2021-06-16 Robin Morisset Don't look at the (non-existent) child2 of DelById https://bugs.webkit.org/show_bug.cgi?id=227095 Reviewed by Mark Lam. Trivial fix to a broken rebase: while it is ok to share most code between DelById and DelByVal, only the latter has a child2(), so it should not be accessed if we are compiling the former. No new test, as it was caught by one of our existing tests. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): 2021-06-16 Yijia Huang Add Air opcode sub32/64(Reg, Imm, Reg) form for ARM64 and select this instruction in Air https://bugs.webkit.org/show_bug.cgi?id=226937 Reviewed by Yusuke Suzuki. Previously, Air arm64 sub32/64 utilize sub(Imm, Tmp) at optlevel = 0 and add(Tmp, -Imm) at optlevel > 0 to perform and optimize sub(Tmp, Imm, Tmp). The issue with this is that we were not eliding redundant operations. For example: // B3 IR @0 = Trunc(ArgumentReg(0)) @1 = Const @2 = Sub(@0, @1) @3 = Return(@2) // Old optimized Air IR // OptLevel = 0 Move %x0, %tmp1, @0 Move $Const, %tmp2, @1 Move %tmp1, %tmp0, @2 // Redundant Sub $Const, %tmp0, @2 Move %tmp0, %x0, @3 Ret32 %x0, @3 To remove those redundant instructions, Air arm64 sub32/64 opcode should indicate a new form sub(Tmp, Imm, Tmp). // New optimized Air IR // OptLevel = 0 Move %x0, %tmp1, @0 Move $Const, %tmp2, @1 Sub %tmp1, $Const, %tmp0, @2 Move %tmp0, %x0, @3 Ret32 %x0, @3 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::sub32): (JSC::MacroAssemblerARM64::sub64): * assembler/testmasm.cpp: (JSC::testSub32Args): (JSC::testSub32Imm): (JSC::testSub32ArgImm): (JSC::testSub64Imm32): (JSC::testSub64ArgImm32): (JSC::testSub64Imm64): (JSC::testSub64ArgImm64): * b3/B3ReduceStrength.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testSubArgs32ZeroExtend): * b3/testb3_3.cpp: (addArgTests): 2021-06-16 Robin Morisset Drop the FTL(DFG) graph after lowering to B3 https://bugs.webkit.org/show_bug.cgi?id=226556 Reviewed by Phil Pizlo. This patch originally landed as r278463, was reverted in r278463. I believe that the bug for which it was reverted actually comes from r278371, which was also reverted at the same time. So I am now relanding this. The challenge in this patch was dealing with all of the Patchpoints created by FTLLowerDFGToB3: they get a lambda at that time, which they execute at the end of Air, and many of these lambdas were capturing a pointer to some parts of the DFG graph and reading through it when being executed. In all cases but one it was easily fixed: they were only reading a few bits from a given node, so I just read these bits in FTLLowerDFGToB3, and captured them (by value) instead of the pointer to the node. The exception was compileCallOrConstructVarargsSpread(): its patchpoint generator was walking through the graph, flattening a tree of PhantomSpread/PhantomNewArrayWithSpread/PhantomNewArrayBuffer/PhantomCreateRest, emitting some code along the way. We now do this flattening of the tree in FTLLowerDFGToB3, store just enough information to later emit the required code in a vector, and capture that vector in the lambda (through a move capture, which is allowed since C++14). See `struct VarargsSpreadArgumentToEmit` for the information that we need to store in that vector. I tested this change by completing a full run of JetStream2 with ASAN. I also ran the stress tests with "spread" in their name in Debug mode. * b3/B3SparseCollection.h: (JSC::B3::SparseCollection::clearAll): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::freeDFGIRAfterLowering): * dfg/DFGGraph.h: * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::getPrivateName): (JSC::FTL::DFG::LowerDFGToB3::compilePrivateBrandAccess): (JSC::FTL::DFG::LowerDFGToB3::cachedPutById): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileTailCall): (JSC::FTL::DFG::LowerDFGToB3::VarargsSpreadArgumentToEmit::VarargsSpreadArgumentToEmit): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileCallEval): (JSC::FTL::DFG::LowerDFGToB3::compileInById): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): (JSC::FTL::DFG::LowerDFGToB3::getById): (JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet): (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet): (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet): (JSC::FTL::DFG::LowerDFGToB3::crash): 2021-06-16 Filip Pizlo RegisterSet should be smaller https://bugs.webkit.org/show_bug.cgi?id=227078 Reviewed by Geoff Garen. Previously, every RegisterSet would have an extra 64-bit word in it just to hold state relevant to hashtable keys. But RegisterSet is almost never used as a hashtable key. This patch moves the hashtable key support into a subclass, HashableRegisterSet. That class ends up only being used in one place. On ARM64, this makes RegisterSet use 64 bits instead of 128 bits. On X86_64, this makes RegisterSet use 32 bits instead of 64 bits. * JavaScriptCore.xcodeproj/project.pbxproj: * ftl/FTLSlowPathCallKey.h: (JSC::FTL::SlowPathCallKey::SlowPathCallKey): * jit/HashableRegisterSet.h: Added. (JSC::HashableRegisterSet::HashableRegisterSet): (JSC::HashableRegisterSet::isEmptyValue const): (JSC::HashableRegisterSet::isDeletedValue const): (JSC::RegisterSetHash::hash): (JSC::RegisterSetHash::equal): * jit/RegisterSet.h: (): Deleted. (JSC::RegisterSet::isEmptyValue const): Deleted. (JSC::RegisterSet::isDeletedValue const): Deleted. (JSC::RegisterSetHash::hash): Deleted. (JSC::RegisterSetHash::equal): Deleted. 2021-06-16 Tadeu Zagallo AssemblyHelpers should save/restore callee save FPRs https://bugs.webkit.org/show_bug.cgi?id=227052 Reviewed by Mark Lam. We have 3 functions in AssemblyHelpers to save and restore callee save registers that were filtering out any FPRs. This is an issue since we do have callee save FPRs in arm64 and these functions can be called from the FTL, and FTL uses those callee saves. The test case shows how that's an issue with tail calls on FTL: the callee saves are correctly stored in the prologue and restored in the epilogue, but when emitting a tail call we use AssemblyHelpers::emitRestoreCalleeSaves to restore the callee saves, which doesn't restore FPRs. This results in the callee save FPRs being trashed. To fix this we just need to stop filtering out the FPRs, if they are listed as used by the code block they should be saved/restored accordingly. I also changed DFGOSREntry to stop filtering out the callee save FPRs and instead assert there aren't any, since they aren't currently used in the DFG, but it could help avoid the same issue in the future. * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitSaveCalleeSavesFor): (JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor): (JSC::AssemblyHelpers::emitRestoreCalleeSavesFor): 2021-06-16 Commit Queue Unreviewed, reverting r278846. https://bugs.webkit.org/show_bug.cgi?id=227060 Speculative revert based on failure history of Speedometer2 Reverted changeset: "Add Air opcode sub32/64(Reg, Imm, Reg) form for ARM64 and select this instruction in Air" https://bugs.webkit.org/show_bug.cgi?id=226937 https://trac.webkit.org/changeset/278846 2021-06-15 Yusuke Suzuki [JSC] Optimize JSON.parse with small content by dropping single character Identifier pool https://bugs.webkit.org/show_bug.cgi?id=227057 Reviewed by Sam Weinig. Profiler results and investigation suggest interesting things. 1. Sampling profiler says Flight-TodoMVC is mostly JSON.parse benchmark. 2. Each JSON data of Flight-TodoMVC is small. And JSON.parse is super frequently called. 3. In the case of JSON.parse with small data, LiteralParser's construction / destruction costs much since it has large Identifier pool with std::array<>. As a simple first step, this patch removes single character Identifier pool from LiteralParser since the exact same Identifier data can be retrieved from VM's SmallStrings. We created a microbenchmark from Flight-TodoMVC's data, and the result is roughly 20% better. And we observed 0.6% improvement in Speedometer2. ToT Patched flight-todomvc-json 81.0552+-0.8403 ^ 67.5756+-0.6221 ^ definitely 1.1995x faster ---------------------------------------------------------------------------------------------------------------------------------- | subtest | ms | ms | b / a | pValue (significance using False Discovery Rate) | ---------------------------------------------------------------------------------------------------------------------------------- | Elm-TodoMVC |128.991667 |128.450000 |0.995801 | 0.278228 | | VueJS-TodoMVC |28.487500 |27.925000 |0.980254 | 0.139315 | | EmberJS-TodoMVC |133.950000 |134.175000 |1.001680 | 0.685021 | | BackboneJS-TodoMVC |51.670833 |51.537500 |0.997420 | 0.628993 | | Preact-TodoMVC |21.783333 |21.754167 |0.998661 | 0.944237 | | AngularJS-TodoMVC |143.820833 |143.770833 |0.999652 | 0.933953 | | Vanilla-ES2015-TodoMVC |71.608333 |71.416667 |0.997323 | 0.500591 | | Inferno-TodoMVC |69.179167 |69.525000 |1.004999 | 0.412406 | | Flight-TodoMVC |81.354167 |79.020833 |0.971319 | 0.000053 (significant) | | Angular2-TypeScript-TodoMVC |42.654167 |41.887500 |0.982026 | 0.086053 | | VanillaJS-TodoMVC |57.054167 |56.633333 |0.992624 | 0.176804 | | jQuery-TodoMVC |274.595833 |275.670833 |1.003915 | 0.148812 | | EmberJS-Debug-TodoMVC |358.387500 |357.595833 |0.997791 | 0.323387 | | React-TodoMVC |93.804167 |93.329167 |0.994936 | 0.113410 | | React-Redux-TodoMVC |157.954167 |157.266667 |0.995647 | 0.131298 | | Vanilla-ES2015-Babel-Webpack-TodoMVC |68.687500 |68.054167 |0.990779 | 0.002155 (significant) | ---------------------------------------------------------------------------------------------------------------------------------- a mean = 235.28964 b mean = 236.72163 pValue = 0.0121265559 (Bigger means are better.) 1.006 times better Results ARE significant * runtime/Identifier.h: (JSC::Identifier::canUseSingleCharacterString): * runtime/LiteralParser.cpp: (JSC::LiteralParser::makeIdentifier): * runtime/LiteralParser.h: * runtime/SmallStrings.cpp: (JSC::SmallStrings::singleCharacterStringRep): * runtime/SmallStrings.h: 2021-06-15 Keith Miller Shouldn't drain the micro task queue when calling out to ObjC https://bugs.webkit.org/show_bug.cgi?id=161942 Unreviewed, relanding r278734. * API/tests/testapi.cpp: (TestAPI::promiseDrainDoesNotEatExceptions): (testCAPIViaCpp): * API/tests/testapi.mm: (testMicrotaskWithFunction): (testObjectiveCAPI): * runtime/JSLock.cpp: (JSC::JSLock::willReleaseLock): * runtime/ObjectPrototype.cpp: (JSC::isPokerBros): * runtime/VM.cpp: (JSC::VM::didExhaustMicrotaskQueue): 2021-06-15 Michael Catanzaro -Warray-bounds warning in Packed.h https://bugs.webkit.org/show_bug.cgi?id=226557 Reviewed by Darin Adler. * b3/air/AirAllocateRegistersByGraphColoring.cpp: * jit/JITCall.cpp: (JSC::JIT::compileOpCall): 2021-06-15 Mark Lam Move setting of scratch buffer active lengths to the runtime functions. https://bugs.webkit.org/show_bug.cgi?id=227013 rdar://79325068 Reviewed by Keith Miller. We previously emit JIT'ed code to set and unset the ScratchBuffer active length around calls into C++ runtime functions. This was needed because the runtime functions may allow GC to run, and GC needs to be able to scan the values stored in the ScratchBuffer. In this patch, we change it so that the runtime functions that need it will declare an ActiveScratchBufferScope RAII object that will set the ScratchBuffer active length, and unset it on exit. This allows us to: 1. Emit less JIT code. The runtime function can take care of it. 2. Elide setting the ScratchBuffer active length if not needed. The runtime functions know whether they can GC or not. They only need to set the active length if they can GC. Note that scanning of the active ScratchBuffer is done synchronously on the mutator thread via Heap::gatherScratchBufferRoots(), which is called as part of the GC conservative root scan. This means there is no urgency / sequencing that requires that the active length be set before calling into the runtime function. Setting it in the runtime function itself is fine as long as it is done before the function executes any operations that can GC. This patch also made the following changes: 1. Introduce ActiveScratchBufferScope RAII object used to set/unset the ScratchBuffer length in the runtime functions. ActiveScratchBufferScope takes the active length in units of number of stack slots / Registers / JSValues instead of bytes. 2. Deleted ScratchRegisterAllocator::preserveUsedRegistersToScratchBufferForCall() and ScratchRegisterAllocator::restoreUsedRegistersFromScratchBufferForCall(). These functions are unused. The reasoning behind what values to pass to ActiveScratchBufferScope, is any: 1. AssemblyHelpers::debugCall() in AssemblyHelpers.cpp: The ScratchBuffer is only used for operationDebugPrintSpeculationFailure(), which now declares an ActiveScratchBufferScope. The active length is GPRInfo::numberOfRegisters + FPRInfo::numberOfRegisters. See scratchSize in AssemblyHelpers::debugCall(). 2. genericGenerationThunkGenerator() in FTLThunks.cpp: The scratch buffer size for determining the active length is requiredScratchMemorySizeInBytes(). However, genericGenerationThunkGenerator() generates code to call either operationCompileFTLOSRExit() or operationCompileFTLLazySlowPath(). Both of these functions will DeferGCForAWhile. Hence, GC cannot run, and we don't need to set the active length here. 3. compileArrayPush() in FTLLowerDFGToB3.cpp: Cases Array::Int32, Array::Contiguous, or Array::Double calls operationArrayPushMultiple() or operationArrayPushDoubleMultiple(). For operationArrayPushMultiple(), the active length is elementCount. See computation of scratchSize. For operationArrayPushDoubleMultiple(), we don't need to set the active length because the ScratchBuffer only contains double values. The GC does not need to scan those. Case Array::ArrayStorage calls operationArrayPushMultiple(). The active length is elementCount. See computation of scratchSize. compileNewArray() in FTLLowerDFGToB3.cpp: Calls operationNewArray(). Active length is m_node->numChildren(), which is passed to operationNewArray() as the size parameter. See computation of scratchSize. compileNewArrayWithSpread() in FTLLowerDFGToB3.cpp: Calls operationNewArrayWithSpreadSlow(). Active length is m_node->numChildren(), which is passes to operationNewArrayWithSpreadSlow() as the numItems parameter. See computation of scratchSize. 4. osrExitGenerationThunkGenerator() in DFGThunks.cpp: Calls operationCompileOSRExit(). Active length is GPRInfo::numberOfRegisters + FPRInfo::numberOfRegisters. See computation of scratchSize. 5. compileNewArray() in DFGSpeculativeJIT.cpp: Calls operationNewArray(). Active length is node->numChildren(), which is passed in as the size parameter. compileNewArrayWithSpread() in DFGSpeculativeJIT.cpp: Calls operationNewArrayWithSpreadSlow(). Active length is node->numChildren(), which is passed in as the numItems parameter. compileArrayPush() in DFGSpeculativeJIT.cpp: Calls operationArrayPushMultiple(). Active length is elementCount, which is passed in as the elementCount parameter. Calls operationArrayPushDoubleMultiple(). Active length is elementCount, but we don't need to set it because the ScratchBuffer only contains double values. * dfg/DFGOSRExit.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewArray): (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread): (JSC::DFG::SpeculativeJIT::compileArrayPush): * dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush): (JSC::FTL::DFG::LowerDFGToB3::compileNewArray): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::JSC_DEFINE_JIT_OPERATION): * ftl/FTLOperations.cpp: (JSC::FTL::JSC_DEFINE_JIT_OPERATION): * ftl/FTLThunks.cpp: (JSC::FTL::genericGenerationThunkGenerator): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::debugCall): * jit/ScratchRegisterAllocator.cpp: (JSC::ScratchRegisterAllocator::preserveUsedRegistersToScratchBufferForCall): Deleted. (JSC::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBufferForCall): Deleted. * jit/ScratchRegisterAllocator.h: * runtime/VM.h: * runtime/VMInlines.h: (JSC::ActiveScratchBufferScope::ActiveScratchBufferScope): (JSC::ActiveScratchBufferScope::~ActiveScratchBufferScope): 2021-06-14 Yusuke Suzuki [JSC] Workaround ICU uloc_addLikelySubtags / uloc_minimizeSubtags bugs https://bugs.webkit.org/show_bug.cgi?id=226996 rdar://79250513 Reviewed by Ross Kirsling. ICU has bugs that uloc_addLikelySubtags / uloc_minimizeSubtags cannot handle very long locale ID that exceeds ULOC_FULLNAME_CAPACITY, while these functions can take arbitrary sized buffer for output. This can be achieved simply by (1) attaching many unicode extensions, or (2) having many variants. In this patch, we add a workaround: if uloc_addLikelySubtags / uloc_minimizeSubtags failed, we perform them without having locale ID keywords part. After performing the operations, we append these keywords back. This is workaround, and still this workaround is not complete since we could have many variants. In that case, uloc_addLikelySubtags / uloc_minimizeSubtags still fails, and in that case, for now, we give up performing uloc_addLikelySubtags / uloc_minimizeSubtags. Fixing this needs to be done in ICU side: https://unicode-org.atlassian.net/browse/ICU-21639 * runtime/IntlLocale.cpp: (JSC::IntlLocale::keywordValue const): (JSC::IntlLocale::maximal): (JSC::IntlLocale::minimal): (JSC::IntlLocale::baseName): 2021-06-14 Mark Lam Add ldp and stp support for FP registers, plus some bug fixes. https://bugs.webkit.org/show_bug.cgi?id=226998 rdar://79313717 Reviewed by Robin Morisset. This patch does the following: 1. Add ldp and stp support for FP registers. This simply entails providing wrappers that take FPRegisterID and passing true for the V bit to the underlying loadStoreRegisterPairXXX encoding function. V is for vector (aka floating point). This will cause bit 26 in the instruction to be set indicating that it's loading / storing floating point registers. 2. Add ARM64 disassembler support ldp and stp for FP registers. This includes fixing A64DOpcodeLoadStoreRegisterPair::mask to not exclude the FP versions of the instructions. 3. Add ARM64Assembler query methods for determining if an immediate is encodable as the signed 12 bit immediate of ldp and stp instructions. 4. Fix ldp and stp offset form to take an int instead of an unsigned. The immediate it takes is a 12-bit signed int, not unsigned. 5. In loadStoreRegisterPairXXX encoding functions used by the forms of ldp and stp, RELEASE_ASSERT that the passed in immediate is encodable. Unlike ldur / stur, there is no form of ldp / stp that takes the offset in a register that can be used as a fail over. Hence, if the immediate is not encodable, this is a non-recoverable event. The client is responsible for ensuring that the offset is encodable. 6. Added some testmasm tests for testing the offset form (as opposed to PreIndex and PostIndex forms) of ldp and stp. We currently only use the offset form in our JITs. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::isValidLDPImm): (JSC::ARM64Assembler::isValidLDPFPImm): (JSC::ARM64Assembler::ldp): (JSC::ARM64Assembler::ldnp): (JSC::ARM64Assembler::isValidSTPImm): (JSC::ARM64Assembler::isValidSTPFPImm): (JSC::ARM64Assembler::stp): (JSC::ARM64Assembler::stnp): (JSC::ARM64Assembler::loadStoreRegisterPairPostIndex): (JSC::ARM64Assembler::loadStoreRegisterPairPreIndex): (JSC::ARM64Assembler::loadStoreRegisterPairOffset): (JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal): * assembler/AssemblerCommon.h: (JSC::isValidSignedImm7): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::loadPair64): (JSC::MacroAssemblerARM64::storePair64): * assembler/testmasm.cpp: (JSC::testLoadStorePair64Int64): (JSC::testLoadStorePair64Double): * disassembler/ARM64/A64DOpcode.cpp: (JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::format): * disassembler/ARM64/A64DOpcode.h: 2021-06-14 Yijia Huang Add Air opcode sub32/64(Reg, Imm, Reg) form for ARM64 and select this instruction in Air https://bugs.webkit.org/show_bug.cgi?id=226937 Reviewed by Saam Barati. Previously, Air arm64 sub32/64 utilize sub(Imm, Tmp) at optlevel = 0 and add(Tmp, -Imm) at optlevel > 0 to perform and optimize sub(Tmp, Imm, Tmp). The issue with this is that we were not eliding redundant operations. For example: // B3 IR @0 = Trunc(ArgumentReg(0)) @1 = Const @2 = Sub(@0, @1) @3 = Return(@2) // Old optimized Air IR // OptLevel = 0 Move %x0, %tmp1, @0 Move $Const, %tmp2, @1 Move %tmp1, %tmp0, @2 // Redundant Sub $Const, %tmp0, @2 Move %tmp0, %x0, @3 Ret32 %x0, @3 To remove those redundant instructions, Air arm64 sub32/64 opcode should indicate a new form sub(Tmp, Imm, Tmp). // New optimized Air IR // OptLevel = 0 Move %x0, %tmp1, @0 Move $Const, %tmp2, @1 Sub %tmp1, $Const, %tmp0, @2 Move %tmp0, %x0, @3 Ret32 %x0, @3 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::sub32): (JSC::MacroAssemblerARM64::sub64): * assembler/testmasm.cpp: (JSC::testSub32Args): (JSC::testSub32Imm): (JSC::testSub32ArgImm): (JSC::testSub64Imm32): (JSC::testSub64ArgImm32): (JSC::testSub64Imm64): (JSC::testSub64ArgImm64): * b3/B3ReduceStrength.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_2.cpp: (testSubArgs32ZeroExtend): * b3/testb3_3.cpp: (addArgTests): 2021-06-14 Commit Queue Unreviewed, reverting r278734. https://bugs.webkit.org/show_bug.cgi?id=226973 broke jsc testapi Reverted changeset: "Shouldn't drain the micro task queue when calling out to ObjC" https://bugs.webkit.org/show_bug.cgi?id=161942 https://trac.webkit.org/changeset/278734 2021-06-13 Saam Barati https://bugs.webkit.org/show_bug.cgi?id=226576 Reviewed by Yusuke Suzuki. ShortCircuitReadModifyResolveNode can't emit a value into its result until after it emits a TDZ check. We were temporarily storing the result of the get_from_scope into the dst. Then we'd emit the TDZ check. The TDZ check can throw, and it could lead to us returning TDZ from the eval itself. Instead, we need to use a temporary to emit a TDZ check on. Only after the TDZ check passes can we move the temporary into the result. * bytecompiler/NodesCodegen.cpp: (JSC::ShortCircuitReadModifyResolveNode::emitBytecode): 2021-06-12 Michael Catanzaro -Wnonnull warning in JITCall.cpp https://bugs.webkit.org/show_bug.cgi?id=226643 Reviewed by Darin Adler. This is a false-positive, so suppress it using IGNORE_ERRONEOUS_GCC_NULL_CHECK_WARNINGS_BEGIN. * jit/JITCall.cpp: (JSC::JIT::compileOpCall): 2021-06-12 Robin Morisset We should drop B3 values while running Air https://bugs.webkit.org/show_bug.cgi?id=226187 Reviewed by Saam Barati. NB: this patch first landed as r278371, then was reverted in r278587 as it broke --dumpDisassembly(). I fixed the bug (a missing line setDisassembler()) and am now re-landing it. Below is a copy of the original Changelog. We must keep the following values: - WasmBoundsCheck, to know whether it is Pinned or Maximum, and if it is pinned find its argument. - CCall/Patch/Check/CheckAdd/CheckSub/CheckMul and all of their children, because all of these are lowered to Air::Patchpoint, which needs to know the type of its arguments, and does so by looking at the children of its origin. I intend to fix these in later patches if possible. Finally we must preserve all B3 values in the following cases: - if we dump the disassembly or the Air graph: because otherwise we cannot print the origins - if we are using the sampling profiler, because it relies on PCToCodeOriginMap which we cannot accurately fill without these origins. We must also keep m_tuples alive, as it is used by Patchpoints in Air to understand the types of their arguments. We also don't touch StackSlots (in this patch), because one of them is captured by FTL::State. Also now PCToOriginMap has a Vector with no inline capacity, since it is either quite large (if needed) or empty (otherwise). The performance impact of this is a progression on various RAMification subtests on Mac, but is more mitigated on iPhone7, with various regressions. I suspect these to be noise, and will monitor the performance bots post-landing to make sure of it. * b3/B3LowerToAir.cpp: (JSC::B3::lowerToAir): * b3/B3Procedure.cpp: (JSC::B3::Procedure::freeUnneededB3ValuesAfterLowering): * b3/B3Procedure.h: (JSC::B3::Procedure::releasePCToOriginMap): (JSC::B3::Procedure::setNeedsPCToOriginMap): (JSC::B3::Procedure::needsPCToOriginMap): * b3/B3SparseCollection.h: (JSC::B3::SparseCollection::clearAll): (JSC::B3::SparseCollection::filterAndTransfer): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): * b3/air/AirCode.h: (JSC::B3::Air::Code::shouldPreserveB3Origins const): * b3/air/AirGenerate.cpp: (JSC::B3::Air::generateWithAlreadyAllocatedRegisters): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLState.cpp: (JSC::FTL::State::State): 2021-06-11 Patrick Angle Web Inspector: Add instrumentation to node destruction for InspectorDOMAgent https://bugs.webkit.org/show_bug.cgi?id=226624 Reviewed by Devin Rousso. Add new `DOM.willDestroyDOMNode` event to inform the frontend of DOM nodes that no longer exist, even if they weren't in the DOM tree. This work serves as a prelude to (Web Inspector: preserve DOM.NodeId if a node is removed and re-added) to eventually only forget about nodes upon destruction, instead of removal from the DOM tree. * inspector/protocol/DOM.json: 2021-06-11 Yijia Huang Air ARM64 sub32 opcode should indicate that it zero-extends its result https://bugs.webkit.org/show_bug.cgi?id=226849 Reviewed by Saam Barati. Sub32 was previously not saying that its result is zero defined. However, sub32 on arm64 architectures zero defines its result, so the top 32 bits are zeroed. The issue with this is what we were not eliding provably redundant zero extend operations. For example: // B3 IR @0 = Trunc(ArgumentReg(0)) @1 = Trunc(ArgumentReg(1)) @2 = Sub(@0, @1) @3 = ZExt32(@2) // i64 @4 = Return(@3) or Store(@3, @x) // Old optimized Air IR Sub32 %x0, %x1, %x0, b@2 Move32 %x0, %x0, b@3 Ret64 %x0, b@4 or Move %x0, (%x), b@4 To remove that redundant zero extend instruction (Move32), Air arm64 sub32 opcode should indicate that it zero-extends its result. // New optimized Air IR Sub32 %x0, %x1, %x0, b@2 Ret64 %x0, b@6 or Move %x0, (%x), b@4 * b3/air/AirOpcode.opcodes: 2021-06-10 Keith Miller Shouldn't drain the micro task queue when calling out to ObjC https://bugs.webkit.org/show_bug.cgi?id=161942 Reviewed by Saam Barati. It looks like the issue is that we aren't checking for the presence of dropped locks when deciding to drain microtasks during JSLock::unlock. This meant that when we drop all locks when calling out to API clients we would drain our microtasks at that point. An alternative would be to pass an extra parameter to the unlock function that says not to drain microtasks. I chose not to do that since it seemed a bit less robust. This patch is very likely to break existing API users. So I'm adding a linked on or after check to protect existing Apps. Lastly, change our Poker Bros check to use applicationSDKVersion too so others trying to add a linked on or after check don't use the dyld function directly too. * API/tests/testapi.cpp: (TestAPI::promiseDrainDoesNotEatExceptions): (testCAPIViaCpp): * API/tests/testapi.mm: (testMicrotaskWithFunction): (testObjectiveCAPI): * runtime/JSLock.cpp: (JSC::JSLock::willReleaseLock): * runtime/ObjectPrototype.cpp: (JSC::isPokerBros): * runtime/VM.cpp: (JSC::VM::didExhaustMicrotaskQueue): 2021-06-10 Mark Lam Another speculative build fix for Win32. https://bugs.webkit.org/show_bug.cgi?id=226880 rdar://79124858 Reviewed by Keith Miller. We're getting reports of "warning C4206: nonstandard extension used: translation unit is empty" turning into a build error on Win32 ports. By design, we rely on #define flags to make some translation units empty. Hence, we don't want this warning to turn into an error. * config.h: 2021-06-10 Yusuke Suzuki [JSC] Remove useDataICInOptimizingJIT option https://bugs.webkit.org/show_bug.cgi?id=226862 Reviewed by Mark Lam. Originally this option is added to fix performance problem when using DataIC in DFG / FTL. But it turned out that that performance regression was caused due to disablement of InlineAccess when using DataIC. With the configuration using DataIC and InlineAccess, we do not observe performance regression. So, let's just drop this option. * jit/JITCode.h: (JSC::JITCode::useDataIC): * runtime/Options.cpp: (JSC::Options::recomputeDependentOptions): * runtime/OptionsList.h: 2021-06-10 Adrian Perez de Castro Non-unified build fixes, early May 2021 edition https://bugs.webkit.org/show_bug.cgi?id=226763 Unreviewed non-unified build fixes. * bytecode/InlineAccess.h: Add missing forward declaration for the CodeBlock type. * jit/JITInlineCacheGenerator.cpp: Add missing CCallHelpers.h header. * runtime/Intrinsic.h: Add missing header. * yarr/YarrUnicodeProperties.h: Ditto. 2021-06-10 Yusuke Suzuki [JSC] Ignore Intl.NumberFormat feature options when linked-ICU is old https://bugs.webkit.org/show_bug.cgi?id=226861 rdar://77393100 Reviewed by Ross Kirsling. Let's just ignore the option when Intl.NumberFormat features cannot be implemented since the linked ICU is old. There is no way not to expose these features since Intl.NumberFormat's these changes are additional ones and Intl.NumberFormat existed before. * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::initializeNumberFormat): 2021-06-09 Ross Kirsling [JSC] Rename *ByIdVariant to *ByVariant and *ByKind::Normal to *ByKind::ById https://bugs.webkit.org/show_bug.cgi?id=226750 Reviewed by Yusuke Suzuki. Cleanup patch following r278445. 1. {Get, Delete, In}ByStatus (but not `Put`) have had `Id` removed from their names; likewise, remove `Id` from the names of {Get, Delete, In}ByIdVariant. These are used *before* ByVal has been converted to ById. 2. The {Get, Del, In}ByKind enum classes shouldn't really call ById `Normal` -- let's say `ById` explicitly. 3. Bonus: In DFGBytecodeParser, move some *Status::computeFor calls inside the conditional that uses them. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/DeleteByStatus.cpp: (JSC::DeleteByStatus::appendVariant): (JSC::DeleteByStatus::computeForStubInfoWithoutExitSiteFeedback): (JSC::DeleteByStatus::visitAggregateImpl): (JSC::DeleteByStatus::markIfCheap): * bytecode/DeleteByStatus.h: * bytecode/DeleteByVariant.cpp: Renamed from Source/JavaScriptCore/bytecode/DeleteByIdVariant.cpp. (JSC::DeleteByVariant::DeleteByVariant): (JSC::DeleteByVariant::~DeleteByVariant): (JSC::DeleteByVariant::operator=): (JSC::DeleteByVariant::attemptToMerge): (JSC::DeleteByVariant::writesStructures const): (JSC::DeleteByVariant::visitAggregateImpl): (JSC::DeleteByVariant::markIfCheap): (JSC::DeleteByVariant::dump const): (JSC::DeleteByVariant::finalize): (JSC::DeleteByVariant::dumpInContext const): * bytecode/DeleteByVariant.h: Renamed from Source/JavaScriptCore/bytecode/DeleteByIdVariant.h. (JSC::DeleteByVariant::overlaps): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::appendVariant): (JSC::GetByStatus::computeFromLLInt): (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): (JSC::GetByStatus::computeFor): (JSC::GetByStatus::merge): (JSC::GetByStatus::visitAggregateImpl): (JSC::GetByStatus::markIfCheap): (JSC::GetByStatus::finalize): * bytecode/GetByStatus.h: * bytecode/GetByVariant.cpp: Renamed from Source/JavaScriptCore/bytecode/GetByIdVariant.cpp. (JSC::GetByVariant::GetByVariant): (JSC::GetByVariant::~GetByVariant): (JSC::GetByVariant::operator=): (JSC::GetByVariant::canMergeIntrinsicStructures const): (JSC::GetByVariant::attemptToMerge): (JSC::GetByVariant::visitAggregateImpl): (JSC::GetByVariant::markIfCheap): (JSC::GetByVariant::finalize): (JSC::GetByVariant::dump const): (JSC::GetByVariant::dumpInContext const): * bytecode/GetByVariant.h: Renamed from Source/JavaScriptCore/bytecode/GetByIdVariant.h. (JSC::GetByVariant::overlaps): * bytecode/InByStatus.cpp: (JSC::InByStatus::appendVariant): (JSC::InByStatus::computeForStubInfoWithoutExitSiteFeedback): (JSC::InByStatus::merge): (JSC::InByStatus::markIfCheap): (JSC::InByStatus::finalize): * bytecode/InByStatus.h: * bytecode/InByVariant.cpp: Renamed from Source/JavaScriptCore/bytecode/InByIdVariant.cpp. (JSC::InByVariant::InByVariant): (JSC::InByVariant::attemptToMerge): (JSC::InByVariant::markIfCheap): (JSC::InByVariant::finalize): (JSC::InByVariant::dump const): (JSC::InByVariant::dumpInContext const): * bytecode/InByVariant.h: Renamed from Source/JavaScriptCore/bytecode/InByIdVariant.h. (JSC::InByVariant::overlaps): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::reset): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicGetter): (JSC::DFG::ByteCodeParser::handleDOMJITGetter): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::handleGetPrivateNameById): (JSC::DFG::ByteCodeParser::handleDeleteById): (JSC::DFG::ByteCodeParser::handleInById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): (JSC::DFG::ConstantFoldingPhase::emitGetByOffset): (JSC::DFG::ConstantFoldingPhase::emitDeleteByOffset): * dfg/DFGNode.h: * dfg/DFGValidate.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): (JSC::FTL::DFG::LowerDFGToB3::compileDeleteById): (JSC::FTL::DFG::LowerDFGToB3::compileDeleteByVal): (JSC::FTL::DFG::LowerDFGToB3::compileMultiDeleteByOffset): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/JITOperations.cpp: (JSC::JSC_DEFINE_JIT_OPERATION): * jit/Repatch.cpp: (JSC::appropriateOptimizingGetByFunction): (JSC::appropriateGetByFunction): (JSC::tryCacheGetBy): (JSC::repatchDeleteBy): (JSC::tryCacheInBy): (JSC::repatchInBy): (JSC::resetGetBy): (JSC::resetDelBy): (JSC::resetInBy): * jit/Repatch.h: 2021-06-09 Fujii Hironori clang-cl: JIT.h(966,67): error: no viable conversion from 'JSC::AbstractMacroAssembler::Address' to 'FunctionPtr' https://bugs.webkit.org/show_bug.cgi?id=226850 Reviewed by Yusuke Suzuki. WinCairo clang-cl builds got broken since r278656 (Bug 226072). * jit/JIT.h: Use the common callOperation(Address, Args...) for x64 Windows. Added static_assert to check the return type. 2021-06-09 Mark Lam Speculative build fix for Win32. https://bugs.webkit.org/show_bug.cgi?id=226793 rdar://79032803 Reviewed by Saam Barati. * API/JSCallbackObject.h: 2021-06-09 Xan Lopez [JSC] Fix incorrect register reuse in 32bit after r278568 https://bugs.webkit.org/show_bug.cgi?id=226817 Reviewed by Caio Araujo Neponoceno de Lima. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): The JSVALUE32_64 branch potentially needs both the tag and payload registers for both left/right nodes, so we cannot reuse any of them for the result since the first thing the code does is set it zero. Just remove the Reuse construction. 2021-06-09 Mikhail R. Gadelha Fix inadvertent tag corruption in functionAddressOf https://bugs.webkit.org/show_bug.cgi?id=226503 Reviewed by Darin Adler. Original patch by Angelos Oikonomopoulos. The cast was sign-extending the JSValue address in 32 bits, so that addresses that had the most significant set gave us a sign-extended result in asNumber which was then converted to an invalid NaN by the bitcast. Instead, cast the address to uintptr_t, and the result will be promoted uint64_t without sign-extending the address. * jsc.cpp: (JSC_DEFINE_HOST_FUNCTION): 2021-06-08 Yusuke Suzuki [JSC] Use DataIC for AccessCase https://bugs.webkit.org/show_bug.cgi?id=226072 Reviewed by Saam Barati and Filip Pizlo. This patch adds non-repatching IC for Baseline JIT in ARM64. This does not work in non-ARM64 architectures (including X64) due to the use of link-register. 1. We add non-repatching IC, which is enabled only in Baseline due to performance reason. We are using the existing IC in DFG and FTL. Non-repatching includes fast-path, and slow-path's operation function. 2. We still keep InlineAccess in all tiers. Removing that causes 0.3 ~ 1.0% regression in Speedometer2. This means that we still need some repatching when we first introduce stubs. 3. We add a mechanism to share generated code stubs in non-repatching IC. Currently, getter / setter / custom accessors are excluded since their code relies on JSGlobalObject, CodeBlock etc. which are not included in AccessCase's data structure. 4. This patch still relies on that CodeBlock will be destroyed synchronously since we need to ensure that sharing-hash-table does not include already-dead JIT code stubs. We can fix it (e.g. annotating epoch to these stubs, bump them in finalizeUnconditionally), but we avoid doing that to prevent from further enlarging this patch. This patch is already significant in its size. 5. Added callOperation(Address) support in CCallHelpers, which can save the target in nonArgGPR0, and call it so that we can use Address including GPR which is also used for arguments. Performance is neutral in JetStream2 and Speedometer2. But it offers the way to remove some code generation in Baseline. * assembler/MacroAssemblerARM64E.h: (JSC::MacroAssemblerARM64E::call): * bytecode/AccessCase.cpp: (JSC::AccessCase::create): (JSC::AccessCase::createTransition): (JSC::AccessCase::createDelete): (JSC::AccessCase::createCheckPrivateBrand): (JSC::AccessCase::createSetPrivateBrand): (JSC::AccessCase::fromStructureStubInfo): (JSC::AccessCase::clone const): (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generateImpl): (JSC::AccessCase::canBeShared): * bytecode/AccessCase.h: (JSC::AccessCase::hash const): (JSC::AccessCase::AccessCase): (JSC::SharedJITStubSet::Hash::Key::Key): (JSC::SharedJITStubSet::Hash::Key::isHashTableDeletedValue const): (JSC::SharedJITStubSet::Hash::Key::operator==): (JSC::SharedJITStubSet::Hash::hash): (JSC::SharedJITStubSet::Hash::equal): (JSC::SharedJITStubSet::Searcher::Translator::hash): (JSC::SharedJITStubSet::Searcher::Translator::equal): (JSC::SharedJITStubSet::PointerTranslator::hash): (JSC::SharedJITStubSet::PointerTranslator::equal): (JSC::SharedJITStubSet::add): (JSC::SharedJITStubSet::remove): (JSC::SharedJITStubSet::find): * bytecode/ByValInfo.h: (JSC::ByValInfo::setUp): (JSC::ByValInfo::offsetOfSlowOperation): (JSC::ByValInfo::offsetOfNotIndexJumpTarget): (JSC::ByValInfo::offsetOfBadTypeJumpTarget): * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::initializeDirectCall): (JSC::CallLinkInfo::setDirectCallTarget): * bytecode/CodeBlock.h: (JSC::CodeBlock::useDataIC const): * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::create): (JSC::GetterSetterAccessCase::clone const): (JSC::GetterSetterAccessCase::emitDOMJITGetter): * bytecode/GetterSetterAccessCase.h: * bytecode/InlineAccess.cpp: (JSC::getScratchRegister): (JSC::InlineAccess::rewireStubAsJumpInAccessNotUsingInlineAccess): (JSC::InlineAccess::rewireStubAsJumpInAccess): (JSC::InlineAccess::resetStubAsJumpInAccess): (JSC::InlineAccess::resetStubAsJumpInAccessNotUsingInlineAccess): (JSC::InlineAccess::rewireStubAsJump): Deleted. * bytecode/InlineAccess.h: * bytecode/InstanceOfAccessCase.cpp: (JSC::InstanceOfAccessCase::create): (JSC::InstanceOfAccessCase::clone const): * bytecode/InstanceOfAccessCase.h: * bytecode/IntrinsicGetterAccessCase.cpp: (JSC::IntrinsicGetterAccessCase::create): (JSC::IntrinsicGetterAccessCase::clone const): * bytecode/IntrinsicGetterAccessCase.h: * bytecode/ModuleNamespaceAccessCase.cpp: (JSC::ModuleNamespaceAccessCase::create): (JSC::ModuleNamespaceAccessCase::clone const): * bytecode/ModuleNamespaceAccessCase.h: * bytecode/ObjectPropertyConditionSet.h: (JSC::ObjectPropertyConditionSet::hash const): (JSC::ObjectPropertyConditionSet::operator==): (JSC::ObjectPropertyConditionSet::operator!=): * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationState::installWatchpoint): (JSC::AccessGenerationState::succeed): (JSC::AccessGenerationState::preserveLiveRegistersToStackForCallWithoutExceptions): (JSC::PolymorphicAccess::addCases): (JSC::PolymorphicAccess::addCase): (JSC::PolymorphicAccess::visitWeak const): (JSC::PolymorphicAccess::regenerate): * bytecode/PolymorphicAccess.h: (JSC::AccessGenerationState::AccessGenerationState): (JSC::AccessGenerationState::preserveLiveRegistersToStackForCallWithoutExceptions): * bytecode/ProxyableAccessCase.cpp: (JSC::ProxyableAccessCase::create): (JSC::ProxyableAccessCase::clone const): * bytecode/ProxyableAccessCase.h: * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::StructureStubInfo): (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::reset): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::offsetOfCodePtr): (JSC::StructureStubInfo::offsetOfSlowPathStartLocation): (JSC::StructureStubInfo::offsetOfSlowOperation): (JSC::StructureStubInfo::patchableJump): Deleted. * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::appendCall): * dfg/DFGSlowPathGenerator.h: (JSC::DFG::slowPathICCall): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetById): (JSC::DFG::SpeculativeJIT::compileGetByIdFlush): (JSC::DFG::SpeculativeJIT::compileDeleteById): (JSC::DFG::SpeculativeJIT::compileDeleteByVal): (JSC::DFG::SpeculativeJIT::compileInById): (JSC::DFG::SpeculativeJIT::compileInByVal): (JSC::DFG::SpeculativeJIT::compileGetPrivateNameByVal): (JSC::DFG::SpeculativeJIT::compileGetPrivateNameById): (JSC::DFG::SpeculativeJIT::compilePutPrivateNameById): (JSC::DFG::SpeculativeJIT::compileCheckPrivateBrand): (JSC::DFG::SpeculativeJIT::compileSetPrivateBrand): (JSC::DFG::SpeculativeJIT::compileInstanceOfForCells): (JSC::DFG::SpeculativeJIT::compileInstanceOf): (JSC::DFG::SpeculativeJIT::compilePutByIdFlush): (JSC::DFG::SpeculativeJIT::compilePutById): (JSC::DFG::SpeculativeJIT::compilePutByIdDirect): (JSC::DFG::SpeculativeJIT::cachedPutById): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): (JSC::DFG::SpeculativeJIT::appendCall): (JSC::DFG::SpeculativeJIT::appendCallSetResult): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis): (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::getPrivateName): (JSC::FTL::DFG::LowerDFGToB3::compilePrivateBrandAccess): (JSC::FTL::DFG::LowerDFGToB3::cachedPutById): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * ftl/FTLSlowPathCall.cpp: (JSC::FTL::SlowPathCallContext::SlowPathCallContext): (JSC::FTL::SlowPathCallContext::keyWithTarget const): (JSC::FTL::SlowPathCallContext::makeCall): * ftl/FTLSlowPathCall.h: (JSC::FTL::callOperation): * ftl/FTLSlowPathCallKey.cpp: (JSC::FTL::SlowPathCallKey::dump const): * ftl/FTLSlowPathCallKey.h: (JSC::FTL::SlowPathCallKey::SlowPathCallKey): (JSC::FTL::SlowPathCallKey::indirectOffset const): (JSC::FTL::SlowPathCallKey::withCallTarget): (JSC::FTL::SlowPathCallKey::operator== const): (JSC::FTL::SlowPathCallKey::hash const): * ftl/FTLThunks.cpp: (JSC::FTL::genericGenerationThunkGenerator): (JSC::FTL::slowPathCallThunkGenerator): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitVirtualCall): * jit/CCallHelpers.cpp: (JSC::CCallHelpers::emitJITCodeOver): * jit/CCallHelpers.h: (JSC::CCallHelpers::ArgCollection::ArgCollection): (JSC::CCallHelpers::ArgCollection::pushRegArg): (JSC::CCallHelpers::ArgCollection::pushExtraRegArg): (JSC::CCallHelpers::ArgCollection::pushNonArg): (JSC::CCallHelpers::ArgCollection::addGPRArg): (JSC::CCallHelpers::ArgCollection::addGPRExtraArg): (JSC::CCallHelpers::ArgCollection::addStackArg): (JSC::CCallHelpers::ArgCollection::addPoke): (JSC::CCallHelpers::calculatePokeOffset): (JSC::CCallHelpers::pokeForArgument): (JSC::CCallHelpers::stackAligned): (JSC::CCallHelpers::marshallArgumentRegister): (JSC::CCallHelpers::setupArgumentsImpl): (JSC::CCallHelpers::pokeArgumentsAligned): (JSC::CCallHelpers::std::is_integral::value): (JSC::CCallHelpers::std::is_pointer::value): (JSC::CCallHelpers::setupArgumentsEntryImpl): (JSC::CCallHelpers::setupArguments): (JSC::CCallHelpers::setupArgumentsForIndirectCall): * jit/GCAwareJITStubRoutine.cpp: (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine): (JSC::GCAwareJITStubRoutine::makeGCAware): (JSC::GCAwareJITStubRoutine::observeZeroRefCount): (JSC::PolymorphicAccessJITStubRoutine::PolymorphicAccessJITStubRoutine): (JSC::PolymorphicAccessJITStubRoutine::observeZeroRefCount): (JSC::PolymorphicAccessJITStubRoutine::computeHash): (JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine): (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler): (JSC::createICJITStubRoutine): (JSC::createJITStubRoutine): Deleted. * jit/GCAwareJITStubRoutine.h: (JSC::GCAwareJITStubRoutine::create): (JSC::PolymorphicAccessJITStubRoutine::cases const): (JSC::PolymorphicAccessJITStubRoutine::weakStructures const): (JSC::PolymorphicAccessJITStubRoutine::hash const): * jit/GPRInfo.h: * jit/JIT.cpp: (JSC::JIT::link): * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::emit_op_iterator_open): (JSC::JIT::emitSlow_op_iterator_open): (JSC::JIT::emit_op_iterator_next): (JSC::JIT::emitSlow_op_iterator_next): * jit/JITCall32_64.cpp: (JSC::JIT::emit_op_iterator_open): (JSC::JIT::emit_op_iterator_next): * jit/JITCode.h: (JSC::JITCode::useDataIC): * jit/JITInlineCacheGenerator.cpp: (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator): (JSC::JITInlineCacheGenerator::finalize): (JSC::JITByIdGenerator::JITByIdGenerator): (JSC::JITByIdGenerator::finalize): (JSC::JITByIdGenerator::generateFastCommon): (JSC::JITGetByIdGenerator::JITGetByIdGenerator): (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator): (JSC::JITPutByIdGenerator::JITPutByIdGenerator): (JSC::JITDelByValGenerator::JITDelByValGenerator): (JSC::JITDelByValGenerator::generateFastPath): (JSC::JITDelByValGenerator::finalize): (JSC::JITDelByIdGenerator::JITDelByIdGenerator): (JSC::JITDelByIdGenerator::generateFastPath): (JSC::JITDelByIdGenerator::finalize): (JSC::JITInByValGenerator::JITInByValGenerator): (JSC::JITInByValGenerator::generateFastPath): (JSC::JITInByValGenerator::finalize): (JSC::JITInByIdGenerator::JITInByIdGenerator): (JSC::JITInstanceOfGenerator::JITInstanceOfGenerator): (JSC::JITInstanceOfGenerator::generateFastPath): (JSC::JITInstanceOfGenerator::finalize): (JSC::JITGetByValGenerator::JITGetByValGenerator): (JSC::JITGetByValGenerator::generateFastPath): (JSC::JITGetByValGenerator::finalize): (JSC::JITPrivateBrandAccessGenerator::JITPrivateBrandAccessGenerator): (JSC::JITPrivateBrandAccessGenerator::generateFastPath): (JSC::JITPrivateBrandAccessGenerator::finalize): * jit/JITInlineCacheGenerator.h: (JSC::JITGetByIdGenerator::JITGetByIdGenerator): Deleted. (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator): Deleted. (JSC::JITPutByIdGenerator::JITPutByIdGenerator): Deleted. (JSC::JITDelByValGenerator::JITDelByValGenerator): Deleted. (JSC::JITDelByValGenerator::slowPathJump const): Deleted. (JSC::JITDelByIdGenerator::JITDelByIdGenerator): Deleted. (JSC::JITDelByIdGenerator::slowPathJump const): Deleted. (JSC::JITInByIdGenerator::JITInByIdGenerator): Deleted. (JSC::JITInstanceOfGenerator::JITInstanceOfGenerator): Deleted. (JSC::JITGetByValGenerator::JITGetByValGenerator): Deleted. (JSC::JITGetByValGenerator::slowPathJump const): Deleted. (JSC::JITPrivateBrandAccessGenerator::JITPrivateBrandAccessGenerator): Deleted. (JSC::JITPrivateBrandAccessGenerator::slowPathJump const): Deleted. * jit/JITInlines.h: (JSC::JIT::emitLoadForArrayMode): (JSC::JIT::appendCallWithExceptionCheck): (JSC::JIT::appendCallWithExceptionCheckSetJSValueResult): (JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::privateCompileHasIndexedProperty): (JSC::JIT::emit_op_has_enumerable_indexed_property): (JSC::JIT::emitSlow_op_has_enumerable_indexed_property): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_instanceof): (JSC::JIT::privateCompileHasIndexedProperty): (JSC::JIT::emit_op_has_enumerable_indexed_property): * jit/JITOperations.cpp: (JSC::JSC_DEFINE_JIT_OPERATION): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::slow_op_get_by_val_prepareCallGenerator): (JSC::JIT::emit_op_get_private_name): (JSC::JIT::emitSlow_op_get_private_name): (JSC::JIT::slow_op_get_private_name_prepareCallGenerator): (JSC::JIT::emit_op_set_private_brand): (JSC::JIT::emitSlow_op_set_private_brand): (JSC::JIT::emit_op_check_private_brand): (JSC::JIT::emitSlow_op_check_private_brand): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::slow_op_put_by_val_prepareCallGenerator): (JSC::JIT::emit_op_put_private_name): (JSC::JIT::emitSlow_op_put_private_name): (JSC::JIT::slow_op_put_private_name_prepareCallGenerator): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emitSlow_op_del_by_id): (JSC::JIT::slow_op_del_by_id_prepareCallGenerator): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emitSlow_op_del_by_val): (JSC::JIT::slow_op_del_by_val_prepareCallGenerator): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::slow_op_get_by_id_prepareCallGenerator): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::slow_op_get_by_id_with_this_prepareCallGenerator): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::slow_op_put_by_id_prepareCallGenerator): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emit_op_in_by_val): (JSC::JIT::emitSlow_op_in_by_val): (JSC::JIT::privateCompilePutByVal): (JSC::JIT::privateCompilePutPrivateNameWithCachedId): (JSC::JIT::privateCompilePutByValWithCachedId): (JSC::JIT::emitDoubleLoad): (JSC::JIT::emitContiguousLoad): (JSC::JIT::emitArrayStorageLoad): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emit_op_get_private_name): (JSC::JIT::emit_op_set_private_brand): (JSC::JIT::emit_op_check_private_brand): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emit_op_in_by_val): * jit/JITStubRoutine.h: * jit/PolymorphicCallStubRoutine.cpp: (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine): * jit/Repatch.cpp: (JSC::readPutICCallTarget): (JSC::repatchSlowPathCall): (JSC::tryCacheGetBy): (JSC::repatchGetBy): (JSC::tryCacheArrayGetByVal): (JSC::repatchArrayGetByVal): (JSC::tryCachePutByID): (JSC::repatchPutByID): (JSC::tryCacheDeleteBy): (JSC::repatchDeleteBy): (JSC::tryCacheInBy): (JSC::repatchInBy): (JSC::tryCacheCheckPrivateBrand): (JSC::repatchCheckPrivateBrand): (JSC::tryCacheSetPrivateBrand): (JSC::repatchSetPrivateBrand): (JSC::tryCacheInstanceOf): (JSC::repatchInstanceOf): (JSC::linkSlowFor): (JSC::linkVirtualFor): (JSC::resetGetBy): (JSC::resetPutByID): (JSC::resetDelBy): (JSC::resetInBy): (JSC::resetInstanceOf): (JSC::resetCheckPrivateBrand): (JSC::resetSetPrivateBrand): (JSC::resetPatchableJump): Deleted. * jit/Repatch.h: * runtime/Options.cpp: (JSC::Options::recomputeDependentOptions): * runtime/OptionsList.h: * runtime/StructureIDTable.h: * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): * runtime/VM.h: 2021-06-08 Robin Morisset Fix speculated type in speculateNeitherDoubleNorHeapBigIntNorString https://bugs.webkit.org/show_bug.cgi?id=226786 Reviewed by Mark Lam. I had forgotten the HeapBigInt part. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString): 2021-06-06 Yusuke Suzuki [JSC] Use ResolvedClosureVar to get brand from scope https://bugs.webkit.org/show_bug.cgi?id=226677 rdar://78802869 Reviewed by Saam Barati. Private brand lookup is doing wrong way to get scope. 1. op_resolve_scope with private name (e.g. #x) 2. then, doing op_get_from_scope with (1)'s scope with different name (e.g. @privateBrand) This is wrong in JSC. We resolve scope at link-time in CodeBlock. So we need to ensure that both op_resolve_scope and op_get_from_scope starts with the current scope-register. As a result, private-brand lookup is broken right now. Let's see the buggy case. class D { #x() {} m() { class C { #yy; #z() { } a() { this.#x(); // <===== This point. } } let c = new C(); c.a(); } } In the above point, we first lookup the scope with #x, and we get the D's class-scope. But our get_from_scope is using privateBrand, and privateBrand property exists too in C's class-scope too since C also has #yy and #z. As a result, CodeBlock linking configures the offset for C's class-scope in get_from_scope. And this offset is different from D's class-scope's privateBrand. Only allowed case for the above usage is ResolvedClosureVar. And generatorification uses it too. In this patch, 1. We ensure that class-scope (with private name) must have @privateBrand and @privateClassBrand with offset 1 and 0. 2. Use ResolvedClosureVar with the above pre-defined offset Since CodeBlock's linking does not resolve the scope for get_from_scope if it is ResolvedClosureVar, we can just perform the desired ResolvedClosureVar lookup with the given scope with the compiled offset. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::instantiateLexicalVariables): (JSC::BytecodeGenerator::pushLexicalScope): (JSC::BytecodeGenerator::pushLexicalScopeInternal): (JSC::BytecodeGenerator::emitCreatePrivateBrand): (JSC::BytecodeGenerator::emitGetPrivateBrand): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::BaseDotNode::emitGetPropertyValue): (JSC::BaseDotNode::emitPutProperty): (JSC::PostfixNode::emitDot): (JSC::PrefixNode::emitDot): (JSC::InNode::emitBytecode): (JSC::BlockNode::emitBytecode): (JSC::ForNode::emitBytecode): (JSC::ForInNode::emitBytecode): (JSC::ForOfNode::emitBytecode): (JSC::SwitchNode::emitBytecode): (JSC::ClassExprNode::emitBytecode): * parser/Parser.cpp: (JSC::Parser::parseClass): * parser/VariableEnvironment.h: 2021-06-07 Alexey Shvayka Unreviewed, reland r276592 with a fix for put() override in prototype chain of a JSProxy https://bugs.webkit.org/show_bug.cgi?id=226185 The API test added in r278366 revealed a flaw in JSObject::definePropertyOnReceiver() that caused putDirectInternal() to be performed on a JSProxy instead of it's target. Remedies that via a type check, ensuring the test and iOS apps are functional. The issue was originally missed because the prototype chain of a global object is immutable and none of the global object's prototypes override put(). OpaqueJSClass::prototype() sets the [[Prototype]] directly, ignoring the IsImmutablePrototypeExoticObject type info flag. Also, excludes an invariant from the original patch that required put() to be overriden when implementing custom [[DefineOwnProperty]]. It is now broken by WindowProperties object. * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::put): * API/tests/testapiScripts/testapi.js: * debugger/DebuggerScope.h: * runtime/ClassInfo.h: * runtime/ClonedArguments.h: * runtime/CustomGetterSetter.cpp: (JSC::callCustomSetter): Deleted. * runtime/CustomGetterSetter.h: * runtime/ErrorConstructor.h: * runtime/ErrorInstance.h: * runtime/GenericArguments.h: * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::put): * runtime/GetterSetter.h: * runtime/JSArray.cpp: (JSC::JSArray::put): * runtime/JSArray.h: * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::put): Deleted. * runtime/JSArrayBufferView.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/JSCell.cpp: (JSC::JSCell::doPutPropertySecurityCheck): Deleted. * runtime/JSCell.h: * runtime/JSFunction.cpp: (JSC::JSFunction::put): * runtime/JSFunction.h: * runtime/JSGenericTypedArrayView.h: * runtime/JSGlobalLexicalEnvironment.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::put): * runtime/JSGlobalObject.h: * runtime/JSLexicalEnvironment.h: * runtime/JSModuleEnvironment.h: * runtime/JSModuleNamespaceObject.h: * runtime/JSObject.cpp: (JSC::JSObject::getOwnPropertySlot): (JSC::JSObject::putInlineSlow): (JSC::definePropertyOnReceiverSlow): (JSC::JSObject::definePropertyOnReceiver): (JSC::JSObject::putInlineFastReplacingStaticPropertyIfNeeded): (JSC::JSObject::doPutPropertySecurityCheck): Deleted. (JSC::JSObject::prototypeChainMayInterceptStoreTo): Deleted. * runtime/JSObject.h: (JSC::JSObject::putByIndexInline): (JSC::JSObject::hasNonReifiedStaticProperties): (JSC::JSObject::getOwnPropertySlot): (JSC::JSObject::putDirect): (JSC::JSObject::doPutPropertySecurityCheck): Deleted. * runtime/JSObjectInlines.h: (JSC::JSObject::canPerformFastPutInlineExcludingProto): (JSC::JSObject::putInlineForJSObject): (JSC::JSObject::putInlineFast): (JSC::JSObject::putDirectInternal): * runtime/JSProxy.h: * runtime/JSTypeInfo.h: (JSC::TypeInfo::hasStaticPropertyTable const): (JSC::TypeInfo::overridesPut const): (JSC::TypeInfo::getOwnPropertySlotMayBeWrongAboutDontEnum const): (JSC::TypeInfo::hasPutPropertySecurityCheck const): Deleted. * runtime/Lookup.h: (JSC::putEntry): Deleted. (JSC::lookupPut): Deleted. * runtime/PropertySlot.h: * runtime/ProxyObject.cpp: (JSC::ProxyObject::put): * runtime/ProxyObject.h: * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::context const): (JSC::PutPropertySlot::isTaintedByOpaqueObject const): (JSC::PutPropertySlot::setIsTaintedByOpaqueObject): * runtime/ReflectObject.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/RegExpObject.cpp: (JSC::RegExpObject::put): * runtime/RegExpObject.h: * runtime/StringObject.cpp: (JSC::StringObject::put): * runtime/StringObject.h: * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::StringPrototype::create): * runtime/StringPrototype.h: * runtime/Structure.cpp: (JSC::Structure::validateFlags): * runtime/Structure.h: (JSC::Structure::hasNonReifiedStaticProperties const): * tools/JSDollarVM.cpp: 2021-06-07 Alexey Shvayka Introduce LexicalScopeFeatures to enable future bytecode optimizations https://bugs.webkit.org/show_bug.cgi?id=224072 Reviewed by Keith Miller. Before this patch, BytecodeGenerator was capable of reasoning about the presence of `with` statements, direct `eval`, or any other code features only within the current executable: ``` with (foo) { (function() { // There was no way to detect WithScope during generation of this function. })(); } ``` This change is required for op_to_this rewrite (#225397): if FunctionCallResolveNode and friends knew there is no WithScope, op_call could be emitted with |this| value of `undefined` as per spec [1], instead of resolved scope. This would: - simplify op_to_this on all tiers, likely resulting in minor perf boost; - save 1 instruction per strict function by removing op_to_this; - remove toThis() from the method table and ~30 its call sites from built-ins; - fix built-in methods that were observably lacking toThis(); - fix __proto__ getter / setter called on global scope; - fix WebIDL accessors called with |this| value of `undefined` and `null`. Also, if ResolveNode knew that unforgeable global properties are not shadowed and there is no `with` statement or sloppy mode direct `eval`, then `undefined` / `Infinity` / `NaN` lookups could be constant-folded. This would save up to 3 bytecode ops per each usage and allow emitting op_is_undefined_or_null for `x === undefined || x === null`. V8 performs this optimization [2]. This patch introduces LexicalScopeFeatures to allow passing such information from Parser to BytecodeGenerator with a minimal code diff. These features are kept separate from CodeFeature to simplify reasoning about feature's scope and because we need to propagate lexical features from parent to child scope. Strict mode is the first use case of LexicalScopeFeatures, which this change carefully fits into existing abstractions without increasing their memory usage even by 1 byte. [1]: https://tc39.es/ecma262/#sec-evaluatecall (step 2) [2]: https://medium.com/@bmeurer/sometimes-undefined-is-defined-7701e1c9eff8 * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::createExecutable): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::recordParse): (JSC::UnlinkedCodeBlock::lexicalScopeFeatures const): * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): (JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets): * bytecode/UnlinkedFunctionExecutable.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitNewClassFieldInitializerFunction): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::lexicalScopeFeatures const): (JSC::BytecodeGenerator::generate): * parser/ASTBuilder.h: (JSC::ASTBuilder::createFunctionMetadata): * parser/Nodes.cpp: (JSC::ScopeNode::ScopeNode): (JSC::ProgramNode::ProgramNode): (JSC::ModuleProgramNode::ModuleProgramNode): (JSC::EvalNode::EvalNode): (JSC::FunctionMetadataNode::FunctionMetadataNode): (JSC::FunctionMetadataNode::operator== const): (JSC::FunctionMetadataNode::dump const): (JSC::FunctionNode::FunctionNode): * parser/Nodes.h: (JSC::ScopeNode::lexicalScopeFeatures): (JSC::ScopeNode::isStrictMode const): * parser/Parser.cpp: (JSC::Parser::parseInner): (JSC::Parser::parseGeneratorFunctionSourceElements): (JSC::Parser::parseAsyncFunctionSourceElements): (JSC::Parser::parseAsyncGeneratorFunctionSourceElements): (JSC::Parser::parseFunctionBody): (JSC::Parser::parseFunctionInfo): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::lexicalScopeFeatures const): (JSC::Scope::setStrictMode): (JSC::Scope::strictMode const): (JSC::Scope::fillParametersForSourceProviderCache): (JSC::Scope::restoreFromSourceProviderCache): (JSC::Parser::pushScope): (JSC::Parser::lexicalScopeFeatures): (JSC::Parser::parse): * parser/ParserModes.h: * parser/SourceProviderCacheItem.h: (JSC::SourceProviderCacheItem::lexicalScopeFeatures const): (JSC::SourceProviderCacheItem::SourceProviderCacheItem): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createFunctionMetadata): * runtime/CachedBytecode.cpp: (JSC::CachedBytecode::addFunctionUpdate): * runtime/CachedTypes.cpp: (JSC::CachedFunctionExecutable::lexicalScopeFeatures const): (JSC::CachedCodeBlock::lexicalScopeFeatures const): (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::CachedFunctionExecutable::encode): (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): (JSC::CachedCodeBlock::encode): (JSC::CachedFunctionExecutable::isInStrictContext const): Deleted. * runtime/CachedTypes.h: * runtime/CodeCache.cpp: (JSC::generateUnlinkedCodeBlockImpl): (JSC::CodeCache::getUnlinkedGlobalCodeBlock): * runtime/ECMAMode.h: (JSC::ECMAMode::fromBool): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::FunctionExecutable): * runtime/GlobalExecutable.h: (JSC::GlobalExecutable::recordParse): (JSC::GlobalExecutable::GlobalExecutable): * runtime/ScriptExecutable.cpp: (JSC::ScriptExecutable::ScriptExecutable): (JSC::ScriptExecutable::newCodeBlockFor): (JSC::ScriptExecutable::recordParse): * runtime/ScriptExecutable.h: (JSC::ScriptExecutable::isInStrictContext const): (JSC::ScriptExecutable::recordParse): 2021-06-07 Commit Queue Unreviewed, reverting r278371 and r278463. https://bugs.webkit.org/show_bug.cgi?id=226749 Break dumpDisassembly in JetStream2 Reverted changesets: "We should drop B3 values while running Air" https://bugs.webkit.org/show_bug.cgi?id=226187 https://trac.webkit.org/changeset/278371 "Drop the FTL(DFG) graph after lowering to B3" https://bugs.webkit.org/show_bug.cgi?id=226556 https://trac.webkit.org/changeset/278463 2021-06-07 Alexey Shvayka Window should behave like a legacy platform object without indexed setter https://bugs.webkit.org/show_bug.cgi?id=225894 Reviewed by Darin Adler. * runtime/TypeError.h: (JSC::typeError): 2021-06-07 Saam Barati Short circuit read modify write nodes emit byte code that uses the wrong locals https://bugs.webkit.org/show_bug.cgi?id=226576 Reviewed by Yusuke Suzuki. It's never a good idea to use the wrong local :-) This patch also adds support for dumping predecessors of basic blocks in the bytecode dump. * bytecode/BytecodeDumper.cpp: (JSC::CodeBlockBytecodeDumper::dumpGraph): * bytecompiler/NodesCodegen.cpp: (JSC::ShortCircuitReadModifyResolveNode::emitBytecode): (JSC::ShortCircuitReadModifyDotNode::emitBytecode): (JSC::ShortCircuitReadModifyBracketNode::emitBytecode): 2021-06-07 Mark Lam Put the Baseline JIT prologue and op_loop_hint code in JIT thunks. https://bugs.webkit.org/show_bug.cgi?id=226375 Reviewed by Keith Miller and Robin Morisset. Baseline JIT prologue code varies in behavior based on several variables. These variables include (1) whether the prologue does any arguments value profiling, (2) whether the prologue is for a constructor, and (3) whether the compiled CodeBlock will have such a large frame that it is greater than the stack reserved zone (aka red zone) which would require additional stack check logic. The pre-existing code would generate specialized code based on these (and other variables). In converting to using thunks for the prologue, we opt not to convert these specializations into runtime checks. Instead, the implementation uses 1 of 8 possible specialized thunks to reduce the need to pass arguments for runtime checks. The only needed argument passed to the prologue thunks is the codeBlock pointer. There are 8 possible thunks because we specialize based on 3 variables: 1. doesProfiling 2. isConstructor 3. hasHugeFrame 2**3 yields 8 permutations of prologue thunk specializations. Similarly, there are also 8 analogous arity fixup prologues that work similarly. The op_loop_hint thunk only takes 1 runtime argument: the bytecode offset. We've tried doing the loop_hint optimization check in the thunk (in order to move both the fast and slow path into the thunk for maximum space savings). However, this seems to have some slight negative impact on benchmark performance. We ended up just keeping the fast path and instead have the slow path call a thunk to do its work. This realizes the bulk of the size savings without the perf impact. This patch also optimizes op_enter a bit more by eliminating the need to pass any arguments to the thunk. The thunk previously took 2 arguments: localsToInit and canBeOptimized. localsToInit is now computed in the thunk at runtime, and canBeOptimized is used as a specialization argument to generate 2 variants of the op_enter thunk: op_enter_canBeOptimized_Generator and op_enter_cannotBeOptimized_Generator, thereby removing the need to pass it as a runtime argument. LinkBuffer size results (from a single run of Speedometer2): BaselineJIT: 93319628 (88.996532 MB) => 83851824 (79.967331 MB) 0.90x ExtraCTIThunk: 5992 (5.851562 KB) => 6984 (6.820312 KB) 1.17x ... Total: 197530008 (188.379295 MB) => 188459444 (179.728931 MB) 0.95x Speedometer2 and JetStream2 results (as measured on an M1 Mac) are neutral. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::untagReturnAddressWithoutExtraValidation): * assembler/MacroAssemblerARM64E.h: (JSC::MacroAssemblerARM64E::untagReturnAddress): (JSC::MacroAssemblerARM64E::untagReturnAddressWithoutExtraValidation): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::branchAdd32): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchAdd32): * bytecode/CodeBlock.h: (JSC::CodeBlock::offsetOfNumCalleeLocals): (JSC::CodeBlock::offsetOfNumVars): (JSC::CodeBlock::offsetOfArgumentValueProfiles): (JSC::CodeBlock::offsetOfShouldAlwaysBeInlined): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitSaveCalleeSavesFor): (JSC::AssemblyHelpers::emitSaveCalleeSavesForBaselineJIT): (JSC::AssemblyHelpers::emitRestoreCalleeSavesForBaselineJIT): * jit/JIT.cpp: (JSC::JIT::compileAndLinkWithoutFinalizing): (JSC::JIT::prologueGenerator): (JSC::JIT::arityFixupPrologueGenerator): (JSC::JIT::privateCompileExceptionHandlers): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::emitNakedNearCall): * jit/JITOpcodes.cpp: (JSC::JIT::op_ret_handlerGenerator): (JSC::JIT::emit_op_enter): (JSC::JIT::op_enter_Generator): (JSC::JIT::op_enter_canBeOptimized_Generator): (JSC::JIT::op_enter_cannotBeOptimized_Generator): (JSC::JIT::emit_op_loop_hint): (JSC::JIT::emitSlow_op_loop_hint): (JSC::JIT::op_loop_hint_Generator): (JSC::JIT::op_enter_handlerGenerator): Deleted. * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_enter): * jit/ThunkGenerators.cpp: (JSC::popThunkStackPreservesAndHandleExceptionGenerator): 2021-06-07 Robin Morisset Optimize compareStrictEq when neither side is a double and at least one is neither a string nor a BigInt https://bugs.webkit.org/show_bug.cgi?id=226676 Reviewed by Filip Pizlo. There is exactly one case where x === y must return false despite x and y being JSValues with the same bits: NaN === NaN There are a few cases where x === y must return true despite x and y being JSValues with potentially different bits: Double === Int32 String === String HeapBigInt === HeapBigInt HeapBigInt === BigInt32 (if they are enabled) If we don't have a double on either side, at least one side has neither a String nor a HeapBigInt, and BigInt32 are disabled, we can clearly ignore all of these pathological cases. This optimization was decided based on looking at DFG graphs of Speedometer2; here is a sample of the compareStrictEq(Untyped, Untyped), courtesy of Phil: Final|Array|String|Bool, Final|Array|String|Bool Array|String|Bool, String|Bool (twice) Array|String|Bool, String|Int32 (once in DFG, once in FTL) ! Array|String|Bool, Array|Bool ! Final|Other, Final|Other ! Int32|Other, Int32 Final|StringIdent, Final|StringIdent (3 times) Final|StringIdent|BoolInt32, StringIdent|BoolInt32 (twice) String|Bool, String|Bool (4 times) DoublePureNaN, String|Bool ! Other, Function|Other ! Final|Other, Final|Function|Other (twice) Final|String|Bool|Other, Final|String|Bool|Other (3 times, two in the FTL) Final|String|Int32, String|Int32 (four times) String|Int32|Bool, Function|String|Int32|Bool (twice) String|DoublePureNaN, String|Bool (twice) ! Final|Bool|Other, Final|Function|Other (four times, twice in FTL) I marked with a ! those for which this optimization should apply. The only slightly interesting part of this patch is DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString where I took care to skip every test whose result we can predict from the abstract interpreter. Results on microbenchmarks: poly-stricteq-not-double 45.5793+-0.5304 ? 46.0306+-0.5621 ? poly-stricteq-not-double-nor-string 45.5829+-0.5750 ^ 16.9089+-0.3070 ^ definitely 2.6958x faster poly-stricteq 49.9719+-0.6450 48.9855+-0.5227 might be 1.0201x faster I also measured the amount of code that we generate in the DFG on JetStream2. The results here are disappointing but still measurable. Before: DFG_fast_CompareStrictEq totalBytes: 468425 count: 10951 avg: 42.774632 DFG_fast_CompareStrictEq totalBytes: 468020 count: 10917 avg: 42.870752 DFG_fast_CompareStrictEq totalBytes: 467424 count: 10888 avg: 42.930198 After: DFG_fast_CompareStrictEq totalBytes: 463946 count: 10917 avg: 42.497573 DFG_fast_CompareStrictEq totalBytes: 474492 count: 11138 avg: 42.601185 DFG_fast_CompareStrictEq totalBytes: 467138 count: 10970 avg: 42.583227 * bytecode/SpeculatedType.h: (JSC::isNeitherDoubleNorHeapBigIntNorStringSpeculation): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue): * dfg/DFGNode.h: (JSC::DFG::Node::shouldSpeculateNeitherDoubleNorHeapBigIntNorString): * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileStrictEq): (JSC::DFG::SpeculativeJIT::compileNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): (JSC::DFG::SpeculativeJIT::speculateNotDouble): (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): (JSC::DFG::checkMayCrashIfInputIsEmpty): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): (JSC::FTL::DFG::LowerDFGToB3::speculate): (JSC::FTL::DFG::LowerDFGToB3::speculateNeitherDoubleNorHeapBigIntNorString): 2021-06-07 Tuomas Karkkainen $vm should have a function for checking if security assertions are enabled similar to $vm.assertEnabled https://bugs.webkit.org/show_bug.cgi?id=226020 Reviewed by Mark Lam. Add method $vm.securityAssertEnabled() which parallels $vm.assertEnabled(), and allows checking at runtime whether the current JavaScriptCore build has security assertions enabled. * tools/JSDollarVM.cpp: 2021-06-04 Chris Dumez FileSystem::readFromFile() should return data as `void*` https://bugs.webkit.org/show_bug.cgi?id=226671 Reviewed by Darin Adler. FileSystem::readFromFile() should return data as `void*` instead of `char*`. This is more flexible and consistent with FileSystem::writeToFile(). * inspector/remote/socket/RemoteInspectorSocket.cpp: (Inspector::RemoteInspector::backendCommands const): 2021-06-04 Devin Rousso Web Inspector: mark recently added protocol commands/events as page-only https://bugs.webkit.org/show_bug.cgi?id=226661 Reviewed by Joseph Pecoraro. * inspector/protocol/CSS.json: * inspector/protocol/Network.json: These commands are not implemented in ITML. By not specifying `"targetTypes": ["page"]` it's implicitly saying that the command/event is supported by ITML since the command/event will fall back to the domain's `"targetTypes"`, which includes ITML. 2021-06-04 Yusuke Suzuki [JSC] Private static method should define privateClassBrandIdentifier in class-scope https://bugs.webkit.org/show_bug.cgi?id=226656 rdar://78313139 Reviewed by Keith Miller. We accidentally made `declaresStaticPrivateMethod` always `false`. This patch fixes that so that we properly define privateClassBrandIdentifier field in the class-scope if static-private-method is defined. * parser/Parser.cpp: (JSC::Parser::parseClass): 2021-06-04 Filip Pizlo Don't emit the NotDouble checks if we're already NotDouble. Rubber stamped by Saam Barati. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateNotDouble): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::speculateNotDouble): 2021-06-04 Mark Lam Placate exception checker validation in objectPrototypeHasOwnProperty. https://bugs.webkit.org/show_bug.cgi?id=226651 rdar://78861296 Reviewed by Keith Miller. * runtime/ObjectPrototype.cpp: (JSC::objectPrototypeHasOwnProperty): 2021-06-03 Filip Pizlo DFG should speculate on CompareStrictEq(@x, @x) https://bugs.webkit.org/show_bug.cgi?id=226621 Reviewed by Mark Lam. Introduces a NotDouble: speculation. We use it to speculate on CompareStrictEq(@x, @x). * bytecode/SpeculatedType.h: (JSC::isNotDoubleSpeculation): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue): * dfg/DFGNode.h: (JSC::DFG::Node::shouldSpeculateNotDouble): * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateNotDouble): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): (JSC::DFG::checkMayCrashIfInputIsEmpty): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::speculate): (JSC::FTL::DFG::LowerDFGToB3::speculateNotDouble): 2021-06-04 Robin Morisset Drop the FTL(DFG) graph after lowering to B3 https://bugs.webkit.org/show_bug.cgi?id=226556 Reviewed by Phil Pizlo. The challenge in this patch was dealing with all of the Patchpoints created by FTLLowerDFGToB3: they get a lambda at that time, which they execute at the end of Air, and many of these lambdas were capturing a pointer to some parts of the DFG graph and reading through it when being executed. In all cases but one it was easily fixed: they were only reading a few bits from a given node, so I just read these bits in FTLLowerDFGToB3, and captured them (by value) instead of the pointer to the node. The exception was compileCallOrConstructVarargsSpread(): its patchpoint generator was walking through the graph, flattening a tree of PhantomSpread/PhantomNewArrayWithSpread/PhantomNewArrayBuffer/PhantomCreateRest, emitting some code along the way. We now do this flattening of the tree in FTLLowerDFGToB3, store just enough information to later emit the required code in a vector, and capture that vector in the lambda (through a move capture, which is allowed since C++14). See `struct VarargsSpreadArgumentToEmit` for the information that we need to store in that vector. I tested this change by completing a full run of JetStream2 with ASAN. I also ran the stress tests with "spread" in their name in Debug mode. * b3/B3SparseCollection.h: (JSC::B3::SparseCollection::clearAll): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::freeDFGIRAfterLowering): * dfg/DFGGraph.h: * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::getPrivateName): (JSC::FTL::DFG::LowerDFGToB3::compilePrivateBrandAccess): (JSC::FTL::DFG::LowerDFGToB3::cachedPutById): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileTailCall): (JSC::FTL::DFG::LowerDFGToB3::VarargsSpreadArgumentToEmit::VarargsSpreadArgumentToEmit): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileCallEval): (JSC::FTL::DFG::LowerDFGToB3::compileInById): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): (JSC::FTL::DFG::LowerDFGToB3::getById): (JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet): (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet): (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet): (JSC::FTL::DFG::LowerDFGToB3::crash): 2021-06-04 Tadeu Zagallo Optimize Function.prototype.toString https://bugs.webkit.org/show_bug.cgi?id=226418 Reviewed by Saam Barati. Add caching to Function.prototype.toString. This is used heavily in Speedometer2, and repeatedly recomputing a string which is a constant is costly. We cache the results of toString in all cases except for bound functions. To make this work for bound functions, we'd need to add a new field they can use for this cache. For other functions, we cache it on the executable (either NativeExecutable or FunctionExecutable). The reason we can't do this on the executable for bound functions is that all bound functions share the same executable, but individual bound functions can have different names. The reason it's valid to cache the results in general is that a function's name field can't be changed from JS code -- it's non-writable. This patch also makes Function.prototype.toString an intrinsic in the DFG/FTL. We emit code on the fast path which reads the cached value if it's present. If not, we call into the slow path, which will compute the cached value for non bound functions, or compute the result for bound functions. I added a new microbenchmark that speeds up by >35x: function-to-string 2197.5952+-30.7118 ^ 59.9861+-2.5550 ^ definitely 36.6350x faster * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::getExecutable): (JSC::DFG::SpeculativeJIT::compileFunctionToString): (JSC::DFG::SpeculativeJIT::compileGetExecutable): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::getExecutable): (JSC::FTL::DFG::LowerDFGToB3::compileGetExecutable): (JSC::FTL::DFG::LowerDFGToB3::compileFunctionToString): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::visitChildrenImpl): (JSC::FunctionExecutable::toStringSlow): * runtime/FunctionExecutable.h: * runtime/FunctionExecutableInlines.h: (JSC::FunctionExecutable::toString): * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::addFunctionProperties): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/JSFunction.cpp: (JSC::JSFunction::toString): * runtime/JSFunction.h: * runtime/JSFunctionInlines.h: (JSC::JSFunction::asStringConcurrently const): * runtime/JSStringInlines.h: * runtime/NativeExecutable.cpp: (JSC::NativeExecutable::toStringSlow): (JSC::NativeExecutable::visitChildrenImpl): * runtime/NativeExecutable.h: 2021-06-04 Michael Catanzaro Fix more GCC warnings https://bugs.webkit.org/show_bug.cgi?id=226193 Reviewed by Adrian Perez de Castro. Fix -Wreturn-type warnings due to missing RELEASE_ASSERT_NOT_REACHED() where expected. * jit/JITPlan.cpp: (JSC::JITPlan::tier const): * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): 2021-06-03 Ross Kirsling [JSC] Implement JIT ICs for InByVal https://bugs.webkit.org/show_bug.cgi?id=226563 Reviewed by Saam Barati. Until now, InByVal has had few optimizations implemented: DFG would attempt to convert string index lookups to InById and int32 lookups to HasIndexedProperty, but there has been no inline caching nor any special handling for symbol lookups. This has become a more urgent problem now, as `#x in obj` (i.e. HasPrivateName / HasPrivateBrand) will need to mimic InByVal's inline caching strategy in order to be deemed performant enough to ship. This patch thus implements inline caching for InByVal at all JIT tiers. The result is a night-and-day difference for symbols, a nice boost for string indices, and no change for int32s: in-by-val-symbol 203.5572+-2.7647 ^ 19.1035+-0.7498 ^ definitely 10.6555x faster in-by-val-string-index 87.0368+-44.7766 45.9971+-32.0007 might be 1.8922x faster in-by-val-int32 110.9904+-1.7109 ? 111.3431+-1.7558 ? * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/CheckPrivateBrandStatus.cpp: (JSC::CheckPrivateBrandStatus::singleIdentifier const): * bytecode/DeleteByStatus.cpp: (JSC::DeleteByStatus::singleIdentifier const): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::singleIdentifier const): * bytecode/ICStatusMap.h: * bytecode/ICStatusUtils.h: (JSC::singleIdentifierForICStatus): * bytecode/InByIdVariant.cpp: (JSC::InByIdVariant::InByIdVariant): (JSC::InByIdVariant::attemptToMerge): (JSC::InByIdVariant::dumpInContext const): * bytecode/InByIdVariant.h: (JSC::InByIdVariant::identifier const): (JSC::InByIdVariant::overlaps): * bytecode/InByStatus.cpp: Renamed from Source/JavaScriptCore/bytecode/InByIdStatus.cpp. (JSC::InByStatus::appendVariant): (JSC::InByStatus::shrinkToFit): (JSC::InByStatus::computeFor): (JSC::InByStatus::computeForStubInfo): (JSC::InByStatus::computeForStubInfoWithoutExitSiteFeedback): (JSC::InByStatus::merge): (JSC::InByStatus::filter): (JSC::InByStatus::markIfCheap): (JSC::InByStatus::finalize): (JSC::InByStatus::singleIdentifier const): (JSC::InByStatus::dump const): * bytecode/InByStatus.h: Renamed from Source/JavaScriptCore/bytecode/InByIdStatus.h. * bytecode/RecordedStatuses.cpp: (JSC::RecordedStatuses::addInByStatus): Renamed from addInByIdStatus. * bytecode/RecordedStatuses.h: * bytecode/SetPrivateBrandStatus.cpp: (JSC::SetPrivateBrandStatus::singleIdentifier const): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::reset): * bytecode/StructureStubInfo.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): (JSC::DFG::AbstractInterpreter::filterICStatus): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleInById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGClobbersExitState.cpp: (JSC::DFG::clobbersExitState): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::addInByVal): * dfg/DFGMayExit.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::hasInByStatus): Renamed from hasInByIdStatus. (JSC::DFG::Node::inByStatus): Renamed from inByIdStatus. * dfg/DFGNodeType.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileInByVal): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGVarargsForwardingPhase.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileInBy): (JSC::FTL::DFG::LowerDFGToB3::compileInById): (JSC::FTL::DFG::LowerDFGToB3::compileInByVal): * jit/ICStats.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): (JSC::JIT::link): * jit/JIT.h: * jit/JITInlineCacheGenerator.cpp: (JSC::JITInByValGenerator::JITInByValGenerator): (JSC::JITInByValGenerator::generateFastPath): (JSC::JITInByValGenerator::finalize): (JSC::JITInByIdGenerator::JITInByIdGenerator): * jit/JITInlineCacheGenerator.h: (JSC::JITDelByIdGenerator::slowPathJump const): (JSC::JITInByValGenerator::JITInByValGenerator): (JSC::JITInByValGenerator::slowPathJump const): * jit/JITOperations.cpp: (JSC::JSC_DEFINE_JIT_OPERATION): * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_in_by_val): (JSC::JIT::emitSlow_op_in_by_val): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_in_by_val): (JSC::JIT::emitSlow_op_in_by_val): * jit/Repatch.cpp: (JSC::tryCacheInBy): Renamed from tryCacheInByID. (JSC::repatchInBy): Renamed from repatchInByID. (JSC::resetInBy): Renamed from resetInByID. * jit/Repatch.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * runtime/CommonSlowPaths.cpp: * runtime/CommonSlowPaths.h: 2021-06-03 Mark Lam Fix an ASSERT in objectPrototypeHasOwnProperty() to account for TerminationException. https://bugs.webkit.org/show_bug.cgi?id=226609 rdar://78465046 Reviewed by Robin Morisset. * runtime/ObjectPrototype.cpp: (JSC::objectPrototypeHasOwnProperty): 2021-06-03 Yusuke Suzuki [JSC] Make $vm's accessor test functions robust against primitive |this| https://bugs.webkit.org/show_bug.cgi?id=226591 Reviewed by Saam Barati. These functions are testing-purpose, and they are not robust against passing primitive as |this|. This patch makes them robust so that we throw an error instead of crash. * tools/JSDollarVM.cpp: 2021-06-03 Commit Queue Unreviewed, reverting r278356. https://bugs.webkit.org/show_bug.cgi?id=226606 "Breaks jsc tests". Reverted changeset: "Convert small JIT pool tests into executable fuzzing" https://bugs.webkit.org/show_bug.cgi?id=226279 https://trac.webkit.org/changeset/278356 2021-06-03 Filip Pizlo DFG should eliminate obvious store barriers https://bugs.webkit.org/show_bug.cgi?id=226604 Reviewed by Mark Lam. This has a couple changes: - PutByOffset doesn't GC! So let's not say that it does. - The store barrier clustering phase is no longer called the store barrier fencing phase in dumps. Small Speedometer2 speed-up. Definite speed-up for Elm. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGStoreBarrierClusteringPhase.cpp: 2021-06-03 Patrick Angle Web Inspector: [Cocoa] `RemoteInspector` won't connect to a new relay if it hasn't yet failed to communicate with a previously connected relay https://bugs.webkit.org/show_bug.cgi?id=226539 Reviewed by Devin Rousso. `RemoteInspector` communicates with a relay daemon running on the same device in order to send updates like new or removed inspectable targets and receive changes to settings like automatic debugging. The relay daemon then communicates with a client that connects for debugging. Only one relay daemon should ever be running at a time, and its lifecycle is managed separately from JavaScriptCore. RemoteInspector holds a RefPtr to its connection to this relay, and only clears this pointer upon a failure to communicate over the XPC connection or a known disconnection. However, it is possible, and in some cases likely (for example the relay restarting from a brief client disconnection and reconnection), that we can be informed of a newly launched relay being available while still thinking we are connected to the old relay, as we have not yet sent a message and triggered a failure in the interim period of time. To correct this we now send a simple message any time `setupXPCConnectionIfNeeded` is called if we have an existing RefPtr to a relay connection in order to verify the connection is still functional. We now also retry to connect to a relay upon failure in order to create a new connection to the current relay. In order to prevent entering a retry loop where every subsequent retry's failure results in another retry forever, a flag to retry connecting is set when a call to setupXPCConnectionIfNeeded is made while we already have a RefPtr to a relay connection. On failure if we are in this special state we will retry once to connect but subsequent failures will not automatically reattempt a connection. * inspector/remote/RemoteInspector.h: * inspector/remote/cocoa/RemoteInspectorCocoa.mm: (Inspector::RemoteInspector::stopInternal): - Clear the retry connection flag when stopping in an orderly fashion. (Inspector::RemoteInspector::setupXPCConnectionIfNeeded): - Set the retry connection flag and send a simple message if we already have a relay connection in order to make sure the connection is either still valid or is torn down properly on failure. (Inspector::RemoteInspector::xpcConnectionFailed): - If the retry flag is set, schedule a retry and clear the retry flag. 2021-06-02 Robin Morisset B3MoveConstants should filter directly on Values, and only create ValueKeys when useful https://bugs.webkit.org/show_bug.cgi?id=226420 Reviewed by Phil Pizlo. I did a few runs of JetStream2 to measure results, the time spent in B3MoveConstants goes from 160-180ms to 100-110ms. The total time spent in B3+Air is in the 6 to 8s range, so this is approximately a 1% speedup. * b3/B3MoveConstants.cpp: 2021-06-02 Robin Morisset Merge B3::StackSlot and Air::StackSlot https://bugs.webkit.org/show_bug.cgi?id=226362 Reviewed by Filip Pizlo. This is a very simple and safe (although small) memory saving, since every B3StackSlot eventually becomes an AirStackSlot with an exact copy of all the same information. Simply dropping the B3StackSlot past that point is tricky, because one of them might be retained by FTLState (and modified by Air). It is much simpler to just use Air::StackSlot throughout. It saves us: - 16 bytes per B3StackSlot (for the structure itself) - another 8 bytes per B3StackSlot (for the pointer in the SparseCollection) - 8 bytes per AirStackSlot (for the pointer to the B3::StackSlot) I also took the opportunity to save an extra 8 bytes per AirStackSlot, by shrinking the bytesize field to a uint16_t (with a RELEASE_ASSERT that we never overflow it) and moving the StackSlotKind in the hole this creates. Total savings: 16 bytes per spill slot and 40 bytes per locked (by B3) slot. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * b3/B3LowerToAir.cpp: * b3/B3Procedure.cpp: (JSC::B3::Procedure::addStackSlot): (JSC::B3::Procedure::dump const): * b3/B3Procedure.h: * b3/B3ProcedureInlines.h: (JSC::B3::Procedure::stackSlots): (JSC::B3::Procedure::stackSlots const): * b3/B3SlotBaseValue.cpp: * b3/B3SlotBaseValue.h: * b3/B3StackSlot.cpp: Removed. * b3/B3StackSlot.h: Removed. * b3/B3Value.cpp: * b3/air/AirCode.cpp: (JSC::B3::Air::Code::addStackSlot): * b3/air/AirCode.h: * b3/air/AirStackSlot.cpp: (JSC::B3::Air::StackSlot::setOffsetFromFP): (JSC::B3::Air::StackSlot::deepDump const): (JSC::B3::Air::StackSlot::StackSlot): * b3/air/AirStackSlot.h: (JSC::B3::Air::StackSlot::ensureSize): * b3/testb3.h: * ftl/FTLCompile.cpp: * ftl/FTLState.h: 2021-06-02 Pablo Saavedra Fix build error with ENABLE_DFG_JIT=OFF https://bugs.webkit.org/show_bug.cgi?id=226550 Reviewed by Mark Lam. * jit/JITPlan.cpp: (JSC::JITPlan::compileInThread): 2021-06-02 Robin Morisset We should drop B3 values while running Air https://bugs.webkit.org/show_bug.cgi?id=226187 Reviewed by Saam Barati. We must keep the following values: - WasmBoundsCheck, to know whether it is Pinned or Maximum, and if it is pinned find its argument. - CCall/Patch/Check/CheckAdd/CheckSub/CheckMul and all of their children, because all of these are lowered to Air::Patchpoint, which needs to know the type of its arguments, and does so by looking at the children of its origin. I intend to fix these in later patches if possible. Finally we must preserve all B3 values in the following cases: - if we dump the disassembly or the Air graph: because otherwise we cannot print the origins - if we are using the sampling profiler, because it relies on PCToCodeOriginMap which we cannot accurately fill without these origins. We must also keep m_tuples alive, as it is used by Patchpoints in Air to understand the types of their arguments. We also don't touch StackSlots (in this patch), because one of them is captured by FTL::State. Also now PCToOriginMap has a Vector with no inline capacity, since it is either quite large (if needed) or empty (otherwise). The performance impact of this is a progression on various RAMification subtests on Mac, but is more mitigated on iPhone7, with various regressions. I suspect these to be noise, and will monitor the performance bots post-landing to make sure of it. * b3/B3LowerToAir.cpp: (JSC::B3::lowerToAir): * b3/B3Procedure.cpp: (JSC::B3::Procedure::freeUnneededB3ValuesAfterLowering): * b3/B3Procedure.h: (JSC::B3::Procedure::releasePCToOriginMap): (JSC::B3::Procedure::setNeedsPCToOriginMap): (JSC::B3::Procedure::needsPCToOriginMap): * b3/B3SparseCollection.h: (JSC::B3::SparseCollection::clearAll): (JSC::B3::SparseCollection::filterAndTransfer): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): * b3/air/AirCode.h: (JSC::B3::Air::Code::shouldPreserveB3Origins const): * b3/air/AirGenerate.cpp: (JSC::B3::Air::generateWithAlreadyAllocatedRegisters): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLState.cpp: (JSC::FTL::State::State): 2021-06-02 Chris Dumez Drop Checked::safeGet() https://bugs.webkit.org/show_bug.cgi?id=226537 Reviewed by Geoffrey Garen. Drop Checked::safeGet() and replace with uses of Checked::operator T() or Checked::value(). safeGet() is a bit akward, having both a return value and an out-parameter. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * runtime/JSArray.cpp: (JSC::JSArray::appendMemcpy): (JSC::JSArray::unshiftCountWithAnyIndexingType): * runtime/JSStringJoiner.cpp: (JSC::JSStringJoiner::joinedLength const): * wasm/WasmFormat.cpp: (JSC::Wasm::Segment::create): * wasm/WasmOperations.cpp: (JSC::Wasm::JSC_DEFINE_JIT_OPERATION): * wasm/WasmTable.cpp: (JSC::Wasm::Table::grow): 2021-06-02 Keith Miller Add globalObject API set property test https://bugs.webkit.org/show_bug.cgi?id=226542 Reviewed by Alexey Shvayka. * API/tests/testapi.cpp: (TestAPI::testJSObjectSetOnGlobalObjectSubclassDefinition): (testCAPIViaCpp): 2021-06-02 Keith Miller Convert small JIT pool tests into executable fuzzing https://bugs.webkit.org/show_bug.cgi?id=226279 Right now, we try to test our engine on a small JIT pool. This isn't a known configuration for any actual ports and causes issues if we run out of JIT memory when we need to compile an OSR exit. Instead of testing such a small pool we should just fuzz each executable allocation that says it can fail. The current fuzzing doesn't do a good job tracking the number of DFG/FTL compiles when allocations fail, so when enabled those tests will just exit early. Also, right now we use a random seed picked by the engine for these tests, which makes it hard to reproduce crashes on the bots. If we see flakiness on the bots we can have the harness pass in a number so it gets logged in the repro command. Reviewed by Michael Saboff. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::numberOfDFGCompiles): * jit/ExecutableAllocationFuzz.cpp: (JSC::doExecutableAllocationFuzzing): * jsc.cpp: (runJSC): 2021-06-02 Chris Dumez Use Checked aliases instead of Checked https://bugs.webkit.org/show_bug.cgi?id=226535 Reviewed by Keith Miller. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * ftl/FTLOperations.cpp: (JSC::FTL::JSC_DEFINE_JIT_OPERATION): * runtime/JSArray.cpp: (JSC::JSArray::appendMemcpy): (JSC::JSArray::unshiftCountWithAnyIndexingType): * runtime/JSStringJoiner.cpp: (JSC::JSStringJoiner::joinedLength const): * runtime/JSStringJoiner.h: * runtime/StringPrototype.cpp: (JSC::jsSpliceSubstringsWithSeparators): * wasm/WasmFormat.cpp: (JSC::Wasm::Segment::create): * wasm/WasmOperations.cpp: (JSC::Wasm::JSC_DEFINE_JIT_OPERATION): * wasm/WasmTable.cpp: (JSC::Wasm::Table::grow): * yarr/YarrInterpreter.cpp: (JSC::Yarr::ByteCompiler::emitDisjunction): * yarr/YarrParser.h: (JSC::Yarr::Parser::consumeNumber): * yarr/YarrPattern.cpp: 2021-06-01 Darin Adler Remove https://bugs.webkit.org/show_bug.cgi?id=226437 Reviewed by Chris Dumez. * : Remove include of . * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: (CppBackendDispatcherHeaderGenerator._generate_secondary_header_includes): Don't generate an include of wtf/Optional.h; including WTFString.h takes care of this anyway. * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py: (CppFrontendDispatcherHeaderGenerator._generate_secondary_header_includes): Ditto. * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: (CppProtocolTypesHeaderGenerator._generate_secondary_header_includes): Ditto. * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: (CppProtocolTypesImplementationGenerator.generate_output): Generate an include of instead of . * inspector/scripts/tests/expected/*: Regenerate. 2021-06-01 Chris Dumez Rename Checked::unsafeGet() to Checked::value() https://bugs.webkit.org/show_bug.cgi?id=226514 Reviewed by Darin Adler. Rename Checked::unsafeGet() to Checked::value(). The "unsafeGet" naming is confusing as this function isn't really unsafe since it will crash if the value has overflowed. Also add an `operator T()` to implicitly convert a Checked to its underlying type without needing to call value(). * b3/B3Const32Value.cpp: (JSC::B3::Const32Value::checkAddConstant const): (JSC::B3::Const32Value::checkSubConstant const): (JSC::B3::Const32Value::checkMulConstant const): * b3/B3Const64Value.cpp: (JSC::B3::Const64Value::checkAddConstant const): (JSC::B3::Const64Value::checkSubConstant const): (JSC::B3::Const64Value::checkMulConstant const): * bytecompiler/BytecodeGenerator.h: (JSC::FinallyContext::numberOfBreaksOrContinues const): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread): (JSC::FTL::DFG::LowerDFGToB3::compileSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread): * ftl/FTLOperations.cpp: (JSC::FTL::JSC_DEFINE_JIT_OPERATION): * heap/Heap.cpp: (JSC::Heap::deprecatedReportExtraMemorySlowCase): (JSC::Heap::extraMemorySize): (JSC::Heap::updateAllocationLimits): (JSC::Heap::reportExtraMemoryVisited): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::propagateExternalMemoryVisitedIfNecessary): * runtime/ArgList.cpp: (JSC::MarkedArgumentBuffer::slowEnsureCapacity): (JSC::MarkedArgumentBuffer::expandCapacity): * runtime/ArrayPrototype.cpp: (JSC::concatAppendOne): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/CommonSlowPaths.cpp: (JSC::JSC_DEFINE_COMMON_SLOW_PATH): * runtime/DirectArguments.h: * runtime/HashMapImpl.h: (JSC::HashMapBuffer::allocationSize): (JSC::HashMapImpl::HashMapImpl): * runtime/HashMapImplInlines.h: (JSC::nextCapacity): (JSC::HashMapImpl::finishCreation): * runtime/JSBigInt.cpp: (JSC::JSBigInt::parseInt): * runtime/JSImmutableButterfly.h: (JSC::JSImmutableButterfly::tryCreate): * runtime/JSLexicalEnvironment.h: (JSC::JSLexicalEnvironment::offsetOfVariable): (JSC::JSLexicalEnvironment::allocationSizeForScopeSize): * runtime/JSObject.h: * runtime/JSPropertyNameEnumerator.cpp: (JSC::JSPropertyNameEnumerator::create): * runtime/JSString.h: * runtime/ScopedArguments.cpp: (JSC::ScopedArguments::createUninitialized): * runtime/StringPrototype.cpp: (JSC::jsSpliceSubstrings): (JSC::jsSpliceSubstringsWithSeparators): * runtime/StructureChain.cpp: (JSC::StructureChain::create): * runtime/VM.h: (JSC::ScratchBuffer::allocationSize): * runtime/WeakMapImpl.h: (JSC::WeakMapBuffer::allocationSize): * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::AirIRGenerator): (JSC::Wasm::AirIRGenerator::emitCallPatchpoint): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): * wasm/WasmInstance.cpp: * wasm/WasmInstance.h: (JSC::Wasm::Instance::allocationSize): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::push): (JSC::Wasm::LLIntGenerator::getDropKeepCount): (JSC::Wasm::LLIntGenerator::walkExpressionStack): (JSC::Wasm::LLIntGenerator::finalize): (JSC::Wasm::LLIntGenerator::callInformationForCaller): (JSC::Wasm::LLIntGenerator::addLoop): (JSC::Wasm::LLIntGenerator::addTopLevel): (JSC::Wasm::LLIntGenerator::addBlock): (JSC::Wasm::LLIntGenerator::addIf): (JSC::Wasm::LLIntGenerator::addElseToUnreachable): * wasm/WasmSignature.h: (JSC::Wasm::Signature::allocatedSize): * wasm/WasmStreamingParser.cpp: (JSC::Wasm::StreamingParser::addBytes): * wasm/WasmTable.cpp: (JSC::Wasm::Table::Table): (JSC::Wasm::Table::grow): (JSC::Wasm::FuncRefTable::FuncRefTable): * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::DisjunctionContext::allocationSize): (JSC::Yarr::Interpreter::ParenthesesDisjunctionContext::allocationSize): (JSC::Yarr::Interpreter::allocParenthesesDisjunctionContext): (JSC::Yarr::ByteCompiler::atomCharacterClass): (JSC::Yarr::ByteCompiler::atomBackReference): (JSC::Yarr::ByteCompiler::atomParentheticalAssertionEnd): (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd): (JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd): (JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd): (JSC::Yarr::ByteCompiler::emitDisjunction): * yarr/YarrInterpreter.h: (JSC::Yarr::ByteTerm::ByteTerm): (JSC::Yarr::ByteTerm::CheckInput): (JSC::Yarr::ByteTerm::UncheckInput): * yarr/YarrJIT.cpp: * yarr/YarrParser.h: (JSC::Yarr::Parser::consumeNumber): * yarr/YarrPattern.cpp: (JSC::Yarr::PatternTerm::dumpQuantifier): 2021-06-01 Adrian Perez de Castro [WPE][GTK] Support building against uClibc https://bugs.webkit.org/show_bug.cgi?id=226244 Reviewed by Michael Catanzaro. * assembler/MacroAssemblerARM64.cpp: (getauxval): Provide a fallback implementation of getauxval() for systems which do not provide , like those using uClibc as their C library. 2021-05-30 Chris Dumez Drop UncheckedCondition / UncheckedLock https://bugs.webkit.org/show_bug.cgi?id=226432 Reviewed by Darin Adler. Drop one remaining use of UncheckedLock in favor of Lock. * jit/JITSafepoint.cpp: * jit/JITWorklistThread.h: 2021-05-30 Darin Adler Remove WTF::Optional synonym for std::optional, using that class template directly instead https://bugs.webkit.org/show_bug.cgi?id=226433 Reviewed by Chris Dumez. * : Let the do-webcore-rename script rename Optional<> to std::optional<>. * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload): Use auto instead of Optional<>. Also use * instead of value() and nest the definition of the local inside an if statement in the case where it's an optional. * inspector/scripts/tests/expected/*: Regenerated these results. 2021-05-29 Chris Dumez Stop using UncheckedLock in JSC::VMInspector https://bugs.webkit.org/show_bug.cgi?id=226427 Reviewed by Mark Lam. Stop using UncheckedLock in JSC::VMInspector, as it is being phased out in favor of Lock, which supports Clang thread safety analysis. * tools/HeapVerifier.cpp: (JSC::HeapVerifier::checkIfRecorded): * tools/SigillCrashAnalyzer.cpp: (JSC::SigillCrashAnalyzer::analyze): * tools/VMInspector.cpp: (JSC::VMInspector::isValidExecutableMemory): (JSC::VMInspector::codeBlockForMachinePC): (JSC::VMInspector::lock): Deleted. * tools/VMInspector.h: (JSC::VMInspector::WTF_RETURNS_LOCK): (JSC::VMInspector::WTF_REQUIRES_LOCK): (JSC::VMInspector::getLock): Deleted. (JSC::VMInspector::iterate): Deleted. 2021-05-29 Chris Dumez Stop using UncheckedLock in JSC::ConcurrentJSLock https://bugs.webkit.org/show_bug.cgi?id=226428 Reviewed by Darin Adler. Stop using UncheckedLock in JSC::ConcurrentJSLock as it is being phased out in favor of Lock, which supports Clang thread safety analysis. * runtime/ConcurrentJSLock.h: (JSC::ConcurrentJSLockerBase::ConcurrentJSLockerBase): * runtime/Structure.cpp: (JSC::Structure::findStructuresAndMapForMaterialization): (JSC::Structure::materializePropertyTable): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::forEachPropertyConcurrently): * yarr/YarrInterpreter.cpp: 2021-05-28 Darin Adler Clients of optional should use has_value instead of relying on hasValue macro https://bugs.webkit.org/show_bug.cgi?id=226395 Reviewed by Chris Dumez. * bytecompiler/NodesCodegen.cpp: (JSC::RegExpNode::emitBytecode): Don't use hasValue. 2021-05-29 Chris Dumez Stop using UncheckedLock in JSC::SamplingProfiler https://bugs.webkit.org/show_bug.cgi?id=226414 Reviewed by Darin Adler. Stop using UncheckedLock in JSC::SamplingProfiler as it is being phased out in favor of Lock, which supports clang thread safety analysis. * heap/Heap.cpp: (JSC::visitSamplingProfiler): * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::InspectorScriptProfilerAgent::startTracking): (Inspector::InspectorScriptProfilerAgent::trackingComplete): (Inspector::InspectorScriptProfilerAgent::stopSamplingWhenDisconnecting): * runtime/JSGlobalObject.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::createThreadIfNecessary): (JSC::SamplingProfiler::timerLoop): (JSC::SamplingProfiler::takeSample): (JSC::SamplingProfiler::processUnverifiedStackTraces): (JSC::SamplingProfiler::start): (JSC::SamplingProfiler::startWithLock): (JSC::SamplingProfiler::pause): (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThreadWithLock): (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread): (JSC::SamplingProfiler::noticeJSLockAcquisition): (JSC::SamplingProfiler::noticeVMEntry): (JSC::SamplingProfiler::clearData): (JSC::SamplingProfiler::releaseStackTraces): (JSC::SamplingProfiler::stackTracesAsJSON): (JSC::SamplingProfiler::reportTopFunctions): (JSC::SamplingProfiler::reportTopBytecodes): * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::WTF_RETURNS_LOCK): (JSC::SamplingProfiler::WTF_REQUIRES_LOCK): 2021-05-29 Chris Dumez Stop using UncheckedLock in JSC::dumpJITMemory() https://bugs.webkit.org/show_bug.cgi?id=226413 Reviewed by Darin Adler. Stop using UncheckedLock in JSC::dumpJITMemory() as it is being phased out in favor of Lock, which supports Clang thread safety analysis. * jit/ExecutableAllocator.cpp: (JSC::dumpJITMemory): 2021-05-29 Chris Dumez Stop using UncheckedLock in JSC::WasmCalleeRegistry https://bugs.webkit.org/show_bug.cgi?id=226412 Reviewed by Darin Adler. Stop using UncheckedLock in JSC::WasmCalleeRegistry, as it is being phased out in favor of Lock, which supports Clang thread safety analysis. * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::FrameWalker): (JSC::FrameWalker::recordJITFrame): (JSC::CFrameWalker::CFrameWalker): (JSC::SamplingProfiler::takeSample): * wasm/WasmCalleeRegistry.h: (JSC::Wasm::CalleeRegistry::WTF_RETURNS_LOCK): (JSC::Wasm::CalleeRegistry::WTF_REQUIRES_LOCK): (JSC::Wasm::CalleeRegistry::getLock): Deleted. (JSC::Wasm::CalleeRegistry::isValidCallee): Deleted. * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): 2021-05-29 Mark Lam VM::isTerminationException() should only be run on a non-null exception value. https://bugs.webkit.org/show_bug.cgi?id=226417 rdar://78646170 Reviewed by Filip Pizlo. * jsc.cpp: (runInteractive): 2021-05-29 Adrian Perez de Castro Non-unified build fixes, late-ish May 2021 edition redux https://bugs.webkit.org/show_bug.cgi?id=226401 Unreviewed non-unified build fixes. * jit/JITSizeStatistics.cpp: Add missing LinkBuffer.h header. * jit/JITSizeStatistics.h: Add missing CCallHelpers.h and wtf/text/WTFString.h headers; remove unneeded CCallHelpers forward declaration. 2021-05-28 Chris Dumez Stop using UncheckedLock in WTF::MetaAllocator https://bugs.webkit.org/show_bug.cgi?id=226396 Reviewed by Darin Adler. Stop using UncheckedLock in WTF::MetaAllocator, as it is being phased out in favor on Lock, which supports Clang thread safety analysis. * jit/ExecutableAllocator.cpp: (JSC::ExecutableAllocator::getLock const): * jit/ExecutableAllocator.h: (JSC::ExecutableAllocatorBase::WTF_RETURNS_LOCK): * tools/VMInspector.cpp: (JSC::VMInspector::isValidExecutableMemory): 2021-05-28 Chris Dumez Stop using UncheckedLock in JSDOMGlobalObject https://bugs.webkit.org/show_bug.cgi?id=226281 Reviewed by Darin Adler. Drop JSC::lockDuringMarking() and its now empty header given that it does conditional locking and it is not compatible with Clang thread safety analysis. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/UnlinkedCodeBlock.h: * heap/LockDuringMarking.h: Removed. 2021-05-28 Saam Barati Add the ability to dump statistics about cumulative counts and code sizes of Baseline JIT opcodes and DFG nodes https://bugs.webkit.org/show_bug.cgi?id=226200 Reviewed by Robin Morisset. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * dfg/DFGSlowPathGenerator.h: (JSC::DFG::SlowPathGenerator::currentNode const): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::runSlowPathGenerators): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): (JSC::JIT::compileAndLinkWithoutFinalizing): * jit/JITSizeStatistics.cpp: Added. (JSC::JITSizeStatistics::markStart): (JSC::JITSizeStatistics::markEnd): (JSC::JITSizeStatistics::dump const): * jit/JITSizeStatistics.h: Added. (JSC::JITSizeStatistics::reset): * jsc.cpp: (runJSC): * runtime/OptionsList.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * tools/JSDollarVM.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::JSDollarVM::finishCreation): 2021-05-28 Saam Barati Don't sink arguments past the context of the inline call frame they were created in https://bugs.webkit.org/show_bug.cgi?id=226363 Reviewed by Filip Pizlo. DFG OSR exit isn't set up to allow materializing phantom arguments objects when the inline call frame is no longer present in the exit metadata. There may be multiple reasons for this, but there's at least one I discovered: We don't analyze any locals when reconstructing the variable event stream if that local is past the extent of the inline call frame. This patch makes it so we treat it as an escape if between the definition and the last use of a sink candidate (either via an IR use or bytecode liveness) there is an exit to a place in the graph where the inline call frame of the definition is no longer present. * dfg/DFGVarargsForwardingPhase.cpp: 2021-05-28 Stephan Szabo Regenerate builtins generator expectations after optional changes https://bugs.webkit.org/show_bug.cgi?id=226381 Reviewed by Chris Dumez. * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result: * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: 2021-05-28 Mark Lam The jsc shell should not continue executing after a termination has been received. https://bugs.webkit.org/show_bug.cgi?id=226368 rdar://78013374 Reviewed by Saam Barati. This patch makes the jsc shell forbid execution in all the places that it has caught and seen a TerminationException. * jsc.cpp: (JSC_DEFINE_HOST_FUNCTION): (checkException): (runWithOptions): (runInteractive): 2021-05-27 Robin Morisset AirAllocateStackByGraphColoring should use the optimized interference graphs from AirAllocateRegistersByGraphColoring https://bugs.webkit.org/show_bug.cgi?id=226258 Reviewed by Phil Pizlo. The main change in this patch is that AirAllocateStackByGraphColoring is now using the optimized datastructures in wtf/InterferenceGraph.h. This required templating most of it over the interference graph used (Small/Large/Huge), but I tried keeping some common parts out of the templated class to minimize the impact on compile times and binary size. A consequence of that change is that coalescableMoves and remappedStackSlots now store indices instead of direct pointers to StackSlots, resulting in a memory reduction of about 3x as well. Another consequence is that I had to slightly alter the way that coalescing works: instead of carefully removing the interference edges of the killed slot, we simply use mayClear() which is not guaranteed to remove anything. I believe that this is sound, because every subsequent access to m_interference checks whether a slot has been coalesced first, so dropping these edges is purely a memory saving, but has no logical effect. The new code was tested in a few ways: - running on JetStream2 with asan - running on JetStream2 with TEST_OPTIMIZED_INTERFERENCE_GRAPH - running on JetStream2 and logging the frame sizes at the end of this phase, and comparing to the results of doing the same on ToT (same average frame size) The two functions where this code had the largest memory footprint in JetStream2 were both in tsf-wasm. One has 751 stack slots, and had an interference graph of 2.1MB and a coalescableMoves vector of 440kB The other has 673 stack slots, and had an interference graph of 1.9MB and a coalescableMoves vector of 421kB. With this patch, they respectively use 79kB+146kB and 67kB+140kB The effect on the rest of JetStream2 is less likely to matter as few functions used more than a few dozens of kB in this phase, but in percentages are just as huge. More importantly (and the reason I wrote this patch in the first place), I checked mruby-wasm.aotoki.dev which with a few other pages forced us to lower Options::maximumTmpsForGraphColoring because of jetsams. It has two massive functions that reach this phase if I increase Options::maximumTmpsForGraphColoring: - about 6k stack slots -> 215MB + 6MB (interference graph + coalescableMoves) - about 9k stack slots -> 395MB + 4MB After this patch, they respectively use 4.5MB+2MB and 9MB+1.5MB, or roughly a 40x improvement. Combined with the recent improvements to the register allocator, I hope to be able to increase Options::maximumTmpsForGraphColoring soon (in a different patch for easier bisection if either cause a perf regression). This would be helpful, since its lowering cratered our performance on some other wasm application by 8x. In terms of compile times, this patch lowered the time spent in AllocateStackByGraphColoring over the course of a run of JetStream2 from roughly 350ms to roughly 270ms. This is almost certainly negligible, but at least it guarantees that it did not regress. * b3/air/AirAllocateRegistersByGraphColoring.cpp: * b3/air/AirAllocateStackByGraphColoring.cpp: (JSC::B3::Air::allocateStackByGraphColoring): 2021-05-27 Darin Adler Next step toward using std::optional directly instead of through WTF::Optional typedef https://bugs.webkit.org/show_bug.cgi?id=226280 Reviewed by Chris Dumez. * : Accept the renaming done by do-webcore-rename. * yarr/YarrSyntaxChecker.cpp: Since the style checker complained about this file, tweaked style to make it happy after the renaming done by do-webcore-rename, and also hand-updated Optional to std::optional as long as we were touching it. 2021-05-27 Adrian Perez de Castro Non-unified build fixes, late May 2021 edition https://bugs.webkit.org/show_bug.cgi?id=226322 Unreviewed non-unified build fixes. * jit/JITPlan.cpp: Add missing HeapInlines.h and VMInlines.h headers. * jit/JITWorklist.cpp: Add missing HeapInlines.h and SlotVisitorInlines.h headers, remove SlotVisitor.h which is now unneeded. * jit/JITWorklistThread.cpp: Add missing HeapInlines.h header. 2021-05-27 Daniel Kolesa [JSC] Fix crash on 32-bit big endian systems. https://bugs.webkit.org/show_bug.cgi?id=226264 Reviewed by Caio Araujo Neponoceno de Lima. This is an instance where properly offsetting was missed since the issue was not present in 2.30 series and therefore not fixed by r273104. * llint/LowLevelInterpreter32_64.asm: 2021-05-26 Chris Dumez Leverage the new Vector(const T*, size_t) constructor https://bugs.webkit.org/show_bug.cgi?id=226304 Reviewed by Darin Adler. Leverage the new Vector(const T*, size_t) constructor in existing code. * wasm/WasmStreamingParser.cpp: (JSC::Wasm::StreamingParser::consume): 2021-05-26 Tadeu Zagallo REGRESSION: ASSERTION FAILED: !isCompilationThread() in JSC::Profiler::Database::addCompilation() https://bugs.webkit.org/show_bug.cgi?id=226302 Reviewed by Saam Barati. We started linking the JIT code in the compiler thread, which now triggers this assertion. The assertion was introduce before a lock was held to modify the data structures in the profiler database, but it's safe to remove it now. * profiler/ProfilerDatabase.cpp: (JSC::Profiler::Database::addCompilation): 2021-05-26 Chris Dumez Use UncheckedLock even less in JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=226278 Reviewed by Darin Adler. Use UncheckedLock even less in JavaScriptCore as it is being phased out in favor of Lock, which supports Clang thread safety analysis. * heap/BlockDirectory.h: (JSC::BlockDirectory::WTF_RETURNS_LOCK): * heap/CodeBlockSet.h: (JSC::CodeBlockSet::WTF_RETURNS_LOCK): * heap/Heap.h: * heap/MarkedSpace.h: (JSC::MarkedSpace::directoryLock): * heap/MarkingConstraintSolver.h: * heap/SlotVisitor.cpp: (JSC::SlotVisitor::donateKnownParallel): * heap/SlotVisitor.h: * jit/JITWorklist.cpp: * jit/JITWorklist.h: * jsc.cpp: * profiler/ProfilerDatabase.h: * runtime/DeferredWorkTimer.h: * runtime/VMTraps.cpp: (JSC::VMTraps::invalidateCodeBlocksOnStack): * runtime/VMTraps.h: * tools/FunctionOverrides.cpp: (JSC::FunctionOverrides::FunctionOverrides): (JSC::FunctionOverrides::reinstallOverrides): (JSC::FunctionOverrides::parseOverridesInFile): * tools/FunctionOverrides.h: (JSC::FunctionOverrides::WTF_REQUIRES_LOCK): * tools/VMInspector.cpp: (JSC::ensureIsSafeToLock): (JSC::VMInspector::codeBlockForMachinePC): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::work): (JSC::Wasm::BBQPlan::compileFunction): (JSC::Wasm::BBQPlan::didCompleteCompilation): * wasm/WasmBBQPlan.h: * wasm/WasmEntryPlan.cpp: (JSC::Wasm::EntryPlan::parseAndValidateModule): (JSC::Wasm::EntryPlan::prepare): (JSC::Wasm::EntryPlan::ThreadCountHolder::~ThreadCountHolder): (JSC::Wasm::EntryPlan::complete): * wasm/WasmEntryPlan.h: (JSC::Wasm::EntryPlan::tryReserveCapacity): * wasm/WasmLLIntPlan.cpp: (JSC::Wasm::LLIntPlan::compileFunction): (JSC::Wasm::LLIntPlan::didCompleteCompilation): (JSC::Wasm::LLIntPlan::completeInStreaming): (JSC::Wasm::LLIntPlan::didFailInStreaming): * wasm/WasmLLIntPlan.h: * wasm/WasmOMGForOSREntryPlan.cpp: (JSC::Wasm::OMGForOSREntryPlan::work): * wasm/WasmOMGForOSREntryPlan.h: * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/WasmOMGPlan.h: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::runCompletionTasks): (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast): (JSC::Wasm::Plan::fail): * wasm/WasmPlan.h: * wasm/WasmStreamingCompiler.cpp: (JSC::Wasm::StreamingCompiler::didCompileFunction): (JSC::Wasm::StreamingCompiler::completeIfNecessary): (JSC::Wasm::StreamingCompiler::didComplete): (JSC::Wasm::StreamingCompiler::finalize): * wasm/WasmStreamingCompiler.h: * wasm/WasmStreamingPlan.cpp: (JSC::Wasm::StreamingPlan::work): * wasm/WasmStreamingPlan.h: * wasm/WasmThunks.h: 2021-05-26 Chris Dumez Stop using UncheckedLock in WTF::AutomaticThread https://bugs.webkit.org/show_bug.cgi?id=226255 Reviewed by Keith Miller. Some code in JSC had to be ported from UncheckedLock to Lock as a result of WTF::AutomaticThread using the Lock type. * dfg/DFGWorklist.cpp: (JSC::DFG::Worklist::Worklist): * dfg/DFGWorklist.h: * heap/Heap.cpp: (JSC::Heap::Heap): * heap/Heap.h: * jit/JITWorklist.cpp: (JSC::JITWorklist::JITWorklist): * jit/JITWorklist.h: * runtime/VMTraps.cpp: (JSC::VMTraps::VMTraps): * runtime/VMTraps.h: * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::Worklist): * wasm/WasmWorklist.h: 2021-05-26 Tadeu Zagallo Merge all the JIT worklists into a shared worklist https://bugs.webkit.org/show_bug.cgi?id=226207 Reviewed by Saam Barati. Delete the DFG and FTL worklists and refactor JITWorklist to handle the compilation for all tiers. This reduces the total number of compiler threads while allowing each tier to use more threads whenever necessary. The default configuration is for the worklist to have 3 threads, baseline can use up to all 3 threads and DFG and FTL follow the previous limits set through JSC::Options. Right now, the worklist will only do work on upper tiers when all lower tiers have no pending tasks or have exceeded the maximum number of concurrent compilations. i.e. by default we only DFG compile when there are no baseline tasks in the queue and we only FTL compile when we either have no DFG tasks in the queue OR there are already 2 DFG compilations in progress. * API/JSVirtualMachine.mm: (+[JSVirtualMachine setNumberOfDFGCompilerThreads:]): (+[JSVirtualMachine setNumberOfFTLCompilerThreads:]): * API/tests/testapi.mm: (runJITThreadLimitTests): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::checkIfOptimizationThresholdReached): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCommon.h: (JSC::DFG::verboseCompilationEnabled): (JSC::DFG::logCompilationChanges): (JSC::DFG::shouldDumpGraphAtEachPhase): (JSC::DFG::shouldDumpDisassembly): * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): (JSC::DFG::compile): * dfg/DFGDriver.h: * dfg/DFGGraph.h: * dfg/DFGGraphSafepoint.h: * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::OSRAvailabilityAnalysisPhase::run): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGOperations.cpp: (JSC::DFG::triggerFTLReplacementCompile): (JSC::DFG::tierUpCommon): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::Plan): (JSC::DFG::Plan::codeSize const): (JSC::DFG::Plan::finalizeInGC): (JSC::DFG::Plan::notifyReady): (JSC::DFG::Plan::cancel): (JSC::DFG::Plan::compileInThreadImpl): (JSC::DFG::Plan::finalize): (JSC::DFG::Plan::iterateCodeBlocksForGC): (JSC::DFG::Plan::checkLivenessAndVisitChildren): (JSC::DFG::Plan::isKnownToBeLiveDuringGC): (JSC::DFG::Plan::isKnownToBeLiveAfterGC): * dfg/DFGPlan.h: * dfg/DFGPlanInlines.h: Removed. * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): * dfg/DFGWorklist.cpp: Removed. * dfg/DFGWorklist.h: Removed. * dfg/DFGWorklistInlines.h: Removed. * ftl/FTLCompile.h: * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::buildExitArguments): * ftl/FTLState.cpp: (JSC::FTL::State::State): * ftl/FTLState.h: (JSC::FTL::verboseCompilationEnabled): (JSC::FTL::shouldDumpDisassembly): * heap/Heap.cpp: (JSC::Heap::completeAllJITPlans): (JSC::Heap::iterateExecutingAndCompilingCodeBlocks): (JSC::Heap::removeDeadCompilerWorklistEntries): (JSC::Heap::stopThePeriphery): (JSC::Heap::suspendCompilerThreads): (JSC::Heap::resumeCompilerThreads): (JSC::Heap::addCoreConstraints): * heap/Heap.h: * heap/RootMarkReason.h: * jit/JIT.cpp: (JSC::JIT::compileAndLinkWithoutFinalizing): (JSC::JIT::codeSize const): (JSC::JIT::compileTimeStats): * jit/JIT.h: * jit/JITBaselinePlan.cpp: Copied from Source/JavaScriptCore/ftl/FTLState.cpp. (JSC::JITBaselinePlan::JITBaselinePlan): (JSC::JITBaselinePlan::compileInThreadImpl): (JSC::JITBaselinePlan::codeSize const): (JSC::JITBaselinePlan::finalize): * jit/JITBaselinePlan.h: Copied from Source/JavaScriptCore/dfg/DFGScannable.h. * jit/JITCompilationKey.cpp: Renamed from Source/JavaScriptCore/dfg/DFGCompilationKey.cpp. (JSC::JITCompilationKey::dump const): * jit/JITCompilationKey.h: Renamed from Source/JavaScriptCore/dfg/DFGCompilationKey.h. (JSC::JITCompilationKey::JITCompilationKey): (JSC::JITCompilationKey::operator! const): (JSC::JITCompilationKey::isHashTableDeletedValue const): (JSC::JITCompilationKey::mode const): (JSC::JITCompilationKey::operator== const): (JSC::JITCompilationKey::hash const): (JSC::JITCompilationKeyHash::hash): (JSC::JITCompilationKeyHash::equal): * jit/JITCompilationMode.cpp: Renamed from Source/JavaScriptCore/dfg/DFGCompilationMode.cpp. (WTF::printInternal): * jit/JITCompilationMode.h: Renamed from Source/JavaScriptCore/dfg/DFGCompilationMode.h. (JSC::isFTL): * jit/JITOperations.cpp: (JSC::JSC_DEFINE_JIT_OPERATION): * jit/JITPlan.cpp: Added. (JSC::JITPlan::JITPlan): (JSC::JITPlan::cancel): (JSC::JITPlan::notifyCompiling): (JSC::JITPlan::notifyReady): (JSC::JITPlan::tier const): (JSC::JITPlan::key): (JSC::JITPlan::isKnownToBeLiveAfterGC): (JSC::JITPlan::isKnownToBeLiveDuringGC): (JSC::JITPlan::iterateCodeBlocksForGC): (JSC::JITPlan::checkLivenessAndVisitChildren): (JSC::JITPlan::computeCompileTimes const): (JSC::JITPlan::reportCompileTimes const): (JSC::JITPlan::compileInThread): * jit/JITPlan.h: Added. (JSC::JITPlan::~JITPlan): (JSC::JITPlan::vm const): (JSC::JITPlan::codeBlock const): (JSC::JITPlan::thread const): (JSC::JITPlan::mode const): (JSC::JITPlan::stage const): (JSC::JITPlan::isFTL const): (JSC::JITPlan::finalizeInGC): * jit/JITPlanStage.h: Renamed from Source/JavaScriptCore/dfg/DFGThreadData.cpp. * jit/JITSafepoint.cpp: Renamed from Source/JavaScriptCore/dfg/DFGSafepoint.cpp. (JSC::Safepoint::Safepoint): (JSC::Safepoint::~Safepoint): (JSC::Safepoint::begin): (JSC::Safepoint::cancel): * jit/JITSafepoint.h: Renamed from Source/JavaScriptCore/dfg/DFGSafepoint.h. * jit/JITScannable.h: Copied from Source/JavaScriptCore/dfg/DFGScannable.h. * jit/JITWorklist.cpp: (JSC::JITWorklist::JITWorklist): (JSC::JITWorklist::~JITWorklist): (JSC::JITWorklist::existingGlobalWorklistOrNull): (JSC::JITWorklist::ensureGlobalWorklist): (JSC::JITWorklist::enqueue): (JSC::JITWorklist::queueLength const): (JSC::JITWorklist::suspendAllThreads): (JSC::JITWorklist::resumeAllThreads): (JSC::JITWorklist::compilationState): (JSC::JITWorklist::completeAllReadyPlansForVM): (JSC::JITWorklist::waitUntilAllPlansForVMAreReady): (JSC::JITWorklist::completeAllPlansForVM): (JSC::JITWorklist::cancelAllPlansForVM): (JSC::JITWorklist::removeDeadPlans): (JSC::JITWorklist::setMaximumNumberOfConcurrentDFGCompilations): (JSC::JITWorklist::setMaximumNumberOfConcurrentFTLCompilations): (JSC::JITWorklist::visitWeakReferences): (JSC::JITWorklist::dump const): (JSC::JITWorklist::removeAllReadyPlansForVM): (JSC::JITWorklist::removeMatchingPlansForVM): * jit/JITWorklist.h: (JSC::JITWorklist::static_cast): * jit/JITWorklistInlines.h: Renamed from Source/JavaScriptCore/dfg/DFGScannable.h. (JSC::JITWorklist::iterateCodeBlocksForGC): * jit/JITWorklistThread.cpp: Added. (JSC::JITWorklistThread::JITWorklistThread): (JSC::JITWorklistThread::name const): (JSC::JITWorklistThread::poll): (JSC::JITWorklistThread::work): (JSC::JITWorklistThread::threadDidStart): (JSC::JITWorklistThread::threadIsStopping): * jit/JITWorklistThread.h: Renamed from Source/JavaScriptCore/dfg/DFGThreadData.h. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): * runtime/OptionsList.h: * runtime/VM.cpp: (JSC::VM::~VM): 2021-05-25 Fujii Hironori Clang can't compile Optional since r278035 because GPRTemporary has non-const copy constructor https://bugs.webkit.org/show_bug.cgi?id=226251 Reviewed by Chris Dumez. WinCairo clang-cl builds reported a compilation error since r278035. > include\optional(95,5): error: the parameter for this explicitly-defaulted copy constructor is const, but a member or base requires it to be non-const * dfg/DFGSpeculativeJIT.h: Deleted the const copy ctor instead of the non-const copy ctor. 2021-05-25 Chris Dumez Use UncheckedLock less in JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=226212 Reviewed by Saam Barati. Use UncheckedLock less in JavaScriptCore as it is being phased out in favor of Lock, which enables Clang thread safety analysis. * assembler/testmasm.cpp: * dfg/DFGCommon.cpp: * dynbench.cpp: * heap/Heap.cpp: * heap/Heap.h: * inspector/remote/socket/RemoteInspectorSocketEndpoint.h: * runtime/JSLock.cpp: * runtime/JSLock.h: * runtime/VM.h: 2021-05-25 Devin Rousso [Modern Media Controls] REGRESSION(r254389) media controls needs the full list of language preferences for ordering tracks https://bugs.webkit.org/show_bug.cgi?id=226038 Reviewed by Myles C. Maxfield and Eric Carlson. Media controls need access to the full list of language preferences in order to properly sort/order the list of tracks in the controls UI. For example, if a `