In some [1] cases where a lexical declaration is not allowed, ASI will
cause a `let` at the end of a line to be interpreted as an
identifier. A recent patch [2] to fix up the error messages from
misplaced `let` usage was a little overzealous in triggering
the error, throwing a SyntaxError in this edge case. This patch
restores the ASI behavior, which is permitted in JSC and
SpiderMonkey as well. Thanks to a test262 test from Andre Bargull
for raising this issue.
[1] https://tc39.github.io/ecma262/#sec-expression-statement
[2] https://codereview.chromium.org/2697193007
Bug: v8:3305
Change-Id: I80ae8ad9a8a93389ff1003323f0d3f003e7a8c8e
Reviewed-on: https://chromium-review.googlesource.com/529225
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45817}
And in one case just remove it since it is superflous.
R=mstarzinger@chromium.org
BUG=v8:6474
Change-Id: I60bfac75f5d65a56c7ca8d67923e9314ec703eac
Reviewed-on: https://chromium-review.googlesource.com/529244
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45816}
This reduces confusion with GC write barrier. The word "barrier" is
reserved for GC write barrier and "fence" for memory ordering fence.
BUG=v8:6474
Change-Id: Ic4352f04430eaca742b72db1580ee0a42a1ffefb
Reviewed-on: https://chromium-review.googlesource.com/528103
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45813}
The wasm-code fuzzer used different parameters for the interpreter and
the generated code due to a typo. This typo is fixed by this CL.
R=clemensh@chromium.org
Change-Id: Ia9c72b83e7722e0a8b3fe6efb3f4b32ca5c937ab
Reviewed-on: https://chromium-review.googlesource.com/527447
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45812}
Also, as this is hard to track down, always DCHECK position after ReadBlock().
Change-Id: Ie32c3a311dd8df91f651b6d82ccacc7c95e6fde0
Reviewed-on: https://chromium-review.googlesource.com/528196
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45811}
base::Optional is a replacement for std::optional, until we switch to
C++17 and can use std::optional directly.
The implementation is copied from chromium's base::Optional, but put in
the {v8::base} namespace instead of just {base}. Also, the
specialization of std::hash for base::Optional is omitted, since it's
disallowed in the style guide.
A first use in the AsmJsParser is introduced, if that one sticks, I
will refactor more uses of std::unique_ptr to use base::Optional
instead, avoiding the heap allocation.
R=mstarzinger@chromium.org
BUG=v8:6474
Change-Id: I019599d4bf9ff0105bf592dfb96d6050feba18ae
Reviewed-on: https://chromium-review.googlesource.com/528884
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45810}
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}
All the bytecode handlers were added a one test, so we would get a
total on all of the bytecode handler benchmarks. It is not a good
indicator when we total unrelated benchmarks. So added more categories
to group only related benchmarks together. This also makes it easier
to look at the results.
Bug: chromium:730628
Change-Id: I1c5858f40c1ce584c4b7bd833a7f3c52a43d07c6
Reviewed-on: https://chromium-review.googlesource.com/527436
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45808}
The mips/mips64 port of http://crrev.com/2909893002. Original commit message:
DebugInfo was very closely tied to break point support:
* It contained only information relevant to break points.
* It was created and freed by break point implementation.
* Existence of a DebugInfo on the shared function info implied existence of
break points.
This CL is a step towards making DebugInfo usable by other debugging
functionality such as block coverage by decoupling it from break point support,
which is now only one kind of information stored on the DebugInfo object.
BUG=v8:6000
Change-Id: Ia770ff3c048022652d8abbe30d372fde5cb452a4
Reviewed-on: https://chromium-review.googlesource.com/528112
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45807}
This makes popping from the marking deque safe for concurrent marking.
BUG=chromium:694255
Change-Id: I3edf8ece3d3c3dd8f045b3ea2f8196b322a56a54
Reviewed-on: https://chromium-review.googlesource.com/527154
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45806}
In some codes flushing the registers was costly: we processed each
register whereas all the registers alone in their equivalence class need
not to be processed. We now overapproximate easily which classes are of
size 2 so as to save many iterations in the Flush() loop in some cases.
Bug: v8:6432
Change-Id: I945e151736e8a515263ac76312127d930fd20d74
Reviewed-on: https://chromium-review.googlesource.com/525795
Commit-Queue: Alexandre Talon <alexandret@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45805}
Use convenient macros for accessing bit fields.
Bug: v8:6470
Change-Id: Iada9779ce56c7ca2e8b6a9617c236e294db7325e
Reviewed-on: https://chromium-review.googlesource.com/527432
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45804}
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}
In sloppy mode, allow multiply labelled function declarations, such as
a: b: function c() {}
Such a form is allowed by the specification, as well as ChakraCore,
SpiderMonkey and JSC (though ChakraCore because it doesn't enforce
any lexical label restrictions.)
Thanks to Andre Bargull for adding the test262 test which caught the bug.
Change-Id: I2d3f172830c2e63252f00afa03177a7d17d79a27
Reviewed-on: https://chromium-review.googlesource.com/527639
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45802}
The JSCreateClosure operator was not marked as Eliminatable, esp. it
wasn't marked as NoWrite (read: no JavaScript observable side-effect),
which lead to a weird performance cliff with the new Array builtin
inlining. For example
a.forEach(c => c);
was not inlined, whereas
const f = c => c;
a.forEach(f);
was properly inlined, despite not causing any trouble for TurboFan in
general. The reason was that the JSCreateClosure for the arrow function
was marked as "can cause potential side effect", which it cannot. This
fixes the operator to be properly marked as Eliminatable, thus removing
this performance cliff.
BUG=v8:1956,v8:6475
R=danno@chromium.org
Review-Url: https://codereview.chromium.org/2930933002
Cr-Commit-Position: refs/heads/master@{#45801}
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}
Port 90c3a2d54b
Original Commit Message:
This CL contains a few pieces:
- A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
graphs, which--when triggered--swizzle the values in the the FrameState to be
parameters to a typically TF-generated builtin that resumes execution to finish
the slow-case functionality.
- Continuation builtins that have special handling in the deoptimizer and their own
new frame type to ensure that the values they need to begin executing can be stashed
away and restored immediately before the builtin is called via a trampoline that runs
when the continuation builtin's frame execution resumes.
- An implementation of Array.prototype.forEach in TurboFan that can be used to
inline it. The inlined forEach implementation uses the checkpoints mechanism
described above to deopt in the middle of the forEach in the cases that optimization
invariants are violated. There is a slightly different continuation stub for each
deopt point in the forEach implementation to ensure the correct side-effects, i.e.
that the deopt of the builtin isn't programmatically observable.
R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2926043005
Cr-Commit-Position: refs/heads/master@{#45798}
Port d3371c23cb
Original Commit Message:
DebugInfo was very closely tied to break point support:
* It contained only information relevant to break points.
* It was created and freed by break point implementation.
* Existence of a DebugInfo on the shared function info implied existence of
break points.
This CL is a step towards making DebugInfo usable by other debugging
functionality such as block coverage by decoupling it from break point support,
which is now only one kind of information stored on the DebugInfo object.
R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6000
LOG=N
Review-Url: https://codereview.chromium.org/2927813004
Cr-Commit-Position: refs/heads/master@{#45796}
- Eliminates b1x4, b1x8, and b1x16 as distinct WASM types.
- All vector comparisons return v128 type.
- Eliminates b1xN and, or, xor, not.
- Selects take a v128 mask vector and are now bit-wise.
- Adds a new test for Select, where mask is non-canonical (not 0's and -1's).
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2919203002
Cr-Commit-Position: refs/heads/master@{#45795}
This splits the monolithic Apply builtin into several smaller builtins,
namely CallVargargs and ConstructVarargs, which accept a length and a
FixedArray of elements and deal with the actual stack manipulation, and
CallWithArrayLike / ConstructWithArrayLike that deal with getting the
elements from the receiver (for Function.prototype.apply, Reflect.apply
and Reflect.construct), which can now be written using the CSA.
The idea is that these builtins can be reused by TurboFan directly in
the future when we optimize apply better, and that we can also reuse the
core logic in the handling of spread calls/constructs.
R=petermarshall@chromium.org
BUG=v8:4587,v8:5269
Review-Url: https://codereview.chromium.org/2930623002
Cr-Commit-Position: refs/heads/master@{#45794}
Port 659e8f7b5c
Original Commit Message:
Instead of allocating and embedding certain heap numbers into the code
during code assembly, emit dummies but record the allocation requests.
Later then, in Assembler::GetCode, allocate the heap numbers and patch
the code by replacing the dummies with the actual objects. The
RelocInfos for the embedded objects are already recorded correctly when
emitting the dummies.
R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6048
LOG=N
Review-Url: https://codereview.chromium.org/2929843002
Cr-Commit-Position: refs/heads/master@{#45793}
concurrent sweeping is disabled, which is not correct.
MemoryAllocator: :CanFreeMemoryChunk returns true for the case when
Change-Id: I560bac0275473445b52fba28b5e647b54f523a3a
Reviewed-on: https://chromium-review.googlesource.com/528081
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45792}
This CL takes advantage of the fact that StatsCounter is now local to
the Counters class. This includes:
1) Method StatsTable::SetCreateHistogramFunction() was only called in
one spot (in api.cc), which also called Counters::ResetHistograms()
and Counters::InitializeHistorgram(). InitializeHistogram can be
folded into Histogram.Reset().
2) Since Histogram::Reset() now regenerats the histogram, we no longer
need the field lookup_done_. Therefore there is no longer a race
between updating ptr_ and lookup_done_, making the Histogram class
thread safe.
3) Made the constructors of several classes private (except for class
Counters), minimizing the scope that they are used. When the couldn't
be moved, add comment that they were public only for test cases.
4) Removed the need for a mutex lock on StatsCounter::Reset(), since
it is now guaranteed to only be called when
StatsTable::SetCounterFunction() is called.
BUG=v8:6361
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.chromium.org/2918703002
Cr-Commit-Position: refs/heads/master@{#45791}
Both TurboFan and ThinStrings have been enabled by default for a while.
This just disentangles the implication between those two flags and sets
the --thin-strings individually. There is no technical reason for the
implication.
R=jkummerow@chromium.org
Change-Id: I26e5357ffaf953de897c76d6edb8ac640bbeafd0
Reviewed-on: https://chromium-review.googlesource.com/528076
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45789}
Add the ability for the typer to track whether a string could be the empty
string. This is needed for typed lowering of JSStringConcat since we can't
create cons string chain with the empty string in arbitrary positions.
The ToPrimitiveToString bytecode handler is modified to collect feedback on
whether it has ever seen the empty string, which is used by
SpeculativeToPrimitiveToString to ensure that the output is non-empty (or
depot) which will subsiquently be used to enable inline cons-string creation
for the JSStringConcat operator in typed lowering in a subsiquent CL.
BUG=v8:6243
Change-Id: I41b99b59798993f756aada8cff90fb137d65ea52
Reviewed-on: https://chromium-review.googlesource.com/522122
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45786}
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}
This removes the last remaining dual implications between sets of flags.
Support for this was originally added to support multiple subsequent
calls to {SetFlagFromString} switching a set of flags on and off. Now
that Chrome no longer relies on this behavior we can remove support for
this entirely.
Original CL: https://crrev.com/f774d8c56f00de92614886fc4cb541411eff7aa1R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I5f9db8457c562c0b434ea7d6eca9941c76fe7d19
Reviewed-on: https://chromium-review.googlesource.com/527174
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@{#45782}
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}
Array buffers can now have an allocation that is larger than the actual
buffer, such as when WebAssembly guard regions are enabled. Embedders
need to know the actual allocation start and length when externalizing
a buffer so they can deallocate it properly.
Bug: chromium:720302, v8:5277
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ifc184fdd59d77af01c07a64d2c0229ca859a01b0
Reviewed-on: https://chromium-review.googlesource.com/523271
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45777}
Calling `read(filename, 'binary')` should return an ArrayBuffer like
SpiderMonkey does. It is possible to call `readbuffer` instead, but that
function is not available in the SpiderMonkey JS shell.
BUG=v8:6464
R=bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2922353002
Cr-Commit-Position: refs/heads/master@{#45776}
Store the rest raw data fields as ints.
Bug: v8:6470
Change-Id: I3d4ab56a722ed6c0b5cb30ecee2d94d7c8f07b40
Reviewed-on: https://chromium-review.googlesource.com/526638
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45775}
Store 'length' and 'formal_parameter_count' fields as raw ints.
Also fixed a couple of issues on the way.
TBR=verwaest@chromium.org
Bug: v8:6470
Change-Id: I74ecd87cb0f041e61dab50d8bc29e3604dd1d09c
Reviewed-on: https://chromium-review.googlesource.com/527156
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45774}
This CL extracts the classes CompilationHelper, InstantiationHelper,
and AsyncCompileJob from wasm-module.cc and puts them into
module-compiler.{h|cc}. This is necessary to introduce a
WasmCompilationManager which is known to the isolate and manages the
lifetime of all AsyncCompileJobs.
In addition to the mechanical changes of copying the code and splitting
class declaration from instantiation, I did the following changes:
* I renamed the CompilationHelper to ModuleCompiler.
* A finalizer function is passed to the InstantiationHelper as a
parameter.
* Adjusted UpdateDispatchTable in wasm-module.cc to make it available in
wasm-module.h, also with the internal signature.
* Duplicate the ResolvePromise/RejectPromise helper functions.
I did not rename InstantiationHelper because I could not come up with a
good name, and it could benefit from a small special refactoring anyways.
BUG=v8:6436
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I4abe854c36dfc995b34c9d7b3e7ec0f4f0aa562e
Reviewed-on: https://chromium-review.googlesource.com/525572
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45773}
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}
