- 25 Nov, 2021 1 commit
-
-
Hao Xu authored
Some of the JumpIf Bytecode Handlers will load the jump offset from bytecode array or constant pool before checking whether the condition is matched, and this jump offset is unused if the jump not actually happens. This CL move the Load operations to the branch on which the condition is matched. Bug: v8:12431 Change-Id: I3cb2fa7447ee2a9cb514148efb605617f95b1b68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300994 Commit-Queue: Hao A Xu <hao.a.xu@intel.com> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78088}
-
- 30 Sep, 2021 1 commit
-
-
Marja Hölttä authored
It's confusing that we have CSA_CHECK and CSA_ASSERT and it's not clear from the names that the former works in release mode and the latter only in debug mode. Renaming CSA_ASSERT to CSA_DCHECK makes it clear what it does. So now we have CSA_CHECK and CSA_DCHECK and they're not confusing. This also renames assert() in Torque to dcheck(). Bug: v8:12244 Change-Id: I6f25d431ebc6eec7ebe326b6b8ad3a0ac5e9a108 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190104Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#77160}
-
- 07 Sep, 2021 1 commit
-
-
Patrick Thier authored
The receiver is now always included in the actual argument count and the formal parameter count. kDontAdaptArgumentsSentinel is changed from UINT16_MAX to 0 to preserve the maximum allowed declared parameters. The build flag activating the changes is not set for any architecture yet. Bug: v8:11112 Change-Id: I48a4969137949a1b4d1f47545209bb22b64e7e05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140608 Commit-Queue: Patrick Thier <pthier@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/main@{#76699}
-
- 06 Sep, 2021 1 commit
-
-
Leszek Swirski authored
Remove the BaselineData intermediate structure for baseline code, and write the baseline Code object into the SharedFunctionInfo directly. We still need a pointer to the BytecodeArray/InterpreterData, so re-use the Code object's deoptimization data slot for this (baseline code doesn't have deoptimization data). A consequence of this is that the BytecodeArray pointer becomes immutable when there is baseline code. This means that we cannot install a debug BytecodeArray while baseline code is active (we have to flush it first), and we can't tier-up code with debug BytecodeArray to baseline. Change-Id: I53b93ec4d4c64b833603d7992f246982fcd97596 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118548 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#76675}
-
- 16 Aug, 2021 1 commit
-
-
Yu Yin authored
Bug: v8:12008 Change-Id: I2e1d918a1370dae1e15919fbf02d69cbe48f63bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089095Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76308}
-
- 12 Aug, 2021 1 commit
-
-
Ross McIlroy authored
These are no longer enabled, so remove the code mitigation logic from the codebase. BUG=chromium:1003890 Change-Id: I536bb1732e8463281c21da446bbba8f47ede8ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045704 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#76256}
-
- 23 Jul, 2021 1 commit
-
-
Leszek Swirski authored
Change the folded interrupt check to be on JumpLoop only, to avoid calling it from Return. The call from Return could cause spurious stack overflows, which interacted poorly with async functions that had already resolved their promise. Now the bytecode budget interrupt function is split into two functions, one which does the stack check and one which doesn't. The former is still called from JumpLoop, the latter is called from Return. Bug: chromium:1231952, chromium:1232105 Change-Id: I8c4e2937f64b5f8fdbd6c1fcb2a76ec5f090ae3c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049076Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75891}
-
- 19 Jul, 2021 1 commit
-
-
Seth Brenith authored
I've noticed a few places where class fields as defined in Torque have different names than the corresponding accessors in the C++ class. I think they should match. Most of this change is just mechanically updating the various places that use k##Field##Offset for those fields. Change-Id: I8ba52aed7f6a1cd6b2d71158f71150b66c2c0da0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027263 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#75796}
-
- 07 Jun, 2021 2 commits
-
-
Camillo Bruni authored
- Add new Builtin enum - Move Builtins::Name:kXXX to Builtin::kXXX - Update existing code Follow CLs will unify the mix of using int builtin-ids and Builtins::Name to only use the new Builtin enum and changing it to an enum class. Change-Id: Ib39aa45a25696acdf147f46392901b1e051deaa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905592 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#74995}
-
Seth Brenith authored
The flag --trace-ignition-dispatches has been broken for a long time, since it was not designed to work with bytecode handlers that are generated ahead of time by mksnapshot. This splits the existing --trace-ignition-dispatches logic into two separate parts: 1. A gn argument which instructs mksnapshot to include dispatch counting in the bytecode handlers, and ensures that the Interpreter allocates the array of counters, and 2. A runtime flag which enables the ignition-statistics extension which implements the JS-accessible function getIgnitionDispatchCounters(). Change-Id: I89323425697f5641451f67b9ddcc0303b8ca209f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2937564Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#74992}
-
- 17 May, 2021 1 commit
-
-
Fanchen Kong authored
This CL makes a call to CollectCallFeedback from Ignition load the receiver lazily, which may improve the performance of Octane/{Richards, Delta-Blue} with --no-opt for 1-3%. Bug: chromium:1207349 Change-Id: I5fb09d5c5662ef8714acf71dd7341d3164b44f93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2895358Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Cr-Commit-Position: refs/heads/master@{#74580}
-
- 06 May, 2021 1 commit
-
-
Fanchen Kong authored
When a function is invoked by prototype.apply, it may undergo following transformation in the JSCallReducer: receiver.apply(this, args) -> this.receiver(...args) Since the new target (also the receiver of apply()) is not collected to the feedback slot, further speculative optimization on the new target is not available if the new target is not a heapconstant. With this CL, the receiver will be collected to the feedback instead of the target if the target is a prototype.apply. It may improve the performance of the following usecase by ~80%. function reduceArray(func, arr, r) { for (var i = 0, len = arr.length; i < len; i++) { r = func.apply(null, r, arr[i]); } return r; } var a = 0; for (var i = 0; i < 10000000; i++) { a += reduceArray(Math.imul, [5,6,2,3,7,6,8,3,7,9,2,5,], 1); } console.log(a); This CL also improves the runTime score of JetStream2/richards-wasm by ~45% in default, ~60% with --turbo-inline-js-wasm-calls. Change-Id: I542eb8d3fcb592f4e0993af93ba1af70e89c3982 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639813 Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74413}
-
- 29 Apr, 2021 1 commit
-
-
Benedikt Meurer authored
The "Restart frame" feature was implemented as part of LiveEdit and primarily used to support LiveEdit of active functions, but that was previously disabled as part of https://crrev.com/c/2846892 because it's too brittle and causes crashes when using seemingly unrelated features. The "Restart frame" feature was also available as a context menu item separately in the DevTools front-end, but that was also already removed as part of https://crrev.com/c/2854681 earlier. So all uses are gone now. This change works by marking Debugger.restartFrame as deprecated and having it respond with a ServerError all the time. It thus allows us to remove a whole bunch of machinery that was essentially just put in various places to support the restart_fp_ magic. In particular the debugger no longer needs any machine specific builtins now. Bug: chromium:1195927 Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484 Fixed: chromium:1203606 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#74276}
-
- 16 Apr, 2021 3 commits
-
-
Leszek Swirski authored
This is a reland of ae0752df Reland fixes: * Remove UNREACHABLE() from constexpr switch, since we don't have a CONSTEXPR_UNREACHABLE() (it's ok, the switch is exhaustive for the enum anyway). * Fix IsRegisterArray trait to use public inheritance and size_t for std::array size. Original change's description: > [codegen] Add static interface descriptors > > Add a new CRTP StaticCallInterfaceDescriptor class, which provides > static constexpr getters for a descriptor's registers, parameter counts, > and so on. Each CallInterfaceDescriptor subclass is changed to extend > StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself > extending CallInterfaceDescriptor to still provide a dynamic lookup > where needed. > > StaticCallInterfaceDescriptor provides a couple of customisation points, > where it reads its CRTP derived descriptor's static fields and > functions, with default fallbacks where appropriate. With these > customisation points, the definition of CallInterfaceDescriptor > subclasses is simplified to: > > a) Providing parameter names (as before) > b) Providing parameter types (as before) > c) Optionally setting flags (like kNoContext or kAllowVarArgs) as > static booleans on the class. > d) Optionally providing a `registers()` method that returns a > std::array<Register, N> of registers that may be used for > parameters (if not provided, this defaults to the implementation > specific default register set). > > Parameter registers (and register count) are automagically set based on > the number of parameters and number of given registers, with extra magic > to ignore no_reg registers (to reduce ia32 special casing). The > CallInterfaceDescriptorData is initialized based on these static > functions, rather than manual per-descriptor initializers. > > This allows us to skip loading descriptors dynamically for CallBuiltin > in Sparkplug, and instead lets us use a bit of template magic to > statically set up arguments for the calls. Any other users of statically > known descriptors will also benefit, thanks to C++ picking the static > methods over the dynamic methods on the base class when available. > > Because we can remove various virtual functions and trigger heavier > inlining of constantly known values, binary size slightly decreases with > this change. > > Note that torque-generated descriptors are changed to use the same magic, > rather than having Torque-specific magic, for consistency. > > Bug: v8:11420 > Change-Id: Icc5e238b6313a08734feb564204a13226b450c22 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518 > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73996} TBR=nicohartmann@chromium.org,clemensb@chromium.org,ishell@chromium.org,clemensb@chromium.org Bug: v8:11420 Change-Id: Icd1f6cdb3c178e74460044b1e9623139929ceba8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831872Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74010}
-
Leszek Swirski authored
This reverts commit ae0752df. Reason for revert: Predictably, constexpr issues on non-clang compilers. Original change's description: > [codegen] Add static interface descriptors > > Add a new CRTP StaticCallInterfaceDescriptor class, which provides > static constexpr getters for a descriptor's registers, parameter counts, > and so on. Each CallInterfaceDescriptor subclass is changed to extend > StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself > extending CallInterfaceDescriptor to still provide a dynamic lookup > where needed. > > StaticCallInterfaceDescriptor provides a couple of customisation points, > where it reads its CRTP derived descriptor's static fields and > functions, with default fallbacks where appropriate. With these > customisation points, the definition of CallInterfaceDescriptor > subclasses is simplified to: > > a) Providing parameter names (as before) > b) Providing parameter types (as before) > c) Optionally setting flags (like kNoContext or kAllowVarArgs) as > static booleans on the class. > d) Optionally providing a `registers()` method that returns a > std::array<Register, N> of registers that may be used for > parameters (if not provided, this defaults to the implementation > specific default register set). > > Parameter registers (and register count) are automagically set based on > the number of parameters and number of given registers, with extra magic > to ignore no_reg registers (to reduce ia32 special casing). The > CallInterfaceDescriptorData is initialized based on these static > functions, rather than manual per-descriptor initializers. > > This allows us to skip loading descriptors dynamically for CallBuiltin > in Sparkplug, and instead lets us use a bit of template magic to > statically set up arguments for the calls. Any other users of statically > known descriptors will also benefit, thanks to C++ picking the static > methods over the dynamic methods on the base class when available. > > Because we can remove various virtual functions and trigger heavier > inlining of constantly known values, binary size slightly decreases with > this change. > > Note that torque-generated descriptors are changed to use the same magic, > rather than having Torque-specific magic, for consistency. > > Bug: v8:11420 > Change-Id: Icc5e238b6313a08734feb564204a13226b450c22 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518 > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73996} Bug: v8:11420 Change-Id: Ie5469c9253fc140590ac30b72db6eb1d93f86806 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831485 Auto-Submit: Leszek Swirski <leszeks@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/master@{#74000}
-
Leszek Swirski authored
Add a new CRTP StaticCallInterfaceDescriptor class, which provides static constexpr getters for a descriptor's registers, parameter counts, and so on. Each CallInterfaceDescriptor subclass is changed to extend StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself extending CallInterfaceDescriptor to still provide a dynamic lookup where needed. StaticCallInterfaceDescriptor provides a couple of customisation points, where it reads its CRTP derived descriptor's static fields and functions, with default fallbacks where appropriate. With these customisation points, the definition of CallInterfaceDescriptor subclasses is simplified to: a) Providing parameter names (as before) b) Providing parameter types (as before) c) Optionally setting flags (like kNoContext or kAllowVarArgs) as static booleans on the class. d) Optionally providing a `registers()` method that returns a std::array<Register, N> of registers that may be used for parameters (if not provided, this defaults to the implementation specific default register set). Parameter registers (and register count) are automagically set based on the number of parameters and number of given registers, with extra magic to ignore no_reg registers (to reduce ia32 special casing). The CallInterfaceDescriptorData is initialized based on these static functions, rather than manual per-descriptor initializers. This allows us to skip loading descriptors dynamically for CallBuiltin in Sparkplug, and instead lets us use a bit of template magic to statically set up arguments for the calls. Any other users of statically known descriptors will also benefit, thanks to C++ picking the static methods over the dynamic methods on the base class when available. Because we can remove various virtual functions and trigger heavier inlining of constantly known values, binary size slightly decreases with this change. Note that torque-generated descriptors are changed to use the same magic, rather than having Torque-specific magic, for consistency. Bug: v8:11420 Change-Id: Icc5e238b6313a08734feb564204a13226b450c22 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73996}
-
- 06 Apr, 2021 1 commit
-
-
Patrick Thier authored
This is a reland of b9c521d0. Fixes crashes by calling kInstallBaselineCode from BaselineEntry if needed, i.e. when there is no feedback vector (required a bit of register rejiggling). This can happen with cross-realm calls. The OSR arming is stored as part of the BytecodeArray and therefore shared across realms. Original change's description: > [sparkplug] OSR Ignition -> Sparkplug > > Add support for OSR to baseline code. > We compile baseline and perform OSR immediately when the bytecode budget > interrupt hits. > > Drive-by: Clean-up deoptimizer special handling of JumpLoop by using > the newly introduced GetBaselinePCForNextExecutedBytecode instead of > GetBaselineEndPCForBytecodeOffset. > > Bug: v8:11420 > Change-Id: Ifbea264d4a83a127dd2a11e28626bf2a5e8aca59 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784687 > Commit-Queue: Patrick Thier <pthier@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73677} Bug: v8:11420 Change-Id: I67325450514ed5a1170b730b1dd59fa6acc6e1d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2800112Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#73803}
-
- 25 Mar, 2021 2 commits
-
-
Deepti Gandluri authored
This reverts commit 52393b90. Reason for revert: Reverting for TSAN fails - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20no-concurrent-marking/3061 Original change's description: > [sparkplug] OSR Ignition -> Sparkplug > > Add support for OSR to baseline code. > We compile baseline and perform OSR immediately when the bytecode budget > interrupt hits. > > Drive-by: Clean-up deoptimizer special handling of JumpLoop by using > the newly introduced GetBaselinePCForNextExecutedBytecode instead of > GetBaselineEndPCForBytecodeOffset. > > Bug: v8:11420 > Change-Id: Ifbea264d4a83a127dd2a11e28626bf2a5e8aca59 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784687 > Commit-Queue: Patrick Thier <pthier@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73677} Bug: v8:11420 Change-Id: I335640216dbbf9a854fc276f3df95bf5a1f9956a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2787192Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#73680}
-
Patrick Thier authored
Add support for OSR to baseline code. We compile baseline and perform OSR immediately when the bytecode budget interrupt hits. Drive-by: Clean-up deoptimizer special handling of JumpLoop by using the newly introduced GetBaselinePCForNextExecutedBytecode instead of GetBaselineEndPCForBytecodeOffset. Bug: v8:11420 Change-Id: Ifbea264d4a83a127dd2a11e28626bf2a5e8aca59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784687 Commit-Queue: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73677}
-
- 17 Feb, 2021 2 commits
-
-
Seth Brenith authored
This is a reland of cf93071c 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} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
-
Victor Gomes authored
Change-Id: Icdd2d4a178415d240a82378ffa575e6e6b79dca1 Bug: v8:11429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697353Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72805}
-
- 16 Feb, 2021 4 commits
-
-
Leszek Swirski authored
This reverts commit cf93071c. 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/+/2697350Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72777}
-
Seth Brenith authored
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/+/2641180Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72773}
-
Victor Gomes authored
Change-Id: I9f41fc97c2ca9a1c62b1de4ee8c9878d5d69b560 Bug: v8:11429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697195Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72772}
-
Leszek Swirski authored
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}
-
- 12 Feb, 2021 1 commit
-
-
Leszek Swirski authored
Sparkplug is a new baseline, non-optimising second-tier compiler, designed to fit in the compiler trade-off space between Ignition and TurboProp/TurboFan. Design doc: https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing Bug: v8:11420 Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72686}
-
- 11 Feb, 2021 1 commit
-
-
Seth Brenith authored
In https://chromium-review.googlesource.com/c/v8/v8/+/2641180 , we are discussing renaming AccumulatorUse. To avoid polluting that change with a large mechanical find&replace, I've created a separate change for the renaming. Change-Id: Ibc7e438f9e719571c9237e7e08ba86562a3c679f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2684923Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72679}
-
- 09 Feb, 2021 1 commit
-
-
Brice Dobry authored
This very large changeset adds support for RISC-V. Bug: v8:10991 Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344 Commit-Queue: Brice Dobry <brice.dobry@futurewei.com> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#72598}
-
- 19 Jan, 2021 1 commit
-
-
Sathya Gunasekaran authored
This will allow us optimize the protector cell checks in the fast path from checking against the function object in every context to just doing a range check against the instance type. This patch adds new instance types for constructor functions that require such protector cell checks. Bug: v8:11256 Change-Id: Iea722f9c6326dfa470149dd02e689a23942097f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595442Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#72146}
-
- 09 Nov, 2020 1 commit
-
-
Ross McIlroy authored
Moves CallStubR to be private and drop the return_count argument from CallStub and its callchain, and instead use the GetReturnCount on the call descriptor. Also removes unused Retain function from code-assembler. BUG=v8:6949,v8:11074 Change-Id: Ic0ebc72f84c2eab156c545af56237d4c46548c05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2523324 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71038}
-
- 14 Oct, 2020 1 commit
-
-
Victor Gomes authored
Change-Id: I2f262f4545de9e421310094d0dfab2f6147869b5 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2466116Reviewed-by: Junliang Yan <junyan@redhat.com> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70502}
-
- 01 Oct, 2020 1 commit
-
-
Dan Elphick authored
CodeAssembler::Parameter now takes a Type template parameter and performs a checked cast to it. There is also UncheckedParameter which returns a TNode but doesn't check the cast. The original Parameter method is still there as UntypedParameter. Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the cast is performed inside Parameter. Since Parameter is not a macro, this means it cannot see the original expression or its file name and line number. So the error messages are vaguely useful, Parameter<T>() takes a SourceLocation parameter which with a default value of SourceLocation::Current(), which at least gives us the file name and line number for the error message. Bug: v8:6949, v8:10933 Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: Bill Budge <bbudge@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#70264}
-
- 29 Jul, 2020 1 commit
-
-
Jakob Gruber authored
This is the first step towards implementing a tier-up mechanism from NCI code to TF. We will follow the existing Ignition-to-Turbofan mechanics, which are, roughly: 1. Track a bytecode interrupt budget. 2. When exhausted, call the runtime profiler, which increments profiler ticks for the top frame's function. 3. When a function should tier up, it is marked as such using the FeedbackVector::optimized_code_weak_or_smi slot / the OptimizationMarker mechanism. 4. The InterpreterEntryTrampoline checks this slot and calls into runtime to compile if needed. 5. The finished code is also placed into this slot, as well as installed on the JSFunction. 6. Again, the IET checks the slot and tail-calls the code object if it exists. This CL implements step 1 for NCI code by inserting the new simplified UpdateInterruptBudget operator at the same spots (and using the same offsets) as Ignition. When the budget is exhausted, we call a runtime function that currently does nothing and will be implemented in the next CL. Bug: v8:8888 Change-Id: I98c0f8d96f32d515218dc2a76f961d44fe281c86 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312778 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#69124}
-
- 27 May, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Also remove a version that was only used once. Bug: v8:9708, v8:6949 Change-Id: Ifd65af3866a3740d8da6d4501445b25a48d7219a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212264Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68006}
-
- 12 May, 2020 1 commit
-
-
Jakob Gruber authored
Previously implemented directly in InterpreterAssembler::Construct, this will soon also be needed to implement a Construct_WithFeedback builtin. Bug: v8:8888 Change-Id: I01a00914c6554a5b83f414a93d85a15ec02df662 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193717 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67753}
-
- 31 Mar, 2020 1 commit
-
-
Junliang Yan authored
Drive-by: Fix a few BE related issue with ptr-compr enabled. Change-Id: Ic2ff9e69a42e65089a1c1544e5eba1833c2fd95e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2057355Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66926}
-
- 04 Mar, 2020 1 commit
-
-
Igor Sheludko authored
This CL simplifies IC code since we no longer need to keep feedback slot indices in both Smi and IntPtr form and as a result it should improve overall performance of --no-opt mode on Octane by ~1%. Bug: v8:10047 Change-Id: Ib717697cdb805c9f93286e9c62ee8a63361d3560 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1965586 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66585}
-
- 03 Mar, 2020 1 commit
-
-
Victor Gomes authored
Bug: v8:10201 Change-Id: Ia7e964df89ac134c01a3fd94ce4b15f1afd0cbff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083295Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66560}
-
- 21 Feb, 2020 1 commit
-
-
Wouter Vermeiren authored
After support for ARCH_PPC was dropped, it became a subset of ARCH_PPC64. If you compile for ppc64, then you set the ARCH_PPC64 define which also sets the ARCH_PPC define. To be able to again support ppc (32 bit) those defines should be split up again. This commit only splits up the defines but does not introduce a working ARCH_PPC variant. Bug: v8:10102 Change-Id: I64e0749f8e5a7dc078ee7890d92e57b82706a849 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989826 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66390}
-
- 17 Feb, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Bug: v8:6949, v8:10155 Change-Id: I0113efe2d4d3a462533c306a87ebee851b1cb85c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056853Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66286}
-