1. 09 Jan, 2017 2 commits
  2. 05 Jan, 2017 1 commit
    • franzih's avatar
      [runtime] Collect IC feedback in DefineDataPropertyInLiteral. · 81736c71
      franzih authored
      Add a feedback vector slot for computed property names in object
      and class literals. Introduce new slot kind for storing
      computed property names.
      
      Change StaDataPropertyInLiteral to use the accumulator (again), so
      we don't exceed Bytecodes::kMaxOperands.
      
      We assume that most computed property names are
      symbols. Therefore we should see performance
      improvements, even if we deal with monomorphic ICs only.
      
      This CL only collects feedback but does not use
      it in Reduce() yet.
      
      BUG=v8:5624
      
      Review-Url: https://codereview.chromium.org/2587393006
      Cr-Commit-Position: refs/heads/master@{#42082}
      81736c71
  3. 28 Dec, 2016 2 commits
  4. 22 Dec, 2016 1 commit
  5. 21 Dec, 2016 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root literal arrays in function literals slots · 93df0940
      mvstanton authored
      Literal arrays and feedback vectors for a function can be garbage
      collected if we don't have a rooted closure for the function, which
      happens often. It's expensive to come back from this (recreating
      boilerplates and gathering feedback again), and the cost is
      disproportionate if the function was inlined into optimized code.
      
      To guard against losing these arrays when we need them, we'll now
      create literal arrays when creating the feedback vector for the outer
      closure, and root them strongly in that vector.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2504153002
      Cr-Commit-Position: refs/heads/master@{#41893}
      93df0940
  6. 20 Dec, 2016 1 commit
    • littledan's avatar
      Use a different map to distinguish eval contexts · 53fdf9d1
      littledan authored
      eval() may introduce a scope which needs to be represented as a context at
      runtime, e.g.,
      
        eval('var x; let y; ()=>y')
      
      introduces a variable y which needs to have a context allocated for it. However,
      when traversing upwards to find the declaration context for a variable which leaks,
      as the declaration of x does above, this context has to be understood to not be
      a declaration context in sloppy mode.
      
      This patch makes that distinction by introducing a different map for eval-introduced
      contexts. A dynamic search for the appropriate context will continue past an eval
      context to find the appropriate context. Marking contexts as eval contexts rather
      than function contexts required updates in each compiler backend.
      
      BUG=v8:5295, chromium:648719
      
      Review-Url: https://codereview.chromium.org/2435023002
      Cr-Commit-Position: refs/heads/master@{#41869}
      53fdf9d1
  7. 19 Dec, 2016 2 commits
  8. 16 Dec, 2016 2 commits
  9. 15 Dec, 2016 2 commits
    • rmcilroy's avatar
      [Interpreter] Allocate registers used as call arguments on-demand. · ae741d04
      rmcilroy authored
      Allocate the registers used as arguments to a call on-demand after visiting the
      argument (or reciever). This means that the visited expression can use registers
      that would otherwise have been allocated for arguments which haven't been
      visited yet.
      
      The reason for doing this is to avoid keeping things live in registers
      unecessarily for chained function calls, which avoids a memory leak for
      functions which chain a large number of calls with large temporary arguments /
      recievers.
      
      BUG=chromium:672027
      
      Review-Url: https://codereview.chromium.org/2557173004
      Cr-Commit-Position: refs/heads/master@{#41714}
      ae741d04
    • rmcilroy's avatar
      [Interpreter] Templatize AccumulatorUsage and OperandType for bytecode creation. · e27b348d
      rmcilroy authored
      Templatizes the AccumulatorUsage and OperandType for BytecodeNode creation and
      BytecodeRegisterOptimizer::PrepareForBytecode. This allows the compiler to
      statically know whether the bytecode being created accesses the accumulator
      and what operand types need scaling, avoiding runtime checks in the code.
      
      Also removes BytecodeNode::set_bytecode methods.
      
      Review-Url: https://codereview.chromium.org/2542903003
      Cr-Commit-Position: refs/heads/master@{#41706}
      e27b348d
  10. 12 Dec, 2016 1 commit
  11. 07 Dec, 2016 2 commits
    • caitp's avatar
      [ignition] desugar GetIterator() via bytecode rather than via AST · b5f146a0
      caitp authored
      Introduces:
      - a new AST node representing the GetIterator() algorithm in the specification, to be used by ForOfStatement, YieldExpression (in the case of delegating yield*), and the future `for-await-of` loop proposed in http://tc39.github.io/proposal-async-iteration/#sec-async-iterator-value-unwrap-functions.
      - a new opcode (JumpIfJSReceiver), which is useful for `if Type(object) is not Object` checks which are common throughout the specification. This node is easily eliminated by TurboFan.
      
      The AST node is desugared specially in bytecode, rather than manually when building the AST. The benefit of this is that desugaring in the BytecodeGenerator is much simpler and easier to understand than desugaring the AST.
      
      This also reduces parse time very slightly, and allows us to use LoadIC rather than KeyedLoadIC, which seems to have  better baseline performance. This results in a ~20% improvement in test/js-perf-test/Iterators micro-benchmarks, which I believe owes to the use of the slightly faster LoadIC as opposed to the KeyedLoadIC in the baseline case. Both produce identical optimized code via TurboFan when the type check can be eliminated, and the load can be replaced with a constant value.
      
      BUG=v8:4280
      R=bmeurer@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, neis@chromium.org, jarin@chromium.org
      TBR=rossberg@chromium.org
      
      Review-Url: https://codereview.chromium.org/2557593004
      Cr-Commit-Position: refs/heads/master@{#41555}
      b5f146a0
    • petermarshall's avatar
      [Ignition/turbo] Add a NewWithSpread bytecode. · a25e7688
      petermarshall authored
      This just calls into a runtime function for implementation currently.
      
      Intermediate step in speeding up constructor calls containing a spread.
      
      The NewWithSpread bytecode will probably end up having different arguments with future CLs - the constructor and the new.target should have their own regs. For now we are calling into the runtime function, so we need the regs together.
      
      BUG=v8:5659
      
      Review-Url: https://codereview.chromium.org/2541113004
      Cr-Commit-Position: refs/heads/master@{#41542}
      a25e7688
  12. 06 Dec, 2016 1 commit
    • mythria's avatar
      [Interpreter] Optimize equality check with null/undefined with a check on the map. · 9119d169
      mythria authored
      Equality with null/undefined is equivalent to a check on the undetectable bit
      on the map of the object. This would be more efficient than performing the entire
      comparison operation.
      
      This cl introduces:
      1. A new bytecode called TestUndetectable that checks if the object is null/undefined.
      2. Updates peeophole optimizer to emit TestUndetectable when a LdaNull/Undefined
      precedes equality check.
      4. TestUndetectable is transformed to ObjectIsUndetectable operator when building
      turbofan graph.
      
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2547043002
      Cr-Commit-Position: refs/heads/master@{#41514}
      9119d169
  13. 05 Dec, 2016 2 commits
  14. 21 Nov, 2016 1 commit
  15. 18 Nov, 2016 1 commit
  16. 16 Nov, 2016 4 commits
  17. 15 Nov, 2016 1 commit
  18. 14 Nov, 2016 2 commits
    • tebbi's avatar
      This CL enables precise source positions for all V8 compilers. It merges... · c3a6ca68
      tebbi authored
      This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset.
      SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
       - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
       - The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
      Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
      
      If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
      So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
      
      All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
      
      At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
      
      I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
      
      The following additional changes were necessary:
       - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
       - The class HPositionInfo was effectively dead code and is now removed.
       - SourcePosition has new printing and information facilities, including computing a full inlining stack.
       - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
       - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
       - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
       - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
      
      BUG=v8:5432
      
      Review-Url: https://codereview.chromium.org/2451853002
      Cr-Commit-Position: refs/heads/master@{#40975}
      c3a6ca68
    • ulan's avatar
      Enable -Wsign-compare compiler warnings. · e5b15226
      ulan authored
      BUG=v8:5614
      
      Review-Url: https://codereview.chromium.org/2493193002
      Cr-Commit-Position: refs/heads/master@{#40958}
      e5b15226
  19. 11 Nov, 2016 1 commit
  20. 10 Nov, 2016 2 commits
  21. 09 Nov, 2016 1 commit
  22. 08 Nov, 2016 1 commit
  23. 07 Nov, 2016 1 commit
  24. 28 Oct, 2016 1 commit
  25. 27 Oct, 2016 1 commit
    • leszeks's avatar
      [ignition] Add a property call bytecode · c4d770b1
      leszeks authored
      This is a new bytecode which behaves (for now) exactly like Call,
      except that in turbofan graph building we can set the
      ConvertReceiverMode to NotNullOrUndefined.
      
      I observe a 1% improvement on Box2D, I'd expect a similar improvement on
      other OOP heavy code.
      
      Review-Url: https://codereview.chromium.org/2450243002
      Cr-Commit-Position: refs/heads/master@{#40610}
      c4d770b1
  26. 24 Oct, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Optimize the Register Optimizer. · ed7bef5b
      rmcilroy authored
      Modify the Bytecode Register Optimizer to be an independent component
      rather than part of the BytecodePipeline. This means the BytecodeArrayBuilder
      can explicitly call it with register operands when outputting a bytecode
      and the Bytecode Register Optimizer doesn't need to work out which operands
      are register operands. This also means we don't need to build BytecodeNodes
      for Ldar / Star / Mov bytecodes unless they are actually emitted by the
      optimizer.
      
      This change also modifies the way the BytecodeArrayBuilder converts
      operands to make use of the OperandTypes specified in bytecodes.h.
      This avoids having to individually convert operands to their raw output
      value before calling Output(...).
      
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2393683004
      Cr-Commit-Position: refs/heads/master@{#40543}
      ed7bef5b
  27. 14 Oct, 2016 1 commit
  28. 11 Oct, 2016 1 commit