The bug was that we didn't track using await as a class name inside
arrow function formal parameters, and hence didn't recognize the error
in this case:
async(x = class await {}) => {}
BUG=v8:6714
Change-Id: Iabe6c947a4f621fb72361671d77f4765ba1a9578
Reviewed-on: https://chromium-review.googlesource.com/616776
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47407}
Before this patch, the parser mixed mixed "Null" and "Empty" as names
for null placeholder instances in ParserBase. Confusingly, those meant
different things in case of Statements.
This patch uses "Null" anywhere the meaning is "== nullptr" in the Parser.
It also makes use of std::nullptr_t and templatized IsNull() methods to
reduce the amount of boilerplate needed in both the Parser and PreParser.
Change-Id: I1451ba56d1a56466beb7e0c91dcf8e2bb7084413
Reviewed-on: https://chromium-review.googlesource.com/618167
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47406}
This improves delta blue by about >5%. Unfortunately, this still does not help load
and check elimination because we do not learn maps from control flow.
Change-Id: I49a97dbc40576b9bc80c87ec2b459e37ba9b4440
Bug: v8:5267
Reviewed-on: https://chromium-review.googlesource.com/618328
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47405}
This patch handles C-style, as well as for-in/of loops. for-await loops
will be changed in a followup.
Bug: v8:6724
Change-Id: I264b8c2d41c0318e796839bf204f7d77b6d24dd8
Reviewed-on: https://chromium-review.googlesource.com/617410
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47404}
Move the desugaring into BytecodeGenerator per TODOs.
BUG=v8:6472
R=tebbi@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org
Change-Id: Ic482bee18d6e6fe73de4c5f9abaf4feda7be2dd5
Reviewed-on: https://chromium-review.googlesource.com/550396
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47403}
Have asm.js instantiate failures tail call the function object again, which
has been reset to the CompileLazy builtin, rather than explicitly calling
the CompileLazy runtime function. This ensures that we call any optimized
code or respect the optimization marker on the feedback vector, and can
introduce DCHECKS in Compiler::Compile to this effect.
Change-Id: I69a1de006c4da8f667a3e8ae8cf69ecf241dae9a
Reviewed-on: https://chromium-review.googlesource.com/618714
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47402}
Make it consistent so that registers in all architecture have a member
function called `bit()`.
Bug:
Change-Id: Ie6323f81d4ecab1557259a43a30100d8da8b35f1
Reviewed-on: https://chromium-review.googlesource.com/618872
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47401}
This is a reland of 21da12a983
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=yangguo@chromium.orgTBR=jarin@chromium.org
Bug: v8:6409
Change-Id: If2eae66a85f129e746a5ca5c04935540f3f86b04
Reviewed-on: https://chromium-review.googlesource.com/618886
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47399}
This CL introduces 6 tests that verify that the effects of a grow_memory
instruction executed inside a function are visible also from the caller of
the function.
The tests verify that:
* the current_memory instruction returns the correct value after
returning from a function that grew memory;
* accessing a memory page that has been created inside a function does
not trap in the caller;
* when a function grows the memory and then store something in the grown
memory, the caller always reads from the grown memory. This checks that
the memory start address gets updated in the caller (the memory buffer
could in fact be relocated by the grow_memory instruction).
These tests are implemented for direct and indirect function calls.
R=ahaas@chromium.org,clemensh@chromium.org
Change-Id: Iac8db0fa7a6dd6f530e090af5423fc165d87e863
Reviewed-on: https://chromium-review.googlesource.com/616150
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47398}
This reverts commit 21da12a983.
Reason for revert: Failing on arm64 simulator
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,leszeks@chromium.org
Change-Id: I4ba63e82417a185f1528ff2633eb6c8872fbbfe5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6409
Reviewed-on: https://chromium-review.googlesource.com/618687
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47397}
The WASM spec maximum memory size is higher than internal V8 maximum object
size. When a memory object grows above this limit (and only in that case), we
should signal an error.
This worked for not-exported memory; however when growing exported memory, the
code was comparing the V8 memory limit with the maximum number of pages defined
in the module, instead of the current number of pages + the number of new
required pages. This lead to signaling errors even when growing exported memory
below the V8 limit if the maximum number of pages specified in the module was
higher than the V8 limit.
GrowMemoryBuffer already checks that we do not grow a memory buffer past the
maximum size specified as parameter, so we can pass it the minimum between the
the V8 limit and the maximum number of pages specified in the module.
This CL introduces a test in test/mjsunit/wasm/import-memory.js that triggers
the problematic path and a patch to fix it.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I5a8da420418b394d61e1ba3cdf4408c3c09e61b6
Reviewed-on: https://chromium-review.googlesource.com/600217
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47395}
Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
function. The code in compiler.cc is refactored to use this function to compile
the SharedFunctionInfo when compiling a JSFunction.
Also does some other cleanup:
- Removes CompileUnoptimizedFunction and inlines into new Compiler function
- Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
out of FinalizeUnoptimizedCompile.
BUG=v8:6409
Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
Reviewed-on: https://chromium-review.googlesource.com/613760
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47394}
This CL solves recent clang compilation error:
"src/wasm/function-body-decoder.cc:1418:18: error: comparison of two
values with different enumeration types in switch statement
('v8::internal::wasm::ControlKind' and 'ControlKind')"
Bug:
Change-Id: I6cb32bb3d42256a80d6f9222f5450ee93ce1021a
Reviewed-on: https://chromium-review.googlesource.com/615247
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47391}
Here the token cannot be Token::INIT since it's coming from the Scanner. Scanner
never returns Token::INIT, and Token::INIT is only used internally in the AST.
Bug:
Change-Id: I185e6d3330651b7ee784b916908e7d8d803b63b9
Reviewed-on: https://chromium-review.googlesource.com/616282
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47390}
In graph building, use liveness information to only create Phis
for live registers when merging two environments, or when preparing
a loop header. Similarly, only create loop exit value nodes for
live registers when exiting a loop.
Bug: v8:6701
Change-Id: Id6ac6a5518e6f1762530d871e92a46f42397928b
Reviewed-on: https://chromium-review.googlesource.com/615173
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47389}
The accumulator should never be alive when jumping back to a loop
header, or jumping out of a loop. This means that as far as far as
TurboFan is concerned, we never need to create Phis or LoopExitValues
for the accumulator, as its value should not escape the loop.
For safety, this also augments the IsLivenessValid DCHECK in the
liveness analysis to check that the accumulator is not live in these
cases, and amends the bytecode analysis tests to kill the accumulator
where necessary to ensure this.
As a drive-by, added some comments to the more complex bytecode analysis
tests, since figuring out what they were for and how to fix them took a
non-trivial amount of time.
Change-Id: Idecf76a36681d724134c59768650c23cc6b0e9ef
Reviewed-on: https://chromium-review.googlesource.com/615168
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47388}
This patch simplifies and reduces code duplication & dead branches
in PatternRewriter, especially relating to handling of destructuring
assignments. It also adds additional DCHECKs to capture invariants.
It should have no change in behavior.
Change-Id: I02bc6c30a1cae8a60c4c5e9033b90953d136212e
Reviewed-on: https://chromium-review.googlesource.com/612511
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47382}
This saves one pointer in Assignment for non-compound
assignment expressions.
Change-Id: I7ec32c1d378917c81ab55c42733b6af450ce65db
Reviewed-on: https://chromium-review.googlesource.com/612673
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47380}
This patch ensures that all code path of the external memory pressure
handler pass the kGCCallbackFlagCollectAllExternalMemory flag to the
embedder. This is necessary to force Oilpan GC.
Bug: chromium:733655
Change-Id: I2e680d1e7f9087d1930d56ead39ef7cf1bc93e56
Reviewed-on: https://chromium-review.googlesource.com/616149
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47378}
This is a very minor cleanup noticed when reading this code. It's simply
a slight reduction in Parser/AST size.
Change-Id: Ice81253d1624723ef124a19442b0dcf4b77f4345
Reviewed-on: https://chromium-review.googlesource.com/614585
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47377}
This removes brittle Scope walking in FinalizeForOfStatement()
by making ParserBase call InitializeForEachStatement() while
in the proper Scope.
Bug: v8:6724
Change-Id: I6e828ccb3a5e4d98633a95a2bfb8d255ad0fc0eb
Reviewed-on: https://chromium-review.googlesource.com/614654
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47376}
This loop doesn't itself have a source position, so I wouldn't think
block coverage of it would make any sense (and all tests continue
to pass).
Removing this argument will make some refactoring I'm working on easier.
Bug: v8:6724
Change-Id: I4d6b734e077d9e61ad9362d07e57f155ec556221
Reviewed-on: https://chromium-review.googlesource.com/615385
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47375}
FPRegister <-> FPRegister moves and swaps were implemented using the FMOV
instruction, whatever the size of the register. However, FMOV only supports
Float and Double moves, it cannot move a whole 128bit register.
Instead, use the vector MOV instruction:
- Simd128 move: mov vd.16b, vn.16b
- Float/Double move: mov vd.8b, vn.8b
Bug:
Change-Id: Ie793078baf3fb816e4047062285bbdaf35483949
Reviewed-on: https://chromium-review.googlesource.com/591308
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#47371}
The code generator uses `ip` as a scratch register directly to assemble a
"Constant -> Float stack slot" move. However, the assembler may also use it to
compute the address.
If we try to assemble such a move and the stack slot is out of range of a store
we get the following:
~~~
movw ip, #52429
movt ip, #15820
movw ip, #59328 ; Use ip to compute the address!
movt ip, #65535
str ip, [fp, +ip]
~~~
Bug:
Change-Id: I97a7b606e3f1d53ed44cc7787e49109cf7a7ab16
Reviewed-on: https://chromium-review.googlesource.com/602230
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#47370}
Now that OSR is done during graph building, we no longer have to
special-case OSR loops in the loop assignment analysis, as we no longer
have the restriction that registers are 'assigned' an OSRValue inside
the loop.
Bug: v8:6518
Change-Id: Ib4fa139091d77efa16246ddc6e63a10cbb877ee4
Reviewed-on: https://chromium-review.googlesource.com/615167
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47367}
Makes ClusterFuzz start fuzzing with the flag on.
BUG=v8:5516
Change-Id: Ia80f7d22f12fe25efb226102a896e8b0e3537947
Reviewed-on: https://chromium-review.googlesource.com/610000
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47366}
Allowing GetModuleNamespace on a not-yet-evaluated module does not make a
lot of sense because accessing the namespace object before evaluation
can lead to surprising behavior.
R=adamk@chromium.org
Bug: v8:1569
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3e3feb344f6399bf92b3dabc97c571a61b38bd41
Reviewed-on: https://chromium-review.googlesource.com/613268
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47365}
This removes:
- CodeBreakIterator for FCG code.
- RelocModes for debug breaks.
- Code generator for debug break slots.
- GC support for debug break slots.
- Code flag to indicate code with debug break slots.
- Builtin type DBG.
- Mechanisms to replace FCG code in the debugger and LiveEdit.
- Runtime entry to the debugger from debug break slots.
R=bmeurer@chromium.org, rmcilroy@chromium.org, ulan@chromium.org
Bug: v8:6409
Change-Id: I5662c8800e3ef1b1584ad107bfe0aae26c9d8abb
Reviewed-on: https://chromium-review.googlesource.com/613263
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47364}
Port 4b397e6c90
Original Commit Message:
The way we access wasm addresses or sizes is the same, on
a platform. We have 2 size parameters - memory and table - and
2 addresses - globals and memory.
The CL also renames for generality the address setting API.
R=mtrofin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ic6c398e0eeb6c9344aca3f92223d8b99a9e518ef
Reviewed-on: https://chromium-review.googlesource.com/615012
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#47360}
Small improvements to code generated on arm and arm64.
Bug: v8:6644
Change-Id: Id3d9be87f6a071e949985a1b6b62a43d9195a104
Reviewed-on: https://chromium-review.googlesource.com/615300
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#47359}
