The regexp interpreter holds several unhandlified references to heap
objects, and is thus within a DisallowHeapAllocation scope. But there
are two situations in which we can and do allocate safely:
1. When creating & throwing a stack overflow exception. The interpreter
aborts afterwards, and thus possible-moved objects are never used.
2. When handling interrupts. We manually relocate unhandlified references
after interrupts have run.
This CL explicitly allows allocations on stack overflows.
Isolate::StackOverflow allocates heap objects.
Bug: chromium:940722, v8:8724
Change-Id: I74ef6f0dd7a30bd55f49a7bc0f2f6ac82adbeda8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518174
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60191}
According to the wasm js-spec, the table index can be uint32. The
implementation in our implementation expected an int though. We did not
check for the int overflow.
I replaced the throwing of the exception in WasmTableObject::Get to use
the ErrorThrower instead of throwing the exception with Isolate::Throw
directly. The reason is that I see with other CL's that I have to throw
several errors, and I don't want to introduce a new message and
MessageId for every error. Moreover, the ErrorThrower is a standard way
in wasm to throw errors. It feels right to throw the error the same way
here.
R=mstarzinger@chromium.org
Bug: chromium:940296
Change-Id: Idb77c813506fe66a3192b66fe0e8e807b80580ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514496
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60181}
When given a sticky regexp s.t. lastIndex > subject.length, the
following should happen:
1. exec returns null (= no match)
2. lastIndex is reset to 0.
This is usually done by the RegExp.p.exec builtin; but in some cases
we take different paths and try to re-implement the parts of exec that
we need.
One of these cases was in %StringReplaceNonGlobalRegExpWithFunction.
Here, we set lastIndex to 0 but then incorrectly called into
RegExpImpl::Exec. REI::Exec started matching with lastIndex == 0,
which is just plain wrong. With this CL we now correctly omit the
REI::Exec call and return null.
Bug: chromium:937681, v8:5361
Change-Id: I6bb1114a6b92ed3c6e63ec7f6ec2df4b95a19b4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514679
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60169}
It wasn't always guaranteed that they were serialized before taking the
dependency.
Bug: chromium:940361
Change-Id: Id5e5e14532809e7496546c2011176e33848506ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514495
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60156}
Emitting bytes to the Uint8Array directly speeds up generation of
binaries enormously.
On the limits-any.js spec test (which creates huge modules), the
execution time of an optdebug build reduces from 286 seconds to 61
seconds.
R=titzer@chromium.org
CC=ahaas@chromium.org, ssauleau@igalia.com
Change-Id: I5b473b7dc7b0853e54d2406f3db3658bb2abed40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1508352
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60096}
Fixing a few float and int overflows.
Drive-by fix: with --experimental-wasm-bigint, Number values
may not be used to initialize i64-typed globals. The existing
code for doing that relied on UB; since it's a spec violation
the fix is to throw instead.
No regression test for 933103 because it will OOM anyway.
No regression test for 932896 because it would be extremely slow.
Bug: chromium:927894, chromium:927996, chromium:930086, chromium:932679, chromium:932896, chromium:933103, chromium:933134
Change-Id: Iae1c1ff1038af4512a52d3e56b8c4b75f2233314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1495911
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60075}
ReduceJSHasProperty was always passing STANDARD_LOAD instead of using the load mode from
the feedback verctor. This was causing deopt loops when checking for out-of-bounds
indices.
chromium: 937734
Change-Id: I6de29f2c6a80bcc171cf027d47a2d1af1414b76c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1501975
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60073}
Causes flakyness in TSAN runs when flag is written by EnforceFlagImplications
and read by ConcurrentMarking.
BUG=v8:8924
Change-Id: I2b0bf0fbb678e03492d7ed13e48657de9316b700
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1505796
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60062}
This piggy-backs off similar support for lite mode, which silently skips
tests that require optimization in lite (and now jitless) modes.
Bug: v8:7777,v8:8778, v8:8885
Change-Id: I666d92685ca71682224028743f02d0cce3723135
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503758
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60057}
When a function is exported from a WebAssembly module, it is implicitly
wrapped in a WasmExportedFunction. For functions that were imports into
this module, the exported function appears like other Wasm function,
e.g. can be used in tables. When that exported function was re-imported
to another module, the logic to compute the import kind mistakenly
assumed the exported function was indeed originally a Wasm function
and tried to call it directly, instead of treating it like an imported
JS function.
R=ahaas@chromium.org
BUG=v8:8947
Change-Id: Ib8fac81fbe0f49c50cfbfb2e69d9bb60aef91fcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503632
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60031}
The original was reverted for breaking webkit layout tests:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
It also caused the following clusterfuzz failures:
chromium:935832
This was a correctness bug due to not properly handling the case of arrays with prototypes other
than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds
holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect
both in access-assembler and in Turbofan.
chromium:935932
This bug was that there was no handling for Has checks on the global object. Turbofan was emitting
code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in
debug builds but in release could show up in different places. This is the bug that caused the
webkit layout test failure that led to the revert.
Both bugs are fixed by in CL, and tests are added for those cases.
Bug: v8:8733, chromium:935932, chromium:935832
Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925
Reviewed-on: https://chromium-review.googlesource.com/c/1493132
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59958}
This is a reland of 35269f77f8
Switches on an expression that unconditionally throws would have all their
case statements dead, causing a DCHECK error in the SwitchBuilder. This
fixes up the DCHECK to allow dead labels.
Original change's description:
> [ignition] Skip binding dead labels
>
> BytecodeLabels for forward jumps may create a dead basic block if their
> corresponding jump was elided (due to it dead code elimination). We can
> avoid generating such dead basic blocks by skipping the label bind when
> no corresponding jump has been observed. This works because all jumps
> except JumpLoop are forward jumps, so we only have to special case one
> Bind for loop headers to bind unconditionally.
>
> Since Binds are now conditional on a jump existing, we can no longer rely
> on using Bind to get the current offset (e.g. at the beginning of a try
> block). Instead, we now expose the current offset in the bytecode array
> writer. Conveniently, this means that we can be a bit smarter about basic
> blocks around these statements.
>
> As a drive-by, remove the unused Bind(target,label) function.
>
> Bug: chromium:934166
> Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
> Reviewed-on: https://chromium-review.googlesource.com/c/1488763
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59942}
TBR=rmcilroy@chromium.org
Bug: chromium:934166
Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4
Reviewed-on: https://chromium-review.googlesource.com/c/1494535
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59948}
This reverts commit 35269f77f8.
Reason for revert: Fuzzer unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Fuzzer/29792
Original change's description:
> [ignition] Skip binding dead labels
>
> BytecodeLabels for forward jumps may create a dead basic block if their
> corresponding jump was elided (due to it dead code elimination). We can
> avoid generating such dead basic blocks by skipping the label bind when
> no corresponding jump has been observed. This works because all jumps
> except JumpLoop are forward jumps, so we only have to special case one
> Bind for loop headers to bind unconditionally.
>
> Since Binds are now conditional on a jump existing, we can no longer rely
> on using Bind to get the current offset (e.g. at the beginning of a try
> block). Instead, we now expose the current offset in the bytecode array
> writer. Conveniently, this means that we can be a bit smarter about basic
> blocks around these statements.
>
> As a drive-by, remove the unused Bind(target,label) function.
>
> Bug: chromium:934166
> Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
> Reviewed-on: https://chromium-review.googlesource.com/c/1488763
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59942}
TBR=rmcilroy@chromium.org,leszeks@chromium.org
Change-Id: I8118e54e0afa5e08b0a0a874c952f8a01f1c3242
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:934166
Reviewed-on: https://chromium-review.googlesource.com/c/1494534
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59947}
BytecodeLabels for forward jumps may create a dead basic block if their
corresponding jump was elided (due to it dead code elimination). We can
avoid generating such dead basic blocks by skipping the label bind when
no corresponding jump has been observed. This works because all jumps
except JumpLoop are forward jumps, so we only have to special case one
Bind for loop headers to bind unconditionally.
Since Binds are now conditional on a jump existing, we can no longer rely
on using Bind to get the current offset (e.g. at the beginning of a try
block). Instead, we now expose the current offset in the bytecode array
writer. Conveniently, this means that we can be a bit smarter about basic
blocks around these statements.
As a drive-by, remove the unused Bind(target,label) function.
Bug: chromium:934166
Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
Reviewed-on: https://chromium-review.googlesource.com/c/1488763
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59942}
This was an oversight in my previous CL.
Bug: chromium:936077, v8:7790
Change-Id: Ic1034c1754d10c72df8f61d1e2c34333e1565e3e
Reviewed-on: https://chromium-review.googlesource.com/c/1491222
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59923}
Bytecode flushing can make tests using assertOptimized flaky if the bytecode is
flushed between marking and optimization. It can also be flaky if the feedback vector
is collected before optimization. To prevent this, a new %PrepareForOptimization
runtime-test function is added that hold onto the bytecode strongly until it is
optimized after being explicitly marked for optimization by %OptimizeFunctionOnNextCall.
BUG=v8:8801,v8:8395
Change-Id: Idbd962a3a2044b915903f9c5e92d1789942b5b41
Reviewed-on: https://chromium-review.googlesource.com/c/1463525
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59914}
We didn't update the arguments count properly when changing the JSCall
node to a direct Call node.
Bug: chromium:936302, v8:8895
Change-Id: I59a39a07e41151d8eaa2e1a1ea7b1835e00fb501
Reviewed-on: https://chromium-review.googlesource.com/c/1491191
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59885}
We somehow forgot to thread through the VectorSlotPair for the CALL_IC
based speculation feedback to CheckedTaggedToTaggedPointer. This was
showing for example with `String#concat()` where we ended up with an
endless deoptimization loop if the parameter was a Smi.
Bug: v8:8913
Change-Id: I84d90403f6fada9b435d4eb71c689edc3c34dc86
Reviewed-on: https://chromium-review.googlesource.com/c/1488770
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59871}
Template objects should be cached after they are first created and reused on
subsiquent calls to tag functions. Currently these cached objects are stored
on the feedback vector, which has appropriate lifetime, however with bytecode
flushing the feedback vector could be cleared when the bytecode is flushed,
causing the template object to be dropped.
In order to retain the cached template objects in the face of bytecode flushing,
this CL adds a weakmap for each native context that is (weakly) keyed by
shared function info, and holds a linked list of cached template objects
associated with that shared function info, indexed by feedback vector slot id.
Misses will check this weakmap, and if no entry is found, a new template object
is created and added into this weakmap alongside the feedback vector.
BUG=v8:8799,v8:8799,v8:8395
Change-Id: Ia95d5cfc394ce58dc9fe6a1e49780f05299acc17
Reviewed-on: https://chromium-review.googlesource.com/c/1477746
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59818}
This merges all the possible targets for 'member expressions' previously
parsed in ParseMemberExpression into ParsePrimaryExpression; since that's
not independently used anyway. This will make it faster since we don't
need to go through unnecessary branches before ParsePrimaryExpression on
the fast path, *and* it will make the binary smaller since
ParseMemberExpression is inlined but ParsePrimaryExpression is not. It
saves 4kb. Yay :)
Bug: chromium:913222
Change-Id: Ib92e1c2a128fffff1db85b625bb5f311ec8c24ef
Reviewed-on: https://chromium-review.googlesource.com/c/1480379
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59814}
That way we can continue running in failure mode.
Bug: chromium:933214
Change-Id: I975901a72f615e2b7ed9955b75ce86bbcad0bbbb
Reviewed-on: https://chromium-review.googlesource.com/c/1481219
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59813}
This makes the asm.js validator reject source with trailing expressions
after the module exporting return statement. Most of the time trailing
statements would not affect semantics, since they are unreachable. In
some cases we might hide an expected ReferenceError tough.
R=leszeks@chromium.org
TEST=mjsunit/regress/regress-crbug-934138
BUG=chromium:934138
Change-Id: I790366204f5e9c943715a065b5229f2442e2c86e
Reviewed-on: https://chromium-review.googlesource.com/c/1481216
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59766}
The DCHECK verified capacity just before the call to EnsureCapacity()
(which extends capacity if needed). This DCHECK can just be removed
since FixedArray::set() already checks the given index is in-bounds.
Drive-by: Remove similar duplicate DCHECKs in FixedArrayBuilder.
Bug: chromium:933776
Change-Id: I9f058548063a170ea6dce112a3877792887efcca
Reviewed-on: https://chromium-review.googlesource.com/c/1479955
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59753}
This is a reland of c9ef0405c7
Original change's description:
> [builtins]: Optimize CreateTypedArray to use element size log 2 for calculations.
>
> TypedArrayElementsInfo now represents an element's size as a log 2 and typed as
> uintptr. This simplifies and speeds up (avoids possible HeapNumber allocations) a
> number of calculations:
>
> - Number of Elements (length) -> Byte Length - is now a WordShl
> - Byte Length -> Number of Elements (length) - is now a WordShr
> - Testing alignment (byte offset or length) - is now a WordAnd
>
> These element/byte length related calculations are encapsulated in
> TypedArrayElementsInfo as struct methods.
>
> This reduces the size of CreateTypedArray by 2.125 KB (24%) on Mac x64.release:
> - Before: 9,088
> - After: 6,896
>
> This improves the performance of the following microbencmarks
> - TypedArrays-ConstructWithBuffer: ~87%
> - TypedArrays-SubarrayNoSpecies: ~28%
>
> Bug: v8:7161
> Change-Id: I2239fd0e0af9d3ad55cd52318088d3c7c913ae44
> Reviewed-on: https://chromium-review.googlesource.com/c/1456299
> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59531}
Bug: v8:7161, chromium:932034
Change-Id: I5c3dc34c549234417f95b404e7d49b2fd496fa69
Reviewed-on: https://chromium-review.googlesource.com/c/1476306
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59728}
This is a reland of 1a3a2bc335,
fixed an infinite loop in Map::TryUpdateSlow and added
a relevant test.
Original change's description:
> Fix accessor update of non-extensible maps.
>
> When installing getter/setter of non-extensible map with existing
> setter/getter of the same name, we introduce a new transition
> (so we have two transitions with the same name!). This triggers
> an assertion in map updater.
>
> This fix carefully checks that on the back-pointer path from
> non-extensible map to the extensible map there are only
> integrity level transitions. Otherwise, we just bail out.
>
> Bug: chromium:932953
> Change-Id: I02e91c3b652428a84a9f5c58b6691ea9b1fc44d6
> Reviewed-on: https://chromium-review.googlesource.com/c/1477067
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59667}
Bug: chromium:932953
Change-Id: I015ee3795f816c8eabb5b5c5cb0ee30f365cc972
Reviewed-on: https://chromium-review.googlesource.com/c/1477675
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59715}
This removes an outdated section order check from {CreateNewBuffer} and
relies solely on the checks done in {ProcessSection}. Those checks are
more comprehensive and will remain coherent with synchronous decoding.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-8846
BUG=v8:8846
Change-Id: Id0cdc3bf3ad78f7970c9fceff66a17ab20f4666b
Reviewed-on: https://chromium-review.googlesource.com/c/1477211
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59702}
This reverts commit 1a3a2bc335.
Reason for revert: Only CL in a reverted roll (https://chromium-review.googlesource.com/c/chromium/src/+/1477147)
Original change's description:
> Fix accessor update of non-extensible maps.
>
> When installing getter/setter of non-extensible map with existing
> setter/getter of the same name, we introduce a new transition
> (so we have two transitions with the same name!). This triggers
> an assertion in map updater.
>
> This fix carefully checks that on the back-pointer path from
> non-extensible map to the extensible map there are only
> integrity level transitions. Otherwise, we just bail out.
>
> Bug: chromium:932953
> Change-Id: I02e91c3b652428a84a9f5c58b6691ea9b1fc44d6
> Reviewed-on: https://chromium-review.googlesource.com/c/1477067
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59667}
TBR=jarin@chromium.org,ishell@chromium.org
Change-Id: I9264423c605cebef87beb6c0f066e90b59faae48
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:932953
Reviewed-on: https://chromium-review.googlesource.com/c/1477219
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59680}
When installing getter/setter of non-extensible map with existing
setter/getter of the same name, we introduce a new transition
(so we have two transitions with the same name!). This triggers
an assertion in map updater.
This fix carefully checks that on the back-pointer path from
non-extensible map to the extensible map there are only
integrity level transitions. Otherwise, we just bail out.
Bug: chromium:932953
Change-Id: I02e91c3b652428a84a9f5c58b6691ea9b1fc44d6
Reviewed-on: https://chromium-review.googlesource.com/c/1477067
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59667}
We'll let the bytecode compiler and optimizing compilers deal with dead code,
rather than the ast visitors. The problem is that the visitors previously
disagreed upon what was dead. That's bad if necessary visitors omit parts of
the code that the bytecode generator will actually visit.
I did consider removing the AST nodes immediately in the parser, but that
adds overhead and actually broke code coverage. Since dead code shouldn't be
shipped to the browser anyway (and we can still omit it later in the bytecode
generator), I opted for keeping the nodes instead.
Change-Id: Ib02fa9031b17556d2e1d46af6648356486f8433d
Reviewed-on: https://chromium-review.googlesource.com/c/1470108
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59569}
Given a map, its HasNonInstancePrototype bit in bit_field can differ
from the same bit in that map's root map. If that is the case just
return false from the equivalence check. (Currently, we just assert
that bit_field is the same for a map and its root map.)
Bug: chromium:930486
Change-Id: Ic0eb83f80725fb1224e0f97927127e1cb8ad92e6
Reviewed-on: https://chromium-review.googlesource.com/c/1462004
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59508}
That way we can properly walk the active ambiguous stack of expressions and
stop where it's non-ambiguous. In the bug we would have forced context
allocation of "this" in an outer function because an inner function was parsed
as part of an arrow function head and "this" was referenced. That caused the
ambiguous arrow head scope to be marked, even though the reference came from a
non-ambiguous function.
Bug: chromium:930580
Change-Id: I0bf0fa569e2d2ca1dc26b0514fe5bdb48ab7ae6f
Reviewed-on: https://chromium-review.googlesource.com/c/1462005
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59488}
This is a reland of I968a08cef6a6d49350aa79185b2c6fb856d15f23
Original change's description:
> [builtins] [turbofan] Refactor Float64Pow to use single implementation
>
> Remove platform-specific Float64Pow implementations and utils Pow in
> favor of a base::ieee754::pow implementation.
>
> This unifies the implementation of pow for the compiler, wasm, and
> runtime.
>
> Bug: v8:5848, v8:5086
> Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
> Reviewed-on: https://chromium-review.googlesource.com/c/1403018
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59229}
Bug: v8:5848, v8:5086
Change-Id: I92f22ae03adafd9ad042e8d4bb406cbd5b5fb51e
Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/1447854
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59411}
This adds constant field tracking for arrays. To prevent changing the
field in some other elements-kind-branch of transition tree, we only
use the const information in the optimizing compiler if the map is not
an array map or if the map is stable (since stable maps cannot
transition to a different elements-kind-branch without deopt).
Some more details:
https://docs.google.com/document/d/1r2GAvdi_wudDS6iRUfdPw0gxWMfV-IX1PqKgwW47FyE
Bug: chromium:912162, v8:8361
Change-Id: Iea1b2f03ddee16205c2141ac5e813a973dd23cf4
Reviewed-on: https://chromium-review.googlesource.com/c/1454606
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59409}
This is a reland of a9e93572d4
Original change's description:
> [test] Check for illegal uses of mjsunit methods
>
> The assertThrows and assertDoesNotThrow methods expect either a
> function to execute, or a string to eval. In several tests however we
> accidentally passed the *result* of the statement to be tested instead
> of the code.
> This CL adds check to catch such error early, and removes wrong uses.
> In most places, we do not need to use assertDoesNotThrow anyway,
> because exceptions are handled as test failures.
>
> Drive-by: Unify catch syntax in mjsunit.js and make sure to propagate
> MjsUnitAssertionErrors correctly.
>
> R=mathias@chromium.org
>
> Bug: v8:8562
> Change-Id: I88894a667cbe0570774f748a9a23e8a527887a49
> Reviewed-on: https://chromium-review.googlesource.com/c/1439238
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59277}
Bug: v8:8562
Change-Id: I3b26935f7b35302d499266155273ea271bf8151d
Reviewed-on: https://chromium-review.googlesource.com/c/1449792
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59328}
If we need to allocate a DOUBLE_ELEMENTS backing store, it's important
to allow large object space allocation.
BUG: chromium:926856
Change-Id: I9dd94f7176891a6f8f11d5f579b67df8151a40b5
Reviewed-on: https://chromium-review.googlesource.com/c/1449531
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59285}
This reverts commit a9e93572d4.
Reason for revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/23956
Happened already 2 builds earlier, but the output is corrupted due to
an outage.
Original change's description:
> [test] Check for illegal uses of mjsunit methods
>
> The assertThrows and assertDoesNotThrow methods expect either a
> function to execute, or a string to eval. In several tests however we
> accidentally passed the *result* of the statement to be tested instead
> of the code.
> This CL adds check to catch such error early, and removes wrong uses.
> In most places, we do not need to use assertDoesNotThrow anyway,
> because exceptions are handled as test failures.
>
> Drive-by: Unify catch syntax in mjsunit.js and make sure to propagate
> MjsUnitAssertionErrors correctly.
>
> R=mathias@chromium.org
>
> Bug: v8:8562
> Change-Id: I88894a667cbe0570774f748a9a23e8a527887a49
> Reviewed-on: https://chromium-review.googlesource.com/c/1439238
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59277}
TBR=ahaas@chromium.org,clemensh@chromium.org,mathias@chromium.org
Change-Id: Iec06c95dd3223f27297e5c6e02835d26b5e753e7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8562
Reviewed-on: https://chromium-review.googlesource.com/c/1449634
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59284}
The assertThrows and assertDoesNotThrow methods expect either a
function to execute, or a string to eval. In several tests however we
accidentally passed the *result* of the statement to be tested instead
of the code.
This CL adds check to catch such error early, and removes wrong uses.
In most places, we do not need to use assertDoesNotThrow anyway,
because exceptions are handled as test failures.
Drive-by: Unify catch syntax in mjsunit.js and make sure to propagate
MjsUnitAssertionErrors correctly.
R=mathias@chromium.org
Bug: v8:8562
Change-Id: I88894a667cbe0570774f748a9a23e8a527887a49
Reviewed-on: https://chromium-review.googlesource.com/c/1439238
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59277}
This reverts commit 595aafeb21.
Reason for revert:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8922824501209195616/+/steps/Mozilla/0/logs/15.8.2.13/0
Original change's description:
> [builtins] [turbofan] Refactor Float64Pow to use single implementation
>
> Remove platform-specific Float64Pow implementations and utils Pow in
> favor of a base::ieee754::pow implementation.
>
> This unifies the implementation of pow for the compiler, wasm, and
> runtime.
>
> Bug: v8:5848, v8:5086
> Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
> Reviewed-on: https://chromium-review.googlesource.com/c/1403018
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59229}
TBR=yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,clemensh@chromium.org,me@gus.host
Change-Id: I266df4b8350cfcebcea8f6063ad75ad962381105
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5848, v8:5086
Reviewed-on: https://chromium-review.googlesource.com/c/1447715
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59232}
Remove platform-specific Float64Pow implementations and utils Pow in
favor of a base::ieee754::pow implementation.
This unifies the implementation of pow for the compiler, wasm, and
runtime.
Bug: v8:5848, v8:5086
Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
Reviewed-on: https://chromium-review.googlesource.com/c/1403018
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59229}
We noticed that almost every call site were loading both files,
the split isn't necessary anymore.
In some message tests, removed the absolute line number to allow future
changes.
Bug: v8:8726
Change-Id: I8527f0a1ecfa685aa01a5e2f5f47ddf1cb13a545
Reviewed-on: https://chromium-review.googlesource.com/c/1446452
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59220}
