1. 14 Mar, 2017 1 commit
  2. 14 Feb, 2017 1 commit
  3. 13 Feb, 2017 4 commits
  4. 09 Feb, 2017 1 commit
  5. 18 Jan, 2017 1 commit
  6. 10 Jan, 2017 1 commit
  7. 03 Jan, 2017 1 commit
  8. 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
  9. 01 Dec, 2016 1 commit
  10. 18 Nov, 2016 1 commit
  11. 16 Nov, 2016 1 commit
  12. 15 Nov, 2016 1 commit
    • petermarshall's avatar
      Fastpath some spread-call desugaring. · a63eeb48
      petermarshall authored
      Avoid using the iterator for arrays with fast elements where the iterator has
      not been modified.
      
      Only deals with the case where there is a single spread argument.
      
      Improves the six-speed "spread" benchmark to 1.5x slower than baseline es5 implementation, compared to 19x slower previously.
      
      BUG=v8:5511
      
      Review-Url: https://codereview.chromium.org/2465253011
      Cr-Commit-Position: refs/heads/master@{#40998}
      a63eeb48
  13. 14 Nov, 2016 1 commit
    • 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
  14. 11 Nov, 2016 1 commit
  15. 28 Oct, 2016 1 commit
  16. 27 Oct, 2016 1 commit
    • zhengxing.li's avatar
      X87: [crankshaft] Refactor kAllowUndefinedAsNaN to kTruncatingToNumber. · 9bc155b9
      zhengxing.li authored
        port df981a9f (r40577)
      
        original commit message:
        The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber
        conversion (except for the uses in HBranch and HCompareHoleAndBranch,
        which were confusing and useless anyways), so fix the naming to match
        that.
      
        Also properly integrate the handling of this flag with the existing
        truncation analysis that is run as part of the representation changes
        phase (i.e. where we already deal with truncating to int32 and smi).
      
        This is done in preparation of allowing Crankshaft to handle any kind
        of Oddball in the ToNumber truncation, instead of just undefined for
        truncation ToNumber and undefined or boolean for ToInt32. It also helps
        to make Crankshaft somewhat more compatible with the (saner)
        implementation in TurboFan.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2456503003
      Cr-Commit-Position: refs/heads/master@{#40607}
      9bc155b9
  17. 24 Oct, 2016 1 commit
  18. 18 Oct, 2016 1 commit
  19. 12 Oct, 2016 1 commit
  20. 11 Oct, 2016 1 commit
  21. 07 Oct, 2016 3 commits
  22. 06 Oct, 2016 2 commits
  23. 22 Sep, 2016 1 commit
  24. 20 Sep, 2016 2 commits
  25. 06 Sep, 2016 1 commit
    • mlippautz's avatar
      Move kMaxRegularHeapObjectSize into globals · 059b5643
      mlippautz authored
      This way we avoid the cyclic dependency between objects.h and heap.h and still
      have one definition. Add a static assert that this size is indeed smaller than
      the payload of a page.
      
      Follow ups can finally remove the dependency on spaces.h for all heap.h users.
      
      R=ulan@chromium.org,bmeurer@chromium.org,vogelheim@chromium.og
      
      Review-Url: https://codereview.chromium.org/2311203002
      Cr-Commit-Position: refs/heads/master@{#39206}
      059b5643
  26. 30 Aug, 2016 1 commit
  27. 25 Aug, 2016 1 commit
  28. 17 Aug, 2016 1 commit
    • rmcilroy's avatar
      Avoid accessing Isolate in source position logging. · b8b4a443
      rmcilroy authored
      Now that all backends use the source position builder to record source
      positions, simplify the code line logging events to take a source
      position table on code creation. This means that the source position
      table builder no longer needs to access the isolate until the table is
      generated. This is required for off-thread bytecode generation.
      
      BUG=v8:5203
      
      Review-Url: https://codereview.chromium.org/2248673002
      Cr-Commit-Position: refs/heads/master@{#38676}
      b8b4a443
  29. 11 Aug, 2016 1 commit
  30. 09 Aug, 2016 1 commit
    • zhengxing.li's avatar
      X87: [stubs] Convert GrowElementsStub to TurboFan. · 978edb24
      zhengxing.li authored
        port eb841269 (r38371)
      
        original commit message:
        One caveat: the Crankshaft stub used to preserve callee-clobbered double
        registers, which is contrary to any real platform ABI that we support. Since the
        only current use of this stub is in Crankshaft, the instruction there now must
        be marked as double-clobbering. This might result in a small performance
        regression. However, when this stub is eventually used in TF-generated code, it
        will be called from deferred code that can save doubles only on the rarely-taken
        path... something that Crankshaft can't do.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2226673002
      Cr-Commit-Position: refs/heads/master@{#38465}
      978edb24
  31. 05 Aug, 2016 3 commits