- 10 Feb, 2020 1 commit
-
-
Santiago Aboy Solanes authored
FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206}
-
- 11 Nov, 2019 1 commit
-
-
Jakob Gruber authored
The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64888}
-
- 05 Nov, 2019 1 commit
-
-
Joshua Litt authored
This reverts commit 10883f56. Reason for revert: Causes bytecode mismatch Bug:chromium:1020538, chromium:1021457 Original change's description: > [hole-check-elimination] Simplest possible hole check elimination > > doc: https://docs.google.com/document/d/1Y9uF3hS2aUrwKU56vGxlvEs_IiGgmWSzau8097Y-XBM/edit > > Bug: v8:7427 > Change-Id: Iedd36c146cefff7e6687fdad48d263889c5c8347 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1778902 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63913} TBR=rmcilroy@chromium.org,leszeks@chromium.org,verwaest@chromium.org,joshualitt@chromium.org Bug: v8:7427 Change-Id: Ib4369a3560e929692585c4546435684deae5ee9b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1899163 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#64789}
-
- 20 Sep, 2019 1 commit
-
-
Joshua Litt authored
doc: https://docs.google.com/document/d/1Y9uF3hS2aUrwKU56vGxlvEs_IiGgmWSzau8097Y-XBM/edit Bug: v8:7427 Change-Id: Iedd36c146cefff7e6687fdad48d263889c5c8347 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1778902 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63913}
-
- 25 Jan, 2019 1 commit
-
-
Mythri authored
SetProperty now infers the language mode from the closure and the context So we no longer have to pass around the language mode. Cleanup by removing the parameter where it is no longer needed. Bug: v8:8580 Change-Id: I89452b5a762eb48a911f158d22c7bfa9e3bb1be4 Reviewed-on: https://chromium-review.googlesource.com/c/1421840 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59089}
-
- 17 Apr, 2018 1 commit
-
-
Sathya Gunasekaran authored
Class fields needs to be initialized after `this` is bound, as per the new spec change: https://github.com/tc39/proposal-class-fields/pull/92 This CL moves the initialization of `this` from parser desugaring to the bytecode generator. Bug: v8:7647 Change-Id: I20f749403e5a4d2f06a39726cf39012ceb541987 Reviewed-on: https://chromium-review.googlesource.com/1014383Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#52646}
-
- 27 Nov, 2017 1 commit
-
-
Sathya Gunasekaran authored
Previously, the class fields initializer function was stored on a synthetic context allocated variable. This approach had sevaral problems: - We didn't know that class literal had fields until after we had completely parsed the class literal. This meant that we had to go back and fix up the scope of the constructor to have this synthetic variable. This resulted in mismatch between parser and preparsed scope data. - This synthetic variable could potentially resolve to an initializer of an outer class. For ex: class X extends Object { c = 1; constructor() { var t = () => { class P extends Object { constructor() { var t = () => { super(); }; t(); } } super(); } t(); } } In this the inner class P could access the outer class X's initiliazer function. We would have to maintain extra metadata to make sure this doesn't happen. Instead this new approach uses a private symbol to store the initializer function on the class constructor itself. For the base constructor case, we can simply check for a bit on the constructor function literal to see if we need to emit code that loads and calls this initializer function. Therefore, we don't pay the cost of loading this function in case there are no class fields. For the derived constructor case, there are two possiblities: (a) We are in a super() call directly in the derived constructor: In this case we can do a check similar to the base constructor check, we can check for a bit on the derived constructor and emit code for loading and calling the initializer function. This is usually the common case and we don't pay any cost for not using class fields. (b) We are in a super() call inside an arrow function in the derived constructor: In this case, we /always/ emit code to load and call the initializer function. If the function doesn't exist then we have undefined and we don't call anything. Otherwise we call the function. super() can't be called twice so even if we emit code to load and call the initializer function multiple times, it doesn't matter because it would have already been an error. Bug: v8:5367 Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88 Reviewed-on: https://chromium-review.googlesource.com/781660 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49628}
-
- 19 Oct, 2017 1 commit
-
-
Ross McIlroy authored
Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
-
- 05 Sep, 2017 1 commit
-
-
Jakob Kummerow authored
Only the error cases of overwriting readonly properties need the language_mode to decide whether to throw or be silent. Reading it from the feedback vector's metadata (just like the C++ code in ic.cc does) removes the need to duplicate each stub for each language_mode ("StoreIC" + "StoreICStrict" etc.). Change-Id: Ic0c67f9d40ca36c65e41b4f162b2ab70d155e549 Reviewed-on: https://chromium-review.googlesource.com/647373Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47836}
-
- 11 Aug, 2017 1 commit
-
-
Ross McIlroy authored
Removes the new.target slot from the interpreter's fixed frame. Instead adds a field to BytecodeArray to get the bytecode's incoming new.target or generator object register. The InterpreterEntryTrampoline then sets this register with the incoming new.target (or generator object) when the function is called. This register can be directly the new.target or generator object variable if they are LOCAL location, otherwise it is a temporary register which is then moved to the variable's location during the function prologue. This fixes a hack in the deoptimizer where we would set the new.target fixed slot to undefined in order to avoid extending it's lifetime through the optimized code - now it's just a standard register and can be optimized away as normal. Bug=v8:6644 Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae Reviewed-on: https://chromium-review.googlesource.com/608966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47320}
-
- 27 Jul, 2017 1 commit
-
-
Leszek Swirski authored
Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
-
- 25 Jul, 2017 1 commit
-
-
Leszek Swirski authored
Reland of https://chromium-review.googlesource.com/c/544888/. Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I7aa6baed03f726843d1b62629c72b74f05114b48 Reviewed-on: https://chromium-review.googlesource.com/579051 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46868}
-
- 18 Jul, 2017 1 commit
-
-
Ross McIlroy authored
BUG=v8:6609 Change-Id: If4c3520fba0653e23e6d34bf344fb00cdbfc6082 Reviewed-on: https://chromium-review.googlesource.com/575049Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46741}
-
- 17 Jul, 2017 1 commit
-
-
Leszek Swirski authored
This reverts commit a2fcdc7c. Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126) Original change's description: > [runtime] Move profiler ticks from SFI to feedback vector > > Instead of counting profiler ticks on the shared function info (which is > shared between native contexts), count them on the feedback vector > (which is not). This allows us to continue pushing optimization > decisions off the SFI, onto the feedback vector. > > Note that a side-effect of this is that ICs don't have to walk the stack > to reset profiler ticks, as they can access the feedback vector directly > from their feedback nexus. > > Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f > Reviewed-on: https://chromium-review.googlesource.com/544888 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46411} TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8 Reviewed-on: https://chromium-review.googlesource.com/574227 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46702}
-
- 14 Jul, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
-
- 05 Jul, 2017 1 commit
-
-
Leszek Swirski authored
Instead of counting profiler ticks on the shared function info (which is shared between native contexts), count them on the feedback vector (which is not). This allows us to continue pushing optimization decisions off the SFI, onto the feedback vector. Note that a side-effect of this is that ICs don't have to walk the stack to reset profiler ticks, as they can access the feedback vector directly from their feedback nexus. Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f Reviewed-on: https://chromium-review.googlesource.com/544888Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46411}
-
- 09 Jun, 2017 1 commit
-
-
Alexandre Talon authored
In some codes flushing the registers was costly: we processed each register whereas all the registers alone in their equivalence class need not to be processed. We now overapproximate easily which classes are of size 2 so as to save many iterations in the Flush() loop in some cases. Bug: v8:6432 Change-Id: I945e151736e8a515263ac76312127d930fd20d74 Reviewed-on: https://chromium-review.googlesource.com/525795 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#45805}
-
- 06 Jun, 2017 1 commit
-
-
Mythri authored
Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole / ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks. In the bytecode-graph builder they are handled by introducing a deopt point instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant bytecodes are removed since they are no longer required. Bug: v8:4280, v8:6383 Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1 Reviewed-on: https://chromium-review.googlesource.com/509613 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45720}
-
- 10 May, 2017 1 commit
-
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246,chromium:718891 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6 Reviewed-on: https://chromium-review.googlesource.com/500134Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45234}
-
- 08 May, 2017 1 commit
-
-
Ross McIlroy authored
This reverts commit 662aa425. Reason for revert: Crashing on Canary BUG=chromium:718891 Original change's description: > Reland: [TypeFeedbackVector] Store optimized code in the vector > > Since the feedback vector is itself a native context structure, why > not store optimized code for a function in there rather than in > a map from native context to code? This allows us to get rid of > the optimized code map in the SharedFunctionInfo, saving a pointer, > and making lookup of any optimized code quicker. > > Original patch by Michael Stanton <mvstanton@chromium.org> > > BUG=v8:6246 > TBR=yangguo@chromium.org,ulan@chromium.org > > Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327 > Reviewed-on: https://chromium-review.googlesource.com/494487 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45084} TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=v8:6246 Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82 Reviewed-on: https://chromium-review.googlesource.com/498633Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45174}
-
- 04 May, 2017 1 commit
-
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246 TBR=yangguo@chromium.org,ulan@chromium.org Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327 Reviewed-on: https://chromium-review.googlesource.com/494487Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45084}
-
- 02 May, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit c5ad9c6d. Reason for revert: Fails on gc stress: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/12661 Original change's description: > [TypeFeedbackVector] Store optimized code in the vector > > Since the feedback vector is itself a native context structure, why > not store optimized code for a function in there rather than in > a map from native context to code? This allows us to get rid of > the optimized code map in the SharedFunctionInfo, saving a pointer, > and making lookup of any optimized code quicker. > > Original patch by Michael Stanton <mvstanton@chromium.org> > > BUG=v8:6246 > > Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5 > Reviewed-on: https://chromium-review.googlesource.com/476891 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45022} TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,jarin@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6246 Change-Id: I9cd5735b03898cae6ae7adea0f19d32fceb31619 Reviewed-on: https://chromium-review.googlesource.com/493287Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#45027}
-
Ross McIlroy authored
Since the feedback vector is itself a native context structure, why not store optimized code for a function in there rather than in a map from native context to code? This allows us to get rid of the optimized code map in the SharedFunctionInfo, saving a pointer, and making lookup of any optimized code quicker. Original patch by Michael Stanton <mvstanton@chromium.org> BUG=v8:6246 Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5 Reviewed-on: https://chromium-review.googlesource.com/476891 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#45022}
-
- 11 Apr, 2017 2 commits
-
-
Leszek Swirski authored
Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
-
Michael Achenbach authored
This reverts commit 751e8935. Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original change's description: > [ignition] Add call bytecodes for undefined receiver > > Adds a collection of call bytecodes which have an implicit undefined > receiver argument, for cases such as global calls where we know that the > receiver has to be undefined. This way we can skip an LdaUndefined, > decrease bytecode register pressure, and set a more accurate > ConvertReceiverMode on the interpreter and TurboFan call. > > As a side effect, the "normal" Call bytecode now becomes a rare case > (only with calls and super property calls), so we get rid of its 0-2 > argument special cases and modify CallProperty[N] to use the > NotNullOrUndefined ConvertReceiverMode. > > Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc > Reviewed-on: https://chromium-review.googlesource.com/463287 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44530} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272 Reviewed-on: https://chromium-review.googlesource.com/474744 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44548}
-
- 10 Apr, 2017 2 commits
-
-
Leszek Swirski authored
Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc Reviewed-on: https://chromium-review.googlesource.com/463287 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44530}
-
Ross McIlroy authored
This relands commit d3e9aade. The original CL was reverted speculatively but didn't cause the buildbot failure. Original change's description: > [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator. > > Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi > literals in the BytecodeGenerator. This enables us to perform the > transformation for literals on either side for commutative operations, and > Avoids having to do the check on every bytecode in the peephole optimizer. > > In the process, adds Smi bytecode variants for all binary operations, adding > - MulSmi > - DivSmi > - ModSmi > - BitwiseXorSmi > - ShiftRightLogical > > BUG=v8:6194 > > Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219 > Reviewed-on: https://chromium-review.googlesource.com/466246 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44477} TBR=rmcilroy@chromium.org,machenbach@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,v8-reviews@googlegroups.com,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. BUG=v8:6194 Change-Id: I2ccaefa1ce58d3885f5c2648755985c06f25c1d8 Reviewed-on: https://chromium-review.googlesource.com/472746Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#44511}
-
- 07 Apr, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit d3e9aade. Reason for revert: Speculative for: https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/4449 Bisect points to this CL. Original change's description: > [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator. > > Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi > literals in the BytecodeGenerator. This enables us to perform the > transformation for literals on either side for commutative operations, and > Avoids having to do the check on every bytecode in the peephole optimizer. > > In the process, adds Smi bytecode variants for all binary operations, adding > - MulSmi > - DivSmi > - ModSmi > - BitwiseXorSmi > - ShiftRightLogical > > BUG=v8:6194 > > Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219 > Reviewed-on: https://chromium-review.googlesource.com/466246 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#44477} TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,ishell@chromium.org,v8-reviews@googlegroups.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6194 Change-Id: If57dbdbe40be77804bf437463b855d3167e2d473 Reviewed-on: https://chromium-review.googlesource.com/471308Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#44488}
-
Ross McIlroy authored
Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi literals in the BytecodeGenerator. This enables us to perform the transformation for literals on either side for commutative operations, and Avoids having to do the check on every bytecode in the peephole optimizer. In the process, adds Smi bytecode variants for all binary operations, adding - MulSmi - DivSmi - ModSmi - BitwiseXorSmi - ShiftRightLogical BUG=v8:6194 Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219 Reviewed-on: https://chromium-review.googlesource.com/466246 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#44477}
-
- 27 Mar, 2017 1 commit
-
-
Sathya Gunasekaran authored
Previously we threw a generic error meesage on failing hole check for accessing 'this'. But 'this' can be a hole only if the super() has not been called so we change the error message. BUG=v8:5957 Change-Id: I2f0e3d813f16919645d8a5efa7d26e73bd2d83fe Reviewed-on: https://chromium-review.googlesource.com/459085 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#44162}
-
- 09 Mar, 2017 1 commit
-
-
danno authored
Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1, and CallProperty2. Also share the bytecode handler code between between equivalent CallX and CallPropertyX handlers. Review-Url: https://codereview.chromium.org/2684993002 Cr-Original-Commit-Position: refs/heads/master@{#43290} Committed: https://chromium.googlesource.com/v8/v8/+/00d6f1f80a00c4ac398af588dbd6815395791015 Review-Url: https://codereview.chromium.org/2684993002 Cr-Commit-Position: refs/heads/master@{#43700}
-
- 20 Feb, 2017 1 commit
-
-
danno authored
Revert of [interpreter] Create custom call opcodes for specific argument counts (patchset #13 id:240001 of https://codereview.chromium.org/2684993002/ ) Reason for revert: Due to arm64 failures Original issue's description: > [interpreter] Create custom call opcodes for specific argument counts > > Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1, > and CallProperty2. Also share the bytecode handler code between between > equivalent CallX and CallPropertyX handlers. > > Review-Url: https://codereview.chromium.org/2684993002 > Cr-Commit-Position: refs/heads/master@{#43290} > Committed: https://chromium.googlesource.com/v8/v8/+/00d6f1f80a00c4ac398af588dbd6815395791015 TBR=rmcilroy@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. Review-Url: https://codereview.chromium.org/2709533002 Cr-Commit-Position: refs/heads/master@{#43308}
-
- 17 Feb, 2017 1 commit
-
-
danno authored
Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1, and CallProperty2. Also share the bytecode handler code between between equivalent CallX and CallPropertyX handlers. Review-Url: https://codereview.chromium.org/2684993002 Cr-Commit-Position: refs/heads/master@{#43290}
-
- 01 Feb, 2017 1 commit
-
-
petermarshall authored
Rename to Construct and ConstructWithSpread, to match the names of the JSOperators used. Unfortunately, I can't find a way for auto-formatting to stay happy unless we change the indentation for the whole BYTECODE_LIST macro. Review-Url: https://codereview.chromium.org/2663963003 Cr-Commit-Position: refs/heads/master@{#42840}
-
- 25 Jan, 2017 1 commit
-
-
leszeks authored
Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
-
- 06 Jan, 2017 1 commit
-
-
adamk authored
Previously the message was "this is not defined" which is nonsensical. BUG=v8:4407 Review-Url: https://codereview.chromium.org/2614053002 Cr-Commit-Position: refs/heads/master@{#42114}
-
- 19 Dec, 2016 1 commit
-
-
henrique.ferreiro authored
This is so that a NotSuperConstructor error is thrown before evaluating the arguments to the super constructor. Besides updating the runtime function, a new bytecode GetSuperConstructor is introduced. BUG=v8:5336 Review-Url: https://codereview.chromium.org/2504553003 Cr-Commit-Position: refs/heads/master@{#41788}
-
- 08 Dec, 2016 1 commit
-
-
rmcilroy authored
BUG=v8:5723 Review-Url: https://codereview.chromium.org/2555263002 Cr-Commit-Position: refs/heads/master@{#41583}
-
- 09 Nov, 2016 1 commit
-
-
rmcilroy authored
The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when inlining accessors in TurboFan. Remove them and replace with a Star lookahead in the bytecode handlers for Lda[Named/Keyed]Property. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2485383002 Cr-Commit-Position: refs/heads/master@{#40860}
-
- 18 Oct, 2016 1 commit
-
-
bmeurer authored
Consistently collect CallIC feedback in fullcodegen and Ignition, even for possibly direct eval calls, that were treated specially so far, for no apparent reason. With the upcoming SharedFunctionInfo based CallIC feedback, we might be able to even inline certain direct eval calls, if they manage to hit the eval cache. More importantly, this patch simplifies the collection and dealing with CallIC feedback (and as a side effect fixes an inconsistency with feedback for super constructor calls). R=mvstanton@chromium.org, mythria@chromium.org BUG=v8:2206,v8:4280,v8:5267 Review-Url: https://codereview.chromium.org/2426693002 Cr-Commit-Position: refs/heads/master@{#40397}
-