To be consistent with the all the other tiers and avoid confusion, we
rename --opt to ---turbofan, and --always-opt to --always-turbofan.
Change-Id: Ie23dc8282b3fb4cf2fbf73b6c3d5264de5d09718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610431
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80336}
https://crrev.com/c/3571817 introduced a bug that string table lookups
failed on SlicedStrings with a start offset of 0.
This CL fixes the issue by re-using the already computed hash only
if the length of the source string matches the length of the string to
lookup.
Bug: chromium:1320179, chromium:1321573
Change-Id: Ic8755a0266a9ec67fe5eb9c96fdab1b55d5009f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616723
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80309}
This is a reland of commit 9145388055
Fixed: properly reference the ClearedValue in CSA (i.e. without
the cage_base upper 32 bits).
Original change's description:
> Reland "[osr] Use the new OSR cache"
>
> This is a reland of commit 91da38831d
>
> Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> on arm64.
>
> Original change's description:
> > [osr] Use the new OSR cache
> >
> > This CL switches over our OSR system to be based on the feedback
> > vector osr caches.
> >
> > - OSRing to Sparkplug is fully separated from OSR urgency. If
> > SP code exists, we simply jump to it, no need to maintain an
> > installation request.
> > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> > If a valid target code object exists, we enter it *without*
> > calling into runtime to fetch the code object.
> > - Finally, OSR urgency still remains as the heuristic for
> > requesting Turbofan OSR compile jobs. Note it no longer has a
> > double purpose of being a generic untargeted installation
> > request.
> >
> > With the new system in place, we can remove now-unnecessary
> > hacks:
> >
> > - Early OSR tierup is replaced by the standard OSR system. Any
> > present OSR code is automatically entered.
> > - The synchronous OSR compilation fallback is removed. With
> > precise installation (= per-JumpLoop-bytecode) we no longer
> > have the problem of 'getting unlucky' with JumpLoop/cache entry
> > mismatches. Execution has moved on while compiling? Simply spawn
> > a new concurrent compile job.
> > - Remove the synchronous (non-OSR) Turbofan compile request now
> > that we always enter available OSR code as early as possible.
> > - Tiering into Sparkplug no longer messes with OSR state.
> >
> > Bug: v8:12161
> > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> > Commit-Queue: Jakob Linke <jgruber@chromium.org>
> > Auto-Submit: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80147}
>
> Bug: v8:12161
> Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80167}
Bug: v8:12161,chromium:1320189
Change-Id: Ibd9a2ab61f51ebb32a3f5a66f7c602faead71c3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620273
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80306}
This reverts commit 9145388055.
Reason for revert: Breaking the Fuchsia Deterministic Builder
Original change's description:
> Reland "[osr] Use the new OSR cache"
>
> This is a reland of commit 91da38831d
>
> Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> on arm64.
>
> Original change's description:
> > [osr] Use the new OSR cache
> >
> > This CL switches over our OSR system to be based on the feedback
> > vector osr caches.
> >
> > - OSRing to Sparkplug is fully separated from OSR urgency. If
> > SP code exists, we simply jump to it, no need to maintain an
> > installation request.
> > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> > If a valid target code object exists, we enter it *without*
> > calling into runtime to fetch the code object.
> > - Finally, OSR urgency still remains as the heuristic for
> > requesting Turbofan OSR compile jobs. Note it no longer has a
> > double purpose of being a generic untargeted installation
> > request.
> >
> > With the new system in place, we can remove now-unnecessary
> > hacks:
> >
> > - Early OSR tierup is replaced by the standard OSR system. Any
> > present OSR code is automatically entered.
> > - The synchronous OSR compilation fallback is removed. With
> > precise installation (= per-JumpLoop-bytecode) we no longer
> > have the problem of 'getting unlucky' with JumpLoop/cache entry
> > mismatches. Execution has moved on while compiling? Simply spawn
> > a new concurrent compile job.
> > - Remove the synchronous (non-OSR) Turbofan compile request now
> > that we always enter available OSR code as early as possible.
> > - Tiering into Sparkplug no longer messes with OSR state.
> >
> > Bug: v8:12161
> > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> > Commit-Queue: Jakob Linke <jgruber@chromium.org>
> > Auto-Submit: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80147}
>
> Bug: v8:12161
> Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80167}
Bug: v8:12161
Change-Id: I73e2d98660e9edfbe07a152a14402380ea9227de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615219
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80287}
- Supports Float64 Add for SmiAdd bytecode
- Adds a Float64Constant and ChangeInt32ToFloat64 nodes
- Converts floats to tagged in Phi node inputs
- Fixes spill double representation
- Fixes materialisation during a deopt of a double in the stack
Bug: v8:7700
Change-Id: I9217a64313b4bd5d0015f935c23771ecf9a2c7ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610426
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80255}
Add an unboxing double field load node, and fix a couple of locations
where it might be used enough to pass tests.
Bug: v8:7700
Change-Id: Ic134484e87a4fa363cbd8a3de667ac8e8116d502
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610623
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80221}
This fixes the ordering of DCHECKs which expect the value to not be in
the free list yet when it is dropped.
Bug: v8:7700
Change-Id: Ifb85d0e20cfe5c083d1f2bc971817143265fdc7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610444
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80218}
CheckedFloat64Unbox mutates the input value, but the register allocator
does not expects this behaviour and propagates a wrong value in the register.
In particular we deopt with the wrong value if the second Float64Unbox
in a Float64Add needs to deopt.
This fixes the input value after we convert to double.
Bug: v8:7700
Change-Id: Ib89573e9f728dc3a34b817fc84f1afcb96f14d18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610422
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80214}
The JS import returns a tagged value, not a value of the machine
representation that corresponds to the signature's return type, since it
hasn't been converted yet.
R=ahaas@chromium.org
Bug: v8:12191
Change-Id: I0783af85eed9c5d25347200540e3e4eee48edfd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3464036
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80213}
This logic was confused in the presence of inlined frames; the
deopt exit offset would point inside the innermost inlined frame
while we incorrectly assumed it points at the outermost frame.
Fix this by always referring to the bytecode offset of the outermost
frame.
Bug: v8:12161
Fixed: chromium:1320094
Change-Id: I2eb28498639432c5344859f64a9388d93ee23bde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3608630
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80212}
This CL includes count value to InvalidCountValue error message to make
it easier to dignoise RangeError of String.prototype.repeat. When
InvalidCountValue error throw, we could not know it's
caused by which count value if count value is not included.
Bug: none
Change-Id: I16e6693da0fc3b181241cb90daca27957f59c77c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3593574
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80198}
When passing anyref-typed things to Wasm, we cannot expect that
all functions are WasmExternalFunctions. Instead of adding a
relatively expensive type check to such calls, this patch disables
function unwrapping for anyref-typed values.
Fixed: v8:12789
Change-Id: Ied57187bac7fde0326634f7b4fc428ad21dc9c2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605231
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80179}
- For simplicity we call a builtin when allocating a number.
- Elision of boxing/unboxing nodes will be done in a followup CL.
Bug: v8:7700
Change-Id: Iec4422d84c6597d3369ab512a1662adb0f077c98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602514
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80178}
Table.set has two arguments, the table index and the value. Therefore
Table.set was defined with a length of 2. However, the value argument is
optional, so the length should actually be 1.
Change-Id: Ica2ea13a8e78c974cb011df2b5dc99f8e7eb4bcd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398496
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80176}
This is a reland of commit 91da38831d
Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
on arm64.
Original change's description:
> [osr] Use the new OSR cache
>
> This CL switches over our OSR system to be based on the feedback
> vector osr caches.
>
> - OSRing to Sparkplug is fully separated from OSR urgency. If
> SP code exists, we simply jump to it, no need to maintain an
> installation request.
> - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> If a valid target code object exists, we enter it *without*
> calling into runtime to fetch the code object.
> - Finally, OSR urgency still remains as the heuristic for
> requesting Turbofan OSR compile jobs. Note it no longer has a
> double purpose of being a generic untargeted installation
> request.
>
> With the new system in place, we can remove now-unnecessary
> hacks:
>
> - Early OSR tierup is replaced by the standard OSR system. Any
> present OSR code is automatically entered.
> - The synchronous OSR compilation fallback is removed. With
> precise installation (= per-JumpLoop-bytecode) we no longer
> have the problem of 'getting unlucky' with JumpLoop/cache entry
> mismatches. Execution has moved on while compiling? Simply spawn
> a new concurrent compile job.
> - Remove the synchronous (non-OSR) Turbofan compile request now
> that we always enter available OSR code as early as possible.
> - Tiering into Sparkplug no longer messes with OSR state.
>
> Bug: v8:12161
> Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80147}
Bug: v8:12161
Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80167}
Currently the Isolate is gotten off of the object that the operation is
being performed on. Shared objects return the shared Isolate, which is
incorrect as it shouldn't be used to run JS, nor does it have
HandleScopes open. Plumb the executing Isolate through.
Bug: v8:12547
Change-Id: I3d960751c798ac657a6122598154e36d9d504c31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606489
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80163}
This reverts commit 91da38831d.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression%20-%20builder/21150/overview
Original change's description:
> [osr] Use the new OSR cache
>
> This CL switches over our OSR system to be based on the feedback
> vector osr caches.
>
> - OSRing to Sparkplug is fully separated from OSR urgency. If
> SP code exists, we simply jump to it, no need to maintain an
> installation request.
> - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> If a valid target code object exists, we enter it *without*
> calling into runtime to fetch the code object.
> - Finally, OSR urgency still remains as the heuristic for
> requesting Turbofan OSR compile jobs. Note it no longer has a
> double purpose of being a generic untargeted installation
> request.
>
> With the new system in place, we can remove now-unnecessary
> hacks:
>
> - Early OSR tierup is replaced by the standard OSR system. Any
> present OSR code is automatically entered.
> - The synchronous OSR compilation fallback is removed. With
> precise installation (= per-JumpLoop-bytecode) we no longer
> have the problem of 'getting unlucky' with JumpLoop/cache entry
> mismatches. Execution has moved on while compiling? Simply spawn
> a new concurrent compile job.
> - Remove the synchronous (non-OSR) Turbofan compile request now
> that we always enter available OSR code as early as possible.
> - Tiering into Sparkplug no longer messes with OSR state.
>
> Bug: v8:12161
> Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80147}
Bug: v8:12161
Change-Id: I4a6955f4f20b6f3b13e98d5600c7c6a5205915bc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605608
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80148}
This CL switches over our OSR system to be based on the feedback
vector osr caches.
- OSRing to Sparkplug is fully separated from OSR urgency. If
SP code exists, we simply jump to it, no need to maintain an
installation request.
- Each JumpLoop checks its dedicated FeedbackVector cache slot.
If a valid target code object exists, we enter it *without*
calling into runtime to fetch the code object.
- Finally, OSR urgency still remains as the heuristic for
requesting Turbofan OSR compile jobs. Note it no longer has a
double purpose of being a generic untargeted installation
request.
With the new system in place, we can remove now-unnecessary
hacks:
- Early OSR tierup is replaced by the standard OSR system. Any
present OSR code is automatically entered.
- The synchronous OSR compilation fallback is removed. With
precise installation (= per-JumpLoop-bytecode) we no longer
have the problem of 'getting unlucky' with JumpLoop/cache entry
mismatches. Execution has moved on while compiling? Simply spawn
a new concurrent compile job.
- Remove the synchronous (non-OSR) Turbofan compile request now
that we always enter available OSR code as early as possible.
- Tiering into Sparkplug no longer messes with OSR state.
Bug: v8:12161
Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80147}
TurboShaft is a new, CFG-based IR for TurboFan.
This CL adds the basic IR and bidirectional translation from/to
TurboFan's sea-of-nodes-based IR for some common operators (still
incomplete even for JS).
Bug: v8:12783
Change-Id: I162fdf10d583a9275a9f655f5b44b888faf813f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563562
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80136}
- In DeserializeContext, scope info local values
snapshot is in order of `name,value,name,value`,
and we should ReadValue after ReadString.
- Support non-inlined ScopeInfo locals, use
NameToIndexHashTable to serialize and deserialize
scope info local values when its local count is
more than kScopeInfoMaxInlinedLocalNamesSize.
Bug: v8:11525, v8:12820
Change-Id: I6ea2c498b594bed7ba8ca5be6af2ab9f0d39aa2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3600531
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80130}
As per https://tc39.es/ecma262/#sec-hostimportmoduledynamically defined,
referencingScriptOrModule in HostImportModuleDynamically can be a Script
Record, a Module Record, or null.
So to https://tc39.es/proposal-shadowrealm/#sec-shadowrealmimportvalue,
the HostImportModuleDynamicallyCallback is been invoked with a `null`
resource_name. This may not be considered a breaking change as the
parameter resource_name is defined as Local<Value>.
Updates d8's DoHostImportModuleDynamically to handle null resource_name,
and resolve the dynamically imported specifier relative to the executing
script's origin. In this way, we have to set ModuleEmbedderData.origin
even if the JavaScript source to be evaluated is Script. Also, a
ModuleEmbedderData is created for each ShadowRealm to separate their
module maps from the initiator context's.
Bug: v8:11989
Change-Id: If70fb140657da4f2dd92eedfcc4515211602aa46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3522883
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#80118}
This CL extends GetIterator to check whether the result of
calling @@iterator is JSReceiver and throw SymbolIteratorInvalid
if it's not JSReceiver.
GetIterator bytecode involves 3 steps now:
- method = GetMethod(obj, @@iterator)
- iterator = Call(method, obj)
- if(!IsJSReceiver(iterator)) throw SymbolIteratorInvalid [Added]
New Builtin: CallIteratorWithFeedbackLazyDeoptContinuation, which
is used when lazy deopt is triggered by call @@iterator.
Related spec: https://tc39.es/ecma262/#sec-getiterator.
Related doc: https://docs.google.com/document/d/1s67HC2f-4zxA_s1Bmm7dfwMFv_KDUfMiWIKkNSeQNKw/edit#heading=h.kdzv8mq4g4ks.
Bug: v8:9489
Change-Id: I17952c0f3e24e1e600ee1348809fb188c2c70f8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563447
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80112}
In the simplest way possible.
Bug: v8:7700
Change-Id: I155aaf85192b75c89617820d6f127a2ae04c7d9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599484
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80089}
Add a --maglev-inlining flag, and add some half-baked support for
inlining functions when there is call feedback.
When the flag is enabled and there is call feedback, we create a nested
MaglevGraphBuilder for the current graph, and pause building the graph
of the outer function. We manually set up its prologue to set up its
frame with the arguments pass into the call, build the body with the
nested graph builder. This inner builder knows that it is building an
inlined function, and all Return bytecodes will instead emit a Jump to a
single merge block at the end of the function, where execution of the
outer function can resume.
These inner function basic blocks are wired into the outer graph with
new JumpToInline and JumpFromInline control nodes. The idea is that
subsequent passes will know what the inline function is, and will use
these to manage the function stack (particularly for codegen and
especially deopts).
Bug: v8:7700
Change-Id: I4e9b153f8cf4d06c56e7be6365e7a18b86a773c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585958
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80077}
As ecma262 normative change https://github.com/tc39/ecma262/pull/2683,
exception thrown on PromiseResolve the broken promises need to be caught
and use it to reject the promise returned by
`AsyncGenerator.prototype.return`.
AsyncGeneratorReturn didn't handle the exception thrown by Await. This
CL add an exception handler around it and pass through the caught
exception to the returned promise and resume the generator by
AsyncGeneratorAwaitResume if the generator is not closed, otherwise
reject the promise by AsyncGeneratorReject and drain the queue.
Bug: v8:12770
Change-Id: Ic3cac4ce36a6d8ecfeb5d7d762a37a2e0524831c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3581158
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#80066}
The fix is merged to all channels, add the regression test.
R=thibaudm@chromium.org
Bug: chromium:1314184
Change-Id: I7b7ca13ff34b19c3dbb727d248619dc1ff874873
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596161
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80044}
The roundss / vroundss instruction is only available on AVX or SSE4_1
hardware. Thus bring back the old code path with much longer code for
such old hardware.
R=tebbi@chromium.org
Bug: chromium:1314363
Change-Id: I79a58627c8b406817330e9f9601234cea28182c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578642
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79914}
Some test variants and fuzzers set their own GC interval, so the flag
specified in the regression test causes flag contradictions.
The test failure was flaky anyway, so this change is only a slight
reduction in reproducability, and the test will still be used as seed
for the fuzzers.
R=machenbach@chromium.org
Bug: chromium:1313475
Change-Id: I7c7084ab34fe46d691b841921d42a487cc8a1cad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576114
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79845}
