This filters test and third_party files to get a speed-up
when running tests and when collecting profile data.
BUG=chromium:568949
LOG=n
NOTRY=true
Review URL: https://codereview.chromium.org/1730543002
Cr-Commit-Position: refs/heads/master@{#34216}
SuperPropertyArgumnets is less useful after deprecating strong mode.
BUG=v8:4280,v8:4682
LOG=N
Review URL: https://codereview.chromium.org/1721723002
Cr-Commit-Position: refs/heads/master@{#34215}
Slots pointing to evacuation candidates are now recorded in the new RememberedSet<OLD_TO_OLD>.
The remembered set is extended to support typed slots.
During parallel evacuation all migration slots are recorded in local slots buffers.
After evacuation all local slots are added to the remembered set.
BUG=chromium:578883
LOG=NO
Review URL: https://codereview.chromium.org/1703823002
Cr-Commit-Position: refs/heads/master@{#34212}
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}
So far counters did not work when they were reentrant and thus would lead to
wrong bookkeeping of the counter stack. Using a separate stack-allocated linked
list to track the timer stack solves this issue. This is a temporary workaround
with the limitations of the counter system in mind. Eventually we will move to
the trace-based system for these kind of statistics.
BUG=v8:4770
LOG=n
Review URL: https://codereview.chromium.org/1695733002
Cr-Commit-Position: refs/heads/master@{#34208}
This fixes an issue encountered in wasm payloads, where we do not
(yet) optimize away duplicate phi definitions - phis in the same block
with the same operand list; and when move optimizations merge phi-
defining moves into the block defining the phi. If all this happens, the
register allocation validator back-propagation fails because it can't
distinguish the duplicate phis, when traversing backwards.
BUG=
Review URL: https://codereview.chromium.org/1720003002
Cr-Commit-Position: refs/heads/master@{#34207}
When assigning to an integer view of the heap an intish
value does not need to be collapsed with |0.
Similarly a floatish value does not need to be collapsed with
fround when assigned to a float view of the heap.
i32[0] = i32_1 + i32_2; // ok
f32[0] = f32_1 + f32_2; // ok
However, floatish values cannot be safely assigned to double
arrays.
f64[0] = f32_1 + f32_2; // not ok
BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/asm-wasm,test-asm-validator
R=aseemgarg@chromium.org,titzer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1722473002
Cr-Commit-Position: refs/heads/master@{#34206}
port 0e43ff5632 (r34187)
original commit message:
The InstructionSelector now associates an effect level to every node in a block.
The effect level of a node is the number of non-eliminatable nodes encountered from the beginning of the block to the node itself.
With this change, on ia32 and x64, a load from memory into a register can be replaced by a memory operand if all of the following conditions hold:
1. The only use of the load is in a 32 or 64 bit word comparison.
2. The user node and the load node belong to the same block.
3. The values of the operands have the same size (i.e., no need to zero-extend or sign-extend the result of the load).
BUG=
Review URL: https://codereview.chromium.org/1724473004
Cr-Commit-Position: refs/heads/master@{#34204}
The CL #33796 (https://codereview.chromium.org/1628133002) added the RunRoundUint32ToFloat32 test case and X87 failed at it.
The reason is same as the CL #33630 (Issue 1649323002: X87: Change the test case for X87 RunRoundInt32ToFloat32), please refer: https://codereview.chromium.org/1649323002.
Here is the key comments from CL #33630:
Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function,
those inlined functions has different behavior comparing with GCC ia32 build and x87 build.
The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value.
The V8 turbofan JITTed has exactly same result in both X87 and IA32 port.
For CHECK_EQ(a, b) function, if a and b are doubles, it will has similar behaviors like CheckFloatEq(...) and CheckDoubleEq(...) function when compiled by GCC and causes the test case
fail.
So we add the following sentence to do type case to keep the same precision for RunRoundUint32ToFloat32. Such as: volatile double expect = static_cast<float>(*i).
BUG=
Review URL: https://codereview.chromium.org/1714413002
Cr-Commit-Position: refs/heads/master@{#34202}
It turns out that some old polyfill library uses
RegExp.prototype.flags as a way of feature testing. It's not clear
how widespread this is. For now, as a minimal workaround, we can
return undefined from getters like RegExp.prototype.global when
the receiver is RegExp.prototype. This patch implements that strategy
but omits a UseCounter to make backports easier.
R=adamk
CC=yangguo@chromium.org
BUG=chromium:581577
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1640803003
Cr-Commit-Position: refs/heads/master@{#34201}
In ES2016, the Proxy enumerate trap is removed. This patch changes
for-in iteration on Proxies to use the ownKeys trap. Due to the clean
organization of that code, the patch basically consists of deletions.
R=adamk
LOG=Y
BUG=v8:4768
Review URL: https://codereview.chromium.org/1717893002
Cr-Commit-Position: refs/heads/master@{#34200}
This patch makes ArraySpeciesCreate fast in V8 by avoiding two property reads
when the following conditions are met:
- No Array instance has had its __proto__ reset
- No Array instance has had a constructor property defined
- Array.prototype has not had its constructor changed
- Array[Symbol.species] has not been reset
For subclasses of Array, or for conditions where one of these assumptions is
violated, the full lookup of species is done according to the ArraySpeciesCreate
algorithm. Although this is a "performance cliff", it does not come up in the
expected typical use case of @@species (Array subclassing), so it is hoped that
this can form a good start. Array subclasses will incur the slowness of looking
up @@species, but their use won't slow down invocations of, for example,
Array.prototype.slice on Array base class instances.
Possible future optimizations:
- For the fallback case where the assumptions don't hold, optimize the two
property lookups.
- For Array.prototype.slice and Array.prototype.splice, even if the full lookup
of @@species needs to take place, we still could take the rest of the C++
fastpath. However, to do this correctly requires changing the calling convention
from C++ to JS to pass the @@species out, so it is not attempted in this patch.
With this patch, microbenchmarks of Array.prototype.slice do not suffer a
noticeable performance regression, unlike their previous 2.5x penalty.
TBR=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1689733002
Cr-Commit-Position: refs/heads/master@{#34199}
The Proxy enumerate trap and Reflect.enumerate are removed from the
ES2016 draft specification. This patch removes the Reflect.enumerate
function, and a follow-on patch will be responsible for the Proxy
trap changes.
R=adamk
LOG=Y
BUG=v8:4768
Review URL: https://codereview.chromium.org/1721453002
Cr-Commit-Position: refs/heads/master@{#34196}
In theory, a user could define the Symbol.isConcatSpreadable property
somewhere in the TypedArray class hierarchy. Array.prototype.concat
optimizes for this case and has templated code for fast concat over
TypedArrays. However, the default environment doesn't have this
property set (it would probably not be web-compatible) and there isn't
clear demand for this optimization. This patch removes that
special-case code.
R=adamk
Review URL: https://codereview.chromium.org/1720533003
Cr-Commit-Position: refs/heads/master@{#34195}
Local testing suggests that optimized builds add more speed
without trading off tool usability. We get the following
differences (A: non-optimized build, B: optimized):
Sometimes: Lines instrumented in A (covered and uncovered) are not instrumented in B.
Rarely: Lines instrumented and covered in A are instrumented, but not covered in B.
The latter might simply be caused by timing differences in
the two builds.
BUG=chromium:568949
LOG=n
NOTRY=true
Review URL: https://codereview.chromium.org/1719923002
Cr-Commit-Position: refs/heads/master@{#34193}
Currently AllocationSite skips the weak_next pointer in IterateBody and IsValidSlot.
This is not correct because the weak_next is a valid slot in AllocationSite.
BUG=
Review URL: https://codereview.chromium.org/1719903002
Cr-Commit-Position: refs/heads/master@{#34192}
This picks the record-write stub depending on the correct remembered set
action parameter. For values known to be maps we can guarantee that they
never reside in new-space, hence store buffer recording can be skipped.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1716163003
Cr-Commit-Position: refs/heads/master@{#34191}
This removes a restriction from full-codegen that limited the usability
of the --debug-code flag to only no-snap configurations. The reasoning
for the restriction would still hold, if we ever put full-codegen code
into the snapshot, which we don't. Also there already are several places
in full-codegen that queried the FLAG_debug_code directly, a more
reliable mechanism will be needed if we snapshot full code.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1722593002
Cr-Commit-Position: refs/heads/master@{#34189}
The InstructionSelector now associates an effect level to every node in a block.
The effect level of a node is the number of non-eliminatable nodes encountered from the beginning of the block to the node itself.
With this change, on ia32 and x64, a load from memory into a register can be replaced by a memory operand if all of the following conditions hold:
1. The only use of the load is in a 32 or 64 bit word comparison.
2. The user node and the load node belong to the same block.
3. The values of the operands have the same size (i.e., no need to zero-extend or sign-extend the result of the load).
BUG=
Review URL: https://codereview.chromium.org/1706763002
Cr-Commit-Position: refs/heads/master@{#34187}
port ba2077aac3 (r34136)
original commit message:
Move the already existing fast case for %NewObject into a dedicated
FastNewObjectStub that we can utilize in places where we would otherwise
fallback to %NewObject immediately, which is rather expensive.
Also use FastNewObjectStub as the generic implementation of JSCreate,
which should make constructor inlining based on SharedFunctionInfo (w/o
specializing to a concrete closure) viable soon.
BUG=
Review URL: https://codereview.chromium.org/1717203002
Cr-Commit-Position: refs/heads/master@{#34182}
Up until now we were unable to (re)optimize code when we hit
uninitialized (Keyed)Load/StoreICs in the code. We always put an IC
there (sharing the feedback vector with fullcodegen at least) and called
it a day. But we never deoptimized the code object when we gathered more
feedback. This doesn't work very well in practice, esp. with hot code
relying on this. So until we have a proper mechanism to express the need
to reoptimize after we gathered additional feedback from optimized code,
we follow the Crankshaft approach instead and install a SOFT deopt, so
we can not only learn but also utilize the new feedback.
R=mstarzinger@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1518013002
Cr-Commit-Position: refs/heads/master@{#34178}
WASM compiler test will sometimes generate invalid instructions for
DINS/INS.
BUG=
Review URL: https://codereview.chromium.org/1709633004
Cr-Commit-Position: refs/heads/master@{#34175}
Most libraries use `JSON.stringify` with all three arguments [1] to allow for
configuration, even if `replacer` and `space` are falsey, causing the
optimized native stringifying to be missed. This commit allows for the common
case where `replacer` and `space` are not used to be fast.
[1]: https://github.com/hapijs/hapi/pull/3014
BUG=v8:4730
LOG=N
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1710933002
Cr-Commit-Position: refs/heads/master@{#34174}
This was changed to match Annex B.2.5.1 of ES2015 and Firefox in
https://chromium.googlesource.com/v8/v8/+/469d9bfa, but website
breakage was seen in M49 Beta. JSC still returns undefined here.
BUG=chromium:585775
LOG=y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1714903004
Cr-Commit-Position: refs/heads/master@{#34172}
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}
Port ba2077aac3
Original commit message:
Move the already existing fast case for %NewObject into a dedicated
FastNewObjectStub that we can utilize in places where we would otherwise
fallback to %NewObject immediately, which is rather expensive.
Also use FastNewObjectStub as the generic implementation of JSCreate,
which should make constructor inlining based on SharedFunctionInfo (w/o
specializing to a concrete closure) viable soon.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1714123002
Cr-Commit-Position: refs/heads/master@{#34169}
