... that have computed name and/or require home object.
This should give us the opportunity to implement initialization
of name and home object values in a stub.
Bug: v8:6459
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I47a1a2c185e120e86c793733cce737811f895291
Reviewed-on: https://chromium-review.googlesource.com/512802
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46638}
Removes the --ignition flag which is now on by default. Adds a
--stress-fullcodegen flag which enables running all functions supported
by fullcodegen to be compiled by fullcodegen.
This will enable moving parser internalization later when we are not
stressing fullcodegen or compiling asm.js functions.
BUG=v8:5203, v8:6409, v8:6589
Change-Id: I7fa68016d4e734755434ec0b4e749ef65ffa7f4e
Reviewed-on: https://chromium-review.googlesource.com/565569
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46635}
It's ok that the instance of the called code object is different from
the caller instance. This happens if one instance calls an exported
function of another instance.
R=ahaas@chromium.org
Bug: chromium:739768
Change-Id: I6afa8332a9b33fe32e9332cdca573053f058421d
Reviewed-on: https://chromium-review.googlesource.com/568494
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46624}
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}
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 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 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}
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 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}
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}
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}
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}
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}
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}
... 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}
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}
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}
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}
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}
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}
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}
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}
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}
... 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}
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 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}
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}
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}
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}
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}
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}
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 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}
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}
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}
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 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}
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}
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}
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}
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}
Large allocations would fail due to the flag not being set.
Bug: chromium:732836
Change-Id: I31686e382386a2d08582c86b29dc8f89841040d1
Reviewed-on: https://chromium-review.googlesource.com/535563
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45999}
With the introduction of the fast-cloning double fields in the CSA stub for
literals we forgot to check for deprecated maps. As a result every subsequent
IC-miss would have to migrate the objects from such boilerplates.
This CL makes sure we don't use the deprecated map when copying boilerplates,
thus restoring the original behavior.
Bug: v8:6211 chromium:728682
Change-Id: If9ea1e0c5c6fb4236cb7a82ea33306a600925ac3
Reviewed-on: https://chromium-review.googlesource.com/538677
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45981}
Storing the boilerplate on the first run leads to memory ovehead for code
that is run only once. Hence we directly return the creating literal on the
first run and only start creating copies from the second run on.
Bug: v8:6211
Change-Id: I69b96d124a5b594b991fdbcc76dbf935d973ffad
Reviewed-on: https://chromium-review.googlesource.com/530688
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45975}
This removes the heuristic from {JSStackFrame::IsConstructor} that tried
to infer whether a frame was called as a constructor or not from the
receiver value. We are now carrying along the appropriate bit derived
from the frame type instead.
R=jgruber@chromium.org
TEST=message/regress/regress-5727
BUG=v8:5727
Change-Id: I0e2f1d0f95485c84c4ebcd3cbfe0123c6afd2e01
Reviewed-on: https://chromium-review.googlesource.com/500313
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45972}
For unknown Argument object Maps we have to expect that constants fields
are kept on the Map.
Bug: chromium:729597
Change-Id: I110f77455ce434a431c8de27d021b1a5deb86f30
Reviewed-on: https://chromium-review.googlesource.com/532900
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45935}
Port the baseline implementation of Object.prototype.isPrototypeOf to
the CodeStubAssembler, sharing the existing prototype chain lookup logic
with the instanceof / OrdinaryHasInstance implementation. Based on that,
do the same in TurboFan, introducing a new JSHasInPrototypeChain
operator, which encapsulates the central prototype chain walk logic.
This speeds up Object.prototype.isPrototypeOf by more than a factor of
four, so that the code
A.prototype.isPrototypeOf(a)
is now performance-wise on par with
a instanceof A
for the case where A is a regular constructor function and a is an
instance of A.
Since instanceof does more than just the fundamental prototype chain
lookup, it was discovered in Node core that O.p.isPrototypeOf would
be a more appropriate alternative for certain sanity checks, since
it's less vulnerable to monkey-patching. In addition, the Object
builtin would also avoid the performance-cliff associated with
instanceof (due to the Symbol.hasInstance hook), as for example hit
by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
The main blocker was the missing performance of isPrototypeOf, since
it was still a JS builtin backed by a runtime call.
This CL also adds more test coverage for the
Object.prototype.isPrototypeOf builtin, especially when called from
optimized code.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
BUG=v8:5269,v8:5989,v8:6483
R=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2934893002
Cr-Commit-Position: refs/heads/master@{#45925}
TracingCpuProfiler test updates the current plaform while
concurrent marking is running.
This patch also disables stress-incremental-marking for
mjsunit/regress-430201.
BUG=chromium:694255
Change-Id: I85ff538c47bce0300cde3204989ef3f9512b805f
Reviewed-on: https://chromium-review.googlesource.com/533873
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45921}
The function that generated a pre-shifted immediate didn't account for the
instruction with post-shift being unencodable. Fix this by passing
information about the target instruction, and use it to limit the application
of pre-shift.
BUG=chromium:725858
Change-Id: Ia0f70b2ea057975d90162aa6889f15b553acd321
Review-Url: https://codereview.chromium.org/2922173004
Cr-Commit-Position: refs/heads/master@{#45911}
There exists a hidden assumption in V8 that neither foreground nor
background tasks own any memory. For asynchronous WebAssembly
compilation this assumption was wrong, which causes crashes when V8 shut
down before the compilation finished.
With this CL I change the way asynchrous compilation happens. In the
existing implementation each compilation stage provided its own task
which could be spawned either in foreground or background. With this CL
each stage only provides a state, and a generic CompileTask executes on
that state. There exists exactly one state at a time.
To have exactly one state at a time I combined the stages
ExecuteCompilationUnits and FinishCompilationUnits to a single stage. In
addition I removed the WaitForBackgroundTasks stage and added a
CancelableTaskManager to the AsyncCompileJob instead to do the waiting.
BUG=v8:6436
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I2eb61f74235c65524ce720c474eaf99ae7472c81
Reviewed-on: https://chromium-review.googlesource.com/532993
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45908}
Double element types were much slower than Smi/Object previously.
We can box each double in a HeapNumber and push them into a new
FixedArray to save going into the runtime.
Bug: v8:4826, chromium:704966
Change-Id: I7f15d0d636a52760daefed722265c696c1ebb13e
Reviewed-on: https://chromium-review.googlesource.com/531004
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45897}
This feature has been on by default without incident
since V8 5.8.
Bug: v8:5051
Change-Id: I1baf81922efd87e07448955147c50a5ba5a0aa42
Reviewed-on: https://chromium-review.googlesource.com/532214
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45881}
This adds missing support for in-object properties within objects having
the {JSGeneratorObject} type to materialization during deoptimization.
For corner-cases where the implicit generator object is statically known
not to escape, object layout might still be arbitrarily complex.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-732169
BUG=chromium:732169,v8:6481
Change-Id: I32f373913d60af64981dc4ed66873cc8a1dbe872
Reviewed-on: https://chromium-review.googlesource.com/530230
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45870}
We were emitting the table index once in the element section instead of
once per element segment. This did not cause failures because we never
had more than one element segment.
This CL fixes this, and adds a test for more than one segment.
R=rossberg@chromium.org
Change-Id: I13923baf3dae383c72760286e24242d0ad55c4db
Reviewed-on: https://chromium-review.googlesource.com/527155
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45857}
This adds support for materializing objects of {JSGeneratorObject} type
during deoptimization. Cases where soft-deopts remove any escaping use
of the implicit generator object can cause it to be escape analyzed.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-732169
BUG=chromium:732169
Change-Id: I2ec10b2a509a4f37a456a8ca2fd74b8de2fb55be
Reviewed-on: https://chromium-review.googlesource.com/530847
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45849}
* add functionality to wasm-module-builder.js to emit the module name
in the name section.
* extend WasmModule to store the module name length and offset.
* add functionality to module-decoder.cc to decode the module name.
* use the module name for printing stack traces. more uses should
follow.
* extend one message test to contain a module name.
R=ahaas@chromium.org
Change-Id: I94e6f1f2eb99cb656a92a85bb7afe0742292046f
Reviewed-on: https://chromium-review.googlesource.com/530366
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45846}
This CL removes most occurences of "WASM" from outputs and comments in
the code. They are replaced either by "WebAssembly" or (especially in
comments) "wasm". These are the spellings officially proposed on
http://webassembly.org/.
R=ahaas@chromium.org
BUG=v8:6474
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id39fa5e25591678263745a4eab266db546e65983
Reviewed-on: https://chromium-review.googlesource.com/529085
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45824}
ExpressionClassifier was used just for transmitting information back and forth
to DeclareFormalParameters.
As a bonus, we now do the Scope::IsDeclaredParameter check only when we're going
to use the information it produces.
BUG=v8:6092,v8:6474
Change-Id: Ib5ac6a779705caa74e933e1c6f03eaaf0f49bf05
Reviewed-on: https://chromium-review.googlesource.com/455836
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45809}
This removes the ability of the compilation pipeline to invoke the
Crankshaft optimizing compiler for JavaScript functions. Note that in
this state Crankshaft can still be used to compile code stubs.
R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I0bec7c8ec7c705c13257df43796403a228ea631c
Reviewed-on: https://chromium-review.googlesource.com/527443
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45803}
Both Ignition and TurboFan have been enabled by default for a while.
This just disentangles the implication between those two flags and sets
the --ignition individually. They can now be controlled individually.
R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I08eca85120160efa5868b5ca36d1613964ed82eb
Reviewed-on: https://chromium-review.googlesource.com/527637
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45800}
The variant in question was intended to test Crankshaft, which is being
deprecated. Note that the variants 'nooptimization' and 'fullcode' still
test configuration where TurboFan is not active.
R=machenbach@chromium.org
BUG=v8:6408
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I587c3eee7ba511dfc270aab66b546d2532bc635f
Reviewed-on: https://chromium-review.googlesource.com/528133
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45785}
ThrowIfHole bytecodes were handled by introducing deopt points to check
for a hole. To avoid deopt loops a hole check protector was used to
generate control flow if there was a deopt due to a hole. However, the
normal control flow version should be as fast as the deopt version
in general. The deopt version could potentially consume less compile time
but it may not be worth the complexity added. Hence simplifying it to
only construct the control flow.
Bug: v8:6383
Change-Id: Icace11f7a6e21e64e1cebd104496e3f559bc85f7
Reviewed-on: https://chromium-review.googlesource.com/525573
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45783}
Don't treat new prototypes differently depending on how they become a
prototype. This is work towards always keeping prototypes in slow-mode.
Bug: v8:6471
Change-Id: I62de1018e21d91fda3a5da044615f32c718910b1
Reviewed-on: https://chromium-review.googlesource.com/526596
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45781}
This adds block coverage support for simple iteration. For-of and
for-in loops are not yet covered, and we don't yet keep execution counts
for init, cond, and next statements.
BUG=v8:6000
Change-Id: I30b468a2c93f0bb60e857b6632be92920f6857e0
Reviewed-on: https://chromium-review.googlesource.com/527113
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45779}
The two variants "turbofan" and "turbofan_opt" are not part of any of
the default sets of variants that run-tests.py uses. The only way to
trigger execution would be via the --variants flag directly, which our
infrastructure is not doing.
R=machenbach@chromium.org
Change-Id: Ifa58cb4a83a3760ffba73e8b40b417a845f53506
Reviewed-on: https://chromium-review.googlesource.com/526637
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45772}
