1. 22 Jun, 2016 1 commit
  2. 21 Jun, 2016 5 commits
  3. 10 Jun, 2016 1 commit
  4. 06 Jun, 2016 1 commit
  5. 03 Jun, 2016 2 commits
    • rmcilroy's avatar
      [Interpreter] Move jump processing to bytecode array writer. · de9d1d8b
      rmcilroy authored
      This moves processing of jumps out of bytecode array builder and into
      bytecode array writer. This simplifies the pipeline by avoiding having
      to flush for offset and patch up offsets in bytecode array builder based
      on what was emitted by the bytecode array writer.
      
      This also enables future refactorings to add dead code elimination back
      into the pipeline, and move processing of scalable operand sizes to the
      end of the pipeline (in the bytecode array writer) rather than having to
      deal with scalable operand types throughout pipeline.
      
      BUG=v8:4280,chromium:616064
      
      Review-Url: https://codereview.chromium.org/2035813002
      Cr-Commit-Position: refs/heads/master@{#36716}
      de9d1d8b
    • Miran.Karic's avatar
      Fix bytecode operand type · 16dda215
      Miran.Karic authored
      A value in unittests/Bytecodes.DecodeBytecodeAndOperands was 16 bit
      instead of 8 bit. This was causing test to fail on big endian machines.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2030063002
      Cr-Commit-Position: refs/heads/master@{#36698}
      16dda215
  6. 01 Jun, 2016 1 commit
  7. 27 May, 2016 2 commits
  8. 25 May, 2016 2 commits
  9. 19 May, 2016 1 commit
    • danno's avatar
      [turbofan] Add FixedArray peephole optimizations to CodeStubAssembler · cbdb3738
      danno authored
      Previously, CodeStubAssembler macros performing FixedArray element accesses had
      to compute offsets to elements explicitly with a fair amount of duplicated
      code. Furthermore, any peephole optimizations that could produce better code--
      like recognizing constant indices or combining array index computation with Smi
      untagging--were also duplicated.
      
      This change factors the code to compute FixedArray index offsets into a common
      routine in the CodeStubAssembler that applies standard peephole optimizations to
      all accesses. In order to do this, it also introduces limited introspection into
      the up-until-now opaque Node* type exported from code-assembler.h, allowing
      Nodes to be queried whether they are constant and extracting their constant
      value in that case.
      
      Review-Url: https://codereview.chromium.org/1989363004
      Cr-Commit-Position: refs/heads/master@{#36370}
      cbdb3738
  10. 18 May, 2016 1 commit
  11. 17 May, 2016 3 commits
  12. 12 May, 2016 1 commit
    • oth's avatar
      [interpreter] Introduce bytecode generation pipeline. · 02b7373a
      oth authored
      This change introduces a pipeline for the final stages of
      bytecode generation.
      
      The peephole optimizer is made distinct from the BytecodeArrayBuilder.
      
      A new BytecodeArrayWriter is responsible for writing bytecode. It
      also keeps track of the maximum register seen and offers a potentially
      smaller frame size.
      
      R=rmcilroy@chromium.org
      LOG=N
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/1947403002
      Cr-Commit-Position: refs/heads/master@{#36220}
      02b7373a
  13. 28 Apr, 2016 1 commit
  14. 22 Apr, 2016 5 commits
  15. 19 Apr, 2016 1 commit
  16. 15 Apr, 2016 1 commit
  17. 14 Apr, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Make dispatch table point to code entry instead of code objects. · 0c05e02f
      rmcilroy authored
      Modifies Ignition to store code entry addresses in the dispatch table
      rather than code objects. This allows the interpreter to avoid
      calculating the code entry address from the code object on every
      dispatch and provides a ~5-7% performance improvement on Octane with
      Ignition.
      
      This change adds ArchOpcode::kArchTailCallAddress to TurboFan to enable
      tail call dispatch using these code addresses. It also adds a Dispatch
      linkage creator (distinct from the stub linkage type used previously) to
      allow targetting a code address target (which will diverge further from
      the stub linkage type when we remove the context machine register in
      Ignition).
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1882073002
      
      Cr-Commit-Position: refs/heads/master@{#35480}
      0c05e02f
  18. 13 Apr, 2016 1 commit
    • Miran.Karic's avatar
      Adjust bytecode operand values for big endian. · 3b416c67
      Miran.Karic authored
      Operand values in Bytecodes.DecodeBytecodeAndOperands test are encoded
      in little endian format. The test calls Bytecodes::Decode function which
      reads the operands but the values are byte swapped on big endian
      machines. Added big endian encoded data which decodes correctly on BE
      machines.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1881423002
      
      Cr-Commit-Position: refs/heads/master@{#35447}
      3b416c67
  19. 06 Apr, 2016 1 commit
  20. 05 Apr, 2016 1 commit
  21. 01 Apr, 2016 1 commit
  22. 23 Mar, 2016 1 commit
  23. 22 Mar, 2016 1 commit
  24. 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
  25. 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
  26. 07 Mar, 2016 1 commit
  27. 01 Mar, 2016 1 commit