This is a followup to moving the ModuleEnv to the compiler directory and
making it immutable.
R=mtrofin@chromium.org, ahaas@chromium.org
Bug:
Change-Id: I0f5ec1b697bdcfad0b4dc2bca577cc0f40de8dc0
Reviewed-on: https://chromium-review.googlesource.com/616762
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47419}
This CL (finally) makes the contract between the compiler and the module
environment clear. In order to compile a function, the caller must provide
an instance of the compiler::ModuleEnv struct, which contains references
to code, function and signature tables, memory start, etc.
R=mtrofin@chromium.org,ahaas@chromium.org
Bug:
Change-Id: I68e44d5da2c5ad44dad402029c2e57f2d5d25b4f
Reviewed-on: https://chromium-review.googlesource.com/613880
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47418}
The MapGuard node sits in the effect chain as a hint for other
optimization passes that a certain value has a certain (set of)
map(s) guarded by checks on the control chain. This is useful
to learn from explicit control flow inserted for polymorphic
property accesses, and then used as part of the polymorphic
inlining.
This change improves the score on the Octane/DeltaBlue benchmark
by around 7-8% and the score on the Octane/Richards benchmark by
like 3% on average.
Bug: v8:5267
Change-Id: Id0b0b2c72e6a9342d5750a0d62cf6be6fb8c5916
Also-By: jarin@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/620586
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47417}
Just to get the RuntimeCallstats data. To be reverted soon.
BUG=v8:5516
NOTREECHECKS=true
Change-Id: I4bb436900a79bb383bf8132002a129b601efdfe3
Reviewed-on: https://chromium-review.googlesource.com/618987
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47416}
The race happens during evacuation when multiple threads access the
main space capacity to check CanExpandOldGeneration.
Bug: chromium:694255
Change-Id: I63dbb71cc3a894f85ee11411a5dc01d53daefa11
Reviewed-on: https://chromium-review.googlesource.com/618876
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47414}
Some preperatory refactoring to allow observation of inline allocations
from Old Space.
BUG=chromium:633920
Change-Id: Ia1232591860729fcd8942d816aa454171d3aec33
Reviewed-on: https://chromium-review.googlesource.com/617923
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#47413}
This also starts black allocation earlier if concurrent marking compile
time flag is on.
Bug: chromium:694255
Change-Id: I73c02676e5149fae10e5f9301ad585926e223a1d
Reviewed-on: https://chromium-review.googlesource.com/618893
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47412}
This patch changes how space size and capacity are updated in GC:
- space capacity changes only when a page added/removed from the space.
- space size is reset to zero before sweeping and incremented by
page->live_bytes_count_ for each to-be-swept page.
- space size is refined after sweeping using the accurate
page->allocated_bytes counter produces by the sweeper.
Invariants:
1. space.capacity = sum [page.size | for page in space].
2. After marking, before sweeping:
a) space.size = sum [page.live_bytes_count | for page in space].
3. After sweeping, before marking ends:
a) space.size = sum [page.allocated_bytes | for page in space].
b) page.allocated_bytes >= (sum [object.size | for object in page] +
page.linear_allocation_area).
c) page.area_size = (page.allocated_bytes + page.wasted_memory +
sum [free_list_entry.size | for free_list_entry in page].
3.b becomes equality if the mutator is not doing array trimming,
object slack tracking during sweeping.
Bug: chromium:694255
Change-Id: Ic8d16a8171187a113fee2df8bf3c2a4c5e77bc08
Reviewed-on: https://chromium-review.googlesource.com/618889
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47409}
There is no need to add speed-bumps for incremental marking purposes
for allocations from CompactionSpaces. This path was getting reached
for Parallel Scavenges.
Bug:
Change-Id: I1f0f315549206bc86f8c48e202c29c18d212369b
Reviewed-on: https://chromium-review.googlesource.com/617920
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#47408}
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}
