Skip to content

V
V8
Switch branch/tag
  1. 29 Jan, 2016 1 commit
    • jkummerow's avatar
      Introduce {FAST,SLOW}_STRING_WRAPPER_ELEMENTS · f4872f74
      jkummerow authored 
      String wrappers (new String("foo")) are special objects: their string
characters are accessed like elements, and they also have an elements
backing store. This used to require a bunch of explicit checks like:

if (obj->IsJSValue() && JSValue::cast(obj)->value()->IsString()) {
  /* Handle string characters */
}
// Handle regular elements (for string wrappers and other objects)
obj->GetElementsAccessor()->Whatever(...);

This CL introduces new ElementsKinds for string wrapper objects (one for
fast elements, one for dictionary elements), which allow folding the
special-casing into new StringWrapperElementsAccessors.

No observable change in behavior is intended.

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

Cr-Commit-Position: refs/heads/master@{#33616}
      f4872f74
  3. 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
  5. 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
  7. 21 Jan, 2016 2 commits
    • bmeurer's avatar
      [crankshaft] Remove the useless HMapEnumLength instruction. · 441af2e6
      bmeurer authored 
      There's no need to have HMapEnumLength as a dedicated instruction,
as it can be expressed using a HLoadNamedField plus an HBitwiseAnd
operation.

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

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

Cr-Commit-Position: refs/heads/master@{#33439}
      441af2e6
    • bmeurer's avatar
      [for-in] Sanitize for-in optimizations and fix bailout points. · f48bf12f
      bmeurer authored 
      The PrepareId bailout location was used incorrectly in Crankshaft and,
as it turns out, is not required anyway (once you do it right). Also
there was some premature optimization going on with the CheckEnumCache
(trying to load null from roots only once), plus we can be smarter about
the null/undefined check anyway.

The idea behind this changes is to prepare unification of the two
different ForInPrepare implementations that we now have, with the end
result being that we only use the new implementation that was recently
added for the interpreter.

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

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

Cr-Commit-Position: refs/heads/master@{#33426}
      f48bf12f
  9. 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
  11. 19 Jan, 2016 1 commit
  13. 15 Jan, 2016 1 commit
  15. 14 Jan, 2016 1 commit
    • mtrofin's avatar
      [turbofan] avoid xchg instruction on Intel · 7440edae
      mtrofin authored 
      On Intel, xchg stalls the pipeline. We use xchg to implement swap
moves. In a separate exploration, the presence of xchg in a very hot
loop, due to a change in register allocation, lead to over 20% regression.

Simply changing that instruction with push/mov/pop (almost) eliminated
the regression.

In light of that, I removed uses of xchg. This leads to more instructions,
though. That is particularly problematic for long cycles, which, today,
we translate to successions of swaps.

I plan to address this cycle issue in a separate change. For now, the
goal is to unblock the initial work that lead here.

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

Cr-Commit-Position: refs/heads/master@{#33282}
      7440edae
  17. 12 Jan, 2016 4 commits
  19. 30 Dec, 2015 1 commit
  21. 17 Dec, 2015 1 commit
    • Benedikt Meurer's avatar
      [runtime] Drop FIRST/LAST_NONCALLABLE_SPEC_OBJECT instance type range. · aafc3e54
      Benedikt Meurer authored 
      The FIRST-LAST_NONCALLABLE_SPEC_OBJECT_TYPE range was accidentially used
in field type tracking, where we should check for JSReceiver instead
(there's no need to exclude JSProxy or JSFunction from tracking).

And the use in %_ClassOf was actually wrong and didn't match the C++
implementation in JSReceiver::class_name() anymore. Now it's consistent
again.

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

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

Cr-Commit-Position: refs/heads/master@{#32926}
      aafc3e54
  23. 16 Dec, 2015 1 commit
  25. 11 Dec, 2015 1 commit
  27. 07 Dec, 2015 1 commit
  29. 04 Dec, 2015 2 commits
  31. 03 Dec, 2015 1 commit
  33. 01 Dec, 2015 1 commit
  35. 30 Nov, 2015 2 commits
  37. 27 Nov, 2015 3 commits
  39. 26 Nov, 2015 1 commit
  41. 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
  43. 24 Nov, 2015 1 commit
  45. 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
  47. 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
  49. 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
  51. 05 Nov, 2015 2 commits
  53. 02 Nov, 2015 1 commit
  55. 22 Oct, 2015 2 commits
  57. 20 Oct, 2015 1 commit