The shortcuts ensure that field type generalization is properly
propagated in the transition graph.
Bug: chromium:738763
Change-Id: Id701a6f95ed6ea093c707fbe0bac228f1f856e9f
Reviewed-on: https://chromium-review.googlesource.com/567992
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46622}
This correctly types values loaded via {LoadElement} nodes from arrays
of HOLEY_DOUBLE_ELEMENTS elements kind as {Type::NumberOrHole}. Even
though "the hole" is still encoded as a tagged NaN, the type system
still needs to consider it as a potential hole value.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-736575
BUG=chromium:736575
Change-Id: Ib869284900a4affb2ddaa1d2a96df9443dba6921
Reviewed-on: https://chromium-review.googlesource.com/567180
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46620}
Previously we enforced that all lengths for ArrayLike objects must
be within Smi range, but all negative numbers should actually be first
converted to +0.
Bug: chromium:740372
Change-Id: If50de9ce0eeb7cb09e14b8e8803f434350d00508
Reviewed-on: https://chromium-review.googlesource.com/566867
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46615}
Insertion into a collection changes the map because of the addition of
the hash value property. Check the root map, not the current map.
Fixes: https://github.com/nodejs/node/issues/14139
Change-Id: Iabcea5337323b9b6deffa1a06892c1cb749f2065
Reviewed-on: https://chromium-review.googlesource.com/566833
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46614}
Didn't seem to help and caused a couple of regressions.
BUG=v8:6243,chromium:740124
Change-Id: I72887ba245a524211dbf181c77d0cdc6d917d090
Reviewed-on: https://chromium-review.googlesource.com/568480
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46608}
When we abort preparsing, we have to reset the Scope state, to ensure
re-parsing will leave us in the proper Zone. Resetting of rare_data_
was missing, causing this to fail in some cases.
Bug: chromium:740803
Change-Id: I7ce70f9c4670eaf1b76745ae8231eb95625b0f4b
Reviewed-on: https://chromium-review.googlesource.com/568784
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46607}
By creating the boilerplate only on the second instantiation we cannot
propagate back the elements transitions early enough. The resulting literals
would change the initial ElementsKind one step too late and already pollute
ICs that went to monomorphic state.
- Disable lazy AllocationSites for literals containing arrays
- Introduce new ComplexLiteral class to share code between ObjectLiteral
and ArrayLiteral
- RegexpLiteral now no longer needs a depth_ field
Bug: v8:6517, v8:6519, v8:6211
Change-Id: Ia88d1878954e8895c3d00a7dda8d71e95bba005c
Reviewed-on: https://chromium-review.googlesource.com/563305
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46603}
This is a reland of f720d024dc
Original change's description:
> [mjsunit] Improve mjsunit stracktrace readability
>
> Format the function name and file-position into proper columns to easily spot
> where the test code ends and the mjsunit framework code starts.
>
> BEFORE:
> Stack: Error
> at new MjsUnitAssertionError (test/mjsunit/mjsunit.js:36:18)
> at failWithMessage (test/mjsunit/mjsunit.js:310:11)
> at fail (test/mjsunit/mjsunit.js:327:12)
> at assertEquals (test/mjsunit/mjsunit.js:398:7)
> at closure (test/mjsunit/regress/regress-4121.js:20:7)
> at literals_sharing_test (test/mjsunit/regress/regress-4121.js:27:3)
> at test (test/mjsunit/regress/regress-4121.js:37:5)
> at eval (eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6), <anonymous>:1:1)
> at test/mjsunit/regress/regress-4121.js:49:6
> at Array.forEach.call (test/mjsunit/regress/regress-4121.js:50:7)
> throw new MjsUnitAssertionError(message);
>
> AFTER:
> Stack: MjsUnitAssertionError
> at assertEquals test/mjsunit/mjsunit.js 398:7
> at closure test/mjsunit/regress/regress-4121.js 20:7
> at literals_sharing_test test/mjsunit/regress/regress-4121.js 27:3
> at test test/mjsunit/regress/regress-4121.js 37:5
> at eval eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6)
> at test/mjsunit/regress/regress-4121.js 49:6
> at Array.forEach.call test/mjsunit/regress/regress-4121.js 50:7
> throw new MjsUnitAssertionError(message);
>
>
> Change-Id: Iad3460a648e26effb43c00426ab043743ee6a138
> Reviewed-on: https://chromium-review.googlesource.com/563627
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46589}
Change-Id: I44bf07f7be4114369315605542cafd17345b4397
Reviewed-on: https://chromium-review.googlesource.com/567063
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46602}
JSFunction::SetName can fail if it tries to create a string with
length > String::kMaxLength (either by prepending "set "/"get " or
by surrounding a Symbol descriptor with "["/"]").
This patch propagates that exception to the surrounding code rather
than CHECK-failing.
Bug: chromium:740398
Change-Id: I394943af481f3147387dd82ec5862d7071d57827
Reviewed-on: https://chromium-review.googlesource.com/566092
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46601}
This makes it possible for automated tests to distinguish between CHECK
failures and DCHECK failures, the latter of which will continue to run
in release builds after the assertion failure point.
Change-Id: Ie26978c0342d401a8c85f3261749739195087579
Reviewed-on: https://chromium-review.googlesource.com/565515
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46596}
This reverts commit f720d024dc.
Reason for revert: Bot failure at
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20custom%20snapshot%20-%20debug/builds/15690
Original change's description:
> [mjsunit] Improve mjsunit stracktrace readability
>
> Format the function name and file-position into proper columns to easily spot
> where the test code ends and the mjsunit framework code starts.
>
> BEFORE:
> Stack: Error
> at new MjsUnitAssertionError (test/mjsunit/mjsunit.js:36:18)
> at failWithMessage (test/mjsunit/mjsunit.js:310:11)
> at fail (test/mjsunit/mjsunit.js:327:12)
> at assertEquals (test/mjsunit/mjsunit.js:398:7)
> at closure (test/mjsunit/regress/regress-4121.js:20:7)
> at literals_sharing_test (test/mjsunit/regress/regress-4121.js:27:3)
> at test (test/mjsunit/regress/regress-4121.js:37:5)
> at eval (eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6), <anonymous>:1:1)
> at test/mjsunit/regress/regress-4121.js:49:6
> at Array.forEach.call (test/mjsunit/regress/regress-4121.js:50:7)
> throw new MjsUnitAssertionError(message);
>
> AFTER:
> Stack: MjsUnitAssertionError
> at assertEquals test/mjsunit/mjsunit.js 398:7
> at closure test/mjsunit/regress/regress-4121.js 20:7
> at literals_sharing_test test/mjsunit/regress/regress-4121.js 27:3
> at test test/mjsunit/regress/regress-4121.js 37:5
> at eval eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6)
> at test/mjsunit/regress/regress-4121.js 49:6
> at Array.forEach.call test/mjsunit/regress/regress-4121.js 50:7
> throw new MjsUnitAssertionError(message);
>
>
> Change-Id: Iad3460a648e26effb43c00426ab043743ee6a138
> Reviewed-on: https://chromium-review.googlesource.com/563627
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46589}
TBR=machenbach@chromium.org,cbruni@chromium.org,ishell@chromium.org
Change-Id: I631cec7f318637ce2f60500e2bf0ab7fe1f6d09e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/567062
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46592}
This CL moves collected source range information out of AST nodes
and into a side table stored on ParseInfo. The side table is only
created if block coverage is enabled, so there's almost no memory
overhead in the standard case.
Change-Id: I41871b8425ebbc6217d82d3ad26b5fc9e5d68ecb
Reviewed-on: https://chromium-review.googlesource.com/566808
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46590}
Format the function name and file-position into proper columns to easily spot
where the test code ends and the mjsunit framework code starts.
BEFORE:
Stack: Error
at new MjsUnitAssertionError (test/mjsunit/mjsunit.js:36:18)
at failWithMessage (test/mjsunit/mjsunit.js:310:11)
at fail (test/mjsunit/mjsunit.js:327:12)
at assertEquals (test/mjsunit/mjsunit.js:398:7)
at closure (test/mjsunit/regress/regress-4121.js:20:7)
at literals_sharing_test (test/mjsunit/regress/regress-4121.js:27:3)
at test (test/mjsunit/regress/regress-4121.js:37:5)
at eval (eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6), <anonymous>:1:1)
at test/mjsunit/regress/regress-4121.js:49:6
at Array.forEach.call (test/mjsunit/regress/regress-4121.js:50:7)
throw new MjsUnitAssertionError(message);
AFTER:
Stack: MjsUnitAssertionError
at assertEquals test/mjsunit/mjsunit.js 398:7
at closure test/mjsunit/regress/regress-4121.js 20:7
at literals_sharing_test test/mjsunit/regress/regress-4121.js 27:3
at test test/mjsunit/regress/regress-4121.js 37:5
at eval eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6)
at test/mjsunit/regress/regress-4121.js 49:6
at Array.forEach.call test/mjsunit/regress/regress-4121.js 50:7
throw new MjsUnitAssertionError(message);
Change-Id: Iad3460a648e26effb43c00426ab043743ee6a138
Reviewed-on: https://chromium-review.googlesource.com/563627
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46589}
This patch teaches the parser that async functions are not valid
destructuring targets so that it can cleanly exit with a SyntaxError.
Previously, async functions used in the wrong position would lead
to a check failure.
Bug: chromium:740366
Change-Id: Ie5b0cf50326c3f96174c6b29d0ccedb5da4f75a2
Reviewed-on: https://chromium-review.googlesource.com/567002
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46587}
This makes sure the inline allocation of generator objects only shrinks
initial maps when slack tracking is actually in progress. Shrinking all
unused properties unconditionally is bogus because instances using them
might have become unreachable and collected by the GC.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-741078
BUG=chromium:741078
Change-Id: Iaf2f08a4fa82c820a945bf012d24c760a6b4f514
Reviewed-on: https://chromium-review.googlesource.com/567982
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46585}
In certain timezones, being at noon UTC doesn't guarantee that
you'll be the same day in local time. This patch fixes that
false assumption. Thanks to Holmes He for reporting the issue.
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I7432c0eb1e13fdf11c665e59dabaebeb79bff8c8
Reviewed-on: https://chromium-review.googlesource.com/568021
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46584}
This introduces 2^16 as an upper limit for the allowed value range of a
table switch on all architectures. It also fixes several overflows in
the table size calculation.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-736633
BUG=chromium:736633
Change-Id: I931bd226c99eb8a1ae1770c159fc314ff650bf57
Reviewed-on: https://chromium-review.googlesource.com/566829
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46575}
Previously (since f0e95769), this toLowerCase fast-path assumed
it would only see one-byte flat contents. Unfortunately, it's
possible to have a one-byte sliced string that has a two-byte parent.
This CL ensures that String.p.toLowerCase handles such cases
correctly.
BUG=chromium:736451
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Iae056b3db5535bb5665439a5cc8282a51571a548
Reviewed-on: https://chromium-review.googlesource.com/565559
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46574}
This patch changes the backing store of slow properties to be a
new instance type called PropertyArray.
Currently the only difference between this and a FixedArray is
the map. A future patch will change the length property to store
the hash code.
Bug: v8:5717, v8:6404
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iaebc98f42e6d93c1392772e6f837787beb64afec
Reviewed-on: https://chromium-review.googlesource.com/539028
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46569}
Otherwise user code can produce an exception and we will crash.
R=jakob@chromium.org
Bug: chromium:736302
Change-Id: I078150909b0348a63e8c375b508e34fc4751b4ab
Reviewed-on: https://chromium-review.googlesource.com/565628
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46566}
After compiling a function, check that validation produces the same
success/error result.
R=ahaas@chromium.org
Change-Id: I617881e125dccff485f5572557b19709de488d55
Reviewed-on: https://chromium-review.googlesource.com/565722
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46561}
This fixes the lowering of Reflect.getPrototypeOf and friends to not
perform a [[ToObject]] coercion, but bailout instead. We ensure to
exclude primitive values from the lowering. This makes the lowering
uniform between "Reflect.getPrototypeOf" and "Object.getPrototypeOf".
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-740116
BUG=chromium:740116
Change-Id: If986ee2a3ae4e8f1fd227bdeb4668f523b0dea84
Reviewed-on: https://chromium-review.googlesource.com/565295
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46556}
Each reducer now has a virtual reducer_name function, returning its name
(the name of the class containing this reducer). This gets displayed when
using the --trace_turbo_reduction flag. Also when using this flags more
messages are displayed.
Actually when a node is replaced in-place (which is called an update
of the node), other reducers can still update it right after the
in-place replacement. When a node is really replaced (not in-place),
then we stop trying to apply reducers to it before we propagate the
reduction through the relevant nodes.
Before a message got printed only for the last reduction it went
through. So in case a node was reduced in-place several times
in a row, only the last update was printed, or none at all if after
being reduced in-place it got reduced by being replaced by another
node: only the non-in-place replacement was showed.
Now each time an in-place reduction is applied to a node, a message
gets printed.
Bug:
Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa
Reviewed-on: https://chromium-review.googlesource.com/563365
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Alexandre Talon <alexandret@google.com>
Cr-Commit-Position: refs/heads/master@{#46552}
Switch statements generate a counter for each clause plus a continuation
counter.
Bug: v8:6000
Change-Id: Ic55a7efda54de1152bd5283d753119aa2764afbd
Reviewed-on: https://chromium-review.googlesource.com/558249
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46550}
- Implement js-api changes for WebAssembly.Memory to accept a shared parameter
- Update allocation to use SharedArrayBuffers
BUG=v8:6532
R=binji@chromium.org, bradnelson@chromium.org
Change-Id: I021491217568751b06fbd7b4b08b1dd88910e21d
Reviewed-on: https://chromium-review.googlesource.com/564058
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46543}
This is a reland of 5b44ba0e34
Original change's description:
> (Reland) [parser] moved load property position after dot
>
> Currently LdaNamedProperty bytecode for expressions like a.b has position before dot. This CL moves this location after dot.
> It's important for later removing of Nop bytecodes in expressions like a.b() where a is local variable, property call and property load should have the same position.
>
> R=jgruber@chromium.org
> TBR=marja@chromium.org
>
> Bug: v8:6425
> Change-Id: I05c21ca5e018da9c432c6bc963c7a96799336d1c
> Reviewed-on: https://chromium-review.googlesource.com/562879
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46484}
TBR=marja@chromium.org,jgruber@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Bug: v8:6425
Change-Id: I5eba5fe43ad31c5c781ffcc8c604cd9c98baa57e
Reviewed-on: https://chromium-review.googlesource.com/565907
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46542}
Adds missing opcodes for exception handling for the function body decoder.
Also adds error messages if the exception handling construct is not yet
functional.
Note that the previous prototype for catch and throw have been marked
as not yet functional. This was done because it doesn't model
exceptions the way the proposal suggests. Rather, they implement a
hard-coded (c++ model) of exceptions.
Bug: v8:6577
Change-Id: Ife170b9f0cb2be91b11082e43c4795ce81a427dc
Reviewed-on: https://chromium-review.googlesource.com/564138
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46540}
Modifies V8 to be able to parse the exception section (defining
exception types), when the experimental_wasm_eh flag is true.
Bug: v8:6577
Change-Id: I5d8b3fddaf5b0dec6b14ddd0992f9fb883e8dc90
Reviewed-on: https://chromium-review.googlesource.com/561757
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46539}
This improves the general Array constructor call performance (w/o
usable AllocationSite feedback) in TurboFan by ~2x, i.e. for example
invoking the Array constructor like this
var a = Array.call(undefined, n);
instead of
var a = Array(n);
such that the CallIC doesn't know that it's eventually calling the
Array constructor.
It also thus changes the single argument Array constructor to always
return holey arrays. Previously the single argument case for the Array
constructor was somehow trying to dynamically detect 0 and in that case
returned a packed array instead of a holey one. That adds quite a lot
of churn, and doesn't seem to be very useful, especially since this
might lead to unnecessary feedback pollution later.
R=mvstanton@chromium.org
Bug: v8:2229, v8:5269, v8:6399
Change-Id: I3d7cb9bd975ec0e491e3cdbcf1230185cfd1e3de
Reviewed-on: https://chromium-review.googlesource.com/565721
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46538}
It's already skipped (for slowness) in debug, asan, and msan builds.
TBR=machenbach@chromium.org
Change-Id: I1d7cb38d88e621f6d14344426bc5f931b1d6ffcd
Reviewed-on: https://chromium-review.googlesource.com/565741
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46537}
In https://chromium-review.googlesource.com/c/472247/, I avoided
running DesugarLexicalBindingsInForStatement() if there were no lexical
loop variables, the function was not resumable, and the variables are
not captured by eval or a function declaration.
I think it's now possible to limit this further, and only do the more
extensive desugaring if there's a function declaration / eval() call
in the loop body. `yield` and `await` are not an issue as those loop
variables are written to the register file and not lost.
This change just removes the `is_resumable()` condition. If it passes
tests, I think it's safe.
BUG=v8:4762, v8:5460, v8:6579
Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a
Reviewed-on: https://chromium-review.googlesource.com/563587
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46536}
This will allow for passing more than one variable. This is
particularly interesting for calling a method on each type in a
parameter pack, as in:
template<typename... T>
void foo(T&&... ts) {
USE(do_something(ts)...);
}
Drive-by fix: Allow to pass arbitrary types to USE, including
references. This might prevent a copy for pass-by-value.
R=ishell@chromium.org
Change-Id: I8f894d730bbcd195ed83705f98771994b4bc906f
Reviewed-on: https://chromium-review.googlesource.com/565561
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46527}
This adds a convenience method for the common Smi to int conversion
pattern.
Bug:
Change-Id: I7d7b171c36cfec5f6d10c60f1d9c3e06e3aed0fa
Reviewed-on: https://chromium-review.googlesource.com/563205
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46516}
An invalid I32V value as index could be used to get a valid
WasmFunction.
R=clemensh@chromium.org
Bug: chromium:735887
Change-Id: I5fbfa01fc3300d86a4a2ba9bcbb86fc02f231ef9
Reviewed-on: https://chromium-review.googlesource.com/561536
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46504}
There are other things to export beside functions. Thus, also print the
export kind when printing an error for duplicate export names.
R=titzer@chromium.org
Change-Id: I7477040dda274a16cfd776d7ac8db6e50a197b97
Reviewed-on: https://chromium-review.googlesource.com/564940
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46503}
... according to the spec ES#sec-%throwtypeerror%
Bug: v8:4034
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ia4f2d228397edf55447fe3e71402c8fc4589369a
Reviewed-on: https://chromium-review.googlesource.com/563214
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46498}
This is the next step towards faster Map and Set iteration. It
introduces the appropriate instance types for Map and Set
iterators (following the pattern for Array iterators) and migrates
the following builtins to the CodeStubAssembler:
- Set.prototype.entries
- Set.prototype.values
- Map.prototype.entries
- Map.prototype.keys
- Map.prototype.values
- %SetIteratorPrototype%.next
- %MapIteratorPrototype%.next
This already provides a significant performance boost for regular
for-of iteration of Sets and Maps, by a factor of 5-10 depending
on the input. The final step will be to inline some fast-paths
into TurboFan.
Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
intrinsics and runtime functions.
TBR=jgruber@chromium.org
Bug: v8:6344, v8:6571, chromium:740122
Change-Id: I3ab0ee49e2afe8d4295707a5ecbd51adda621918
Reviewed-on: https://chromium-review.googlesource.com/563626
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46497}
This reverts commit 5b44ba0e34.
Reason for revert: Layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16841
Original change's description:
> (Reland) [parser] moved load property position after dot
>
> Currently LdaNamedProperty bytecode for expressions like a.b has position before dot. This CL moves this location after dot.
> It's important for later removing of Nop bytecodes in expressions like a.b() where a is local variable, property call and property load should have the same position.
>
> R=jgruber@chromium.org
> TBR=marja@chromium.org
>
> Bug: v8:6425
> Change-Id: I05c21ca5e018da9c432c6bc963c7a96799336d1c
> Reviewed-on: https://chromium-review.googlesource.com/562879
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46484}
TBR=kozyatinskiy@chromium.org,jgruber@chromium.org
Change-Id: If9d5fa5f46ed10a407559e9cf10d2a6a54dbe163
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6425
Reviewed-on: https://chromium-review.googlesource.com/564418
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46491}
BUG=v8:6231
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I326ace8ee27e5347d26bae11b8061f4fe524db53
Reviewed-on: https://chromium-review.googlesource.com/562744
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46488}
... but use proper map for functions with readonly prototype from the start.
Bug: v8:6459
Change-Id: I432d4969822e7cc4c2ba83e103f550d1c4f2e234
Reviewed-on: https://chromium-review.googlesource.com/563199
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46487}
Currently LdaNamedProperty bytecode for expressions like a.b has position before dot. This CL moves this location after dot.
It's important for later removing of Nop bytecodes in expressions like a.b() where a is local variable, property call and property load should have the same position.
R=jgruber@chromium.orgTBR=marja@chromium.org
Bug: v8:6425
Change-Id: I05c21ca5e018da9c432c6bc963c7a96799336d1c
Reviewed-on: https://chromium-review.googlesource.com/562879
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46484}
This CL refactors the WasmMemoryObject and WasmInstanceObject classes to
use WeakFixedArray instead of using a doubly-linked list of instances. This
simplifies the lifetime management of instances by not requiring them to
be unlinked from this list upon GC. It also simplifies the iteration over
the instances using a given WasmMemoryObject.
Note that, contrary to my naive assumption at the outset, it is still necessary for the InstanceFinalizer (called upon a WasmInstanceObject death) to unlink itself from a WasmMemoryObject's instances list, due to finalizer ordering.
R=deepti@chromium.org, mlippautz@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2972803002
Cr-Commit-Position: refs/heads/master@{#46482}
This adds support for exception control flow by adding a counter behind throw
statements (never incremented), as well as a counter for catch and finally
blocks.
Bug: v8:6000
Change-Id: I3959772c889b543ab5e186ad7cd710e55a8aec23
Reviewed-on: https://chromium-review.googlesource.com/558993
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46476}
This CL refactors the internal representation of JavaScript-exposed
WebAssembly objects to be more like other such objects in V8. By introducing
a new instance type for each of the JS-exposed types, we get more robust
typechecking without using embedder fields (which were previously used
when these objects where instance type JS_API_OBJECT).
In addition to the new instance types, the subclasses X of JSObject
(WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
now have appropriate Is##X() methods on Object and are now robust.
BUG=v8:6547
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.chromium.org/2964943002
Cr-Commit-Position: refs/heads/master@{#46475}
This CL changes for floats what https://chromium-review.googlesource.com/c/558964/
changed for doubles.
Original message:
On x86, signalling NaNs get converted to quiet NaNs when they get push
on the stack and popped again. This happens in the code generation for
arm, specifically for the vmov instruction with the immediate parameter.
This CL replaces the vmov function in assembler-arm to take the
immediate as a uint64_t instead of a double, to guarantee that the bit
pattern does not change even if the parameter is a signalling NaN.
New in this CL:
Although src/double.h existed already, src/float.h did not exist yet.
I created the file in this CL, and moved the classes Float32 and
Float64 there, which already existed in src/deoptimizer.h.
R=titzer@chromium.org, martyn.capewell@arm.com, v8-arm-ports@googlegroups.com
BUG=v8:6564
Change-Id: I6a3f1f154af9c8cd4bb8e7e856235d3eee5e9edd
Reviewed-on: https://chromium-review.googlesource.com/561009
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46473}
This CL contains new created tests for instructions INS and EXT.
TEST=cctest/test-assembler-mips[64]/Ins,
cctest/test-assembler-mips[64]/Ext
BUG=
Change-Id: Ie62037ee425a5cba3700c5025608fdada144add5
Reviewed-on: https://chromium-review.googlesource.com/561319
Commit-Queue: Miran Karić <Miran.Karic@imgtec.com>
Reviewed-by: Miran Karić <Miran.Karic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46468}
Blink needs %ErrorPrototype% in order to properly set up the inheritance
chain from DOMException, as specified in WebIDL:
https://heycam.github.io/webidl/#es-DOMException-specialness
This patch is similar to commit 5ec1cddcd ("Expose %IteratorPrototype% as an
intrinsic in the public API"), with the difference that there was no entry
for %ErrorPrototype% in any of the mappings in contexts.h.
Bug: chromium:556950, chromium:737497
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iadc5b2b844f29f6c9640b6a89769d233931366e9
Reviewed-on: https://chromium-review.googlesource.com/559058
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#46464}
This adds a new binary block coverage mode (in addition to the existing count
block coverage), as well as a few transformation passes to reduce the number of
uselessly reported ranges.
Bug: v8:6000
Change-Id: I4fb234ca015990d00aa2f1dccb87f76ba4748994
Reviewed-on: https://chromium-review.googlesource.com/552642
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46463}
Adds constant folding for the StringConcat bytecode to
NativeContextSpecialization. Can reduce operator to either a fully folded
constant string, or a JSAdd or a StringConcat with a reduced number of
operators.
BUG=v8:6243, chromium:738312
Change-Id: I6b2be6a3d95230a23f3c7390a4f7be5181c49a2a
Reviewed-on: https://chromium-review.googlesource.com/559146
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46461}
If a thin string can be dereferenced for StringConcat we still need to check
whether the dereferenced string is a sequential string itself (it could be
an external string).
BUG=v8:6243
Change-Id: I146541512525726f092580512c0b5f02d33685a7
Reviewed-on: https://chromium-review.googlesource.com/558994
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46459}
Print the object that is being destructured and update the error
message.
Previously,
d8> var [a] = {}
(d8):1: TypeError: [Symbol.iterator] is not a function
Now,
d8> var [a] = {}
(d8):1: TypeError: {} is not iterable
Bug: v8:6513, v8:5532
Change-Id: I5cbfe7c7e20632bce1a48bd38a1b0c98d0ff0660
Reviewed-on: https://chromium-review.googlesource.com/557370
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46457}
The ')'-in-parameter checking is not necessary for
CompileFunctionInContext. The arguments array is expected to be an
array of identifiers, not an array of arbitrary strings that get
concatenated.
Furthermore, there's no reason to have the .toString() representation
look like it came from CreateDynamicFunction(), and in fact inserting
line breaks makes it more complicated to map line and column numbers
correctly.
Overall, the --harmony-function-tostring behavior only makes
CompileFunctionInContext worse, so this CL removes it.
R=littledan@chromium.org, adamk@chromium.org, caitp@igalia.com
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Bug: v8:4958
Change-Id: Ifbc8a83216ca6a6979da1199972aa65f4bee36c3
Reviewed-on: https://chromium-review.googlesource.com/558220
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Josh Wolfe <jwolfe@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46456}
Tsan figured out that I called compilation_units_.empty() outside a
lock.
Original message:
This CL adds a new function {InitializeCompilationUnit} to initialize
a single compilation unit and not just all compilation units at once.
This is necessary for streaming compilation eventually. This also
required some refactoring on how the working queue for compilation units
works. Previously the synchronization was done with an atomic counter,
now it is done with a lock. Note that the code to finish compilation
of a module still only works if the working queue gets only empty when
all work is done. I plan to change this in a different CL.
Since the code would not be tested without streaming compilation, I added
an experimental flag and a test to test the new code.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: Ia83560d1c70f0802271a88c514e0d1cb0458f6c4
Reviewed-on: https://chromium-review.googlesource.com/561458
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46454}
In the original CL I moved an error check backwards, unfortunately
behind a vector lookup which should not happen when there is an error.
Now I also move the vector lookup backwards.
Original message:
We stored the size of a function body before we check that
these values are valid. This caused a failing DCHECK in the constructor
of WireBytesRef which checked for integer overflows. With this CL we
check the size of the function body before we create the WireBytesRef.
R=clemensh@chromium.org
Bug: chromium:738097
Change-Id: Ie65b3cfcbcd6bdb3f04b0760673d9c7b7a0d1057
Reviewed-on: https://chromium-review.googlesource.com/561519
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46453}
This CL adds a few transformations that clean up the set of reported
source ranges. Duplicates, empty, and uncovered ranges are removed, and
nested/consecutive ranges are merged if possible.
BUG=v8:6000
Change-Id: I421ee35ce8292cfe84c1eea4f653762cea5d909d
Reviewed-on: https://chromium-review.googlesource.com/558411
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46450}
Replaces the old PromotionQueue that was kept at the end of to space.
This change allows a future implementation to use
(a) a thread-local promotion list and
(b) enables work stealing for concurrent scenarios.
Bug: chromium:738865
Change-Id: I4c983a36e69ad4a9462eb9a59f586a85e51acbde
Reviewed-on: https://chromium-review.googlesource.com/561141
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46446}
This reverts commit 6c8aed76ff.
Reason for revert: Breaks some debug bots:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug/builds/16754https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/17654
Original change's description:
> [wasm] Check the size of a function body before storing it
>
> We stored the size of a function body before we check that
> these values are valid. This caused a failing DCHECK in the constructor
> of WireBytesRef which checked for integer overflows. With this CL we
> check the size of the function body before we create the WireBytesRef.
>
> R=clemensh@chromium.org
>
> Bug: chromium:738097
> Change-Id: I18f8b628c1499aae9c8e9340ea73c87f19e6f1d7
> Reviewed-on: https://chromium-review.googlesource.com/561000
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46442}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: Ifd533c0dee369c746bc97fea13275ebc09ed5eff
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:738097
Reviewed-on: https://chromium-review.googlesource.com/561517
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46445}
We stored the size of a function body before we check that
these values are valid. This caused a failing DCHECK in the constructor
of WireBytesRef which checked for integer overflows. With this CL we
check the size of the function body before we create the WireBytesRef.
R=clemensh@chromium.org
Bug: chromium:738097
Change-Id: I18f8b628c1499aae9c8e9340ea73c87f19e6f1d7
Reviewed-on: https://chromium-review.googlesource.com/561000
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46442}
TruncateDoubleToI generated a 32-bit result but did not clear the upper
32 bits. This violated the invariant that the upper 32 bits should be
cleared when the result is 32 bits. This change fixes the bug mentioned
below. Clearing the upper 32 bits is also done on x64.
R=v8-arm-ports@googlegroups.com, titzer@chromium.org, martyn.capewell@arm.com
Bug: chromium:738952
Change-Id: I7e23e03fbed380ff08803db41fbae6382957ba08
Reviewed-on: https://chromium-review.googlesource.com/559671
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46440}
Remove all IsHeapObject/IsSmi checks from assembler and also from
the macro-assembler functions that Turbofan code generation uses.
Note for porters: In case it's unclear which macro-assembler
functions need to be modified, it may be best to wait until I
split MacroAssembler in a followup-CL, which will make that clear.
Bug: v8:6048
Change-Id: Ife0735cc6f48713c9ec493faf2dac5e553d1c06b
Reviewed-on: https://chromium-review.googlesource.com/561015
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46436}
Introduce a stripped down version of UseScratchRegisterScope for ARM and use it
inside the assembler and macro-assembler. At the exception of the Call
instructions, we now use this scope instead of using the ip register
directly. This is inspired from how the ARM64 backend works.
In general, the benefit of doing this is we can catch cases where ip is being
used both by the caller and by the assembler. But more specifically, TurboFan
reserves r9 as an extra scratch register because ip can already be used by the
assembler. With this utility, we can isolate the cases in the code generator
which need an extra register and potentially fix them, allowing us to give r9
back to the register allocator.
This patch uncovered places in the assembler where we were using ip
unconditionally when we could have re-used the destination register instead.
Bug: v8:6553
Change-Id: Ib7134e3ed64dd1f90baf209ae831ed8f644cac78
Reviewed-on: https://chromium-review.googlesource.com/544956
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46425}
On x86, signalling NaNs get converted to quiet NaNs when they get push
on the stack and popped again. This happens in the code generation for
arm, specifically for the vmov instruction with the immediate parameter.
This CL replaces the vmov function in assembler-arm to take the
immediate as a uint64_t instead of a double, to guarantee that the bit
pattern does not change even if the parameter is a signalling NaN.
BUG=v8:6564
Change-Id: I062559f9a7ba8b0f560628e5c39621ca578c3e7d
Reviewed-on: https://chromium-review.googlesource.com/558964
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#46418}
If the input array is small, then the cost of a trip to the
runtime to transition the ElementsKind is too expensive.
Bug:
Change-Id: Ib04f8567674a6f1f66f4c7263eba5fb4c58987aa
Reviewed-on: https://chromium-review.googlesource.com/544866
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46417}
Instead of counting profiler ticks on the shared function info (which is
shared between native contexts), count them on the feedback vector
(which is not). This allows us to continue pushing optimization
decisions off the SFI, onto the feedback vector.
Note that a side-effect of this is that ICs don't have to walk the stack
to reset profiler ticks, as they can access the feedback vector directly
from their feedback nexus.
Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
Reviewed-on: https://chromium-review.googlesource.com/544888
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46411}
To be used with tuples of heap objects and sizes.
Bug: chromium:738865
Change-Id: I29d9cf98bb2097cc8e1616aaf19a251507ffbd9e
Reviewed-on: https://chromium-review.googlesource.com/559050
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46407}
In case of LAP(lazy accessor pair), the function's creation context
must be equal to the accessor holder's creation context, so this CL
changes the current context to the accessor holder's creation context.
BUG=v8:6156
Review-Url: https://codereview.chromium.org/2770003002
Cr-Commit-Position: refs/heads/master@{#46406}
This is a preliminary step before we stop swapping maps in the bootstrapper
(strict/sloppy map with writable prototype <-> readonly prototype).
Bug: v8:6459
Change-Id: I120550c10e98a234e283d79a8d408096601c92af
Reviewed-on: https://chromium-review.googlesource.com/558879
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46403}
Instead of having the "next step" state machine logic in the compiler
dispatcher, move it to the compiler dispatcher job. This is a
prerequisite to having more generic jobs with slightly different state
sets, such as an optimizing compile job.
Bug: v8:6537
Change-Id: Ib7319222f26dbc0e2afc95573b06d813825afde3
Reviewed-on: https://chromium-review.googlesource.com/554751
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46396}
Every, Some, Reduce, ReduceRight. Added a test that should improve
when TurboFan inlines these builtins. Updated Map and Filter tests
to include a TurboFan inline test.
Bug: v8:2229
Change-Id: Ie84d414fdcccea23c734caca55a3344f9442547f
Reviewed-on: https://chromium-review.googlesource.com/558935
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46395}
On Loongson 3A, MADD/MSUB instructions are actually fused MADD/MSUB and
they can cause failure in some of the tests. Since this optimization is
rarely used, and not used at all on MIPS64R6, MADD/MSUB instructions
are removed from the source base.
TEST=
BUG=
Change-Id: Ifbb5508a62731bb061f332864ffd1e210e97f963
Reviewed-on: https://chromium-review.googlesource.com/558066
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46387}
When providing scope information (containing the value of local
variables of live stack frames), decode the local variable names of all
functions in a wasm module and store this in the WasmDebugInfo
structure.
Use these names to actually name the reported locals, instead of using
the default names "param#<d>" and "local#<d>". These names are only used
as fallbacks for locals which were not assigned a name.
R=titzer@chromium.org,kozyatinskiy@chromium.org
BUG=v8:6245
Change-Id: Ibf7d30e392248ef5590177cd8b6329239b45e018
Reviewed-on: https://chromium-review.googlesource.com/548495
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46379}
Instructions ins and ext didn't work properly when size = 32 because of
incorrect mask initialization, this CL fixes this. A test for Ins is
also added.
BUG=
Change-Id: I95cc8e13aaa2341b34ae59dae1eefb64c551b8b4
Reviewed-on: https://chromium-review.googlesource.com/558872
Commit-Queue: Miran Karić <Miran.Karic@imgtec.com>
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46378}
The jsapi-harness test runs the JS-API spec tests of WebAssembly, which
get fetched from github when 'gclient sync' is executed. Without
'gclient sync' the harness may executed a version of the tests which is
older than required by the harness. In this CL I add a suggestion to
the test to run 'gclient sync' which is shown when the test is failing.
R=marja@chromium.org
Change-Id: I36d03bebc4d6cc554eefd4eb376c3d309b7ee5b9
Reviewed-on: https://chromium-review.googlesource.com/558419
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46375}
This sometimes caused problems with bots (for node too) because the
allocation could fail.
Bug: v8:6452
Change-Id: I346a9117eba8b6ed41566efeceaf7fb190784d76
Reviewed-on: https://chromium-review.googlesource.com/558075
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46373}
These were originally written as part of
https://chromium-review.googlesource.com/c/550396/. I've separated them
out into a separate CL with the intent of landing it first, so that it's
easier to see the difference these CLs will have on generated bytecode.
BUG=v8:5855
TBR=tebbi@chromium.org, rmcilroy@chromium.org
Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1
Reviewed-on: https://chromium-review.googlesource.com/558221
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46370}
This CL updates the wasm spec tests. In addition it adds an
assertNotEquals function to mjsunit.js, and it fixes the test harness
to not call quit() because it causes a dead-lock in combination with
async compilation.
R=rossberg@chromium.org
Change-Id: I50cf737993adb3e2bd27977efe7e20e304b89078
Reviewed-on: https://chromium-review.googlesource.com/558077
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46366}
The `FAST_` prefix doesn’t make much sense — they’re all just different cases
with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.
This patch renames the FAST elements kinds as follows:
- e.g. FAST_ELEMENTS => PACKED_ELEMENTS
- e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS
The following exceptions are left intact, for lack of a better name:
- FAST_SLOPPY_ARGUMENTS_ELEMENTS
- SLOW_SLOPPY_ARGUMENTS_ELEMENTS
- FAST_STRING_WRAPPER_ELEMENTS
- SLOW_STRING_WRAPPER_ELEMENTS
This makes it easier to reason about elements kinds, and less confusing to
explain how they’re used.
R=jkummerow@chromium.org, cbruni@chromium.org
BUG=v8:6548
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
Reviewed-on: https://chromium-review.googlesource.com/556032
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46361}
V8's catch prediction mechanism tries to predict whether a thrown
exception will be caught, just by looking at the current call stack.
At the time when catch prediction was first introduced, only a few
builtins (mostly related to Promise and Generator) could end up being
fed into the catch prediction mechanism. This is no longer the case now
that builtins are used in new ways, e.g. Array.p.forEach's continuation
builtins.
This CL removes the need to explicitly mark all builtins visible to the
StackFrameIterator as CAUGHT/UNCAUGHT/PROMISE, and instead defaults to
treating unmarked builtins as UNCAUGHT.
BUG=v8:6536
Change-Id: Ibdc106a91b2b0ffb93099433077642cad02c71e2
Reviewed-on: https://chromium-review.googlesource.com/555518
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46357}
... and set the instance class name in a bootstrapper instead.
Change-Id: Ie8a9a0e7cdc22ca19616b4a0d09665e059cd4d3e
Reviewed-on: https://chromium-review.googlesource.com/557864
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46356}
With FCG no longer able to deoptimize, we can remove the "push" version
of output frame state combine, as deoptimisation to bytecode is always
the PokeAt variant.
Bug: v8:6409
Change-Id: I9b6d38a7441ca834835615c238228fa8a75a027b
Reviewed-on: https://chromium-review.googlesource.com/557866
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46355}
This reverts commit 1520a8518a.
Reason for revert: This CL does not do what it should. All tasks which access the isolate have to be cancelable to guarantee that the isolate still exists when the task is executed. Foreground compilation tasks access the isolate, so they cannot be just normal tasks.
Original change's description:
> [wasm] Run foreground compilation tasks as normal tasks
>
> This CL makes foreground compilation tasks normal (i.e. not cancelable)
> again, because otherwise a deadlock can happen. I think the reason why
> the foreground tasks were cancelable was to make sure that all tasks
> either finish correctly or get canceled. However, since the isolate can
> only shut down on the main thread, this means that the foreground task
> should have already finished when the isolate shuts down, or it should
> not have started at all. I reordered the deletion of the AsyncCompileJob
> though to make sure that an AsyncCompileJob is removed from
> CompilationManager before its promise is resolved.
>
> Here is the deadlock: The JS code which is executed after a promise is
> resolved is executed within the task which resolves the promise. In case
> of async compilation this means that some JS code is executed within a
> CompileTask. In JS, the shutdown of the isolate can be triggered. During
> the shutdown of the isolate, the CancelableTaskManager waits for all
> registered cancelable tasks to complete, including the CompileTask of
> async compilation. This means that the CancelableTaskManager waits for
> itself to finish, which is a deadlock.
>
> R=clemensh@chromium.org, mtrofin@chromium.org
>
> Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
> Reviewed-on: https://chromium-review.googlesource.com/554733
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46343}
TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I60fab90b46d70c703d827816503e7e23b8c50251
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558284
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46353}
This CL landed on top of another CL which I want to revert.
This reverts commit 27b0d6a9fc.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [wasm] Update spec tests
>
> Update the spec tests in v8 to the most recent version.
>
> R=rossberg@chromium.org
> CC=titzer@chromium.org
>
> Change-Id: Ib4e809c20150502b131a2c0b68fdb2ede1d5f85f
> Reviewed-on: https://chromium-review.googlesource.com/552155
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46346}
TBR=mstarzinger@chromium.org,rossberg@chromium.org,ahaas@chromium.org
Change-Id: I82e4a2887bcb867d3572b78c36a20adc05df0903
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558040
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46352}
This reverts commit ca93156294.
Reason for revert: tsan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/16007
Original change's description:
> [wasm] Allow the initialization of a single compilation unit
>
> This CL adds a new function {InitializeCompilationUnit} to initialize
> a single compilation unit and not just all compilation units at once.
> This is necessary for streaming compilation eventually. This also
> required some refactoring on how the working queue for compilation units
> works. Previously the synchronization was done with an atomic counter,
> now it is done with a lock. Note that the code to finish compilation
> of a module still only works if the working queue gets only empty when
> all work is done. I plan to change this in a different CL.
>
> Since the code would not be tested without streaming compilation, I added
> an experimental flag and a test to test the new code.
>
> R=clemensh@chromium.org, mtrofin@chromium.org
>
> Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
> Reviewed-on: https://chromium-review.googlesource.com/550096
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46348}
TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: Ied6532f05463c0b78c8b8f5307d44640bcca8316
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558224
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46350}
This reverts commit 0d2ed6c328.
The CL introduced perf regressions: crbug.com/735649.
We are going to reland the CL in an isolated V8 roll to ensure
that perf regressions are attributed correctly.
Original commit message:
> [heap] Allow a minimum semi-space size of 512K.
> This CL also reduces the minimum semi-space size to 512K.
> BUG=chromium:716032
BUG=chromium:735649
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I1f1b08ca6853347c00070f000c309d839ff8a4bb
Reviewed-on: https://chromium-review.googlesource.com/552541
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46349}
This CL adds a new function {InitializeCompilationUnit} to initialize
a single compilation unit and not just all compilation units at once.
This is necessary for streaming compilation eventually. This also
required some refactoring on how the working queue for compilation units
works. Previously the synchronization was done with an atomic counter,
now it is done with a lock. Note that the code to finish compilation
of a module still only works if the working queue gets only empty when
all work is done. I plan to change this in a different CL.
Since the code would not be tested without streaming compilation, I added
an experimental flag and a test to test the new code.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
Reviewed-on: https://chromium-review.googlesource.com/550096
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46348}
This way, each lazy function needs to handle only the data relevant to
itself. This reduced data handling overheads.
Other changes:
1) Don't deserialize the data; once it's on the heap, it can stay there. Lazy
function compilation is only done in the main thread.
2) Separate ProducedPreParsedScopeData and ConsumedPreParsedScopeData. It's clearer, because:
- The data looks fundamentally different when we're producing it and when we're
consuming it.
- Cleanly separates the operations we can do in the "producing phase" and in the
"consuming phase".
Bug: v8:5516
Change-Id: I6985a6621f71b348a55155724765624b5d5f7c33
Reviewed-on: https://chromium-review.googlesource.com/528094
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46347}
Update the spec tests in v8 to the most recent version.
R=rossberg@chromium.orgCC=titzer@chromium.org
Change-Id: Ib4e809c20150502b131a2c0b68fdb2ede1d5f85f
Reviewed-on: https://chromium-review.googlesource.com/552155
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46346}
This CL makes foreground compilation tasks normal (i.e. not cancelable)
again, because otherwise a deadlock can happen. I think the reason why
the foreground tasks were cancelable was to make sure that all tasks
either finish correctly or get canceled. However, since the isolate can
only shut down on the main thread, this means that the foreground task
should have already finished when the isolate shuts down, or it should
not have started at all. I reordered the deletion of the AsyncCompileJob
though to make sure that an AsyncCompileJob is removed from
CompilationManager before its promise is resolved.
Here is the deadlock: The JS code which is executed after a promise is
resolved is executed within the task which resolves the promise. In case
of async compilation this means that some JS code is executed within a
CompileTask. In JS, the shutdown of the isolate can be triggered. During
the shutdown of the isolate, the CancelableTaskManager waits for all
registered cancelable tasks to complete, including the CompileTask of
async compilation. This means that the CancelableTaskManager waits for
itself to finish, which is a deadlock.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
Reviewed-on: https://chromium-review.googlesource.com/554733
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46343}
This mostly reverts commit c503b80595 but fixes
an issue where literals would always be pretenured on first instantiation.
As a cleanup we pass in a PretenureFlag instead of using the FeedbackVector as
indicator.
Bug: v8:6211
Change-Id: Id328552620e33f5083519bcba1e24396d162d516
Reviewed-on: https://chromium-review.googlesource.com/555670
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46342}
Similar to JSCall, we can also replace uninitialized JSConstruct nodes
with SOFT deopts to ensure that we don't generate unnecessary dead code.
This for example shows up in the hot parts of the Node event emitter
currently where the generic code for handling events with 4 or more
parameters might not have been run, but we still generate most of the
code because the new Array call in the beginning is not turned into
a SOFT deopt immediately.
Drive-by-fix: Also refactor the BytecodeGraphBuilder's handling of
Construct bytecodes a bit to reduce the amount of code duplication.
BUG=v8:4551, v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2958253002
Cr-Commit-Position: refs/heads/master@{#46339}
Previously V8 created a promise to return to userland,
but instead we let the embedder create and track the promise.
Bug: v8:5785
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I8903ffbabf3a256f1c8df844a656a873da304586
Reviewed-on: https://chromium-review.googlesource.com/492646
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46333}
The naming convention in v8 has trivial getters named like the field,
no 'get_' prefix, and dropping the '_' suffix of the field.
BUG=
Review-Url: https://codereview.chromium.org/2958283003
Cr-Commit-Position: refs/heads/master@{#46332}
When internalization of the key fails because the string does not
exist in the StringTable yet, then no regular object can possibly
have a property with that name, so just returning "false" is safe.
However, for objects with interceptors this is not true, as there
may well be intercepted properties whose keys have not been
internalized. So "special API objects" must take the slow path to
query any interceptors.
Bug: chromium:735990
Change-Id: Ibe6c4f8b14fef65738115f12167d3602bec3d9b7
Reviewed-on: https://chromium-review.googlesource.com/552550
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46323}
This adds support for lowering of nodes having the {JSToObject} operator
even if they have exceptional control projections (e.g. are inside of a
try-block).
R=bmeurer@chromium.org
TEST=mjsunit/compiler/optimized-with
Change-Id: I711ff4935db68c43243a971a8b21989487c86317
Reviewed-on: https://chromium-review.googlesource.com/554628
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46318}
This reverts commit 96698b55e0.
Reason for revert: This patch was correct when it landed, but later,
the spec was changed to V8's old behavior in
https://github.com/tc39/ecma262/pull/885 .
Original change's description:
> [parser] allow ASI when "await" or "yield" follows "let"
>
> Per https://github.com/tc39/test262/pull/956, André believes that ASI
> should be permitted in these situations.
>
> BUG=
> R=marja@chromium.org, adamk@chromium.org, littledan@chromium.org
>
> Change-Id: I5602d8a507576607750ffa9e873e1bfa53dd3523
> Reviewed-on: https://chromium-review.googlesource.com/472568
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Cr-Commit-Position: refs/heads/master@{#44585}
TBR=adamk@chromium.org,marja@chromium.org,littledan@chromium.org,caitp@igalia.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I2c5bf709867da539ccd4cd82f3be98c8a0301f31
Reviewed-on: https://chromium-review.googlesource.com/553617
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46317}
This adds support for lowering of nodes having the {JSCreateArray}
operator even if they have exceptional control projections (e.g. are
placed inside a try-block).
R=mvstanton@chromium.org
TEST=mjsunit/compiler/array-constructor
Change-Id: I2fe34dbb3729b4763471f2638a960b01c531c038
Reviewed-on: https://chromium-review.googlesource.com/554732
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46315}
In our internal code, we should only use pending exceptions. They will
be converted to scheduled exceptions on the API boundary.
Hence, the ErrorThrower just sets a pending exception; it should never
have to think about scheduled exceptions. The new
ScheduledErrorThrower inherits from ErrorThrower and reschedules any
pending exceptions in its destructor (turning them into scheduled
exceptions).
In some situations, there might already be a scheduled exception, e.g.
when calling other API methods (v8::Value::Get). In this case, the
ErrorThrower should also not set another pending exception. For the
reasons mentioned above, this can only be handled in the
ScheduledErrorThrower, which is used the API methods.
This fixes one DCHECK failure and one TODO about scheduled exceptions
if no instance can be created, because the start function throws.
R=mtrofin@chromium.org, mstarzinger@chromium.org
BUG=v8:6232,chromium:736256
Change-Id: I4905be04c565df9495de18fb26adbb5c05d193d2
Reviewed-on: https://chromium-review.googlesource.com/548641
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46314}
There are very few cases where OSR code can be re-used, and where the
function won't be non-concurrently optimized after OSR has happened.
Maintaining the OSR code cache is unnecessary complexity, and caching
OSR prevents us from e.g. seeding the optimizer with the actual OSR
values.
So, this patch removes it.
Change-Id: Ib9223de590f35ffc1dc2ab593b7cc9fe97dde4a6
Reviewed-on: https://chromium-review.googlesource.com/552637
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46306}
icu-case-mapping was shipped a few months ago. By dropping
the flag, unibrow's case conversion code won't be included
by default because V8_INTL_SUPPORT is on by default.
BUG=v8:4477, v8:4476
TEST=test262/{built-ins,intl402}/Strings/*, webkit/fast/js/*,
mjsunit/string-case, intl/general/case*
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I78be9cc64b4588bc5af79ecbbadf93af6e84a1df
Reviewed-on: https://chromium-review.googlesource.com/534541
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46304}
It appears we actually get a compile time boost, and sometimes a
runtime boost, at the cost of some reloc info growth.
Bug:
Change-Id: I1d1dc48f364e6611f895ebd00f86451199dd8626
Reviewed-on: https://chromium-review.googlesource.com/544713
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46302}
V8 now takes care of recording a module's status, as proposed
in https://github.com/tc39/ecma262/pull/916.
R=adamk@chromium.org
Bug: v8:1569, chromium:594639
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id884f1c817e1dc3eea79a5d5a7f5cd996db1dbb0
Reviewed-on: https://chromium-review.googlesource.com/548500
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46293}
This implements the changes proposed at
https://github.com/tc39/ecma262/pull/916.
The API will be extended in a follow-up CL.
R=adamk@chromium.org
Bug: v8:1569
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I79476b5b674c924fea390dff1b9bee7f86a111c6
Reviewed-on: https://chromium-review.googlesource.com/544970
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46289}
Removes from CL https://codereview.chromium.org/2929853003 code to fix
histogram timers in class WasmCompilationUnit. This was done because
the CL was reverted due to errors caused by background compiles that
updated UMA histogram timers.
The goal of this CL is to reland the remaining portion of the reverted
CL.
Bug:v8:6361
Change-Id: Ic03ceb118734bd55c463a843521bcd5b09342afe
Reviewed-on: https://chromium-review.googlesource.com/550196
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@google.com>
Cr-Commit-Position: refs/heads/master@{#46268}
This is a reland of 72b88fdab8
Original change's description:
> [runtime] Make all built-in functions strict.
>
> According to ES#sec-built-in-function-objects all built-in functions
> must be strict.
>
> This is a preliminary CL before changing the way we define built-in
> functions in native JS files.
>
> Bug: v8:6529, v8:6459
> Change-Id: I8e60b342f04ea1b0843fe1990334cbb9b26ebac4
> Reviewed-on: https://chromium-review.googlesource.com/546215
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46237}
Bug: v8:6529, v8:6459
Change-Id: Ic0eb3d7925ed63dd716c4a114601415f92627ca5
Reviewed-on: https://chromium-review.googlesource.com/550156
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46262}
This reverts commit 3c04ee6d4e.
Reason for revert: Speculative revert for OOMs in:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/18563
Original change's description:
> [heap] Make aborting compaction a fatal
>
> Last attempt failed because of too agressive growing and no proper GC
> scheduling.
>
> Also refactor live object iteration on the way to avoid a branch when we
> know that we will succeed.
>
> Bug: chromium:651354
> Change-Id: I8f52cbc79ac293989fb7c29c492d4ae4afe5ebe4
> Reviewed-on: https://chromium-review.googlesource.com/544829
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46245}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: Ifb9fd0c873c4ec6d4bd895f2978849cc2a223a05
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:651354
Reviewed-on: https://chromium-review.googlesource.com/549324
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46247}
Last attempt failed because of too agressive growing and no proper GC
scheduling.
Also refactor live object iteration on the way to avoid a branch when we
know that we will succeed.
Bug: chromium:651354
Change-Id: I8f52cbc79ac293989fb7c29c492d4ae4afe5ebe4
Reviewed-on: https://chromium-review.googlesource.com/544829
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46245}
Adds a CheckString to all operand inputs of JSStringConcat. The operands are
already known to be strings, so this will get eliminated in almost all cases,
however, if there is a yield within the concatenation then we lose the
knowledge that the previous operands are strings since the values are loaded
from the generator object. Adds a test for this case.
BUG=v8:6243
Change-Id: I1601a316e6efbed1c53486f1027cb0ea023ff030
Reviewed-on: https://chromium-review.googlesource.com/549301
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46243}
This reverts commit 72b88fdab8.
Reason for revert: Changes a layout test:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16595
Original change's description:
> [runtime] Make all built-in functions strict.
>
> According to ES#sec-built-in-function-objects all built-in functions
> must be strict.
>
> This is a preliminary CL before changing the way we define built-in
> functions in native JS files.
>
> Bug: v8:6459
> Change-Id: I8e60b342f04ea1b0843fe1990334cbb9b26ebac4
> Reviewed-on: https://chromium-review.googlesource.com/546215
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46237}
TBR=adamk@chromium.org,ishell@chromium.org,verwaest@chromium.org
Change-Id: Ic458b478b2dd23aae7ea2a51aa6052c1f5931c56
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6459
Reviewed-on: https://chromium-review.googlesource.com/549322
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46242}
Bug: chromium:736758
Change-Id: If49fda42618c27be1472a98399e440ad26b7f199
Reviewed-on: https://chromium-review.googlesource.com/548401
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46241}
According to ES#sec-built-in-function-objects all built-in functions
must be strict.
This is a preliminary CL before changing the way we define built-in
functions in native JS files.
Bug: v8:6459
Change-Id: I8e60b342f04ea1b0843fe1990334cbb9b26ebac4
Reviewed-on: https://chromium-review.googlesource.com/546215
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46237}
Uninitialized property accesses are replaced with SOFT deopts in
TurboFan, but uninitialized JSCall nodes are not, and instead they
just stick around and are also not being inlined because the heurstic
in TurboFan doesn't consider those candidates since their call frequency
is below the threshold. This unifies the behavior and also replaces
uninitialized calls with SOFT deopts, addressing some inconsistency in
optimization behavior as discovered by Brian White of Node for example
here: https://twitter.com/mscdexdotexe/status/879005026202640385R=jarin@chromium.org
BUG=v8:4551, v8:5267
Review-Url: https://codereview.chromium.org/2956843002
Cr-Commit-Position: refs/heads/master@{#46231}
If a String object contains unicode, the returned {ToCString()} may
actually longer than the {length()} of the String.
But it's always null-terminated, so we can just print it without
explicitly passing a length.
R=ahaas@chromium.org
Change-Id: I3398f151d70ed459ecd8093ea18409670a7374c7
Reviewed-on: https://chromium-review.googlesource.com/548058
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46225}
The implication was actually in the wrong direction: If there is no
memory start address, then the size must be 0.
If the size is 0 though, we might allocate nevertheless to have guard
pages around the accessible memory.
R=ahaas@chromium.org
BUG=chromium:736584
Change-Id: I297dece658d5eaf69c58ecb109ff21d3ca0b8a8d
Reviewed-on: https://chromium-review.googlesource.com/548635
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46221}
Test that unicode identifiers can be used for imports and exports, and
that unicode function names appear correctly in error messages.
R=ahaas@chromium.org
Change-Id: Ic6ac77159c275845886b2eb779cf59edb8cba9ea
Reviewed-on: https://chromium-review.googlesource.com/548315
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46220}
This is a regression test that will ensure that follow-up CLs that will
touch native function definitions will not brake anything.
Bug: v8:6459
Change-Id: Iceafd38462f2d9de14e119b6aa48be2b9bff1d33
Reviewed-on: https://chromium-review.googlesource.com/545935
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46200}
This is a fix to https://codereview.chromium.org/2929853003 that got
reverted. The DCHECK checked to see that it was not in a background
thread. While this is a property we want for v8, it is also used
by blink, and blink violates this property.
Therefore, this CL removes the DCHECK for now.
BUG=v8:6361
Review-Url: https://codereview.chromium.org/2961443002
Cr-Commit-Position: refs/heads/master@{#46190}
Move bytecode array writing logic into the array builder, allowing us to
remove the bytecode array writer and bytecode node, and convert runtime
operand writing to compile-time bytecode operand writing using the
information statically known at compile time.
Bug: v8:6474
Change-Id: I210cd9897fd41293745614e4a253c7c251dfffc9
Reviewed-on: https://chromium-review.googlesource.com/533055
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46183}
This prepares ground for switching mark-compactor to use
Worklist data-structure instead of the existing marking deque.
BUG=chromium:694255
Change-Id: I0ac4c563018a9619962fb4bf388b5f3cceffb86d
Reviewed-on: https://chromium-review.googlesource.com/544933
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46178}
The race happens when the layout descriptor is evacuated at the same
time as an object that has this layout descriptor is evacuated.
Change-Id: I0a5fc545cf359fdfe738d8b6359713f5ea170986
Reviewed-on: https://chromium-review.googlesource.com/544953
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46175}
This reverts commit 217d654c9b.
Reason for revert: Changes layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16520
Original change's description:
> [parser] moved load property position after dot
>
> Currently LdaNamedProperty bytecode for expressions like a.b has position before dot. This CL moves this location after dot.
> It's important for later removing of Nop bytecodes in expressions like a.b() where a is local variable, property call and property load should have the same position.
>
> R=jgruber@chromium.org
>
> Bug: v8:6425
> Change-Id: I528c5007de52215beba80851ab04693ecec038e2
> Reviewed-on: https://chromium-review.googlesource.com/543047
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46163}
TBR=marja@chromium.org,kozyatinskiy@chromium.org,jgruber@chromium.org
Change-Id: I94543526f39f0a20452fbce1a7bc6744cac66621
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6425
Reviewed-on: https://chromium-review.googlesource.com/544993
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46171}
This removes the --turbo flag and solely relies on the filter pattern
provided via --turbo-filter when deciding whether to use TurboFan. Note
that disabling optimization wholesale can still be done with --no-opt,
which should be used in favor of --no-turbo everywhere.
Also note that this contains semantic changes to the TurboFan activation
criteria. We respect the filter pattern more stringently and no longer
activate TurboFan just because the source contains patterns forcing use
of Ignition via {AstNumberingVisitor::DisableFullCodegenAndCrankshaft}.
R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I0c855f6a62350eb62283a3431c8cc1baa750950e
Reviewed-on: https://chromium-review.googlesource.com/528121
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46167}
Async generator yield* is still desugared in the parser, to be moved to the BytecodeGenerator in a future CL.
Bug: v8:6472
Change-Id: I8b33e2f9e931949f7375540099cd8ec3a6b27cf1
Reviewed-on: https://chromium-review.googlesource.com/539335
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46165}
Currently LdaNamedProperty bytecode for expressions like a.b has position before dot. This CL moves this location after dot.
It's important for later removing of Nop bytecodes in expressions like a.b() where a is local variable, property call and property load should have the same position.
R=jgruber@chromium.org
Bug: v8:6425
Change-Id: I528c5007de52215beba80851ab04693ecec038e2
Reviewed-on: https://chromium-review.googlesource.com/543047
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46163}
This piggy-backs on top of existing precise and best-effort coverage to expose
block coverage through the inspector protocol.
Coverage collection now implicitly reports block-granularity coverage when
available. A new 'isBlockCoverage' property on Inspector's FunctionCoverage
type specifies the granularity of reported coverage.
For now, only count-based block coverage is supported, but binary block
coverage should follow soon.
Support is still gated behind the --block-coverage flag.
Bug: v8:6000
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I9c4d64e1d2a098e66178b3a68dcee800de0081af
Reviewed-on: https://chromium-review.googlesource.com/532975
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46157}
HistoryTimer's can't run in the background because they use a timer
with a simple api of Start() and Stop(). This CL fixes this problem
by building a base class TimedHistogram that doesn't have a timer.
The class HistoryTimer is modified to use this base class so that
uses that run on the foreground thread do not need to be modified.
It also adds a new class TimedHistogramScope that defines the timer
in this class. This allows the corresopnding TimedHistogram class to
be type safe.
BUG=v8:6361
Review-Url: https://codereview.chromium.org/2929853003
Cr-Commit-Position: refs/heads/master@{#46150}
In most cases, I'm using ENTER_V8 which is due to the fact that the
respective methods might end up executing script, either because they
invoke some callback, or because they might trigger a proxy trap.
Also add microtask suppression scopes in the debugger to all the places
that need one according to tests.
BUG=v8:5830
R=marja@chromium.org,jgruber@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I24cc3de37fc0d8156acfe86b290568e5f8f662b4
Reviewed-on: https://chromium-review.googlesource.com/519262
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46146}
This CL leverages and extends the deopt-to-stub mechanisms previously
introduced to support deopting from CSA-built builtins (e.g. Array.prototype.forEach).
BUG=v8:6373
LOG=N
Review-Url: https://codereview.chromium.org/2890363002
Cr-Commit-Position: refs/heads/master@{#46144}
If the fuzzer input cannot be executed in the interpreter within a step
limit, then the interpreter does not calculate the result but instead
finishes with a RangeError. The problem with the input of the bug report
was that the interpreter finished with that RangeError, but the
execution of the compiled code still returned a result, which was
naturally not a RangeError and therefore caused the result check to fail.
With this CL the compiled code is not even executed when there is a
RangeError after the execution in the interpreter. Thereby we also
avoid executing an infinite loop.
BUG=chromium:734435
R=clemensh@chromium.org
Change-Id: If9d0fb9e14e84f06d6f11d22f882363d56c1c20b
Reviewed-on: https://chromium-review.googlesource.com/544838
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46140}
In the failing case (see test), the loop variable (which should be context
allocated) is in a hidden scope, so we need to save and restore data for hidden
scopes too.
The !is_hidden() check was overly limiting - NeedsScopeData already handles the
"hidden leaf scope" case which is the one we want to avoid.
(Btw, this also means that the previous assumption "variables in hidden scopes
are not context allocated" was wrong.)
BUG=v8:5516
Change-Id: I1c6116654b19ef0cfd64e8a743b46af683a9fcd5
Reviewed-on: https://chromium-review.googlesource.com/544938
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46136}
let f = function g() { ... } declares "g" inside the function. This
CL makes the preparser declare it too, and saves + restores the scope data for
it.
BUG=v8:5516
Change-Id: Id4c64f446d30f5252038cfb0f0f473b85ba24a9b
Reviewed-on: https://chromium-review.googlesource.com/544816
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46133}
transition, check to see if we have already done this transition.
BUG=v8:6450
Review-Url: https://codereview.chromium.org/2915863004
Cr-Commit-Position: refs/heads/master@{#46129}
The test setup was as follows:
- Preparse function test() { ... }, get scope allocation data.
- Apply the scope allocation data to (function test() { ... })();
- Compare against normal scope allocation for (function test() { ... })();
But the IIFE is unnecessary - we already disable lazy parsing.
Cleaning this up is needed because in the next CL, I want to fix the Scopes
produced by PreParser in this case:
let f = function g() {
// Here we should declare g!
}
And that fix will make the variables in
function test() {
// Here we don't declare test
}
and
(function test() {
// Here we do declare test
})();
not match any more, so it doesn't make sense to compare them against each other.
BUG=v8:5516
Change-Id: I93d154c6977bb3cbe405b6ca193cf6283df297bc
Reviewed-on: https://chromium-review.googlesource.com/543341
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46128}
This switches all uses of the patching {BinaryOpICStub} over to the
respective existing and non-patching CSA-builtins, and removes some
supporting code. It also removes the inlined SMI handling.
R=verwaest@chromium.org
BUG=v8:6408
Change-Id: If547c0127bfcafbd01ccb33b702b1868006ebcb1
Reviewed-on: https://chromium-review.googlesource.com/541398
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46122}
This will allow for embedders to easily implement their own Platform
without duplicating the tracing controller code.
BUG=v8:6511
R=fmeawad@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I7c64933d12b2cf53f0636fbc87f6ad5d22019f5c
Reviewed-on: https://chromium-review.googlesource.com/543015
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Fadi Meawad <fmeawad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46118}
In edge cases such as the following, sloppy-mode block-scoped function
hoisting is expected to occur:
eval(`
with({a: 1}) {
function a() {}
}
`)
In this case, there should be the equivalent of a var declaration
outside of the eval, which gets set to the value of the local function
a when the body of the with is executed.
Previously, the way that var declarations are hoisted out of eval
meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL
assignment. However, such a lookup mode meant that the object in the
with scope received the assignment!
This patch fixes that error by marking the assignments produced by
the sloppy mode block scoped function hoisting desugaring so as to
generate a different runtime call which skips with scopes.
Bug: chromium:720247, v8:5135
Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748
Reviewed-on: https://chromium-review.googlesource.com/529230
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46116}
(Reland: NeedsManualRebaseline'd newly-fixed layout test in Chromium.)
This was never legal; the spec only allows '\0' in strict-mode strings
or templates when not followed by a decimal digit. Previously we were
only enforcing that it not be followed by an _octal_ digit.
This was already fixed for numeric literals, but not for escape
sequences in strings.
BUG=v8:6504
Review-Url: https://codereview.chromium.org/2948903002
Cr-Commit-Position: refs/heads/master@{#46106}
This method returns position of importing stmt in module source.
R=neis@chromium.org
Bug: chromium:721589
Change-Id: I8639796a001fdfec7cf5aa1bf1a27493f7a757a9
Reviewed-on: https://chromium-review.googlesource.com/541322
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46105}
Allows BitVector to resize, updating its own data and data length to
match the new length. We can fast-path resizes which fit into the same
data length (since high bits are already zero), and replace the pattern
where a BitVector is cloned using CopyFrom.
Change-Id: If79ca782c516e93b2a27c5e335e263554d522e88
Reviewed-on: https://chromium-review.googlesource.com/539522
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46101}
This CL improves reported source range precision in a couple of ways:
Source ranges are now standardized to consist of an inclusive start
index and an exclusive end index (similar to what's reported for
functions). For example:
0123456789 // Offset.
{ f(); } // Block represented as range {0,8}.
Duplicate singleton ranges (i.e. same start and end offsets) are now
merged (this only becomes relevant once jump statement coverage is
added). For example:
for (.) break; // Break- and loop continuation have same positions.
SourceRangeScope incorrectly collected starting position
(unconditionally) and end position (when no semi-colon was present).
01234567890123 // Offset.
for (.) break // Loop body range is {8,13}, was {6,9}.
Bug: v8:6000
Change-Id: I62e7c70cc894a20f318330a2fbbcedc47da2b5db
Reviewed-on: https://chromium-review.googlesource.com/541358
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46095}
Adds typed lowering of JSStringConcat to ConsString allocation if the
following conditions hold:
- All concatinations will result in a ConsString of >= ConString::kMinLength
- No concatinations will result in a empty string in the RHS unless there is
a sequential string in the LHS.
This also means JSStringConcat needs an eager checkpoint since it can
deopt if throwing a RangeError when the string length protector is valid.
BUG=v8:6243
Change-Id: I01ca79f884df467c10f2c032c72d51b5199c1a3c
Reviewed-on: https://chromium-review.googlesource.com/526636
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46093}
Add a new JSConstructWithArrayLike operator that is backed by the
ConstructWithArrayLike builtin (similar to what was done before
for the JSCallWithArrayLike operator), and use that operator to
optimize Reflect.construct inlining in TurboFan. This is handled
uniformly with JSConstructWithSpread in the JSCallReducer.
Also add missing test coverage for Reflect.construct in optimized
code, especially for some interesting corner cases.
R=petermarshall@chromium.org
BUG=v8:4587,v8:5269
Review-Url: https://codereview.chromium.org/2949813002
Cr-Commit-Position: refs/heads/master@{#46087}
- Iterator advancing is kept mainly unchanged.
- The iterator stores the size of the object which is to be used by the
caller in follow ups. This way we might be able to avoid further out
of line loads.
- The iteartor follows the regular std conventions allowing range based
loops.
Bug: chromium:651354
Change-Id: I8928224a62d3a48a48145a2d00279a28608bc634
Reviewed-on: https://chromium-review.googlesource.com/543335
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46085}
The fuzzer has already been removed from chromium. In addition I removed
code which was only used by this fuzzer.
BUG=chromium:734550
R=clemensh@chromium.orgCC=mstarzinger@chromium.org
Change-Id: I2ff4614e4d64131412ead759318e5c38e38f5d3d
Reviewed-on: https://chromium-review.googlesource.com/542816
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46078}
- Now that there are no boolean vector types, we can directly test the
results of relational ops.
Bug: v8:6020
Change-Id: Id2139133ae3a548a9985a26a3427cbeddc6272a6
Reviewed-on: https://chromium-review.googlesource.com/536176
Reviewed-by: Aseem Garg <aseemgarg@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46075}
On an error during {ProcessExports()}, we would just continue
execution, resulting in a DCHECK failure later.
I did not find any tests for exported globals, so I added a few
(including a regression test for the referenced bug).
R=ahaas@chromium.org
BUG=chromium:734295
Change-Id: I35370de934c274f870680c662ef848c72268a7bc
Reviewed-on: https://chromium-review.googlesource.com/539401
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46064}
If one wasm instance imports an exported function of another instance,
we unwrap the js-to-wasm wrapper of the export and use the underlying
code object directly. However, the code object does not keep the wasm
instance alive. It is only connected via a WeakCell.
With this CL, we explicitly store a FixedArray of all wasm instances
from which we imported functions to keep them alive at least as long as
the instance which imports the code.
R=mtrofin@chromium.org, ahaas@chromium.org
BUG=chromium:734345
Change-Id: I8dcfc9a4ea2d791a62d8cb7255039e481c50bdfd
Reviewed-on: https://chromium-review.googlesource.com/539738
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46062}
Inspector uses only BREAK_POSITION_ALIGNED, no tests pass STATEMENT_ALIGNED. It's exposed only with debugger API but I'm pretty sure that nobody actually uses it and as far as mirrors API is deprecated - it's time to remove it.
R=jgruber@chromium.org
Bug: none
Change-Id: I28d62e145811d3eb6f4d64007c47c51b2ecbaf0f
Reviewed-on: https://chromium-review.googlesource.com/536934
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46056}
This makes sure that the coercion of global import values to numbers
remains non-observable to JavaScript. It allows instantiation failures
to fall back to JavaScript proper without accidentally causing some
side-effect to happen twice. Also coercions might invalidate previous
checks done during linking or throw exceptions.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6431
BUG=v8:6431
Change-Id: Ibe2f7a336bc0fb25532d526746ecc802e04bbd5c
Reviewed-on: https://chromium-review.googlesource.com/512544
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46051}
The constructor of WireBytesRef checks that offset+length is still in
the uint32_t range. This CL avoids triggering this check on illegally
size strings.
R=ahaas@chromium.org
BUG=chromium:734246
Change-Id: Iab5c7013aa3e0ac5060bc4733e712a1652679b1a
Reviewed-on: https://chromium-review.googlesource.com/539402
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46050}
This was never legal; the spec only allows '\0' in strict-mode strings or templates
when not followed by a decimal digit. Previously we were only enforcing that it
not be followed by an _octal_ digit.
This was already fixed for numeric literals, but not for escape sequences in strings.
BUG=v8:6504
Review-Url: https://codereview.chromium.org/2950633002
Cr-Commit-Position: refs/heads/master@{#46046}
Add a new JSCallWithArrayLike operator that is backed by the
CallWithArrayLike builtin, and use that operator for both
Function.prototype.apply and Reflect.apply inlining. Also unify
the handling of JSCallWithArrayLike and JSCallWithSpread in
the JSCallReducer to reduce the copy&paste overhead.
Drive-by-fix: Add a lot of test coverage for Reflect.apply and
Function.prototype.apply in optimized code, especially for some
corner cases, which was missing so far.
BUG=v8:4587,v8:5269
R=petermarshall@chromium.org
Review-Url: https://codereview.chromium.org/2950773002
Cr-Commit-Position: refs/heads/master@{#46041}
We can remove a lot of native code and rely on CallOrConstructVarargs
to do the stack manipulation for us.
This will also take advantage of the fast-path for double arrays in
CallOrConstructDoubleVarargs.
We can also remove Runtime_SpreadIterableFixed because it isn't used
anymore. We just call directly into spread_iterable from CSA.
Bug: v8:6488, chromium:704966
Change-Id: I81a18281f062619851134fff7ce88471566ee3b5
Reviewed-on: https://chromium-review.googlesource.com/535615
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46038}
Previously, Date.toString() and friends were completely
implementation-defined. However, they actually seemed to match
each other's behavior with the exception of how years less than
1000 are formatted. The rough consensus among browsers seemed
to be %04d, so this was standardized at TC39 [1]. V8 previously
used %4d (it was the only one to do so); this patch adopts
the new standard.
[1] 5d4acf3377
Bug: v8:6076
Change-Id: I8c795a4e1b71187ad7c24a1aee8d7d66719a2586
Reviewed-on: https://chromium-review.googlesource.com/536733
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46037}
For each Managed<T> (which is a Foreign), we create a weak global handle
with a finalizer which deletes the referenced C++ object once the
Foreign is dead.
Before calling this finalizer, the garbage collector needs to mark the
referenced object black (i.e. live), because the finalizer might
resurrect it.
Since this is never done for managed objects, we can use the more
lightweight phantom handle semantics, which allows the referenced
object to be garbage collected right away.
However, we can't access the global handle via the WeakCallbackInfo,
because the global handle will already be garbage collected. So we need
to store it explicitly. This is solved by storing the global handle
together with the finalizer.
In order to implement this, ownership of the ManagedObjectFinalizer
is moved from the isolate to the managed object.
R=ulan@chromium.org, mtrofin@chromium.org
BUG=v8:6505, chromium:734345
Change-Id: I94a245df601f70e19355d82439d30099e159231b
Reviewed-on: https://chromium-review.googlesource.com/539578
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46036}
This test checks how much time we spent for generating Debugger.paused notification.
R=machenbach@chromium.org
Bug: chromium:688036
Change-Id: Ie8a52aafe6c8d93401b0b2a90a202ddff7de78ef
Reviewed-on: https://chromium-review.googlesource.com/538584
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46035}
The initial implementation did not work in certain cases.
For example, in the following case 'f' didn't have a shared name while
it should have had an empty shared name:
var f = (function() { return function() { return 42; } }();
The new implementation ensures that all anonymous functions have empty
shared name and if any of them happen to be an object literal property
value or an accessor function or a concise method then such a function
is marked as having no shared name.
Bug: v8:6459
Change-Id: I0f936afce0c152d91b2b41c1dc475a5ed841eca0
Reviewed-on: https://chromium-review.googlesource.com/538666
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46026}
Adds a 'performance' test which tracks the number of expressions
which can be nested before the compiler runs out of stack space.
This isn't really a performance test, but is created as a js-perf-test
to enable regression tracking in the dashboards.
Change-Id: Iee0c00df53b38b083e2dde09676ac9b13e439461
Reviewed-on: https://chromium-review.googlesource.com/539419
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46019}
- Use correct prefixes for SIMD/Atomics ops
- S128 LoadMem/StoreMem should not use 0xc0/0xc1 opcodes, these are now
being used for sign extension
- S128 LoadMem/StoreMem should use prefixed opcodes
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2943773002
Cr-Commit-Position: refs/heads/master@{#46016}
This patch updates the error positition and the error msg.
Previously,
→ ./out.gn/x64.release/d8 test.js
test.js:1: TypeError: undefined is not a function
var [a] = {};
^
TypeError: undefined is not a function
at test.js:1:1
With this patch,
→ ./out.gn/x64.release/d8 test.js
test.js:1: TypeError: [Symbol.iterator] is not a function
var [a] = {};
^
TypeError: [Symbol.iterator] is not a function
at test.js:1:11
Bug: v8:5532
Change-Id: Ib066e8ec8a53fdf06cce491bde4b1d0c6d564cbc
Reviewed-on: https://chromium-review.googlesource.com/539024
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46015}
We only need to use this for certain Intrinsics defined in the spec.
This CL removes unnecessary uses.
Bug: v8:6474
Change-Id: I13a9f0c57d877dd65a883a38f9683d55623030d3
Reviewed-on: https://chromium-review.googlesource.com/529224
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46012}
Track execution counts of the continuations of block structures (e.g.
IfStatements) to capture cases in which execution does not continue after a
block. For example:
for (;;) {
return;
}
// Never reached, tracked by continuation counter.
A continuation counter only has a start position; it's range is implicitly
until the next sibling range or the end of the parent range.
Bug: v8:6000
Change-Id: I8e8f1f5b140b64c86754b916e626eb50f0707d70
Reviewed-on: https://chromium-review.googlesource.com/530846
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46006}
If we pass in thin-string into a keyed load, the underlying internalized string is used to find the handler. However, the thin string itself was used to interpret the handler. Since the thin string itself isn't unique, this caused existing properties on the prototype chain to not be found in case of dictionary-mode prototypes.
Bug: chromium:731193
Change-Id: Ic98d3789ecf9175e17d9c898ab13231aad59efcc
Reviewed-on: https://chromium-review.googlesource.com/539596
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46005}
It might happen that we deprecate the map of previous sub-literals if we create
literals with the same map several times. This is usually the case for
configuration arrays.
Bug: chromium:734051
Change-Id: I82284e5aae632286135b2092816d776d229c65af
Reviewed-on: https://chromium-review.googlesource.com/538665
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46003}
Here we optimize Dsubu by instead of loading imm and subtracting, we
load -imm and perform addition when loading -imm takes less instructions
than loading imm. Similarily li is optimized by loading -imm and
performing addition or loading ~imm and inverting bits using nor when
one of these loads takes two instructions less than loading imm, saving
at least one instruction. Tests are adjusted to cover these
optimizations.
BUG=
TEST=cctest/test-assembler-mips/li_macro
cctest/test-assembler-mips/Dsubu
Review-Url: https://codereview.chromium.org/2909913002
Cr-Commit-Position: refs/heads/master@{#46001}
