[webkit-changes] [WebKit/WebKit] 3f9563: [JSC][armv7] Unreviewed: Unskip some tests; change...

[jjgriego]

  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...

[jjgriego]

  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/...

[jjgriego]

  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

[jjgriego]

  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...

[jjgriego]

  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

[jjgriego]

  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

[jjgriego]

  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):

[webkit-changes] [WebKit/WebKit] db2ca0: [armv7] Prepare macro assembler for testb3 support

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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

[jjgriego]

  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

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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.

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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

[jjgriego]

  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-...

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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

[jjgriego]

  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...

[jjgriego]

  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):

[webkit-changes] [WebKit/WebKit] a424a3: [JSC][armv7] Unskip most of newly-added v8/regress...

[jjgriego]

  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...

[jjgriego]

  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}

[jjgriego]

  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...

[jjgriego]

  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...

[jjgriego]

  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

[jjgriego]

  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