Explain why we still have kNumber in addition to kNumberOrOddball,
although the original motivation, which was Crankshaft, is gone now.
Bug: v8:7109
Change-Id: I33016fbfa96bb0db57473b6d0c720fa1389d11f1
Reviewed-on: https://chromium-review.googlesource.com/817439
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49991}
The CompareOperationFeedback documentation was outdated and there was an
invalid TODO on it that suggested to unify this with the
BinaryOperationFeedback which in retrospect doesn't make a lot of sense.
Bug: v8:7109
Change-Id: Ibf748e242db55430f29d305f1ef1df6d44449481
Reviewed-on: https://chromium-review.googlesource.com/819090
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49990}
This patch adds a field for the speculation mode to Call
nodes, and passes the speculation mode from the CallIC
to the Call node in the byte code graph builder.
Bug: v8:7127
Change-Id: I89fa10643b46143b36776de1d5ba6ebe3fa2c878
Reviewed-on: https://chromium-review.googlesource.com/814537
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49965}
- Implement RunMicrotasks in CSA to prevent a potentially large number
of jumps between C++ and JS code while consuming te queue. Appears to
provide a ~60% speedup in microtask-heavy code, which from limited
testing appears to scale linearly.
The code-stub microtask pump bails out to the old C++ microtask pump
if it encounters a CallHandlerInfo microtask, and remains in C++ for
the remainder of the queue (returning to the JS/stub implementation
after the bailed out queue is exhausted).
- Add a variation of JSEntryStub which enters the new RunMicrotasks code
stub.
- Add a new RunMicrotasks helper to Execution, which uses the
RunMicrotasks entry stub.
Bug:
Change-Id: I4667d4dd633d24455ea5d7cef239da0af1a7365e
Reviewed-on: https://chromium-review.googlesource.com/650486
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49842}
Some uses use uint64_t instead of int64_t to avoid compiler warnings
about illegal narrowing of values with the MSB set.
R=tebbi@chromium.org,mlippautz@chromium.org
Bug: v8:7109
Change-Id: I6e861f48828bd931c451ef336672a260c13ae042
Reviewed-on: https://chromium-review.googlesource.com/803275
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49797}
V8_INT64_C will be cleaned up in a follow-up CL.
R=tebbi@chromium.org,mlippautz@chromium.org
Bug: v8:7109
Change-Id: I6af97e7266039eb443896b404b77b8e2b5de5adb
Reviewed-on: https://chromium-review.googlesource.com/803294
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49790}
Prior to this change, the exponentiation operator was rewritten by the
parser to a call of the Math.pow builtin. However, Math.pow does not
accept BigInt arguments, while the exponentiation operator must accept
them.
This CL
- removes the parser's special treatment of ** and **=, treating them
like any other binary op instead.
- adds a TFC builtin Exponentiate that does the right thing for
all inputs.
- adds interpreter bytecodes Exp and ExpSmi whose handlers call the
Exponentiate builtin. For simplicity, they currently always collect
kAny feedback.
- adds a Turbofan operator JSExponentiate with a typed-lowering to
the existing NumberPow and a generic-lowering to the Exponentiate
builtin. There is currently no speculative lowering.
Note that exponentiation for BigInts is actually not implemented yet,
so we can't yet test it.
Bug: v8:6791
Change-Id: Id90914c9c3fce310ce01e715c09eaa9f294f4f8a
Reviewed-on: https://chromium-review.googlesource.com/785694
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49696}
This is the first step towards wasm code sharing. This CL moves wasm
code generation outside the JavaScript GC heap using the previously -
introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
flag).
See design document: go/wasm-on-native-heap-stage-1
This CL doesn't change other wasm architectural invariants. We still
have per-Isolate wasm code generation, and per-wasm module instance
code specialization.
Bug:v8:6876
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
Reviewed-on: https://chromium-review.googlesource.com/674086
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49689}
Previously, in order to get immortal immovable objects onto
the first page, the serializer would iterate the root list
twice. The first time it would prioritize immortal immovables.
The second time it would serialize the rest.
This does not guarantee that immortal immovable objects
actually end up on the first page, and by now this is not
necessary anymore, since we mark all pages created during
heap init as immortal immovable pages.
R=mlippautz@chromium.org
Change-Id: Ie95fcd779377a75337621ba862bc1a745ed5cbaa
Reviewed-on: https://chromium-review.googlesource.com/768731
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49468}
Port c192569047
Original Commit Message:
We expect no GC between the call to UnwindAndFindHandler and
the call to that handler. We can precalculate the handler entrypoint
and then let the CEntryStub just load and call that address.
The main motivation for this change is the wasm on the native heap
work, and making the CEntryStub able to work with non- Code* values.
R=mtrofin@chromium.org, mstarzinger@chromium.org, bradnelson@chromium.org, titzer@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com
Change-Id: I139fddabef9f601b46dac9011db3ab8e01e3346d
Reviewed-on: https://chromium-review.googlesource.com/752483
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#49107}
We expect no GC between the call to UnwindAndFindHandler and
the call to that handler. We can precalculate the handler entrypoint
and then let the CEntryStub just load and call that address.
The main motivation for this change is the wasm on the native heap
work, and making the CEntryStub able to work with non- Code* values.
Bug: v8:6876
Change-Id: I660f29619edc315afbb537ef3df018865fab7ba4
Reviewed-on: https://chromium-review.googlesource.com/744723
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49084}
Abstract equality comparison of a BigInt and a String converts the
latter to BigInt. This conversion can fail; since we do not want to
pass a context to the comparison function, we must signal such failure
without throwing an exception.
This CL uses the existing ShouldThrow enum to configure behavior of
String-to-BigInt conversion, moving it out of Object into globals.h.
Bug: v8:6791, v8:6979
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ibb98675079b8392cf03bbcbbbd5556108500a32d
Reviewed-on: https://chromium-review.googlesource.com/734172
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48946}
and use a newly-introduced "enum class Operation" in all
other places that so far passed Token::Values around.
Also delete some related dead code along the way.
Bug: v8:6921
Change-Id: I062f396d304aa62298cfeff202e3132a4a5597c1
Reviewed-on: https://chromium-review.googlesource.com/736851
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48944}
Since we don't support gcc 2.96-4.0 any more, we can generalize the
V8_INFINITY macro to always use std::numeric_limits<double>::infinity().
This also makes value constexpr on all systems.
R=tebbi@chromium.org
Change-Id: Ifa97dd2ee6d2c1e179c45f60a82d1ea8481e0590
Reviewed-on: https://chromium-review.googlesource.com/725733
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48694}
This CL teaches the respective bytecode handlers and standalone stubs
about BigInts, and collects "kBigInt" feedback for them. However,
Turbofan does not yet care about such feedback, so it is simply converted
to "any" for now (making TF emit stub calls for BigInt operations).
Bug: v8:6791
Change-Id: I6440c108ccd79058d77adc2a6041251db9d5f81d
Reviewed-on: https://chromium-review.googlesource.com/683758
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48173}
Change-Id: I891ff57b7a3a47e3371269b123705cdf6391499b
Reviewed-on: https://chromium-review.googlesource.com/648513
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47830}
This CL adds support to optimize for..in in fast enum-cache mode to the
same degree that it was optimized in Crankshaft, without adding the same
deoptimization loop that Crankshaft had with missing enum cache indices.
That means code like
for (var k in o) {
var v = o[k];
// ...
}
and code like
for (var k in o) {
if (Object.prototype.hasOwnProperty.call(o, k)) {
var v = o[k];
// ...
}
}
which follows the https://eslint.org/docs/rules/guard-for-in linter
rule, can now utilize the enum cache indices if o has only fast
properties on the receiver, which speeds up the access o[k]
significantly and reduces the pollution of the global megamorphic
stub cache.
For example the micro-benchmark in the tracking bug v8:6702 now runs
faster than ever before:
forIn: 1516 ms.
forInHasOwnProperty: 1674 ms.
forInHasOwnPropertySafe: 1595 ms.
forInSum: 2051 ms.
forInSumSafe: 2215 ms.
Compared to numbers from V8 5.8 which is the last version running with
Crankshaft
forIn: 1641 ms.
forInHasOwnProperty: 1719 ms.
forInHasOwnPropertySafe: 1802 ms.
forInSum: 2226 ms.
forInSumSafe: 2409 ms.
and V8 6.0 which is the current stable version with TurboFan:
forIn: 1713 ms.
forInHasOwnProperty: 5417 ms.
forInHasOwnPropertySafe: 5324 ms.
forInSum: 7556 ms.
forInSumSafe: 11067 ms.
It also improves the throughput on the string-fasta benchmark by
around 7-10%, and there seems to be a ~5% improvement on the
Speedometer/React benchmark locally.
For this to work, the ForInPrepare bytecode was split into
ForInEnumerate and ForInPrepare, which is very similar to how it was
handled in Fullcodegen initially. In TurboFan we introduce a new
operator LoadFieldByIndex that does the dynamic property load.
This also removes the CheckMapValue operator again in favor of
just using LoadField, ReferenceEqual and CheckIf, which work
automatically with the EscapeAnalysis and the
BranchConditionElimination.
Bug: v8:6702
Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
Reviewed-on: https://chromium-review.googlesource.com/645949
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47768}
This reverts commit 1169f55bbc.
Reason for revert: http://crbug.com/758994
Original change's description:
> Remove obsolete kNumber binop feedback.
>
> With the removal of Crankshaft, kNumber has become obsolete as
> BinaryOperationFeedback. Turbofan uses kNumberOrOddball.
>
> Bug:
> Change-Id: If577f5efcc81d7c08f43908f2764ff0ec6f8747c
> Reviewed-on: https://chromium-review.googlesource.com/628376
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47555}
TBR=jkummerow@chromium.org,jarin@chromium.org,neis@chromium.org,mythria@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I1b33f572f3e6865e00d2468bffcce2ea466814b3
Reviewed-on: https://chromium-review.googlesource.com/637711
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47642}
With the removal of Crankshaft, kNumber has become obsolete as
BinaryOperationFeedback. Turbofan uses kNumberOrOddball.
Bug:
Change-Id: If577f5efcc81d7c08f43908f2764ff0ec6f8747c
Reviewed-on: https://chromium-review.googlesource.com/628376
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47555}
For Divide operations like
r = a / b
where r has only truncated uses (i.e. only used in bitwise operations),
we used to generate a Float64Div unless we statically knew something
about a and b, even if a and b have always been integers so far.
Crankshaft was able to generate an integer division here, because
Fullcodegen collected feedback independently for inputs and outputs of
binary operations.
This adds new BinaryOperationFeedback::kSignedSmallInputs, which is used
specifically for Divide to state that we have seen only SignedSmall
inputs thus far, but the outputs weren't always in the SignedSmall
range.
The issue was discovered in a WebGL Triangulation library and reported
via https://twitter.com/mourner/status/895708603117518848 after Node
8.3.0 was released with I+TF.
R=jarin@chromium.org
Bug: v8:6698
Change-Id: I830e421a3bf91fc8fa3665cbb706bc13675a6d2b
Reviewed-on: https://chromium-review.googlesource.com/612063
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47302}
This is a reland of 35c923cc10
Original change's description:
> [heap] Add support for atomic access to page flags.
>
> This patch renames AsAtomicWord to AsAtomicPointer and
> adds new AsAtomicWord that works with intptr_t.
>
> Slot recording uses atomic page flag accessors.
>
> BUG=chromium:694255
>
> Change-Id: I1c692813244b41320182e9eea50462d1802fcd98
> Reviewed-on: https://chromium-review.googlesource.com/597688
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47086}
Bug: chromium:694255
Change-Id: I36780ff4001e068815d4be1e16cd06f1a4f98d13
Reviewed-on: https://chromium-review.googlesource.com/599909
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47131}
This begins splitting up the Deserializer class into
{Object,Partial,Startup}Deserializer. For now, all functionality remains in
the Deserializer base clase, to be refactored in future CLs. Empty .cc files
are added here to avoid having to touch build files again.
Bug: v8:6624
Change-Id: If563e03492991bd55c91cd2e09312c0a26aaab2c
Reviewed-on: https://chromium-review.googlesource.com/598067
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47107}
This patch renames AsAtomicWord to AsAtomicPointer and
adds new AsAtomicWord that works with intptr_t.
Slot recording uses atomic page flag accessors.
BUG=chromium:694255
Change-Id: I1c692813244b41320182e9eea50462d1802fcd98
Reviewed-on: https://chromium-review.googlesource.com/597688
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47086}
Replacing pc with trampoline on stack
This CL is the follow up of https://chromium-review.googlesource.com/c/586707/
which used to crash when running the gc-stress bots.
It seems to be working now. We now keep the trampoline PC in the Safepoint
table and use that information to find SafepointEntries.
There's some refactoring that can be done, such as changing the code for
exceptions in a similar way and removing the trampoline from the
DeoptimizationInputData. Will take care of this in the next CL.
Bug: v8:6563
Change-Id: I8c0a2489de19e6d5fb4ebf1de7da1933726265b4
Reviewed-on: https://chromium-review.googlesource.com/596027
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47066}
This reverts commit a01ac7cbd9.
Reason for revert: Causes flakes on gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/14218
Original change's description:
> Replacing pc with trampoline on stack
>
> This CL is the follow up of https://chromium-review.googlesource.com/c/586707/
> which used to crash when running the gc-stress bots.
> It seems to be working now. We now keep the trampoline PC in the Safepoint
> table and use that information to find SafepointEntries.
>
> There's some refactoring that can be done, such as changing the code for
> exceptions in a similar way and removing the trampoline from the
> DeoptimizationInputData. Will take care of this in the next CL.
>
> Bug: v8:6563
> Change-Id: I02565297093620023a1155b55d76a4dafcb54794
> Reviewed-on: https://chromium-review.googlesource.com/593622
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47030}
TBR=jarin@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
Change-Id: Ie9929c9acae321a91014b76b9008f8835313e67d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6563
Reviewed-on: https://chromium-review.googlesource.com/595927
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47038}
This CL is the follow up of https://chromium-review.googlesource.com/c/586707/
which used to crash when running the gc-stress bots.
It seems to be working now. We now keep the trampoline PC in the Safepoint
table and use that information to find SafepointEntries.
There's some refactoring that can be done, such as changing the code for
exceptions in a similar way and removing the trampoline from the
DeoptimizationInputData. Will take care of this in the next CL.
Bug: v8:6563
Change-Id: I02565297093620023a1155b55d76a4dafcb54794
Reviewed-on: https://chromium-review.googlesource.com/593622
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47030}
This is a reland of 3f90d9f994
Original change's description:
> [Memory] Add an OnCriticalMemoryPressure method to V8::Platform.
>
> Adds virtual V8::Platform::OnCriticalMemoryPressure method, default
> implementation does nothing.
>
> Calls this method on first allocation failures in NewArray, Malloced,
> and zone AccountingAllocator and adds retry logic.
>
> Adds utility functions for allocating base::VirtualMemory to functions
> in allocation.h, which call this method and add retry logic.
>
> Calls these utility functions in heap CodeRange, Spaces, StoreBuffer
> and SequentialMarkingDeque.
>
> Bug: v8:6635
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I38afd394f3be556aca037d16675e9884658158cb
> Reviewed-on: https://chromium-review.googlesource.com/583543
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46988}
Bug: v8:6635
Change-Id: I0d70c5796f407f0ed42cfddf581d26f533f9bea8
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/593090
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47027}
Adds virtual V8::Platform::OnCriticalMemoryPressure method, default
implementation does nothing.
Calls this method on first allocation failures in NewArray, Malloced,
and zone AccountingAllocator and adds retry logic.
Adds utility functions for allocating base::VirtualMemory to functions
in allocation.h, which call this method and add retry logic.
Calls these utility functions in heap CodeRange, Spaces, StoreBuffer
and SequentialMarkingDeque.
Bug: v8:6635
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I38afd394f3be556aca037d16675e9884658158cb
Reviewed-on: https://chromium-review.googlesource.com/583543
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46988}
This reverts commit e15f554427.
Reason for revert: it breaks the GC stress.
Original change's description:
> Changing the return address on the stack.
>
> Rather than patching code, the deoptimizer now replaces the
> return address in the frames with respective trampolines.
> This change required to change the way we search for Safepoint
> entries and for Exception Handlers.
> It's working in architectures: x64, ia32, arm, arm64 and mips.
>
> Bug: V8:6563
> Change-Id: I3cbd4d192c3513f307b3a6a2ac99e60d03c753d3
> Reviewed-on: https://chromium-review.googlesource.com/586707
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46967}
TBR=jarin@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
Change-Id: I430fa9123beef2e0723b38cdef9537181203f7e7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: V8:6563
Reviewed-on: https://chromium-review.googlesource.com/591371
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46969}
Rather than patching code, the deoptimizer now replaces the
return address in the frames with respective trampolines.
This change required to change the way we search for Safepoint
entries and for Exception Handlers.
It's working in architectures: x64, ia32, arm, arm64 and mips.
Bug: V8:6563
Change-Id: I3cbd4d192c3513f307b3a6a2ac99e60d03c753d3
Reviewed-on: https://chromium-review.googlesource.com/586707
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46967}
There remained a few of regressions and we didn't see any significant
improvement in the real world with this turned on. This CL reverts all the
StringConcat bytecode work which landed.
BUG=v8:6243
Change-Id: I832eb72e880ad41411dbec8fe29f71ef0f2025c8
Reviewed-on: https://chromium-review.googlesource.com/575130
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46769}
SuspendFlags was originally used by the suspend operation to determine
which field to record the bytecode offset of a suspended generator, and
the value the generator was resumed with. For async generators, await
operations would use a separate field, in order to preserve the previous
yield input value. This was important to ensure `function.sent`
continued to function correctly.
As function.sent is being retired, this allows the removal of support
for that. Given that this was the only real need for SuspendFlags in the
first place (with other uses tacked on as a hack), this involves several
other changes as well:
- Modification of MacroAssembler AssertGeneratorObject. No longer
accepts a SuspendFlags parameter to determine which type of check to
perform.
- Removal of `flags` operand from SuspendGenerator bytecode, and the
GeneratorStore js-operator.
- Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
- Removal of Runtime functions, interpreter intrinsics and
AccessBuilders associated with the [[await_input_or_debug_pos]] field
in JSAsyncGeneratorObject, as this field no longer exists.
- Addition of a new `Yield` AST node (subclass of Suspend) in order to
prevent the need for the other SuspendFlag values.
BUG=v8:5855
TBR=bmeurer@chromium.org
Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
Reviewed-on: https://chromium-review.googlesource.com/570485
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46683}
This includes several changes. From most to least interesting:
- No longer implement AwaitExpressions using a do-expression.
- Reduces frame-size of async generators by not allocating temporary
variables to hold results of Await epxressions.
- Streamline and reduce generated bytecodes for Await.
- Debugger no longer emits a debug::kCallBreakLocation breakpoint for
the JS-builtin call performed for Await, and instead only emits such
a breakpoint if the operand of Await is actually a call.
- Push fewer parameters to Await* builtins, using the receiver for the
first parameter (possible now that the CallRuntime invocation not
part of the AST).
- Adds a new Await AST node. No new members or anything, but it seemed
palatable to avoid having `if (is_await())` in a number of
VisitSuspend functions.
BUG=v8:5855, v8:5099, v8:4483
R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.orgTBR=bmeurer@chromium.org
Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf
Reviewed-on: https://chromium-review.googlesource.com/558806
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46666}
The tail call implementation is hidden behind the --harmony-tailcalls
flag, which is off-by-default (and has been unstaged since February).
It is known to be broken in a variety of cases, including clusterfuzz
security issues (see sample Chromium issues below). To avoid letting
the implementation bitrot further on trunk, this patch removes it.
Bug: v8:4698, chromium:636914, chromium:724746
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c
Reviewed-on: https://chromium-review.googlesource.com/569069
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46651}
In edge cases such as the following, sloppy-mode block-scoped function
hoisting is expected to occur:
eval(`
with({a: 1}) {
function a() {}
}
`)
In this case, there should be the equivalent of a var declaration
outside of the eval, which gets set to the value of the local function
a when the body of the with is executed.
Previously, the way that var declarations are hoisted out of eval
meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL
assignment. However, such a lookup mode meant that the object in the
with scope received the assignment!
This patch fixes that error by marking the assignments produced by
the sloppy mode block scoped function hoisting desugaring so as to
generate a different runtime call which skips with scopes.
Bug: chromium:720247, v8:5135
Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748
Reviewed-on: https://chromium-review.googlesource.com/529230
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46116}
For interpreted functions, use the optimized code slot in the feedback
vector to store an optimization marker (optimize/in optimization queue)
rather than changing the JSFunction's code object. Then, adapt the
self-healing mechanism to also dispatch based on this optimization
marker. Similarly, replace SFI marking with optimization marker checks
in CompileLazy.
This allows JSFunctions to share optimization information (replacing
shared function marking) without leaking this information across native
contexts. Non I+TF functions (asm.js or --no-turbo) use a
CheckOptimizationMarker shim which generalises the old
CompileOptimized/InOptimizationQueue builtins and also checks the same
optimization marker as CompileLazy and InterpreterEntryTrampoline.
This is a reland of https://chromium-review.googlesource.com/c/509716
Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe
Reviewed-on: https://chromium-review.googlesource.com/535460
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45997}
When iterating over stack frames in the cpu profiler, don't perform any
object casts that have heap-testing DCHECKs. Instead, access values on
the frame by offsets directly, and only check their tags for validity.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia54b18f8ab947c1827f17483806104f0d1d34136
Reviewed-on: https://chromium-review.googlesource.com/536973
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45985}
This reverts commit e39c9e020f.
Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561
Original change's description:
> [compiler] Drive optimizations with feedback vector
>
> For interpreted functions, use the optimized code slot in the feedback vector
> to store an optimization marker (optimize/in optimization queue) rather than
> changing the JSFunction's code object. Then, adapt the self-healing mechanism
> to also dispatch based on this optimization marker. Similarly, replace SFI
> marking with optimization marker checks in CompileLazy.
>
> This allows JSFunctions to share optimization information (replacing shared
> function marking) without leaking this information across native contexts. Non
> I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
> generalises the old CompileOptimized/InOptimizationQueue builtins and also
> checks the same optimization marker as CompileLazy and
> InterpreterEntryTrampoline.
>
> Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
> Reviewed-on: https://chromium-review.googlesource.com/509716
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45901}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94
Reviewed-on: https://chromium-review.googlesource.com/532916
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45903}
For interpreted functions, use the optimized code slot in the feedback vector
to store an optimization marker (optimize/in optimization queue) rather than
changing the JSFunction's code object. Then, adapt the self-healing mechanism
to also dispatch based on this optimization marker. Similarly, replace SFI
marking with optimization marker checks in CompileLazy.
This allows JSFunctions to share optimization information (replacing shared
function marking) without leaking this information across native contexts. Non
I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
generalises the old CompileOptimized/InOptimizationQueue builtins and also
checks the same optimization marker as CompileLazy and
InterpreterEntryTrampoline.
Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
Reviewed-on: https://chromium-review.googlesource.com/509716
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45901}
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}
Adds support for Speculatively lower ToPrimitiveToString to CheckString
where the type hint shows the value has always been a string.
BUG=v8:6243
Change-Id: I7f36deb8c2bc309e6d0546e099c76ac518c6be09
Reviewed-on: https://chromium-review.googlesource.com/521123
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45760}
... to properly handle stack overflows near the hard stack limit.
Bug: chromium:716522
Change-Id: I6acdb29f039b9835bdf45b087d6561a05ed837bb
Reviewed-on: https://chromium-review.googlesource.com/517799
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45619}
For the Scavenger we require a first pass over global handles for identifying
unmodified nodes because the Scavenger might have already written forwarding
pointers during scanning, making it hard to perform the proper checks.
The minor MC does not mutate the object graph during marking and can thus merge
this phase into the regular phase executed during marking roots.
Furthermore, moves processing into the parallel marking phase of the minor MC
collector.
Bug: chromium:720477, chromium:651354
Change-Id: Id33552124264e3ab0bdf34d22ac30c19c1522707
Reviewed-on: https://chromium-review.googlesource.com/509550
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45461}
Introduce a new Symbol comparison feedback bit in the lattice and
collect that feedback on Equal/StrictEqual in Ignition. Utilize this
feedback in TurboFan by adding a dedicated CheckSymbol operator to
check for symbol inputs. This way we can optimize Symbol comparison
where TurboFan doesn't know anything statically about either side, or
abstract equality comparisons where TurboFan doesn't statically know
anything about one side.
BUG=v8:6278,v8:6344,v8:6423
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2893263002
Cr-Commit-Position: refs/heads/master@{#45455}
Special cases addition expressions where one of the sides is known to be a
string to enable chains of string additions to be transformed into a series
of ToPrimitiveToString operations followed by a single string concatenation
at the end of the chain of additions. This should avoid creating temporary
strings for each of the string additions (in essence this is an automated
string builder).
BUG=v8:6243
Change-Id: I44977d6dad00ee906f251c4bd9cab27e160c09d1
Reviewed-on: https://chromium-review.googlesource.com/493966
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45453}
Generate the code (extra runtime calls) for --trace-ignition support at
compile time, based on a #define (similar to TRACE_MAPS). Then check for
--trace-ignition at run-time when deciding whether to actually print
anything. This should make --trace-ignition less painful to use.
Note that --trace-igition is disabled by default, even on debug builds.
It has to be enabled with the gn arg "v8_enable_trace_ignition=true"
As a drive-by, TRACE_MAPS is renamed to V8_TRACE_MAPS, for consistency,
and SFI unique index (needed both by --trace-ignition and --trace-maps)
is cleaned up to be behind another #define.
Change-Id: I8dd0c62d0e6b7ee9c75541d45eb729dc03acbee9
Reviewed-on: https://chromium-review.googlesource.com/506203
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45346}
The reason we need this mode is that IterateRoots for the Scavenger only
captures dependent weak nodes. This is also what we do for marking for the
minor MC.
Since the regular marking might also mark objects that are weakly
(non-dependently) pointed to by nodes we need to capture all of them during
pointers updating. The reason this works for the Scavenger is because we do one
pass at the end of the scavenger (combined with resetting) that captures all
those nodes.
BUG=chromium:651354
Review-Url: https://codereview.chromium.org/2869413002
Cr-Commit-Position: refs/heads/master@{#45248}
This patch expands scope analysis to skip hole initialization
when it can be determined statically that no hole checks will
be generated at runtime.
Two conditions must be met to safely eliminate hole initialization:
- There must not exist a VariableProxy referencing this Variable
whose HoleCheckMode is kRequired
- The Variable must be stack allocated; any other allocation implies
that it may be accessed from not-yet-analyzed scopes (other modules,
inner functions, or eval code) and that code may require
hole checks.
The new logic required removing debug code in full-codegen which is
now incorrect in some cases.
Also fixed Variable's bitfield helpers to take no more space than needed.
Bug: chromium:651637
Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d
Reviewed-on: https://chromium-review.googlesource.com/494006
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45170}
Taking the slow runtime path for every non-internalized string key
can be avoided by doing optimistic string table lookups: if there
is a matching entry, use that; if there isn't, then no existing
object has a property with that name.
The hashing/internalizing logic is in C++ and called directly.
Review-Url: https://codereview.chromium.org/2811333002
Cr-Commit-Position: refs/heads/master@{#44650}
This patch hooks up concurrent marking (behind the flag) with the rest
of the GC:
1. Incremental marking spawns concurrent marking task seeded with the
root set.
2. Mark-compact waits for concurrent marking tasks to finish.
3. Scavenger does fast promotion if concurrent marking is pending.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2735803005
Cr-Commit-Position: refs/heads/master@{#44526}
- Introduce new struct AsyncGeneratorRequest, which holds
information pertinent to resuming execution of an
AsyncGenerator, such as the Promise associated with the async
generator request. It is intended to be used as a singly
linked list, and holds a pointer to the next item in te queue.
- Introduce JSAsyncGeneratorObject (subclass of
JSGeneratorObject), which includes several new internal fields
(`queue` which contains a singly linked list of
AsyncGeneratorRequest objects, and `await_input` which
contains the sent value from an Await expression (This is
necessary to prevent function.sent (used by yield*) from
having the sent value observably overwritten during
execution).
- Modify SuspendGenerator to accept a set of Flags, which
indicate whether the suspend is for a Yield or Await, and
whether it takes place on an async generator or ES6
generator.
- Introduce interpreter intrinsics and TF intrinsic lowering for
accessing the await input of an async generator
- Modify the JSGeneratorStore operator to understand whether or
not it's suspending for a normal yield, or an AsyncGenerator
Await. This ensures appropriate registers are stored.
- Add versions of ResumeGeneratorTrampoline which store the
input value in a different field depending on wether it's an
AsyncGenerator Await resume, or an ordinary resume. Also modifies
whether debug code will assert that the generator object is a
JSGeneratorObject or a JSAsyncGeneratorObject depending on the
resume type.
BUG=v8:5855
R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org,
littledan@chromium.org, neis@chromium.orgTBR=marja@chromium.org
Change-Id: I9d58df1d344465fc937fe7eed322424204497187
Reviewed-on: https://chromium-review.googlesource.com/446961
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44240}
This patch adds support for MIPS SIMD (MSA) instructions in Assembler
and Decoder (disassembler) classes. MSA instructions are implemented for
both mips32 and mips64 architectures.
BUG=
Review-Url: https://codereview.chromium.org/2740123004
Cr-Commit-Position: refs/heads/master@{#44148}
While the primary use-case for Suspend nodes is the Yield expression,
there are other uses as well: Await expressions, and the initial suspend
of Generators, which returns an object matching the Iterator protocol.
"Suspend" is a better representation of the spec text (closer
to the spec text for the values of [[GeneratorState]] and
[[AsyncGeneratorState]]), and can make it easier to understand the
meaning of what I had previously called Yield::is_normal() (now
Suspend::is_yield()).
Changes requested as part of https://chromium-review.googlesource.com/c/447117/
BUG=
R=neis@chromium.org, adamk@chromium.orgTBR=bmeurer@chromium.org, paul.lind@imgtec.com, joransiu@ca.ibm.com, weiliang.lin@intel.com
Change-Id: Ic6f15b04fff091c20f26526391b967287c06f6bf
Reviewed-on: https://chromium-review.googlesource.com/455583
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44038}
Default to the chromium-internal build config (instead of the more
permissive no_chromium_code config).
BUG=v8:5878
Review-Url: https://codereview.chromium.org/2758563002
Cr-Commit-Position: refs/heads/master@{#43909}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
Previously, when restarting a frame, we would rewrite all frames
between the debugger activation and the frame to restart to squash
them, and replace the return address with that of a builtin to
leave that rewritten frame, and restart the function by calling it.
We now simply remember the frame to drop to, and upon returning
from the debugger, we check whether to drop the frame, load the
new FP, and restart the function.
R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5587
Review-Url: https://codereview.chromium.org/2636913002
Cr-Commit-Position: refs/heads/master@{#42725}
We can share almost all of the architecture-specific builtin code with super-call-with-spread.
Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2649143002
Cr-Commit-Position: refs/heads/master@{#42632}
Collect Receiver feedback for abstract/strict equality in Ignition and
use it in TurboFan to optimize JSEqual and JSStrictEqual operations to
pointer equality instead of having to call Equal/StrictEqual builtins.
R=jarin@chromium.org
BUG=v8:5267,v8:5400
Review-Url: https://codereview.chromium.org/2639883002
Cr-Commit-Position: refs/heads/master@{#42435}
Add machinery to Ignition and TurboFan to collect and consume
InternalizedString feedback for abstract and strict equality
comparisons. Here we can turn the comparison into a simple
pointer equality check.
R=jarin@chromium.org
BUG=v8:5786
Review-Url: https://codereview.chromium.org/2609013002
Cr-Commit-Position: refs/heads/master@{#42008}
Currently, to find out a Promise's status and result, one has to use the
debug context. This is for example done in Node.js. This new API is a
better replacement, also in the context of the debug context being
deprecated eventually.
R=franzih@chromium.org, gsathya@chromium.org, jochen@chromium.org
BUG=v8:5764
Review-Url: https://codereview.chromium.org/2589113002
Cr-Commit-Position: refs/heads/master@{#41855}
Encode the PropertyAttribute and whether the function
names must be set as a flag instead of setting two registers.
BUG=v8:5624
Review-Url: https://codereview.chromium.org/2586463002
Cr-Commit-Position: refs/heads/master@{#41812}
TurboFan can indeed comsume NumberOrOddball feedback for abstract
relational comparisons, so we should just provide it from Ignition.
Drive-by-fix: Add a DCHECK to protect against abstract/strict equality
number comparison accidentially utilizing Oddball feedback.
BUG=v8:5267,v8:5400
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2518283002
Cr-Commit-Position: refs/heads/master@{#41166}
Reason for revert:
Turbofan doesn't do proper ToNumber conversions on NumberOrOddball equality conversions.
BUG=v8:5660
Original issue's description:
> [Interpreter] Collect NumberOrOddball feedback in CompareOps.
>
> Collect feedback for oddballs in the interpreter compare operations handlers.
> This is important to ensure that we don't consider oddball comparisons as
> generic, which prevents optimization.
>
> BUG=chromium:660947
>
> Committed: https://crrev.com/721e74d9d942fd4f2e3392ea9626d9d404dbbbd0
> Cr-Commit-Position: refs/heads/master@{#41081}
TBR=bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:660947
Review-Url: https://codereview.chromium.org/2517133002
Cr-Commit-Position: refs/heads/master@{#41134}
Collect feedback for oddballs in the interpreter compare operations handlers.
This is important to ensure that we don't consider oddball comparisons as
generic, which prevents optimization.
BUG=chromium:660947
Review-Url: https://codereview.chromium.org/2506283003
Cr-Commit-Position: refs/heads/master@{#41081}
