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}
We are hitting some limits in number of opcodes on ARM64. Try to reduce
it by merging AnyTrue opcodes (from 4 to 1) since the codegen is
identical.
Bug: v8:10930
Change-Id: Ib0bcedbd24d122a4da1ffcb29c1e4b5656fa6ac2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422087
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70063}
The detach CHECK is currently crashing on a non-TypedArray and non-Array
input source to TypedArray#set that detaches the destination TypedArray
in its length getter.
Bug: v8:10885
Change-Id: I80bcb4ffb4e4122afbff5c412623c008dc9509df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419655
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70062}
Strange things happen if we add too many opcodes such that we exceed the
number of bits ArchOpcodeField has, and in some arch (ARM64), we are
only one away from requiring 10 bits (at 0x1ff) now.
Bug: v8:10930
Change-Id: I8dc6b7e0822291f2403db4e4e1dfaf90b9416a8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422843
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70061}
This is to establish a naming rule for Torque-generated files:
- If the file is called foo/bar-tq..., then it is derived from a
file foo/bar.tq
- Otherwise it doesn't belong to a specific .tq file.
So far, we attached -tq to all Torque-generated file names, where it
sometimes corresponded to a .tq file name and sometimes not.
It is not necessary to add -tq to file names to indicate that they are
Torque-generated, since they are already in a directory called
torque-generated, and we always refer to them as
"torque-generated/filename", so there is no confusion even though some
files now have the same name as a corresponding hand-written file, for
example factory.cc.
TBR: hpayer@chromium.org
Bug: v8:7793
Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70060}
It is not allowed to invoke ResetPendingObject() in
MarkCompactCollector::StartMarking(). This method is invoked when
starting incremental marking, at this point the object might not be
initialized.
Bug: v8:10315
Change-Id: I7659855d78fbb28536f57b26e8a7d33c1ba4092e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424267
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70059}
The tests are flaky because of missing safepoint information for stack
checks. Adding the safepoint information there is not trivial though,
so I disable these tests for now to keep at least the bots green.
An alternative would be to revert the CLs that add safepoints in the
first place. However, I would prefer to avoid the overhead that would
be caused by it. The implementation is completely hidden behind a flag,
so it does not have impact on production code.
R=clemensb@chromium.org
Bug: v8:10929
Change-Id: I38c0e3c3806de2cc39ba26bc3b47c2ea8d1cf81a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423705
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70056}
Otherwise concurrent allocation might start incremental marking, which
would then mark the global handle.
Bug: v8:10315
Change-Id: Ibc681b001847a7c52e9fd8a0420e42a0d0ecfbda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424004
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70054}
This flag has no uses in any tests, and it's hard to image a use case
for debugging or similar.
R=ahaas@chromium.org
Bug: v8:10933
Change-Id: I2e96187e4410805824d213e9a9df152b54dd3fb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421825
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70052}
This CL improves the condition that checks all parameters received
from JavaScript when calling an exported WebAssembly function
to determine whether they can be transformed without calls to
built-in functions. The condition is now updated to stop checking
if one parameter that cannot be transformed quickly
is encountered.
Bug: v8:10943
Change-Id: If199aa8d2ffcef86f973c23d9663f8091dfced8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423713
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Vicky Kontoura <vkont@google.com>
Cr-Commit-Position: refs/heads/master@{#70050}
This reverts commit 4a2b2b2e56.
Reason for revert: Speculative revert due to https://ci.chromium.org/p/chromium/builders/try/linux-rel/495075?
Original change's description:
> [Heap]: Marking use Jobs.
>
> StopRequest is removed in favor of:
> COMPLETE_TASKS_FOR_TESTING -> JoinForTesting()
> PREEMPT_TASKS -> Pause()
> COMPLETE_ONGOING_TASKS now has the same behavior as PREEMPT_TASKS
> - we should avoid waiting on the main thread as much as possible.
>
> Change-Id: Icceeb4f0c0fda2ed234b2f26fe308b11410fcfb7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376166
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70037}
TBR=ulan@chromium.org,etiennep@chromium.org
Change-Id: I63f24bffa0f56c6ffa1d1977fc4fb8a76b6f3ba2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423722
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70049}
Choose the page size based on V8_HOST_ARCH_ARM64 (i.e. we're building
an arm64 binary) instead of V8_TARGET_ARCH_ARM64 (i.e. V8's compilers
are emitting arm64 instructions, which is the case in simulator builds
as well).
Drive-by:
- use V8_TARGET_OS_MACOSX instead of __APPLE__
- drop implementation difference between AllocatePageSize and
CommitPageSize on POSIX (they must return the same value anyway)
This continues and obsoletes the work at
https://chromium-review.googlesource.com/c/v8/v8/+/2314102 .
Bug: chromium:1107945, chromium:1128932
Change-Id: Iaaa509dd496ff581ddda4d957bc3d35d806cf81e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421817
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70047}
The actual fix is in LoadIC::ComputeHandler (checking
lookup_start_object == holder instead of receiver == holder) + the
LookupIterator changes for preserving lookup_start_object.
The rest is renaming / refactoring.
Bug: v8:9237, chromium:1127653
Change-Id: Ieef46fb46ababa79623951c48639429c5b552d2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414039
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70045}
StressConcurrentAllocatorTask now checks whether tear down was started
for the isolate to avoid allocation failures.
As a drive-by change remove the unused method
ConcurrentAllocator::PerformCollectionAndAllocateAgain.
Bug: v8:10315
Change-Id: Iba329ebbd782e9f8f11e9b8ec644bf28ab9c80ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423703
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70044}
Added scopes to diallow/allow GCs from happening using a DCHECK. It is
stricter than DisallowHeapAllocation, since this also doesn't allow
safepoints.
As soon as Turbofan is ready, we can replace all usages of
DisallowHeapAllocation with DisallowGarbageCollection.
Bug: v8:10315
Change-Id: I12c144ec099d9af57d692ff343adbe7aec46c0c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362960
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70042}
Building and running tests with v8_enabled_concurrent_marking=false
currently produces two failures:
1) Segmentation fault on attempt to mark a read-only object.
This is fixed by changing MarkBit::Set to be a no-op if the object
is already marked (which is the case for the readonly space).
2) Missing write-barrier due to bogus condition in the bailout.
The barrier can be skipped only if the host object is not marked yet.
This also disables two concurrent allocation tests that rely on
concurrent marking write-barrier.
Bug: v8:10875
Change-Id: Ib3a238fc34c8f20c697470e0bd4ac427fb4bdc0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421816
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70041}
Instantiating a module that contains a function (exported) with a v128
in its signature is fine, but then later calling it will trap.
So v128 values are technically not callable from JS, but we can give it
a default argument of 0, and will later trap anyway. This is useful when
fuzzers generate functions with v128 in the signature of the main
function that we then later try to call.
Bug: chromium:1129068
Change-Id: I93f239a0355b8059e25b8bd5f1274d151d71ee11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2419657
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70038}
StopRequest is removed in favor of:
COMPLETE_TASKS_FOR_TESTING -> JoinForTesting()
PREEMPT_TASKS -> Pause()
COMPLETE_ONGOING_TASKS now has the same behavior as PREEMPT_TASKS
- we should avoid waiting on the main thread as much as possible.
Change-Id: Icceeb4f0c0fda2ed234b2f26fe308b11410fcfb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376166
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70037}
Avoid resetting log flags as this could cause data races with
allocating background threads.
Bug: v8:10315
Change-Id: I7be01ff54e349652f182b944ed3f3366d1239ad7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421814
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70036}
Test was asserting heap size before and after GC. With background
thread allocation those assertions might not hold.
Bug: v8:10315
Change-Id: I4f8c0f6d0b80040b3c89f85e801416abb29ed30e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421999
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70034}
This CL introduces a fast path for transforming JavaScript
parameters to WebAssembly when calling an exported WebAssembly
function from JavaScript.
A transformation is considered fast when it does not require a call
to a built-in function, thus spilling registers for the call can be
avoided.
Bug: v8:10943
Change-Id: I5563bfdf77a68bef7ab8afc6d0f4ab2d2ea67bd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418857
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Vicky Kontoura <vkont@google.com>
Cr-Commit-Position: refs/heads/master@{#70033}
Changes:
- When checking if a table is a function table, check for subtyping to
funcref instead of equality.
- Add WasmModuleObject argument to GetFunctionTableEntry.
- Implement WasmTableObject::Get/Set for all legal table types.
- Factor out SetFunctionTableEntry from WasmTableObject::Set.
- Write unittests and JS tests.
Bug: v8:9495
Change-Id: I4f0c7a7013f17c561afb3039c5e0811634a4d313
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416387
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70032}
Remove the hack introduced in https://crrev.com/c/2412176, use the
existing {ValueTypeToConstantName} function instead.
R=ahaas@chromium.org
Bug: chromium:1127717
Change-Id: I4ac50346825d7b00ea8dadccd7798a273ae84499
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421568
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70028}
Bug: v8:7790
Change-Id: Ibe41dcc3d1717326b8ce7bf3491bf32a8d0882b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2421810
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70027}
Assertions are implemented with the new ASSERTION instruction. The nfa
interpreter evaluates the assertion based on the current context in the
subject string every time a thread executes ASSERTION. This is
analogous to what re2 and rust/regex do.
Alternatives to this approach:
- The interpreter could calculate eagerly for all assertion types
whether they are satisfied whenever the current input position is
advanced. This would make evaluating the ASSERTION instruction itself
cheaper, but at the cost of making every advance in the input string
more expensive. I suspect this would be slower on average because
assertions are not that common that we typically evaluate >= 2
assertions at every input position.
- Assertions in a regexp could be desugared into CONSUME_RANGE
instructions, so that no new instruction would be necessary. For
example, the word boundary assertion \b is satisfied at a given
position/state if we have just consumed a word character and will
consume a non-word character next, or vice-versa. The tricky part
about this is that the assertion itself should not consume input, so
we'd have to split (automaton) states according to whether we've
arrived at them via a word character or not. The current compiler is
not really equipped for this kind of transformation. For {start,end}
of {line,file} assertions, we'd need to introduce dummy characters
indicating start/end of input (say, 0x10000 and 0x10001) which we feed
to the interpreter before respectively after the actual input.
I suspect that this approach wouldn't make much of a difference for
NFA execution. It would likely speed up (lazy) DFA execution though
because assertions would be dealt with in the fast path.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: Ic2012c943e0ce54eb8662789fb3d4c1b6cd8d606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398644
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70026}
Return MaybeHandle directly instead of converting to Handle first and
then back to MaybeHandle.
Bug: v8:10315
Change-Id: I7d0b67ea3931ad4eba48fc58d934d5722ff70905
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418402
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70025}
When a compaction space allocates a new code page, that pages needs to
be added to the Isolate::code_pages_ array used for stack unwinding.
Since the array is owned by the main thread, compaction thread cannot
directly modify it. Because of that code pages are added upon merging
of the compaction space to the main space in MergeLocalSpace.
The bug was that all code pages coming from the compaction space
were added to the code_pages_ array. However, some of the pages are
not newly allocated but merely borrowed from the main space.
This CL keeps track of all newly allocated paged by a compaction space.
Bug: v8:10900
Change-Id: Iff3ff5d608df60fb752d2e0ffc29e51f2d967936
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418718
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70023}
Since the flag is enabled by default, it is more useful to have the
reverse implications so that disabling the flag is guaranteed to work.
Bug: v8:10315
Change-Id: I191c35682442925f3fed691460d074ba6715fc99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2409498
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70022}
That DCHECK could fail even though GC was in the right state. It could
happen that the first load gets the old value NOT_IN_GC, since this
isn't TEAR_DOWN a second load needs to be performed. The load then
returns TEAR_DOWN but that doesn't match NOT_IN_GC either.
Fix this by only loading gc_state() once.
Bug: v8:10315
Change-Id: Ibcad540fa4d5f578c9936c472b294bbccebdc09a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418719
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70021}
For js frame, we want to display currently executing function.
Change-Id: If33b04279dafdf6e4834bfb6c7240e8e7e799fc7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411483
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70018}
