Skip to content

V
V8
Switch branch/tag
  1. 29 Oct, 2015 1 commit
  3. 26 Oct, 2015 3 commits
  5. 22 Oct, 2015 2 commits
  7. 20 Oct, 2015 1 commit
  9. 19 Oct, 2015 1 commit
  11. 16 Oct, 2015 1 commit
  13. 15 Oct, 2015 3 commits
  15. 13 Oct, 2015 1 commit
  17. 12 Oct, 2015 1 commit
  19. 07 Oct, 2015 1 commit
  21. 06 Oct, 2015 1 commit
  23. 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
  25. 01 Oct, 2015 2 commits
  27. 30 Sep, 2015 1 commit
  29. 29 Sep, 2015 2 commits
  31. 28 Sep, 2015 1 commit
  33. 25 Sep, 2015 1 commit
  35. 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
  37. 23 Sep, 2015 2 commits
    • bmeurer's avatar
      [runtime] Remove weird pushing of something on StackOverflow. · 556b522a
      bmeurer authored 
      We somehow try to push some stuff on the stack when we detect a stack
overflow, that we don't need. Even worse we might access outside the
valid stack bounds. Since we don't need this, it's gone.

CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=jarin@chromium.org
BUG=chromium:534881
LOG=n

Review URL: https://codereview.chromium.org/1360953003

Cr-Commit-Position: refs/heads/master@{#30883}
      556b522a
    • bmeurer's avatar
      [builtin] Refactor Invoke to deal with any kind of callable. · 634d1d86
      bmeurer authored 
      Now both Execution::Call and Execution::New can deal with any
kind of target and will raise a proper exception if the target is not
callable (which is not yet spec compliant for New, as we would
have to check IsConstructor instead, which we don't have yet).

Now we no longer need to do any of these weird call/construct
delegate gymnastics in C++, and we finally have a single true
bottleneck for Call/Construct abstract operations in the code
base, with only a few special handlings left in the compilers to
optimize the JSFunction case.

R=jarin@chromium.org
BUG=v8:4430, v8:4413
LOG=n

Review URL: https://codereview.chromium.org/1360793002

Cr-Commit-Position: refs/heads/master@{#30874}
      634d1d86
  39. 22 Sep, 2015 1 commit
    • 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