1. 19 May, 2017 1 commit
  2. 18 May, 2017 1 commit
    • Adam Klein's avatar
      Reland: [ignition] Be smarter about register allocation in VisitSuspend · 5dc2d6f6
      Adam Klein authored
      Split BytecodeGenerator::VisitSuspend into two pieces, one for
      building the suspension code and one for resumption (these
      are split into separate Build methods for convenience).
      Each gets its own RegisterAllocationScope, which allows us to
      reduce the register file size of the empty generator by 1.
      
      For consistency, rename VisitGeneratorPrologue() to
      BuildGeneratorPrologue() to match the names of the two
      newly-created methods.
      
      This relands the patch originally committed in
      98927ea5, as the test failure
      due to that change was a code flushing bug. Code flushing was
      disabled in de4a4095.
      
      R=rmcilroy@chromium.org
      
      Bug: v8:6379
      Change-Id: Ifb4deafea99693c0a4e8646cf4e9884c7374cfc6
      Reviewed-on: https://chromium-review.googlesource.com/508814Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45406}
      5dc2d6f6
  3. 16 May, 2017 2 commits
  4. 15 May, 2017 3 commits
  5. 12 May, 2017 1 commit
  6. 10 May, 2017 1 commit
  7. 09 May, 2017 1 commit
  8. 08 May, 2017 2 commits
    • 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
    • Adam Klein's avatar
      Skip hole initialization of lexical variables when possible · ededfcd2
      Adam Klein authored
      This patch expands scope analysis to skip hole initialization
      when it can be determined statically that no hole checks will
      be generated at runtime.
      
      Two conditions must be met to safely eliminate hole initialization:
        - There must not exist a VariableProxy referencing this Variable
          whose HoleCheckMode is kRequired
        - The Variable must be stack allocated; any other allocation implies
          that it may be accessed from not-yet-analyzed scopes (other modules,
          inner functions, or eval code) and that code may require
          hole checks.
      
      The new logic required removing debug code in full-codegen which is
      now incorrect in some cases.
      
      Also fixed Variable's bitfield helpers to take no more space than needed.
      
      Bug: chromium:651637
      Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d
      Reviewed-on: https://chromium-review.googlesource.com/494006
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45170}
      ededfcd2
  9. 05 May, 2017 1 commit
  10. 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
  11. 02 May, 2017 2 commits
  12. 19 Apr, 2017 1 commit
    • Caitlin Potter's avatar
      [parser] avoid complex for-loop desugaring when possible · 267115da
      Caitlin Potter authored
      let/const declarations in "standard" C-style for-loops have
      some complex desugaring to accommodate the case where loop
      loop variables may be captured. This slows down the baseline
      performance of for-loops with let variables.
      
      This change attempts to avoid this desugaring if it's known that
      the loop variable is not captured at any point. A side effect of
      this change is that let/const loop variables, when not captured
      within the loop body, are not necessarily shown in the debugger,
      similar to other stack-allocated vars.
      
      BUG=v8:4762, v8:5460
      R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org
      
      Change-Id: I8dbe545a12c086f675972bdba60c94998268311a
      Reviewed-on: https://chromium-review.googlesource.com/472247
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44731}
      267115da