Named capture groups may be specified using the /(?<name>pattern)/u
syntax, with named backreferences specified as /\k<name>/u. They're
hidden behind the --harmony-regexp-named-captures flag, and are only
enabled for unicode regexps.
R=yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2050343002
Cr-Commit-Position: refs/heads/master@{#36986}
We'd like to track performance metrics in an automated way. This CL introduces
--turbo-stats-nvp which exposes --turbo-stats information in {"name"=value} pair
format.
BUG=
Review-Url: https://codereview.chromium.org/2053383002
Cr-Commit-Position: refs/heads/master@{#36919}
We were able to achieve our goals for register allocation independent of
the allocation algorithm. Performance data so far is inconclusive re. the
value of the Greedy algorithm, compared to the particular Linear Scan
implementation we're currently using, and the performance measurement
techniques we currently use are too imprecise to help with this matter.
Retiring the algorithm to lower maintenance and evolution cost (e.g. lower
cost of adding aliasing support). Once we improve benchmarking stability,
and establish a suite sensitive enough for codegen improvement studies,
we may revive the algorithm, should the need arise.
BUG=
Review-Url: https://codereview.chromium.org/2060673002
Cr-Commit-Position: refs/heads/master@{#36912}
This CL sets the default value of the flag wasm_num_compilation_tasks to 10.
The actual number of compilation tasks is the minimum of the flag value and
V8::GetCurrentPlatform()->NumberOfAvailableBackgroundThreads(), which is 8
on my machine.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2054093002
Cr-Commit-Position: refs/heads/master@{#36892}
With this change the bytecode array builder only emits expression
positions for bytecodes that can throw. This allows more peephole
optimization opportunities and results in smaller code.
BUG=v8:4280,chromium:615979
LOG=N
Review-Url: https://codereview.chromium.org/2038323002
Cr-Commit-Position: refs/heads/master@{#36863}
The stubs do not increase respective counters as they are in the snapshot and --native-code-counters is off during snapshot creation anyway.
Review-Url: https://codereview.chromium.org/2031753003
Cr-Commit-Position: refs/heads/master@{#36754}
This introduces optimized number operations based on type feedback.
Summary of changes:
1. Typed lowering produces SpeculativeNumberAdd/Subtract for JSAdd/Subtract if
there is suitable feedback. The speculative nodes are connected to both the
effect chain and the control chain and they retain the eager frame state.
2. Simplified lowering now executes in three phases:
a. Propagation phase computes truncations by traversing the graph from uses to
definitions until checkpoint is reached. It also records type-check decisions
for later typing phase, and computes representation.
b. The typing phase computes more precise types base on the speculative types (and recomputes
representation for affected nodes).
c. The lowering phase performs lowering and inserts representation changes and/or checks.
3. Effect-control linearization lowers the checks to machine graphs.
Notes:
- SimplifiedLowering will be refactored to have handling of each operation one place and
with clearer input/output protocol for each sub-phase. I would prefer to do this once
we have more operations implemented, and the pattern is clearer.
- The check operations (Checked<A>To<B>) should have some flags that would affect
the kind of truncations that they can handle. E.g., if we know that a node produces
a number, we can omit the oddball check in the CheckedTaggedToFloat64 lowering.
- In future, we want the typer to reuse the logic from OperationTyper.
BUG=v8:4583
LOG=n
Review-Url: https://codereview.chromium.org/1921563002
Cr-Commit-Position: refs/heads/master@{#36674}
Reason for revert:
All known async/await issues are fixed; turn back on Clusterfuzz
Original issue's description:
> Revert of [ESNext] Activate async/await for ClusterFuzz (patchset #1 id:1 of https://codereview.chromium.org/1992173002/ )
>
> Reason for revert:
> First CF feedback is in, reverting for now until the know bugs are fixed.
>
> Original issue's description:
> > [ESNext] Activate async/await for ClusterFuzz
> >
> > BUG=v8:4483
> > R=neis@chromium.org,littledan@chromium.org,caitpotter88@gmail.com
> > LOG=N
> >
> > Committed: https://crrev.com/c57cadfa09fa493141bf43c1c7b898187a71da19
> > Cr-Commit-Position: refs/heads/master@{#36362}
>
> TBR=littledan@chromium.org,caitpotter88@gmail.com,neis@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4483
>
> Committed: https://crrev.com/eb059498b2b2d05731b0dce648bdab801d3873fd
> Cr-Commit-Position: refs/heads/master@{#36397}
TBR=caitpotter88@gmail.com,neis@chromium.org,mstarzinger@chromium.org,hablich@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:4483
Review-Url: https://codereview.chromium.org/2023003002
Cr-Commit-Position: refs/heads/master@{#36639}
We now have data that 0.011% of websites use the pattern
for (var i = 0 in j) { ... }
This pattern was banned by ES2015, with the idea to revisit if
it presents a web compatibility problem. Informally, after
the May 2016 TC39 meeting, the new data was discussed, and there
was interest in reversing the decision. Although the specification
is not yet updated, it seems likely to come soon.
This patch turns off the flag which bans that construct, reenabling
it. The change should prevent websites from breaking.
BUG=v8:4942
Review-Url: https://codereview.chromium.org/2011223003
Cr-Commit-Position: refs/heads/master@{#36562}
Annex B 3.3 applies only for ordinary FunctionDeclarations, not
GeneratorDeclarations or AsyncFunctionDeclarations. This patch
- Skips applying Annex B 3.3 to async functions
- Adds a flag to refrain from applying it to generators
- UseCounter for how often duplicate function in block occurs
with generators (unclear how to measure need for hoisting from block)
BUG=v8:4806
Review-Url: https://codereview.chromium.org/1995863002
Cr-Commit-Position: refs/heads/master@{#36557}
This interpreter directly decodes and executes WASM binary code for
the purpose of supporting low-level debugging. It is not currently
integrated into the main WASM implementation.
R=ahaas@chromium.org,clemensh@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/1972153002
Cr-Commit-Position: refs/heads/master@{#36497}
Instead of having two lists of harmony flags, one with i18n and
one without, use a bit more macro programming.
Review-Url: https://codereview.chromium.org/2001753003
Cr-Commit-Position: refs/heads/master@{#36450}
This flag has been on by default for a while, along with
FLAG_track_prototype_users which provides the prerequisite
infrastructure. We are now sure that this is the direction
we want to go in, so in order to simplify the code, this CL
drops the respective flag-off code paths.
Review-Url: https://codereview.chromium.org/1993913002
Cr-Commit-Position: refs/heads/master@{#36445}
Reason for revert:
First CF feedback is in, reverting for now until the know bugs are fixed.
Original issue's description:
> [ESNext] Activate async/await for ClusterFuzz
>
> BUG=v8:4483
> R=neis@chromium.org,littledan@chromium.org,caitpotter88@gmail.com
> LOG=N
>
> Committed: https://crrev.com/c57cadfa09fa493141bf43c1c7b898187a71da19
> Cr-Commit-Position: refs/heads/master@{#36362}
TBR=littledan@chromium.org,caitpotter88@gmail.com,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4483
Review-Url: https://codereview.chromium.org/2003503002
Cr-Commit-Position: refs/heads/master@{#36397}
Move it to HARMONY_STAGED from HARMONY_INPROGRESS.
Update test262.status now that case mapping tests are passing with
'--harmony' specified.
BUG=v8:4476,v8:4477
LOG=Y
TEST=test262/{built-ins,intl402}/Strings/*, webkit/fast/js/*,
mjsunit/string-case, intl/general/case*
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_noi18n_rel_ng
Review-Url: https://codereview.chromium.org/1990083002
Cr-Commit-Position: refs/heads/master@{#36379}
The MLS instruction is available in all ARMv7 devices, and in no ARMv6
devices, aside from the usual ARMv6T2 caveat. We don't need a separate
feature flag for it.
BUG=
Review-Url: https://codereview.chromium.org/1988133004
Cr-Commit-Position: refs/heads/master@{#36378}
The default value of the flag was true, so --intl_extra was not previously
unshipped. This patch sets it to false.
BUG=v8:3785
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_noi18n_rel_ng
Review-Url: https://codereview.chromium.org/1990763003
Cr-Commit-Position: refs/heads/master@{#36346}
This promotes the escape analysis from an experimental feature to be a
fully supported feature. The main goal is to unleach ClusterFuzz on the
implementation so that we can stabilize it.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1989833002
Cr-Commit-Position: refs/heads/master@{#36324}
This adds back the instanceof operator support in the backends and
introduces a @@hasInstance protector cell on the isolate that guards the
fast path for the InstanceOfStub. This way we recover the ~10%
regression on Octane EarleyBoyer in Crankshaft and greatly improve
TurboFan and Ignition performance of instanceof.
R=ishell@chromium.orgTBR=hpayer@chromium.org,rossberg@chromium.org
BUG=chromium:597249, v8:4447
LOG=n
Review-Url: https://codereview.chromium.org/1980483003
Cr-Commit-Position: refs/heads/master@{#36275}
This change introduces a pipeline for the final stages of
bytecode generation.
The peephole optimizer is made distinct from the BytecodeArrayBuilder.
A new BytecodeArrayWriter is responsible for writing bytecode. It
also keeps track of the maximum register seen and offers a potentially
smaller frame size.
R=rmcilroy@chromium.org
LOG=N
BUG=v8:4280
Review-Url: https://codereview.chromium.org/1947403002
Cr-Commit-Position: refs/heads/master@{#36220}
This adds the --validate-asm flag which will trigger validation of all
asm.js modules before they are being compiled. In case a module doesn't
pass validation, a warning will be printed, but compilation as well as
execution will continue unhampered.
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/1972593002
Cr-Commit-Position: refs/heads/master@{#36216}
With this CL it is possible to compile a wasm module with multiple
threads in parallel. Parallel compilation works as follows:
1) The main thread allocates a compilation unit for each wasm function.
2) The main thread spawns WasmCompilationTasks which run on the
background threads.
3.a) The background threads and the main thread pick one compilation unit
at a time and execute the parallel phase of the compilation unit.
After finishing the execution of the parallel phase, the compilation
unit is stored in a result queue.
3.b) If the result queue contains a compilation unit, the main thread
dequeues it and finishes its compilation.
4) After the execution of the parallel phase of all compilation units has
started, the main thread waits for all WasmCompilationTasks to finish.
5) The main thread finalizes the compilation of the module.
I'm going to add some additional tests before committing this CL.
R=titzer@chromium.org, bmeurer@chromium.org, mlippautz@chromium.org, mstarzinger@chromium.org
Committed: https://crrev.com/17215438659d8ff2d7d55f95226bf8a1477ccd79
Cr-Commit-Position: refs/heads/master@{#36178}
Review-Url: https://codereview.chromium.org/1961973002
Cr-Commit-Position: refs/heads/master@{#36207}
This patch removes the following properties, as their use count is
very low, they are V8-only, and not on a standards track.
- v8Parse
- resolved
- pattern
v8BreakIterator is left in as it has significantly more usage.
BUG=v8:3785
R=adamk,jshin@chromium.org
Review-Url: https://codereview.chromium.org/1968893002
Cr-Commit-Position: refs/heads/master@{#36190}
When I18N is enabled, use ICU's case conversion API and transliteration
API [1] to implement String.prototype.to{Upper,Lower}Case and
String.prototype.toLocale{Upper,Lower}Case.
* ICU-based case conversion was implemented in runtime-i18n.cc/i18n.js
* The above 4 functions are overridden with those in i18n.js when
--icu_case_mapping flag is turned on. To control the override by the flag,
they're overriden in icu-case-mapping.js
Previously, toLocale{U,L}Case just called to{U,L}Case so that they didn't
support locale-sensitive case conversion for Turkic languages (az, tr),
Greek (el) and Lithuanian (lt).
Before ICU APIs for the most general case are called, a fast-path for Latin-1
is tried. It's taken from Blink and adopted as necessary. This fast path
is always tried for to{U,L}Case. For toLocale{U,L}Case, it's only taken
when a locale (explicitly specified or default) is not in {az, el, lt, tr}.
With these changes, a build with --icu_case_mapping=true passes a bunch
of tests in test262/intl402/Strings/* and intl/* that failed before.
Handling of pure ASCII strings (aligned at word boundary) are not as fast
as Unibrow's implementation that uses word-by-word case conversion. OTOH,
Latin-1 input handling is faster than Unibrow. General Unicode input
handling is slower but more accurate.
See https://docs.google.com/spreadsheets/d/1KJCJxKc1FxFXjwmYqABS0_2cNdPetvnd8gY8_HGSbrg/edit?usp=sharing for the benchmark.
This CL started with http://crrev.com/1544023002#ps200001 by littledan@,
but has changed significantly since.
[1] See why transliteration API is needed for uppercasing in Greek.
http://bugs.icu-project.org/trac/ticket/10582
R=yangguo
BUG=v8:4476,v8:4477
LOG=Y
TEST=test262/{built-ins,intl402}/Strings/*, webkit/fast/js/*, mjsunit/string-case,
intl/general/case*
Review-Url: https://codereview.chromium.org/1812673005
Cr-Commit-Position: refs/heads/master@{#36187}
Reason for revert:
The ThreadSanitizer finds data races.
Original issue's description:
> [wasm] Implement parallel compilation.
>
> With this CL it is possible to compile a wasm module with multiple
> threads in parallel. Parallel compilation works as follows:
>
> 1) The main thread allocates a compilation unit for each wasm function.
> 2) The main thread spawns WasmCompilationTasks which run on the
> background threads.
> 3.a) The background threads and the main thread pick one compilation unit
> at a time and execute the parallel phase of the compilation unit.
> After finishing the execution of the parallel phase, the compilation
> unit is stored in a result queue.
> 3.b) If the result queue contains a compilation unit, the main thread
> dequeues it and finishes its compilation.
> 4) After the execution of the parallel phase of all compilation units has
> started, the main thread waits for all WasmCompilationTasks to finish.
> 5) The main thread finalizes the compilation of the module.
>
> I'm going to add some additional tests before committing this CL.
>
> R=titzer@chromium.org, bmeurer@chromium.org, mlippautz@chromium.org, mstarzinger@chromium.org
>
> Committed: https://crrev.com/17215438659d8ff2d7d55f95226bf8a1477ccd79
> Cr-Commit-Position: refs/heads/master@{#36178}
TBR=bmeurer@chromium.org,mlippautz@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/1965243003
Cr-Commit-Position: refs/heads/master@{#36182}
With this CL it is possible to compile a wasm module with multiple
threads in parallel. Parallel compilation works as follows:
1) The main thread allocates a compilation unit for each wasm function.
2) The main thread spawns WasmCompilationTasks which run on the
background threads.
3.a) The background threads and the main thread pick one compilation unit
at a time and execute the parallel phase of the compilation unit.
After finishing the execution of the parallel phase, the compilation
unit is stored in a result queue.
3.b) If the result queue contains a compilation unit, the main thread
dequeues it and finishes its compilation.
4) After the execution of the parallel phase of all compilation units has
started, the main thread waits for all WasmCompilationTasks to finish.
5) The main thread finalizes the compilation of the module.
I'm going to add some additional tests before committing this CL.
R=titzer@chromium.org, bmeurer@chromium.org, mlippautz@chromium.org, mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/1961973002
Cr-Commit-Position: refs/heads/master@{#36178}
The data from UseCounters are in--V8's custom Promise methods are not
in wide use on the web (<.002%). Therefore, this patch removes them.
That includes:
- Promise.prototype.chain
- Promise.defer -- the most widely used of the bunch
- Promise.accept
For now, those methods are still available by checking the "disable
latest stable JavaScript features" flag, or --promise-extra at the
command line, but I expect them to be fully removable.
R=adamk
CC=rossberg
BUG=v8:3238,v8:4633
Review-Url: https://codereview.chromium.org/1965183002
Cr-Commit-Position: refs/heads/master@{#36152}
The flag in question used to fall-back to Crankshaft whenever an OSR
request couldn't be handled by TurboFan. By now OSR in TurboFan is
sufficiently stabilized that one single --use-osr flag should do it.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/1960043002
Cr-Commit-Position: refs/heads/master@{#36102}
Since Ignition dispatch counters have been made accessible from
JavaScript via getIgnitionDispatchCounters() in [1], writing
them to a file at the end of the execution does not seem the best
default anymore.
Following this commit, a file is written only if d8 is invoked
with --trace-ignition-dispatches-output-file.
[1] https://crrev.com/905becd13b8696e126255decf130fdb9e1d9aa30
LOG=N
BUG=v8:4899
Review-Url: https://codereview.chromium.org/1943923002
Cr-Commit-Position: refs/heads/master@{#36015}
This adds a dedicated flag for enabling the BytecodeGraphBuilder. The
intention is to be explicit when this variant is being tested and to
avoid unnecessary overhead in production code for a configuration that
is not yet shipping.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/1925123002
Cr-Commit-Position: refs/heads/master@{#35892}
I introduced a new flag, --wasm-parallel-compilation, which turns on
parallel compilation of wasm modules. If parallel compilation is turned
on, then the compilation of wasm functions is split into three phases,
initialization, execution, and finalization. The execution phase is the
phase which is going to contain all the code that can be executed in
parallel. At the moment the execution phase is still empty.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/1928933002
Cr-Commit-Position: refs/heads/master@{#35875}
Trace-opt/trace-deopt output is ambiguous if multiple functions share
the same name. This change adds file names to this output behind the
--trace-file-names flag to reduce this ambiguity.
R=ofrobots@google.com
BUG=
Review URL: https://codereview.chromium.org/1920873003
Cr-Commit-Position: refs/heads/master@{#35824}
The feature was deprecated in M49 and flagged off in M50.
This patch removes it entirely from the codebase.
Review URL: https://codereview.chromium.org/1909433003
Cr-Commit-Position: refs/heads/master@{#35714}
In a full mark-compact GC, instead of copying memory to old space for
pages that have more than X% live bytes, we just move the whole page over to old
space.
X=70 (default value)
BUG=chromium:581412
LOG=N
TBR=hpayer@chromium.org
This reverts commit 8b3337278f.
Review URL: https://codereview.chromium.org/1901093002
Cr-Commit-Position: refs/heads/master@{#35649}
In a full mark-compact GC, instead of copying memory to old space for
pages that have more than X% live bytes, we just move the whole page over to old
space.
X=70 (default value)
BUG=chromium:581412
LOG=N
Review URL: https://codereview.chromium.org/1863983002
Cr-Commit-Position: refs/heads/master@{#35610}
This prefixes the escape analysis flag with "experimental", thereby
making sure the flag in question is not being fuzzed. It will reduce
noise levels on ClusterFuzz again.
R=jarin@chromium.org
BUG=chromium:603653
LOG=n
Review URL: https://codereview.chromium.org/1894513002
Cr-Commit-Position: refs/heads/master@{#35521}
We had exactly one test case for --noturbo-types, so it's likely that
the generic pipeline (without types) was already broken for quite some
time, plus no one expressed interest in maintaining it, plus it
complicates the JSGenericLowering integration. So decision is to kill
it.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1872333002
Cr-Commit-Position: refs/heads/master@{#35387}
When FLAG_trace_ignition_dispatches is enabled, a dispatch counter is
kept for each pair of source-destination bytecode handlers.
Each counter saturates at max uintptr_t value.
Counters are dumped as a JSON-encoded object of objects, such that
each key on the top level object is a source bytecode name, and each key
on the corresponding value is a destination bytecode name, with the
associated counter as value. The output file name can be controlled
with the FLAG_trace_ignition_dispatches_output_file flag.
The JSON file may be written by calling
Interpreter::WriteDispatchCounters(), which is done for d8 in
Shell::OnExit, if FLAG_trace_ignition_dispatches is enabled.
BUG=v8:4899
LOG=N
Review URL: https://codereview.chromium.org/1828633003
Cr-Commit-Position: refs/heads/master@{#35380}
Reason for revert:
breaks some chromium browser_tests: https://codereview.chromium.org/1848233002/
Original issue's description:
> Ship --harmony-regexp-exec
>
> There are still spec compliance fixes to be made, but this patch
> turns the flag to shipping to make sure we get more canary coverage
> and performance data from the bots.
>
> BUG=v8:4602
> LOG=y
>
> Committed: https://crrev.com/84492bb66b340f4e0df36758e98fddbb10b5d1dc
> Cr-Commit-Position: refs/heads/master@{#35181}
TBR=littledan@chromium.org,adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4602
Review URL: https://codereview.chromium.org/1852673003
Cr-Commit-Position: refs/heads/master@{#35198}
There are still spec compliance fixes to be made, but this patch
turns the flag to shipping to make sure we get more canary coverage
and performance data from the bots.
BUG=v8:4602
LOG=y
Review URL: https://codereview.chromium.org/1847103002
Cr-Commit-Position: refs/heads/master@{#35181}
Embedders that rely on unmodified wrappers to survive should pass the command-line flag --noscavenge_reclaim_unmodified_objects
BUG=4880
LOG=yes
Review URL: https://codereview.chromium.org/1839243005
Cr-Commit-Position: refs/heads/master@{#35164}
Difference from --perf-basic-prof:
- correctly attributes samples when code space gets reused (when unused code object dies and a new code objects is allocated at the same place).
- outputs compiled machine code for instruction-level profile.
Just like --perf-basic-prof, the file writer is not synchronized (even worse, there is a per-isolate file handle), so we will run into trouble with multiple isolates. However, this patch is still an improvement on --perf-basic-prof, and it should be fine to replace ll-prof.
The patch also introduces experimental support for debug info, but it does not seem to be picked by the perf tool.
Usage:
You need the perf tool from Linux kernel >4.5. Then run:
$ perf record -k mono d8 --perf-prof <your JS file>
$ perf inject -j -i perf.data -o perf.data.jitted
$ perf report -i perf.data.jitted
Some explanations:
The "-k mono" switch from "perf record" tells the perf tool to use the monotonic clock for perf sample timestamping. The "perf inject -j" command injects the collected code events into the perf data file, writing the output into perf.data.jitted. The perf report command then creates the report.
Review URL: https://codereview.chromium.org/1809203007
Cr-Commit-Position: refs/heads/master@{#35091}
It's been on since M49. Also moved tests from harmony -> es6,
one of which was merged with another test of the same name.
While moving stuff over to regexp.js, I also noticed that there
were unused calls to %FunctionSetName and %SetNativeFlag (those
calls are already handled by InstallGetter()).
Review URL: https://codereview.chromium.org/1838563003
Cr-Commit-Position: refs/heads/master@{#35076}
This patch implements ES2015 RegExp subclassing semantics, namely the
hardest part where RegExp.prototype.exec and certain flag getters can
be overridden in order to provide different behavior. This change is
hidden behind a new flag, --harmony-regexp-exec. The flag guards the
behavior by installing entirely different implementations of the
methods which follow the new semantics.
Preliminary performance tests show a 3-4x regression in the Octane
RegExp benchmark. The new code doesn't call out into several fast
paths that the old code supported, so this is expected.
The patch is tested mostly by test262, where most RegExp tests are fixed,
with the exception of deliberate spec violations for web compatibility,
and for the 'sticky' flag, which is not dynamically read by this patch
in all cases but rather statically compiled into the RegExp. The latter
will require a follow-on patch to implement. A small additional set of
tests verifies one particular case, mostly to check whether the flag
mechanism works.
R=adamk,yangguo@chromium.org
LOG=Y
BUG=v8:4602
Review URL: https://codereview.chromium.org/1596483005
Cr-Commit-Position: refs/heads/master@{#35068}
Makes --ignition cause eager compilation if we aren't building the startup
snapshot.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1811553003
Cr-Commit-Position: refs/heads/master@{#35066}
Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.
In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.
Also gone are any tests which relied on legacy const declarations.
Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.
Review URL: https://codereview.chromium.org/1819123002
Cr-Commit-Position: refs/heads/master@{#35002}
Flags --dump_wasm_module and --dump_wasm_module_path=/path/to/folder allow us to run a bunch of tests and capture all of the wasm module files including the ones that come from the .js and .cc tests which are built on the fly, as well as the asm2wasm tests.
The files are all uniquely named `HASH.{ok,failed}.wasm`.
This will be especilly useful for fuzz testing, but could also be used for other tests including non-V8 tests.
For now I manually hacked tools/testrunner/local/execution.py so that tools/run-tests.py can output the modules. We may want to ad a flag to run-tests.py proper if this turns out to be useful.
R=bradnelson@chromium.org, titzer@chromium.org, kcc@chromium.org
Review URL: https://codereview.chromium.org/1816583003
Cr-Commit-Position: refs/heads/master@{#34968}
Both of them shipped in Chrome 49 without incident.
Also move relevant tests from harmony/ to es6/.
Review URL: https://codereview.chromium.org/1815773002
Cr-Commit-Position: refs/heads/master@{#34964}
Bounds check hoisting was known to be buggy and has never been turned on.
Since Crankshaft is deprecated, nobody is going to spend time fixing it,
so let's just get rid of it.
BUG=v8:4155,v8:4849
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1823623002
Cr-Commit-Position: refs/heads/master@{#34948}
Note that this optimization only kicks in with --harmony-instanceof
being enabled as well. By itself this optimization itself does not
trigger.
R=bmeurer@chromium.org
BUG=v8:4447
LOG=n
Review URL: https://codereview.chromium.org/1817043002
Cr-Commit-Position: refs/heads/master@{#34947}
This CL restores special crankshaft optimizations for instance of when
--harmony-instanceof is true. Similar work has to happen for TurboFan.
I've added a flag to pile-up the optimizations to be done elsewhere, which
will follow over several CLs.
R=verwaest@chromium.org, mstarzinger@chromium.org
BUG=v8:4447
LOG=n
Review URL: https://codereview.chromium.org/1809113002
Cr-Commit-Position: refs/heads/master@{#34930}
Function declarations were previously permitted by V8 in many locations
which no ECMAScript specification allowed; the ECMAScript 2015 spec
enumerates a few locations (in blocks, as well as after labels and in
conditionals when in sloppy mode). This patch ships the flag to restrict
the usage of function declarations to those contexts.
R=adamk
LOG=Y
BUG=v8:4824
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1799233003
Cr-Commit-Position: refs/heads/master@{#34828}
Modules already have a separate entrypoint into the engine (at the moment,
this is v8::ScriptCompiler::CompileModule, though that will change to
something like ParseModule). This meant that requiring a commandline flag
simply added an extra complexity burden on embedders. By removing the v8
flag, this lets embedders use their own flagging mechanism (such as d8's
"--module", or Blink's RuntimeEnabledFeatures) to control whether
modules are to be used.
Also remove old modules tests that were being skipped (since they test
very old, pre-ES2015 modules syntax).
R=littledan@chromium.org
BUG=v8:1569, chromium:594639
LOG=y
Review URL: https://codereview.chromium.org/1804693002
Cr-Commit-Position: refs/heads/master@{#34764}
When black allocation is active, all objects allocated in old space are allocated black. Important: With that change, you cannot assume anymore that new objects are white right after their allocation. Currently, black allocation is enabled when incremental marking is started.
This feature can be turned off via flag: --noblack-allocation
BUG=chromium:561449
LOG=n
Review URL: https://codereview.chromium.org/1420423009
Cr-Commit-Position: refs/heads/master@{#34743}
Reason for revert:
Speculative revert to check if this CL is causing GC stress failures.
Original issue's description:
> Enable parallel pointer updates after evacuation.
>
> BUG=chromium:578883
> LOG=NO
>
> Committed: https://crrev.com/7217fcc0bf5b0f62947f92128ec76855d50e91da
> Cr-Commit-Position: refs/heads/master@{#34712}
TBR=mlippautz@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:578883
LOG=NO
Review URL: https://codereview.chromium.org/1803573002
Cr-Commit-Position: refs/heads/master@{#34741}
ES2015 Object.prototype.toString semantics were enabled in version 4.9,
which has been in stable Chrome for nearly two weeks at this point.
R=littledan@chromium.org
Review URL: https://codereview.chromium.org/1784033002
Cr-Commit-Position: refs/heads/master@{#34732}
These flags have been on by default since version 4.9, which has been
in stable Chrome for over a week now, demonstrating that they're
here to stay.
Also moved the tests out of harmony/ and into es6/.
Review URL: https://codereview.chromium.org/1776683003
Cr-Commit-Position: refs/heads/master@{#34692}
With the flag enables we print the keys found on each prototype and
the number of prototypes.
BUG=
Review URL: https://codereview.chromium.org/1779523002
Cr-Commit-Position: refs/heads/master@{#34680}
This flag bans illegal (and likely useless) constructs like
for (;;) function f() {}
R=adamk
BUG=v8:4824
LOG=Y
Review URL: https://codereview.chromium.org/1781653005
Cr-Commit-Position: refs/heads/master@{#34646}
ES2015 generally bans FunctionDeclarations in positions which expect a Statement,
as opposed to a StatementListItem, such as a FunctionDeclaration which constitutes
the body of a for loop. However, Annex B 3.2 and 3.4 make exceptions for labeled
function declarations and function declarations as the body of an if statement in
sloppy mode, in the latter case specifying that the semantics are as if the
function declaration occurred in a block. Chrome has historically permitted
further extensions, for the body of any flow control construct.
This patch addresses both the syntactic and semantic mismatches between V8 and
the spec. For the semantic mismatch, function declarations as the body of if
statements change from unconditionally hoisting in certain cases to acquiring
the sloppy mode function in block semantics (based on Annex B 3.3). For the
extra syntax permitted, this patch adds a flag,
--harmony-restrictive-declarations, which excludes disallowed function declaration
cases. A new UseCounter, LegacyFunctionDeclaration, is added to count how often
function declarations occur as the body of other constructs in sloppy mode. With
this patch, the code generally follows the form of the specification with respect
to parsing FunctionDeclarations, rather than allowing them in arbitrary Statement
positions, and makes it more clear where our extensions occur.
BUG=v8:4647
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1757543003
Cr-Commit-Position: refs/heads/master@{#34470}
This patch moves iterator finalization (calling .return() when a
for-of loop exits early) to shipping. The only part of this feature
which is currently known to be missing is destructuring--.return()
should be also be called when destructuring with an array which
does not end in a rest pattern, but it currently does not. The rest
of this feature, including calling .return() from certain builtins,
is implemented.
R=adamk
BUG=v8:3566
LOG=Y
Review URL: https://codereview.chromium.org/1738463003
Cr-Commit-Position: refs/heads/master@{#34307}
This patch moves for-of closing to staging. There are a couple of
minor semantics bugs remaining in finalization along edge cases, but
we don't know of any stability issues.
BUG=v8:3566
R=rossberg
LOG=Y
Review URL: https://codereview.chromium.org/1725203002
Cr-Commit-Position: refs/heads/master@{#34254}
This patch moves the ES2015 Symbol.species feature from staging to
shipping. @@species should be good to ship now that the regression
from fast-path cases in concat, slice and splice have been addressed.
R=adamk
BUG=v8:4093
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1721993002
Cr-Commit-Position: refs/heads/master@{#34226}
This implements a mechanism to track the exact depth of the operand
stack in full-codegen for every sub-expression visitation. So far we
only tracked the depth at statement level, but not at expression level.
With the introduction of do-expressions it will be possible to construct
local control flow (i.e. break, continue and friends) that target labels
at an arbitrary operand stack depth, making this tracking a prerequisite
for full do-expression support.
R=rossberg@chromium.org,jarin@chromium.org
BUG=v8:4755,v8:4488
LOG=n
Review URL: https://codereview.chromium.org/1706283002
Cr-Commit-Position: refs/heads/master@{#34211}
Until now inlining in TurboFan was staged behind --turbo, which means
that it wasn't enabled with --turbo-shipping. It seems reasonable to
ship it now, since Clusterfuzz had fun with it for a year already, and
we need to reach parity with Crankshaft with more and more things being
enabled behind --turbo-shipping.
Review URL: https://codereview.chromium.org/1721243002
Cr-Commit-Position: refs/heads/master@{#34209}
This was previously reverted due to breakage in devtools, but that has
been worked around in https://codereview.chromium.org/1666573002.
The feature has been publicly-announced as deprecated for several months,
and Chrome 49 will emit deprecation warnings in the console for
uses of the API. This CL aims to remove it from M50 (which is what the
message warns of).
BUG=chromium:552100
LOG=y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1711863003
Cr-Commit-Position: refs/heads/master@{#34171}
Extract the logic to find out the best candidate out of the core of the
scheduler. It allows more flexibility and make it easy to change the
policy use to schedule the basic blocks.
This patch also provide a new algorithm to randomly schedule the code
in order to perform stress tests on the scheduler.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1714753004
Cr-Commit-Position: refs/heads/master@{#34156}
Implements iterator finalisation by desugaring for-of loops with an additional try-finally wrapper. See comment in parser.cc for details.
Also improved some AST printing facilities while there.
@Ross, I had to disable the bytecode generation test for for-of, because it got completely out of hand after this change (the new bytecode has 150+ lines). See the TODO that I assigned to you.
Patch set 1 is WIP patch by Georg (http://crrev.com/1695583003), patch set 2 relative changes.
@Georg, FYI, I changed the following:
- Moved try-finally out of the loop body, for performance, and in order to be able to handle `continue` correctly.
- Fixed scope management in ParseForStatement, which was the cause for the variable allocation failure.
- Fixed pre-existing zone initialisation bug in rewriter, which caused the crashes.
- Enabled all tests, adjusted a few others, added a couple more.
BUG=v8:2214
LOG=Y
Review URL: https://codereview.chromium.org/1695393003
Cr-Commit-Position: refs/heads/master@{#34111}
Reason for revert:
Tanks Mandreel-latency.
Original issue's description:
> Tweak type info threshold.
>
> Let the world know (if it cares) that this is the kind of
> silliness that JS engines have to partake in if they want
> to look good on Sunspider (this should give 5% overall).
>
> Committed: https://crrev.com/4f62af4234e8ad74abd8e4cd3e492f7727efc768
> Cr-Commit-Position: refs/heads/master@{#33866}
TBR=yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review URL: https://codereview.chromium.org/1699063002
Cr-Commit-Position: refs/heads/master@{#34027}
Harvesting maps from the stub cache for megamorphic ICs is both slow
(linear in the size of the stub cache) and imprecise (as it finds all
maps that have a cached handler for the given property name).
In the canonical megamorphic situation, this type feedback is useless
anyway. The interesting case is when we can filter it down to a single
map; however in these cases it is often possible to derive this map
just by looking at the HGraph, which is both faster and more reliable.
Review URL: https://codereview.chromium.org/1669213003
Cr-Commit-Position: refs/heads/master@{#33998}
This adds initial support for inline allocation of object and array
literals to the JSCreateLowering pass. It's basically identical to
what Crankshaft does.
This also unstages the TurboFan escape analysis, as the lowering seems
to trigger a bunch of bugs in it; those bugs will be fixed separately,
and we will re-enable escape analysis afterwards.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1698783002
Cr-Commit-Position: refs/heads/master@{#33972}
- Remove unused methods that we should never actually use like SetArea() or
set_size().
- Live bytes are now reported with --trace-live-bytes and not gc-verbose.
BUG=chromium:581076
LOG=N
Review URL: https://codereview.chromium.org/1686413002
Cr-Commit-Position: refs/heads/master@{#33908}
Let the world know (if it cares) that this is the kind of
silliness that JS engines have to partake in if they want
to look good on Sunspider (this should give 5% overall).
Review URL: https://codereview.chromium.org/1684093002
Cr-Commit-Position: refs/heads/master@{#33866}
This patch moves Symbol.species support to the "experimental JavaScript
features" flag. While @@species is still a performance hit, it doesn't seem
like it would make the web unusably slow; shipping would still have to
wait on fixing the performance regression, but staging this version should
yield valuable web compatibility information.
R=cbruni
BUG=v8:4093
LOG=Y
Review URL: https://codereview.chromium.org/1678143002
Cr-Commit-Position: refs/heads/master@{#33827}
The flag in question is a debug-only flag supported by full-codegen and
Crankshaft only. In it's current form there are some unresolved issues:
- The flag is defeated by inlining in Crankshaft.
- The flag is not supported by TurboFan.
- The flag is not supported by Ignition.
Instead of addressing the above issues and increasing maintenance cost
for all backends and also given the "slim" test coverage, this CL fully
removes the support from all backends.
R=bmeurer@chromium.org,jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1676263002
Cr-Commit-Position: refs/heads/master@{#33817}
This is also a refactoring of the merge function in
escape analysis.
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1654163003
Cr-Commit-Position: refs/heads/master@{#33728}
This removes --harmony-completion, --harmony-concat-spreadable, and
--harmony-tolength and moves the appropriate tests from harmony/ to es6/.
Review URL: https://codereview.chromium.org/1667453002
Cr-Commit-Position: refs/heads/master@{#33712}
This patch ships the first part of RegExp subclassing--defining
Symbol.{match,replace,search,split}, but keeping their original
definitions which are restricted to a RegExp receiver and do not
call out to the core 'exec' method. This is being shipped separately
because the two sets of extension points are separate features with
separate functionality. The amount of behavior which is held behind
the flag is very small, just exposing the symbols as properties of
Symbol--the behavior that the String methods call out to these Symbol
properties has already been shipping unflagged.
R=yangguo@chromium.org
BUG=v8:4305,v8:4343,v8:4344,v8:4345
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1652793002
Cr-Commit-Position: refs/heads/master@{#33629}
The body of a generator function can now refer to the generator's input value via a new
"function.sent" expression. We extend the proposal at
https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md
in the obvious way to also apply to GeneratorResumeAbrupt.
This will enable us to desugar yield*.
The new syntax is behind a new --harmony-function-sent flag.
BUG=v8:4700
LOG=n
Review URL: https://codereview.chromium.org/1620253003
Cr-Commit-Position: refs/heads/master@{#33574}
This patch stages the first part of RegExp subclassing--defining
Symbol.{match,replace,search,split}, but keeping their original
definitions which are restricted to a RegExp receiver and do not
call out to the core 'exec' method. This is being staged separately
because the two sets of extension points are separate features with
separate functionality. The amount of behavior which is held behind
the flag is very small, just exposing the symbols as properties of
Symbol--the behavior that the String methods call out to these Symbol
properties has already been shipping unflagged.
R=yangguo@chromium.org
BUG=v8:4305,v8:4343,v8:4344,v8:4345
LOG=Y
Review URL: https://codereview.chromium.org/1637703003
Cr-Commit-Position: refs/heads/master@{#33534}
