Skip to content

V
V8
Switch branch/tag
  1. 24 Feb, 2016 1 commit
  3. 18 Feb, 2016 1 commit
  5. 17 Feb, 2016 5 commits
  7. 16 Feb, 2016 1 commit
  9. 11 Feb, 2016 1 commit
  11. 10 Feb, 2016 1 commit
    • verwaest's avatar
      Mark null and undefined as undetectable, and use it to handle abstract... · 3ce9e808
      verwaest authored 
      Mark null and undefined as undetectable, and use it to handle abstract equality comparison in the generic compare ic

Marking as undetectable makes abstract equality of null, undefined, and
other undetectable objects easier. Supporting it in the generic compare
IC significantly speeds up dynamic comparison between those values and
JSReceivers by not falling back to the runtime.

MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>

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

Cr-Commit-Position: refs/heads/master@{#33858}
      3ce9e808
  13. 09 Feb, 2016 1 commit
    • bmeurer's avatar
      [intrinsics] Kill the %_IsMinusZero intrinsic. · 00f7d1f5
      bmeurer authored 
      By now only the default %TypedArray%.prototype.sort compare function
and the JS implementation of SameValueZero were still using the odd
%_IsMinusZero intrinsic, whose semantics both included a number check
(actually HeapNumber test) plus testing if the heap number stores the
special -0 value. In both cases we already know that we deal with
number so we can reduce it to a simple number test for -0, which can
be expressed via dividing 1 by that value and checking the sign of
the result. In case of the compare function, we can be even smarter
and work with the reciprocal values in case x and y are equal to 0
(although long term we should probably rewrite the fast case for
the typed array sorting function in C++ anyway, which will be way,
way faster than our handwritten callback-style, type-feedback
polluted JS implementation).

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33833}
      00f7d1f5
  15. 08 Feb, 2016 1 commit
    • mstarzinger's avatar
      Remove --stop-at flag from several backends. · 664110f8
      mstarzinger authored 
      The flag in question is a debug-only flag supported by full-codegen and
Crankshaft only. In it's current form there are some unresolved issues:
- The flag is defeated by inlining in Crankshaft.
- The flag is not supported by TurboFan.
- The flag is not supported by Ignition.

Instead of addressing the above issues and increasing maintenance cost
for all backends and also given the "slim" test coverage, this CL fully
removes the support from all backends.

R=bmeurer@chromium.org,jkummerow@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33817}
      664110f8
  17. 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
  19. 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
  21. 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
  23. 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
  25. 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
  27. 19 Jan, 2016 1 commit
  29. 15 Jan, 2016 1 commit
  31. 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
  33. 12 Jan, 2016 4 commits
  35. 30 Dec, 2015 1 commit
  37. 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
  39. 16 Dec, 2015 1 commit
  41. 11 Dec, 2015 1 commit
  43. 07 Dec, 2015 1 commit
  45. 04 Dec, 2015 2 commits
  47. 03 Dec, 2015 1 commit
  49. 01 Dec, 2015 1 commit
  51. 30 Nov, 2015 2 commits
  53. 27 Nov, 2015 3 commits
  55. 26 Nov, 2015 1 commit