... when the element is read-only in one of the prototypes:
* the length should not be updated,
* in strict mode the store operation should throw TypeError.
Bug: chromium:1055138
Change-Id: I7fc08e22c83f8a9848053cfe20851dc1b82f0e3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172090
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67717}
Scripts aren't callable functions. Even though internally they were for a
while, they aren't anymore. We shouldn't return them to users as if they were.
We already remove strict-mode functions from CallSites, so we now do the same
for internal functions that are created for scripts.
Bug: v8:10508
Change-Id: I270c714524439fba9ad90dd29826bed4811ba2b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193716
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67709}
In the existing code we used a register of the UseScratchRegisterScope
for the destination address. However, this register is needed for the
ParallelRegisterMove as well. With this CL we use fixed registers for
the destination address and the offset as well. The CL also changes the
implementation of CalculateActualAddress to allow to set an explicit
register for the result.
R=clemensb@chromium.org
Bug: v8:10108, chromium:1079449
Change-Id: I39c11b9ffa5f3e937ce4820b9991482ad711b4b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2192652
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67702}
This changes the existing implementation that creates an unresolved reference for those cases to look at exactly what scopes are relevant so it can correctly handle catch scopes and avoid re-resolving later.
Variable through with aren't marked as assigning since this information isn't relevant for the with itself; and if the with is passed through, there's no need to mark the outer variable as assigned since it's either initialized or it isn't.
The catch variable is assigned since it is relevant for the catch variable.
The CL uses LookupLocal which wouldn't work for deserialized scopes, but this isn't relevant because 1) eval scopes are declaration scopes, and 2) eval causes all outer variables to be maybe_assigned anyway.
Bug: chromium:1074737
Change-Id: I3febca479ddd1f3c62eae299190b06c0b4cd3746
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187272
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67683}
This reverts commit 6204768bab.
Reason for revert: A number of Clusterfuzz reports (e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1079474)
Original change's description:
> [turbofan] Improve equality on NumberOrOddball
>
> This CL cleans up CompareOperationFeedback by replacing it with a
> composable set of flags. The interpreter is changed to collect
> more specific feedback for abstract equality, especially if oddballs
> are involved.
>
> TurboFan is changed to construct SpeculativeNumberEqual operator
> instead of the generic JSEqual in many more cases. This change has
> shown a local speedup of a factor of 3-10, because the specific
> operator is way faster than calling into the generic builtin, but
> it also enables additional optimizations, further improving
> runtime performance.
>
> Bug: v8:5660
> Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67645}
TBR=rmcilroy@chromium.org,neis@chromium.org,mythria@chromium.org,nicohartmann@chromium.org
Change-Id: I3410310ed2b1ff2eaee70c1b91c3151d35866108
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5660
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190414
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67673}
This CL cleans up CompareOperationFeedback by replacing it with a
composable set of flags. The interpreter is changed to collect
more specific feedback for abstract equality, especially if oddballs
are involved.
TurboFan is changed to construct SpeculativeNumberEqual operator
instead of the generic JSEqual in many more cases. This change has
shown a local speedup of a factor of 3-10, because the specific
operator is way faster than calling into the generic builtin, but
it also enables additional optimizations, further improving
runtime performance.
Bug: v8:5660
Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67645}
After sorting the work array but before writing the values back into
the actual receiver, we have an accessor check. This accessor check
needs to be stricter, in order to catch Array prototype protector
cell invalidations.
R=jgruber@chromium.org
Bug: chromium:1077508
Change-Id: I3c3bd4711f9019f9d4423701724319eee9d800a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187171
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67638}
When the input to a speculative BigInt operation was an undefined
constant, no necessary type check was inserted by the
RepresentationChanger. This CL fixes this.
Bug: chromium:1077804
Change-Id: I3d4e15b1e018803d56e46c7b23b9d4b03832ba8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182455
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67610}
... to be in sync with KeyedLoadIC_SloppyArguments in handling OOB
accesses which may involve prototype chain walk.
Bug: chromium:1063796
Change-Id: I8421c19085dfd2f3b6360c64fd04f53b1351576c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2174504
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67541}
- Update opcode numbers, tests
- As the wasm-module-builder currently assumes opcode bytes, skip
the test that needs a multi-byte leb128 opcode
- Renumber post-MVP opcodes
Change-Id: I6531e954e63986dc6f7a3144ec054d16e6dc1b05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173952
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67517}
Spilling a register in Liftoff require a scratch register when the
offset of the stack slot from fp is greater than 2^12. This CL adds
a check to LiftoffAssembler::Spill on arm to check that a scratch
register is available. It also fixes one case where the scratch register
was not available.
R=clemensb@chromium.orgCC=zhin@chromium.org
Bug: chromium:1075953
Change-Id: Idb2bc7e26e3d4fbd6bb0eb6c9a9b8cfd8b3c569e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172424
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67494}
With this CL the registers in a register pair get ordered such that the
low word register always has a lower register code than the high word
register. This should allow easier reasoning about the register
allocation, and prevent some register allocation bugs.
Background: for many operations in Liftoff, input registers are reused
as output registers. With register pairs, input register pairs are
reused as output register pairs. Additional reasoning, and sometimes
even additional code is needed when the registers of the output register
pair are swapped, i.e. when the high word register of the input becomes
the low word register of the output. With this CL the additional
reasoning is not necessary anymore, as the high word and low word
registers would get swapped during register allocation.
Additionally this CL fixes the logic of the last_spilled_regs list. This
list stored the last spilled registers, but recorded only one of the two
registers of a register pair. With this CL, both registers get recorded.
This CL does not have a regression test. The regression test was more
than 9000 lines long, and quite slow. I was not able to minimize it
substantially. The test would be fragile by nature, as it has to create
a special register configuration or otherwise does not test anything
meaningful. All in all I think it's better not to add the test.
R=clemensb@chromium.org
Bug: chromium:1074586
Change-Id: I4b2475b0c6537c7ce2e51fee281388cdd85f2953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168875
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67473}
Having no value argument in DataView setters (e.g. setFloat64) caused
wrong behavior in compiled code.
Bug: chromium:1071190
Change-Id: I37ddba8555dafad321f8d4c1352da8a501a98453
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170091
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67451}
In AtomicOp64 ClearRegister is called twice to clear the registers r8
and r9. Thereby new registers may get allocated. We forgot to add the
newly allocated registers to pinned after the first call to
ClearRegister, which caused the same registers to be allocated again in
the second ClearRegister, and thereby caused the bug.
R=clemensb@chromium.org
Change-Id: I0d069aea4c9438fe30c30c22406b4075ddf3e95c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170088
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67445}
This removes the {RedirectToWasmInterpreter} runtime function and the
respective method from {WasmDebugInfo}.
Some tests test specifically the interaction between compiled code and
the interpreter. They are irrelevant now and are deleted.
R=thibaudm@chromium.org
Bug: v8:10389
Change-Id: I38330fcb523f7c65968fdf03abc60af3392bdcc8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2164793
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67427}
The interpreter will be moved to be test-only, hence
--wasm-interpret-all also needs to be removed.
Since we don't have any non-compiling tier any more, we also remove the
implication from --jitless to --wasm-lazy-compilation. Instead, we add
another CHECK that we can't be in jitless mode if we trigger any wasm
compilation.
All tests that just ran other tests and additionally passed
--wasm-interpret-all become redundant and are deleted. Also all
regression tests that explicitly specify --wasm-interpret-all are not
needed any more.
R=thibaudm@chromium.org
Bug: v8:10389
Change-Id: I5ddf20a842117a6c05e277a5308f5cfe42e6bfa5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2164792
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67419}
This reverts the changes made in
https://chromium-review.googlesource.com/c/v8/v8/+/1695465https://chromium-review.googlesource.com/c/v8/v8/+/1776078
We originally moved this protector to the native context to avoid
cross-native-context pollution of protector state. Ideally,
invalidating a protector in one NC should not affect any other NC.
But as it turns out, having the protector on the NC causes more
problems than it solves since all affected callers now need to find
the correct native context to check. Sometimes (e.g. in CSA regexp
builtins) it is possible to blindly check the current NC, but the
reasoning behind this optimization is tricky to understand.
Sometimes, fetching the correct NC is not possible due to access
restrictions. These implementation complexities outweigh the (unknown)
potential performance benefits.
In the future we should attempt to move away from the protector
concept for these kinds of checks.
Bug: chromium:1069964,v8:9463
Change-Id: I2cbb2ec7266282165dae5e4a6c8bdbda520c50a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157382
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67415}
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}
