The emitted safepoint entries had the wrong size, because it did not
contain StandardFrameConstants::kFixedFrameSizeAboveFp. The code still
worked because the indices of encoded in the entries where too low by
StandardFrameConstants::kFixedFrameSizeAboveFp and thereby corrected
the invalid size. It worked as follows:
First the stack_slots_size gets calculated from the safepoint entry.
Then the position of a stack slot was
"frame_header_base + stack_slots_size - index * pointer_size", where
"index" is what is encoded in the safepoint map. Because of the incorrect
encoding, both stack_slot_size and index were too low by
StandardFrameConstants::kFixedFrameSizeAboveFp. Therefore the errors in
both values eliminated each other, making the end result correct.
With --print-code, the safepoint entry size was also read, and it
crashed because the encoded value was too low.
The reland fixes the indices.
Original message:
With this CL we emit safepoint maps for externref values on the Liftoff
value stack. With that there is support for externref parameters and
locals in Liftoff, as well as for intermediate values of type
externref.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: I88444e57745d7b9fe8f1630e904d49736fa9d720
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2398531
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69786}
An earlier cl:
https://chromium-review.googlesource.com/c/v8/v8/+/2354810 fixed loading
double fields with dynamic map checks. The fix however didn't update the
expected type information to also expect Smi fields. So, in the later
optimization phases the CheckHeapObject operation was reduced to a NoP
since the expected type was a HeapObject. This cl fixes the bug by
updating the type to Type::Any.
Bug: chromium:1124696, v8:10582
Change-Id: Ic96dd74c97caf8eaf5289d8e8939f6feb1686a57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2396088
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69730}
Due to the way SSE flags work, we need to enable all versions prior to
SSE 4.1 as well.
Bug: v8:10863
Change-Id: I50ddd3f486641e7bf22c651fc2c9a8a4ccbc2b46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391325
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69687}
The test is incompatible with --noenable-sse4-1, which is randomly
added by numfuzz (and possibly other fuzzers).
The "Flags" from the test files are always passed last and are often
used to neuter incompatible flags.
Bug: v8:10863
Change-Id: I8fd11b4d38586f25f5af63ab8ef83873dc250557
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2389982
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69665}
For TypedArray, a fast path is used when using the builtin iterator, and
next method has not been overriden. If we use that fast path for JSArray
too, the method will be about 200x times faster on a large array.
This patch also fixes a bug when a typed array is modified during the
mapper execution. In that case, the modification should not be taken
into account.
Bug: v8:10802
Change-Id: I74e2cbcd6a654def318585b4e08745037584669a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358749
Commit-Queue: Arnaud Renevier <arenevier@fb.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69655}
With a recent change, we require WebAssembly code to be tiered up to
serialize it, see https://crrev.com/c/2349290. In that CL tests were
adjusted to set the --wasm-tier-up flag when serialization was involved.
However, the test adjusted in this CL was missing, because this test
used the kExprRefNull instruction, which caused a bailout to TurboFan
anyways. With recent changes, Liftoff can compile kExprRefNull now,
and therefore causes problems.
R=thibaudm@chromium.org
Bug: v8:10852
Change-Id: I9b89f37c22f17cbf046110f3ee1c98bfea73e009
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387574
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69648}
The graph assembler calls MergeControlToEnd as part of Unreachable
node creation; this causes issues when used inside the GraphReducer
framework, since the reducer is not notified by gasm that the end node
should be revisited.
The (hacky) fix in this CL is to always mark the end node for
revisitation after a gasm reduction has taken place.
Bug: v8:8888,chromium:1123379
Change-Id: I350bb7144add04a0c3fd7f3d88c07fcfe1cd42e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384772
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69619}
A recent unrelated change caused these tests to get unlucky in
GC stress mode. Their "assertOptimized" expectations rely on
certain type feedback data not getting flushed at the wrong time.
Bug: v8:10846
Change-Id: I86d0b0c049539e4a69aa764cc6ec92465ca12beb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381458
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69617}
For SIMD instructions that use aligned moves (like movaps or movapd), we
don't have correct memory alignment for SIMD moves yet. Switch to to
movupd.
Bug: v8:9198
Bug: v8:10831
Change-Id: Ic60fba5d08dda9676f6091ce505ac7be54957d00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380240
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69613}
With in-place representation changes we can transition from a double
field to a Tagged field without changing the map. So it is not always
safe to assume the loaded value would be a HeapNumber. TurboFan takes a
dependency on the field representation to ensure the code is deoptimized
on any changes. With dynamic map checks, it is not possible to take such
a dependency. Hence check the loaded value is a HeapNumber and
deoptimize otherwise.
Bug: chromium:1112155,v8:10582
Change-Id: I910ac1c0781ac8842fdbf272f9173b55b02923ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354810
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69521}
Load extends always load 8 bytes, so the access size does not depend on
MachineType of the load. The MachineType is used for classifying the
lane shape of the 8-byte load.
Also add cctest to load splats and load extends to test OOB. (Note that
load splats access size depends on MachineType).
Add regression test from clusterfuzz, minimized by ahaas@. Remove the
`--no-wasm-trap-handler` flag since we have a no_wasm_traps variant that
should test this flag.
Bug: chromium:1116019
Change-Id: I27ba051d0536ca0f6fd75dd641ca9b78132dafed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363291
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69489}
This reverts commit dc18b82221.
Reason for revert: still causing failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/31566
Original change's description:
> Reland^3 "[flags] warn about contradictory flags"
>
> This is a reland of 0ba115e6a9
> Changes:
> - Also allow second parameter influenced by --cache to be reassigned.
> - Fix --stress-opt to only --always-opt in the last iteration as before.
>
> Original change's description:
> > Reland^2 "[flags] warn about contradictory flags"
> >
> > This is a reland of d8f8a7e210
> > Change compared to last reland:
> > - Do not check for d8 flag contradictions in the presence of --fuzzing
> > - Allow identical re-declaration of --cache=*
> >
> > Original change's description:
> > > Reland "[flags] warn about contradictory flags"
> > >
> > > This is a reland of b8f9166664
> > > Difference to previous CL: Additional functionality to specify
> > > incompatible flags based on GN variables and extra-flags, used
> > > to fix the issues that came up on the waterfall.
> > >
> > > This also changes the rules regarding repeated flags: While
> > > explicitly repeated flags are allowed for boolean values as long
> > > as they are identical, repeated flags or explicit flags in the
> > > presence of an active implication are disallowed for non-boolean
> > > flags. The latter simplifies specifying conflict rules in
> > > variants.py. Otherwise a rule like
> > >
> > > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > > "--gc-interval=*": ["--gc-interval=*"],
> > > }
> > >
> > > wouldn't work because specifying the same GC interval twice
> > > wouldn't actually count as a conflict. This was an issue with
> > > test/mjsunit/wasm/gc-buffer.js, which specifies
> > > --gc-interval=500 exactly like the extra flag by the stress bot.
> > >
> > > Also, this now expands contradictory flags checking to d8 flags
> > > for consistency.
> > >
> > > Original change's description:
> > > > [flags] warn about contradictory flags
> > > >
> > > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > > >
> > > > Bug: v8:10577
> > > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#68168}
> > >
> > > Bug: v8:10577
> > > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68989}
> >
> > Bug: v8:10577
> > Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#69339}
>
> Bug: v8:10577
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Change-Id: I4a69dc57a102782cb453144323e3752ac8278624
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69433}
TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
Change-Id: I4ccdd7b931d0ddccbcec1d6cfae8d4874ee49cfc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10577
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360414
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69438}
This is a reland of 0ba115e6a9
Changes:
- Also allow second parameter influenced by --cache to be reassigned.
- Fix --stress-opt to only --always-opt in the last iteration as before.
Original change's description:
> Reland^2 "[flags] warn about contradictory flags"
>
> This is a reland of d8f8a7e210
> Change compared to last reland:
> - Do not check for d8 flag contradictions in the presence of --fuzzing
> - Allow identical re-declaration of --cache=*
>
> Original change's description:
> > Reland "[flags] warn about contradictory flags"
> >
> > This is a reland of b8f9166664
> > Difference to previous CL: Additional functionality to specify
> > incompatible flags based on GN variables and extra-flags, used
> > to fix the issues that came up on the waterfall.
> >
> > This also changes the rules regarding repeated flags: While
> > explicitly repeated flags are allowed for boolean values as long
> > as they are identical, repeated flags or explicit flags in the
> > presence of an active implication are disallowed for non-boolean
> > flags. The latter simplifies specifying conflict rules in
> > variants.py. Otherwise a rule like
> >
> > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > "--gc-interval=*": ["--gc-interval=*"],
> > }
> >
> > wouldn't work because specifying the same GC interval twice
> > wouldn't actually count as a conflict. This was an issue with
> > test/mjsunit/wasm/gc-buffer.js, which specifies
> > --gc-interval=500 exactly like the extra flag by the stress bot.
> >
> > Also, this now expands contradictory flags checking to d8 flags
> > for consistency.
> >
> > Original change's description:
> > > [flags] warn about contradictory flags
> > >
> > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > >
> > > Bug: v8:10577
> > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68168}
> >
> > Bug: v8:10577
> > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68989}
>
> Bug: v8:10577
> Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69339}
Bug: v8:10577
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Change-Id: I4a69dc57a102782cb453144323e3752ac8278624
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352770
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69433}
This is a reland of 57242a051e
no-sse4.1 builds were failing due to missing simd-scalar-lowering
for s128.const, this reland adds that implementation.
Original change's description:
> [wasm-simd][arm] Use vmov to move all ones to register
>
> vceq(dst, dst, dst) does not seem to always set the register to all
> ones. The right way should be be to use vmov (immediate) anyway. This
> was not supported in the assembler yet, so we need changes to the
> assembler, diassembler, and simulator.
>
> There is an unfortunate fork in logic in the simulator, due to the way
> the switches are set up, vmov (imm) logic is duplicated across two
> different cases, because the switch looks at the top bit of the
> immediate. Refactoring this will be a bigger change that is irrelevant
> for this bug, so I'm putting that off for now. Instead we extract the
> core of vmov (imm) into helpers and call it in the two cases.
>
> Bug: chromium:1112124
> Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69315}
Bug: chromium:1112124
Change-Id: Id450e5cea41f7a569e49be8386a7788ca8f00658
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346937
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69346}
This reverts commit 0ba115e6a9.
Reason for revert: Breaks test on TSAN - block-conflicts
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/14230
Original change's description:
> Reland^2 "[flags] warn about contradictory flags"
>
> This is a reland of d8f8a7e210
> Change compared to last reland:
> - Do not check for d8 flag contradictions in the presence of --fuzzing
> - Allow identical re-declaration of --cache=*
>
> Original change's description:
> > Reland "[flags] warn about contradictory flags"
> >
> > This is a reland of b8f9166664
> > Difference to previous CL: Additional functionality to specify
> > incompatible flags based on GN variables and extra-flags, used
> > to fix the issues that came up on the waterfall.
> >
> > This also changes the rules regarding repeated flags: While
> > explicitly repeated flags are allowed for boolean values as long
> > as they are identical, repeated flags or explicit flags in the
> > presence of an active implication are disallowed for non-boolean
> > flags. The latter simplifies specifying conflict rules in
> > variants.py. Otherwise a rule like
> >
> > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> > "--gc-interval=*": ["--gc-interval=*"],
> > }
> >
> > wouldn't work because specifying the same GC interval twice
> > wouldn't actually count as a conflict. This was an issue with
> > test/mjsunit/wasm/gc-buffer.js, which specifies
> > --gc-interval=500 exactly like the extra flag by the stress bot.
> >
> > Also, this now expands contradictory flags checking to d8 flags
> > for consistency.
> >
> > Original change's description:
> > > [flags] warn about contradictory flags
> > >
> > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> > >
> > > Bug: v8:10577
> > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#68168}
> >
> > Bug: v8:10577
> > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68989}
>
> Bug: v8:10577
> Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69339}
TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
Change-Id: I1454a05e357ddd704db7fb79e51be65d45a9a16e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10577
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2348365
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69341}
This is a reland of d8f8a7e210
Change compared to last reland:
- Do not check for d8 flag contradictions in the presence of --fuzzing
- Allow identical re-declaration of --cache=*
Original change's description:
> Reland "[flags] warn about contradictory flags"
>
> This is a reland of b8f9166664
> Difference to previous CL: Additional functionality to specify
> incompatible flags based on GN variables and extra-flags, used
> to fix the issues that came up on the waterfall.
>
> This also changes the rules regarding repeated flags: While
> explicitly repeated flags are allowed for boolean values as long
> as they are identical, repeated flags or explicit flags in the
> presence of an active implication are disallowed for non-boolean
> flags. The latter simplifies specifying conflict rules in
> variants.py. Otherwise a rule like
>
> INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> "--gc-interval=*": ["--gc-interval=*"],
> }
>
> wouldn't work because specifying the same GC interval twice
> wouldn't actually count as a conflict. This was an issue with
> test/mjsunit/wasm/gc-buffer.js, which specifies
> --gc-interval=500 exactly like the extra flag by the stress bot.
>
> Also, this now expands contradictory flags checking to d8 flags
> for consistency.
>
> Original change's description:
> > [flags] warn about contradictory flags
> >
> > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> >
> > Bug: v8:10577
> > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68168}
>
> Bug: v8:10577
> Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68989}
Bug: v8:10577
Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69339}
This is a reland of 60ee70bb40.
The wasm c-api flakes were fixed in https://crrev.com/c/2349293.
Original change's description:
> [wasm] Ensure that only TurboFan code is serialized
>
> We have the implicit assumption that Liftoff code will never be
> serialized, and we start relying on that when implementing new features
> (debugging, dynamic tiering).
>
> This CL makes the serializer fail if the module contains any Liftoff
> code. Existing tests are changed to ensure that we fully tiered up
> before serializing a module (similar to the logic in Chromium).
> The "wasm-clone-module" test needs to serialize the module before
> enabling the debugger.
>
> Note that chrome currently only serializes a module after it fully
> tiered up, so that should be fine. If other embedders need the ability
> to serialize a module in an arbitrary state, we will have to fix this
> later. With this CL we will be on the safe side though and (gracefully)
> fail serialization instead of accidentally serializing Liftoff code.
>
> R=ahaas@chromium.org
>
> Bug: v8:10777
> Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69276}
Bug: v8:10777
Change-Id: I2a7c1429812ca46d88a2902b8e0a7b7e3d638b56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349290
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69335}
This reverts commit 57242a051e.
Reason for revert: regression tests fails:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/31477
Original change's description:
> [wasm-simd][arm] Use vmov to move all ones to register
>
> vceq(dst, dst, dst) does not seem to always set the register to all
> ones. The right way should be be to use vmov (immediate) anyway. This
> was not supported in the assembler yet, so we need changes to the
> assembler, diassembler, and simulator.
>
> There is an unfortunate fork in logic in the simulator, due to the way
> the switches are set up, vmov (imm) logic is duplicated across two
> different cases, because the switch looks at the top bit of the
> immediate. Refactoring this will be a bigger change that is irrelevant
> for this bug, so I'm putting that off for now. Instead we extract the
> core of vmov (imm) into helpers and call it in the two cases.
>
> Bug: chromium:1112124
> Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69315}
TBR=bbudge@chromium.org,jkummerow@chromium.org,v8-arm-ports@googlegroups.com,zhin@chromium.org
Change-Id: I5d9d1dcb81771f71001d959ec5a03a43a11c4233
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1112124
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2347211
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69316}
vceq(dst, dst, dst) does not seem to always set the register to all
ones. The right way should be be to use vmov (immediate) anyway. This
was not supported in the assembler yet, so we need changes to the
assembler, diassembler, and simulator.
There is an unfortunate fork in logic in the simulator, due to the way
the switches are set up, vmov (imm) logic is duplicated across two
different cases, because the switch looks at the top bit of the
immediate. Refactoring this will be a bigger change that is irrelevant
for this bug, so I'm putting that off for now. Instead we extract the
core of vmov (imm) into helpers and call it in the two cases.
Bug: chromium:1112124
Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69315}
Up until now. we only checked the size of tables defined in a module
at instantiation time. For imported tables we only checked if the
imported table matched the declared import in size. This causes a
problem because we allocate function tables also for imported tabled
before we actually look at the imported table.
With this CL we first check the size of all tables, and only then start
to initialize and load them.
R=jkummerow@chromium.org
Bug: chromium:1114006
Change-Id: Iaf194ed21fb83304fe3a7f0f7ba7b282396e3954
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339473
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69291}
The cast from uint32_t to int caused an integer overflow that let a
bounds check succeed that should have failed.
R=jkummerow@chromium.org
Bug: chromium:1114005
Change-Id: Iea1af70af300be54c2a33d7dd10b3faa34d56eaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339472
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69289}
This reverts commit 60ee70bb40.
Reason for revert: wasm-api-tests/WasmCapiTest.Serialize starts flaking: https://crbug.com/v8/10784
Original change's description:
> [wasm] Ensure that only TurboFan code is serialized
>
> We have the implicit assumption that Liftoff code will never be
> serialized, and we start relying on that when implementing new features
> (debugging, dynamic tiering).
>
> This CL makes the serializer fail if the module contains any Liftoff
> code. Existing tests are changed to ensure that we fully tiered up
> before serializing a module (similar to the logic in Chromium).
> The "wasm-clone-module" test needs to serialize the module before
> enabling the debugger.
>
> Note that chrome currently only serializes a module after it fully
> tiered up, so that should be fine. If other embedders need the ability
> to serialize a module in an arbitrary state, we will have to fix this
> later. With this CL we will be on the safe side though and (gracefully)
> fail serialization instead of accidentally serializing Liftoff code.
>
> R=ahaas@chromium.org
>
> Bug: v8:10777
> Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69276}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: Ic1349375bd562bb0a2724c39c27ef3247461c97b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342845
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69284}
We have the implicit assumption that Liftoff code will never be
serialized, and we start relying on that when implementing new features
(debugging, dynamic tiering).
This CL makes the serializer fail if the module contains any Liftoff
code. Existing tests are changed to ensure that we fully tiered up
before serializing a module (similar to the logic in Chromium).
The "wasm-clone-module" test needs to serialize the module before
enabling the debugger.
Note that chrome currently only serializes a module after it fully
tiered up, so that should be fine. If other embedders need the ability
to serialize a module in an arbitrary state, we will have to fix this
later. With this CL we will be on the safe side though and (gracefully)
fail serialization instead of accidentally serializing Liftoff code.
R=ahaas@chromium.org
Bug: v8:10777
Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69276}
We used to check the size of tables at compile time, and threw a
CompilationError if a given size exceeded the implementation-defined
limit. However, the spec defines that an error should only be thrown
when the implementation-defined limit is reached, which is either at
instantiation time of during runtime at a table.grow.
With this CL the V8 implementation becomes spec compliant in this
regard.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: I7d0e688b385a65e4060a569e5ab1dec68947ceea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326331
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69267}
This test uses a i64x2.shr_s to shift a v128 with all bits set by 1,
resulting in v128 with all bits set (no change). This value is then
dropped, and param[2] (3), is returned.
Without the fix, -1 is returned, since i64x2.shr_s overwrites the
register for param[2] with 0xffffffff.
Bug: v8:10752
Bug: chromium:1111522
Change-Id: I0310bf6039be780a6738689069cdbcfa3a24bbdb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335779
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69233}
If we are near the stack limit, calling the proxy method might not work
any more. Instead of crashing because of an empty MaybeLocal, handle
this gracefully.
Drive-by: Minor refactoring in TryGetValue.
R=tebbi@chromium.org
Bug: chromium:1110001
Change-Id: I07e7773768166b3dbea2e6b75a3ab8b24bfeee53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332156
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69161}
This reverts commit d8f8a7e210.
Reason for revert: Breaks code_serializer variant - https://cr-buildbucket.appspot.com/build/8874070652992164976
Original change's description:
> Reland "[flags] warn about contradictory flags"
>
> This is a reland of b8f9166664
> Difference to previous CL: Additional functionality to specify
> incompatible flags based on GN variables and extra-flags, used
> to fix the issues that came up on the waterfall.
>
> This also changes the rules regarding repeated flags: While
> explicitly repeated flags are allowed for boolean values as long
> as they are identical, repeated flags or explicit flags in the
> presence of an active implication are disallowed for non-boolean
> flags. The latter simplifies specifying conflict rules in
> variants.py. Otherwise a rule like
>
> INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> "--gc-interval=*": ["--gc-interval=*"],
> }
>
> wouldn't work because specifying the same GC interval twice
> wouldn't actually count as a conflict. This was an issue with
> test/mjsunit/wasm/gc-buffer.js, which specifies
> --gc-interval=500 exactly like the extra flag by the stress bot.
>
> Also, this now expands contradictory flags checking to d8 flags
> for consistency.
>
> Original change's description:
> > [flags] warn about contradictory flags
> >
> > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> >
> > Bug: v8:10577
> > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68168}
>
> Bug: v8:10577
> Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68989}
TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
Change-Id: I7969065b0edbc463a94e530485bc2ab623d77b62
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10577
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312782
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68992}
This is a reland of b8f9166664
Difference to previous CL: Additional functionality to specify
incompatible flags based on GN variables and extra-flags, used
to fix the issues that came up on the waterfall.
This also changes the rules regarding repeated flags: While
explicitly repeated flags are allowed for boolean values as long
as they are identical, repeated flags or explicit flags in the
presence of an active implication are disallowed for non-boolean
flags. The latter simplifies specifying conflict rules in
variants.py. Otherwise a rule like
INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
"--gc-interval=*": ["--gc-interval=*"],
}
wouldn't work because specifying the same GC interval twice
wouldn't actually count as a conflict. This was an issue with
test/mjsunit/wasm/gc-buffer.js, which specifies
--gc-interval=500 exactly like the extra flag by the stress bot.
Also, this now expands contradictory flags checking to d8 flags
for consistency.
Original change's description:
> [flags] warn about contradictory flags
>
> Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
>
> Bug: v8:10577
> Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68168}
Bug: v8:10577
Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68989}
The {operator==} on {VarState} did not check the spill offset, so when
merging stack states, we forgot to move stack values if both source and
destination were stack slots, but at different offsets.
This CL fixes this by removing the {operator==}, because the semantics
(and use) are not clear, and it's only used in one place anyway.
The equality check was mostly redundant, so inlining it also makes the
code smaller and faster.
R=ahaas@chromium.org
Bug: v8:10702
Change-Id: I6c8b2cfd1002274175c9a17d305692e4631fd7dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2304574
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68916}
We cannot allocate large arrays exceeding the size of
kMaxRegularHeapObjectSize in young space. Bailout of optimization in
such cases.
Bug: chromium:1105746
Change-Id: I4f7357c2dd7b3e70d747f9067660725ecf6ae768
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300481
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68889}
mjsunit/regress/regress-896326.js failed on mips simulator, because mips
simulator has larger stack size and won't throw the expected RangeError
exception.
This CL set sim-stack-size to 100K in regress-896326 just like setting
the native machine's stack-size.
Change-Id: I51328b10a7b54addab2adb90401680c0581d7ee2
Bug: v8:10709
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299880
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68865}
This is a follow-up fix for
https://chromium-review.googlesource.com/c/v8/v8/+/2292230
In this CL fixes the case when the property cell is added to the
dictionary but the value is not actually stored which leaves
PropertyCell with the hole in the dictionary.
Now the logic for GlobalDictionary matches the logic for
NameDictionary - the property cell is added to the dictionary in
LookupIterator::ApplyTransitionToDataProperty().
Bug: chromium:1104711, chromium:1105383
Change-Id: I56da16d85d13288fbc41fd60dbce556fec5e7d18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297472
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68860}
The named LoadIC code was missing a check for "names" that
convert to TypedArray indices. This was flushed out by the
recent bump of the max TypedArray size from 2^32-1 to 2^32.
Named StoreICs had the same bug; fixed here as well.
Bug: v8:4153
Fixed: chromium:1104608
Change-Id: I6bd2552d6ccc238104f92e7b95d19970d4a75dae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2295606
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68840}
For 64-bit binary operations, Liftoff on arm made the assumption that
register pairs are always ordered, i.e. the register code for the low
word is lower than the register code for the high word.
Ensuring this was only implemented in {GetUnusedRegister} in
https://crrev.com/c/2168875. Other cases were missing though, e.g.
return values, but also different places were we
construct register pairs internally.
Thus, this CL removes this constraint again and instead handles
unordered register pairs in 64-bit binary operations on arm.
R=thibaudm@chromium.org
Bug: chromium:1101304
Change-Id: I4cd9fb1577f82ab06d34c9dde6533cf04a2cade7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287870
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68752}
After r68405 reduced the default stack size on Arm64 a couple of tests
hit stack limits on the Arm64 android bots. Reduce the argument count
on these tests to avoid this issue.
BUG=chromium:1099623
Change-Id: I8957043b74bd416bb78223599b1a661a4887f54a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280095
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68670}
An 'arguments' array cannot be allocated in young space when its size
exceeds kMaxRegularHeapObjectSize. In this case the optimizations in
JSCreateLowering::ReduceJSCreateArguments are skipped.
Bug: chromium:1098565
Change-Id: I30fdc78a1eb6e51fcd293785a46c9fd78995da9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2273121
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68585}
With this CL d8 exits with an error code if there is an unhandled
promise rejection, e.g. due tue a failed assertion in a promise. Up
until now these assertions were just ignored.
Bug: v8:10556
Change-Id: I25f20e4be45a2de130562deb15f6a144f0ac976f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238569
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68503}
The IsInBounds function is used in a few different places, when used for
bounds checks on 32-bit platforms, size_t for max_memory_size leads to
incorrect out of bounds accesses as size_t is not guaranteed to be
64-bit on all platforms. Use specific uint32_t, uint64_t methods for
Wasm bounds checking instead of size_t.
Bug: chromium:1080902
Change-Id: I0e21f0a310382c8ed0703c8302200d3352495c13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2256858
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68500}
Due to recent spec changes, this CL removes the type immediate of
ref.is_null again. Instead we check if the type of the input parameter
is nullable.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: If07d30fe4dd27664be7774422573b2ab2b0dfa20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247654
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68484}
When preparsing and detecting a sloppy block function redefinition then
don't mark the variable as assigned to make it consistent with the eager
parser.
Bug: chromium:1053364
Change-Id: Iec7c24db80014bfe73ee41a4f3bb7a41a354cef2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241511
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68415}
This subsumes the old behavior of --allow-natives-for-fuzzing under
--fuzzing as well. Both flags are used in a redundant way in fuzz
configs. Only --allow-natives-for-fuzzing wasn't specified as a
required argument, leading to the bug below.
We still need the flag --allow-natives-for-differential-fuzzing
to allow different functions when using differential fuzzing.
Bug: chromium:1094866
Change-Id: I398791779e58ed4d80e896c1cfea343848159212
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2246568
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68401}
We recently changed uc32 to be an unsigned type, and with the invalid
marker being static_cast<uc32>(-1) this DCHECK no longer holds. After
this CL it expicitly checks for the invalid marker.
Bug: v8:10568,chromium:1094226
Change-Id: Idd9efe055b38387e3e37b132cb786cca130767b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245592
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68333}
Previously, for the various customisation points of String builtins
(like String.prototype.replace), we skipped the customisation symbol
lookup (like for Symbol.replace) for Smis.
But, we do need to do the lookup for Smis in case Number.prototype or
Object.prototype have the Symbol. This missing lookup was creating an
observable difference between Smis and HeapNumbers.
Bug: chromium:1092896
Change-Id: I8928d237fa74abeaa2aa81318b8903087c507f0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238030
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68285}
The reference types wasm proposal dropped all subtyping. Subsequently,
the 'anyref' type was renamed to externref.
This changes all references of the *type* anyref to externref.
Additionally, the flag that permits this extension is renamed to
"reftypes" to mirror the proposal name.
Bug: v8:7748
Change-Id: Icf323f13b9660fd10540e65125af053fca3a03f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232941
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68270}
A previous CL removed the kNoThrow flags from both
SpeculativeBigIntAdd and SpeculativeBigIntSubtract. This introduced a
bug, because the JSTypeHintLowering phase, where these operators are
introduced during inlining, does not support the generation of throwing
operators.
Since these operators always deoptimize in case of an error, instead of
throwing the exception directly, it is safe to mark them as kNoThrow.
Bug: chromium:1091461
No-Try: true
No-Tree-Checks: true
Change-Id: I551616b0c462647574e5af8824d9ed7b3252659d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235113
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68254}
Speculative BigInt addition fails to throw the expected exception
when called with non-BigInt inputs when the result of the computation
is unused. In paricular, this CL does:
- Remove kNoThrow on speculative BigInt operators
- Fix AddWithFeedback to not lose type feedback if builtin throws
to elide existing deopt loops
- Add handling of TypeCheckKind in RepresentationChanger where this
was previously ignored
Bug: chromium:1073440
Change-Id: I953a5b790fc3b37a6824f0b6546a0488c51fbb3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228493
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68181}
We use StoreOwnIC to initialize the object after creating a new object
with CreateObjectLiteral. CreateObjectLiteral stores kHoleNaNInt64
to indicate an uninitialized double field. When we actually try
to store a NaN value into that field later using StoreOwnIC, IC avoids
actually storing the new value since the existing value is "same as"
the value we try to write. The float comparison treats all NaNs as
equal. In this particular case, we should actually store the new value
since kHoleNaNInt64 value is used to represent an uninitialized field.
This cl just stores the new value even when the existing value is same
as the new value for double fields. The check is still required to
correctly track const fields.
Bug: chromium:1082293
Change-Id: Ib37061802f2403545cffa6d6fef08be074b0825d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228886
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68167}
All subtyping has been removed from the reference-types proposal. This
CL implements this proposal change now in V8.
R=manoskouk@chromium.org
Bug: v8:10556
Change-Id: I08ef064952278e03ea655461fa9f0c96426157c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2222345
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68152}
Even in unreachable code, the targets of br_table have to have matching
types.
R=thibaudm@chromium.org
Bug: v8:10556
Change-Id: I2e85df3cb92f7910a6bcb5ac03927c424194660d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218062
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68148}
With recent changes to the anyref proposal, null refs now have a type
immediate which declares the type of a null ref constant. Likewise,
the RefIsNull instruction is type aware now. This CL addresses these
proposal changes now.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: I810dfa3a4ab4389afc9639f897cee5d43e9b62cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215172
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68141}
This reverts commit 76debfda32.
Reason for revert: Nullptr access in new test: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/37265
Original change's description:
> [wasm-simd][liftoff] Fix I64x2Mul
>
> The I64x2Mul overwrote the lhs/rhs if they are the same as dst. So when
> deciding if we need temporaries, we should not only check the
> cache_state, but whether they alias dst or not.
>
> Bug: chromium:1088273
> Change-Id: I82efa9b45e0a3d321a06efde60971ce95b21490f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2225796
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68114}
TBR=clemensb@chromium.org,zhin@chromium.org
Change-Id: I5fd337b71d82d262d36ff410077a11c17b50036b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1088273
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2226756
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68117}
The I64x2Mul overwrote the lhs/rhs if they are the same as dst. So when
deciding if we need temporaries, we should not only check the
cache_state, but whether they alias dst or not.
Bug: chromium:1088273
Change-Id: I82efa9b45e0a3d321a06efde60971ce95b21490f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2225796
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68114}
Allocating a new feedback vector happens in two steps: We create an
empty structure and then initialize the array based on the
FeedbackMetadata.When allocating a new feedback array we could trigger
a GC which might flush the bytecode and associated feedback metadata.
This shouldn't happen in normal cases, because we either allocate
feedback vector after compilation or when we reach the expected budget.
In both cases, the age of the feedback vector should be 0 and hence
bytecode shouldn't be flushed. However, with debugger enabled we may
allocate feedback vectors even when the bytecode array is old
for example: when we enable precise invocation counters. This also
causes issues in tests with --stress-flush-bytecode. In the stress mode
we flush bytecode without considering the age. Holding on to the
feedback metadata prevents crashes in such cases.
Bug: v8:10560
Change-Id: Ie806ff4102cb5fcf257c8683d5ca957853e38c05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218066
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68052}
Temporarily disable stress-bytecode-flush on
mjsunit/regress/regress-786784 while we investigate failures related
to bytecode flushing.
Bug: v8:10560
Change-Id: Ieb5cc7ba87da04133e98c6be25c9a499d79543e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218038
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68046}
In BinaryOpAssembler::Generate_BinaryOperationWithFeedback, the
feedback is stored only after the respective builtin/runtime call.
If this call throws an exception, the feedback is lost, leading
to a deopt loop in some cases. This CL fixes that issue by writing
the gathered feedback before passing control to the builtin.
Bug: chromium:1077197, v8:9441
Change-Id: I20e4b14815520224e2c6f8af1af6a89f754ccddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202904
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68038}
This is a reland of 6204768bab
The original issue exposed the problem that NumberEqual performs
implicit conversion of oddballs to numbers, which is incorrect for
abstract equality comparison (i.e. 0 == null must not be true).
This reland fixes this by applying the following steps:
* Introduced a new kNumberOrBoolean value for CompareOperationFeedback,
CompareOperationHint, TypeCheckKind and CheckedTaggedInputMode.
* In CodeStubAssembler::Equal: Further distinguish between boolean and
non-boolean oddballs and set feedback accoringly.
* In JSTypedLowering: Construct [Speculative]NumberEqual operator with
CompareOperationHint::kNumberOrBoolean, when this feedback is present.
JSOperatorBuilder and operator cache are extended accordingly.
* In SimplifiedLowering: Propagate a UseInfo with new
TypeCheckKind::kNumberOrBoolean.
* This leads to the generation of CheckedTaggedToFloat64 in
RepresentationChanger with new CheckedTaggedInputMode::kNumberOrBoolean.
* In EffectControlLinearizer: Handle this new mode. Accept and convert
number and boolean and deopt for rest.
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: tebbi@chromium.org
Bug: v8:5660
Change-Id: I12e733149a1d2773cafb781a1d4b10aa1eb242a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193713
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68037}
There was a legacy place in map code that wasn't fully ported to use
the strong, new SloppyArgumentsElements type because of code that used
hard-coded constants.
Bug: chromium:1086470
Change-Id: Ieba152e4bd92c89125f831949c2efb4f4219f95c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215059
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67984}
We can't consistently rewire the successor blocks of an unreachable node to
disconnect them from the graph when we are trying to maintain the schedule.
Instead simply leave the code there. As a future optimization we could add a
proper scheduled dead code elimination phase which can deal with this.
As a side-effect, one of the tests sees a int64 DeadValue, so add support for that
in the instruction selector.
BUG=chromium:1083272,chromium:1083763,chromium:1084953,v8:9684
Change-Id: I69a6feaeef4eae62110392e27ea848b28bccf787
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209061
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67953}
The proposal uses the lane shape, e.g. i64x2.anytrue, and we were using
s1x2.anytrue in our opcodes. This was a legacy naming, because we were
trying to bitpack the booleans. Now that we aren't doing that, rename
these to be more consistent with the proposal.
This was done with a straightforward sed script, changing both cpp code
and also some comments in mjsunit test files.
Bug: v8:10506
Change-Id: If077ed805de23520d8580d6b3b1906c80f67b94f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207915
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67945}
This was introduced by https://crrev.com/c/2207137.
Load offsets can be negative.
Drive-by: Add a helper function to wrap the verbose static casts in
bounds checks.
Bug: chromium:1084872,chromium:1083450
Change-Id: I48934d04a8ab15a8fc347465064b190e32c00716
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209066
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67924}
Registers cannot be used as a merge destination if they have more than
one use, otherwise the merge will unexpectedly affect other uses of that
register.
R=ahaas@chromium.org,clemensb@chromium.org
Bug: chromium:1084151
Change-Id: I0d6ad97c585920357a37d95361e0320d32c71f4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208851
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67904}
So far this is mainly a readability improvement to specify
expectations on the packed argument. In the future we should also
check signedness during bytecode generation.
Drive-by: Update DCHECK to allow signed args to
CHECK_CURRENT_POSITION.
Bug: chromium:1083450
Change-Id: I9376ec691b51eb251c972309ad65dd6c04eec3ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207137
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67880}
The lowering for anytrue was assuming that the input nodes are all
integers. The regression test added in https://crrev.com/c/2194471 calls
anytrue with float operands, this was causing the lowering to generate
cmpl instructions with a float register and an immediate, which is
wrong.
The fix is to use GetReplacementsWithType on the input nodes, but
only if the input were floats, since we use Word32Equal.
Drive-by clean up of comments in the aforementioned regression test.
Bug: v8:10535
Change-Id: I4de89516c178e9003a4c745808d831be87918381
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203400
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67878}
The scheduler could schedule unreachable nodes on two basic blocks that
later merge. Update DCHECK in graph-assembler's basic block updater to
only check for the self-containedness of unreachable basic blocks
removed from the schedule after all the blocks have been re-written to
allow for this case.
BUG=chromium:1079446,v8:9684
Change-Id: I91899dbf389e4425542dbd2b1ca95c3f6ad79c05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196354
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67812}
The AVX implementation does not have dst == input(0), so the vminps call
was wrong. The intention is to compare the 2 input operands.
Bug: chromium:1081030
Change-Id: Id54074327a6aca4b75988fc9d85beccfeabfc791
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194471
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67786}
... when one of the receivers is a JSArray that may have a read-only
length.
Bug: chromium:1069530
Change-Id: Idbaf1a9030bb5a0f9c25e30925f18f603a99832f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196353
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67783}
Prior to this CL we still implemented a HasProperty-GetProperty
sequence when accessing named captures in GetSubstitution. This was
briefly part of the spec (we also threw an exception when the property
was not present), but since late 2017 the GetProperty call has been
unconditional.
See https://tc39.es/ecma262/#sec-getsubstitution.
Bug: v8:10513
Change-Id: Id82c06958b0b0feffc6eede580b99ab8676a0dae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2195821
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67733}
... 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}
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}
Replacing a constant BigInt with a constant int64 is only valid
when the use site has truncating semantics. (For non-constant
values, the representation changer did correctly check for this.)
Bug: chromium:1028593
Change-Id: Ib58b16ece6f21ba30153fd6cfa0560cc2d78d6a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1940263
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65262}
Reverting https://chromium-review.googlesource.com/c/v8/v8/+/1741660
This fixed one bug but caused a lot of others and on balance I think
reverting it is the lesser evil.
This also fixed generator-relocation.js because
(function*(){}).constructor is the function constructor and we try to
set a breakpoint on line 3.
Bug: chromium:109362, chromium:1028689
Fixes: v8:9721
Change-Id: I1bfe6ec57ce77ea7292df91266311f5c0194947e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1940259
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65232}
This reverts commit 48c9ca4462.
Reason for revert: Possible clusterfuzz issues
Bug: chromium:1028952
Original change's description:
> [names] Fix some test262 name tests to conform with spec changes
>
> In order to reflect web reality, TC39 has made some slight changes to
> name descriptors, see https://github.com/tc39/ecma262/pull/1490 for
> details. V8 was mostly already in compliance with these changes, but
> ThrowTypeError and anonymous classes needed some slight changes.
>
> Bug: v8:9646
> Change-Id: I163238954938f0c005e3adbc61b90498e01436da
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764622
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63373}
TBR=gsathya@chromium.org,joshualitt@chromium.org
Bug: v8:9646
Change-Id: I06dd5527d30052d9c9dfc45a2862be930274aba7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939948
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65216}
Now since we also encode KeyedAccessStoreMode information in the slow
handler for some cases, the DCheck can result in failure.The Check can
result in failures for other cases of StoreSlow. Removing the DCHECK
altogether, now verifying the correctness of the behavior using the
Kind Bits of the Handler in the method GetKeyedAccessStoreMode.
Bug: chromium:1027025, chromium:1028085
Change-Id: I59acedbb499930e67ae5999d4bfd0f040a34b46e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929408
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Suraj Sharma <surshar@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65185}
(1) One more place in ic.cc must guard against "lookup->name()" calls
when the LookupIterator might be in indexed mode.
(2) Rather than burdening LookupIterator users with specifying
"kGuaranteedNoTypedArray", we can do the corresponding calculation in
the LookupIterator itself, which makes it robust towards any callers
that haven't been updated (specifically, in Object.values).
Bug: chromium:1027461,chromium:1028213
Change-Id: I76b5d08e309fc2a694955b537adbeb5a30e681f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1936474
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65177}
This flag has had no effect since mid 2017 when its use-site was
accidentally removed (in https://codereview.chromium.org/2902533003).
Change-Id: I81436b064c2664deff781ad6d75ad47937e3fdc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934333
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65172}
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}
FunctionBlueprint holds a SharedFunctionInfo, FeedbackVector and a
Hints object that represents what we know about the Context of
the "function-to-be." Since we occasionally synthesize a
FunctionBlueprint object from a JSFunction (when we have it),
it can happen that sometimes the Context hint is a concrete
Context object, and other times it's a VirtualContext, representing
a context created sometime during the bytecode execution of the
function under optimization. Moreover, both such FunctionBlueprints
can exist in the same run due to the vagaries of CALL_IC feedback
(ie, sometimes you have a JSFunction, other times you don't).
More details in doc:
https://docs.google.com/document/d/1F1FxoDzlaYP5l5T6ZcZacV3LCUp5elcez05KWj-Mp78/edit?usp=sharing
Bug: crbug:1024282
Change-Id: Id4055531333b3dcbdb93afd23d9a226728292e11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926151
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65127}
This reduction relies on a known object layout of the regexp instance
in order to access the lastIndex field through a statically-determined
offset. Prior to this CL, we checked only for instance types, not for
the map, and thus it was possible to read garbage from either inside
or outside the current object.
Bug: chromium:1024758,v8:7779
Change-Id: I1eec8220797f443bdf3d05804e54f33b21fa2f00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924353
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65039}
Since WASM can generate direct calls to any function that it knows the
arity of and these can be any JS linkage builtin, we need to ensure that
CPP builtins also go into CODE_SPACE.
This moves 276 builtins (~25KiB) from RO_SPACE back to CODE_SPACE.
Bug: chromium:1022695, v8:7464
Change-Id: I4cda8b68ddf6a5ddad09c6e7d4e6a08c8e6c2ccb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916600
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65004}
When simulating bytecode, we store the current environment at the
site of the appropriate catch handler when entering a try range.
If the start of the try range is dead, we don't bother to store
an environment. However, generators can create alive regions
inside the try range. At such moments, we should recognize
we're in a try range and store the environment for the handler.
Bug: chromium:1017159
Change-Id: Icccc2ccf530895099bc62b97d9aaec8b97d5f4e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879247
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64929}
This allows the tests to continue running on the gc fuzzers while
staying compatible with the --force-slow-path flag being passed
randomly.
When run in slow_path variants these tests are no-ops, but that's
negligible as the tests are also fast without slow_path.
Change-Id: I461c47b669b163e1e1594ea1a941f63e90f2221e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910947
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64914}
... even with ptr-compr.
Although full uintptr-sized TypedArrays are not supported yet
we may already start using uint32-sized typed arrays as we no
longer rely on TypedArray length to be a Smi.
Bug: v8:4153
Change-Id: If179541ad4f02c4ec7de9d1f3836138fe526d8a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1905847
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64897}
The function-entry stack check should dominate all other
instructions in a function. Prior to this CL it was possible to create
paths not including a stack check due to SwitchOnGeneratorState: the
generator-creation branch had a stack check, while generator-resume
branches did not.
0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 }
4 : 27 fe fa Mov <closure>, r1
7 : 27 02 f9 Mov <this>, r2
10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2
14 : 26 fb Star r0
16 : a7 StackCheck
17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0]
22 : b1 fb fb 01 ResumeGenerator r0, r0-r0
[... no stack check here ...]
This CL moves the stack check to the beginning of the bytecode array,
i.e. before SwitchOnGeneratorState.
Bug: chromium:1020031
Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64888}
When --always-promote-young-mc is enabled, this test becomes more
flaky. Increase old space size, such that objects fit into the
old generation during mark-compact.
Bug: v8:9192
Change-Id: Iad3b914c7d5b7bafa752f3b6178684a137bd8dad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1890101
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64830}
The (age, context) pair has to be added atomically in to the weak
array of detached contexts. Otherwise, GC may happen after insertion
of age and observe inconsistent state.
Bug: chromium:1016703
Change-Id: Icb20bed4359904b2d976986a236558542e314bbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895573
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64820}
The bug is due to an unexpected opcode. To avoid similar issues in the future, we fallback to CheckContextExtensionSlowPath. This was the default behaviour before the CL (https://chromium-review.googlesource.com/c/v8/v8/+/1876051).
Bug: chromium:1020983
Change-Id: Ia7f0f2986ec0008d1128ad3856efbb5d9e52dfc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1899989
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64794}
This issue was fixed in https://chromium-review.googlesource.com/c/v8/v8/+/1873692
Bug: chromium:1016450
Change-Id: I56e1c504ae6876283568a88a9aa7d24af3ba6474
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876057
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64738}
This reverts commit b8ac4eb4dc.
Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1020533
Original change's description:
> [runtime] Correctly handle global stores when global object has proxies
>
> When global object has proxies we should first call hasProperty and
> then call SetProperty if has property returns true. This cl fixes both
> StoreGlobal and StoreLookupGlobal to correctly handle these cases.
>
> Bug: chromium:1018871
> Change-Id: I140514e2119c6bab2125abcdc1b19d46526be5ff
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1889885
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64687}
TBR=mythria@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1018871
Change-Id: I5abbf9275cba17576e1b1e492abd36d6bc1ca1bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893194
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64714}
When global object has proxies we should first call hasProperty and
then call SetProperty if has property returns true. This cl fixes both
StoreGlobal and StoreLookupGlobal to correctly handle these cases.
Bug: chromium:1018871
Change-Id: I140514e2119c6bab2125abcdc1b19d46526be5ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1889885
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64687}
JSProxy::HasProperty returns Nothing<bool>() when there is an
exception when executing has trap handler. We should not treat
these cases similar to not found cases.
Bug: chromium:1018871
Change-Id: I5510e707c96576d2dca4c8402e21a89065cc9b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886919
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64670}
This is a reland of 4a16305b65
The original CL adjust only one part of the stack check, namely the
comparison of the stack pointer against the stack limit in generated code.
There is a second part: Runtime::kStackGuard repeats this check to
distinguish between a stack overflow and an interrupt request.
This second part in runtime must apply the offset just like in generated
code. It is implemented in this reland by the StackCheckOffset operator
and a new StackGuardWithGap runtime function.
Original change's description:
> [compiler] Optionally apply an offset to stack checks
>
> The motivation behind this change is that the frame size of an optimized
> function and its unoptimized version may differ, and deoptimization
> may thus trigger a stack overflow. The solution implemented in this CL
> is to optionally apply an offset to the stack check s.t. the check
> becomes 'sp - offset > limit'. The offset is applied to stack checks at
> function-entry, and is set to the difference between the optimized and
> unoptimized frame size.
>
> A caveat: OSR may not be fully handled by this fix since we've already
> passed the function-entry stack check. A possible solution would be to
> *not* skip creation of function-entry stack checks for inlinees.
>
> This CL: 1. annotates stack check nodes with the stack check kind, where
> kind is one of {function-entry,iteration-body,unknown}. 2. potentially
> allocates a temporary register to store the result of the 'sp - offset'
> in instruction selection (and switches input registers to 'unique'
> mode). 3. Applies the offset in code generation.
>
> Drive-by: Add src/compiler/globals.h for compiler-specific globals.
>
> Bug: v8:9534,chromium:1000887
> Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63701}
Bug: v8:9534, chromium:1000887
Change-Id: I71771c281afd7d57c09aa48ea1b182d01e6dee2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822037
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64634}
The `capture_ix` refers to all captures while `capture_count` only
refers to named captures. Clarified by renaming `capture_count` to
`named_capture_count` and removing the incorrect part of the DCHECK.
The `>= 1` part of the condition must still hold since named captures
can only refer to explicit capture groups, which start at index 1.
Tbr: petermarshall@chromium.org
Bug: chromium:1018592
Change-Id: If8a26f6661ba0483d585f74270b3b4a3853e2ca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886810
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64629}
Otherwise the expression scope may be in a weird state and DCHECKs for valid
arrow functions in ValidateAndCreateScope willl unnecessarily fire.
Bug: chromium:1018611
Change-Id: I101b8902dce07c29aacba3e7a5e6f86d66505d5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879906
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64591}
When global object has proxies we should first call hasProperty and
then call GetProperty according to spec. This cl fixes both
LoadGlobal and LoadLookupGlobal to correctly handle these cases.
Also fixes tests that didn't expect hasProperty to be called.
Change-Id: I3a45df7ae24be74dd46cf04cafbf8c2d7018b3af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876059
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64580}
This code is triggered by Runtime_ArrayIncludes_Slow. The elements kind
changes from DICTIONARY (with accessor property using
Object.defineProperty) to empty DICTIONARY (by set the length to 0), to
frozen/seal/nonextensible elements. This element kind transition
happened in accessor property by Array.includes.
Bug: v8:9894
Change-Id: I224ceb537ff358a30a6e00414c71d6fe18924bb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876994
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64575}
Original change's description:
> [runtime] Remove extension slots from context objects
>
> Context objects have an extension slot, which contains further
> additional data that depends on the type of the context.
>
> This CL removes the extension slot from contexts that don't need
> them, hence reducing memory.
>
> The following contexts will still have an extension slot: native,
> module, await, block and with contexts. See objects/contexts.h for
> what the slot is used for.
> The following contexts will not have an extension slot anymore (they
> were not used before): script, catch and builtin contexts.
> Eval and function contexts only have the extension slot if they
> contain a sloppy eval.
>
> Bug: v8:9744
> Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> Commit-Queue: Victor Gomes <victorgomes@google.com>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64372}
TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
Bug: v8:9744
Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64477}
If a new jump table is created and lazy compilation is enabled, we need
to initialize the new jump table with jumps to the lazy compile table.
R=ahaas@chromium.org
Bug: chromium:1016515
Change-Id: I5749470d4a08af903a6a4da13dbe5454ee6db309
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873687
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64462}
Parenthesized variable names are valid references for assignment. To make sure
we can properly mark the variable as assigned, we should push parenthesized
variables to the outer expression scope after the parenthesized expression is
guaranteed to not be an arrow head; so that the variable list of the parent is
complete.
Technically we could probably get by with simply pushing a single variable,
since more complex expressions aren't valid parenthesized assignment targets:
(a) = ... and [(a),(b)] = ... are valid, but ([a,b]) = ... isn't.
It doesn't really seem worth it though.
Bug: chromium:1015372
Change-Id: I095c35126742a14d0171537b9795f7258c33ab4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872389
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64455}
This is a reland of c48096d442
Original change's description:
> Reland "[runtime] Remove extension slots from context objects"
>
> This is a reland of c07c02e1c4
>
> Original change's description:
> > [runtime] Remove extension slots from context objects
> >
> > Context objects have an extension slot, which contains further
> > additional data that depends on the type of the context.
> >
> > This CL removes the extension slot from contexts that don't need
> > them, hence reducing memory.
> >
> > The following contexts will still have an extension slot: native,
> > module, await, block and with contexts. See objects/contexts.h for
> > what the slot is used for.
> > The following contexts will not have an extension slot anymore (they
> > were not used before): script, catch and builtin contexts.
> > Eval and function contexts only have the extension slot if they
> > contain a sloppy eval.
> >
> > Bug: v8:9744
> > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> > Commit-Queue: Victor Gomes <victorgomes@google.com>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Auto-Submit: Victor Gomes <victorgomes@google.com>
> > Cr-Commit-Position: refs/heads/master@{#64372}
>
> TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
>
> Bug: v8:9744
> Change-Id: I0749cc2d8f59940c25841736634a70047116d647
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64380}
TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
Bug: v8:9744
Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@google.com>
Cr-Commit-Position: refs/heads/master@{#64451}
When using promise hooks we can actually end up in capturing stack trace
with an async generator on the stack whose queue is empty, and we need
to gracefully handle that case as well.
Fixed: chromium:1015945
Change-Id: Ia459e7444b373ecab01ca6900a781fd8b4021d1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870230
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64403}
At certain points in time we learn that we have to drop certain errors in the
ExpressionScope. If an AccumulationScope appears between where we learn about
the error and where we drop the error, we previously stopped accumulating,
assuming that we're already going to fail anyway. Since we might drop the
earlier error later; we can't early on this. Instead the accumulator should
simply keep on accumulating, keeping the earlier error alive across
accumulation.
Bug: chromium:1015567
Change-Id: I4d70643d02233fe82582b568a0a946eacf883880
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869198
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@{#64384}
With the recent removal of the --wasm-shared-code flag, it became
effectively impossible to turn off this flag. Hence its functionality
became mandatory and the ability to turn off sharing of {WasmEngine}
process-wide has to be removed as well.
R=clemensb@chromium.org
Change-Id: I7c25e909e49134a226d6a9fe9c42f0ecd9d02a69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864935
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64322}
It turns out that because we are *subtracting* from fp, we need to
*subtract less* to get a higher address. Who knew.
R=jkummerow@chromium.org
Bug: v8:9830, chromium:1014798
Change-Id: I5b9782dd0be27f4c3efbd306ec6c3450b249cb55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864933
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64321}
