Looks like these may have been missed; all other related operators
silence NaNs.
Bug: v8:7519
Change-Id: If6ee8d6e02d304ccbb4821c21386f93eab225434
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637853
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72277}
Move index constants into the wrapper, add getters, and use the
wrapper in more spots.
Bug: v8:1166136
Change-Id: I3f37a541482fd6b7c604719c759952a72d58bad2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637218
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72198}
This reflects the actual contents of the type, which is an offset into
the bytecode (or certain marker values). Historically, in the days of
FCG the bailout id used to refer to node ids - this is why certain
tracing output still calls the bailout id 'node id' and 'ast id'.
These spots will be fixed in a follow-up CL.
This change is mechanical:
git grep -l BailoutId | while read f; do \
sed -i 's/BailoutId/BytecodeOffset/g' $f; done
With a manual component of updating the DeoptimizationData method
name from 'BytecodeOffset' to 'GetBytecodeOffset'.
Bug: v8:11332
Change-Id: I956b947a480bf52263159c0eb1e895360bcbe6d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639754
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72189}
If a register is used for both input and output by a SAME_INPUT_OUTPUT
operand, then it represents a different virtual register for the end
use-position of an instruction (since that will become the output's
virtual register). It therefore can't be used to represent the input
virtual register for any input operands that are USED_AT_END.
BUG=chromium:1163715,v8:9684
Change-Id: I8dc0008ba81d5f1d0e38091b6dc013725c62b1b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632700
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72149}
This is a reland of 2f3cda580b
GetFirstUnusedStackSlot is restored, and used for finding the padding
slot location, if any.
Original change's description:
> [compiler] Rework calculation to start of return slots
>
> - Changes GetOffsetToReturns to take into account return slot padding
> and argument padding.
> - Changes GetStackParameterDelta to use GetOffsetToReturns for the SP
> delta calculation.
> - Removes GetFirstUnusedStackSlot.
>
> Change-Id: I13df72e86750c62798bae262f0560cf1d7f981db
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593306
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72078}
Change-Id: I954d7e7487728dbd6a545a6c84efb8f8f65d894d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626979
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72115}
- Changes GetOffsetToReturns to take into account return slot padding
and argument padding.
- Changes GetStackParameterDelta to use GetOffsetToReturns for the SP
delta calculation.
- Removes GetFirstUnusedStackSlot.
Change-Id: I13df72e86750c62798bae262f0560cf1d7f981db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593306
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72078}
LoopExitValue nodes can be used as inputs to Phis in loop optimizations.
To do this, we need to know the machine representation that needs to be
passed to the new Phi node. This CL adds a MachineRepresentation
argument to LoopExitValue nodes, as well as a helper to extract it.
Since the MachineRepresentation is not used by JS compilation, nodes
generated during JS compilation are passed kTagged as a default value.
Change-Id: I925f382d5e6988d8fad3de7a6db231e871d6ed36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2578983
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71798}
Clean up src/wasm and test/
Bug: v8:11074
Change-Id: I1b3d3475a0fbfafe75bb49acfd851f8bd5af5182
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2519183
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71025}
Integer splats (especially for sizes < 32-bits) does not directly
translate to a single instruction on ia32. We can do better for special
values, like 0, which can be lowered to `eor dst dst`. We do this check
in the instruction selector, and emit a special opcode kX64S128Zero.
Also add a unittest to verify this optimization, and necessary
raw-assembler methods for the test.
Bug: v8:11093
Change-Id: Icfebef06a5ecf49619ea54f31a5296094fb53ff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2516300
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71024}
Integer splats (especially for sizes < 32-bits) does not directly
translate to a single instruction on x64. We can do better for special
values, like 0, which can be lowered to `xor dst dst`. We do this check
in the instruction selector, and emit a special opcode kX64S128Zero.
Also change the xor operation for kX64S128Zero from xorps to pxor. This
can help reduce any potential data bypass delay (search for this on
agner's microarchitecture manual for more details.). Since integer
splats are likely to be followed by integer ops, we should remain in the
integer domain, thus use pxor.
For i64x2.splat the codegen goes from:
xorl rdi,rdi
vmovq xmm0,rdi
vmovddup xmm0,xmm0
to:
vpxor xmm0,xmm0,xmm0
Also add a unittest to verify this optimization, and necessary
raw-assembler methods for the test.
Bug: v8:11093
Change-Id: I26b092032b6e672f1d5d26e35d79578ebe591cfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2516299
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70977}
This is a reland of 44f46defcf with a
fix for failures with --turbonci_as_mid_tier
Original change's description:
> [turboprop] Pass required parameters as value inputs to TierUpCheck node
>
> TierUpCheck node tail calls interpreter entry trampoline when additional
> processing is needed for tiering up. Calling IET requires target,
> new_target, input count and context as parameters. Earlier these were
> created as parameter nodes in effect-control-linearizer. This causes
> problems with Turboprop since TurboProp doesn't use the second scheduler
> and cannot reschedule these nodes to the start block. We should instead
> create these parameter nodes in bytecode-graph-builder and pass them
> as value inputs to TierUpCheck node.
>
> Bug: v8:9684
> Change-Id: Icfe5a33b4e628d5a3ba9a3121b2b0746be6aed5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498695
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70790}
Bug: v8:9684
Change-Id: Ic1a7d39aab0a599d0dd421f237e7bc640fcd6eb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504258
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70856}
This is a reland of d7ece57e20 with
a fix to failures on NumFuzz.
Original change's description:
> [turboprop] Add a slot for optimization marker in feedback vector
>
> Optimization marker and the optimized code used to share the same slot
> in the feedback vector as they were mutually exclusive. With turboprop
> we would want to mark the function for tier up to Turbofan while holding
> the optimized code for Turboprop. So this cl uses the existing padding
> field to hold the optimization marker instead.
>
> As a driveby, removes unused JSFunction::ClearOptimizedCodeSlot function
> and fixes a minor bug in Runtime_GetOptimizationStatus.
>
> Bug: v8:9684
> Change-Id: I18c551a69648a0837d16c5453d023c0b295b1521
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467836
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70789}
Bug: v8:9684
Change-Id: Ie6aa3c061a852bb047b5921e4e747d43505568e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502871
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70834}
The value of a node was accessed without prior HasValue check. With
WebAssembly this node is not guaranteed to be a value.
R=mslekova@chromium.org
Change-Id: I62170183f3940a04b0550dfbb78cb49d2f5d7f72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504250
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70833}
This reverts commit d7ece57e20.
Reason for revert: failures on NumFuzz
https://ci.chromium.org/p/v8/builders/ci/V8%20NumFuzz%20-%20debug/11818?
Original change's description:
> [turboprop] Add a slot for optimization marker in feedback vector
>
> Optimization marker and the optimized code used to share the same slot
> in the feedback vector as they were mutually exclusive. With turboprop
> we would want to mark the function for tier up to Turbofan while holding
> the optimized code for Turboprop. So this cl uses the existing padding
> field to hold the optimization marker instead.
>
> As a driveby, removes unused JSFunction::ClearOptimizedCodeSlot function
> and fixes a minor bug in Runtime_GetOptimizationStatus.
>
> Bug: v8:9684
> Change-Id: I18c551a69648a0837d16c5453d023c0b295b1521
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467836
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70789}
TBR=rmcilroy@chromium.org,mythria@chromium.org,jgruber@chromium.org
Change-Id: Ia9894fef713a522b9c3d349bef4abcde3e1e1832
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9684
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502870
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70803}
Optimization marker and the optimized code used to share the same slot
in the feedback vector as they were mutually exclusive. With turboprop
we would want to mark the function for tier up to Turbofan while holding
the optimized code for Turboprop. So this cl uses the existing padding
field to hold the optimization marker instead.
As a driveby, removes unused JSFunction::ClearOptimizedCodeSlot function
and fixes a minor bug in Runtime_GetOptimizationStatus.
Bug: v8:9684
Change-Id: I18c551a69648a0837d16c5453d023c0b295b1521
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467836
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70789}
Currently there are a number of -Wsubobject-linkage warnings when
compiling with gcc (formatted to fit 72 character lines):
In file included from
...
from ../../testing/gtest/include/gtest/gtest.h:10,
from ../../testing/gtest-support.h:8,
from ../../test/unittests/test-utils.h:20,
from ../../test/unittests/compiler/backend/
instruction-selector-unittest.h:15,
from ../../test/unittests/compiler/x64/
instruction-selector-x64-unittest.cc:9:
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:
In instantiation of ‘class
testing::internal::ParameterizedTestFactory<v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test>’:
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:439:12: required from
‘testing::internal::TestFactoryBase*
testing::internal::TestMetaFactory<TestSuite>::CreateTestFactory(
testing::internal::TestMetaFactory<TestSuite>::ParamType)
[with
TestSuite = v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test;
testing::internal::TestMetaFactory<TestSuite>::ParamType =
v8::internal::compiler::{anonymous}::LoadWithToInt64Extension]’
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:438:20: required from here
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:394:7: warning:
‘testing::internal::ParameterizedTestFactory<
v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test >’ has a field
‘testing::internal::ParameterizedTestFactory<
v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test>::parameter_’ whose type uses the
anonymous namespace [-Wsubobject-linkage]
394 | class ParameterizedTestFactory : public TestFactoryBase {
| ^~~~~~~~~~~~~~~~~~~~~~~~
This commit moves the parameterized tests in question into the
anonymous namespace to avoid the warnings.
Change-Id: I9c4a8bd9f4e225ed14ab64f5433d5f5c102e01a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418723
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70482}
Adds support for avoiding spills in non-deferred blocks by instead
restricting the spill ranges to deferred blocks if the virtual
register is only spilled in deferred blocks.
It does this by tracking registers that reach the exit point of deferred
blocks and spilling them them pre-emptively in the deferred block while
treating them as committed from the point of view of the non-deferred
blocks. We also now track whether virtual registers need to be spilled
at their SSA definition point (where they are output by an instruction),
or can instead be spilled at the entry to deferred blocks for use as
spill slots within those deferred blocks. In both cases, the tracking
of these deferred spills is kept as a pending operation until the
allocator confirms that adding these spills will avoid spills in the
non-deferred pathways, to avoid adding unnecessary extra spills in
deferred blocks.
BUG=v8:9684
Change-Id: Ib151e795567f0e4e7f95538415a8cc117d235b64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440603
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70374}
With this change, a load from memory into a register can be replaced by a memory operand for floating point binops if possible.
This eliminates one instruction for following pattern:
vmovss xmm0, m32
vmulss xmm1, xmm1, xmm0
===>
vmulss xmm1, xmm1, m32
Change-Id: I6944287fae3b7756621fb6b3d0b3db9e0beaf080
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411696
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70255}
Control-flow aware allocation has been enabled by default for a long
time now. This removes the unused code paths related to splintering.
R=neis@chromium.org
Bug: v8:10933
Change-Id: I19d9eb448c3912b24a1ad16030e7dd556b13accc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2434328
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70172}
Using associative property of addition: (x + A) + B => x + (A + B).
Note: A and B need to have the same sign and we need to check that
(x + A) isn't used anywhere else.
20% perf improvement of the following function.
function f(n) {
var c = 0;
for (var i = 0; i < n; i++) {
c = c + 2 + 3;
}
return c;
}
for n = 10_000_000.
Before: 7.31s.
After: 6.05s.
Bug: v8:10305
Change-Id: If45d1cad6128a9a25cb9f43a4828ae28d594a84b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2365221
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70064}
... 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}
There exists such optimization for additions but not for multiplication.
This adds optimizations that apply the reductions
(x * Int32Constant(a)) * Int32Constant(b)) => x * Int32Constant(a * b)
(x * Int64Constant(a)) * Int64Constant(b)) => x * Int64Constant(a * b)
to the TurboFan graph.
Bug: v8:10305
Change-Id: I28f72c2b7d8ff0f758a0a08b69fb3763557a6241
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360327
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69462}
Since it will be patched in later in the cases where it will be used,
there is no need to have it as a parameter.
Bug: v8:7790
Change-Id: I93b27f3baf8c3841a60f5ac5ed09993d1caf19bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351667
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69366}
With a displacement of int32_t min (-2^31), and a displacement mode of
kNegativeDisplacement, we will try to negate this constant, but the
result will not fit in an int32_t, leading to a runtime crash.
Check for this special case in CanBeImmediate, and return false.
Bug: chromium:1091892
Change-Id: I7f18153d13805f2836dd5c8e1bc098f1e9600566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2341095
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69311}
This is a reland of 13141c8a65
... with a fix for an UB issue of passing null pointers to memcpy()
when size is zero.
TBR=leszeks@chromium.org
Original change's description:
> [zone-compr] Introduce ZoneTypeTraits and ZoneCompression
>
> Also move zone compression flags to src/common/globals.h.
>
> Bug: v8:9923
> Change-Id: Id0a77720e735e2669a1e5eef48e1b4866ad99480
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324255
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69160}
Bug: v8:9923
Change-Id: I2245b81516c39ccea262c282c659ef601af57abf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332165
Commit-Queue: Igor Sheludko (OOO Aug 3-17) <ishell@chromium.org>
Reviewed-by: Igor Sheludko (OOO Aug 3-17) <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69166}
These are no longer tied to instruction-selector, so move them out into
their own unittests. We can then remove the *ForTesting methods.
Bug: v8:10696
Change-Id: I387cf38290d9602b011ee1d13ee5285ac660f208
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326951
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69149}
Adds unittests that test the fast register allocator correctly deals
with spills of Phi's between their definition and a predecessor block's
gap move to populate the Phi.
BUG=v8:9684
Change-Id: I17263058d5ac29088895ad3de7b3131315ec8fae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299371
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69141}
Adds support for Phis to be allocated to the fast register
allocator. Registers used for Phis are marked specially between
the point where the Phi is defined, and the gap-move's in the
predecessor blocks which populate the Phi value, since if the
Phi is spilled then all predecessor blocks must also spill the
Phi even if they were already allocated.
BUG=v8:9684
Change-Id: Iebe90495b83df655d3335a7d55874123f3b27f8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299366
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69139}
Adds support for populating reference maps to the fast
register allocator. In order to calculate whether a stack slot
is live at a given instruction, we use the dominator tree to
build a bitmap of blocks which are dominated by each block.
A variable's spill operand is classed as alive for any blocks that are
dominated by the block it was defined in, until the instruction index
of the spill operand's last use. As such, it may be classified as live
down a branch where the spill operand is never used, however it is safe
since the spill slot won't be re-allocated until after it's last-use
instruction index in any case.
BUG=v8:9684
Change-Id: I772374599ef916f57d82d468f66429e32c712ddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298008
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69108}
Adds support for tracking the instruction range of spilled operands,
and then allocating spill slots to these ranges. It also adds some
unittests covering spill slot allocation.
Spill slots are allocated in a linear fashion, running through the
instruction stream in a linear order, ensuring that no spill operand
is allocated to a same spill slot that is already assigned to during
this whole start / end range. This isn’t optimal, since it doesn’t
take into account holes in these ranges (e.g, blocks between start
and end that aren’t dominated by the start), but in practice rarely
leads to more than one extra spill slot being allocated compared to
the current allocator.
BUG=v8:9684
Change-Id: Iedee7bcf552080e5b4b6a2f4e96b78b6c1396cab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297470
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69107}
Adds support for register allocation within a block to the fast
register allocator. Also adds some unittests covering basic
register allocation. No support yet for spill slot allocation,
so functions that spill don't work yet.
BUG=v8:9684
Change-Id: I91d0fc0660d7b65f59235242fd5e3b1a7618d813
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297467
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69045}
... that controls whether the TF graph zones should support compression.
Bug: v8:9923
Change-Id: Ifbe237b75e9c92e62eb32b69d6b3b1a818269b83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2308347
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69036}
Design doc:
https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing
V8 can already collect data about how many times each basic block in the
builtins is run. This change enables using that data for profile-guided
optimization. New comments in BUILD.gn describe how to use this feature.
A few implementation details worth mentioning, which aren't covered in
the design doc:
- BasicBlockProfilerData currently contains an array of RPO numbers.
However, this array is always just [0, 1, 2, 3, ...], so this change
removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument
ensures that the removal is valid.
- RPO numbers, while useful for printing data that matches with the
stringified schedule, are not useful for matching profiling data with
blocks that haven't been scheduled yet. This change adds a new array
of block IDs in BasicBlockProfilerData, so that block counters can be
used for PGO.
- Basic block counters need to be written to a file so that they can be
provided to a subsequent run of mksnapshot, but the design doc doesn't
specify the transfer format or what file is used. In this change, I
propose using the existing v8.log file for that purpose. Block count
records look like this:
block,TestLessThanHandler,37,29405
This line indicates that block ID 37 in TestLessThanHandler was run
29405 times. If multiple lines refer to the same block, the reader
adds them all together. I like this format because it's easy to use:
- V8 already has robust logic for creating the log file, naming it to
avoid conflicts in multi-process situations, etc.
- Line order doesn't matter, and interleaved writes from various
logging sources are fine, given that V8 writes each line atomically.
- Combining multiple sources of profiling data is as simple as
concatenating their v8.log files together.
- It is a good idea to avoid making any changes based on profiling data
if the function being compiled doesn't match the one that was
profiled, since it is common to use profiling data downloaded from a
central lab which is updated only periodically. To check whether a
function matches, I propose using a hash of the Graph state right
before scheduling. This might be stricter than necessary, as some
changes to the function might be small enough that the profile data is
still relevant, but I'd rather err on the side of not making incorrect
changes. This hash is also written to the v8.log file, in a line that
looks like this:
builtin_hash,LdaZeroHandler,3387822046
Bug: v8:10470
Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69008}
Adds basic framework to pipeline.cc to enable a seperate fast register
allocator for the TurboProp mid-tier. As part of this, common logic as
well as a base class for RegisterAllocationData is moved to a seperate
register-allocation.h header file. The current register allocator's
RegisterAllocationData is renamed to TopTierRegisterAllocationData, and
the former name is the new base class held in PipelineData.
BUG=v8:9684
Change-Id: I28285b7d6112505bf90e88ea3cda66d03dfabc74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2295359
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68852}
This CL adds functionality to read the source positions directly
from the JS heap rather than from serialized data.
In order to do this, we create a PersistentHandles container in the
OptimizedCompilationInfo which gets passed onto the JSHeapBroker. This
allows us to create the handles in the main thread and pass them safely
to the background thread.
In order to read safely from the background thread, we need a LocalHeap
which blocks the GC from running and potentially moving the handles.
This LocalHeap is created only when the JSHeapBroker has finalized
serializing and destroyed when retiring it.
Bug: v8:7790
Change-Id: I19f8b08d12e5be0a3df34d6af2043310c0c7b6fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2277802
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68836}
... by migrating old-style code
MyObject* obj = new (zone) MyObject(...)
to the new style
MyObject* obj = zone->New<MyObject>(...)
Bug: v8:10689
Change-Id: I55c686bbedfa1fd1955a5927df3f72b366312fd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288867
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68808}
This will allow it to take an OffThreadIsolate in the future, without
requiring GetIsolate on SharedFunctionInfo.
Change-Id: I7db56d5f0587585f829b26e60683c133760d8ff1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282534
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68696}
This is the last batch of operators which used to embed the feedback
vector as a HeapConstant:
- CreateEmptyLiteralArray
- LoadGlobal
- LoadNamed
- StoreDataPropertyInLiteral
- StoreGlobal
- StoreInArrayLiteral
- StoreNamed
- StoreNamedOwn
They now take the vector as an input. In NCI mode, the vector is
loaded from the closure at the beginning of the function.
Bug: v8:8888
Change-Id: Ifd2d2a556db343512b61e099a73702822b1ba9f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282525
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68695}
Prior to this CL, the construct node layout was:
{target, args..., new_target}
The new layout is:
{target, new_target, args..., feedback_vector}
Having new_target at index 1 brings it closer to call node layout,
which is now identical except that it has receiver at index 1. The new
feedback vector input will be needed for NCI code.
Affected node kinds are:
- JSConstruct
- JSConstructWithArrayLike
- JSConstructWithSpread
- JSConstructForwardVarargs (just the new_target position change)
Bug: v8:8888
Change-Id: I4c68a0901d01e8862fd276c8a858799d5f4ff024
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2278475
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68692}
This is likely the major change of the series, as Call nodes are the
focus of call reducer (and to a lesser extent other phases like
inlining).
This CL essentially adds the new input to Call nodes, and updates the
rest of the pipeline. As a (fairly large) drive-by, I also introduce
the JSCallNode wrapper class and apply it in call reducer.
This change, although large, will hopefully make future refactorings
*much* easier, since it is now clear where certain assumptions about
Call node layout are made.
Bug: v8:8888
Change-Id: Ia15fe0ba459b6034863a5815a4e4662cee41fc83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2264353
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68616}
