1. 22 Jun, 2017 1 commit
  2. 21 Jun, 2017 1 commit
  3. 20 Jun, 2017 1 commit
  4. 26 May, 2017 1 commit
  5. 23 May, 2017 1 commit
  6. 20 Mar, 2017 1 commit
    • leszeks's avatar
      [disasm] Make jump target printing perf friendly · dc789377
      leszeks authored
      Makes disassembly jump target printing look more like the output of
      objdump, for compatibility with perf's jump arrows. This includes
      swapping the order of address and offset, and making the offset and line
      numbers hex.
      
      As a drive-by, print comment lines in objdump-v8 so that they can be
      shown/hidden as "source" lines by perf.
      
      Review-Url: https://codereview.chromium.org/2757263002
      Cr-Commit-Position: refs/heads/master@{#43940}
      dc789377
  7. 17 Mar, 2017 1 commit
    • neis's avatar
      Disentangle assembler from isolate. · 94b088ca
      neis authored
      This is a first step towards moving Turbofan code generation off the main thread.
      
      Summary of the changes:
      - AssemblerBase no longer has a pointer to the isolate. Instead, its
        constructor receives the few things that it needs from the isolate (on most
        architectures this is just the serializer_enabled flag).
      - RelocInfo no longer has a pointer to the isolate. Instead, the functions
        that need it take it as an argument.  (There are currently still a few that
        implicitly access the isolate through a HeapObject.)
      - The MacroAssembler now explicitly holds a pointer to the isolate (before, it
        used to get it from the Assembler).
      - The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
        it's not used at all in the Assemblers.
      - A few architectures implemented parts of the Assembler with the help
        of a Codepatcher that is based on MacroAssembler.  Since the Assembler no
        longer has the isolate, but the MacroAssembler still needs it, this doesn't
        work anymore.  Instead, these Assemblers now use a new PatchingAssembler.
      
      BUG=v8:6048
      
      Review-Url: https://codereview.chromium.org/2732273003
      Cr-Commit-Position: refs/heads/master@{#43890}
      94b088ca
  8. 15 Mar, 2017 1 commit
  9. 23 Feb, 2017 1 commit
  10. 07 Feb, 2017 1 commit
  11. 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
  12. 25 Jul, 2016 1 commit
  13. 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
  14. 29 Jun, 2016 1 commit
  15. 16 Jun, 2016 1 commit
    • ishell's avatar
      [ic] LoadICState cleanup. · 5fcd3eb8
      ishell authored
      LoadICState was used to hold the TypeofMode flag which is relevant only for LoadGlobalIC.
      This CL removes usage of this state from LoadIC and KeyedLoadIC and renames the state
      class to LoadGlobalICState.
      
      BUG=chromium:576312
      LOG=Y
      
      Review-Url: https://codereview.chromium.org/2065373003
      Cr-Commit-Position: refs/heads/master@{#37033}
      5fcd3eb8
  16. 14 Jun, 2016 1 commit
    • ishell's avatar
      [ic] Split LoadIC into LoadGlobalIC and LoadIC. · d9e8764f
      ishell authored
      The former will handle loads of predeclared global variables (vars and
      functions), lets, consts and undeclared variables. The latter will handle
      named loads from explicit receiver. In addition, named loads does not
      depend of the TypeofMode.
      
      TypeofMode related cleanup will be done in the follow-up CL.
      
      BUG=chromium:576312
      LOG=Y
      TBR=bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/1912633002
      Cr-Commit-Position: refs/heads/master@{#36965}
      d9e8764f
  17. 09 Jun, 2016 1 commit
    • ishell's avatar
      [ic] [stubs] Remove InlineCacheState field from the code flags. · 9dc62d27
      ishell authored
      There are no ICs left that store their state in this field: vector based
      ICs use feedback vector and the rest three (BinaryOpIC, CompareIC and
      ToBooleanIC) reconstruct their state from the ExtraICState field.
      
      This CL also removes unused InlineCacheState::DEBUG_STUB which was used
      mostly in Code::is_debug_stub(). The latter now checks if the code is one
      of the debug builtins instead.
      
      BUG=chromium:618701
      LOG=Y
      
      Review-Url: https://codereview.chromium.org/2052763003
      Cr-Commit-Position: refs/heads/master@{#36871}
      9dc62d27
  18. 24 May, 2016 1 commit
  19. 13 May, 2016 1 commit
  20. 11 May, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Pass inlining_id via relocation info. · 32049620
      mstarzinger authored
      This passes the inlining_id of deoptimization points via the relocation
      info instead of via a side-channel to the CPU profiler. This is one step
      towards deprecating the side-channel in question and avoid the need for
      performing a lookup of the return address of the deopt point.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/1956693002
      Cr-Commit-Position: refs/heads/master@{#36177}
      32049620
  21. 12 Apr, 2016 1 commit
  22. 11 Apr, 2016 2 commits
  23. 08 Apr, 2016 2 commits
    • jfb's avatar
      Revert of Fix printf formats (patchset #8 id:140001 of... · 4c4fdc2d
      jfb authored
      Revert of Fix printf formats (patchset #8 id:140001 of https://codereview.chromium.org/1869433004/ )
      
      Reason for revert:
      One small issue easily fixed here: https://codereview.chromium.org/1867333003/
      
      But it looks like MSVS 2013 doesn't like some of the formats and exists with the unhelpful:
      Stderr:
      f:\dd\vctools\crt\crtw32\stdio\output.c(1125) : Assertion failed: ("Incorrect
      format specifier", 0)
      
      It's easier to revert for now, I'll dig more into the docs:
      https://msdn.microsoft.com/en-us/library/56e442dc(v=vs.120).aspx
      https://msdn.microsoft.com/en-us/library/tcxf1dw6(v=vs.120).aspx
      
      And then resubmit, making sure I run these bots.
      
      Original issue's description:
      > Fix printf formats
      >
      > The usage of __attribute__((format(x, y)) was either wrong or missing from multiple functions, leading to erroneous formats. This CL:
      >
      >  - Imports PRINTF_FORMAT macro from Chrome's src/base/compiler-specific.h.
      >  - Uses it appropriately.
      >  - Imports Chrome's base/format_macros.h mainly to fix size_t formats (further cleanup could be done).
      >  - Fixes a bunch of incorrect formats.
      >
      > R= jochen@chromium.org, bmeurer@chromium.org, yangguo@chromium.org, ahaas@chromium.org
      >
      > Committed: https://crrev.com/6ebf9fbb93d31f9be41156a3325d58704ed4933d
      > Cr-Commit-Position: refs/heads/master@{#35365}
      
      TBR=jochen@chromium.org,bmeurer@chromium.org,yangguo@chromium.org,ahaas@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1867383002
      
      Cr-Commit-Position: refs/heads/master@{#35366}
      4c4fdc2d
    • jfb's avatar
      Fix printf formats · 6ebf9fbb
      jfb authored
      The usage of __attribute__((format(x, y)) was either wrong or missing from multiple functions, leading to erroneous formats. This CL:
      
       - Imports PRINTF_FORMAT macro from Chrome's src/base/compiler-specific.h.
       - Uses it appropriately.
       - Imports Chrome's base/format_macros.h mainly to fix size_t formats (further cleanup could be done).
       - Fixes a bunch of incorrect formats.
      
      R= jochen@chromium.org, bmeurer@chromium.org, yangguo@chromium.org, ahaas@chromium.org
      
      Review URL: https://codereview.chromium.org/1869433004
      
      Cr-Commit-Position: refs/heads/master@{#35365}
      6ebf9fbb
  24. 06 Apr, 2016 1 commit
    • verwaest's avatar
      Use a dictionary-mode code cache on the map rather than a dual system. · d2eb555e
      verwaest authored
      The previous code cache system required stubs to be marked with a StubType, causing them to be inserted either into a fixed array or into a dictionary-mode code cache. This could cause names to be in both cases, and lookup would just find the "fast" one first. Given that we clear out the caches on each GC, the memory overhead shouldn't be too bad. Additionally, the dictionary itself should just stay linear for small arrays; that's faster anyway.
      
      This CL additionally deletes some dead IC code.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1846963002
      
      Cr-Commit-Position: refs/heads/master@{#35291}
      d2eb555e
  25. 01 Mar, 2016 1 commit
  26. 30 Nov, 2015 1 commit
  27. 27 Nov, 2015 1 commit
  28. 09 Nov, 2015 1 commit
    • mtrofin's avatar
      [assembler] Introduce proper AssemblerBase::Print() for improved debuggability. · ab1d270a
      mtrofin authored
      While working on frame elision, I wanted to disassemble codegen in the
      debugger, as the code generation is progressing. I discovered we had a
       "Print" member on the x64 assembler, without any implementation. I
      pulled it up to AssemblerBase and gave it an implementation that
      should work for the other architectures.
      
      Also checked that ia32, x87, arm and arm64 assemblers didn't have
      such an implementation - free Print.
      
      Arm64 has a naming conflict with the v8::internal::Disassembler. I
      renamed the arm64 type with a more specific name.
      
      Opportunistically fixed a bug in the name converter. This debug-time
      printer doesn't provide a Code object, which should be OK with the
      name converters, by the looks of other APIs there. All this means is that
      when using the Print() API, we just get addresses dumped without any
      context (like what this address may be - a stub maybe, etc). This seems
      fine for the scenario.
      
      There may be other places that assume a Code object. Since this is
      a diagnostics-only scenario, for codegen developers, I feel it is
      reasonable to fix such other places as we find them.
      
      Review URL: https://codereview.chromium.org/1431933003
      
      Cr-Commit-Position: refs/heads/master@{#31869}
      ab1d270a
  29. 24 Aug, 2015 1 commit
    • rmcilroy's avatar
      Add CompileInfo::GetDebugName() · 53ac9fe8
      rmcilroy authored
      Replaces all instances of the code which computed the debug
      name of a stub or function with calls to CompileInfo::GetDebugName instead.
      
      Also:
        - Removes useless parameter on CodeStub::GetMajorName
        - Removes FakeStubForTesting since it is no longer required
        - Adds CompileInfo::ShouldEnsureSpaceForLazyDeopt() to replace unclear calls to IsStub().
      
      Review URL: https://codereview.chromium.org/1297203002
      
      Cr-Commit-Position: refs/heads/master@{#30324}
      53ac9fe8
  30. 14 Aug, 2015 1 commit
  31. 31 Jul, 2015 1 commit
  32. 13 Jul, 2015 2 commits
  33. 10 Jul, 2015 1 commit
    • yangguo's avatar
      Debugger: use debug break slot to break on call. · 8965b683
      yangguo authored
      Break point at calls are currently set via IC. To change this, we
      need to set debug break slots instead. We also need to distinguish
      those debug break slots as calls to support step-in.
      
      To implement this, we add a data field to debug break reloc info to
      indicate non-call debug breaks or in case of call debug breaks, the
      number of arguments. We can later use this to find the callee on the
      evaluation stack in Debug::PrepareStep.
      
      BUG=v8:4269
      R=ulan@chromium.org
      LOG=N
      
      Review URL: https://codereview.chromium.org/1222093007
      
      Cr-Commit-Position: refs/heads/master@{#29561}
      8965b683
  34. 03 Jul, 2015 1 commit
  35. 16 Jun, 2015 1 commit
    • mstarzinger's avatar
      Revert of Decompiler improvements. (patchset #2 id:20001 of... · e2ce4681
      mstarzinger authored
      Revert of Decompiler improvements. (patchset #2 id:20001 of https://codereview.chromium.org/1177123002/)
      
      Reason for revert:
      Code printout has become unreadable. Offsets are printed in decimal numbers everywhere else. This is inconsistent with the rest of the code-base. Some examples are tables for deoptimization data, safepoints and exception handlers. I would be fine with this change if _all_ tracing would be adapted. But there are _many_ places to touch.
      
      Original issue's description:
      > Decompiler improvements.
      >
      > The main motivation is simplifying profiling activities:
      >
      > 1) Use hex instead of decimal for offsets, just like perf does. This
      > affects --print-opt-code
      >
      > 2) When printing block information, indicate loop information: if
      > block is header, where the end is; if block is in a loop, where the
      > loop starts. This affects --code-comments.
      >
      > Using --print-opt-code --code-comments, and cross-referencing with data
      > obtained from perf, one may now find the block a hotspot belongs to
      > without needing to do hex2dec/dec2hex conversions. Once found, loop info
      > is available locally, on the block.
      >
      > BUG=
      >
      > Committed: https://crrev.com/32f4bd659d38eb5485eedb1d0dd236ff1bdc01d5
      > Cr-Commit-Position: refs/heads/master@{#28964}
      
      TBR=jarin@chromium.org,stichnot@chromium.org,jvoung@chromium.org,mtrofin@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1188093002
      
      Cr-Commit-Position: refs/heads/master@{#29046}
      e2ce4681
  36. 11 Jun, 2015 1 commit
    • mtrofin's avatar
      Decompiler improvements. · 32f4bd65
      mtrofin authored
      The main motivation is simplifying profiling activities:
      
      1) Use hex instead of decimal for offsets, just like perf does. This
      affects --print-opt-code
      
      2) When printing block information, indicate loop information: if
      block is header, where the end is; if block is in a loop, where the
      loop starts. This affects --code-comments.
      
      Using --print-opt-code --code-comments, and cross-referencing with data
      obtained from perf, one may now find the block a hotspot belongs to
      without needing to do hex2dec/dec2hex conversions. Once found, loop info
      is available locally, on the block.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1177123002
      
      Cr-Commit-Position: refs/heads/master@{#28964}
      32f4bd65
  37. 01 Jun, 2015 1 commit