1. 10 Feb, 2020 1 commit
  2. 11 Nov, 2019 1 commit
    • Jakob Gruber's avatar
      [interpreter] Move function-entry stack check to start of bytecode array · cebfde67
      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: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64888}
      cebfde67
  3. 05 Nov, 2019 1 commit
  4. 20 Sep, 2019 1 commit
  5. 25 Jan, 2019 1 commit
  6. 17 Apr, 2018 1 commit
  7. 27 Nov, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [class] Store class fields initializer on the constructor · 4ca9d843
      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: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49628}
      4ca9d843
  8. 19 Oct, 2017 1 commit
  9. 05 Sep, 2017 1 commit
  10. 11 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      [Interpreter] Remove new.target from fixed frame slot. · c820b89b
      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: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47320}
      c820b89b
  11. 27 Jul, 2017 1 commit
  12. 25 Jul, 2017 1 commit
  13. 18 Jul, 2017 1 commit
  14. 17 Jul, 2017 1 commit
    • Leszek Swirski's avatar
      Revert "[runtime] Move profiler ticks from SFI to feedback vector" · 14c5c4fd
      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: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46702}
      14c5c4fd
  15. 14 Jul, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] improve return position of explicit return in non-async function · 08965860
      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: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46687}
      08965860
  16. 05 Jul, 2017 1 commit
  17. 09 Jun, 2017 1 commit
  18. 06 Jun, 2017 1 commit
  19. 10 May, 2017 1 commit
  20. 08 May, 2017 1 commit
    • Ross McIlroy's avatar
      Revert "Reland: [TypeFeedbackVector] Store optimized code in the vector" · fd749344
      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: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45174}
      fd749344
  21. 04 May, 2017 1 commit
    • Ross McIlroy's avatar
      Reland: [TypeFeedbackVector] Store optimized code in the vector · 662aa425
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45084}
      662aa425
  22. 02 May, 2017 2 commits
  23. 11 Apr, 2017 2 commits
  24. 10 Apr, 2017 2 commits
    • Leszek Swirski's avatar
      [ignition] Add call bytecodes for undefined receiver · 751e8935
      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: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44530}
      751e8935
    • Ross McIlroy's avatar
      Reland: [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator."" · 496864f8
      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: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44511}
      496864f8
  25. 07 Apr, 2017 2 commits
  26. 27 Mar, 2017 1 commit
  27. 09 Mar, 2017 1 commit
  28. 20 Feb, 2017 1 commit
  29. 17 Feb, 2017 1 commit
  30. 01 Feb, 2017 1 commit
  31. 25 Jan, 2017 1 commit
  32. 06 Jan, 2017 1 commit
  33. 19 Dec, 2016 1 commit
  34. 08 Dec, 2016 1 commit
  35. 09 Nov, 2016 1 commit
  36. 18 Oct, 2016 1 commit
    • bmeurer's avatar
      [ic] Unify CallIC feedback collection and handling. · 308788b3
      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}
      308788b3