The table.copy bytecode copies a range of table entries in a similar
way to memcopy. This CL implements the behavior in a runtime call
that calls into the wasm engine.
R=mstarzinger@chromium.org,binji@chromium.org
BUG=v8:7747
Change-Id: I420451202b1b78ea92cbd10387a644ed57e111c8
Reviewed-on: https://chromium-review.googlesource.com/c/1414919
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58858}
That makes the declaration in sync with how dynamic references are resolved,
avoiding duplicate variable creation in the likely case that the variable is
also referenced within the eval.
Bug: v8:5112, v8:5135, v8:8693
Change-Id: I0c55495f573fe8b5076b1627c139ff72d1adda74
Also-by: leszeks@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/1408890
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58850}
Storing a VariableProxy in declarations means that a declaration and
initialisation assignment are tightly coupled to use the same var. In
particular, this means that Var declarations in with scopes have to
clone the VariableProxy to split the declaration and initializer LHS
lookup.
This patch changes declarations to point directly to the Variable, not
the VariableProxy. This will allow future refactoring to decouple
declarations and initialisations.
Change-Id: I0baa77bfd12fe175f9521d292740d7d712cffd37
Reviewed-on: https://chromium-review.googlesource.com/c/1406683
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58843}
Now the embedder can instruct V8 to restore the initial heap limit
once the heap size drops below the given percentage of the heap limit.
Bug: chromium:922038
Change-Id: Ib668406c5d59c02b45a8eae7de96527ebc3f2b4d
Reviewed-on: https://chromium-review.googlesource.com/c/1411606
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58837}
This switches the experimental exception handling implementation to the
new proposal where 'catch' blocks behave in a catch-all fashion and a
new 'br_on_exn' operation is used to check for a certain exception type
and extract the exception values on a match.
R=clemensh@chromium.org
TEST=unittests/FunctionBodyDecoderTest,mjsunit/wasm/exceptions
BUG=v8:8091
Change-Id: Ib12ba28b3aa2a7d831312a83abcb00bf56d0adc3
Reviewed-on: https://chromium-review.googlesource.com/c/1409431
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58832}
The parenthesized flag guarantees that the contents was validated as a possible
arrow head. By collapsing a parenthesized expression with an outer binary
expression we invalidly kept the flag and invalidly assumed that the collapsed
expression was validated.
Bug: chromium:921382
Change-Id: I207dcbfd228a1ed216130226fdb7ea045b89b85a
Reviewed-on: https://chromium-review.googlesource.com/c/1412172
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58829}
We often use ResultBase or VoidResult to store or pass wasm errors
(errors with locations). This CL extracts a WasmError class which can
store an error (can also be empty), and Result<T> which stores an error
or a T (exactly one of them).
R=titzer@chromium.org
Bug: v8:8689
Change-Id: I3f5203559984a0ae8757e0130a9184957fa28df5
Reviewed-on: https://chromium-review.googlesource.com/c/1409365
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58827}
A sloppy function in a block scope implicitily creates a var in the outer
declaration scope if it's not blocked. The assignment created reads the local
lexical declaration for the function. The reference introduced automatically
takes part in NeedsHoleCheck, requiring the reference to have a valid position.
Since the assignment will happen after the local declaration, we give the
end_position() of the closure as the position of the reference, so hole checks
can be omitted.
Bug: chromium:917755
Change-Id: Iee0e042b2463f97f05075f9eec09dac8c6eaf539
Reviewed-on: https://chromium-review.googlesource.com/c/1408991
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58823}
With this CL we support importing mutable anyref globals. The CL
contains the following changes:
* We store a reference to the buffer of the imported global in
`WasmInstance::imported_mutable_globals_buffer`. This FixedArray is
already used to keep the ArrayBuffers of value-typed imported
mutable globals alive but was not accessed otherwise.
* We store the offset in the buffer of the imported global in
`WasmInstance::imported_mutable_globals`. This `Address`-array is
used for value-typed imported mutalbe globals to store direct
pointers into the backing store of the ArrayBuffer of the imported
global.
* In wasm-compiler.cc we generate code to load these fields and then
load or store globals.
* in module-compiler.cc I removed the counter variable
`next_imported_mutable_global_index`. The variable was only used for
a DCHECK. I replaced the DCHECK with a slightly weaker DCHECK now.
* Tests.
R=mstarzinger@chromium.org
Bug: v8:7581
Change-Id: I11f0f4d8637c98eded5fb2eec44bc8ead8ed5c7b
Reviewed-on: https://chromium-review.googlesource.com/c/1409169
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58822}
--jitless -> --no-opt
-> --no-validate-asm
-> --wasm-interpret-all -> --no-asm-wasm-lazy-compilation
-> --no-wasm-lazy-compilation
Note that wasm still isn't supported in jitless mode since it generates
code at runtime even with --wasm-interpret-all.
Drive-by: Fail early when trying to compile irregexp code in jitless
mode.
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Bug: v8:7777
Change-Id: I7f0421f71efeaaeb030ed9ec268d12a659667acf
Reviewed-on: https://chromium-review.googlesource.com/c/1406677
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58820}
EnumSet currently lives in src/utils.h, which is a conglomerate of many
different helper functions and classes. In order to remove unneeded
include, move the EnumSet to its own header.
R=titzer@chromium.org
Bug: v8:7490, v8:8562
Change-Id: I979814167e87b914e9807b03e342d8b34e514331
Reviewed-on: https://chromium-review.googlesource.com/c/1409430
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58818}
The table.drop bytecode "drops" the backing storage for an element
initializer. In the V8 implementation, this is a nop, other than
updating a per-instance boolean array so that two drops of the same
segment or a drop of an active segment will trap.
This is implemented with inline code in TurboFan in order to be symmetric
to memory.drop, but could as easily be a runtime call to be supported in
Liftoff.
R=mstarzinger@chromium.org
CC=binji@chromium.org
BUG=v8:7747
Change-Id: Ic017398eaa764dd3a9ff19523453ff7142c9abf6
Reviewed-on: https://chromium-review.googlesource.com/c/1408996
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58817}
It is slightly faster than Page::FromAddress(o->address()) (saves
one instruction), and more concise than Page::FromAddress(o->ptr()).
Same for MemoryChunk::FromHeapObject().
Bug: v8:8562
Change-Id: I9dc2b787aed5cad2d4087850dfa2e8eb157ad225
Reviewed-on: https://chromium-review.googlesource.com/c/1405031
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58806}
This removes the iteration protocol from the parser entirely, and opens
up future possibilities for more bytecodes implementing the various
functions of the protocol.
Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb
Reviewed-on: https://chromium-review.googlesource.com/c/1403125
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58795}
The background compile tasks should not access the NativeModule during
the main compile phase.
This CL moves on of the accessed fields into the {CompilationEnv}. It
is initialized from the existing field on the {NativeModule}.
R=titzer@chromium.org
Bug: v8:8689
Change-Id: I9738e2fb4681a035cbacf3c9e00b9e5cc9419416
Reviewed-on: https://chromium-review.googlesource.com/c/1409423
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58793}
The --perf-prof flag generates unwanted .dump files, while the
--perf-prof-unwinding-info flag enables the functionality under test here.
R=jgruber@chromium.org
BUG=chromium:913844
Change-Id: Ie5ee374977d6105854f42065600dac1bc5ba6df7
Reviewed-on: https://chromium-review.googlesource.com/c/1409363
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58791}
This reverts commit 68a8bdd829.
Reason for revert: memory regression: crbug.com/921239
Original change's description:
> [heap] Remove bailout marking worklist.
>
> The concurrent marker can now process all objects.
> This patch also eagerly visits the objects that undergo layout
> changes. This is because previously such objects were pushed
> onto the bailout worklist, which is gone now.
> To preserve the incremental step accounting, the patch introduces
> a new GC tracer scope called MC_INCREMENTAL_LAYOUT_CHANGE.
>
> Bug: v8:8486
> Change-Id: Ic1c2f0d4e2ac0602fc945f3258af9624247bd65f
> Reviewed-on: https://chromium-review.googlesource.com/c/1386486
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58712}
TBR=ulan@chromium.org,mlippautz@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8486, chromium:921239
Change-Id: I1f851b948f4ce403316e469999f0b16e8dfdb62d
Reviewed-on: https://chromium-review.googlesource.com/c/1408990
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58787}
This CL adds two new runtime calls for table operations:
- Runtime_WasmTableInit
- Runtime_WasmTableCopy
These runtime calls (will) implement the semantics for the corresponding
bytecodes from the bulk memory proposal. The actual implementation
of these runtime calls will be done in further CLs.
The third table operation, table.drop, will be implemented with inline
code, similar to memory.drop. This is also be done in a further CL.
R=mstarzinger@chromium.org
CC=binji@chromium.org
BUG=v8:7747
Change-Id: I498aa054329baf9f72ae55d245b12c3ccd4157b7
Reviewed-on: https://chromium-review.googlesource.com/c/1408994
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58786}
This is a reland of e2d44ede95
Original change's description:
> [parser] Inline byte scope data into PreparseData object
>
> Each PreparseData object had at least one pointer to a PodArray for its
> serialized scope data. These objects usually have only tens of bytes of
> payload. By inlining the byte data we save 3 words per PreparseData object.
> This optimization saves 140KB of data on cnn.com.
>
>
> - Store data_length and inner_length as int32 saving a words on 64bit
> - Inline store byte data into PreparseData
> - OnHeapConsumedPreparseData directly uses the PreparseData object
> - get_inner, set_inner no longer allow Null sentinels
>
> Change-Id: I1f62154d05ea2f98a6574efa738b32a8a84319d5
> Reviewed-on: https://chromium-review.googlesource.com/c/1406673
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58751}
Change-Id: I1f0a22c641d0d67f435b01c82daf8da7f144bff4
Reviewed-on: https://chromium-review.googlesource.com/c/1407066
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58785}
Instead, pass it as a parameter to the compilation.
This makes compilation units slimmer with the end goal of them being
just the function index and execution tier.
It also makes ownership handling of the NativeModule easier.
R=titzer@chromium.org
Bug: v8:8343, v8:7921
Change-Id: I0522c894569c71d8b7245f5ed5612ab2a249e1ad
Reviewed-on: https://chromium-review.googlesource.com/c/1406668
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58776}
This matches the terminology that is used throughout the spec.
R=clemensh@chromium.org
Change-Id: I62445e750415e6048b805110c7306f3bdbf9da60
Reviewed-on: https://chromium-review.googlesource.com/c/1408988
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58774}
It removes the assertion that caused the bug report by introducing a new
trampoline (WasmBigIntToI64) for the conversion code stub between a Bigint
object and a Wasm i64 BigIntToI64).
The tests were updated to cover calling the stub from a Wasm callsite.
Bug: v8:8625
Change-Id: I55891001cfa72f6f2849792293b43bbb54147f1a
Reviewed-on: https://chromium-review.googlesource.com/c/1405028
Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58767}
Bug: chromium:917215
Change-Id: Ie2127953a8ce3d6da4feb3478039ba318774e21d
Reviewed-on: https://chromium-review.googlesource.com/c/1404176
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58755}
This reverts commit e2d44ede95.
Reason for revert: Breaks GC stress tests - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/23527
Original change's description:
> [parser] Inline byte scope data into PreparseData object
>
> Each PreparseData object had at least one pointer to a PodArray for its
> serialized scope data. These objects usually have only tens of bytes of
> payload. By inlining the byte data we save 3 words per PreparseData object.
> This optimization saves 140KB of data on cnn.com.
>
>
> - Store data_length and inner_length as int32 saving a words on 64bit
> - Inline store byte data into PreparseData
> - OnHeapConsumedPreparseData directly uses the PreparseData object
> - get_inner, set_inner no longer allow Null sentinels
>
> Change-Id: I1f62154d05ea2f98a6574efa738b32a8a84319d5
> Reviewed-on: https://chromium-review.googlesource.com/c/1406673
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58751}
TBR=ulan@chromium.org,cbruni@chromium.org,leszeks@chromium.org
Change-Id: I39d92ee7bd2864e1b0c3a8fed4a11b68b3e14d58
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1407073
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58753}
Each PreparseData object had at least one pointer to a PodArray for its
serialized scope data. These objects usually have only tens of bytes of
payload. By inlining the byte data we save 3 words per PreparseData object.
This optimization saves 140KB of data on cnn.com.
- Store data_length and inner_length as int32 saving a words on 64bit
- Inline store byte data into PreparseData
- OnHeapConsumedPreparseData directly uses the PreparseData object
- get_inner, set_inner no longer allow Null sentinels
Change-Id: I1f62154d05ea2f98a6574efa738b32a8a84319d5
Reviewed-on: https://chromium-review.googlesource.com/c/1406673
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58751}
The fuzzers were already removed on the chrome side and therefore
inactive, see https://crrev.com/c/1194228.
R=machenbach@chromium.org
Bug: v8:8562
Change-Id: I0cf5ec6d07e07452c5168ea952f45028bcea1c85
Reviewed-on: https://chromium-review.googlesource.com/c/1406678
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58750}
It is not legal for destructuring patterns and identifiers in declarations
to be in parentheses. This includes nested patterns/identifiers inside
another pattern.
We were checking sub-patterns for parentheses when parsing possible
sub-patterns, but this check missed sub-patterns with a default
initialiser (e.g. [({x:y})=1] = {}), as the AssignmentExpression hid
the pattern.
So, we now additionally record declaration/pattern errors of an assignment
LHS when parsing the assignment cover grammar.
Bug: v8:8630
Change-Id: Ia5a97003671fc1da7f68d7fb15943928ce9496e3
Reviewed-on: https://chromium-review.googlesource.com/c/1404452
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58743}
The JSRegExp's data fixed array is variable size depending on the
regexp kind.
Bug: v8:8572
Change-Id: I8f07b8e8d2a9a81e0905563fb701e1e3687cafb5
Reviewed-on: https://chromium-review.googlesource.com/c/1405034
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58741}
As far as I can tell these were unused; their only callers were arm
and ppc simulators, but codegen explicitly returned nullptr if in a
simulator build, falling back to std::sqrt.
There's more potential cleanup to be done here for other functions
defined in codegen-*.cc files.
Tbr: clemensh@chromium.org
Bug: v8:7777, v8:8675
Change-Id: I4b9d6062c6724a810ab094d09e3cd04a0b733d9b
Reviewed-on: https://chromium-review.googlesource.com/c/1405851
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58740}
In the degenerate case where we wanted to emit {x = x - x} (where {x}
is any register), ia32 and x64 generated wrong code (producing {-x + -x}
instead). Fix this by special casing this case.
R=ahaas@chromium.org
Bug: chromium:919308
Change-Id: I9cd9818d2a678450ac6530107e7a5cbb625ddb8d
Reviewed-on: https://chromium-review.googlesource.com/c/1405029
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58731}
This avoids having to update either the source code or the generated
test cases each year.
R=ahaas@chromium.org
Change-Id: I33fb85dc4ae7d45f8d05d982e0285d6fd3008a26
Reviewed-on: https://chromium-review.googlesource.com/c/1405032
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58725}
i64 values can be up to 20 characters long (19 + sign), plus we need
one character for the terminating null character. Thus the previous 18
needs to be increased to 21.
Also extend the test to check the longest possible i64 values.
R=ahaas@chromium.orgCC=kozyatinskiy@chromium.org
Bug: v8:8644
Change-Id: Ia9458db162a55dd57b5e8bc7cf7db73c3bab4734
Reviewed-on: https://chromium-review.googlesource.com/c/1404443
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58724}
In {Assembler::and_} we might need to use the scratch register. Thus use
a free LiftoffRegister instead to emit i32 popcnt.
R=ahaas@chromium.orgCC=george.wort@arm.com
Bug: chromium:918284
Change-Id: Ia814899bf6e33dd4989fd09329542b4bc09b48df
Reviewed-on: https://chromium-review.googlesource.com/c/1405036
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58723}
This is a reland of 8f83fd0a55
Original change's description:
> [wasm] Fix SIMD boolean reductions on Intel
>
> - Both AllTrue/AnyTrue values should return boolean 0/1
> instead of 0xffffffff to match Spec/Toolchain
> - Fix AllTrue implementation to be correct
> - Add unit tests to spot check return values as the
> cumulative test can coerce some return values to True/False
>
> Change-Id: I84eb73c915414c9ec290e73f1306404ceff729f0
> Bug: v8:8636
> Reviewed-on: https://chromium-review.googlesource.com/c/1404197
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58715}
Bug: v8:8636
Change-Id: Ifc438d7b64bf5d461cc848851165665104fe57d0
Reviewed-on: https://chromium-review.googlesource.com/c/1405909
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58719}
- Both AllTrue/AnyTrue values should return boolean 0/1
instead of 0xffffffff to match Spec/Toolchain
- Fix AllTrue implementation to be correct
- Add unit tests to spot check return values as the
cumulative test can coerce some return values to True/False
Change-Id: I84eb73c915414c9ec290e73f1306404ceff729f0
Bug: v8:8636
Reviewed-on: https://chromium-review.googlesource.com/c/1404197
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58715}
If feedback for call site frequency is 0, then the combined frequency
is still 0, even if the current function invocation count is infinity.
Bug: chromium:919754
Change-Id: I97be096b6b38f934fb13f01b2b22e148c539e1c0
Reviewed-on: https://chromium-review.googlesource.com/c/1404445
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58714}
If a species constructor is installed, filter() needs to loop over
the elements of the array in the "slow" way, because it doesn't
know the ElementsKind of the output array. The code failed to
bail out to the slow case for the loop right away on discovering this.
Bug: chromium:920184, chromium:920491
Change-Id: I74496db20a90807b631c1bebe7604d85b199df67
Reviewed-on: https://chromium-review.googlesource.com/c/1405035
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58713}
The concurrent marker can now process all objects.
This patch also eagerly visits the objects that undergo layout
changes. This is because previously such objects were pushed
onto the bailout worklist, which is gone now.
To preserve the incremental step accounting, the patch introduces
a new GC tracer scope called MC_INCREMENTAL_LAYOUT_CHANGE.
Bug: v8:8486
Change-Id: Ic1c2f0d4e2ac0602fc945f3258af9624247bd65f
Reviewed-on: https://chromium-review.googlesource.com/c/1386486
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58712}
Use the right register type for the temporary register.
R=titzer@chromium.org
Bug: v8:6600, chromium:917588
Change-Id: Ia2617f6b406924ca7f496608fd495faf04dff25b
Reviewed-on: https://chromium-review.googlesource.com/c/1403127
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58711}
Keep track of loop nesting depth on FunctionState and use that to decide
whether to mark var as assigned. That also fixes the weird cornercase where a
loop body can have multiple expressions due to multiple declarations with
independent initializers in a single var-statement.
Change-Id: Ia24affde29e22e9464448fd390062f6dd983faf2
Reviewed-on: https://chromium-review.googlesource.com/c/1405037
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58707}
For desrtucturing assignments from null/undefined, we throw an error
that references the destructuring object literal's property name, e.g.
for
var { x } = null;
we report that we cannot destructure 'x' from null.
Rather than calculating this property during bytecode generation (and
including it in the bytecode as an argument to the type error
constructor), we can calculate it at exception throwing time, by
re-parsing the source in a similar way to the existing call site
rendering.
This slightly decreases bytecode size and slightly decreases the amount
of work the bytecode compiler needs to do. In the future, it could also
allow us to give more detailed error messages, as we now have access to
the entire AST and are on the slow path anyway.
Bug: v8:6499
Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72
Reviewed-on: https://chromium-review.googlesource.com/c/1396080
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58706}
Mostly signed integer overflows, and a few cases of double
division by zero (which is defined by IEEE-754 to return
Infinity (or NaN for 0/0) but is UB in C++).
In base/ieee754.cc, use constants for NaN and Infinity instead
of computing these values.
In spaces-unittest.cc, ensure that a large enough allocation
is used.
Bug: v8:3770
Change-Id: I50d9a77dc860ef9993b7b269a5f8c117b0f62f9d
Reviewed-on: https://chromium-review.googlesource.com/c/1403454
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58701}
This reverts commit 5dee355fe6.
Reason for revert: https://ci.chromium.org/p/v8-internal/builders/luci.v8-internal.ci/v8_linux64_perf_1/4282
Original change's description:
> [test] add perf tests for String.p.startsWith
>
> Add performance tests for String.prototype.startsWith ahead of port to
> torque in order to keep track of how performance is affected.
>
> Bug: v8:8400
> Change-Id: Ifc753a6f13da20c1760e545a99fd693717e3acc6
> Reviewed-on: https://chromium-review.googlesource.com/c/1402934
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58685}
TBR=jgruber@chromium.org,usharma1998@gmail.com
Change-Id: I5855b08fa5e55ab8594185a0a84a26f567e2b9d3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8400
Reviewed-on: https://chromium-review.googlesource.com/c/1404446
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58697}
Mostly signed integer overflows, and a few cases of double
division by zero (which is defined by IEEE-754 to return
Infinity (or NaN for 0/0) but is UB in C++).
Bug: v8:3770
Change-Id: Id92725b0ac57cb357978124a3dc6f477430bc97d
Reviewed-on: https://chromium-review.googlesource.com/c/1403133
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58696}
The 'done' setting dance in BuildFillArrayWithIterator turned out to
not be useful, as the StoreInArrayLiteral call could not ever throw an
exception. Since iterator exceptions count as done, we are guarnteed to
be done as soon as we enter the loop.
Change-Id: Ibe2ba1fcbe383bfcfedb185169890b6931cc7884
Reviewed-on: https://chromium-review.googlesource.com/c/1402792
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58695}
The IteratorClose spec specifies that exceptions in
%GetMethod(iterator.return) are not suppressed by exceptions in the
given continuation (body of a loop, assignments in destructuring),
while exceptions in the execution of iterator.return() are.
This means that we have to split out the property access + a typeof
check to be outside the try-catch, and keep the call inside of it.
The non-split version is only for cases when there is no 'throws'
continuation (as is the case for yield* calling IteratorClose), so
the existing BuildIteratorClose can be renamed to reflect this.
Change-Id: Id71aea4fddd6ffb986bd9aaa09d29615a8800f71
Reviewed-on: https://chromium-review.googlesource.com/c/1402789
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58694}
Mostly signed integer overflows, and a few cases of double
division by zero (which is defined by IEEE-754 to return
Infinity (or NaN for 0/0) but is UB in C++).
Bug: v8:3770
Change-Id: I8007987594ff534ca697c1c3247215a72a001343
Reviewed-on: https://chromium-review.googlesource.com/c/1403132
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58693}
This CL disables RX (read and execute) permissions for Code memory
when in jitless mode. All memory that was previously allocated RX
is now read-only.
Bug: v8:7777
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: I52d6ed785d244ec33168a02293c5506d26f36fe8
Reviewed-on: https://chromium-review.googlesource.com/c/1390122
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58692}
Add performance tests for String.prototype.startsWith ahead of port to
torque in order to keep track of how performance is affected.
Bug: v8:8400
Change-Id: Ifc753a6f13da20c1760e545a99fd693717e3acc6
Reviewed-on: https://chromium-review.googlesource.com/c/1402934
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58685}
If the key of the u-ext has no value it will return error so
we should just return undefined for that case.
Bug: v8:8663
Change-Id: I7446ad74c8d0609ad268385b6f4d986060424ce9
Reviewed-on: https://chromium-review.googlesource.com/c/1404194
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58682}
Since register can be used multiple times on the stack, they can also
be spilled into multiple stack slots. At merge points, we then might
have to reload the spilled slots. A DCHECK currently checks that each
register is only loaded once. Instead of failing, just load the first
stack slot, the others are statically known to contain the same value
anyways.
R=ahaas@chromium.org
Bug: v8:6600, chromium:919533
Change-Id: Ic0c806238b2997f006829b4b509a50468a55befa
Reviewed-on: https://chromium-review.googlesource.com/c/1403124
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58676}
The unwinding info writer was assuming that a block that had no initial
state must be the start or end block. It was trying to check if the
block was the start or end by asserting that the block had either
no predecessors or no successors. Loop rotation breaks this assumption,
since it can move a block from inside a loop to before the loop
header, and the block can then be the "start" block. But since
such a block has both predecessor(s) and a successor, the check was
wrong.
R=clemensh@chromium.org
BUG=chromium:913844
Change-Id: Ic24c67a822d510cb082f25608089d313c3459be8
Reviewed-on: https://chromium-review.googlesource.com/c/1373770
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58675}
Emit a single destructuring assignment for destructuring declarations,
which can be desugared by the bytecode generator. This allows us to
remove destructuring desugaring from the parser (specifically, the
pattern rewriter) entirely.
The pattern "rewriter" is now only responsible for walking the
destructuring pattern to declare variables, mark them assigned, and
potentially rewrite scopes for the edge case of parameters with a sloppy
eval.
Note that since the rewriter is no longer rewriting, we have to flip the
VariableProxy copying logic for var re-lookup, so that we now pass the
new VariableProxy to the variable declaration and leave the original
unresolved (rather than passing the original through and rewriting to a
new unresolved VariableProxy).
This change does have some effect on breakpoint locations, due to some
of the available information changing between the parser and bytecode
generator, however the new locations appear to be more consistent
between assignments and declarations.
Change-Id: I3a58dd0a387d2bfb8e5e9e22dde0acc5f440cb82
Reviewed-on: https://chromium-review.googlesource.com/c/1382462
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58670}
Ivica Bogosavljevic is no longer part of MIPS V8 team, and therefore his
name is removed from OWNERS.
TBR=mstarzinger@chromium.org
NOTRY=true
No-Presubmit: true
Change-Id: I1ea6745b795573a17362dfd869528ddf78b8ab41
Reviewed-on: https://chromium-review.googlesource.com/c/1402775
Commit-Queue: Predrag Rudic <prudic@wavecomp.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58667}
These flakes can't be reproduced locally so we need more information
when they fail. Add some logging so that we can figure out why they
are breaking.
Bug: v8:8649, v8:8648
Change-Id: I2fb1384bb7592c6fc68c08952505e79329f00bec
Reviewed-on: https://chromium-review.googlesource.com/c/1400418
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58641}
Print all the mismatch failures in the bytecode rather than aborting at
the first mismatch.
R=rmcilroy
Change-Id: Id572ead5fdc4d126ac9a05942f940b0eaef7150f
Reviewed-on: https://chromium-review.googlesource.com/c/1400412
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58628}
This CL adds support for anyref in WebAssembly.Global objects. Note
that the specification is not complete yet in this area.
I did the following changes:
- I renamed the `array_buffer` field of WasmGlobalObject to
`untagged_buffer`
- I added an additional field of type FixedArray, `tagged_buffer`.
- In the constructor of WasmGlobalObject I allocate either the former
or the latter, but not both.
- In the WebAssembly.Global constructor I added special handling for
the case where no initial value is provided. In that case I set the
inital value to `null` and not to `undefined`.
R=titzer@chromium.org
Bug: v8:7581
Change-Id: I7e4855d7e6c04a9bcdc7ebd450caca5819d060e2
Reviewed-on: https://chromium-review.googlesource.com/c/1398226
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58625}
If we have both f32 and f64 locals, we use the same register to hold
their zero value. On stack transfers, we might thus encounter the same
fp register with both the f32 and f64 type. Explicitly allow that case
to happen.
R=ahaas@chromium.org
Bug: chromium:918917, v8:6600
Change-Id: I6937008d38853fe2bdccd9715e1a2499cf6bf7c6
Reviewed-on: https://chromium-review.googlesource.com/c/1398225
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58623}
This CL prevents redundancy elimination from widening types, which
can cause problems if the input of a DeadValue (which has type None)
is replaced by an equivalent node that does not have type None. This
can happen because load elimination does not re-type nodes, for
example.
Bug: chromium:919340
Change-Id: I89e872412edbcdc610e70ae160cde56cd045006c
Reviewed-on: https://chromium-review.googlesource.com/c/1397709
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58617}
The two names refer to the same thing by now, so this patch is
entirely mechanical.
Bug: v8:3770
Change-Id: Ia360c06c89af6b3da27fd21bbcaeb2bdaa28ce22
Reviewed-on: https://chromium-review.googlesource.com/c/1397705
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58615}
This is a reland of part of
https://chromium-review.googlesource.com/c/v8/v8/+/1397664.
It drops the explicit fni_.Infer() call after parsing arrow functions. We'll
want to avoid inferring if the arrow function is an argument to a function
call.
It also avoids adding the single argument of "name => " to the inferred name.
Bug: chromium:916975
Change-Id: I96a934408113483d73eba14073fe21e8cfe2ada6
Reviewed-on: https://chromium-review.googlesource.com/c/1397665
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58613}
Fix WebAssembly's global/constructor js-api. Globals with a value
of i64 is now valid even if Wasm BigInt feature isn't activated.
Bug: v8:8319
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Change-Id: Ia41ad69efa5253064ecdb8f59b149393cd672b68
Reviewed-on: https://chromium-review.googlesource.com/c/1382747
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58603}
This patch sets the name slot of the private name symbols for
private fields and display the names in error messages of invalid
private field accesses.
TBR: adamk@chromium.org
Bug: v8:8144
Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76
Reviewed-on: https://chromium-review.googlesource.com/c/1374332
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#58601}
