1. 15 Oct, 2015 5 commits
  2. 13 Oct, 2015 1 commit
  3. 12 Oct, 2015 1 commit
  4. 07 Oct, 2015 1 commit
  5. 06 Oct, 2015 1 commit
  6. 02 Oct, 2015 8 commits
    • rmcilroy's avatar
      [Interpreter] Add CallRuntime support to the interpreter. · 75f6ad74
      rmcilroy authored
      Adds support for calling runtime functions from the interpreter. Adds the
      CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      to enable the interpreter to enter C++ code based on the functionId.
      
      Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      and groups all the interpreter builtins together.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1362383002
      
      Cr-Commit-Position: refs/heads/master@{#31089}
      75f6ad74
    • danno's avatar
      Re-reland: Remove register index/code indirection · 5cf1c0bc
      danno authored
      Previous to this patch, both the lithium and TurboFan register
      allocators tracked allocated registers by "indices", rather than
      the register codes used elsewhere in the runtime. This patch
      ensures that codes are used everywhere, and in the process cleans
      up a bunch of redundant code and adds more structure to how the
      set of allocatable registers is defined.
      
      Some highlights of changes:
      
      * TurboFan's RegisterConfiguration class moved to V8's top level
        so that it can be shared with Crankshaft.
      * Various "ToAllocationIndex" and related methods removed.
      * Code that can be easily shared between Register classes on
        different platforms is now shared.
      * The list of allocatable registers on each platform is declared
        as a list rather than implicitly via the register index <->
        code mapping.
      
      Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      Cr-Commit-Position: refs/heads/master@{#30913}
      
      Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
      Cr-Commit-Position: refs/heads/master@{#31075}
      
      Review URL: https://codereview.chromium.org/1287383003
      
      Cr-Commit-Position: refs/heads/master@{#31087}
      5cf1c0bc
    • danno's avatar
      Revert of Reland: Remove register index/code indirection (patchset #20... · 00e07b00
      danno authored
      Revert of Reland: Remove register index/code indirection (patchset #20 id:380001 of https://codereview.chromium.org/1287383003/ )
      
      Reason for revert:
      Failures on MIPS
      
      Original issue's description:
      > Remove register index/code indirection
      >
      > Previous to this patch, both the lithium and TurboFan register
      > allocators tracked allocated registers by "indices", rather than
      > the register codes used elsewhere in the runtime. This patch
      > ensures that codes are used everywhere, and in the process cleans
      > up a bunch of redundant code and adds more structure to how the
      > set of allocatable registers is defined.
      >
      > Some highlights of changes:
      >
      > * TurboFan's RegisterConfiguration class moved to V8's top level
      >   so that it can be shared with Crankshaft.
      > * Various "ToAllocationIndex" and related methods removed.
      > * Code that can be easily shared between Register classes on
      >   different platforms is now shared.
      > * The list of allocatable registers on each platform is declared
      >   as a list rather than implicitly via the register index <->
      >   code mapping.
      >
      > Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      > Cr-Commit-Position: refs/heads/master@{#30913}
      >
      > Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
      > Cr-Commit-Position: refs/heads/master@{#31075}
      
      TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1380863004
      
      Cr-Commit-Position: refs/heads/master@{#31083}
      00e07b00
    • rmcilroy's avatar
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset... · b4a2f656
      rmcilroy authored
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #8 id:220001 of https://codereview.chromium.org/1362383002/ )
      
      Reason for revert:
      Now breaking arm32 debug bot (worked locally even with --debug-code, so I'll need to figure out what's different on the bot)
      
      Original issue's description:
      > [Interpreter] Add CallRuntime support to the interpreter.
      >
      > Adds support for calling runtime functions from the interpreter. Adds the
      > CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      > and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      > to enable the interpreter to enter C++ code based on the functionId.
      >
      > Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      > and groups all the interpreter builtins together.
      >
      > BUG=v8:4280
      > LOG=N
      >
      
      TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4280
      
      Review URL: https://codereview.chromium.org/1379933003
      
      Cr-Commit-Position: refs/heads/master@{#31078}
      b4a2f656
    • rmcilroy's avatar
      [Interpreter] Add CallRuntime support to the interpreter. · c991d8f3
      rmcilroy authored
      Adds support for calling runtime functions from the interpreter. Adds the
      CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      to enable the interpreter to enter C++ code based on the functionId.
      
      Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      and groups all the interpreter builtins together.
      
      BUG=v8:4280
      LOG=N
      
      Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
      Cr-Commit-Position: refs/heads/master@{#31064}
      
      Review URL: https://codereview.chromium.org/1362383002
      
      Cr-Commit-Position: refs/heads/master@{#31076}
      c991d8f3
    • danno's avatar
      Remove register index/code indirection · 7b7a8205
      danno authored
      Previous to this patch, both the lithium and TurboFan register
      allocators tracked allocated registers by "indices", rather than
      the register codes used elsewhere in the runtime. This patch
      ensures that codes are used everywhere, and in the process cleans
      up a bunch of redundant code and adds more structure to how the
      set of allocatable registers is defined.
      
      Some highlights of changes:
      
      * TurboFan's RegisterConfiguration class moved to V8's top level
        so that it can be shared with Crankshaft.
      * Various "ToAllocationIndex" and related methods removed.
      * Code that can be easily shared between Register classes on
        different platforms is now shared.
      * The list of allocatable registers on each platform is declared
        as a list rather than implicitly via the register index <->
        code mapping.
      
      Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      Cr-Commit-Position: refs/heads/master@{#30913}
      
      Review URL: https://codereview.chromium.org/1287383003
      
      Cr-Commit-Position: refs/heads/master@{#31075}
      7b7a8205
    • rmcilroy's avatar
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset... · 90f69d16
      rmcilroy authored
      Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #6 id:180001 of https://codereview.chromium.org/1362383002/ )
      
      Reason for revert:
      Broke Arm64 bot (CEntry stub is trying to pop arguments off stack when argv_in_reg, so I need to fix this).
      
      Original issue's description:
      > [Interpreter] Add CallRuntime support to the interpreter.
      >
      > Adds support for calling runtime functions from the interpreter. Adds the
      > CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      > and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      > to enable the interpreter to enter C++ code based on the functionId.
      >
      > Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      > and groups all the interpreter builtins together.
      >
      > BUG=v8:4280
      > LOG=N
      >
      > Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
      > Cr-Commit-Position: refs/heads/master@{#31064}
      
      TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4280
      
      Review URL: https://codereview.chromium.org/1387543002
      
      Cr-Commit-Position: refs/heads/master@{#31066}
      90f69d16
    • rmcilroy's avatar
      [Interpreter] Add CallRuntime support to the interpreter. · 40e8424b
      rmcilroy authored
      Adds support for calling runtime functions from the interpreter. Adds the
      CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
      and the arguments in sequential registers. Adds a InterpreterCEntry builtin
      to enable the interpreter to enter C++ code based on the functionId.
      
      Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
      and groups all the interpreter builtins together.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1362383002
      
      Cr-Commit-Position: refs/heads/master@{#31064}
      40e8424b
  7. 01 Oct, 2015 2 commits
  8. 30 Sep, 2015 1 commit
  9. 29 Sep, 2015 1 commit
  10. 28 Sep, 2015 1 commit
  11. 25 Sep, 2015 1 commit
  12. 24 Sep, 2015 6 commits
    • mstarzinger's avatar
      [turbofan] Call ArgumentsAccessStub to materialize arguments. · 9b12ec9a
      mstarzinger authored
      This lowers JSCreateArgument nodes to call the ArgumentsAccessStub for
      help with materializing arguments objects when possible. Along the way
      this changes the calling convention of said stub to take parameters in
      registers instead of on the stack.
      
      R=mvstanton@chromium.org
      
      Review URL: https://codereview.chromium.org/1348773002
      
      Cr-Commit-Position: refs/heads/master@{#30919}
      9b12ec9a
    • danno's avatar
      Revert of Remove register index/code indirection (patchset #17 id:320001 of... · 3ac27431
      danno authored
      Revert of Remove register index/code indirection (patchset #17 id:320001 of https://codereview.chromium.org/1287383003/ )
      
      Reason for revert:
      Failures on greedy RegAlloc, Fuzzer
      
      Original issue's description:
      > Remove register index/code indirection
      >
      > Previous to this patch, both the lithium and TurboFan register
      > allocators tracked allocated registers by "indices", rather than
      > the register codes used elsewhere in the runtime. This patch
      > ensures that codes are used everywhere, and in the process cleans
      > up a bunch of redundant code and adds more structure to how the
      > set of allocatable registers is defined.
      >
      > Some highlights of changes:
      >
      > * TurboFan's RegisterConfiguration class moved to V8's top level
      >   so that it can be shared with Crankshaft.
      > * Various "ToAllocationIndex" and related methods removed.
      > * Code that can be easily shared between Register classes on
      >   different platforms is now shared.
      > * The list of allocatable registers on each platform is declared
      >   as a list rather than implicitly via the register index <->
      >   code mapping.
      >
      > Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
      > Cr-Commit-Position: refs/heads/master@{#30913}
      
      TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1365073002
      
      Cr-Commit-Position: refs/heads/master@{#30914}
      3ac27431
    • danno's avatar
      Remove register index/code indirection · 80bc6f6e
      danno authored
      Previous to this patch, both the lithium and TurboFan register
      allocators tracked allocated registers by "indices", rather than
      the register codes used elsewhere in the runtime. This patch
      ensures that codes are used everywhere, and in the process cleans
      up a bunch of redundant code and adds more structure to how the
      set of allocatable registers is defined.
      
      Some highlights of changes:
      
      * TurboFan's RegisterConfiguration class moved to V8's top level
        so that it can be shared with Crankshaft.
      * Various "ToAllocationIndex" and related methods removed.
      * Code that can be easily shared between Register classes on
        different platforms is now shared.
      * The list of allocatable registers on each platform is declared
        as a list rather than implicitly via the register index <->
        code mapping.
      
      Review URL: https://codereview.chromium.org/1287383003
      
      Cr-Commit-Position: refs/heads/master@{#30913}
      80bc6f6e
    • bmeurer's avatar
      [es6] Introduce spec compliant IsConstructor. · 8fe3ac07
      bmeurer authored
      There was already a bit on the Map named "function with prototype",
      which basically meant that the Map was a map for a JSFunction that could
      be used as a constructor. Now this CL generalizes that bit to
      IsConstructor, which says that whatever (Heap)Object you are looking at
      can be used as a constructor (i.e. the bit is also set for bound
      functions that can be used as constructors and proxies that have a
      [[Construct]] internal method).
      
      This way we have a single chokepoint for IsConstructor checking, which
      allows us to get rid of the various ways in which we tried to guess
      whether something could be used as a constructor or not.
      
      Drive-by-fix: Renamed IsConstructor on FunctionKind to
      IsClassConstructor to resolve the weird name clash, and the
      IsClassConstructor name also matches the spec.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
      R=jarin@chromium.org, rossberg@chromium.org
      BUG=v8:4413, v8:4430
      LOG=n
      
      Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
      Cr-Commit-Position: refs/heads/master@{#30900}
      
      Review URL: https://codereview.chromium.org/1358423002
      
      Cr-Commit-Position: refs/heads/master@{#30902}
      8fe3ac07
    • bmeurer's avatar
      Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001... · 656ebdce
      bmeurer authored
      Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001 of https://codereview.chromium.org/1358423002/ )
      
      Reason for revert:
      Failed on Fuzzer and MIPS bot.
      
      Original issue's description:
      > [es6] Introduce spec compliant IsConstructor.
      >
      > There was already a bit on the Map named "function with prototype",
      > which basically meant that the Map was a map for a JSFunction that could
      > be used as a constructor. Now this CL generalizes that bit to
      > IsConstructor, which says that whatever (Heap)Object you are looking at
      > can be used as a constructor (i.e. the bit is also set for bound
      > functions that can be used as constructors and proxies that have a
      > [[Construct]] internal method).
      >
      > This way we have a single chokepoint for IsConstructor checking, which
      > allows us to get rid of the various ways in which we tried to guess
      > whether something could be used as a constructor or not.
      >
      > Drive-by-fix: Renamed IsConstructor on FunctionKind to
      > IsClassConstructor to resolve the weird name clash, and the
      > IsClassConstructor name also matches the spec.
      >
      > R=jarin@chromium.org, rossberg@chromium.org
      > BUG=v8:4430
      > LOG=n
      >
      > Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
      > Cr-Commit-Position: refs/heads/master@{#30900}
      
      TBR=jarin@chromium.org,rossberg@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4430
      
      Review URL: https://codereview.chromium.org/1360403002
      
      Cr-Commit-Position: refs/heads/master@{#30901}
      656ebdce
    • bmeurer's avatar
      [es6] Introduce spec compliant IsConstructor. · 8de4d935
      bmeurer authored
      There was already a bit on the Map named "function with prototype",
      which basically meant that the Map was a map for a JSFunction that could
      be used as a constructor. Now this CL generalizes that bit to
      IsConstructor, which says that whatever (Heap)Object you are looking at
      can be used as a constructor (i.e. the bit is also set for bound
      functions that can be used as constructors and proxies that have a
      [[Construct]] internal method).
      
      This way we have a single chokepoint for IsConstructor checking, which
      allows us to get rid of the various ways in which we tried to guess
      whether something could be used as a constructor or not.
      
      Drive-by-fix: Renamed IsConstructor on FunctionKind to
      IsClassConstructor to resolve the weird name clash, and the
      IsClassConstructor name also matches the spec.
      
      R=jarin@chromium.org, rossberg@chromium.org
      BUG=v8:4430
      LOG=n
      
      Review URL: https://codereview.chromium.org/1358423002
      
      Cr-Commit-Position: refs/heads/master@{#30900}
      8de4d935
  13. 23 Sep, 2015 3 commits
  14. 22 Sep, 2015 3 commits
    • bmeurer's avatar
      [ic] Introduce BOOLEAN state for CompareIC. · 10c5f2e8
      bmeurer authored
      Slow path for relational comparison of boolean primitive values
      now goes through the runtime, which made the slow path even
      slower than it already was. So in order to repair the regression,
      we just track boolean feedback for comparisons and use that
      to generate decent code in Crankshaft (not the best possible
      code, but good enough for Crankshaft; TurboFan will be able
      to do better on that).
      
      R=jarin@chromium.org
      BUG=chromium:534200
      LOG=n
      
      Review URL: https://codereview.chromium.org/1347063004
      
      Cr-Commit-Position: refs/heads/master@{#30860}
      10c5f2e8
    • bmeurer's avatar
      [x64] Compare map instead of value to heap number map in ToStringStub. · 02a2580b
      bmeurer authored
      Fixes a typo introduced earlier, where we compare the value to heap
      number map instead of the map loaded previously.
      
      TBR=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1355253002
      
      Cr-Commit-Position: refs/heads/master@{#30859}
      02a2580b
    • bmeurer's avatar
      [builtins] Add support for NewTarget to Execution::New. · 1dfac69f
      bmeurer authored
      Introduce new builtins Construct and ConstructFunction (in line
      with the Call and CallFunction builtins that we already have) as
      proper bottleneck for Construct and [[Construct]] on JSFunctions.
      Use these builtins to support passing NewTarget from C++ to
      JavaScript land.
      
      Long-term we want the CallConstructStub to be used for
      gathering feedback on entry to construction chain (i.e. the
      initial new Foo), and use the Construct builtins to do the
      actual work inside the construction chain (i.e. calling into
      super and stuff).
      
      MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      
      R=jarin@chromium.org
      BUG=v8:4430
      LOG=n
      
      Review URL: https://codereview.chromium.org/1359583002
      
      Cr-Commit-Position: refs/heads/master@{#30857}
      1dfac69f
  15. 21 Sep, 2015 1 commit
    • bmeurer's avatar
      [ic] Also collect known map for relational comparison. · e56f265f
      bmeurer authored
      Previously we only collected the known map for equality comparisons. But
      if we also collect it for relational comparisons, we can inline a fast
      path of ToPrimitive on the objects, which is especially interesting
      since both sides have the same map.
      
      For now we only inline a very limited subset of ToPrimitive in
      Crankshaft, which is when the receiver map (and its prototype chain)
      doesn't have @@toPrimitive, and both valueOf and toString are the
      default versions on the %ObjectPrototype%. In this case the relational
      comparison would reduce to a string comparison of "[object CLASS]" with
      itself and so we can reduce that to a boolean constant plus map checks
      on both left and right hand side, plus code dependencies on the
      prototype chain. This repairs the regression on box2d.
      
      R=jkummerow@chromium.org
      BUG=chromium:534200
      LOG=n
      
      Review URL: https://codereview.chromium.org/1355113002
      
      Cr-Commit-Position: refs/heads/master@{#30852}
      e56f265f
  16. 18 Sep, 2015 2 commits
    • bmeurer's avatar
      [stubs] Refactor StringCompareStub and use it for HStringCompareAndBranch. · 8016547c
      bmeurer authored
      The StringCompareStub used to take its parameters on the (JavaScript)
      stack, which made it impossible to use in TurboFan. Actually
      StringCompareStub was currently completely unused. This changes the
      calling convention to something TurboFan compatible and introduces a
      CallInterfaceDescriptor for StringCompareStub. It also changes
      HStringCompareAndBranch to use the StringCompareStub instead of using
      the full blown CompareICStub for a stupid string comparison.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1347913003
      
      Cr-Commit-Position: refs/heads/master@{#30818}
      8016547c
    • bmeurer's avatar
      [runtime] Replace COMPARE/COMPARE_STRONG with proper Object::Compare. · 593c655a
      bmeurer authored
      This removes the weird COMPARE and COMPARE_STRONG JavaScript builtins
      and replaces them with a proper C++ implementation in Object::Compare
      and appropriate wrappers Object::LessThan, Object::GreaterThan, and
      friends that are intended to be used by a true/false returning CompareIC
      in the future, as well as the interpreter.  As a short-term solution we
      provide %Compare and %Compare_Strong entry points for the current
      CompareIC that return the appropriate integer values expected by
      fullcodegen currently.
      
      Now the Abstract Relational Comparison is also using the correct
      ToPrimitive implementation, which properly supports @@toPrimitive.
      
      BUG=v8:4307
      LOG=n
      
      Review URL: https://codereview.chromium.org/1350113002
      
      Cr-Commit-Position: refs/heads/master@{#30816}
      593c655a
  17. 17 Sep, 2015 2 commits