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}
