This relands commit 1a38573f9d.
The original change used a sequence of instruction in the test that
could not be scalar lowered properly.
Original change's description:
> [arm] Change fp_fixed registers to be allocatable registers
>
> fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
> need to be allocatable, so that they can be correctly marked as fixed
> and spilled as required. The previous value of fp_fixed2, d29, is not in
> the list of allocatable double registers, and not marked as fixed
> appropriately.
>
> One fix could be to extend the list of allocatable double registers, but
> there is a comment there saying that the list is kept even-length to
> make stack alignment easier. So rather than messing with that, we
> instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
> the only user, this is a simpler change.
>
> Bug: chromium:1070078
> Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67372}
Bug: chromium:1070078
Change-Id: I02bb4b3ad03817318cbd0ee706c5ef4f20c845ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165867
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67406}
This reverts commit 390ed4b934.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/36714?
Original change's description:
> [arm] Change fp_fixed registers to be allocatable registers
>
> fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
> need to be allocatable, so that they can be correctly marked as fixed
> and spilled as required. The previous value of fp_fixed2, d29, is not in
> the list of allocatable double registers, and not marked as fixed
> appropriately.
>
> One fix could be to extend the list of allocatable double registers, but
> there is a comment there saying that the list is kept even-length to
> make stack alignment easier. So rather than messing with that, we
> instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
> the only user, this is a simpler change.
>
> Bug: chromium:1070078
> Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67372}
TBR=gdeepti@chromium.org,zhin@chromium.org,thibaudm@chromium.org
Change-Id: I00b4b34771b5832cc3d5fe6eac7aac506ec82d50
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1070078
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165865
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67375}
fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
need to be allocatable, so that they can be correctly marked as fixed
and spilled as required. The previous value of fp_fixed2, d29, is not in
the list of allocatable double registers, and not marked as fixed
appropriately.
One fix could be to extend the list of allocatable double registers, but
there is a comment there saying that the list is kept even-length to
make stack alignment easier. So rather than messing with that, we
instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
the only user, this is a simpler change.
Bug: chromium:1070078
Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67372}
If module bytes end in a prefix like 0xfc (numeric prefix), we read out
of bounds (pc + 1). So, if validate flag is set, check the length.
Bug: chromium:1073553
Change-Id: Ia9771419d01f2315723d19dd96630172b5a7a1f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161404
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67370}
The fast store handlers create elements and if we have a typed array
on the prototype chain it is not easy to check when it is OK to create
new elements. The TypedArrays swallow all OOB stores, and there is no
easy way to check if the current store is OOB for JSObjects. So use
slow stub when there are typed arrays on the prorotype chain of
JSObjects.
Bug: chromium:1068492
Change-Id: I9eea9cf00e3eb84931c5545d18ba53c4ec39f353
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134138
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67226}
SIMD opcodes consist of the prefix byte, then an LEB128 encoded int. We
were decoding this incorrectly as a fixed uint8. This fixes the decoder
to properly handle multi bytes.
In some cases, the multi byte logic is applied to all prefixed opcodes.
This is not a problem, since for values < 0x80, the LEB encoding is a
single byte, and decodes to the same int. If the prefix opcode has
instructions with index >= 0x80, it would be required to be LEB128
encoded anyway.
There are a bunch of trivial changes to test-run-wasm-simd, to change
the macro from BUILD to BUILD_V, the former only works for single byte
opcodes, the latter is a new template-based macro that correct handles
multi-byte opcodes. The only unchanged test is the shuffle fuzzer test,
which builds its own sequence of bytes without using the BUILD macro.
Bug: v8:10258
Change-Id: Ie7377e899a7eab97ecf28176fd908babc08d0f19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118476
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67186}
When we create a new elements array we should initialize it with holes.
The capacity of the newly created elements array could be greater than
the actual length of the array and we expect the unused slots to be
filled with holes.
Bug: chromium:1070560
Change-Id: Ia365eed59859e36a9c8b9e27be34f93ab88942bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150599
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67180}
In strict mode stores to non-existent properties throw. We should not
install a handler with the property cell for such stores. These handlers
would expect that the value exists when they see a property cell. If
this property cell gets invalidated later, it appears as if it is a
valid property cell with undefined value. This leads to an incorrect
behaviour. This cl checks if we are in strict mode and uses a slow
stub in such cases.
Bug: chromium:1067757
Change-Id: I543c6a6931530bfb13cc9a33d1dabaa756489fd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142255
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67151}
When memory.grow was executed concurrently on multiple threads a data
race could happen such that two memory.grow operations result in the
same return value. With this CL the return value of memory.grow is
unique, given that memory.grow actually grows the memory.
As a concrete example, assume a shared WebAssembly memory initially has
a size of 100. Assume two threads call memory.grow concurrently with a
parameter `10`. Then with the existing code, memory would grow correctly
to a size of 120, but the data race may cause both memory.grow
operations to return 100. With the change in this CL one memory.grow
operation would return 100, the other would return 110.
R=gdeepti@chromium.orgCC=rreverser@google.com
Bug: chromium:1067621
Change-Id: Ib22b5135714a56799e0818ccb39e5dce327e5f8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144113
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67135}
For example, when --fuzzing is off, %OptimizeFunctionOnNextCall now
crashes when given a non-function argument.
The following behaviors remain unchanged for now:
- %DeoptimizeFunction continues to do nothing if the function is not
optimized.
- %DeoptimizeNow continues to do nothing if the top-most JS function
is not optimized.
- %OptimizeOSR continues to do nothing if the function already has
optimized code.
Bug: v8:10249
Change-Id: I35d2f3d50ce3f94c8ffccabe50fb4df2b70ce028
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137406
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67121}
This relands commit 7d955faa76.
Changed the test case to use i16x8 splat instead of i8x16 splat,
the latter was causing issues when doing scalar lowering. This
change still causes the regression test to fail without the fix.
Original change's description:
> [wasm-simd][x64][ia32] Do not overwrite input register
>
> We are ovewriting input register (contains the shift) when we are
> masking it, instead, move to a temporary,then mask it.
>
> Bug: chromium:1065599
> Change-Id: Iab72b94581239447e444746681387350b576e24a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2125941
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66997}
Bug: chromium:1065599
Change-Id: I0dc78ddb013652ef88c07d065c3f6877937c5300
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2136220
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67026}
This is a minimal version of https://crrev.com/c/2135642 intended for
backmerges.
Ensure that the interpreter has space for all required registers.
Bug: chromium:1067270
Change-Id: Iefd016b4845fb8698d1e0ef5f6a03df0e66aa576
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137403
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67013}
This reverts commit 7d955faa76.
Reason for revert: Bad change, modified wrong test file https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/36416
Original change's description:
> [wasm-simd][x64][ia32] Do not overwrite input register
>
> We are ovewriting input register (contains the shift) when we are
> masking it, instead, move to a temporary,then mask it.
>
> Bug: chromium:1065599
> Change-Id: Iab72b94581239447e444746681387350b576e24a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2125941
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66997}
TBR=gdeepti@chromium.org,zhin@chromium.org
Change-Id: I50c57906d6eb49758584b477c971179ea3c6e5d3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1065599
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134655
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67000}
We are ovewriting input register (contains the shift) when we are
masking it, instead, move to a temporary,then mask it.
Bug: chromium:1065599
Change-Id: Iab72b94581239447e444746681387350b576e24a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2125941
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66997}
For keyed stores we recompute handlers based on the receiver maps
we have seen. This is done so that we can transition to the most generic
elements kind we have seen so far. When we recompute this handlers we
get a new prototype validity cell and ignore the existing cell. This
leads to incorrect behaviour if the cell was invalid. Recomputing the
handler may be extra work which is not worth doing at this point. So
we just reuse the existing validity cell and let the IC recompute the
handler if we see the map again.
Bug: chromium:1053939
Change-Id: Ifc891d70f5a4b8b774238e12fb40e29b4d174e37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122032
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66963}
Double literals without dots should still be parsed as double constants,
not unsigned constants. The static_cast would remove the fractional
part, making constants like "1e-15" come out as "0" unsigned constants.
The precise semantics is not spec'ed, so we still consider literals like
"1e1" to be unsigned, and only switch to double if there is a fractional
part.
R=ecmziegler@chromium.org
Bug: chromium:1065635
Change-Id: I0aac018058a149632e0849572d19fdcc7b2af7aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126922
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66949}
The ReduceStringPrototypeStartsWith implementation in TurboFan
was doing the CheckString too late, after returning "false" in
case there are no arguments.
Fixed: chromium:1065741
Change-Id: I1016383d65120d3b050e76d6ac41986497af0b8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2129639
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66948}
If "use asm" is used inside a "function*" or async function, it should
bail out.
Drive-by: Minor cleanup in {Runtime_InstantiateAsmJs}.
R=ecmziegler@chromium.org
Bug: chromium:1065852
Change-Id: Ice48126b803a30c4b4ff7b5ae22df85a3f36198a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126920
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66939}
This might help reduce flaky test results caused by too high memory
consumption due to the large Float32Array in regress-crbug-1057653.js.
Bug: v8:10333
Change-Id: Id99ebb67ebe5a7a730e44cd8967ebbea905ccdc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108547
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66836}
to properly choose named or indexed mode
Bug: chromium:1059738
Change-Id: Icd086fee31079f52770742afa54fc946acb1fd81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101005
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66702}
Move the recently introduced extra check for 32-bit platforms so
that it covers all code paths that would be hit by custom/future
memory limit settings.
Bug: chromium:1057094
Change-Id: I5e2217a24578ee82c7bfa753b7d5dcd3d00e1b7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083300
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66568}
This reverts commit b12ba06edf.
Reason for revert:
After further discussion we decided to stick with fdlibm.
Original change's description:
> [builtins] stop using imprecise fdlibm pow
>
> This CL reinstates the old pow implementation which calls out to the
> system implementation of pow.
>
> Bug: v8:9622
> Change-Id: I3df997888ced3fb8b5bd4b810098e967649aaa55
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774898
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66303}
TBR=yangguo@chromium.org,neis@chromium.org,hpayer@chromium.org,me@gus.host
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9622
Change-Id: I941f70c7432cd2fab86e0eadcb2e1a9ec8195e91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072746
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66452}
Move load splat and load extend ops into the list of SIMD memory
opcodes, since they similarly take an i32 and an memarg. This fixes the
OpcodeLength calculation in function-body-decoder-impl.h.
And in turn, fixes the mjsunit test code that the fuzzer generates. See
the regress-1055692.js file for the weird S8x16LoadSplat followed by 2
kExprUnreachable, where the kExprUnreachable really is a memarg
{0x0, 0x0}. This bug was caught by the fuzzer, and that was the
generated test (with small fixes to add kExprDrop), so leaving it as it
is.
Bug: chromium:1055692
Change-Id: I743b6beb82350b5fea22c8dd10b546a02741cfed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071401
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66439}
This is a reland of 03d5a7ba9b
Nothing changed here compared to the original test. The tests on the
blink side were invalid, I fixed them in https://crrev.com/c/2066907.
Original change's description:
> [wasm] The name of a custom section can cause a validation error
>
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
>
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
>
> R=clemensb@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}
Bug: v8:10126
Change-Id: I48aaed8eb9899da1703030fb6809fe46a6e66191
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069325
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66431}
This is a reland of 548fda4afb
regress-1054466 is modified to not use 64x2 operations, since that was
causing problems on noavx/nosse builds, which requires scalar lowering,
and scalar lowering for 64x2 ops is not implemented.
Original change's description:
> [liftoff] Check fp_pair when looking up register for reuse
>
> Given two registers that are both not gp_pair, one could be an fp_pair,
> and the other not, and we will incorrect call == on them. The current
> check needs to be expanded to check that both registers are fp_pair.
>
> Bug: chromium:1054466
> Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66402}
Bug: chromium:1054466
Change-Id: If88f1ff2fb17aaa3727758cda5b368be1c6d9bd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071396
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66423}
This reverts commit 548fda4afb.
Reason for revert: Segfault on nosse bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/35905?
Original change's description:
> [liftoff] Check fp_pair when looking up register for reuse
>
> Given two registers that are both not gp_pair, one could be an fp_pair,
> and the other not, and we will incorrect call == on them. The current
> check needs to be expanded to check that both registers are fp_pair.
>
> Bug: chromium:1054466
> Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66402}
TBR=clemensb@chromium.org,zhin@chromium.org
Change-Id: I56f13406ef3cc3793c9d0e2273c4dc5fb0e3de38
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1054466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069327
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66405}
Given two registers that are both not gp_pair, one could be an fp_pair,
and the other not, and we will incorrect call == on them. The current
check needs to be expanded to check that both registers are fp_pair.
Bug: chromium:1054466
Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66402}
Make sure the "initial pages" memory limit is enforced correctly and
throws a CompileError when exceeded.
Bump the "maximum pages" memory limit to 65536.
The --wasm-max-mem-pages flag now controls the "initial pages" limit;
the "maximum pages" limit is always 65536 as spec'ed.
This CL depends on https://github.com/WebAssembly/spec/pull/1121.
Bug: v8:7881, v8:8633
Change-Id: I68d07cef56633b8b8ce3b3d047c14e1096daf547
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035876
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66400}
An enum cache can only be referenced together with the map that owns the
entries that are needed. Otherwise the entires can be trimmed away if
the map dies because of transitions.
Bug: chromium:1050046
Change-Id: I5bc9dd65ca092c3d5ebc08ce553f6f1dc980d41b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066959
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66375}
This reverts commit 03d5a7ba9b.
Reason for revert: Needs rebaseline:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3243
Original change's description:
> [wasm] The name of a custom section can cause a validation error
>
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
>
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
>
> R=clemensb@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I5a7ea265ce47b9e685a5056bb83db6dc58f774a9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10126
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2065168
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66356}
The WebAssembly spec defines that the name of a custom section can cause
a validation error. The streaming decoder, however, used a separate
Decoder object to decode the name, and thereby avoided a validation
error. With this CL the streaming decoder uses the main decoder to
decode the name of the custom section.
In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
This test defined an invalid WebAssembly module and expected it to
compile. As it is a regression test, it makes no sense to fix the test.
The module is invalid because it defines the length of the custom section
to be '0', so there are no bytes in the custom section for its name.
R=clemensb@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10126
Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66348}
This CL reinstates the old pow implementation which calls out to the
system implementation of pow.
Bug: v8:9622
Change-Id: I3df997888ced3fb8b5bd4b810098e967649aaa55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774898
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66303}
The previous code was relying on {compilation_unit_builder_} to check if
a section was after or before the code section. This only works for the
first section after code section, since the compilation unit builder is
then reset. Use an additional field to track this instead.
R=clemensb@chromium.org
Bug: chromium:1051912
Change-Id: Id1dfa803ecde2cf77f206ea781c007fc61168942
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054099
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66265}
These tests rely on predictable opt & deopt timings. Also add the
--opt flag to tests to force optimization even in configurations that
contain the --no-opt flag.
Bug: v8:9972,chromium:1049982
Change-Id: Ic161d188ebfae9aaae6a160d365413abedfee5f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050402
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66231}
This fixes a bug in lazy deopts caused by calls to the callback function
in Array.prototype.reduce and reduceRight.
The deopt continuation expects the *next* iteration's index value but
we actually passed the current iteration's value.
The user-visible effect of this bug was that sometimes, an unexpected
additional call to the callback function would occur.
It was introduced by https://crrev.com/c/1934329.
Bug: v8:9972,chromium:1049982
Change-Id: Icfd2ef076209e20602f54d4662220e1d4c5d07ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049850
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66226}
If we need a byte register, but {src} is none, we should definitely use
another register.
R=ahaas@chromium.org
Bug: chromium:1048241
Fixed: chromium:1048241
Change-Id: I3396826986e1823250ad6855b84f4b05faaf3b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036073
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66095}
Factory::NewFunction now requires names passed into it to be flat.
Make sure to flatten Wasm function names when creating new Wasm JS
functions.
Fixes: chromium:1047368
Change-Id: I7bd2d8bc83ae8fab901ab469872bce0f703fc3ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030738
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66064}
As discussed offline, the current implementation implement each
situation separately. I think we can simplify the code a lot by sharing
code between the different paths.
This CL does that by
1) implementing the kI64Store case separately, because it does not have
all the register contraints that the others have, and
2) moving all logic to ensure that the {src} register is usable before
the switch, such that it's shared by all the compare-exchange cases.
As a side produce, this also fixes issue 1045225, because for i64 stores
which actually only use the lower half of {src}, only that half will be
pinned.
R=ahaas@chromium.org
Bug: chromium:1045225, v8:10108
Change-Id: I0be025b9706d563835ae6337d45b88e0233eacad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029414
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66062}
There was a bug in the function body decoder where
type checking of brtable only happened if the brtable
instruction is reachable. However, type checking is
required in all cases where brtable "not unreachable".
The difference between reachable and "not unreachable"
is a state called spec-reachable where a clever
compiler can already infer that the code will be
unreachable (e.g. a memory access is out of bounds
just by the offset and therefore unconditionally
traps), but the spec can not. If an instruction is
only spec-reachable, it still has to be type checked.
R=clemensb@chromium.org
FIX=chromium:1046472
Change-Id: I7e9f1108597871615c0d443a0e94de35a0207b5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66049}
Copying one object's named properties is always fine, even if one of
the names could be a large index on a TypedArray. Mark the LookupIterator
as OWN_SKIP_INTERCEPTOR to avoid the DCHECK.
Bug: chromium:1044909
Change-Id: I6918186a4b50df7865de3572cb674fd7d6eadb78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023558
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66027}
... which didn't check writability of array length on appending
a new element to an array.
Bug: chromium:1041251
Change-Id: I6935e505a4844e5b22abe9d4a42786619499daa6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023551
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66023}
The compiler assumes (for loads) that the property cell of a
non-configurable global property never gets invalidated.
Bug: chromium:1044919
Change-Id: I27f6ce30fb9a21e2c1e5310f25e9bb973ebbc266
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023562
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66021}
Converting an object to an array length can freeze the array whose
length is being set, but SetLength for the frozen elements accessor
is supposedly unreachable. This fix extends the existing special
handling for suddenly-readonly lengths to cover this case as well.
Prior art: https://codereview.chromium.org/2543553002
Bug: chromium:1044911
Change-Id: I85d2e79446a8d9c1d22cd86ddf828328bf51a1a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023555
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66020}
The actual allocatable size still depends on the allocator;
in particular Blink's ArrayBufferAllocator is currently limited
to 2GB.
WebAssembly memories are not affected by this change (i.e. still
capped at 2GB as well).
For 32-bit platforms, the limit remains at 2**30-1 (=max smi) elements.
Bug: v8:4153
Change-Id: If0d6047dd4061028688d85a3dc0a2684dcca8693
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007495
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65924}
The interpreted-frames-native-stack flag has been broken since pointer
compression was enabled. This fixes the load of the field.
Bug: v8:10138
Change-Id: I746407a7a5680c5d3e9a3b190371af00818282b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011206
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65878}
This adjusts parsing of negative numbers in UnaryExpression and
MultiplicativeExpression to return double if the token is -0.
R=clemensb@chromium.org
TEST=mjsunit/regress/regress-6838-4
BUG=v8:6838
Change-Id: I6c2113b520c3831f4a5101f0a963f49c1eb9d7d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007272
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65862}
The advance-by parameter can contain negative numbers, but until this
CL was treated as unsigned.
Bug: v8:10072,v8:9330
Change-Id: Ib9a9c2d47ba71fa819e89502d14871af6dfc9693
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002543
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65809}
When reserving the requested virtual memory fails (due to address space
exhaustion), simply return nullptr to indicate allocation failure, which
callers must be prepared to handle anyway. That way, ClusterFuzz will
correctly classify OOM situations.
Bonus change: skip demo test on simulators to save time.
Drive-by cleanup: add a 'simulator_run' section to mjsunit.status
Bug: chromium:1042151,chromium:1042173
Change-Id: I8569f3c0d2a681fbf6f91b665dcb88a4ac3b901e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002391
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65785}
Tests which set the --perf-prof flag leave behind a file in the current
working directory every time they execute.
In order to avoid this, this CL introduces a --perf-prof-delete-file
flag, which removes this file right after creating it. This still allows
the process to write to it via the open handle, but the file will be
gone afterwards, even if the process crashes or gets killed while
executing.
R=ahaas@chromium.org
Bug: v8:10121
Change-Id: I99b159bb6d94255f77095ac78d98ba55106e94fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000738
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65759}
The fix in https://crrev.com/c/1997135 didn't properly recurse the cache
scope after a with scope, passing the current scope rather than the
original cache scope up the recursion. Now the "use external cache" check
is done in LookupWith (and, analogously, LookupSloppyEval) while passing
the given cache scope through the Lookup recursion.
Fixed: chromium:1041210
Fixed: chromium:1041616
Change-Id: I5ac9ddc6c16d63b59aa034721fccec2f7781c4f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000133
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65754}
TSan complains in "isolates" tests otherwise. Also further reduce
virtual memory requirements of the sample test to address flaky
allocation failures on 32-bit platforms.
Change-Id: I26c9a59965009d7083876b4ff4836ee879d33350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000138
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65750}
This reverts commit 304e97d334.
Reason for revert: Last roll is failing - https://ci.chromium.org/p/chromium/builders/try/linux-rel/282356
Original change's description:
> [parser] Fix caching dynamic vars on wrong scope
>
> When looking up a variable in a deserialized WITH scope, we were
> unconditionally passing in the cache scope to the lookup, even if the
> with was inside the cache scope. This would lead to and outer scope of
> the with holding the generated dynamic variable. If the cache scope was
> the SCRIPT scope, the dynamic variable would be interpreted as a global
> object property.
>
> Now, we only store the WITH scope dynamic variables in the cache scope
> if it is an inner scope of the WITH scope, same as we do for 'normal'
> scope lookups.
>
> Fixed: chromium:1041210
> Change-Id: I4e8eb25bbb8ea58311355d13a9c7c97bf2fa3ec7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997135
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65732}
TBR=leszeks@chromium.org,verwaest@chromium.org
Change-Id: I7b6d77d03b603152a9a47541db466934f46b1176
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000140
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65747}
Rather than explicitly requesting MAP_HUGETLB mappings, which requires
kernel configuration, we should rely on the "Transparent Hugepages"
feature, where eligible allocation requests are automatically fulfilled
with huge page mappings.
Bug: chromium:1041232
Change-Id: I5263da7a23290316aa7b99e63881ca88e65b4e34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997442
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65741}
When looking up a variable in a deserialized WITH scope, we were
unconditionally passing in the cache scope to the lookup, even if the
with was inside the cache scope. This would lead to and outer scope of
the with holding the generated dynamic variable. If the cache scope was
the SCRIPT scope, the dynamic variable would be interpreted as a global
object property.
Now, we only store the WITH scope dynamic variables in the cache scope
if it is an inner scope of the WITH scope, same as we do for 'normal'
scope lookups.
Fixed: chromium:1041210
Change-Id: I4e8eb25bbb8ea58311355d13a9c7c97bf2fa3ec7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997135
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65732}
This patch contains real changes affecting the following tests:
- regress-1119: Bogus test, was failing justifiedly. Dropped.
- regress-crbug-9161: Was accidentally disabled everywhere. Re-enabled
for ASan (as the comment promised).
- regress-crbug-160010: Throws "invalid string length" on all platforms.
Was disabled everywhere. Dropped.
- regress-crbug-514081: Test was previously changed to use 2MB instead
of 2GB. Re-enabled variants.
Additionally, it reorders a bunch of definitions:
- Introduced separate sections for "mode == debug" and "no_i18n" to make
the "ALWAYS" section cleaner.
- Sorted various "slow tests", "open bugs", and "no_variants" definitions
into groups.
- Simplified long "arch == x or arch == y" sequences to "arch in (x, y)".
Bug: v8:10021
Change-Id: Ibe404ae400011196473cf082a4706ddbef7c8349
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995390
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65718}
The regression test for crbug.com/976627 was:
(1) silently failing on all platforms,
(2) very brittle, baking in several internal limits,
(3) highly specific for one particular place in the code,
(4) when fixed, very slow: 6 seconds on x64.release.
For all these reasons, it is herewith dropped.
Bug: v8:10021
Change-Id: Ic144f6bfcca0c301f3aca7840edbdc43f34a77fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993975
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65715}
When Heap::TearDown is called, parts of the Isolate are already gone
(specifically: Managed<> objects, which includes Wasm NativeModules).
Since heap verification can depend on these parts (e.g. to find Code
objects belonging to current activations on the stack), we should do
it before tearing down things. Heap::StartTearDown is a suitable way
to achieve that.
Bug: v8:9209
Change-Id: I44094b19e16a4f372eb14ab363d8b4a65182f38a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993968
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65684}
This patch maintains the previous default value of the flag controlling
the max size of Wasm memories, but allows the limit to be raised on the
command line.
Bonus content: improve the multi-mapped mock allocator by falling back
to regular allocation for small requests.
More bonus content: make debug-mode Wasm tests faster.
Bug: v8:6306
Change-Id: Idabae5734794b06e65d45b3a6165dbd488847f3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981157
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65681}
This CL factors out the decision-making logic whether a property key should
be treated as a "property" or "element" into LookupIterator::Key, which can
be constructed on its own, allowing use sites to take this distinction into
account before constructing a LookupIterator from the Key, without needing
to duplicate the logic.
This also makes the assortment of LookupIterator constructors more uniform.
Bug: chromium:1031175
Change-Id: I81d7b11ab7e4915f5c05668138e6e0c51ae11821
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962272
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65672}
In the WebAssembly.Global constructor we continued to execute even after
the JavaScript code in the descriptor.mutable getter threw an exception.
This caused a problem when the descriptor.value getter was executed even
though there was a scheduled exception.
R=jkummerow@chromium.org
Bug: chromium:1033948
Change-Id: Idac554175fe45ec677447b793db069eb6de543b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993283
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65669}
This is a cleanup to remove unneeded flags after these changes (in
https://crrev.com/c/1988548):
* --future does not imply --wasm-tier-up any more, and
* --wasm-tier-up does not imply --liftoff any more.
Instead, now
* --wasm-tier-up is enabled by default,
* --wasm-tier-up has no effect if --liftoff is not set, and
* --future implies --liftoff.
R=ahaas@chromium.org
Bug: chromium:1040061
Change-Id: I5d04ee1f1d84ddcd0654df0e0a4c6298f80aee9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993280
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65666}
When FLAG_noconcurrent_recompilation is turned on we always run on main
thread. So it is safe to derefernce handles when printing the turbofan
graph. We should only add a DCHECK when dereferencing read-only heap
objects when optimizing concurrently.
Bug: chromium:1040444,chromium:1040403
Change-Id: I6bde966690458b1d122611b02e713c581c87f534
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992433
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65659}
When parsing an arrowhead, it's possible for temporary variables to be
created with a different index depending on whether the parsing is lazy
or eager. This then results in bytecode mismatches as the index is used
to determine which register to use.
To make the ordering stable, this changes variable allocation in arrow
functions to always allocate the non-temporaries first and then the
temporaries.
Bug: chromium:1020162
Change-Id: Ia47c4c2916d63f12d20d663e4e3842bfd68f6d8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977865
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65657}
The optimized code for String.charCodeAt(BigInt.asUintN(64, 10n)) did
not throw a TypeError due to how lowering of CheckBounds triggers
RepresentationChanger.
Bug: chromium:1038573
Change-Id: Ie0f9ca95de5af5fd3701841ab169e11ccc77216c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986003
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65632}
During conflict detection, we want to early exit the scope loop when we
find a non-conflict, but continue looking at the other declarations in
the scope.
Bug: chromium:1038588
Change-Id: Ia2a19b02222fbd13cec70d3a60d2f5bae4ce245b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1985991
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65602}
The native context can differ from the current isolates
raw_native_context, so this DCHECK was never valid.
Bug: chromium:1033966
Change-Id: Iecbbdf33a8645ffd6e8768f4ba0eb0292eca269f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1982582
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65577}
If --perf-prof is specified, we commit the whole code range at once, and
never update the {total_committed_code_space_} counter (see
{WasmCodeManager::Commit} and {WasmCodeManager::Decommit}). Hence we
should also not decrement that counter when the native module dies.
R=jkummerow@chromium.org
Bug: chromium:1032753
Change-Id: I9a40f1a1322485d7142ed56f5c9365305aa0e056
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969790
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65476}
Objects in arrays take the shape of the object right before as feedback to
speed up object creation. If a subsequent object with the same shape has a
member that also has the same shape, that member can cause the feedback map to
be deprecated. To avoid confusion, we now update (dedeprecate) the feedback map
before use.
Thanks a bunch Seth Brenith for figuring out the issue!
Bug: chromium:1029077
Change-Id: I047b1acfd4906616a2302f253ab9cd29272bdc79
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1970211
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65474}
The {cmp} instruction might add an entry to the constant pool at a time
where we didn't expect any entries to be added.
This can be fixed by moving the {CheckConstPool} call *after* the {cmp}.
R=mslekova@chromium.org
Bug: chromium:1034394
Change-Id: If075ad0b02e2973a734d70d9e58c205bd14e6a33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967380
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65463}
Bug: chromium:1029530
Change-Id: I12aa4c238387f6a47bf149fd1a136ea83c385f4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962278
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65434}
With bytecode flushing and the current OSR triggering mechanism which
stores OSR nesting level on bytecode array it is possible to trigger
OSR on a closure that doesn't have feedback vector.
Bug: chromium:1031479
Change-Id: I4c62486f6b0eb6d6f9c96f98c1c1b275f3e6d6d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962850
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65431}
This reverts commit 026a0c214a.
Reason for revert: Reverting due to https://crbug.com/1029461
Original change's description:
> [parser] Fix variable caching for conflict lookup
>
> During conflict lookup (for lexical variables and sloppy block function
> hoisting), we cache the looked-up variable on the current scope if the
> lookup goes through a ScopeInfo. However, for variable lookup during
> scope analysis, we use the "entry point" as the cache.
>
> Since both lookups can create Variables, this can cause us to create
> duplicate variables, e.g. a duplicate function name variable in the
> attached test.
>
> Instead, for ScopeInfo conflict lookups we can cache the result on the
> function's outer scope, which shoud be equivalent to the entry point.
>
> As a (necessary) drive-by, we can terminate the lookup early if we find
> a VAR with the same name, as we can safely assume that its existence
> means that it doesn't conflict, which means that our variable can't
> conflict either.
>
> Bug: chromium:1026603
> Change-Id: I19f80f65597ba6573ebe0b48aa5698f55e5c3ea1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928861
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65138}
TBR=leszeks@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1026603
Bug: chromium:1029461
Change-Id: Id7f5dd342e32e1bb57c51b3748feff32ee0ba41d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958014
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65390}
In 5742da056a, the toString property was
accidentally applied to all NativeError prototypes, when it should only
be inherited from Error.prototype.
Refs: https://github.com/tc39/ecma262/issues/1794
Bug: v8:10017
Change-Id: I2af9a31f463deb9871dd7a4a5a2e4dd7485ed38c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1933054
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65355}
Imports can also have associated names, and in fact we generate these
names for asm.js. Thus in logging, just append this name to the
generated signature.
R=jkummerow@chromium.org
Bug: chromium:1030103
Change-Id: I3969bcf8d1d17f4256b5a0643acdf8a24766f889
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948705
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65321}
Bug: chromium:1029576
Change-Id: If647f764da2682a0f278b9b8060d0665fab1c40c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948711
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65312}
CSA::TryLookupElement must check the upper bound for dictionary-mode
indices.
The "stable map + accessor" branch of FastGetOwnValuesOrEntries must
construct its LookupIterator such that it handles the named/indexed
distinction correctly.
Bug: chromium:1029338,chromium:1029369
Change-Id: I17e74ed24c260c5cfc20c61616e75db7d347f7a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1943164
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65301}
Loop variable analysis doesn't recognize that the initial type of the
loop variable phi combined with the increment type may produce a NaN
result through the addition of two infinities of differing sign.
This leads to unreachable code and a SIGINT crash.
The fix is to consider this case before typing the loop variable phi,
falling back to more conservative typing if discovered.
R=neis@chromium.org
Bug: chromium:1028863
Change-Id: Ic4b5189c4c50c5bbe29e46050de630fd0673de9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1946352
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65291}
Adding a regression test for https://crrev.com/c/1930606.
This test was generated using --dump-wasm-module, which created a 6KB
module, and then running binaryen's wasm-reduce on it until it churned
this out, and removing an extra kExprUnreachable.
Bug: chromium:1027410
Change-Id: I14ba6ebe52f45e3b3ba943088807e110eebe0339
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1933592
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65276}
