1. 18 Nov, 2016 1 commit
  2. 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
  3. 11 Nov, 2016 1 commit
  4. 10 Nov, 2016 1 commit
  5. 26 Oct, 2016 3 commits
    • bmeurer's avatar
      Revert of [compiler] Properly validate stable map assumption for globals.... · d0a047d4
      bmeurer authored
      Revert of [compiler] Properly validate stable map assumption for globals. (patchset #3 id:40001 of https://codereview.chromium.org/2444233004/ )
      
      Reason for revert:
      Breaks tree: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/8789
      
      Original issue's description:
      > [compiler] Properly validate stable map assumption for globals.
      >
      > For global object property cells, we did not check that the map on the
      > previous object is still the same for which we actually optimized. So
      > the optimized code was not in sync with the actual state of the property
      > cell. When loading from such a global object property cell, Crankshaft
      > optimizes away any map checks (based on the stable map assumption),
      > leading to arbitrary memory access in the worst case.
      >
      > TurboFan has the same bug for stores, but is safe on loads because we
      > do appropriate map checks there. However mixing TurboFan and Crankshaft
      > still exposes the bug.
      >
      > R=yangguo@chromium.org
      > BUG=chromium:659475
      
      TBR=yangguo@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:659475
      
      Review-Url: https://codereview.chromium.org/2454513003
      Cr-Commit-Position: refs/heads/master@{#40582}
      d0a047d4
    • bmeurer's avatar
      [compiler] Properly validate stable map assumption for globals. · 3aa57eb9
      bmeurer authored
      For global object property cells, we did not check that the map on the
      previous object is still the same for which we actually optimized. So
      the optimized code was not in sync with the actual state of the property
      cell. When loading from such a global object property cell, Crankshaft
      optimizes away any map checks (based on the stable map assumption),
      leading to arbitrary memory access in the worst case.
      
      TurboFan has the same bug for stores, but is safe on loads because we
      do appropriate map checks there. However mixing TurboFan and Crankshaft
      still exposes the bug.
      
      R=yangguo@chromium.org
      BUG=chromium:659475
      
      Review-Url: https://codereview.chromium.org/2444233004
      Cr-Commit-Position: refs/heads/master@{#40578}
      3aa57eb9
    • bmeurer's avatar
      [crankshaft] Refactor kAllowUndefinedAsNaN to kTruncatingToNumber. · df981a9f
      bmeurer authored
      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.
      
      R=yangguo@chromium.org
      BUG=v8:5400
      
      Review-Url: https://codereview.chromium.org/2449353002
      Cr-Commit-Position: refs/heads/master@{#40577}
      df981a9f
  6. 18 Oct, 2016 1 commit
  7. 12 Oct, 2016 3 commits
  8. 07 Oct, 2016 3 commits
  9. 06 Oct, 2016 2 commits
  10. 22 Sep, 2016 1 commit
  11. 20 Sep, 2016 3 commits
  12. 06 Sep, 2016 1 commit
    • marja's avatar
      Include only stuff you need, part 8: Fix debug.h -> liveedit.h. · 51a3ffd9
      marja authored
      Rebuilding (after touching certain files) is crazy slow because
      includes are out of control.
      
      The (last remaining) offending include path is: ast.h <- liveedit.h <-
      debug.h <- src/x64/assembler-whatever-port-inl.h <-
      src/macro-assembler.h <- everything possible
      
      With this CL, the rebuild steps needed when touching ast-value-factory.h
      drops from 365 to 181.
      
      BUG=v8:5294
      TBR=bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2316443002
      Cr-Commit-Position: refs/heads/master@{#39195}
      51a3ffd9
  13. 01 Sep, 2016 1 commit
  14. 31 Aug, 2016 1 commit
  15. 18 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add support for eager/soft deoptimization reasons. · db635d5b
      bmeurer authored
      So far TurboFan wasn't adding the deoptimization reasons for eager/soft
      deoptimization exits that can be used by either the DevTools profiler or
      the --trace-deopt flag. This adds basic support for deopt reasons on
      Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through
      the reasons to the code generation.
      
      Also moves the DeoptReason to it's own file (to resolve include cycles)
      and drops unused reasons.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2161543002
      Cr-Commit-Position: refs/heads/master@{#37823}
      db635d5b
  16. 13 Jul, 2016 1 commit
  17. 30 Jun, 2016 2 commits
  18. 27 Jun, 2016 1 commit
  19. 23 Jun, 2016 1 commit
  20. 20 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper Float64Tan operator. · c87168bc
      bmeurer authored
      Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
      operator based on that, similar to what we do for Float64Cos and Float64Sin.
      Rewrite Math.tan() as TurboFan builtin and use those operators to also
      inline Math.tan() into optimized TurboFan functions.
      
      Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
      the %ConstructDouble runtime entry for writing tests.
      
      BUG=v8:5086,v8:5126
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2083453002
      Cr-Commit-Position: refs/heads/master@{#37087}
      c87168bc
  21. 17 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper Float64Cos and Float64Sin. · c781e831
      bmeurer authored
      Import base::ieee754::cos() and base::ieee754::sin() from fdlibm and
      introduce Float64Cos and Float64Sin TurboFan operator based on that,
      similar to what we do for Float64Log. Rewrite Math.cos() and Math.sin()
      as TurboFan builtins and use those operators to also inline Math.cos()
      and Math.sin() into optimized TurboFan functions.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      R=mvstanton@chromium.org
      BUG=v8:5086,v8:5118
      
      Review-Url: https://codereview.chromium.org/2073123002
      Cr-Commit-Position: refs/heads/master@{#37072}
      c781e831
  22. 08 Jun, 2016 2 commits
  23. 01 Jun, 2016 1 commit
  24. 30 May, 2016 2 commits
  25. 17 May, 2016 1 commit
    • bmeurer's avatar
      [es6] Reintroduce the instanceof operator in the backends. · 551e0aa1
      bmeurer authored
      This adds back the instanceof operator support in the backends and
      introduces a @@hasInstance protector cell on the isolate that guards the
      fast path for the InstanceOfStub. This way we recover the ~10%
      regression on Octane EarleyBoyer in Crankshaft and greatly improve
      TurboFan and Ignition performance of instanceof.
      
      R=ishell@chromium.org
      TBR=hpayer@chromium.org,rossberg@chromium.org
      BUG=chromium:597249, v8:4447
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1980483003
      Cr-Commit-Position: refs/heads/master@{#36275}
      551e0aa1
  26. 10 May, 2016 1 commit
  27. 20 Apr, 2016 1 commit
    • mbrandy's avatar
      PPC: [crankshaft] Address the deoptimization loops of Math.floor, Math.round and Math.ceil. · 4e93ce4f
      mbrandy authored
      Port 978ad03b
      
      Original commit message:
          Fix and re-enable the flexible representation for Math.floor (which is used to
          implement Math.ceil) and Math.round, which allows Math.floor and Math.round to
          return double results instead of int32, and therefore allows values outside
          the int32 range, especially -0 is now a valid result, which doesn't deopt.
      
          Also port this feature to x64 and ia32 when the CPU supports the SSE4.1
          extension.
      
          This addresses all the known deoptimization loops related to Math.round
          in the Kraken benchmark suite, and seems to also address most of the
          deoptimization loops related to Math.floor in the Oort Online benchmark.
      
          Drive-by-fix: Import the regression tests for the broken HMathFloorOfDiv
          optimization that caused the initial revert of the feature (for arm64 only
          back then).
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=chromium:476477,v8:2890,v8:4059
      LOG=n
      
      Review URL: https://codereview.chromium.org/1839643007
      
      Cr-Commit-Position: refs/heads/master@{#35659}
      4e93ce4f
  28. 19 Apr, 2016 1 commit
    • adamk's avatar
      Remove all non-function-name uses of CONST_LEGACY · 59546149
      adamk authored
      Now that all 'const' declarations are of the ES2015 variety, the only
      use of CONST_LEGACY is for function name bindings in sloppy mode
      named function expressions.
      
      This patch aims to delete all code meant to handle other cases, which
      mostly had to do with hole initialization/hole checks. Since function
      name bindings are initialized at entry to a function, it's impossible
      to ever observe one in an uninitialized state.
      
      To simplify the patch further, it removes the `IMPORT` VariableMode,
      as it's not likely to be needed (IMPORT is identical to CONST for
      the purpose of VariableMode).
      
      Review URL: https://codereview.chromium.org/1895973002
      
      Cr-Commit-Position: refs/heads/master@{#35632}
      59546149