1. 02 Feb, 2016 1 commit
    • jarin's avatar
      Remove the template magic from types.(h|cc), remove types-inl.h. · ef35f11c
      jarin authored
      This CL removes the Config templatization from the types. It is not
      necessary anymore, after the HeapTypes have been removed.
      
      The CL also changes the type hierarchy - the specific type kinds are
      not inner classes of the Type class and they do not inherit from Type.
      This is partly because it seems impossible to make this work without
      templates. Instead, a new TypeBase class is introduced and all the
      structural (i.e., non-bitset) types inherit from it.
      
      The bitset type still requires the bit-munging hack and some nasty
      reinterpret-casts to pretend bitsets are of type Type*. Additionally,
      there is now the same hack for TypeBase - all pointers to the sub-types
      of TypeBase are reinterpret-casted to Type*. This is to keep the type
      constructors in inline method definitions (although it is unclear how
      much that actually buys us).
      
      In future, we would like to move to a model where we encapsulate Type*
      into a class (or possibly use Type where we used to use Type*). This
      would loosen the coupling between bitset size and pointer size, and
      eventually we would be able to have more bits.
      
      TBR=bradnelson@chromium.org
      
      Review URL: https://codereview.chromium.org/1655833002
      
      Cr-Commit-Position: refs/heads/master@{#33656}
      ef35f11c
  2. 29 Jan, 2016 3 commits
    • ahaas's avatar
      [turbofan] Add the StackSlot operator to turbofan. · 64588037
      ahaas authored
      The StackSlot operator allows to allocate a spill slot on the stack. We
      are going to use this operator to pass floats through pointers to c
      functions, which we need for floating point rounding in the case where
      the architecture does not provide rounding instructions.
      
      R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
      
      Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223
      Cr-Commit-Position: refs/heads/master@{#33600}
      
      Review URL: https://codereview.chromium.org/1645653002
      
      Cr-Commit-Position: refs/heads/master@{#33606}
      64588037
    • ahaas's avatar
      Revert of [turbofan] Add the StackSlot operator to turbofan. (patchset #4... · 11f7c2e6
      ahaas authored
      Revert of [turbofan] Add the StackSlot operator to turbofan. (patchset #4 id:60001 of https://codereview.chromium.org/1645653002/ )
      
      Reason for revert:
      problems on Mac64
      
      Original issue's description:
      > [turbofan] Add the StackSlot operator to turbofan.
      >
      > The StackSlot operator allows to allocate a spill slot on the stack. We
      > are going to use this operator to pass floats through pointers to c
      > functions, which we need for floating point rounding in the case where
      > the architecture does not provide rounding instructions.
      >
      > R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
      >
      > Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223
      > Cr-Commit-Position: refs/heads/master@{#33600}
      
      TBR=titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1644283002
      
      Cr-Commit-Position: refs/heads/master@{#33601}
      11f7c2e6
    • ahaas's avatar
      [turbofan] Add the StackSlot operator to turbofan. · 7a693437
      ahaas authored
      The StackSlot operator allows to allocate a spill slot on the stack. We
      are going to use this operator to pass floats through pointers to c
      functions, which we need for floating point rounding in the case where
      the architecture does not provide rounding instructions.
      
      R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
      
      Review URL: https://codereview.chromium.org/1645653002
      
      Cr-Commit-Position: refs/heads/master@{#33600}
      7a693437
  3. 28 Jan, 2016 2 commits
  4. 27 Jan, 2016 4 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of... · a7027851
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )
      
      Reason for revert:
      Bug: failing to use write barrier when writing code entry into closure.
      
      Original issue's description:
      > Reland of Type Feedback Vector lives in the closure
      >
      > (Fixed a bug found by nosnap builds.)
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      >
      > TBR=hpayer@chromium.org
      > BUG=
      >
      > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
      > Cr-Commit-Position: refs/heads/master@{#33548}
      
      TBR=bmeurer@chromium.org,yangguo@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1643533003
      
      Cr-Commit-Position: refs/heads/master@{#33556}
      a7027851
    • mvstanton's avatar
      Reland of Type Feedback Vector lives in the closure · d984b3b0
      mvstanton authored
      (Fixed a bug found by nosnap builds.)
      
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      
      TBR=hpayer@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1642613002
      
      Cr-Commit-Position: refs/heads/master@{#33548}
      d984b3b0
    • oth's avatar
      [interpreter] Reduce move operations for wide register support. · 95bec7e7
      oth authored
      Introduces the concept of transfer direction to register operands. This
      enables the register translator to emit exactly the moves that a
      bytecode having it's register operands translated needs.
      
      BUG=v8:4280,v8:4675
      LOG=N
      
      Review URL: https://codereview.chromium.org/1633153002
      
      Cr-Commit-Position: refs/heads/master@{#33544}
      95bec7e7
    • titzer's avatar
      [wasm] Factor out WasmModuleInstance from ModuleEnv. · 1e1f72f3
      titzer authored
      R=ahaas@chromium.org,bradnelson@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1637923002
      
      Cr-Commit-Position: refs/heads/master@{#33541}
      1e1f72f3
  5. 26 Jan, 2016 3 commits
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of... · e2e7dc32
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )
      
      Reason for revert:
      FAilure on win32 bot, need to investigate webkit failures.
      
      Original issue's description:
      > Type Feedback Vector lives in the closure
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      >
      > TBR=hpayer@chromium.org
      >
      > BUG=
      >
      > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
      > Cr-Commit-Position: refs/heads/master@{#33518}
      
      TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1632993003
      
      Cr-Commit-Position: refs/heads/master@{#33520}
      e2e7dc32
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · a5200f7e
      mvstanton authored
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      
      TBR=hpayer@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1563213002
      
      Cr-Commit-Position: refs/heads/master@{#33518}
      a5200f7e
    • oth's avatar
      [interpreter] Wide register support. · 19df7a20
      oth authored
      This increases the size of register operands to be 16-bit.
      
      Not all bytecodes have wide register variants, so when they are
      needed a register translator will copy them into a small area
      reserved at the top of the 8-bit register range and these registers
      are supplied as arguments to the bytecode with 8-bit operands.
      
      This is non-intrusive for typical bytecode where the number of
      registers is less than 120. For bytecodes with wide register
      operands (above the window) their index needs to be translated
      to avoid the reserved translation window.
      
      Enables splay.js to run in Octane and a handful of mjsunit tests.
      
      BUG=v8:4280,v8:4675
      LOG=NO
      
      Review URL: https://codereview.chromium.org/1613163002
      
      Cr-Commit-Position: refs/heads/master@{#33516}
      19df7a20
  6. 25 Jan, 2016 3 commits
  7. 23 Jan, 2016 1 commit
  8. 22 Jan, 2016 1 commit
  9. 20 Jan, 2016 3 commits
  10. 19 Jan, 2016 1 commit
    • oth's avatar
      [Interpreter] Preparation for wide registers. · 68654b64
      oth authored
      o Adds wide variants of bytecodes that have operands describing ranges
        of registers. The upcoming wide register support does not suppport
        re-mapping ranges.
      o Adds kRegPair16 and kRegTriple16 operands required for new wide
        bytecodes and renames Count8/Count16 operands to RegCount8/RegCount16.
      o Removes Exchange bytecodes
      
      BUG=v8:4675
      LOG=NO
      
      Review URL: https://codereview.chromium.org/1595103006
      
      Cr-Commit-Position: refs/heads/master@{#33389}
      68654b64
  11. 18 Jan, 2016 1 commit
  12. 14 Jan, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Ensure we always have an outer register allocation scope. · ef21fb2d
      rmcilroy authored
      Split RegisterAllocationScope out of ExpressionResult and allocate one
      for each statement. This ensures that we always have an outer register
      allocation scope for statement code (used in CountOperation and
      RegisterExecutionResult). Also refactored the register allocator code to
      move it to it's own file and rename from TemporaryRegisterScope to
      BytecodeRegisterAllocator.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1587033002
      
      Cr-Commit-Position: refs/heads/master@{#33296}
      ef21fb2d
  13. 13 Jan, 2016 1 commit
  14. 12 Jan, 2016 1 commit
  15. 11 Jan, 2016 2 commits
  16. 08 Jan, 2016 2 commits
    • rmcilroy's avatar
      [Interpreter] Add support for calling runtime functions which return a pair. · 1a063d94
      rmcilroy authored
      Adds support for calling runtime functions which return a pair of
      values. Adds the bytecode CallRuntimePair. Also adds support to TurboFan
      for calling stubs which return multiple values.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1568493002
      
      Cr-Commit-Position: refs/heads/master@{#33181}
      1a063d94
    • dtc-v8's avatar
      WASM: Reserve an ignored section for source code meta information. · 0427d9ff
      dtc-v8 authored
      Requesting reservation of a wasm section for experimentation with
      storing source code meta information, such as source code comments,
      and also extra inform on presentation of the AST such an `if-block`
      pattern being presented as a `when` operation.
      
      The wasm design already defines unrecognized sections to be ignored,
      and this reserved section is ignored. This section is only intended to
      hold source code meta information and to have no effect on code
      execution.
      
      With wasm going live (behind a flag) on v8, I would also like to be
      able to give people something to play with in terms of the deployed
      binary code being a useful source code. It's all experimental, but I
      understand the entire binary format that V8 is currently using is
      basically a throwaway, and that the working strategy is to get
      something running and then revisit format decisions.
      
      I would like a fixed reserved section number to avoid potential
      clashes with other projects - although I am not aware of any other
      calls for addition sections beyond the need for debug info. If a fixed
      number is not acceptable, then could this patch alternatively ignore
      all unrecognized sections and perhaps add the section size to them
      all - something which is already noted todo in the design document?
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1565693002
      
      Cr-Commit-Position: refs/heads/master@{#33165}
      0427d9ff
  17. 05 Jan, 2016 6 commits
  18. 04 Jan, 2016 1 commit
  19. 27 Dec, 2015 2 commits
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · 97def807
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      Cr-Commit-Position: refs/heads/master@{#33042}
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33044}
      97def807
    • bmeurer's avatar
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound... · 1cf8b105
      bmeurer authored
      Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ )
      
      Reason for revert:
      Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
      
      Original issue's description:
      > [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
      >
      > According to the ES2015 specification, bound functions are exotic
      > objects, and thus don't need to be implemented as JSFunctions. So
      > we introduce a new JSBoundFunction type to represent bound functions
      > and make them optimizable. This already improves the performance of
      > calling or constructing bound functions by 10-100x depending on the
      > use case because we avoid the crazy dance between JavaScript and C++
      > that was implemented in v8natives.js previously.
      >
      > There's still room for improvement in the performance of actually
      > creating bound functions, which is also relevant in practice, but
      > we already have a plan how to accomplish that later.
      >
      > The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      >
      > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      > BUG=chromium:535408, chromium:571299, v8:4629
      > LOG=n
      >
      > Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
      > Cr-Commit-Position: refs/heads/master@{#33042}
      
      TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:535408, chromium:571299, v8:4629
      
      Review URL: https://codereview.chromium.org/1552473002
      
      Cr-Commit-Position: refs/heads/master@{#33043}
      1cf8b105
  20. 26 Dec, 2015 1 commit
    • bmeurer's avatar
      [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · ca8623ea
      bmeurer authored
      According to the ES2015 specification, bound functions are exotic
      objects, and thus don't need to be implemented as JSFunctions. So
      we introduce a new JSBoundFunction type to represent bound functions
      and make them optimizable. This already improves the performance of
      calling or constructing bound functions by 10-100x depending on the
      use case because we avoid the crazy dance between JavaScript and C++
      that was implemented in v8natives.js previously.
      
      There's still room for improvement in the performance of actually
      creating bound functions, which is also relevant in practice, but
      we already have a plan how to accomplish that later.
      
      The mips/mips64 ports were contributed by akos.palfi@imgtec.com.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=chromium:535408, chromium:571299, v8:4629
      LOG=n
      
      Review URL: https://codereview.chromium.org/1542963002
      
      Cr-Commit-Position: refs/heads/master@{#33042}
      ca8623ea