Commit Graph

417 Commits

Author SHA1 Message Date
Sathya Gunasekaran
ffda54fbd4 [class] Throw early errors for fields with constructor and prototype name
See https://tc39.github.io/proposal-class-fields/#sec-static-semantics-early-errors

Bug: v8:5367
Change-Id: I0329d1b41c4658b733df47397fbcc2c16bad117e
Reviewed-on: https://chromium-review.googlesource.com/792946
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49672}
2017-11-28 15:00:18 +00:00
Sathya Gunasekaran
42bc9e8c64 [class] Expand bytecode expectations coverage for class fields
Bug: v8:5367
Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba
Reviewed-on: https://chromium-review.googlesource.com/793150
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 13:21:36 +00:00
Sathya Gunasekaran
94dfb8a1f4 [class] Add harmony-public-fields flag
Change the existing uses of the harmony-class-fields flag to
harmony-public-fields so that we can stage this separately
from the upcoming harmony-private-fields to get some
clusterfuzz coverage.

Bug: v8:5367
Change-Id: I76cdefa4faf34eae73d3a5f6d6089cf75677732a
Reviewed-on: https://chromium-review.googlesource.com/792940
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49661}
2017-11-28 10:19:29 +00:00
Sathya Gunasekaran
34657ab30b [class] Implement super property access in instance fields
Bug: v8:5367
Change-Id: Ic725c5ef22ab05891764d3ebf9a99c0d383e6d90
Reviewed-on: https://chromium-review.googlesource.com/789939
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49660}
2017-11-28 10:14:19 +00:00
Adam Klein
bfa90f7e7c Move function name var initialization to BytecodeGenerator
Besides avoiding the weird hack of inserting a statement at the 0th
index of the function body, we also avoid allocating (and initializing)
the variable if it's unreferenced (which I'd wager is the common case).

Bug: v8:6092
Change-Id: If917d422bb4818cf21e8272aa786ca84d4472802
Reviewed-on: https://chromium-review.googlesource.com/784092
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49646}
2017-11-27 18:37:47 +00:00
Sathya Gunasekaran
4ca9d843f8 [class] Store class fields initializer on the constructor
Previously, the class fields initializer function was stored on a
synthetic context allocated variable. This approach had sevaral
problems:

- We didn't know that class literal had fields until after we had
completely parsed the class literal. This meant that we had to go back
and fix up the scope of the constructor to have this synthetic
variable. This resulted in mismatch between parser and preparsed scope
data.

- This synthetic variable could potentially resolve to an initializer
of an outer class.

For ex:
class X extends Object {
  c = 1;
  constructor() {
    var t = () => {
      class P extends Object {
        constructor() {
          var t = () => { super(); };
          t();
        }
      }
      super();
    }
    t();
  }
}

In this the inner class P could access the outer class X's initiliazer
function. We would have to maintain extra metadata to make sure this
doesn't happen.

Instead this new approach uses a private symbol to store the
initializer function on the class constructor itself.

For the base constructor case, we can simply check for a bit on the
constructor function literal to see if we need to emit code that loads
and calls this initializer function. Therefore, we don't pay the cost
of loading this function in case there are no class fields.

For the derived constructor case, there are two possiblities:
(a) We are in a super() call directly in the derived constructor:

In this case we can do a check similar to the base constructor check,
we can check for a bit on the derived constructor and emit code for
loading and calling the initializer function.

This is usually the common case and we don't pay any cost for not using
class fields.

(b) We are in a super() call inside an arrow function in the derived
constructor:

In this case, we /always/ emit code to load and call the initializer
function. If the function doesn't exist then we have undefined and we
don't call anything. Otherwise we call the function.

super() can't be called twice so even if we emit code to load and call
the initializer function multiple times, it doesn't matter because it
would have already been an error.

Bug: v8:5367
Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
Reviewed-on: https://chromium-review.googlesource.com/781660
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49628}
2017-11-27 10:35:11 +00:00
Toon Verwaest
da0af28545 [interpreter] DYNAMIC_GLOBAL needs to walk the context chain starting from current_scope, not closure_scope
The main reason why we currently don't see this fail is that block-scopes always appear to have an extension: the scope info object is stored there.

Bug: 
Change-Id: I38f0c15387e235eeea9a57c95af0d9eb185dad2a
Reviewed-on: https://chromium-review.googlesource.com/785951
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49585}
2017-11-22 17:40:26 +00:00
Igor Sheludko
cc9e77abe8 Reland^2 "[runtime] Slightly optimize creation of class literals."
This CL also includes fixes for CF issues found while the previous
reland was active.

Bug: v8:5799, chromium:783902, chromium:783926, chromium:783822
Change-Id: I1f7d9b037d90838469c45f5d72771a77444c662e
Reviewed-on: https://chromium-review.googlesource.com/764067
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49457}
2017-11-17 18:15:34 +00:00
Jakob Gruber
e4b394a1f4 Revert "Reland "[runtime] Slightly optimize creation of class literals.""
This reverts commit 22932d6b43.

Reason for revert: TSAN https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/18232

Original change's description:
> Reland "[runtime] Slightly optimize creation of class literals."
> 
> Bug: v8:5799
> Change-Id: I782ec131c7194aef20942a19750168a974913c3f
> Reviewed-on: https://chromium-review.googlesource.com/757337
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49291}

TBR=ulan@chromium.org,rmcilroy@chromium.org,jarin@chromium.org,ishell@chromium.org,verwaest@chromium.org

Change-Id: I0742d25b0e2364efc696d19492ba20614a3821fa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5799
Reviewed-on: https://chromium-review.googlesource.com/763458
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49303}
2017-11-10 16:00:31 +00:00
Igor Sheludko
22932d6b43 Reland "[runtime] Slightly optimize creation of class literals."
Bug: v8:5799
Change-Id: I782ec131c7194aef20942a19750168a974913c3f
Reviewed-on: https://chromium-review.googlesource.com/757337
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49291}
2017-11-10 11:57:18 +00:00
Mike Stanton
bdcab5f756 [FeedbackVector] Case statements can share a single vector slot
In the fast case, the feedback should be the same across all slots
(like a switch over enum values).

BUG=v8:7045

Change-Id: I2c32f81cda55874ea6fc8d6a18c85d9929cff1bb
Reviewed-on: https://chromium-review.googlesource.com/756701
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49177}
2017-11-07 11:16:47 +00:00
Georg Neis
c961986ec6 [bigint] Fix typeof.
The bytecode generator has special handling for comparing the result of
the typeof operator against a string literal. This needs to be adapted
for bigints.

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

Bug: v8:6791
Change-Id: I42d6c9e9225ce05e19393f10e01ae496ecb70c9c
Reviewed-on: https://chromium-review.googlesource.com/753465
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49172}
2017-11-07 10:06:54 +00:00
Toon Verwaest
c82cd31325 Drop custom accessor deoptimization support
Previously StaNamedProperty and StaKeyedProperty were in a weird state where
they claimed to not touch the accumulator, but actually did in case they were
deopted in the middle. A frame was added in the middle to overwrite the 
accumulator again with the right value before returning from the setter, using
a lot of complexity in the deoptimizer.

This changes those instructions to be marked as writing to the accumulator
(e.g., the result of the setter), and uses to manually store and reload into
the accumulator the value being stored.

If we want to avoid the additional bytecodes, we could make sure that bytecodes
that claim to leave the accumulator alone don't deopt back to Advance/Dispatch
but LoadAccumulatorWithValue/Advance/Dispatch. That's in a way similar to what
happened before this CL, but I believe could be implemented much simpler.


Bug: 
Change-Id: I4850a690ef5a30976701d0e050951faa46fd1c18
Reviewed-on: https://chromium-review.googlesource.com/753487
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49159}
2017-11-06 20:20:58 +00:00
Mathias Bynens
dbcea11564 [parser] Improve error message for import()
Currently, dynamic `import()` throws the following SyntaxError when
used without a specifier:

    > import();
    < Uncaught SyntaxError: Unexpected token )

From the error message, it seems this the result of the code snippet
being seen as static `import` followed by parens, as opposed to
`import()` with no specifier.

This patch makes this error message more clear:

    > import();
    < SyntaxError: import() requires a specifier

BUG=v8:7020,v8:6513

Change-Id: I3519dfd0029f38d23da858a5499f1d226e794935
Reviewed-on: https://chromium-review.googlesource.com/747141
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49058}
2017-10-31 19:42:44 +00:00
Adam Klein
6d56874868 Revert "[runtime] Slightly optimize creation of class literals."
This reverts commit 521fa16e02.

Reason for revert: fails tests under code-serializer:

https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/17691

Original change's description:
> [runtime] Slightly optimize creation of class literals.
> 
> TBR=bmeurer@chromium.org
> 
> Bug: v8:5799
> Change-Id: I61de5f8b3333db174dadf76ed983950acb39742b
> Reviewed-on: https://chromium-review.googlesource.com/649509
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49044}

TBR=rmcilroy@chromium.org,yangguo@chromium.org,mythria@chromium.org,gsathya@chromium.org,ishell@chromium.org,verwaest@chromium.org

Change-Id: I994edb855a8a0aa6e7e7476b0b013a46aac6f2e7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5799
Reviewed-on: https://chromium-review.googlesource.com/745581
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49046}
2017-10-31 01:04:20 +00:00
Igor Sheludko
521fa16e02 [runtime] Slightly optimize creation of class literals.
TBR=bmeurer@chromium.org

Bug: v8:5799
Change-Id: I61de5f8b3333db174dadf76ed983950acb39742b
Reviewed-on: https://chromium-review.googlesource.com/649509
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49044}
2017-10-31 00:08:26 +00:00
Adam Klein
317cf32131 [ast] Move AstValue implementation into Literal
This eliminates the AstValue class, effectively moving its
implementation into the Literal AstNode. This should cause
no difference in behavior, but it does signal some shifts
in the underlying system. Biggest changes include:

  - Reduction in AST memory usage
  - No duplicate HeapNumbers in Ignition constant pools
  - Non-String values are allocated either at constant pool
    creation time (or at boilerplate creation time for literals),
    rather than at AstValueFactory::Internalize() time.

There are a variety of test-only/debug-only changes due to these
switches as well.

Bug: v8:6984
Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1
Reviewed-on: https://chromium-review.googlesource.com/731111
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 20:21:29 +00:00
Georg Neis
03035038b9 [bigint] Implement ToBigInt and NumberToBigInt.
... and use them to complete the BigInt function.

Bug: v8:6791
Change-Id: Ia36db86b92d1a0cfcb783516e04d6c0e3750f194
Reviewed-on: https://chromium-review.googlesource.com/737643
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48993}
2017-10-27 06:43:57 +00:00
Leszek Swirski
52ef2a1c27 [parser] Add an n-ary node for large binop chains
Expressions of the form

    a_0 + a_1 + a_2 + a_3 + ... + a_n

seem to be reasonably common for cases such as building templates.
However, parsing these expressions results in a n-deep expression tree:

           ...
          /
         +
        / \
       +  a_2
      / \
    a_0 a_1

Traversing this tree during compilation can cause a stack overflow when n is
large.

Instead, for left-associate operations such as add, we now build up an
n-ary node in the parse tree, of the form

         n-ary +
       /  |      \
      /   |  ...  \
    a_0  a_1      a_n

The bytecode compiler can now iterate through the child expressions
rather than recursing.

This patch only supports arithmetic operations -- subsequent patches
will enable the same optimization for logical tests and comma
expressions.

Bug: v8:6964
Bug: chromium:724961
Bug: chromium:731861
Bug: chromium:752081
Bug: chromium:771653
Bug: chromium:777302
Change-Id: Ie97e4ce42506fe62a7bc4ffbdaa90a9f698352cb
Reviewed-on: https://chromium-review.googlesource.com/733120
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48920}
2017-10-25 11:28:55 +00:00
Georg Neis
d8fbe426fe [bigint] Adapt JSON.stringify.
Bug: v8:6791
Change-Id: Id34db2021c02b885be3f300648d5941362381d0b
Reviewed-on: https://chromium-review.googlesource.com/735561
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48896}
2017-10-25 07:13:47 +00:00
Benedikt Meurer
bcee140617 [turbofan] Introduce InstanceOfIC to collect rhs feedback.
This adds a new InstanceOfIC where the TestInstanceOf bytecode collects
constant feedback about the right-hand side of instanceof operators,
including both JSFunction and JSBoundFunction instances. TurboFan then
uses the feedback to optimize instanceof in places where the right-hand
side is not a known constant (known to TurboFan).

This addresses the odd performance cliff that we see with instanceof in
functions with multiple closures. It was discovered as one of the main
bottlenecks on the uglify-es test in the web-tooling-benchmark. The
uglify-es test (run in separation) is ~18% faster with this change.

On the micro-benchmark in the tracking bug we go from

  instanceofSingleClosure_Const: 69 ms.
  instanceofSingleClosure_Class: 246 ms.
  instanceofMultiClosure: 246 ms.
  instanceofParameter: 246 ms.

to

  instanceofSingleClosure_Const: 70 ms.
  instanceofSingleClosure_Class: 75 ms.
  instanceofMultiClosure: 76 ms.
  instanceofParameter: 73 ms.

boosting performance by roughly 3.6x and thus effectively removing the
performance cliff around instanceof.

Bug: v8:6936, v8:6971
Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e
Reviewed-on: https://chromium-review.googlesource.com/730686
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48820}
2017-10-23 10:15:36 +00:00
Ross McIlroy
ed592eb03f [Cleanup][Interpreter] Move feedback slot allocation to bytecode generator
Moves the feedback vector slot allocation out of ast-numbering and into
bytecode generation directly. This has a couple of benifits, including reduced
AST size, avoid code duplication and reduced feedback vector sizes in many cases
due to only allocating slots when needed. Also removes AstProperties since
this is no longer needed.

AstNumbering is now only used to allocate suspend ids for generators.

BUG=v8:6921

Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f
Reviewed-on: https://chromium-review.googlesource.com/722959
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 16:17:14 +00:00
Toon Verwaest
c95edbf27d [codegen] Delete unused StringCharLoadGenerator
Bug: v8:6921
Change-Id: I9e42d0a5e7ce7fdda1d00468a82d35b973200e2c
Reviewed-on: https://chromium-review.googlesource.com/718697
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48545}
2017-10-13 13:28:32 +00:00
Jakob Kummerow
e34debaf2b [bigint] Support BigInts in -,~,++,-- unary ops
and add the implementations for BitwiseNot, Increment, Decrement.
This CL teaches the respective bytecode handlers about BigInts,
and collects kBigInt type feedback for them (which TF discards
for now, substituting "any").

Bug: v8:6791
Change-Id: I4e802b301b9702d8270bda400edd7e885e6b11b9
Reviewed-on: https://chromium-review.googlesource.com/706101
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48479}
2017-10-12 01:40:33 +00:00
Georg Neis
6ff68255e9 [bigint] Introduce ToNumeric conversion.
This introduces a ToNumeric conversion to the runtime and interpreter.
ToNumeric behaves like ToNumber, except that it also lets BigInts pass.

Bug: v8:6791
Change-Id: Idf9d0b5d283638459fe5893de41cc120356247a7
Reviewed-on: https://chromium-review.googlesource.com/707013
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48440}
2017-10-11 07:49:28 +00:00
jgruber
159236ec25 [regexp] Update semantics of GetSubstitution with named captures
The specced semantics of GetSubstitution are expected to change in the
case of malformed named references, or named references to nonexistent
named groups. The former will evaluate to the identity replacement of
'$<', while the latter will result in replacement by the empty string.

See also:
https://github.com/tc39/proposal-regexp-named-groups/issues/29

Bug: v8:5437, v8:6912
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I879288f775774cb0ec563f9d9129a99710efb77c
Reviewed-on: https://chromium-review.googlesource.com/708654
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48426}
2017-10-10 11:37:29 +00:00
Camillo Bruni
6ee34530ea [literals] Don't reserve unused FeedbackVectorSlot for the empty object literal
Bug: v8:6211
Change-Id: Ie838cf118679e12483689e2c223e7ecc8335db18
Reviewed-on: https://chromium-review.googlesource.com/662759
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48418}
2017-10-10 10:00:49 +00:00
Toon Verwaest
de578fe3f8 [macro-assembler] Delete unused Jump/CheckBothSmi
Bug: 
Change-Id: I0c2dabebbfa709589c19b1c48ec8de4c7f7a3952
Reviewed-on: https://chromium-review.googlesource.com/707151
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48410}
2017-10-09 23:29:45 +00:00
Toon Verwaest
20a47ce094 [macro-assembler] Delete unused AllocateJSValue and related functions
Bug: 
Change-Id: I315d0017179e2f0a9883647b91fd4f0a762eade0
Reviewed-on: https://chromium-review.googlesource.com/707054
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48381}
2017-10-09 13:32:21 +00:00
Jan Krems
8e60857093 Parsing import.meta expression
Rewrites import.meta expressions into null literals. Builds on top
of- and requires dynamic import parsing to simplify the implementation.

Adds a new --harmony-import-meta flag.

BUG=v8:6693

Change-Id: Iadb7ddf6bad8986bf3ad641dbd3826fe730b5f44
Reviewed-on: https://chromium-review.googlesource.com/702678
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48359}
2017-10-09 02:47:31 +00:00
Michael Achenbach
ba44981a6a Revert "[language] Implement optional catch binding proposal"
This reverts commit d0651bd108.

Reason for revert: Breaks gc stress with embedded snapshot:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15355

Original change's description:
> [language] Implement optional catch binding proposal
> 
> This allows the syntax `try {} catch {}` (with no binding after the
> `catch`).
> 
> See https://github.com/michaelficarra/optional-catch-binding-proposal/
> 
> Currently behind --harmony-optional-catch-binding.
> 
> As part of the implementation, this allows TryCatchStatements to not
> have an associated catch scope; various paths which assumed they
> would have been updated to handle this case.
> 
> Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
> Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f
> Reviewed-on: https://chromium-review.googlesource.com/571453
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Kevin Gibbons <bakkot@gmail.com>
> Cr-Commit-Position: refs/heads/master@{#48300}

TBR=rmcilroy@chromium.org,adamk@chromium.org,marja@chromium.org,gsathya@chromium.org,bakkot@gmail.com

Change-Id: I63d68160ec75b87e28d3dcdddca2d8b7d0503b46
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/702334
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48303}
2017-10-05 08:31:15 +00:00
Kevin Gibbons
d0651bd108 [language] Implement optional catch binding proposal
This allows the syntax `try {} catch {}` (with no binding after the
`catch`).

See https://github.com/michaelficarra/optional-catch-binding-proposal/

Currently behind --harmony-optional-catch-binding.

As part of the implementation, this allows TryCatchStatements to not
have an associated catch scope; various paths which assumed they
would have been updated to handle this case.

Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ic525b45199eef025eb05da562e10fbd4f3d7465f
Reviewed-on: https://chromium-review.googlesource.com/571453
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Kevin Gibbons <bakkot@gmail.com>
Cr-Commit-Position: refs/heads/master@{#48300}
2017-10-05 01:51:20 +00:00
Jakob Kummerow
f83d0e0be8 [bigint] Implement shift ops
Bug: v8:6791
Change-Id: I5e91832bcb74e895eaf7a3d6ee493c832abba7bf
Reviewed-on: https://chromium-review.googlesource.com/699635
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48299}
2017-10-05 00:56:50 +00:00
Jakob Kummerow
3b57e96cd1 [bigint] Support BigInts in +,-,*,/,% binary ops.
This CL teaches the respective bytecode handlers and standalone stubs
about BigInts, and collects "kBigInt" feedback for them. However,
Turbofan does not yet care about such feedback, so it is simply converted
to "any" for now (making TF emit stub calls for BigInt operations).

Bug: v8:6791
Change-Id: I6440c108ccd79058d77adc2a6041251db9d5f81d
Reviewed-on: https://chromium-review.googlesource.com/683758
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48173}
2017-09-26 22:01:54 +00:00
Mathias Bynens
a10e4a179e [js] Check comparefn in (Typed)Array#sort
This patch ensures a `TypeError` is thrown when the argument passed to
`Array.prototype.sort` or `%TypedArray%.prototype.sort` is neither a
function nor `undefined`.

Every other major JavaScript engine already threw in this case. Making
V8’s behavior match increases interoperability.

https://github.com/tc39/ecma262/pull/785

BUG=v8:6542

Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I412a59810abdd118217c8d8361389ec6c2f640bd
Reviewed-on: https://chromium-review.googlesource.com/668356
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48028}
2017-09-15 10:08:06 +00:00
Adam Klein
c9efff3fcd [bigint] Add bytecodes for unary-minus and bitwise-not
This continues to move the "desugaring" of unary operators further
down the pipeline, in this case into the bytecode handlers for new
bytecodes `Negate` and `BitwiseNot` and the corresponding TF code
in BytecodeGraphBuilder.

Bug: v8:6971
Tbr: yangguo@chromium.org
Change-Id: If6b5d6b239a09ef8b4dbde49321614503c0f5beb
Reviewed-on: https://chromium-review.googlesource.com/661146
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47980}
2017-09-12 19:07:59 +00:00
Adam Klein
bf55951cdd [bigint] Output ToNumber bytecode for unary plus
As part of that change, make ToNumber return in the accumulator.

Bug: v8:6791
Change-Id: I8ce0f4fbc7ad8ee7fb4a32a8a499394395010750
Reviewed-on: https://chromium-review.googlesource.com/658082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47976}
2017-09-12 15:27:21 +00:00
Jaroslav Sevcik
6e8c00f7df Introduce an Abort bytecode and turbofan operator.
The advantage of an explicit Abort that the interpreter and the compiler know
that aborting cannot continue or throw or deopt. As a result we generate less
code and we do not confuse the compiler if the environment is not set up for
throwing (as in the generator dispatch that fails validation in
crbug.com/762057).

Bug: chromium:762057
Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7
Reviewed-on: https://chromium-review.googlesource.com/657025
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 12:16:23 +00:00
Ross McIlroy
a192639e2f [Interpreter] Make CallJSRuntime implicitly use undefined reciever.
JS runtime calls are always created with undefined recievers, so make the
bytecode behave similarly to CallUndefinedReciever such that we don't need
to push an explicit undefined register for the receiver for such calls.

Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls
to pass the generator in the first argument rather than the reciever since
these runtime calls were desugered in the bytecode generator and explicitly
passed the generator in the receiver.

Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269
Reviewed-on: https://chromium-review.googlesource.com/654257
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47870}
2017-09-07 12:14:24 +00:00
Jakob Kummerow
cfcdeab002 [storeic] Drop duplicate stubs for each LanguageMode
Only the error cases of overwriting readonly properties need the
language_mode to decide whether to throw or be silent. Reading it
from the feedback vector's metadata (just like the C++ code in
ic.cc does) removes the need to duplicate each stub for each
language_mode ("StoreIC" + "StoreICStrict" etc.).

Change-Id: Ic0c67f9d40ca36c65e41b4f162b2ab70d155e549
Reviewed-on: https://chromium-review.googlesource.com/647373
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47836}
2017-09-05 18:00:39 +00:00
Benedikt Meurer
f1ec44e2f5 [turbofan] Optimize fast enum cache driven for..in.
This CL adds support to optimize for..in in fast enum-cache mode to the
same degree that it was optimized in Crankshaft, without adding the same
deoptimization loop that Crankshaft had with missing enum cache indices.
That means code like

  for (var k in o) {
    var v = o[k];
    // ...
  }

and code like

  for (var k in o) {
    if (Object.prototype.hasOwnProperty.call(o, k)) {
      var v = o[k];
      // ...
    }
  }

which follows the https://eslint.org/docs/rules/guard-for-in linter
rule, can now utilize the enum cache indices if o has only fast
properties on the receiver, which speeds up the access o[k]
significantly and reduces the pollution of the global megamorphic
stub cache.

For example the micro-benchmark in the tracking bug v8:6702 now runs
faster than ever before:

 forIn: 1516 ms.
 forInHasOwnProperty: 1674 ms.
 forInHasOwnPropertySafe: 1595 ms.
 forInSum: 2051 ms.
 forInSumSafe: 2215 ms.

Compared to numbers from V8 5.8 which is the last version running with
Crankshaft

 forIn: 1641 ms.
 forInHasOwnProperty: 1719 ms.
 forInHasOwnPropertySafe: 1802 ms.
 forInSum: 2226 ms.
 forInSumSafe: 2409 ms.

and V8 6.0 which is the current stable version with TurboFan:

 forIn: 1713 ms.
 forInHasOwnProperty: 5417 ms.
 forInHasOwnPropertySafe: 5324 ms.
 forInSum: 7556 ms.
 forInSumSafe: 11067 ms.

It also improves the throughput on the string-fasta benchmark by
around 7-10%, and there seems to be a ~5% improvement on the
Speedometer/React benchmark locally.

For this to work, the ForInPrepare bytecode was split into
ForInEnumerate and ForInPrepare, which is very similar to how it was
handled in Fullcodegen initially. In TurboFan we introduce a new
operator LoadFieldByIndex that does the dynamic property load.

This also removes the CheckMapValue operator again in favor of
just using LoadField, ReferenceEqual and CheckIf, which work
automatically with the EscapeAnalysis and the
BranchConditionElimination.

Bug: v8:6702
Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
Reviewed-on: https://chromium-review.googlesource.com/645949
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 11:27:37 +00:00
Adam Klein
6154040782 [parser] Reduce AST overhead for parsing SwitchStatements
This makes several changes to SwitchStatement handling:

  - Store the CaseClause list inline (as it's always allocated)
  - Only rewrite with additional blocks if the Block Scope for
    the switch statement isn't empty
  - Use Parser::IgnoreCompletion() instead of inserting an additional
    `undefined` ExpressionStatement

Bug: v8:6092
Change-Id: Ib08d0ba851dd8e78b3dc74782b8e554541e79182
Reviewed-on: https://chromium-review.googlesource.com/644176
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47751}
2017-08-31 16:46:05 +00:00
Camillo Bruni
dbaafb76c7 [literals] No longer use a FeedbackVectorSlot for the empty object literal
Bug: v8:6211
Change-Id: I0f15c59b7b786ab327e4ab548523095dd85ba83e
Reviewed-on: https://chromium-review.googlesource.com/637835
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47650}
2017-08-28 16:08:38 +00:00
Leszek Swirski
e5df5bd044 [ignition] Always write the deferred command result register
For deferred commands (such as in try-finally), some deferred commands
save and restore the accumulator using a result register (e.g. return,
throw, rethrow), while others don't (e.g. break, continue,
fall-through).

However, conditionally reading this result register that may not ever be
written caused it to be considered live from the start of the function,
as far as the liveness analysis could statically tell.

Now, we write the result register for all deferred commands, including
the fall-through. As a micro-optimization, we re-use the Smi command
tokeen to clobber the result, rather than emitting an LdaUndefined.

Bug: chromium:758472
Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b
Reviewed-on: https://chromium-review.googlesource.com/635592
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47612}
2017-08-25 16:31:24 +00:00
Adam Klein
ac0a2df30e [ignition] Fix return value of delete on global lexical variables
BytecodeGenerator previously assumed that any UNALLOCATED variable
must be a global object property, but that's incorrect for global
lexical variables declared in a different script.

This patch fixes the behavior by always falling back to the runtime
to deal with deleting UNALLOCATED variables. This is sub-optimal,
but should be correct, and it's unclear if speed is important for
this case.

Bug: v8:6733
Change-Id: I83c2a0b6e30e5e5f4c79bfe14ebf196529816c71
Reviewed-on: https://chromium-review.googlesource.com/627636
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47554}
2017-08-23 16:17:48 +00:00
Camillo Bruni
7daf8cf3ee [literals] Add CreateEmptyObjectLiteral bytecode
The quite common empty object literal doesn't need an AllocationSite
since it starts off with the general ElementsKind. By using a separate 
bytecode we can directly instantiate the empty object without jumping
to the runtime first.

Note: this experimentally disables pretenuring for empty object
      literals. Depending on the outcome of our benchmarks pretenuring
      will be enabled again or fully removed for empty object literals.

Bug: v8:6211
Change-Id: I2fee81cbefc70865fc436dbd3bc5fc8de04db91c
Reviewed-on: https://chromium-review.googlesource.com/577555
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47467}
2017-08-21 10:01:16 +00:00
Caitlin Potter
fbb46475c8 [ignition] desugar AsyncGenerator yield* in BytecodeGenerator
Move the desugaring into BytecodeGenerator per TODOs.

BUG=v8:6472
R=tebbi@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org

Change-Id: Ic482bee18d6e6fe73de4c5f9abaf4feda7be2dd5
Reviewed-on: https://chromium-review.googlesource.com/550396
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47403}
2017-08-17 16:04:28 +00:00
Ross McIlroy
c820b89bc5 [Interpreter] Remove new.target from fixed frame slot.
Removes the new.target slot from the interpreter's fixed frame. Instead
adds a field to BytecodeArray to get the bytecode's incoming
new.target or generator object register. The InterpreterEntryTrampoline
then sets this register with the incoming new.target (or generator object)
when the function is called. This register can be directly the new.target
or generator object variable if they are LOCAL location, otherwise it is a
temporary register which is then moved to the variable's location during the
function prologue.

This fixes a hack in the deoptimizer where we would set the new.target fixed
slot to undefined in order to avoid extending it's lifetime through the
optimized code - now it's just a standard register and can be optimized away
as normal.

Bug=v8:6644

Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae
Reviewed-on: https://chromium-review.googlesource.com/608966
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47320}
2017-08-11 17:04:08 +00:00
Ross McIlroy
1458e8b01a [fullcodegen] Delete FullCodegen.
Deletes the now unused Full-codegen compiler. Also removes some macro
assembler instructions which are no longer used.

Note: there is still additional cleanup work to do after this lands
(e.g., remove support for FCG frames support and FCG
debugger support, etc.), but this will be done in followup CLs to keep
this patch managable.

BUG=v8:6409

Change-Id: I8d828fe7a64d29f2c1252d5fda968a630a2e9ef2
Reviewed-on: https://chromium-review.googlesource.com/584773
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47307}
2017-08-11 11:50:05 +00:00
Caitlin Potter
fa1a339777 [async-iteration] eliminate implicit Await when resuming with .return()
AsyncGenerators, when resumed with a "return" completion, Await the sent
value to provide consistency with syntactic return statements. This
moves the await to during AsyncGeneratorResumeNext, shrinking the number
of bytecodes.

There's a minor change to BytecodeGenerator which removes a
%_GeneratorClose() call, since it's inserted implicitly by the parser.

BUG=v8:5855
TBR=neis@chromium.org

Change-Id: I2965c610e5985ac24c713b481e62f6b97f96a3d8
Reviewed-on: https://chromium-review.googlesource.com/582218
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47253}
2017-08-09 14:53:14 +00:00