Since we use a ScopedPtrList to track cover grammar expressions we don't know
the position of the commas anymore. The position of the commas was used to
demark the initializer, which is needed to figure out whether we need hole
checks for variable references. (Typically only references within the
initializer need hole checks for the initialized variable.) Since we didn't
have the comma position, we simply used the position of the first expression as
the position of any subsequent comma, which would make it seem as if the
initializer body wasn't in the initializer. Now instead we simply use the
position of the subsequent parameter as the end of the initializer, which is
close enough.
Bug: chromium:902810
Change-Id: I8d2bc7a2dc9f59db16ce56ccef01e263a18a3b7a
Reviewed-on: https://chromium-review.googlesource.com/c/1326022
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57357}
The Ignition statement list visitor will skip the rest of the
statements in the list if it hits a jump statement (like a return
or break), as the rest of the code in the list can be considered
dead.
return;
dead_call(); // skipped
However, since this is at an AST node level, it does not take into
account condition shortcutting:
if(2.2) return;
dead_call(); // not skipped
There is also a second dead code elimination in Ignition compilation, at
the bytecode array writer level, where a bytecodes are not emitted if an
"exit" bytecode (Return, Jump, or a few others) has been written, until
the next basic block starts (i.e. a Bind).
This can cause an issue with statements that resurrect the bytecode
array writer part-way through their visit. An example is try-catch
statements, which save the context to a register, and then Bind to start
the try region.
For the case:
if (2.2) return;
try { // try statement not skipped
...
}
the bytecode writer is called with
OutputReturn() // exit bytecode seen
OutputMove(<context>, r1) // not emitted
Bind(&try_begin) // starts new basic block
// try body
So, the try is emitted, but without saving the context to a register.
This means that the liveness analysis sees the read of that register
(as the output liveness of throwing bytecodes), but does not have a
write to the register, which means that the liveness escapes.
This patch fixes this by using the bytecode array writer dead-code
elimination (i.e. "exit bytecode seen") to inform the statement list
visitor, so that in this example the try statement is not visited at
all.
Bug: chromium:902395
Change-Id: Ieb8e46a4318df3edbac0ae17235e0ce8fba12ee3
Reviewed-on: https://chromium-review.googlesource.com/c/1322951
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57350}
Installation of the PrototypePropertyDependency, as well as GC, can
invalidate dependencies.
Bug: chromium:902552
Change-Id: Iabcce026c7475c722d19ac0b80758b22d9fbcfda
Reviewed-on: https://chromium-review.googlesource.com/c/1322450
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57343}
regress-336820 is testing that joining a very sparse
array to create a too-big string results in a RangeError,
rather than a crash. Reducing the largest index by
two orders of magnitude speeds this up (on x64 debug)
by 8x (from 8 seconds down to 1). Given that this test
takes nearly 9 minutes on arm64 sim debug, I hope to
see big ones there too.
Bug: v8:7783, chromium:336820
Change-Id: I74c22cf451a892eb039efc7f1259152921bf8530
Reviewed-on: https://chromium-review.googlesource.com/c/1323915
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57335}
The array length is modifiable by user code that is called as a
side-effect during the sorting algorithm. We thus cannot base any
guarantees on the current length, but must reference the initially-read
array length instead.
Note that even though the algorithm may read and write from beyond
the current array length value, this adheres to the spec, which only
requires accesses to be within the original array dimensions (i.e.: 0
<= i < original array length).
Bug: chromium:901633
Change-Id: Id765e80d4231ff6f2a73e040ec94c2b07f8c5b0f
Reviewed-on: https://chromium-review.googlesource.com/c/1317814
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57279}
- Avoid allocating AstRawString in the preparser
- Use fast LiteralEquals to compare the directive.
Bug: chromium:901250
Change-Id: I178aca812f6c0ffa28d7f48b707316a5a99a2ac0
Reviewed-on: https://chromium-review.googlesource.com/c/1314570
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57217}
Restructure the code a little, and change how we detect sloppy block function
redeclaration so we don't dereference a possibly nullptr function.
Bug: chromium:900786
Change-Id: Ief124fe767603ca36f4dc8865c4aeb3e0635b4cf
Reviewed-on: https://chromium-review.googlesource.com/c/1314331
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57206}
The fast-path in the `ArrayPrototypeLastIndexOf` torque implementation
didn't check that the `fromIndex` is within the bounds of the JSArray
_AFTER_ the call to ToInteger, which can have arbitrary side-effects,
i.e. it can change the length of the array.
R=yangguo@chromium.org
Bug: chromium:898785
Change-Id: I7ef84143ec8c33148f6e9d451bd52769d5074fb4
Reviewed-on: https://chromium-review.googlesource.com/c/1314329
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57204}
CanCover is not transitive. The counter example are Nodes A,B,C such
that CanCover(A, B) and CanCover(B,C) and B is pure. In this case the
effect level of A and B might differ.
This CL adds a missing CanCover check to a case of shift reduction where
we assumed transitivity.
Change-Id: I9f368ffa6907d2af21bbc87b3e6570d0d422e125
Bug: v8:8384
Reviewed-on: https://chromium-review.googlesource.com/c/1307419
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57157}
For memory limit checks, we should use the minimum of the
--wasm-max-mem-pages flag and kV8MaxWasmMemoryPages. The former is a
limit set by the user, the latter is the maximum we can handle
internally.
R=titzer@chromium.org
Bug: chromium:898677
Change-Id: I3c549f4e90dd016b5d07475d9353f30134f76dcc
Reviewed-on: https://chromium-review.googlesource.com/c/1305274
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57127}
The "grow_memory" opcode was renamed to "memory.grow", and the spec
repo was updated to use kExprMemoryGrow internally instead of
kExprGrowMemory (https://github.com/WebAssembly/spec/pull/720).
This CL does the same change for v8.
Drive-by: Rename "current_size" to "memory.size", and a minor cleanup
in wasm-graph-builder.js to bring it in line with the version in the
js-api tests in the spec repo.
R=titzer@chromium.org
Change-Id: If525dba898b2c248890a616d3392c22b45f698ef
Reviewed-on: https://chromium-review.googlesource.com/c/1302057
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57089}
This fixes the fall-back case when parsing a multiplicative expression
where the lookahead found a '-' token followed by an unsigned token, but
no '*' token is following. We cannot rewind both tokens, but still need
to make sure that a full multiplicative expression is parsed.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-8377
BUG=v8:8377
Change-Id: I20ce6267445b32bdaf03f41f11d9ef4be66cb636
Reviewed-on: https://chromium-review.googlesource.com/c/1304317
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57084}
This allows very large arrays being joined to incrementally,
on-demand allocate the internal buffer. Previously, join
would allocate the buffer upfront and all at once. Large,
sparse arrays will use less memory.
Bug: chromium:897404
Change-Id: Id914b14a7c55a62834f63ad602bdb45363249075
Reviewed-on: https://chromium-review.googlesource.com/c/1303538
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57075}
While not strictly necessary, this is consistent with how
SlowFlagGetter behaves. It adds an additional shift operation (which
we could fold into the smi untagging if needed).
Drive-by: Typify flag accessors.
Bug: chromium:899464
Change-Id: Ib154d626e522ed723e2c19b1ab7f68560ac414bc
Reviewed-on: https://chromium-review.googlesource.com/c/1304315
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57063}
When replacing a LoadElement with variable index with its known fields,
only do it if the types match, otherwise we end up with a graph that
representation selection cannot handle. That can only happen in dead
code, but TurboFan would nevertheless crash in representation selection.
Bug: chromium:893982, chromium:899524, v8:5267, v8:6200
Change-Id: I01e645d5e01bffb911d216d37d923792d9d0beab
Reviewed-on: https://chromium-review.googlesource.com/c/1303721
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57059}
The assumption behind this optimization was invalid. Even if the
string's prototype is unchanged, the symbol could exist somewhere
further up the prototype chain.
GetProperty has been sped up significantly so it might be fine to just
skip this fast path. An alternative would be to use a protector cell.
Bug: v8:8357
Change-Id: Ia577107a58157350eb15780c02aa63d77e600637
Reviewed-on: https://chromium-review.googlesource.com/c/1301498
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57038}
This just adds calls to SerializePrototype right before we access the
serialized prototype. Eventually we need to do this earlier.
Bug: v8:7790, chromium:899115
Change-Id: I597e95f5f6df8aae608ee295fe9550e7c2a45e6d
Reviewed-on: https://chromium-review.googlesource.com/c/1301475
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57034}
The valid store types of a {Float64Array} heap view are specified to be
"float?" and "double?". We correctly accepted both types but forgot to
emit the appropriate conversion in the "float?" case. This just adds the
missing conversion expression.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-898974
BUG=chromium:898974,v8:8347
Change-Id: I306b10e2088185b1522da29b1a113908ef9925f2
Reviewed-on: https://chromium-review.googlesource.com/c/1301499
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57025}
Checking impl()->IsAsync(identifier) is insufficient since it could be
parenthesized. By checking the token in addition to IsIdentifier guarantees
that we've only seen the single token ASYNC.
Bug: chromium:898812
Change-Id: Id94dd607381050b4bd8cd6d8672a5d11256db7da
Reviewed-on: https://chromium-review.googlesource.com/c/1300134
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57013}
PrepareElementsForSort must return a number less than or equal the array
length.
Bug: chromium:897512, v8:7382
Change-Id: If5f9c4d052e623ab9f3300b8534603abbee859fa
Reviewed-on: https://chromium-review.googlesource.com/c/1297958
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56982}
This reverts commit ec969ea3b1.
Reason for revert: test fails consistently on arm bots.
I can't repro the failure locally, but it does consume ~512MB of memory (for a single string, I think?), so my guess is that the bots don't have enough contiguous address space.
Original change's description:
> [builtins] Fix Array.p.join length overflow and invalid string length handling
>
> - Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
> - When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
> - Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
>
> - Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
>
> Bug: chromium:897404
> Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
> Reviewed-on: https://chromium-review.googlesource.com/c/1293070
> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56907}
TBR=danno@chromium.org,peter.wm.wong@gmail.com,jgruber@chromium.org,tebbi@chromium.org
Change-Id: I8ca80bd75833aacc94ccb25ceb82bbc8880991db
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:897404
Reviewed-on: https://chromium-review.googlesource.com/c/1297471
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56915}
- Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
- When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
- Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
- Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
Bug: chromium:897404
Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
Reviewed-on: https://chromium-review.googlesource.com/c/1293070
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56907}
Whenever left-trimming is possible (e.g. whenever user code is
called), we must not store a reference to an exposed JSArray's
elements.
Bug: chromium:897366,v8:7382
Change-Id: I8dd6a93aa6ed19e755ccce7122e0e019dc578a31
Reviewed-on: https://chromium-review.googlesource.com/c/1292066
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56903}
This is to fix test262 tests which expect that there is no arguments
object.
Bug: v8:7186
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I56205c29609666dc832297e4d36a4d487eae36cc
Reviewed-on: https://chromium-review.googlesource.com/c/1291469
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56890}
Previously we'd first accumulate errors to the parent and validate the
destructuring pattern in the parent. In the case of ParseArguments this
will invalidly propagate binding pattern errors from one argument to the
next. The reason why ParseArguments keeps track of binding pattern errors
is because it could also be used to parse async arrow function parameters.
If we see async(a,b) we don't yet know whether this is the head of an
async arrow function, or a call to async with arguments a and b.
Bug: v8:8241
Change-Id: I670ab9a9c6f2e0bee399808b02a465ae1afa7c3f
Reviewed-on: https://chromium-review.googlesource.com/c/1296229
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56887}
In the ElementsAccessor fast-path for Array.prototype.includes, we
iterate backing-store elements according to start and length numbers
which might or might not be within the JSArray::length field, for
example when side-effects changed the receiver while start and length
are computed. So even when we have a packed ElementsKind, we might still
observe the hole. This is fine, since logical out-of-bounds accesses
are safe in this case, but it means we must not rely on the
ElementsKind telling us if we can encounter holes.
Bug: chromium:897098
Change-Id: I17db38246aef6edbdd5cee30598cbf7619aba6d8
Reviewed-on: https://chromium-review.googlesource.com/c/1293571
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56884}
With async_hooks it's also possible that the "current microtask" is an
await task, whose generator is already suspended, when there's an
exception thrown in the AFTER callback. In that case we cannot build
a meaningful async stack trace.
Bug: chromium:897406, v8:7522
Change-Id: I682dc1fc3ebb1864e1c2061041ff99ced0313f0c
Reviewed-on: https://chromium-review.googlesource.com/c/1292057
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56839}
In the process:
- add volatile types for FastJSArray and remove the length_fast accessor
from JSArray with the application of more rigorous typing.
- add micro benchmarks for testing all the interesting slice cases
Also update a few assorted places in .tq code to make them more
idiomatic.
The original version of this patch had an overly agressive assert that has
been loosened.
TBR=jgruber@chromium.org
Change-Id: I56870862f4b124d1b38372daa326182a526c874c
Reviewed-on: https://chromium-review.googlesource.com/c/1291375
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56829}
This reverts commit 41ba3d3eb0.
Reason for revert: Speculative revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Fuzzer/27370https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20predictable/19895
Original change's description:
> [builtins] Implement Array.prototype.slice in Torque
>
> In the process:
>
> - add volatile types for FastJSArray and remove the length_fast accessor
> from JSArray with the application of more rigorous typing.
> - add micro benchmarks for testing all the interesting slice cases
>
> Also update a few assorted places in .tq code to make them more
> idiomatic.
>
> Change-Id: I76ec2bb25b65a869180af1f7288419dc1f0a9c37
> Reviewed-on: https://chromium-review.googlesource.com/c/1281603
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56806}
TBR=danno@chromium.org,jgruber@chromium.org,tebbi@chromium.org
Change-Id: I1f2c82b4c3ab0848857f620facacf9604d4fcd11
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1290973
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56815}
In the process:
- add volatile types for FastJSArray and remove the length_fast accessor
from JSArray with the application of more rigorous typing.
- add micro benchmarks for testing all the interesting slice cases
Also update a few assorted places in .tq code to make them more
idiomatic.
Change-Id: I76ec2bb25b65a869180af1f7288419dc1f0a9c37
Reviewed-on: https://chromium-review.googlesource.com/c/1281603
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56806}
When --async-stack-traces is on and there's an exception from within an
async_hook "after" handler, we will be faced with a settled promise. In
that case we cannot do anything, since the promise will not have any
reactions on it anymore, but we should also not crash of course.
Bug: chromium:896700, v8:7522
Change-Id: I6e3d212d0433da40740489ff7421c5a98cf9bff3
Reviewed-on: https://chromium-review.googlesource.com/c/1290550
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56801}
When creating the buffer for the fall back, the initial entry was not
considered when calculating the size.
Bug: chromium:896181
Change-Id: I7f15bb1bdf31b3255db91b1fe8dcd68c76033980
Reviewed-on: https://chromium-review.googlesource.com/c/1286957
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#56768}
Properly handle the case where the CheckFloat64Hole becomes a
no-op after RETYPE (because the feedback type is already Number).
We always need to pass the Number restriction type here.
Bug: chromium:895199
Change-Id: I96a949ba35db1e6d35abedddc4507c101d95b716
Reviewed-on: https://chromium-review.googlesource.com/c/1278804
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56622}
This fixes the typing for the case when the call is not lowered to
the simplified operator.
Bug: chromium:880207
Change-Id: Icecf12de77ece0fe9ffec2777874f5f0004a1e97
Reviewed-on: https://chromium-review.googlesource.com/c/1278642
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56621}
On ia32, we were pinning too many registers, resulting in no unpinned
byte registers left (we only have three byte registers since {ebx}
is reserved for the root register).
It turns out that on most paths, we don't actually need to pin any
registers, since {Store} is often the last call for an operation (like
any store or set_global). If registers need to be pinned, only pass
those that must be kept alive across the {Store}. This allows to
compute a more narrow set of pinned registers on demand inside {Store}.
Plus minor drive-by changes.
R=titzer@chromium.org
Bug: chromium:894374, chromium:894307, v8:6600
Change-Id: Ic4d7131784c193dc7a2abf0e504d9973f6d5c5f1
Reviewed-on: https://chromium-review.googlesource.com/c/1275819
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56587}
Use naming similar to the spec: "table" instead of "function table",
"element segment" instead of "function table init".
Change-Id: Ib1b6cdfa566f8bd00017ccedf9440084204f10ff
Reviewed-on: https://chromium-review.googlesource.com/c/1273612
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56545}
This reverts commit 471fef0469.
Reason for revert: A more general fix incoming at https://crrev.com/c/1273095.
Original change's description:
> [coverage] change block range to avoid ambiguity.
>
> By moving the block range end to left of closing bracket,
> we can avoid ambiguity where an open-ended singleton range
> could be both interpreted as inside the parent range, or
> next to it.
>
> R=verwaest@chromium.org
>
> Bug: v8:8237
> Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
> Reviewed-on: https://chromium-review.googlesource.com/1254127
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56347}
TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8237
Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834
Reviewed-on: https://chromium-review.googlesource.com/c/1273096
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56513}
Now duplicate parameter detection depends on tracking of unresolved references.
This also fixes finding duplicate parameters of arrow functions nested in other
arrow functions.
Change-Id: I644bfdc513244637345c1069e5c7e5fde713da63
Reviewed-on: https://chromium-review.googlesource.com/c/1270578
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56467}
The RNG state is initialized with random_seed parameter that usually
has lots of zeros. Each random generation iteration shuffles bits with
xor operation over the state. It takes a while before the state is populated
with enough 1s and starts generating uniformly distributed numbers.
The patch warms up the state with 32 iterations when --random_seed is used.
BUG=v8:8265
Change-Id: I7a4e8c842962bea0f2935c7b3673494367d8580f
Reviewed-on: https://chromium-review.googlesource.com/c/1263816
Commit-Queue: Alexei Filippov <alph@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56418}
For each intrinsic/runtime function we define in runtime.h, an inline
version is automatically declared. We only ever use 24 of the inline
functions. Even though we don't call the other ones, macro magic means
they still take up space by existing in various arrays and tables like
kIntrinsicFunctions. They also create code in switch statements.
Some drive-by cleanups:
- Remove the switch in NameForRuntimeId() and just use the table of
runtime functions to lookup the name directly.
- Remove tests for IsFunction, ClassOf and StringAdd intrinsics as
they are the last users of the inline versions of these.
- Remove the MaxSmi inline version as it is only used in tests.
Saves 64 KiB binary size.
Change-Id: I4c870ddacd2655ffcffa97d93200ed8f853752f5
Reviewed-on: https://chromium-review.googlesource.com/c/1261939
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56412}
For --async-stack-traces don't try to peak into frames that don't belong
to async functions/generators, specifically don't try to peak into some
arbitrary builtin frames (the FrameInspector doesn't support that).
Bug: chromium:892472, chromium:892473, v8:7522
Change-Id: Idcdee26ff958c03b24dd2910bb92fc51cbc14e3c
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1264276
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56396}
When converting a Signed32\/MinusZero value from Word32 to Float64
representation or just passing it through as Word32 (with potential
type checks on it) we don't need to worry about -0 as long as the uses
identify 0 and -0.
Drive-by-fix: Fix the CheckChange() helper in the representation
changer test to pass Truncation::Any() by default.
Bug: chromium:891639, chromium:891612, chromium:891627, v8:8015, v8:8178
Change-Id: I06948ec0cdb8e778cb3678124ef927277a5f40ee
Reviewed-on: https://chromium-review.googlesource.com/c/1258902
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56369}
By moving the block range end to left of closing bracket,
we can avoid ambiguity where an open-ended singleton range
could be both interpreted as inside the parent range, or
next to it.
R=verwaest@chromium.org
Bug: v8:8237
Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
Reviewed-on: https://chromium-review.googlesource.com/1254127
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56347}
Delay the creation of FunctionNameVariables until we validated the
FormalParameters. This is needed so we don't declare them in cases where
we later get an error, have to reset, and reparse.
Bug: chromium:890553, v8:7926
Change-Id: I742e6f7f71158e3903843bd583dc7943468c18f6
Reviewed-on: https://chromium-review.googlesource.com/1254061
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Florian Sattler <sattlerf@google.com>
Cr-Commit-Position: refs/heads/master@{#56314}
The representation changer was lacking support for directly converting
Word64 values to Bit representation.
Bug: chromium:890243, v8:4153, v8:7881, v8:8171, v8:8178
Change-Id: I5fa31716c7b2b10ad00dc31d5035a1ada152661c
Reviewed-on: https://chromium-review.googlesource.com/1251551
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56304}
- Add a new broker mode kRetired, in which the heap can
again be accessed.
- Change the way modes work. We now always start in kDisabled.
If FLAG_concurrent_compiler_frontend is on, we eventually move
to kSerializing, then to kSerialized, then to kRetired.
- Add an ObjectDataKind to ObjectData that indicates whether the
data is just a dummy (i.e. created while broker was in kDisabled
mode).
This also happens to fix a bug found by clusterfuzz.
Bug: v8:7790, chromium:889722
Change-Id: I38833fe7ad26d2d3efb15ba560576defb82f673a
Reviewed-on: https://chromium-review.googlesource.com/1245425
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56260}
I moved AnalyzePartially from ParseFunctionLiteral to SkipFunction, but arrow
functions only used the ResetAfterPreparsing part.
Bug: chromium:888825
Change-Id: I08de99af128b28031df6ed86a725e4dc918078f8
Reviewed-on: https://chromium-review.googlesource.com/1243383
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56218}
When constructing a TypedArray by length, only actually setup the
JSTypedArray instance once the buffer is allocated, as only at that
time it's known whether the byte length is fine. Otherwise we confuse
the heap verifier.
Bug: chromium:887891
Change-Id: I407ff9a2a053dd11ef764e4e32f482abb27eb0a8
Reviewed-on: https://chromium-review.googlesource.com/1238494
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56131}
The order in which ToNumber(left) and ToPrimitive(right,hint Number)
is called when performing an abstract relational comparison is
observable, and we need to make sure to trigger the conversions in
the correct order.
Bug: chromium:687063
Change-Id: Idc9edb99643c4cf1774b89dcdc319ed5dc7cdc8a
Reviewed-on: https://chromium-review.googlesource.com/1236557
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56125}
Previously we only supported strings and not filenames. This
changes the default to filename and adds a new `type: string` which can
be passed `options` to allow for strings to be passed in test code.
See: https://developer.mozilla.org/en-US/docs/Web/API/Worker/Worker
Bug: v8:8020
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie8818885c5c5c071b6614852322cb45aeb01a647
Reviewed-on: https://chromium-review.googlesource.com/1185980
Commit-Queue: Sam Clegg <sbc@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56056}
The JSTypedArray instance is created early on in the TypedArray
constructors, using EmitFastNewObject, which puts Undefined into
all slots. But the code might still produce an exception afterwards
leaving the JSTypedArray in a weird state. It's not a security issue
since the object doesn't escape, but it confuses the heap verifier.
Bug: chromium:885404, v8:4153, v8:7881, v8:8171
Change-Id: I5fb8131fcae69edf4a92602ed477dca305c3d6c7
Reviewed-on: https://chromium-review.googlesource.com/1233257
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56019}
This is the next step to support large array buffers. On 64-bit archs
the full safe integer range is available (up to 2^53-1 bytes in theory).
On 32-bit platforms the full Unsigned31 range is allowed, so that we can
continue to use CheckBounds for typed arrays and data views in the
optimizing compiler (it's generally unlikely that the kernel will give
you more than 1GiB of contiguous memory anyways).
Drive-by-fix: This introduces proper chokepoints for the byte_offset
and byte_length accesses in the CSA code, and also does some renaming
for consistency.
Bug: v8:4153, v8:7881, v8:8171
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I92a767638532ca9f86084398ce72556c5180cc6e
Reviewed-on: https://chromium-review.googlesource.com/1228377
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56008}
Word8 and Word16 representation is treated like Word32 for the sake of
TurboFan's representation selection, but this was missing from the
Word64 conversions.
Bug: chromium:884933, v8:4153, v8:7881, v8:8171, v8:8178
Change-Id: If7b69cdd02b12546d87bba0643e9ee9cb35cb299
Reviewed-on: https://chromium-review.googlesource.com/1229953
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55983}
This verifies that asm.js over the internal parameter count limit
does not crash. The internal limit is 1000 parameters, and the test
was using >3000 parameters. Reduce this down to 1005, and also
introduce a test which does not dynamically construct the string
and eval it, because the construction of this string takes time.
Mark the old test as slow in debug mode.
R=machenbach@chromium.org
BUG=v8:8165
Change-Id: Ib6ef5e1e58d3f37a71720fb59afa19464e7f2ff7
Reviewed-on: https://chromium-review.googlesource.com/1224057
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55860}
This is an unmodified reland of ece86adc6b.
Original change's description:
> [typedarray] Properly convert hole to undefined in TypedArray.from
>
> It used to call the old IterableToList, which had the wrong
> semantics for holes.
>
> Bug: v8:8133
> Change-Id: Idd5acd55a155bc43df7552135a44151bb2db38e9
> Reviewed-on: https://chromium-review.googlesource.com/1213204
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55745}
Tbr: petermarshall@chromium.org
Bug: v8:8133
Change-Id: I91c1eaf61cbcc29116e3a6cc3415f29cfba3561e
Reviewed-on: https://chromium-review.googlesource.com/1223007
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55846}
This reverts commit ece86adc6b.
Reason for revert: Potential cause of auto-roller breakage https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win10_chromium_x64_rel_ng/91864
Original change's description:
> [typedarray] Properly convert hole to undefined in TypedArray.from
>
> It used to call the old IterableToList, which had the wrong
> semantics for holes.
>
> Bug: v8:8133
> Change-Id: Idd5acd55a155bc43df7552135a44151bb2db38e9
> Reviewed-on: https://chromium-review.googlesource.com/1213204
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55745}
TBR=neis@chromium.org,petermarshall@chromium.org,dhai@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8133
Change-Id: I09b108e7844c598253fbbe02d705699c21308637
Reviewed-on: https://chromium-review.googlesource.com/1220286
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55802}
This CL fixes a bug that allowed calls to Array.p.shift on
zero-length arrays where the 'length' is read-only without throwing
a TypeError.
R=bmeurer@chromium.org, jgruber@chromium.org
Bug: chromium:882233
Change-Id: Ib129ab4c4f4f233e7bb553effa77539badfbe26e
Reviewed-on: https://chromium-review.googlesource.com/1215164
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#55746}
It used to call the old IterableToList, which had the wrong
semantics for holes.
Bug: v8:8133
Change-Id: Idd5acd55a155bc43df7552135a44151bb2db38e9
Reviewed-on: https://chromium-review.googlesource.com/1213204
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55745}
This CL implements a generic baseline version of Array.p.unshift
in Torque, enabling us to remove the JS fall-back.
The elements-accessor fast-path is still used, but the check whether
to use it is also moved to Torque.
Support for sparse JSArrays is removed.
Drive-by change: Small refactoring in builtins-array that will
get extended to other array builtins in a follow-up CL.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: v8:7624
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I7b23ce15e7b922eb333f61a408050dedec77c95a
Reviewed-on: https://chromium-review.googlesource.com/1189902
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55670}
The Math.expm1() function can actually return -0, for example in the
case that -0 is passed to it.
Bug: chromium:880207
Change-Id: If3a7a3a1fb6a18075ba0d7816687dfd831ebe293
Reviewed-on: https://chromium-review.googlesource.com/1205072
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55657}
Before, splice was implemented with a C++ fast path and a
comprehensive JavaScript version.
This impl. is entirely in Torque with a fastpath for SMI,
DOUBLE and OBJECT arrays, and a comprehensive slow path.
The same level of "sparse" array support as given by the
array.js implementation is included.
This reland addresses several issues:
* Removed "sparse" array support from splice.
* Addressed ClusterFuzz issue 876443:
The test and code that uses the fix is in this CL.
The fix in isolation can be seen here:
https://chromium-review.googlesource.com/c/v8/v8/+/1199403
* Removed dead code in elements.cc
BUG=chromium:876443, v8:8131, v8:1956, v8:7221
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1
Reviewed-on: https://chromium-review.googlesource.com/1201783
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55610}
This fixes exception creation (by the WebAssembly throw operation) so
that it is not observable by JavaScript. Internal properties are now
stored with symbol names instead of string names, which also prevents
them from being accessed or monkey-patched directly by JavaScript.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-8094
BUG=v8:8094
Change-Id: I33cb27f4373114cd4db28d9aef23560093e55242
Reviewed-on: https://chromium-review.googlesource.com/1203951
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55602}
The previous typing rules for ToNumeric and ToNumber didn't match on the
NonBigIntPrimitive input set, which causes trouble when we morph ToNumeric
nodes into ToNumber nodes, and generally lead to worse typings in the
graph, and thus worse code generation. This change improves the existing
typing rules and turns ToNumber into a chokepoint again.
Bug: chromium:879898, v8:8015
Change-Id: I4a7ff0e9c420c5dcfdb2b96884e019a5943828a4
Reviewed-on: https://chromium-review.googlesource.com/1201522
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55595}
This CL fixes an issue where getters/setters would get called on a
prototype with the wrong receiver. This happens in the pre-processing
for Array.p.sort when values get copied down from the prototype chain.
R=jgruber@chromium.org
Bug: v8:7682
Change-Id: I0d8ff1dc721c33bd721aaca54ffd357b3d2a2096
Reviewed-on: https://chromium-review.googlesource.com/1198767
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#55546}
This CL removes a regression test that was intended to check that the
maximum call stack size was not exceeded when calling Array.p.sort.
As the new sorting algorithm (TimSort) does not work recursively, this
test is no longer really necessary. It is also rather slow and causes
issues on some bots, so we remove the test.
R=mslekova@chromium.org
Bug: v8:7783
Change-Id: I5bb9693ab825fe077776fd6825688545286285fd
Reviewed-on: https://chromium-review.googlesource.com/1196511
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#55527}
This CL fixes a bug if the second argument ('from') for lastIndexOf
changes the array when its converted to an integer.
R=jgruber@chromium.org
Bug: chromium:878845
Change-Id: I8759dd19381c63f0dde1d4c5abc1b6c7291c6048
Reviewed-on: https://chromium-review.googlesource.com/1196507
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#55525}
This fixes a crash with a predicate used during stack unwinding of
WebAssembly frames during exception handling. The predicate caused an
observable side-effect in JavaScript during unwinding, code that is
inherently unhandlified and is not allowed to be observable.
The fix actually just removes the entire predicate. This is because the
updated proposal causes all JavaScript exceptions to participate in
WebAssembly exception handling, allowing modelling of "finally" language
constructs to perform cleanup independent of the embedders exception
details.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-8095
BUG=v8:8095
Change-Id: Ic03bc45e7b7f4562a431ccf910ee9ddcf558aa48
Reviewed-on: https://chromium-review.googlesource.com/1193445
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55457}
This method introduces an inherent race because it allows changing
global static flag variables from concurrently running Isolates (or
Workers). Since there are not too many use-cases left, the method in
question can be removed entirely.
R=hpayer@chromium.org
Change-Id: I9798730dd775b04f0bc83f18ed5982672e76e5d5
Reviewed-on: https://chromium-review.googlesource.com/1186731
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55392}
This CL adds a baseline implementation for Array.p.reverse in Torque,
as well as fastpaths for PACKED elements kinds.
Support for sparse JSArrays was removed.
R=jgruber@chromium.org, petermarshall@chromium.org
Bug: v8:7624
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I12900fbbb44746f1c5d36b78be826e14b88b4f69
Reviewed-on: https://chromium-review.googlesource.com/1185600
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55369}
Instead of changing the [[IteratedObject]] field to undefined to mark an
array iterator as exhausted, store the appropriate maximum value into
the [[ArrayIteratorNextIndex]] field such that the iterator will never
produce any values again.
Without this change the map check and the "length" access on the
[[IteratedObject]] cannot be eliminated inside the loop, since the
object can either be the array or undefined. Even with this change
it's still not possible immediately due to missing aliasing
information in the LoadElimination, but it paves the way for follow
up improvements. Eventually the goal is to have `for..of` as fast as
a traditional `for` loop even for really tight loops.
This CL also hardens the implementation of the ArrayIterator by using
proper CASTs and CSA_ASSERTs. The readability of the CSA builtin was
improved by utilizing proper helper functions.
Bug: v8:7510, v8:7514, v8:8070
Change-Id: Ib46604fadad1a0f80e77fe71a1f47b0ca31ab841
Reviewed-on: https://chromium-review.googlesource.com/1181902
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55261}
The RegExp replace implementation is a bit of a mess. Here, we first
try to handle parts of RegExp.p.exec, and then call directly into the
raw irregexp code (skipping RegExp.p.exec).
We got parts of this wrong: when lastIndex > string.length and the
regexp instance is sticky, two things should happen. 1. The match
should fail, and 2. lastIndex should be reset to 0. On the fast path,
we did the latter but not the former, instead running exec with a
lastIndex of 0.
This CL omits the irregexp call in this case, and defaults to a failed
match instead.
Bug: chromium:875493
Change-Id: I8c959610d267575e37686076a3fd5dfde322f0ca
Reviewed-on: https://chromium-review.googlesource.com/1180889
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55207}
This makes sure the aforementioned predicate is independent of the
current context (aka. Realm) and only uses the instance type of the
given object to determine whether it is a WebAssembly module object.
R=titzer@chromium.org
TEST=mjsunit/regress/wasm/regress-8059
BUG=v8:8059
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Icc8e400f8412483f2a3883ca65c58b7ef938ef23
Reviewed-on: https://chromium-review.googlesource.com/1180886
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55205}
Enforce both engine limitations and spec (http://asmjs.org/spec/latest/)
limitations on the size of asm.js heaps.
R=clemensh@chromium.org
CC=mstarzinger@chromium.org
Bug: chromium:873600
Change-Id: I104c23bbd0a9a7c494f97f8f9e83ac5a37496dfd
Reviewed-on: https://chromium-review.googlesource.com/1174411
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55163}
In order to know which labels are valid continue targets, we must
track the labels that immediately prefix an iteration statement.
Also document some things that I had to figure out.
Bug: v8:8033
Change-Id: Ia8288fd0e553a547aa0f9d1b4381bb103325bc3a
Reviewed-on: https://chromium-review.googlesource.com/1172292
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55110}
This is a reland of a4355b77b3
Original change's description:
> [test] Add files not pushed for test on Android
>
> TBR=neis@chromium.org
> NOTRY=true
>
> Bug: v8:8047
> Change-Id: I6d59cd9137f56a5061d836afb02b33f7b25d4aa0
> Reviewed-on: https://chromium-review.googlesource.com/1170772
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55047}
TBR=neis@chromium.org
NOTRY=true
Bug: v8:8047
Change-Id: If273d9407ed17f4de827b08039efe4d5cd34632e
Reviewed-on: https://chromium-review.googlesource.com/1171282
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55063}
This CL fixes a bug found by Clusterfuzz, in which the functions
LoadDataViewByteOffset and -ByteLength incorrectly had a return
type of TNode<Smi> instead of TNode<Number>.
This caused a CAST() call to fail when the requested byte offset
or byte length did not fit inside a Smi, i.e. when the underlying
ArrayBuffer of the DataView had a length longer than 2^30 on
32-bit platforms.
The CL also includes a new test in mjsunit to test against this.
Bug: chromium:869313
Change-Id: Ibb7d29bda5782a12c4b506c070bb03fef8c3ec70
Reviewed-on: https://chromium-review.googlesource.com/1158582
Commit-Queue: Théotime Grohens <theotime@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54900}
While working on crrev.com/c/1141045 I caused 3 assertThrows() tests
under the 'Deeply nested target' tests to fail. The tests for
defineProperty, isExtensible, and preventExtensions began to fail under
a couple build configurations because my change modified the stack check
code such that it no longer inhibited tail call optimization. Under some
build configurations the methods responsible for causing a stack oveflow
for those 3 methods were tail call optimized and the tests no longer
threw an exception.
Other built-in implementations of proxy handler methods could also fail
in the future due to refactors moving variables off the stack. Change
the test to ensure v8 doesn't crash but don't rely on stack overflow
exceptions being thrown for the 'deeply nested target' test.
BUG=chromium:864705
Change-Id: Iefeaa1d5402986c1831d0f259f83025452756387
Reviewed-on: https://chromium-review.googlesource.com/1159356
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54878}
The original implementation of 'testAsync' in mjsunit.js required to
put the call to '%AbortJS' into an 'eval' statement. The reason is that
this call requires the flag --allow-natives-syntax to be set, but the
flag is not set in all mjsunit tests. With the use of 'eval'
compilation errors can be avoided.
The problem with this approach was that the fuzzer started to produce
test cases which include the line 'eval("%AbortJS(message)");', and
this line crashes intentionally. Different to the line
'%Abort(message)', however, the 'eval' statement cannot be filtered
so easily in the fuzzer. Therefore I pulled the implementation of
'testAsync' into a separate file to avoid the 'eval'.
Additional changes: I use '===' now instead of 'deepEquals' in
AsyncAssertion.equals because 'deepEquals' is not available outside
mjsunit.js. Using '===' seems more appropriate anyways because for
all tests but one it is sufficient, and it is more precise than
deepEquals.
R=gsathya@chromium.org
Bug: chromium:774841
Change-Id: I47270aa63ff5a1d6aa76a771f9276eaaf579c5ac
Reviewed-on: https://chromium-review.googlesource.com/1156598
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54833}
The ToBigInt conversion can have side effects, so the check for
neutered-ness must happen afterwards.
Bug: chromium:867776
Change-Id: I6e550c77a284da4cf132c21a6c3b1ed8f34eedc9
Reviewed-on: https://chromium-review.googlesource.com/1153553
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54761}
The CSA fast path returned null for Proxy.prototype whereas runtime GetProperty
returned undefined. The CL fixes this discrepancy by returning undefined for
both cases and this makes it complaint with the spec.
Change-Id: I35b75c09dc99e8fd629671e30eacd2cabea8c1d4
Reviewed-on: https://chromium-review.googlesource.com/1145438
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#54745}
If an exception is thrown in instrumented async code, for instance
await import('non-existing-module')
it should be correctly reported by the hooks that run around this code.
Also calling ToLocalChecked() on the hook result is wrong if the hook
has thrown an exception.
Bug: chromium:865892
Change-Id: I5712376fe4426a3e49223d821e4647150887a258
Reviewed-on: https://chromium-review.googlesource.com/1146561
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54610}
This is a reland of 9eca23e9ed
Adds a deopt continuation, which fixes JavaScript stack traces
to contain the number constructor after inlining.
Original change's description:
> [turbofan] Inline Number constructor in certain cases
>
> This CL adds inlining for the Number constructor if new.target is not
> present. The lowering is BigInt compatible, i.e. it converts BigInts to
> numbers.
>
> Bug: v8:7904
> Change-Id: If03b9f872d82e50b6ded7709069181c33dc44e82
> Reviewed-on: https://chromium-review.googlesource.com/1118557
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54454}
Bug: v8:7904
Change-Id: Ic416e5ba81fa3a0f59ae4afa80df83c46a759487
Reviewed-on: https://chromium-review.googlesource.com/1146581
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54609}
This CL changes Array.p.fill to use the baseline implementation
for everything other than JSArray.
One of the reasons is that shadowing the length property on
TypedArrays (and other ElementsKinds) is allowed and should be
respected by Array.p.fill. The fast-path for fill for TypedArrays
expects the indices to be clamped to the actual length of the
underlying backing store and not to some length property.
While this mismatch (and others) could probably be handled properly,
we do the conservative thing and only use the fast-path for specific
JSArrays.
R=jgruber@chromium.org
Bug: chromium:865312
Change-Id: Ib3050e3bfc22d47ca8597b6df34788dc2b59b6e1
Reviewed-on: https://chromium-review.googlesource.com/1142772
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#54558}
i32 stack parameters can be loaded by Turbofan as 64-bit value, hence
they would not be zero extended. If this loaded value is then passed to
Liftoff (which assumes zero-extended i32 values), we could use it for
memory accesses, which would be out of bounds.
R=mstarzinger@chromium.org
Bug: chromium:864509, v8:6600
Change-Id: I0f45a269b1fb1c2befc2e6bc660c559a88323767
Reviewed-on: https://chromium-review.googlesource.com/1140168
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54500}
The instruction selector currently sometimes emits a lea32 with an
offset of 0, which the code generator just ignores (emits no code at
all). This can result in the result of TruncateInt64ToInt32 to not be
zero extended.
This CL fixes that by disallowing lea32 instructions with 0 offset, and
fixing the instruction selector to generate a movl or just no code for
that case.
R=jarin@chromium.org
Bug: chromium:863810, v8:7947
Change-Id: I1b21fc5f0fda9ca3144917538c3d0bbf46601c33
Reviewed-on: https://chromium-review.googlesource.com/1137825
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54489}
This removes an occurrence where the "%Foo" native syntax appears as part
of a string. Such strings are picked up by the fuzzer and recombined in
unsupported ways, producing false-positive crash reports. Simply avoid
having those strings in the fuzzing corpus.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-808848
BUG=chromium:844842
Change-Id: I017c1552578f0d26033e58b11353e87e27a69ebf
Reviewed-on: https://chromium-review.googlesource.com/1136300
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54432}
When we changed FeedbackMetadata to be it's own type instead of a
subtype of FixedArray, we missed this check for valid objects in old
space. This restores the old behavior during verification.
Bug: chromium:862433
Change-Id: Icdb144df4aebc0c6d78a28405c7f53e40b2e1376
Reviewed-on: https://chromium-review.googlesource.com/1134995
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54408}
After liveedit removed - we do not need this context any more.
R=yangguo@chromium.orgTBR=clemensh@chromium.org
Bug: v8:5530
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Idb43d016d51b8048f6cd2ca590fd7510abcacb49
Reviewed-on: https://chromium-review.googlesource.com/1106802
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54273}
Fixes V8 correctness failure when there's a proxy in the global object
prototype chain and unsuccessful attempt is made to access a property.
Bug: chromium:849024
Change-Id: I829e1a6c038982b7c7a77f8bdefb61facb4614f0
Reviewed-on: https://chromium-review.googlesource.com/1124446
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54237}
We need to push the sign-extended constant instead of just the lower 32
bits. Otherwise, the callee might read stale data from the stack.
Bug: chromium:854011, v8:6600
R=ahaas@chromium.orgCC=rodolph.perfetta@arm.com
Change-Id: Iafcfd6ba9532771615b41215fb4d1a2b85ce5623
Reviewed-on: https://chromium-review.googlesource.com/1124683
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54185}
This CL adds a regression test that will check that the elements
pointer is properly reloaded after the JavaScript comparison
function is called during Array.p.sort.
R=jgruber@chromium.org
Bug: chromium:859809
Change-Id: I15f55fcc1906bd8d0751596e5457367a643b92da
Reviewed-on: https://chromium-review.googlesource.com/1124475
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54174}
This CL changes the NumberDictionary fast-path for Array.p.sort to
throw a TypeError when trying to write to a read-only property.
Previously, the fast-path simply bailed to the slow-path which could
swallow the TypeError by accident. I.e. because the fast-path could
leave the array in an inconsistent state that is already sorted.
Example:
let arr = new Array(10);
Object.defineProperty(arr, 0, {value: 2, writable: false});
Object.defineProperty(arr, 2, {value: 1, writable: false});
arr.sort();
The pre-processing step will move the value 1 to index 1: {0: 2, 1: 1}
When trying to swap those 2 values, the fast-path will write the 2 at
index 1, then try to write the 1 at index 0 and fail, bailing to the
slow-path. As the array looks like {0: 2, 1: 2} its already sorted
and the TypeError will not be thrown.
R=jgruber@chromium.org
Bug: v8:7382, v8:7907
Change-Id: I5d2f2d73478fdca066ce1048dcb2b8301751cb1f
Reviewed-on: https://chromium-review.googlesource.com/1122120
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54150}
For spread calls with arrays with double elements but zero length,
we skip the box-as-heapnumber step; so in this corner case the
Call builtin sees a FixedDoubleArray, which is fine because it
doesn't read any of the raw double values from it.
This patch doesn't change the implementation, it only updates the
assert to match reality.
Bug: chromium:856095
Change-Id: I0227f4ccbc6c61c8f5f7669a266ef7a64c6a9a43
Reviewed-on: https://chromium-review.googlesource.com/1117922
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54149}
When parsing a numeric literal in a line like "a=0x0e+b|0;",
currently the scanner consumes the "e+" part (as it thinks
it's the start of an exponent).
In the ECMAScript lexical grammar HexIntegerLiteral cannot
contain exponents, which means the '+' character should be
parsed as a binary operator.
R=bradnelson@chromium.org
BUG=v8:7893
Change-Id: I97a0d4ea2ee1d38a3462efbfaef5eb87b8ea704b
Reviewed-on: https://chromium-review.googlesource.com/1116551
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54132}
This CL fixes the NumberDictionary fast-path in Array.p.sort, when
storing to a read-only property that was never read from.
R=jgruber@chromium.org
Bug: v8:7907
Change-Id: I2b772fb5b1619a94a7d239ba4417ecb7902a167c
Reviewed-on: https://chromium-review.googlesource.com/1119910
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54109}
This is a reland of ada648006b, fixed
for 32 bit architectures (register pairs).
Original change's description:
> [Liftoff] Fix register use count
>
> In {SetLocalFromStackSlot}, we decrement the use count of the register
> in the target slot without updating this slot, and then call
> {GetUnusedRegister}. At that point, the register use counts do not
> match the cache state, which leads to errors later on.
> This CL fixes this by marking the target slot as a stack slot after
> reducing the register use count.
>
> It also adds a Validation which helped to find that error and will
> catch similar errors earlier.
>
> R=titzer@chromium.org
>
> Bug: chromium:854050, v8:6600
> Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
> Reviewed-on: https://chromium-review.googlesource.com/1111958
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53976}
TBR=titzer@chromium.org
Bug: chromium:854050, v8:6600
Change-Id: Ibc8801737e9604a8490382c569b0378585625376
Reviewed-on: https://chromium-review.googlesource.com/1112238
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53981}
This reverts commit ada648006b.
Reason for revert: Failure with slow dchecks: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/20982
Original change's description:
> [Liftoff] Fix register use count
>
> In {SetLocalFromStackSlot}, we decrement the use count of the register
> in the target slot without updating this slot, and then call
> {GetUnusedRegister}. At that point, the register use counts do not
> match the cache state, which leads to errors later on.
> This CL fixes this by marking the target slot as a stack slot after
> reducing the register use count.
>
> It also adds a Validation which helped to find that error and will
> catch similar errors earlier.
>
> R=titzer@chromium.org
>
> Bug: chromium:854050, v8:6600
> Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
> Reviewed-on: https://chromium-review.googlesource.com/1111958
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53976}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: I5b8d8d405dcd7f82ee431cba290419425b9859a1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:854050, v8:6600
Reviewed-on: https://chromium-review.googlesource.com/1112277
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53979}
In {SetLocalFromStackSlot}, we decrement the use count of the register
in the target slot without updating this slot, and then call
{GetUnusedRegister}. At that point, the register use counts do not
match the cache state, which leads to errors later on.
This CL fixes this by marking the target slot as a stack slot after
reducing the register use count.
It also adds a Validation which helped to find that error and will
catch similar errors earlier.
R=titzer@chromium.org
Bug: chromium:854050, v8:6600
Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
Reviewed-on: https://chromium-review.googlesource.com/1111958
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53976}
Cleanup decoding of flags so that invalid flags for sections other than
memory are caught correctly.
Bug: chromium:853453
Change-Id: Ia347d5f7672eee93ca3f6a743f06fba629f55cb5
Reviewed-on: https://chromium-review.googlesource.com/1104976
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53972}
This CL fixes a bug where execution would continue on a fast-path
even though a previous recursion step bailed to the slow path. This
would allow possibly illegal loads that could leak to JS.
Drive-by change: Instead of bailing to the slow-path on each recursion
step, we now bail completely and start the slow-path afterwards.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: chromium:854299, v8:7382
Change-Id: Ib2fd5d85dbd0c3894d7775c4f62e053c31b5e5d1
Reviewed-on: https://chromium-review.googlesource.com/1107702
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53892}
This CL fixes a bug that allowed OOB read/stores on fastpaths when
a comparison function caused the underlying FixedArray to change
while keeping the elements kinds and size property on the original
JSArray the same.
R=jgruber@chromium.org
Bug: chromium:852592
Change-Id: I09af357d10e7f41e75241e4c87430fc9aa806f8c
Reviewed-on: https://chromium-review.googlesource.com/1104158
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53811}
Reading up on the bug description, this is a test
that is triggered by TurboFan execution. This can
be done with natives and does not need excessive
loop iterations. Additionally, we have a more specific
regression test for the original issue in the repo:
http://crrev.com/c/584837
Bug: v8:7783
Change-Id: Id022b515b663e6fb897acb29f43ef92b70b547b8
Reviewed-on: https://chromium-review.googlesource.com/1101018
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53799}
Byte offset can be outside of Smi range and must be loaded as a Number
rather than a Smi.
Bug: chromium:852258
Change-Id: Ida6e07ba68a050d4f5a9f28500986cc67c619b4c
Reviewed-on: https://chromium-review.googlesource.com/1100886
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53748}
`date` could be outside the int32_t range and thus FastD2I may not be
used.
Bug: chromium:849663
Change-Id: I96a012b40d35ec8f80e449e4e687b0ce7b572d5e
Reviewed-on: https://chromium-review.googlesource.com/1087063
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53526}
Compress the parameter count (and function length) stored in
SharedFunctionInfo to a uint16_t. This limits us to 2^16 - 1 parameters
per function, minus one for the "don't adapt arguments" sentinel value,
which is one fewer than Code::kMaxArguments was already. Anyway, 65534
arguments should be enough for anyone!
This drops SFI size by 4 bytes.
Bug: chromium:818642
Change-Id: I126bfb24453dcdc5087a104d3a12cf195a56fa9f
Reviewed-on: https://chromium-review.googlesource.com/1076627
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53447}
The regression test 2185-2 measured the Array.p.sort time for various
pre-sorted data configurations. This CL adds the various data
configurations to the ArraySortPreSorted benchmark and removes the
regression test altogether.
R=cbruni@chromium.org, jgruber@chromium.org
Change-Id: I6e2eb235e4a7578f4a107229bfc6a9e89a3aa5e3
Reviewed-on: https://chromium-review.googlesource.com/1076188
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53420}
This loads references to {null} values from the instance object instead
of embedding them into the generated code. It is one step towards making
the {WasmCode} objects independent of the Isolate.
Note that this also fixes an issue with the serializer/deserializer that
failed to properly serialize {null} values and accidentally collapsed
them to {undefined} values instead.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-7785
BUG=v8:7424,v8:7785
Change-Id: Ie436c2d96890e7c8c89ffe2bd4189a759254775b
Reviewed-on: https://chromium-review.googlesource.com/1070981
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53352}
At the moment, WebAssembly.instantiate(bytes) is implemented by
desugaring it to WebAssembly.compile(bytes).then(WebAssembly.instantiate).
The problem is that the {then} in this snippet is observable. With this
CL I introduce a CompilationResultResolver which allows to do the
desugaring internally and thereby make the {then} unobservable.
Unfortunately the result of WebAssembly.instantiate(bytes) is different
than the result of WebAssembly.instantiate(module). Therefore I also
introduced an InstantiationResultResolver for symmetry with
WebAssembly.compile.
R=mstarzinger@chromium.org
Bug: chromium:837417
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2d98e03d65f2ada19041d5a9e2df5da91b24ccca
Reviewed-on: https://chromium-review.googlesource.com/1059783
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53347}
Instead use the canonical empty fixed array. Some code assumes
that this is the only fixed array of length 0.
Bug: chromium:843062
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: If780acf50147c061a81f2ff2b31779fbd1c78559
Reviewed-on: https://chromium-review.googlesource.com/1064052
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53320}
This is not web compatible, so let's delete the code.
Bug: v8:5536
Change-Id: I50506d37dcdff1f7f95577c47adcec653cc1f06e
Reviewed-on: https://chromium-review.googlesource.com/1064740
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53264}
The js-to-wasm wrappers are shared across instances, so we cannot
directly call the instance-specific wasm-to-js wrappers. Instead, we
need to call via the import table.
R=titzer@chromium.org
Bug: chromium:843563
Change-Id: Ia882604f6769472fe2eb69176cbed728215ced29
Reviewed-on: https://chromium-review.googlesource.com/1064610
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53254}
It is possible for user code to modify fast regexp result objects
before they are used e.g. by RegExp.p.match, so we may not make any
assumptions about their contents. The only exception is when the
RegExp itself is fast.
Bug: chromium:843022
Change-Id: I14eafbdfb2b2ced609da1391b57c73cbe167f7fb
Reviewed-on: https://chromium-review.googlesource.com/1061455
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53210}
Array.indexOf accepts an optional fromIndex argument. When non-negative,
this argument restricts the searched indices to those starting at
fromIndex:
[1, 2, 1].indexOf(1,1) == 2
When negative, it is meant to be added to the array length to provide
such initial index for the search:
[1, 2, 1].indexOf(1, -2) == 2
This transformation has been done by the non-optimised builtin but not
by the reducer. The CL adds this construction to the reducer.
Bug: chromium:842612
Change-Id: I0ff089997f4ebb4dc3c2923e52c382a8a96cd711
Reviewed-on: https://chromium-review.googlesource.com/1059628
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53197}
The clusterfuzz issue crashes because VisitBinops expected only but 4
input operands but in the generated graph 5 input operands get created
The issue is fixed by increasing the size of the input operand buffer.
R=jarin@chromium.org
Bug: chromium:842501
Change-Id: I4bbb09a968e165e6f5a0a02d06eee97333f7aa38
Reviewed-on: https://chromium-review.googlesource.com/1056989
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53147}
We must not accept something of kBit representation as of
kWord32 representation (unless it's truncated accordingly).
Deopt instead.
Bug: v8:7740
Change-Id: Ib4f73600d66f8762a6e22f7ea1ce79e8ef451b34
Reviewed-on: https://chromium-review.googlesource.com/1054670
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53144}
This was already the case for 1-byte strings. This prevents crashes when
attempting to externalize such strings.
Bug: chromium:842078, v8:7464
Change-Id: I3092a6748edaf77b2689f7b6f6b949929998e508
Reviewed-on: https://chromium-review.googlesource.com/1054290
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53124}
Avoid writing NumberOfElements to HashTable when it hasn't changed as
the HashTable could be in RO_SPACE and this operation will crash.
Bug: v8:841592
Change-Id: Iffadd567fc10aa9cd13d953da81275464b16c6c0
Reviewed-on: https://chromium-review.googlesource.com/1052693
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53116}
This is a reland of e084eea628.
Undefined behavious was fixed in https://crrev.com/c/1051235.
Original change's description:
> Fix SourcePositionInfo for wasm
>
> In wasm we often don't have a SharedFunctionInfo associated with a
> compilation job, so we can't get a Script. Just print "unknown" in
> these cases (instead of crashing).
>
> R=titzer@chromium.org
> CC=herhut@chromium.org
>
> Bug: chromium:840757, v8:7738
> Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
> Reviewed-on: https://chromium-review.googlesource.com/1049632
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53080}
TBR=titzer@chromium.org
Bug: chromium:840757, v8:7738
Change-Id: If04040a33766955cfed78e7c27226dd04c3f9b9f
Reviewed-on: https://chromium-review.googlesource.com/1051266
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53111}
Plus a bit of CSA typification.
Bug: v8:7725
Change-Id: I43fea4a4c0739f9c24d84035816b046e742372ee
Reviewed-on: https://chromium-review.googlesource.com/1051653
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53102}
This reverts commit e084eea628.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20UBSanVptr/builds/3163
Original change's description:
> Fix SourcePositionInfo for wasm
>
> In wasm we often don't have a SharedFunctionInfo associated with a
> compilation job, so we can't get a Script. Just print "unknown" in
> these cases (instead of crashing).
>
> R=titzer@chromium.org
> CC=herhut@chromium.org
>
> Bug: chromium:840757, v8:7738
> Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
> Reviewed-on: https://chromium-review.googlesource.com/1049632
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53080}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: Ib2020ea3f2b778df9fe50ccbe803938f2f4fd709
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:840757, v8:7738
Reviewed-on: https://chromium-review.googlesource.com/1051265
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53082}
In wasm we often don't have a SharedFunctionInfo associated with a
compilation job, so we can't get a Script. Just print "unknown" in
these cases (instead of crashing).
R=titzer@chromium.org
CC=herhut@chromium.org
Bug: chromium:840757, v8:7738
Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
Reviewed-on: https://chromium-review.googlesource.com/1049632
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53080}
This CL implements the functionality of SafeRemoveArrayHoles (JS),
which is used as a pre-processing step for sorting, in a runtime
function.
SafeRemoveArrayHoles is a generic fallback, when an existing runtime
function fails to remove holes/move undefineds to the end of an array.
This CL extends the existing runtime function to also support JSProxy
objects, and objects where indices have accessors.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: v8:7382
Change-Id: I4881539cf2171caba08ff6e3e50320291f49839c
Reviewed-on: https://chromium-review.googlesource.com/1041950
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53060}
Since 94ce16b704, when loading an iterator from null or undefined, we
generate the error message "x is not iterable" instead of the unwieldy
"Cannot read property 'Symbol(Symbol.iterator)' of undefined". However
Runtime::GetObjectProperty, which is used as slow path by LoadICs, did
not check for this case, leading to different messages being generated
depending on IC state.
Bug: chromium:823130
Change-Id: Ie98500b97efef401aac9880b9af47d58c3c2825d
Reviewed-on: https://chromium-review.googlesource.com/1042951
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52974}
We incorrectly used a TurboFan typer check for {0,10,undefined} on the
radix argument on Number.parseInt, which was internally widened to the
checking whether radix is in range 0-10 or undefined. This CL introduces
two separate checks.
Bug: chromium:838766
Change-Id: I5ebfc1c82bad5b9794b4f844e79e4df01f541a83
Reviewed-on: https://chromium-review.googlesource.com/1039197
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52914}
A stack overflow can be thrown by JSEntryStub, which means the
thread-in-wasm flag will not have the expected value. To accommodate
this, we now clear the flag during exceptional returns if it is set.
Bug: chromium:834624
Change-Id: I8359af79886ab98dfecc2fb39ca19118b7fa38eb
Reviewed-on: https://chromium-review.googlesource.com/1019570
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52891}
When WebAssembly.instantiate or WebAssembly.instantiateStreaming is
called in JavaScript, internally we transfrom it into
WebAssembly.compile(buffer).then(WebAssembly.instantiate). However,
modifying the prototype of WebAssembly.Module can change the result of
WebAssembly.compile(buffer). With this CL we make sure that even if the
result of WebAssembly.compile is modified, there is still no type
confusion. In the long term we have to do a refactoring and remove
this internal transformation.
R=mstarzinger@chromium.org
Bug: chromium:837417
Change-Id: I376068b8b8b01b991ec450162da6a62ae7030c62
Reviewed-on: https://chromium-review.googlesource.com/1032392
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52859}
In the case of an indirect call to an imported function, the target
instance stored in the IFT was actually wrong.
Bug: chromium:834619
Change-Id: Id2ac4158335ecf2b58e1983ce37df852a9ebd1b2
Reviewed-on: https://chromium-review.googlesource.com/1030174
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52831}
WebAssembly.instantiate is polymorphic, it can either take a module
object as parameter, or a buffer source which should be compiled first.
To share code between the two implementations, the module object was
first passed to a promise (i.e. which is the result of compilation).
However, passing the module object to a promise has a side effect if
the module object has a then function. To avoid this side effect I
remove this code sharing and call AsyncInstantiate directly in case
the parameter is a module object.
R=mstarzinger@chromium.org
Bug: chromium:836141
Change-Id: I67b76d0d7761c5aeb2cf1deda45b6842e494eed4
Reviewed-on: https://chromium-review.googlesource.com/1025774
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52755}
Several functions on Array.prototype incorrectly threw a TypeError just
because their receiver was sealed or frozen.
Bug: v8:7677
Change-Id: I4ec38bfbf468f9bd676f1c0b341c8a50cf814f15
Reviewed-on: https://chromium-review.googlesource.com/1021870
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52718}
With certain ICU data bundles (such as the Node.js "small-icu"),
%GetDefaultICULocale() may return a more specific language tag (e.g.
"en-US") than what's available (e.g. "en"). In those cases, consider the
more specific language tag supported.
This CL also resolves the following Node.js issue:
https://github.com/nodejs/node/issues/15223
Bug: v8:7024
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ifda0776b3418734d5caa8af4e50c17cda95add73
Reviewed-on: https://chromium-review.googlesource.com/668350
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52716}
Throw a TypeError if the length of a concat-spreadable object makes the
total length too large, as specified.
Bug: v8:7652
Change-Id: Ie3f694d64c949703edd733c0310cfb3f64b78a15
Reviewed-on: https://chromium-review.googlesource.com/1013714
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52644}
If the new length is too large, we must throw a TypeError.
Bug: v8:7652
Change-Id: I47268c04405f7a5f5bbc971cd434f2d786af9ca1
Reviewed-on: https://chromium-review.googlesource.com/1013563
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52624}
This patch moves the desugaring from the parser to the bytecode
generator for super calls that have a spread at a non last position.
This allows us to have the post super() call behavior, such as
initializing instance fields in one place in VisitCallSuper.
Bug: v8:7642
Change-Id: I00a693beb7078a63282359c1121b66bb62c157c8
Reviewed-on: https://chromium-review.googlesource.com/1009907
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52596}
It is not safe to assume the first match is a string just
because the RegExp result is fast.
Bug: chromium:831943
Change-Id: Idd40f8b75312f0be54f45f626dc017339033abc6
Reviewed-on: https://chromium-review.googlesource.com/1009325
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#52578}
On indirect function calls, if the corresponding table entry is empty,
we cannot call {GetCodeFromStartAddress}. In that case, the signature
check will fail anyway, so perform the signature check first, and only
get the code object if the check succeeds.
R=mstarzinger@chromium.org
Bug: chromium:831463
Change-Id: Iead949e4c12502b1a2a3949db2dabab4a184a1e7
Reviewed-on: https://chromium-review.googlesource.com/1005005
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52542}
We hardcoded this accidentally in the original CL for the turbofan case,
instead we need to call JSConstructStubGeneric() which will return the
correct construct stub based on the harmony_restrict_constructor_return
flag.
Bug: chromium:829899
Change-Id: I6776a5daebd57d8881d926ad68595141312a877d
Reviewed-on: https://chromium-review.googlesource.com/1001893
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52470}
The bug was fixed in https://crrev.com/c/995796, but this CL adds a
regression test to make sure it stays fixed.
Bug: chromium:827806
Change-Id: I9f4aed364bbd310af4253da457887a8b8015533a
Reviewed-on: https://chromium-review.googlesource.com/993237
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52409}
This is a follow-up to https://chromium-review.googlesource.com/981687.
When a wasm function has a large stack frame, the x64 code generator
performs the stack overflow check before constructing the frame. This
requires the use of the `address_of_real_stack_limit` external
reference.
This reference is thread local, so if it is not relocated the stack
overflow check will always fail.
Bug: chromium:808848
Change-Id: I0edf3fe5a006242fc50d0bff44cd9dd0e7d85bd9
Reviewed-on: https://chromium-review.googlesource.com/982906
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52330}
When peeking into descriptor arrays (for Function.prototype.bind
inlining), we need to check the number of descriptors rather than
the length of the DescriptorArray.
Bug: chromium:825045
Change-Id: I55dbe1544e5e4cb8e23d873961c71ed12294d89c
Reviewed-on: https://chromium-review.googlesource.com/991812
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52315}
When a wasm function has a large stack frame, the x64 code generator
performs the stack overflow check before constructing the frame. This
requires using the `address_of_real_stack_limit` external reference, as
well as the `ThrowWasmStackOverflow` runtime function.
`ThrowWasmStackOverflow` is called via a generated trampoline, but it is
not a builtin, so the serializer adds it to the `stub_lookup_` map. This
map is encoded by using a monotonically increasing `stub_id` that starts
at 0.
When the function is serialized, a stub is differentiated from a builtin
by which half of the `i32` bits is used, upper or lower. A stub only
uses the lower 16 bits and a builtin only uses the upper 16 bits.
The deserializer checks whether the lower 16 bits are 0; if so, it is
determined to be a builtin. But if the `stub_id` is 0, then it will be
confused with builtin 0 (`RecordWrite`). Calling the builtin instead of
the stub causes a crash.
This CL starts all `stub_id`s at 1, which prevents the builtin/stub
confusion.
There is an additional bug that is not fixed by this CL:
`ThrowWasmStackOverflow` shouldn't be called at all. Currently it is
called because `address_of_real_stack_limit` is a thread-local value
that is not properly relocated.
Bug: chromium:808848
Change-Id: I06b3e650ea58ad717dcc47a3716443e16582e711
Reviewed-on: https://chromium-review.googlesource.com/981687
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52252}
--cleanup-code-caches-at-gc flag was removed in
b8b25e1c27,
rendering the test obsolete.
Change-Id: I34331d230102924899c89d3330379df51a489029
Reviewed-on: https://chromium-review.googlesource.com/980937
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52239}
This eases transition handlers caching and avoids memory overhead of
respective StoreHandler objects. In addition, it allows to use such
transition handlers on runtime side to make Object.assign implementation
a bit faster.
Bug: v8:5988
Change-Id: Iba660a11d4b300cd5f80615fb7e2608e53da8fee
Reviewed-on: https://chromium-review.googlesource.com/931701
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52187}
When using trap handlers, memory references do not get any checks inserted. This
means there is no check for a null memory as happens when the memory size is
0. Normally this would be correctly caught as an out of bounds access, since the
low memory addresses are not normally mapped. However, if they were mapped for
some reason, we would not catch the out of bounds access.
The fix is to ensure WebAssembly instances always have a guard region even if
the memory is size 0.
This is a rewrite of 5e76ff5a4a
Note that this can lead to a large amount of unnecessary address space usage,
so we share a single reservation for empty array buffers.
Bug: chromium:769637
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ia8e84be6d595e347d3d342959f2c374db1a3f683
Reviewed-on: https://chromium-review.googlesource.com/702657
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52163}
On float comparisons, we need a scratch byte register for the setcc
instruction, and if none is available, we spill. But this spilling code
is skipped if one of the operands is NaN. The cache state is updated
however, so following code assumes that the spill happened.
This CL fixes this by spilling before checking for NaN, such that the
spilling code is always executed.
R=titzer@chromium.org
Bug: v8:7582, v8:6600
Change-Id: I768d8de14e494d3ebea181c1f9f3129a4b005396
Reviewed-on: https://chromium-review.googlesource.com/973961
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52162}
See referenced bug: Async compilation can deadlock if a background task
queues the last compilation unit to be finished while the finisher
is already exiting because there was no more work.
This CL fixes this by making the finisher task check for new work after
setting the finisher_is_running_ flag to false.
R=ahaas@chromium.orgCC=kimanh@google.com
Bug: chromium:824681
Change-Id: If1f5700a9fdd5d150b36e37a5d14b692c2b0f3fb
Reviewed-on: https://chromium-review.googlesource.com/975301
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52139}
On ia32, the upper "half stack slot" must be located above the lower
half stack slot (in absolute address), hence the index is
"2 * index - 1" instead of "2 * index + 1". Note that the index
describes the negative offset from the stack pointer.
R=titzer@chromium.org
Bug: v8:7579
Change-Id: If207af405b126ab30043432d7934273e6e2a5330
Reviewed-on: https://chromium-review.googlesource.com/973301
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52116}
This avoids a deopt loop.
Bug: v8:7254
Change-Id: I3a676186bc52fd47b03f03c26cb07d9257993693
Reviewed-on: https://chromium-review.googlesource.com/968503
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52036}
This reverts commit c94dcb2117.
Reason for revert: several performances regressions.
Original change's description:
> [compiler] Don't infer receiver maps for stores.
>
> This avoids a deopt loop.
>
> Bug: v8:7254
> Change-Id: I9ab1dfc754c5ad63c451a9e2276aa1d7eb4c27b1
> Reviewed-on: https://chromium-review.googlesource.com/966065
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51994}
TBR=jarin@chromium.org,neis@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7254
Change-Id: Iff9c6fb61a559e48ad11d2db9e559de61cc0f5ef
Reviewed-on: https://chromium-review.googlesource.com/968302
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52012}
This avoids a deopt loop.
Bug: v8:7254
Change-Id: I9ab1dfc754c5ad63c451a9e2276aa1d7eb4c27b1
Reviewed-on: https://chromium-review.googlesource.com/966065
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51994}
There was a bug in spilling i64 constants, in that the half stack slot
*above* should have been filled with the high word instead of the one *below*.
Instead of just fixing this, this CL optimizes spilling x64 constants to the
stack by emitting shorter and faster code, especially if the constant fits in
31 bits (which is the majority of cases).
R=titzer@chromium.org
Bug: v8:7565,v8:6600
Change-Id: Id75ddafe82615930a84333a0c49bd515ccbcc093
Reviewed-on: https://chromium-review.googlesource.com/965062
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51985}
TurboFan assumed that the output of NumberToString is always a
sequential string, since that's what we put into the number to
string table. However we might eventually morph these strings
into ThinStrings when we need to internalize them, in which case
the type in TurboFan will be wrong, and we read out of bounds.
Also-By: tebbi@chromium.org
Bug: chromium:822284
Change-Id: I5aebe73028b95849fff72bba262c517677112353
Reviewed-on: https://chromium-review.googlesource.com/964523
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51970}
Always use the runtime to set the length on an array if it doesn't match
the expected length after populating it using Array.from.
Bug: chromium:821137
Change-Id: I5a730db58de61ba789040e6dfc815d6067fbae64
Reviewed-on: https://chromium-review.googlesource.com/962222
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51919}
During a C call, a previous value of the stack pointer is stored in a
platform specific callee saved register. Loading the out argument of the
C call might overwrite the value in that register, if the destination
register collides with the platform specific register. Hence, do first
use that register to restore the previous stack pointer, and only then
load the out argument.
Similarly, when pushing arguments to the stack, do first push all
values and then set the platform specific register in order to avoid
overwriting an argument value held in that register.
Drive-by: Fix offset computations for parameters pushed to the stack
for c calls.
R=titzer@chromium.org
Bug: chromium:820802,chromium:820896,chromium:820807,v8:6600
Change-Id: If4567467b7912454f0bd2cad5927233c98894b03
Reviewed-on: https://chromium-review.googlesource.com/959064
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51916}
The IterableToList helper builtin can return the input JSArray unchanged
if the fast-path detection decides that it doesn't need to iterate the
elements, which means we can also get a JSArray with an elements kind
that is not PACKED_ELEMENTS as a result of IterableToList.
Bug: chromium:821159, v8:7310
Change-Id: I93a886e6b7f1e1a58dd05affa46fea7501cc5a81
Reviewed-on: https://chromium-review.googlesource.com/959323
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51893}
Depending on visitation order the LoadElimination might be find memoized
nodes in its state tables that were killed by other reducers in the mean
time. The LoadElimination must just ignore those stale entries.
Bug: chromium:820820
Change-Id: Ia62e401ff77da547ed215a14074e70aeb5c3a766
Reviewed-on: https://chromium-review.googlesource.com/958843
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51892}
The lifetime of the collator is handled by the JavaScript heap. At the
moment this is implemented with a weak GlobalHandle. With this CL I
change the implementation to use a Managed object instead. In addition I
did some code cleanup.
The main reason for using a Managed is an lsan problem. The final GC in
d8 is triggered before all pending WebAssembly compilations get
canceled. Via the native context, WebAssembly compilation can keep the
Collator wrapper alive, and therefore the collator is never deallocated.
Managed, however, get processed at isolate teardown, independent of the
reachability of the Managed.
TEST=mjsunit/regress/regress-813440
Bug: chromium:813440
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie727eb1aff2144586eb36426cc44a32357c0f822
Reviewed-on: https://chromium-review.googlesource.com/956069
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51886}
On 32-bit systems, the computation {count + type_list->size()} can
overflow, leading to memory corruption later on.
R=titzer@chromium.org
Bug: chromium:819869
Change-Id: Ic81d201e58211e3989b4e945cd52e98dc951fbda
Reviewed-on: https://chromium-review.googlesource.com/955025
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51817}
When optimizing SpeculativeToNumber we need to pay attention to the
hint, otherwise we optimize away a Signed32 conversion, based on the
fact that the input is a Number.
Bug: chromium:819298
Change-Id: I2ac7b0dac708fee9083eca2880bd5674a82daaa3
Reviewed-on: https://chromium-review.googlesource.com/955423
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51805}
The optimized code for %ArrayIteratorPrototype%.next for holey arrays
was wrong, since it would first store the [[NextIndex]] and then check
whether it hit a hole. However in that case TurboFan doesn't have any
point to deoptimize to, so we need to perform the side-effecting stores
only after all checks are done.
Bug: v8:7510, v8:7514, chromium:819086
Change-Id: I0214c7124833286113e4dc7403ddc20a82fa8da3
Reviewed-on: https://chromium-review.googlesource.com/950723
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51753}
Math fast-path cannot drop arguments because their side-effects
must be preserved. For example, Math.imul(x) dropped x entirely,
because if x is convertible to an integer, the result is 0.
This, however, is not OK because converting x to an integer might
throw.
Bug: chromium:818070, v8:7250, v8:7240
Change-Id: I8363e6dcd3fc78c879395aacb636d5782c3b023e
Reviewed-on: https://chromium-review.googlesource.com/948523
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51736}
This changes the JSArrayIterator to always have only a single instance
type, instead of the zoo of instance types that we had before, and
which became less useful with the specification update to when "next"
is loaded from the iterator now. This greatly simplifies the baseline
implementation of the array iterator, which now only looks at the
iterated object during %ArrayIteratorPrototype%.next invocations.
In TurboFan we introduce a new JSCreateArrayIterator operator, that
holds the IterationKind and get's the iterated object as input. When
optimizing %ArrayIteratorPrototype%.next in the JSCallReducer, we
check whether the receiver is a JSCreateArrayIterator, and if so,
we try to infer maps for the iterated object from there. If we find
any, we speculatively assume that these won't have changed during
iteration (as we did before with the previous approach), and generate
fast code for both JSArray and JSTypedArray iteration.
Drive-by-fix: Drop the fast_array_iteration protector, it's not
necessary anymore since we have the deoptimization guard bit in
the JSCallReducer now.
This addresses the performance cliff noticed in webpack 4. The minimal
repro on the tracking bug goes from
console.timeEnd: mono, 124.773000
console.timeEnd: poly, 670.353000
to
console.timeEnd: mono, 118.709000
console.timeEnd: poly, 141.393000
so that's a 4.7x improvement.
Also make presubmit happy by adding the missing #undef's.
Bug: v8:7510, v7:7514
Change-Id: I79a46bfa2cd0f0710e09365ef72519b1bbb667b5
Reviewed-on: https://chromium-review.googlesource.com/946098
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51725}
The CHECK didn't account for the recent introduction of
StoreInArrayLiteralIC.
Bug: v8:5940, chromium:818438
Change-Id: I73b4120eb39b16d766f0b1a9cb82ba44804b09a3
Reviewed-on: https://chromium-review.googlesource.com/947950
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51719}
Table inits can contain imported functions, hence their code will be a
wasm-to-wasm wrapper.
Fix a DCHECK and add a regression test.
R=ahaas@chromium.org
Bug: chromium:817380
Change-Id: I836be589e1ae66839ccd470154c8dea488e6bc1f
Reviewed-on: https://chromium-review.googlesource.com/943107
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51685}
The assert-guarded comment claiming that ToNumber could not
possibly neuter the target array unfortunately turns out to
have been wishful thinking.
Bug: chromium:816961
Change-Id: Ib98f96f4cd7f33414c0b5a6037bfb881938cc15e
Reviewed-on: https://chromium-review.googlesource.com/939767
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51637}
This also adds a DCHECK that the buffer does not have guard pages in
MaterializeArrayBuffer because the code there does not know how correctly set up
a buffer with guard pages.
Bug: chromium:801849
Change-Id: Ic761fcdfbd16a2d6e87f4eb135f5d03b7aa2d71d
Reviewed-on: https://chromium-review.googlesource.com/938968
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51616}
