[git-webkit] Automatic rebasing or pull-requests - #5

…jects each time rx::DisplayMtl::getMetalDeviceMatchingAttribute() is called

<https://webkit.org/b/235278>
<rdar://problem/87653812>

Unreviewed follow-up fix from Bug 235281, Comment #5.

* src/libANGLE/renderer/metal/DisplayMtl.mm:
(rx::DisplayMtl::getMetalDeviceMatchingAttribute):
- Remove unneeded calls to .get().


Canonical link: https://commits.webkit.org/246111@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@288097 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    Follow-up: REGRESSION (r286603): Leak of three NSMutableDictionary objects each time rx::DisplayMtl::getMetalDeviceMatchingAttribute() is called
    <https://webkit.org/b/235278>
    <rdar://problem/87653812>

    Unreviewed follow-up fix from Bug 235281, Comment #5.

    * src/libANGLE/renderer/metal/DisplayMtl.mm:
    (rx::DisplayMtl::getMetalDeviceMatchingAttribute):
    - Remove unneeded calls to .get().

    Canonical link: https://commits.webkit.org/246111@main
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@288097 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/245886.26@safari-613-branch
git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-613-branch@288508 268f45cc-cd09-0410-ab3c-d52691b4dbfc

    Follow-up: REGRESSION (r286603): Leak of three NSMutableDictionary objects each time rx::DisplayMtl::getMetalDeviceMatchingAttribute() is called
    <https://webkit.org/b/235278>
    <rdar://problem/87653812>

    Unreviewed follow-up fix from Bug 235281, Comment #5.

    * src/libANGLE/renderer/metal/DisplayMtl.mm:
    (rx::DisplayMtl::getMetalDeviceMatchingAttribute):
    - Remove unneeded calls to .get().

    Canonical link: https://commits.webkit.org/246111@main
    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@288097 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Canonical link: https://commits.webkit.org/245886.26@safari-613-branch
git-svn-id: https://svn.webkit.org/repository/webkit/branches/safari-613-branch@288508 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=251063
rdar://104585575

Reviewed by Mark Lam and Justin Michaud.

This patch enhances CallFrame::dump to support wasm frames in btjs stacktrace.
The example is as follows.

    frame #0: 0x00000001035fca78 JavaScriptCore`JSC::functionBreakpoint(globalObject=0x000000012f410068, callFrame=0x000000016fdfa9d0) at JSDollarVM.cpp:2273:9 [opt]
    frame WebKit#1: 0x000000010ec44204 0x10eccc5dc
    frame WebKit#2: 0x000000010eccc5dc callback#Dwaxn6 [Baseline bc#50](Undefined)
    frame WebKit#3: 0x000000010ec4ca84 wasm-stub [WasmToJS](Wasm::Instance: 0x10d29da40)
    frame WebKit#4: 0x000000010ed0c060 <?>.wasm-function[1] [OMG](Wasm::Instance: 0x10d29da40)
    frame WebKit#5: 0x000000010ed100d0 jsToWasm#CWTx6k [FTL bc#22](Cell[JSModuleEnvironment]: 0x12f524540, Cell[WebAssemblyFunction]: 0x10d06a3a8, 1, 2, 3)
    frame WebKit#6: 0x000000010ec881b0 #D5ymZE [Baseline bc#733](Undefined, Cell[Generator]: 0x12f55c180, 1, Cell[Object]: 0x12f69dfc0, 0, Cell[JSLexicalEnvironment]: 0x12f52cee0)
    frame WebKit#7: 0x000000010ec3c008 asyncFunctionResume#A4ayYg [LLInt bc#49](Undefined, Cell[Generator]: 0x12f55c180, Cell[Object]: 0x12f69dfc0, 0)
    frame WebKit#8: 0x000000010ec3c008 promiseReactionJobWithoutPromise#D0yDF1 [LLInt bc#25](Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180)
    frame WebKit#9: 0x000000010ec80ec0 promiseReactionJob#EdShZz [Baseline bc#74](Undefined, Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180)
    frame WebKit#10: 0x000000010ec3c728
    frame WebKit#11: 0x0000000103137560 JavaScriptCore`JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) [inlined] JSC::JITCode::execute(this=<unavailable>, vm=<unavailable>, protoCallFrame=<unavailable>) at JITCodeInlines.h:42:38 [opt]
    frame WebKit#12: 0x0000000103137524 JavaScriptCore`JSC::Interpreter::executeCall(this=<unavailable>, lexicalGlobalObject=<unavailable>, function=<unavailable>, callData=<unavailable>, thisValue=<unavailable>, args=<unavailable>) at Interpreter.cpp:1093:27 [opt]
    frame WebKit#13: 0x000000010349d6d0 JavaScriptCore`JSC::runJSMicrotask(globalObject=0x000000012f410068, identifier=(m_identifier = 81), job=JSValue @ x22, argument0=JSValue @ x26, argument1=JSValue @ x25, argument2=<unavailable>, argument3=<unavailable>) at JSMicrotask.cpp:98:9 [opt]
    frame WebKit#14: 0x00000001039dfc54 JavaScriptCore`JSC::VM::drainMicrotasks() (.cold.1) at VM.cpp:0:9 [opt]
    frame WebKit#15: 0x00000001035e58a4 JavaScriptCore`JSC::VM::drainMicrotasks() [inlined] JSC::MicrotaskQueue::dequeue(this=<unavailable>) at VM.cpp:0:9 [opt]
    frame WebKit#16: 0x00000001035e5894 JavaScriptCore`JSC::VM::drainMicrotasks(this=0x000000012f000000) at VM.cpp:1255:46 [opt]
    ...

* Source/JavaScriptCore/interpreter/CallFrame.cpp:
(JSC::CallFrame::dump const):

Canonical link: https://commits.webkit.org/259262@main

https://bugs.webkit.org/show_bug.cgi?id=273715
rdar://127515199

Unreviewed test gardening.

* LayoutTests/platform/mac-site-isolation/TestExpectations:

Canonical link: https://commits.webkit.org/278703@main

…ter follows to the same value

https://bugs.webkit.org/show_bug.cgi?id=279570
rdar://135851156

Reviewed by Keith Miller.

Let's consider the following FTL graph.

    BB#0
    @0 = NewObject()
    Jump WebKit#1

    BB#1
    PutByOffset(@0, 0, @x)
    Jump WebKit#2

    BB#2
    ...
    @z = ...
    @1 = GetByOffset(@x, 0)
    Branch(@1, WebKit#3, WebKit#4)

    BB#3
    PutByOffset(@0, 0, @z)
    Jump WebKit#5

    BB#4
    PutByOffset(@0, 0, @z)
    Jump WebKit#5

    BB#5
    Jump WebKit#2

Now, we would like to eliminate @0 object allocation. And we are
computing SSA for pointers of fields of the that object which gets
eliminated. Consider about @x's fields' SSA. PutByOffset becomes Def
and GetByOffset becomes Use. And the same field will get the same SSA
variable. So we first puts Defs and compute Phis based on that.

In ObjectAllocationSinking phase, we had a fast path when the both SSA
variable is following to the same value. Let's see BB#5. Because BB#3
and BB#4 defines Defs, dominance frontier BB#5 will need to introduce
Phi. But interestingly, both SSA variable is following to the same @z.
As a result, we were not inserting Phi for this case.

But this is wrong. Inserted Phi is a Def, and based on that, we will
further introduce Phis with that. If we omit inserting Phi in BB#5,
we will not insert Phi into BB#2 while BB#2 will merge BB#1's Def And
BB#5's Phi's Def. As a result, in BB#2, we think this variable is
following to BB#1's Def. But that's wrong and BB#5's Phi exists.

This patch removes this fast path to fix the issue.

* JSTests/stress/object-allocation-sinking-phi-insertion-for-pointers.js: Added.
(Queue):
(Queue.prototype.enqueue):
(Queue.prototype.dequeue):
(i.queue.dequeue):
* Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp:

Canonical link: https://commits.webkit.org/283558@main

    [JSC] ObjectAllocationSinking should not omit phi insertion when pointer follows to the same value
    https://bugs.webkit.org/show_bug.cgi?id=279570
    rdar://135851156

    Reviewed by Keith Miller.

    Let's consider the following FTL graph.

        BB#0
        @0 = NewObject()
        Jump #1

        BB#1
        PutByOffset(@0, 0, @x)
        Jump #2

        BB#2
        ...
        @z = ...
        @1 = GetByOffset(@x, 0)
        Branch(@1, #3, #4)

        BB#3
        PutByOffset(@0, 0, @z)
        Jump #5

        BB#4
        PutByOffset(@0, 0, @z)
        Jump #5

        BB#5
        Jump #2

    Now, we would like to eliminate @0 object allocation. And we are
    computing SSA for pointers of fields of the that object which gets
    eliminated. Consider about @x's fields' SSA. PutByOffset becomes Def
    and GetByOffset becomes Use. And the same field will get the same SSA
    variable. So we first puts Defs and compute Phis based on that.

    In ObjectAllocationSinking phase, we had a fast path when the both SSA
    variable is following to the same value. Let's see BB#5. Because BB#3
    and BB#4 defines Defs, dominance frontier BB#5 will need to introduce
    Phi. But interestingly, both SSA variable is following to the same @z.
    As a result, we were not inserting Phi for this case.

    But this is wrong. Inserted Phi is a Def, and based on that, we will
    further introduce Phis with that. If we omit inserting Phi in BB#5,
    we will not insert Phi into BB#2 while BB#2 will merge BB#1's Def And
    BB#5's Phi's Def. As a result, in BB#2, we think this variable is
    following to BB#1's Def. But that's wrong and BB#5's Phi exists.

    This patch removes this fast path to fix the issue.

    * JSTests/stress/object-allocation-sinking-phi-insertion-for-pointers.js: Added.
    (Queue):
    (Queue.prototype.enqueue):
    (Queue.prototype.dequeue):
    (i.queue.dequeue):
    * Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp:

    Canonical link: https://commits.webkit.org/283558@main

Canonical link: https://commits.webkit.org/280938.337@safari-7619-branch

Reviewed by NOBODY (OOPS!).

This was spotted by ASan, the real and imaginary AudioFloatArrays end-up using aligned_alloc() for
their storage, which expects a power-of-two size. Using fftSize / 2 + 1 makes the size
non-power-of-two, the full fftSize being power-of-two (we now have an ASSERT for this).

==1733723==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fc75c438bca bp 0x7ffed612c860 sp 0x7ffed612c028 T0)
==1733723==The signal is caused by a WRITE memory access.
==1733723==Hint: address points to the zero page.
    #0 0x7fc75c438bca in __memset_avx2_unaligned_erms (/lib64/libc.so.6+0x16dbca) (BuildId: 77c77fee058b19c6f001cf2cb0371ce3b8341211)
    WebKit#1 0x2fc4ce in __asan_memset (/var/home/phil/WebKit/local-build-gtk/WebKitBuild/GTK/Release/bin/WebKitWebProcess+0x2fc4ce) (BuildId: e2b0aff0c8fcab48026d63cf711cd70d0aeceb79)
    WebKit#2 0x7fc77047599e in WebCore::FFTFrame::FFTFrame(unsigned int) UnifiedSource-3c72abbe-20.cpp
    WebKit#3 0x7fc76d41c08b in WebCore::PeriodicWave::createBandLimitedTables(float const*, float const*, unsigned int, WebCore::ShouldDisableNormalization) UnifiedSource-f8afad56-52.cpp
    WebKit#4 0x7fc76d41f371 in WebCore::PeriodicWave::generateBasicWaveform(WebCore::PeriodicWave::Type) UnifiedSource-f8afad56-52.cpp
    WebKit#5 0x7fc76d41e633 in WebCore::PeriodicWave::createSine(float) UnifiedSource-f8afad56-52.cpp
    WebKit#6 0x7fc76d3c2352 in WebCore::BaseAudioContext::periodicWave(WebCore::OscillatorType) UnifiedSource-f8afad56-49.cpp
    WebKit#7 0x7fc76d410dbf in WebCore::OscillatorNode::setTypeForBindings(WebCore::OscillatorType) UnifiedSource-f8afad56-52.cpp
    WebKit#8 0x7fc76d4102f4 in WebCore::OscillatorNode::create(WebCore::BaseAudioContext&, WebCore::OscillatorOptions const&) UnifiedSource-f8afad56-52.cpp
    WebKit#9 0x7fc76d3bc210 in WebCore::BaseAudioContext::createOscillator() UnifiedSource-f8afad56-49.cpp
    WebKit#10 0x7fc76acbc743 in WebCore::jsBaseAudioContextPrototypeFunction_createOscillator(JSC::JSGlobalObject*, JSC::CallFrame*) UnifiedSource-3a52ce78-11.cpp
    WebKit#11 0x7fc705c10037  (<unknown module>)

* Source/WebCore/platform/audio/gstreamer/FFTFrameGStreamer.cpp:
(WebCore::FFTFrame::FFTFrame):

https://bugs.webkit.org/show_bug.cgi?id=316798

Reviewed by BJ Burg.

To improve traceability, this commit adds RELEASE_LOG statements
covering the following areas of Source/WebDriver:

- Browser startup and lifetime (for glib ports)
- HTTP request and response
- Driver->Browser Automation.json commands and replies.

The added log statements cover mainly data like the request path, body
size, response status, and duration. The actual body with payload like
field values or JS code to be executed is omitted. For deeper
inspection, the existing LOG() statements that inspect the actual
payload are kept.

We opted for RELEASE_LOG instead of LOG due to the WebDriver-related
channels being low-volume in comparison to hotter ones internal to the
browser. On top of that, it should be easier for reporters to provide
release logs, helping get more useful bug reports.

Example output:

Started WebSocket BiDi server with host local and port 60782
Started HTTP server with host local and port 60781
HTTP request POST /session (body=303 bytes)
Spawning local browser: /sdk/webkit/WebKitBuild/WPE/Release/bin/MiniBrowser with 2 argument(s)
Connecting to RemoteInspector at 127.0.0.1:54821
Connected to RemoteInspector at 127.0.0.1:54821 after 1 attempt(s)
    SEND inspector WebKit#1: Automation.createBrowsingContext (52 bytes)
    RECV inspector WebKit#1: ok
HTTP response 200 in 196ms
HTTP request POST /session/fbc9c527-945d-4030-852e-50c5f1852557/url (body=43 bytes)
    SEND inspector WebKit#2: Automation.resolveBrowsingContext (149 bytes)
    RECV inspector WebKit#2: ok
    SEND inspector WebKit#3: Automation.waitForNavigationToComplete (207 bytes)
    RECV inspector WebKit#3: ok
    SEND inspector WebKit#4: Automation.isShowingJavaScriptDialog (135 bytes)
    RECV inspector WebKit#4: ok
    SEND inspector WebKit#5: Automation.navigateBrowsingContext (212 bytes)
    RECV inspector WebKit#5: ok
HTTP response 200 in 124ms

* Source/WebDriver/SessionHost.cpp:
(WebDriver::SessionHost::inspectorDisconnected):
(WebDriver::SessionHost::sendCommandToBackend):
(WebDriver::SessionHost::dispatchMessage):
* Source/WebDriver/WebDriverService.cpp:
(WebDriver::printUsageStatement):
(WebDriver::WebDriverService::run):
(WebDriver::WebDriverService::handleRequest):
* Source/WebDriver/glib/SessionHostGlib.cpp:
(WebDriver::SessionHost::launchBrowser):
(WebDriver::SessionHost::connectToBrowser):
(WebDriver::SessionHost::connectionDidClose):
(WebDriver::SessionHost::setTargetList):

Canonical link: https://commits.webkit.org/316784@main

https://bugs.webkit.org/show_bug.cgi?id=323729

Reviewed by NOBODY (OOPS!).

zeroExtend32ToWord(r, r) is spelled mov wN, wN on arm64, and every tier
emits it defensively: BBQ before it uses an i32 as an address operand,
extends it to i64 or wraps an i64 to i32 (the upper half of an i32 in a
register is don't-care in BBQ's register model), the DFG when it strictly
fills an Int32, and B3/Air for ZExt32 and for every 32-bit C call argument.
Nearly every time, the instruction right before it already left the upper
half of the register clear -- a 32-bit add, a 32-bit load, a right shift of
an i64 by 32 -- so the mov does nothing:

    add w0, w0, w1          ; DFG ArithAdd
    mov w0, w0              ; zeroExtend32ToWord(w0, w0)

    ldur w1, [x29, #-0x10]  ; BBQ reloads an i32 local
    mov w1, w1              ; i64.extend_i32_u

    lsr x0, x0, WebKit#32         ; BBQ i64.shr_u
    mov w0, w0              ; i32.wrap_i64

    mov x2, WebKit#5              ; Air: Move $5 into the argument register,
    mov w2, w2              ; then Move32 to zero-extend it

Two changes:

* MacroAssemblerARM64::zeroExtend32ToWord(src, dest) with src == dest now
  asks the assembler whether the instruction it just emitted already wrote
  dest with the upper half clear, and emits nothing if so. ARM64Assembler
  remembers the last instruction word it emitted (insn() is the only
  emission path) and decodes it: every sf=0 data-processing class, every
  load into a W register, and the 64-bit instructions whose result provably
  fits in 32 bits -- MOVZ with hw < 2, UBFX of width at most 32 (which is
  what LSR by 32 or more is), and AND or MOV with a bitmask immediate
  confined to the low half. The one way this could go wrong is control
  arriving at the mov without having executed the producer, so the
  assembler also records the offset of the most recent label(): Label
  construction, Jump::link(), JumpList::link(), align() and
  padBeforePatch() all bind through it, and a label at the current
  position disables the elision. labelIgnoringWatchpoints() is
  deliberately not a barrier. It marks positions inside jump-replacement
  regions, which no branch may target, and the DFG and Air evaluate it
  after every slow path and instruction for the PC-to-origin map, so
  treating it as one would disable the elision almost everywhere.

* B3/Air materialized a 32-bit immediate C call argument as Move $imm into
  a fresh Tmp followed by Move32 into the argument register, both in
  ShufflePair::insts() and in emitShuffle()'s shift path. TmpWidth only
  narrows the def width of an Imm move and this one is a BigImm, so the
  register allocator could not turn the Move32 into a Move and delete it
  after coalescing; it survived as mov x2, WebKit#5; mov w2, w2. A register
  destination now takes a single Move of the zero-extended immediate.

Scanning everything the JITs emit while running JetStream 3 on arm64 (54.6M
instructions in 109,925 code blocks), armlint reports 2844 redundant
zero-extensions after a zeroing write: 1903 in BBQ, 410 in FTL, 289 in the
DFG, 238 in OMG and 4 in FTL OSR exits. After this change it reports 20: 9
in FTL, 7 in BBQ, 3 in the DFG and 1 in OMG, every one of them an and with
a mask after a cset, lsr or ldrb rather than a self-move, so none is a
zeroExtend32ToWord() call.

Counting every mov wN, wN in the corpus rather than only the ones armlint
can prove dead: 57364 before, 53617 after, so 3747 instructions (15 KB) are
gone. BBQ goes from 32770 to 30874 and the count is identical across two
runs of the new binary; FTL goes from 2624 to 1752 and OMG from 1734 to
1297, more than armlint's site counts because the Air change also removes
Move32s whose preceding Move armlint does not model as a zeroing write; the
DFG goes from 10043 to 9495. Two dumps of the same binary differ by 83 in
this count, and by 0.3% in total code bytes (the JIT embeds pointers whose
movz/movk count depends on where things were allocated), so the 15 KB is
real per instruction but invisible in the corpus total. What remains is
30874 self-moves in BBQ and 9495 in the DFG whose producer is not the
immediately preceding instruction; catching those needs a set of
known-clean registers rather than a look at the last instruction.

JetStream 3 under the jsc shell on this M-series machine, 16 interleaved
pairs (eight A,B then eight B,A so run-order drift cancels), geomean paired
B/A: -0.21%, 95% CI [-1.19%, +0.77%], median -0.17%, and the sign flips with
the run order (A,B pairs -0.49%, B,A pairs +0.08%). Seven of 75 subtests
move by more than their own confidence interval, in both directions, with
the largest at about 2% either way. So the change is instruction count and
code size only, as expected for a register-to-register mov that the core
renames away.

testmasm gains testZeroExtend32ToWordAfterZeroExtendingWrite, which checks
both the emitted size and the result of each shape with dirty upper halves
in the inputs: add32, a 32-bit load, a W move, a one-instruction X movz,
lsr x by 32, and64 with a low-half bitmask and a bitmask mov elide the mov;
add64, a 64-bit load, a movk or a bitmask reaching into the upper half,
lsr x by 16, a wider and64 mask, a csel (moveConditionally32 selects 64
bits), a label() or a linked jump between the two instructions, a different
register, and src != dest all keep it. testmasm goes from 465 to 466 tests;
testb3, testair and all 20810 JSTests/stress runs (default and
no-cjit-validate modes) pass.

Found with armlint.

* Source/JavaScriptCore/assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::ARM64Assembler):
(JSC::ARM64Assembler::labelForWatchpoint):
(JSC::ARM64Assembler::label):
(JSC::ARM64Assembler::lastInstructionZeroExtendsRegister):
(JSC::ARM64Assembler::zeroExtendsRegister):
(JSC::ARM64Assembler::insn):
* Source/JavaScriptCore/assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::zeroExtend32ToWord):
* Source/JavaScriptCore/assembler/testmasm.cpp:
(JSC::testZeroExtend32ToWordAfterZeroExtendingWrite):
(JSC::run):
* Source/JavaScriptCore/b3/air/AirEmitShuffle.cpp:
(JSC::B3::Air::ShufflePair::insts const):
(JSC::B3::Air::emitShuffle):

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EaeigoH8u1YuiVpZZQdTQ8

…gi?id=316798

    [WebDriver] Improve driver logging coverage
    https://bugs.webkit.org/show_bug.cgi?id=316798

    Reviewed by BJ Burg.

    To improve traceability, this commit adds RELEASE_LOG statements
    covering the following areas of Source/WebDriver:

    - Browser startup and lifetime (for glib ports)
    - HTTP request and response
    - Driver->Browser Automation.json commands and replies.

    The added log statements cover mainly data like the request path, body
    size, response status, and duration. The actual body with payload like
    field values or JS code to be executed is omitted. For deeper
    inspection, the existing LOG() statements that inspect the actual
    payload are kept.

    We opted for RELEASE_LOG instead of LOG due to the WebDriver-related
    channels being low-volume in comparison to hotter ones internal to the
    browser. On top of that, it should be easier for reporters to provide
    release logs, helping get more useful bug reports.

    Example output:

    Started WebSocket BiDi server with host local and port 60782
    Started HTTP server with host local and port 60781
    HTTP request POST /session (body=303 bytes)
    Spawning local browser: /sdk/webkit/WebKitBuild/WPE/Release/bin/MiniBrowser with 2 argument(s)
    Connecting to RemoteInspector at 127.0.0.1:54821
    Connected to RemoteInspector at 127.0.0.1:54821 after 1 attempt(s)
        SEND inspector WebKit#1: Automation.createBrowsingContext (52 bytes)
        RECV inspector WebKit#1: ok
    HTTP response 200 in 196ms
    HTTP request POST /session/fbc9c527-945d-4030-852e-50c5f1852557/url (body=43 bytes)
        SEND inspector WebKit#2: Automation.resolveBrowsingContext (149 bytes)
        RECV inspector WebKit#2: ok
        SEND inspector WebKit#3: Automation.waitForNavigationToComplete (207 bytes)
        RECV inspector WebKit#3: ok
        SEND inspector WebKit#4: Automation.isShowingJavaScriptDialog (135 bytes)
        RECV inspector WebKit#4: ok
        SEND inspector WebKit#5: Automation.navigateBrowsingContext (212 bytes)
        RECV inspector WebKit#5: ok
    HTTP response 200 in 124ms

    * Source/WebDriver/SessionHost.cpp:
    (WebDriver::SessionHost::inspectorDisconnected):
    (WebDriver::SessionHost::sendCommandToBackend):
    (WebDriver::SessionHost::dispatchMessage):
    * Source/WebDriver/WebDriverService.cpp:
    (WebDriver::printUsageStatement):
    (WebDriver::WebDriverService::run):
    (WebDriver::WebDriverService::handleRequest):
    * Source/WebDriver/glib/SessionHostGlib.cpp:
    (WebDriver::SessionHost::launchBrowser):
    (WebDriver::SessionHost::connectToBrowser):
    (WebDriver::SessionHost::connectionDidClose):
    (WebDriver::SessionHost::setTargetList):

    Canonical link: https://commits.webkit.org/316784@main

Canonical link: https://commits.webkit.org/305877.1183@webkitglib/2.52

…bug.cgi?id=316798

Reviewed by NOBODY (OOPS!).

To improve traceability, this commit adds RELEASE_LOG statements
covering the following areas of Source/WebDriver:

- Browser startup and lifetime (for glib ports)
- HTTP request and response
- Driver->Browser Automation.json commands and replies.

The added log statements cover mainly data like the request path, body
size, response status, and duration. The actual body with payload like
field values or JS code to be executed is omitted. For deeper
inspection, the existing LOG() statements that inspect the actual
payload are kept.

We opted for RELEASE_LOG instead of LOG due to the WebDriver-related
channels being low-volume in comparison to hotter ones internal to the
browser. On top of that, it should be easier for reporters to provide
release logs, helping get more useful bug reports.

Example output:

WPEWebDriver starting: http=local:49641 bidi=49642
Started WebSocket BiDi server with host local and port 49642
Started HTTP server with host local and port 49641
=> POST /session (body=303 bytes)
Spawning local browser: /sdk/webkit/WebKitBuild/WPE/Release/bin/MiniBrowser with 2 argument(s)
Connecting to remote inspector at 127.0.0.1:51177
Still attempting connection to 127.0.0.1:51177 (attempt 10)
Connected to remote inspector at 127.0.0.1:51177 after 20 attempt(s)
-> command WebKit#1: Automation.createBrowsingContext (52 bytes)
<- reply WebKit#1: ok
<= 200 in 2068ms
=> POST /session/c4d60e66-ab08-4d46-a932-7506710c3420/url (body=48 bytes)
-> command WebKit#2: Automation.resolveBrowsingContext (149 bytes)
<- reply WebKit#2: ok
-> command WebKit#3: Automation.waitForNavigationToComplete (207 bytes)
<- reply WebKit#3: ok
-> command WebKit#4: Automation.isShowingJavaScriptDialog (135 bytes)
<- reply WebKit#4: ok
-> command WebKit#5: Automation.navigateBrowsingContext (217 bytes)
<- reply WebKit#5: ok
<= 200 in 207ms

* Source/WebDriver/SessionHost.cpp:
(WebDriver::SessionHost::inspectorDisconnected):
(WebDriver::SessionHost::sendCommandToBackend):
(WebDriver::SessionHost::dispatchMessage):
* Source/WebDriver/WebDriverService.cpp:
(WebDriver::printUsageStatement):
(WebDriver::WebDriverService::run):
(WebDriver::WebDriverService::handleRequest):
* Source/WebDriver/glib/SessionHostGlib.cpp:
(WebDriver::SessionHost::launchBrowser):
(WebDriver::SessionHost::connectToBrowser):
(WebDriver::SessionHost::connectionDidClose):
(WebDriver::SessionHost::setTargetList):

…e / jfalse follows

https://bugs.webkit.org/show_bug.cgi?id=327327
rdar://189865582

Reviewed by NOBODY (OOPS!).

Currently, when we have a code like,

    function notInstance(term) {
        if (!(term instanceof Pair))
            return term;
        return term.car;
    }

`instanceof` creates a graph due to multiple complicated arms, and then
all of boolean results are combined into one phi, and then we jump based
on this phi result. However this form pessimizes the optimizations.

    WebKit#3  MatchStructure arm         D@74: MatchStructure(D@63, Object=>true)
                                   D@76: SetLocal(D@74, loc5)
                                   D@77: Jump(T:WebKit#7)
    WebKit#4  value-not-object arm       D@59: JSConstant(False)
                                   D@61: SetLocal(D@59, loc5)
                                   D@62: Jump(T:WebKit#7)
    WebKit#5  custom hasInstance arm     D@47: InstanceOfCustom(...)
                                   D@49: SetLocal(D@47, loc5)
                                   D@50: Jump(T:WebKit#7)

    WebKit#7 (bc#25)  preds: WebKit#5 WebKit#3 WebKit#4    D@78: GetLocal(loc5)
                                   D@79: Branch(D@78, T:WebKit#9, F:WebKit#8)
    WebKit#8 (bc#28)  return term
    WebKit#9 (bc#30)  CheckStructure(term, [Object]); GetByOffset(car); Return

In the above graph, due to unified blocks, D@74 MatchStructure's
filtering result is gone, and CheckStructure remains while we already
did Structure check via MatchStructure in one of the most common case.

So, we connect each jump directly when `instanceof` result is used with
`jtrue` / `jfalse`, like

    WebKit#3  MatchStructure arm         D@74: MatchStructure(D@63, Object=>true)
                                   D@76: SetLocal(D@74, loc5)
                                   D@77: Branch(D@74, T:WebKit#8, F:WebKit#7)
    WebKit#4  value-not-object arm       D@59: JSConstant(False)
                                   D@61: SetLocal(D@59, loc5)
                                   D@62: Branch(D@59, T:WebKit#8, F:WebKit#7)
    WebKit#5  custom hasInstance arm     D@47: InstanceOfCustom(...)
                                   D@49: SetLocal(D@47, loc5)
                                   D@50: Branch(D@47, T:WebKit#8, F:WebKit#7)

    WebKit#7 (bc#28)  preds: WebKit#5 WebKit#3 WebKit#4    return term
    WebKit#8 (bc#30)  preds: WebKit#5 WebKit#3 WebKit#4    CheckStructure(term, [Object]); GetByOffset(car); Return

                                   D@76: SetLocal(D@74, loc5)
                                   D@77: Jump(T:WebKit#7)
                                   D@61: SetLocal(D@59, loc5)
                                   D@62: Jump(T:WebKit#7)
                                   D@49: SetLocal(D@47, loc5)
                                   D@50: Jump(T:WebKit#7)

                                   D@79: Branch(D@78, T:WebKit#9, F:WebKit#8)

Then, eventually each MatchStructure, etc. are foled into constant, and
proper constant is propagated through the following blocks instead of
propagating the phi.

Test: JSTests/stress/instanceof-branch-fusion.js

* JSTests/stress/instanceof-branch-fusion.js: Added.
(shouldBe):
(Pair):
(Custom.Symbol.hasInstance):
(Custom):
(notInstance):
(isInstance):
(resultUsedAfterBranch):
(custom):
(loop):
(customJtrue):
(argumentDst):
(longBody):
(longBodyExpected):
(inlinedPredicate):
(inlinedCaller):
(catch):
* Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):

…e / jfalse follows

https://bugs.webkit.org/show_bug.cgi?id=327327
rdar://189865582

Reviewed by Keith Miller and Tadeu Zagallo.

Currently, when we have a code like,

    function notInstance(term) {
        if (!(term instanceof Pair))
            return term;
        return term.car;
    }

`instanceof` creates a graph due to multiple complicated arms, and then
all of boolean results are combined into one phi, and then we jump based
on this phi result. However this form pessimizes the optimizations.

    WebKit#3  MatchStructure arm         D@74: MatchStructure(D@63, Object=>true)
                                   D@76: SetLocal(D@74, loc5)
                                   D@77: Jump(T:WebKit#7)
    WebKit#4  value-not-object arm       D@59: JSConstant(False)
                                   D@61: SetLocal(D@59, loc5)
                                   D@62: Jump(T:WebKit#7)
    WebKit#5  custom hasInstance arm     D@47: InstanceOfCustom(...)
                                   D@49: SetLocal(D@47, loc5)
                                   D@50: Jump(T:WebKit#7)

    WebKit#7 (bc#25)  preds: WebKit#5 WebKit#3 WebKit#4    D@78: GetLocal(loc5)
                                   D@79: Branch(D@78, T:WebKit#9, F:WebKit#8)
    WebKit#8 (bc#28)  return term
    WebKit#9 (bc#30)  CheckStructure(term, [Object]); GetByOffset(car); Return

In the above graph, due to unified blocks, D@74 MatchStructure's
filtering result is gone, and CheckStructure remains while we already
did Structure check via MatchStructure in one of the most common case.

So, we connect each jump directly when `instanceof` result is used with
`jtrue` / `jfalse`, like

    WebKit#3  MatchStructure arm         D@74: MatchStructure(D@63, Object=>true)
                                   D@76: SetLocal(D@74, loc5)
                                   D@77: Branch(D@74, T:WebKit#8, F:WebKit#7)
    WebKit#4  value-not-object arm       D@59: JSConstant(False)
                                   D@61: SetLocal(D@59, loc5)
                                   D@62: Branch(D@59, T:WebKit#8, F:WebKit#7)
    WebKit#5  custom hasInstance arm     D@47: InstanceOfCustom(...)
                                   D@49: SetLocal(D@47, loc5)
                                   D@50: Branch(D@47, T:WebKit#8, F:WebKit#7)

    WebKit#7 (bc#28)  preds: WebKit#5 WebKit#3 WebKit#4    return term
    WebKit#8 (bc#30)  preds: WebKit#5 WebKit#3 WebKit#4    CheckStructure(term, [Object]); GetByOffset(car); Return

                                   D@76: SetLocal(D@74, loc5)
                                   D@77: Jump(T:WebKit#7)
                                   D@61: SetLocal(D@59, loc5)
                                   D@62: Jump(T:WebKit#7)
                                   D@49: SetLocal(D@47, loc5)
                                   D@50: Jump(T:WebKit#7)

                                   D@79: Branch(D@78, T:WebKit#9, F:WebKit#8)

Then, eventually each MatchStructure, etc. are foled into constant, and
proper constant is propagated through the following blocks instead of
propagating the phi.

Test: JSTests/stress/instanceof-branch-fusion.js

* JSTests/stress/instanceof-branch-fusion.js: Added.
(shouldBe):
(Pair):
(Custom.Symbol.hasInstance):
(Custom):
(notInstance):
(isInstance):
(resultUsedAfterBranch):
(custom):
(loop):
(customJtrue):
(argumentDst):
(longBody):
(longBodyExpected):
(inlinedPredicate):
(inlinedCaller):
(catch):
* Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):

Canonical link: https://commits.webkit.org/323664@main

… 1 on the taken edge

https://bugs.webkit.org/show_bug.cgi?id=327633
rdar://190084203

Reviewed by Keith Miller.

When you have a code like this,

    x === 32 || x === 9 || ..

the graph likes this is generated.

    BB#0: (root)
        Int32 @0 = ArgumentReg(x0)                 // x
        Int32 @1 = Const32(36)
        Int32 @2 = Equal(@0, @1)
        Void  @3 = Branch(@2), Successors: Then:WebKit#1, Else:WebKit#2

    BB#1: (firstTaken)  preds: #0
        Void  @4 = Upsilon(@2, ^10)                // passes the compare itself into the Phi
        Void  @5 = Jump, Successors: WebKit#4

    BB#2: (secondCompare)  preds: #0
        Int32 @6 = Const32(95)
        Int32 @7 = Equal(@0, @6)
        Void  @8 = Branch(@7), Successors: Then:WebKit#3, Else:WebKit#6

    BB#3: (secondTaken)  preds: WebKit#2
        Void  @9 = Upsilon(@7, ^10)
        Void  @11 = Jump, Successors: WebKit#4

    BB#4: (join)  preds: WebKit#1, WebKit#3
        Int32 @10 = Phi                            // the merged "||" result
        ...
        Void  @15 = Branch(@10), Successors: Then:WebKit#5, Else:WebKit#6

    BB#5: (matched)
        ...

    BB#6: (unmatched)  preds: WebKit#2, WebKit#4
        Void  @17 = Return($5)

In foldPathConstants, we can install 1 for taken path if the Branch's
input returns bool (e.g. `===`). Then in the above case, @4 and @9 are
replaced with Constant 1, then @10 will be folded into 1 since both are
the same constant input, and @15 will become jump since input is always 1.

Tests: Source/JavaScriptCore/b3/testb3_1.cpp
       Source/JavaScriptCore/b3/testb3_5.cpp

* Source/JavaScriptCore/b3/B3FoldPathConstants.cpp:
* Source/JavaScriptCore/b3/testb3.h:
* Source/JavaScriptCore/b3/testb3_1.cpp:
(run):
* Source/JavaScriptCore/b3/testb3_5.cpp:
(testBranchOnPhiOfTakenComparesFoldPathConstant):

Canonical link: https://commits.webkit.org/323859@main