1. 05 Nov, 2018 1 commit
  2. 14 Sep, 2018 1 commit
  3. 02 May, 2018 1 commit
    • Leszek Swirski's avatar
      Revert "[parser] Slice the source string where possible" · 18bc2856
      Leszek Swirski authored
      This reverts commit 2df5e7a7.
      
      Reason for revert: Mystery crashes https://bugs.chromium.org/p/chromium/issues/detail?id=838805
      
      Original change's description:
      > [parser] Slice the source string where possible
      > 
      > When internalizing string literals (for quoted strings or property names),
      > try to create a sliced string of the source string rather than allocating
      > a copy of the bytes.
      > 
      > This will not work for string literals that contain escapes (e.g. unicode
      > escapes), and currently does not support two-byte strings.
      > 
      > Bug: chromium:818642
      > Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
      > Reviewed-on: https://chromium-review.googlesource.com/1010282
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52898}
      
      TBR=marja@chromium.org,yangguo@chromium.org,jarin@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,verwaest@chromium.org
      
      Change-Id: I598b6668c43a3e843e2dd8e60852b2b2f3461954
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:818642
      Reviewed-on: https://chromium-review.googlesource.com/1039885
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52919}
      18bc2856
  4. 01 May, 2018 1 commit
  5. 13 Dec, 2017 1 commit
  6. 15 Nov, 2017 1 commit
  7. 27 Oct, 2017 1 commit
    • Adam Klein's avatar
      [ast] Move AstValue implementation into Literal · 317cf321
      Adam Klein authored
      This eliminates the AstValue class, effectively moving its
      implementation into the Literal AstNode. This should cause
      no difference in behavior, but it does signal some shifts
      in the underlying system. Biggest changes include:
      
        - Reduction in AST memory usage
        - No duplicate HeapNumbers in Ignition constant pools
        - Non-String values are allocated either at constant pool
          creation time (or at boilerplate creation time for literals),
          rather than at AstValueFactory::Internalize() time.
      
      There are a variety of test-only/debug-only changes due to these
      switches as well.
      
      Bug: v8:6984
      Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1
      Reviewed-on: https://chromium-review.googlesource.com/731111
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49013}
      317cf321
  8. 19 Oct, 2017 1 commit
  9. 01 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Optimize fast enum cache driven for..in. · f1ec44e2
      Benedikt Meurer authored
      This CL adds support to optimize for..in in fast enum-cache mode to the
      same degree that it was optimized in Crankshaft, without adding the same
      deoptimization loop that Crankshaft had with missing enum cache indices.
      That means code like
      
        for (var k in o) {
          var v = o[k];
          // ...
        }
      
      and code like
      
        for (var k in o) {
          if (Object.prototype.hasOwnProperty.call(o, k)) {
            var v = o[k];
            // ...
          }
        }
      
      which follows the https://eslint.org/docs/rules/guard-for-in linter
      rule, can now utilize the enum cache indices if o has only fast
      properties on the receiver, which speeds up the access o[k]
      significantly and reduces the pollution of the global megamorphic
      stub cache.
      
      For example the micro-benchmark in the tracking bug v8:6702 now runs
      faster than ever before:
      
       forIn: 1516 ms.
       forInHasOwnProperty: 1674 ms.
       forInHasOwnPropertySafe: 1595 ms.
       forInSum: 2051 ms.
       forInSumSafe: 2215 ms.
      
      Compared to numbers from V8 5.8 which is the last version running with
      Crankshaft
      
       forIn: 1641 ms.
       forInHasOwnProperty: 1719 ms.
       forInHasOwnPropertySafe: 1802 ms.
       forInSum: 2226 ms.
       forInSumSafe: 2409 ms.
      
      and V8 6.0 which is the current stable version with TurboFan:
      
       forIn: 1713 ms.
       forInHasOwnProperty: 5417 ms.
       forInHasOwnPropertySafe: 5324 ms.
       forInSum: 7556 ms.
       forInSumSafe: 11067 ms.
      
      It also improves the throughput on the string-fasta benchmark by
      around 7-10%, and there seems to be a ~5% improvement on the
      Speedometer/React benchmark locally.
      
      For this to work, the ForInPrepare bytecode was split into
      ForInEnumerate and ForInPrepare, which is very similar to how it was
      handled in Fullcodegen initially. In TurboFan we introduce a new
      operator LoadFieldByIndex that does the dynamic property load.
      
      This also removes the CheckMapValue operator again in favor of
      just using LoadField, ReferenceEqual and CheckIf, which work
      automatically with the EscapeAnalysis and the
      BranchConditionElimination.
      
      Bug: v8:6702
      Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
      Reviewed-on: https://chromium-review.googlesource.com/645949
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47768}
      f1ec44e2
  10. 10 Feb, 2017 1 commit
  11. 09 Jan, 2017 1 commit
  12. 16 Nov, 2016 1 commit
  13. 11 Nov, 2016 1 commit
  14. 10 Nov, 2016 1 commit
  15. 07 Oct, 2016 3 commits
  16. 05 Oct, 2016 1 commit
  17. 30 Sep, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Replace BytecodeRegisterAllocator with a simple bump pointer. · 27fe988b
      rmcilroy authored
      There are only a few occasions where we allocate a register in an outer
      expression allocation scope, which makes the costly free-list approach
      of the BytecodeRegisterAllocator unecessary. This CL replaces all
      occurrences with moves to the accumulator and stores to a register
      allocated in the correct scope. By doing this, we can simplify the
      BytecodeRegisterAllocator to be a simple bump-pointer allocator
      with registers released in the same order as allocated.
      
      The following changes are also made:
       - Make BytecodeRegisterOptimizer able to use registers which have been
         unallocated, but not yet reused
       - Remove RegisterExpressionResultScope and rename
         AccumulatorExpressionResultScope to ValueExpressionResultScope
       - Introduce RegisterList to represent consecutive register
         allocations, and use this for operands to call bytecodes.
      
      By avoiding the free-list handling, this gives another couple of
      percent on CodeLoad.
      
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2369873002
      Cr-Commit-Position: refs/heads/master@{#39905}
      27fe988b
  18. 18 Aug, 2016 1 commit
  19. 08 Aug, 2016 1 commit
  20. 29 Jul, 2016 1 commit
  21. 05 Jul, 2016 1 commit
    • oth's avatar
      [interpreter] Introduce binary op bytecodes for Smi operand. · 40511877
      oth authored
      Introduces fused bytecodes for fusing LdaSmi followed by a binary op bytecode.
      The chosen bytecodes are used frequently in Octane: AddSmi, SubSmi,
      BitwiseOrSmi, BitwiseAndSmi, ShiftLeftSmi, ShiftRightSmi.
      
      There are additional code stubs for these operations that are biased towards
      both the left hand and right hand operands being Smis.
      
      BUG=v8:4280
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2111923002
      Cr-Commit-Position: refs/heads/master@{#37531}
      40511877
  22. 27 Jun, 2016 1 commit
  23. 21 Jun, 2016 3 commits
  24. 27 May, 2016 1 commit
  25. 25 May, 2016 2 commits
  26. 12 May, 2016 1 commit
    • oth's avatar
      [interpreter] Introduce bytecode generation pipeline. · 02b7373a
      oth authored
      This change introduces a pipeline for the final stages of
      bytecode generation.
      
      The peephole optimizer is made distinct from the BytecodeArrayBuilder.
      
      A new BytecodeArrayWriter is responsible for writing bytecode. It
      also keeps track of the maximum register seen and offers a potentially
      smaller frame size.
      
      R=rmcilroy@chromium.org
      LOG=N
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/1947403002
      Cr-Commit-Position: refs/heads/master@{#36220}
      02b7373a
  27. 01 Apr, 2016 1 commit
  28. 21 Mar, 2016 1 commit
    • oth's avatar
      [interpreter] Add support for scalable operands. · 48d082af
      oth authored
      This change introduces wide prefix bytecodes to support wide (16-bit)
      and extra-wide (32-bit) operands. It retires the previous
      wide-bytecodes and reduces the number of operand types.
      
      Operands are now either scalable or fixed size. Scalable operands
      increase in width when a bytecode is prefixed with wide or extra-wide.
      
      The bytecode handler table is extended to 256*3 entries. The
      first 256 entries are used for bytecodes with 8-bit operands,
      the second 256 entries are used for bytecodes with operands that
      scale to 16-bits, and the third group of 256 entries are used for
      bytecodes with operands that scale to 32-bits.
      
      LOG=N
      BUG=v8:4747,v8:4280
      
      Review URL: https://codereview.chromium.org/1783483002
      
      Cr-Commit-Position: refs/heads/master@{#34955}
      48d082af
  29. 17 Feb, 2016 1 commit
  30. 11 Feb, 2016 3 commits
  31. 04 Feb, 2016 1 commit
  32. 02 Feb, 2016 1 commit
    • oth's avatar
      [interpreter] Move temporary register allocator into own file. · ef93854a
      oth authored
      Moves the temporary register allocator out of the bytecode array
      builder into TemporaryRegisterAllocator class and adds unittests.
      Particular must be taken around the translation window boundary
      motivating the addition of tests.
      
      Also adds a Clear() method to IdentityMap() which is called by
      the destructor. This allows classes to hold an IdentityMap if
      they are zone allocated. Classes must call Clear() before the zone
      is re-cycled or face v8 heap corruption.
      
      BUG=v8:4280,v8:4675
      LOG=N
      
      Review URL: https://codereview.chromium.org/1651133002
      
      Cr-Commit-Position: refs/heads/master@{#33686}
      ef93854a
  33. 23 Dec, 2015 1 commit