2022-01-25 Yusuke Suzuki [JSC] Wasm module import should be done in sync when WebAssembly.instantiate gets module https://bugs.webkit.org/show_bug.cgi?id=235506 Reviewed by Saam Barati. According to the spec, module imports need to be done synchronously when WebAssembly.instantiate is called with a wasm module[1]. To align our implementation to this behavior, we split WebAssemblyModuleRecord::initializeImportsAndExports into WebAssemblyModuleRecord::initializeImports and WebAssemblyModuleRecord::initializeExports. The former does not require CalleeGroups so we can execute before compiling CalleeGroups. [1]: https://webassembly.github.io/spec/js-api/#asynchronously-instantiate-a-webassembly-module * runtime/AbstractModuleRecord.cpp: (JSC::AbstractModuleRecord::evaluate): * wasm/WasmInstance.h: (JSC::Wasm::Instance::setOwner): (JSC::Wasm::Instance::finalizeCreation): Deleted. * wasm/WasmModuleInformation.h: (JSC::Wasm::ModuleInformation::hasMemoryImport const): * wasm/js/JSWebAssembly.cpp: (JSC::instantiate): (JSC::resolve): Deleted. * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): (JSC::JSWebAssemblyInstance::initializeImports): (JSC::JSWebAssemblyInstance::finalizeCreation): * wasm/js/JSWebAssemblyInstance.h: * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::initializeImports): (JSC::WebAssemblyModuleRecord::initializeExports): (JSC::WebAssemblyModuleRecord::initializeImportsAndExports): Deleted. * wasm/js/WebAssemblyModuleRecord.h: 2022-01-24 Mark Lam Rename Vector and FixedVector::findMatching to findIf to match stl naming. https://bugs.webkit.org/show_bug.cgi?id=234864 rdar://87424746 Reviewed by Yusuke Suzuki. * bytecompiler/NodesCodegen.cpp: (JSC::ArrayPatternNode::emitDirectBinding): 2022-01-24 Yusuke Suzuki [JSC] Enable Array#groupBy and Array#groupByToMap https://bugs.webkit.org/show_bug.cgi?id=235549 Reviewed by Ross Kirsling. * runtime/OptionsList.h: 2022-01-24 Cameron McCormack Remove VM::stringCache https://bugs.webkit.org/show_bug.cgi?id=235536 Reviewed by Sam Weinig. We consult VM::stringCache when creating a JSString, but since bug 142115 we never insert anything into it. Removing this results in almost-significant improvements in the VueJS, Vanilla-ES2015, and jQuery sub-tests of Speedometer 2 (of 0.5-2%, 0.03 <= p <= 0.05), and an almost significant 0.2% improvement in the overall score (p = 0.06). * runtime/JSString.cpp: (JSC::jsStringWithCacheSlowCase): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2022-01-24 Diego Pino Garcia Unreviewed, fix non-unified build after r288458 * runtime/DeferredWorkTimer.h: 2022-01-24 Patrick Angle Web Inspector: [Flexbox] Add instrumentation/protocol bits for flex layout containers https://bugs.webkit.org/show_bug.cgi?id=235454 Reviewed by Devin Rousso. * inspector/protocol/CSS.json: 2022-01-24 Mikhail R. Gadelha [JSC][32bit] Fix regexp crash on ARMv7 https://bugs.webkit.org/show_bug.cgi?id=234476 Reviewed by Yusuke Suzuki. This patch fixes several regexp crashes on ARMv7 due to an incorrect offset to retrieve the 5th argument from the stack: in ARMv7, only 4 arguments are passed via registers r0-r3i, and any other argument is placed on the stack, however, YarrJIT was trying to get the 5th arg from a fixed offset, so because the generateEnter() method pushed register into the stack, the offset was wrong. This patch fixes how the offset is calculated for MIPS and ARMv7. This patch also introduces some small changes: 1. Added static_asserts that the YarrJIT calls do indeed have 5 arguments and that the 5th argument has the type that we expect (MatchingContextHolder*). 2. Removed an unnecessary pointer from the MatchingContextHolder constructor. 3. Fixed some warnings in the YarrJIT code here and there. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileRegExpTestInline): * runtime/RegExpInlines.h: (JSC::RegExp::matchInline): * yarr/YarrJIT.cpp: * yarr/YarrMatchingContextHolder.h: (JSC::Yarr::MatchingContextHolder::MatchingContextHolder): 2022-01-24 Yusuke Suzuki [JSC] Support import assertion syntax https://bugs.webkit.org/show_bug.cgi?id=235312 Reviewed by Ross Kirsling. This patch adds syntax support for import assertion[1]. This does not add the actual feature propagating import assertion to the module request yet. [1]: https://github.com/tc39/proposal-import-assertions * bytecompiler/NodesCodegen.cpp: (JSC::ImportNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createImportExpr): (JSC::ASTBuilder::createImportAssertionList): (JSC::ASTBuilder::appendImportAssertion): (JSC::ASTBuilder::createImportDeclaration): (JSC::ASTBuilder::createExportAllDeclaration): (JSC::ASTBuilder::createExportNamedDeclaration): * parser/NodeConstructors.h: (JSC::ImportNode::ImportNode): (JSC::ImportDeclarationNode::ImportDeclarationNode): (JSC::ExportAllDeclarationNode::ExportAllDeclarationNode): (JSC::ExportNamedDeclarationNode::ExportNamedDeclarationNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::Parser::parseImportAssertions): (JSC::Parser::parseImportDeclaration): (JSC::Parser::parseExportDeclaration): (JSC::Parser::parseMemberExpression): * parser/Parser.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createImportExpr): (JSC::SyntaxChecker::createImportAssertionList): (JSC::SyntaxChecker::appendImportAssertion): (JSC::SyntaxChecker::createImportDeclaration): (JSC::SyntaxChecker::createExportAllDeclaration): (JSC::SyntaxChecker::createExportNamedDeclaration): * runtime/JSGlobalObjectFunctions.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/OptionsList.h: 2022-01-24 Mark Lam Add FixedVector::clear(), contains(), find(), and findMatching(). https://bugs.webkit.org/show_bug.cgi?id=234855 Reviewed by Yusuke Suzuki. Use FixedVector instead of Vector in DeferredWorkTimer::TicketData now that the needed APIs have been added. * runtime/DeferredWorkTimer.h: 2022-01-24 Joseph Griego [Shadow Realms] Use WebCore module loaders for shadow realm importValue https://bugs.webkit.org/show_bug.cgi?id=234155 Reviewed by Darin Adler. Add hook for creating the new realm object for shadow realms, since importValue requires the cooperation of the module loading logic to work right. * API/JSAPIGlobalObject.cpp: * jsc.cpp: * runtime/JSGlobalObject.cpp: * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::deriveShadowRealmGlobalObject): * runtime/ShadowRealmConstructor.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/ShadowRealmObject.cpp: (JSC::ShadowRealmObject::create): * runtime/ShadowRealmObject.h: 2022-01-21 Commit Queue Unreviewed, reverting r288400. https://bugs.webkit.org/show_bug.cgi?id=235470 broke ARM64E build Reverted changeset: "[JSC][32bit] Fix regexp crash on ARMv7" https://bugs.webkit.org/show_bug.cgi?id=234476 https://commits.webkit.org/r288400 2022-01-21 Mikhail R. Gadelha [JSC][32bit] Fix regexp crash on ARMv7 https://bugs.webkit.org/show_bug.cgi?id=234476 Reviewed by Yusuke Suzuki. This patch fixes several regexp crashes on ARMv7 due to an incorrect offset to retrieve the 5th argument from the stack: in ARMv7, only 4 arguments are passed via registers r0-r3i, and any other argument is placed on the stack, however, YarrJIT was trying to get the 5th arg from a fixed offset, so because the generateEnter() method pushed register into the stack, the offset was wrong. This patch fixes how the offset is calculated for MIPS and ARMv7. This patch also introduces some small changes: 1. Added static_asserts that the YarrJIT calls do indeed have 5 arguments and that the 5th argument has the type that we expect (MatchingContextHolder*). 2. Removed an unnecessary pointer from the MatchingContextHolder constructor. 3. Fixed some warnings in the YarrJIT code here and there. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileRegExpTestInline): * runtime/RegExpInlines.h: (JSC::RegExp::matchInline): * yarr/YarrJIT.cpp: * yarr/YarrMatchingContextHolder.h: (JSC::Yarr::MatchingContextHolder::MatchingContextHolder): 2022-01-21 Yusuke Suzuki Unreviewed, follow-up after r288066 https://bugs.webkit.org/show_bug.cgi?id=235271 * runtime/DatePrototype.cpp: (JSC::applyToNumberToOtherwiseIgnoredArguments): (JSC::fillStructuresUsingDateArgs): (JSC::setNewValueFromTimeArgs): (JSC::setNewValueFromDateArgs): (JSC::applyToNumbersToTrashedArguments): Deleted. 2022-01-21 Mike Gorse Build failure with g++ 12: std::exchange undefined https://bugs.webkit.org/show_bug.cgi?id=235445 Reviewed by Michael Catanzaro. * API/JSRetainPtr.h: Include 2022-01-21 Zan Dobersek [RISCV64] Add MacroAssemblerRISCV64 branch-testing operations https://bugs.webkit.org/show_bug.cgi?id=235442 Reviewed by Yusuke Suzuki. Implement MacroAssemblerRISCV64 branch-testing operations. The branching instructions being intentionally simple in RISC-V, and with no status register, scratch register has to be used to hold the testing result and perform a branch based on its value. This will disallow use of these implementations from Air, but that has to be address inside Air itself. When performing tests for values that are smaller than 64 bits in width, the tested value is zero-extended or, when necessary, loaded as an unsigned value, to impose zeroed upper bits that eliminate masking values that are too wide or get sign-extended when used as immediates. Post-masking, these shorter-width values still have to be sign-extended to accommodate branch instructions that are used when testing signedness. The test result value is then passed on, along with the desired condition, to the new branchTestFinalize() helper method that finally generates the appropriate branch. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::branchTest8): (JSC::MacroAssemblerRISCV64::branchTest16): (JSC::MacroAssemblerRISCV64::branchTest32): (JSC::MacroAssemblerRISCV64::branchTest64): (JSC::MacroAssemblerRISCV64::branchPtr): (JSC::MacroAssemblerRISCV64::branchTestFinalize): 2022-01-21 Zan Dobersek [RISCV64] Add MacroAssemblerRISCV64 operations for bitfield, zero-counting, byte-swapping operations https://bugs.webkit.org/show_bug.cgi?id=235439 Reviewed by Yusuke Suzuki. Add MacroAssemblerRISCV64 implementations that cover unsigned bitfield, leading-zero, trailing-zero and byte-swapping operations. All these operations are not supported in base RISC-V specifications. There are extensions currently being ratified that will introduce more useful instructions, but until then more verbose implementations will have to be used. For the unsigned bitfield operations, the desired result is achieved through shifting and masking. Scratch registers are only needed in case of the mask immediate being too large, but that will be properly handled by the higher-level JITs. For other operations covered in this patch we have to use scratch registers and custom loops to implement the necessary behavior. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::extractUnsignedBitfield32): (JSC::MacroAssemblerRISCV64::extractUnsignedBitfield64): (JSC::MacroAssemblerRISCV64::insertUnsignedBitfieldInZero32): (JSC::MacroAssemblerRISCV64::insertUnsignedBitfieldInZero64): (JSC::MacroAssemblerRISCV64::countLeadingZeros32): (JSC::MacroAssemblerRISCV64::countLeadingZeros64): (JSC::MacroAssemblerRISCV64::countTrailingZeros32): (JSC::MacroAssemblerRISCV64::countTrailingZeros64): (JSC::MacroAssemblerRISCV64::byteSwap16): (JSC::MacroAssemblerRISCV64::byteSwap32): (JSC::MacroAssemblerRISCV64::byteSwap64): 2022-01-21 Alex Christensen Fix build when using Visual Studio 2022 https://bugs.webkit.org/show_bug.cgi?id=235440 Reviewed by Antti Koivisto. It doesn't like having a switch with a default but no cases. This is cleaner with if statements anyways. Also make members const because I can. * jit/JITCode.cpp: (JSC::JITCode::calleeSaveRegisters const): * jit/JITCode.h: 2022-01-21 Lauro Moura [CMake] Cannot link libTestRunnerInjectedBundle.so in non unified build https://bugs.webkit.org/show_bug.cgi?id=226088 Reviewed by Adrian Perez de Castro. * wasm/js/JSWebAssemblyModule.h: Add missing header 2022-01-20 Pablo Saavedra Non-unified build fails due to forward declaration in JavaScriptCore/jit/JITStubRoutine.h https://bugs.webkit.org/show_bug.cgi?id=235409 Unreviewed non-unified build fix. * jit/JITStubRoutine.h: 2022-01-20 Joseph Griego [JSC] Add section directive in MacroAssemblerX86Common asm blocks https://bugs.webkit.org/show_bug.cgi?id=235406 Reviewed by Yusuke Suzuki. These asm blocks aren't in a function body so they need a .text directive to prevent them from being included in some arbitrary section (say, an inline function's section) by happenstance, which was happening in the WPE build without UnifiedSources. * assembler/MacroAssemblerX86Common.cpp: 2022-01-19 Yusuke Suzuki [JSC] Implement Temporal.Now.instant() https://bugs.webkit.org/show_bug.cgi?id=234836 Reviewed by Ross Kirsling. This patch implements Temporal.Now.instant() since Temporal.Instant is now implemented. It returns an instant which represents current wall time. * runtime/ISO8601.cpp: (JSC::ISO8601::ExactTime::now): * runtime/ISO8601.h: * runtime/TemporalNow.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): 2022-01-19 Yusuke Suzuki [JSC] Fix non-JIT Windows LLInt https://bugs.webkit.org/show_bug.cgi?id=235388 Reviewed by Mark Lam. We should implement cCall3 which calls llint_link_call etc. from LLInt code. This implementation needs to work on Windows too, so it requires stack modification. While we do not have a problem on JIT Windows build, it is required for non JIT Windows build. (If JIT is enabled, LLInt is fine. But if JIT is entirely disabled, this change is required.) * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_link_call): (JSC::LLInt::llint_virtual_call): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/cloop.rb: * offlineasm/instructions.rb: 2022-01-19 Saam Barati Update ARM64EHash https://bugs.webkit.org/show_bug.cgi?id=235192 Reviewed by Mark Lam. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/AssemblerBuffer.h: (JSC::ARM64EHash::ARM64EHash): (JSC::ARM64EHash::~ARM64EHash): (JSC::ARM64EHash::allocatePinForCurrentThreadAndInitializeHash): (JSC::ARM64EHash::deallocatePinForCurrentThread): (JSC::ARM64EHash::update): (JSC::ARM64EHash::pin): (JSC::ARM64EHash::currentHash): (JSC::ARM64EHash::setUpdatedHash): (JSC::AssemblerBuffer::AssemblerBuffer): (JSC::AssemblerBuffer::arm64eHash): (JSC::AssemblerBuffer::putIntegralUnchecked): (JSC::ARM64EHash::bitsForDiversifier): Deleted. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): (JSC::LinkBuffer::allocate): * assembler/SecureARM64EHashPins.cpp: Added. (JSC::WriteToJITRegionScope::WriteToJITRegionScope): (JSC::WriteToJITRegionScope::~WriteToJITRegionScope): (JSC::ValidateNonReentrancyScope::ValidateNonReentrancyScope): (JSC::ValidateNonReentrancyScope::~ValidateNonReentrancyScope): (JSC::allocateInExecutableMemory): (JSC::SecureARM64EHashPins::Page::Page): (JSC::initializePage): (JSC::SecureARM64EHashPins::metadata): (JSC::SecureARM64EHashPins::initializeAtStartup): (JSC::SecureARM64EHashPins::allocatePinForCurrentThreadImpl): (JSC::SecureARM64EHashPins::allocatePinForCurrentThread): (JSC::SecureARM64EHashPins::deallocatePinForCurrentThread): * assembler/SecureARM64EHashPins.h: Added. (JSC::SecureARM64EHashPins::firstPage): * assembler/SecureARM64EHashPinsInlines.h: Added. (JSC::SecureARM64EHashPins::keyForCurrentThread): (JSC::SecureARM64EHashPins::forEachPage): (JSC::SecureARM64EHashPins::forEachEntry): (JSC::SecureARM64EHashPins::findFirstEntry): (JSC::SecureARM64EHashPins::pinForCurrentThread): * heap/MarkedBlock.h: * heap/MarkedSpace.h: * heap/SlotVisitor.h: * jit/BaselineJITPlan.cpp: (JSC::BaselineJITPlan::BaselineJITPlan): (JSC::BaselineJITPlan::compileInThreadImpl): * jit/ExecutableAllocator.cpp: * parser/Parser.h: * runtime/InitializeThreading.cpp: (JSC::initialize): * runtime/IterationStatus.h: Removed. * runtime/JSCConfig.h: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::parseAndCompileAir): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompileB3): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::compileFunction): 2022-01-19 Yusuke Suzuki [JSC] Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint https://bugs.webkit.org/show_bug.cgi?id=235348 Reviewed by Michael Saboff. YarrJIT's backtrackCharacterClassNonGreedy breakpoint is actually reachable. We should subtract index (since it is already incremented), and go to the normal nonGreedyFailures path. * yarr/YarrJIT.cpp: 2022-01-19 Michael Catanzaro Fix -Wreturn-type and -Wunused-parameter warnings, January 2022 edition https://bugs.webkit.org/show_bug.cgi?id=235336 Reviewed by Adrian Perez de Castro. * wasm/WasmCompilationMode.h: (JSC::Wasm::isOSREntry): (JSC::Wasm::isAnyBBQ): (JSC::Wasm::isAnyOMG): 2022-01-18 Yusuke Suzuki [JSC] Remove Wasm::Table's m_mask https://bugs.webkit.org/show_bug.cgi?id=235329 Reviewed by Mark Lam. This patch removes m_mask in Wasm::Table. The mask is removed in the other places, but forgot removing that in Wasm::Table. * wasm/WasmTable.cpp: (JSC::Wasm::Table::setLength): (JSC::Wasm::Table::clear): (JSC::Wasm::Table::set): (JSC::Wasm::Table::get const): (JSC::Wasm::FuncRefTable::setFunction): (JSC::Wasm::FuncRefTable::function const): (JSC::Wasm::FuncRefTable::instance const): * wasm/WasmTable.h: (JSC::Wasm::Table::offsetOfLength): (JSC::Wasm::Table::offsetOfMask): Deleted. (JSC::Wasm::Table::mask const): Deleted. 2022-01-18 Alex Christensen Use c++2a instead of gnu++2a for Cocoa builds https://bugs.webkit.org/show_bug.cgi?id=234936 Reviewed by Sam Weinig. * Configurations/Base.xcconfig: * Configurations/JavaScriptCore.xcconfig: * DerivedSources.make: 2022-01-18 Adrian Perez de Castro Non-unified build fails due to missing header in WasmCalleeGroup.cpp Unreviewed non-unified build fix. * wasm/WasmCalleeGroup.cpp: Add missing inclusion of the LinkBuffer.h header. 2022-01-16 Lauro Moura Fix C++20 build warnings with GCC https://bugs.webkit.org/show_bug.cgi?id=235023 Reviewed by Alex Christensen. Mostly related to deprecating operations between enums of different types and not capturing this by default in lambdas. * assembler/X86Assembler.h: Casting enums to same type. (JSC::X86Assembler::cmovcc): (JSC::X86Assembler::jccRel32): (JSC::X86Assembler::setccOpcode): * b3/B3CheckSpecial.cpp: Capture this in lambda. (JSC::B3::CheckSpecial::generate): * b3/B3Type.cpp: Replace is_pod_v is is_standard_layout_v and is_trivial_v * bytecode/AccessCase.cpp: Capture this in lambda. (JSC::AccessCase::generateImpl): * bytecode/CallLinkInfo.cpp: Ditto. (JSC::OptimizingCallLinkInfo::emitDirectFastPath): (JSC::OptimizingCallLinkInfo::emitDirectTailCallFastPath): (JSC::OptimizingCallLinkInfo::initializeDirectCall): * dfg/DFGSpeculativeJIT.cpp: Ditto. * dfg/DFGSpeculativeJIT64.cpp: Ditto. (JSC::DFG::SpeculativeJIT::compile): * jit/ICStats.h: Cast enums to same type. (JSC::ICEvent::hash const): * jit/JITArithmetic.cpp: Capture this in lambda. (JSC::JIT::emitMathICSlow): * jit/JITSizeStatistics.cpp: Ditto. (JSC::JITSizeStatistics::markEnd): * runtime/VM.cpp: Ditto. (JSC::VM::deleteAllLinkedCode): (JSC::VM::deleteAllCode): (JSC::VM::shrinkFootprintWhenIdle): * wasm/WasmAirIRGenerator.cpp: Ditto. (JSC::Wasm::AirIRGenerator::AirIRGenerator): (JSC::Wasm::AirIRGenerator::addTableGet): (JSC::Wasm::AirIRGenerator::addTableSet): (JSC::Wasm::AirIRGenerator::addTableInit): (JSC::Wasm::AirIRGenerator::addTableFill): (JSC::Wasm::AirIRGenerator::addTableCopy): (JSC::Wasm::AirIRGenerator::addMemoryFill): (JSC::Wasm::AirIRGenerator::addMemoryCopy): (JSC::Wasm::AirIRGenerator::addMemoryInit): (JSC::Wasm::AirIRGenerator::emitCheckAndPreparePointer): (JSC::Wasm::AirIRGenerator::emitAtomicLoadOp): (JSC::Wasm::AirIRGenerator::emitAtomicStoreOp): (JSC::Wasm::AirIRGenerator::emitAtomicBinaryRMWOp): (JSC::Wasm::AirIRGenerator::emitAtomicCompareExchange): (JSC::Wasm::AirIRGenerator::atomicWait): (JSC::Wasm::AirIRGenerator::atomicNotify): (JSC::Wasm::AirIRGenerator::emitEntryTierUpCheck): (JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck): (JSC::Wasm::AirIRGenerator::addCallIndirect): (JSC::Wasm::AirIRGenerator::addCallRef): (JSC::Wasm::AirIRGenerator::emitChecksForModOrDiv): (JSC::Wasm::AirIRGenerator::addOp<:i32truncsf64>): (JSC::Wasm::AirIRGenerator::addOp<:i32truncsf32>): (JSC::Wasm::AirIRGenerator::addOp<:i32truncuf64>): (JSC::Wasm::AirIRGenerator::addOp<:i32truncuf32>): (JSC::Wasm::AirIRGenerator::addOp<:i64truncsf64>): (JSC::Wasm::AirIRGenerator::addOp<:i64truncuf64>): (JSC::Wasm::AirIRGenerator::addOp<:i64truncsf32>): (JSC::Wasm::AirIRGenerator::addOp<:i64truncuf32>): * wasm/WasmB3IRGenerator.cpp: Ditto. (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::addTableGet): (JSC::Wasm::B3IRGenerator::addTableSet): (JSC::Wasm::B3IRGenerator::addTableInit): (JSC::Wasm::B3IRGenerator::addTableFill): (JSC::Wasm::B3IRGenerator::addTableCopy): (JSC::Wasm::B3IRGenerator::emitIndirectCall): (JSC::Wasm::B3IRGenerator::addMemoryFill): (JSC::Wasm::B3IRGenerator::addMemoryInit): (JSC::Wasm::B3IRGenerator::addMemoryCopy): (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffsetForAtomicOps): (JSC::Wasm::B3IRGenerator::atomicWait): (JSC::Wasm::B3IRGenerator::atomicNotify): (JSC::Wasm::B3IRGenerator::emitEntryTierUpCheck): (JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck): (JSC::Wasm::B3IRGenerator::addCall): (JSC::Wasm::B3IRGenerator::addCallIndirect): (JSC::Wasm::B3IRGenerator::addCallRef): (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv): (JSC::Wasm::B3IRGenerator::addOp<:i32truncsf64>): (JSC::Wasm::B3IRGenerator::addOp<:i32truncsf32>): (JSC::Wasm::B3IRGenerator::addOp<:i32truncuf64>): (JSC::Wasm::B3IRGenerator::addOp<:i32truncuf32>): (JSC::Wasm::B3IRGenerator::addOp<:i64truncsf64>): (JSC::Wasm::B3IRGenerator::addOp<:i64truncuf64>): (JSC::Wasm::B3IRGenerator::addOp<:i64truncsf32>): (JSC::Wasm::B3IRGenerator::addOp<:i64truncuf32>): * yarr/YarrJIT.cpp: Ditto. 2022-01-15 Yusuke Suzuki [JSC] Fix Date functions' argument coercion https://bugs.webkit.org/show_bug.cgi?id=235271 Reviewed by Alexey Shvayka. Even if the input Date is NaN or the result looks like NaN, we need to coerce passed arguments to Number[1] since it has observable side effect. [1]: https://github.com/tc39/ecma262/pull/2136 * runtime/DatePrototype.cpp: (JSC::applyToNumbersToTrashedArguments): (JSC::fillStructuresUsingTimeArgs): (JSC::fillStructuresUsingDateArgs): (JSC::setNewValueFromTimeArgs): (JSC::setNewValueFromDateArgs): 2022-01-15 Yusuke Suzuki [JSC] Fix misc issues in WebAssembly.Exception https://bugs.webkit.org/show_bug.cgi?id=235261 Reviewed by Alexey Shvayka. 1. Add @toStringTag to WebAssembly.Exception.prototype. 2. Add argument count check for WebAssembly.Exception methods (since it is specified in WebIDL and these methods do not have optional parameters). * wasm/js/WebAssemblyExceptionPrototype.cpp: (JSC::WebAssemblyExceptionPrototype::finishCreation): (JSC::JSC_DEFINE_HOST_FUNCTION): 2022-01-15 Yusuke Suzuki [JSC] Fix misc WebAssembly.Table issues https://bugs.webkit.org/show_bug.cgi?id=235262 Reviewed by Alexey Shvayka. * wasm/js/WebAssemblyTablePrototype.cpp: 2022-01-14 Yusuke Suzuki and Mikhail R. Gadelha [JSC] Fix Linux 64bit compilation https://bugs.webkit.org/show_bug.cgi?id=235232 Reviewed by Saam Barati. Define PAS_BMALLOC in all projects since JavaScriptCore includes some files which can require this macro variable. Previously, JSDollarVM.cpp includes these files first, then at that time, we can define PAS_BMALLOC. However, after enabling jit-heap, these files are included before JSDollarVM.cpp and include pas_config.h without PAS_BMALLOC definition, which later causes the problem when including pas_lock.h since non PAS_BMALLOC libpas requires darwin specific locking. Since defining PAS_BMALLOC does not matter to whether using libpas or not, this patch just defines it globally. And for Apple ports, we define this when we define BENABLE_LIBPAS. * tools/JSDollarVM.cpp: 2022-01-14 Yusuke Suzuki [JSC] Fix WebAssembly.Global's typename for "anyfunc" https://bugs.webkit.org/show_bug.cgi?id=235105 Reviewed by Keith Miller. We should return "anyfunc" string instead of "funcref" according to the spec[1,2]. [1]: https://webassembly.github.io/spec/js-api/#globals [2]: https://webassembly.github.io/spec/js-api/#tables * wasm/js/JSWebAssemblyGlobal.cpp: (JSC::JSWebAssemblyGlobal::type): * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::type): 2022-01-14 Mark Lam JSStringJoiner's constructor should take a size_t length. https://bugs.webkit.org/show_bug.cgi?id=235217 rdar://87538657 Reviewed by Yusuke Suzuki. Also removed an unnecessary exception check in JSStringJoiner::append(). This is because appendWithoutSideEffects() cannot throw any exceptions. * runtime/JSStringJoiner.h: (JSC::JSStringJoiner::JSStringJoiner): (JSC::JSStringJoiner::append): 2022-01-14 Alexey Shvayka JSArray::fastSlice() should not convert the source from CoW https://bugs.webkit.org/show_bug.cgi?id=234990 Reviewed by Yusuke Suzuki. Since we aren't modifying the source array in fastSlice() nor its slow path, there is no reason to convert it from CopyOnWrite. * runtime/JSArray.cpp: (JSC::JSArray::fastSlice): 2022-01-14 Saam Barati Make isJITPC fast https://bugs.webkit.org/show_bug.cgi?id=235241 Reviewed by Yusuke Suzuki. Make it an inlined function, and stop tagging g_jscConfig.startExecutableMemory and g_jscConfig.endExecutableMemory, since they're in the Config page, and not mutable after it's frozen. * jit/ExecutableAllocator.cpp: (JSC::initializeJITPageReservation): (JSC::isJITPC): Deleted. * jit/ExecutableAllocator.h: (JSC::isJITPC): 2022-01-14 Saam Barati Use IRC for Wasm, and Briggs for JS on ARM64 https://bugs.webkit.org/show_bug.cgi?id=235235 Reviewed by Yusuke Suzuki and Robin Morisset. When I turned on IRC for everything in r287218, we saw some regressions on iOS on JetStream2. So, this patch makes it so JS code on arm64 goes back to using Briggs, and Wasm will use IRC. * b3/air/AirAllocateRegistersByGraphColoring.cpp: * b3/air/AirCode.h: (JSC::B3::Air::Code::setForceIRCRegisterAllocation): (JSC::B3::Air::Code::forceIRCRegisterAllocation): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompileB3): 2022-01-13 Zan Dobersek [RISCV64] riscv64 backend should lower offlineasm instructions https://bugs.webkit.org/show_bug.cgi?id=234952 Reviewed by Yusuke Suzuki. In the riscv64 offlineasm backend, instead of handling higher-level offlineasm instructions with different operand combinations and manually juggling temp registers, use the approach of aggressively lowering these opcodes into sequences of RISC-V instructions. Addresses and immediate values are lowered into usable forms where necessary. Different lowering phases handle any offlineasm instruction so that the resulting opcodes can be, with accompanying operands, used trivially to construct the RISC-V assembly. Lowered RISC-V opcodes use the 'rv_' prefix so that they can be easily diassociated from any offlineasm opcode that might share the same name. The prefix is removed when the assembly is finally generated. * offlineasm/riscv64.rb: 2022-01-13 Saam Barati Link Wasm code on the same thread that JITs https://bugs.webkit.org/show_bug.cgi?id=235201 Reviewed by Yusuke Suzuki and Mark Lam. This is preparing us for the changes that'll be needed by https://bugs.webkit.org/show_bug.cgi?id=235192. It should also be a small perf improvement, as we're now linking in parallel instead of doing it after all compilations have finished. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompileB3): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::prepareImpl): (JSC::Wasm::BBQPlan::compileFunction): (JSC::Wasm::BBQPlan::didCompleteCompilation): (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmBBQPlan.h: 2022-01-13 Elliott Williams [XCBuild] Add "product dependencies" which influence workspace build order https://bugs.webkit.org/show_bug.cgi?id=235094 Some ancillary targets (e.g. script-only targets like Derived Sources) do not have implicit dependencies visible to Xcode. In workspace builds, we need to give XCBuild additional information to ensure that they always run after their dependencies. This patch adds "Product Dependencies" phases, which are Copy Files phases that copy the _product_ of another dependency. The product names are also added to EXCLUDED_SOURCE_FILE_NAMES, making the actual copy a no-op, but these phases give XCBuild enough metadata to infer the relationship between targets. For example, JavaScriptCore's "Generate Unified Sources" target depends on headers from WTF, so it lists libWTF.a in its Product Dependencies. Xcode sees the relationship between the target doing the copy (Generate Unified Sources) and the target which produces the product (WTF) and schedules them accordingly. Because these dependencies are _implicit_ and the copy phases are no-ops, they do not influence command-line or production builds where each project is built separately. Reviewed by Alexey Proskuryakov. * Configurations/Base.xcconfig: Add EXCLUDED_SOURCE_FILE_NAMES * Configurations/JavaScriptCore.xcconfig: Inherit EXCLUDED_SOURCE_FILE_NAMES * JavaScriptCore.xcodeproj/project.pbxproj: Add Product Dependencies 2022-01-13 Tim Horton Fix a few Objective-C object leaks due to early returns in `init` https://bugs.webkit.org/show_bug.cgi?id=235162 Reviewed by Wenson Hsieh. * API/JSValue.mm: (-[JSValue initWithValue:inContext:]): 2022-01-12 Mark Lam [Re-landing] Update hashThreadState() to exclude __opaque_flags. https://bugs.webkit.org/show_bug.cgi?id=235081 rdar://86282584 Reviewed by Keith Miller. Removed some unused code. * runtime/MachineContext.h: (JSC::MachineContext::stackPointer): (JSC::MachineContext::framePointer): (JSC::MachineContext::instructionPointer): (JSC::MachineContext::linkRegister): (JSC::MachineContext::setStackPointer): Deleted. (JSC::MachineContext::setFramePointer): Deleted. (JSC::MachineContext::setLinkRegister): Deleted. 2022-01-12 Commit Queue Unreviewed, reverting r287912. https://bugs.webkit.org/show_bug.cgi?id=235164 ARM64/ARM64E Speedometer2 50% regression, probably breaking something Reverted changeset: "[RISCV64] riscv64 backend should lower offlineasm instructions" https://bugs.webkit.org/show_bug.cgi?id=234952 https://commits.webkit.org/r287912 2022-01-12 Commit Queue Unreviewed, reverting r287908. https://bugs.webkit.org/show_bug.cgi?id=235156 Broke M1 Monterey JSC Reverted changeset: "Update hashThreadState() to exclude __opaque_flags." https://bugs.webkit.org/show_bug.cgi?id=235081 https://commits.webkit.org/r287908 2022-01-11 Zan Dobersek [RISCV64] riscv64 backend should lower offlineasm instructions https://bugs.webkit.org/show_bug.cgi?id=234952 Reviewed by Yusuke Suzuki. In the riscv64 offlineasm backend, instead of handling higher-level offlineasm instructions with different operand combinations and manually juggling temp registers, use the approach of aggressively lowering these opcodes into sequences of RISC-V instructions. Addresses and immediate values are lowered into usable forms where necessary. Different lowering phases handle any offlineasm instruction so that the resulting opcodes can be, with accompanying operands, used trivially to construct the RISC-V assembly. Lowered RISC-V opcodes use the 'rv_' prefix so that they can be easily diassociated from any offlineasm opcode that might share the same name. The prefix is removed when the assembly is finally generated. * offlineasm/risc.rb: Also handle branch-on-arithmetic opcodes in the riscvLowerMisplacedAddress lowering phase. * offlineasm/riscv64.rb: 2022-01-11 Mark Lam Update hashThreadState() to exclude __opaque_flags. https://bugs.webkit.org/show_bug.cgi?id=235081 rdar://86282584 Reviewed by Keith Miller. Removed some unused code. * runtime/MachineContext.h: (JSC::MachineContext::stackPointer): (JSC::MachineContext::framePointer): (JSC::MachineContext::instructionPointer): (JSC::MachineContext::linkRegister): (JSC::MachineContext::setStackPointer): Deleted. (JSC::MachineContext::setFramePointer): Deleted. (JSC::MachineContext::setLinkRegister): Deleted. 2022-01-11 Asumu Takikawa [Wasm] Unify memory import handling in module loader and JS cases https://bugs.webkit.org/show_bug.cgi?id=234116 Reviewed by Yusuke Suzuki. Moves the memory import handling code to the Wasm module record and use the strategy used by the module loader to handle memory in all cases. * wasm/WasmModule.cpp: (JSC::Wasm::Module::copyInitialCalleeGroupToAllMemoryModes): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finalizeCreation): (JSC::JSWebAssemblyInstance::tryCreate): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::initializeImportsAndExports): 2022-01-11 Yusuke Suzuki [JSC] Fix kind of error thrown by wasm module creation https://bugs.webkit.org/show_bug.cgi?id=235082 Reviewed by Michael Saboff. It should throw WebAssembly.CompileError instead of WebAssembly.LinkError. This fixes occasional failure in wasm imports-oom.js test. * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::createStub): 2022-01-11 Adrian Perez de Castro Non-unified build fixes, early January 2022 edition https://bugs.webkit.org/show_bug.cgi?id=235013 Unreviewed non-unified build fixes. * wasm/js/JSWebAssemblyModule.cpp: Add missing JSWebAssemblyLinkError.h header. * wasm/js/JSWebAssemblyModule.h: Add missing forward declaration for the JSC::OptimizingCallLinkInfo type. 2022-01-10 Saam Barati Allow loop tier up to the Air tier https://bugs.webkit.org/show_bug.cgi?id=234587 Reviewed by Yusuke Suzuki. This patch adds loop tier up from LLInt -> Air. To implement this, we use EntrySwitch to point at each loop header, making each loop an entrypoint. This is unlike BBQ->OMG tier up, where we compile a special OSR entry OMG callee. This seems like a good architecture for the Air tier, since we might end up with slightly worse throughput, but we won't need a different compilation for loops vs call entrypoints. This patch also fixes a bug in Air's O0 register allocation where it didn't properly account for all named registers in an instruction. There was a silly bug where we asked each arg if it were a temp, instead of asking the Inst for each of its temps, since an Arg can be an address but still use temps. * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: (JSC::B3::Air::GenerateAndAllocateRegisters::generate): * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::emitLoad): (JSC::Wasm::AirIRGenerator::AirIRGenerator): (JSC::Wasm::AirIRGenerator::finalizeEntrypoints): (JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck): (JSC::Wasm::AirIRGenerator::addLoop): (JSC::Wasm::parseAndCompileAir): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::parseAndCompileB3): (JSC::Wasm::parseAndCompile): Deleted. * wasm/WasmB3IRGenerator.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::prepareImpl): (JSC::Wasm::BBQPlan::work): (JSC::Wasm::BBQPlan::compileFunction): (JSC::Wasm::BBQPlan::didCompleteCompilation): (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmBBQPlan.h: * wasm/WasmCallee.h: * wasm/WasmCalleeGroup.h: * wasm/WasmFormat.h: * wasm/WasmIRGeneratorHelpers.h: (JSC::Wasm::computeExceptionHandlerAndLoopEntrypointLocations): (JSC::Wasm::computeExceptionHandlerLocations): * wasm/WasmLLIntPlan.cpp: (JSC::Wasm::LLIntPlan::didCompleteCompilation): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/WasmOSREntryPlan.cpp: (JSC::Wasm::OSREntryPlan::work): * wasm/WasmSlowPaths.cpp: (JSC::LLInt::WASM_SLOW_PATH_DECL): * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): 2022-01-10 Alex Christensen Start using C++20 https://bugs.webkit.org/show_bug.cgi?id=233963 Reviewed by Yusuke Suzuki. * Configurations/Base.xcconfig: * Configurations/JavaScriptCore.xcconfig: * DerivedSources.make: * heap/Heap.cpp: (JSC::Heap::addCoreConstraints): * runtime/CachedTypes.cpp: * runtime/LiteralParser.h: * shell/PlatformPlayStation.cmake: 2022-01-10 Elliott Williams postprocess-headers.sh: Avoid redundant processing to speed up incremental Xcode builds https://bugs.webkit.org/show_bug.cgi?id=234941 Reviewed by Jonathan Bedard. On builds made with the legacy build system (currently any CLI build for Apple platforms), postprocess-headers.sh always runs, even when no headers have been copied. PBXBuild doesn't have the necessary granularity to let us avoid running it when there are no headers to copy, however, this patch improves execution time by only running the postprocess rule when a header has changed since the last time it ran. This change reduces JavaScriptCore's null build time from ~18.3s to ~5.32s. * postprocess-headers.sh: Added timestamp check 2022-01-09 Sam Weinig Remove support for Direct2D https://bugs.webkit.org/show_bug.cgi?id=234999 Reviewed by Darin Adler. Direct2D and FTW have not been building for over a year. It is time to remove them. * PlatformFTW.cmake: Removed. 2022-01-07 Saam Barati Unreviewed. Appease an assertion that was broken by r287801 by slightly refactoring code so we don't clobber the same named register twice. * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: (JSC::B3::Air::GenerateAndAllocateRegisters::generate): 2022-01-07 Saam Barati Add support for Wasm exceptions in the Air generator https://bugs.webkit.org/show_bug.cgi?id=231211 Reviewed by Filip Pizlo. This patch adds support to Air for Wasm exceptions. The implementation is very similar to how we implement it in the B3 Wasm tier. This patch shares code with the B3 tier where it can. This patch also fixes a bug where you the early clobbered registers of a patchpoint could prevent the prior instruction from register allocating. For example, you can have the instructions I1, I2. Where I2 clobbers the entire register file. It doesn't mean I1 shouldn't be able to allocate registers. Instead, the clobber should occur after I1 executes. This patch fixes the issue. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: (JSC::B3::Air::GenerateAndAllocateRegisters::generate): * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::ControlData::ControlData): (JSC::Wasm::AirIRGenerator::ControlData::isTry): (JSC::Wasm::AirIRGenerator::ControlData::isCatch): (JSC::Wasm::AirIRGenerator::ControlData::convertTryToCatch): (JSC::Wasm::AirIRGenerator::ControlData::convertTryToCatchAll): (JSC::Wasm::AirIRGenerator::ControlData::tryStart const): (JSC::Wasm::AirIRGenerator::ControlData::tryEnd const): (JSC::Wasm::AirIRGenerator::ControlData::tryDepth const): (JSC::Wasm::AirIRGenerator::ControlData::catchKind const): (JSC::Wasm::AirIRGenerator::ControlData::exception const): (JSC::Wasm::AirIRGenerator::emitCallPatchpoint): (JSC::Wasm::AirIRGenerator::addStackMap): (JSC::Wasm::AirIRGenerator::takeStackmaps): (JSC::Wasm::AirIRGenerator::takeExceptionHandlers): (JSC::Wasm::AirIRGenerator::newTmp): (JSC::Wasm::AirIRGenerator::emitPatchpoint): (JSC::Wasm::AirIRGenerator::emitLoad): (JSC::Wasm::AirIRGenerator::AirIRGenerator): (JSC::Wasm::AirIRGenerator::finalizeEntrypoints): (JSC::Wasm::AirIRGenerator::forEachLiveValue): (JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck): (JSC::Wasm::AirIRGenerator::addTry): (JSC::Wasm::AirIRGenerator::addCatch): (JSC::Wasm::AirIRGenerator::addCatchAll): (JSC::Wasm::AirIRGenerator::addCatchToUnreachable): (JSC::Wasm::AirIRGenerator::addCatchAllToUnreachable): (JSC::Wasm::AirIRGenerator::emitCatchImpl): (JSC::Wasm::AirIRGenerator::addDelegate): (JSC::Wasm::AirIRGenerator::addDelegateToUnreachable): (JSC::Wasm::AirIRGenerator::addThrow): (JSC::Wasm::AirIRGenerator::addRethrow): (JSC::Wasm::AirIRGenerator::addEndToUnreachable): (JSC::Wasm::AirIRGenerator::addCall): (JSC::Wasm::AirIRGenerator::emitIndirectCall): (JSC::Wasm::parseAndCompileAir): (JSC::Wasm::AirIRGenerator::preparePatchpointForExceptions): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::insertEntrySwitch): (JSC::Wasm::B3IRGenerator::emitCatchImpl): (JSC::Wasm::B3IRGenerator::addThrow): (JSC::Wasm::B3IRGenerator::addRethrow): (JSC::Wasm::PatchpointExceptionHandle::generate const): Deleted. (JSC::Wasm::buildEntryBufferForCatch): Deleted. (JSC::Wasm::computeExceptionHandlerLocations): Deleted. * wasm/WasmB3IRGenerator.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::compileFunction): * wasm/WasmIRGeneratorHelpers.h: Added. (JSC::Wasm::PatchpointExceptionHandle::generate const): (JSC::Wasm::computeExceptionHandlerLocations): (JSC::Wasm::emitRethrowImpl): (JSC::Wasm::emitThrowImpl): (JSC::Wasm::buildEntryBufferForCatch): (JSC::Wasm::emitCatchPrologueShared): * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::finalize): * wasm/WasmModuleInformation.h: * wasm/WasmOMGPlan.cpp: * wasm/WasmOSREntryPlan.cpp: * wasm/WasmStreamingParser.cpp: (JSC::Wasm::StreamingParser::parseCodeSectionSize): 2022-01-07 Alexey Shvayka Expand the set of objects we take JSArray::fastSlice() path for https://bugs.webkit.org/show_bug.cgi?id=234539 Reviewed by Yusuke Suzuki. Currently, Array.prototype's slice() / splice() methods take a fast path only for JSArray source objects. With this change, gcSafeMemcpy-based path is taken for any object with ordinary getOwnPropertySlotByIndex() method, which speeds up the common case of `[].slice.call(arguments)` by 140% (in strict mode only, see ClonedArguments). Also, once is https://webkit.org/b/234538 resolved, calling Array.prototype.slice() on a static NodeList, which is a common idiom to acquire map() / filter() methods, will become faster as well. This patch was thoroughly evaluated to be spec-perfect and memory-safe: - indexing mode check and holesMustForwardToPrototype() guarantee that there are no observable userland code to be invoked; - fastSlice() signature is upgraded to uint64_t so `nullptr` is returned in case of large "length", resulting in a RangeError being thrown on the slow path; - to handle the case of source array being shrinked after "length" lookup (see r175420), OOB read check is moved to JSArray::fastSlice() and refined to rely on vectorLength() so the double "length" lookup is avoided (added a test for this). All this (and more) is well covered by the test262 suite. This change improves Speedometer2/EmberJS-Debug-TodoMVC score by 0.5%: although the test is slow on its own, `[].slice.call(arguments)` is performed ~56k times per run. * runtime/ArrayPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/JSArray.cpp: (JSC::JSArray::fastSlice): * runtime/JSArray.h: 2022-01-07 Tim Horton Adopt linkedOnOrAfter() in more places https://bugs.webkit.org/show_bug.cgi?id=234951 Reviewed by Wenson Hsieh. * API/JSWrapperMap.mm: (supportsInitMethodConstructors): * API/tests/testapi.cpp: (TestAPI::promiseDrainDoesNotEatExceptions): * API/tests/testapi.mm: (testMicrotaskWithFunction): * runtime/JSLock.cpp: (JSC::JSLock::willReleaseLock): * runtime/ObjectPrototype.cpp: (JSC::isPokerBros): Adopt linkedOnOrAfter. 2022-01-07 Alex Christensen Unreviewed, reverting r287698. Broke an internal build Reverted changeset: "Start using C++20" https://bugs.webkit.org/show_bug.cgi?id=233963 https://commits.webkit.org/r287698 2022-01-07 Yusuke Suzuki [JSC] Clean up StructureStubInfo https://bugs.webkit.org/show_bug.cgi?id=234943 Reviewed by Saam Barati. Use std::unique_ptr instead of raw pointer. * bytecode/CheckPrivateBrandStatus.cpp: (JSC::CheckPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/DeleteByStatus.cpp: (JSC::DeleteByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/InByStatus.cpp: (JSC::InByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/InstanceOfStatus.cpp: (JSC::InstanceOfStatus::computeForStubInfo): * bytecode/PutByStatus.cpp: (JSC::PutByStatus::computeForStubInfo): * bytecode/SetPrivateBrandStatus.cpp: (JSC::SetPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::deref): (JSC::StructureStubInfo::aboutToDie): (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::visitAggregateImpl): (JSC::StructureStubInfo::visitWeakReferences): (JSC::StructureStubInfo::propagateTransitions): (JSC::StructureStubInfo::summary const): (JSC::StructureStubInfo::containsPC const): (JSC::StructureStubInfo::~StructureStubInfo): Deleted. * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::offsetOfCodePtr): (JSC::StructureStubInfo::offsetOfDoneLocation): (JSC::StructureStubInfo::offsetOfSlowPathStartLocation): (JSC::StructureStubInfo::offsetOfSlowOperation): (JSC::StructureStubInfo::offsetOfCountdown): 2022-01-06 Saam Barati preparePatchpointForExceptions needs to handle tuples https://bugs.webkit.org/show_bug.cgi?id=234909 Reviewed by Yusuke Suzuki. We got the offsets wrong when building a stackmap in B3IRGenerator for exception sites. We need to index into StackmapGenerationParams differently from indexing into the patchpoint's children. StackmapGenerationParams reserves its first N entries for the N return values. The patchpoint's children contains no results though, so we don't need to account for the number of return values when indexing into the children() vector of the PatchpointValue. To make this code simpler, we keep track of the number of live values we need when throwing. These values are both at the end of StackmapGenerationParams and at the end of the children() vector. So we just look at the last "number of live values" in both vectors to get the correct ValueRep and correct type. The code for calls also didn't account for the fact that call arguments will be appended after the live values we're building into a stackmap. This patch fixes that code to always put the live values last. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::PatchpointExceptionHandle::generate const): (JSC::Wasm::B3IRGenerator::preparePatchpointForExceptions): 2022-01-06 Alex Christensen Start using C++20 https://bugs.webkit.org/show_bug.cgi?id=233963 Reviewed by Yusuke Suzuki. * Configurations/Base.xcconfig: * Configurations/JavaScriptCore.xcconfig: * DerivedSources.make: * heap/Heap.cpp: (JSC::Heap::addCoreConstraints): * runtime/CachedTypes.cpp: * runtime/LiteralParser.h: * shell/PlatformPlayStation.cmake: 2022-01-04 Yusuke Suzuki [JSC] Remove m_calleeSaveRegisters from CodeBlock::JITData and rename it to BaselineJITData https://bugs.webkit.org/show_bug.cgi?id=234555 Reviewed by Saam Barati. This patch removes m_calleeSaveRegisters from CodeBlock::JITData, and moving it to each JITCode. This is reasonable since m_calleeSaveRegisters information belongs to JITCode, not CodeBlock. And in LLInt, Baseline, and DFG cases, m_calleeSaveRegisters is the same. So we do not have this field in these JITCode. Only FTL can have m_calleeSaveRegisters. By removing m_calleeSaveRegisters from CodeBlock::JITData, now it only includes Baseline JIT related data. So this patch renames CodeBlock::JITData to BaselineJITData. We also use TrailingArray for BaselineJITData so that we can remove one level indirection when loading JITConstantPool from JITData. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::setupWithUnlinkedBaselineCode): (JSC::CodeBlock::~CodeBlock): (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::finalizeJITInlineCaches): (JSC::CodeBlock::getICStatusMap): (JSC::CodeBlock::findStubInfo): (JSC::CodeBlock::resetBaselineJITData): (JSC::CodeBlock::stronglyVisitStrongReferences): (JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters): (JSC::CodeBlock::findPC): (JSC::CodeBlock::ensureJITDataSlow): Deleted. (JSC::CodeBlock::setCalleeSaveRegisters): Deleted. (JSC::CodeBlock::resetJITData): Deleted. (JSC::CodeBlock::calleeSaveRegisters const): Deleted. * bytecode/CodeBlock.h: (JSC::CodeBlock::offsetOfBaselineJITData): (JSC::CodeBlock::baselineJITData): (JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters): (JSC::CodeBlock::JITData::offsetOfJITConstantPool): Deleted. (JSC::CodeBlock::ensureJITData): Deleted. (JSC::CodeBlock::offsetOfJITData): Deleted. (JSC::CodeBlock::baselineJITConstantPool): Deleted. * bytecode/Repatch.cpp: (JSC::linkPolymorphicCall): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::emitRestoreCalleeSaves): (JSC::DFG::JITCompiler::emitSaveCalleeSaves): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::calleeSaveSlot): (JSC::DFG::reifyInlinedCallFrames): (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::StackLayoutPhase::run): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLJITCode.h: (JSC::FTL::JITCode::calleeSaveRegisters const): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::executableFor): (JSC::AssemblyHelpers::emitSaveOrCopyLLIntBaselineCalleeSavesFor): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitSaveThenMaterializeTagRegisters): (JSC::AssemblyHelpers::emitSaveCalleeSavesFor): Deleted. (JSC::AssemblyHelpers::emitRestoreCalleeSavesFor): Deleted. (JSC::AssemblyHelpers::emitSaveCalleeSaves): Deleted. (JSC::AssemblyHelpers::emitRestoreCalleeSaves): Deleted. * jit/BaselineJITCode.h: * jit/CallFrameShuffleData.cpp: * jit/CallFrameShuffleData.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::emitMaterializeMetadataAndConstantPoolRegisters): (JSC::JIT::emitSaveCalleeSaves): (JSC::JIT::compileAndLinkWithoutFinalizing): * jit/JIT.h: * jit/JITCode.cpp: (JSC::JITCode::calleeSaveRegisters const): * jit/JITCode.h: * jit/JITInlines.h: (JSC::JIT::loadConstant): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): * jit/RegisterAtOffsetList.cpp: (JSC::RegisterAtOffsetList::dfgCalleeSaveRegisters): * jit/RegisterAtOffsetList.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * tools/VMInspector.cpp: (JSC::VMInspector::dumpRegisters): 2022-01-04 Stephan Szabo [PlayStation] Fix non-ninja build of zydis https://bugs.webkit.org/show_bug.cgi?id=234854 Unreviewed build fix * PlatformPlayStation.cmake: Set Zycore.c as CXX 2022-01-04 Yusuke Suzuki [JSC] Remove JSWebAssemblyCalleeGroup cell https://bugs.webkit.org/show_bug.cgi?id=234780 Reviewed by Saam Barati. This cell is not observable to users. And this cell just holds Wasm-to-JS stubs, but it is the same to all memory modes. Thus, we should just generate it in VM-linked Wasm::Module (it means, we should have it in JSWebAssemblyModule), and we do not need to have / allocate JSWebAssemblyCalleeGroup cell. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::finalizeUnconditionalFinalizers): (JSC::Heap::deleteAllCodeBlocks): * heap/Heap.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/WasmBinding.h: * wasm/js/JSWebAssemblyCalleeGroup.cpp: Removed. * wasm/js/JSWebAssemblyCalleeGroup.h: Removed. * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::visitChildrenImpl): (JSC::JSWebAssemblyInstance::finalizeCreation): * wasm/js/JSWebAssemblyInstance.h: * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::createStub): (JSC::JSWebAssemblyModule::visitChildrenImpl): (JSC::JSWebAssemblyModule::clearJSCallICs): (JSC::JSWebAssemblyModule::finalizeUnconditionally): (JSC::JSWebAssemblyModule::generateWasmToJSStubs): (JSC::JSWebAssemblyModule::calleeGroup): Deleted. (JSC::JSWebAssemblyModule::setCalleeGroup): Deleted. * wasm/js/JSWebAssemblyModule.h: * wasm/js/WebAssemblyModuleConstructor.cpp: * wasm/js/WebAssemblyWrapperFunction.h: 2022-01-04 Yusuke Suzuki WebAssembly i32.atomic.wait timeout value incorrectly interpreted by factor 1000 https://bugs.webkit.org/show_bug.cgi?id=234833 Reviewed by Michael Saboff. Wasm atomics' timeout should be interpreted as nanoseconds. * wasm/WasmOperations.cpp: (JSC::Wasm::wait): 2022-01-03 Yusuke Suzuki Unreviewed, fix build failure https://bugs.webkit.org/show_bug.cgi?id=232723 * runtime/ArrayPrototype.cpp: (JSC::toLocaleString): 2022-01-03 Yusuke Suzuki Array.prototype.toLocaleString does not respect deletion of Object.prototype.toLocaleString https://bugs.webkit.org/show_bug.cgi?id=232723 Reviewed by Alexey Shvayka. This patch implements ECMA402 Array.prototype.toLocaleString[1]. The new implementation invokes "toLocaleString" method for each elements. [1]: https://tc39.es/ecma402/#sup-array.prototype.tolocalestring * runtime/ArrayPrototype.cpp: (JSC::toLocaleString): (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::slowJoin): 2022-01-03 Yusuke Suzuki [JSC] Fix Intl.PluralRules.selectRange input validation https://bugs.webkit.org/show_bug.cgi?id=234817 Reviewed by Alexey Shvayka. Add specified argument validation[1] to Intl.PluralRules.selectRange. [1]: https://tc39.es/proposal-intl-numberformat-v3/out/pluralrules/proposed.html#sec-intl.pluralrules.prototype.selectrange * runtime/IntlPluralRules.cpp: (JSC::IntlPluralRules::selectRange const): * runtime/IntlPluralRulesPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): 2022-01-03 Yusuke Suzuki [JSC] Update UCD to Unicode 14.0.0 https://bugs.webkit.org/show_bug.cgi?id=234811 Reviewed by Sam Weinig. This is yearly update of UCD data. * ucd/CaseFolding.txt: * ucd/DerivedBinaryProperties.txt: * ucd/DerivedCoreProperties.txt: * ucd/DerivedNormalizationProps.txt: * ucd/PropList.txt: * ucd/PropertyAliases.txt: * ucd/PropertyValueAliases.txt: * ucd/ScriptExtensions.txt: * ucd/Scripts.txt: * ucd/UnicodeData.txt: * ucd/emoji-data.txt: * yarr/generateYarrUnicodePropertyTables.py: 2022-01-03 Yusuke Suzuki [JSC] Read-modify-write operation's second put-to-scope should not throw error if binding does not exist https://bugs.webkit.org/show_bug.cgi?id=234813 Reviewed by Alexey Shvayka. This patch fixes a bug throwing RefereceError when read-modify-write's read operation removes binding from object. Throwing error should happen only when evaluating it under strict mode. * bytecompiler/NodesCodegen.cpp: (JSC::PostfixNode::emitResolve): (JSC::PrefixNode::emitResolve): (JSC::ReadModifyResolveNode::emitBytecode): (JSC::ShortCircuitReadModifyResolveNode::emitBytecode): 2022-01-03 Yusuke Suzuki [JSC] Fix length of Intl.NumberFormat.formatRange and Intl.PluralRules.selectRange https://bugs.webkit.org/show_bug.cgi?id=234806 Reviewed by Alexey Shvayka. These length's numbers are wrong. This patch fixes them. * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototype::finishCreation): * runtime/IntlPluralRulesPrototype.cpp: (JSC::IntlPluralRulesPrototype::finishCreation): 2022-01-02 Yusuke Suzuki [JSC] Use emitPutProperty / emitGetPropertyValue consistently to handle private names in edge cases https://bugs.webkit.org/show_bug.cgi?id=234794 Reviewed by Alexey Shvayka. This patch consistently uses emitPutProperty / emitGetPropertyValue so that we handle private names in edge cases. * bytecompiler/NodesCodegen.cpp: (JSC::TaggedTemplateNode::emitBytecode): (JSC::ForInNode::emitLoopHeader): (JSC::ForOfNode::emitBytecode): (JSC::AssignmentElementNode::bindValue const): 2022-01-02 Zan Dobersek Remove unused AbstractMacroAssembler::repatchJumpToNop() function https://bugs.webkit.org/show_bug.cgi?id=234777 Reviewed by Yusuke Suzuki. Remove the unused AbstractMacroAssembler::repatchJumpToNop() function, along with the underlying relinkJumpToNop() functions on ISA-specific assembler classes. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::relinkJumpToNop): Deleted. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::relinkJumpToNop): Deleted. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::repatchJumpToNop): Deleted. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::relinkJumpToNop): Deleted. * assembler/RISCV64Assembler.h: (JSC::RISCV64Assembler::relinkJumpToNop): Deleted. * assembler/X86Assembler.h: (JSC::X86Assembler::relinkJumpToNop): Deleted. 2022-01-02 Zan Dobersek [RISCV64] Make DFG, FTL, B3, WASM buildable on CPU(RISCV64) https://bugs.webkit.org/show_bug.cgi?id=234775 Reviewed by Yusuke Suzuki. Enable building DFG, FTL, B3 and WASM subsystems on 64-bit RISC-V. Necessary guards and missing bits are added to make things buildable, but actual enabling of these features at build-time is left for later. Even when enabled at build-time in the future, there'll likey be open issues that will require disabling different features at run-time. MacroAssemblerRISCV64::setCarry() no-op method is added for now. Carry flag retrieval isn't exactly possible on RISC-V, so the uses of it will have to be addressed some other way. The patchpointScratchRegister value is defined for CPU(RISCV64). As on ARM64, the value matches MacroAssemblerRISCV64::dataTempRegister. In B3, we follow ARM64 in the pinned extended-offset-address use and stack argument lowering. in WASM, we can again mirror ARM64 around LLInt callee registers and slots as well as executing the epilogue of a OSR-entry callee. * assembler/MacroAssembler.h: Provide lea64() for CPU(RISCV64) as well. * assembler/MacroAssemblerRISCV64.h: * b3/B3Common.cpp: (JSC::B3::pinnedExtendedOffsetAddrRegister): * b3/air/AirLowerStackArgs.cpp: (JSC::B3::Air::lowerStackArgs): * jit/GPRInfo.h: * wasm/WasmCallee.cpp: (JSC::Wasm::LLIntCallee::calleeSaveRegisters): * wasm/WasmLLIntPlan.cpp: (JSC::Wasm::LLIntPlan::didCompleteCompilation): * wasm/WasmOperations.cpp: (JSC::Wasm::doOSREntry): 2022-01-02 Zan Dobersek [RISCV64] Enable building LLInt WebAssembly via the riscv64 offlineasm backend https://bugs.webkit.org/show_bug.cgi?id=234776 Reviewed by Yusuke Suzuki. Sprinkle RISCV64 conditions around WebAssembly.asm as appropriate. For division, we can reuse the divi(s)/divq(s) instructions already available in offlineasm. RISC-V additionally provides remainder instructions, so the necessary offlineasm instructions are added and used for RISCV64. In the offlineasm riscv64 backend, the division and remainder instruction handling is improved to properly cover signed and unsigned variants. For other instructions used in LLint WebAssembly implementation like left or right rotation, trailing- or leading-zero counting, order-based floating-point comparison, load-reserved and store-conditional operations, the riscv64WASMPlaceholder helper is used to generate an ebreak instruction that will halt the program at runtime but will not throw a build-time error. Proper implementations will be provided once WebAssembly support on RISCV64 is taken up. * llint/WebAssembly.asm: * offlineasm/instructions.rb: * offlineasm/riscv64.rb: 2022-01-02 Zan Dobersek [RISCV64] Get testmasm building for CPU(RISCV64) https://bugs.webkit.org/show_bug.cgi?id=234774 Reviewed by Yusuke Suzuki. Add missing MacroAssemblerRISCV64 methods used in testmasm. Placeholders are used for now, proper implementations will be introduced later. In testmasm itself, we avoid testing the condition-flags register values since, like on MIPS, that register isn't available on RISC-V. * assembler/MacroAssemblerRISCV64.h: * assembler/testmasm.cpp: (JSC::testProbeModifiesStackPointer): (JSC::testProbeModifiesStackValues): 2021-12-31 Yusuke Suzuki [JSC] Replace UDIS86 with Zydis https://bugs.webkit.org/show_bug.cgi?id=234765 Reviewed by Michael Saboff. UDIS86 is not updated from 2014. Since it is missing relatively new SIMD opcodes, we cannot disassemble these opcodes when implementing Wasm SIMD. This patch replaces UDIS86 with Zydis, which is actively developed and used in SpiderMonkey too. It is under MIT license. This patch imports Zydis v3.2.1. 1. Import header and C files of Zydis and Zycore in a flattened manner. 2. Add directory names to the files (e.g. `Zydis/Decoder.c` => `ZydisDecoder.c`) to make it easy to build in JSC build. 3. Replace header includes from `#include ` to `#include "ZydisXXX.h"`. 4. Fix compile errors with our stricter compiler flags. 5. Remove Zycore API files and ZycoreArgParse.[hc] since they are not used. We didn't add files to Sources.txt since unified builds do not support C files currently. 2022-01-01 Jeff Miller Update user-visible copyright strings to include 2022 https://bugs.webkit.org/show_bug.cgi?id=234263 Reviewed by Anders Carlsson. * Info.plist: 2021-12-30 Adrian Perez de Castro Non-unified build fixes, end-of-year 2021 edition https://bugs.webkit.org/show_bug.cgi?id=234755 Unreviewed non-unified build fixes. * runtime/DeferredWorkTimer.h: Add missing JSCast.h header. 2021-12-28 Zan Dobersek [RISCV64] Add MacroAssemblerRISCV64 operations for floating-point branches https://bugs.webkit.org/show_bug.cgi?id=234631 Reviewed by Yusuke Suzuki. Add the floating-point branching operation implementations in MacroAssemblerRISCV64. Unordered status of values is determined through the fclass instruction and then handled as appropriate for the desired condition. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::branchFloat): (JSC::MacroAssemblerRISCV64::branchDouble): (JSC::MacroAssemblerRISCV64::branchDoubleNonZero): (JSC::MacroAssemblerRISCV64::branchDoubleZeroOrNaN): (JSC::MacroAssemblerRISCV64::branchTruncateDoubleToInt32): (JSC::MacroAssemblerRISCV64::branchConvertDoubleToInt32): (JSC::MacroAssemblerRISCV64::branchFP): 2021-12-28 Zan Dobersek [RISCV64] Add MacroAssemblerRISCV64 operations for testing, comparison https://bugs.webkit.org/show_bug.cgi?id=234630 Reviewed by Yusuke Suzuki. Add MacroAssemblerRISCV64 implementations for the different variants of compare and test instructions. For comparisons, the implementations set up the two values in separate registers and perform the comparison per the inquired relation, writing out the result into the destination register. For tests, the two values are set up and put through the bitwise AND, with the result evaluated and the destination register filled out according to the inquired result condition. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::compare8): (JSC::MacroAssemblerRISCV64::compare32): (JSC::MacroAssemblerRISCV64::compare64): (JSC::MacroAssemblerRISCV64::test8): (JSC::MacroAssemblerRISCV64::test32): (JSC::MacroAssemblerRISCV64::test64): (JSC::MacroAssemblerRISCV64::compareFinalize): (JSC::MacroAssemblerRISCV64::testFinalize): 2021-12-28 Zan Dobersek [RISCV64] Add MacroAssemblerRISCV64 operations with patchable elements https://bugs.webkit.org/show_bug.cgi?id=234635 Reviewed by Yusuke Suzuki. Add MacroAssemblerRISCV64 implementations for operations that generate patchable code sections. This covers moves, stores and branches. For moves and stores of pointer values, the patchable section is achieved by generating a immediate loader instruction sequence with all the placeholder instructions (nops) included. Some methods that had their noop implementations provided until now have been removed since they are not necessary anymore. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::moveWithPatch): (JSC::MacroAssemblerRISCV64::storePtrWithPatch): (JSC::MacroAssemblerRISCV64::branch32WithPatch): (JSC::MacroAssemblerRISCV64::branchPtrWithPatch): (JSC::MacroAssemblerRISCV64::patchableBranch64): 2021-12-28 Zan Dobersek [RISCV64] Enable signal-based VM traps for CPU(RISCV64) https://bugs.webkit.org/show_bug.cgi?id=234719 Reviewed by Yusuke Suzuki. Enable signal-based VM traps on RISCV64. On Linux, this depends on generating a SIGSEGV or SIGBUS signal. The former can be generated through a simple storage instruction that sources the address from the zero register. This storage instruction is generated on the desired location through the RISCV64Assembler::replaceWithVMHalt() method. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::replaceWithVMHalt): * assembler/RISCV64Assembler.h: (JSC::RISCV64Assembler::replaceWithVMHalt): 2021-12-28 Zan Dobersek [RISCV64] Define HAVE_MACHINE_CONTEXT, provide mcontext_t accessors for CPU(RISCV64) https://bugs.webkit.org/show_bug.cgi?id=234718 Reviewed by Yusuke Suzuki. Define HAVE_MACHINE_CONTEXT for RISCV64. In the MachineContext.h header, CPU(RISCV64)-specific accessors into the mcontext_t struct are also provided. * runtime/MachineContext.h: (JSC::MachineContext::stackPointerImpl): (JSC::MachineContext::framePointerImpl): (JSC::MachineContext::instructionPointerImpl): (JSC::MachineContext::argumentPointer<1>): (JSC::MachineContext::llintInstructionPointer): 2021-12-27 Yusuke Suzuki Consider merging Wasm::FunctionCodeBlock and Wasm::LLIntCallee https://bugs.webkit.org/show_bug.cgi?id=203691 Reviewed by Filip Pizlo. This patch merges Wasm::FunctionCodeBlock into Wasm::LLIntCallee since both are one-on-one and what they want to represent are the same. We change Wasm::FunctionCodeBlock to Wasm::FunctionCodeBlockGenerator so that we can use FixedVector in Wasm::LLIntCallee which makes Wasm::LLIntCallee small, and this is similar to what JS side is doing (UnlinkedCodeBlockGenerator). * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/BytecodeDumper.cpp: (JSC::Wasm::BytecodeDumper::dumpBlock): (JSC::Wasm::BytecodeDumper::dumpConstants): (JSC::Wasm::BytecodeDumper::constantName const): * bytecode/BytecodeDumper.h: * interpreter/Interpreter.cpp: (JSC::CatchInfo::CatchInfo): * llint/LLIntOffsetsExtractor.cpp: * llint/WebAssembly.asm: * wasm/WasmCallee.cpp: (JSC::Wasm::LLIntCallee::LLIntCallee): (JSC::Wasm::LLIntCallee::outOfLineJumpOffset): (JSC::Wasm::LLIntCallee::outOfLineJumpTarget): (JSC::Wasm::LLIntCallee::linkExceptionHandlers): Deleted. * wasm/WasmCallee.h: (JSC::Wasm::Callee::llintFunctionCodeBlock const): Deleted. * wasm/WasmFunctionCodeBlockGenerator.cpp: Renamed from Source/JavaScriptCore/wasm/WasmFunctionCodeBlock.cpp. (JSC::Wasm::FunctionCodeBlockGenerator::setInstructions): (JSC::Wasm::FunctionCodeBlockGenerator::addOutOfLineJumpTarget): (JSC::Wasm::FunctionCodeBlockGenerator::outOfLineJumpOffset): (JSC::Wasm::FunctionCodeBlockGenerator::addSignature): (JSC::Wasm::FunctionCodeBlockGenerator::addJumpTable): (JSC::Wasm::FunctionCodeBlockGenerator::numberOfJumpTables const): * wasm/WasmFunctionCodeBlockGenerator.h: Renamed from Source/JavaScriptCore/wasm/WasmFunctionCodeBlock.h. (JSC::Wasm::FunctionCodeBlockGenerator::FunctionCodeBlockGenerator): (JSC::Wasm::FunctionCodeBlockGenerator::tierUpCounter): * wasm/WasmGeneratorTraits.h: * wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::parseAndCompileBytecode): (JSC::Wasm::LLIntGenerator::LLIntGenerator): (JSC::Wasm::LLIntGenerator::finalize): (JSC::Wasm::LLIntGenerator::addLoop): (JSC::Wasm::LLIntGenerator::addSwitch): * wasm/WasmLLIntGenerator.h: * wasm/WasmLLIntPlan.cpp: (JSC::Wasm::LLIntPlan::compileFunction): (JSC::Wasm::LLIntPlan::didCompleteCompilation): * wasm/WasmLLIntPlan.h: * wasm/WasmLLIntTierUpCounter.h: (JSC::Wasm::LLIntTierUpCounter::LLIntTierUpCounter): * wasm/WasmSlowPaths.cpp: (JSC::LLInt::shouldJIT): (JSC::LLInt::jitCompileAndSetHeuristics): (JSC::LLInt::WASM_SLOW_PATH_DECL): (JSC::LLInt::doWasmCallIndirect): (JSC::LLInt::doWasmCallRef): 2021-12-26 Yusuke Suzuki [JSC] Use SlowPathReturnType instead of EncodedMatchResult https://bugs.webkit.org/show_bug.cgi?id=234686 Reviewed by Filip Pizlo. This patch replaces YarrJIT's EncodedMatchResult with SlowPathReturnType so that CCallHelpers can handle it correctly. * runtime/MatchResult.h: (JSC::MatchResult::MatchResult): (JSC::MatchResult::failed): * runtime/SlowPathReturnType.h: (JSC::decodeResult): * yarr/YarrJIT.h: 2021-12-23 Mark Lam Make DeferredWorkTimer::addPendingWork() return a Ticket. https://bugs.webkit.org/show_bug.cgi?id=234628 rdar://84260429 Reviewed by Yusuke Suzuki. 1. Make Ticket a unique token instead of the JSObject* target object. The Ticket is now a pointer to the TicketData in the pending work list. 2. Instead of taking a Ticket argument, DeferredWorkTimer::addPendingWork() now takes a JSObject* `target` argument explicitly, and returns the Ticket for the added TicketData instead. All the relevant DeferredWorkTimer APIS already take a Ticket as an argument. This ensures that addPendingWork() is called before we start doing work with these APIs (especially scheduleWorkSoon()). 3. Previously, addPendingWork() will only save one instance of TicketData for a given JSObject* key. With this patch, we'll register a new TicketData instance for every call to addPendingWork(), and return a unique Ticket for it. This is needed because it may be possible for 2 different clients to call addPendingWork() and scheduleWorkSoon() with the same target JSObject* but with different sets of dependencies. Secondly, even is the both sets of dependencies are identical, a client may call addPendingWork() and scheduleWorkSoon() with the same JSObject* target more than once because it intended to schedule more than 1 task to run. Note that DeferredWorkTimer::doWork() consumes the corresponding TicketData (i.e. removes it from the m_pendingTickets list) for each task as it is run. To ensure that the dependencies for each task is protected, we'll either need to ref count the TicketData for the same target object (and hold off on removing it from the list), or we'll need to register a different TicketData instance for each task. Ref counting can solve the second issue above, but does not solve the first. So, this patch goes with the more generic solution to allow each task to have its own TicketData instance (and, its own unique Ticket). 4. Previously, if the client cancels pending work, we would remove the TicketData immediately from the m_pendingTickets list. This opens up an opportunity for the same TicketData memory to be re-allocated by another client. This, in turn, would make the Ticket token not unique and potentially allow a cancelled ticket to be reused before DeferredWorkTimer::doWork() is called. This patch changes DeferredWorkTimer::cancelPendingWork() to only clear the contents of the TicketData instead. TicketData::scriptExecutionOwner being null is used as an indication that the ticket has been cancelled. Since the TicketData itself is not "freed" yet, all TicketData will remain unique until DeferredWorkTimer::doWork(). Consequently, DeferredWorkTimer::doWork() will now check for cancelled tickets and remove them from the m_pendingTickets list. 5. JSFinalizationRegistry was previously calling DeferredWorkTimer::hasPendingWork() to check if it has already scheduled a task, so as not to reschedule again until after the previously scheduled task has been run. This does not play nice with the new Ticket API, because this hasPendingWork() check needs to be done before calling addPendingWork(), and hence, the Ticket is not available yet. Fortunately, JSFinalizationRegistry should know if it has already scheduled a task itself. This patch adds a m_hasAlreadyScheduledWork flag to JSFinalizationRegistry that can be used for this check instead. * jsc.cpp: (JSC_DEFINE_HOST_FUNCTION): * runtime/DeferredWorkTimer.cpp: (JSC::DeferredWorkTimer::TicketData::TicketData): (JSC::DeferredWorkTimer::TicketData::vm): (JSC::DeferredWorkTimer::TicketData::cancel): (JSC::DeferredWorkTimer::doWork): (JSC::DeferredWorkTimer::addPendingWork): (JSC::DeferredWorkTimer::hasPendingWork): (JSC::DeferredWorkTimer::hasDependancyInPendingWork): (JSC::DeferredWorkTimer::cancelPendingWork): * runtime/DeferredWorkTimer.h: (JSC::DeferredWorkTimer::TicketData::target): * runtime/JSFinalizationRegistry.cpp: (JSC::JSFinalizationRegistry::finalizeUnconditionally): * runtime/JSFinalizationRegistry.h: * wasm/WasmStreamingCompiler.cpp: (JSC::Wasm::StreamingCompiler::StreamingCompiler): (JSC::Wasm::StreamingCompiler::~StreamingCompiler): (JSC::Wasm::StreamingCompiler::didComplete): (JSC::Wasm::StreamingCompiler::fail): (JSC::Wasm::StreamingCompiler::cancel): * wasm/WasmStreamingCompiler.h: * wasm/js/JSWebAssembly.cpp: (JSC::JSWebAssembly::webAssemblyModuleValidateAsync): (JSC::instantiate): (JSC::compileAndInstantiate): (JSC::JSWebAssembly::webAssemblyModuleInstantinateAsync): 2021-12-22 Saam Barati LLInt should loop OSR into BBQ and BBQ should loop OSR into OMG https://bugs.webkit.org/show_bug.cgi?id=234542 Reviewed by Yusuke Suzuki. It's a startup perf improvement on some Wasm benchmarks I'm running to have Wasm LLInt do loop OSR entry into BBQ instead of OMG. This improves this benchmark by 5%. There is probably more perf to be had here. Currently, we're just OSR entering into B3 BBQ O1. However, in the future, we should just compile a single Air BBQ Callee that allows for OSR entry at loop boundaries. Maybe we can model this using EntrySwitch without any real harm to throughput. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/MacroAssemblerCodeRef.cpp: (JSC::shouldDumpDisassemblyFor): * jsc.cpp: (JSC_DEFINE_HOST_FUNCTION): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::parseAndCompile): * wasm/WasmCallee.h: (JSC::Wasm::Callee::setOSREntryCallee): Deleted. * wasm/WasmCalleeGroup.h: * wasm/WasmCompilationMode.cpp: (JSC::Wasm::makeString): * wasm/WasmCompilationMode.h: (JSC::Wasm::isOSREntry): (JSC::Wasm::isAnyBBQ): (JSC::Wasm::isAnyOMG): * wasm/WasmOMGForOSREntryPlan.cpp: Removed. * wasm/WasmOMGForOSREntryPlan.h: Removed. * wasm/WasmOSREntryPlan.cpp: Copied from Source/JavaScriptCore/wasm/WasmOMGForOSREntryPlan.cpp. (JSC::Wasm::OSREntryPlan::OSREntryPlan): (JSC::Wasm::OSREntryPlan::work): (JSC::Wasm::OMGForOSREntryPlan::OMGForOSREntryPlan): Deleted. (JSC::Wasm::OMGForOSREntryPlan::work): Deleted. * wasm/WasmOSREntryPlan.h: Copied from Source/JavaScriptCore/wasm/WasmOMGForOSREntryPlan.h. * wasm/WasmOperations.cpp: (JSC::Wasm::doOSREntry): (JSC::Wasm::JSC_DEFINE_JIT_OPERATION): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::updateCallSitesToCallUs): * wasm/WasmSlowPaths.cpp: (JSC::LLInt::WASM_SLOW_PATH_DECL): 2021-12-22 Alex Christensen Fix compiling with pickier compiler https://bugs.webkit.org/show_bug.cgi?id=234593 Reviewed by Brady Eidson. * API/tests/Regress141275.mm: (-[JSTEvaluator initWithScript:]): * API/tests/testapi.mm: (checkModuleWasRejected): 2021-12-22 Zan Dobersek [RISCV64] Add RISCV64 support in YARR https://bugs.webkit.org/show_bug.cgi?id=234547 Reviewed by Yusuke Suzuki. Add RISCV64 support to YARR. This covers providing the required register and immediate defitinitions, as well as also enabling codepaths shared with other 64-bit architectures. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::load16): YARR JIT also requires a load16() overload that loads from an ExtendedAddress. * yarr/YarrJIT.cpp: * yarr/YarrJITRegisters.h: 2021-12-22 Zan Dobersek [RISCV64] Fix RISCV64Assembler::ImmediateDecomposition in debug builds https://bugs.webkit.org/show_bug.cgi?id=234594 Unreviewed, fix the RISCV64Assembler::ImmediateDecomposition constructor to build in debug mode (fixing the assert) as well as run properly in that mode (performing manual sign-extension on the lower 12 bits of the IImmediate value as required for this type of immediates). * assembler/RISCV64Assembler.h: (JSC::RISCV64Instructions::ImmediateDecomposition::ImmediateDecomposition): 2021-12-21 Zan Dobersek [RISCV64] Add or enable missing CPU(RISCV64) codepaths in baseline JIT https://bugs.webkit.org/show_bug.cgi?id=234551 Reviewed by Yusuke Suzuki. Sprinkle the necessary CPU(RISCV64) build guards as well as additional RISCV64-specific codepaths encapsualted by those build guards in the baseline JIT code. In many cases we can align with the code that ARM64 is already using. In InlineAccess, the byte-sizes for access and replacement operations are based on a mix of educated guessing and aggressive testing. In baseline JIT, we can usually adopt what ARM64 already does since the similarities are big enough. * bytecode/InlineAccess.h: The sizes here are based on the estimated count of necessary instructions for access or replacement, and were tested with the enabled crash-inducing fallback in linkCodeInline(). (JSC::InlineAccess::sizeForPropertyAccess): (JSC::InlineAccess::sizeForPropertyReplace): (JSC::InlineAccess::sizeForLengthAccess): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitLoadStructure): (JSC::AssemblyHelpers::debugCall): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitSaveThenMaterializeTagRegisters): (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters): (JSC::AssemblyHelpers::prologueStackPointerDelta): (JSC::AssemblyHelpers::emitFunctionPrologue): (JSC::AssemblyHelpers::emitFunctionEpilogueWithEmptyFrame): (JSC::AssemblyHelpers::emitFunctionEpilogue): (JSC::AssemblyHelpers::preserveReturnAddressAfterCall): (JSC::AssemblyHelpers::restoreReturnAddressBeforeReturn): * jit/CCallHelpers.h: (JSC::CCallHelpers::prepareForTailCallSlow): * jit/CallFrameShuffler.cpp: (JSC::CallFrameShuffler::prepareForTailCall): * jit/JITPropertyAccess.cpp: (JSC::JIT::slow_op_resolve_scopeGenerator): (JSC::JIT::slow_op_get_from_scopeGenerator): * jit/RegisterSet.cpp: (JSC::RegisterSet::macroScratchRegisters): (JSC::RegisterSet::dfgCalleeSaveRegisters): (JSC::RegisterSet::ftlCalleeSaveRegisters): * jit/ThunkGenerators.cpp: (JSC::popThunkStackPreservesAndHandleExceptionGenerator): 2021-12-21 Zan Dobersek [RISCV64] Add missing MacroAssemblerRISCV64 floating-point rounding, comparison methods https://bugs.webkit.org/show_bug.cgi?id=234475 Reviewed by Yusuke Suzuki. Add missing MacroAssemblerRISCV64 methods that cover floating-point rounding and comparison operations. Manually detecting NaN values is possible by classifying floating-point values, and subsequently rounding operation or different comparison conditions have to be handled appropriately. Single-precision and double-precision implementations can neatly be handled in singular templated helper methods, and precision-specific codepaths can be determined at compile-time. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::ceilFloat): (JSC::MacroAssemblerRISCV64::ceilDouble): (JSC::MacroAssemblerRISCV64::floorFloat): (JSC::MacroAssemblerRISCV64::floorDouble): (JSC::MacroAssemblerRISCV64::roundTowardNearestIntFloat): (JSC::MacroAssemblerRISCV64::roundTowardNearestIntDouble): (JSC::MacroAssemblerRISCV64::roundTowardZeroFloat): (JSC::MacroAssemblerRISCV64::roundTowardZeroDouble): (JSC::MacroAssemblerRISCV64::compareFloat): (JSC::MacroAssemblerRISCV64::compareDouble): (JSC::MacroAssemblerRISCV64::roundFP): (JSC::MacroAssemblerRISCV64::compareFP): 2021-12-21 Carlos Garcia Campos CSP: Include the sample in eval violation reports https://bugs.webkit.org/show_bug.cgi?id=234390 Reviewed by Kate Cheney. * interpreter/Interpreter.cpp: (JSC::eval): Pass the code to reportViolationForUnsafeEval(). * runtime/DirectEvalExecutable.cpp: (JSC::DirectEvalExecutable::create): Ditto. * runtime/FunctionConstructor.cpp: (JSC::stringifyFunction): Helper function with the code to stringify function to be called also for the csp violation report. (JSC::constructFunction): Call stringifyFunction() to get the code for reportViolationForUnsafeEval(). (JSC::constructFunctionSkippingEvalEnabledCheck): Use stringifyFunction(). * runtime/IndirectEvalExecutable.cpp: (JSC::IndirectEvalExecutable::createImpl): Pass the code to reportViolationForUnsafeEval(). * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::reportViolationForUnsafeEval): Add string parameter for the code sample. * runtime/JSGlobalObjectFunctions.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): Pass the code to reportViolationForUnsafeEval(). 2021-12-21 Zan Dobersek [RISCV64] Add basic MacroAssemblerRISCV64 branching methods https://bugs.webkit.org/show_bug.cgi?id=234474 Reviewed by Yusuke Suzuki. Add MacroAssemblerRISCV64 implementations for the basic branching methods. RelationalCondition enum values are aliased to the branching condition values in RISCV64Assembler. The makeBranch() helper method is added that generates the final branching instruction for the given condition and the two registers holding values for the comparison and returns the Jump object based on the label constructed at the location of the branching placeholder. Branching methods essentially consist of preparing the two registers and calling the makeBranch() method. For 8-bit and 32-bit comparisons the compared values have to be sign-extended into the scratch registers because the branching instructions don't operate on partial values. This might cause friction in higher JIT levels where the use of scratch registers is disallowed. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::invert): (JSC::MacroAssemblerRISCV64::branch8): (JSC::MacroAssemblerRISCV64::branch32): (JSC::MacroAssemblerRISCV64::branch64): (JSC::MacroAssemblerRISCV64::branch32WithUnalignedHalfWords): (JSC::MacroAssemblerRISCV64::makeBranch): 2021-12-21 Geza Lore [JSC][ARMv7] Minor code size improvements https://bugs.webkit.org/show_bug.cgi?id=234387 Reviewed by Yusuke Suzuki. A few mew code size improvements to ARMv7/Thumb-2 - Use ldrd/strd in mode places (via AssemblyHelpers:loadValue and AssemblyHelpers::storeValue) - Use BIC immediate instruction instead of AND where appropriate - Use a 2-byte ADDS instead of a 4-byte CMN when possible. This applies very often as it handles testing JSValue tags. - Use addressTempRegister in branch32 Overall saving of about 3.5% code size on JetStream2, according to --dumpLinkBufferStats. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::bic): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::and32): (JSC::MacroAssemblerARMv7::storePair32): (JSC::MacroAssemblerARMv7::compare32AndSetFlags): (JSC::MacroAssemblerARMv7::branch32): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::storePair32): * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::compileExit): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillJSValue): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compileGetByVal): (JSC::DFG::SpeculativeJIT::compile): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::storeValue): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_mov): 2021-12-19 Ross Kirsling [JSC] OpPow should have a "small int exponent" fast path at lower tiers https://bugs.webkit.org/show_bug.cgi?id=234408 Reviewed by Yusuke Suzuki. DFG has an ArithPow fast path which just multiplies in a loop when the exponent is an int between 0 and 1000; this can be done at lower tiers too. Implementing this at LLInt gives the following speedup with JIT disabled: Before After pow-int-int 193.7180+-0.4897 ^ 100.3569+-1.9804 ^ definitely 1.9303x faster pow-double-int 194.0744+-0.7998 ^ 100.0346+-0.8655 ^ definitely 1.9401x faster 193.8824+-0.4667 ^ 100.0964+-0.9922 ^ definitely 1.9370x faster Implementing this at Baseline gives similar results with DFG disabled: Before After pow-int-int 195.6251+-0.9577 ^ 99.9627+-0.3307 ^ definitely 1.9570x faster pow-double-int 196.1975+-0.9307 ^ 101.0056+-0.3124 ^ definitely 1.9424x faster 195.8786+-0.5883 ^ 100.4767+-0.2333 ^ definitely 1.9495x faster Results are neutral otherwise. * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_pow): (JSC::JIT::emitSlow_op_pow): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2021-12-18 Mikhail R. Gadelha [JSC][32bit] Fix undefined behavior causing miscompilation with clang 13 on ARM https://bugs.webkit.org/show_bug.cgi?id=234399 Reviewed by Yusuke Suzuki. Compiling JSC with clang 13 on ARMv7 on linux was broken because clang was marking the constant Infinity as poison during constant folding, if either -O2 or -O3 were used, causing the constant to not being initialized. This patch removes the undefined behaviour by preventing the static_cast to int32_t if the double is either inf or NaN. * runtime/MathCommon.h: (JSC::canBeInt32): (JSC::canBeStrictInt32): 2021-12-18 Yusuke Suzuki [JSC] Do not allocate m_bbqCallee and m_omgCallee until it becomes necessary https://bugs.webkit.org/show_bug.cgi?id=234457 Reviewed by Saam Barati. WebAssembly memory import will require initializing both Wasm::CalleeGroup. So, we should shrink memory size of Wasm::CalleeGroup as much as possible to avoid memory regression. This patch allocates m_bbqCallee and m_omgCallee only when it becomes available. * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::work): * wasm/WasmCalleeGroup.cpp: (JSC::Wasm::CalleeGroup::CalleeGroup): * wasm/WasmCalleeGroup.h: (JSC::Wasm::CalleeGroup::compilationFinished): Deleted. (JSC::Wasm::CalleeGroup::runnable): Deleted. (JSC::Wasm::CalleeGroup::errorMessage): Deleted. (JSC::Wasm::CalleeGroup::functionImportCount const): Deleted. (JSC::Wasm::CalleeGroup::embedderEntrypointCalleeFromFunctionIndexSpace): Deleted. (JSC::Wasm::CalleeGroup::wasmEntrypointCalleeFromFunctionIndexSpace): Deleted. (JSC::Wasm::CalleeGroup::wasmBBQCalleeFromFunctionIndexSpace): Deleted. (JSC::Wasm::CalleeGroup::entrypointLoadLocationFromFunctionIndexSpace): Deleted. (JSC::Wasm::CalleeGroup::wasmToWasmExitStub): Deleted. (JSC::Wasm::CalleeGroup::mode const): Deleted. * wasm/WasmOMGForOSREntryPlan.cpp: (JSC::Wasm::OMGForOSREntryPlan::work): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::updateCallSitesToCallUs): * wasm/WasmPlan.h: 2021-12-17 Yusuke Suzuki [WTF] Introduce TrailingArray https://bugs.webkit.org/show_bug.cgi?id=234201 Reviewed by Darin Adler. Use ThreadSafeRefCountedFixedVector in ObjectPropertyConditionSet and Wasm::LLIntCallees. * bytecode/CodeBlock.h: (JSC::CodeBlock::baselineJITConstantPool): * bytecode/ObjectPropertyConditionSet.cpp: (JSC::ObjectPropertyConditionSet::mergedWith const): (JSC::ObjectPropertyConditionSet::dumpInContext const): (JSC::ObjectPropertyConditionSet::isValidAndWatchable const): * bytecode/ObjectPropertyConditionSet.h: (JSC::ObjectPropertyConditionSet::invalid): (JSC::ObjectPropertyConditionSet::create): (JSC::ObjectPropertyConditionSet::isValid const): (JSC::ObjectPropertyConditionSet::size const): (JSC::ObjectPropertyConditionSet::begin const): (JSC::ObjectPropertyConditionSet::end const): (JSC::ObjectPropertyConditionSet::ObjectPropertyConditionSet): Deleted. (JSC::ObjectPropertyConditionSet::releaseRawPointer): Deleted. (JSC::ObjectPropertyConditionSet::adoptRawPointer): Deleted. (JSC::ObjectPropertyConditionSet::fromRawPointer): Deleted. (JSC::ObjectPropertyConditionSet::Data::Data): Deleted. * jit/JIT.cpp: (JSC::JIT::compileAndLinkWithoutFinalizing): * jit/JITInlines.h: (JSC::JIT::loadConstant): * llint/LLIntOffsetsExtractor.cpp: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * wasm/WasmCallee.h: (JSC::Wasm::LLIntCallees::create): Deleted. (JSC::Wasm::LLIntCallees::at const): Deleted. (JSC::Wasm::LLIntCallees::data const): Deleted. (JSC::Wasm::LLIntCallees::LLIntCallees): Deleted. * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::create): (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: * wasm/WasmModule.cpp: (JSC::Wasm::Module::Module): (JSC::Wasm::Module::getOrCreateCodeBlock): * wasm/WasmModule.h: 2021-12-17 Saam Barati Use IRC by default on arm64 https://bugs.webkit.org/show_bug.cgi?id=234449 Reviewed by Yusuke Suzuki. I'm seeing a Wasm perf improvement on some benchmarks of ~12% by switching from Briggs to IRC. Let's make IRC the default on arm64. * b3/air/AirAllocateRegistersByGraphColoring.cpp: * b3/air/AirAllocateRegistersByGraphColoring.h: (JSC::B3::Air::useIRC): Deleted. 2021-12-17 Saam Barati Support WasmAddress in B3 CSE https://bugs.webkit.org/show_bug.cgi?id=234051 Reviewed by Filip Pizlo and Yusuke Suzuki. This patch adds support in B3's CSE phase to handle WasmAddressValue computations. The reason this can't partake in pure CSE is that WasmAddressValue reads pinned. To support this, we keep track of which blocks write pinned. If we're trying to replace a value V2 with V1 because it appears there is a redundancy, we check if any paths from V1 to V2 write pinned. If none do, we proceed with the replacement. * b3/B3EliminateCommonSubexpressions.cpp: 2021-12-17 Zan Dobersek [RISCV64] Implement linking and patching support in RISCV64Assembler https://bugs.webkit.org/show_bug.cgi?id=234398 Reviewed by Yusuke Suzuki. Populate RISCV64Assembler class with the necessary implementations and facilities to support linking and patching operations. Implementations of different methods in MacroAssemblerRISCV64 covering calls, jumps and patches are also added. Helper structs are added in the RISCV64Assembler class that cover linking of jumps, calls or branches and patching of pointer values. Relevant methods are also implemented to utilize these helpers. RISCV64Assembler also gains helper methods that generate placeholders for the specific type of linking or patching. The passed-in functor is then invoked, enabling the user (MacroAssemblerRISCV64 implementation) to additionally generate the desired instruction sequence that utilizes the given placeholder. In MacroAssemblerRISCV64, different noop methods covering jumps, calls, linking and patching are replaced with the appropriate implementations. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::readCallTarget): (JSC::MacroAssemblerRISCV64::replaceWithJump): (JSC::MacroAssemblerRISCV64::startOfBranchPtrWithPatchOnRegister): (JSC::MacroAssemblerRISCV64::revertJumpReplacementToBranchPtrWithPatch): (JSC::MacroAssemblerRISCV64::linkCall): (JSC::MacroAssemblerRISCV64::repatchCall): (JSC::MacroAssemblerRISCV64::jump): (JSC::MacroAssemblerRISCV64::farJump): (JSC::MacroAssemblerRISCV64::nearCall): (JSC::MacroAssemblerRISCV64::nearTailCall): (JSC::MacroAssemblerRISCV64::threadSafePatchableNearCall): (JSC::MacroAssemblerRISCV64::ret): (JSC::MacroAssemblerRISCV64::call): (JSC::MacroAssemblerRISCV64::callOperation): (JSC::MacroAssemblerRISCV64::startOfPatchableBranchPtrWithPatchOnAddress): Deleted. (JSC::MacroAssemblerRISCV64::startOfPatchableBranch32WithPatchOnAddress): Deleted. (JSC::MacroAssemblerRISCV64::revertJumpReplacementToPatchableBranchPtrWithPatch): Deleted. (JSC::MacroAssemblerRISCV64::revertJumpReplacementToPatchableBranch32WithPatch): Deleted. * assembler/RISCV64Assembler.h: (JSC::RISCV64Instructions::ImmediateBase::immediateMask): (JSC::RISCV64Instructions::ImmediateBase::v): (JSC::RISCV64Instructions::ImmediateDecomposition::ImmediateDecomposition): (JSC::RISCV64Assembler::getDifferenceBetweenLabels): (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::replaceWithJump): (JSC::RISCV64Assembler::revertJumpReplacementToPatch): (JSC::RISCV64Assembler::readCallTarget): (JSC::RISCV64Assembler::cacheFlush): (JSC::RISCV64Assembler::fillNops): (JSC::RISCV64Assembler::jumpPlaceholder): (JSC::RISCV64Assembler::branchPlaceholder): (JSC::RISCV64Assembler::pointerCallPlaceholder): (JSC::RISCV64Assembler::nearCallPlaceholder): (JSC::RISCV64Assembler::LinkJumpOrCallImpl::apply): (JSC::RISCV64Assembler::LinkJumpImpl::placeholderInsn): (JSC::RISCV64Assembler::LinkJumpImpl::generatePlaceholder): (JSC::RISCV64Assembler::LinkCallImpl::placeholderInsn): (JSC::RISCV64Assembler::LinkCallImpl::generatePlaceholder): (JSC::RISCV64Assembler::LinkBranchImpl::placeholderInsn): (JSC::RISCV64Assembler::LinkBranchImpl::generatePlaceholder): (JSC::RISCV64Assembler::LinkBranchImpl::apply): (JSC::RISCV64Assembler::PatchPointerImpl::placeholderInsn): (JSC::RISCV64Assembler::PatchPointerImpl::generatePlaceholder): (JSC::RISCV64Assembler::PatchPointerImpl::apply): (JSC::RISCV64Assembler::PatchPointerImpl::read): 2021-12-16 Saam Barati Use arm64's fmax/fmin instructions in Wasm https://bugs.webkit.org/show_bug.cgi?id=234367 Reviewed by Keith Miller. This patch adds support in B3 for FMax and FMin. We use this for Wasm's f32/64 min/max operations. On arm64, we select the arm64 fmin/fmax instructions for these B3 opcodes. On x86, we lower these to control flow to calculate the result inside of lower macros. This speeds up Wasm programs that make heavy usage of min/max. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::floatMax): (JSC::MacroAssemblerARM64::floatMin): (JSC::MacroAssemblerARM64::doubleMax): (JSC::MacroAssemblerARM64::doubleMin): * b3/B3Common.h: (JSC::B3::fMax): (JSC::B3::fMin): * b3/B3ConstDoubleValue.cpp: (JSC::B3::ConstDoubleValue::fMinConstant const): (JSC::B3::ConstDoubleValue::fMaxConstant const): * b3/B3ConstDoubleValue.h: * b3/B3ConstFloatValue.cpp: (JSC::B3::ConstFloatValue::fMinConstant const): (JSC::B3::ConstFloatValue::fMaxConstant const): * b3/B3ConstFloatValue.h: * b3/B3LowerMacros.cpp: * b3/B3LowerToAir.cpp: * b3/B3Opcode.cpp: (WTF::printInternal): * b3/B3Opcode.h: * b3/B3ReduceStrength.cpp: * b3/B3Validate.cpp: * b3/B3Value.cpp: (JSC::B3::Value::fMinConstant const): (JSC::B3::Value::fMaxConstant const): (JSC::B3::Value::effects const): (JSC::B3::Value::key const): (JSC::B3::Value::typeFor): * b3/B3Value.h: * b3/B3ValueInlines.h: * b3/B3ValueKey.cpp: (JSC::B3::ValueKey::materialize const): * b3/air/AirOpcode.opcodes: * b3/testb3.h: * b3/testb3_1.cpp: (run): * b3/testb3_7.cpp: (testFMaxMin): (testFloatMaxMin): (testDoubleMaxMin): * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::addFloatingPointMinOrMax): (JSC::Wasm::AirIRGenerator::addOp<:f32min>): * wasm/wasm.json: 2021-12-16 Caitlin Potter [JSC] only emit pointer validation for ARM64E https://bugs.webkit.org/show_bug.cgi?id=234402 Reviewed by Yusuke Suzuki and Mark Lam. JIT thunks no longer emit `push ; pop ;` on non-ARM64E arches with the emitPointerValidation macro. * jit/ThunkGenerators.cpp: (JSC::emitPointerValidation): 2021-12-16 Michael Saboff Create symlinks pointing to alternate root framework locations https://bugs.webkit.org/show_bug.cgi?id=234374 Reviewed by Filip Pizlo. Added build variables and build step to create symlinks pointing to the alternate build locations from the current framework install location. * Configurations/JavaScriptCore.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/create-symlink-to-altroot.sh: Added. 2021-12-16 Devin Rousso Implement Array.prototype.groupBy and Array.prototype.groupByToMap https://bugs.webkit.org/show_bug.cgi?id=234327 Reviewed by Yusuke Suzuki. Implement new Array Grouping proposal , which just reached Stage 3. `Array.prototype.groupBy`/`Array.prototype.groupByToMap` will return a `{}`/`Map` where each value in the array is put into a "bucket" keyed by the return value of the provoded callback. ```js const array = [1, 2, 3, 4]; array.groupBy(n => n % 2 ? "odd" : "even") // { odd: [1, 3], even: [2, 4] } array.groupByToMap(n => n % 2 ? "odd" : "even") // new Map([["odd", [1, 3]], ["even", [2, 4]]) ``` * builtins/ArrayPrototype.js: (groupBy): Added. (groupByToMap): Added. * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): * bytecode/BytecodeIntrinsicRegistry.h: * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_toPropertyKey): Added. Allow `@toPropertyKey` to be used in builtins to convert a value to a property key. This is used to avoid converting the return value of the callback given to `groupBy` more than once. * builtins/BuiltinNames.h: * bytecode/LinkTimeConstant.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): Allow `@Map` to be used in builtins to create a primordial `Map` instance. This is used to avoid side effects when creating and populating the `Map` returned by `groupByToMap`. * runtime/OptionsList.h: Add `useArrayGroupByMethod` option. 2021-12-15 Yusuke Suzuki Rename Wasm::CodeBlock to Wasm::CalleeGroup https://bugs.webkit.org/show_bug.cgi?id=203694 Reviewed by Mark Lam. This is not a CodeBlock. And the name causes confusion with JSC::CodeBlock, which is not at all related. This patch renames it to Wasm::CalleeGroup. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::finalizeUnconditionalFinalizers): (JSC::Heap::deleteAllCodeBlocks): * heap/Heap.h: (JSC::Heap::forEachCodeBlockSpace): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::BBQPlan): (JSC::Wasm::BBQPlan::work): * wasm/WasmBBQPlan.h: * wasm/WasmCalleeGroup.cpp: Renamed from Source/JavaScriptCore/wasm/WasmCodeBlock.cpp. (JSC::Wasm::CalleeGroup::create): (JSC::Wasm::CalleeGroup::createFromExisting): (JSC::Wasm::CalleeGroup::CalleeGroup): (JSC::Wasm::CalleeGroup::~CalleeGroup): (JSC::Wasm::CalleeGroup::waitUntilFinished): (JSC::Wasm::CalleeGroup::compileAsync): (JSC::Wasm::CalleeGroup::isSafeToRun): (JSC::Wasm::CalleeGroup::setCompilationFinished): * wasm/WasmCalleeGroup.h: Renamed from Source/JavaScriptCore/wasm/WasmCodeBlock.h. * wasm/WasmInstance.cpp: (JSC::Wasm::Instance::initElementSegment): * wasm/WasmInstance.h: (JSC::Wasm::Instance::calleeGroup const): (JSC::Wasm::Instance::isImportFunction const): (JSC::Wasm::Instance::codeBlock const): Deleted. * wasm/WasmMachineThreads.h: * wasm/WasmModule.cpp: (JSC::Wasm::Module::getOrCreateCalleeGroup): (JSC::Wasm::Module::compileSync): (JSC::Wasm::Module::compileAsync): (JSC::Wasm::Module::copyInitialCalleeGroupToAllMemoryModes): (JSC::Wasm::Module::getOrCreateCodeBlock): Deleted. (JSC::Wasm::Module::copyInitialCodeBlockToAllMemoryModes): Deleted. * wasm/WasmModule.h: (JSC::Wasm::Module::calleeGroupFor): (JSC::Wasm::Module::codeBlockFor): Deleted. * wasm/WasmOMGForOSREntryPlan.cpp: (JSC::Wasm::OMGForOSREntryPlan::OMGForOSREntryPlan): (JSC::Wasm::OMGForOSREntryPlan::work): * wasm/WasmOMGForOSREntryPlan.h: * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::OMGPlan): (JSC::Wasm::OMGPlan::work): * wasm/WasmOMGPlan.h: * wasm/WasmOperations.cpp: (JSC::Wasm::triggerOMGReplacementCompile): (JSC::Wasm::JSC_DEFINE_JIT_OPERATION): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::updateCallSitesToCallUs): * wasm/WasmPlan.h: * wasm/WasmSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): (JSC::LLInt::doWasmCall): * wasm/js/JSWebAssembly.cpp: (JSC::resolve): (JSC::instantiate): * wasm/js/JSWebAssemblyCalleeGroup.cpp: Renamed from Source/JavaScriptCore/wasm/js/JSWebAssemblyCodeBlock.cpp. (JSC::JSWebAssemblyCalleeGroup::create): (JSC::JSWebAssemblyCalleeGroup::JSWebAssemblyCalleeGroup): (JSC::JSWebAssemblyCalleeGroup::finishCreation): (JSC::JSWebAssemblyCalleeGroup::destroy): (JSC::JSWebAssemblyCalleeGroup::clearJSCallICs): (JSC::JSWebAssemblyCalleeGroup::visitChildrenImpl): (JSC::JSWebAssemblyCalleeGroup::finalizeUnconditionally): * wasm/js/JSWebAssemblyCalleeGroup.h: Renamed from Source/JavaScriptCore/wasm/js/JSWebAssemblyCodeBlock.h. * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::visitChildrenImpl): (JSC::JSWebAssemblyInstance::finalizeCreation): * wasm/js/JSWebAssemblyInstance.h: * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::calleeGroup): (JSC::JSWebAssemblyModule::setCalleeGroup): (JSC::JSWebAssemblyModule::visitChildrenImpl): (JSC::JSWebAssemblyModule::codeBlock): Deleted. (JSC::JSWebAssemblyModule::setCodeBlock): Deleted. * wasm/js/JSWebAssemblyModule.h: * wasm/js/WebAssemblyFunction.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::initializeImportsAndExports): * wasm/js/WebAssemblyWrapperFunction.h: 2021-12-15 Joseph Griego [Shadow Realms] Wrapped functions must only throw TypeError from calling realm https://bugs.webkit.org/show_bug.cgi?id=234357 Reviewed by Yusuke Suzuki. This wrapping logic already exists for ShadowRealm.prototype.evaluate but not for calls to wrapped functions. at present, this requires some awkward manouvering to actually throw a typeerror from the shadow realm, since the wrapper code always runs in the incubating realm. Hopefully we can make this less messy soon by replacing this implementation with one more integrated with the runtime. This case wasn't covered by existing JSC or test262 tests; added coverage both upstream in t262 and in this patch. * builtins/ShadowRealmPrototype.js: (wrapped): (globalPrivate.wrap): 2021-12-14 Ross Kirsling [JSC] OpInstanceofCustom should be in CommonSlowPaths https://bugs.webkit.org/show_bug.cgi?id=234316 Reviewed by Alexey Shvayka. No tier has a fast path for OpInstanceofCustom and this is unlikely to change anytime soon. As such, we should not be having LLInt and Baseline implement *separate* slow paths for this operation; this patch straightforwardly makes use of CommonSlowPaths instead. * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_instanceof_custom): Deleted. (JSC::JIT::emitSlow_op_instanceof_custom): Deleted. * llint/LLIntSlowPaths.cpp: * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * runtime/CommonSlowPaths.cpp: (JSC::JSC_DEFINE_COMMON_SLOW_PATH): * runtime/CommonSlowPaths.h: 2021-12-14 Jean-Yves Avenard Rename SharedBuffer classes. https://bugs.webkit.org/show_bug.cgi?id=233677 rdar://problem/85963900 Reviewed by Youenn Fablet. SharedBuffer are renamed FragmentedSharedBuffer and ContiguousSharedBuffer to SharedBuffer to better reflect their actual types. * runtime/ArrayBuffer.h: 2021-12-13 Saam Barati WasmB3IRGenerator should estimate static execution counts https://bugs.webkit.org/show_bug.cgi?id=234284 Reviewed by Filip Pizlo. This enables the register allocator to make better decisions. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * b3/B3BasicBlock.h: (JSC::B3::BasicBlock::setFrequency): * b3/B3EstimateStaticExecutionCounts.cpp: Added. (JSC::B3::estimateStaticExecutionCounts): * b3/B3EstimateStaticExecutionCounts.h: Added. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): 2021-12-13 Brady Eidson Teach webpushtool to register and "host" the daemon. https://bugs.webkit.org/show_bug.cgi?id=234265 Reviewed by Tim Horton. * inspector/ConsoleMessage.h: Remove `using JSC::MessageType` because it makes it hard for others to also have a `MessageType` type. * inspector/JSGlobalObjectConsoleClient.h: * runtime/ConsoleTypes.h: 2021-12-13 Saam Barati Roll back r286345, r286387, r286471, r286667, r286849 https://bugs.webkit.org/show_bug.cgi?id=234268 Reviewed by Mark Lam. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/AccessCase.cpp: (JSC::AccessCase::AccessCase): (JSC::AccessCase::forEachDependentCell const): (JSC::AccessCase::dump const): (JSC::AccessCase::propagateTransitions const): (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::canBeShared): * bytecode/AccessCase.h: (JSC::AccessCase::structure const): (JSC::AccessCase::newStructure const): (JSC::AccessCase::hash const): (JSC::AccessCase::AccessCase): * bytecode/ArrayProfile.cpp: (JSC::ArrayProfile::computeUpdatedPrediction): * bytecode/ArrayProfile.h: * bytecode/CheckPrivateBrandStatus.cpp: (JSC::CheckPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::determineLiveness): (JSC::CodeBlock::finalizeLLIntInlineCaches): (JSC::CodeBlock::stronglyVisitWeakReferences): * bytecode/DeleteByStatus.cpp: (JSC::DeleteByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/GetByIdMetadata.h: (JSC::GetByIdModeMetadata::GetByIdModeMetadata): (JSC::GetByIdModeMetadata::clearToDefaultModeWithoutCache): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeFromLLInt): (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/InByStatus.cpp: (JSC::InByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/InlineAccess.cpp: (JSC::InlineAccess::rewireStubAsJumpInAccess): (JSC::InlineAccess::resetStubAsJumpInAccess): * bytecode/InstanceOfStatus.cpp: (JSC::InstanceOfStatus::computeForStubInfo): * bytecode/InternalFunctionAllocationProfile.h: (JSC::InternalFunctionAllocationProfile::offsetOfStructure): (JSC::InternalFunctionAllocationProfile::structure): (JSC::InternalFunctionAllocationProfile::clear): (JSC::InternalFunctionAllocationProfile::visitAggregate): (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase): (JSC::InternalFunctionAllocationProfile::offsetOfStructureID): Deleted. * bytecode/PolyProtoAccessChain.cpp: (JSC::PolyProtoAccessChain::needImpurePropertyWatchpoint const): * bytecode/PolyProtoAccessChain.h: * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::visitWeak const): * bytecode/PutByIdFlags.h: * bytecode/PutByStatus.cpp: (JSC::PutByStatus::computeFromLLInt): (JSC::PutByStatus::computeForStubInfo): * bytecode/SetPrivateBrandStatus.cpp: (JSC::SetPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/SpeculatedType.cpp: (JSC::speculationFromCell): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::initGetByIdSelf): (JSC::StructureStubInfo::initPutByIdReplace): (JSC::StructureStubInfo::initInByIdSelf): (JSC::StructureStubInfo::deref): (JSC::StructureStubInfo::aboutToDie): (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::reset): (JSC::StructureStubInfo::visitAggregateImpl): (JSC::StructureStubInfo::visitWeakReferences): (JSC::StructureStubInfo::propagateTransitions): (JSC::StructureStubInfo::summary const): (JSC::StructureStubInfo::containsPC const): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::offsetOfByIdSelfOffset): (JSC::StructureStubInfo::offsetOfInlineAccessBaseStructure): (JSC::StructureStubInfo::inlineAccessBaseStructure): (JSC::StructureStubInfo::offsetOfInlineAccessBaseStructureID): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::branchWeakStructure): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::finalize): * dfg/DFGSpeculativeJIT.cpp: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined): (JSC::DFG::SpeculativeJIT::compileToBooleanObjectOrOther): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::emitUntypedBranch): (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise): (JSC::FTL::DFG::LowerDFGToB3::compileCreateInternalFieldObject): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * heap/AbstractSlotVisitor.h: * heap/AbstractSlotVisitorInlines.h: * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::runEndPhase): * heap/Heap.h: (JSC::Heap::structureIDTable): * heap/IsoAlignedMemoryAllocator.cpp: (JSC::IsoAlignedMemoryAllocator::IsoAlignedMemoryAllocator): (JSC::IsoAlignedMemoryAllocator::~IsoAlignedMemoryAllocator): (JSC::IsoAlignedMemoryAllocator::tryAllocateAlignedMemory): (JSC::IsoAlignedMemoryAllocator::freeAlignedMemory): (JSC::IsoAlignedMemoryAllocator::tryMallocBlock): Deleted. (JSC::IsoAlignedMemoryAllocator::freeBlock): Deleted. (JSC::IsoAlignedMemoryAllocator::commitBlock): Deleted. (JSC::IsoAlignedMemoryAllocator::decommitBlock): Deleted. * heap/IsoAlignedMemoryAllocator.h: * heap/IsoMemoryAllocatorBase.cpp: Removed. * heap/IsoMemoryAllocatorBase.h: Removed. * heap/IsoSubspace.cpp: (JSC::IsoSubspace::IsoSubspace): (JSC::IsoSubspace::tryAllocateFromLowerTier): * heap/IsoSubspace.h: * heap/PreciseAllocation.cpp: (JSC::PreciseAllocation::createForLowerTier): (JSC::PreciseAllocation::tryCreateForLowerTier): Deleted. * heap/PreciseAllocation.h: * heap/SlotVisitor.cpp: (JSC::SlotVisitor::appendJSCellOrAuxiliary): * heap/SlotVisitor.h: * heap/SlotVisitorInlines.h: * heap/StructureAlignedMemoryAllocator.cpp: Removed. * heap/StructureAlignedMemoryAllocator.h: Removed. * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo): (JSC::AssemblyHelpers::emitLoadStructure): (JSC::AssemblyHelpers::emitLoadPrototype): (JSC::AssemblyHelpers::emitRandomThunk): (JSC::AssemblyHelpers::emitConvertValueToBoolean): (JSC::AssemblyHelpers::branchIfValue): (JSC::AssemblyHelpers::emitNonNullDecodeStructureID): Deleted. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchStructure): (JSC::AssemblyHelpers::nukeStructureAndStoreButterfly): * jit/GCAwareJITStubRoutine.cpp: (JSC::PolymorphicAccessJITStubRoutine::computeHash): * jit/JITInlineCacheGenerator.cpp: (JSC::generateGetByIdInlineAccess): (JSC::JITPutByIdGenerator::generateBaselineDataICFastPath): (JSC::JITInByIdGenerator::generateBaselineDataICFastPath): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_typeof_is_undefined): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_get_prototype_of): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_property_enumerator): * jit/JITStubRoutine.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::performLLIntGetByID): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArrayPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/BigIntPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/BooleanPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/CommonSlowPaths.cpp: (JSC::JSC_DEFINE_COMMON_SLOW_PATH): * runtime/DatePrototype.cpp: (JSC::formateDateInstance): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::sanitizedMessageString): (JSC::ErrorInstance::sanitizedNameString): (JSC::ErrorInstance::sanitizedToString): * runtime/ErrorPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::visitChildrenImpl): * runtime/FunctionExecutable.h: * runtime/FunctionPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/FunctionRareData.cpp: (JSC::FunctionRareData::visitChildrenImpl): * runtime/FunctionRareData.h: * runtime/HasOwnPropertyCache.h: * runtime/InitializeThreading.cpp: (JSC::initialize): * runtime/JSCConfig.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::dumpInContextAssumingStructure const): (JSC::JSValue::dumpForBacktrace const): * runtime/JSCell.cpp: (JSC::JSCell::toObjectSlow const): * runtime/JSCell.h: (JSC::JSCell::clearStructure): * runtime/JSCellInlines.h: (JSC::JSCell::structure const): (JSC::JSCell::setStructure): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::visitChildrenImpl): * runtime/JSGlobalObject.h: * runtime/JSObject.cpp: (JSC::JSObject::visitButterflyImpl): (JSC::JSObject::createInitialUndecided): (JSC::JSObject::createInitialInt32): (JSC::JSObject::createInitialDouble): (JSC::JSObject::createInitialContiguous): (JSC::JSObject::createArrayStorage): (JSC::JSObject::convertUndecidedToArrayStorage): (JSC::JSObject::convertInt32ToArrayStorage): (JSC::JSObject::convertDoubleToArrayStorage): (JSC::JSObject::convertContiguousToArrayStorage): (JSC::JSObject::putDirectCustomGetterSetterWithoutTransition): (JSC::JSObject::putDirectNonIndexAccessorWithoutTransition): * runtime/JSObject.h: (JSC::JSObject::nukeStructureAndSetButterfly): (JSC::JSObject::getPropertySlot): * runtime/JSObjectInlines.h: (JSC::JSObject::getPropertySlot): (JSC::JSObject::getNonIndexPropertySlot): (JSC::JSObject::putDirectWithoutTransition): (JSC::JSObject::putDirectInternal): * runtime/JSPropertyNameEnumerator.cpp: (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator): (JSC::JSPropertyNameEnumerator::visitChildrenImpl): * runtime/JSPropertyNameEnumerator.h: * runtime/NumberPrototype.cpp: (JSC::toThisNumber): * runtime/ObjectPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::objectPrototypeToString): * runtime/RegExpPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/StringPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::~Structure): (JSC::Structure::flattenDictionaryStructure): (JSC::Structure::dump const): (JSC::Structure::canCachePropertyNameEnumerator const): * runtime/Structure.h: (JSC::Structure::id const): * runtime/StructureChain.cpp: (JSC::StructureChain::create): (JSC::StructureChain::visitChildrenImpl): * runtime/StructureID.h: Removed. * runtime/StructureIDBlob.h: (JSC::StructureIDBlob::StructureIDBlob): * runtime/StructureIDTable.cpp: Added. (JSC::StructureIDTable::StructureIDTable): (JSC::StructureIDTable::makeFreeListFromRange): (JSC::StructureIDTable::resize): (JSC::StructureIDTable::flushOldTables): (JSC::StructureIDTable::allocateID): (JSC::StructureIDTable::deallocateID): * runtime/StructureIDTable.h: Added. (JSC::nukedStructureIDBit): (JSC::nuke): (JSC::isNuked): (JSC::decontaminate): (JSC::StructureIDTable::base): (JSC::StructureIDTable::size const): (JSC::StructureIDTable::table const): (JSC::StructureIDTable::decode): (JSC::StructureIDTable::encode): (JSC::StructureIDTable::get): (JSC::StructureIDTable::tryGet): (JSC::StructureIDTable::validate): (JSC::StructureIDTable::deallocateID): (JSC::StructureIDTable::allocateID): (JSC::StructureIDTable::flushOldTables): * runtime/StructureRareData.cpp: (JSC::StructureRareData::StructureRareData): * runtime/StructureRareData.h: * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::tryCachePropertyNameEnumeratorViaWatchpoint): * runtime/SymbolPrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/TypeProfilerLog.cpp: (JSC::TypeProfilerLog::processLogEntries): (JSC::TypeProfilerLog::visit): * runtime/VM.h: (JSC::VM::getStructure): (JSC::VM::tryGetStructure): * runtime/WriteBarrier.h: (JSC::WriteBarrierStructureID::WriteBarrierStructureID): Deleted. (JSC::WriteBarrierStructureID::get const): Deleted. (JSC::WriteBarrierStructureID::operator* const): Deleted. (JSC::WriteBarrierStructureID::operator-> const): Deleted. (JSC::WriteBarrierStructureID::clear): Deleted. (JSC::WriteBarrierStructureID::operator bool const): Deleted. (JSC::WriteBarrierStructureID::operator! const): Deleted. (JSC::WriteBarrierStructureID::setWithoutWriteBarrier): Deleted. (JSC::WriteBarrierStructureID::unvalidatedGet const): Deleted. (JSC::WriteBarrierStructureID::value const): Deleted. * runtime/WriteBarrierInlines.h: (JSC::WriteBarrierStructureID::set): Deleted. (JSC::WriteBarrierStructureID::setMayBeNull): Deleted. (JSC::WriteBarrierStructureID::setEarlyValue): Deleted. * tools/HeapVerifier.cpp: (JSC::HeapVerifier::validateJSCell): * tools/Integrity.cpp: * tools/Integrity.h: * tools/IntegrityInlines.h: (JSC::Integrity::auditStructureID): * tools/JSDollarVM.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::JSDollarVM::finishCreation): (JSC::JSDollarVM::visitChildrenImpl): * tools/JSDollarVM.h: * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::jsCallEntrypointSlow): * wasm/js/WebAssemblyGlobalPrototype.cpp: (JSC::getGlobal): 2021-12-13 Yusuke Suzuki [JSC] Use FixedVector for wasm exception in Wasm::Instance https://bugs.webkit.org/show_bug.cgi?id=234224 Reviewed by Saam Barati. Since we know # of exception tags when instantiating Wasm::Instance, we can use FixedVector instead of Vector. This is the same to Table, Functions etc. We also remove Wasm::Tag::m_id. Since we do not copy Wasm::Tag and we always allocate Wasm::Tag from heap, we can just use pointer comparison. Then, we do not need to have this m_id. * wasm/WasmInstance.cpp: (JSC::Wasm::Instance::Instance): (JSC::Wasm::Instance::setTag): (JSC::Wasm::Instance::addTag): Deleted. * wasm/WasmInstance.h: * wasm/WasmModuleInformation.h: (JSC::Wasm::ModuleInformation::internalExceptionCount const): * wasm/WasmTag.cpp: * wasm/WasmTag.h: (JSC::Wasm::Tag::create): Deleted. (JSC::Wasm::Tag::parameterCount const): Deleted. (JSC::Wasm::Tag::parameter const): Deleted. (JSC::Wasm::Tag::operator== const): Deleted. (JSC::Wasm::Tag::operator!= const): Deleted. (JSC::Wasm::Tag::signature const): Deleted. (JSC::Wasm::Tag::Tag): Deleted. * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::initializeImportsAndExports): 2021-12-13 waddlesplash ExecutableAllocator: Do not store things in g_config when USE(SYSTEM_MALLOC). https://bugs.webkit.org/show_bug.cgi?id=232165 Reviewed by Yusuke Suzuki. Following r281910 two additional slots were added to g_config in order to store these pointers for use in bmalloc and Gigacage. However, when USE(SYSTEM_MALLOC) is enabled, there are no slots reserved for Gigacage, and so this collided with g_wtfConfig and overwrote data there instead. This should fix crashes seen on Haiku, which enables USE(SYSTEM_MALLOC). * jit/ExecutableAllocator.cpp: (JSC::initializeJITPageReservation): 2021-12-13 Elliott Williams Deployment target for macOS 11+ does not follow minor version bumps https://bugs.webkit.org/show_bug.cgi?id=233906 Reviewed by Alexey Proskuryakov. * Configurations/DebugRelease.xcconfig: 2021-12-13 Adrian Perez de Castro Unreviewed build fix after r286936 * wasm/WasmOSREntryData.h: Replace wrong inclusion of wtf/Vector.h (unused) with the correct wtf/FixedVector.h one. * wasm/WasmTierUpCount.h: Add missing WasmOSREntryData.h inclusion. 2021-12-13 Zan Dobersek [RISCV64] Add MacroAssemblerRISCV64 implementations for trivial floating-point-register operations https://bugs.webkit.org/show_bug.cgi?id=234223 Reviewed by Yusuke Suzuki. Add implementations for the trivial floating-point register operations in MacroAssemblerRISCV64. This covers moves, loads, stores, arithmetics, basic conversion and truncation and the lightweight logical operations. The two floating-point temporary registers needed in some operations are listed. The rounding and comparison operations are left for later as they require a more complex implementation due to the necessary manual NaN checks. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::swap): (JSC::MacroAssemblerRISCV64::moveZeroToFloat): (JSC::MacroAssemblerRISCV64::moveZeroToDouble): (JSC::MacroAssemblerRISCV64::moveFloat): (JSC::MacroAssemblerRISCV64::moveFloatTo32): (JSC::MacroAssemblerRISCV64::move32ToFloat): (JSC::MacroAssemblerRISCV64::moveDouble): (JSC::MacroAssemblerRISCV64::moveDoubleTo64): (JSC::MacroAssemblerRISCV64::move64ToDouble): (JSC::MacroAssemblerRISCV64::loadFloat): (JSC::MacroAssemblerRISCV64::loadDouble): (JSC::MacroAssemblerRISCV64::storeFloat): (JSC::MacroAssemblerRISCV64::storeDouble): (JSC::MacroAssemblerRISCV64::addFloat): (JSC::MacroAssemblerRISCV64::addDouble): (JSC::MacroAssemblerRISCV64::subFloat): (JSC::MacroAssemblerRISCV64::subDouble): (JSC::MacroAssemblerRISCV64::mulFloat): (JSC::MacroAssemblerRISCV64::mulDouble): (JSC::MacroAssemblerRISCV64::divFloat): (JSC::MacroAssemblerRISCV64::divDouble): (JSC::MacroAssemblerRISCV64::sqrtFloat): (JSC::MacroAssemblerRISCV64::sqrtDouble): (JSC::MacroAssemblerRISCV64::absFloat): (JSC::MacroAssemblerRISCV64::absDouble): (JSC::MacroAssemblerRISCV64::andFloat): (JSC::MacroAssemblerRISCV64::andDouble): (JSC::MacroAssemblerRISCV64::orFloat): (JSC::MacroAssemblerRISCV64::orDouble): (JSC::MacroAssemblerRISCV64::negateFloat): (JSC::MacroAssemblerRISCV64::negateDouble): (JSC::MacroAssemblerRISCV64::convertInt32ToFloat): (JSC::MacroAssemblerRISCV64::convertInt32ToDouble): (JSC::MacroAssemblerRISCV64::convertInt64ToFloat): (JSC::MacroAssemblerRISCV64::convertInt64ToDouble): (JSC::MacroAssemblerRISCV64::convertUInt64ToFloat): (JSC::MacroAssemblerRISCV64::convertUInt64ToDouble): (JSC::MacroAssemblerRISCV64::convertFloatToDouble): (JSC::MacroAssemblerRISCV64::convertDoubleToFloat): (JSC::MacroAssemblerRISCV64::truncateFloatToInt32): (JSC::MacroAssemblerRISCV64::truncateFloatToUint32): (JSC::MacroAssemblerRISCV64::truncateFloatToInt64): (JSC::MacroAssemblerRISCV64::truncateFloatToUint64): (JSC::MacroAssemblerRISCV64::truncateDoubleToInt32): (JSC::MacroAssemblerRISCV64::truncateDoubleToUint32): (JSC::MacroAssemblerRISCV64::truncateDoubleToInt64): (JSC::MacroAssemblerRISCV64::truncateDoubleToUint64): 2021-12-12 Zan Dobersek [RISCV64] Add MacroAssemblerRISCV64 implementations for trivial general-purpose-register operations https://bugs.webkit.org/show_bug.cgi?id=233992 Reviewed by Yusuke Suzuki. Add implementations for the trivial general-purpose-register operations in MacroAssemblerRISCV64. This covers non-patchable loads and stores, shifts, logical operations, zero- and sign-extensions, moves and swaps, stack operations as well as miscellaneous operations like aborts, breakpoints and nops. The loadImmediate helper methods are added to handle loading of different types of immediate values. This should replace move() calls when a sign-extended immediate load is desired, whereas move() for a 32-bit immediate is expected to perform no sign extension. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::add32): (JSC::MacroAssemblerRISCV64::add64): (JSC::MacroAssemblerRISCV64::sub32): (JSC::MacroAssemblerRISCV64::mul32): (JSC::MacroAssemblerRISCV64::lshift32): (JSC::MacroAssemblerRISCV64::lshift64): (JSC::MacroAssemblerRISCV64::rshift32): (JSC::MacroAssemblerRISCV64::rshift64): (JSC::MacroAssemblerRISCV64::urshift32): (JSC::MacroAssemblerRISCV64::urshift64): (JSC::MacroAssemblerRISCV64::load8): (JSC::MacroAssemblerRISCV64::load8SignedExtendTo32): (JSC::MacroAssemblerRISCV64::load16): (JSC::MacroAssemblerRISCV64::load16Unaligned): (JSC::MacroAssemblerRISCV64::load16SignedExtendTo32): (JSC::MacroAssemblerRISCV64::load32): (JSC::MacroAssemblerRISCV64::load32WithUnalignedHalfWords): (JSC::MacroAssemblerRISCV64::load64): (JSC::MacroAssemblerRISCV64::loadPair32): (JSC::MacroAssemblerRISCV64::store8): (JSC::MacroAssemblerRISCV64::store16): (JSC::MacroAssemblerRISCV64::store32): (JSC::MacroAssemblerRISCV64::store64): (JSC::MacroAssemblerRISCV64::storePair32): (JSC::MacroAssemblerRISCV64::zeroExtend8To32): (JSC::MacroAssemblerRISCV64::zeroExtend16To32): (JSC::MacroAssemblerRISCV64::zeroExtend32ToWord): (JSC::MacroAssemblerRISCV64::signExtend8To32): (JSC::MacroAssemblerRISCV64::signExtend16To32): (JSC::MacroAssemblerRISCV64::signExtend32ToPtr): (JSC::MacroAssemblerRISCV64::and32): (JSC::MacroAssemblerRISCV64::and64): (JSC::MacroAssemblerRISCV64::or8): (JSC::MacroAssemblerRISCV64::or16): (JSC::MacroAssemblerRISCV64::or32): (JSC::MacroAssemblerRISCV64::or64): (JSC::MacroAssemblerRISCV64::xor32): (JSC::MacroAssemblerRISCV64::xor64): (JSC::MacroAssemblerRISCV64::not32): (JSC::MacroAssemblerRISCV64::not64): (JSC::MacroAssemblerRISCV64::neg32): (JSC::MacroAssemblerRISCV64::neg64): (JSC::MacroAssemblerRISCV64::move): (JSC::MacroAssemblerRISCV64::swap): (JSC::MacroAssemblerRISCV64::push): (JSC::MacroAssemblerRISCV64::pushPair): (JSC::MacroAssemblerRISCV64::pop): (JSC::MacroAssemblerRISCV64::popPair): (JSC::MacroAssemblerRISCV64::abortWithReason): (JSC::MacroAssemblerRISCV64::breakpoint): (JSC::MacroAssemblerRISCV64::nop): (JSC::MacroAssemblerRISCV64::loadImmediate): 2021-12-12 Yusuke Suzuki [JSC] Use FixedVector to shrink some of Wasm data structures https://bugs.webkit.org/show_bug.cgi?id=234206 Reviewed by Saam Barati. We can use FixedVector to shrink some of Wasm data structures including Wasm::Callee. * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::PatchpointExceptionHandle::generate const): (JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck): * wasm/WasmCallee.cpp: (JSC::Wasm::LLIntCallee::linkExceptionHandlers): (JSC::Wasm::OptimizingJITCallee::linkExceptionHandlers): (JSC::Wasm::OptimizingJITCallee::stackmap const): * wasm/WasmCallee.h: (JSC::Wasm::Callee::hasExceptionHandlers const): (JSC::Wasm::JITCallee::wasmToWasmCallsites): (JSC::Wasm::OptimizingJITCallee::OptimizingJITCallee): * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: * wasm/WasmHandlerInfo.cpp: (JSC::Wasm::HandlerInfo::handlerForIndex): * wasm/WasmHandlerInfo.h: * wasm/WasmOSREntryData.h: (JSC::Wasm::OSREntryData::OSREntryData): (JSC::Wasm::OSREntryData::values): (JSC::Wasm::OSREntryValue::OSREntryValue): Deleted. (JSC::Wasm::OSREntryValue::type const): Deleted. * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::updateCallSitesToCallUs): * wasm/WasmTierUpCount.cpp: (JSC::Wasm::TierUpCount::addOSREntryData): * wasm/WasmTierUpCount.h: * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock): * wasm/js/JSWebAssemblyCodeBlock.h: 2021-12-11 Saam Barati Teach the sampling profiler how to display origin data for B3 Wasm https://bugs.webkit.org/show_bug.cgi?id=234097 Reviewed by Yusuke Suzuki. This teaches the SamplingProfiler how to gather origin data for Wasm. We reuse the PCToCodeOriginMap from JS, and store the wasm function offset data inside of CodeOrigin's BytecodeIndex. For now, this patch is only doing this for B3, because the Air backend doesn't currently generate filled in OpcodeOrigin data. We'll fix that in: https://bugs.webkit.org/show_bug.cgi?id=234182 Also, this capability isn't yet supported in Web Inspector. We'll want to do that in a future change as we improve Web Inspector's ability to debug Wasm code. When that time comes, we'll have to generate the PCToCodeOriginMap based on debugging info, and not just 'useSamplingProfiler' JSC option. The data now shows up like this for hottest bytecodes: Hottest bytecodes as 524 '>.wasm-function[2373]:OMG:0x21a' 414 '>.wasm-function[2363]:OMG:0x1ae' 395 '>.wasm-function[2373]:OMG:0x418' 354 '>.wasm-function[2373]:OMG:0x34f' 270 '>.wasm-function[2373]:OMG:0x352' 256 '>.wasm-function[2363]:OMG:0x152' * ftl/FTLCompile.cpp: (JSC::FTL::compile): * jit/PCToCodeOriginMap.cpp: (JSC::PCToCodeOriginMapBuilder::PCToCodeOriginMapBuilder): * jit/PCToCodeOriginMap.h: * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::recordJITFrame): (JSC::SamplingProfiler::processUnverifiedStackTraces): (JSC::SamplingProfiler::reportTopBytecodes): * runtime/SamplingProfiler.h: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::origin): (JSC::Wasm::parseAndCompileAir): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): (JSC::Wasm::computePCToCodeOriginMap): * wasm/WasmB3IRGenerator.h: (): Deleted. * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::work): (JSC::Wasm::BBQPlan::didCompleteCompilation): (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmCalleeRegistry.h: (JSC::Wasm::CalleeRegistry::unregisterCallee): (JSC::Wasm::CalleeRegistry::addPCToCodeOriginMap): (JSC::Wasm::CalleeRegistry::WTF_REQUIRES_LOCK): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/WasmOpcodeOrigin.h: (JSC::Wasm::OpcodeOrigin::OpcodeOrigin): 2021-12-11 Mark Lam Automatically forbid JS execution when we throw a TerminationException. https://bugs.webkit.org/show_bug.cgi?id=234188 Reviewed by Yusuke Suzuki. For Worker threads, we throw a TerminationException when Worker.terminate() is called. Once the TerminationException is thrown, we expect to completely unwind out of any JS frames on the stack, and we also expect the client to never call into JS again. Previously, WebCore will call VM:setExecutionForbidden() to flag that we should not re-enter the VM anymore. On JSC side, this executionForbidden() is used to prevent micro-tasks from firing. On WebCore side, it is used to prevent many things from running, including firing events. Previously, we reply on WebCore side to catch the TerminationException, determine that it is the TerminationException, and then call VM:setExecutionForbidden(). This is tedious and error prone as there may be places in WebCore that should call VM:setExecutionForbidden() but is missed. This has been the source of some bugs with the handling of the Worker termination in the past. In this patch, we change VM to setExecutionForbidden() immediately when we throw the TerminationException, but only if VM::m_executionForbiddenOnTermination is set. Currently, we'll only set VM:m_executionForbiddenOnTermination for Workers because for legacy reasons, other clients of JSC has the ability to re-enter the VM after a TerminationException unwinds out (which is ok to do when used under some controlled conditions). Until we can determine that it is safe to adopt this "execution forbidden on termination" behavior universally, we'll adopt it only for workers. In a subsequent patch, we can also look into removing all the places in WebCore that checks for TerminationException in order to call VM:setExecutionForbidden(). We'll leave those in place for now though they should be redundant after this patch. Also add some ASSERTs to document invariants regarding states used in the handing of TerminationException. * runtime/VM.cpp: (JSC::VM::setException): (JSC::VM::throwTerminationException): * runtime/VM.h: (JSC::VM::forbidExecutionOnTermination): 2021-12-10 Yusuke Suzuki [JSC] Wasm catch thunk should be JIT code to use ExceptionHandlerPtrTag https://bugs.webkit.org/show_bug.cgi?id=234183 Reviewed by Tadeu Zagallo. ExceptionHandlerPtrTag is only usable for JITCode. Thus, we should not tag wasm catch LLInt code with it. This patch fixes it by using trampoline. This is the same to normal LLInt's handleCatchThunk. * assembler/JITOperationList.cpp: (JSC::JITOperationList::populatePointersInJavaScriptCoreForLLInt): * llint/LLIntExceptions.cpp: (JSC::LLInt::handleWasmCatch): (JSC::LLInt::handleWasmCatchAll): * llint/LLIntThunks.cpp: (JSC::LLInt::handleWasmCatchThunk): (JSC::LLInt::handleWasmCatchAllThunk): * llint/LLIntThunks.h: 2021-12-10 Michael Saboff https://bugs.webkit.org/show_bug.cgi?id=234173 Update Install Paths for build system changes Reviewed by Yusuke Suzuki. Updated install paths for changes in the build system that use a system path prefix. * Configurations/Base.xcconfig: 2021-12-10 Mikhail R. Gadelha [JSC][32bit] Add callee save registers for MIPS https://bugs.webkit.org/show_bug.cgi?id=233766 Reviewed by Mark Lam. This patch enables callee save registers for mips, which fixes an assertion violation from the call frame shufflers in some tests if jsc was built with assertions enabled (either debug or release+assert mode). * jit/RegisterSet.cpp: (JSC::RegisterSet::llintBaselineCalleeSaveRegisters): (JSC::RegisterSet::dfgCalleeSaveRegisters): 2021-12-10 Yusuke Suzuki [JSC] isTaggedJSCCodePtrImpl does not have proper implementation for JITCage & JITCode combination https://bugs.webkit.org/show_bug.cgi?id=234186 Reviewed by Mark Lam. If JITCage is enabled and target code is JITCode, we should use tagJSCCodePtrImpl. * runtime/JSCPtrTag.h: (JSC::isTaggedJSCCodePtrImpl): 2021-12-10 Don Olmstead Add FileSystem function to read a file at a path https://bugs.webkit.org/show_bug.cgi?id=234103 Reviewed by Alex Christensen. Use FileSystem::readEntireFile. * inspector/remote/socket/RemoteInspectorSocket.cpp: (Inspector::RemoteInspector::backendCommands const): 2021-12-10 Tadeu Zagallo Remove Mac-specific ARM64EHash implementation https://bugs.webkit.org/show_bug.cgi?id=234150 Reviewed by Saam Barati. Currently we have a weaker implementation of ARM64EHash on mac, but we measured it and it's not any faster than the stricter version we use on iOS. We are removing the mac-specific version and switching it to use the stricter version. * assembler/AssemblerBuffer.h: 2021-12-10 Adrian Perez de Castro Non-unified build fixes, mid December 2021 edition https://bugs.webkit.org/show_bug.cgi?id=234106 Unreviewed non-unified build fixes. * wasm/js/WasmToJS.h: Remove unneeded forward declaration of CallLinkInfo, add forward declaration of OptimizingCallLinkInfo. 2021-12-09 Alex Christensen Prepare for transition to C++20 https://bugs.webkit.org/show_bug.cgi?id=234022 Reviewed by Yusuke Suzuki. * bytecode/SuperSampler.cpp: * bytecode/SuperSampler.h: * heap/GCSegmentedArray.h: (JSC::GCSegmentedArrayIterator::operator== const): (JSC::GCSegmentedArrayIterator::operator!= const): (JSC::GCSegmentedArrayIterator::operator==): Deleted. (JSC::GCSegmentedArrayIterator::operator!=): Deleted. * jit/RegisterSet.h: (JSC::RegisterSet::iterator::operator== const): (JSC::RegisterSet::iterator::operator!= const): (JSC::RegisterSet::iterator::operator==): Deleted. (JSC::RegisterSet::iterator::operator!=): Deleted. * parser/Parser.h: (JSC::ScopeRef::operator== const): (JSC::ScopeRef::operator!= const): (JSC::ScopeRef::operator==): Deleted. (JSC::ScopeRef::operator!=): Deleted. * parser/ParserTokens.h: * runtime/GenericOffset.h: (JSC::GenericOffset::operator== const): (JSC::GenericOffset::operator!= const): (JSC::GenericOffset::operator< const): (JSC::GenericOffset::operator> const): (JSC::GenericOffset::operator<= const): (JSC::GenericOffset::operator>= const): * runtime/PropertyTable.h: 2021-12-09 Saam Barati Procedure::setNeedsPCToOriginMap should call Code::forcePreservationOfB3Origins https://bugs.webkit.org/show_bug.cgi?id=234093 Reviewed by Yusuke Suzuki. We need to do this to ensure the sampling profiler works in FTL. The reason this was sometimes working was Air::Code's constructor was looking at Procedure's m_needsPCToOriginMap before it was initialized, in its constructor. This is because Procedure was constructing Code before all its fields were initialized. This patch fixes that bug to construct Code after Procedure has all its fields initialized. * b3/B3Procedure.cpp: (JSC::B3::Procedure::Procedure): (JSC::B3::Procedure::setNeedsPCToOriginMap): * b3/B3Procedure.h: (JSC::B3::Procedure::setNeedsPCToOriginMap): Deleted. 2021-12-09 Saam Barati Add an option to dump the B3 IR for an allowlist of Wasm function indices https://bugs.webkit.org/show_bug.cgi?id=234028 Reviewed by Tadeu Zagallo. * b3/B3Common.cpp: (JSC::B3::shouldDumpIR): * b3/B3Common.h: * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3Procedure.cpp: (JSC::B3::Procedure::dump const): (JSC::B3::Procedure::setShouldDumpIR): * b3/B3Procedure.h: (JSC::B3::Procedure::shouldDumpIR const): * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): * b3/testb3.h: (shouldBeVerbose): (lowerToAirForTesting): * b3/testb3_6.cpp: (testInterpreter): (testMoveConstants): * b3/testb3_7.cpp: (testReduceStrengthReassociation): * runtime/OptionsList.h: * tools/FunctionAllowlist.cpp: (JSC::FunctionAllowlist::shouldDumpWasmFunction const): * tools/FunctionAllowlist.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::shouldDumpIRFor): (JSC::Wasm::parseAndCompile): * wasm/WasmOMGForOSREntryPlan.cpp: (JSC::Wasm::OMGForOSREntryPlan::work): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): 2021-12-09 Yusuke Suzuki [JSC] Introduce BaselineCallLinkInfo and OptimizingCallLinkInfo to shrink sizeof(BaselineCallLinkInfo) https://bugs.webkit.org/show_bug.cgi?id=233985 Reviewed by Mark Lam. This patch introduces BaselineCallLinkInfo and OptimizingCallLinkInfo to shrink sizeof(BaselineCallLinkInfo). BaselineCallLinkInfo is included in metadata, and allocated for LLInt and Baseline. So shrinking it can make metadata small for LLInt and Baseline, which exists for all live functions. We also reorder OpIteratorOpen::Metadata and OpIteratorNext::Metadata to shrink sizes. sizeof(BaselineCallLinkInfo) becomes 88, while the old sizeof(CallLinkInfo) was 120. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/BytecodeList.rb: * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::setMonomorphicCallee): (JSC::CallLinkInfo::emitFastPathImpl): (JSC::OptimizingCallLinkInfo::emitFastPath): (JSC::OptimizingCallLinkInfo::emitTailCallFastPath): (JSC::OptimizingCallLinkInfo::emitSlowPath): (JSC::CallLinkInfo::emitDataICSlowPath): (JSC::OptimizingCallLinkInfo::slowPathStart): (JSC::OptimizingCallLinkInfo::fastPathStart): (JSC::OptimizingCallLinkInfo::emitDirectFastPath): (JSC::OptimizingCallLinkInfo::emitDirectTailCallFastPath): (JSC::OptimizingCallLinkInfo::initializeDirectCall): (JSC::OptimizingCallLinkInfo::setDirectCallTarget): (JSC::BaselineCallLinkInfo::initialize): (JSC::CallLinkInfo::slowPathStart): Deleted. (JSC::CallLinkInfo::fastPathStart): Deleted. (JSC::CallLinkInfo::emitFastPath): Deleted. (JSC::CallLinkInfo::emitTailCallFastPath): Deleted. (JSC::CallLinkInfo::emitSlowPath): Deleted. (JSC::CallLinkInfo::initializeDataIC): Deleted. (JSC::CallLinkInfo::emitDirectFastPath): Deleted. (JSC::CallLinkInfo::emitDirectTailCallFastPath): Deleted. (JSC::CallLinkInfo::initializeDirectCall): Deleted. (JSC::CallLinkInfo::setDirectCallTarget): Deleted. * bytecode/CallLinkInfo.h: (JSC::CallLinkInfo::type const): (JSC::CallLinkInfo::CallLinkInfo): (JSC::CallLinkInfo::calleeGPR const): (JSC::CallLinkInfo::callLinkInfoGPR const): (JSC::CallLinkInfo::setCallLinkInfoGPR): (JSC::CallLinkInfo::setUpCall): Deleted. (JSC::CallLinkInfo::setCodeLocations): Deleted. (JSC::CallLinkInfo::calleeGPR): Deleted. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFor): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::setupWithUnlinkedBaselineCode): (JSC::CodeBlock::finalizeUnconditionally): (JSC::CodeBlock::getICStatusMap): (JSC::CodeBlock::jettison): * bytecode/GetterSetterAccessCase.h: * bytecode/PolymorphicAccess.h: * bytecode/Repatch.cpp: (JSC::revertCall): (JSC::linkDirectCall): * bytecode/Repatch.h: * dfg/DFGCommonData.h: (JSC::DFG::CommonData::addCallLinkInfo): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::addJSCall): (JSC::DFG::JITCompiler::addJSDirectCall): (JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord): (JSC::DFG::JITCompiler::JSDirectCallRecord::JSDirectCallRecord): * dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION): * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/CallFrameShuffleData.cpp: (JSC::CallFrameShuffleData::createForBaselineOrLLIntTailCall): * jit/GCAwareJITStubRoutine.cpp: (JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine): (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler): (JSC::createICJITStubRoutine): * jit/GCAwareJITStubRoutine.h: * jit/JITCall.cpp: (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileTailCall): (JSC::JIT::compileOpCall): (): Deleted. * wasm/js/JSWebAssemblyCodeBlock.h: * wasm/js/WasmToJS.cpp: (JSC::Wasm::wasmToJS): * wasm/js/WasmToJS.h: 2021-12-08 Asumu Takikawa Support WebAssembly.Memory imports in Wasm/ESM modules. https://bugs.webkit.org/show_bug.cgi?id=184745 Reviewed by Yusuke Suzuki. Changes how Wasm code is initialized for modules that are loaded by the module loader and have memory imports. The initial code for the LLInt tier is copied to all memory modes, so that the memory import can be initialized after compilation. When LLInt is turned off, the compilation of B3/Air code is delayed until the memory is initialized. * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::createFromExisting): (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: * wasm/WasmInstance.h: (JSC::Wasm::Instance::finalizeCreation): (JSC::Wasm::Instance::module const): (JSC::Wasm::Instance::codeBlock const): (JSC::Wasm::Instance::memory const): (JSC::Wasm::Instance::isImportFunction const): (JSC::Wasm::Instance::module): Deleted. (JSC::Wasm::Instance::codeBlock): Deleted. (JSC::Wasm::Instance::memory): Deleted. * wasm/WasmModule.cpp: (JSC::Wasm::Module::copyInitialCodeBlockToAllMemoryModes): * wasm/WasmModule.h: * wasm/js/JSWebAssembly.cpp: (JSC::instantiate): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finalizeCreation): (JSC::JSWebAssemblyInstance::tryCreate): * wasm/js/JSWebAssemblyInstance.h: * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::initializeImportsAndExports): 2021-12-08 Yusuke Suzuki [JSC] Introduce WriteBarrierStructureID https://bugs.webkit.org/show_bug.cgi?id=233918 Reviewed by Mark Lam. This patch adds WriteBarrierStructureID class, which is similar to WriteBarrier, but internally, it holds StructureID, so sizeof(WriteBarrierStructureID) is 4. This class is useful to use StructureID for memory saving while keeping WriteBarrier's useful features (automatically inserts write-barrier when setting etc.). This also paves the way to introducing DOMStructures array with WriteBarrierStructureID instead of costly HashMap>. * bytecode/AccessCase.cpp: (JSC::AccessCase::AccessCase): (JSC::AccessCase::forEachDependentCell const): (JSC::AccessCase::dump const): (JSC::AccessCase::propagateTransitions const): (JSC::AccessCase::canBeShared): * bytecode/AccessCase.h: (JSC::AccessCase::structure const): (JSC::AccessCase::newStructure const): (JSC::AccessCase::hash const): (JSC::AccessCase::AccessCase): * bytecode/CheckPrivateBrandStatus.cpp: (JSC::CheckPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/DeleteByStatus.cpp: (JSC::DeleteByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/InByStatus.cpp: (JSC::InByStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/InlineAccess.cpp: (JSC::InlineAccess::rewireStubAsJumpInAccess): (JSC::InlineAccess::resetStubAsJumpInAccess): * bytecode/InstanceOfStatus.cpp: (JSC::InstanceOfStatus::computeForStubInfo): * bytecode/InternalFunctionAllocationProfile.h: (JSC::InternalFunctionAllocationProfile::offsetOfStructureID): (JSC::InternalFunctionAllocationProfile::structure): (JSC::InternalFunctionAllocationProfile::clear): (JSC::InternalFunctionAllocationProfile::visitAggregate): (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase): (JSC::InternalFunctionAllocationProfile::offsetOfStructure): Deleted. * bytecode/PutByStatus.cpp: (JSC::PutByStatus::computeForStubInfo): * bytecode/SetPrivateBrandStatus.cpp: (JSC::SetPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::initGetByIdSelf): (JSC::StructureStubInfo::initPutByIdReplace): (JSC::StructureStubInfo::initInByIdSelf): (JSC::StructureStubInfo::deref): (JSC::StructureStubInfo::aboutToDie): (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::reset): (JSC::StructureStubInfo::visitAggregateImpl): (JSC::StructureStubInfo::visitWeakReferences): (JSC::StructureStubInfo::propagateTransitions): (JSC::StructureStubInfo::summary const): (JSC::StructureStubInfo::containsPC const): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::inlineAccessBaseStructure): (JSC::StructureStubInfo::offsetOfByIdSelfOffset): (JSC::StructureStubInfo::offsetOfInlineAccessBaseStructureID): (JSC::StructureStubInfo::offsetOfInlineAccessBaseStructure): Deleted. * dfg/DFGSpeculativeJIT.cpp: * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise): (JSC::FTL::DFG::LowerDFGToB3::compileCreateInternalFieldObject): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * heap/AbstractSlotVisitor.h: * heap/AbstractSlotVisitorInlines.h: (JSC::AbstractSlotVisitor::append): (JSC::AbstractSlotVisitor::appendHidden): * heap/SlotVisitor.h: * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::append): (JSC::SlotVisitor::appendHidden): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitNonNullDecodeStructureID): (JSC::AssemblyHelpers::emitLoadStructure): * jit/AssemblyHelpers.h: * jit/JITInlineCacheGenerator.cpp: (JSC::generateGetByIdInlineAccess): (JSC::JITPutByIdGenerator::generateBaselineDataICFastPath): (JSC::JITInByIdGenerator::generateBaselineDataICFastPath): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::visitChildrenImpl): * runtime/FunctionExecutable.h: * runtime/FunctionRareData.cpp: (JSC::FunctionRareData::visitChildrenImpl): * runtime/FunctionRareData.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::visitChildrenImpl): * runtime/JSGlobalObject.h: * runtime/JSPropertyNameEnumerator.cpp: (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator): (JSC::JSPropertyNameEnumerator::visitChildrenImpl): * runtime/JSPropertyNameEnumerator.h: * runtime/StructureRareData.cpp: (JSC::StructureRareData::StructureRareData): * runtime/StructureRareData.h: * runtime/WriteBarrier.h: (JSC::WriteBarrierStructureID::WriteBarrierStructureID): (JSC::WriteBarrierStructureID::get const): (JSC::WriteBarrierStructureID::operator* const): (JSC::WriteBarrierStructureID::operator-> const): (JSC::WriteBarrierStructureID::clear): (JSC::WriteBarrierStructureID::operator bool const): (JSC::WriteBarrierStructureID::operator! const): (JSC::WriteBarrierStructureID::setWithoutWriteBarrier): (JSC::WriteBarrierStructureID::unvalidatedGet const): (JSC::WriteBarrierStructureID::value const): * runtime/WriteBarrierInlines.h: (JSC::WriteBarrierStructureID::set): (JSC::WriteBarrierStructureID::setMayBeNull): (JSC::WriteBarrierStructureID::setEarlyValue): * tools/JSDollarVM.cpp: (JSC::JSDollarVM::finishCreation): (JSC::JSDollarVM::visitChildrenImpl): * tools/JSDollarVM.h: 2021-12-07 Saam Barati TypedArray prototype set should go down the fast path when using non clamped integer types of the same byte size https://bugs.webkit.org/show_bug.cgi?id=233905 Reviewed by Keith Miller. We can use memmove in this scenario because the bitpattern of the data between the signed and unsigned values will be the same. This patch also fixes a bug where we were looking at the wrong pointer when determining to do a forward or backwards loop in our memmove. We were looking at the vector instead of vector+offset. * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::set): 2021-12-07 Ross Kirsling [JSC] Add LLInt IC for try_get_by_id of own cacheable value https://bugs.webkit.org/show_bug.cgi?id=233830 Reviewed by Yusuke Suzuki. This patch adds an LLInt IC for the "own cacheable value" path of try_get_by_id; this is the simplest case and basically the same as get_by_id_direct. Performance is neutral with JIT enabled as well as on current uses of try_get_by_id in JSC (e.g. hasObservableSideEffectsForRegexpSplit), but microbenchmarks of try_get_by_id itself see a 2x speedup: Before After try-get-by-id-polymorphic 123.8361+-0.4562 ^ 61.7586+-0.3770 ^ definitely 2.0052x faster try-get-by-id-basic 124.4437+-0.6091 ^ 61.0340+-0.1924 ^ definitely 2.0389x faster 124.1207+-0.3130 ^ 61.3865+-0.2019 ^ definitely 2.0220x faster * bytecode/BytecodeList.rb: * bytecode/CodeBlock.cpp: * bytecode/GetByStatus.cpp: * llint/LLIntSlowPaths.cpp: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2021-12-07 Commit Queue Unreviewed, reverting r286502 and r286580. https://bugs.webkit.org/show_bug.cgi?id=233930 Speedometer2 0.7% regression Reverted changesets: "Remove StructureIDBlob" https://bugs.webkit.org/show_bug.cgi?id=233723 https://commits.webkit.org/r286502 "TypeInfo should be materializable from Structures as a single load." https://bugs.webkit.org/show_bug.cgi?id=233875 https://commits.webkit.org/r286580 2021-12-07 Zan Dobersek [RISCV64] Add more MacroAssemblerRISCV64 helper infrastructure https://bugs.webkit.org/show_bug.cgi?id=233805 Reviewed by Yusuke Suzuki. Introduce RISCV64Assembler::ImmediateLoader, a helper class that generates the operations necessary for loading any immediate value into some register. This can be as simple as using ADDI to load 12-bit values or a combination of LUI, ADDI and possibly additional combinations of LSHIFT and ADDI instructions. There's also a placeholder mode which generates no-ops for unused operation slots, in order to enable future patching and repatching for other immediate values. MacroAssemblerRISCV64::Imm is introduced as a private helper struct that groups together validity and construction operations for the different immediate types implemented in the RISCV64Instructions namespace. In MacroAssemblerRISCV64, resolveAddress() overloads are provided to help generate most optimal address loading sequencing. RISC-V addressing mode utilizes a base register and a 12-bit signed offset. When needed, additional computation is done on the address object's parameters and stored in the destination register through which the load can then be performed. Helper TempRegister and LazyTempRegister structs are added to the MacroAssemblerRISCV64 class, along with the respective temps() and lazyTemp() methods. temps() returns the TempRegister object, with the template parameters defining which of the two scratch register types should be allowed for use through this object. Release-time assert on the m_allowScratchRegister value is done at the point of calling temps(). lazyTemp() only handles one scratch register, and the assert is done only when the register is actually used, and not just reserved for use. This enables simpler implementations that better handle both modes of scratch register usage (allowed or disallowed). To get things rolling, the first set of MacroAssemblerRISCV64 methods is implemented. Addition, subtraction and multiplication definitions are provided, with the templated no-op declarations removed. * assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::TempRegister::data): (JSC::MacroAssemblerRISCV64::TempRegister::memory): (JSC::MacroAssemblerRISCV64::LazyTempRegister::LazyTempRegister): (JSC::MacroAssemblerRISCV64::LazyTempRegister::operator RegisterID): (JSC::MacroAssemblerRISCV64::temps): (JSC::MacroAssemblerRISCV64::lazyTemp): (JSC::MacroAssemblerRISCV64::add32): (JSC::MacroAssemblerRISCV64::add64): (JSC::MacroAssemblerRISCV64::sub32): (JSC::MacroAssemblerRISCV64::sub64): (JSC::MacroAssemblerRISCV64::mul32): (JSC::MacroAssemblerRISCV64::mul64): (JSC::MacroAssemblerRISCV64::Imm::isValid): (JSC::MacroAssemblerRISCV64::Imm::I): (JSC::MacroAssemblerRISCV64::Imm::S): (JSC::MacroAssemblerRISCV64::Imm::B): (JSC::MacroAssemblerRISCV64::Imm::U): (JSC::MacroAssemblerRISCV64::Imm::J): (JSC::MacroAssemblerRISCV64::resolveAddress): * assembler/RISCV64Assembler.h: (JSC::RISCV64Assembler::ImmediateLoader::ImmediateLoader): (JSC::RISCV64Assembler::ImmediateLoader::moveInto): 2021-12-06 Keith Miller TypeInfo should be materializable from Structures as a single load. https://bugs.webkit.org/show_bug.cgi?id=233875 Reviewed by Mark Lam. This is mostly just the members of Structure and JSCell so that JSType and InlineTypeFlags are at the end of the JSCell header. * assembler/testmasm.cpp: (JSC::testBranchIfType): (JSC::testBranchIfNotType): * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository): * runtime/JSCell.h: * runtime/JSCellInlines.h: (JSC::JSCell::JSCell): * runtime/Structure.h: (JSC::Structure::typeInfo const): 2021-12-06 Mark Lam Remove unneeded virtual allocator methods from Subspace. https://bugs.webkit.org/show_bug.cgi?id=233891 rdar://86117970 Reviewed by Yusuke Suzuki. Since the virtual allocate() and allocateFor() methods are now deleted, we can also rename the inline allocateNonVirtual() and allocatorForNonVirtual() methods to simply allocate() and allocateFor(). Similarly, rename allocatorForNonVirtualConcurrently() to allocatorForConcurrently(). There are 2 places that still invokes the non-inline version of CompleteSubspace::allocatorFor(). For this reason, we introduce a CompleteSubsace::allocatorForNonInline() to keep the linkage the same. There's a chance that the compiler/linker may already inline the method in 1 or both of these places, but we'll offer allocatorForNonInline() to keep the code expressing the same thing and let the compiler/linker decide whether to inline it or not just as before. This is purely a re-factoring patch. There are no behavior changes, except for the removal of those 2 entries from the vtbls. * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/ObjectAllocationProfileInlines.h: (JSC::ObjectAllocationProfileBase::initializeProfile): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitAllocateRawObject): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * heap/CompleteSubspace.cpp: (JSC::CompleteSubspace::allocatorForNonInline): (JSC::CompleteSubspace::tryAllocateSlow): (JSC::CompleteSubspace::allocatorFor): Deleted. (JSC::CompleteSubspace::allocate): Deleted. * heap/CompleteSubspace.h: (JSC::CompleteSubspace::allocatorFor): (JSC::CompleteSubspace::allocatorForNonVirtual): Deleted. * heap/CompleteSubspaceInlines.h: (JSC::CompleteSubspace::allocate): (JSC::CompleteSubspace::allocateNonVirtual): Deleted. * heap/IsoSubspace.cpp: (JSC::IsoSubspace::allocatorFor): Deleted. (JSC::IsoSubspace::allocate): Deleted. * heap/IsoSubspace.h: (JSC::IsoSubspace::allocatorFor): (JSC::IsoSubspace::allocatorForNonVirtual): Deleted. * heap/IsoSubspaceInlines.h: (JSC::IsoSubspace::allocate): (JSC::IsoSubspace::allocateNonVirtual): Deleted. * heap/Subspace.h: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize): * runtime/ButterflyInlines.h: (JSC::Butterfly::tryCreateUninitialized): (JSC::Butterfly::createUninitialized): (JSC::Butterfly::tryCreate): (JSC::Butterfly::growArrayRight): (JSC::Butterfly::reallocArrayRightIfPossible): * runtime/DirectArguments.cpp: (JSC::DirectArguments::overrideThings): * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::initModifiedArgumentsDescriptor): * runtime/HashMapImpl.h: (JSC::HashMapBuffer::create): * runtime/JSArray.cpp: (JSC::JSArray::tryCreateUninitializedRestricted): * runtime/JSArray.h: (JSC::JSArray::tryCreate): * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext): * runtime/JSBigInt.cpp: (JSC::JSBigInt::createWithLength): * runtime/JSCellInlines.h: (JSC::allocatorForConcurrently): (JSC::tryAllocateCellHelper): (JSC::allocatorForNonVirtualConcurrently): Deleted. * runtime/JSPropertyNameEnumerator.cpp: (JSC::JSPropertyNameEnumerator::create): * runtime/ScopedArguments.cpp: (JSC::ScopedArguments::createUninitialized): * runtime/StructureChain.cpp: (JSC::StructureChain::create): 2021-12-06 Patrick Angle Web Inspector: Support Cascade Layers in the Styles sidebar https://bugs.webkit.org/show_bug.cgi?id=233208 Reviewed by Devin Rousso. Add new values to `CSS.Grouping`'s `type` enum for cascade layers and make the `text` optional since an anonymous layer will not have a name or other text. * inspector/protocol/CSS.json: 2021-12-03 Keith Miller Remove StructureIDBlob https://bugs.webkit.org/show_bug.cgi?id=233723 Reviewed by Yusuke Suzuki. StructureIDBlob isn't very useful now that StructureIDs are just the bottom bits of the pointer on 64 bit platforms. In a follow up patch I'll change the layout of JSCell and Structure so that TypeInfo creation can be a single load platforms that allow (and don't penalize) misaligned loads. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_to_scope): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::addNewPropertyTransition): (JSC::Structure::removeNewPropertyTransition): (JSC::Structure::attributeChangeTransition): (JSC::Structure::nonPropertyTransitionSlow): (JSC::Structure::setBrandTransition): * runtime/Structure.h: (JSC::Structure::id const): (JSC::Structure::objectInitializationBlob const): (JSC::Structure::idBlob const): (JSC::Structure::isProxy const): (JSC::Structure::typeInfo const): (JSC::Structure::indexingType const): (JSC::Structure::indexingMode const): (JSC::Structure::fencedIndexingMode): (JSC::Structure::indexingModeIncludingHistory const): (JSC::Structure::indexingModeIncludingHistoryOffset): (JSC::Structure::structureIDOffset): Deleted. * runtime/StructureIDBlob.h: Removed. * runtime/StructureInlines.h: (JSC::Structure::hasIndexingHeader const): * tools/VMInspectorInlines.h: (JSC::VMInspector::verifyCellSize): 2021-12-02 Yusuke Suzuki [JSC] shell's $.globalObjectFor is not safe for non object cells https://bugs.webkit.org/show_bug.cgi?id=233794 Reviewed by Saam Barati. Only Object cells can have Structures having JSGlobalObject. * jsc.cpp: (JSC_DEFINE_HOST_FUNCTION): 2021-12-02 Saam Barati Lower structureHeapAddressSize on more memory limited ARM64 devices https://bugs.webkit.org/show_bug.cgi?id=233786 Reviewed by Yusuke Suzuki. Some processes using JSC are failing the mmap for the 1GB region. Let's lower the region size to 512MB on lower memory iOS devices. * runtime/JSCConfig.h: 2021-12-02 Saam Barati Fix OOM crash in JSValue::toWTFStringForConsole https://bugs.webkit.org/show_bug.cgi?id=233775 Reviewed by Mark Lam. * runtime/JSCJSValue.cpp: (JSC::JSValue::toWTFStringForConsole const): 2021-12-02 Zan Dobersek [RISCV64] Fix effective address loading for LabelReferences with offsets https://bugs.webkit.org/show_bug.cgi?id=233754 Reviewed by Yusuke Suzuki. r286345 (and subsequent change in r286372) introduced a load from a label address with an additional offset. To properly handle this, RISCV64 offlineasm generates the desired load-effective-address instruction but now also generates an additional add instruction when an offset value is present for that lea. * offlineasm/riscv64.rb: 2021-12-02 Geza Lore [JSC] Generated code size reductions for baseline JIT (all architectures) https://bugs.webkit.org/show_bug.cgi?id=233474 Reviewed by Yusuke Suzuki. This patch introduces a few improvements that reduce the generated code size. Target independent improvements to the Baseline JIT: 1. Some bytecodes that are very frequent (e.g.: get_by_id, call) share the same instructions at the tail end of the fast and slow paths. Instead of duplicating these in the slow path, then branch to the next sequential bytecode on the fast path, make the slow path branch to and reuse these common instructions, which then naturally fall through to the next sequential bytecode. 2. Minor tweaks in a few places to remove redundant reloading of immediates and remove redundant moves. 3. Remove a small number of redundant unconditional branches from some DataIC fast paths. ARMv7/Thumb-2 specific improvements: 4. Add assembler support for LDRD and STRD (load/store a pair of 32-bit GPRs) and use them throughout via loadValue/storeValue. This yields denser code as it often eliminates repeated temporary register setups (especially for a BaseIndex access), and also due to point 4 below. This is also potentially a performance improvement on micro-architectures with a 64-bit LSU data-path. 5. Instructions using only r0-r7 as operands can often use a short, 16-bit encoding in Thumb-2, so prefer to use low order registers as temporaries wherever possible. The net effect of this patch is that the emitted baseline code during a run of JetStream2 is ~6.6% smaller on x86_64, ~5.1% smaller on ARM64, and ~24% smaller on ARMv7/Thumb-2. On ARMv7/Thumb-2, DFG code is also ~5.3% smaller, while on other architectures the DFG code is unaffected. On ARMv7/Thumb-2, this patch also yields an ~2% improvement in JetStream2 scores on my test machine. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::ldrd): (JSC::ARMv7Assembler::strd): (JSC::ARMv7Assembler::ARMInstructionFormatter::twoWordOp12Reg4Reg4Reg4Imm8): * assembler/MacroAssembler.h: (JSC::MacroAssembler::addPtr): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::bestTempRegister): (JSC::MacroAssemblerARMv7::scratchRegister): (JSC::MacroAssemblerARMv7::add32): (JSC::MacroAssemblerARMv7::sub32): (JSC::MacroAssemblerARMv7::loadPair32): (JSC::MacroAssemblerARMv7::store32): (JSC::MacroAssemblerARMv7::storePair32): (JSC::MacroAssemblerARMv7::compare32AndSetFlags): (JSC::MacroAssemblerARMv7::test32): (JSC::MacroAssemblerARMv7::branch32): (JSC::MacroAssemblerARMv7::farJump): (JSC::MacroAssemblerARMv7::call): (JSC::MacroAssemblerARMv7::compare32): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::loadPair32): (JSC::MacroAssemblerMIPS::storePair32): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::storeValue): (JSC::AssemblyHelpers::loadValue): * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::compileCallEval): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCall): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::emitSlow_op_iterator_open): (JSC::JIT::emitSlow_op_iterator_next): * jit/JITInlineCacheGenerator.cpp: (JSC::generateGetByIdInlineAccess): (JSC::JITPutByIdGenerator::generateBaselineDataICFastPath): * jit/JITInlineCacheGenerator.h: * jit/JITInlines.h: (JSC::JIT::setFastPathResumePoint): (JSC::JIT::fastPathResumePoint const): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_enter): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::generateGetByValSlowCase): (JSC::JIT::emit_op_get_private_name): (JSC::JIT::emitSlow_op_get_private_name): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emit_op_in_by_val): (JSC::JIT::emitSlow_op_in_by_val): (JSC::JIT::emitHasPrivate): (JSC::JIT::emitHasPrivateSlow): (JSC::JIT::emitSlow_op_has_private_name): (JSC::JIT::emitSlow_op_has_private_brand): (JSC::JIT::emit_op_enumerator_get_by_val): (JSC::JIT::emitWriteBarrier): 2021-12-01 Adrian Perez de Castro Non-unified build fixes, early December 2021 edition https://bugs.webkit.org/show_bug.cgi?id=233699 Unreviewed non-unified build fixes. * dfg/DFGCodeOriginPool.h: Add missing CodeOrigin.h header. * heap/Heap.cpp: Add missing GigacageAlignedMemoryAllocator.h header. * heap/IsoSubspace.cpp: Add missing IsoAlignedMemoryAllocator.h header, and remove IsoMemoryAllocatorBase.h as it is included by the former. * runtime/StackFrame.h: Add missing BytecodeIndex.h header. * runtime/StructureID.h: Add missing wtf/HashTraits.h header. * tools/Integrity.h: Add missing StructureID.h header. 2021-12-01 Yusuke Suzuki [JSC] RegExpTestInline DFG / FTL nodes should introduce a write-barrier https://bugs.webkit.org/show_bug.cgi?id=233716 Reviewed by Michael Saboff. Since RegExpTestInline fast path stores cells into JSGlobalObject's RegExpCachedResult field, we need to consider about inserting a write-barrier onto JSGlobalObject. This patch adds RegExpTestInline to DFGStoreBarrierInsertionPhase so that DFG / FTL inserts a write-barrier appropriately. * dfg/DFGStoreBarrierInsertionPhase.cpp: 2021-12-01 Keith Miller Add static_assert the value we use to initialize a StructureID buffer should be 0. https://bugs.webkit.org/show_bug.cgi?id=233720 Reviewed by Yusuke Suzuki. Also, add static assert that the zero we are putting into the buffer matches the default StructureID constructor. * runtime/StructureChain.cpp: (JSC::StructureChain::create): * runtime/StructureID.h: (JSC::StructureID::bits const): 2021-12-01 Yusuke Suzuki Unreviewed, use void* to suppress GCC warning https://bugs.webkit.org/show_bug.cgi?id=233379 * runtime/StructureChain.cpp: (JSC::StructureChain::create): 2021-12-01 Mikhail R. Gadelha Disable madd4 instruction generation globally for MIPS https://bugs.webkit.org/show_bug.cgi?id=233713 Reviewed by Yusuke Suzuki. This is an improved version of r285788 and follows the approach used in r231301. This patch removes the volatile attribute from the double variable and adds a -mno-madd4 flag globally when compiling on MIPS. * CMakeLists.txt: * runtime/ParseInt.h: (JSC::parseInt): 2021-12-01 Yusuke Suzuki Unreviewed, fix CLoop build https://bugs.webkit.org/show_bug.cgi?id=233379 * llint/LowLevelInterpreter64.asm: 2021-12-01 Xan Lopez [JSC] Fix potential build break related to StructureID.h https://bugs.webkit.org/show_bug.cgi?id=233693 Reviewed by Adrian Perez de Castro. * runtime/StructureID.h: include StdIntExtras.h for CPURegister. 2021-12-01 Xan Lopez [JSC] Remove debug print left over from previous patch https://bugs.webkit.org/show_bug.cgi?id=233692 Unreviewed follow-up patch. * offlineasm/x86.rb: remove debug print. 2021-11-30 Mark Lam Move Subspaces from VM to Heap. https://bugs.webkit.org/show_bug.cgi?id=233648 rdar://85875751 Reviewed by Saam Barati. Subspaces are Heap data structures to begin with, and this refactoring is needed in preparation for the global GC. 1. Embed HeapCellType and IsoHeapCellType instances in Heap directly instead of malloc'ing them separately and referencing them via unique_ptrs. These instances are always instantiated unconditionally anyway. This change eliminates the unneeded busy work to allocate them separately. 2. Introduce a HeapSubspaceTypes.h that #include all the types that we have subspaces for. This makes it so that Heap.cpp's #include list is not flooded with these types with subspaces, and that it'll be easier to discern between these Subspace types from other data structures needed for implementing Heap. 3. Add VM accessor methods for subspaces that forward to Heap. This will make it easier for us to redirect to a thread local allocator later for the global GC. 4. Remove unneeded #includes in VM.h. 5. Remove unused CodeBlockSet::iterateViaSubspaces(). * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/DFGExitProfile.h: * bytecode/EvalCodeBlock.h: * bytecode/ExecutableToCodeBlockEdge.cpp: (JSC::ExecutableToCodeBlockEdge::visitChildrenImpl): (JSC::ExecutableToCodeBlockEdge::finalizeUnconditionally): (JSC::ExecutableToCodeBlockEdge::runConstraint): * bytecode/ExecutableToCodeBlockEdge.h: * bytecode/FunctionCodeBlock.h: * bytecode/ModuleProgramCodeBlock.h: * bytecode/ProgramCodeBlock.h: * bytecode/Repatch.h: * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor): (JSC::UnlinkedFunctionExecutable::finalizeUnconditionally): * bytecode/UnlinkedFunctionExecutable.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitAllocateRawObject): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::emitNewTypedArrayWithSize): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * generator/DSL.rb: * heap/CodeBlockSet.h: * heap/CodeBlockSetInlines.h: (JSC::CodeBlockSet::iterateViaSubspaces): Deleted. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::finalizeUnconditionalFinalizers): (JSC::Heap::deleteAllCodeBlocks): (JSC::Heap::deleteAllUnlinkedCodeBlocks): (JSC::Heap::deleteUnmarkedCompiledCode): (JSC::Heap::sweepInFinalize): (JSC::Heap::addCoreConstraints): * heap/Heap.h: (JSC::Heap::gigacageAuxiliarySpace): (JSC::Heap::SpaceAndSet::SpaceAndSet): (JSC::Heap::SpaceAndSet::setFor): (JSC::Heap::forEachCodeBlockSpace): (JSC::Heap::forEachScriptExecutableSpace): * heap/HeapSubspaceTypes.h: Added. * heap/IsoHeapCellType.h: * heap/IsoInlinedHeapCellType.h: * heap/IsoInlinedHeapCellTypeInlines.h: Added. (JSC::IsoInlinedHeapCellType::IsoInlinedHeapCellType): (JSC::IsoInlinedHeapCellType::DestroyFunc::operator const): (JSC::IsoInlinedHeapCellType::finishSweep const): (JSC::IsoInlinedHeapCellType::destroy const): * heap/MarkedBlockInlines.h: * inspector/JSInjectedScriptHostPrototype.h: * inspector/JSJavaScriptCallFramePrototype.h: * interpreter/CallFrame.h: * jsc.cpp: (JSCMemoryFootprint::subspaceFor): (JSFileDescriptor::subspaceFor): * runtime/AggregateErrorPrototype.h: * runtime/ArrayIteratorPrototype.h: * runtime/AsyncFromSyncIteratorPrototype.h: * runtime/AsyncFunctionPrototype.h: * runtime/AsyncGeneratorFunctionPrototype.h: * runtime/AsyncGeneratorPrototype.h: * runtime/AsyncIteratorPrototype.h: * runtime/AtomicsObject.h: * runtime/BigIntPrototype.h: * runtime/BrandedStructure.h: * runtime/ButterflyInlines.h: (JSC::Butterfly::tryCreateUninitialized): (JSC::Butterfly::createUninitialized): (JSC::Butterfly::tryCreate): (JSC::Butterfly::growArrayRight): (JSC::Butterfly::reallocArrayRightIfPossible): * runtime/CachedTypes.h: * runtime/ClonedArguments.h: * runtime/ConsoleObject.h: * runtime/CustomGetterSetter.h: (JSC::CustomGetterSetter::subspaceFor): * runtime/DOMAttributeGetterSetter.h: * runtime/DateInstance.h: * runtime/DatePrototype.h: * runtime/DirectArguments.h: * runtime/ErrorPrototype.h: * runtime/Exception.h: * runtime/FinalizationRegistryPrototype.h: * runtime/FunctionExecutable.h: * runtime/GeneratorFunctionPrototype.h: * runtime/GeneratorPrototype.h: * runtime/GetterSetter.h: * runtime/HashMapImpl.h: (JSC::HashMapBuffer::create): * runtime/InternalFunction.h: (JSC::InternalFunction::subspaceFor): * runtime/IntlCollatorPrototype.h: * runtime/IntlDateTimeFormatPrototype.h: * runtime/IntlDisplayNamesPrototype.h: * runtime/IntlListFormatPrototype.h: * runtime/IntlLocalePrototype.h: * runtime/IntlNumberFormatPrototype.h: * runtime/IntlObject.h: * runtime/IntlPluralRulesPrototype.h: * runtime/IntlRelativeTimeFormatPrototype.h: * runtime/IntlSegmentIteratorPrototype.h: * runtime/IntlSegmenterPrototype.h: * runtime/IntlSegmentsPrototype.h: * runtime/IteratorPrototype.h: * runtime/JSArray.cpp: (JSC::JSArray::tryCreateUninitializedRestricted): * runtime/JSArray.h: (JSC::JSArray::subspaceFor): (JSC::JSArray::tryCreate): * runtime/JSArrayBufferPrototype.h: * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext): * runtime/JSBigInt.cpp: (JSC::JSBigInt::createWithLength): * runtime/JSBigInt.h: * runtime/JSCallee.h: (JSC::JSCallee::subspaceFor): * runtime/JSDataViewPrototype.h: * runtime/JSFunction.h: (JSC::JSFunction::subspaceFor): * runtime/JSGenericTypedArrayViewPrototype.h: * runtime/JSGlobalLexicalEnvironment.h: * runtime/JSImmutableButterfly.h: (JSC::JSImmutableButterfly::subspaceFor): * runtime/JSLexicalEnvironment.h: (JSC::JSLexicalEnvironment::subspaceFor): * runtime/JSModuleLoader.h: * runtime/JSONObject.h: * runtime/JSObjectInlines.h: (JSC::JSFinalObject::subspaceFor): * runtime/JSPromise.h: (JSC::JSPromise::subspaceFor): * runtime/JSPromisePrototype.h: (JSC::JSPromisePrototype::subspaceFor): * runtime/JSPropertyNameEnumerator.cpp: (JSC::JSPropertyNameEnumerator::create): * runtime/JSPropertyNameEnumerator.h: * runtime/JSProxy.h: (JSC::JSProxy::subspaceFor): * runtime/JSString.h: (JSC::JSString::subspaceFor): * runtime/JSTypedArrayViewPrototype.h: * runtime/MapIteratorPrototype.h: * runtime/MapPrototype.h: * runtime/MathObject.h: * runtime/NativeErrorPrototype.h: * runtime/NativeExecutable.h: * runtime/NumberObject.h: (JSC::NumberObject::subspaceFor): * runtime/ObjectPrototype.h: * runtime/ProgramExecutable.h: * runtime/PropertyTable.h: * runtime/ReflectObject.h: * runtime/RegExp.h: * runtime/RegExpObject.h: * runtime/RegExpPrototype.h: * runtime/RegExpStringIteratorPrototype.h: * runtime/ScopedArguments.cpp: (JSC::ScopedArguments::createUninitialized): * runtime/ScopedArguments.h: * runtime/SetIteratorPrototype.h: * runtime/SetPrototype.h: * runtime/ShadowRealmPrototype.h: * runtime/SparseArrayValueMap.h: * runtime/StringIteratorPrototype.h: * runtime/StringObject.h: (JSC::StringObject::subspaceFor): * runtime/Structure.h: (JSC::Structure::subspaceFor): * runtime/StructureChain.cpp: (JSC::StructureChain::create): * runtime/StructureChain.h: * runtime/StructureRareData.h: * runtime/SymbolPrototype.h: * runtime/SymbolTable.h: * runtime/TemporalCalendarPrototype.h: * runtime/TemporalDurationPrototype.h: * runtime/TemporalInstantPrototype.h: * runtime/TemporalNow.h: * runtime/TemporalObject.h: * runtime/TemporalPlainTimePrototype.h: * runtime/TemporalTimeZonePrototype.h: * runtime/ThrowScope.cpp: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: (JSC::VM::cellHeapCellType): (JSC::VM::destructibleObjectHeapCellType): (JSC::VM::primitiveGigacageAuxiliarySpace): (JSC::VM::jsValueGigacageAuxiliarySpace): (JSC::VM::immutableButterflyJSValueGigacageAuxiliarySpace): (JSC::VM::gigacageAuxiliarySpace): (JSC::VM::cellSpace): (JSC::VM::variableSizedCellSpace): (JSC::VM::destructibleObjectSpace): (JSC::VM::arraySpace): (JSC::VM::bigIntSpace): (JSC::VM::calleeSpace): (JSC::VM::clonedArgumentsSpace): (JSC::VM::customGetterSetterSpace): (JSC::VM::dateInstanceSpace): (JSC::VM::domAttributeGetterSetterSpace): (JSC::VM::exceptionSpace): (JSC::VM::executableToCodeBlockEdgeSpace): (JSC::VM::functionSpace): (JSC::VM::getterSetterSpace): (JSC::VM::globalLexicalEnvironmentSpace): (JSC::VM::internalFunctionSpace): (JSC::VM::jsProxySpace): (JSC::VM::nativeExecutableSpace): (JSC::VM::numberObjectSpace): (JSC::VM::plainObjectSpace): (JSC::VM::promiseSpace): (JSC::VM::propertyNameEnumeratorSpace): (JSC::VM::propertyTableSpace): (JSC::VM::regExpSpace): (JSC::VM::regExpObjectSpace): (JSC::VM::ropeStringSpace): (JSC::VM::scopedArgumentsSpace): (JSC::VM::sparseArrayValueMapSpace): (JSC::VM::stringSpace): (JSC::VM::stringObjectSpace): (JSC::VM::structureChainSpace): (JSC::VM::structureRareDataSpace): (JSC::VM::structureSpace): (JSC::VM::brandedStructureSpace): (JSC::VM::symbolTableSpace): (JSC::VM::executableToCodeBlockEdgesWithConstraints): (JSC::VM::executableToCodeBlockEdgesWithFinalizers): (JSC::VM::codeBlockSpace): (JSC::VM::functionExecutableSpace): (JSC::VM::programExecutableSpace): (JSC::VM::unlinkedFunctionExecutableSpace): (JSC::VM::setFuzzerAgent): Deleted. (JSC::VM::SpaceAndSet::SpaceAndSet): Deleted. (JSC::VM::SpaceAndSet::setFor): Deleted. (JSC::VM::forEachCodeBlockSpace): Deleted. (JSC::VM::forEachScriptExecutableSpace): Deleted. * runtime/VMInlines.h: (JSC::VM::setFuzzerAgent): * runtime/WeakMapPrototype.h: * runtime/WeakObjectRefPrototype.h: * runtime/WeakSetPrototype.h: * tools/JSDollarVM.cpp: * tools/JSDollarVM.h: * wasm/js/JSWebAssembly.h: * wasm/js/WebAssemblyCompileErrorPrototype.h: * wasm/js/WebAssemblyExceptionPrototype.h: * wasm/js/WebAssemblyGlobalPrototype.h: * wasm/js/WebAssemblyInstancePrototype.h: * wasm/js/WebAssemblyLinkErrorPrototype.h: * wasm/js/WebAssemblyMemoryPrototype.h: * wasm/js/WebAssemblyModulePrototype.h: * wasm/js/WebAssemblyRuntimeErrorPrototype.h: * wasm/js/WebAssemblyTablePrototype.h: * wasm/js/WebAssemblyTagPrototype.h: 2021-11-30 Keith Miller Structures should be allocated out of an aligned pool of memory so StructureID->Structure* is fast. https://bugs.webkit.org/show_bug.cgi?id=233379 Reviewed by Yusuke Suzuki. This patch changes the 64-bit pointer variant of StructureID to just be the bottom bits of a reserved address space for structures. With this system the decoding of a StructureID is just adding the bits to the start of the structure address space (saved in JSCConfig). We also take care to ignore any high bits of a StructureID outside the reserved address range. This prevents a data corruption from causing us to read past the structure space, much like the gigacage. Now that StructureIDs can be directly determined from the Structure* (and visa versa) we no longer need StructureIDTable, which has been removed. Also, as Structures are still IsoHeaped but not allocated by fastMalloc, there's a new AlignedMemoryAllocator subclass that gets MarkedBlocks out of a simple static allocator. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/AccessCase.cpp: (JSC::AccessCase::forEachDependentCell const): (JSC::AccessCase::propagateTransitions const): (JSC::AccessCase::generateWithGuard): * bytecode/ArrayProfile.cpp: (JSC::ArrayProfile::computeUpdatedPrediction): * bytecode/ArrayProfile.h: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::determineLiveness): (JSC::CodeBlock::finalizeLLIntInlineCaches): (JSC::CodeBlock::stronglyVisitWeakReferences): * bytecode/GetByIdMetadata.h: (JSC::GetByIdModeMetadata::GetByIdModeMetadata): (JSC::GetByIdModeMetadata::clearToDefaultModeWithoutCache): * bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeFromLLInt): * bytecode/InlineAccess.cpp: (JSC::InlineAccess::rewireStubAsJumpInAccess): (JSC::InlineAccess::resetStubAsJumpInAccess): * bytecode/PolyProtoAccessChain.cpp: (JSC::PolyProtoAccessChain::needImpurePropertyWatchpoint const): * bytecode/PolyProtoAccessChain.h: * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::visitWeak const): * bytecode/PutByIdFlags.h: * bytecode/PutByStatus.cpp: (JSC::PutByStatus::computeFromLLInt): * bytecode/SpeculatedType.cpp: (JSC::speculationFromCell): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::reset): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::inlineAccessBaseStructure): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::branchWeakStructure): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::finalize): * dfg/DFGSpeculativeJIT.cpp: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined): (JSC::DFG::SpeculativeJIT::compileToBooleanObjectOrOther): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::emitUntypedBranch): (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * heap/Heap.cpp: (JSC::Heap::runEndPhase): * heap/Heap.h: (JSC::Heap::structureIDTable): Deleted. * heap/IsoAlignedMemoryAllocator.cpp: (JSC::IsoAlignedMemoryAllocator::IsoAlignedMemoryAllocator): (JSC::IsoAlignedMemoryAllocator::~IsoAlignedMemoryAllocator): (JSC::IsoAlignedMemoryAllocator::tryMallocBlock): (JSC::IsoAlignedMemoryAllocator::freeBlock): (JSC::IsoAlignedMemoryAllocator::commitBlock): (JSC::IsoAlignedMemoryAllocator::decommitBlock): (JSC::IsoAlignedMemoryAllocator::tryAllocateAlignedMemory): Deleted. (JSC::IsoAlignedMemoryAllocator::freeAlignedMemory): Deleted. * heap/IsoAlignedMemoryAllocator.h: * heap/IsoMemoryAllocatorBase.cpp: Copied from Source/JavaScriptCore/heap/IsoAlignedMemoryAllocator.cpp. (JSC::IsoMemoryAllocatorBase::IsoMemoryAllocatorBase): (JSC::IsoMemoryAllocatorBase::~IsoMemoryAllocatorBase): (JSC::IsoMemoryAllocatorBase::releaseMemoryFromSubclassDestructor): (JSC::IsoMemoryAllocatorBase::tryAllocateAlignedMemory): (JSC::IsoMemoryAllocatorBase::freeAlignedMemory): * heap/IsoMemoryAllocatorBase.h: Copied from Source/JavaScriptCore/heap/IsoAlignedMemoryAllocator.h. * heap/IsoSubspace.cpp: (JSC::IsoSubspace::IsoSubspace): (JSC::IsoSubspace::tryAllocateFromLowerTier): * heap/IsoSubspace.h: * heap/PreciseAllocation.cpp: (JSC::PreciseAllocation::tryCreateForLowerTier): (JSC::PreciseAllocation::createForLowerTier): Deleted. * heap/PreciseAllocation.h: * heap/SlotVisitor.cpp: (JSC::SlotVisitor::appendJSCellOrAuxiliary): * heap/StructureAlignedMemoryAllocator.cpp: Added. (JSC::StructureAlignedMemoryAllocator::StructureAlignedMemoryAllocator): (JSC::StructureAlignedMemoryAllocator::~StructureAlignedMemoryAllocator): (JSC::StructureAlignedMemoryAllocator::dump const): (JSC::StructureAlignedMemoryAllocator::tryAllocateMemory): (JSC::StructureAlignedMemoryAllocator::freeMemory): (JSC::StructureAlignedMemoryAllocator::tryReallocateMemory): (JSC::StructureMemoryManager::StructureMemoryManager): (JSC::StructureMemoryManager::tryMallocStructureBlock): (JSC::StructureMemoryManager::freeStructureBlock): (JSC::StructureAlignedMemoryAllocator::initializeStructureAddressSpace): (JSC::StructureAlignedMemoryAllocator::tryMallocBlock): (JSC::StructureAlignedMemoryAllocator::freeBlock): (JSC::StructureAlignedMemoryAllocator::commitBlock): (JSC::StructureAlignedMemoryAllocator::decommitBlock): * heap/StructureAlignedMemoryAllocator.h: Copied from Source/JavaScriptCore/heap/IsoAlignedMemoryAllocator.h. * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo): (JSC::AssemblyHelpers::emitLoadStructure): (JSC::AssemblyHelpers::emitLoadPrototype): (JSC::AssemblyHelpers::emitRandomThunk): (JSC::AssemblyHelpers::emitConvertValueToBoolean): (JSC::AssemblyHelpers::branchIfValue): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchStructure): (JSC::AssemblyHelpers::nukeStructureAndStoreButterfly): * jit/GCAwareJITStubRoutine.cpp: (JSC::PolymorphicAccessJITStubRoutine::computeHash): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_typeof_is_undefined): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_get_prototype_of): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_property_enumerator): * jit/JITStubRoutine.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::performLLIntGetByID): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/x86.rb: * runtime/ArrayPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/BigIntPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/BooleanPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/CommonSlowPaths.cpp: (JSC::JSC_DEFINE_COMMON_SLOW_PATH): * runtime/DatePrototype.cpp: (JSC::formateDateInstance): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::sanitizedMessageString): (JSC::ErrorInstance::sanitizedNameString): (JSC::ErrorInstance::sanitizedToString): * runtime/ErrorPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/FunctionPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/HasOwnPropertyCache.h: * runtime/InitializeThreading.cpp: (JSC::initialize): * runtime/JSCConfig.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::dumpInContextAssumingStructure const): (JSC::JSValue::dumpForBacktrace const): * runtime/JSCell.cpp: (JSC::JSCell::toObjectSlow const): * runtime/JSCell.h: (JSC::JSCell::clearStructure): * runtime/JSCellInlines.h: (JSC::JSCell::structure const): (JSC::JSCell::setStructure): * runtime/JSObject.cpp: (JSC::JSObject::visitButterflyImpl): (JSC::JSObject::createInitialUndecided): (JSC::JSObject::createInitialInt32): (JSC::JSObject::createInitialDouble): (JSC::JSObject::createInitialContiguous): (JSC::JSObject::createArrayStorage): (JSC::JSObject::convertUndecidedToArrayStorage): (JSC::JSObject::convertInt32ToArrayStorage): (JSC::JSObject::convertDoubleToArrayStorage): (JSC::JSObject::convertContiguousToArrayStorage): (JSC::JSObject::putDirectCustomGetterSetterWithoutTransition): (JSC::JSObject::putDirectNonIndexAccessorWithoutTransition): * runtime/JSObject.h: (JSC::JSObject::nukeStructureAndSetButterfly): (JSC::JSObject::getPropertySlot): * runtime/JSObjectInlines.h: (JSC::JSObject::getPropertySlot): (JSC::JSObject::getNonIndexPropertySlot): (JSC::JSObject::putDirectWithoutTransition): (JSC::JSObject::putDirectInternal): * runtime/JSPropertyNameEnumerator.cpp: (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator): (JSC::JSPropertyNameEnumerator::visitChildrenImpl): * runtime/JSPropertyNameEnumerator.h: * runtime/NumberPrototype.cpp: (JSC::toThisNumber): * runtime/ObjectPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::objectPrototypeToString): * runtime/RegExpPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/StringPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::~Structure): (JSC::Structure::flattenDictionaryStructure): (JSC::Structure::dump const): (JSC::Structure::canCachePropertyNameEnumerator const): * runtime/Structure.h: (JSC::Structure::id const): * runtime/StructureChain.cpp: (JSC::StructureChain::visitChildrenImpl): * runtime/StructureID.h: Added. (JSC::StructureID::nuke const): (JSC::StructureID::isNuked const): (JSC::StructureID::decontaminate const): (JSC::StructureID::operator bool const): (JSC::StructureID::operator== const): (JSC::StructureID::operator!= const): (JSC::StructureID::bits const): (JSC::StructureID::StructureID): (JSC::StructureID::isHashTableDeletedValue const): (JSC::StructureID::decode const): (JSC::StructureID::encode): (JSC::StructureIDHash::hash): (JSC::StructureIDHash::equal): * runtime/StructureIDBlob.h: * runtime/StructureIDTable.cpp: Removed. * runtime/StructureIDTable.h: Removed. * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::tryCachePropertyNameEnumeratorViaWatchpoint): * runtime/SymbolPrototype.cpp: (JSC::JSC_DEFINE_CUSTOM_GETTER): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/TypeProfilerLog.cpp: (JSC::TypeProfilerLog::processLogEntries): (JSC::TypeProfilerLog::visit): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: (JSC::VM::getStructure): Deleted. (JSC::VM::tryGetStructure): Deleted. * tools/HeapVerifier.cpp: (JSC::HeapVerifier::validateJSCell): * tools/Integrity.cpp: * tools/Integrity.h: * tools/IntegrityInlines.h: (JSC::Integrity::auditStructureID): * tools/JSDollarVM.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::jsCallEntrypointSlow): * wasm/js/WebAssemblyGlobalPrototype.cpp: (JSC::getGlobal): 2021-11-30 Alexey Shvayka Rename "queueTaskToEventLoop" to "queueMicrotaskToEventLoop" https://bugs.webkit.org/show_bug.cgi?id=233639 Reviewed by Mark Lam. This change improves grep-ability and avoids confusion since JSDOMWindowBase's queueMicrotaskToEventLoop() is capable only of scheduling microtasks (hence its signature). ECMA-262 has no notion of macrotasks, and now JSC hasn't as well. No behavior change. * API/JSAPIGlobalObject.cpp: * API/JSAPIGlobalObject.mm: * jsc.cpp: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::queueMicrotask): * runtime/JSGlobalObject.h: 2021-11-30 Saam Barati GetMyArgumentByValOutOfBounds needs to check for negative indices https://bugs.webkit.org/show_bug.cgi?id=232966 Reviewed by Yusuke Suzuki. Negative indices inside of GetMyArgumentByValOutOfBounds would cause us to have the resulting value be undefined, instead of a full blown lookup that properly consults the prototype chain and such. The reason for this is negative indices would show up as "out of bounds", which would lead this node to result in undefined. But negative indices really should be treated as string property names, and can't be treated like normal out of bounds positive integers. This patch makes it so we speculate that we don't see negative indices. If we do see negative indices, we stop performing the transformation inside of arguments elimination so we don't end up in an OSR exit loop. * dfg/DFGArgumentsEliminationPhase.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal): 2021-11-30 Geza Lore [JSC] Unify most Baseline ops between JSVALUE64 and JSVALUE32_64 https://bugs.webkit.org/show_bug.cgi?id=233424 Reviewed by Yusuke Suzuki. This patch unifies the Baseline JIT implementations of most bytecode ops between the JSVALUE32_64 and JSVALUE64 platforms. There are very few changes to the generated code on JSVALUE64 (and all are fairly trivial, e.g.: removal of redundant moves in the slow path), apart from machine register substitutions. My measurements on x86_64 indicate the patch is performance neutral there (which is what we expect). On ARMv7/Thumb-2 JetStream2 shows a 0.4% improvement. This is due to some of the improved implementations picked up from the JSVALUE64 versions. Also remove various unused code. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::initializeFromUnlinkedStructureStubInfo): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchIfBoolean): (JSC::AssemblyHelpers::branchIfNotBoolean): (JSC::AssemblyHelpers::isUndefined): * jit/GPRInfo.h: * jit/JIT.cpp: * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_compareAndJumpImpl): (JSC::JIT::emit_compareUnsignedAndJumpImpl): (JSC::JIT::emit_compareUnsignedImpl): (JSC::JIT::emit_compareAndJumpSlowImpl): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emit_op_mod): (JSC::JIT::emitBitBinaryOpFastPath): (JSC::JIT::emit_op_bitnot): (JSC::JIT::emitRightShiftFastPath): (JSC::JIT::emitMathICFast): (JSC::JIT::emitMathICSlow): (JSC::JIT::emit_op_div): * jit/JITArithmetic32_64.cpp: Removed. * jit/JITInlineCacheGenerator.h: * jit/JITInlines.h: (JSC::JIT::emitGetVirtualRegisterPayload): (JSC::JIT::emitPutVirtualRegister): (JSC::JIT::emitJumpSlowCaseIfNotInt): (JSC::JIT::loadCodeBlockConstantPayload): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_typeof_is_undefined): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_big_int): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_to_property_key): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jundefined_or_null): (JSC::JIT::emit_op_jnundefined_or_null): (JSC::JIT::emit_op_jeq_ptr): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emit_op_neq): (JSC::JIT::compileOpStrictEq): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_numeric): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emit_op_new_regexp): (JSC::JIT::emit_op_get_rest_length): (JSC::JIT::emit_op_get_prototype_of): * jit/JITOpcodes32_64.cpp: (JSC::JIT::compileOpEqCommon): (JSC::JIT::compileOpEqSlowCommon): (JSC::JIT::emit_op_eq): (JSC::JIT::emit_op_neq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::compileOpStrictEqCommon): (JSC::JIT::emit_op_stricteq): (JSC::JIT::emit_op_nstricteq): (JSC::JIT::emit_op_jstricteq): (JSC::JIT::emit_op_jnstricteq): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): * jit/JITPropertyAccess.cpp: (JSC::JIT::generateGetByValSlowCase): (JSC::JIT::emitSlow_op_get_private_name): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_enumerator_get_by_val): (JSC::JIT::emit_enumerator_has_propertyImpl): (JSC::JIT::emitWriteBarrier): * jit/JSInterfaceJIT.h: (JSC::JSInterfaceJIT::emitLoadJSCell): 2021-11-29 Yusuke Suzuki [JSC] jumpForTypedArrayOutOfBounds should use asAnyInt since it uses isAnyInt https://bugs.webkit.org/show_bug.cgi?id=233610 rdar://85820476 Reviewed by Saam Barati. Since we are using isAnyInt, then we should use asAnyInt. asUInt32 will crash if the value is double AnyInt etc. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds): 2021-11-29 Saam Barati FTL's implementation of HasIndexedProperty for InBounds accesses checks the inverse of what it should be checking when exiting by seeing a hole https://bugs.webkit.org/show_bug.cgi?id=233408 Reviewed by Mark Lam. The implementation of an InBounds HasIndexedProperty in FTL, when speculating, we would exit when we did not see a hole, not when we did see a hole. This is the inverse of what we need to do, we should exit when we do see a hole. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * tools/JSDollarVM.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): (JSC::JSDollarVM::finishCreation): 2021-11-29 Yusuke Suzuki [JSC] slice should be aware of TerminationException https://bugs.webkit.org/show_bug.cgi?id=233593 rdar://85823844 Reviewed by Mark Lam. Since termination exception can happen at any time, assertNoException is wrong. * runtime/ArrayPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): 2021-11-29 Yusuke Suzuki [JSC] Add Intl.NumberFormat.formatRangeToParts https://bugs.webkit.org/show_bug.cgi?id=233540 Reviewed by Ross Kirsling. This patch implements Intl.NumberFormat#formatRangeToParts if ICU is 69 or greater. It also cleans up / optimizes existing Intl.NumberFormat#formatToParts implementation. We first collect all fields generated by ICU. And then, flattening nested fields into non-overlapping sequence of parts via flattenFields. * runtime/IntlNumberFormat.cpp: (JSC::flattenFields): (JSC::numberFieldsPracticallyEqual): (JSC::IntlNumberFormat::formatRangeToPartsInternal): (JSC::IntlNumberFormat::formatRangeToParts const): (JSC::IntlNumberFormat::formatToPartsInternal): (JSC::IntlNumberFormat::formatToParts const): * runtime/IntlNumberFormat.h: * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototype::finishCreation): (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/IntlRelativeTimeFormat.cpp: (JSC::IntlRelativeTimeFormat::formatToParts const): 2021-11-29 Michael Catanzaro [GTK] 2.35.1 fails to build for Fedora: undefined reference to 'llint_link_call' https://bugs.webkit.org/show_bug.cgi?id=233574 Unreviewed, add missing attributes. * llint/LLIntSlowPaths.h: 2021-11-29 Yusuke Suzuki [JSC] Public Class Field initialization is slow https://bugs.webkit.org/show_bug.cgi?id=232479 Reviewed by Alexey Shvayka. Class public field implementation did not have optimization for initializing class fields: using runtime call to initialize fields instead of IC. This patch leverages put_by_id / put_by_val with direct flag so that we can enable IC. Currently, we are not changing original putDirect semantics since it is out of this patch's scope. We will look into it and probably changing it in a separate patch, but not in this patch. ToT Patched class-fields-classic-constructor-assignments 17.1491+-2.6327 15.0906+-0.6795 might be 1.1364x faster class-fields-public-fields 409.4328+-8.3140 ^ 20.2752+-2.0835 ^ definitely 20.1938x faster class-fields-private-fields 27.2621+-1.3858 25.1810+-3.9873 might be 1.0826x faster * bytecompiler/NodesCodegen.cpp: (JSC::DefineFieldNode::emitBytecode): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::putDirectWithReify): * runtime/JSObject.cpp: (JSC::JSObject::putDirectCustomAccessor): (JSC::JSObject::putDirectNonIndexAccessor): * runtime/JSObject.h: (JSC::JSObject::putDirect): (JSC::JSObject::putDirectRespectingExtensibility): * runtime/JSObjectInlines.h: (JSC::JSObject::putInlineFast): (JSC::JSObject::putDirectInternal): (JSC::JSObject::putOwnDataProperty): (JSC::JSObject::putOwnDataPropertyMayBeIndex): 2021-11-29 Yusuke Suzuki [JSC] private name operation should use RETURN_IF_EXCEPTION https://bugs.webkit.org/show_bug.cgi?id=233577 rdar://85813869 Reviewed by Mark Lam. Because of TerminatedExecutionError, error can be thrown at any time. * jit/JITOperations.cpp: (JSC::JSC_DEFINE_JIT_OPERATION): (JSC::putPrivateNameOptimize): (JSC::putPrivateName): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): 2021-11-29 Yusuke Suzuki [JSC] Move m_incomingPolymorphicCalls out of CodeBlock::JITData https://bugs.webkit.org/show_bug.cgi?id=233415 Reviewed by Mark Lam and Darin Adler. This patch moves m_incomingPolymorphicCalls from CodeBlock::JITData to CodeBlock since it is now used in LLInt too if JIT is enabled. To keep CodeBlock small, this patch shrinks sizeof(SentinelLinkedList). * bytecode/CodeBlock.cpp: (JSC::CodeBlock::linkIncomingPolymorphicCall): (JSC::CodeBlock::unlinkIncomingCalls): * bytecode/CodeBlock.h: 2021-11-29 Yusuke Suzuki [JSC] GetTypedArrayLengthAsInt52 can get Array::Generic ArrayMode https://bugs.webkit.org/show_bug.cgi?id=233571 rdar://85812164 Reviewed by Mark Lam. If speculation is not populated enough, then GetTypedArrayLengthAsInt52 can get Array::Generic. In that case, we should convert it to Array::ForceExit as it is done in GetArrayLength. And blessArrayOperation inserts ForceOSRExit. So GetTypedArrayLengthAsInt52 won't be compiled. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileGetTypedArrayLengthAsInt52): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayLengthAsInt52): 2021-11-29 Zan Dobersek [RISCV64] Populate RISCV64Assembler with instruction-generation methods https://bugs.webkit.org/show_bug.cgi?id=233256 Reviewed by Yusuke Suzuki. Sprinkle RISCV64Assembler class with helper methods for generating the desired instruction values. Immediate types from the RISCV64Instructions namespace are introduced into the class for easier usage here and in the MacroAssemblerRISCV64 class. Instruction-generating methods roughly match the different instruction types in the RISCV64Instructions namespace. A few optimizations are done around floating-point instructions. We can use one base method which expects the desired FP size as a template parameter, and the appropriate RISCV64Instructions type can then be selected based on that size value. Different combinations for FP move and conversion instructions are also grouped behind a single method, with thorough compile-time validation done to prevent generating invalid instructions. A few helper methods intended for masking, sign-extension and zero-extension are also added. The Condition enum is fixed to list only RISCV-viable conditions, with the values ordered so that a simple XOR-by-one of a given value will produce the value of the inverted condition. * assembler/RISCV64Assembler.h: (JSC::RISCV64Assembler::invert): (JSC::RISCV64Assembler::luiInsn): (JSC::RISCV64Assembler::auipcInsn): (JSC::RISCV64Assembler::jalInsn): (JSC::RISCV64Assembler::jalrInsn): (JSC::RISCV64Assembler::beqInsn): (JSC::RISCV64Assembler::bneInsn): (JSC::RISCV64Assembler::bltInsn): (JSC::RISCV64Assembler::bgeInsn): (JSC::RISCV64Assembler::bltuInsn): (JSC::RISCV64Assembler::bgeuInsn): (JSC::RISCV64Assembler::lbInsn): (JSC::RISCV64Assembler::lhInsn): (JSC::RISCV64Assembler::lwInsn): (JSC::RISCV64Assembler::ldInsn): (JSC::RISCV64Assembler::lbuInsn): (JSC::RISCV64Assembler::lhuInsn): (JSC::RISCV64Assembler::lwuInsn): (JSC::RISCV64Assembler::sbInsn): (JSC::RISCV64Assembler::shInsn): (JSC::RISCV64Assembler::swInsn): (JSC::RISCV64Assembler::sdInsn): (JSC::RISCV64Assembler::addiInsn): (JSC::RISCV64Assembler::sltiInsn): (JSC::RISCV64Assembler::sltiuInsn): (JSC::RISCV64Assembler::xoriInsn): (JSC::RISCV64Assembler::oriInsn): (JSC::RISCV64Assembler::andiInsn): (JSC::RISCV64Assembler::slliInsn): (JSC::RISCV64Assembler::srliInsn): (JSC::RISCV64Assembler::sraiInsn): (JSC::RISCV64Assembler::addInsn): (JSC::RISCV64Assembler::subInsn): (JSC::RISCV64Assembler::sllInsn): (JSC::RISCV64Assembler::sltInsn): (JSC::RISCV64Assembler::sltuInsn): (JSC::RISCV64Assembler::xorInsn): (JSC::RISCV64Assembler::srlInsn): (JSC::RISCV64Assembler::sraInsn): (JSC::RISCV64Assembler::orInsn): (JSC::RISCV64Assembler::andInsn): (JSC::RISCV64Assembler::ecallInsn): (JSC::RISCV64Assembler::ebreakInsn): (JSC::RISCV64Assembler::addiwInsn): (JSC::RISCV64Assembler::slliwInsn): (JSC::RISCV64Assembler::srliwInsn): (JSC::RISCV64Assembler::sraiwInsn): (JSC::RISCV64Assembler::addwInsn): (JSC::RISCV64Assembler::subwInsn): (JSC::RISCV64Assembler::sllwInsn): (JSC::RISCV64Assembler::srlwInsn): (JSC::RISCV64Assembler::srawInsn): (JSC::RISCV64Assembler::mulInsn): (JSC::RISCV64Assembler::mulhInsn): (JSC::RISCV64Assembler::mulhsuInsn): (JSC::RISCV64Assembler::mulhuInsn): (JSC::RISCV64Assembler::divInsn): (JSC::RISCV64Assembler::divuInsn): (JSC::RISCV64Assembler::remInsn): (JSC::RISCV64Assembler::remuInsn): (JSC::RISCV64Assembler::mulwInsn): (JSC::RISCV64Assembler::divwInsn): (JSC::RISCV64Assembler::divuwInsn): (JSC::RISCV64Assembler::remwInsn): (JSC::RISCV64Assembler::remuwInsn): (JSC::RISCV64Assembler::flwInsn): (JSC::RISCV64Assembler::fldInsn): (JSC::RISCV64Assembler::fswInsn): (JSC::RISCV64Assembler::fsdInsn): (JSC::RISCV64Assembler::fmaddInsn): (JSC::RISCV64Assembler::fmsubInsn): (JSC::RISCV64Assembler::fnmsubInsn): (JSC::RISCV64Assembler::fnmaddInsn): (JSC::RISCV64Assembler::faddInsn): (JSC::RISCV64Assembler::fsubInsn): (JSC::RISCV64Assembler::fmulInsn): (JSC::RISCV64Assembler::fdivInsn): (JSC::RISCV64Assembler::fsqrtInsn): (JSC::RISCV64Assembler::fsgnjInsn): (JSC::RISCV64Assembler::fsgnjnInsn): (JSC::RISCV64Assembler::fsgnjxInsn): (JSC::RISCV64Assembler::fminInsn): (JSC::RISCV64Assembler::fmaxInsn): (JSC::RISCV64Assembler::feqInsn): (JSC::RISCV64Assembler::fltInsn): (JSC::RISCV64Assembler::fleInsn): (JSC::RISCV64Assembler::fclassInsn): (JSC::RISCV64Assembler::fcvtInsn): (JSC::RISCV64Assembler::fmvInsn): (JSC::RISCV64Assembler::fenceInsn): (JSC::RISCV64Assembler::lrwInsn): (JSC::RISCV64Assembler::scwInsn): (JSC::RISCV64Assembler::lrdInsn): (JSC::RISCV64Assembler::scdInsn): (JSC::RISCV64Assembler::amoswapwInsn): (JSC::RISCV64Assembler::amoaddwInsn): (JSC::RISCV64Assembler::amoxorwInsn): (JSC::RISCV64Assembler::amoandwInsn): (JSC::RISCV64Assembler::amoorwInsn): (JSC::RISCV64Assembler::amoswapdInsn): (JSC::RISCV64Assembler::amoadddInsn): (JSC::RISCV64Assembler::amoxordInsn): (JSC::RISCV64Assembler::amoanddInsn): (JSC::RISCV64Assembler::amoordInsn): (JSC::RISCV64Assembler::nop): (JSC::RISCV64Assembler::maskRegister): (JSC::RISCV64Assembler::signExtend): (JSC::RISCV64Assembler::zeroExtend): (JSC::RISCV64Assembler::insn): (JSC::RISCV64Assembler::insnFP): (JSC::RISCV64Assembler::isValidShiftAmount): 2021-11-29 Myles C. Maxfield [Cocoa] Stop linking JavaScriptCore.framework with libz because it doesn't use any symbols from it https://bugs.webkit.org/show_bug.cgi?id=233550 Reviewed by Anders Carlsson. Every compile produces a message like: Ld /Users/mmaxfield/Build/Products/Debug/JavaScriptCore.framework/Versions/A/JavaScriptCore normal (in target 'JavaScriptCore' from project 'JavaScriptCore') ld: warning: linking with (/usr/lib/libz.1.dylib) but not using any symbols from it * JavaScriptCore.xcodeproj/project.pbxproj: 2021-11-26 Adrian Perez de Castro Non-unified build fixes, late November 2021 edition https://bugs.webkit.org/show_bug.cgi?id=233493 Unreviewed non-unified build fixes. * jit/ThunkGenerators.h: Add missing inclusion of CallMode.h header, move header inclusions inside the ENABLE(JIT) guard. 2021-11-24 Zan Dobersek MacroAssembler: remove unused load/store methods for addresses with patchable offsets https://bugs.webkit.org/show_bug.cgi?id=233251 Reviewed by Yusuke Suzuki. Remove MacroAssembler methods for load and store operations on addresses with patchable offset values as they're not used in any place anymore. * assembler/MacroAssembler.h: (JSC::MacroAssembler::loadPtrWithAddressOffsetPatch): Deleted. (JSC::MacroAssembler::loadPtrWithCompactAddressOffsetPatch): Deleted. (JSC::MacroAssembler::storePtrWithAddressOffsetPatch): Deleted. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load32WithAddressOffsetPatch): Deleted. (JSC::MacroAssemblerARM64::load32WithCompactAddressOffsetPatch): Deleted. (JSC::MacroAssemblerARM64::store32WithAddressOffsetPatch): Deleted. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::load32WithAddressOffsetPatch): Deleted. (JSC::MacroAssemblerARMv7::load32WithCompactAddressOffsetPatch): Deleted. (JSC::MacroAssemblerARMv7::store32WithAddressOffsetPatch): Deleted. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::load32WithAddressOffsetPatch): Deleted. (JSC::MacroAssemblerMIPS::load32WithCompactAddressOffsetPatch): Deleted. (JSC::MacroAssemblerMIPS::store32WithAddressOffsetPatch): Deleted. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::load32WithAddressOffsetPatch): Deleted. (JSC::MacroAssemblerX86Common::load32WithCompactAddressOffsetPatch): Deleted. (JSC::MacroAssemblerX86Common::store32WithAddressOffsetPatch): Deleted. 2021-11-24 Zan Dobersek [RISCV64] Fix floating-point register listings in FPRInfo.h https://bugs.webkit.org/show_bug.cgi?id=233243 Reviewed by Yusuke Suzuki. As with general-purpose registers, fpRegT0 to fpRegT7 assignments have to match the argument registers. Index-to-FPRReg mapping functions are updated accordingly. * jit/FPRInfo.h: (JSC::FPRInfo::toRegister): (JSC::FPRInfo::toIndex): 2021-11-24 Aditi Singh [JSC] Implement Date.prototype.toTemporalInstant() https://bugs.webkit.org/show_bug.cgi?id=232075 Reviewed by Yusuke Suzuki. * runtime/CommonIdentifiers.h: * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): (JSC::JSC_DEFINE_HOST_FUNCTION): 2021-11-23 Don Olmstead Non-unified build fixes, mid November 2021 edition https://bugs.webkit.org/show_bug.cgi?id=233450 Unreviewed non-unified build fixes. * heap/IsoHeapCellType.h: * jit/ThunkGenerators.h: 2021-11-22 Geza Lore [JSC] Make sharing of unlinked baseline code possible on JSVALUE32_64 https://bugs.webkit.org/show_bug.cgi?id=232624 Reviewed by Yusuke Suzuki. This patch contains a few different changes, which taken together make it possible to share the unlinked baseline JIT code between different CodeBlocks on JSVALUE32_64 platforms. Note that by default, code sharing is disabled on JSVALUE32_64 due to the increased executable memory usage it may cause. The reson the executable memory usage might increase is that the UnlinkedCodeBlock has a longer lifetime than the corresponding linked CodeBlocks (due to the CodeCache I'm told), and when using code sharing, it holds a reference to the JITed code. This then prevents recycling of executable memory while the UnlinkedCodeBlock is live, while without sharing we could have reclaimed some of the executable memory earlier. The high level changes in this pach are: 1. A lot of baseline implementations of the opcodes that needed changing for the unlinked baseline are now unified between the JSVALUE64 and JSVALUE32_64 platforms. Note that while this required adding some abstraction, the code generated by the baseline JIT on JSVALUE64 should be identical using this abstraction compared to before. 2. I added a JSRInfo class which defines standard names for certain JSValueReg instances. This enables a lot of the unification in the point above to be expressed in a very simple manner, with very little transformation of the existing code. Again, this should have no impact on the generated code on JSVALUE64, apart from some register substitutions. 3. The sizes of the resolve_scope and get_from_scope ops increased significantly with the unlinked baseline. This can cause issues on some JSVALUE32_64 targets where memory is more precious, so for these two ops I swapped in the implementations under EXTRA_CTI_THUNKS, which implement these using shared stubs. These stubs work on all platforms that support ENABLE(JIT), so they are now the only implementation and I have removed the basic bloated versions. 4. Removed some unused code and fields I discovered while working on this, strictly speaking this is not necessary for the functional change. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::storeValue): (JSC::AssemblyHelpers::isNull): (JSC::AssemblyHelpers::isNotNull): (JSC::AssemblyHelpers::emitTurnUndefinedIntoNull): (JSC::AssemblyHelpers::noOverlap): (JSC::AssemblyHelpers::noOverlapImpl): (JSC::AssemblyHelpers::noOverlapImplRegMask): * jit/GPRInfo.h: * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): (JSC::JIT::compileAndLinkWithoutFinalizing): (JSC::JIT::link): (JSC::JIT::privateCompileExceptionHandlers): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_compareAndJumpImpl): (JSC::JIT::emit_compareUnsignedAndJumpImpl): (JSC::JIT::emit_compareUnsignedImpl): (JSC::JIT::emit_op_mod): (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emitBinaryDoubleOp): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): * jit/JITCall.cpp: (JSC::JIT::emit_op_ret): (JSC::JIT::compileSetupFrame): (JSC::JIT::compileOpCall): (JSC::JIT::emit_op_iterator_open): (JSC::JIT::emit_op_iterator_next): * jit/JITInlines.h: (JSC::JIT::getConstantOperand): (JSC::JIT::appendCallWithExceptionCheckSetJSValueResult): (JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile): (JSC::JIT::emitValueProfilingSiteIfProfiledOpcode): (JSC::JIT::emitValueProfilingSite): (JSC::JIT::emitGetVirtualRegister): (JSC::JIT::emitPutVirtualRegister): (JSC::JIT::emitGetVirtualRegisterPayload): (JSC::JIT::emitGetVirtualRegisterTag): (JSC::JIT::emitLoadDouble): (JSC::loadAddrOfCodeBlockConstantBuffer): (JSC::JIT::loadCodeBlockConstant): (JSC::JIT::loadCodeBlockConstantPayload): (JSC::JIT::loadCodeBlockConstantTag): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_new_object): (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_typeof_is_undefined): (JSC::JIT::emit_op_is_undefined_or_null): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_jfalse): (JSC::JIT::valueIsFalseyGenerator): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jeq_ptr): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emit_op_jtrue): (JSC::JIT::valueIsTruthyGenerator): (JSC::JIT::emit_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emit_op_throw): (JSC::JIT::compileOpStrictEq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emit_op_switch_imm): (JSC::JIT::emit_op_switch_char): (JSC::JIT::emit_op_switch_string): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_instanceof_custom): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emit_op_loop_hint): (JSC::JIT::emitNewFuncCommon): (JSC::JIT::emitNewFuncExprCommon): (JSC::JIT::emit_op_new_array_with_size): (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): (JSC::JIT::emit_op_get_argument): (JSC::JIT::emit_op_get_prototype_of): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_to_property_key): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jundefined_or_null): (JSC::JIT::emit_op_jnundefined_or_null): (JSC::JIT::emit_op_jeq_ptr): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::compileOpEqJumpSlow): (JSC::JIT::emit_op_neq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::compileOpStrictEq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_numeric): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_enter): (JSC::JIT::emit_op_check_tdz): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_getter_by_id): (JSC::JIT::emit_op_put_setter_by_id): (JSC::JIT::emit_op_put_getter_setter_by_id): (JSC::JIT::emit_op_put_getter_by_val): (JSC::JIT::emit_op_put_setter_by_val): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::generateOpResolveScopeThunk): (JSC::JIT::slow_op_resolve_scopeGenerator): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::generateOpGetFromScopeThunk): (JSC::JIT::slow_op_get_from_scopeGenerator): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): (JSC::JIT::emit_op_get_internal_field): (JSC::JIT::emit_op_put_internal_field): (JSC::JIT::emit_op_get_property_enumerator): (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): (JSC::JIT::emitWriteBarrier): * jit/JITPropertyAccess32_64.cpp: Removed. * jit/JSInterfaceJIT.h: * jit/ThunkGenerators.cpp: (JSC::popThunkStackPreservesAndHandleExceptionGenerator): * jit/ThunkGenerators.h: * runtime/OptionsList.h: 2021-11-20 Yusuke Suzuki [JSC] Move RepatchXXX from jit to bytecode https://bugs.webkit.org/show_bug.cgi?id=233395 Reviewed by Mark Lam. They are also used by non JIT code too. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/Repatch.cpp: Renamed from Source/JavaScriptCore/jit/Repatch.cpp. * bytecode/Repatch.h: Renamed from Source/JavaScriptCore/jit/Repatch.h. * bytecode/RepatchInlines.h: Renamed from Source/JavaScriptCore/jit/RepatchInlines.h. 2021-11-19 Asumu Takikawa Fix WebAssembly memory.fill out of bounds error message https://bugs.webkit.org/show_bug.cgi?id=233392 Reviewed by Yusuke Suzuki. * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::addMemoryFill): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addMemoryFill): * wasm/WasmSlowPaths.cpp: (JSC::LLInt::WASM_SLOW_PATH_DECL): 2021-11-19 Commit Queue Unreviewed, reverting r286030. https://bugs.webkit.org/show_bug.cgi?id=233387 5% JetStream2 regression Reverted changeset: "DFGByteCodeParser.cpp should avoid resizing the Operands<> of every BasicBlock on every inlining" https://bugs.webkit.org/show_bug.cgi?id=228053 https://commits.webkit.org/r286030 2021-11-19 Saam Barati Fix assertion added in r285592 https://bugs.webkit.org/show_bug.cgi?id=233373 rdar://85451012 Reviewed by Keith Miller. The assertion added in r285592 should not apply to Symbols. This patch fixes that error. We don't care if a Symbol can be parsed as an index since the string value in a Symbol is just its description, not the actual property. * dfg/DFGValidate.cpp: 2021-11-19 Joseph Griego [JSC] Shadow realms: set correct Function prototype on wrapped functions https://bugs.webkit.org/show_bug.cgi?id=233143 Reviewed by Yusuke Suzuki. At present, the Function prototype set on each of the returned wrapped functions will be the Function object from the realm the shadow realm builtin is from--to comply with the latest draft of the shadow realms spec [1], wrapped function objects should have the Function prototype from the realm the wrapper object is destined for, instead. At present, this requires tracking both the calling (destination) and target (source) realm and switching between the two as function arguments are wrapped (when the notion of source and destination realm also flips) Adds a simple builtin (moveFunctionToRealm) that can switch the Function prototype given only the Shadow Realm object corresponding to the correct global object. Also marks the corresponding part of test262 as passing. [1] https://tc39.es/proposal-shadowrealm/ sections 2.1, 2.2 * builtins/BuiltinNames.h: * builtins/ShadowRealmPrototype.js: (wrapped): (globalPrivate.wrap): (evaluate): (importValue): (globalPrivate.wrap.wrapped): Deleted. * bytecode/LinkTimeConstant.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/ShadowRealmPrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): * runtime/ShadowRealmPrototype.h: 2021-11-19 Robin Morisset AirFixObviousSpills should be optimized https://bugs.webkit.org/show_bug.cgi?id=228052 Reviewed by Yusuke Suzuki. There were two problems with AirFixObviousSpills: - merge() had a quadratic blow-up, as for each element in a vector, it was searching it in a different vector. - it would visit blocks even when their state at head had not changed. I fixed the first problem by making sure that the vectors are sorted before calling merge, and making use of that invariant in the search of the vectors (see filterVectorAgainst) This reduced the total time spent in that phase from 390ms to 230ms, and the worst case time spent in that phase for one function from 100ms to 30ms (all of the results in this Changelog are for JetStream2 on a M1 MBP). I fixed the second problem even more easily by adding a m_shouldVisit BitVector. I also moved the m_wasVisited boolean that was in State to a m_notBottom BitVector for simplicity and symmetry. That change further reduced the total/max time from 230ms/30ms to 140ms/16ms. * b3/air/AirFixObviousSpills.cpp: 2021-11-18 Robin Morisset [JSC/Air] Optimize enableMovesOnValueAndAdjacents in IRC https://bugs.webkit.org/show_bug.cgi?id=228615 Reviewed by Saam Barati. The Iterated Register Coalescing (IRC) register allocator spends a very significant fraction of its time in JS2 in enableMovesOnValueAndAdjacents (816ms out of 2.07s spent in register allocation for Wasm code in one run I looked at with Instruments). The reason is that if this function is called on N nodes that are neighbors of each other, then enableMovesOnValue (which is kinda expensive as it iterates a SmallSet which is not always small) will be called N times on each of the N nodes. This can trivially be fixed by keeping track of which nodes need enableMovesOnValue called on them and only calling it on them once. It is a bit tricky to measure the performance impact of this, as it heavily depends on whether some very large functions reach Air or not, so there is a lot of noise. Here are the numbers out of 4 runs of JS2 (cli version) on an M1 MBP with --airForceIRCAllocator=1: Baseline : total time in allocateRegistersByGraphColoring ranges from 2090ms to 3018ms, most time for a single function ranges from 631ms to 849ms With this patch: total time in allocateRegistersByGraphColoring ranges from 1580ms to 2333ms, most time for a single function ranges from 337ms to 560ms So despite the noise it seems quite clearly a win. * b3/air/AirAllocateRegistersByGraphColoring.cpp: 2021-11-18 Mark Lam SubSpace constructors should take a const HeapCellType& instead of a HeapCellType*. https://bugs.webkit.org/show_bug.cgi?id=233341 rdar://85573277 Reviewed by Yusuke Suzuki. This helps document that HeapCellTypes are immutable once they are instantiated, and that SubSpaces won't be modifying them. Also remove the const on CellAttributes return values since it is not needed nor meaningful. * heap/BlockDirectory.h: (JSC::BlockDirectory::attributes const): * heap/CompleteSubspace.cpp: (JSC::CompleteSubspace::CompleteSubspace): * heap/CompleteSubspace.h: * heap/HeapCellType.cpp: (JSC::HeapCellType::finishSweep const): (JSC::HeapCellType::destroy const): (JSC::HeapCellType::finishSweep): Deleted. (JSC::HeapCellType::destroy): Deleted. * heap/HeapCellType.h: (JSC::HeapCellType::attributes const): * heap/IsoHeapCellType.cpp: (JSC::IsoHeapCellType::finishSweep const): (JSC::IsoHeapCellType::destroy const): (JSC::IsoHeapCellType::finishSweep): Deleted. (JSC::IsoHeapCellType::destroy): Deleted. * heap/IsoHeapCellType.h: * heap/IsoInlinedHeapCellType.h: * heap/IsoSubspace.cpp: (JSC::IsoSubspace::IsoSubspace): * heap/IsoSubspace.h: * heap/IsoSubspacePerVM.cpp: (JSC::IsoSubspacePerVM::forVM): * heap/IsoSubspacePerVM.h: * heap/MarkedBlock.h: (JSC::MarkedBlock::Handle::attributes const): (JSC::MarkedBlock::attributes const): * heap/PreciseAllocation.h: (JSC::PreciseAllocation::attributes const): * heap/Subspace.cpp: (JSC::Subspace::initialize): * heap/Subspace.h: (JSC::Subspace::heapCellType const): * heap/SubspaceInlines.h: (JSC::Subspace::attributes const): * runtime/JSDestructibleObjectHeapCellType.cpp: (JSC::JSDestructibleObjectHeapCellType::finishSweep const): (JSC::JSDestructibleObjectHeapCellType::destroy const): (JSC::JSDestructibleObjectHeapCellType::finishSweep): Deleted. (JSC::JSDestructibleObjectHeapCellType::destroy): Deleted. * runtime/JSDestructibleObjectHeapCellType.h: * runtime/VM.cpp: (JSC::VM::VM): 2021-11-18 Mark Lam Rename PropertyMapHashTable.h to PropertyTable.h to match the class. https://bugs.webkit.org/show_bug.cgi?id=233333 rdar://85565760 Reviewed by Yusuke Suzuki. Also renamed some supporting data structures to match. This is just a refactoring patch. There are no behavior changes. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/PropertyMapHashTable.h: Removed. * runtime/PropertyTable.cpp: * runtime/PropertyTable.h: Copied from Source/JavaScriptCore/runtime/PropertyMapHashTable.h. (JSC::PropertyTable::find): (JSC::PropertyTable::get): (JSC::PropertyTable::add): (JSC::PropertyTable::remove): (JSC::PropertyTable::reinsert): (JSC::PropertyTable::rehash): * runtime/Structure.cpp: (JSC::PropertyTableStatisticsExitLogger::PropertyTableStatisticsExitLogger): (JSC::PropertyTableStatisticsExitLogger::~PropertyTableStatisticsExitLogger): (JSC::PropertyMapStatisticsExitLogger::PropertyMapStatisticsExitLogger): Deleted. (JSC::PropertyMapStatisticsExitLogger::~PropertyMapStatisticsExitLogger): Deleted. * runtime/StructureInlines.h: * runtime/VM.cpp: 2021-11-18 Mark Lam CellAttributes should be returned by value. https://bugs.webkit.org/show_bug.cgi?id=233335 rdar://85568435 Reviewed by Yusuke Suzuki. CellAttributes fits in 16 bits, and client code never modifies returned CellAttributes values. Hence, there is no reason to return them by reference. Also fixed a bit-rotted comment in SubSpace.h. * heap/BlockDirectory.h: (JSC::BlockDirectory::attributes const): * heap/HeapCellType.h: (JSC::HeapCellType::attributes const): * heap/MarkedBlock.h: (JSC::MarkedBlock::Handle::attributes const): (JSC::MarkedBlock::attributes const): * heap/PreciseAllocation.h: (JSC::PreciseAllocation::attributes const): * heap/Subspace.h: * heap/SubspaceInlines.h: (JSC::Subspace::attributes const): 2021-11-18 Robin Morisset DFGByteCodeParser.cpp should avoid resizing the Operands<> of every BasicBlock on every inlining https://bugs.webkit.org/show_bug.cgi?id=228053 Reviewed by Saam Barati. The dfg bytecode parser only makes use of block->variablesAtTail. But currently it updates the size of variablesAtHead, valuesAtHead, valuesAtTail and intersectionOfPastValuesAtHead every single time it changes the number of Tmps and/or Locals. This happens notably whenever it inlines a function. It is not nearly as cheap as it looks, as each resizing may reallocate a Vector, requires filling the new slots with zeros, and requires moving the existing values (which are all 0) to the new Vector. This was obvious when looking at profiling of JS2: bzero + memmove are the two hottest C++ functions, and the manipulation of Operands is partly responsible. This patch fixes this by only resizing block->variablesAtTail during the execution of the bytecode parser, and initializing all of the other operands at the very end of it. It also merges the adjustment of numLocals and of numTmps for variablesAtTail during inlining, to avoid accidentally moving data twice. On JetStream2 on an M1 MBP, it changes the total time spent in the DFGByteCodeParser from 1240-1260ms to 1155-1170ms. * bytecode/Operands.h: (JSC::Operands::ensureLocalsAndTmps): * dfg/DFGBasicBlock.cpp: * dfg/DFGBasicBlock.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::ensureLocalsForVariablesAtTail): (JSC::DFG::ByteCodeParser::ensureLocalsAndTmpsForVariablesAtTail): (JSC::DFG::ByteCodeParser::allocateBlock): (JSC::DFG::ByteCodeParser::allocateTargetableBlock): (JSC::DFG::ByteCodeParser::allocateUntargetableBlock): (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::handleVarargsInlining): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::handlePutById): (JSC::DFG::ByteCodeParser::parse): 2021-11-18 Yusuke Suzuki [JSC] Add branchTest16 operation https://bugs.webkit.org/show_bug.cgi?id=233275 Reviewed by Mark Lam. This patch adds branchTest16 to all macro assemblers. And it also fixes the existing bug of edge case of branchTest8: when we cannot represent the imm as ARM logical value, then we are failing to emit the right instructions. Probably this bug does not appear since we are not using such a value as an imm for branchTest8. We added tests to testmasm so that these code is stressed now. * assembler/MacroAssembler.h: (JSC::MacroAssembler::branchTest16): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load16SignedExtendTo32): (JSC::MacroAssemblerARM64::branchTest32): (JSC::MacroAssemblerARM64::branchTest8): (JSC::MacroAssemblerARM64::branchTest16): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::branchTest16): (JSC::MacroAssemblerARMv7::test32): (JSC::MacroAssemblerARMv7::test8): * assembler/MacroAssemblerHelpers.h: (JSC::MacroAssemblerHelpers::mask16OnCondition): (JSC::MacroAssemblerHelpers::load16OnCondition): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::load16): (JSC::MacroAssemblerMIPS::load16SignedExtendTo32): (JSC::MacroAssemblerMIPS::mask16OnTest): (JSC::MacroAssemblerMIPS::branchTest16): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::branchTest16): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::branchTest16): * assembler/X86Assembler.h: (JSC::X86Assembler::cmpw_im): (JSC::X86Assembler::testw_im): * assembler/testmasm.cpp: (JSC::testBranchTest8): (JSC::testBranchTest16): 2021-11-18 David Kilzer Add missing dependencies for when generating derived sources Reviewed by Darin Adler. * JavaScriptCore.xcodeproj/project.pbxproj: (Derived Sources : Generate Derived Sources): - Add an input dependency on the script run from the build phase script. * DerivedSources-input.xcfilelist: - Update after changes to DerivedSoures.make. WebKit headers included by are now listed. * DerivedSources.make: (platform_h_compiler_command): Add. (FEATURE_AND_PLATFORM_DEFINES): - Extract compiler command into a call routine for reuse. (PLATFORM_HEADER_DIR): Add. (PLATFORM_HEADER_DEPENDENCIES): Add. (FEATURE_AND_PLATFORM_DEFINE_DEPENDENCIES): - Generate a makefile dependency list for , then filter it to list only WebKit project headers. 2021-11-18 Carlos Garcia Campos [GLIB] jsc_value_object_define_property_accessor() throws an exception when called on a value without a wrapper instance https://bugs.webkit.org/show_bug.cgi?id=233253 Reviewed by Michael Catanzaro. We assumed that getter and setter were always methods, so we always try to set the initial parameter as the instance. When called with a value not having an instance we get an exception because the expected instance is nullptr. This patch changes the behavior of jsc_value_object_define_property_accessor() to call the getter and setter as functions, but keeping the behavior of jsc_class_add_property() in which case they are still called as methods. * API/glib/JSCClass.cpp: (jsc_class_add_property): Use jscValueAddPropertyAccessor(). * API/glib/JSCValue.cpp: (jsObjectCall): Remove useless break after return. (jscValueObjectDefinePropertyAccessor): Helper to define the property accessor using the given function type for the getter and setter. (jsc_value_object_define_property_accessor): Call jscValueObjectDefinePropertyAccessor() with function as function type. (jscValueAddPropertyAccessor): Call jscValueObjectDefinePropertyAccessor() with method as function type. * API/glib/JSCValuePrivate.h: 2021-11-17 Yusuke Suzuki [JSC] TypedArray GetArrayLength should not use Reuse https://bugs.webkit.org/show_bug.cgi?id=233299 rdar://85502079 Reviewed by Robin Morisset. We should not perform OSR exit after assigning a value to a reused register, otherwise, OSR exit cannot recover the proper value. Now TypedArray GetArrayLength can perform OSR exit after loading a length, so we should not use reused register for length. * dfg/DFGSpeculativeJIT.cpp: 2021-11-17 Saam Barati Run the memmove fast path in JSGenericTypedArrayView