Some pretty hacky code was used to carry out the tail-call
handler dispatch on ia32 vector stores due to a lack
of free registers. It really tanks performance. A better
approach is to use a virtual register on the isolate.
BUG=
Review URL: https://codereview.chromium.org/1336313002
Cr-Commit-Position: refs/heads/master@{#30718}
This removes the aforementioned flag which has been on by default for a
while now. Note that this does not control optimization decisions, only
the last-resort bailout in the graph builder.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1335543002
Cr-Commit-Position: refs/heads/master@{#30673}
Adds support for property store operations via Store/KeyedStore ICs. Adds the
following bytecodes:
- StoreIC
- KeyedStoreIC
The --vector_store flag is now required for --ignition.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1319833004
Cr-Commit-Position: refs/heads/master@{#30660}
- Modify js2c to accept --js and --nojs,
- modify mksnapshot to accept --startup_src
(instead of a positional parameter, so that it can be omitted),
- modify v8.gyp to use the above so that no target has multiple
output dependencies, and
- update GN to use the switches above.
(I have not succeeded in fixing the GYP->make translator to properly map
multi-output rules, so that they work as expected in all edge cases.
This CL signals defeat on that front, and instead I rewrite the GYP
file to avoid that situation in the first place.)
R=jochen@chromium.org
BUG=v8:4382
LOG=N
Review URL: https://codereview.chromium.org/1310273009
Cr-Commit-Position: refs/heads/master@{#30640}
Once a range is found to have a conflict, split around all the calls it
crosses over, since it will anyway have conflicts there, too.
Incrementally, from the last change to greedy, this change brings
overall improvement in benchmarks. In fact, except for 2 regressions
in Jetstream (splay-latency and date-format-xparb, at 6 and 7%
respectivelly), everything else is in the green or noise. Quite a few
benchmarks are over 3%, with a few (zlib, for example) in the double
digits.
Review URL: https://codereview.chromium.org/1328783002
Cr-Commit-Position: refs/heads/master@{#30579}
Move the --harmony-sloppy-let flag to staging for further testing, and
update test262 for the new passing tests. Also increase the strictness
of the parser, even in sloppy mode, to disallow "new legacy compat" for
for (let x = 5 in {}) {}
which is now a SyntaxError.
BUG=v8:3305
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1321013005
Cr-Commit-Position: refs/heads/master@{#30525}
Reason for revert:
Fails a test262 test with --always-opt.
Original issue's description:
> Stage sloppy let
>
> Move the --harmony-sloppy-let flag to staging for further testing, and
> update test262 for the new passing tests. Also increase the strictness
> of the parser, even in sloppy mode, to disallow "new legacy compat" for
>
> for (let x = 5 in {}) {}
>
> which is now a SyntaxError.
>
> BUG=v8:3305
> LOG=Y
> R=adamk
>
> Committed: https://crrev.com/07bc0117be8dc9e63ec14d5f9645c483d60a1bec
> Cr-Commit-Position: refs/heads/master@{#30515}
TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3305
Review URL: https://codereview.chromium.org/1324033002
Cr-Commit-Position: refs/heads/master@{#30518}
Move the --harmony-sloppy-let flag to staging for further testing, and
update test262 for the new passing tests. Also increase the strictness
of the parser, even in sloppy mode, to disallow "new legacy compat" for
for (let x = 5 in {}) {}
which is now a SyntaxError.
BUG=v8:3305
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1327483002
Cr-Commit-Position: refs/heads/master@{#30515}
We completely un-wired the greedy allocator to focus on the
stackchecks in loops (splintering) work. This change re-wires greedy,
still behind its flag. For now, enabling the greedy allocator disables
the stackchecks in loops feature (and range splintering), so that we are
at the baseline we left it at.
The main contribution in this change is adapting the codebase after
the live range model refactoring, whereby RegisterAllocationData's
live_ranges() contains just top-level ranges, and children are accessed
via their parents.
BUG=
Review URL: https://codereview.chromium.org/1320363002
Cr-Commit-Position: refs/heads/master@{#30492}
When encountering a "=" token in ParseAssignmentExpression, the default
parameter case is not locally distinguishable from the destructuring case.
BUG=
Review URL: https://codereview.chromium.org/1317843002
Cr-Commit-Position: refs/heads/master@{#30386}
The lack of marking this dependency led to a ClusterFuzz crash when
sloppy-function was on but not sloppy. This case does not make sense.
R=adamk
LOG=N
BUG=chromium:520891
Review URL: https://codereview.chromium.org/1316773004
Cr-Commit-Position: refs/heads/master@{#30364}
This change encompasses what is necessary to enable stack checks in loops without suffering large regressions.
Primarily, it consists of a new mechanism for dealing with deferred blocks by "splintering", rather than splitting, inside deferred blocks.
My initial change was splitting along deferred block boundaries, but the regression introduced by stackchecks wasn't resolved conclusively. After investigation, it appears that just splitting ranges along cold block boundaries leads to a greater opportunity for moves on the hot path, hence the suboptimal outcome.
The alternative "splinters" ranges rather than splitting them. While splitting creates 2 ranges and links them (parent-child), in contrast, splintering creates a new independent range with no parent-child relation to the original. The original range appears as if it has a liveness hole in the place of the splintered one. All thus obtained ranges are then register allocated with no change to the register allocator.
The splinters (cold blocks) do not conflict with the hot path ranges, by construction. The hot path ones have less pressure to split, because we remove a source of conflicts. After allocation, we merge the splinters back to their original ranges and continue the pipeline. We leverage the previous changes made for deferred blocks (determining where to spill, for example).
Review URL: https://codereview.chromium.org/1305393003
Cr-Commit-Position: refs/heads/master@{#30357}
Embedders would use these for features which must be able to be turned
off at runtime, despite being compiled into V8. They can be turned on
and off by the embedder using the --experimental_extras flag, e.g. via
v8::SetFlagsFromString.
R=yangguo@chromium.org, mlippautz@chromium.org, hpayer@chromium.org
BUG=chromium:507137
LOG=Y
Review URL: https://codereview.chromium.org/1284413002
Cr-Commit-Position: refs/heads/master@{#30260}
Bytecode generator for local assignment and basic binary operations.
Command-line flag for printing bytecodes.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1294543002
Cr-Commit-Position: refs/heads/master@{#30221}
Restricts linux perf-event code range reporting to functions only (i.e. on
stubs.) While this makes the gathered ticks less accurate, it reduces the
growth of the /tmp/perf-${pid}.map file.
BUG=v8:3453
R=hablich@chromium.org,danno@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1292743002
Cr-Commit-Position: refs/heads/master@{#30179}
This patch puts --harmony-sloppy into staging. Now that let, lexically-scoped
functions and ES2015 sloppy mode const semantics have been split off into
separate flags, the change only enables classes in sloppy mode.
BUG=v8:3305
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1288153003
Cr-Commit-Position: refs/heads/master@{#30141}
In an initial attempt to implement sloppy mode lexical bindings,
functions were made lexically scoped in sloppy mode. However, the
ES2015 spec says that they need an additional hoisted var binding,
and further, it's not clear when we'll implement that behavior
or whether it's web-compatible.
This patch splits off function block scoping into a new, separate
flag called --harmony_sloppy_function. This change will enable the
possibility of testing and shipping this feature separately from
other block scoping-related features which don't have the same risks.
BUG=v8:4285
R=adamk
LOG=N
Review URL: https://codereview.chromium.org/1282093002
Cr-Commit-Position: refs/heads/master@{#30122}
With the recent changes to the incremental marking API we can now kick off
incremental marking while respecting callback flags.
Performance neutral for smoothness.image_decoding_cases on N9 (read: does not
crash) as long as we synchronously process phantom callbacks
(kGCCallbackFlagForced).
OORT single run:
"marksweep": {
"count": 5,
"pause_min": 7.5,
"pause_max": 158.8,
"pause_avg": 97.52000000000001,
"pause_gt_10ms": 4
}
--- vs ---
"marksweep": {
"count": 5,
"pause_min": 16.2,
"pause_max": 22.1,
"pause_avg": 19.32,
"pause_gt_10ms": 5
}
The number of actual full GCs varies. The improvement manifests in reduced
maximum and average pauses.
BUG=chromium:515795
LOG=N
Review URL: https://codereview.chromium.org/1271253002
Cr-Commit-Position: refs/heads/master@{#30028}
To avoid tanking context startup performance, only the actual installation of the
JS-exposed API is flag-guarded. The remainder of the implementation still
resides in the snapshot.
Review URL: https://codereview.chromium.org/1257063003
Cr-Commit-Position: refs/heads/master@{#30017}
Added a separate flag for this, since we intend to enable it for the linear allocator as well. Currently, the option is "on" for greedy, as a point in time to enable its testing (through the greedy allocator bots).
BUG=
Review URL: https://codereview.chromium.org/1256313003
Cr-Commit-Position: refs/heads/master@{#30005}
Reason for revert:
Suspected to cause Canary crashes
Original issue's description:
> Reland^2 "Enable loads and stores to global vars through property cell shortcuts installed into parent script context".
>
> This reverts commit 362b378501.
>
> R=ishell@chromium.org
>
> Committed: https://crrev.com/440ae014e56924b52337c3747221b79283f07b81
> Cr-Commit-Position: refs/heads/master@{#29849}
TBR=ishell@chromium.org,v8-mips-ports@googlegroups.com,plind44@gmail.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/1260423002
Cr-Commit-Position: refs/heads/master@{#29905}
Reason for revert:
This CL may be the reason for the spike on memory corruption. Tentatively reverting this CL.
BUG=chromium:512780
LOG=n
Original issue's description:
> Activate preserving of optimized code map accross GCs.
>
> This enables --noflush-optimized-code-cache which allows preserving
> entries in the optimized code map accross GCs. This only applies to
> values being reachable through other paths.
>
> R=hpayer@chromium.org,hablich@chromium.org
>
> Committed: https://crrev.com/1a8776db25b63c4ce718423772d1fd13f58eeab5
> Cr-Commit-Position: refs/heads/master@{#29755}
TBR=hablich@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1255043003
Cr-Commit-Position: refs/heads/master@{#29888}
--harmony_sloppy includes behavior to turn on sloppy mode lexical
bindings. Before this patch, it also included a way to parse let
which is likely web-incompatible (let is disallowed as an
identifier). This patch splits off the let parsing from the more
general block scoping code, so that block scoping can be developed
independently.
R=adamk
LOG=N
BUG=v8:3305
Review URL: https://codereview.chromium.org/1255013002
Cr-Commit-Position: refs/heads/master@{#29855}
This function will be used later instead of HasLowAllocationRate
to decide how many pages to compact.
BUG=chromium:502247
LOG=NO
Review URL: https://codereview.chromium.org/1254603002
Cr-Commit-Position: refs/heads/master@{#29841}
Adds basic support for generation of interpreter bytecode handler code
snippets. The InterpreterAssembler class exposes a set of low level,
interpreter specific operations which can be used to build a Turbofan
graph. The Interpreter class generates a bytecode handler snippet for
each bytecode by assembling operations using an InterpreterAssembler.
Currently only two simple bytecodes are supported: LoadLiteral0 and Return.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1239793002
Cr-Commit-Position: refs/heads/master@{#29814}
This preserves the context-independent entry in an optimized code map
across GCs when the code is considered young (i.e. less than 3 ages).
Note that any context-dependent entry for the same code will still be
flushed immediately when the respective context dies, hence context
lifetime is not increased.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1252463002
Cr-Commit-Position: refs/heads/master@{#29790}
This enables --noflush-optimized-code-cache which allows preserving
entries in the optimized code map accross GCs. This only applies to
values being reachable through other paths.
R=hpayer@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1217863006
Cr-Commit-Position: refs/heads/master@{#29755}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Committed: https://crrev.com/e5ed3bee99807c502fa7d7a367ec401e16d3f773
Cr-Commit-Position: refs/heads/master@{#29689}
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29712}
