This is an overly pessimistic approach where PreParser only keeps
track of unresolved variables, but doesn't declare anything. This
will result in context-allocating variables in the outer function
unnecessarily, if the variable names clash with variable names
used by the inner function (even if the variables are not the
same). However, we have been unable to prove that this approach
wouldn't be good enough for the practical purposes.
Fixes after the previous try ( https://codereview.chromium.org/2322243002/ ):
Keep the context-allocation decision stable when compiling fully eagerly.
Tests which exercise this functionality:
mjsunit/fixed-context-shapes-when-recompiling.js
Design document (chromium):
https://docs.google.com/a/chromium.org/document/d/1rRv5JJZ0JpOZAZN2CSUwZPFJiBAdRnTiSYhazseNHFg/edit?usp=sharing
BUG=
Review-Url: https://codereview.chromium.org/2352593002
Cr-Commit-Position: refs/heads/master@{#39719}
Add a general feedback slot for instanceof similar to what we already have
for for-in, which basically has a fast (indicated by the uninitialized
sentinel) and a slow (indicated by the megamorphic sentinel) mode. Now
we can only take the fast path when the feedback slot says it hasn't
seen any funky inputs and nothing funky appeared in the prototype chain.
In the TurboFan code we also deoptimize whenever we see a funky object
(i.e. a proxy or an object that requires access checks) in the prototype
chain (similar to what Crankshaft already did).
Drive-by-fix: Also make Crankshaft respect the mode and therefore
address the deopt loop in Crankshaft around instanceof.
We might want to introduce an InstanceOfIC mechanism at some point and
track the map of the right-hand side.
BUG=v8:5267
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2370693002
Cr-Commit-Position: refs/heads/master@{#39718}
V8 is collecting a growing amount of fuzzers, all of which take substantial
space on the bots and in chromium build archives. This CL improves that
situation by allowing component (shared library) builds for almost all fuzzers.
The parser fuzzer is handled as an exception since it would require exporting a
large number of additional functions.
A component build results in about a 50-100x improvement in file size for each
fuzzer (~50M-100M to around 1.1M).
BUG=chromium:648864
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
Review-Url: https://codereview.chromium.org/2360983002
Cr-Commit-Position: refs/heads/master@{#39709}
If DevTools is turned on in the middle of doing some things with async
functions, then more items may be popped from the Promise stack than were
pushed to it. In this sort of case, it's OK to have a catch misprediction,
but a crash is unacceptable. This patch defensively handles this edge
case where the Promise stack is unexpectedly empty for that reason.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2361333003
Cr-Commit-Position: refs/heads/master@{#39705}
This patch tracks the stack of async functions differently from other
Promise async stack tracking. With this patch, the stack trace of a
callstack of async functions should look similarly to the call stack
if all of the functions were synchronous. An example can be found in
the updated test expectations: https://codereview.chromium.org/2362923002 .
The new stack traces are implemented using existing mechanisms in the
inspector. The inspector has two ways to save async stack traces: recurring
and non-recurring stacks. An example of a non-recurring stack is setTimeout,
and a recurring one is saved for setInterval. Recurring stacks are deleted
only when a special "cancel" function is called, rather than being deleted
after being used the first time. Previous Promise async stack tracking always
used non-recurring stacks.
For async functions, this patch saves a recurring stack. The top frame of
the stack is duplicated, as the resuming function contains a similar frame;
the devtools frontend is responsible for removing or marking this frame,
which it can do based on seeing the [async function] line which follows it.
The second frame will instead be provided by the resuming execution
context. The recurring stack is saved when the async function is entered, and
it is deleted from a finally block. The id of the stack is saved in the outer
Promise being constructed by the async function. When an intermediate
throwaway Promise will be triggered as a reaction, it will be identified as
such based on its debugging metadata, and the corresponding async function's
recurring stack will be used.
BUG=v8:4483
Review-Url: https://codereview.chromium.org/2357423002
Cr-Commit-Position: refs/heads/master@{#39695}
There's no reason (anymore) to have empty imports in special_imports. Remove
them from there and rename special_imports to namespace_imports to be more
precise.
R=adamk@chromium.org
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2368613002
Cr-Commit-Position: refs/heads/master@{#39693}
This matches current Crankshaft/fullcodegen behavior more closely and
thus reduces the chances that we run into unnecessary polymorphism due
to the field representation tracking in our object model.
R=jarin@chromium.org
BUG=v8:5267
Committed: 6a939714e9
Review-Url: https://codereview.chromium.org/2367593003
Cr-Commit-Position: refs/heads/master@{#39692}
Resolve imports and indirect exports at instantiation time.
With this CL we have some basic functionality for modules working. Not yet
supported: star exports, namespace imports, cycle detection, proper variable
initialisation in mutually recursive modules.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2362083002
Cr-Commit-Position: refs/heads/master@{#39689}
DevTools wants to be able to detect async functions in order to print
their synopsis better in stack traces and tooltips. This patch provides a
simple method to do the check.
BUG=v8:4483
Review-Url: https://codereview.chromium.org/2365833002
Cr-Commit-Position: refs/heads/master@{#39687}
Reason for revert:
Main suspect for tsan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/11893
Also changes layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/10036
+mips builder:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/4032
Original issue's description:
> [wasm] Master CL for Binary 0xC changes.
>
> [0xC] Convert to stack machine semantics.
> [0xC] Use section codes instead of names.
> [0xC] Add elements section decoding.
> [0xC] Decoding of globals section.
> [0xC] Decoding of memory section.
> [0xC] Decoding of imports section.
> [0xC] Decoding of exports section.
> [0xC] Decoding of data section.
> [0xC] Remove CallImport bytecode.
> [0xC] Function bodies have an implicit block.
> [0xC] Remove the bottom label from loops.
> [0xC] Add signatures to blocks.
> [0xC] Remove arities from branches.
> Add tests for init expression decoding.
> Rework compilation of import wrappers and how they are patched.
> Rework function indices in debugging.
> Fix ASM->WASM builder for stack machine.
> Reorganize asm.js foreign functions due to import indices change.
>
> R=ahaas@chromium.org,rossberg@chromium.org,bradnelson@chromium.org
> BUG=chromium:575167
> LOG=Y
>
> Committed: https://crrev.com/76eb976a67273b8c03c744f64ad850b0432554b9
> Cr-Commit-Position: refs/heads/master@{#39678}
TBR=ahaas@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,rossberg@chromium.org,bradnelson@google.com,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:575167
Review-Url: https://codereview.chromium.org/2361053004
Cr-Commit-Position: refs/heads/master@{#39685}
[0xC] Convert to stack machine semantics.
[0xC] Use section codes instead of names.
[0xC] Add elements section decoding.
[0xC] Decoding of globals section.
[0xC] Decoding of memory section.
[0xC] Decoding of imports section.
[0xC] Decoding of exports section.
[0xC] Decoding of data section.
[0xC] Remove CallImport bytecode.
[0xC] Function bodies have an implicit block.
[0xC] Remove the bottom label from loops.
[0xC] Add signatures to blocks.
[0xC] Remove arities from branches.
Add tests for init expression decoding.
Rework compilation of import wrappers and how they are patched.
Rework function indices in debugging.
Fix ASM->WASM builder for stack machine.
Reorganize asm.js foreign functions due to import indices change.
R=ahaas@chromium.org,rossberg@chromium.org,bradnelson@chromium.org
BUG=chromium:575167
LOG=Y
Review-Url: https://codereview.chromium.org/2345593003
Cr-Commit-Position: refs/heads/master@{#39678}
CpuFeatures::IsSupported(feature) indicates that the feature is
available on the target. AssemblerBase::IsEnabled(feature) indicates
that we've checked for support (using CpuFeatureScope). The main benefit
is that we can test on (for example) ARMv8, but have some assurance that
we won't generate ARMv8 instructions on ARMv7 targets.
This patch simply cleans up the usage, which had become inconsistent.
The instruction emission functions now check not only that their
dependent features are supported, but also that we've verified that
using CpuFeatureScope.
BUG=
Review-Url: https://codereview.chromium.org/2360243002
Cr-Commit-Position: refs/heads/master@{#39676}
It looks like it tried to trigger lazy inner function parsing by
inserting a comment into an inner function.
1) We don't have lazy inner functions yet.
2) Even if we had, there's no way this heuristic could trigger laziness:
we need to do the laziness decision upfront, without looking at the
contents / size of the function.
3) Some of the combinations were weird: lazy_outer but non-lazy inner?
In the current heuristics, only the total script size affects laziness;
in particular, it doesn't matter where the long comment is.
R=mstarzinger@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2364003002
Cr-Commit-Position: refs/heads/master@{#39673}
This makes sure the {EscapeAnalysisReducer} inserts proper {TypeGuard}
nodes if the replacement node is not a subtype of the original node.
This happens predominantly for code that has been made unreachable by
type checks.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-640497
BUG=chromium:640497
Review URL: https://codereview.chromium.org/2363573003 .
Cr-Commit-Position: refs/heads/master@{#39656}
This matches current Crankshaft/fullcodegen behavior more closely and
thus reduces the chances that we run into unnecessary polymorphism due
to the field representation tracking in our object model.
R=jarin@chromium.org
BUG=v8:5267
Review URL: https://codereview.chromium.org/2367593003 .
Cr-Commit-Position: refs/heads/master@{#39655}
Rename the high-level operators CheckTaggedSigned to CheckSmi and
CheckTaggedPointer to CheckHeapObject, to better match the naming
convention (i.e. ObjectIsSmi and CheckSmi, ObjectIsString and
CheckString, etc.).
For lowering CheckSmi, always report TaggedSigned representation
and let the RepresentationChanger come up with a reasonable conversion
from whatever input representation to TaggedSigned. This way we no
longer insert the useless ChangeSomethingToTagged and then Smi check
the result sequences, i.e. mostly reduces the amount of useless code
being generated. But we also observe a few performance improvements
on some crypto benchmarks.
This would enable us to avoid the Smi canonicalization when going from
Float64 to Tagged completely and thus match the representation selection
of Crankshaft in many areas (which might reduce the amount of
polymorphism until we fix our object model).
A follow-up CL will do the same for CheckHeapObject.
BUG=v8:5267
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/2362173003 .
Cr-Commit-Position: refs/heads/master@{#39654}
This CL optimizes the code in BytecodeArrayBuilder and
BytecodeArrayWriter by making the following main changes:
- Move operand scale calculation out of BytecodeArrayWriter to the
BytecodeNode constructor, where the decision on which operands are
scalable can generally be statically decided by the compiler.
- Move the maximum register calculation out of BytecodeArrayWriter
and into BytecodeRegisterOptimizer (which is the only place outside
BytecodeGenerator which updates which registers are used). This
avoids the BytecodeArrayWriter needing to know the operand types
of a node as it writes it.
- Modify EmitBytecodes to use individual push_backs rather than
building a buffer and calling insert, since this turns out to be faster.
- Initialize BytecodeArrayWriter's bytecode vector by reserving 512
bytes,
- Make common functions in Bytecodes constexpr so that they
can be statically calculated by the compiler.
- Move common functions and constructors in Bytecodes and
BytecodeNode to the header so that they can be inlined.
- Change large static switch statements in Bytecodes to const array
lookups, and move to the header to allow inlining.
I also took the opportunity to remove a number of unused helper
functions, and rework some others for consistency.
This reduces the percentage of time spent in making BytecodeArrays
in CodeLoad from ~15% to ~11% according to perf. The
CoadLoad score increase by around 2%.
BUG=v8:4280
Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64
Review-Url: https://codereview.chromium.org/2351763002
Cr-Original-Commit-Position: refs/heads/master@{#39599}
Cr-Commit-Position: refs/heads/master@{#39637}
WasmModule::Instantiate can return an empty handle if it is not possible
to instantiate the module. With this change the wasm-module-runner does
not assume anymore that WasmModule::Instantiate produces a valid handle.
BUG=chromium:648078
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2365493003
Cr-Commit-Position: refs/heads/master@{#39629}
Generate TBZ/TBNZ for certain comparisons against zero. E.g. instead of:
cmp w0, 0x0
b.lt/ge <addr>
we can generate:
tbnz/tbz w0, 31, <addr>
BUG=
Review-Url: https://codereview.chromium.org/2359723004
Cr-Commit-Position: refs/heads/master@{#39620}
Port for VisitFloat32Add, VisitFloat64Add, VisitFloat32Sub and
VisitFloat64Sub in InstructionSelector.
TEST=unittests/InstructionSelectorTest.Float32AddWithFloat32Mul,
unittests/InstructionSelectorTest.Float64AddWithFloat64Mul,
unittests/InstructionSelectorTest.Float32SubWithFloat32Mul,
unittests/InstructionSelectorTest.Float64SubWithFloat64Mul
BUG=
Review-Url: https://codereview.chromium.org/2341303002
Cr-Commit-Position: refs/heads/master@{#39616}
This makes sure cycles in the object states graph are detected early by
escape analysis instead of late in the scheduler. This is mainly done
for improved debuggability.
R=bmeurer@chromium.org
BUG=chromium:613923
Review-Url: https://codereview.chromium.org/2354263002
Cr-Commit-Position: refs/heads/master@{#39614}
Reason for revert:
Prime suspect for roll blocker: https://codereview.chromium.org/2362503002/
Original issue's description:
> [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter.
>
> This CL optimizes the code in BytecodeArrayBuilder and
> BytecodeArrayWriter by making the following main changes:
>
> - Move operand scale calculation out of BytecodeArrayWriter to the
> BytecodeNode constructor, where the decision on which operands are
> scalable can generally be statically decided by the compiler.
> - Move the maximum register calculation out of BytecodeArrayWriter
> and into BytecodeRegisterOptimizer (which is the only place outside
> BytecodeGenerator which updates which registers are used). This
> avoids the BytecodeArrayWriter needing to know the operand types
> of a node as it writes it.
> - Modify EmitBytecodes to use individual push_backs rather than
> building a buffer and calling insert, since this turns out to be faster.
> - Initialize BytecodeArrayWriter's bytecode vector by reserving 512
> bytes,
> - Make common functions in Bytecodes constexpr so that they
> can be statically calculated by the compiler.
> - Move common functions and constructors in Bytecodes and
> BytecodeNode to the header so that they can be inlined.
> - Change large static switch statements in Bytecodes to const array
> lookups, and move to the header to allow inlining.
>
> I also took the opportunity to remove a number of unused helper
> functions, and rework some others for consistency.
>
> This reduces the percentage of time spent in making BytecodeArrays
> in CodeLoad from ~15% to ~11% according to perf. The
> CoadLoad score increase by around 2%.
>
> BUG=v8:4280
>
> Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64
> Cr-Commit-Position: refs/heads/master@{#39599}
TBR=mythria@chromium.org,leszeks@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2360193003
Cr-Commit-Position: refs/heads/master@{#39612}
This CL optimizes the code in BytecodeArrayBuilder and
BytecodeArrayWriter by making the following main changes:
- Move operand scale calculation out of BytecodeArrayWriter to the
BytecodeNode constructor, where the decision on which operands are
scalable can generally be statically decided by the compiler.
- Move the maximum register calculation out of BytecodeArrayWriter
and into BytecodeRegisterOptimizer (which is the only place outside
BytecodeGenerator which updates which registers are used). This
avoids the BytecodeArrayWriter needing to know the operand types
of a node as it writes it.
- Modify EmitBytecodes to use individual push_backs rather than
building a buffer and calling insert, since this turns out to be faster.
- Initialize BytecodeArrayWriter's bytecode vector by reserving 512
bytes,
- Make common functions in Bytecodes constexpr so that they
can be statically calculated by the compiler.
- Move common functions and constructors in Bytecodes and
BytecodeNode to the header so that they can be inlined.
- Change large static switch statements in Bytecodes to const array
lookups, and move to the header to allow inlining.
I also took the opportunity to remove a number of unused helper
functions, and rework some others for consistency.
This reduces the percentage of time spent in making BytecodeArrays
in CodeLoad from ~15% to ~11% according to perf. The
CoadLoad score increase by around 2%.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2351763002
Cr-Commit-Position: refs/heads/master@{#39599}
This add support for ConsString objects allocated inline to the escape
analysis pass. The raw hash field in such strings needs special handling
similar to existing raw fields. This also contains materialization code
within the deoptimizer as usual.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-648737
BUG=chromium:648737
Review-Url: https://codereview.chromium.org/2357153002
Cr-Commit-Position: refs/heads/master@{#39594}
This also adds sources missing for PPC and x87, fixes a few
missing files in gyp due to wrong quotation and a few that
were simply not included.
The gn files are now authoritative, but the gcmole gyp and
gn source lists are enforced to match exactly.
This additional enforcement helped finding the bugs above
and will be removed when we deprecate the gyp files.
BUG=614645
NOTRY=true
Review-Url: https://codereview.chromium.org/2352103002
Cr-Commit-Position: refs/heads/master@{#39592}
This removes an optimization from the code generator that tries to
materialize certain constants (i.e. context and closure) from the
stackframe when possible. This does not work with Harmony tail calls
which are split into several instructions. There have already been
numerous bugs in this optimization, it is too fragile in its current
form.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-648539
BUG=chromium:648539
Review-Url: https://codereview.chromium.org/2357583003
Cr-Commit-Position: refs/heads/master@{#39583}
After parsing a function, if there's no masking declaration in the function scope, DeclareFunctionVar will also bind the function name to a variable. It will either bind it to the const/const-legacy function_ variable, or to a dynamic non-local if the function calls sloppy eval.
Even if the variable is masked or sloppy eval is called, we still declare the function-var. The client immediately sets up the variable by assigning the resulting function to it.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2274133002
Cr-Commit-Position: refs/heads/master@{#39581}
- Add a new container object to store the data required for
PromiseResolveThenableJob.
- Create a new runtime function to enqueue the microtask event with
the required data.
This patches causes a 4% regression in the bluebird benchmark.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2314903004
Cr-Commit-Position: refs/heads/master@{#39571}
This patch gives the ability for the embedder to ask for the
module requests of a module, and to pass a ResolveCallback
into Module::Instantiate().
In d8, I've implemented a simple module_map that's used
along with this API to allow loading, compiling, instantiating,
and evaluating a whole tree of modules.
No path resolution is yet implemented, meaning that all
import paths are relative to whatever directory d8 runs
in. And no imports are linked to the exports of the
requested module.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2351113004
Cr-Commit-Position: refs/heads/master@{#39569}
This patch ensures that variables like .new_target aren't overwritable
using with scopes. It does this by ensuring that scope analysis does
not consider with scopes (or eval scopes) for such 'synthetic variables',
similarly to how the 'this' variable was already handled.
The patch also adds a DCHECK for the dynamic parallel to this case,
replacing a previous unreachable path for a particular instance.
BUG=v8:5405
Review-Url: https://codereview.chromium.org/2353623002
Cr-Commit-Position: refs/heads/master@{#39567}
This patch uses temporaries rather than unresolved variables for
.promise and .debug_is_active. For .promise, a new field is added
to the FunctionState, similarly to .generator_object. This change
fixes a bug where .promise was locally shadowable by with, affecting
program semantics.
BUG=v8:5405
Review-Url: https://codereview.chromium.org/2359513002
Cr-Commit-Position: refs/heads/master@{#39566}
To improve performance, this patch makes Promise.all and Promise.race not
perform correct catch prediction when the debugger is not open. The case
may come up if Promise.race or Promise.all is called, then DevTools is
open, then a component Promise is rejected. In this case, the user would
falsely get an exception event even if the "pause on caught exceptions"
box is unchecked. There are tests which triggered this case; however, it
seems both unlikely and and acceptable to have an event in this case.
Many analogous events are already produced when DevTools is enabled
during the operation of a program.
BUG=v8:3093
Review-Url: https://codereview.chromium.org/2350363002
Cr-Commit-Position: refs/heads/master@{#39565}
This patch knits together Promises returned by async/await such that when
one async function awaits the result of another one, catch prediction works
across the boundaries, whether the exception comes synchronously or
asynchronously. Edges are added in three places:
- When a locally uncaught await happens, if the value passed into await
is a Promise, from the awaited value to the Promise under construction
in the broader async function
- From a "throwaway" Promise, which may be found on the Promise debug
stack, to the Promise under construction in the async function that
surrounds it
- When a Promise is resolved with another Promise (e.g., when returning a
Promise from an async function)
In this reland, the caught tests are broken up into four parts to avoid
timeouts.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2346363004
Cr-Commit-Position: refs/heads/master@{#39564}
The CreateArrayLiteral bytecode handler now directly inlines the FastCloneShallowArrayStub.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2341743003
Cr-Commit-Position: refs/heads/master@{#39562}
This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.
BUG=v8:5409
Review-Url: https://codereview.chromium.org/2344143003
Cr-Commit-Position: refs/heads/master@{#39558}
Full code uses patching ICs for this feedback, and the interpreter uses
the type feedback vector. It's a good idea to code the vector slots
appropriately as ICs so that the runtime profiler can better gauge if
the function is ready for tiering up from Ignition to TurboFan.
As is, the feedback is stored in "general" slots which can't be
characterized by the runtime profiler into feedback states.
This CL addresses that problem. Note that it's also important to
carefully exclude these slots from the profiler's consideration when
determining if you want to optimize from Full code.
BUG=
Review-Url: https://codereview.chromium.org/2342853002
Cr-Commit-Position: refs/heads/master@{#39555}
- Eliminates *all* copies in the process.
- Moves (nearly) all functionality into Scanner::BookmarkScope.
- Significant code reduction.
[Needs to be rebased once crrev.com/2347883002 lands. All changes in *parser* are from that CL.]
R=marja@chromium.org
BUG=v8:4947
Review-Url: https://codereview.chromium.org/2341323002
Cr-Commit-Position: refs/heads/master@{#39554}
The implicit assignment to the induction variable in a ForInStatement
has been ignored by the AST loop assignment analysis. This was hidden
for cases where the parser introduced a ".for" temporary, but triggers
when the variable is declared outside the loop.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647887
BUG=chromium:647887
Review-Url: https://codereview.chromium.org/2356733002
Cr-Commit-Position: refs/heads/master@{#39551}
This means we can no longer take the closure's context to parse, but
need to rely on the outer scope info.
Since it's not possible to get that, however, for lazy functions, we
introduce a new field to SharedFunctionInfo that stores the outer scope
info whenever available.
BUG=v8:5215
R=marja@chromium.org,verwaest@chromium.org,jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2358503002
Cr-Commit-Position: refs/heads/master@{#39548}
Extract String feedback on Add operation and utilize to lower ConsString
creation in JSTypedLowering when we know that a String addition will
definitely result in the creation of a ConsString.
Note that Crankshaft has to guard the potential length overflow of the
resulting string with an eager deoptimization exit, while we can safely
throw an exception in that case.
Also note that the bytecode pipeline does not currently provide the
String feedback for the addition, which has to be added.
BUG=v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2354853002
Cr-Commit-Position: refs/heads/master@{#39540}
Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup
variables that can be globally loaded, without calling the runtime, as long as
there was no context extension by a sloppy eval along their context chain.
BUG=v8:5263
Review-Url: https://codereview.chromium.org/2347143002
Cr-Commit-Position: refs/heads/master@{#39537}
This would've caught the "preparser tracking only unresolved variables
but no declarations is not enough" bug.
BUG=
Review-Url: https://codereview.chromium.org/2350683002
Cr-Commit-Position: refs/heads/master@{#39532}
Avoid internalizing on-the-fly now that scope analysis and natives syntax
runtime calls no longer require internalized AST values. This should be
more efficient by avoiding extra branches on every AST value creation.
BUG=v8:5215, chromium:634953
Review-Url: https://codereview.chromium.org/2328593002
Cr-Commit-Position: refs/heads/master@{#39531}
Crankshaft just unconditionally deoptimizes the code when the length of
a string addition result would overflow. In order to protect against
deopt loops we insert a global protector cell.
We will use the same mechanism for inlining certain string additions
into TurboFan as well, and protecting against overflow (we will also
extend this to deal with String.prototype.concat and friends once we
get there).
BUG=v8:5404
R=jarin@chromium.org,hpayer@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux64_msan_rel
Committed: https://crrev.com/cb19257a926a55209a6d6858ce26d51a0447ba71
Review-Url: https://codereview.chromium.org/2348293002
Cr-Original-Commit-Position: refs/heads/master@{#39511}
Cr-Commit-Position: refs/heads/master@{#39525}
Reason for revert:
Need to break up test into smaller tests to avoid timeouts
Original issue's description:
> Async/await Promise dependency graph
>
> This patch knits together Promises returned by async/await such that when
> one async function awaits the result of another one, catch prediction works
> across the boundaries, whether the exception comes synchronously or
> asynchronously. Edges are added in three places:
> - When a locally uncaught await happens, if the value passed into await
> is a Promise, from the awaited value to the Promise under construction
> in the broader async function
> - From a "throwaway" Promise, which may be found on the Promise debug
> stack, to the Promise under construction in the async function that
> surrounds it
> - When a Promise is resolved with another Promise (e.g., when returning a
> Promise from an async function)
>
> BUG=v8:5167
>
> Committed: https://crrev.com/7265fdde7c76b9f875b40b0b139515936d491d64
> Cr-Commit-Position: refs/heads/master@{#39522}
TBR=adamk@chromium.org,jgruber@chromium.org,kozyatinskiy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2351953002
Cr-Commit-Position: refs/heads/master@{#39523}
This patch knits together Promises returned by async/await such that when
one async function awaits the result of another one, catch prediction works
across the boundaries, whether the exception comes synchronously or
asynchronously. Edges are added in three places:
- When a locally uncaught await happens, if the value passed into await
is a Promise, from the awaited value to the Promise under construction
in the broader async function
- From a "throwaway" Promise, which may be found on the Promise debug
stack, to the Promise under construction in the async function that
surrounds it
- When a Promise is resolved with another Promise (e.g., when returning a
Promise from an async function)
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2317383002
Cr-Commit-Position: refs/heads/master@{#39522}
This patch closes a memory leak in async/await where the desugaring
was creating a situation analagous to that described in v8:5002.
Intermediate Promises were being kept alive, so a long-running loop
would cause linear memory usage on the heap. This patch returns
undefined to the 'then' callback passed into PerformPromiseThen
in order to avoid this hazard. Test expectations are fixed to remove
expecting extraneous events which occurred on Promises that are
now not given unnecessarily complex resolution paths before being
thrown away.
This patch is a reland; originally, tests which exercised the memory
exhaustion were checked in. Although it's possible to find good parameters
for running such tests locally, it is difficult to automate the tests
between the rock of timeouts and the hard place of too-small heaps
causing memory exhaustion in some modes even when there is no leak.
BUG=v8:5390
Review-Url: https://codereview.chromium.org/2352933002
Cr-Commit-Position: refs/heads/master@{#39520}
We must keep track of the exact order in which modules are requested.
To do so, maintain a map from module specifiers to position while
parsing (in ModuleDescriptor). Descriptor entries now refer to that
position rather than the string. When generating the ModuleInfo, turn
this map into an array of specifiers. We don't need the map anymore
later on, so we do not reconstruct it when deserializing again.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2353633002
Cr-Commit-Position: refs/heads/master@{#39519}
Reason for revert:
Mean https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/10910
Original issue's description:
> [crankshaft] Protect against deopt loops from string length overflows.
>
> Crankshaft just unconditionally deoptimizes the code when the length of
> a string addition result would overflow. In order to protect against
> deopt loops we insert a global protector cell.
>
> We will use the same mechanism for inlining certain string additions
> into TurboFan as well, and protecting against overflow (we will also
> extend this to deal with String.prototype.concat and friends once we
> get there).
>
> BUG=v8:5404
> R=jarin@chromium.org,hpayer@chromium.org
>
> Committed: https://crrev.com/cb19257a926a55209a6d6858ce26d51a0447ba71
> Cr-Commit-Position: refs/heads/master@{#39511}
TBR=hpayer@chromium.org,jarin@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5404
Review-Url: https://codereview.chromium.org/2357433002
Cr-Commit-Position: refs/heads/master@{#39518}
Handle the case of asm.js modules that return a single function
instead of a collection of them.
R=mtrofin@chromium.org
TEST=mjsunit/asm/asm-wasm
BUG=v8:4203
BUG=v8:5356
Review-Url: https://codereview.chromium.org/2348383003
Cr-Commit-Position: refs/heads/master@{#39515}
Reason for revert:
Still causes issues on bot (sometimes!)
Original issue's description:
> Reland of Fix async/await memory leak (patchset #1 id:1 of https://codereview.chromium.org/2354473002/ )
>
> Reason for revert:
> Relanding with faster-running test
>
> Original issue's description:
> > Revert of Fix async/await memory leak (patchset #5 id:80001 of https://codereview.chromium.org/2334323006/ )
> >
> > Reason for revert:
> > newly introduced test async-await-loop times out: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/10894/steps/Ignition%20-%20turbofan%20%28flakes%29/logs/async-await-loop
> >
> > Original issue's description:
> > > Fix async/await memory leak
> > >
> > > This patch closes a memory leak in async/await where the desugaring
> > > was creating a situation analagous to that described in v8:5002.
> > > Intermediate Promises were being kept alive, so a long-running loop
> > > would cause linear memory usage on the heap. This patch returns
> > > undefined to the 'then' callback passed into PerformPromiseThen
> > > in order to avoid this hazard. Test expectations are fixed to remove
> > > expecting extraneous events which occurred on Promises that are
> > > now not given unnecessarily complex resolution paths before being
> > > thrown away.
> > >
> > > BUG=v8:5390
> > >
> > > Committed: https://crrev.com/a0ba18e9634c5e2d439033ab61a77cff54f9af35
> > > Cr-Commit-Position: refs/heads/master@{#39479}
> >
> > TBR=adamk@chromium.org,caitp@igalia.com,littledan@chromium.org
> > NOTRY=true
> > BUG=v8:5390
> >
> > Committed: https://crrev.com/196db1999da130019bbf8e3bd65977f840e8afaf
> > Cr-Commit-Position: refs/heads/master@{#39493}
>
> TBR=adamk@chromium.org,caitp@igalia.com,hablich@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> BUG=v8:5390
>
> Committed: https://crrev.com/e51482f01f26e0013e6377e85c4d2c41900e403c
> Cr-Commit-Position: refs/heads/master@{#39508}
TBR=adamk@chromium.org,caitp@igalia.com,hablich@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5390
Review-Url: https://codereview.chromium.org/2348403003
Cr-Commit-Position: refs/heads/master@{#39512}
Crankshaft just unconditionally deoptimizes the code when the length of
a string addition result would overflow. In order to protect against
deopt loops we insert a global protector cell.
We will use the same mechanism for inlining certain string additions
into TurboFan as well, and protecting against overflow (we will also
extend this to deal with String.prototype.concat and friends once we
get there).
BUG=v8:5404
R=jarin@chromium.org,hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2348293002
Cr-Commit-Position: refs/heads/master@{#39511}
Reason for revert:
Relanding with faster-running test
Original issue's description:
> Revert of Fix async/await memory leak (patchset #5 id:80001 of https://codereview.chromium.org/2334323006/ )
>
> Reason for revert:
> newly introduced test async-await-loop times out: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/10894/steps/Ignition%20-%20turbofan%20%28flakes%29/logs/async-await-loop
>
> Original issue's description:
> > Fix async/await memory leak
> >
> > This patch closes a memory leak in async/await where the desugaring
> > was creating a situation analagous to that described in v8:5002.
> > Intermediate Promises were being kept alive, so a long-running loop
> > would cause linear memory usage on the heap. This patch returns
> > undefined to the 'then' callback passed into PerformPromiseThen
> > in order to avoid this hazard. Test expectations are fixed to remove
> > expecting extraneous events which occurred on Promises that are
> > now not given unnecessarily complex resolution paths before being
> > thrown away.
> >
> > BUG=v8:5390
> >
> > Committed: https://crrev.com/a0ba18e9634c5e2d439033ab61a77cff54f9af35
> > Cr-Commit-Position: refs/heads/master@{#39479}
>
> TBR=adamk@chromium.org,caitp@igalia.com,littledan@chromium.org
> NOTRY=true
> BUG=v8:5390
>
> Committed: https://crrev.com/196db1999da130019bbf8e3bd65977f840e8afaf
> Cr-Commit-Position: refs/heads/master@{#39493}
TBR=adamk@chromium.org,caitp@igalia.com,hablich@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
BUG=v8:5390
Review-Url: https://codereview.chromium.org/2348403002
Cr-Commit-Position: refs/heads/master@{#39508}
This is in preparation for upcmoming scanner + bookmarking cleanups.
Also, drive-by fix for setting a bookmark close to the end of the stream,
when the look-ahead character (c0_) is kEndOfInput, which the bookmarking
logic also used as kNoBookmark.
R=marja@chomium.org
BUG=v8:4947
Review-Url: https://codereview.chromium.org/2345053003
Cr-Commit-Position: refs/heads/master@{#39507}
According to the ES6 specification, in "for in/of" loops like:
for (var v of [1,2,3]) return f(...);
the call to f() should not be considered a tail call. This was
not working properly, i.e., the case without declarations:
var v;
for (v of [1,2,3]) return f(...);
R=adamk@chromium.org, ishell@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2343823002
Cr-Commit-Position: refs/heads/master@{#39497}
Reason for revert:
newly introduced test async-await-loop times out: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/10894/steps/Ignition%20-%20turbofan%20%28flakes%29/logs/async-await-loop
Original issue's description:
> Fix async/await memory leak
>
> This patch closes a memory leak in async/await where the desugaring
> was creating a situation analagous to that described in v8:5002.
> Intermediate Promises were being kept alive, so a long-running loop
> would cause linear memory usage on the heap. This patch returns
> undefined to the 'then' callback passed into PerformPromiseThen
> in order to avoid this hazard. Test expectations are fixed to remove
> expecting extraneous events which occurred on Promises that are
> now not given unnecessarily complex resolution paths before being
> thrown away.
>
> BUG=v8:5390
>
> Committed: https://crrev.com/a0ba18e9634c5e2d439033ab61a77cff54f9af35
> Cr-Commit-Position: refs/heads/master@{#39479}
TBR=adamk@chromium.org,caitp@igalia.com,littledan@chromium.org
NOTRY=true
BUG=v8:5390
Review-Url: https://codereview.chromium.org/2354473002
Cr-Commit-Position: refs/heads/master@{#39493}
test-run-wasm-module cctests broken in debug since recent refactoring changes for moving Compilation/Instantiation off the module object (https://codereview.chromium.org/2320723005). The problem here is that SetupIsolateForWasm tries to add the same property to a module_object multiple times and hits a DCHECK when this property is found on a lookup.
- Fixed to use the setup method only once when CcTest::InitIsolateOnce is used.
- Move setup method to test as this is only used for cctests/fuzzers. The install method should take care of this in the regular JS pipeline.
R=mtrofin@chromium.org, ahaas@chromium.org
Review-Url: https://codereview.chromium.org/2342263002
Cr-Commit-Position: refs/heads/master@{#39484}
We'd like wasm regressions to live under a subfolder of the mjsunit
regression folder.
BUG=
Review-Url: https://codereview.chromium.org/2344373002
Cr-Commit-Position: refs/heads/master@{#39483}
Normally the parser just uses AstConsStrings to concatenate, but some
types require an AstRawString. This patch adds an AstValueFactory
method which produces one from two AstRawStrings.
Review-Url: https://codereview.chromium.org/2348783002
Cr-Commit-Position: refs/heads/master@{#39482}
This patch closes a memory leak in async/await where the desugaring
was creating a situation analagous to that described in v8:5002.
Intermediate Promises were being kept alive, so a long-running loop
would cause linear memory usage on the heap. This patch returns
undefined to the 'then' callback passed into PerformPromiseThen
in order to avoid this hazard. Test expectations are fixed to remove
expecting extraneous events which occurred on Promises that are
now not given unnecessarily complex resolution paths before being
thrown away.
BUG=v8:5390
Review-Url: https://codereview.chromium.org/2334323006
Cr-Commit-Position: refs/heads/master@{#39479}
For denominators that are powers of two, replace Float64 division with
multiplication by the reciprocal.
Additionally, replace division by -1 with negation, and multiplication by two
with addition.
BUG=
Review-Url: https://codereview.chromium.org/2347573002
Cr-Commit-Position: refs/heads/master@{#39478}
crrev.com/2339933002 and crrev.com/2314663002 were overlapping, so
this slipped through the cracks.
R=jochen@chromium.org
BUG=v8:4947, chromium:646794
Review-Url: https://codereview.chromium.org/2343093002
Cr-Commit-Position: refs/heads/master@{#39474}
Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup
variables that can be context loaded, without calling the runtime, as
long as there was no context extension by a sloppy eval along their
context chain.
BUG=v8:5263
Review-Url: https://codereview.chromium.org/2343633002
Cr-Commit-Position: refs/heads/master@{#39473}
In ignition, arguments to function calls and function constructors are
pushed onto the stack before calling the function. It is required to check
that stack does not overflow when pushing the arguments.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/2335513004
Cr-Commit-Position: refs/heads/master@{#39470}
- Smaller, more consistent streams API (Advance, Back, pos, Seek)
- Remove implementations from the header, in favor of creation functions.
Observe:
- Performance:
- All Utf16CharacterStream methods have an inlinable V8_LIKELY w/ a
body of only a few instructions. I expect most calls to end up there.
- There used to be performance problems w/ bookmarking, particularly
with copying too much data on SetBookmark w/ UTF-8 streaming streams.
All those copies are gone.
- The old streaming streams implementation used to copy data even for
2-byte input. It no longer does.
- The only remaining 'slow' method is the Seek(.) slow case for utf-8
streaming streams. I don't expect this to be called a lot; and even if,
I expect it to be offset by the gains in the (vastly more frequent)
calls to the other methods or the 'fast path'.
- If it still bothers us, there are several ways to speed it up.
- API & code cleanliness:
- I want to remove the 'old' API in a follow-up CL, which should mostly
delete code, or replace it 1:1.
- In a 2nd follow-up I want to delete much of the UTF-8 handling in Blink
for streaming streams.
- The "bookmark" is now always implemented (and mostly very fast), so we
should be able to use it for more things.
- Testing & correctness:
- The unit tests now cover all stream implementations,
and are pretty good and triggering all the edge cases.
- Vastly more DCHECKs of the invariants.
BUG=v8:4947
Review-Url: https://codereview.chromium.org/2314663002
Cr-Commit-Position: refs/heads/master@{#39464}
Ensure we can serialize a wasm compiled module even after it was
instantiated a few times.
BUG=
Review-Url: https://codereview.chromium.org/2339933003
Cr-Commit-Position: refs/heads/master@{#39463}
This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields
See design doc:
https://docs.google.com/document/d/1WRtNm3ZLNJT1WVr8aq4RJuByYgfuAFAhj20LwTW6JVE/
This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.
Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.
BUG=v8:5367
Review-Url: https://codereview.chromium.org/2315733003
Cr-Commit-Position: refs/heads/master@{#39459}
We don't need the context anymore for parsing, the scope info chain is
enough.
BUG=v8:5215
R=marja@chromium.org,jgruber@chromium.org,mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2342443004
Cr-Commit-Position: refs/heads/master@{#39457}
Reason for revert:
With fixes for frozen RegExps in https://codereview.chromium.org/2339443002 , it should be web-compatible to put RegExps in strict mode again, per spec.
Original issue's description:
> Revert of Put RegExp js code in strict mode (patchset #2 id:20001 of https://codereview.chromium.org/1776883005/ )
>
> Reason for revert:
> Found to break SAP Web IDE, and these semantics are not shipped in any other browser.
> Revert to legacy semantics while assessing web compatibility.
>
> BUG=chromium:624318
>
> Original issue's description:
> > Put RegExp js code in strict mode
> >
> > src/js/regexp.js was one of the few files that was left in sloppy
> > mode. The ES2017 draft specification requires that writes to
> > lastIndex throw when the property is non-writable, and test262
> > tests enforce this behavior. This patch puts that file in strict
> > mode.
> >
> > BUG=v8:4504
> > R=yangguo@chromium.org
> > LOG=Y
> >
> > Committed: https://crrev.com/80b1b2a45bbd9bf3d08e4e6516acfaaa8f438213
> > Cr-Commit-Position: refs/heads/master@{#34801}
>
> TBR=yangguo@chromium.org,adamk@chromium.org
>
> Committed: https://crrev.com/34880eb3dcf7492d44c0a3b45b6c888189f2c3c3
> Cr-Commit-Position: refs/heads/master@{#37449}
TBR=adamk@chromium.org,yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:624318
Review-Url: https://codereview.chromium.org/2344773002
Cr-Commit-Position: refs/heads/master@{#39456}
To avoid a dependency on the heap during parsing, we only create a scope chain
without linking to the associated ScopeInfo objects before parsing. This is
enough to avoid special cases during parsing of arrow functions / eval.
Looking at the outer scope's variables during parsing was only needed for hosting
sloppy block functions inside eval. To be able to do this now, we hoist for the
outer-most eval scope after parsing, in DeclarationScope::Analyze.
DeclarationScope::Analyze is also where we replace the outer scope chain with the
fully deserialized version, so variables can be resolved.
Also, this unifies background and foreground thread parsing, as we don't have to
worry about ScopeInfos getting accessed before we're back on the main thread.
BUG=v8:5215
R=verwaest@chromium.org,marja@chromium.org,adamk@chromium.org
Review-Url: https://codereview.chromium.org/2306413002
Cr-Commit-Position: refs/heads/master@{#39452}
All parameters passed by reference must be labeled const.
If the object is mutable, then we pass by pointer.
BUG=
Review-Url: https://codereview.chromium.org/2336233006
Cr-Commit-Position: refs/heads/master@{#39451}
We used to intercept function definitions, but not declarations.
GenericNamedPropertySetterCallback now also intercepts function declarations.
For definitions, we call DeclareGlobal and then InitializeVarGlobal. For
declarations, we never call InitializeVarGlobal, thus we must check for
interceptors in DeclareGlobal.
If the semantics of a redeclaration are wrong, e.g., redeclaring a read-only
property, an exception is thrown independent of whether an interceptor is
installed. Usually, i.e., not during a declaration, we only throw if
the call is not successfully intercepted.
BUG=v8:5375
Review-Url: https://codereview.chromium.org/2334733002
Cr-Commit-Position: refs/heads/master@{#39450}
This CL implements the throw wasm opcode. This is a pre-requisite for
implementing try-catches in wasm.
BUG=
Review-Url: https://codereview.chromium.org/2339053003
Cr-Commit-Position: refs/heads/master@{#39449}
This handles the case where generating bytecode for inlining purposes
causes a stack overflow. We just abort inlining but also need to clear
pending exceptions.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647217
BUG=chromium:647217
Review-Url: https://codereview.chromium.org/2339383002
Cr-Commit-Position: refs/heads/master@{#39448}
The semantics of the {BailoutId} representing an OSR entry point is
different between the interpreter and the full code generator. These
semantics are hard-coded in various graph builders. We need to ensure
that the correct graph builder is chosen for OSR compilations.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-5380
BUG=v8:5380
Review-Url: https://codereview.chromium.org/2341663002
Cr-Commit-Position: refs/heads/master@{#39444}
This is a first implementation of inlining into graphs that have been
created using the {BytecodeGraphBuilder}. Note that inlining sticks to
graphs of the same kind, we only ever inline AstGraph into AstGraph or
BytecodeGraph into BytecodeGraph, no mixed inlining.
R=bmeurer@chromium.org,rmcilroy@chromium.org
TEST=cctest/test-run-inlining
BUG=v8:5251
Review-Url: https://codereview.chromium.org/2262033003
Cr-Commit-Position: refs/heads/master@{#39439}
This flag has been flipped off since 52, so it is due for removal.
R=adamk@chromium.org,caitp@igalia.com
BUG=v8:3785
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng
Review-Url: https://codereview.chromium.org/2268633002
Cr-Commit-Position: refs/heads/master@{#39435}
In case of duplicate exports, always report the error for the very last
one.
(Fixed a bug.)
BUG=v8:5358,v8:1569
Review-Url: https://codereview.chromium.org/2340953002
Cr-Commit-Position: refs/heads/master@{#39434}
Handle the "synchronous case" by marking try/catch blocks introduced for
async functions as ASYNC_AWAIT and traversing up the stack, finding successive
Promises and returning caught if any of them are predicted to be caught.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2325813002
Cr-Commit-Position: refs/heads/master@{#39433}
This exposes an interface for the embedder to provide a delegate which can
serialize or deserialize embedder-specific objects, like Blink's DOM wrappers.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2327653002
Cr-Commit-Position: refs/heads/master@{#39422}
Add a dedicated simplified operator to inline the general case for the
ToBoolean conversion. In a follow up CL we will also use the ToBoolean
hints gathered by the baseline compiler.
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_arm64_gc_stress_dbg
R=jarin@chromium.org
BUG=v8:5267
Committed: https://crrev.com/8c50b51ab3d21efcd2f6900d83962159f21e1590
Review-Url: https://codereview.chromium.org/2167593002
Cr-Original-Commit-Position: refs/heads/master@{#37882}
Cr-Commit-Position: refs/heads/master@{#39420}
This CL adds fuzzers for the wasm module sections 'types', 'names',
'globals', 'imports', 'function signatures', 'memory', and 'data', one
fuzzer per section. No fuzzers are added for the other sections because
either there already exists a fuzzer (e.g. wasm-code), or there exist
inter-section dependencies.
To avoid introducing a bunch executables which would make compilation
with make slow, I introduce a single executable
'v8_simple_wasm_section_fuzzer' which calls the fuzzers mentioned above.
This executable is run by the trybots and ensures that the fuzzers
actually compile. For debugging I introduce commandline parameters which
allow to execute the specific fuzzers from 'v8_simple_wasm_section_fuzzer'.
R=titzer@chromium.org, jochen@chromium.org, mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2336603002
Cr-Commit-Position: refs/heads/master@{#39413}
The wasm-module-runner is used both in cctests and in fuzzers. As
discussed offline, it is weird to include cctest header files in
fuzzers, so I introduce a new test/common directory which contains the
common files.
R=titzer@chromium.org, jochen@chromium.org
Review-Url: https://codereview.chromium.org/2335193002
Cr-Commit-Position: refs/heads/master@{#39411}
Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).
Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.
Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).
See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8
BUG=v8:5267,v8:5372
R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2337123003
Cr-Commit-Position: refs/heads/master@{#39410}
The initial support for low level exception handling in Wasm will not
support finally blocks. This decision is taken for both simplicity (
handling finallys is not straightforward if we want try blocks to yield
values), and lack of good use case (clang++ does not need them.) They
may be added in the future once we understand the implications of
having them.
BUG=
Review-Url: https://codereview.chromium.org/2336303002
Cr-Commit-Position: refs/heads/master@{#39393}
This reverts commit cf5180c3ef. It turns
out finally blocks aren't useful in the current incarnation of Wasm. We
might reintroduce it later.
BUG=
Review-Url: https://codereview.chromium.org/2330073002
Cr-Commit-Position: refs/heads/master@{#39390}
This adds a regression test for a bug where {OsrPoll} instructions
within the bytecode stream ended up outside of actual loops. This has
been fixed already, by merging {OsrPoll} into the backwards branch.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-645888
BUG=chromium:645888
Review-Url: https://codereview.chromium.org/2337033002
Cr-Commit-Position: refs/heads/master@{#39385}
This introduces a new {JumpLoop} bytecode to combine the OSR polling
mechanism modeled by {OsrPoll} with the actual {Jump} performing the
backwards branch. This reduces the overall size and also avoids one
additional dispatch. It also makes sure that OSR polling is only done
within real loops.
R=rmcilroy@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2331033002
Cr-Commit-Position: refs/heads/master@{#39384}
Moves the context chain search loop out of generated bytecode, and into
the (Lda|Ldr|Sda)ContextSlot handler, by passing the context depth in as
an additional operand. This should decrease the bytecode size and
increase performance for deep context chain searches, at the cost of
slightly increasing bytecode size for shallow context access.
Review-Url: https://codereview.chromium.org/2336643002
Cr-Commit-Position: refs/heads/master@{#39378}
To make better inlining decisions, it's good to have call counts for poly/mega-morphic cases. This CL makes it work for calls, and another will follow to better unify the code between constructor calls and normal calls (and thence, to record megamorphic call counts there as well).
BUG=
Review-Url: https://codereview.chromium.org/2325083003
Cr-Commit-Position: refs/heads/master@{#39377}
Add strength reduction rules to optimize
CheckTaggedSigned(CheckTaggedSigned(x)) -> CheckTaggedSigned(x)
and
CheckTaggedPointer(CheckTaggedPointer(x)) -> CheckTaggedPointer(x)
where we do some cleanup optimizations after loop peeling and redundancy
elimination, which can generate these constructs.
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2336093002
Cr-Commit-Position: refs/heads/master@{#39366}
This change avoids needing to keep around an unused compiled
module. Instead, the result of compiling the wasm bytes is
given to the first instance. The module object and that instance object
point to the same compiled module. Instances are, then, cloned from
the compiled module the module object points to. When an instance is
collected, we make sure that the module object still has a clone
available, and, if the last instance is GC-ed, we also reset the compiled
module so that it does not reference its heap, so that it (==heap) may
be collected.
This is achieved by linking the clones in a double-linked list and
registering a finalizer for each. When we create an instance, we tie it
in the front of the list, making the module object point to it (O(1)). When
the finalizer is called, we relink the list over the dying object (O(1)). The
costliest operation is finalizing the last instance, since we need to visit
all wasm functions and reset heap references.
BUG=v8:5316
Committed: https://crrev.com/01f5af515728aebe6c5246f4f7dd6c573e8748af
Review-Url: https://codereview.chromium.org/2305903002
Cr-Original-Commit-Position: refs/heads/master@{#39153}
Cr-Commit-Position: refs/heads/master@{#39361}
Moved the compilation/instantiation pipeline to work off the
module object (JSObject), making the compiled module data (the
FixedArray) an implementation detail. This:
- simplifies the code by removing duplicate decode->compile->instantiate
sequences
- sets up the stage for "dressing up" the runtime model with
stronger typed APIs
- helps relanding this CL: https://codereview.chromium.org/2305903002/.
It turns out that GCs during the cloning/instantiation events cause
trouble, and centering the source of truth on the module object helps
address this issue.
In the process, clarified cctest setup for wasm-capable isolates,
and changed signatures for consistency (using ModuleOrigin througout).
BUG=
Review-Url: https://codereview.chromium.org/2320723005
Cr-Commit-Position: refs/heads/master@{#39360}
The raw pointer to the parameter_map might get stale in case of accessors present on
the arguments object.
Drive-by-fix: use nullptr instead of the_hole with isolate access.
BUG=chromium:645680
Review-Url: https://codereview.chromium.org/2332503002
Cr-Commit-Position: refs/heads/master@{#39359}
The whitelist is populated with those inline intrinsics that are lowered
in JSIntrinsicInlining and were not previously blacklisted. Thus the only
additional FrameStates this CL adds are those where the caller tries to
call the INLINE version of an intrinsic but ends up calling the RUNTIME
version instead.
R=bmeurer@chromium.org
BUG=chromium:644631
Review-Url: https://codereview.chromium.org/2331543002
Cr-Commit-Position: refs/heads/master@{#39357}
This adds partial support of exports to the runtime system and
to the interpreter. It introduces a new HeapObject JSModule that
maps each of the module's export names to a Cell containing the
exported value.
Several aspects of this implementation are subject to change in
follow-up CLs.
BUG=v8:1569
Committed: https://crrev.com/241a0412eed919395a2e163b30b9b66071ce5c17
Review-Url: https://codereview.chromium.org/2302783002
Cr-Original-Commit-Position: refs/heads/master@{#39341}
Cr-Commit-Position: refs/heads/master@{#39352}
With this CL the wasm-code-fuzzer first decodes and interprets the test
case generated by the fuzzer. It then compiles the test case, but only
executes the compiled instance if the interpretation of the test case
was successful. If the compiled instance is executed, then the result of
the execution is compared with the result of the interpretation.
Additionally this CL refactors the CompileAndRunWasmModule function in
wasm-module.cc to resuse code in the call to the interpreter.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2321443002
Cr-Commit-Position: refs/heads/master@{#39351}
This patch changes incremental marking work scheduling from combination
of idle/delayed tasks to ordinary short-running tasks and moves
more marking work from V8.Execute to tasks by accounting how much
bytes were marked in tasks.
BUG=chromium:616434
LOG=NO
Review-Url: https://codereview.chromium.org/2321553002
Cr-Commit-Position: refs/heads/master@{#39348}
Reason for revert:
Failures related to deopt.
Original issue's description:
> [modules] Basic support of exports
>
> This adds partial support of exports to the runtime system and
> to the interpreter. It introduces a new HeapObject JSModule that
> maps each of the module's export names to a Cell containing the
> exported value.
>
> Several aspects of this implementation are subject to change in
> follow-up CLs.
>
> BUG=v8:1569
>
> Committed: https://crrev.com/241a0412eed919395a2e163b30b9b66071ce5c17
> Cr-Commit-Position: refs/heads/master@{#39341}
TBR=adamk@chromium.org,rmcilroy@chromium.org,ulan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2328283002
Cr-Commit-Position: refs/heads/master@{#39345}
This adds partial support of exports to the runtime system and
to the interpreter. It introduces a new HeapObject JSModule that
maps each of the module's export names to a Cell containing the
exported value.
Several aspects of this implementation are subject to change in
follow-up CLs.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2302783002
Cr-Commit-Position: refs/heads/master@{#39341}
With this CL the AstDecoder produces an error if it encounters a
grow_memory instruction in an asmjs module. Additionally asmjs
instructions are not allowed anymore in wasm modules.
BUG=chromium:644674
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2324733002
Cr-Commit-Position: refs/heads/master@{#39339}
This patch moves the following parsing method to ParserBase:
- ParseSwitchStatement
It also removes ParseCaseClause and merges it with ParseSwitchStatement,
mainly to avoid the complexity of introducing one more abstract typedef
to be shared between parser implementations, but also because the merged
ParseSwitchStatement is now only 59 lines.
R=adamk@chromium.org, marja@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2324843005
Cr-Commit-Position: refs/heads/master@{#39337}
Escape sequences may now be written to a trace file (previously,
any string with a valid escapable character would fail a check).
Also, string properties are now surrounded with quotes.
BUG=v8:4561
Review-Url: https://codereview.chromium.org/2309943005
Cr-Commit-Position: refs/heads/master@{#39319}
GetFunctionNameStr and GetScriptResourceNameStr can be called from a thread
other than isolate VM thread unlike their conterparts GetFunctionName
and GetScriptResourceName.
BUG=406277
Review-Url: https://codereview.chromium.org/2328673003
Cr-Commit-Position: refs/heads/master@{#39313}
This fixes a corner-case where the bytecode was using the <new.target>
register directly without going through the local variable. The value
might be clobbered because the deoptimizer doesn't properly restore the
value. The label will causes bytecode pipeline to be flushed and hence
ensure {BytecodeRegisterOptimizer} doesn't reuse <new.target> anymore.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-645103
BUG=chromium:645103
Review-Url: https://codereview.chromium.org/2325133002
Cr-Commit-Position: refs/heads/master@{#39306}
Before this change, the spread desugaring would naively call
`%AppendElement($R, the_hole)` and in some cases $R would have
a non-holey elements kind, putting the array into the bad state
of exposing holes to author code.
This patch avoids calling %AppendElement with a hole, instead
simply incrementing $R.length when it sees a hole in the literal
(this is safe because $R is known to be an Array). The existing
logic for elements transitions takes care of giving the array a
holey ElementsKind.
BUG=chromium:644215
Review-Url: https://codereview.chromium.org/2321533003
Cr-Commit-Position: refs/heads/master@{#39294}
This CL fixes %DebugPrint for FAST_HOLEY_DOUBLE_ELEMENTS and now properly
distinguishes TheHole and NaN values.
BUG=
Review-Url: https://codereview.chromium.org/2294913004
Cr-Commit-Position: refs/heads/master@{#39293}
Adds support to collect allocation site feedback for Array function calls
to the call bytecode handler.
BUG=v8:4280, v8:4780
LOG=N
Review-Url: https://codereview.chromium.org/2307903002
Cr-Commit-Position: refs/heads/master@{#39283}
The existing PropertyQueryCallback intercepts getOwnPropertyDescriptor, but
it returns only value and attributes, not the accessors. This
PropertyDescriptorCallback returns a descriptor similar to Ecma-262 6.2.4.
You can either set a PropertyQueryCallback or a PropertyDescriptorCallback,
but not both. When you set a callback for DefineProperty(), you can set a
PropertyDescriptorCallback but not a PropertyQueryCallback.
BUG=v8:5359
Review-Url: https://codereview.chromium.org/2311873002
Cr-Commit-Position: refs/heads/master@{#39279}
This fixes the materialization of JSFunction objects to not rely on a
context being available. The context has been cleared because it might
be de-materiallized itself.
R=bmeurer@chromium.org
TEST=mjsunit/compiler/escape-analysis-materialize
BUG=chromium:644245
Review-Url: https://codereview.chromium.org/2320983002
Cr-Commit-Position: refs/heads/master@{#39277}
The test was using some callee saved registers but tests don't save those.
BUG=v8:5354
Review-Url: https://codereview.chromium.org/2322923002
Cr-Commit-Position: refs/heads/master@{#39275}
This adds support to the deoptimizer to materialize ContextExtension
objects that have been de-materialized by escape analysis. This is
follow-up to the inline allocation of such objects during the create
lowering phase (i.e. JSCreateWithContext and JSCreateCatchContext).
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-644245
BUG=chromium:644245
Review-Url: https://codereview.chromium.org/2317353003
Cr-Commit-Position: refs/heads/master@{#39270}
When lowering Array.prototype.push/.pop to the fast inlined version, we
first need to ensure that all prototypes (including the Object.prototype)
are stable.
R=mvstanton@chromium.org
BUG=chromium:644689
Review-Url: https://codereview.chromium.org/2319533005
Cr-Commit-Position: refs/heads/master@{#39266}
Reason for revert:
Breaks g++ build.
Original issue's description:
> [turbofan] ARM: Implement vswp and use in gap resolver
>
> Use vswp to switch double-precision registers in the gap resolver, with fall
> back temp register-based code if NEON is not available.
>
> BUG=
>
> Committed: https://crrev.com/2837c2e65a2ee5b9fc610f30ce1215f52323ecbd
> Cr-Commit-Position: refs/heads/master@{#39209}
BUG=
Review-Url: https://codereview.chromium.org/2314043002
Cr-Commit-Position: refs/heads/master@{#39264}
The optimization is not correct for unsigned output types, and we the
overall complexity seems too high. We need to find a better way to
take into account the input/output type restrictions.
Also added a regression test for the unsigned output bug.
BUG=v8:5267,v8:5270,v8:5357
TBR=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2320013002
Cr-Commit-Position: refs/heads/master@{#39262}
The trouble here is that the type of the induction variable might be
a bit ahead of the increment (JSAdd) operation's type. When we update
the type of the increment, we might only update the induction variable
type while the JSAdd type might be stale. If the induction variable typing
needs to fall back to normal phi typing (e.g., when the increment is not
an integer anymore), it might use the stale type.
To get around this, we fake monotonicity if we fallback to normal phi
typing. Another option would be to force re-typing of the increment
operation, but that seems to be harder to maintain.
BUG=chromium:644633
Review-Url: https://codereview.chromium.org/2320803002
Cr-Commit-Position: refs/heads/master@{#39261}
This patch fixes a bunch of out-of-date TODOs, un-skips some tests
and refers to appropriate bug numbers and current specification
status where appropriate.
R=adamk
Review-Url: https://codereview.chromium.org/2319203002
Cr-Commit-Position: refs/heads/master@{#39260}
