We don't want to handle even non-growing stores when there are TypedArrays
in the prototype chain. Typed arrays handle the out-of-bounds accesses by
ignoring the stores unlike the regular array writes. We just let runtime
handle these cases instead of making ICs more complex.
There was an earlier cl (https://chromium-review.googlesource.com/c/v8/v8/+/1609790)
that fixed it for growing stores. This cl extends it for non-growing stores
as well to handle more cases.
Bug: chromium:961709
Change-Id: I65e079b88c10d2ba343f69a67134893319cd8f8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662305
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62243}
This adds missing support when converting a Word32 value (either in
Signed32 or Unsigned32 range) to Word64 representation, for which the
type also includes MinusZero. This conversion is fine as long as the
difference between 0 and -0 is not observable (in other words, as long
as the truncation identifies zeros).
Bug: chromium:971782, chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383
Change-Id: I9d350a25f57b1342eb7fd1279d55a8610bdaf7cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664062
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62235}
This adds preliminary support for storing constructed WebAssembly
functions in tables. Note that for now only tables at index #0 are
supported, extending it to other tables indexes will be done as a
follow-up.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I9aa07813e07f0ceb4eafe37af412b45c7d235722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1640209
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62210}
RegExp assertions (e.g.: '^', '$', '\b', ...) sequences have certain
properties that this rewriter exploits:
1. They are zero-width and order-independent, thus one can remove all
duplicate assertions.
2. If a subsequence is guaranteed to fail, the entire sequence fails.
Any sequence always known to fail (e.g. containing both '\b' and '\B')
can be rewritten to a single node that triggers failure.
This CL generalizes the previous optimization for repeated assertions
to be order-independent, i.e. assertions only have to be in the same
sequence but not next to each other.
Bug: v8:6515, v8:6126
Change-Id: I3f92f081ce8a55ad8c34c269a09a6686e3b008f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657925
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62201}
When iterating over the holdings inside the cleanup callback,
we could potentially unregister the weakref which is next or
prev on the key list causing these checks to be incorrect.
Bug: v8:9360, v8:8179
Change-Id: I53ea12346eb4882b16a82677b64ba2c756d23a1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658161
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62165}
Disable bytecode flushing for test as it messes up lazy source
positions and the flags aren't representative anyway.
Bug: v8:8510
Change-Id: I6d5bc8dcd174a9bfc48f682518e6c62d79acb691
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658152
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62155}
The store element handlers don't check if the array length is writable
before updating the length. Since this is not expected to be a common
case no need of handling this in the element handlers. Just moving to
megamorphic would be sufficient.
Bug: chromium:967104
Change-Id: I7a7f9ea768266b9ffd6289328d61d2297d455619
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658154
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62152}
ObjectPreventExtensions and ReflectPreventExtensions are now Torque builtins (previously CPP) and the Proxy path is implemented completely in Torque while everything else calls into runtime (and is thus a bit slower than previously).
Perf improvement in micro-benchmark JSTests/Proxies
Before:
PreventExtensionsWithoutTrap-Proxies(Score): 1978
PreventExtensionsWithTrap-Proxies(Score): 739
After:
PreventExtensionsWithoutTrap-Proxies(Score): 3017
PreventExtensionsWithTrap-Proxies(Score): 2044
Bug: v8:6664
Change-Id: I6505d730cea6b0d197f6f5d0540b39056c8b763d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1652688
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62130}
Make sure to use the callback passed to cleanupSome
Bug: v8:8179
Change-Id: Ia5d90b56edf80e05bdaf0dc520b555c29042b64c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655306
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62122}
With bytecode flushing and lazy feedback allocation, we need to call
%PrepareForOptimization before we call %OptimizeFunctionOnNextCall,
ideally after declaring the function.
Bug: v8:8801, v8:8394, v8:9183
Change-Id: I3fb257282a30f6526a376a3afdedb44786320d34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648255
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62119}
Currently, in wasm-function stack traces, v8 displays the decimal offset
from the start of the function. However, the WebAssembly WebAPI
specification says that it should be a hex offset into the module.
This change makes the stack trace display with hex module offsets, as
well as fixing all the unit tests that depended on the old behaviour.
R=fgm@chromium.org, titzer@chromium.org, yangguo@chromium.org
Bug: v8:9172
Change-Id: I73737a319a42dd665521ab8a4b825199ae11c87f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1646846
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Guanzhong Chen <gzchen@google.com>
Cr-Commit-Position: refs/heads/master@{#62103}
It was a good flag, but it's time to say goodbye. Let us take a moment
to remember the good times we've had during its short time on earth.
It shipped in Chrome 74.
BUG=v8:8523
R=adamk@chromium.org, mathias@chromium.org, gsathya@chromium.org
Change-Id: I37e58360614c0bb3582b8bbfac795d5ed3e5a149
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1641205
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Auto-Submit: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#62099}
An error object's 'stack' property is lazily formatted once the
property is first read. It is thus possible that lazy formatting
happens in a different realm than where the error object was
constructed.
In this case, we should use the origin-realm's prepareStackTrace
function to format the stack trace.
This CL implements that behavior by fetching prepareStackTrace from
the given error object's context's error function.
Bug: v8:7848
Change-Id: Ibc383cf24f2c0dab2fd8bb7bc740f1488d9954a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1113438
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62090}
This CL adds two mjsunit tests that transition an error object to
dictionary mode before and after Error.stack is formatted and verify
that the custom 'stack' property accessor works as intended.
Bug: v8:8742
Change-Id: I4beb52c75b94533c10fac007f41117ab8915fac8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649789
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62078}
Quotes have been added around the token to make the message clearer.
Bug: chromium:943636
Change-Id: Ic38f3e6d307157af2c0146e69fb611a2cfb46564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593307
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62074}
The path for sealed elements is handled by using the same path for SmiOrObjectElementKind, just need to extend a DCHECK in CodeStubAssembler::IsFixedArrayWithKind.
The only special case is when we write to a hole in holey sealed elements. Since we can not write in that case, just bail out.
Bug: chromium:967101
Change-Id: Ibf837ae053fe609bca83da432f298ef056f3aced
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632830
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62071}
The CloneObject bytecode was only able to handle objects, null and
undefined, and explicit bytecode had to be generated to perform the
ToObject outside the bytecode (unlike the other IC bytecodes that
just perform the ToObject implicitly). That means the simplest possible
object cloning would also generate a sequence of 5 bytecodes (at least):
```
Mov <register>, a0
JumpIfNull @1
JumpIfUndefined @1
ToObject <register>
1: CloneObject <register>
```
That is quite wasteful and unnecessary, since the core logic in the
runtime already does the ToObject properly anyways. This change
refactors the CloneObjectIC slightly to behave more like the other ICs
and do the ToObject implicitly when necessary.
Bug: v8:7611, v8:9114, v8:9183, v8:9343
Change-Id: I11973e90bf875f154a5a7739287bee17041e4a7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649554
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62064}
The DoubleToFloat32 helper takes care of everything, so use it
consistently.
Bug: chromium:969498
Change-Id: If71e5374684b89615006548cb0329f4d4cb7fd6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648253
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62062}
As per the new specs, when the exception is thrown by iterator's return method
while doing iterator close because it is not callable, the exception is
suppressed in the same way as if the return method is called and threw an exception.
https://github.com/tc39/ecma262/issues/1398
Bug: v8:9056
Change-Id: I21abd5fdd01d3a957c3c16d9d3aaab9091e43142
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648256
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#62035}
We need to hold onto the bytecode array so it doesn't get flushed.
Bug: v8:8394
Change-Id: Ia583a0a662740e369fcbc1c94041895e463be26e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645329
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62011}
ObjectIsExtensible is now a Torque builtin (previously CPP) and the Proxy path is implemented completely in Torque while everything else calls into runtime (and is thus a bit slower than previously).
Improvement in micro-benchmark
Before:
IsExtensibleWithoutTrap-Proxies(Score): 2228
IsExtensibleWithTrap-Proxies(Score): 917
After:
IsExtensibleWithoutTrap-Proxies(Score): 3683
IsExtensibleWithTrap-Proxies(Score): 3310
Bug: v8:6664
Change-Id: I1fbe1c51cb724a23d7a59fc8231bb3d1461a6add
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1637444
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62006}
With bytecode flushing and lazy feedback allocation, we need to call
%PrepareForOptimization before we call %OptimizeFunctionOnNextCall,
ideally after declaring the function.
Bug: v8:8801, v8:8394, v8:9183
Change-Id: I6bf119e726426df8527d97546b6ce806112c894d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643167
Auto-Submit: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61988}
Array push / pop / shift were inlined if the elements kind of the
receiver maps is the same. This cl extends it by inlining these
builtins even when the receiver maps have different elements kinds.
It still limits it to only fast elements kinds. This is required to
prevent regressions in deltablue when lazy feedback allocation is
enabled. With lazy feedback allocation we may see polymorphic
feedback more often, since we don't have allocation site feedback
till the feedback vectors are allocated.
Bug: v8:9078
Change-Id: Id4a7b84be6305b125913b6ce0fb4f3eb3e3b15ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632239
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61949}
