It is possible that we fallback to GenericLowering for minimorphic
property accesses. So handle MinimorphicPropertyAccess in
ShouldUseMegamorphicLoadBuiltin.
Bug: chromium:1223733
Change-Id: Ia1ba8c8786be91dda841d4138cffe81185c066b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2997104
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75505}
We've already been zero-extending 32-bit offset registers since
https://chromium-review.googlesource.com/c/v8/v8/+/2917612,
but that patch only covered the case where offset_imm == 0.
When there is a non-zero offset, we need the same fix.
Bug: chromium:1224882,v8:11809
Change-Id: I1908f735929798f411346807fc4f3c79d8e04362
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2998582
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75500}
Bug: v8:7790, chromium:1225300
Change-Id: I36ae331db0abb072ebc597b4682c3983a00d8a1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999084
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75497}
This will automatically skip the test in the stress_snapshot variant,
where Wasm is not supported.
R=cbruni@chromium.org
Bug: v8:11937
Change-Id: I29078e070a7b1526470e15d8667c5256ea4d8fe1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996642
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75473}
... which didn't properly handle non-Smi integer indices with
JSTypedArray receivers.
The addition of new JSReceiver::OrdinaryDefineOwnProperty() overload
with LookupIterator::Key caused circular dependency between lookup.h
and js-objects.h, so the LookupIterator::Key was moved out of the
LookupIterator class in order to make it forward-declarable.
Bug: chromium:1209405
Change-Id: I265f0c00f65ab6476c8f1d0ca1264f555d43465f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972727
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75326}
This partially reverts https://crrev.com/c/2649032
The previous CL was a bit too aggressive in replaceing movl with Move
which does sign extension for int32.
We can only safely replace movl if the input is in the [0, 2**31] range.
Bug: chromium:1220855
Change-Id: I6c29db1acd7de6b03ffaf802a868b6a531252bc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2975860
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75304}
This isn't used outside of tests, so let's just remove it.
Change-Id: I06b7ec11911fd8ebc3bbabcba16d0c2a3fafddab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968413
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75220}
This also removes intrinsics that were just used in tests. It keeps
InlineIncBlockCounter for now because it's a less straightforward.
Change-Id: I77e55d7a746294892d0fd7ab577ebf8eb42f1f08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953195
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75217}
The PropertyArray may store the hash of it's parent object. This hash
can be installed at various points. Meanwhile, the background compiler
thread inspects the length field.
BUG=chromium:1220974
Change-Id: I7b13fd4546fb48e649fcbf67dee02d7c668393f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967471
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75208}
This failure comes as the feedback is cleared but the CallFeedbackContent field remain unchanged.
Bug: v8:11851
Change-Id: I75a0acad74dcaab1feafe97779e03caa8b7833de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2948426
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75090}
When growing a memory without a maximum, we should still check against
the spec'ed limit, to avoid an overflow when computing the new number of
pages.
R=ahaas@chromium.org
Bug: chromium:1215808
Change-Id: I476b954268277e7dce1106a9b8c3c713b0d1a560
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944433
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74980}
The upper 32 bits of the 64 bit offset register are not guaranteed to be
cleared, so a zero-extension is needed. We already do the zero-extension
in the case of explicit bounds checking, but this should also be done if
the trap handler is enabled.
R=clemensb@chromium.orgCC=jkummerow@chromium.org
Bug: v8:11809
Change-Id: I21e2535c701041d11fa06c176fa683d82db0a3f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917612
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74881}
Bug: chromium:1212583
Change-Id: I6cce7e419b108a0d30cf4d9d9bb0ba304fb0803e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922249
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74864}
There are two different limits for the maximum memory size in
WebAssembly:
1) A 4GB limit which is the same on all platforms, and is observable for
JS programs. It is used to limit the allowed declared maximum size of a
wasm memory.
2) A potentially lower limit (2GB on 32-bit systems, 4GB otherwise)
which can be further limited using a command-line flag. This limit is
used whenever actually allocating or growing a wasm memory. This limit
is not directly observable, but we make sure that no wasm memory will
ever be bigger than this limit.
The second limit is the one we should check against when allocating or
growing memory, while the first limit should be used when validating
a module (or the parameters for WebAssembly.Memory). The compiler can
rely on no memory being bigger than the second limit, which again is
never bigger than the first limit.
This CL adds some more documentation to the two limits, and cleans up
all usages.
This also makes {kPlatformMaxPages} and {kMaxMemoryPagesAtRuntime}
obsolete.
R=jkummerow@chromium.org
Bug: chromium:1207263
Change-Id: I43541aafd3f497d1c368bd9400e9bc667bdfd3d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910787
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74742}
Trimming is required before the Typer phase to ensure that all nodes
that might be reached via use links have been typed.
Add this phase back on the (background thread) OptimizeGraph
step instead of the (main-thread) CreateGraph phase since there
is no need to do it on the main thread.
BUG=chromium:1212244
Change-Id: I136aadb62d623c8f1898e4e9c0441266d5690be6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912709
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74733}
The old code was relying on identical alignment of both the source and
the destination of the Relaxed_Memcpy. This is not always given, thus
check for alignment of both.
R=mlippautz@chromium.org
Bug: chromium:1208782, v8:11704
Change-Id: Ic5dca3a5f0ecaea0df6eb123105520bd7785853c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905611
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74694}
This is the second reland of 4683d6fe52
Initial CL: crrev.com/c/2874663
First reland: crrev.com/c/2886861
The first reland fixes Ref construction failures in:
- MapRef::instance_descriptors
- NativeContext reads (see also crrev.com/c/2891575)
The second reland (this CL):
- Adds required infrastructure (e.g. kAssumeMemoryFence) but
without enabling the IsPendingAllocation check. Enabling the check
will be done separately to avoid further revert chains.
Original change's description:
> [compiler] Consider IsPendingAllocation in Ref construction
>
> The logic in JSHeapBroker::TryGetOrCreateData assumes that parts
> of the object are safe to read. In particular, the instance type
> must be readable for the chain of `Is##Name()` type checks.
>
> This is guaranteed if
>
> - a global memory fence happened after object initialization and
> prior to the read by the compiler; or
> - the object was published through a release store and read through
> an acquire read.
>
> The former is protected by the new call to ObjectMayBeUninitialized
> (which internally calls IsPendingAllocation) in TryGetOrCreateData.
>
> The latter must be marked explicitly by calling the new
> MakeRefAssumeMemoryFence variant.
>
> Note that support in this CL is expected to be incomplete and will
> have to be extended in the future as more cases show up in which
> MakeRef calls must be converted to MakeRefAssumeMemoryFence or to
> TryMakeRef.
>
> Bug: v8:7790,v8:11711
> Change-Id: Ic2f7d9fc46e4bfc3f6bbe42816f73fc5ec174337
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874663
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74474}
Bug: v8:7790,v8:11711,chromium:1207680,chromium:1207679
Change-Id: I123b2962df724a13dd2c7334ae949234bc3bf27a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902738
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74638}
This reverts commit 4683d6fe52.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/36744/overview
Original change's description:
> Reland "[compiler] Consider IsPendingAllocation in Ref construction"
>
> This is a reland of 5f0ac36cc6
>
> Fixes Ref construction failures in:
> - MapRef::instance_descriptors
> - NativeContext reads (see also crrev.com/c/2891575)
>
> Original change's description:
> > [compiler] Consider IsPendingAllocation in Ref construction
> >
> > The logic in JSHeapBroker::TryGetOrCreateData assumes that parts
> > of the object are safe to read. In particular, the instance type
> > must be readable for the chain of `Is##Name()` type checks.
> >
> > This is guaranteed if
> >
> > - a global memory fence happened after object initialization and
> > prior to the read by the compiler; or
> > - the object was published through a release store and read through
> > an acquire read.
> >
> > The former is protected by the new call to ObjectMayBeUninitialized
> > (which internally calls IsPendingAllocation) in TryGetOrCreateData.
> >
> > The latter must be marked explicitly by calling the new
> > MakeRefAssumeMemoryFence variant.
> >
> > Note that support in this CL is expected to be incomplete and will
> > have to be extended in the future as more cases show up in which
> > MakeRef calls must be converted to MakeRefAssumeMemoryFence or to
> > TryMakeRef.
> >
> > Bug: v8:7790,v8:11711
> > Change-Id: Ic2f7d9fc46e4bfc3f6bbe42816f73fc5ec174337
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874663
> > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#74474}
>
> Bug: v8:7790,v8:11711,chromium:1207680,chromium:1207679
> Change-Id: Ib3dbf59909e6982a3230dd6a67c9fb7d6ffb9ab4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2886861
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74587}
Bug: v8:7790
Bug: v8:11711
Bug: chromium:1207680
Bug: chromium:1207679
Change-Id: I8cd45ac006b7b5f3d668d0df272bcba880c75926
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2901990
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74621}
Turns out std::sort() gets angry when various ranges of an array
alias each other in memory. We wouldn't like it when it's angry.
Fixed: chromium:1209152
Change-Id: Ic927b46c59d10f7d3856768628c773b344005979
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897098
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74598}
This is a reland of 5f0ac36cc6
Fixes Ref construction failures in:
- MapRef::instance_descriptors
- NativeContext reads (see also crrev.com/c/2891575)
Original change's description:
> [compiler] Consider IsPendingAllocation in Ref construction
>
> The logic in JSHeapBroker::TryGetOrCreateData assumes that parts
> of the object are safe to read. In particular, the instance type
> must be readable for the chain of `Is##Name()` type checks.
>
> This is guaranteed if
>
> - a global memory fence happened after object initialization and
> prior to the read by the compiler; or
> - the object was published through a release store and read through
> an acquire read.
>
> The former is protected by the new call to ObjectMayBeUninitialized
> (which internally calls IsPendingAllocation) in TryGetOrCreateData.
>
> The latter must be marked explicitly by calling the new
> MakeRefAssumeMemoryFence variant.
>
> Note that support in this CL is expected to be incomplete and will
> have to be extended in the future as more cases show up in which
> MakeRef calls must be converted to MakeRefAssumeMemoryFence or to
> TryMakeRef.
>
> Bug: v8:7790,v8:11711
> Change-Id: Ic2f7d9fc46e4bfc3f6bbe42816f73fc5ec174337
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874663
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74474}
Bug: v8:7790,v8:11711,chromium:1207680,chromium:1207679
Change-Id: Ib3dbf59909e6982a3230dd6a67c9fb7d6ffb9ab4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2886861
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74587}
This also propagates the exception through all the users of
ConvertElementsWithCapacity.
Bug: chromium:1201626
Change-Id: Ie44ba4327a4c3a20f1376477f45d3cd95d0da3b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857961
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74412}
The test takes several minutes on slower bots, so speed it up a bit
without removing the ability to hit the data race.
R=ulan@chromium.org
Bug: chromium:1205290, v8:11741
Change-Id: I57e411bfa2ff2a22bef1a916b74f7684b2f0be17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876855
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74408}
For copying the SharedArrayBuffer content, we cannot use a simple
{memcpy} because that produces data races with thread concurrently
modifying the content. Instead, use a custom {Relaxed_Memcpy} that uses
proper relaxed atomics. The implementation is slightly optimized to do
word-sized loads and stores where possible. If we still get performance
regressions, we can optimize it further in follow-up CLs.
R=ulan@chromium.orgCC=mlippautz@chromium.org
Bug: v8:11704, chromium:1205290
Change-Id: Ie34afc5c22ec5496c0fe822d55d4788031f06c54
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874652
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74403}
As per WebAssembly Web API[1], the engine should only consider names
from the name section to synthesize function names in the context of
call stacks. We previously also added support to harvest the exports
table here in an attempt to improve the DevTools debugging experience,
but that needs a separate fix specifically for the inspector (which
should also take into account the imports to harvest names).
[1]: https://webassembly.github.io/spec/web-api/index.html#conventions
Fixed: chromium:1164305
Change-Id: I4bde5c8398a5164f1d8ac9060ad3743ed494c41e
Bug: chromium:1159307, chromium:1164241, chromium:1071432
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874464
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74382}
We potentially emitted the same gap move multiple times to satisfy slot
constraint of live ranges defined by a constant. Avoid this by keeping
track of already spilled ranges for a given instruction.
This is not expected to cause any regression because this case is rare.
If it does, a better approach to save allocations would be to re-use the
same vector by storing it somewhere that survives the function calls,
e.g. in the ConstraintBuilder.
Drive-by: Remove unused functions.
R=sigurds@chromium.orgCC=nicohartmann@chromium.org
Bug: chromium:1204748
Change-Id: I75a838a8b27775ecdeddb4c60cf72c56d5f1c2a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2871462
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74375}
Element segments and tables in tests used an ad-hoc mechanism to
describe the different types of initializer expressions, e.g. an number
which could denote either the value of a constant or the index of a
global. This CL tidies up and generalizes the test infrastructure by
directly using WasmInitExpr in those cases.
Additional changes:
- Introduce WasmElemSegment class.
- Remove obsolete --experimental-wasm-bulk-memory flag from tests.
- Rename WasmInitExpr.type -> kind.
- Remove dependency of wasm-module-builder from mjsunit.js (except in
assertTraps).
Change-Id: I716254a04ceea9ceb8ac6b848e12e1637f618f0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857638
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74368}
When fast deleting properties generalize all outgoing transitions
to mutable instead of generalizing when property is reconfigured.
Bug: chromium:1201938
Change-Id: I080f2f43de1691a742be2a2bec5cd20d02d78dbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859960
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74334}
Replacing a crash with a TypeError.
Bug: chromium:1203692
Change-Id: I6970f980b46f20033f29c1deb9bc5d49ea2014ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2856842
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74266}
Changes:
- Add WasmInitExpr class which knows how to create initializer
expressions as pairs of {type, value}. Also define a default for every
type. Emit such pairs to a byte array with emit_init_expr().
- Add an initializer expression to every global (addGlobal() uses the
default if the argument is absent).
- Introduce wasmI64Const();
- Update tests as needed.
Change-Id: I75ffe96604891506ad78bd3677ce1efe5e0cee07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2851892
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74231}
We were inconsistent in handling offsets >= 2GB on 32-bit systems. The
code was still relying on this being detected as statically out of
bounds, but with the increase of {kV8MaxWasmMemoryPages} to support 4GB
memories, this is not the case any more.
This CL fixes this by again detecting such situations as statically OOB.
We do not expect to be able to allocate memories of size >2GB on such
systems. If this assumptions turns out to be wrong, we will erroneously
trap. If that happens, we will have to explicitly disallow memories of
such size on 32-bit systems.
R=jkummerow@chromium.org
Bug: v8:7881, chromium:1201340
Change-Id: Ic89a67d38fb860eb8a48a4ff51bc02c53f8a2c2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848467
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74175}
JS-to-Wasm wrappers embed heap constants (like the undefined value), and
those heap values are being accessed during compilation for tracing.
This is not a data race, since those values are read-only. But if the
isolate dies while we are compiling those wrappers, we might read from
the heap after it has been free'd.
Ideally we would not access the isolate or the heap at all during
compilation, but delaying all tracing until the "finalization" phase is
not feasible, and removing the heap value printing from tracing would
significantly regress quality of this tracing.
Hence this CL only fixes the actual issue: That we keep compiling
wrappers when the isolate is already gone. It does so by introducing an
{OperationsBarrier} per isolate that is being taken by each thread that
executes wrapper compilation, and is used for waiting for background
threads to finish before the isolate shuts down.
Additionally, we actually cancel all compilation if a module dies (or
the isolate shuts down) before it finished baseline compilation. In this
state, the module cannot be shared between isolates yet, so it's safe to
fully cancel all compilation. This cancellation is not strictly
necessary, but it will reduce the time we are blocked while waiting for
wrapper compilation to finish (because no new compilation will start).
R=thibaudm@chromium.orgCC=manoskouk@chromium.org
Bug: v8:11626, chromium:1200231
Change-Id: I5b19141d22bd0cb00ba84ffa53fb07cf001e13cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846881
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74142}
After appending 'unimplemented instruction' we need to increase the data
pointer to avoid an endless loop and to fulfill a later DCHECK.
R=jkummerow@chromium.org
Bug: chromium:1201114
Change-Id: I707809f81a4d9a6b3653b94b4836482c006b76ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843819
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74108}
Changes:
- Remove TypeCheckBranchResult. Change TypeCheckBranch() to return bool.
Refactor call sites to reflect this (decouple current code
reachability check from type check).
- Unify TypeCheckBranch(), TypeCheckFallthrough(), and the type-checking
part of Return() into TypeCheckStackAgainstMerge().
- Make sure all TypeCheck* functions are only called within VALIDATE.
- In graph-builder-interface, rename end_env -> merge_env to reflect
its function for loops.
- Change expected error messages in some tests.
Change-Id: I857edc18db9c2454ad12d539ffe7a10e96367710
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839560
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74100}
When the enumerability flag is flipped we need to invalidate the
prototype info.
Bug: chromium:1163499
Change-Id: Iceeaa5fc47eebfe7d333c9eb594bf0763e6cef92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831871
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74013}
The typing of br_table was relaxed in
https://github.com/WebAssembly/spec/pull/1305. Before, we had to compute
the greatest lower bound of all branch types and make sure that stack
values are subtypes of that type. Now, we have to check that the stack
values are subtypes of each individual branch. This makes a difference
only in polymorphic stacks, but greatly simplifies the code, especially
with the upcoming introduction of a much more complex type system in
wasm-gc.
Change-Id: I6e3b410cfe0e71a97623b3030b3575ef707c4900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2827897
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73982}
The existing code assumes that the number of inputs is fixed to 4.
However, the fuzzer says that at least 5 inputs are also possible.
This CL makes the number of inputs more flexible.
CC=sam.parker@arm.com
Bug: chromium:1197393
Change-Id: I487ac96570b96f04b4d0a47065e7b383ba39016f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2821435
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73917}
Lookarounds rewind the position after matching, and thus don't play
well with eats_at_least (EAL). This CL disables EAL propagation from
lookarounds.
In the future we could be a bit smarter by skipping over lookarounds
instead of resetting to 0.
Bug: v8:11290
Change-Id: I935400a7f9cda96d9c5a80e412ba7d04de70a84f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2808944
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73849}
The eats_at_least (EAL) value is applied in forward-directions only.
Two reasons for that which are relevant to this CL:
- EAL's of neighboring nodes are combined additively, irrespective of
their read_backward value.
- EatsAtLeastPropagator::VisitText uses the successor's
eats_at_least_from_not_start value, which doesn't work properly for
read_backwards successors (which may end at the start).
A symptom of this bug was that we applied an incorrect EAL of 255
starting at the initial 'x' of /x(?<=^x{4})/); for subject strings
shorter than 255 chars, this would result in an incorrect failure
result.
Bug: v8:11616
Change-Id: I4b2b1b78f0cea8f59e4beb1037ee46035d83c927
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2807596
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73848}
This fixes a bug introduced in crrev.com/c/2660995.
String.prototype.indexOf must clamp the `position` argument as per
step:
7. Let start be the result of clamping pos between 0 and len.
Source: tc39.es/ecma262/#sec-string.prototype.indexof
Previously, this was done in the StringIndexOf builtin, but the recent
refactor changed builtin implementations to match the spec more
closely (i.e. to clamp in String.prototype.indexOf, not
StringIndexOf). This means we now have to clamp in
JSCallReducer::ReduceStringPrototypeIndexOf.
Tbr: neis@chromium.org
Bug: chromium:1194869
Change-Id: I5af8d41b50f4905453f03079e3ee6d46186536db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2799359
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73772}
This is a reland of e70cbb83da
Moved the ConsString comparison logic out-of-line, both to make gcc
happy, and to reduce the size of the fast-path in IsEqualToImpl.
Original change's description:
> [string] Fix non-SeqStrings in IsEqualTo
>
> Bug: chromium:1193903
> Change-Id: I80704dd3cba5754779432356b20bd3ea99630291
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794426
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73746}
Bug: chromium:1193903
Change-Id: Iae6f078853438427e86d3ac68bcfed0712a85bf7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2797288
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73763}
This CL is part of a series that implements Turbofan support for
property accesses satisfying the following conditions:
1. The holder is a dictionary mode object.
2. The holder is a prototype.
3. The access is a load.
This feature will only be enabled if the build flag
v8_dict_property_const_tracking is set.
This particular CL modifies existing mjsunit tests whose assumptions
don't hold if v8_dict_property_const_tracking is enabled. This is
done by adding special handling for the case that
%IsDictPropertyConstTrackingEnabled() holds.
Bug: v8:11248
Change-Id: Ia36be73e4659a988b2471f0c8151b0442f3a98f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2780292
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73745}
Don't switch to the catch state if it is never reached.
Also steal the catch state instead of splitting it since it cannot be
used after a delegate instruction.
R=ahaas@chromium.org
Bug: chromium:1192313
Change-Id: I3967ac81e066d2146c8aa37b26a35a99ba88bdf6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2787488
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73703}
This is a reland of e3ccb53877
No changes for the reland.
This CL was speculatively reverted, but was not the cause of the problem.
TBR=jgruber@chromium.org
Original change's description:
> Reland "[sparkplug][deoptimizer] Deoptimize to baseline."
>
> This is a reland of bdcd7d79d3
>
> Handle lazy deopts when the current bytecode is JumpLoop.
> Instead of advancing to the next bytecode, re-execute the JumpLoop.
>
> TBR=jgruber@chromium.org, neis@chromium.org
>
> Original change's description:
> > [sparkplug][deoptimizer] Deoptimize to baseline.
> >
> > If we have baseline code, deoptimize to baseline instead of the
> > interpreter. The process is similar to deopting to the interpreter.
> > We just use different builtins
> > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of
> > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that
> > patch an interpreter frame to a baseline frame and continue execution in
> > baseline code (based on the deopt type, at the current or next
> > bytecode).
> >
> > Bug: v8:11420
> > Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591
> > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#73609}
>
> Bug: v8:11420
> Change-Id: Ib8cac028121188ddc23ff29377760ed684eb7392
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783035
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73636}
Bug: v8:11420
Change-Id: I7fbbb73a4fdaeab8b294862ee6ae952928c57994
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784695
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73656}
This reverts commit e3ccb53877.
Reason for revert: Speculative revert for ARM 64 CFI fails - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/5174?
Original change's description:
> Reland "[sparkplug][deoptimizer] Deoptimize to baseline."
>
> This is a reland of bdcd7d79d3
>
> Handle lazy deopts when the current bytecode is JumpLoop.
> Instead of advancing to the next bytecode, re-execute the JumpLoop.
>
> TBR=jgruber@chromium.org, neis@chromium.org
>
> Original change's description:
> > [sparkplug][deoptimizer] Deoptimize to baseline.
> >
> > If we have baseline code, deoptimize to baseline instead of the
> > interpreter. The process is similar to deopting to the interpreter.
> > We just use different builtins
> > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of
> > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that
> > patch an interpreter frame to a baseline frame and continue execution in
> > baseline code (based on the deopt type, at the current or next
> > bytecode).
> >
> > Bug: v8:11420
> > Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591
> > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#73609}
>
> Bug: v8:11420
> Change-Id: Ib8cac028121188ddc23ff29377760ed684eb7392
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783035
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73636}
Bug: v8:11420
Change-Id: Icd797b4979a114a2a627e12c8bb7d2215df03182
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2785074
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73643}
This is a reland of bdcd7d79d3
Handle lazy deopts when the current bytecode is JumpLoop.
Instead of advancing to the next bytecode, re-execute the JumpLoop.
TBR=jgruber@chromium.org, neis@chromium.org
Original change's description:
> [sparkplug][deoptimizer] Deoptimize to baseline.
>
> If we have baseline code, deoptimize to baseline instead of the
> interpreter. The process is similar to deopting to the interpreter.
> We just use different builtins
> (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of
> InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that
> patch an interpreter frame to a baseline frame and continue execution in
> baseline code (based on the deopt type, at the current or next
> bytecode).
>
> Bug: v8:11420
> Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73609}
Bug: v8:11420
Change-Id: Ib8cac028121188ddc23ff29377760ed684eb7392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783035
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73636}
This is a more canonical type name, and is in line with {kVoidCode}.
Change-Id: Iaae9524b6fb6ecaafd63ce81cf30e3d01ca3e525
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2775565
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73557}
The condition can change between VisitBranch and VisitIf, so VisitIf
can't assume that the condition is not yet in the ControlPathConditions
list. Thanks Manos!
Change-Id: Ic74253b6faf2663cfa5212765d81392cb89d73b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773312
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73539}
This is a reland of a3b1233e16
Changes compared to original commit:
- Use a more canonical way to replace TrapIf/Unless nodes that always
trap. This fixes the issue where their outputs were marked dead even
if they were Merge/Loop nodes.
- Use Throw() over Return() to connect a dangling trap to End().
- Add regression test.
Original change's description:
> [turbofan] Optimize TrapIf/Unless in BranchElim. and CommonOp-Reducer
>
> Bug: v8:11510
> Change-Id: I1e8fcb54444e494c7d765ad556d09d954441361f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752876
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73468}
Bug: v8:11510, chromium:1189454
Change-Id: I1d691a3ea299ed668cff925910ed231aad37cac6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2772601
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73537}
Calls with a spread expression in a non-final position get transformed
to calls to Reflect.apply. This transformation is currently done in
the parser, which does not compose well with other features (e.g.
direct eval checking, optional chaining).
Do this transform in the BytecodeGenerator instead.
Bug: v8:11573, v8:11558, v8:5690
Change-Id: I56c90a2036fe5b43e0897c57766f666bf72bc3a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2765783
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73534}
This is a reland of 1a69d8d874
The fix is to skip this regression test on systems that do not
support SIMD.
Original change's description:
> [wasm-simd] Fix i32x4.extadd_pairwise_i16x8_u codegen
>
> It did not handle the case where dst == src. We switch the registers
> used around to write to scratch first and ensure we don't overwrite dst.
>
> Bug: chromium:1187831
> Change-Id: Idf447aa1a3eff3920f2dfa3e0ec11efae37778cd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2762425
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73521}
Bug: chromium:1187831
Change-Id: I1bb6f4ce69f98064d3da5113e3b4c5a4f75a08c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2774133
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73526}
This reverts commit 1a69d8d874.
Reason for revert: Fails on nosse: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/41365/overview
Original change's description:
> [wasm-simd] Fix i32x4.extadd_pairwise_i16x8_u codegen
>
> It did not handle the case where dst == src. We switch the registers
> used around to write to scratch first and ensure we don't overwrite dst.
>
> Bug: chromium:1187831
> Change-Id: Idf447aa1a3eff3920f2dfa3e0ec11efae37778cd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2762425
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73521}
Bug: chromium:1187831
Change-Id: I40d360b16338ef52e7e4327d4166c194ee950827
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773802
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73522}
It did not handle the case where dst == src. We switch the registers
used around to write to scratch first and ensure we don't overwrite dst.
Bug: chromium:1187831
Change-Id: Idf447aa1a3eff3920f2dfa3e0ec11efae37778cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2762425
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73521}
Live ranges defined by a constant operand normally don't require a spill
slot since they can just rematerialize the value from the constant. In
the attached issue however, deoptimization adds an explicit slot
requirement for a range that is defined by a constant operand. This case
is not expected in the register allocator and we eventually hit a
DCHECK.
This fix allocates a new stack slot during the MeetRegisterConstraints
and adds the missing gap move.
Drive-by: remove dead method LiveRange::NextSlotPosition.
R=sigurds@chromium.org
CC=nicohartmann@chromium.org
Bug: chromium:1146880
Change-Id: I08fbb890f2f3d9574196989cf3e5ef6232433484
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563689
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73510}
Throwing an object that needs special property lookup currently traps
when we catch it in wasm. We should just return undefined to let the
caller know that this is not a wasm exception object.
Drive-by: use the named {caught_tag} register consistently.
R=clemensb@chromium.org
Bug: chromium:1188825
Change-Id: I8ebd4db756ac7ba04208ab43c7349c28b813fc49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2767519
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73497}
If the block is unreachable, the interface is not called and the
{try_info} field is not set. Therefore, check it before accessing it.
R=clemensb@chromium.org
Bug: chromium:1188975
Change-Id: Ic6d7d2b7e26b0448143076e25a89c036216e8618
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2767017
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73480}
Processing StateValues into operands is one of the most costly
parts of instruction selection. As it happens, StateValues are
shared by many nodes, and so we are unecessarily reprocessing
the same StateValues multiple times. This CL introduces caching
for the processed StateValues enabling very fast emitting of
operands for subsiquent instructions with the same StateValue.
The hitrate for the cache is higher than 90% on most optimizations.
BUG=v8:9684
Change-Id: I7edcfa1b0d7add16e509f0e2abeda0a8873f5a95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2756535
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73434}
This is done with a script that does something like:
files=$(ag 'v\d\d?x\d\d?[._]?all_?true' -l)
sed -i 's/V\(8x16\|16x8\|32x4\|64x2\)\([._]\?\)\([aA]ll_\?[tT]rue\)/I\1\2\3/g' $(files)
sed -i 's/v\(8x16\|16x8\|32x4\|64x2\)\([._]\?\)\([aA]ll_\?[tT]rue\)/i\1\2\3/g' $(files)
And manual fixups in test-run-wasm-simd.cc and wasm-opcodes-inl.h.
Bug: v8:10946
Change-Id: Ib5dad388dd6dd9cd0fb575ad961dffc189a2e6ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2740488
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73309}
Instead of using addresses of prototype and constructor (which can be
movedby GC) when computing the hash of a Map, we use the addresses of the
prototype map (which won't be compacted).
The prototype map is in a 1:1 relation with the prototype.
In addition the prototype points to the constructor in most cases.
Bug: v8:11519
Change-Id: Ibc47e5870955d7721509be07fae7719a93da9a26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739646
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73286}
... where TF doesn't see that the property is deleted and re-added.
Bug: chromium:1161847
Change-Id: I599a25fa8d29154b5bfede45f6655a1eac44a0f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739592
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73280}
- Adds some missing types, to appease the fuzzers.
Bug: chromium:1185464
Change-Id: I08c4ebe5f4ae0d036da9819b805aeac93be384fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742017
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73279}
Before dropping a value we should validate that there is indeed a value
on the stack.
R=jkummerow@chromium.org
Bug: chromium:1184964
Change-Id: Iec3ac061df2545717749e664b10c383765d67c9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739588
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73263}
The recent change crrev.com/c/2712755 got a bounds check wrong,
causing an invalid use of the lookup iterator.
Bug: v8:1185072
Change-Id: I3138d266cb4b2482dcb5078fb025bbfc43dd2940
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742196
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73250}
... to different attributes or different property kind.
Bug: chromium:1161847, v8:9233
Change-Id: I5a6e1e012c6afcf09ed9da6bbf9f33c1007c3d99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727272
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73220}
For adding stack checks in optimized code, we compute a conservative
estimate of the frame size in the case of a deoptimization. Earlier we
included the size of arguments adaptor frames used when actual arguments
didn't match formal parameter count. Though we don't have an explicit
adaptor frame, we should still include the size of these additional
arguments when computing the frame size.
Bug: chromium:1181240
Change-Id: Ib977c5492bb824762fe62aac5e4ffb1c2c233b86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2723252
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73094}
Fixes a problem with the inlining of JS-to-Wasm call wrappers into a
surrounding exception handler and re-enables this case.
Bug: v8:11092
Change-Id: I4937838c2b4a199e21f5ac90bee5b8e8de2470be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2678341
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73086}
The flag should not be set after an exception is thrown in a runtime
function. The unwinder still runs after the destructor, and should take
care of setting the flag depending on the catching frame.
R=ahaas@chromium.org,jkummerow@chromium.org
Bug: chromium:1180690
Change-Id: I0013c90f759a5145309f6e08d61ed36aeecbac63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713103
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72972}
After the runtime call for dynamic tiering, the instance cache is
invalidated. This was assumed to be done in {SpillAllRegisters}, but the
instance is still being accessed after that call, so the instance cache
register might still be set after the runtime call.
R=ahaas@chromium.org
Bug: chromium:1179065
Change-Id: I375e7c388e5a74789050e374db50d21c2efe27e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2714544
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72958}
.. which can return Undefined if reading out of bounds, so the return
type is ObjectRef and not StringRef (if we had torque-like union types
it'd be StringRef|OddballRef). Also change the function name to
GetCharAsStringOrUndefined.
Bug: v8:7790,chromium:1181246
Change-Id: Icf9e8fd03d11c3936e87a509b9117e547972d283
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712965
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72952}
Also fixes existing tests which were asserting the wrong behavior (that
setting writable=false won't have an effect).
The bug was introduced by https://chromium-review.googlesource.com/c/v8/v8/+/1442640 .
Bug: chromium:1158138
Change-Id: I2d85721848eb4e7d530a980a9ecef7f8693bb9a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2691050
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72948}
This moves all tests that construct a wasm module (and load
wasm-module-builder.js) from test/regress to the test/regress/wasm
directory. This will make it easier to skip them all in the
v8_enable_webassembly=false configuration.
R=ahaas@chromium.org
Bug: v8:11238
Change-Id: Ib22b0fb40a58f213182e68b78b34041651c436d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712243
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72942}
This is a reland of 76a2ab06a1
Changes since the original CL:
- Handle unserialized elements (optional result in getter).
- Merge should_access_heap and --turbo-direct-heap-access paths.
- Slightly update the serialized path in GetOwnCowElement.
- Fix the cctest, add a regression test.
Atomic JSObject::elements/JSArray::length setters are addressed
in this CL: crrev.com/c/2704076.
Original change's description:
> [compiler] Direct heap reads for JSArrayRef
>
> There are two aspects to the non-JSObject parts of JSArrayRef:
>
> - JSArrayRef::length. Relevant only in two spots, 1. when reading
> (immutable) array boilerplates and 2. for GetOwnCowElement.
>
> - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
> store. Relies on the invariant that cow backing stores are immutable.
>
> This CL renames the length accessor to length_unsafe to make the
> danger explicit at callsites.
>
> For GetOwnCowElement the refactor is slightly larger, since we now
> need to read into the backing store while keeping full control of
> object reads (e.g. JSArray::length and JSArray::elements_kind). We
> make all reads explicit at the call site by requiring that elements,
> elements kind, and length are passed in as arguments to
> GetOwnCowElement. Inside GetOwnCowElement, consistency between these
> is *not* guaranteed due to concurrency. At runtime, consistency *is*
> guaranteed through the reference-equality check on the elements seen
> during compilation. The actual elements read is implemented in
> ConcurrentLookupIterator::GetOwnCowElement.
>
> Bug: v8:7790
> Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72834}
Bug: v8:7790
Change-Id: I7577ad554992cafff81099a28c34f27db9bd8042
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710431
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72904}
This moves all asm.js tests (tests that use "%IsAsmWasmCode") into a
separate directory. This will make it easier to skip them all in the
v8_enable_webassembly=false configuration.
R=ahaas@chromium.org
Bug: v8:11238
Change-Id: I805f222b7977f5508f7dbee1f1bd61a88ccd34aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710427
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72900}
We always built a new Phi node for the delegate merge, which is
incorrect when the target block's exception is already a Phi. Use
CreateOrMergeIntoPhi instead.
R=clemensb@chromium.org
Bug: v8:11472
Change-Id: I8af3ab07d536ddfe247ace04cc844207d32adb99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707167
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72874}
This is the first part of exception handling support in Liftoff. For
now, the only supported instruction is throw, and only with empty
payload or only i32 values.
R=thibaudm@chromium.org
Bug: v8:11453
Change-Id: I9fdf1328ef46655674a05186fb93216518886d03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704659
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72871}
In {MergeFullStackWith}, we were accidentally looking at the cached
instance in the current {cache_state_} instead of the state passed as
{source}. This could lead to missing reload of the instance after a
conditional branch.
R=thibaudm@chromium.org
Bug: chromium:1179182
Change-Id: Ida3c06491f7973a183c43745159abbf6aa8a058b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704081
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72864}
Pinned registers were not considered correctly when taking a volatile
register. This CL refactors handling of the pinned registers list by
combining the candidates list and the pinned list early. This avoid
additional parameters on some functions and might save some redundant
masking.
As a side effect, it also fixes the DCHECK error on arm.
R=ahaas@chromium.org
Bug: chromium:1179025
Change-Id: Ib9193b209c5741ea97fd1d0dffeeb9e824639439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699254
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72812}
The expected exception in this regression test is thrown due to a
limitation in the IrRegExp engine.
The experimental engine is unaffected and won't throw.
Bug: v8:11363
Change-Id: If37d86f5d4494b40c47ecc5e5bc4f86fda30389c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699251
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72806}
This reverts commit 87df0b7ecc (thus
relands 42cd9eb78d), with fixes for
the discovered issues.
Original change's description:
> Revert "[compiler] Directly read PropertyCells"
>
> This reverts commit 42cd9eb78d.
>
> Reason for revert: Clusterfuzz issues, e.g.
> https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
>
> Original change's description:
> > [compiler] Directly read PropertyCells
> >
> > Main changes:
> >
> > - Introduce a new broker data kind kBackgroundSerialized for objects
> > that can be serialized in the background (when direct reads are on).
> > (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
> > in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
> > - Make PropertyCell use that new kind.
> > - Introduce a bottleneck in runtime code for changes to PropertyCells
> > and make sure that a certain protocol is followed that allows
> > concurrent reads from the background thread.
> > - Improve interface of PropertyCell in various ways.
> >
> > Bug: v8:7790
> > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#72586}
>
> TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
>
> Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
> Bug: v8:7790
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72619}
Bug: v8:7790, chromium:1176509, chromium:1176318, chromium:1176504
Change-Id: Icaf285912bb948432a4a2d599cd174f6a5aa296e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685166
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72697}
Currently %OptimizeFunctionOnNextCall returns if there is the function
is already optimized. This cl changes this function to allow tiering up
till we reach top tier. That allows us to tier up from Turboprop to
Turbofan using intrinsics. This cl also introduces a runtime-test
function to check if turboprop-as-toptier or turboprop-as-midtier is
enabled.
Bug: chromium:1172797, v8:9684
Change-Id: Idbd99b816d4b93e4e619be5d4ccdfe89fc561a9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682638
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72668}
V8 implements a fast-path for RegExp.prototype.split which diverges
from the spec: instead of creating a new sticky regexp instance
`splitter` and running it in a loop, we reuse the existing non-sticky
regexp without looping through each character.
This works fine in most cases, but we run into issues when matching at
the very end of the string. According to the spec, matches at the end
of the string are impossible in @@split, but in our fast-path
implementation they can happen.
The obvious fix would be to remove our fast-path but this comes with
high performance costs. The fix implemented in this CL adds a special
flag to `exec` s.t. matches at the end of the string can be treated as
failures. This is only relevant for @@split.
Bug: chromium:1075514
Change-Id: Ifb790ed116793998d7aeb37e307f3f3f764023d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681950
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72644}
The is_awaiting bit on async generators distinguishes waiting on an
await. When the async generator resumes from an await, the is_awaiting
bit is cleared.
It is possible through overriding Promise#constructor that `await`
throws *after* setting is_awaiting. There is an implicit try-catch
around the body of the async generator such that, usually, caught
exceptions would clear the is_awaiting bit. However, the exception
thrown from a monkeypatched Promise#constructor can be caught by script,
and thus never clear the is_awaiting bit.
This CL sets the is_awaiting bit *after* `await` completes, with the
exception of the return resumption. It is not possible to have the
exception thrown by the await in the return resumption be caught by
script.
Bug: chromium:1171667
Change-Id: I0b615617a5c949f03350ab0f06c42920d43b5488
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659508
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72593}
Turboprop doesn't use optimizations based on field constness to reduce
the number of deoptimizations. While this is safe for loads, for stores
if a different value is stored to a const field we should update the
constness of the field. This is needed so we can safely deopt any other
code that is relying on the constness of the field. Currently, turboprop
doesn't do this. So for now treat stores to constant fields similar to
TurboFan. In future, we may consider adding code to update the field
constness if necessary to reduce the number of deoptimizations.
Bug: chromium:1172797, v8:9684
Change-Id: I1d660457cb5d647e1283a495040a7e452fe1ac7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673401
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72590}
This is a reland of 6ada6a90ee
- Fixed a GC issue
https://bugs.chromium.org/p/v8/issues/detail?id=11335:
GC expected all arguments on the stack from code with
CodeKind::TURBOFAN to be tagged objects. This is not the case now with
inlined Wasm calls, and this information can be passed in
SafepointEntry for each call site.
- Disabled JS-to-Wasm inlining for calls inside try/catch.
For more details, see updated doc:
https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
Bug: v8:11092
Original change's description:
> Reland "Faster JS-to-Wasm calls"
>
> This is a reland of 860fcb1bd2
>
> - Disabled the tests for this feature in V8-lite mode (the original
> change broke V8-lite tests).
> - Also modified test console-profile-wasm.js that was brittle with this
> change because it assumed that there was always a JS-to-Wasm wrapper
> but this is not the case when the TurboFan compilation completes before
> the Liftoff-compiled code starts to run.
>
> More changes in Patchset 8:
>
> - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
> into a new phase, wasm-inlining that reuses the JSInliner reducer.
> The doc
> https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
> describes the new logic.
>
> - Fixed a couple of small issues in wasm_compiler.cc to make sure that
> the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
> this should solve the problem we had inlining the calls in functions
> that can throw exception.
Original change's description:
> Faster JS-to-Wasm calls
>
> This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
>
> Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> the basis of the signature of a Wasm function to call, and whose task
> is to:
> - set "thread_in_wasm_flag" to true
> - convert the arguments from tagged types into Wasm native types
> - calculate the address of the Wasm function to call and call it
> - convert back the result from Wasm native types into tagged types
> - reset "thread_in_wasm_flag" to false.
>
> This CL tries to improve the performance of JS-to-Wasm calls by
> inlining the code of the JS-to-Wasm wrappers in the call site.
>
> It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> this kind of calls. A 'JSWasmCall' node is associated to
> WasmCallParameters, which contain information about the signature of
> the Wasm function to call.
>
> WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid
> generating code to convert the types for the arguments
> of the Wasm function, when the conversion is not necessary.
> The actual inlining of the graph generated for this wrapper happens in
> the simplified-lowering phase.
>
> A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> lazy deoptimizations that can happen if the Wasm function callee calls
> back some JS code that invalidates the compiled JS caller function.
>
Bug: v8:11092
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72541}
In the latest spec, catch_all is encoded as 0x05. This is the same
opcode as "else", but they do not conflict because "else" is not valid
in the context of a try block.
The 0x0a opcode now corresponds to the "unwind" instruction, which
currently has the same semantics as "catch_all".
R=clemensb@chromium.org
Bug: v8:11392
Change-Id: Ie9cd06c9a2001a02d8bea5be7a3c016e3a58ee3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2674007
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72531}
For dictionary mode objects, whether or not a property is constant was
not tracked before. This CL makes the required non-Turbofan changes,
guarded behind the new flag V8_DICT_PROPERTY_CONST_TRACKING.
In addition, prototypes are not converted to fast mode objects if this
flags is enabled.
Bug: v8:11247
Change-Id: Ia5942733239a97560b6efc015f0e25a35fea3d7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566757
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72524}
When constant-folding the test based on static types in the function
body decoder, we have to ensure Liftoff's value stack is properly
updated.
Fixed: chromium:1172912
Change-Id: I618992608882b850a8a4bce0b267ce456e4c2a40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664447
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72482}
Optional chain checks check if the object is null or undefined and
if it is we don't perform the load but just load accumulator with
undefined. For calls the value of the accumulator needs to be stored
in the callee register. We were doing this only when the object
isn't null or undefined. This cl fixes it by storing it to callee
always.
Bug: chromium:1171954
Change-Id: I391af18e783486fed70be561027bd8aba97b93cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2665466
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72475}
This is a reland of commit 9c09c227b0.
The fix for gc stress failure is merged: https://crrev.com/c/2656857.
Original change's description:
> Bug: v8:11331
> Change-Id: Ie394ec841a1a1c4030c4f589eac2cee8a6a2a1f9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639033
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72304}
Bug: v8:11331
Change-Id: I82f57b3fe5f0c456472aa7ce404703f34b73d17e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659511
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72465}
Fix 1: Track Scope::needs_home_object and Scope::uses_super_property
accurately. When "eval" is seen, figure out whether it can access
"super" and if yes, set the corresponding home object as needed.
Fix 2: The object literal scope shouldn't be entered for things
inside spreads.
Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
This saves memory (the home object doesn't need to be stored for each
method, but only once per class) and hopefully makes the home object
a constant in the optimized code.
Detailed documentation of the changes:
https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
Bug: v8:9237
Bug: chromium:1167918
Bug: chromium:1167981
Bug: chromium:1167988
Bug: chromium:1168055
Bug: chromium:1171195
Bug: chromium:1171600
Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72422}
This reverts commit f6450b97ec.
Reason for revert: ClusterFuzz bugs
Original change's description:
> Reland [super] Store home object in Context instead of JSFunction
>
> 1) Computed property keys (esp functions in them) shouldn't be inside
> the object literal scope.
>
> 2) I was using an imprecise "maybe uses super" and storing it to
> preparse data. This won't fly, since it pollutes sister scopes and
> leads to confusion wrt whether an object literal needs a home object
> or not. Made it precise (mostly cancelling changes in the original CL).
>
> 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
> this_function (which made it used) -> inconsistent scopes between
> parsing and preparsing.
>
> 4) MultipleEntryBlockContextScope was messing up the accumulator
>
> Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
>
> This saves memory (the home object doesn't need to be stored for each
> method, but only once per class) and hopefully makes the home object
> a constant in the optimized code.
>
> Detailed documentation of the changes:
> https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
>
> Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
> Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72169}
TBR=marja@chromium.org,leszeks@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9237
Bug: chromium:1167918
Bug: chromium:1167981
Bug: chromium:1167988
Bug: chromium:1168055
Bug: chromium:1171195
Bug: chromium:1171600
Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72391}
Instead of updating the detected features set directly, use the
synchronized {OnCompilationStopped} method.
In order to avoid this error in the future, the whole
{detected_features()} getter is removed, as it returns a pointer which
can only be accessed when holding the mutex anyway. Also, the refactored
code was the only user of this dangerous method.
Drive-by: Pass the WasmFeatures set by value, since it's just an
EnumSet.
Drive-by 2: Remove a print line from the regression test which can be
confusing if the test is picked up again by foozzie.
R=ahaas@chromium.orgCC=zhin@chromium.org
Bug: v8:11357
Change-Id: I75b5c8f35983d2bc1fd2b61adcb2ecfc18564f39
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653226
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72375}
Bug: chromium:1170261
Change-Id: Id2c5d18df892ece2823f7784dee4e69e54b7454c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652491
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72368}
This reverts commit 9c09c227b0.
Reason for revert: gc stress failures https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress/20563/overview
Original change's description:
> [wasm-simd] Merge all any_true to v128.any_true
>
> In https://github.com/WebAssembly/simd/pull/423, all any_true
> instructions were removed, and replaced with a single v128.any_true.
>
> This patch removes all but v8x16.any_true, and renames it to
> v128.any_true.
>
> Bug: v8:11331
> Change-Id: Ie394ec841a1a1c4030c4f589eac2cee8a6a2a1f9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639033
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72304}
TBR=neis@chromium.org,gdeepti@chromium.org,neis@google.com,zhin@chromium.org
Change-Id: I52dbf8de679059dd7b17908c1fe3ada0eb54ff84
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11331
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649240
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72305}
In https://github.com/WebAssembly/simd/pull/423, all any_true
instructions were removed, and replaced with a single v128.any_true.
This patch removes all but v8x16.any_true, and renames it to
v128.any_true.
Bug: v8:11331
Change-Id: Ie394ec841a1a1c4030c4f589eac2cee8a6a2a1f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639033
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72304}
This reverts commit 6ada6a90ee.
Reason for revert: Revert for link issue:
https://bugs.chromium.org/p/v8/issues/detail?id=11335
Original change's description:
> Reland "Faster JS-to-Wasm calls"
>
> This is a reland of 860fcb1bd2
>
> - Disabled the tests for this feature in V8-lite mode (the original
> change broke V8-lite tests)
> - Also modified test console-profile-wasm.js that was brittle with this
> change because it assumed that there was always a JS-to-Wasm wrapper
> but this is not the case when the TurboFan compilation completes before
> the Liftoff-compiled code starts to run.
>
> More changes in Patchset 8:
>
> - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
> into a new phase, wasm-inlining that reuses the JSInliner reducer.
> The doc
> https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
> describes the new logic.
>
> - Fixed a couple of small issues in wasm_compiler.cc to make sure that
> the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
> this should solve the problem we had inlining the calls in functions
> that can throw exception.
>
>
> Original change's description:
> > Faster JS-to-Wasm calls
> >
> > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
> >
> > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> > the basis of the signature of a Wasm function to call, and whose task
> > is to:
> > - set "thread_in_wasm_flag" to true
> > - convert the arguments from tagged types into Wasm native types
> > - calculate the address of the Wasm function to call and call it
> > - convert back the result from Wasm native types into tagged types
> > - reset "thread_in_wasm_flag" to false.
> >
> > This CL tries to improve the performance of JS-to-Wasm calls by
> > inlining the code of the JS-to-Wasm wrappers in the call site.
> >
> > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> > this kind of calls. A 'JSWasmCall' node is associated to
> > WasmCallParameters, which contain information about the signature of
> > the Wasm function to call.
> >
> > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
> > of the Wasm function, when the conversion is not necessary.
> > The actual inlining of the graph generated for this wrapper happens in
> > the simplified-lowering phase.
> >
> > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> > lazy deoptimizations that can happen if the Wasm function callee calls
> > back some JS code that invalidates the compiled JS caller function.
> >
> > Bug: v8:11092
> > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> > Cr-Commit-Position: refs/heads/master@{#71824}
>
> Bug: v8:11092
> Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
> Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72147}
Tbr: ahaas@chromium.org, jgruber@chromium.org
Bug: v8:11092, v8:11335
Change-Id: Iab2908928dfe7ea353f70cb5d3bf2de4d3074db6
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644758
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72253}
On x64, reference types where not handled yet in LiftoffAssembler::push.
Note that the values pushed on the stack there do not have to be
handled by a safepoint. The reason is that stack parameters in general
are handled separately from safepoints.
R=thibaudm@chromium.org
Bug: chromium:1168116
Change-Id: Ie62479c13839f0ba240d0e41fa76d07a2cc48881
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642263
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72252}
It acquires the string lock to avoid race conditions. It does so in a
slow way (by getting the isolate from the string) to avoid piping the
Isolate through.
Bug: v8:7790, chromium:1166095
Change-Id: I8b769b4e96ee780314359d1d15d712012aade88a
Fix: chromium:1166095
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637861
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72236}
Previously ShouldHaveBeenSerialized() would return false for
kPossiblyBackgroundSerializedHeapObject objects which prevented
checks for whether the correct serialization had been done before
accessing Map::prototype() for these ObjectRefs.
BUG=chromium:1168435,v8:7790,v8:9684
Change-Id: I31b4cf7c7ce67ba1c46aea1451172b279d215508
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640479
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72215}
The inlining of JS-to-Wasm wrappers can fail inside try/catch because
the IR built by WasmWrapperGraphBuilder::BuildJSToWasmWrapper does not
always set the correct control outputs in the call node.
This patch disables inlining inside try/catch to work around this issue.
Bug: chromium:1168386
Change-Id: I1b43bdb044b38d95c2d309290e228a86ba1513a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639927
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72191}
The bytecode offset (previously 'bailout id') was referred to as 'ast
id', 'node id', 'bailout id' in different spots. And 'bailout id' was
used to refer to deoptimization exits. This CL makes used terms more
consistent.
Bug: v8:11332
Change-Id: I2b34c7d4ebf465939e18fdfba675d83852f2430a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639756
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72190}
This is a reland of 8703c38d9a
The reland marks the new test as slow, skips all variants, and
skips all non-release modes.
Original change's description:
> [compiler] Emit a function-entry stack check on OSR-entry
>
> This CL extends the smarter function-entry stack check logic (see
> v8:9534) to OSR'd code. These smarter stack checks prevent
> overflowing the stack during deoptimization.
>
> The challenge for both function-entry (FE) and OSR-entry (OE) stack
> checks is that there is no dedicated physical StackCheck to
> deoptimize into. For more context: the physical StackCheck bytecode
> was removed in crrev.com/c/1914218.
>
> FE stack checks solve this by using a marker bailout id to signify
> a deopt bytecode offset before the first bytecode.
>
> In this CL, OE stack checks take a similar approach by using the
> OSR'd loop's JumpLoop bytecode, which is conceptually immediately
> before the OSR'd loop header.
>
> When a stack overflow at an OE stack check occurs: %StackGuard
> may cause a lazy deopt on return to the optimized OSR code,
> causing re-execution of the JumpLoop handler in the
> InterpreterEnterBytecodeAdvance builtin, ultimately continuing
> execution the interpreter at the first bytecode of the OSR'd loop
> header.
>
> Bug: chromium:1034322, v8:9534
> Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72153}
Tbr: neis@chromium.org, solanes@chromium.org
Bug: chromium:1034322
Bug: v8:9534
Change-Id: I28a23d0cc4b14d59c3d4a5dbadd5dab3ac31d442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639753
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72183}
1) Computed property keys (esp functions in them) shouldn't be inside
the object literal scope.
2) I was using an imprecise "maybe uses super" and storing it to
preparse data. This won't fly, since it pollutes sister scopes and
leads to confusion wrt whether an object literal needs a home object
or not. Made it precise (mostly cancelling changes in the original CL).
3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
this_function (which made it used) -> inconsistent scopes between
parsing and preparsing.
4) MultipleEntryBlockContextScope was messing up the accumulator
Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
This saves memory (the home object doesn't need to be stored for each
method, but only once per class) and hopefully makes the home object
a constant in the optimized code.
Detailed documentation of the changes:
https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72169}
This reverts commit 8703c38d9a.
Reason for revert: New test is timing out on gc-stress (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/31726/overview)
Original change's description:
> [compiler] Emit a function-entry stack check on OSR-entry
>
> This CL extends the smarter function-entry stack check logic (see
> v8:9534) to OSR'd code. These smarter stack checks prevent
> overflowing the stack during deoptimization.
>
> The challenge for both function-entry (FE) and OSR-entry (OE) stack
> checks is that there is no dedicated physical StackCheck to
> deoptimize into. For more context: the physical StackCheck bytecode
> was removed in crrev.com/c/1914218.
>
> FE stack checks solve this by using a marker bailout id to signify
> a deopt bytecode offset before the first bytecode.
>
> In this CL, OE stack checks take a similar approach by using the
> OSR'd loop's JumpLoop bytecode, which is conceptually immediately
> before the OSR'd loop header.
>
> When a stack overflow at an OE stack check occurs: %StackGuard
> may cause a lazy deopt on return to the optimized OSR code,
> causing re-execution of the JumpLoop handler in the
> InterpreterEnterBytecodeAdvance builtin, ultimately continuing
> execution the interpreter at the first bytecode of the OSR'd loop
> header.
>
> Bug: chromium:1034322, v8:9534
> Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72153}
TBR=neis@chromium.org,jgruber@chromium.org,solanes@chromium.org
Change-Id: Ie72f2e2927ffa83d595aad0d88c606d422f953a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1034322
Bug: v8:9534
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637858
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72158}
This CL extends the smarter function-entry stack check logic (see
v8:9534) to OSR'd code. These smarter stack checks prevent
overflowing the stack during deoptimization.
The challenge for both function-entry (FE) and OSR-entry (OE) stack
checks is that there is no dedicated physical StackCheck to
deoptimize into. For more context: the physical StackCheck bytecode
was removed in crrev.com/c/1914218.
FE stack checks solve this by using a marker bailout id to signify
a deopt bytecode offset before the first bytecode.
In this CL, OE stack checks take a similar approach by using the
OSR'd loop's JumpLoop bytecode, which is conceptually immediately
before the OSR'd loop header.
When a stack overflow at an OE stack check occurs: %StackGuard
may cause a lazy deopt on return to the optimized OSR code,
causing re-execution of the JumpLoop handler in the
InterpreterEnterBytecodeAdvance builtin, ultimately continuing
execution the interpreter at the first bytecode of the OSR'd loop
header.
Bug: chromium:1034322, v8:9534
Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72153}
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}
StateValuesAccess iterates over actual (non-adapted) arguments, thus
we must be careful not to iterate past their end when handling rest
args and advancing through the initial non-rest-args.
Tbr: neis@chromium.org
Bug: chromium:1167709,chromium:1166136
Change-Id: If506050a5518f394e0dcdbf39840b99923d4cbae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637213
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72145}
FrameState parameters must not be iterated directly since parameters
can be encoded into StateValues (i.e. parameter i is not necessarily
InputAt(i)). Instead, they should be accessed through the
StateValuesAccess helper class.
One example:
82: StateValues[sparse:^^^^^^](81, 31, 32, 33, 34, 35)
81: StateValues[sparse:^^^^^^^^](110, 24, 25, 26, 27, 28, 29, 30)
31: NumberConstant[8]
32: NumberConstant[9]
33: NumberConstant[10]
34: NumberConstant[11]
35: NumberConstant[13]
Here, node 81 holds multiple parameters. These are properly iterated
by the StateValuesAccess class.
Bug: chromium:1166136
Change-Id: I12725f83994e1c05571bcba153ff45154b16d93f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625879
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72126}
Exception ref is not part of the latest exception handling
proposal. Remove the corresponding value type, the type opcode and some
obsolete tests.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: I5e068ba3426f4b56b90ef056193acdd8cc8fe7d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632599
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72116}
Offsets in regular expressions are limited to 16 bits.
It was possible to exceed this limit when emitting greedy loops where
the length of text nodes exceeded 16 bits, resulting in overflowing
offsets.
With this CL we throw a SyntaxError "Regular expression too large" to
prevent this overflow.
Bug: chromium:1166138
Change-Id: Ica624a243bf9827083ff883d9a976f13c8da02e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629286
Commit-Queue: Patrick Thier <pthier@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72095}
This is a reland of 164cf80bbb
The reland fixes UB (left-shift of negative integer type) with a
static_cast<uint32_t>.
Original change's description:
> [regexp] Hard-crash on invalid offsets in AdvanceCurrentPosition
>
> Drive-by: Range checks in `Emit(byte, twenty_four_bits)` to ensure the
> given packed bits actually fit into 24 bits.
>
> Bug: chromium:1166138
> Change-Id: I2e711e6466bb48d7b9897f68dfe621d12bd92508
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625877
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72064}
Tbr: leszeks@chromium.org
Bug: chromium:1166138
Change-Id: I514495e14bb99dfc9588fdb4a9f35d67d8d64acb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626663
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72088}
Ext mul's codegen assumes that all inputs are in registers, but the
instruction-selector wasn't the correct constraints. The codegen for ext
mul is slightly complicated so we chose to restrict the inputs to be
registers rather than changing codegen.
Bug: chromium:1165966,v8:11262
Change-Id: I5d4eb56d17a4d0a2927b089dbf74362c7e7ff4fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626711
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72073}
Drive-by: Range checks in `Emit(byte, twenty_four_bits)` to ensure the
given packed bits actually fit into 24 bits.
Bug: chromium:1166138
Change-Id: I2e711e6466bb48d7b9897f68dfe621d12bd92508
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625877
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72064}
This CL fixes a bug in the code generation for I32AtomicCompareExchange
in Liftoff on ia32. The problem is the inconsistency that
LiftoffAssembler::PeekToRegister(...) introduces to the cache state.
PeekToRegister loads the value from the value stack into a register, but
does not pop the value off the stack. When the value was already stored
in a register, the use counter of that register gets decreased, even
though the value is still on the stack.
The problem arises when this register later gets reused, which is
necessary unfortunately on ia32. When SpillRegister is called for this
register, all stack values that are stored in this register get written
to memory. SpillRegister uses the use counter of the register to detect
when the register was spilled to all stack slots that were cached by
this register. However, as described above, the value stack and the use
counter are inconsistent at that moment, so SpillRegister finishes
early and does not spill the register to all stack values, and this
causes the bug later.
With this CL the decrement of the use counter gets delayed until when
the value actually gets popped off the stack.
R=clemensb@chromium.org
Bug: chromium:1145135
Change-Id: I07cb256a7e5135dbce41b246c120650635ad2758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602464
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72018}
When creating a new closure, we check feedback vector for any optimized
code and install it on the newly created closure. We evict the optimized
code from the feedback vector if it is marked for deoptimization. We
used to evict the code before creating the new closure. However,
creating a new closure could cause allocation failures and hence trigger
a GC. This could mark optimized code on feedback vector for
deoptimization if any weak objects held by optimized code are GC'ed.
This cl delays the eviction unitl after the closure was created.
Bug: v8:1163184
Change-Id: I217279e4a51f75b87bb7ae5a00fd1cf57805e3c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613034
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71999}
We were incorrectly clearing the high reg from the list of regs to load.
The intention was to prevent double (and incorrect) loading - loading
128 bits from the low fp and the loading 128 bits from the high fp.
But this violates the assumption that the two regs in a pair would be
set or unset at the same time.
The fix here is to introduce a new enum for register loads, a nop, which
does nothing. The high fp of the fp pair will be tied to this nop, so as
we iterate down the reglist, we load 128 bits using the low fp, then
don't load anything for the high fp.
Bug: chromium:1161654
Change-Id: If2ea79132b78623e5990237c60cf0883d9a8223f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617380
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71976}
Now that the underlying bug is fixed, we can expect the test to always
pass.
Also simplify the test a tiny bit and skip it on debug builds because
it's slow.
Bug: chromium:1161357
Change-Id: I2ce5e064b4f707f4bd680f04df95d5a342bec1b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616220
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@{#71972}
The flag was enabled by default in M85, it is time to remove it.
R=clemensb@chromium.org
Bug: v8:7741, chromium:1160677
Change-Id: Ic4a9490efa645a7466cb844484169ab262f0df38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610965
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71945}
This adds a regression test for a bug in lowering load transforms.
This test will fail if 0efa3fd97e is
reverted.
Bug: chromium:1124885
Change-Id: I31b714d4565c4fff730c1274af8059031cb1e1b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610508
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71919}
In https://crrev.com/c/2591859 we changed the way we generate code for
v128.select, which assumes that all inputs are registers. We did not
update the instruction selector with this new constraint.
Fixed: chromium:1161954
Bug: v8:11282
Change-Id: I5fc9a0315873a3e795078997d87aa92d4c8bddfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2603764
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71904}
.. to verify that the trampoline_pc has been set.
Bug: chromium:1161357
Change-Id: If7e1a13cff9919e2e8a65c095d80dfcef2dc05cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606333
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71896}
Previously, we were looking up the prototype of the receiver and
checking that against %TypedArrayPrototype% before invalidating the
protector cell.
This is incorrect as it's possible to patch the prototype and then
change the constructor property, bypassing this check.
This CL adds a new instance type to prototype of all TypedArray
constructors and checks the receiver against this instance type.
TBR: tebbi@chromium.org
Bug: v8:11274, v8:11256
Change-Id: I2ff6280e4cf820b06c5593fe4addd36f7ac656c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2594776
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71799}
next_enumeration_index is the next free index available to store a
property. ObjectDescriptor tracks this field while instantiating the
literal and updates the next_enumeration_index when finalizing the
instantiation. When adding new properties (named / computed) we were
updating this value to the current value that is being used instead
of next free index. This cl fixes it.
Bug: chromium:1152231
Change-Id: Ica8c36dcabf035db559e29d4573ecd5e53d6062a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2577463
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71709}
First step towards the new exception handling proposal:
https://github.com/WebAssembly/exception-handling/issues/125
This is essentially a revert of:
"[wasm] Switch to new 'catch' and 'br_on_exn' proposal."
The changes are:
- "catch" instruction takes a tag immediate,
- "rethrow" instruction takes a label immediate,
- Add "catch_all" instruction,
- Remove "br_on_exn" instruction,
- Do not push exceptions on the stack, only the encoded values
R=clemensb@chromium.org
CC=aheejin@chromium.org
Bug: v8:8091
Change-Id: Iea4d8d5a5d3ad50693f645e93c13e8de117aa884
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484514
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71602}
Safepoint maps record all spill slots that contain a tagged value. The
introduction of multi-value return changed the stack frame layout though
and the calculation of spill slots has not been adjusted accordingly.
This CL adjusts the creation of safepoints now to work for multi-value
returns as well.
R=neis@chromium.org
Bug: v8:11206
Change-Id: Id623dbc28b976dcf625ac78738e03e642fafbb36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569762
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71591}
The {ParallelRegisterMove} at the end of {AtomicLoad} might need a
temporary scratch register for spilling values to the stack. Make sure
that one is available by giving up the scratch register used for the
address of the atomic access.
R=ahaas@chromium.org
Bug: chromium:1153442
Change-Id: I267c43e2193662c420f96f6683ebd4bbb0e1bca3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566759
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71564}
Unifies various operators for dynamic map checks with the naming
scheme of DynamicCheckMaps (to be similar to CheckMaps.
BUG=v8:10582
Change-Id: I8ac842f55fe31cdc7b84968d077017a86ddf4442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567952
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71559}
The flags were added because scalar lowering was not implemented for the
instructions in the test. Now that scalar lowering is complete, we can
remove these flags.
Fixed: v8:11137
Change-Id: Ic7bdedbfe558fafebe98917fe4e6a7922203ba91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565078
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71474}
Fixed: chromium:1151890
Change-Id: I26f5c76494a9ff3f5a141f381e1c9a543e368571
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2561618
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71422}
For a very particular special case (long "chains" of bound
functions with an undefined @@hasInstance handler), evaluating
the `instanceof` operator could lead to a very deep recursion.
This patch adds a stack check to make sure we throw rather than
crash on stack overflow.
Bug: v8:11115
Change-Id: I6bf941b9e75e9fe3a52112ade27388ac4fbbda2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545624
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71335}
... to --turbo-dynamic-map-checks. With the upcoming use in NCI code,
this feature is no longer used exclusively by Turboprop.
Bug: v8:8888
Change-Id: I61e01db086fd2e8566d2e2a09574be74b6e5a7bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546693
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71263}
For NCI compilation tasks, we don't actually install the generated
Code object on the function. In that case, we cannot make assertions
about function state.
Bug: v8:8888,chromium:1146013
Change-Id: Ia2342c52e565ccb1f6b5b09dda5e998b3fd3eb3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2532297
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71140}
... instead of FLAG_concurrent_recompilation. The
optimizing_compile_dispatcher may be nullptr despite the flag being
set.
Bug: v8:8888,chromium:1145988
Change-Id: Ia3a6b1a95dde2b8cdd43dd2beebf04c66f145f78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2531781
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71116}
The arm implementation made the assumption that the {lhs} and {dst}
registers are either the same, or there is no overlap. This assumption
does not hold.
ia32 on the other hand has a lot of complicated logic (and unnecessary
code generation) for different cases of overlap.
This CL fixes the arm issue *and* simplifies the ia32 logic by making
the arm assumption hold, and using it to eliminate special handling on
ia32.
R=thibaudm@chromium.org
Bug: chromium:1146861
Change-Id: I8753c2ed70349e735c03293130c899c0c8a3a671
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526388
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71060}
When searching for a target map during map update, attempt to
update field representations in-place to the more general
representation, where possible.
Bug: chromium:1143772
Change-Id: I6a43c94910a1d2d8f8b0ad89048f94b51461f76c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507715
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70887}
Fix super calls so that arguments are evaluated before the
super constructor is checked to be in fact a constructor.
A new bytecode is introduced to split the IsConstructor check
out from the current GetSuperConstructor bytecode.
Bug: v8:10111
Change-Id: I3af99e32a34d99493806bb01b547d6f671cdc9de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493077
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70881}
Inside of LoopPeeler::PeelInnerLoopsOfTree we call the typer, which
inspects heap objects, so we need to unpark the local heap.
Reverted in https://chromium-review.googlesource.com/c/v8/v8/+/2502333
Original change's description:
> [compiler] Replace Symbol with direct reads
>
> Bug: v8:7790
> Change-Id: I49120a6349777fd992a97d697940e79b2e71dbd1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400988
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69812}
Bug: v8:7790, chromium:1137594
Change-Id: I8539175002e19b04b84009eb6b2cc5ced4ee53c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502339
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70872}
Test was skipped because the generated test contains multi-byte opcode,
and wasn't correct. Fix up the test with the correct encoding. The
fuzzer now generates multi-byte opcodes correctly, and so shouldn't be
an issue.
Bug: v8:10486
Change-Id: I1f5ad7d456320a30da6c553f65fdca0fc86a291a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505238
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70864}
PPC has a larger page size than other platforms, so increase the page
size in the test to account for this.
Change-Id: I392064e9ef3f87c5bddb7763b35661aee5b4669d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2502330
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70857}
The number of available double registers depends on supported CPU
features on arm. Any code that applies to all double regs must be
extra-careful to correctly handle either 16 or 32 registers.
This was not the case for deopt entries, which were recently moved
from a runtime-generated code stub to a mksnapshot-time-generated
builtin.
This CL fixes the issue by inspecting the runtime value of cpu
features and acting on it.
Bug: v8:8661,chromium:1142158
Change-Id: I6f4d2e6ee6a80217b9110194b8e1edbe8670d8d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498686
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70796}
Make the array elements in msunit/regress/regress-542823 larger, so that
it takes fewer of them to force the joined string to go into large
object space. Also, set the array's size dynamically based on the
maximum non-large object size, rather than having a fixed magic "large
enough" size, and verify that the resulting joined string is indeed in
LO space.
This reduces the runtime of this test under slow_path and gc-stress from
minutes to seconds.
Bug: v8:11060
Change-Id: I51d960b6a3e052199f50c1a6ba6fbce1b6d1ae38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498689
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70762}
For deserialized modules the compilation state was not set to
kFinishedTopTierCompilation and co. A consequence was that code that
required top tier compilation to be finished to block indefinitely.
With this CL the compilation state is initialized properly.
I tested this CL locally with the regression test mentioned in the bug
tracker issue. However, this regression test required to run this test
twice in separate processes. It would be possible to write a regression
test for this that runs on the bots, but I considered it not worth it.
R=clemensb@chromium.org
Bug: v8:11024
Change-Id: Ib4e75eae03fab13a3ff013118fc1f33a1278b33f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2494930
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70757}
msunit/regress/regress-542823 is intended to test large object
allocation in Array.prototype.join, but to do so it has a pretty
inefficient way of first building a large array.
Speed-up this test by using Array.prototype.fill, call .join directly,
and make the whole thing an IIFE to avoid global loads.
Bug: v8:11060
Change-Id: I5906bcb6c65b10ec830b026cf1f24acb6d5e1aaf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498681
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70755}
The dynamic map check builtin loads the feedback vector from the
function's frame, therefore it doesn't work if we inline the
function. We don't do inlining on TurboProp so this is fine, but
it was possible to enable dynamic map checks on TurboFan which does.
This change prevents that, and also makes the dynamic map checks flag
specific to TurboProp and no longer an implication, which also allos
it to be switched on the command line independenly of --turboprop.
BUG=chromium:1141502,v8:9684
Change-Id: I365de461a6373335a45a7a154af7d4cf1c13dc2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2494928
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70737}
The register that holds the {new_value} for the AtomicCompareExchange8U
has to be a byte register on ia32. There was code to guarantee that, but
after that code there was code that frees the {eax} register, and that
code moved the {new_value} to a different register again. With this CL
we first free {eax}, and then find a byte register for the {new_value}.
R=clemensb@chromium.org
Bug: chromium:1140549
Change-Id: I1679f3f9ab26c5416ea251c7925366ff43336d85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491031
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70721}
This trap now used for all runtime type errors thrown when interfacing
with JS. Its name and message have been changed to reflect this.
Additional change: Remove the trap from the list of traps used
exclusively for RuntimeError (as opposed to TypeError) in
wasm-module-builder.js.
Change-Id: I517766837a60d94b562d4c0de922d52db786b635
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488688
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70682}
Bug: chromium:1139782,v8:10765
Change-Id: I417cd037b2587599b925cce08d8652b2df1985ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488687
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Cr-Commit-Position: refs/heads/master@{#70679}
Preparing for tail call is usually done by emitting the gap moves and
then moving the stack pointer to its new position. An optimization
consists in moving the stack pointer first and transforming some of the
moves into pushes. In the attached case it looks like this (arm):
138 add sp, sp, #40
13c str r6, [sp, #-4]!
140 str r6, [sp, #-4]!
144 str r6, [sp, #-4]!
148 str r6, [sp, #-4]!
14c str r6, [sp, #-4]!
...
160 vldr d1, [sp - 4*3]
The last line is a gap reload, but because the stack pointer was already
moved, the slot is now below the stack pointer. This is invalid and
triggers this DCHECK:
Fatal error in ../../v8/src/codegen/arm/assembler-arm.cc, line 402
Debug check failed: 0 <= offset (0 vs. -12).
A comment already explains that we skip the optimization if the gap
contains stack moves to prevent this, but the code only checks for
non-FP slots. This is fixed by replacing "source.IsStackSlot()" with
"source.IsAnyStackSlot()":
108 vldr d1, [sp + 4*2]
...
118 str r0, [sp, #+36]
11c str r0, [sp, #+32]
120 str r0, [sp, #+28]
124 str r0, [sp, #+24]
128 str r0, [sp, #+20]
...
134 add sp, sp, #20R=jgruber@chromium.org
Bug: chromium:1137608
Change-Id: If2b85dde49bf31a6bd3f5e0255407f9390727f9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474784
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70603}
This is a reland of cdc8d9a5ec
Skipped tests on gc_stress and fixed CONSTEXPR_DCHECK for gcc.
Original change's description:
> [TurboProp] Avoid marking the output of a call live in its catch handler
>
> The output of a call won't be live if an exception is thrown while the
> call is on the stack and we unwind to a catch handler.
>
> BUG=chromium:1138075,v8:9684
>
> Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70562}
Bug: chromium:1138075
Bug: v8:9684
Change-Id: I685c94ee2ffcf06658df07fcef06f58c4f01f54b
Cq-Include-Trybots: luci.v8.try:v8_linux64_gcc_compile_dbg
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479009
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70573}
This reverts commit cdc8d9a5ec.
Reason for revert: The regression test is too slow:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/30454
Also gcc failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20gcc%20-%20debug/9528
Original change's description:
> [TurboProp] Avoid marking the output of a call live in its catch handler
>
> The output of a call won't be live if an exception is thrown while the
> call is on the stack and we unwind to a catch handler.
>
> BUG=chromium:1138075,v8:9684
>
> Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70562}
TBR=rmcilroy@chromium.org,neis@chromium.org
Change-Id: I0f6b9378d516a70401fc429fb3612bbf962b0fb2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1138075
Bug: v8:9684
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2479007
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70564}
The output of a call won't be live if an exception is thrown while the
call is on the stack and we unwind to a catch handler.
BUG=chromium:1138075,v8:9684
Change-Id: I95bf535bac388940869eb213e25565d64fe96df1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476317
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70562}
In certain situations a phi might not be used by later code, and so
is neither spilled nor has a register allocated to it. Handle this
by removing the incorrect DCHECK.
BUG=chromium:1137979,v8:9684
Change-Id: I702dc05dba22e23dac5c1a366a770f18bac45c52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471998
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70536}
It is related to Reduce consecutive overflow addition with constants.
Turned out that we needs to consider also effect use before relaxing it.
This fixed the issue that fuzzer found in e93a369f7a.
Bug: chromium:1137586
Change-Id: I32fee5ecc7a6ce40d6f739f9c6e2440a647a2222
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469597
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70514}
Whenever more then one value is pushed to the stack, we need to execute
a check for growing the stack first (since https://crrev.com/c/2431525).
This CL adds two missing checks.
R=thibaudm@chromium.org
Bug: chromium:1137582
Change-Id: I9755502dfdb77c03d1dde3e83fb7d33b9b99e499
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467796
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70480}
AST reindexing has to skip visiting fields that are already in the
member initializer, as they will have already been visited when
visiting said initializer. This is the case for private fields and
fields with computed names.
However, the reindexer was incorrectly assuming that all properties
with a FunctionLiteral value are methods (and thus not fields, and
can safely be visited). This is not the case for fields with
function expression values.
Now, we correctly use the class property's "kind" when making this
visitation decision.
Fixed: chromium:1132111
Change-Id: Ia53d1fe713453e361b818dfb0b5f88a90cecdf21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440519
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70247}
Array.prototype.pop() must throw a TypeError whenever the array's
length is readonly; there is no exception to that when the length
is 0. This patch moves the length==0 special case after the read-
only length check in both fast paths (CSA and C++).
Fixed: v8:10908
Change-Id: I4a77439478cffeaf11022ff8beb78b0a907290d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440576
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70233}
Sorting a TypedArray with a custom compare function requires us to
copy the array's contents to a FixedArray. When the TypedArray is
larger than FixedArray::kMaxLength, we should throw a RangeError
rather than crashing with an OOM message.
Fixed: v8:10931
Change-Id: I8a27cc0ac80a9172bc5e8e154fdf4ccce5974317
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440575
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70232}
LoadTransform operators contain a LoadKind, which can be unaligned,
protected, poisoned, normal.
If it is protected, we cannot eliminiate that load,
since we rely on the segv signal handling. So, we use partial template
specialization on LoadKind::kProtected, and don't set the operator to
not be eliminatable.
Bug: chromium:1132461
Change-Id: If45fc6562348ffd4dbaa27058e6c5d4242f79abb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436081
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70205}
Add opt and noturbo inlining to these tests to ensure that
they keep working.
Bug: v8:10924
Change-Id: Icdb5ddffad11ea3c2eea723e339d450d8405b6b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426604
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70145}
These instructions were changed from "s8x16" to "i8x16" prefixes in
https://github.com/WebAssembly/simd/pull/321.
This CL updates all V8 code, including arch-specific code, to match.
Bug: v8:10946, v8:10933
Change-Id: I26ef9ad77571f94501d42c1d65f57380fd507f3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432068
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70143}
In atomic.notify we overwrote the register which stored the index,
without checking if it was still in use or not.
R=clemensb@chromium.org
Bug: v8:10898
Change-Id: I59ed7a2c1f1342ff4252e3c4d33822111caee82c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426616
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70125}
