1. 12 Aug, 2016 1 commit
  2. 28 Jul, 2016 3 commits
  3. 26 Jul, 2016 3 commits
  4. 01 Jun, 2016 2 commits
  5. 23 May, 2016 1 commit
    • oth's avatar
      [Interpreter] Preserve source positions in peephole optimizer. · e43fbde7
      oth authored
      The original peephole optimizer logic in the BytecodeArrayBuilder did
      not respect source positions as it was written before there were
      bytecode source positions. This led to some minor differences to
      FCG and was problematic when combined with pending bytecode
      optimizations. This change makes the new peephole optimizer fully
      respect source positions.
      
      BUG=v8:4280
      LOG=N
      
      Review-Url: https://codereview.chromium.org/1998203002
      Cr-Commit-Position: refs/heads/master@{#36439}
      e43fbde7
  6. 10 May, 2016 1 commit
  7. 06 May, 2016 1 commit
  8. 27 Apr, 2016 1 commit
    • ssanfilippo's avatar
      [Interpreter] Add Ignition statistics JavaScript extension. · 905becd1
      ssanfilippo authored
      This commit introduces IgnitionStatisticsExtension, which provides
      methods for accessing Ignition statistics and counters from JavaScript.
      
      The extension is registered when FLAG_ignition and
      FLAG_trace_ignition_dispatches are both enabled.
      
      For the moment, the only exposed function is
      getIgnitionDispatchCounters(), which allows to retrieve Ignition
      dispatch counters as a JavaScript object.
      
      BUG=v8:4899
      LOG=N
      
      Review URL: https://codereview.chromium.org/1899133004
      
      Cr-Commit-Position: refs/heads/master@{#35816}
      905becd1
  9. 01 Apr, 2016 1 commit
    • mythria's avatar
      [Interpreter] Handles BytecodeArrays when scanning objects in heap. · 8a9ada48
      mythria authored
      Handles bytecodeArray Objects when verifying the heap and also when
      collecting code statistics. The changes include:
      1. BytecodeArrays could be a part of the large object space. When
      verifying the large object space we should also allow BytecodeArray
      objects.
      2. Adds support for BytecodeArrays when collecting code statistics.
      
      BUG=v8:4280,chromium:599001
      LOG=N
      
      Review URL: https://codereview.chromium.org/1850443006
      
      Cr-Commit-Position: refs/heads/master@{#35202}
      8a9ada48
  10. 31 Mar, 2016 2 commits
    • mythria's avatar
      [Interpreter] Changes GenerateDoubleToObject to push and pop rsi value. · e6b6e554
      mythria authored
      In the earlier implementation of GenerateDoubleToObject the context
      is loaded from the parent's frame. rsi is clobbered because it is used
      to store kHoleNan constnat. It is not always safe to peek at
      the parents frame. Bytecode handlers have TypedFrame and the type of
      frame is stored at FP + 1. GenerateDoubleToObject expects context
      to be store at that place. In the current implementation rsi is pushed
      onto the stack and is popped when exiting this function.
      
      BUG=v8:4280,chromium:597565
      LOG=N
      
      Review URL: https://codereview.chromium.org/1848473002
      
      Cr-Commit-Position: refs/heads/master@{#35163}
      e6b6e554
    • oth's avatar
      [interpreter] Adds test for tracing. · 8cf73ae1
      oth authored
      Fixes a stale DCHECK and a memory leak in tracing output.
      
      LOG=N
      BUG=v8:4280
      TBR=rmcilroy@chromium.org
      
      Review URL: https://codereview.chromium.org/1844023003
      
      Cr-Commit-Position: refs/heads/master@{#35161}
      8cf73ae1
  11. 21 Mar, 2016 1 commit
    • oth's avatar
      [interpreter] Add support for scalable operands. · 48d082af
      oth authored
      This change introduces wide prefix bytecodes to support wide (16-bit)
      and extra-wide (32-bit) operands. It retires the previous
      wide-bytecodes and reduces the number of operand types.
      
      Operands are now either scalable or fixed size. Scalable operands
      increase in width when a bytecode is prefixed with wide or extra-wide.
      
      The bytecode handler table is extended to 256*3 entries. The
      first 256 entries are used for bytecodes with 8-bit operands,
      the second 256 entries are used for bytecodes with operands that
      scale to 16-bits, and the third group of 256 entries are used for
      bytecodes with operands that scale to 32-bits.
      
      LOG=N
      BUG=v8:4747,v8:4280
      
      Review URL: https://codereview.chromium.org/1783483002
      
      Cr-Commit-Position: refs/heads/master@{#34955}
      48d082af
  12. 16 Mar, 2016 1 commit
  13. 15 Mar, 2016 1 commit
    • yangguo's avatar
      [ignition, debugger] correctly set position for return with elided bytecode. · 3c1dc424
      yangguo authored
      We may not emit bytecode for the evaluation of the to-be-returned
      expression. In that case we cannot set two return positions for a return
      statement (one before and one after the expression evaluation). This
      sets the interpreter apart from full-codegen.
      
      Make sure that we always have the second of the two return positions.
      
      Note that we end up with separate test cases for ignition and FCG.
      
      R=rmcilroy@chromium.org, vogelheim@chromium.org
      BUG=v8:4690
      LOG=N
      
      Review URL: https://codereview.chromium.org/1801473003
      
      Cr-Commit-Position: refs/heads/master@{#34771}
      3c1dc424
  14. 02 Mar, 2016 1 commit
  15. 23 Feb, 2016 1 commit
  16. 22 Feb, 2016 1 commit
  17. 05 Feb, 2016 1 commit
  18. 04 Feb, 2016 3 commits
  19. 28 Jan, 2016 1 commit