By now lazy allocation of block scopes probably doesn't make that much sense anymore, since the memory overhead significantly reduced. Not indirecting scope() over ScopeState is faster, which is more important at this point.
BUG=v8:5209
Change-Id: I2968f01252769e7b1198a0a0876765a06ab0d3bd
Reviewed-on: https://chromium-review.googlesource.com/445025
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43313}
This makes it easier to implement asynchronous compilation by hiding all the implementation details of both synchronous and asynchronous compilation within wasm-module.cc, whereas before the code in wasm-js.cc actually implemented asynchronous compilation in terms of synchronous.
BUG=
Review-Url: https://codereview.chromium.org/2695813005
Cr-Commit-Position: refs/heads/master@{#43310}
Reason for revert:
Due to arm64 failures
Original issue's description:
> [interpreter] Create custom call opcodes for specific argument counts
>
> Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
> and CallProperty2. Also share the bytecode handler code between between
> equivalent CallX and CallPropertyX handlers.
>
> Review-Url: https://codereview.chromium.org/2684993002
> Cr-Commit-Position: refs/heads/master@{#43290}
> Committed: 00d6f1f80aTBR=rmcilroy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2709533002
Cr-Commit-Position: refs/heads/master@{#43308}
The constant field tracking is still disabled.
BUG=v8:5495
Change-Id: I543fe50b82e2255bbf200ea785ec53e3623e30cb
Reviewed-on: https://chromium-review.googlesource.com/440924
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43304}
Reason for revert:
Introduces a new test failure/flake: https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/16427
Original issue's description:
> [wasm] Embedder can control what buffers wasm compilation works on.
>
> Two controls, one for instantiation and one for compilation. They allow
> the embedder (e.g. Chrome) check properties of the parameters of those
> two operations, and decide if they are allowed to continue.
>
> For example, Chrome may now decline compilation of certain size buffers,
> in synchronous cases; same for instantiation (where the buffer size
> refers to the size of the buffer containing wasm wire bytes)
>
> BUG=v8:5981
>
> Review-Url: https://codereview.chromium.org/2699843003
> Cr-Commit-Position: refs/heads/master@{#43295}
> Committed: d9bc0ffb16TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5981
Review-Url: https://codereview.chromium.org/2701413002
Cr-Commit-Position: refs/heads/master@{#43303}
Reason for revert:
Introduces a new test failure/flake: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/13707
Original issue's description:
> [wasm] Identify wasm functions with index into the function tables.
>
> Currently, the default name for wasm functions in generated code is 'wasm', tag wasm functions with the index into the function table to identify functions. Snippets of sample output with --print-code below.
>
> Before:
> --- Code ---
> kind = WASM_FUNCTION
> name = wasm
> compiler = turbofan
>
> After:
> --- Code ---
> kind = WASM_FUNCTION
> name = wasm#200
> compiler = turbofan
>
> R=mtrofin@chromium.org
>
> Review-Url: https://codereview.chromium.org/2690113012
> Cr-Commit-Position: refs/heads/master@{#43296}
> Committed: 5fc3ac29e4TBR=mtrofin@chromium.org,gdeepti@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2708593002
Cr-Commit-Position: refs/heads/master@{#43302}
The bytecode generator did not necessarily know for which scope, and
thus language mode, it was generating code, because it only tracked
scopes that have a context. This led to wrong behavior in some
examples involving class expressions (which are always in strict
mode).
With this CL, the bytecode generator explicitly tracks the current
scope, independent of whether it has a context.
BUG=v8:5927
Change-Id: Ifa6b3ee5e13e07b63d00e74c7f557a328633c88b
Reviewed-on: https://chromium-review.googlesource.com/444785
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43300}
Currently, typeof o, where o is an undetectable
callable object (such as document.all), returns 'function' if
optimised. It should, however, return 'undefined'.
This CL excludes undetectable objects from the optimization
resulting in type 'function' and renames the related code to
reflect that.
BUG=v8:5972
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2697063002
Cr-Commit-Position: refs/heads/master@{#43298}
Currently, the default name for wasm functions in generated code is 'wasm', tag wasm functions with the index into the function table to identify functions. Snippets of sample output with --print-code below.
Before:
--- Code ---
kind = WASM_FUNCTION
name = wasm
compiler = turbofan
After:
--- Code ---
kind = WASM_FUNCTION
name = wasm#200
compiler = turbofan
R=mtrofin@chromium.org
Review-Url: https://codereview.chromium.org/2690113012
Cr-Commit-Position: refs/heads/master@{#43296}
Two controls, one for instantiation and one for compilation. They allow
the embedder (e.g. Chrome) check properties of the parameters of those
two operations, and decide if they are allowed to continue.
For example, Chrome may now decline compilation of certain size buffers,
in synchronous cases; same for instantiation (where the buffer size
refers to the size of the buffer containing wasm wire bytes)
BUG=v8:5981
Review-Url: https://codereview.chromium.org/2699843003
Cr-Commit-Position: refs/heads/master@{#43295}
Adds five new TF builtins for the spec defined functions/closures. This follows
mechanism similar to promise resolving functions approach where we store the
closure variables in a custom context.
Adds a new --harmony-promise-finally flag.
BUG=v8:5967
Review-Url: https://codereview.chromium.org/2695753002
Cr-Commit-Position: refs/heads/master@{#43294}
Failed instance migration should only be reported if the map of the
object was originally marked as deprecated. Otherwise it's pretty
confusing to investigate deoptimizations.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2700143002
Cr-Commit-Position: refs/heads/master@{#43293}
Until recently, it sometimes did.
BUG=
Change-Id: I8785c1865909e6f46693b71c9146d4fa17114fce
Reviewed-on: https://chromium-review.googlesource.com/444188
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43291}
Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
and CallProperty2. Also share the bytecode handler code between between
equivalent CallX and CallPropertyX handlers.
Review-Url: https://codereview.chromium.org/2684993002
Cr-Commit-Position: refs/heads/master@{#43290}
This is the beginning of a new fuzzer that generates
correct-by-construction Wasm modules. This should allow us to better
exercise the compiler and correctness aspects of fuzzing. It is based off
of ahaas' original Wasm fuzzer.
At the moment, it can generate expressions made up of most binops, and
also nested blocks with unconditional breaks. Future CLs will add
additional constructs, such as br_if, loops, memory access, etc.
The way the fuzzer works is that it starts with an array of arbitrary
data provided by libfuzzer. It uses the data to generate an expression.
Care is taken to make use of the entire string. Basically, the
generator has a bunch of grammar-like rules for how to construct an
expression of a given type. For example, an i32 can be made by adding
two other i32s, or by wrapping an i64. The process then continues
recursively until all the data is consumed.
We generate an expression from a slice of data as follows:
* If the slice is less than or equal to the size of the type (e.g. 4
bytes for i32), then it will emit the entire slice as a constant.
* Otherwise, it will consume the first 4 bytes of the slice and use
this to select which rule to apply. Each rule then consumes the
remainder of the slice in an appropriate way. For example:
* Unary ops use the remainder of the slice to generate the argument.
* Binary ops consume another four bytes and mod this with the length
of the remaining slice to split the slice into two parts. Each of
these subslices are then used to generate one of the arguments to
the binop.
* Blocks are basically like a unary op, but a stack of block types is
maintained to facilitate branches. For blocks that end in a break,
the first four bytes of a slice are used to select the break depth
and the stack determines what type of expression to generate.
The goal is that once this generator is complete, it will provide a one
to one mapping between binary strings and valid Wasm modules.
Review-Url: https://codereview.chromium.org/2658723006
Cr-Commit-Position: refs/heads/master@{#43289}
... which is used for initializing properties with non compile time values.
Currently we use StoreOwnIC only for storing properties that already exist
in the boilerplate therefore we can reuse StoreIC dispatcher.
The proper StoreOwnIC dispatcher will be implemented in a separate CL.
BUG=v8:5495, v8:4414
Change-Id: I9c33fdb8499ec5be2c7fce1ecb6ce7aa285e5844
Reviewed-on: https://chromium-review.googlesource.com/443588
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43285}
The functions do not work correctly with concurrent sweeper and they
do not take weak references into account.
The latter is a fundamental problem for this tracing approach.
BUG=
Review-Url: https://codereview.chromium.org/2707433002
Cr-Commit-Position: refs/heads/master@{#43284}
Add `ValueSerializer::SetTreatArrayBufferViewsAsHostObjects()` which
instructs the `ValueSerializer` to treat ArrayBufferView objects as
host objects.
BUG=v8:5926
Review-Url: https://codereview.chromium.org/2696133007
Cr-Commit-Position: refs/heads/master@{#43281}
For results processor to work, we need to maintain the assumption that the cwd is equal to the currently running benchmark directory.
NOTRY=true
TBR=clemensh@chromium.org
Change-Id: I585c301dea846194652645973470786ad43aa280
Reviewed-on: https://chromium-review.googlesource.com/444784
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43280}
Instead of placing a runtime call to StackGuard in the compiled wasm
code, we just call the builtin, which is cheaper. By passing Smi::kZero
as context, we save even more code space and avoid embedding the
context in the code.
The WasmStackGuard builtin then calls the new WasmStackGuard runtime
function, which gets the context from the instance attached to the
calling wasm code, and then does the usual StackGuard logic.
For the unity benchmark in asm-wasm mode, generated code size reduces
from 63.0 to 61.6 MB (-2.1%).
R=titzer@chromium.org, ahaas@chromium.org, mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2691993004
Cr-Commit-Position: refs/heads/master@{#43277}
A fast promotion mode that works solely on GC heuristics without
requiring compiler or other profiler support by implementing zero-copy
evacuation for new space.
- Once a threshold of survived bytes in the Scavenger is reached the
mode is activated.
- In fast promotion mode all pages are moved to old space instead of
performing a Scavenge.
- The inevitable upcoming full MC determines whether the decision
whether the mode should stay on or be turned off based on the young
generation survival rate.
BUG=chromium:693413
Change-Id: Ifdf296092a9bac609f9dcdfb47a24046f3093745
Reviewed-on: https://chromium-review.googlesource.com/442560
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43276}
https://codereview.chromium.org/2694003002/ introduced
"SyntaxError: Lexical declaration cannot appear in a single-statement context"
for the case when let + desctructuring from a list happen.
As was pointed out in https://codereview.chromium.org/2694003002/#msg18, the
case without destructuring would also benefit from a better message: if a
single statement is expected and "let identifier = ..." is seen, the error is
indeed again that the lexical declaration is not a statement. However, the current
error is "Unexpected identifier", because the parser tries to accept "let" as
an identifier in an expression statement, and then gives up seeing the other
identifier after "let".
This CL ensures that the parser recognises the error properly and reports
accordingly. It also renames the existing test, which contains destructuring,
and adds the one with a non-destructuring lexical declaration.
BUG=v8:5686
Review-Url: https://codereview.chromium.org/2697193007
Cr-Commit-Position: refs/heads/master@{#43275}
When trying to infer receiver maps for property accesses, go hunting in
the effect chain to find an earlier CheckMaps or StoreField for the
receiver.
BUG=v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2704563005
Cr-Commit-Position: refs/heads/master@{#43274}
In the JSInliner we shouldn't introduce JSConvertReceiver needlessly if
the input is already known to produce a receiver, i.e. if it's a
JSCreate or something like that.
BUG=v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2697513010
Cr-Commit-Position: refs/heads/master@{#43273}
Before this change, presubmit on upload/commit would miss checking status files when e.g. test files were deleted.
But the status file check in CI will enforce that all referenced test files exist.
NOTRY=true
Change-Id: I6069563a0a4e98406977dbce2ae44b299f7cd4b0
Reviewed-on: https://chromium-review.googlesource.com/443467
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43270}
The CodeStubAssembler::SubString method should not try to be defensive
about non-string inputs, but really enforce String receiver. Passing
a non-String input will result in crash in the %SubString runtime
function anyway.
R=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2700103002
Cr-Commit-Position: refs/heads/master@{#43267}
The new swarming archiving method requires isolate files to be copied to the build dir.
BUG=chromium:598990
NOTRY=true
TBR=tandrii@chromium.org,tansell@chromium.org,vogelheim@chromium.org
Change-Id: I87633725d9ce715684f761ce0c8d2691642c5389
Reviewed-on: https://chromium-review.googlesource.com/444644
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43266}
