Before this CL, we created one live range per successive set of
deferred blocks. For scenarios with many such blocks, this creates
an upfront pressure for the register allocator to deal with many ranges.
Linear sorts ranges, which is a super-linear operation.
The change places all deferred intervals into one range, meaning that,
at most, there will be twice as many live ranges as the original set. In
pathological cases (benchmarks/Compile/slow_nbody1.js), this change
halves the compilation time. We see some improvements elsewhere,
notably SQLite at ~4-5%.
We may be able to avoid the subsequent merge. Its cost is the
additional ranges it may need to create. The sole reason for the merge
phase is to provide an unchanged view of the world to the subsequent
phases. With the at-most-one splinter model, we may be able to teach
the other phases about splintering - should we find perf hindrances
due to merging.
Review URL: https://codereview.chromium.org/1391023007
Cr-Commit-Position: refs/heads/master@{#31224}
For live ranges with many use positions, such as those encountered in
some unity asm.js code, this change significantly reduces compile time
(e.g. benchmarks/Compile/slow_nbody1.js: from ~6s to 2s). The
improvement is solely due to regressions (fixed by this CL) due to
splintering.
This CL does not fully address compile time problems for large
functions in Turbofan, but constitutes a step in the right direction.
Review URL: https://codereview.chromium.org/1386253004
Cr-Commit-Position: refs/heads/master@{#31220}
Previously, name conflicts between var and let declarations were only
made into exceptions if they were visible at parse-time. This patch adds
runtime checks so that sloppy-mode direct eval can't introduce conflicting
var declarations. The change is implemented by traversing the scope chain
when a direct eval introduces a var declaration to look for conflicting
let declarations, up to the function boundary.
BUG=v8:4454
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1382513003
Cr-Commit-Position: refs/heads/master@{#31211}
-Bitwise Or
-Bitwise Xor
-Bitwise And
Adds the above bytecodes, support to BytecodeGenerator and BytecodeArrayBuilder to enable it's use, it's implementation and tests.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1386133002
Cr-Commit-Position: refs/heads/master@{#31210}
Reason for revert:
This still breaks Inbox.
Original issue's description:
> Stage --harmony_sloppy_function
>
> This patch turns on ES2015-style function hoisting semantics in
> staging. --harmony_sloppy_function was previously staged, leading
> to a number of bugs being filed and the staging being reversed;
> important bugs have been fixed, so it is time to try again.
>
> R=adamk
> LOG=Y
> BUG=v8:4285
>
> Committed: https://crrev.com/333e27fd99f8187c97e62b9538529900f0a30668
> Cr-Commit-Position: refs/heads/master@{#31190}
TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4285
Review URL: https://codereview.chromium.org/1402763003
Cr-Commit-Position: refs/heads/master@{#31206}
Adds support for following operators
-Shift left
-Shift right
-Shift right logical
Adds the above bytecodes, support to BytecodeGenerator and BytecodeArrayBuilder
to enable it's use, it's implementation and tests.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1392913002
Cr-Commit-Position: refs/heads/master@{#31205}
The stack manipulation was expensive. Two virtual registers are better.
BUG=
Review URL: https://codereview.chromium.org/1376933006
Cr-Commit-Position: refs/heads/master@{#31204}
Scope has no subclasses, so "protected" should just be "private". And
there is no ParserFactory class, so making it a friend doesn't buy us
anything.
Review URL: https://codereview.chromium.org/1393303005
Cr-Commit-Position: refs/heads/master@{#31201}
Fixes clang on windows warning:
..\..\v8\src\base\platform\platform-win32.cc(836,1) :
error: function declared 'noreturn' should not return
[-Werror,-Winvalid-noreturn]
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_clang_rel,win_clang_x64_rel
Review URL: https://codereview.chromium.org/1390193003
Cr-Commit-Position: refs/heads/master@{#31194}
The test had an effect phi with one effect input connected to a loop with two control inputs. Also, the Terminate node was used by the effect phi.
Review URL: https://codereview.chromium.org/1398763002
Cr-Commit-Position: refs/heads/master@{#31193}
This patch turns on ES2015-style function hoisting semantics in
staging. --harmony_sloppy_function was previously staged, leading
to a number of bugs being filed and the staging being reversed;
important bugs have been fixed, so it is time to try again.
R=adamk
LOG=Y
BUG=v8:4285
Review URL: https://codereview.chromium.org/1393423002
Cr-Commit-Position: refs/heads/master@{#31190}
Make the end position of a regexp literal the first character following the regexp. This matches the behaviour of number literals and string literals, as well as single-character tokens.
This change corrects the lazy-parsing of arrow functions with concise bodies, whose last token is a regular expression literal.
BUG=v8:4474
LOG=N
R=wingo@igalia.com, adamk@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1389313003
Cr-Commit-Position: refs/heads/master@{#31189}
Not all register codes are safe for use on all architectures.
Using RegisterConfiguration when picking a calling convention
in test-multiple-return.
BUG=None
TEST=test-multiple-return
R=titzer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1401453002
Cr-Commit-Position: refs/heads/master@{#31188}
Reason for revert:
This contains bugs, as found by mstarzinger. Reverting until we can find a clean fix (maybe it should be an inline function instead of a macro).
Original issue's description:
> Use simple/fast macro version of MinMax in JS
>
> Use the simple macro version of {Min, Max} where possible to
> improve performance
>
> Follow-up to CR: https://codereview.chromium.org/1331993004
>
> BUG=
>
> Committed: https://crrev.com/27c96c26212a10bb7f19f7bf3ff793b31bbad354
> Cr-Commit-Position: refs/heads/master@{#31162}
TBR=jkummerow@chromium.org,mstarzinger@chromium.org,karl@skomski.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1394303003
Cr-Commit-Position: refs/heads/master@{#31187}
Without that, it has a few false positives about out-of-bounds array accesses.
Also makes the clang static-analyzer happy.
Original code review from Sven Panne:
https://codereview.chromium.org/790723002/
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm_dbg,v8_linux_arm64_dbg,v8_mac64_dbg,v8_win_compile_dbg,v8_linux_gcc_rel
Review URL: https://codereview.chromium.org/1393023003
Cr-Commit-Position: refs/heads/master@{#31185}
This will allow exploration of possibilities like passing around buffer base and length.
BUG=None
TEST=test-multiple-return
LOG=N
R=mtrofin@chromium.org,titzer@chromium.org
Review URL: https://codereview.chromium.org/1391333003
Cr-Commit-Position: refs/heads/master@{#31184}
This adds support to also lower stores to global property cells in state
kConstant or kConstantType, where we need to deoptimize eagerly in case
we have a value/type mismatch.
Also fixes bugs in the construction of the frame states in the
AstGraphBuilder.
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1398723002
Cr-Commit-Position: refs/heads/master@{#31178}
This fixes several warnings when cross-building using GCC (since r31087,
5cf1c0b).
In particular, CPURegister::code() now returns 'int', matching the other
platforms (and the coding style guide). The rest of the patch consists
of similar changes to make this work.
BUG=
Review URL: https://codereview.chromium.org/1393043003
Cr-Commit-Position: refs/heads/master@{#31176}
This change removes the unswept free bytes counter.
The new approach
- directly decrements allocated memory and capacity before sweeping (using live
bytes from the marker), and
- adds back capacity during refilling a free list.
This is another pre-work for moving around free lists while keeping the counters
in a sane state.
The previous approach allowed us to nail down how much memory is to-be-swept.
However, there were no users of this as we only used it do decrement it from
allocated memory (which still accounted for dead objects). If we want to keep
track of unswept free bytes in a space during compaction we can introduce a
separate new concurrent counter for this purpose.
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1380723002
Cr-Commit-Position: refs/heads/master@{#31175}
