Implicitly rethrow the exception when we reach the end of a
try..unwind..end. Also make it a validation error to rethrow
an exception caught by an unwind block.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: Ia149d2e81b1fbfa9209047b35ff0c9fedc1b8895
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696662
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72785}
The WasmThrow and WasmRethrow runtime functions have the same signature,
but we should still use the correct description in case the signature
changes (which is planned for a follow-up CL).
R=thibaudm@chromium.org
Bug: v8:11453
Change-Id: Iaec9c353d30fa7673ceb8994e3029c4adfc01311
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697348
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72784}
The Debug::SetBreakPointForScript() method essentially figures out the
SharedFunctionInfo and then duplicates the logic from SetBreakpoint().
Bug: chromium:1162229
Change-Id: Iae98ab5d182739d44e0277b799509723d950f381
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697351
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72782}
- Adds DCHECKs to make sure no stack slots are allocated after
aligning a frame.
- Changes Arm64 CodeGenerator::FinishFrame to align the frame after
allocating callee-saved registers, and relaxes the constraints on
the number of callee-saved registers.
Bug: v8:9198
Change-Id: Iacb0518b57fa3ea2ff801eda69719f4c32733850
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2694104
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72781}
This CL avoids redundant loads of the instance from the frame by caching
it in a register if possible. This register will be the first one to be
cleared once we run out of registers (hence it's called a "volatile
register"). On local tests, this seems to reduce most redundant loads
within a function, and it also reduces the load for the stack check in
the function prologue.
After the stack check, we need to discard the cached instance though,
since the potential runtime call for the stack check might clobber it.
This will be addressed in a follow-up CL by re-loading the cached
instance after the stack check. This is expected to remove another good
chunk of instance loads, because the instance would initially be
available in a register when starting the function code.
R=thibaudm@chromium.org
Bug: v8:11336
Change-Id: Ie65ab81263fb9d972f4b7a6daaef86cf704874ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695401
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72779}
This reverts commit cf93071c91.
Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72777}
My previous CL was missing a negation in two places.
Bug: chromium:1178731
Change-Id: I5bc4d78226e43a62ddd374c3d7dd36a9ed0c1a2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697192
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72775}
Custom platform implementations which do not run all foreground tasks
before shutting down an isolate could trigger a DCHECK (see linked
issue).
This was introduced in https://crrev.com/c/2578980, but the bug does not
trigger in the default platform implementation, hence went unnoticed.
Since it's only a spurious DCHECK error without security implications, I
decided against a test with a custom platform implementation to
reproduce the bug.
R=ahaas@chromium.org
Bug: v8:11456
Change-Id: Ie01562af7bdffe23cad7172180f2bc19ea61dfda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697189
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72774}
Design doc:
https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
that we can use a single byte to represent the common operation of
storing to a low-numbered register. This generally reduces the quantity
of bytecode generated on web sites by 8-9%.
In order to not degrade speed, a couple of other changes are required:
The existing lookahead logic to check for Star after certain other
bytecode handlers is updated to check for these new short Star codes
instead. Furthermore, that lookahead logic is updated to contain its own
copy of the dispatch jump rather than merging control flow with the
lookahead-failed case, to improve branch prediction.
A bunch of constants use bytecode size in bytes as a proxy for the size
or complexity of a function, and are adjusted downward proportionally to
the decrease in generated bytecode size.
Other small drive-by fix: update generate-bytecode-expectations to emit
\n instead of \r\n on Windows.
Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72773}
Baseline scratch registers don't include the regular kScratchRegister
(for now at least) because the rest of the system doesn't use the
ScratchRegisterScope (yet).
Bug: v8:11429
Change-Id: I7a2f27a814e262e5b14bd30b2ae53d53e173bcc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697194
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72771}
Lazy sweeping may have found a memory block not positioned at the head
of the corresponding bucket. Such a block is not found during a
subsequent free list allocation, as such allocations do not linearly
walk the free list.
Bug: chromium:1056170
Change-Id: I288b6ad768987705d86fc78d0aa6fe46e99417b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692822
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72770}
The current API returns a Handle<NativeContext> which can be
optionally null and all the users of this API never actually
checked for this null value.
Previously, this wasn't a problem as all the possible JSObjects
that were user visible would return a valid NativeContext but now
there are wasm objects that don't have a valid constructor so don't
have a NativeContext.
Bug: v8:11451, chromium:1166077
Change-Id: I4fd5edf8f1a750e6f0abb931fd41358e5ae4dfcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692695
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72769}
When there are multiple nested catch blocks, the rethrow immediate
disambiguates which catch block to take the exception from. We
add a FixedArray to keep track of exceptions that are currently
in scope, and compute the mappings between rethrow/catch instructions
and the index to fetch/store the exception from/to in the FixedArray
during pre-processing.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: If55242c551f42262c790b5bf3f1543a003280623
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695388
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72768}
Change the interpreter tracing functions to be generic unoptimized code
tracing functions. The type of the code is now inferred from the frame,
rather than passed in.
Also expands the set of gn flags to explicitly enable unoptimized
tracing, with a helper gn flags for enabling it for Ignition and for
baseline (both just set unoptimized tracing to be enabled for now, we
could split this up in the future though), and V8 flags separate tracing
Ignition and tracing baseline.
Bug: v8:11420, v8:11429
Change-Id: I040c2628fe5744dcb38ef8623df3e34f9c86a5b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692817
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72767}
The origin trial for WebAssembly Threads is over for quite some time,
WebAssembly Threads are enabled by default. The API can therefore be
removed now.
Bug: v8:11384
Change-Id: I3dd65ff63c1ed31d39a76e5aea08b950ef420f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690598
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72766}
Changes:
- In graph-builder-interface.cc, move loop exit utilities in the private
section.
- In the same functions, remove SsaEnv argument. Always use ssa_env_
instead.
- Introduce TerminateThrow, which introduces loop exits before inserting
a throw node.
- Introduce loop exits in the exception handling opcodes.
- Introduce control_depth_of_current_catch() helper.
- Drive-by: Add an optional missing 'break' in DoReturnCall.
- Add some tests, improve test flags in loop-unrolling.js test file.
Bug: v8:11298
Change-Id: I613352023e3e1c72a83cd389d98574758655abee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692820
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72765}
- Also changes in arm and ia32 for consistency
- Removes fall-through since MaybeOptimizeCode never returns
Change-Id: I115cff07c7d58ac3f7d0e0feeccbd6b1b172bd53
Bug: v8:11429
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695392
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72764}
On-heap hash maps in blink are limited to Member types and non-traceable
types. The only exception to that is TraceWrapperV8Reference. Thus
ephemerons can have non-gced traceable values. This values should not be
pushed to the marking worklist since we expect everything in the
worklist to be marked and not in construction (but these values don't
have an object header).
Instead, when getting a non-gced value we should immediately trace it.
This is only relevant to ephemerons. Any other case would go through
Trace(const T&) that dispatches to the TraceTrait.
Blink has 1 use case of HeahHashMap from WeakMember<ScriptWrappable> to
TraceWrapperV8Reference.
Bug: chromium:1056170
Change-Id: Ia8f341d6bb1fc8fd3655b2be66b7814896549d1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696648
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72763}
Pass an explicit Isolate* argument to Compiler::Compile*, rather
than grabbing the Isolate from the function
Change-Id: I37a38103c67305077225ea3951d36007cf07beea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696655
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72762}
We will need more Smi loading for exception handling, hence refactor the
existing code to reduce duplication and increase readability.
R=ahaas@chromium.org
Bug: v8:11453
Change-Id: If12ddf607e3aeb7ce0448d977d0d450127caf1d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692818
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72761}
They are a source of inconsistency and thus confusion.
Bug: v8:11371
Change-Id: Ia62f6800ad85576bed1cfe10e7ad044bdbf569af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692247
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72759}
For stack traces, especially all stack traces exposed via the Inspector
(i.e. for the purpose of async stack traces), JSFunction::GetDebugName()
is still a bottleneck, even after the removal of "displayName" support.
As outlined in https://bit.ly/devtools-function-displayName-removal a
follow-up optimization here would be to improve the performance of the
"name" lookup. Previously, it'd always use the LookupIterator combined
with JSReceiver::GetDataProperty(), which in the common case would find
the "name" property and the return undefined, since it doesn't invoke
getters on AccessorInfos, and eventually fall through to the actual
logic in SharedFunctionInfo::DebugName().
Now we had a similar situation with Function.prototype.bind(), which
also needs to lookup "name" on regular function objects quite often, and
what we implemented there is to just look into the DescriptorArray of
the incoming function object and see if the entry for the "name"
descriptor is still untouched (key is "name" and value is an
AccessorInfo), and if so completely bypass the slow-path lookup via the
LookupIterator.
With this CL (and the optimization in https://crrev.com/c/2695386), the
cost of symbolization is now significantly lower than the cost of the
actual stack trace capturing, for the async stack traces in the example
from https://crbug.com/1077657 as indicated by the perf profile below:
```
- 26.03% v8_inspector::AsyncStackTrace::capture
+ 17.34% v8::StackTrace::CurrentStackTrace
- 7.27% v8_inspector::(anonymous namespace)::toFramesVector
- 7.18% v8_inspector::V8Debugger::symbolize
- 6.27% v8_inspector::StackFrame::StackFrame
+ 2.52% v8_inspector::toProtocolString
+ 1.88% v8::internal::StackFrameInfo::GetLineNumber
0.78% operator new[]
0.55% operator new[]
```
Bug: chromium:1077657, v8:8742, chromium:1069425, chromium:1177685
Change-Id: I38f23816295f4381f5109cc78e4856dc0b67b097
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695593
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72758}
- Directly use the right target register for the "fast" case as temporary
register
- Don't load the function to load the feedback since that's unnecessary
by now
- Deduplicate the cell loading code
Bug: v8:11429
Change-Id: Ia2298315c2db6f228be0821687ff92859169dd97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695588
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72755}
Previously we had cached the source position information on
JSStackFrame (C++) objects and reused that between calls to
GetLineNumber() and GetColumnNumber(). The refactoring in
https://crrev.com/eed0d27c2f774b3adbc85d0a5fb30a8cf0f018a8
effectively removed that cache, while still making things
faster though.
This CL puts back the caching on the StackFrameInfo objects
by reusing the `offset` slot to store the computed source
position (as indicated by a bit in the `flags`). For promise
combinator async frames, the bit is always set and the
`offset_or_source_position` slot thus always contains the source
position (aka the `promise index` in this case). We also
added a `StackFrameInfo::ComputeLocation()` method to remove the
last remaining place where we'd peek into the StackFrameInfo from
outside stack-frame-info.{cc,h}.
Also-By: kimanh@chromium.org
Bug: chromium:1077657, v8:8742, chromium:1069425
Change-Id: I59e26a91965617163776e6cc2610b88e6925452c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695386
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72752}
This is a reland of 5cc7bfd04c, after the
dependency has relanded.
Original change's description:
> [compiler] Clean up ObjectDataKind
>
> In particular: remove PossiblyBackgroundSerializedHeapObject in favor of
> either SerializedHeapObject or BackgroundSerializedHeapObject, depending
> on the (existing) argument to the ObjectRef constructor.
>
> Bug: v8:7790
> Change-Id: I0a67872c377107799233742cc7774bea62811d0f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681946
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72591}
Tbr: solanes@chromium.org, nicohartmann@chromium.org
Bug: v8:7790
Change-Id: I7de88f54172078a42b5aa341b11309ac3581eed0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695589
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72751}
This removes a redundant SpillRegisters implementation in
liftoff-assembler-ia32.h, and uses the existing platform-independent
method in liftoff-assembler.h consistently.
R=ahaas@chromium.org
Bug: v8:11384
Change-Id: I20f0417c248e06557dc1fe8bab834a99257940de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695399
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72750}
Port 15f3392a7e
Original Commit Message:
This CL adds support for instrumentation breakpoints in wasm. The
request for "break on entry" is set on the script, and we need to
keep
it stored there because there might not be any instances of that
wasm
module yet. Once instances get created, the flag value is
transferred to
all instances. The flag stored there is then checked in the function
prologue in Liftoff debugging code. This ensures that we will stop
at
the first valid break position in any function within that module.
Hitting that instrumentation breakpoint will then clear the flag
from
the script and from all other live instances (in the same isolate).
A first basic test is contained in this CL. More tests will be added
later.
R=clemensb@chromium.org, midawson@redhat.com, mfarazma@redhat.com
BUG=
LOG=N
Change-Id: I892eec22aa804abb8b22f3bdd811664f9a2605d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695606
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72749}
This reverts commit 1370b29e75.
Reason for revert: Breaks some targets that lack a dependency onto v8-gn.h, see https://crbug.com/1178409.
Original change's description:
> [build] Enable external flag header with defines
>
> Due to some unusual build failures on some trybots,
> v8_generate_external_defines_header was reverted to false. This turns it
> back on but changes the behaviour so that defines are added to the
> command line as well as to the header. Because the generated header
> checks that flags that should be unset are actually unset and flags that
> should be set are either unset or set to 1, this will cause build
> failures on many types of mismatches, although it will not detect where a
> flag is not set on the command line when it is set by the header.
>
> If no further failures show up with this, the hybrid part can be removed
> and the v8-gn.h header can stand on its own.
>
> Bug: v8:11292, v8:11341
> Change-Id: I1deeeebec58f79607e68a28f808649e884810923
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649041
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72327}
TBR=mlippautz@chromium.org,delphick@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:11292
Bug: v8:11341
Change-Id: I6cf57014ef8be73c286ad9c5ebf597915f183717
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695400
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72748}
We could revisit this later, but right now the direction we're going is
simply keeping fast paths in the called builtins and not generating more
custom inline code.
Bug: v8:11429
Change-Id: I2e3a67e1a2a2ab62e8c785dd9bdf2de3e7215f60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695405
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72747}
Add (ToNumber|ToNumeric)_Baseline builtins which get the feedback vector
and context from the stack, perform ToNumber/ToNumeric, and update
feedback. These share C++ code with Builtins::kToNumber, but don't call
it directly, as they need to collect feedback as part of the conversion.
Bug: v8:11420, v8:11429
Change-Id: Idca1281004ec27096cbe9204653fdd72386ab52b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692573
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72746}
The check was a leftover from a debugging session.
We don't have a feedback vector even though we have baseline code,
e.g. when we share baseline code across realms. In this case
the feedback vector will be allocated upon the first invocation
of the function.
Bug: chromium:1177217
Change-Id: Ia5cde35b0f5d746c2ba64d3ca2083acdfaf286bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695396
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72745}
Add a new StackFrame class for unoptimized frames (which are either
interpreted or baseline). BaselineFrame becomes a subclass of this
rather than InterpretedFrame, and the various frame constants helpers
are similarly amended.
Bug: v8:11420, v8:11429
Change-Id: I87e9368aef48ef06a39476bf826f379ce1441528
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692208
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72743}
This adds a call to re-compile top level functions in case
no shared function info could be found. We ran into a bug
where it was not possible to set a breakpoint on the
top-level function since it was already removed by the GC.
Bug: chromium:1137141
Change-Id: I5bb6984825eee8ebcb44619e15b3acf3d118b9bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672181
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72738}
