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#