Earlier, we had to introduce some temporary workarounds in Turbofan to
enable optimizations for common wasm-gc patterns. These are now not
required, since these optimizations are applied in WasmTyper and WasmGCOperatorReducer.
Bug: v8:7748
Change-Id: I3a7bc4bd2a8023a438ee4620934ff3fcb8bcfc6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3693999
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81011}
We implement two optimizations for trap conditionals for patterns that
come up in wasm-gc.
In case of a Merge followed by a trap, where the path conditions of all
branches of the Merge contain the trap condition, we lift the trap into
the branches of the Merge.
In case of a Branch whose IfTrue branch is followed by a TrapIf with the
same condition, we replace it with the trap followed by the IfFalse
branch. Symmetrically for IfFalse and TrapUnless.
Bug: v8:7748
Change-Id: I43040aebe60eab7b2230fc3130e3b8250e8b2f45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190109
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77181}
... by unparking the local heap before accessing the handles.
Bug: v8:7790
Change-Id: I0910fd8ad2a1e9cbbf312acb4f26358a09891f0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404455
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69852}
This CL try to use a phi as a branch condition if the control flow from the
branch is known from previous conditions. This change will open up more branch
folding opportunities for later pass.
Change-Id: I26316ab3a68c2d58d0df53691981288a996d4ba1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674484
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63434}
This adds a simple counter to Turbofan that's incremented throughout the compilation, hopefully
frequently enough so we can use it to detect divergence and performance bugs.
In addition, we assert that this counter never gets too high. That's the equivalent of a simple
timeout, just more deterministic. The limitations on Turbofan input size should guarantee that
we never exceed this limit. Since we probably do exceed it rarely, this check is only a DCHECK and
intended to detect performance and divergence issues, but not supposed to be performed in release
builds.
In addition, this CL adds UMA stats to observe the real world distribution of the tick measurement.
Bug: v8:9444
Change-Id: I182dac6ecac64715e3f5885ff5c7c17549351cd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695475
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62754}
This reverts commit f010b28fbe.
Reason for revert: Introduces a clusterfuzz issue and CAnary crash
Original change's description:
> [TurboFan] Diagnostic code to track down bug in representation selection
>
> We need to characterize the types of dead (IrOpcode::kDead) nodes
> introduced in compilation phases prior to representation selection.
> Normally, a dead node isn't expected at the start of this phase. The
> question is, which phase introduced the dead node and failed to
> deal with it properly?
>
> Bug: chromium:780658
> Change-Id: Ief5b45480bb7d704a2d09dafd60b5d389e0fd42e
> Reviewed-on: https://chromium-review.googlesource.com/765968
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49328}
TBR=mvstanton@chromium.org,mstarzinger@chromium.org
Change-Id: I5d628eb1de630ce4a353b6ef0f80fd74ad740f17
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:780658
Reviewed-on: https://chromium-review.googlesource.com/768747
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49347}
We need to characterize the types of dead (IrOpcode::kDead) nodes
introduced in compilation phases prior to representation selection.
Normally, a dead node isn't expected at the start of this phase. The
question is, which phase introduced the dead node and failed to
deal with it properly?
Bug: chromium:780658
Change-Id: Ief5b45480bb7d704a2d09dafd60b5d389e0fd42e
Reviewed-on: https://chromium-review.googlesource.com/765968
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49328}
This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.
The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
slots to pop upon return in addition to those specified by the Linkage of the
compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
handles all tail-call cases except where the return value type differs, this fallback
was not really useful and in fact caused unexpected behavior with variable
sized argument popping, since it wasn't possible to materialize a Return node
with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
pop argument since the variable pop functionality
LOG=N
Review-Url: https://codereview.chromium.org/2446543002
Cr-Commit-Position: refs/heads/master@{#40699}
Reason for revert:
Seems to break arm64 sim debug and blocks roll:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294
Original issue's description:
> [turbofan] Support variable size argument removal in TF-generated functions
>
> This is preparation for using TF to create builtins that handle variable number of
> arguments and have to remove these arguments dynamically from the stack upon
> return.
>
> The gist of the changes:
> - Added a second argument to the Return node which specifies the number of stack
> slots to pop upon return in addition to those specified by the Linkage of the
> compiled function.
> - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
> handles all tail-call cases except where the return value type differs, this fallback
> was not really useful and in fact caused unexpected behavior with variable
> sized argument popping, since it wasn't possible to materialize a Return node
> with the right pop count from the TailCall without additional context.
> - Modified existing Return generation to pass a constant zero as the additional
> pop argument since the variable pop functionality
>
> LOG=N
TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
NOPRESUBMIT=true
Review-Url: https://codereview.chromium.org/2473643002
Cr-Commit-Position: refs/heads/master@{#40691}
This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.
The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
slots to pop upon return in addition to those specified by the Linkage of the
compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
handles all tail-call cases except where the return value type differs, this fallback
was not really useful and in fact caused unexpected behavior with variable
sized argument popping, since it wasn't possible to materialize a Return node
with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
pop argument since the variable pop functionality
LOG=N
Review-Url: https://codereview.chromium.org/2446543002
Cr-Commit-Position: refs/heads/master@{#40678}
Drop the typing rules for the machine operators and replace them
with UNREACHABLE. These typing rules were never correct and there's
also no need to have those rules at all.
Drive-by-fix: Remove the extremely annoying test-simplified-lowering.cc
file, which is not very useful, but consumes a large amount of time to
keep it compiling and passing. Instead we should introduce appropriate
tests for the SimplifiedLowering that also test something meaningful
w/o just cementing the implementation.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2292463002
Cr-Commit-Position: refs/heads/master@{#38970}
MachineType is now a class with two enum fields:
- MachineRepresentation
- MachineSemantic
Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably:
- register allocator now uses just the representation.
- Phi and Select nodes only refer to representations.
Review URL: https://codereview.chromium.org/1513543003
Cr-Commit-Position: refs/heads/master@{#32738}
Removes a branch that checks for a condition that has been checked on dominators of the branch.
This introduces a new reducer that propagates the list of checked conditions (and their boolean values) through the control flow graph. If it encounters a branch checking a condition with a known value, the branch is eliminated.
The analysis relies on loops being reducible: if a condition has been checked on all paths to loop entry, then it is checked in the loop (regardless what of the conditions checked inside the loop).
The implementation is fairly naive and could be improved:
- all the operation on the condition lists could be made allocation-free when revisited.
- we could try to use a map structure rather than a linked list (to make
lookups faster).
- the merging of control flow could be changed to take into account
conditions from non-dominating paths (as long as all paths check
the condition).
Review URL: https://codereview.chromium.org/1376293005
Cr-Commit-Position: refs/heads/master@{#31347}
