Skip to content

V
V8
Switch branch/tag
  1. 26 Jan, 2016 1 commit
    • ishell's avatar
      [es6] Tail calls support. · 6131ab1e
      ishell authored 
      This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
When debugger is active tail calls are disabled.

Tail calling can be enabled by --harmony-tailcalls flag.

BUG=v8:4698
LOG=Y
TBR=rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33509}
      6131ab1e
  3. 25 Jan, 2016 1 commit
    • bmeurer's avatar
      [for-in] Further refactorings and unification around for-in. · 88f9995d
      bmeurer authored 
      Cleanup %ForInPrepare runtime entry, and unify common logic with
%ForInEnumerate (renamed from %GetPropertyNamesFast). Also introduce
a TupleType to properly type JSForInPrepare and its projections w/o
special hacks in the Typer. And fix %ForInNext and JSForInNext to be
consistent with fullcodegen again (after the proxy refactorings last
quarter).

R=jarin@chromium.org
BUG=v8:3650
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33487}
      88f9995d
  5. 21 Jan, 2016 3 commits
  7. 20 Jan, 2016 1 commit
    • danno's avatar
      [compiler] Remove CodeStub from CompilationInfo · d1d01964
      danno authored 
      The motivation for this is that CompilationInfo really shouldn't
explicitly know anything about CodeStubs. This is evident in
the TurboFan stubs pipeline, which only needs to pass down
information about Code::Flags to the code generator and not
any of the CallInterfaceDescriptor silliness that Hydrogen has
to push around, since TF has the Linkage class that
encapsulates everything that is needed for the stub ABI. So,
instead of threading CodeStub machinery through the TF stub
pipeline, it is now removed from CompilationInfo and replaced
by only the explicit bits needed both by the Crankshaft and
TF pipelines in code generation.

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

Cr-Commit-Position: refs/heads/master@{#33410}
      d1d01964
  9. 15 Jan, 2016 1 commit
  11. 12 Jan, 2016 4 commits
  13. 30 Dec, 2015 1 commit
  15. 17 Dec, 2015 2 commits
  17. 16 Dec, 2015 1 commit
  19. 11 Dec, 2015 1 commit
  21. 07 Dec, 2015 1 commit
  23. 04 Dec, 2015 2 commits
  25. 03 Dec, 2015 1 commit
  27. 01 Dec, 2015 1 commit
  29. 30 Nov, 2015 2 commits
  31. 27 Nov, 2015 3 commits
  33. 26 Nov, 2015 1 commit
  35. 25 Nov, 2015 1 commit
    • bmeurer's avatar
      [runtime] First step to sanitize regexp literal creation. · 09b44428
      bmeurer authored 
      This is the initial step towards refactoring the regexp literation
creation code to make it less obscure and more similar to the mechanism
we use to create array and object literals.  There's now a new runtime
entry %CreateRegExpLiteral with the same interface as the entries for
array and object literals, except that we still pass the flags as
string.

Instead of embedding the hand written native to clone JSRegExp instances
we now have a FastCloneRegExpStub, which behaves similar to the other
FastCloneShallowArrayStub and FastCloneShallowObjectStub that we already
had.

R=mlippautz@chromium.org, yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#32255}
      09b44428
  37. 24 Nov, 2015 1 commit
  39. 23 Nov, 2015 1 commit
    • bmeurer's avatar
      [builtins] Sanitize the machinery around Construct calls. · 374b6ea2
      bmeurer authored 
      There's no point in collecting feedback for super constructor calls,
because in all (interesting) cases we can gather (better) feedback from
other sources (i.e. via inlining or via using a LOAD_IC to get to the
[[Prototype]] of the target).  So CallConstructStub is now only used
for new Foo(...args) sites where we want to collect feedback in the
baseline compiler.  The optimizing compilers, Reflect.construct and
super constructor calls use the Construct builtin directly, which allows
us to remove some weird code from the CallConstructStub (and opens the
possibility for more code sharing with the CallICStub, maybe even going
for a ConstructICStub).

Also remove the 100% redundant HCallNew instruction, which is just a
wrapper for the Construct builtin anyway (indirectly via the
CallConstructStub).

Drive-by-fix: Drop unused has_function_cache bit on Code objects.

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

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

Cr-Commit-Position: refs/heads/master@{#32172}
      374b6ea2
  41. 19 Nov, 2015 1 commit
    • mstarzinger's avatar
      [crankshaft] Pass new.target to direct function calls. · e2bce9d3
      mstarzinger authored 
      This changes all direct function calls in Crankshaft to pass undefined
via the register expected to hold the new.target value. Note that the
register is still ignored by all callees for now.

This is a preparatory CL to allows us passing new.target in a register
instead of via a side-channel through the construct stub frame.

R=bmeurer@chromium.org
BUG=v8:4544
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32125}
      e2bce9d3
  43. 16 Nov, 2015 1 commit
  45. 09 Nov, 2015 2 commits
    • bmeurer's avatar
      [runtime] Drop redundant %CharFromCode runtime entry. · 2b4cb2a1
      bmeurer authored 
      The %StringCharFromCode and %CharFromCode runtime function perform
exactly the same task, so we need only one of them.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#31873}
      2b4cb2a1
    • bmeurer's avatar
      [builtins] Introduce specialized Call/CallFunction builtins. · 7c3396d0
      bmeurer authored 
      Introduce receiver conversion mode specialization for the Call and
CallFunction builtins, so we can specialize the builtin functionality
(actually an optimization only) based on static information from the
callsite (this is basically a superset of the optimizations that were
available with the CallFunctionStub and CallICStub, except that these
optimizations are correct now).

This fixes a regression introduced by the removal of CallFunctionStub,
for programs that call a lot.

R=yangguo@chromium.org
BUG=chromium:552244
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31871}
      7c3396d0
  47. 05 Nov, 2015 2 commits
  49. 02 Nov, 2015 1 commit
  51. 22 Oct, 2015 2 commits
  53. 20 Oct, 2015 1 commit