[webkit-changes] [WebKit/WebKit] 273f52: [ARMv7] Support running testb3
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 273f5243aa85af80bc22a9dbbd370efc61e726f6 https://github.com/WebKit/WebKit/commit/273f5243aa85af80bc22a9dbbd370efc61e726f6 Author: Joseph Griego Date: 2024-08-28 (Wed, 28 Aug 2024) Changed paths: M Source/JavaScriptCore/b3/B3Generate.cpp M Source/JavaScriptCore/b3/B3LowerToAir32_64.cpp M Source/JavaScriptCore/b3/B3Procedure.h M Source/JavaScriptCore/b3/air/AirCCallingConvention.cpp M Source/JavaScriptCore/b3/air/AirCCallingConvention.h M Source/JavaScriptCore/b3/air/AirCustom.cpp M Source/JavaScriptCore/b3/air/AirCustom.h M Source/JavaScriptCore/b3/air/AirLowerMacros.cpp M Source/JavaScriptCore/b3/testb3.h M Source/JavaScriptCore/b3/testb3_1.cpp M Source/JavaScriptCore/b3/testb3_2.cpp M Source/JavaScriptCore/b3/testb3_3.cpp M Source/JavaScriptCore/b3/testb3_4.cpp M Source/JavaScriptCore/b3/testb3_5.cpp M Source/JavaScriptCore/b3/testb3_6.cpp M Source/JavaScriptCore/b3/testb3_7.cpp M Source/JavaScriptCore/b3/testb3_8.cpp A Source/JavaScriptCore/b3/testb3_failingArmV7Tests.inc A Tools/Scripts/canonicalize-testb3-ir.py A Tools/Scripts/dump-testb3-ir Log Message: --- [ARMv7] Support running testb3 https://bugs.webkit.org/show_bug.cgi?id=276367 Reviewed by OOPS. This patch was written by Joseph Griego a while back. This does the following: - Support running testb3 on armv7 - Allow dumping testb3 output, to ensure these changes don't affect other platforms testb3 does not pass fully yet, but it does pass simple tests like testRotR. I also added a list of skipped subtests, and confirmed on x86_64 and ARM64 (non-E) that the generated B3 code is not changed. To make these tests run, we mostly just abstract the calling convention away. Every other change is mechanical. Canonical link: https://commits.webkit.org/282881@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 3f9563: [JSC][armv7] Unreviewed: Unskip some tests; change...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 3f9563a839d341f6cbdd2a2e0874a7678208aa53 https://github.com/WebKit/WebKit/commit/3f9563a839d341f6cbdd2a2e0874a7678208aa53 Author: Joseph Griego Date: 2024-02-16 (Fri, 16 Feb 2024) Changed paths: M JSTests/microbenchmarks/array-from-object-func.js M JSTests/stress/dont-link-virtual-calls-on-compiler-thread.js M JSTests/wasm/function-tests/memory-access-past-4gib.js M JSTests/wasm/js-api/test_memory.js M JSTests/wasm/modules/wasm-imports-js-exports.js Log Message: --- [JSC][armv7] Unreviewed: Unskip some tests; change skip conditions to $memoryLimited https://bugs.webkit.org/show_bug.cgi?id=269479 Unreviewed gardening. Thse tests pass now; the microbenchmarks/array-from{,-derived-object}-func.js tests should probably use $memoryLimited as a skip condition rather than the architecture. * JSTests/microbenchmarks/array-from-derived-object-func.js: * JSTests/microbenchmarks/array-from-object-func.js: * JSTests/stress/dont-link-virtual-calls-on-compiler-thread.js: * JSTests/wasm/function-tests/memory-access-past-4gib.js: * JSTests/wasm/js-api/test_memory.js: * JSTests/wasm/modules/wasm-imports-js-exports.js: Canonical link: https://commits.webkit.org/274830@main To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 47d90d: [JSC][armv7] Fix crashes in wasm tests in CallFram...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 47d90d73bf82af1dc02357be03cd1ad1b2895a22 https://github.com/WebKit/WebKit/commit/47d90d73bf82af1dc02357be03cd1ad1b2895a22 Author: Joseph Griego Date: 2024-02-06 (Tue, 06 Feb 2024) Changed paths: M Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp Log Message: --- [JSC][armv7] Fix crashes in wasm tests in CallFrameShuffler https://bugs.webkit.org/show_bug.cgi?id=268828 Reviewed by Yusuke Suzuki. A number of (especially wasm) tests are failing after https://github.com/WebKit/WebKit/pull/23620, with an assertion in `CallFrameShuffler::emitStore`. We just need to use `UnboxedInt32InGPR` instead of `InGPR` for the pointer registers that need to be preserved when preparing for a tail call, since the 32-bit CallFrameShuffler doesn't know how to deal with `InGPR`. * Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): Canonical link: https://commits.webkit.org/274195@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] ab656f: [JSC][armv7] Unreviewed: Skip slowMicrobenchmarks/...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: ab656fa30df92be4b8a0c5caa7ba7ee70f9fa528 https://github.com/WebKit/WebKit/commit/ab656fa30df92be4b8a0c5caa7ba7ee70f9fa528 Author: Joseph Griego Date: 2024-02-06 (Tue, 06 Feb 2024) Changed paths: M JSTests/slowMicrobenchmarks/fake-iterators-that-throw-when-finished.js Log Message: --- [JSC][armv7] Unreviewed: Skip slowMicrobenchmarks/fake-iterators-that-throw-when-finished https://bugs.webkit.org/show_bug.cgi?id=268831 Unreviewed gardening. Test hangs on armv7 linux on a box with many cores (like the EWS runners), probably due to lock contention in the HeapHelper threads; skip for now while working on a proper fix to make EWS smoother. * JSTests/slowMicrobenchmarks/fake-iterators-that-throw-when-finished.js: Canonical link: https://commits.webkit.org/274155@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 55815d: [JSC][armv7] Enable concurrent JIT
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 55815dc77e790829e87cda3bd37ddbb5c536e5e7 https://github.com/WebKit/WebKit/commit/55815dc77e790829e87cda3bd37ddbb5c536e5e7 Author: Joseph Griego Date: 2024-01-31 (Wed, 31 Jan 2024) Changed paths: M LayoutTests/js/script-tests/regress-139548.js M Source/JavaScriptCore/bytecode/ValueProfile.h M Source/JavaScriptCore/jit/AssemblyHelpers.h M Source/JavaScriptCore/llint/LowLevelInterpreter.asm M Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm M Source/JavaScriptCore/offlineasm/arm.rb M Source/JavaScriptCore/offlineasm/instructions.rb M Source/JavaScriptCore/runtime/JSCJSValue.h M Source/JavaScriptCore/runtime/WriteBarrier.h M Source/JavaScriptCore/runtime/WriteBarrierInlines.h M Source/WTF/wtf/PlatformEnable.h Log Message: --- [JSC][armv7] Enable concurrent JIT https://bugs.webkit.org/show_bug.cgi?id=239821 Reviewed by Justin Michaud. Here we are again--the goal is to enable concurrent JIT support on ARMv7--the problem, of course, is we don't have a way to update a JSValue atomically, with the current encoding. ** Approach Previous passes at this have tried to cope with the possibility of reading a "spliced JSValue"--i.e., a value observed with a CellTag and a not-Cell payload; this seems to work but isn't great and we don't have a way to get reasonable answers from e.g. value profiles when this happens. Instead, we develop the following protocol for updating a JSValue: - Write a newly-reserved tag value, `InvalidTag` to the tag part of the value, - Write the new payload word - Write the new tag word Now, when _reading_ a JSValue from threads other than the mutator, we can use doubleword atomics and retry until the tag value is not `InvalidTag`. Unfortunately, although in practice I've been unable to find any hardware where store reordering seems to be observable, the architecture requires us to insert store-store fences (`dmb ishst`) between these writes; this isn't free, as discussed below. ** Implementation We add a few new primitives for manipulating JSValues in memory that are used in some key places where JSValues are accessed concurrently: ValueProfiles and any JSValue behind a WriteBarrier (which addresses most things in the heap.) As discussed above, for writes, we perform the 3 fenced stores, in order; reads are retried until the tag is not InvalidTag; and a `clearEncodedJSValueConcurrent` is provided since this operation does not require fences (only the tag is modified) ** Performance The addition of fences adds a nontrivial performance cost, especially for code that spends a lot of time in the interpreter; however, this is still an improvement for JetStream2 first-run times on some benchmarks, overall, the performance is about the same for JS2. I expect a regression to code size because of the extra stores--though I believe there's opportunity to optimize some of these away in the JITs based on speculation--if we know the JSValue is already a cell or non-cell, the InvalidTag store is unnecssary and can be omitted. * Source/JavaScriptCore/bytecode/ValueProfile.h: (JSC::ValueProfileBase::clearBuckets): (JSC::ValueProfileBase::classInfo const): (JSC::ValueProfileBase::numberOfSamples const): (JSC::ValueProfileBase::isLive const): (JSC::ValueProfileBase::computeUpdatedPrediction): * Source/JavaScriptCore/jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::storeAndFence32): (JSC::AssemblyHelpers::storeCell): (JSC::AssemblyHelpers::storeValue): (JSC::AssemblyHelpers::storeTrustedValue): * Source/JavaScriptCore/llint/LowLevelInterpreter.asm: * Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm: * Source/JavaScriptCore/offlineasm/arm.rb: * Source/JavaScriptCore/offlineasm/instructions.rb: * Source/JavaScriptCore/runtime/JSCJSValue.h: (JSC::JSValue::decodeConcurrent): (JSC::updateEncodedJSValueConcurrent): (JSC::clearEncodedJSValueConcurrent): * Source/JavaScriptCore/runtime/WriteBarrier.h: * Source/JavaScriptCore/runtime/WriteBarrierInlines.h: (JSC::RawValueTraits>::set): * Source/WTF/wtf/PlatformEnable.h: Canonical link: https://commits.webkit.org/273841@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] f1cd53: [JSC][armv7] Unreviewed: Skip failing tests on lin...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: f1cd53b0a8e7d197d0f58fd6bab9d072f8d234ff https://github.com/WebKit/WebKit/commit/f1cd53b0a8e7d197d0f58fd6bab9d072f8d234ff Author: Joseph Griego Date: 2024-01-26 (Fri, 26 Jan 2024) Changed paths: M JSTests/microbenchmarks/array-from-derived-object-func.js M JSTests/microbenchmarks/array-from-object-func.js M JSTests/microbenchmarks/get-private-name.js M JSTests/microbenchmarks/object-is.js M JSTests/slowMicrobenchmarks/map-constant-key.js M JSTests/stress/gc-b3.js M JSTests/stress/proxy-set-failure-inline-cache.js M JSTests/stress/sampling-profiler-richards.js M JSTests/wasm/function-tests/memory-access-past-4gib.js Log Message: --- [JSC][armv7] Unreviewed: Skip failing tests on linux-armv7 https://bugs.webkit.org/show_bug.cgi?id=268179 Unreviewed gardening. Many of these are legitimate problems and need to be fixed; but EWS is having a bad day and it would help tremendously if they weren't run. * JSTests/microbenchmarks/array-from-derived-object-func.js: * JSTests/microbenchmarks/array-from-object-func.js: * JSTests/microbenchmarks/get-private-name.js: * JSTests/microbenchmarks/object-is.js: * JSTests/slowMicrobenchmarks/map-constant-key.js: * JSTests/stress/gc-b3.js: * JSTests/stress/proxy-set-failure-inline-cache.js: * JSTests/stress/sampling-profiler-richards.js: * JSTests/wasm/function-tests/memory-access-past-4gib.js: Canonical link: https://commits.webkit.org/273570@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 22599e: [JSC][armv7] Re-enable DFG after CallIC changes
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 22599e19e5d7d89b799a199b57490d287105944d https://github.com/WebKit/WebKit/commit/22599e19e5d7d89b799a199b57490d287105944d Author: Joseph Griego Date: 2024-01-24 (Wed, 24 Jan 2024) Changed paths: M Source/JavaScriptCore/runtime/Options.cpp Log Message: --- [JSC][armv7] Re-enable DFG after CallIC changes https://bugs.webkit.org/show_bug.cgi?id=267947 Reviewed by Yusuke Suzuki. After 65c8acc4699947d9a9b6326b9672a2fca5804a8c, DFG was broken on armv7 and was disabled. However, this breakage was due to DFG calls not checking the tag word of the callee and also skipping part of the tail-call preparation due to an old, unused patchable branch; incidentally, both were fixed in d0345d69220e43945f9b9632378eab88cb50e1da, so, we can re-enable DFG if test cases are passing again. * Source/JavaScriptCore/runtime/Options.cpp: (JSC::Options::notifyOptionsChanged): Canonical link: https://commits.webkit.org/273415@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 557d5c: [JSC] Remove unmaintained MIPS support for JIT/LLInt
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 557d5c09eaa8b73f68df370a2f3aef21523e3624 https://github.com/WebKit/WebKit/commit/557d5c09eaa8b73f68df370a2f3aef21523e3624 Author: Joseph Griego Date: 2024-01-10 (Wed, 10 Jan 2024) Changed paths: M Source/JavaScriptCore/API/tests/ExecutionTimeLimitTest.cpp M Source/JavaScriptCore/CMakeLists.txt M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/Sources.txt M Source/JavaScriptCore/assembler/CPU.h M Source/JavaScriptCore/assembler/LinkBuffer.cpp R Source/JavaScriptCore/assembler/MIPSAssembler.h R Source/JavaScriptCore/assembler/MIPSRegisters.h M Source/JavaScriptCore/assembler/MacroAssembler.h R Source/JavaScriptCore/assembler/MacroAssemblerMIPS.cpp R Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h M Source/JavaScriptCore/assembler/MaxFrameExtentForSlowPathCall.h M Source/JavaScriptCore/assembler/PerfLog.cpp M Source/JavaScriptCore/assembler/ProbeContext.cpp M Source/JavaScriptCore/assembler/ProbeContext.h M Source/JavaScriptCore/assembler/RegisterInfo.h M Source/JavaScriptCore/assembler/testmasm.cpp M Source/JavaScriptCore/bytecode/InlineAccess.h M Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h M Source/JavaScriptCore/disassembler/CapstoneDisassembler.cpp M Source/JavaScriptCore/jit/AssemblyHelpers.h M Source/JavaScriptCore/jit/CCallHelpers.h M Source/JavaScriptCore/jit/ExecutableAllocator.h M Source/JavaScriptCore/jit/FPRInfo.h M Source/JavaScriptCore/jit/GPRInfo.h M Source/JavaScriptCore/jit/RegisterSet.cpp M Source/JavaScriptCore/jit/ThunkGenerators.cpp M Source/JavaScriptCore/llint/LLIntOfflineAsmConfig.h M Source/JavaScriptCore/llint/LLIntThunks.cpp M Source/JavaScriptCore/llint/LowLevelInterpreter.asm M Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm M Source/JavaScriptCore/offlineasm/backends.rb R Source/JavaScriptCore/offlineasm/mips.rb M Source/JavaScriptCore/runtime/VM.h M Source/JavaScriptCore/yarr/YarrJIT.cpp M Source/JavaScriptCore/yarr/YarrJITRegisters.h M Source/WTF/wtf/PlatformEnable.h Log Message: --- [JSC] Remove unmaintained MIPS support for JIT/LLInt https://bugs.webkit.org/show_bug.cgi?id=267347 Reviewed by Yusuke Suzuki. Igalia can't commit to supporting MIPS support for the JIT and LLInt anymore (and the bots are no longer running)--switch the MIPS build over to CLoop and remove the relevant JIT-only code. Note this doesn't remove _all_ references to CPU(MIPS)--there's still some, e.g. in heap/RegisterState; but this seems necessary even using CLoop and no JIT. * Source/JavaScriptCore/API/tests/ExecutionTimeLimitTest.cpp: (testExecutionTimeLimit): * Source/JavaScriptCore/assembler/CPU.h: (JSC::prologueStackPointerDelta): (JSC::isMIPS): Deleted. * Source/JavaScriptCore/assembler/LinkBuffer.cpp: (JSC::LinkBuffer::linkCode): * Source/JavaScriptCore/assembler/MIPSAssembler.h: Removed. * Source/JavaScriptCore/assembler/MIPSRegisters.h: Removed. * Source/JavaScriptCore/assembler/MacroAssembler.h: * Source/JavaScriptCore/assembler/MacroAssemblerMIPS.cpp: Removed. * Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h: Removed. * Source/JavaScriptCore/assembler/MaxFrameExtentForSlowPathCall.h: * Source/JavaScriptCore/assembler/PerfLog.cpp: * Source/JavaScriptCore/assembler/ProbeContext.cpp: (JSC::Probe::executeJSCJITProbe): * Source/JavaScriptCore/assembler/ProbeContext.h: (JSC::Probe::CPUState::pc): (JSC::Probe::CPUState::fp): (JSC::Probe::CPUState::sp): * Source/JavaScriptCore/assembler/RegisterInfo.h: * Source/JavaScriptCore/assembler/testmasm.cpp: (JSC::isSpecialGPR): (JSC::testProbePreservesGPRS): (JSC::testProbeModifiesStackPointer): (JSC::testProbeModifiesStackValues): * Source/JavaScriptCore/bytecode/InlineAccess.h: (JSC::InlineAccess::sizeForPropertyAccess): (JSC::InlineAccess::sizeForPropertyReplace): (JSC::InlineAccess::sizeForLengthAccess): * Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp: (JSC::InlineCacheCompiler::emitDataICPrologue): * Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::prepareForExternalCall): * Source/JavaScriptCore/disassembler/CapstoneDisassembler.cpp: (JSC::tryToDisassemble): * Source/JavaScriptCore/jit/AssemblyHelpers.h: * Source/JavaScriptCore/jit/CCallHelpers.h: (JSC::CCallHelpers::setupArgumentsImpl): (JSC::CCallHelpers::prepareForTailCallSlow): (JSC::CCallHelpers::setupStubCrossArgs): Deleted. * Source/JavaScriptCore/jit/ExecutableAllocator.h: * Source/JavaScriptCore/jit/FPRInfo.h: * Source/JavaScriptCore/jit/GPRInfo.h: (JSC::PreferredArgumentImpl::preferredArgumentJSR): * Source/JavaScriptCore/jit/RegisterSet.cpp: (JSC::RegisterSetBuilder::macroClobberedGPRs): (JSC::RegisterSetBuilder::macroClobberedFPRs): (JSC::RegisterSetBuilder::vmCalleeSaveRegisters):
[webkit-changes] [WebKit/WebKit] db2ca0: [armv7] Prepare macro assembler for testb3 support
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: db2ca0942a93ee3c04abab6d559783e81266fb4d https://github.com/WebKit/WebKit/commit/db2ca0942a93ee3c04abab6d559783e81266fb4d Author: Joseph Griego Date: 2023-12-08 (Fri, 08 Dec 2023) Changed paths: M Source/JavaScriptCore/assembler/MacroAssembler.h M Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h Log Message: --- [armv7] Prepare macro assembler for testb3 support https://bugs.webkit.org/show_bug.cgi?id=257291 Reviewed by Yusuke Suzuki. Some parts of testb3 use macro assembler functionality that's missing; these are straightforward to implement. Also remove a unnecessary declaration of MacroAssemblerBaes (it's also defined in MacroAssembler.h) * Source/JavaScriptCore/assembler/MacroAssembler.h: (JSC::MacroAssembler::ret64): * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::rotateLeft32): (JSC::MacroAssemblerARMv7::convertInt32ToDouble): (JSC::MacroAssemblerARMv7::setCarry): Canonical link: https://commits.webkit.org/271734@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] c95abf: [JSC] Wasm-GC: Struct members should have their na...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: c95abf8658bed1f7efac061995e591f8cff43b90 https://github.com/WebKit/WebKit/commit/c95abf8658bed1f7efac061995e591f8cff43b90 Author: Joseph Griego Date: 2023-11-27 (Mon, 27 Nov 2023) Changed paths: M Source/JavaScriptCore/wasm/WasmTypeDefinition.cpp M Source/JavaScriptCore/wasm/WasmTypeDefinition.h Log Message: --- [JSC] Wasm-GC: Struct members should have their natural alignment https://bugs.webkit.org/show_bug.cgi?id=265322 Reviewed by Justin Michaud. For 32-bit concurrent JIT (and also for concurrent GC on 64-bit, AIUI), we need members of these structs that are refs to be 8-byte aligned (for 64-bit atomic access and to avoid spanning cache lines respectively); also, for performance reasons, it's probably also good to have the scalar types aligned, anyways. * Source/JavaScriptCore/wasm/WasmTypeDefinition.cpp: (JSC::Wasm::StructType::StructType): * Source/JavaScriptCore/wasm/WasmTypeDefinition.h: (JSC::Wasm::typeAlignmentInBytes): Canonical link: https://commits.webkit.org/271146@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 1ff6d4: [JSC][armv7] Reserve `d14` as a scratch register f...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 1ff6d45f35c140efefa6110b5d5a71a872f3821e https://github.com/WebKit/WebKit/commit/1ff6d45f35c140efefa6110b5d5a71a872f3821e Author: Joseph Griego Date: 2023-10-25 (Wed, 25 Oct 2023) Changed paths: M Source/JavaScriptCore/jit/FPRInfo.h M Source/JavaScriptCore/jit/RegisterSet.cpp M Source/JavaScriptCore/llint/LowLevelInterpreter.asm M Source/JavaScriptCore/offlineasm/arm.rb Log Message: --- [JSC][armv7] Reserve `d14` as a scratch register for wasm JITs https://bugs.webkit.org/show_bug.cgi?id=263324 Reviewed by Justin Michaud. We really need an extra FP scratch register for wasm BBQ on armv7. In particular, we use the `nonPreservedNonArgumentFPR0` for this purpose, but we also ended up using register currently singled out as the `nonPreservedNonArgumentFPR0`, `d7` as an argument register in BBQ JIT contexts. To avoid the overlap, reserve `d14` as a scratch register--we copy exactly the approach used to reserve `d15` as a scratch FPR for the macroassembler [1]: though the register is callee-save in the platform ABI, we save/restore only at VM entry/exit and the register is volatile in VM contexts. [1] https://commits.webkit.org/250952@main * Source/JavaScriptCore/jit/FPRInfo.h: * Source/JavaScriptCore/jit/RegisterSet.cpp: (JSC::RegisterSetBuilder::vmCalleeSaveRegisters): * Source/JavaScriptCore/llint/LowLevelInterpreter.asm: * Source/JavaScriptCore/offlineasm/arm.rb: Canonical link: https://commits.webkit.org/269762@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] a6a933: [JSC] Fix wasm extended constant expressions in ex...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: a6a933a795b3a4bae2c7cb8ebe9f60406f0927bf https://github.com/WebKit/WebKit/commit/a6a933a795b3a4bae2c7cb8ebe9f60406f0927bf Author: Joseph Griego Date: 2023-10-24 (Tue, 24 Oct 2023) Changed paths: M Source/JavaScriptCore/wasm/WasmOperations.cpp M Source/JavaScriptCore/wasm/WasmOperationsInlines.h M Source/JavaScriptCore/wasm/js/JSWebAssemblyStruct.cpp M Source/JavaScriptCore/wasm/js/JSWebAssemblyStruct.h Log Message: --- [JSC] Fix wasm extended constant expressions in exception-scope-verification builds https://bugs.webkit.org/show_bug.cgi?id=263444 Reviewed by Justin Michaud. In debug/`ENABLE(EXCEPTION_SCOPE_VERIFICATION)` builds, we aren't following all the rules: `JSWebAssemblyStruct::tryCreate` throws if certain wasm operations aren't enabled, but we're calling it from a context (WasmConstExprGenerator) that isn't trivial to decorate with a ThrowScope (because it cooperates with the wasm FunctionParser) For now, change `tryCreate` to be total (except for OOMs which still assert), and rename it to `create`... since, at present, it it always called from contexts [1] where we know the runtime options are set anyways. [1] It is also called from the wasm slow path `struct_new` and `operationWasmStructNew` but these are unreachable unless wasm is enabled and the LLIntGenerator or similar checks the runtime option too) * Source/JavaScriptCore/wasm/WasmOperations.cpp: (JSC::Wasm::JSC_DEFINE_JIT_OPERATION): * Source/JavaScriptCore/wasm/WasmOperationsInlines.h: (JSC::Wasm::structNew): * Source/JavaScriptCore/wasm/js/JSWebAssemblyStruct.cpp: (JSC::JSWebAssemblyStruct::create): (JSC::JSWebAssemblyStruct::tryCreate): Deleted. * Source/JavaScriptCore/wasm/js/JSWebAssemblyStruct.h: Canonical link: https://commits.webkit.org/269718@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] f0a74b: [JSC] Macro assemblers: add ResultCondition::Carry
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: f0a74ba686ad09f95cbe896871dbac4d46f8be6a https://github.com/WebKit/WebKit/commit/f0a74ba686ad09f95cbe896871dbac4d46f8be6a Author: Joseph Griego Date: 2023-10-24 (Tue, 24 Oct 2023) Changed paths: M Source/JavaScriptCore/assembler/MacroAssembler.cpp M Source/JavaScriptCore/assembler/MacroAssemblerARM64.h M Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h M Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h M Source/JavaScriptCore/assembler/MacroAssemblerRISCV64.h M Source/JavaScriptCore/assembler/MacroAssemblerX86Common.h Log Message: --- [JSC] Macro assemblers: add ResultCondition::Carry https://bugs.webkit.org/show_bug.cgi?id=263559 Reviewed by Yusuke Suzuki. We want to perform a fast 32-bit addition while branching on _unsigned_ overflow for the ARMv7 wasm BBQ JIT; heretofore we've not needed this in the macroassemblers, especially on 64-bit where we seem to only care about signed overflow; add this case to ResultCondition. On many archs there's a condition code we can reach for and use; this is not the case on MIPS and RISC-V where I've left the condition unimplemented for now; (MIPS is going away soon, RISCV64 is unlikely to need branch-on-carry any time soon in my estimation) * Source/JavaScriptCore/assembler/MacroAssembler.cpp: (WTF::printInternal): * Source/JavaScriptCore/assembler/MacroAssemblerARM64.h: * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h: * Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h: * Source/JavaScriptCore/assembler/MacroAssemblerRISCV64.h: (JSC::MacroAssemblerRISCV64::branchTestFinalize): * Source/JavaScriptCore/assembler/MacroAssemblerX86Common.h: Canonical link: https://commits.webkit.org/269717@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 4a0ec7: [JSC][armv7] Use udf for break/breakpoint in offli...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 4a0ec7daa9e9eb684bd61be24d35962f1263fd35 https://github.com/WebKit/WebKit/commit/4a0ec7daa9e9eb684bd61be24d35962f1263fd35 Author: Joseph Griego Date: 2023-10-18 (Wed, 18 Oct 2023) Changed paths: M Source/JavaScriptCore/assembler/ARMv7Assembler.h M Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h M Source/JavaScriptCore/llint/LowLevelInterpreter.asm M Source/JavaScriptCore/offlineasm/arm.rb Log Message: --- [JSC][armv7] Use udf for break/breakpoint in offlineasm/masm https://bugs.webkit.org/show_bug.cgi?id=263322 Reviewed by Yusuke Suzuki. `bkpt` behaves very badly under gdb on armv7; it hangs [1] rather than traps. To workaround, use `udf #0` instead; the encodings and semantics are very similar. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=22645 * Source/JavaScriptCore/assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::udf): * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::breakpoint): * Source/JavaScriptCore/offlineasm/arm.rb: Canonical link: https://commits.webkit.org/269481@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 9ea306: [JSC][armv7] Skip wasm/stress/simple-inline-stackt...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 9ea306f30d73877433b5545e71f77fd1e64b1d9d https://github.com/WebKit/WebKit/commit/9ea306f30d73877433b5545e71f77fd1e64b1d9d Author: Joseph Griego Date: 2023-09-29 (Fri, 29 Sep 2023) Changed paths: M JSTests/wasm/stress/simple-inline-stacktrace-with-catch.js Log Message: --- [JSC][armv7] Skip wasm/stress/simple-inline-stacktrace-with-catch.js https://bugs.webkit.org/show_bug.cgi?id=262136 Reviewed by Yusuke Suzuki and Justin Michaud. This test is failing after https://commits.webkit.org/267656@main but we haven't been able to identify exactly what's wrong yet; skip in the interest of getting CI green, the extra stack frame seems somewhat benign. [Note that simple-inline-stacktrace.js is already skipped as of this commit] * JSTests/wasm/stress/simple-inline-stacktrace-with-catch.js: Canonical link: https://commits.webkit.org/268668@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] ec52f0: [JSC][armv7] Small fixes for DataIC address comput...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: ec52f0d00cbd1a7387bcd768bcd9377b8f454a33 https://github.com/WebKit/WebKit/commit/ec52f0d00cbd1a7387bcd768bcd9377b8f454a33 Author: Joseph Griego Date: 2023-09-27 (Wed, 27 Sep 2023) Changed paths: M Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp Log Message: --- [JSC][armv7] Small fixes for DataIC address computations https://bugs.webkit.org/show_bug.cgi?id=262132 Reviewed by Yusuke Suzuki. Fixes a great deal of the test suite. `push {r7, lr}` uses 4 bytes, so the prologue size needs to be 6 and not 4. Also, CodePtr::untaggedPtr produces a pointer suitable for jmp/call targets, which for thumb code is off by 1--use `dataLocation()` instead for doing pointer arithmetic--this change should affect nothing on other architectures. * Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp: (JSC::InlineCacheCompiler::regenerate): Canonical link: https://commits.webkit.org/268555@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 77e646: [JSC][armv7] Fix DFG {NewSet, NewMap} assertions
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 77e6461ff053676f9d8ffa976a45bf1980728d0c https://github.com/WebKit/WebKit/commit/77e6461ff053676f9d8ffa976a45bf1980728d0c Author: Joseph Griego Date: 2023-09-27 (Wed, 27 Sep 2023) Changed paths: M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp Log Message: --- [JSC][armv7] Fix DFG {NewSet,NewMap} assertions https://bugs.webkit.org/show_bug.cgi?id=262181 Reviewed by Yusuke Suzuki. These asserts seem to be useful only for `CPU(ARM64)` and they're not true on 32-bit; rather than make them portable, sink them to where they're needed. * Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp: Canonical link: https://commits.webkit.org/268525@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 1352cc: Cherry-pick 267511@main (7a9106c7a56f). https://bu...
Branch: refs/heads/webkitglib/2.42 Home: https://github.com/WebKit/WebKit Commit: 1352cc06fa9f7f64f1b3fc5e9a47e904e6f57ba3 https://github.com/WebKit/WebKit/commit/1352cc06fa9f7f64f1b3fc5e9a47e904e6f57ba3 Author: Joseph Griego Date: 2023-09-19 (Tue, 19 Sep 2023) Changed paths: A JSTests/stress/typed-array-intrinsic-getter-with-conflicting-value-profile.js M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp Log Message: --- Cherry-pick 267511@main (7a9106c7a56f). https://bugs.webkit.org/show_bug.cgi?id=260908 [32 bit] DFG graph generation: intrinsic getters are fallible https://bugs.webkit.org/show_bug.cgi?id=260908 Reviewed by Yusuke Suzuki. On 32-bit, unlike 64-bit, some of the DFG intrinsic getters (really, the TypedArray ones) are _fallible_: if the SpeculatedType doesn't match our expecations (a non-strict subset of SpecInt32Only), we refuse to generate code. [1] However, DFG::ByteCodeParser::handleGetById doesn't appear to handle this case gracefully--if `handleIntrinsicGetter` fails, we attempt to generate a call to the getter, but in the case of TypedArray intrinsics, we won't have the necessary CallLinkStatus and while attempting to do so, we crash. To fix this, I've added a bit of code that handles the failure from handleIntrinsicGetter and emits an ordinary `GetById` node instead of trying to inline anything for this op. I've added a test that demonstrates the current behavior (a segfault) on armv7 and passes with tihs patch. [1] For what it's worth, maybe this shouldn't be the case: it does seem like we should still be able to generate code in these cases anyhow, but it's simpler to just cope with the failure. * JSTests/stress/typed-array-intrinsic-getter-with-conflicting-value-profile.js: Added. (foo): (i.null.foo.Object.create): (i.42.foo): * Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleGetById): Canonical link: https://commits.webkit.org/267511@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 7a9106: [32 bit] DFG graph generation: intrinsic getters a...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 7a9106c7a56f0cd97901a535361ba5418900e058 https://github.com/WebKit/WebKit/commit/7a9106c7a56f0cd97901a535361ba5418900e058 Author: Joseph Griego Date: 2023-08-31 (Thu, 31 Aug 2023) Changed paths: A JSTests/stress/typed-array-intrinsic-getter-with-conflicting-value-profile.js M Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp Log Message: --- [32 bit] DFG graph generation: intrinsic getters are fallible https://bugs.webkit.org/show_bug.cgi?id=260908 Reviewed by Yusuke Suzuki. On 32-bit, unlike 64-bit, some of the DFG intrinsic getters (really, the TypedArray ones) are _fallible_: if the SpeculatedType doesn't match our expecations (a non-strict subset of SpecInt32Only), we refuse to generate code. [1] However, DFG::ByteCodeParser::handleGetById doesn't appear to handle this case gracefully--if `handleIntrinsicGetter` fails, we attempt to generate a call to the getter, but in the case of TypedArray intrinsics, we won't have the necessary CallLinkStatus and while attempting to do so, we crash. To fix this, I've added a bit of code that handles the failure from handleIntrinsicGetter and emits an ordinary `GetById` node instead of trying to inline anything for this op. I've added a test that demonstrates the current behavior (a segfault) on armv7 and passes with tihs patch. [1] For what it's worth, maybe this shouldn't be the case: it does seem like we should still be able to generate code in these cases anyhow, but it's simpler to just cope with the failure. * JSTests/stress/typed-array-intrinsic-getter-with-conflicting-value-profile.js: Added. (foo): (i.null.foo.Object.create): (i.42.foo): * Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleGetById): Canonical link: https://commits.webkit.org/267511@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 2bec7b: Skip `watchdog-fire-while-in-forEachInIterable` fo...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 2bec7b6bcb9a6be87744ef86200ead38af8e7475 https://github.com/WebKit/WebKit/commit/2bec7b6bcb9a6be87744ef86200ead38af8e7475 Author: Joseph Griego Date: 2023-08-23 (Wed, 23 Aug 2023) Changed paths: M JSTests/stress/watchdog-fire-while-in-forEachInIterable.js Log Message: --- Skip `watchdog-fire-while-in-forEachInIterable` for memory-limited platforms https://bugs.webkit.org/show_bug.cgi?id=260616 Reviewed by Yusuke Suzuki. This has been failing on 32-bit release builds for some time; skip there for now. If the array size was smaller, we could make this test work--AIUI, if the watchdog doesn't fire at all, the test still passes? So, I'm being quite conservative about not changing the test for 64-bit. * JSTests/stress/watchdog-fire-while-in-forEachInIterable.js: Canonical link: https://commits.webkit.org/267209@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 292964: 32-bit macro assemblers should support `roundTowar...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 292964e14c7136830d5fcc7cf946b196f8430026 https://github.com/WebKit/WebKit/commit/292964e14c7136830d5fcc7cf946b196f8430026 Author: Joseph Griego Date: 2023-08-22 (Tue, 22 Aug 2023) Changed paths: M Source/JavaScriptCore/assembler/ARMv7Assembler.h M Source/JavaScriptCore/assembler/MIPSAssembler.h M Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h M Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h Log Message: --- 32-bit macro assemblers should support `roundTowardsNearestIntDouble` https://bugs.webkit.org/show_bug.cgi?id=260525 Reviewed by Yusuke Suzuki. As title, this is used now for Uint8ClampedArray; for now, only implement the needed rounding instruction in these assemblers--admittedly, the generated code is a little silly, e.g. on MIPS: 0x71afe4d0: round.w.d $f2, $f0 0x71afe4d4: cvt.d.w $f2, $f2 0x71afe4d8: trunc.w.d $f16, $f2 ... but it is correct; to avoid the extra instructions, we'd need a different macro assembler instruction for these rounding semantics that converts straight to a GPR instead of an FPR; can send that as a followup patch but this gets things working. * Source/JavaScriptCore/assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::vcvt_floatingPointToSignedNearest): * Source/JavaScriptCore/assembler/MIPSAssembler.h: (JSC::MIPSAssembler::roundwd): * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::roundTowardNearestIntDouble): * Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::roundTowardNearestIntDouble): Canonical link: https://commits.webkit.org/267146@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] c4574f: [WTF] RELEASE_ASSERT_NOT_REACHED should allow a me...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: c4574f31334dd38adc9962e34b195ef364d1eb7f https://github.com/WebKit/WebKit/commit/c4574f31334dd38adc9962e34b195ef364d1eb7f Author: Joseph Griego Date: 2023-08-02 (Wed, 02 Aug 2023) Changed paths: M Source/WTF/wtf/Assertions.h Log Message: --- [WTF] RELEASE_ASSERT_NOT_REACHED should allow a message https://bugs.webkit.org/show_bug.cgi?id=259526 Reviewed by Mark Lam. The asserts-enabled and asserts-not-enabled implementations of this macro don't agree about whether or not it allows a message--allow one for the sake of form. Since revision f0224c3ac4969 it's used in at least one place with a message. * Source/WTF/wtf/Assertions.h: Canonical link: https://commits.webkit.org/266516@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 900bcb: Fix Mac JSCOnly build
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 900bcbfd6a37803857e87f4265c21415a346cc3d https://github.com/WebKit/WebKit/commit/900bcbfd6a37803857e87f4265c21415a346cc3d Author: Joseph Griego Date: 2023-06-19 (Mon, 19 Jun 2023) Changed paths: M Source/WTF/wtf/PlatformJSCOnly.cmake Log Message: --- Fix Mac JSCOnly build https://bugs.webkit.org/show_bug.cgi?id=257720 Reviewed by Elliott Williams. The build currently fails because this header is included from wtf/Assertions.h but is not copied as a public header in the cmake build; an easy fix, and I think it should be appropriate (only changed for this port) * Source/WTF/wtf/PlatformJSCOnly.cmake: Canonical link: https://commits.webkit.org/265303@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 95ec7f: Add `-list` flag to testb3
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 95ec7fc55b008cd504f2e8b6c178f5b864a51825 https://github.com/WebKit/WebKit/commit/95ec7fc55b008cd504f2e8b6c178f5b864a51825 Author: Joseph Griego Date: 2023-05-22 (Mon, 22 May 2023) Changed paths: M Source/JavaScriptCore/b3/testb3.h M Source/JavaScriptCore/b3/testb3_1.cpp M Source/JavaScriptCore/b3/testb3_2.cpp M Source/JavaScriptCore/b3/testb3_3.cpp M Source/JavaScriptCore/b3/testb3_4.cpp M Source/JavaScriptCore/b3/testb3_6.cpp M Source/JavaScriptCore/b3/testb3_7.cpp M Source/JavaScriptCore/b3/testb3_8.cpp Log Message: --- Add `-list` flag to testb3 https://bugs.webkit.org/show_bug.cgi?id=256857 Reviewed by Justin Michaud. This is useful to write scripts that need to analyze runs of testb3 or to continue past failures (which manifest as crashes). `testb3` now can be invoked as: testb3 [-list] [-filter ] the `-list` flag causes testb3 to simply print the defined test cases; `-filter` acts like the current argument (filtering the test cases to run). `-filter` is ignored if `-list` was passed. `testb3` will also continue to accept the current commandline: testb3 [filter] To accomplish this, the `const char* filter` parameter has been replaced everywhere with a TestConfig parameter that stores a filter and also now a run mode. * Source/JavaScriptCore/b3/testb3.h: * Source/JavaScriptCore/b3/testb3_1.cpp: (shouldRun): (run): (main): * Source/JavaScriptCore/b3/testb3_2.cpp: (testBitOrImms32): * Source/JavaScriptCore/b3/testb3_3.cpp: (testNegPtr): (addArgTests): * Source/JavaScriptCore/b3/testb3_4.cpp: (testPatchpointAnyImm): * Source/JavaScriptCore/b3/testb3_6.cpp: (addSShrShTests): * Source/JavaScriptCore/b3/testb3_7.cpp: (tupleNestedLoop): * Source/JavaScriptCore/b3/testb3_8.cpp: (testAtomicXchg): (testLoad): Canonical link: https://commits.webkit.org/264339@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 891988: Cherry-pick 264088@main (d565c2070f7a). https://bu...
Branch: refs/heads/webkitglib/2.38 Home: https://github.com/WebKit/WebKit Commit: 891988e5eb269450ccdaed22ab4cc7e3573c697f https://github.com/WebKit/WebKit/commit/891988e5eb269450ccdaed22ab4cc7e3573c697f Author: Joseph Griego Date: 2023-05-20 (Sat, 20 May 2023) Changed paths: M Source/WTF/wtf/text/StringCommon.h M Tools/TestWebKitAPI/Tests/WTF/StringCommon.cpp Log Message: --- Cherry-pick 264088@main (d565c2070f7a). https://bugs.webkit.org/show_bug.cgi?id=256606 Fix off-by-one in WTF::findIgnoringASCIICaseWithoutLength https://bugs.webkit.org/show_bug.cgi?id=256606 Reviewed by Chris Dumez. A needle identical to the haystack won't be found by this function because of the length comparison used. Luckily, this function is unused except in testb3, so nothing else really needs to be changed. * Source/WTF/wtf/text/StringCommon.h: (WTF::findIgnoringASCIICaseWithoutLength): Canonical link: https://commits.webkit.org/264088@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] d565c2: Fix off-by-one in WTF::findIgnoringASCIICaseWithou...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: d565c2070f7adafe2511904b6a3a27f3d93396d2 https://github.com/WebKit/WebKit/commit/d565c2070f7adafe2511904b6a3a27f3d93396d2 Author: Joseph Griego Date: 2023-05-15 (Mon, 15 May 2023) Changed paths: M Source/WTF/wtf/text/StringCommon.h M Tools/TestWebKitAPI/Tests/WTF/StringCommon.cpp Log Message: --- Fix off-by-one in WTF::findIgnoringASCIICaseWithoutLength https://bugs.webkit.org/show_bug.cgi?id=256606 Reviewed by Chris Dumez. A needle identical to the haystack won't be found by this function because of the length comparison used. Luckily, this function is unused except in testb3, so nothing else really needs to be changed. * Source/WTF/wtf/text/StringCommon.h: (WTF::findIgnoringASCIICaseWithoutLength): Canonical link: https://commits.webkit.org/264088@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 313db1: Add Joseph Griego as a committer.
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 313db1f1d14e98ccd922a1e51f6e72fd8c9e9f31 https://github.com/WebKit/WebKit/commit/313db1f1d14e98ccd922a1e51f6e72fd8c9e9f31 Author: Joseph Griego Date: 2023-03-22 (Wed, 22 Mar 2023) Changed paths: M metadata/contributors.json Log Message: --- Add Joseph Griego as a committer. https://bugs.webkit.org/show_bug.cgi?id=254287 Reviewed by Alex Christensen. As title, after invitation :) * metadata/contributors.json: Canonical link: https://commits.webkit.org/261990@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 9edf42: Cherry-pick 260115@main (397fe12d87a4). https://bu...
Branch: refs/heads/webkitglib/2.38 Home: https://github.com/WebKit/WebKit Commit: 9edf42d5fc1147294c1b438a7e3272db15107371 https://github.com/WebKit/WebKit/commit/9edf42d5fc1147294c1b438a7e3272db15107371 Author: Joseph Griego Date: 2023-02-14 (Tue, 14 Feb 2023) Changed paths: M Source/bmalloc/bmalloc/DebugHeap.cpp Log Message: --- Cherry-pick 260115@main (397fe12d87a4). https://bugs.webkit.org/show_bug.cgi?id=252053 bmalloc DebugHeap should not crash in low-memory conditions on Linux https://bugs.webkit.org/show_bug.cgi?id=252053 Reviewed by Yusuke Suzuki. `posix_memalign` may not initialize the result pointer if it fails on Linux [1]. If we don't initialize the result ourselves, this manifests as later segfaults/bus errors/bizarre behavior as we get a completely bogus result that can point basically anywhere. [1] https://man7.org/linux/man-pages/man3/posix_memalign.3.html * Source/bmalloc/bmalloc/DebugHeap.cpp: (bmalloc::DebugHeap::memalign): Canonical link: https://commits.webkit.org/260115@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 397fe1: bmalloc DebugHeap should not crash in low-memory c...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 397fe12d87a4c4485ff80bf963e43629acb647fa https://github.com/WebKit/WebKit/commit/397fe12d87a4c4485ff80bf963e43629acb647fa Author: Joseph Griego Date: 2023-02-10 (Fri, 10 Feb 2023) Changed paths: M Source/bmalloc/bmalloc/DebugHeap.cpp Log Message: --- bmalloc DebugHeap should not crash in low-memory conditions on Linux https://bugs.webkit.org/show_bug.cgi?id=252053 Reviewed by Yusuke Suzuki. `posix_memalign` may not initialize the result pointer if it fails on Linux [1]. If we don't initialize the result ourselves, this manifests as later segfaults/bus errors/bizarre behavior as we get a completely bogus result that can point basically anywhere. [1] https://man7.org/linux/man-pages/man3/posix_memalign.3.html * Source/bmalloc/bmalloc/DebugHeap.cpp: (bmalloc::DebugHeap::memalign): Canonical link: https://commits.webkit.org/260115@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 6055ee: [JSC][armv7] Fix wasm ref.as_non_null
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 6055ee6392589ea77765c0a3d4d8b8898a6534ff https://github.com/WebKit/WebKit/commit/6055ee6392589ea77765c0a3d4d8b8898a6534ff Author: Joseph Griego Date: 2023-02-07 (Tue, 07 Feb 2023) Changed paths: M Source/JavaScriptCore/llint/WebAssembly32_64.asm M Source/JavaScriptCore/wasm/WasmAirIRGenerator32_64.cpp M Source/JavaScriptCore/wasm/WasmAirIRGenerator64.cpp M Source/JavaScriptCore/wasm/WasmAirIRGeneratorBase.h Log Message: --- [JSC][armv7] Fix wasm ref.as_non_null https://bugs.webkit.org/show_bug.cgi?id=251606 Reviewed by Yusuke Suzuki. Right now, the implementation of this instruction triggers assertion failures in both LLInt and the BBQ/Air backends on 32-bit ARM. For LLInt, the incorrect `return` instruction is used, use `return2i` since refs are two-word values. For the Air backend, we need to use `emitMove` (again, because refs are two-word values); here, we also need a version that doesn't assert in the JIT that the dest is a supertype of the source TypedTmp--since the whole point of ref.as_non_null is that it works as a checked coercion... So, I've added that as `emitMoveWithoutTypeCheck` * Source/JavaScriptCore/llint/WebAssembly32_64.asm: * Source/JavaScriptCore/wasm/WasmAirIRGenerator32_64.cpp: (JSC::Wasm::AirIRGenerator32::emitMoveWithoutTypeCheck): (JSC::Wasm::AirIRGenerator32::emitMove): * Source/JavaScriptCore/wasm/WasmAirIRGenerator64.cpp: (JSC::Wasm::AirIRGenerator64::emitMoveWithoutTypeCheck): (JSC::Wasm::AirIRGenerator64::emitMove): * Source/JavaScriptCore/wasm/WasmAirIRGeneratorBase.h: (JSC::Wasm::ExpressionType>::addRefAsNonNull): Canonical link: https://commits.webkit.org/259958@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 0d1af8: [JSC] Skip `wasm/stress/only-referenced.js` on 32-...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 0d1af8a18827e1222164047d78d92c8fdeba2166 https://github.com/WebKit/WebKit/commit/0d1af8a18827e1222164047d78d92c8fdeba2166 Author: Joseph Griego Date: 2023-02-02 (Thu, 02 Feb 2023) Changed paths: M JSTests/wasm/stress/only-referenced.js Log Message: --- [JSC] Skip `wasm/stress/only-referenced.js` on 32-bit ARM https://bugs.webkit.org/show_bug.cgi?id=251593 Reviewed by Yusuke Suzuki. Test case uses shared memory--skip for now. In practice it should be possible to change the .wasm blob to avoid declaring the memory as shared but I'd rather not muddle with the binary--and we're trying to enable shared mem on 32-bit anyways. * JSTests/wasm/stress/only-referenced.js: Canonical link: https://commits.webkit.org/259762@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 83a1bc: [JSC][armv7] Use the correct calling convention fo...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 83a1bc69e51b312580fb05cb9fb683cc801ae47e https://github.com/WebKit/WebKit/commit/83a1bc69e51b312580fb05cb9fb683cc801ae47e Author: Joseph Griego Date: 2023-01-20 (Fri, 20 Jan 2023) Changed paths: M Source/JavaScriptCore/wasm/WasmAirIRGenerator32_64.cpp Log Message: --- [JSC][armv7] Use the correct calling convention for `operationWasmRethrow` https://bugs.webkit.org/show_bug.cgi?id=250588 Reviewed by Mark Lam. https://github.com/WebKit/WebKit/pull/8523 changed the signature of some runtime wasm operations, but incorrectly translated these changes for the arm32 calling convention, breaking some tests. Changes to other wasm operations were covered by the platform-specific `emitCCall`, but calls to `operationWasmRethrow` are not emitted this way. (The arm32 calling convention requires that 64-bit arguments get passed starting in an even-numbered registers, potentially causing an odd-numbered register to be unused in the call, in this case, `r1/argumentGPR1`) * Source/JavaScriptCore/wasm/WasmAirIRGenerator32_64.cpp: (JSC::Wasm::AirIRGenerator32::addRethrow): Canonical link: https://commits.webkit.org/259152@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 69bce7: [JSC][armv7] Skip `wasm/stress/tail-call-should-no...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 69bce7a3e18c57600316783d18415aed6ba28565 https://github.com/WebKit/WebKit/commit/69bce7a3e18c57600316783d18415aed6ba28565 Author: Joseph Griego Date: 2023-01-18 (Wed, 18 Jan 2023) Changed paths: M JSTests/wasm/stress/tail-call-should-not-clobber-caller-origin.js Log Message: --- [JSC][armv7] Skip `wasm/stress/tail-call-should-not-clobber-caller-origin.js` https://bugs.webkit.org/show_bug.cgi?id=250587 Reviewed by Mark Lam. This test uses wasm SIMD and won't run on ARMv7--skip it for now. * JSTests/wasm/stress/tail-call-should-not-clobber-caller-origin.js: Canonical link: https://commits.webkit.org/259041@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 925943: [JSC] Atomics.waitAsync should be invocable from t...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 9259434c015156e882dd760a0a0355c5c5d9e3c4 https://github.com/WebKit/WebKit/commit/9259434c015156e882dd760a0a0355c5c5d9e3c4 Author: Joseph Griego Date: 2023-01-12 (Thu, 12 Jan 2023) Changed paths: A LayoutTests/js/Atomics-waitasync-invocable-on-main-thread-expected.txt A LayoutTests/js/Atomics-waitasync-invocable-on-main-thread.html M Source/JavaScriptCore/runtime/AtomicsObject.cpp Log Message: --- [JSC] Atomics.waitAsync should be invocable from the main thread https://bugs.webkit.org/show_bug.cgi?id=250518 Reviewed by Keith Miller. According to the current proposed spec [1], async atomic waits are not restricted to threads with `AgentCanSuspend()`--so, Atomics.waitAsync should not throw a TypeError for this reason. I've added a (very simple) test to this effect. So, we should delay the check for `isAtomicsWaitAllowedOnCurrentThread` until after we know the wait is known to be synchronous. If there's an implementation reason we shouldn't do this, let me know, but I couldn't find one. [1] https://tc39.es/proposal-atomics-wait-async/#sec-dowait * LayoutTests/js/Atomics-waitasync-invocable-on-main-thread-expected.txt: Added. * LayoutTests/js/Atomics-waitasync-invocable-on-main-thread.html: Added. * Source/JavaScriptCore/runtime/AtomicsObject.cpp: (JSC::atomicsWaitImpl): Canonical link: https://commits.webkit.org/258856@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 0df23a: [JSC][32-bit] Wasm callee pointer should not be in...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 0df23a961475d940636c2989ac7fd6b858157390 https://github.com/WebKit/WebKit/commit/0df23a961475d940636c2989ac7fd6b858157390 Author: Joseph Griego Date: 2023-01-06 (Fri, 06 Jan 2023) Changed paths: M Source/JavaScriptCore/llint/WebAssembly.asm Log Message: --- [JSC][32-bit] Wasm callee pointer should not be incorrectly untagged https://bugs.webkit.org/show_bug.cgi?id=250219 Reviewed by Justin Michaud. After https://github.com/WebKit/WebKit/pull/8138, the untag code in the LLInt wasm prologue was changed to use `~WasmTag` as a mask; which on 32-bit ends up having most bits unset, effectively zeroing out the callee pointer, breaking a big chunk of the test suite on armv7. The old version of this untag code used `~3` as the mask which happened to work for all platforms. Fix this by emitting the untag instruction only for the 64-bit JSValue representation, since for JSVALUE32_64 platforms, the callee pointer is untagged anyways. * Source/JavaScriptCore/llint/WebAssembly.asm: Canonical link: https://commits.webkit.org/258584@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] cbff45: [JSC] B3/Air should use the system register conven...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: cbff45e59253712319ac26cab74d8c76557d91ca https://github.com/WebKit/WebKit/commit/cbff45e59253712319ac26cab74d8c76557d91ca Author: Joseph Griego Date: 2022-12-22 (Thu, 22 Dec 2022) Changed paths: M Source/JavaScriptCore/b3/B3StackmapGenerationParams.cpp M Source/JavaScriptCore/b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp M Source/JavaScriptCore/b3/air/AirCode.cpp M Source/JavaScriptCore/b3/air/AirHandleCalleeSaves.cpp M Source/JavaScriptCore/b3/air/AirLowerAfterRegAlloc.cpp M Source/JavaScriptCore/b3/air/testair.cpp M Source/JavaScriptCore/interpreter/Interpreter.cpp Log Message: --- [JSC] B3/Air should use the system register convention https://bugs.webkit.org/show_bug.cgi?id=249776 Reviewed by Yusuke Suzuki. A previous patch (189dce5799e8) changed several of these locations to use the `vmCalleeSaveRegisters` over the `calleeSaveRegisters`--change them back. Though on most platforms with Air support, these two register sets are identical, on ARMv7, which is new to the Air club, fewer registers are included in the VM register calee-save set than in the system's callee-save set, which caused problems with unwinding. This patch also addresses the ARMv7-only issue with unwinding: if an Air callee in a VM stack being unwound saves registers other than VM callee-saves, they simply won't be restored--this is OK for the time being as VM callers will only expect the VM callee-saves to be preserved. Eventually we may want to enable code generation on ARMv7 to select the VM convention over the system one to avoid unnecessary save/restores in ARM-generated code. (The alternative, making vmCalleeSaveRegisters use all of the available platform callee-saves, isn't appealing, as we want more temporary registers available to the assembler and lower tiers) Note that the usage in `B3StackGenerationParams.cpp` was actually more-or-less original to that file. Still, it seems correct to use `calleeSaveRegisters` there. (And again, on platforms other than ARMv7, the change is a no-op; the sets are identical) * Source/JavaScriptCore/b3/B3StackmapGenerationParams.cpp: (JSC::B3::StackmapGenerationParams::unavailableRegisters const): * Source/JavaScriptCore/b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: (JSC::B3::Air::GenerateAndAllocateRegisters::prepareForGeneration): * Source/JavaScriptCore/b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): * Source/JavaScriptCore/b3/air/AirHandleCalleeSaves.cpp: (JSC::B3::Air::handleCalleeSaves): * Source/JavaScriptCore/b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * Source/JavaScriptCore/b3/air/testair.cpp: * Source/JavaScriptCore/interpreter/Interpreter.cpp: (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const): Canonical link: https://commits.webkit.org/258261@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 189dce: [JSC] Port and enable Wasm BBQ JIT on ARMv7
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 189dce5799e8464f6d477a92d8dd7c26c085362d https://github.com/WebKit/WebKit/commit/189dce5799e8464f6d477a92d8dd7c26c085362d Author: Joseph Griego Date: 2022-12-13 (Tue, 13 Dec 2022) Changed paths: M JSTests/wasm.yaml M JSTests/wasm/regress/242294.js M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/Sources.txt M Source/JavaScriptCore/assembler/ARMv7Assembler.h M Source/JavaScriptCore/assembler/AbstractMacroAssembler.h M Source/JavaScriptCore/assembler/AllowMacroScratchRegisterUsage.h M Source/JavaScriptCore/assembler/AllowMacroScratchRegisterUsageIf.h M Source/JavaScriptCore/assembler/AssemblerCommon.h M Source/JavaScriptCore/assembler/CPU.h M Source/JavaScriptCore/assembler/DisallowMacroScratchRegisterUsage.h M Source/JavaScriptCore/assembler/MacroAssembler.h M Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h M Source/JavaScriptCore/b3/B3CheckSpecial.cpp M Source/JavaScriptCore/b3/B3Common.cpp M Source/JavaScriptCore/b3/B3LowerMacros.cpp M Source/JavaScriptCore/b3/B3ValueRep.cpp M Source/JavaScriptCore/b3/B3WasmBoundsCheckValue.cpp M Source/JavaScriptCore/b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp M Source/JavaScriptCore/b3/air/AirAllocateRegistersByGraphColoring.cpp M Source/JavaScriptCore/b3/air/AirArg.h M Source/JavaScriptCore/b3/air/AirCCallingConvention.cpp M Source/JavaScriptCore/b3/air/AirCCallingConvention.h M Source/JavaScriptCore/b3/air/AirCode.cpp M Source/JavaScriptCore/b3/air/AirCode.h M Source/JavaScriptCore/b3/air/AirCustom.cpp M Source/JavaScriptCore/b3/air/AirCustom.h M Source/JavaScriptCore/b3/air/AirGenerate.cpp M Source/JavaScriptCore/b3/air/AirHandleCalleeSaves.cpp M Source/JavaScriptCore/b3/air/AirLowerAfterRegAlloc.cpp M Source/JavaScriptCore/b3/air/AirLowerMacros.cpp M Source/JavaScriptCore/b3/air/AirLowerStackArgs.cpp M Source/JavaScriptCore/b3/air/AirOpcode.opcodes M Source/JavaScriptCore/b3/air/AirStackAllocation.cpp M Source/JavaScriptCore/b3/air/opcode_generator.rb M Source/JavaScriptCore/b3/air/testair.cpp M Source/JavaScriptCore/b3/testb3.h M Source/JavaScriptCore/b3/testb3_1.cpp M Source/JavaScriptCore/b3/testb3_2.cpp M Source/JavaScriptCore/b3/testb3_3.cpp M Source/JavaScriptCore/b3/testb3_4.cpp M Source/JavaScriptCore/b3/testb3_5.cpp M Source/JavaScriptCore/b3/testb3_6.cpp M Source/JavaScriptCore/b3/testb3_7.cpp M Source/JavaScriptCore/b3/testb3_8.cpp M Source/JavaScriptCore/bytecode/VirtualRegister.h M Source/JavaScriptCore/generator/Wasm.rb M Source/JavaScriptCore/jit/GPRInfo.h M Source/JavaScriptCore/jit/PCToCodeOriginMap.cpp M Source/JavaScriptCore/jit/PCToCodeOriginMap.h M Source/JavaScriptCore/jit/RegisterSet.h M Source/JavaScriptCore/jit/Width.h M Source/JavaScriptCore/llint/WebAssembly.asm M Source/JavaScriptCore/llint/WebAssembly32_64.asm M Source/JavaScriptCore/runtime/MathCommon.cpp M Source/JavaScriptCore/runtime/MathCommon.h M Source/JavaScriptCore/runtime/StackAlignment.h A Source/JavaScriptCore/wasm/WasmAirIRGenerator32_64.cpp A Source/JavaScriptCore/wasm/WasmAirIRGenerator64.cpp M Source/JavaScriptCore/wasm/WasmAirIRGeneratorBase.h R Source/JavaScriptCore/wasm/WasmAirIRGeneratorTmp.cpp M Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp M Source/JavaScriptCore/wasm/WasmBBQPlan.cpp M Source/JavaScriptCore/wasm/WasmFunctionParser.h M Source/JavaScriptCore/wasm/WasmIRGeneratorHelpers.h M Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp M Source/JavaScriptCore/wasm/WasmOpcodeOrigin.h M Source/JavaScriptCore/wasm/WasmOperations.cpp M Source/JavaScriptCore/wasm/WasmOperations.h M Source/JavaScriptCore/wasm/WasmSlowPaths.cpp M Source/JavaScriptCore/wasm/WasmSlowPaths.h M Source/JavaScriptCore/wasm/generateWasmB3IRGeneratorInlinesHeader.py M Source/JavaScriptCore/wasm/generateWasmOpsHeader.py M Source/JavaScriptCore/wasm/js/WebAssemblyFunction.cpp M Source/WTF/wtf/PlatformEnable.h M Tools/Scripts/run-jsc-stress-tests Log Message: --- [JSC] Port and enable Wasm BBQ JIT on ARMv7 https://bugs.webkit.org/show_bug.cgi?id=241009 Reviewed by Justin Michaud. This patch enables the Wasm BBQ JIT on ARMv7. The bulk of the changes are in WasmAirIRGenerator, where the key change is the handling of 64-bit integer (and other non floating point type) values as pairs of 32-bit values; to avoid covering this class in conditionals, it's converted into an abstract base class, `WasmAirIRGeneratorBase` with the common functionality and any wasm instructions that can be converted into a shared implementation backed by some per-word-size helpers. We achieve this primarily through changing TypedTmp (which represents a Wasm
[webkit-changes] [WebKit/WebKit] cac02a: [JSC] WasmAirIRGenerator.cpp -> WasmAirIRGenerator...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: cac02a1a9807a8f5de375a8493a94b5323e13c68 https://github.com/WebKit/WebKit/commit/cac02a1a9807a8f5de375a8493a94b5323e13c68 Author: Joseph Griego Date: 2022-12-13 (Tue, 13 Dec 2022) Changed paths: M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj M Source/JavaScriptCore/Sources.txt R Source/JavaScriptCore/wasm/WasmAirIRGenerator.cpp A Source/JavaScriptCore/wasm/WasmAirIRGeneratorBase.h A Source/JavaScriptCore/wasm/WasmAirIRGeneratorTmp.cpp Log Message: --- [JSC] WasmAirIRGenerator.cpp -> WasmAirIRGeneratorBase.h https://bugs.webkit.org/show_bug.cgi?id=241009 Reviewed by Justin Michaud. In preparation for https://github.com/WebKit/WebKit/pull/2080, rename WasmAirIRGenerator.cpp to preserve blame for this file. This commit also adds a `WasmAirIRGeneratorTmp.cpp` to keep things building before separate 64- and 32- bit compilation units are added in the above-mentioned PR. Ideally this should be landed together with PR 2080. * Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj: * Source/JavaScriptCore/Sources.txt: * Source/JavaScriptCore/wasm/WasmAirIRGeneratorBase.h: Renamed from Source/JavaScriptCore/wasm/WasmAirIRGenerator.cpp. (JSC::Wasm::TypedTmp::TypedTmp): (JSC::Wasm::TypedTmp::operator== const): (JSC::Wasm::TypedTmp::operator!= const): (JSC::Wasm::TypedTmp::operator bool const): (JSC::Wasm::TypedTmp::operator Tmp const): (JSC::Wasm::TypedTmp::operator Arg const): (JSC::Wasm::TypedTmp::tmp const): (JSC::Wasm::TypedTmp::type const): (JSC::Wasm::TypedTmp::dump const): (JSC::Wasm::ConstrainedTmp::ConstrainedTmp): (JSC::Wasm::ConstrainedTmp::operator bool const): (JSC::Wasm::AirIRGenerator::ControlData::ControlData): (JSC::Wasm::AirIRGenerator::ControlData::isIf): (JSC::Wasm::AirIRGenerator::ControlData::isTry): (JSC::Wasm::AirIRGenerator::ControlData::isAnyCatch): (JSC::Wasm::AirIRGenerator::ControlData::isCatch): (JSC::Wasm::AirIRGenerator::ControlData::isTopLevel): (JSC::Wasm::AirIRGenerator::ControlData::isLoop): (JSC::Wasm::AirIRGenerator::ControlData::isBlock): (JSC::Wasm::AirIRGenerator::ControlData::dump const): (JSC::Wasm::AirIRGenerator::ControlData::blockType const): (JSC::Wasm::AirIRGenerator::ControlData::signature const): (JSC::Wasm::AirIRGenerator::ControlData::targetBlockForBranch): (JSC::Wasm::AirIRGenerator::ControlData::convertIfToBlock): (JSC::Wasm::AirIRGenerator::ControlData::branchTargetArity const): (JSC::Wasm::AirIRGenerator::ControlData::branchTargetType const): (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::emptyExpression): (JSC::Wasm::AirIRGenerator::fail const): (JSC::Wasm::AirIRGenerator::addExtractLane): (JSC::Wasm::AirIRGenerator::addReplaceLane): (JSC::Wasm::AirIRGenerator::addSIMDI_V): (JSC::Wasm::AirIRGenerator::addSIMDV_V): (JSC::Wasm::AirIRGenerator::addSIMDBitwiseSelect): (JSC::Wasm::AirIRGenerator::addSIMDRelOp): (JSC::Wasm::AirIRGenerator::addSIMDV_VV): (JSC::Wasm::AirIRGenerator::addEndToUnreachable): (JSC::Wasm::AirIRGenerator::endTopLevel): (JSC::Wasm::AirIRGenerator::emitCallPatchpoint): (JSC::Wasm::AirIRGenerator::setParser): (JSC::Wasm::AirIRGenerator::didFinishParsingLocals): (JSC::Wasm::AirIRGenerator::didPopValueFromStack): (JSC::Wasm::AirIRGenerator:: const): (JSC::Wasm::AirIRGenerator::addStackMap): (JSC::Wasm::AirIRGenerator::takeStackmaps): (JSC::Wasm::AirIRGenerator::takeExceptionHandlers): (JSC::Wasm::AirIRGenerator::validateInst): (JSC::Wasm::AirIRGenerator::extractArg): (JSC::Wasm::AirIRGenerator::append): (JSC::Wasm::AirIRGenerator::appendEffectful): (JSC::Wasm::AirIRGenerator::newTmp): (JSC::Wasm::AirIRGenerator::g32): (JSC::Wasm::AirIRGenerator::g64): (JSC::Wasm::AirIRGenerator::gExternref): (JSC::Wasm::AirIRGenerator::gFuncref): (JSC::Wasm::AirIRGenerator::gRef): (JSC::Wasm::AirIRGenerator::f32): (JSC::Wasm::AirIRGenerator::f64): (JSC::Wasm::AirIRGenerator::v128): (JSC::Wasm::AirIRGenerator::tmpForType): (JSC::Wasm::AirIRGenerator::tmpsForSignature): (JSC::Wasm::AirIRGenerator::addPatchpoint): (JSC::Wasm::AirIRGenerator::emitPatchpoint): (JSC::Wasm::AirIRGenerator::emitCheck): (JSC::Wasm::AirIRGenerator::emitCCall): (JSC::Wasm::AirIRGenerator::moveOpForValueType): (JSC::Wasm::AirIRGenerator::emitLoad): (JSC::Wasm::AirIRGenerator::materializeAddrArg): (JSC::Wasm::AirIRGenerator::materializeSimpleAddrArg): (JSC::Wasm::AirIRGenerator::outerLoopIndex const): (JSC::Wasm::AirIRGenerator::useSignalingMemory const): (JSC::Wasm::AirIRGenerator::instanceValue): (JSC::Wasm::AirIRGenerator::fixupPointerPlusOffs
[webkit-changes] [WebKit/WebKit] a424a3: [JSC][armv7] Unskip most of newly-added v8/regress...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: a424a3666e9ffa84ccb087b7bfc677299aa0f236 https://github.com/WebKit/WebKit/commit/a424a3666e9ffa84ccb087b7bfc677299aa0f236 Author: Joseph Griego Date: 2022-12-07 (Wed, 07 Dec 2022) Changed paths: M JSTests/wasm.yaml M JSTests/wasm/v8/regress/regress-1045225.js M JSTests/wasm/v8/regress/regress-1045737.js M JSTests/wasm/v8/regress/regress-1048241.js M JSTests/wasm/v8/regress/regress-1074586.js M JSTests/wasm/v8/regress/regress-1080902.js M JSTests/wasm/v8/regress/regress-10898.js M JSTests/wasm/v8/regress/regress-1140549.js M JSTests/wasm/v8/regress/regress-1153442.js M JSTests/wasm/v8/regress/regress-1179025.js M JSTests/wasm/v8/regress/regress-1220855.js M JSTests/wasm/v8/regress/regress-873600.js M JSTests/wasm/v8/regress/regress-9425.js Log Message: --- [JSC][armv7] Unskip most of newly-added v8/regress tests https://bugs.webkit.org/show_bug.cgi?id=248905 Reviewed by Yusuke Suzuki. Many of these tests do pass on 32-bit arm; we just need to skip a few that require wasm shared memory or >2GB allocations; so, do that and run the rest of the suite as normal for now. Of the unconditionally skipped tests in this directory, I suspect only `JSTests/wasm/v8/regress/regress-crbug-816961.js` has the potential to be problematic for the 32-bit port. * JSTests/wasm.yaml: * JSTests/wasm/v8/regress/regress-1045225.js: * JSTests/wasm/v8/regress/regress-1045737.js: * JSTests/wasm/v8/regress/regress-1048241.js: * JSTests/wasm/v8/regress/regress-1074586.js: * JSTests/wasm/v8/regress/regress-1080902.js: * JSTests/wasm/v8/regress/regress-10898.js: * JSTests/wasm/v8/regress/regress-1140549.js: * JSTests/wasm/v8/regress/regress-1153442.js: * JSTests/wasm/v8/regress/regress-1179025.js: * JSTests/wasm/v8/regress/regress-1220855.js: * JSTests/wasm/v8/regress/regress-873600.js: * JSTests/wasm/v8/regress/regress-9425.js: Canonical link: https://commits.webkit.org/257516@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] fdb483: Improve same-register moves in AirAllocateRegister...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: fdb483c0938270803e4374715b55d0c52b8e27de https://github.com/WebKit/WebKit/commit/fdb483c0938270803e4374715b55d0c52b8e27de Author: Joseph Griego Date: 2022-12-07 (Wed, 07 Dec 2022) Changed paths: M Source/JavaScriptCore/b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp Log Message: --- Improve same-register moves in AirAllocateRegistersAndStackAndGenerateCode https://bugs.webkit.org/show_bug.cgi?id=242816. Reviewed by Saam Barati. When we are emitting a `Move` from a Tmp to a named-register Tmp that matches its current allocation, we currently generate code that spills the source tmp to the stack, allocates a new (distinct) register for it, restores it there, and then moves it; this seems wasteful and, although this kind of situation in Air is not common on x86_64, we do generate it on 32-bit ARM targets: For example, this pattern is quite common before patchpoints: ... Move %tmpN, %r0 : str r0, [r7, #-0x50] - : ldr r3, [r7, #-0x50] - : mov r0, r3 : str r0, [r7, #-0x70] : str r1, [r7, #-0x58] : str r2, [r7, #-0x60] - : str r3, [r7, #-0x50] : ldr r0, [r7, #-0x70] : ldr r1, [r7, #-0x60] ... (This is a before- and after-this-patch diff of disassembly output, with code addresses elided: that is, this patch causes the lines prefixed with `-` to be removed) * Source/JavaScriptCore/b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: (JSC::B3::Air::GenerateAndAllocateRegisters::generate): Canonical link: https://commits.webkit.org/257513@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] bb3be5: [JSC] Fix race condition in Atomics.{wait, waitAsync}
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: bb3be5c8f260f4dbdece34885f9de06dd5254b6d https://github.com/WebKit/WebKit/commit/bb3be5c8f260f4dbdece34885f9de06dd5254b6d Author: Joseph Griego Date: 2022-12-06 (Tue, 06 Dec 2022) Changed paths: M JSTests/stress/waitasync-waiter-list-order.js M Source/JavaScriptCore/runtime/AtomicsObject.cpp M Source/JavaScriptCore/runtime/WaiterListManager.cpp M Source/JavaScriptCore/runtime/WaiterListManager.h Log Message: --- [JSC] Fix race condition in Atomics.{wait,waitAsync} https://bugs.webkit.org/show_bug.cgi?id=248631 Reviewed by Yusuke Suzuki. At the moment, this is manifesting as intermittent timeouts in the arm32 linux test runner, for example: https://build.webkit.org/#/builders/24/builds/17430 After investigation, this is the test `stress/waitasync-waiter-list-order.js` hanging; this manifests as some of the workers hanging on the initial `Atomic.wait` call in that test--using a debugger to examine the memory being waited on reveals that they should all have woken up and moved on. The implementation of both `Atomics.wait` and `Atomics.waitAsync` begin by atomically reading from the array and comparing the result to the expected value, then obtaining a lock on the list of waiters and proceeding from there--this is contrary to the spec [1], which requires that the atomic read happens while the list of waiters is exclusively locked and allows a race where the following interleaving results in A hanging indefinitely if no other calls to Atomic.notify on that address occur: thread A: begin Atomic.wait(buffer, idx, expected_value) thread A: read buffer[idx], get expected_value thread B: perform Atomic.store(buffer, idx, unexpected_value) thread B: perform Atomic.notify(buffer, idx) [nothing is notified since the list of waiters is empty] thread A: lock list of waiters, wait on condition variable, hang waiting for next notify This is fixed by delaying the atomic read until the lock on the list of waiters is held [1] https://tc39.es/ecma262/multipage/structured-data.html#sec-atomics.wait * Source/JavaScriptCore/runtime/AtomicsObject.cpp: (JSC::atomicsWaitImpl): * Source/JavaScriptCore/runtime/WaiterListManager.cpp: (JSC::WaiterListManager::waitImpl): (JSC::WaiterListManager::wait): (JSC::WaiterListManager::timeoutAsyncWaiter): (JSC::WaiterListManager::addAsyncWaiter): Deleted. * Source/JavaScriptCore/runtime/WaiterListManager.h: Canonical link: https://commits.webkit.org/257423@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 51613a: [JSC][armv7] Use register numbers, not names, in d...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 51613ad86d5893667dd02bcdc0430f542f766fb9 https://github.com/WebKit/WebKit/commit/51613ad86d5893667dd02bcdc0430f542f766fb9 Author: Joseph Griego Date: 2022-10-28 (Fri, 28 Oct 2022) Changed paths: M Source/JavaScriptCore/disassembler/CapstoneDisassembler.cpp Log Message: --- [JSC][armv7] Use register numbers, not names, in disassembly https://bugs.webkit.org/show_bug.cgi?id=246708 Reviewed by Yusuke Suzuki. As title. Capstone by default will use the conventional names for some registers under the usual ARM abi: e.g. r12 is the "InterProcedural link" register, `ip`, and r11 is `fp` for ARM code... Neither of these makes any sense inside of the JIT, which uses r12 as a GPR and r7 as the frame pointer (like other thumb code does.) To alleviate confusion, I suggest we ask capstone to just use register numbers for these. Note that `pc` and `sp` are always named in the ISA, they don't have numbers at all, so they'll still disassemble as `pc` and `sp`. * Source/JavaScriptCore/disassembler/CapstoneDisassembler.cpp: (JSC::tryToDisassemble): Canonical link: https://commits.webkit.org/256113@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] 256a5b: [JSC] Fix AssemblyCommentRegistry when not using l...
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: 256a5b87fda903edfb2bf98dd7293122cc611b08 https://github.com/WebKit/WebKit/commit/256a5b87fda903edfb2bf98dd7293122cc611b08 Author: Joseph Griego Date: 2022-10-19 (Wed, 19 Oct 2022) Changed paths: M Source/JavaScriptCore/jit/ExecutableAllocator.cpp Log Message: --- [JSC] Fix AssemblyCommentRegistry when not using libpas jit heap https://bugs.webkit.org/show_bug.cgi?id=246705 Reviewed by Yusuke Suzuki. On e.g. armv7 linux where the libpas allocator is not used, the assertion enforcing that comment registry regions are disjoint fails. Reproducing the failure is easy: ./WebKitBuild/Debug/bin/jsc --dumpDisassembly=1 JSTests/stress/dfg-branch.js This results in: ASSERTION FAILED: newEnd <= thisStart || thisEnd <= newStart ../../Source/JavaScriptCore/assembler/AssemblyComments.h(63) : void JSC::AssemblyCommentRegistry::registerCodeRange(void*, void*, JSC::AssemblyCommentRegistry::CommentMap&&) Aborted This seems to be because the comment registry range for a executable region is not unregistered when the memory reason is released back to the allocator--this code was added only for the libpas allocator. To fix it, we just need to also unregister regions when using the not-libpas allocator, too. * Source/JavaScriptCore/jit/ExecutableAllocator.cpp: Canonical link: https://commits.webkit.org/255735@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [WebKit/WebKit] b07e2d: [JSC] Clean up wasm AirIRGenerator FP truncation
Branch: refs/heads/main Home: https://github.com/WebKit/WebKit Commit: b07e2d5c790373fbf908cecdf9aa47517c40de93 https://github.com/WebKit/WebKit/commit/b07e2d5c790373fbf908cecdf9aa47517c40de93 Author: Joseph Griego Date: 2022-09-26 (Mon, 26 Sep 2022) Changed paths: M Source/JavaScriptCore/wasm/WasmAirIRGenerator.cpp Log Message: --- [JSC] Clean up wasm AirIRGenerator FP truncation https://bugs.webkit.org/show_bug.cgi?id=245436 Reviewed by Justin Michaud. The implementation for all of the (checked and saturated) floating point to integer truncations ends up being really duplicative--we have code for the patchpoints to generate the appropriate instructions twice for each flavor of this operation and code for the bounds checking needed is duplicated many times. This patch adds a new method for generating only the code for an unchecked truncation; a table of the output ranges for each flavor, and uses both to have a single implementation for both the checked and saturating versions of each truncation instruction. Also avoids clobbering the macro scratch registers on ARM64 for some variants of the truncation (the ones resulting in U64s) since the macro assembler doesn't seem to actually need them on that architecture. Relying on the existing test suite; this shouldn't really change the generated code, except for the change to the macro scratch register clobbers on ARM64. * Source/JavaScriptCore/wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::lookupTruncationRange): (JSC::Wasm::AirIRGenerator::addUncheckedFloatingPointTruncation): (JSC::Wasm::AirIRGenerator::truncSaturated): (JSC::Wasm::AirIRGenerator::addCheckedFloatingPointTruncation): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): (JSC::Wasm::AirIRGenerator::addOp): Canonical link: https://commits.webkit.org/254875@main ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes