Skip to content

V
V8
Switch branch/tag
  1. 11 Jan, 2017 1 commit
  3. 29 Dec, 2016 2 commits
  5. 22 Dec, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Lower StringCharCodeAt to a dedicated builtin. · 86e2a199
      bmeurer authored 
      Introduce a dedicated StringCharCodeAt builtin, that performs the core
logic of String.prototype.charCodeAt and lower the StringCharCodeAt
simplified operator to a call to this builtin rather than inlining the
full functionality into each and every TurboFan graph using it. This can
significantly reduce compile time in some cases (i.e. can easily shave
off over 50% of compile time overhead for small functions that call
String.prototype.charCodeAt).

Currently it returns the char code as TaggedSigned value, but
middle-term we should make it possible to return untagged values
from builtins.

R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2600443002
Cr-Commit-Position: refs/heads/master@{#41912}
      86e2a199
    • bmeurer's avatar
      [turbofan] Introduce a dedicated StringCharAt operator. · 05f5ebce
      bmeurer authored 
      Previously String element access and String.prototype.charAt were
lowered to a subgraph StringFromCharCode(StringCharCodeAt(s, k)),
however that can be fairly expensive both runtime and compile time
wise. The dedicated StringCharAt operator is implemented via a call
to a builtin that does exactly this.

R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2599683002
Cr-Commit-Position: refs/heads/master@{#41909}
      05f5ebce
  7. 20 Dec, 2016 1 commit
    • littledan's avatar
      Use a different map to distinguish eval contexts · 53fdf9d1
      littledan authored 
      eval() may introduce a scope which needs to be represented as a context at
runtime, e.g.,

  eval('var x; let y; ()=>y')

introduces a variable y which needs to have a context allocated for it. However,
when traversing upwards to find the declaration context for a variable which leaks,
as the declaration of x does above, this context has to be understood to not be
a declaration context in sloppy mode.

This patch makes that distinction by introducing a different map for eval-introduced
contexts. A dynamic search for the appropriate context will continue past an eval
context to find the appropriate context. Marking contexts as eval contexts rather
than function contexts required updates in each compiler backend.

BUG=v8:5295, chromium:648719

Review-Url: https://codereview.chromium.org/2435023002
Cr-Commit-Position: refs/heads/master@{#41869}
      53fdf9d1
  9. 19 Dec, 2016 1 commit
  11. 15 Dec, 2016 1 commit
  13. 13 Dec, 2016 1 commit
    • gsathya's avatar
      PromiseHandle port to TF · 9fc3c017
      gsathya authored 
      Splits PromiseHandle into two TF builtins to account for catch
prediction. An exception in PromiseHandleReject builtin results in a
"caught" prediction whereas an expception in PromiseHandle results in a
"promise rejection" prediction.

An extra is_exception_caught bit is added to Code to mark this catch
prediction behavior.

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2572623002
Cr-Commit-Position: refs/heads/master@{#41683}
      9fc3c017
  15. 08 Dec, 2016 1 commit
  17. 01 Dec, 2016 1 commit
  19. 29 Nov, 2016 1 commit
  21. 18 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Properly optimize instanceof (even in the presence of @@hasInstance). · 241c024c
      bmeurer authored 
      This is the TurboFan counterpart of http://crrev.com/2504263004, but it
is a bit more involved, since in TurboFan we always inline the appropriate
call to the @@hasInstance handler, and by that we can optimize a lot more
patterns of instanceof than Crankshaft, and even yield fast instanceof
for custom @@hasInstance handlers (which we can now properly inline as
well).

Also we now properly optimize Function.prototype[@@hasInstance], even if
the right hand side of an instanceof doesn't have the Function.prototype
as its direct prototype.

For the baseline case, we still rely on the global protector cell, but
we can address that in a follow-up as well, and make it more robust in
general.

TEST=mjsunit/compiler/instanceof
BUG=v8:5640
R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2511223003
Cr-Commit-Position: refs/heads/master@{#41092}
      241c024c
  23. 07 Nov, 2016 1 commit
  25. 25 Oct, 2016 1 commit
    • jgruber's avatar
      [regexp] Remove unused code · 77ddcfb3
      jgruber authored 
      This CL removes code that is now unused since the port of regexp.js has been
completed. Removed functions / classes are:

* regexp.js (GetSubstitution moved to string.js)
* RegExpConstructResult stub
* RegExpFlags intrinsic
* RegExpSource intrinsic
* RegExpInitializeAndCompile runtime function

BUG=v8:5339

Review-Url: https://codereview.chromium.org/2448463002
Cr-Commit-Position: refs/heads/master@{#40547}
      77ddcfb3
  27. 19 Oct, 2016 1 commit
  29. 17 Oct, 2016 1 commit
  31. 12 Oct, 2016 1 commit
  33. 08 Sep, 2016 1 commit
  35. 02 Sep, 2016 1 commit
  37. 08 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add initial support for growing stores. · e6822a83
      bmeurer authored 
      Introduce a dedicated MaybeGrowFastElements simplified operator, which
tries to grow a fast elements backing store for a given element that
should be added to an array/object. Use that to lower a growing keyed
store to a sequence of

 1) check index is a valid array index,
 2) check stored value,
 3) maybe grow elements backing store (and deoptimize if it would
    normalize), and
 4) store the actual element.

The actual growing is done by two dedicated GrowFastDoubleElements
and GrowFastSmiOrObjectElements builtins, which are very similar to
the GrowArrayElementsStub that is used by Crankshaft.

Drive-by-fix: Turn CopyFixedArray into CopyFastSmiOrObjectElements
builtin, similar to the new growing builtins, so we don't need to
inline the store+write barrier for the elements into all optimized
code objects anymore.

Also fix a bug in the OperationTyper for NumberSilenceNaN, which was
triggered by this change.

BUG=v8:5272

Review-Url: https://codereview.chromium.org/2227493002
Cr-Commit-Position: refs/heads/master@{#38418}
      e6822a83
  39. 05 Aug, 2016 5 commits
  41. 01 Aug, 2016 1 commit
  43. 26 Jul, 2016 4 commits
  45. 21 Jul, 2016 1 commit
  47. 19 Jul, 2016 2 commits
  49. 14 Jul, 2016 1 commit
  51. 13 Jul, 2016 1 commit
  53. 30 Jun, 2016 1 commit
  55. 28 Jun, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce Float64Pow and NumberPow operators. · e607e12e
      bmeurer authored 
      Introduce a new machine operator Float64Pow that for now is backed by
the existing MathPowStub to start the unification of Math.pow, and at
the same time address the main performance issue that TurboFan still has
with the imaging-darkroom benchmark in Kraken.

Also migrate the Math.pow builtin itself to a TurboFan builtin and
remove a few hundred lines of hand-written platform code for special
handling of the fullcodegen Math.pow version.

BUG=v8:3599,v8:5086,v8:5157

Review-Url: https://codereview.chromium.org/2103733003
Cr-Commit-Position: refs/heads/master@{#37323}
      e607e12e
  57. 22 Jun, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Add intrinsics called as stubs. · 485e7751
      rmcilroy authored 
      Adds support for intrinsics which can be called as stubs. Namely:
 - HasProperty
 - MathPow
 - NewObject
 - NumberToString
 - RegExpConstructResult
 - RegExpExec
 - Substring
 - ToString
 - ToName
 - ToLength
 - ToNumber
 - ToObject

Also adds interface descriptors for stub calls which have arguments
passed on the stack.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/2051573002
Cr-Commit-Position: refs/heads/master@{#37185}
      485e7751
  59. 14 Jun, 2016 1 commit
    • ishell's avatar
      [ic] Split LoadIC into LoadGlobalIC and LoadIC. · d9e8764f
      ishell authored 
      The former will handle loads of predeclared global variables (vars and
functions), lets, consts and undeclared variables. The latter will handle
named loads from explicit receiver. In addition, named loads does not
depend of the TypeofMode.

TypeofMode related cleanup will be done in the follow-up CL.

BUG=chromium:576312
LOG=Y
TBR=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/1912633002
Cr-Commit-Position: refs/heads/master@{#36965}
      d9e8764f