1. 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
  2. 11 Nov, 2016 1 commit
  3. 18 Oct, 2016 1 commit
  4. 12 Oct, 2016 1 commit
  5. 06 Oct, 2016 2 commits
  6. 22 Sep, 2016 1 commit
  7. 20 Sep, 2016 2 commits
  8. 25 Aug, 2016 1 commit
  9. 14 Jul, 2016 1 commit
  10. 30 Jun, 2016 1 commit
  11. 27 Jun, 2016 1 commit
  12. 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
  13. 17 Jun, 2016 2 commits
    • 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
    • bmeurer's avatar
      [builtins] Introduce proper Float64Exp operator. · d5f2ac5e
      bmeurer authored
      Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
      TurboFan operator based on that, similar to what we do for Float64Log.
      Rewrite Math.exp() as TurboFan builtin and use that operator to also
      inline Math.exp() into optimized TurboFan functions.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108,chromium:620786
      R=mvstanton@chromium.org
      
      Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260
      Review-Url: https://codereview.chromium.org/2077533002
      Cr-Original-Commit-Position: refs/heads/master@{#37037}
      Cr-Commit-Position: refs/heads/master@{#37047}
      d5f2ac5e
  14. 16 Jun, 2016 2 commits
  15. 30 May, 2016 1 commit
  16. 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
  17. 13 May, 2016 1 commit
  18. 06 May, 2016 1 commit
  19. 07 Apr, 2016 1 commit
  20. 01 Apr, 2016 1 commit
  21. 30 Mar, 2016 1 commit
  22. 22 Mar, 2016 2 commits
  23. 21 Mar, 2016 2 commits
  24. 16 Mar, 2016 3 commits
  25. 08 Mar, 2016 1 commit
    • verwaest's avatar
      Don't do any special normalization if a boilerplate contains function literals. · fd405704
      verwaest authored
      This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:
      
      function.prototype = {
        method: function() { ... }
      }
      
      Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.
      
      This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.
      
      BUG=chromium:593008
      LOG=n
      
      Review URL: https://codereview.chromium.org/1772423002
      
      Cr-Commit-Position: refs/heads/master@{#34602}
      fd405704
  26. 29 Feb, 2016 1 commit
    • bmeurer's avatar
      [stubs] Introduce a proper ToBooleanStub. · d1df58e8
      bmeurer authored
      Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match
      our naming convention, and add a new TurboFan-powered ToBooleanStub,
      which just does the ToBoolean conversion without any runtime call or
      code patching, so we can use it for Ignition (and TurboFan).
      
      Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we
      already have for to_string and to_number, so we don't need to actually
      dispatch on the concrete Oddball at all.
      
      R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1744163002
      
      Cr-Commit-Position: refs/heads/master@{#34361}
      d1df58e8
  27. 26 Feb, 2016 1 commit
  28. 24 Feb, 2016 1 commit
  29. 18 Feb, 2016 1 commit
  30. 17 Feb, 2016 3 commits