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}
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}
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}
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 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 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 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 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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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}
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 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}
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}
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}
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}
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}
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}
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}
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}
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}
While fixing the bug, removed code duplication from super load/store
runtime calls, and inlined calls of Object::ReadAbsentProperty (left
over from strong mode).
BUG=v8:5335
Review-Url: https://codereview.chromium.org/2311413002
Cr-Commit-Position: refs/heads/master@{#39257}
We were previously incorrectly changing:
sub r0, 0, r1
cmp r2, r0
b.cond <addr>
to:
cmn r2, r1
b.cond <addr>
for all conditions. This is incorrect for conditions involving the C (carry)
and V (overflow) flags, and in particular in the case where r1 = INT_MIN.
The optimization is still safe to perform for Equal and NotEqual since they
do not depend on the C and V flags.
BUG=
Review-Url: https://codereview.chromium.org/2318043002
Cr-Commit-Position: refs/heads/master@{#39246}
Migrate the isNaN, isFinite, Number.isFinite, Number.isInteger,
Number.isSafeInteger and Number.isNaN predicates to TurboFan
builtins and make them optimizable (for certain input types) in
JavaScript callees being optimized by TurboFan. That means both
the baseline and the optimized version is now always at maximum,
consistent performance. Especially TurboFan suffered from poor
baseline (and optimized) performance because it cannot play the
same weird tricks that Crankshaft plays for %_IsSmi.
This also adds a bunch of new tests to properly cover the use
of the Harmony predicates in optimized code.
R=franzih@chromium.org
BUG=v8:5049,v8:5267
Review-Url: https://codereview.chromium.org/2313073002
Cr-Commit-Position: refs/heads/master@{#39242}
In ignition, allocation site mementos were disabled when creating array
literals. Enabled them in this cl.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/2294913006
Cr-Commit-Position: refs/heads/master@{#39234}
This moves scope-related logic (such as looking up variables) to Scope
where it belongs, and enables PreParser to do more Scope-related
operations in the future.
BUG=
Review-Url: https://codereview.chromium.org/2301183003
Cr-Commit-Position: refs/heads/master@{#39233}
Lexically declared "arguments" in sloppy mode will throw redeclaration error
currently, this patch fixes it by delaying the declaration of arguments until we
fully parse parameter list and function body.
BUG=v8:4577
LOG=N
Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa
Review-Url: https://codereview.chromium.org/2290753003
Cr-Original-Commit-Position: refs/heads/master@{#39109}
Cr-Commit-Position: refs/heads/master@{#39230}
Move the code to perform function name inference for properties into
parsing the properties themselves, instead of the containing object.
This allows us to avoid unnecessary calls when parsing shorthand
properties and methods and simplifies the logic in the remaining cases.
Also fixes an edge case bug: inferring the name of the getter in
`class { static get constructor(){} }`.
Review-Url: https://codereview.chromium.org/2313723005
Cr-Commit-Position: refs/heads/master@{#39222}
This adds handling of {IrOpcode::kObjectIsReceiver} nodes to the escape
status analysis. Such uses are treated as escaping for now until we add
dedicated handling to the escape analysis reducer.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-631027
BUG=chromium:631027
Review-Url: https://codereview.chromium.org/2317623003
Cr-Commit-Position: refs/heads/master@{#39205}
The constructor and new.target arguments were passed to CallConstruct in
the wrong order by BytecodeGraphBuilder, which caused subclassing to be
incorrect when optimizing from bytecode.
Also clean up some unecessary functions in interpreter.cc found while
figuring this out.
BUG=chromium:642409
Review-Url: https://codereview.chromium.org/2312103002
Cr-Commit-Position: refs/heads/master@{#39204}
This handles the case where preparation of bytecode might fail inside
Compiler::EnsureBytecode due to the underlying function being a fully
validated asm.js module. We simply bailout of bytecode preparation.
R=bradnelson@chromium.org
TEST=mjsunit/regress/regress-crbug-644111
BUG=chromium:644111
Review-Url: https://codereview.chromium.org/2309853002
Cr-Commit-Position: refs/heads/master@{#39187}
Disable the propagation of truncations through Phi, Select or TypeGuard
if the output representation is tagged, because when the truncations are
taken we don't necessarily reflect this in the types and therefore we
might end up in a situation where we produce a word32 value, the type
says Number, and now we need to change that to tagged, which is not
possible since we don't know how to interpret the bits, i.e. whether the
value is Signed32 or Unsigned32.
BUG=chromium:644048
Review-Url: https://codereview.chromium.org/2311903002
Cr-Commit-Position: refs/heads/master@{#39186}
Reason for revert:
Performance regressions: crbug.com/644087
Clusterfuzz: crbug.com/644074
We'll reland all regexp changes at once when the port is complete and at least performance-neutral, since the partial port requires slow workarounds.
Original issue's description:
> [regexp] Port RegExp getters and setters
>
> BUG=v8:5339
>
> Committed: https://crrev.com/ac0eb5e05af40e16ae9402bb8a62600b32cc2ec9
> Committed: https://crrev.com/7711b1a16f864ed6ea56fa40274ff3f6287bbe34
> Cr-Original-Commit-Position: refs/heads/master@{#39076}
> Cr-Commit-Position: refs/heads/master@{#39088}
TBR=bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2313713002
Cr-Commit-Position: refs/heads/master@{#39176}
Reason for revert:
mac gc stress failures:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/8341
Original issue's description:
> [wasm] reuse the first compiled module.
>
> 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
> Cr-Commit-Position: refs/heads/master@{#39153}
TBR=bradnelson@chromium.org,verwaest@chromium.org,vogelheim@chromium.org,yangguo@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5316
Review-Url: https://codereview.chromium.org/2306403002
Cr-Commit-Position: refs/heads/master@{#39154}
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
Review-Url: https://codereview.chromium.org/2305903002
Cr-Commit-Position: refs/heads/master@{#39153}
This disables notification of wasm script 'compilation' since
OnAfterCompile actually triggers a JS call (which is disallowed during
stack trace collection).
BUG=641065
Review-Url: https://codereview.chromium.org/2304943002
Cr-Commit-Position: refs/heads/master@{#39139}
Collect type feedback in the bytecode handler for 'new' bytecode. The
earlier cl (https://codereview.chromium.org/2153433002/) was reverted
because that implementation did not collect allocation site feedback.
This regressed delta blue by an order of magnitude. This implementation
includes collection of allocation site feedback.
Reland of https://codereview.chromium.org/2190293003/ with a bug fix.
BUG=v8:4280, v8:4780
LOG=N
Review-Url: https://codereview.chromium.org/2225923003
Cr-Commit-Position: refs/heads/master@{#39120}
Reason for revert:
Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/9470
Original issue's description:
> Allow lexically declared "arguments" in function scope in sloppy mode.
>
> Lexically declared "arguments" in sloppy mode will throw redeclaration error
> currently, this patch fixes it by delaying the declaration of arguments until we
> fully parse parameter list and function body.
>
> BUG=v8:4577
> LOG=N
>
> Committed: https://crrev.com/70a613dd0a5f5d205b46559b55702764464851fa
> Cr-Commit-Position: refs/heads/master@{#39109}
TBR=adamk@chromium.org,mythria@chromium.org,lpy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4577
Review-Url: https://codereview.chromium.org/2304853002
Cr-Commit-Position: refs/heads/master@{#39115}
Lexically declared "arguments" in sloppy mode will throw redeclaration error
currently, this patch fixes it by delaying the declaration of arguments until we
fully parse parameter list and function body.
BUG=v8:4577
LOG=N
Review-Url: https://codereview.chromium.org/2290753003
Cr-Commit-Position: refs/heads/master@{#39109}
We use a signaling NaN to represent the hole in
FAST_HOLEY_DOUBLE_ELEMENTS backing stores, but on Intel processors, the
C++ compiler may decide to (or be forced to due to calling conventions)
use X87 registers for double values. However transfering to X87
registers automatically quietens the NaNs and there's no way to disable
this. Therefore we should just always load the hole NaN from the canonical
place identified by the address_of_hole_nan external reference instead,
which might even be more efficient in some cases.
R=jarin@chromium.org, jkummerow@chromium.org
BUG=v8:5332
Review-Url: https://codereview.chromium.org/2303643002
Cr-Commit-Position: refs/heads/master@{#39062}
This patch arranges that property names are parsed in a single pass,
reporting the name as well as the type of the property, instead of
parsing qualifiers like 'static' or 'get' initially as names and then
re-parsing. This change is easier to reason about, very slightly (4%)
faster in some cases (although slower in other, less common ones, though
this slowdown will be fixed in an upcoming patch), and is a prerequisite
for separating the parsing of object and class literal properties, which
will become increasingly important as ECMAScript adds more class features.
This is a reland of https://codereview.chromium.org/2278153004/,
which fixes the issue causing the revert and adds more tests.
Review-Url: https://codereview.chromium.org/2300503002
Cr-Commit-Position: refs/heads/master@{#39056}
Previously, fast holey elements accessors would detect element presence
by simply doing a hole check on any slot within the backing store's
capacity. This relied on the (mostly-true but brittle) assumption that
slots beyond the length are always correctly zapped with The Hole.
Review-Url: https://codereview.chromium.org/2297253002
Cr-Commit-Position: refs/heads/master@{#39051}
When we try to further fold previously folded allocations in Crankshaft
GVN we don't properly transform the allocations involved, which causes
the mechanism to leave holes in the new/old space (and thereby violate
the iterability property of the new/old space).
BUG=chromium:621868
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2297983003
Cr-Commit-Position: refs/heads/master@{#39040}
This removes two bits of duplication:
- Parsing of each AssignmentExpression, which previously was called
first outside the loop and then inside the loop.
- Parsing of arrow rest parameters, which previously was handled
separately for the one-arg and N-arg cases.
The only change in behavior is in a few error messages.
Review-Url: https://codereview.chromium.org/2279363002
Cr-Commit-Position: refs/heads/master@{#39030}
Test ensuring globals are isolated between instances. Also
added support for globals section to mjsunit's
WebModuleBuilder as a prerequisite.
BUG=
Review-Url: https://codereview.chromium.org/2296993002
Cr-Commit-Position: refs/heads/master@{#39028}
If the input of grow-memory was not representable as a SMI, then the
input was not passed correctly to the runtime, which caused a crash.
With this CL the input of grow-memory is checked before the runtime is
called.
R=titzer@chromium.org, gdeepti@chromium.org
TEST=mjsunit/wasm/grow-memory.js:testGrowMemoryTrapsWithNonSmiInput()
Review-Url: https://codereview.chromium.org/2288773002
Cr-Commit-Position: refs/heads/master@{#39022}
With this CL we use isolate->native_context() to provide a context for
the CEntryStub of the runtime call. The native_context() is sufficient
here because Runtime::kWasmThrowTypeError does not use the context.
R=titzer@chromium.org
TEST=mjsunit/wasm/ffi-error.js
BUG=chromium:639492
Review-Url: https://codereview.chromium.org/2291043002
Cr-Commit-Position: refs/heads/master@{#39014}
Tail calls don't make sense from async functions and generators, as
each activation of these functions needs to make a new, distnict,
non-reused generator object. These tail calls are not required per
spec. This patch disables both syntactic and implicit tail calls
in async functions and generators.
R=neis
BUG=v8:5301,chromium:639270
Review-Url: https://codereview.chromium.org/2278413003
Cr-Commit-Position: refs/heads/master@{#38986}
This removes test/webkit/fast/js/stack-overflow-arrity-catch.js, which tests that the stack overflows in a very particular way. It doesn't seem to test anything important, and only used to work because we didn't inline into try-blocks.
BUG=
R=jarin
Review-Url: https://codereview.chromium.org/2216353002
Cr-Commit-Position: refs/heads/master@{#38976}
- Make constants more interesting.
- Add an addition to be done after the inlined call in the try-block.
- On command line, have a bit more output.
- New alternative that deopts from unoptimized code.
BUG=
R=jarin
Review-Url: https://codereview.chromium.org/2285743002
Cr-Commit-Position: refs/heads/master@{#38974}
These tests were spliced out of changelist 2216353002 and extended.
BUG=
Review-Url: https://codereview.chromium.org/2245263003
Cr-Commit-Position: refs/heads/master@{#38906}
Reason for revert:
Octane/Mandreel aborts with an exception now:
TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function
Original issue's description:
> [turbofan] Insert dummy values when changing from None type.
>
> Currently we choose the MachineRepresentation::kNone representation for
> values of Type::None, and when converting values from the kNone representation
> we use "impossible" conversions that will crash at runtime. This
> assumes that the impossible conversions should never be hit (the only
> way to produce the impossible values is to perform an always-failing
> runtime check on a value, such as Smi-checking a string). Note that
> this assumes that the runtime check is executed before the impossible
> convesrion.
>
> Introducing BitwiseOr type feedback broke this in two ways:
>
> - we always pick Word32 representation for bitwise-or, so the
> impossible conversion does not trigger (it only triggers with
> None representation), and we could end up with unsupported
> conversions from Word32.
>
> - even if we inserted impossible conversions, they are pure conversions.
> Since untagging, bitwise-or operations are also pure, we could hoist
> all these before the smi check of the inputs and we could hit the
> impossible conversions before we get to the smi check.
>
> This CL addresses this by just providing dummy values for conversions
> from the Type::None type. It also removes the impossible-to-* conversions.
>
> BUG=chromium:638132
>
> Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
> Cr-Commit-Position: refs/heads/master@{#38883}
TBR=mstarzinger@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:638132
Review-Url: https://codereview.chromium.org/2280613002
Cr-Commit-Position: refs/heads/master@{#38893}
There's no point in running the LoadElimination on asm.js functions and
it would take serious amount of effort to actually make it correct for
the deprecated parts of the pipeline.
R=jarin@chromium.org
BUG=v8:5308
Review-Url: https://codereview.chromium.org/2276273002
Cr-Commit-Position: refs/heads/master@{#38884}
Currently we choose the MachineRepresentation::kNone representation for
values of Type::None, and when converting values from the kNone representation
we use "impossible" conversions that will crash at runtime. This
assumes that the impossible conversions should never be hit (the only
way to produce the impossible values is to perform an always-failing
runtime check on a value, such as Smi-checking a string). Note that
this assumes that the runtime check is executed before the impossible
convesrion.
Introducing BitwiseOr type feedback broke this in two ways:
- we always pick Word32 representation for bitwise-or, so the
impossible conversion does not trigger (it only triggers with
None representation), and we could end up with unsupported
conversions from Word32.
- even if we inserted impossible conversions, they are pure conversions.
Since untagging, bitwise-or operations are also pure, we could hoist
all these before the smi check of the inputs and we could hit the
impossible conversions before we get to the smi check.
This CL addresses this by just providing dummy values for conversions
from the Type::None type. It also removes the impossible-to-* conversions.
BUG=chromium:638132
Review-Url: https://codereview.chromium.org/2266823002
Cr-Commit-Position: refs/heads/master@{#38883}
This patch fixes up one last case of redundant ExceptionEvents being
triggered in the debugger for Promises--it makes the default reject
handler for Promises (e.g., if the second argument for
Promise.prototype.then is missing) appear to the debugger as a
rethrow.
R=adamk@chromium.org,jgruber@chromium.org
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2278643002
Cr-Commit-Position: refs/heads/master@{#38876}
Unfortunately, I was unable to produce a repro without asm.js. In normal
JavaScript, the bounds check renaming saves us.
I have not done anything about the index variable aliasing and handling
of differently sized elements yet!
BUG=chromium:639210, v8:5266
Review-Url: https://codereview.chromium.org/2270793004
Cr-Commit-Position: refs/heads/master@{#38874}
This preserves the original shared code of the underlying function when
bytecode is provided. The method in question should only ensure bytecode
is present, but should avoid switching compilation tiers of the given
function. It might be that the function was fast-tracked to baseline by
inlining without going through the interpreted tier first.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-635923
BUG=chromium:635923
Review-Url: https://codereview.chromium.org/2278543002
Cr-Commit-Position: refs/heads/master@{#38866}
Don't bother using %_IsJSReceiver, which immediately gets lowered to
ObjectIsReceiver anyways (by the JSIntrinsicLowering), but requires
some complicated rewiring of effect/control chains.
R=mstarzinger@chromium.org
BUG=chromium:640369
Review-Url: https://codereview.chromium.org/2271973003
Cr-Commit-Position: refs/heads/master@{#38864}
To make async/await catch prediction work well, this patch regularizes
the exception events sent to DevTools from various places in the Promise
lifecycle. The core is that there should be an exception event when the
rejection first starts, rather than when it is propagated.
- Several cases within Promise code which propagate errors are
modified to not trigger a new ExceptionEvent in that case, such
as .then on a rejected Promise and returning a rejected Promise
from .then, as well as Promise.race and Promise.all.
- Make Promise.reject() create an ExceptionEvent, subject to catch
prediction based on the Promise stack. This is important
so that, e.g., if "await Promise.reject()" will trigger a new
throw (rather than a silent rethrow of something that never
triggered an event in the first place).
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2244003003
Cr-Commit-Position: refs/heads/master@{#38847}
This makes sure the deoptimizer picks bytecode prepared for debugging
when materializing an interpreted frame if one is available. This is
normally done by the interpreter entry trampoline and hence needs to be
replicated by the deoptimizer.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2271443003
Cr-Commit-Position: refs/heads/master@{#38815}
Make use of %IsAsmWasmCode in place of Wasm.instantiateModuleFromAsm,
in order to reduce the surface area of the Wasm object,
and to focus on testing asm.js coming in via the parser.
Ignore extra CONST_LEGACY assignment introduced by the parser
when modules have the form:
(function Foo(a, b, c) {..});
This requires both a validator and AsmWasmBuilder change.
Move stdlib use collection to import time,
to reject modules that import a function, even if not used.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=jpp@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2264913002
Cr-Commit-Position: refs/heads/master@{#38806}
This flag was shipped on in 52, so it's due for removal. The patch includes
removing the deprecated and unused-in-Blink API Promise::Chain, and many
test updates.
R=adamk@chromium.org
BUG=v8:4633
Review-Url: https://codereview.chromium.org/2267033002
Cr-Commit-Position: refs/heads/master@{#38804}
Includes fast paths in the runtime for
DictionaryElementsAccessor, FastSmiOrObjectElementsAccessor,
FastDoubleElementsAccessor, TypedElementsAccessor, and
SloppyArgumentsElementsAccessor.
BUG=
Review-Url: https://codereview.chromium.org/2232063002
Cr-Commit-Position: refs/heads/master@{#38800}
This detects loops with integer decrements.
Drive-by fix: Add lower bounds to lower_bounds
zone vector instead of upper_bounds.
BUG=
Review-Url: https://codereview.chromium.org/2260153002
Cr-Commit-Position: refs/heads/master@{#38772}
Record which asm.js stdlib members are used and add a check that NaN is actually correctly set. Other stdlib members to be added in a later change.
Also add a stdlib argument to Wasm.instantiateModuleFromAsm, in preparation for that function to be replaced by normal asm.js instantiation.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
LOG=N
R=jpp@chromium.org,titzer@chromium.org
Review-Url: https://codereview.chromium.org/2251433002
Cr-Commit-Position: refs/heads/master@{#38760}
Unify the representation selection rules for NumberAdd/Subtract and
SpeculativeNumberAdd/Subtract wrt. Int32Add/Sub selection. We can
safely use Int32Add/Sub as long as the inputs are in the safe additive
integer range and the output is either truncated to Word32 or provably
in Signed32 or Unsigned32 range.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2253293005
Cr-Commit-Position: refs/heads/master@{#38746}
As required by the spec, ToJS now throws a TypeError fit I64 values
instead of truncating the I64 value to I32. To throw a TypeError I
introduced a new runtime function because the existing
Runtime::kThrowWasmError does not throw a TypeError. Since we have calls
to two runtime functions now, and an additional one is needed for stack
checks, I extracted the call to runtime functions into a helper function.
R=titzer@chromium.org
TEST=mjsunit/wasm/ffi-error.js:I64InSignatureThrows
Review-Url: https://codereview.chromium.org/2254803002
Cr-Commit-Position: refs/heads/master@{#38718}
This fixes canonicalization of {SharedFunctionInfo} objects in the
{Compiler::GetSharedFunctionInfo} method when bytecode is preserved.
Eager compilation is only triggered when no code is present.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-638551
BUG=chromium:638551
Review-Url: https://codereview.chromium.org/2245263006
Cr-Commit-Position: refs/heads/master@{#38709}
Ensures SMI values have SMI type even if they have a dot (e.g., 1.0).
Adds SMI_WITH_DOT type to maintain this.
BUG=chromium:638134
Review-Url: https://codereview.chromium.org/2248693005
Cr-Commit-Position: refs/heads/master@{#38698}
This fixes the case where a module is instantiated twice via the same
closure when in the meantime another closure has destroyed and removed
the WASM data attached to the SharedFunctionInfo.
R=bradnelson@chromium.org
TEST=mjsunit/asm/asm-validation
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2253613004
Cr-Commit-Position: refs/heads/master@{#38696}
Reason for revert:
WebGL tests have been updated and rolled (at https://codereview.chromium.org/2227023002), so this should no longer fail outdated tests.
Original issue's description:
> Revert of Amend DataView, ArrayBuffer, and TypedArray methods to use ToIndex. (patchset #8 id:140001 of https://codereview.chromium.org/2090353003/ )
>
> Reason for revert:
> Speculative revert to unblock roll: https://codereview.chromium.org/2107223003/
>
> Original issue's description:
> > Amend DataView, ArrayBuffer, and TypedArray methods to use ToIndex.
> >
> > The spec was modified to relax some requirements which implementors had not been
> > enforcing. Part of this process involved introducing a new abstract operation
> > ToIndex, which had partial overlap with our existing semantics as well as some
> > differences (most notably treating undefined as 0). Test262 tests were introduced to
> > check for the new semantics, some of which we were failing. This patch amends the
> > parts of our implementation corresponding to specification algorithms which use
> > ToIndex to follow its semantics precisely.
> >
> > BUG=v8:4784,v8:5120
> >
> > Committed: https://crrev.com/09720349ea058d178521ec58d0a5676443a5a132
> > Cr-Commit-Position: refs/heads/master@{#37406}
>
> TBR=littledan@chromium.org,adamk@chromium.org,bakkot@google.com
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4784,v8:5120
>
> Committed: https://crrev.com/b1f7f1f4e41a723d5f997738a07e35a031713b8f
> Cr-Commit-Position: refs/heads/master@{#37417}
TBR=littledan@chromium.org,adamk@chromium.org,hablich@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:4784,v8:5120
Review-Url: https://codereview.chromium.org/2247073004
Cr-Commit-Position: refs/heads/master@{#38689}
Our previous per-arch instantiation thunks for asm.js
didn't support modules that had or were called with anything other
than 3 arguments. Adding support for this.
Addding a runtime test method to check if asm validation succeeded.
Adding a test of validation with different argument count combinations.
R=mstarzinger@chromium.org
TEST=mjsunit/asm/asm-validator.js
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=4203
Review-Url: https://codereview.chromium.org/2229723002
Cr-Commit-Position: refs/heads/master@{#38688}
Async functions are implemented via special generator functions; special in the
sense that they generally do not immediately yield. However, our generators
implementation still assumed that every generator function initially yields
(concretely: before doing the state dispatch in a loop header). This CL fixes
that.
R=littledan@chromium.org, rmcilroy@chromium.org
BUG=chromium:638019
Review-Url: https://codereview.chromium.org/2253033002
Cr-Commit-Position: refs/heads/master@{#38684}
At the moment, two NumberConstant nodes get different type even if their
value is the same because we always allocate a new heap number for
each number constant. This can lead to replacing a node with a node of
disjoint type in value numbering, which can result in incorrect code
down the line because of inconsistent types.
This fix makes sure that we only replace a node with a sub-type
node. Once we introduce a proper type for number constants, we can
move back to the intersection typing in value numbering.
Unfortunately, it is quite hard to write a repro for this because we cache NumberConstant nodes. We only throw away cached values that have too many conflicts (>5), so the test has to contain values that fall into the same bucket. That's where the magic floating point numbers in the test come from (they have the same low 8-bits of their hashes).
BUG=chromium:633497
Review-Url: https://codereview.chromium.org/2251833002
Cr-Commit-Position: refs/heads/master@{#38675}
Properly deoptimize if the left hand side of a CheckedInt32Mod is
negative and the result of the operation is zero.
R=jarin@chromium.org
BUG=v8:5286
Review-Url: https://codereview.chromium.org/2243803002
Cr-Commit-Position: refs/heads/master@{#38615}
This bug was triggered by a very specific combination:
* A context-allocated variable at script scope.
* OSR optimization.
* A scheduled breakpoint, which triggers at stack checks.
Stack checks differ from other possible breakpoint locations in that
the context (among other things) may be in a register and not on the
stack, making it impossible to recover during deoptimization. The
frame_inspector then returns undefined when asked for the context.
In GetFrameDetails, handle this case by omitting all context-allocated
variables.
BUG=v8:5279
Review-Url: https://codereview.chromium.org/2245603002
Cr-Commit-Position: refs/heads/master@{#38611}
This adds a very first version of inlined Array.prototype.pop into
TurboFan optimized code. We currently limit the inlining to fast
object or smi elements, until the unclear situation around hole NaNs
is resolved and we have a clear semantics inside the compiler.
It's also probably overly defensive in when it's safe to inline
the call to Array.prototype.pop, but we can always extend that
later once we have sufficient trust in the implementation and see
an actual need to extend it.
BUG=v8:2229,v8:3952,v8:5267
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2239703002
Cr-Commit-Position: refs/heads/master@{#38578}
With this CL all kinds of Callable can imported into wasm. Please take a special look at the context that is used now in the WasmToJSWrapper.
BUG=633895
TEST=mjsunit/wasm/ffi.js
Review-Url: https://codereview.chromium.org/2208703002
Cr-Commit-Position: refs/heads/master@{#38569}
This patch adds additional tests for async functions and generators, in how
they interact with destructuring, default arguments and shadow parameter
copying.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2229243002
Cr-Commit-Position: refs/heads/master@{#38560}
This switches the interface of the runtime profiler to use frames as
opposed to functions for performing on-stack replacement. Requests for
such replacements need to target a specific frame. This will enable us
to activate bytecode as well as baseline code for the same function.
The existing %OptimizeOsr runtime function also had to adapted and now
takes an optional stack depth to target a specific stack frame.
R=bmeurer@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2230783004
Cr-Commit-Position: refs/heads/master@{#38548}
The scopes of suspended generators can now be accessed through GeneratorMirror
(similar to FrameMirror).
BUG=v8:5235
Review-Url: https://codereview.chromium.org/2228393002
Cr-Commit-Position: refs/heads/master@{#38530}
We now deopt when the lhs of a mod is negative and the rhs is 1 too (previously, we erroneusly returned 0 instead of -0).
BUG=v8:5278
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2233713002
Cr-Commit-Position: refs/heads/master@{#38525}
For holey/growing keyed stores, we need to check that there are no
setters in the prototype chain and protect against changes to that
via code dependencies.
R=verwaest@chromium.org
BUG=v8:5275,v8:5276
Review-Url: https://codereview.chromium.org/2231683002
Cr-Commit-Position: refs/heads/master@{#38514}
When we compile a growing store in TurboFan, we don't pass a (native)
context to the %GrowArrayElements fallback function, as the whole logic
is actually context independent. However, that means that we need to
bailout early in case the object is a prototype, which requires context
dependent checks in the array protector code.
R=cbruni@chromium.org
BUG=chromium:635798
Review-Url: https://codereview.chromium.org/2224253003
Cr-Commit-Position: refs/heads/master@{#38491}
While we might at some point want to explore if this is a win versus
whole modules, for now we have the Tables interface planned.
R=titzer@chromium.org,ahaas@chromium.org,mtrofin@chromium.org,rossberg@chromium.org
BUG=v8:5044
Review-Url: https://codereview.chromium.org/2226053002
Cr-Commit-Position: refs/heads/master@{#38461}
Introduces a new VariableLocation MODULE for variables that live in a
module's export table. Scope analysis sets this for the approriate variables.
Not yet supported by any backend.
Also, treats all imports as CONST bindings (including namespace imports), rather
than having new special variable modes.
BUG=
Review-Url: https://codereview.chromium.org/2199283002
Cr-Commit-Position: refs/heads/master@{#38426}
- Don't read .constructor when returning a Promise from an async function.
Instead, call out to the internals of Promise.resolve directly.
This is done by adding back in an "optimization" from an earlier form of
the async/await code written by Caitlin Potter.
- Async functions always return a new Promise with a distinct identity,
even if they simply return another Promise.
R=caitp@igalia.com
BUG=v8:4483
Review-Url: https://codereview.chromium.org/2219623002
Cr-Commit-Position: refs/heads/master@{#38404}
If we infer loop variable bounds, we need to insert a type rename node
(sigma) to make sure that simplified lowering can choose representations
consistently.
Review-Url: https://codereview.chromium.org/2222513002
Cr-Commit-Position: refs/heads/master@{#38391}
Unskip test which failed with Intl support disabled, and avoid using Intl
objects within the test.
BUG=chromium:634273,chromium:634357,v8:5162
NOTRY=true
R=mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2218743003
Cr-Commit-Position: refs/heads/master@{#38384}
Reason for revert:
[Sheriff] Fails on nosnap debug:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/8403
Original issue's description:
> [Interpreter] Collect type feedback for 'new' in the bytecode handler
>
> Collect type feedback in the bytecode handler for 'new' bytecode. The
> earlier cl (https://codereview.chromium.org/2153433002/) was reverted
> because that implementation did not collect allocation site feedback.
> This regressed delta blue by an order of magnitude. This implementation
> includes collection of allocation site feedback.
>
> BUG=v8:4280, v8:4780
> LOG=N
>
> Committed: https://crrev.com/9d5e6129c4c7f9cbfe81a5fad2a470f219fe137c
> Cr-Commit-Position: refs/heads/master@{#38364}
TBR=bmeurer@chromium.org,rmcilroy@chromium.org,balazs.kilvady@imgtec.com,mythria@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280, v8:4780
Review-Url: https://codereview.chromium.org/2212343002
Cr-Commit-Position: refs/heads/master@{#38368}
Collect type feedback in the bytecode handler for 'new' bytecode. The
earlier cl (https://codereview.chromium.org/2153433002/) was reverted
because that implementation did not collect allocation site feedback.
This regressed delta blue by an order of magnitude. This implementation
includes collection of allocation site feedback.
BUG=v8:4280, v8:4780
LOG=N
Review-Url: https://codereview.chromium.org/2190293003
Cr-Commit-Position: refs/heads/master@{#38364}
This fixes the runtime profiler to no longer assume that seeing an
optimized frame on the stack implies the underlying function is not
being interpreted when entered normally. This no longer holds with code
generated for OSR directly from bytecode (not installed on function).
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-632800
BUG=chromium:632800
Review-Url: https://codereview.chromium.org/2208603005
Cr-Commit-Position: refs/heads/master@{#38360}
This makes sure we prevent a tier-up for function which also have an
optimized activation of OSR code on the stack. In case the OSR code
deoptimizes, it needs the bytecode to still be around.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-5262
BUG=v8:5262
Review-Url: https://codereview.chromium.org/2206363004
Cr-Commit-Position: refs/heads/master@{#38359}
We don't need to add stability dependencies on JSObject prototypes when
storing to an element, because we do the map check (and thereby guard
the elements kind) and we also properly deoptimize on holes if the array
protector is not usable.
R=verwaest@chromium.org
BUG=chromium:616709
Review-Url: https://codereview.chromium.org/2198833002
Cr-Commit-Position: refs/heads/master@{#38355}
When parsing a eagerly-parsed-but-lazily-compiled function, we
used to put some of its AST nodes into a discardable Zone. This
CL puts the function Scope, its inner Scopes and the related AST
nodes (Declarations, VariableProxys) into the temporary Zone
too. This reduces peak memory usage and enables future work to
keep the temporary Zone around for later compilation.
BUG=
Review-Url: https://codereview.chromium.org/2210243002
Cr-Commit-Position: refs/heads/master@{#38348}
The contract is that the method is only invoked when there are no elements on
the prototype, and this elements type forbids accessor elements. So it is safe
to limit the search to the end of the backing store.
BUG=chromium:634269, v8:5162
R=cbruni@chromium.org, mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2209273002
Cr-Commit-Position: refs/heads/master@{#38344}
This adds the possibility to address test cases in the
status file with the variant under which the test is running.
This is only allowed in top-level sections.
Example:
[{
'test-case': [PASS, SLOW],
}]
['variant == foo', {
'test-case': [FAIL],
}]
The test case "test-case" is marked as slow in all variants.
Additionally, in variant foo, it'll be expected to fail.
This CL also exemplifies the new feature with test cases
running under the ignition_turbofan variant. The
corresponding legacy flag is deprecated.
BUG=v8:5238
Review-Url: https://codereview.chromium.org/2203013002
Cr-Commit-Position: refs/heads/master@{#38342}
This adds the missing lazy bailout point when defining accessor pairs
within object literals via Runtime::kDefineAccessorPropertyUnchecked.
The runtime function in question can indeed trigger a lazy deopt due
to a DependentCode::kPrototypeCheckGroup dependency.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-633585
BUG=chromium:633585
Review-Url: https://codereview.chromium.org/2207413002
Cr-Commit-Position: refs/heads/master@{#38336}
An infinite recursion can be triggered when NoSideEffectToString is
called on an error object with its name property set to itself.
BUG=633998
Review-Url: https://codereview.chromium.org/2206313002
Cr-Commit-Position: refs/heads/master@{#38325}
These tests all called assertUnreachable within a try/catch block.
BUG=v8:5246
Review-Url: https://codereview.chromium.org/2209663003
Cr-Commit-Position: refs/heads/master@{#38323}
Avoids compiling baseline code when the function isn't able to be
optimized by crankshaft.
BUG=chromium:632289
Review-Url: https://codereview.chromium.org/2194453002
Cr-Commit-Position: refs/heads/master@{#38304}
In the parser, we desugar yield* with the help of a regular yield. One
particular implementation detail of this desugaring is that when the user calls
the generator's throw method, this throws an exception that we immediately
catch. This exception should not be visible to the user, but through Devtools'
"Pause on Caught Exceptions" feature it used to be.
This CL extends the type of catch predictions with a new value for such internal
exceptions and uses that for the offending try-catch statement in yield*. It
instruments the debugger to _not_ trigger an exception event in that case.
R=yangguo@chromium.orgTBR=littledan@chromium.org
BUG=v8:5218
Review-Url: https://codereview.chromium.org/2203803002
Cr-Commit-Position: refs/heads/master@{#38286}
This was being allowed due to the use of BindingFlags instead of VariableMode
to determine whether a looked-up binding was lexical. Because function
declarations are hoisted, they never need hole checks, and so were being
miscategorized as non-lexical.
This patch augments Context::Lookup with a VariableMode out param, which
allows this check to determine precisely whether the binding is lexical.
BUG=v8:4454, v8:5256
Review-Url: https://codereview.chromium.org/2206483004
Cr-Commit-Position: refs/heads/master@{#38260}
Reason for revert:
Broke Node.js tests (test-require-dot etc.)
Original issue's description:
> Put Scopes into temporary Zone
>
> When parsing a eagerly-parsed-but-lazily-compiled function, we
> used to put some of its AST nodes into a discardable Zone. This
> CL puts the function Scope, its inner Scopes and the related AST
> nodes (Declarations, VariableProxys) into the temporary Zone
> too. This reduces peak memory usage and enables future work to
> keep the temporary Zone around for later compilation.
>
> BUG=
>
> Committed: https://crrev.com/eaebdd858b466057ccc39894a172c9b66868e8f7
> Cr-Commit-Position: refs/heads/master@{#38232}
TBR=adamk@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.chromium.org/2205013002
Cr-Commit-Position: refs/heads/master@{#38258}
We cannot just blindly make a representation selection for Phi or Select
based on the truncations, but we also need to consider the type of the
inputs (or actually of the Phi/Select node itself). We can only use
Word32 representation based on Word32 truncation if the inputs are
Number or Oddball, same for Float64.
R=epertoso@chromium.org
BUG=v8:5255
Review-Url: https://codereview.chromium.org/2206553002
Cr-Commit-Position: refs/heads/master@{#38241}
This type is not supposed to be constructable by users. Internally, we
use CallSiteUtils::Construct to create CallSite objects; and we simply
map a thrower builtin as the public CallSite constructor.
R=yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2201823002
Cr-Commit-Position: refs/heads/master@{#38234}
This makes sure we are not inserting {OsrPoll} instructions for any
statements that are not actually loops and have no back edges. Without
back edges the {BytecodeGraphBuilder} is unable to deduce loop ranges
and hence cannot construct a graph for OSR entry.
R=neis@chromium.org
TEST=mjsunit/regress/regress-5252
BUG=v8:5252
Review-Url: https://codereview.chromium.org/2200733002
Cr-Commit-Position: refs/heads/master@{#38233}
When parsing a eagerly-parsed-but-lazily-compiled function, we
used to put some of its AST nodes into a discardable Zone. This
CL puts the function Scope, its inner Scopes and the related AST
nodes (Declarations, VariableProxys) into the temporary Zone
too. This reduces peak memory usage and enables future work to
keep the temporary Zone around for later compilation.
BUG=
Review-Url: https://codereview.chromium.org/2193793002
Cr-Commit-Position: refs/heads/master@{#38232}
When we narrow a signed32 comparison to uint8 or uint16 representation,
we also need to change the condition to unsigned comparisons otherwise
the comparison will be done on int16/int8 which interprets the narrowed
bits wrong.
R=epertoso@chromium.org
BUG=v8:5254
Review-Url: https://codereview.chromium.org/2202803003
Cr-Commit-Position: refs/heads/master@{#38231}
The flag was introduced for ignition development. It can only
be used when running ignition tests in isolation on the bots.
The bots only use ignition_turbo in isolation since a while
and don't pass the --ignition flag anymore.
BUG=v8:5238
Review-Url: https://codereview.chromium.org/2197123002
Cr-Commit-Position: refs/heads/master@{#38206}
This CL fixes a long-standing bug with Object.keys where the enumerability
check was omitted if the [ownKeys] trap is not present. The only distinction the
KeyAccumulator needs is whether it collects keys for for-in (is_for_in_) or not.
ForInFilter performs a separate step to filter out non-enumerable keys later-on
while in all the other use-cases we have to filter keys.
BUG=v8:1543, v8:5250
Review-Url: https://codereview.chromium.org/2176113009
Cr-Commit-Position: refs/heads/master@{#38199}
This introduces a bunch of new tests that test various aspects of
accessor inlining in TurboFan (without the actual inlining), and does
the appropriate fixes to the AstGraphBuilder. The actual inlining CL
will land separately (so we don't need to revert the tests and fixes
if the accessor CL has to be reverted).
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2197913002
Cr-Commit-Position: refs/heads/master@{#38191}
Drive-by fix: actually match the hint in the IsSpeculativeBinopMatcher.
Review-Url: https://codereview.chromium.org/2191883002
Cr-Commit-Position: refs/heads/master@{#38176}
This adds preliminary support for on-stack replacement from Ignition to
optimized code generated by TurboFan to the runtime profiler. Involved
heuristics (e.g. code size allowance) have been taken from existing code
without any re-evaluation in the new setting.
R=rmcilroy@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2182183005
Cr-Commit-Position: refs/heads/master@{#38159}
Previously, the stack property was set up in JS as read-only; but since
it had a JS setter, writability was ignored and writing to stack was
possible.
This is no longer the case now that stack is either an actual data
property, or is associated with C++ accessors. Explicitly set the
property as writable to preserve old behavior.
BUG=5245
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2190313002
Cr-Commit-Position: refs/heads/master@{#38158}
In the process also inline the stub into the appropriate interpreter bytecode
handler and make sure that the context register is preserved in hand-written
assembly code that calls the stub and expects the context register to be
preserved.
BUG=608675
Review-Url: https://codereview.chromium.org/2188993003
Cr-Commit-Position: refs/heads/master@{#38132}
This patch updates internal data structures used by V8 to support
multiple indirect function tables (WebAssembly/design#682). But, since
this feature is post-MVP, the functionality is not directly exposed and
parsing/generation of WebAssembly is left unchanged. Nevertheless, it
is being used in an experiment to implement fine-grained control flow
integrity based on C/C++ types.
BUG=
Review-Url: https://codereview.chromium.org/2174123002
Cr-Commit-Position: refs/heads/master@{#38110}
Objects that reside below the age mark could be on pages that have been moved
within new space. In this case mementos survived which can actually point to
already-collected allocation sites.
BUG=chromium:631050,chromium:581412
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2179033005
Cr-Commit-Position: refs/heads/master@{#38094}
This required the introduction of the CheckedNumberOrOddballAsWord32 use info, and a change in the RepresentationChanger to handle it.
BUG=
Review-Url: https://codereview.chromium.org/2184513003
Cr-Commit-Position: refs/heads/master@{#38086}
Reason for revert:
Fix has been landed.
Original issue's description:
> Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ )
>
> Reason for revert:
> Bunch of breakages. Maybe bad interaction with e520e5da55 ?
>
> E.g.:
> https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607
>
> Original issue's description:
> > [interpreter] Add explicit OSR polling bytecode.
> >
> > This adds an explicit {OsrPoll} bytecode into every loop header which
> > triggers on-stack replacement when armed. Note that each such bytecode
> > stores the static loop depths as an operand, and hence can be armed for
> > specific loop depths.
> >
> > This also adds builtin code that triggers OSR compilation and switches
> > execution over to optimized code in case compilation succeeds. In case
> > compilation fails, the bytecode dispatch just continues unhindered.
> >
> > R=rmcilroy@chromium.org
> > TEST=mjsunit/ignition/osr-from-bytecode
> > BUG=v8:4764
> >
> > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458
> > Cr-Commit-Position: refs/heads/master@{#38043}
>
> TBR=rmcilroy@chromium.org,mstarzinger@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4764
>
> Committed: https://crrev.com/439aa2c6d708bfd95db725bd6f97c4c49bbc51fc
> Cr-Commit-Position: refs/heads/master@{#38044}
TBR=rmcilroy@chromium.org,machenbach@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2184713002
Cr-Commit-Position: refs/heads/master@{#38056}
Reason for revert:
Bunch of breakages. Maybe bad interaction with e520e5da55 ?
E.g.:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607
Original issue's description:
> [interpreter] Add explicit OSR polling bytecode.
>
> This adds an explicit {OsrPoll} bytecode into every loop header which
> triggers on-stack replacement when armed. Note that each such bytecode
> stores the static loop depths as an operand, and hence can be armed for
> specific loop depths.
>
> This also adds builtin code that triggers OSR compilation and switches
> execution over to optimized code in case compilation succeeds. In case
> compilation fails, the bytecode dispatch just continues unhindered.
>
> R=rmcilroy@chromium.org
> TEST=mjsunit/ignition/osr-from-bytecode
> BUG=v8:4764
>
> Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458
> Cr-Commit-Position: refs/heads/master@{#38043}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2184553003
Cr-Commit-Position: refs/heads/master@{#38044}
This adds an explicit {OsrPoll} bytecode into every loop header which
triggers on-stack replacement when armed. Note that each such bytecode
stores the static loop depths as an operand, and hence can be armed for
specific loop depths.
This also adds builtin code that triggers OSR compilation and switches
execution over to optimized code in case compilation succeeds. In case
compilation fails, the bytecode dispatch just continues unhindered.
R=rmcilroy@chromium.org
TEST=mjsunit/ignition/osr-from-bytecode
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2172233002
Cr-Commit-Position: refs/heads/master@{#38043}
When we eliminate nodes during truncation analysis that have no value
uses, we must make sure that we do not eliminate speculative number
operations that would have side effects depending on the inputs, i.e.
for example a SpeculativeNumberMultiply(x,y) does ToNumber(x) and
ToNumber(y) first, so if either x or y could throw an exception during
ToNumber conversion, we must not eliminate the multiplication, even if
it has no value uses (some later pass may kill the actual machine
multiplication, but the checks on the inputs have to remain still).
So we check whether both x and y are PlainPrimitive, i.e. neither
Receiver nor Symbol, which could raise exceptions for ToNumber, and
only in that case we propagate the "unusedness" of the node to its
inputs.
This also uncovered a bug with the type of Dead, which must be None,
as this represents an impossible value, so we had to fix that too.
Also the dead code removal will not work correctly for constants (i.e.
pure nodes with no value inputs), as those might be cached and hence
we might resurrect them for an unrelated node lowering during
SimplifiedLowering and only later kill the actual node (replacing its
uses with Dead), which would then also replace the new use with Dead.
So that was fixed as well. This shouldn't change anything for the
result, as unused constants automagically disappear from the graph later
on anyways.
R=yangguo@chromium.org
BUG=chromium:631318
Review-Url: https://codereview.chromium.org/2182003002
Cr-Commit-Position: refs/heads/master@{#38038}
After multiplying two integers we emit code like:
if (result == 0) {
if (OR_OPERATION(rhs, lhs) < 0) {
DEOPT;
}
}
This CL allows us to eliminate the OR and comparison if either rhs or
lhs is a negative number, reducing the code to:
if (result == 0) DEOPT;
BUG=
Review-Url: https://codereview.chromium.org/2167643002
Cr-Commit-Position: refs/heads/master@{#38016}
Introducing machine operators early causes trouble for the typing,
truncation analysis and representation selection, so we should rather
stick to simplified operators instead. Now there's only the for-in case
left, which is not clear how we can handle this in a better way.
Drive-by-fix: Also don't introduce Int32Constant and Word32Shl in
JSTypedLowering, but use NumberConstant and proper NumberShiftLeft
operators instead.
R=jarin@chromium.org
BUG=chromium:630951
Review-Url: https://codereview.chromium.org/2182453002
Cr-Commit-Position: refs/heads/master@{#38008}
The dead code elimination in SimplifiedLowering can eliminate pure nodes
if they don't have value uses. But some of those can indeed have control
inputs, i.e. Phi nodes do of course have a control input.
R=jarin@chromium.org
BUG=chromium:630923
Review-Url: https://codereview.chromium.org/2177133002
Cr-Commit-Position: refs/heads/master@{#37995}
In PrependElementIndicesImpl we sort a FixedArray of indices potentially
containing HeapNumbers. During the string conversion we might trigger a GC.
This in turn might try to read a slot where we previously had a HeapNumber
but the sort sneaked a SMI in there which is not a valid pointer.
BUG=chromium:630561
Review-Url: https://codereview.chromium.org/2173653003
Cr-Commit-Position: refs/heads/master@{#37993}
This allows us to skip complicated logic for setting the accessors.
BUG=
Review-Url: https://codereview.chromium.org/2164903004
Cr-Commit-Position: refs/heads/master@{#37969}
This is in preparation to implementing exception prediction for async
functions. Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.
To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.
The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.
BUG=v8:5167
Review-Url: https://codereview.chromium.org/2161263003
Cr-Commit-Position: refs/heads/master@{#37966}
See discussion in https://codereview.chromium.org/2156303002/#msg8
With the new --harmony-function-tostring behavior, these tests would
fail without this change. This change makes the tests pass regardless
of whether or not --harmony-function-tostring is used.
All of these changes are simply inserting a space after the "function"
keyword to match the current function toString behavior. When
--harmony-function-tostring is enabled, the toString behavior matches
the spacing used in the function declaration. With the declaration
matching the current formatting, the toString behavior becomes
unaffected by --harmony-function-tostring.
BUG=v8:4958
LOG=n
Review-Url: https://codereview.chromium.org/2161413002
Cr-Commit-Position: refs/heads/master@{#37959}
This cl also fixes two bugs in the previous code:
1) JITed functions were not allowed access to the heap because the module instance wasn't correctly synthesized. This wasn't discovered in the previous test.
2) Decoding of functions with the JITSingleFunction opcode was off by 1 as the length of the opcode wasn't computed correctly.
BUG=5044
Review-Url: https://codereview.chromium.org/2168183002
Cr-Commit-Position: refs/heads/master@{#37957}
Use the ForInFilterStub directly. Hence we will only jump to the runtime for
special receivers (instance_type <= LAST_SPECIAL_RECEIVER_TYPE) and for
converting element indices which are not in the string cache.
BUG=
Review-Url: https://codereview.chromium.org/2151773002
Cr-Commit-Position: refs/heads/master@{#37934}
The optimizing compilers actually invoke %TransitionElementsKind for
any kind of JSObject, the only relevant thing is the elements kind.
The runtime function was however checking for JSArray unnecessarily.
This only worked by coincindence in Crankshaft because the stub would
normally not call into the runtime fallback.
R=jarin@chromium.org
BUG=chromium:629823
Review-Url: https://codereview.chromium.org/2166963004
Cr-Commit-Position: refs/heads/master@{#37919}
This CL more or less reverts commit https://codereview.chromium.org/2107733002/
The use of the MathPow code stub that was introduced by that commit caused
problems on arm64, and the MathPow code stub was also an obstacle in the
implementation of parallel code generation.
In addition this CL turns on the mjsunit/wasm/embenchen tests for arm64
which were turned off because of problems with MathPow on arm64.
R=titzer@chromium.org, bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2166793002
Cr-Commit-Position: refs/heads/master@{#37911}
As required by the spec.
This is a variant of what I reverted in f47e722403.
It will probably still cause a regression but now it's easier to migrate (parts of)
the current implementation to C++, which is expected to make things faster again.
BUG=chromium:627729,v8:5113
Review-Url: https://codereview.chromium.org/2164923002
Cr-Commit-Position: refs/heads/master@{#37897}
This ports a large portion of Error methods to C++,
including the constructor, stack setter and getter,
and Error.prototype.toString.
BUG=
Review-Url: https://codereview.chromium.org/2142933003
Cr-Commit-Position: refs/heads/master@{#37870}
We need to pay attention to potential side effects from parameter
evaluation when inlining the fast case Array.prototype.shift.
R=yangguo@chromium.org
BUG=chromium:614644
Review-Url: https://codereview.chromium.org/2161943002
Cr-Commit-Position: refs/heads/master@{#37850}
Original issue's description:
> Don't compile functions in a context the caller doesn't have access to
>
> Instead just return undefined
>
> A side effect of this is that it's no longer possible to compile
> functions in a detached context.
>
> BUG=chromium:541703
> R=verwaest@chromium.org,bmeurer@chromium.org
BUG=chromium:541703
R=verwaest@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.chromium.org/2155503004
Cr-Commit-Position: refs/heads/master@{#37842}
The bug occurs because we do not canonicalize character class ranges
before adding case equivalents. While adding case equivalents, we abort
early for one-byte subject strings, assuming that the ranges are sorted.
Which they are not.
R=marja@chromium.org
BUG=v8:5199
Review-Url: https://codereview.chromium.org/2159683002
Cr-Commit-Position: refs/heads/master@{#37833}
This makes sure that we preserve call's tailness even if we have
introduced a loop exit between the call and the return.
BUG=chromium:628773
Review-Url: https://codereview.chromium.org/2155123002
Cr-Commit-Position: refs/heads/master@{#37832}
In int32 multiplication, if we have a positive integer as input, then we know we can't produce a -0 answer. The same is true if truncation is applied (x * y | 0). Without this information, we have to rather annoyingly check if the result of multiplication is 0, then OR the inputs to check for negativity, and possibly return -0. In TurboFan, we'll deopt in this case.
BUG=
Review-Url: https://codereview.chromium.org/2154073002
Cr-Commit-Position: refs/heads/master@{#37831}
This fixes the deoptimization information for the lazy bailout point
after a [[ToObject]] operation inserted for with statements. The result
value was pushed on the operand stack but erroneously ignored and left
on the operand stack by the FullCodeGenerator.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-5205
BUG=v8:5205
Review-Url: https://codereview.chromium.org/2158443002
Cr-Commit-Position: refs/heads/master@{#37818}
Delaying for merges caused branch cloning using dummy effect phi inputs,
potentially splitting the effect chain at start.
We still have to delay the creation for loops because we need to break
cycles.
BUG=chromium:628403
Review-Url: https://codereview.chromium.org/2159603002
Cr-Commit-Position: refs/heads/master@{#37808}
This reverts commit 457c02573c because it caused a
regression in SunSpider/string-fasta and possibly AreWeFastYet/Life. Need to
implement this in a smarter way.
TBR=littledan@chromium.org
BUG=chromium:627729,v8:5113
Review-Url: https://codereview.chromium.org/2149303003
Cr-Commit-Position: refs/heads/master@{#37793}
This makes sure that the uses of PlainPrimitiveToNumber get a more
precise type (so that the uses know how to interpret the output
representation).
BUG=chromium:628516
Review-Url: https://codereview.chromium.org/2151223002
Cr-Commit-Position: refs/heads/master@{#37792}
- Add Simd128 type to Wasm AST types
- Add a pass that converts SIMD machine ops to runtime calls
- Sample opcodes Int32x4Splat, Int32x4ExtractLane and test
- Separate out generic SIMD Machine ops as these cannot be
handled by runtime functions just yet.
LOG=N
BUG=v8:4124
R=bradnelson@chromium.org, bbudge@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/1991143002
Cr-Commit-Position: refs/heads/master@{#37789}
Annex B.3.3 of the spec requires that sloppy-mode block-scoped functions
declared by "eval" are hoisted unless doing so would cause an early
error (which is to say, conflict with a lexical declaration). This patch
amends the check for conflicting declarations to include those outside
of the eval itself.
BUG=v8:4468, v8:4479
Review-Url: https://codereview.chromium.org/2112163002
Cr-Commit-Position: refs/heads/master@{#37783}
Instead of unconditionally parsing the catch parameter as an expression
and then recovering if it turns out to be a simple variable proxy
(the overwhelmingly common case), this patch peeks one token ahead
before attempting to parse. This avoids doing the usual RemoveUnresolved
gymnastics in ParseTryStatement, and as a side-effect slightly improves
function name inference for an async arrow function test case.
Review-Url: https://codereview.chromium.org/2151433005
Cr-Commit-Position: refs/heads/master@{#37780}
Implemented the WebAssembly.Module and WebAssembly.Instance
in terms of the WasmModule::CompileFunctions and
WasmModule::Instantiate APIs.
Added negative tests - for invalid module object.
BUG=
Review-Url: https://codereview.chromium.org/2121593002
Cr-Commit-Position: refs/heads/master@{#37775}
Typed lowering now produces SpeculativeNumberShiftLeft for JSShiftLeft if the type feedback is kSignedSmall or kSigned32.
BUG=v8:4583
LOG=n
Review-Url: https://codereview.chromium.org/2150553002
Cr-Commit-Position: refs/heads/master@{#37762}
Reason for revert:
blink is unhappy about the microtask change
Original issue's description:
> Reland "Don't compile functions in a context the caller doesn't have access to"
>
> Original issue's description:
> > Don't compile functions in a context the caller doesn't have access to
> >
> > Instead just return undefined
> >
> > A side effect of this is that it's no longer possible to compile
> > functions in a detached context.
> >
> > BUG=chromium:541703
> > R=verwaest@chromium.org,bmeurer@chromium.org
>
> BUG=chromium:541703
> R=verwaest@chromium.org
>
> Committed: https://crrev.com/6bceabac5b705b2ce1f52d34650cea1ae3b8c617
> Cr-Commit-Position: refs/heads/master@{#37756}
TBR=verwaest@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:541703
Review-Url: https://codereview.chromium.org/2151843002
Cr-Commit-Position: refs/heads/master@{#37760}
Using the Hydrogen code stub bailout mechanism is not correct for the
string length overflow check in the StringAddStub. Instead make sure we
just throw the proper exception.
R=mstarzinger@chromium.org
BUG=chromium:627934
Review-Url: https://codereview.chromium.org/2146353002
Cr-Commit-Position: refs/heads/master@{#37758}
This adds a missing conversion of time zone names to string primitives
before case conversion and regular expression matching are applied.
This is in sync with ECMA-402, section 12.1.1.1, step 16(a).
R=jochen@chromium.org
TEST=mjsunit/regress/regress-crbug-627935
BUG=chromium:627935
Review-Url: https://codereview.chromium.org/2143003005
Cr-Commit-Position: refs/heads/master@{#37757}
Original issue's description:
> Don't compile functions in a context the caller doesn't have access to
>
> Instead just return undefined
>
> A side effect of this is that it's no longer possible to compile
> functions in a detached context.
>
> BUG=chromium:541703
> R=verwaest@chromium.org,bmeurer@chromium.org
BUG=chromium:541703
R=verwaest@chromium.org
Review-Url: https://codereview.chromium.org/2143893005
Cr-Commit-Position: refs/heads/master@{#37756}
Reason for revert:
Causes crashes on Canary
Original issue's description:
> Don't compile functions in a context the caller doesn't have access to
>
> Instead just return undefined
>
> A side effect of this is that it's no longer possible to compile
> functions in a detached context.
>
> BUG=chromium:541703
> R=verwaest@chromium.org,bmeurer@chromium.org
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng
>
> Committed: https://crrev.com/992e34c21635b179a993b82ac1d81753e7a6a57a
> Cr-Commit-Position: refs/heads/master@{#37657}
TBR=bmeurer@chromium.org,verwaest@chromium.org,jochen@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:541703, chromium:628053
Review-Url: https://codereview.chromium.org/2148163002
Cr-Commit-Position: refs/heads/master@{#37736}
The runtime JIT function is passed in the function table to hook up the compiled code and the starting address of the memory to locate the bytes to be compiled.
BUG=5044
Review-Url: https://codereview.chromium.org/2137993003
Cr-Commit-Position: refs/heads/master@{#37735}
Reason for revert:
Correcting issue.
Original issue's description:
> Revert of Add errors for declarations which conflict with catch parameters. (patchset #6 id:100001 of https://codereview.chromium.org/2109733003/ )
>
> Reason for revert:
> Fuzzer claims `try { \"\" ; } catch(x) { let x1 = [1,,], x = x; }` causes a crash.
>
> Original issue's description:
> > Add errors for declarations which conflict with catch parameters.
> >
> > Catch parameters are largely treated as lexical declarations in the
> > block which contains their body for the purposes of early syntax errors,
> > with some exceptions outlined in B.3.5. This patch introduces most of
> > those errors, except those from `eval('for (var e of ...);')` inside of
> > a catch with a simple parameter named 'e'.
> >
> > Note that annex B.3.5 allows var declarations to conflict with simple
> > catch parameters, except when the variable declaration is the init of a
> > for-of statement.
> >
> > BUG=v8:5112,v8:4231
> >
> > Committed: https://crrev.com/2907c726b2bb5cf20b2bec639ca9e6a521585406
> > Cr-Commit-Position: refs/heads/master@{#37462}
>
> TBR=littledan@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:5112,v8:4231
>
> Committed: https://crrev.com/8834d5ecb559001c87c42322969471da60574a8c
> Cr-Commit-Position: refs/heads/master@{#37464}
R=littledan@chromium.org
BUG=v8:5112,v8:4231
Review-Url: https://codereview.chromium.org/2119933002
Cr-Commit-Position: refs/heads/master@{#37728}
* Rename Atomics.futexWait -> Atomics.wait
* Rename Atomics.futexWake -> Atomics.wake
* Remove Atomics.futexWakeOrRequeue
* Return value of Atomics.wait is now a string: "ok", "not-equal" or
"timed-out"
* Update comments that reference URL for ecmascript_sharedmem to
https://github.com/tc39/ecmascript_sharedmem
Review-Url: https://codereview.chromium.org/2143443002
Cr-Commit-Position: refs/heads/master@{#37727}
This fixes the deoptimization information for the lazy bailout point
after a [[ToName]] operation inserted for object literals and class
literals. The result value was erroneously ignored.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-627828
BUG=chromium:627828
Review-Url: https://codereview.chromium.org/2149493003
Cr-Commit-Position: refs/heads/master@{#37719}
This fully deprecates all uses of the RUNTIME_ASSERT macro and removes
the macro and underlying logging function in question. All uses have
been replaces with CHECK macros which crash safely even in production.
It makes sure we discover abuse of runtime functions in the wild early
and also abort the process safely. Breaking assumptions in any runtime
function can no longer accidentally be caught by JavaScript.
R=yangguo@chromium.org
BUG=v8:5066
Review-Url: https://codereview.chromium.org/2132493002
Cr-Commit-Position: refs/heads/master@{#37704}
This makes sure the {AstGraphBuilder} respects the catch-prediction that
is provided by the parser along with each {TryStatement}. This is needed
for try-blocks materialized by the parser not to influence predictions
users expect when using the debugger.
R=neis@chromium.org
TEST=mjsunit/debug-exceptions
BUG=v8:5183
Review-Url: https://codereview.chromium.org/2147573002
Cr-Commit-Position: refs/heads/master@{#37702}
Collect type feedback in the call bytecode handler. The current
implementation only collects feedback for JS function objects. The other
objects and Array functions do not collect any feedback. They will be
marked Megamorphic.
BUG=v8:4280, v8:4780
LOG=N
Review-Url: https://codereview.chromium.org/2122183002
Cr-Commit-Position: refs/heads/master@{#37700}
This solves an issue with throws inside for-of always being marked as caught.
BUG=v8:5183
Review-Url: https://codereview.chromium.org/2146493002
Cr-Commit-Position: refs/heads/master@{#37686}
- check that packed elements do not contain the_hole (with fix)
- verify argument objects with elements kind
- use JSObjectVerifiy in all JSObject "subclasses"
- change initialization order for ArrayLiteralBoilerplate to simplify verification
BUG=v8:5188
Review-Url: https://codereview.chromium.org/2126613002
Cr-Commit-Position: refs/heads/master@{#37680}
This removes the checking for use-def and def-use chain links from the
graph verification. Presence of such links can only be violated by a bug
in the actual {Node} implementation itself. That container class is also
covered by unit tests.
The verification in question was useful in the early days when the graph
implementation itself was prone to bugs. By now it has stabilized and
spending O(n^2) time during graph verification is too wasteful to still
be considered a reasonable trade-off.
R=jarin@chromium.org
TEST=unittests/NodeTest.*
Review-Url: https://codereview.chromium.org/2140973003
Cr-Commit-Position: refs/heads/master@{#37670}
Remove obsolete definitions from macros.py, and drop the now obsolete
%_ToPrimitive, %_ToPrimitive_Number, %_ToPrimitive_String, %_ToName
and the %ToPrimitive_String intrinsics/runtime entries.
R=yangguo@chromium.org
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2137203002
Cr-Commit-Position: refs/heads/master@{#37665}
Instead just return undefined
A side effect of this is that it's no longer possible to compile
functions in a detached context.
BUG=chromium:541703
R=verwaest@chromium.org,bmeurer@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.chromium.org/2034083002
Cr-Commit-Position: refs/heads/master@{#37657}
This patch just checks for a stack overflow and returns failure
from the cases which Clusterfuzz found. However, there may be
more locations in the parser which need similar treatment.
R=caitpotter88@gmail.com,neis
BUG=v8:4483,chromium:624300
Review-Url: https://codereview.chromium.org/2135503002
Cr-Commit-Position: refs/heads/master@{#37655}
CallSite::IsConstructor() was unable to recognize builtin construct stubs
(NumberConstructor_ConstructStub and StringConstructor_ConstructStub) as
constructors, and thus these frames were not formatted correctly in stack
traces.
Fix this by explicitly marking their Code objects as construct stubs and
passing along a special receiver value when we encounter such cases in
CaptureSimpleStackTrace.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2125163004
Cr-Commit-Position: refs/heads/master@{#37631}
This enables tests which rely on the context available at "debugger"
statements to be accurate. This is the case by now when deoptimization
information is available.
R=yangguo@chromium.org
BUG=v8:4055
Review URL: https://codereview.chromium.org/2129123002 .
Cr-Commit-Position: refs/heads/master@{#37604}
Drive-by-fix: hydrogen code does not blindly return the
byteLength offset, instead it executes what is defined
in the byteLength getter.
BUG=
Review-Url: https://codereview.chromium.org/2123263002
Cr-Commit-Position: refs/heads/master@{#37595}
This enables tests which rely on the context available at "debugger"
statements to be accurate. This is the case by now when deoptimization
information is available.
R=mvstanton@chromium.org
BUG=v8:4035
Review-Url: https://codereview.chromium.org/2125773005
Cr-Commit-Position: refs/heads/master@{#37590}
When reading the value property of an iterator result fails, we must not close the iterator.
This was not discovered earlier because the tests had a subtle bug.
This CL fixes both the desugaring and the tests.
BUG=
Review-Url: https://codereview.chromium.org/2119353002
Cr-Commit-Position: refs/heads/master@{#37571}
For variables introduced as part of a catch pattern, we used to set their
"initializer position" to the beginning of the pattern. This lead to
full-codegen eliminating crucial hole checks when reading such variables
inside the pattern itself.
R=adamk@chromium.org, littledan@chromium.org
BUG=v8:5178
Review-Url: https://codereview.chromium.org/2123953002
Cr-Commit-Position: refs/heads/master@{#37569}
While the test was useful to reproduce the issue locally it creates a lot of
heap pressure and causes all sorts of troubles (OOM, slowness) on the bots, so
let's drop it.
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2127803002
Cr-Commit-Position: refs/heads/master@{#37551}
This removes explicit uses of the RUNTIME_ASSERT macro from some runtime
methods. The implicit ones in CONVERT_FOO_ARG_CHECKED will be addressed
in a separate CL for all runtime modules at once.
R=yangguo@chromium.org
BUG=v8:5066
Review-Url: https://codereview.chromium.org/2053573004
Cr-Commit-Position: refs/heads/master@{#37545}
This is a quick fix for the hole leaking from generators via the debugger's frame
inspection feature: when collecting the arguments, convert each hole to undefined.
In the long term, we probably want to remember and restore the actual arguments
rather than pushing these dummy arguments on each resume.
BUG=v8:5164
Review-Url: https://codereview.chromium.org/2122923003
Cr-Commit-Position: refs/heads/master@{#37544}
