Skip to content

V
V8
Switch branch/tag
  1. 02 Feb, 2017 1 commit
  3. 27 Jan, 2017 1 commit
  5. 25 Jan, 2017 1 commit
    • zhengxing.li's avatar
      X87: [TypeFeedbackVector] DeclareGlobals needs a literals array. · f223d4f5
      zhengxing.li authored 
        port d287c819 (r42620)

  original commit message:
  [RELAND with one change: until literal arrays are rooted in the outer
  feedback vector (coming in the next days), the runtime-scope.cc change
  is held off.]

  When a function is declared in global scope, the closure is created
  by the DeclareGlobals runtime service. It needs a pointer to the
  literals array, already allocated in the feedback vector. This
  fixes a bug where it's behavior wasn't in sync with CreateClosure,
  which accepts the literals from the vector.

  This enables a follow-on performance improvement in the CompileLazy
  builtin.

BUG=

Review-Url: https://codereview.chromium.org/2653893002
Cr-Commit-Position: refs/heads/master@{#42641}
      f223d4f5
  7. 18 Jan, 2017 1 commit
  9. 16 Jan, 2017 1 commit
  11. 11 Jan, 2017 1 commit
    • rmcilroy's avatar
      [compiler] Collect eager inner functions for compilation during renumbering. · a3052cfe
      rmcilroy authored 
      This CL modifies the ast-numbering phase to collect function literals which
should be compiled eagerly. This is then used to eagerly compile the inner
functions before compiling the outer function. This will be used to queue
compilation jobs on the CompilerDispatcher in a later CL.

This CL moves the compilation of eager inner functions out of the
GetSharedFunctionInfo function and instead compiles them explicitly. This
simplifies GetSharedFunctionInfo and also means there is no need to pass a
LazyCompilationMode to the function, so this concept has been removed.

BUG=v8:5203,v8:5215

Review-Url: https://codereview.chromium.org/2618553004
Cr-Commit-Position: refs/heads/master@{#42221}
      a3052cfe
  13. 09 Jan, 2017 2 commits
  15. 06 Jan, 2017 1 commit
  17. 05 Jan, 2017 1 commit
    • gsathya's avatar
      [ESnext] Implement Object spread · a40b7172
      gsathya authored 
      This patch adds parsing of spread object property.

-- Changes ParsePropertyName to parse Token::ELLIPSIS.
-- Throws if rest is encountered by setting a pattern error.
-- Adds a new PropertyKind enum (SPREAD)
-- Adds a new ObjectLiteralProperty::kind (SPREAD)
-- Adds a new harmony-object-spread flag and protects the parser code
with it.
-- Adds a new runtime function called CopyDataProperties
-- Does not add any support for this feature in fullcodegen.
-- Ignition calls out to a runtime function CopyDataProperties to
perform spread operation.
-- Move FastAssign from builtins-objects.cc to objects.cc
-- Refactor Builtin_ObjectAssign to use SetOrCopyDataProperties

Object rest will be implemented in a follow on patch.

BUG=v8:5549

Review-Url: https://codereview.chromium.org/2606833002
Cr-Commit-Position: refs/heads/master@{#42102}
      a40b7172
  19. 03 Jan, 2017 2 commits
  21. 22 Dec, 2016 1 commit
  23. 21 Dec, 2016 1 commit
  25. 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
  27. 16 Dec, 2016 2 commits
  29. 05 Dec, 2016 1 commit
  31. 01 Dec, 2016 2 commits
  33. 28 Nov, 2016 2 commits
  35. 25 Nov, 2016 2 commits
  37. 24 Nov, 2016 1 commit
  39. 22 Nov, 2016 1 commit
  41. 21 Nov, 2016 1 commit
    • mstarzinger's avatar
      [fullcodegen] Remove deprecated generator implementation. · 09255541
      mstarzinger authored 
      This removes the deprecated generator support for resumable functions
from {FullCodeGenerator}. The existing {AstNumbering} heuristic already
triggers Ignition for most resumable functions, with this change we make
said heuristic a hard choice and remove the deprecated code. This also
has the advantage that any suspended {JSGeneratorObject} instance on the
heap is guaranteed to have code based on a bytecode array.

R=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2504223002
Cr-Commit-Position: refs/heads/master@{#41135}
      09255541
  43. 18 Nov, 2016 1 commit
  45. 16 Nov, 2016 1 commit
  47. 10 Nov, 2016 1 commit
  49. 02 Nov, 2016 1 commit
    • bmeurer's avatar
      [compiler] Sanitize IC counts for vector based ICs. · 5ef1bddf
      bmeurer authored 
      All vector ICs use the TypeFeedbackVector::ComputeCounts method now,
while the remaining patching ICs still use the traditional way of
counting on the TypeFeedbackInfo hanging off the fullcodegen code
object. This fixes the problem that counts were sometimes off.

Drive-by-fix: Move FullCodeGenerator::CallIC to fullcodegen.cc.

R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2472653002
Cr-Commit-Position: refs/heads/master@{#40690}
      5ef1bddf
  51. 24 Oct, 2016 2 commits
  53. 20 Oct, 2016 1 commit
    • adamk's avatar
      [ignition] Eliminate hole checks where statically possible for loads and stores · 35a3ccbf
      adamk authored 
      Move hole check logic from full-codegen into scope analysis, and store the
"needs hole check" bit on VariableProxy. This makes it easy to re-use in
any backend: it will be trivial to extend the use of this logic in, e.g.,
full-codegen variable stores.

While changing the signatures of the variable loading/storing methods in
Ignition, I took the liberty of replacing the verb "Visit" with "Build", since these
are not part of AST visiting.

BUG=v8:5460

Review-Url: https://chromiumcodereview.appspot.com/2411873004
Cr-Commit-Position: refs/heads/master@{#40479}
      35a3ccbf
  55. 19 Oct, 2016 1 commit
    • zhengxing.li's avatar
      X87: [ic] Unify CallIC feedback collection and handling. · 572c231c
      zhengxing.li authored 
        port 308788b3 (r40397)

  original commit message:
  Consistently collect CallIC feedback in fullcodegen and Ignition, even
  for possibly direct eval calls, that were treated specially so far, for
  no apparent reason. With the upcoming SharedFunctionInfo based CallIC
  feedback, we might be able to even inline certain direct eval calls, if
  they manage to hit the eval cache. More importantly, this patch
  simplifies the collection and dealing with CallIC feedback (and as a
  side effect fixes an inconsistency with feedback for super constructor
  calls).

BUG=

Review-Url: https://chromiumcodereview.appspot.com/2429623005
Cr-Commit-Position: refs/heads/master@{#40416}
      572c231c
  57. 18 Oct, 2016 1 commit
  59. 13 Oct, 2016 1 commit
  61. 12 Oct, 2016 1 commit
  63. 07 Oct, 2016 2 commits