- 22 Jun, 2018 1 commit
-
-
Igor Sheludko authored
Bug: v8:5269, v8:7754 Change-Id: I5cde20c269b60145b20e9cfbbd94bcaf3fac6feb Reviewed-on: https://chromium-review.googlesource.com/1110132Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#53960}
-
- 21 Jun, 2018 2 commits
-
-
Igor Sheludko authored
Bug: v8:7754 Change-Id: I5de3f1fb1c1c44312238c05f53257ca75136d093 Reviewed-on: https://chromium-review.googlesource.com/1109690 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53912}
-
Igor Sheludko authored
Bug: v8:7754, v8:6600 Change-Id: I4db943d4a4a02a14bba670f89661ea98c5e306dd Reviewed-on: https://chromium-review.googlesource.com/1107919 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53907}
-
- 18 Jun, 2018 1 commit
-
-
Igor Sheludko authored
This CL also adds macros for defining JS-compatible interface descriptors that has additional parameters. ArrayConstructorDescriptor is redefined using the new macros. Bug: v8:7754 Change-Id: Id39cac9f234666576f35de755d11aba198248bea Reviewed-on: https://chromium-review.googlesource.com/1100833 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53796}
-
- 12 Jun, 2018 1 commit
-
-
Igor Sheludko authored
This is a necessary cleanup before porting Array[No,Single,N]ArgumentsConstructor builtins to CSA. Bug: v8:5269, v8:7703 Change-Id: I40a2dd83faab1f8c3c180d461ef62fa4d8578f5e Reviewed-on: https://chromium-review.googlesource.com/1097079 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53671}
-
- 07 Jun, 2018 1 commit
-
-
Igor Sheludko authored
This CL introduces CSA::TailCallJSCode() for tail calling code objects with JSCall linkage. Bug: v8:5269, v8:7703 Change-Id: I97370dc4355dc658a9cd62166efcbe7f03d6daca Reviewed-on: https://chromium-review.googlesource.com/1087459 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53590}
-
- 30 May, 2018 1 commit
-
-
Pierre Langlois authored
The MathPowInternal builtin is now only called directly from the code-generator. Also, this patch takes the opportunity to cleanup the builtin for arm and arm64 a little. Change-Id: If53edcecd42b227ef74ee817bc5d7fbbcea8b0e2 Reviewed-on: https://chromium-review.googlesource.com/1076127Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#53442}
-
- 28 May, 2018 1 commit
-
-
Junliang Yan authored
Port a55d8632 Original Commit Message: Its contents are now inlined into the one remaining call site. R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: If0ba82784c0b9b095301e88141e1ff5b1fd507be Reviewed-on: https://chromium-review.googlesource.com/1075607Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#53393}
-
- 08 May, 2018 1 commit
-
-
Junliang Yan authored
Port d8131cd6 Original Commit Message: Stubs and builtins are very similar. The main differences are that stubs can be parameterized and may be generated at runtime, whereas builtins are generated at mksnapshot-time and shipped with the snapshot (or embedded into the binary). My main motivation for these conversions is that we can generate faster calls and jumps to (embedded) builtins callees from (embedded) builtin callers. Instead of going through the builtins constants table indirection, we can simply do a pc-relative call/jump. This also unlocks other refactorings, e.g. removal of CallRuntimeDelayed. R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I193e4275470d492912a7d0f8523c3b8c29f1b146 Reviewed-on: https://chromium-review.googlesource.com/1050732 Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#53081}
-
- 03 May, 2018 1 commit
-
-
Toon Verwaest authored
There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
-
- 22 Feb, 2018 1 commit
-
-
Benedikt Meurer authored
This is preparatory cleanup work for eventually tracking the functions (rather than concrete closures) in the CALL_IC, also for builtins like the default PromiseCapability [[Resolve]] and [[Reject]] functions. It adds a new FeedbackCell type, which is used by JSFunctions consistently now to reference the feedback vector (or undefined if not the function is not compiled yet or is a native/asm.js function). This also changes the calling convention for FastNewClosure builtin and the JSCreateClosure operator in TurboFan to carry the FeedbackCell here instead of the parent FeedbackVector and the slot index. In addition we eliminate the now unused %InterpreterNewClosure runtime function. Bug: v8:2206, v8:7253, v8:7310 Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656 Reviewed-on: https://chromium-review.googlesource.com/928403 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#51474}
-
- 13 Feb, 2018 1 commit
-
-
Junliang Yan authored
Port a021b6c4 Original Commit Message: Moves generation of speculation poison to be based on the PC target vs the actual PC being executed. The speculation poison is generated in the prologue of the generated code if CompilationInfo::kGenerateSpeculationPoison is set. The result is stored in a known register, which can then be read using the SpeculationPoison machine node. Currently we need to ensure the SpeculationPoison node is scheduled right after the code prologue so that the poison register doesn't get clobbered. This is currently not verified, however it's only use is in RawMachineAssembler where it is manually scheduled early. The Ignition bytecode handlers are updated to use this speculation poison rather than one generated by comparing the target bytecode. R=rmcilroy@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:798964 LOG=N Change-Id: I4b9a1b0865b6164171cf83f0e45c36c69ac08a18 Reviewed-on: https://chromium-review.googlesource.com/914848Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#51273}
-
- 31 Jan, 2018 1 commit
-
-
Junliang Yan authored
Port c9941af2 R=rmcilroy@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:798964 LOG=N Change-Id: Id1f6a45169a24f06605297a404461a6cbdf78347 Reviewed-on: https://chromium-review.googlesource.com/894305Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#51007}
-
- 21 Dec, 2017 1 commit
-
-
Stephan Herhut authored
Bug: Change-Id: I785dd2fb839f8388e7389f4fe935cb983f6e81eb Reviewed-on: https://chromium-review.googlesource.com/803435Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Stephan Herhut <herhut@google.com> Cr-Commit-Position: refs/heads/master@{#50264}
-
- 14 Dec, 2017 1 commit
-
-
Igor Sheludko authored
This CL also removes LoadICProtoArray* builtins which are no longer necessary. Bug: v8:7206, v8:5561 Change-Id: Ic5d9a3d4d21c4bd5e5e1cd110bd029ced157a000 Reviewed-on: https://chromium-review.googlesource.com/819252 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#50104}
-
- 22 Nov, 2017 1 commit
-
-
Junliang Yan authored
Port a087abb0 Original Commit Message: There's not really a point in passing the resume_mode as parameter to the ResumeGenerator builtin. Instead we could as well just store the mode to the generator object directly. immediately so we don't need to move it there later. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jbarboza@ca.ibm.com BUG= LOG=N Change-Id: I85d064dad444443fa7ba9d6801e32e4048676ceb Reviewed-on: https://chromium-review.googlesource.com/783792Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#49588}
-
- 30 Oct, 2017 1 commit
-
-
Toon Verwaest authored
Remove distinction between lazy and non-lazy CallApiCallback, always explicitly set up target context Bug: Change-Id: I0cb751a0415433fdfec21451e2fac3e0726bf26e Reviewed-on: https://chromium-review.googlesource.com/743019 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49024}
-
- 25 Oct, 2017 1 commit
-
-
Jakob Kummerow authored
and use a newly-introduced "enum class Operation" in all other places that so far passed Token::Values around. Also delete some related dead code along the way. Bug: v8:6921 Change-Id: I062f396d304aa62298cfeff202e3132a4a5597c1 Reviewed-on: https://chromium-review.googlesource.com/736851 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48944}
-
- 13 Oct, 2017 1 commit
-
-
Mathias Bynens authored
New code should use nullptr instead of NULL. This patch updates existing use of NULL to nullptr where applicable, making the code base more consistent. BUG=v8:6928,v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c Reviewed-on: https://chromium-review.googlesource.com/718338 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48557}
-
- 25 Sep, 2017 1 commit
-
-
Benedikt Meurer authored
When inlining based on SharedFunctionInfo rather than based on concrete JSFunction, we weren't able to properly optimize array, object and regexp literals inside the inlinee, because we didn't know the concrete FeedbackVector for the inlinee inside JSCreateLowering. This was because JSCreateLowering wasn't properly updated after the literals moved to the FeedbackVector. Now with this CL we also have the VectorSlotPair on the literal creation operators, just like we do for property accesses and calls, and are thus able to always access the appropriate FeedbackVector and optimize the literal creation. The impact is illustrated by the micro-benchmark on the tracking bug, which goes from createEmptyArrayLiteral: 1846 ms. createShallowArrayLiteral: 1868 ms. createShallowObjectLiteral: 2246 ms. to createEmptyArrayLiteral: 1175 ms. createShallowArrayLiteral: 1187 ms. createShallowObjectLiteral: 1195 ms. with this CL, so up to 2x faster now. Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin and cleanup the names of the other builtins to be consistent with the names of the TurboFan operators and Ignition bytecodes. Bug: v8:6856 Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097 Reviewed-on: https://chromium-review.googlesource.com/680656 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48140}
-
- 06 Sep, 2017 1 commit
-
-
Anisha Rohra authored
Port 30f08f39 Always return to the InterpreterEntryTrampoline rather than calling the InterpreterExitTrampoline from the Return bytecode handler. This fixes a regression which occured if we upset the call/return stack by skipping the return to the InterpreterEntryTrampoline from the return bytecode handler. R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Id2bae444e72cd7ddfb74f4861fc2c4f7b5e9bda5 Reviewed-on: https://chromium-review.googlesource.com/653618Reviewed-by: Jaideep Bajwa <bjaideep@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47858}
-
- 01 Sep, 2017 1 commit
-
-
Albert Mingkun Yang authored
Saving/restoring only registers in the restricted set before calling RecordWrite code stub, which prepares for turning on `v8_enable_csa_write_barrier` on all architectures. Bug: chromium:749486 Change-Id: I6c8ba0c1561513569218e80011673cf24c7d6127 Reviewed-on: https://chromium-review.googlesource.com/641531Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com> Cr-Commit-Position: refs/heads/master@{#47770}
-
- 29 Aug, 2017 1 commit
-
-
Jaideep Bajwa authored
Port 51a15140 Original Commit Message: This change adapts the Call bytecode handlers such that they don't require a stack frame. It does this by modifying the call bytecode handler to tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the callee function will return to the InterpreterEntryTrampoline when it returns (since this is the return address on the interpreter frame), which is adapted to dispatch to the next bytecode handler. The return bytecode handler is modified to tail-call a new InterpreterExitTramoline instead of returning to the InterpreterEntryTrampoline. Overall this significanlty reduces the amount of stack space required for interpreter frames, increasing the maximum depth of recursive calls from around 6000 to around 12,500 on x64. R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:753705 LOG=N Change-Id: Ieac490d82098c13741080061eda762d54baf8c04 Reviewed-on: https://chromium-review.googlesource.com/639315Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47694}
-
- 24 Aug, 2017 1 commit
-
-
Albert Mingkun Yang authored
This is useful for the RecordWrite stub that can now specify the set of allocatable registers in its call descriptor interface. During register allocation a custom register configuration is used to ensure that the register are allocated from the given set. This makes calling RecordWrite stub less expensive as we need to save/restore only the allocatable registers instead all registers. Bug: chromium:749486 Change-Id: If4d73f1fd525e480970ea92600fb811e63677eb5 Reviewed-on: https://chromium-review.googlesource.com/624734Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com> Cr-Commit-Position: refs/heads/master@{#47577}
-
- 15 Aug, 2017 1 commit
-
-
Martyn Capewell authored
No longer needed. Bug: v8:6409 Change-Id: Iea0afcb7ced24d10223db5e01f66813e97fc4134 Reviewed-on: https://chromium-review.googlesource.com/613761 Commit-Queue: Martyn Capewell <martyn.capewell@arm.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47357}
-
- 08 Aug, 2017 1 commit
-
-
Anisha Rohra authored
Port ee350c31 R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com BUG= LOG=N Change-Id: I2dfc7562fc327a4d8577c405d5fec8c440ef0a49 Reviewed-on: https://chromium-review.googlesource.com/606707Reviewed-by: Jaideep Bajwa <bjaideep@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#47230}
-
- 07 Aug, 2017 3 commits
-
-
Benedikt Meurer authored
Drop the deprecated CallConstructStub and remove the use of CallICStub from fullcodegen, since that feedback is unused completely every since Crankshaft got removed, thus we can safely unlink all the CallIC stuff from fullcodegen nowadays, and completely nuke the CallICStub and the CallICTrampolineStub now (we can also transitively nuke the unused CreateAllocationSiteStub and CreateWeakCellStub). Instead the CallIC logic is integrated into Ignition now, and part of the bytecode handlers for [[Call]] and [[Construct]]. There's still some follow-up cleanup with the way the Array constructor feedback is integrated, but that's way easier now. Bug: v8:5517, v8:6399, v8:6409, v8:6679 Change-Id: I0a6c6046faceca9b1606577bc9e63d9295e44619 Reviewed-on: https://chromium-review.googlesource.com/603609 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47196}
-
Michael Achenbach authored
This reverts commit 6c541561. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/17240 Original change's description: > [ic] Properly integrate the CallIC into Ignition. > > Drop the deprecated CallConstructStub and remove the use of CallICStub > from fullcodegen, since that feedback is unused completely every since > Crankshaft got removed, thus we can safely unlink all the CallIC stuff > from fullcodegen nowadays, and completely nuke the CallICStub and the > CallICTrampolineStub now (we can also transitively nuke the unused > CreateAllocationSiteStub and CreateWeakCellStub). > > Instead the CallIC logic is integrated into Ignition now, and part of > the bytecode handlers for [[Call]] and [[Construct]]. There's still some > follow-up cleanup with the way the Array constructor feedback is > integrated, but that's way easier now. > > Bug: v8:5517, v8:6399, v8:6409, v8:6679 > Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835 > Reviewed-on: https://chromium-review.googlesource.com/602134 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47192} TBR=rmcilroy@chromium.org,yangguo@chromium.org,bmeurer@chromium.org Change-Id: I416ce6646f62ceb4127b3acee43912ee0d701c23 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5517, v8:6399, v8:6409, v8:6679 Reviewed-on: https://chromium-review.googlesource.com/603647Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47193}
-
Benedikt Meurer authored
Drop the deprecated CallConstructStub and remove the use of CallICStub from fullcodegen, since that feedback is unused completely every since Crankshaft got removed, thus we can safely unlink all the CallIC stuff from fullcodegen nowadays, and completely nuke the CallICStub and the CallICTrampolineStub now (we can also transitively nuke the unused CreateAllocationSiteStub and CreateWeakCellStub). Instead the CallIC logic is integrated into Ignition now, and part of the bytecode handlers for [[Call]] and [[Construct]]. There's still some follow-up cleanup with the way the Array constructor feedback is integrated, but that's way easier now. Bug: v8:5517, v8:6399, v8:6409, v8:6679 Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835 Reviewed-on: https://chromium-review.googlesource.com/602134 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47192}
-
- 26 Jul, 2017 1 commit
-
-
Jaideep Bajwa authored
Port fe046627 Port d594a6d9 Port 53553f5d R=mslekova@google.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2c160f8e3a1c3a809de6a6631864104ed95900d7 Reviewed-on: https://chromium-review.googlesource.com/587610Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#46914}
-
- 19 Jul, 2017 1 commit
-
-
Ross McIlroy authored
There remained a few of regressions and we didn't see any significant improvement in the real world with this turned on. This CL reverts all the StringConcat bytecode work which landed. BUG=v8:6243 Change-Id: I832eb72e880ad41411dbec8fe29f71ef0f2025c8 Reviewed-on: https://chromium-review.googlesource.com/575130 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46769}
-
- 23 Jun, 2017 1 commit
-
-
Jaideep Bajwa authored
Port a971a64d Original Commit Message: We can remove a lot of native code and rely on CallOrConstructVarargs to do the stack manipulation for us. This will also take advantage of the fast-path for double arrays in CallOrConstructDoubleVarargs. We can also remove Runtime_SpreadIterableFixed because it isn't used anymore. We just call directly into spread_iterable from CSA. R=petermarshall@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Idad830c9aace4151db866c9f863158cd7525e881 Reviewed-on: https://chromium-review.googlesource.com/546575Reviewed-by: Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#46187}
-
- 09 Jun, 2017 1 commit
-
-
bjaideep authored
Port af76779a Original Commit Message: This splits the monolithic Apply builtin into several smaller builtins, namely CallVargargs and ConstructVarargs, which accept a length and a FixedArray of elements and deal with the actual stack manipulation, and CallWithArrayLike / ConstructWithArrayLike that deal with getting the elements from the receiver (for Function.prototype.apply, Reflect.apply and Reflect.construct), which can now be written using the CSA. The idea is that these builtins can be reused by TurboFan directly in the future when we optimize apply better, and that we can also reuse the core logic in the handling of spread calls/constructs. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:4587,v8:5269 LOG=N Review-Url: https://codereview.chromium.org/2932833002 Cr-Commit-Position: refs/heads/master@{#45826}
-
- 07 Jun, 2017 1 commit
-
-
Ross McIlroy authored
Adds support for lowering of ToPrimitiveToString and StringConcat bytecodes to the corresponding builtins. As part of this, moves the interpreter implementation of these operations into the appropriate builtin generators and add builtin support for them. Also adds TailCallRuntimeN operator to code-assembler which enables tail calling a runtime function when the arguments have already been pushed onto the stack. BUG=v8:6243 Change-Id: Id5c851bc42e4ff490d9a23a8990ae331c7eac73e Reviewed-on: https://chromium-review.googlesource.com/515362 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45756}
-
- 18 May, 2017 1 commit
-
-
bjaideep authored
Port bfa319e5 Original Commit Message: We already had an optimization to turn Function.prototype.apply with arguments object, i.e. function foo() { return bar.apply(this, arguments); } into a special operator JSCallForwardVarargs, which avoids the allocation and deconstruction of the arguments object, but just passes along the incoming parameters. We can do the same for rest parameters and spread calls/constructs, i.e. class A extends B { constructor(...args) { super(...args); } } or function foo(...args) { return bar(1, 2, 3, ...args); } where we basically pass along the parameters (plus maybe additional statically known parameters). For this, we introduce a new JSConstructForwardVarargs operator and generalize the CallForwardVarargs builtins that are backing this. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:6407,v8:6278,v8:6344 LOG=N Review-Url: https://codereview.chromium.org/2887153004 Cr-Commit-Position: refs/heads/master@{#45402}
-
- 21 Apr, 2017 5 commits
-
-
jgruber authored
If we avoid throwing a stack overflow exception from Irregexp code during direct calls, there is no need to construct exit frames before the Irregexp call anymore. As that was the last remaining blocker, we can now implement the entire stub in CSA. BUG=v8:5339 Review-Url: https://codereview.chromium.org/2752143003 Cr-Original-Original-Commit-Position: refs/heads/master@{#44770} Committed: https://chromium.googlesource.com/v8/v8/+/74f2497eae068f85da26904d8c451376c77957bf Review-Url: https://codereview.chromium.org/2752143003 Cr-Original-Commit-Position: refs/heads/master@{#44775} Committed: https://chromium.googlesource.com/v8/v8/+/9c0832eb1aceba625a2443a31d51bcaf550c575a Review-Url: https://codereview.chromium.org/2752143003 Cr-Commit-Position: refs/heads/master@{#44779}
-
jgruber authored
Revert of [regexp] Remove remainder of native RegExpExecStub (patchset #10 id:180001 of https://codereview.chromium.org/2752143003/ ) Reason for revert: More failures on ports: https://build.chromium.org/p/client.v8.ports/builders/V8%20Android%20Arm64%20-%20builder/builds/9123/steps/compile/logs/stdio https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/8966/steps/compile/logs/stdio Original issue's description: > [regexp] Remove remainder of native RegExpExecStub > > If we avoid throwing a stack overflow exception from Irregexp code during > direct calls, there is no need to construct exit frames before the Irregexp > call anymore. As that was the last remaining blocker, we can now implement the > entire stub in CSA. > > BUG=v8:5339 > > Review-Url: https://codereview.chromium.org/2752143003 > Cr-Original-Commit-Position: refs/heads/master@{#44770} > Committed: https://chromium.googlesource.com/v8/v8/+/74f2497eae068f85da26904d8c451376c77957bf > Review-Url: https://codereview.chromium.org/2752143003 > Cr-Commit-Position: refs/heads/master@{#44775} > Committed: https://chromium.googlesource.com/v8/v8/+/9c0832eb1aceba625a2443a31d51bcaf550c575a TBR=ishell@chromium.org,mstarzinger@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5339 Review-Url: https://codereview.chromium.org/2832193002 Cr-Commit-Position: refs/heads/master@{#44776}
-
jgruber authored
If we avoid throwing a stack overflow exception from Irregexp code during direct calls, there is no need to construct exit frames before the Irregexp call anymore. As that was the last remaining blocker, we can now implement the entire stub in CSA. BUG=v8:5339 Review-Url: https://codereview.chromium.org/2752143003 Cr-Original-Commit-Position: refs/heads/master@{#44770} Committed: https://chromium.googlesource.com/v8/v8/+/74f2497eae068f85da26904d8c451376c77957bf Review-Url: https://codereview.chromium.org/2752143003 Cr-Commit-Position: refs/heads/master@{#44775}
-
machenbach authored
Revert of [regexp] Remove remainder of native RegExpExecStub (patchset #8 id:140001 of https://codereview.chromium.org/2752143003/ ) Reason for revert: https://build.chromium.org/p/client.v8.ports/builders/V8%20Android%20Arm64%20-%20builder/builds/9118 Original issue's description: > [regexp] Remove remainder of native RegExpExecStub > > If we avoid throwing a stack overflow exception from Irregexp code during > direct calls, there is no need to construct exit frames before the Irregexp > call anymore. As that was the last remaining blocker, we can now implement the > entire stub in CSA. > > BUG=v8:5339 > > Review-Url: https://codereview.chromium.org/2752143003 > Cr-Commit-Position: refs/heads/master@{#44770} > Committed: https://chromium.googlesource.com/v8/v8/+/74f2497eae068f85da26904d8c451376c77957bf TBR=ishell@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5339 Review-Url: https://codereview.chromium.org/2833083002 Cr-Commit-Position: refs/heads/master@{#44771}
-
jgruber authored
If we avoid throwing a stack overflow exception from Irregexp code during direct calls, there is no need to construct exit frames before the Irregexp call anymore. As that was the last remaining blocker, we can now implement the entire stub in CSA. BUG=v8:5339 Review-Url: https://codereview.chromium.org/2752143003 Cr-Commit-Position: refs/heads/master@{#44770}
-