This makes sure that the lowering of {JSCreate} operator during create
lowering is only applied to operations where both target and new.target
are known to be constructors.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-768080
BUG=chromium:774780,chromium:768080
Change-Id: I55a582a3453bba7e14655b594b7714a3940eeaae
Reviewed-on: https://chromium-review.googlesource.com/725332
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48680}
This fixes https://bugs.chromium.org/p/chromium/issues/detail?id=773954.
The issue was that in the EffectControlLinearizer, the effect input of an
{Unreachable} node was not updated, leaving a {Checkpoint} behind.
This is a reland of 4cf476458f
Original change's description:
> Reland^3 "[turbofan] eagerly prune None types and deadness from the graph"
>
> This fixes the issues
> https://bugs.chromium.org/p/chromium/issues/detail?id=772873
> and https://bugs.chromium.org/p/chromium/issues/detail?id=772872.
>
> One problem was that mutating an effect node into Unreachable confused
> the LoadElimination sidetables, so I just always create a new node now.
>
> The other problem was that UpdateBlockControl() was executed after
> UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input.
> So now I make sure that UpdateEffectPhi() is always executed last.
>
> This is a reland of 6ddb5e7da7
> Original change's description:
> > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph"
> >
> > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the
> > graph end. This fixes issues with later phases running DeadCodeElimination and
> > introducing new DeadValue nodes when processing uses of Unreachable.
> >
> > This is a reland of 3c4bc27f13
> > Original change's description:
> > > Reland "[turbofan] eagerly prune None types and deadness from the graph"
> > >
> > > This is a reland of e1cdda2512
> > > Original change's description:
> > > > [turbofan] eagerly prune None types and deadness from the graph
> > > >
> > > > In addition to using the {Dead} node to prune dead control nodes and nodes that
> > > > depend on them, we introduce a {DeadValue} node representing an impossible value
> > > > that can occur at any position in the graph. The extended {DeadCodeElimination}
> > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
> > > > the effect chain when possible. The remaining uses of {DeadValue} are handled
> > > > in {EffectControlLinearizer}, where we always have access to the effect chain.
> > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use
> > > > of a node with type {None} as dead.
> > > >
> > > > Bug: chromium:741225
> > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
> > > > Reviewed-on: https://chromium-review.googlesource.com/641250
> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#48208}
> > >
> > > Bug: chromium:741225
> > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138
> > > Reviewed-on: https://chromium-review.googlesource.com/692034
> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#48232}
> >
> > Bug: chromium:741225
> > Change-Id: I5702ec34856c075717162153adc765774453c45f
> > Reviewed-on: https://chromium-review.googlesource.com/702264
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48366}
>
> Bug: chromium:741225
> Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f
> Reviewed-on: https://chromium-review.googlesource.com/709214
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48469}
Bug: chromium:741225
Change-Id: Id9d4f3a3ae36cb3e38f80edcdba88efa7922ca24
Reviewed-on: https://chromium-review.googlesource.com/715716
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48660}
Ensure we only lower SpeculativeNumberBinops to a pure operator for
non-string plain primitives. Previously we could lower if a value might be
the-hole, however this would fail a CHECK in ConvertInputsToNumber which
expects a plain primitive.
BUG=chromium:772420
Change-Id: I0c755d10db7afd9cabfb638eca5662d70dfc8d51
Reviewed-on: https://chromium-review.googlesource.com/715717
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48649}
OSR for functions which use arguments no longer needs to be disabled, since
TurboFan handles the case.
Bug:
Change-Id: I121f1190a142c18f113bd5f875e258812645c43f
Reviewed-on: https://chromium-review.googlesource.com/721661
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48631}
Disabling only for stress mode did not help, the test uses 10GB
in other modes too.
Bug: v8:6924
Change-Id: I0e1348f8a43e41612d3a94e75396f0a26a82ece2
Reviewed-on: https://chromium-review.googlesource.com/721662
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48626}
Inner functions which called eval, and were the kind of functions
that can use `super`, were erroneously not marked as "uses_super_property",
leading to downstream crashes when the runtime tried to load the
[[HomeObject]] from them.
This patch eliminates the public Scope::uses_super_property()
API and ensures that callers always call Scope::NeedsHomeObject()
instead.
This is a minimal fix designed for easy merging; it's likely that
in the long run we should remove most mentions of "uses super property"
and replace them with "needs home object" for clarity.
Bug: v8:5516, chromium:774994
Change-Id: Id269dd33e35bd40f6b59a3d3e19330687afa64f8
Reviewed-on: https://chromium-review.googlesource.com/721879
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48619}
This supports {valueOf() { return BigInt(...) }} objects as
operands in binary and unary operations.
Bug: v8:6791
Change-Id: I30ec9983ff611477742f9ea0bc6d04972fe21d3c
Reviewed-on: https://chromium-review.googlesource.com/716863
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48612}
Port the baseline version of Reflect.has to the CodeStubAssembler and
reuse the existing logic for HasProperty (i.e. the HasProperty builtin).
Also inline the Reflect.has builtin into TurboFan, by adding a check
on the target in front of a use of the JSHasProperty operator.
Technically this additional check is not necessary, because the
JSHasProperty operator already throws if the target is not a JSReceiver,
but the exception message is confusing then.
This improves the performance of the micro-benchmark from
reflectHasPresent: 337 ms.
reflectHasAbsent: 472 ms.
to
reflectHasPresent: 121 ms.
reflectHasAbsent: 216 ms.
which is a nice 2.8x improvement in the best case. It also improves the
chai test on the web-tooling-benchmark by around 1-2%, which is roughly
the expected win (since Reflect.has overall accounts for around 3-4%).
Bug: v8:5996, v8:6936, v8:6937
Change-Id: I856183229677a71c19936f06f2a4fc7a794a9a4a
Reviewed-on: https://chromium-review.googlesource.com/720959
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48608}
- Extract core StringPrototypeRepeat code into a TFS builtin (StringRepeat)
- Assumes arguments are a string and smi (no range checks)
- Add StringPrototypePadStart and StringPrototypePadEnd TFJ builtins
- Added StringPadAssembler to ensure common behavior
- Removed functionality from string.js
A quick benchmark shows significant performance gains for unoptimized
code (2.1x to 2.46x) and optimized code (1.03x - 1.56x).
https: //github.com/peterwmwong/v8-perf/blob/master/string-pad/README.md
Bug: v8:5049
Change-Id: I6e4fe99fb62a3edb3d6906fd4f78b3576b5b0d13
Reviewed-on: https://chromium-review.googlesource.com/720067
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48595}
When skipping inner funcs is enabled, we also track variables for top level
funcs. Thus, we also declared the function name for the function scope, even
though it was the function scope for a function whose preparsing was
aborted. This lead into declaring the function name twice.
The fix is to declare the function name only in the success case.
The code was "wrong" before too, but this was never a problem, since variable
tracking and aborting preparsing were enabled for disjoint sets of
functions (aborting preparsing only for top-level, and variable tracking for
non-top-level).
BUG=v8:5516,chromium:774475
Change-Id: Ie6c321cc834cd946e8843f73916fa7dd75e9cd09
Reviewed-on: https://chromium-review.googlesource.com/720920
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48592}
This CL removes the code specialization for WASM functions that access
globals. Previously, we were embedding the start address of the globals
memory (globals_start) as a constant in the code, which required
patching for every instance. We now put this base in to the WasmContext,
which is available as a parameter to every WasmFunction.
R=ahaas@chromium.org,
CC=mtrofin@chromium.org
Bug:
Change-Id: I04bb739e898cc5a3b7dd081cc166483022d113fd
Reviewed-on: https://chromium-review.googlesource.com/712595
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48581}
In Array.prototype.map, we have to store the map result in an output array.
If we know we are storing objects, or special objects like boolean, rather
than a number, then we can reduce the amount of checks we have to do to
transition the output array to the appropriate ElementsKind.
Likewise, if we know we've got floating point values, we can specialize
appropriately to a double array.
Bug: v8:6896
Change-Id: I375daf604562b53638ea749945c1a4c907e33547
Reviewed-on: https://chromium-review.googlesource.com/711845
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48579}
This patch introduces assertPromiseFulfills and assertPromiseFulfills as
a replacement for assertPromiseResult because it’s more JavaScript-y.
BUG=v8:6921
R=ahaas@chromium.org
Also-By: ahaas@chromium.org
Change-Id: I2f865dba3992ddf3b58987bf0b376d143edb5c31
Reviewed-on: https://chromium-review.googlesource.com/718746
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48578}
Reuses the existing logic for BigInt.parseInt, adapted slightly
to allow octal and binary radix prefixes (and to support parsing
of a raw character buffer, rather than a v8::internal::String).
Bug: v8:6791
Change-Id: I41904b2204721eac452e0765fa9ff0ab26ee343b
Reviewed-on: https://chromium-review.googlesource.com/711334
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48560}
Previously, Function("++f`...`) would not throw an exception until the
created function was called. Now, it throws an early ReferenceError.
This change matches the behaviour in JavaScriptCore and SpiderMonkey.
Ordinary calls such as Function("++f()") are still thrown at runtime,
also compatible with JavaScriptCore and SpiderMonkey.
BUG=v8:4480, v8:6910
R=marja@chromium.org, littledan@chromium.org
Change-Id: If31c6d360a0464744eff5d8dd377ebff184ae00e
Reviewed-on: https://chromium-review.googlesource.com/712794
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48553}
This adds and explicit check for the constructability of the new.target
value in the lowering of {JSCall} nodes known to call Reflect.construct.
The {JSConstruct} operator does not perform this check and relies on the
implicit validity of new.target in all other use cases.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-768080
BUG=chromium:768080
Change-Id: I7c1921e787bae64ba83de3eb08aa00fc5523e251
Reviewed-on: https://chromium-review.googlesource.com/718100
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48543}
The test uses more than 10GB memory in stress mode and causes OOM
failures on TSAN bots.
NOTRY=true
Bug: v8:6924
Change-Id: Ifaab153316432a5c59869ef312b43d84827480df
Reviewed-on: https://chromium-review.googlesource.com/718110
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48532}
These tests use too much memory on MIPS.
Bug:
Change-Id: I9ab15b04ad8cec94ab1b1c022e819a2d802e375d
Reviewed-on: https://chromium-review.googlesource.com/716497
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#48518}
This flag describes that the memory defined in a wasm module has a
maximum size. Therefore I think kHasMaximumFlag is more appropriate.
R=titzer@chromium.org
Bug: v8:6921
Change-Id: Ie794d670f74e7f1f9a42822e2f774da85aaaaa4b
Reviewed-on: https://chromium-review.googlesource.com/718198
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48517}
In preparation for adding more separate test files.
Bug: v8:6791
Change-Id: I92e2a3ab6fd35e2f902179a005ed9640851ca1b6
Reviewed-on: https://chromium-review.googlesource.com/716927
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48512}
Parser creates a FunctionState for default ctors, which affects the
next_function_is_likely_called logic. PreParser needs to match that logic, so
that Parser and PreParser agree about which functions are skippable.
BUG=v8:5515, chromium:773576
Change-Id: I96cb6f5aa68e74389a863355f70a34693a2d1329
Reviewed-on: https://chromium-review.googlesource.com/712579
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48511}
Contrary to other Absolute-bitwise operations, it is not symmetric.
Bug: v8:6791
Change-Id: Id0d57e3cf61177af0b77a3d9d4a4e17e5737ae11
Reviewed-on: https://chromium-review.googlesource.com/714301
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48507}
This propagates the existing type of a {JSAdd} node back to the newly
created {Allocate} node. There are cases where said type is {None}.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-772720
BUG=chromium:772720
Change-Id: Iab18d2108a789b51db4e405f7f335c5c0ca6f686
Reviewed-on: https://chromium-review.googlesource.com/708796
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48493}
Also add tests for Object::SameValue.
R=jkummerow@chromium.org
Bug: v8:6791
Change-Id: I0611044dcfee4c6ba836629cf82d1589135e4ab0
Reviewed-on: https://chromium-review.googlesource.com/712034
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48486}
R=jkummerow@chromium.org
Bug: v8:6791
Change-Id: I7e99a8aa2aa65e78a8d4288f496d496600063bfe
Reviewed-on: https://chromium-review.googlesource.com/712534
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48485}
This reverts commit 4cf476458f.
Reason for revert: Broken effect chains detected by Clusterfuzz. Playing it safe for the 63 branch.
Original change's description:
> Reland^3 "[turbofan] eagerly prune None types and deadness from the graph"
>
> This fixes the issues
> https://bugs.chromium.org/p/chromium/issues/detail?id=772873
> and https://bugs.chromium.org/p/chromium/issues/detail?id=772872.
>
> One problem was that mutating an effect node into Unreachable confused
> the LoadElimination sidetables, so I just always create a new node now.
>
> The other problem was that UpdateBlockControl() was executed after
> UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input.
> So now I make sure that UpdateEffectPhi() is always executed last.
>
> This is a reland of 6ddb5e7da7
> Original change's description:
> > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph"
> >
> > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the
> > graph end. This fixes issues with later phases running DeadCodeElimination and
> > introducing new DeadValue nodes when processing uses of Unreachable.
> >
> > This is a reland of 3c4bc27f13
> > Original change's description:
> > > Reland "[turbofan] eagerly prune None types and deadness from the graph"
> > >
> > > This is a reland of e1cdda2512
> > > Original change's description:
> > > > [turbofan] eagerly prune None types and deadness from the graph
> > > >
> > > > In addition to using the {Dead} node to prune dead control nodes and nodes that
> > > > depend on them, we introduce a {DeadValue} node representing an impossible value
> > > > that can occur at any position in the graph. The extended {DeadCodeElimination}
> > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
> > > > the effect chain when possible. The remaining uses of {DeadValue} are handled
> > > > in {EffectControlLinearizer}, where we always have access to the effect chain.
> > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use
> > > > of a node with type {None} as dead.
> > > >
> > > > Bug: chromium:741225
> > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
> > > > Reviewed-on: https://chromium-review.googlesource.com/641250
> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > > > Cr-Commit-Position: refs/heads/master@{#48208}
> > >
> > > Bug: chromium:741225
> > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138
> > > Reviewed-on: https://chromium-review.googlesource.com/692034
> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#48232}
> >
> > Bug: chromium:741225
> > Change-Id: I5702ec34856c075717162153adc765774453c45f
> > Reviewed-on: https://chromium-review.googlesource.com/702264
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48366}
>
> Bug: chromium:741225
> Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f
> Reviewed-on: https://chromium-review.googlesource.com/709214
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48469}
TBR=jarin@chromium.org,tebbi@chromium.org
Change-Id: Icf6a6af4feaafd4bde28cb7b996735ff91bb3810
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:741225
Reviewed-on: https://chromium-review.googlesource.com/715096
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48482}
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}
This CL teaches the respective bytecode handlers and standalone
stubs about BigInts, and collects "kBigInt" type feedback for them.
Just like for other binary ops, that feedback is converted to "any"
for TurboFan for now.
Bug: v8:6791
Change-Id: I0709cc77dc248dad506207c7b35b63c80b1ef96a
Reviewed-on: https://chromium-review.googlesource.com/699424
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48471}
This fixes the issues
https://bugs.chromium.org/p/chromium/issues/detail?id=772873
and https://bugs.chromium.org/p/chromium/issues/detail?id=772872.
One problem was that mutating an effect node into Unreachable confused
the LoadElimination sidetables, so I just always create a new node now.
The other problem was that UpdateBlockControl() was executed after
UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input.
So now I make sure that UpdateEffectPhi() is always executed last.
This is a reland of 6ddb5e7da7
Original change's description:
> Reland^2 "[turbofan] eagerly prune None types and deadness from the graph"
>
> Now, the EffectControlLinearizer connects all occurrences of Unreachable to the
> graph end. This fixes issues with later phases running DeadCodeElimination and
> introducing new DeadValue nodes when processing uses of Unreachable.
>
> This is a reland of 3c4bc27f13
> Original change's description:
> > Reland "[turbofan] eagerly prune None types and deadness from the graph"
> >
> > This is a reland of e1cdda2512
> > Original change's description:
> > > [turbofan] eagerly prune None types and deadness from the graph
> > >
> > > In addition to using the {Dead} node to prune dead control nodes and nodes that
> > > depend on them, we introduce a {DeadValue} node representing an impossible value
> > > that can occur at any position in the graph. The extended {DeadCodeElimination}
> > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
> > > the effect chain when possible. The remaining uses of {DeadValue} are handled
> > > in {EffectControlLinearizer}, where we always have access to the effect chain.
> > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use
> > > of a node with type {None} as dead.
> > >
> > > Bug: chromium:741225
> > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
> > > Reviewed-on: https://chromium-review.googlesource.com/641250
> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#48208}
> >
> > Bug: chromium:741225
> > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138
> > Reviewed-on: https://chromium-review.googlesource.com/692034
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48232}
>
> Bug: chromium:741225
> Change-Id: I5702ec34856c075717162153adc765774453c45f
> Reviewed-on: https://chromium-review.googlesource.com/702264
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48366}
Bug: chromium:741225
Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f
Reviewed-on: https://chromium-review.googlesource.com/709214
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48469}
This is a reland of ed6f00fb8e
Original change's description:
> [modules] Implement import.meta proposal
>
> Rewrites references to import.meta to a new GetImportMetaObject runtime
> call. Embedders can define a callback for creating the meta object using
> v8::Isolate::SetHostGetImportMetaObjectCallback. If no callback has been
> provided, an empty object with null prototype is created.
>
> This adds an example implementation to d8 that sets meta.url.
>
> Bug: v8:6693
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I6871eec79da45bba81bbbc84b1ffff48534c368d
> Reviewed-on: https://chromium-review.googlesource.com/707902
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48433}
TBR=adamk@chromium.org
Bug: v8:6693
Change-Id: Ie2d746ad996a56ed6ff50b832f320fe44e02f231
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/712834
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48468}
Adds some necessary padding to ensure the frame is 16-byte aligned.
We don't yet consider the bailout state, which will be handled separately.
This patch also improves the code generated for ContinueTo*Builtin* stubs.
Finally, it adds a test that checks the return value for Array.map in
the case where a LAZY deopt results in a topmost builtin continuation
frame - this is easy to break if the padding for the result is done
incorrectly in NotifyBuiltinContinuation, but was not detected by existing
tests.
Bug: v8:6644
Change-Id: Id1a294950cdf535e2bfdb0ed27c67f077ec34f8a
Reviewed-on: https://chromium-review.googlesource.com/704835
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48465}
- Expose fast paths for RegExpPrototypeMatchBody/RegExpPrototypeSearchBody as TFS builtins
- Add StringPrototypeMatch and StringPrototypeSearch TFJ builtins
- Add StringMatchSearchAssembler to ensure same search/match behavior
- Remove functionality from string.js
A quick benchmark shows gains of 20-30% for unoptimized code and 0-20% for optimized code.
https://github.com/peterwmwong/v8-perf/blob/master/string-search-match/README.md
Bug: v8:5049
Change-Id: I0fffee6e94e62ecae049c9e5798da52d67ae1823
Reviewed-on: https://chromium-review.googlesource.com/707824
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48452}
Skipped the tests that are not suitable for deoptimization fuzzing.
regress/regress-2618 test fixed to check kMaybeDeopted flag.
Minor code style fix in mjsunit.js.
Bug: v8:6900
Change-Id: Icc02a6b99005ae08ee7cb6cf2c1e9137329d79d3
Reviewed-on: https://chromium-review.googlesource.com/708797
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48444}
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}
This reverts commit ed6f00fb8e.
Reason for revert: tree is broken
NOTRY=true
NOTREECHECKS=true
Original change's description:
> [modules] Implement import.meta proposal
>
> Rewrites references to import.meta to a new GetImportMetaObject runtime
> call. Embedders can define a callback for creating the meta object using
> v8::Isolate::SetHostGetImportMetaObjectCallback. If no callback has been
> provided, an empty object with null prototype is created.
>
> This adds an example implementation to d8 that sets meta.url.
>
> Bug: v8:6693
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I6871eec79da45bba81bbbc84b1ffff48534c368d
> Reviewed-on: https://chromium-review.googlesource.com/707902
> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48433}
TBR=adamk@chromium.org,gsathya@chromium.org,jan.krems@groupon.com
Change-Id: I908a508d5db84cc8ae60d4fd4a0446bb570c1492
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6693
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/710760
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48434}
Rewrites references to import.meta to a new GetImportMetaObject runtime
call. Embedders can define a callback for creating the meta object using
v8::Isolate::SetHostGetImportMetaObjectCallback. If no callback has been
provided, an empty object with null prototype is created.
This adds an example implementation to d8 that sets meta.url.
Bug: v8:6693
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I6871eec79da45bba81bbbc84b1ffff48534c368d
Reviewed-on: https://chromium-review.googlesource.com/707902
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48433}
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}
Previously, JS_ASYNC_GENERATOR_OBJECT_TYPE maps led to an UNREACHABLE
macro, but are now restored like ordinary JSGeneratorObjects.
BUG=chromium:772649, v8:5855
R=adamk@chromium.org, yangguo@chromium.org, verwaest@chromium.org
Change-Id: I02e101565625f8a057d0e5b242a5fe0df263df89
Reviewed-on: https://chromium-review.googlesource.com/706780
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48423}
This makes sure that frames representing builtin stub continuations not
only materialize all stack slots, but also spilled register values. Note
that this also applies when the stub frame is not the top-most frame.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-6907
BUG=v8:6907
Change-Id: I01a2edf5629de6aac61ceea350d1ab5f91dc2dc1
Reviewed-on: https://chromium-review.googlesource.com/707245
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48415}
This ensures the JSFunction objects materialized by the deoptimizer have
the correct instance size (depending on the given map). There are corner
cases where the instance size might vary due to in-object properties.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-772610
BUG=chromium:772610
Change-Id: I4808c7260db1adbd1cdc3871c2a946475e4934f2
Reviewed-on: https://chromium-review.googlesource.com/707109
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48383}
Missing arguments are identical to undefined, and are converted to the
integer 0 by ECMAScript {ToInteger()}.
Add more tests, and enable previously disabled tests.
There is a follow-up refactoring here: https://crrev.com/c/704586R=titzer@chromium.org, mstarzinger@chromium.org
Change-Id: I89cc259aaf5975ec2f6f51ff002e7d1b32adba5e
Reviewed-on: https://chromium-review.googlesource.com/704658
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48373}
The escape analysis is able to perform scalar replacement on JSArrays
with in-object properties (which currently only happens for subclasses
of the Array constructor), but the Deoptimizer didn't properly
materialized and initialized the values of the in-object fields so far.
Bug: chromium:772689, v8:6399
Change-Id: I6555a46773d2a1543db069142aa05f4337566b9c
Reviewed-on: https://chromium-review.googlesource.com/706781
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48365}
Make calls like
new Array(n)
new A(n)
(where A is a subclass of Array) inlinable into TurboFan. We do this by
speculatively checking that n is an unsigned integer that is not greater
than JSArray::kInitialMaxFastElementArray, and then lowering the backing
store allocation to a builtin call. The speculative optimization is
either protected by the AllocationSite for the Array constructor
invocation (if we have one), or by a newly introduced global protector
cell that is used for Array constructor invocations that don't have an
AllocationSite, i.e. the ones from Array#map, Array#filter, or from
subclasses of Array.
Next step will be to implement the backing store allocations inline in
TurboFan, but that requires Loop support in the GraphAssembler, so it's
done as a separate CL. This should further boost the performance.
This boosts the ARES6 ML benchmark by up to 8% on the steady state,
and also improves monomorphic Array#map calls by around 20-25% on the
initial setup.
Bug: v8:6399
Tbr: ulan@chromium.org
Change-Id: I7c8bdecf7c814ce52db6ee3051c3206a4f7d4bb6
Reviewed-on: https://chromium-review.googlesource.com/704639
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48348}
This brings V8's behavior in line with both the spec and with
other engines.
This also fixes the (now-incorrect) DCHECK in BytecodeGenerator relating
to the delete operator's application to a VariableProxy.
Bug: v8:6697, v8:6721
Change-Id: I413c02af235b0bb652eb4c5d5c971e2cf80e0906
Reviewed-on: https://chromium-review.googlesource.com/703894
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48346}
Power-of-two radixes were supported already; this adds all others
(with 2 <= radix <= 36).
Bonus: fix digit_div fallback path for divisors with no leading zeros.
Bug: v8:6791
Change-Id: Id472667f057ad13338e0d8257a899490490e6f8f
Reviewed-on: https://chromium-review.googlesource.com/693316
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48323}
The code used to rely on all such loops having a block scope around
them, but that is no longer the case for loops whose loop variables
are VAR-declared.
This patch introduces a new DeclarationDescriptor::Kind for such
variables, and sets it during parsing, allowing the variable
declaration code to note them as assigned appropriately.
Bug: chromium:768158
Change-Id: I0cd60e8c8c735681be9dbb9344a93156af09c952
Reviewed-on: https://chromium-review.googlesource.com/701624
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48320}
The catch variable is a special VAR-mode variable which is not in a declaration
scope. Normally creating such a variable is not possible with DeclareVariable,
but Parser bypasses it by calling DeclareLocal directly (which doesn't have the
hoisting check).
PreParser used to cut corners and declare the catch variable as a LET-mode
variable to prevent hoisting.
But since LET and VAR variables behave differently when deciding whether they
block sloppy block function hoisting, that approach doesn't fly.
BUG=v8:5516,chromium:771474
Change-Id: Ic6f5f4996416c9fa59132725c8b0b6b570c72f48
Reviewed-on: https://chromium-review.googlesource.com/700634
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48308}
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}
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}
This reverts commit 5e76ff5a4a.
Reason for revert: tsan failures - https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/17574
Original change's description:
> Reland "[wasm] always allocate memory when guard regions are needed"
>
> This reverts commit 7cf29d8df3.
>
> Original change's description:
> > [wasm] always allocate memory when guard regions are needed
> >
> > When using trap handlers, memory references do not get any checks inserted. This
> > means there is no check for a null memory as happens when the memory size is
> > 0. Normally this would be correctly caught as an out of bounds access, since the
> > low memory addresses are not normally mapped. However, if they were mapped for
> > some reason, we would not catch the out of bounds access.
> >
> > The fix is to ensure WebAssembly instances always have a guard region even if
> > the memory is size 0.
> >
> > Bug: chromium:769637
>
> Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00
> Reviewed-on: https://chromium-review.googlesource.com/695812
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48293}
TBR=gdeepti@chromium.org,mtrofin@chromium.org,mlippautz@chromium.org,eholk@chromium.org,eholk@google.com,clemensh@chromium.org
Change-Id: I52d5354126158a92602b08c48703d562ac95075b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/699599
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48294}
This reverts commit 7cf29d8df3.
Original change's description:
> [wasm] always allocate memory when guard regions are needed
>
> When using trap handlers, memory references do not get any checks inserted. This
> means there is no check for a null memory as happens when the memory size is
> 0. Normally this would be correctly caught as an out of bounds access, since the
> low memory addresses are not normally mapped. However, if they were mapped for
> some reason, we would not catch the out of bounds access.
>
> The fix is to ensure WebAssembly instances always have a guard region even if
> the memory is size 0.
>
> Bug: chromium:769637
Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00
Reviewed-on: https://chromium-review.googlesource.com/695812
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48293}
Fix an error overwriting the `prototype` property of async generator
functions when FLAG_enable_slow_asserts is enabled.
Previously, the `initial_async_generator_prototype` field was never
written to the native context, and was always undefined. This caused
some incorrect runtime behaviour, and would crash when loading the field
using the Context::initial_aysnc_generator_prototype accessor when
attempting to cast the Undefined oddball to a JSObject.
BUG=chromium:771470, v8:5855
R=adamk@chromium.org, verwaest@chromium.org, gsathya@chromium.org
Change-Id: I13f2a518c59852bc77c2de1f2468a4eea457609e
Reviewed-on: https://chromium-review.googlesource.com/700261
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#48291}
The code in `AsmJsScanner::Next()` checks for both
end of input and parse error:
if (token_ == kEndOfInput || token_ == kParseError) {
return;
}
but until now the code in the parsing loop only checked
for `kEndOfInput`, resulting in an infinite loop on
`kParseError`.
R=bradnelson@chromium.org, mstarzinger@chromium.org
Bug: chromium:771428
Change-Id: I9170f090503590b3b9b949a0d00ab4daef85bf66
Reviewed-on: https://chromium-review.googlesource.com/699994
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48290}
In the process, also enable support for PACKED_DOUBLE_ELEMENTS arrays.
Change-Id: I16dd79276f1023e30b072d45216396533077f53c
Reviewed-on: https://chromium-review.googlesource.com/571006
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48289}
This CL speeds up a common pattern found in the React framework:
function f(a, b, c) { ... };
let f_bound = f.bind(this, 1);
let f_bound2 = f_bound(this, 2);
This CL yields roughly a 15x improvement for rebinding a bound function.
Change-Id: I4d8580a5bce422af411148bc6b3e4eb287fac9ce
Reviewed-on: https://chromium-review.googlesource.com/695206
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48283}
The Object.is builtin provides an entry point to the abstract operation
SameValue, which properly distinguishes -0 and 0, and also identifies
NaNs. Most of the time you don't need these, but rather just regular
strict equality, but when you do, Object.is(o, -0) is the most readable
way to check for minus zero.
This is for example used in Node.js by formatNumber to properly print -0
for negative zero. However since the builtin thus far implemented as C++
builtin and TurboFan didn't know anything about it, Node.js considering
to go with a more performant, less readable version (which also makes
assumptions about the input value) in
https://github.com/nodejs/node/pull/15726
until the performance of Object.is will be on par (so hopefully we can
go back to Object.is in Node 9).
This CL ports the baseline implementation of Object.is to CSA, which
is pretty straight-forward since SameValue is already available in
CodeStubAssembler, and inlines a few interesting cases into TurboFan,
i.e. comparing same SSA node, and checking for -0 and NaN explicitly.
On the micro-benchmarks we go from
testNumberIsMinusZero: 1000 ms.
testObjectIsMinusZero: 929 ms.
testObjectIsNaN: 954 ms.
testObjectIsSame: 793 ms.
testStrictEqualSame: 104 ms.
to
testNumberIsMinusZero: 89 ms.
testObjectIsMinusZero: 88 ms.
testObjectIsNaN: 88 ms.
testObjectIsSame: 86 ms.
testStrictEqualSame: 105 ms.
which is a nice 10x to 11x improvement and brings Object.is on par with
strict equality for most cases.
Drive-by-fix: Also refactor and optimize the SameValue check in the
CodeStubAssembler to avoid code bloat (by not inlining StrictEqual
into every user of SameValue, and also avoiding useless checks).
Bug: v8:6882
Change-Id: Ibffd8c36511f219fcce0d89ed4e1073f5d6c6344
Reviewed-on: https://chromium-review.googlesource.com/700254
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48275}
When atomic operations are used in loops, return the correct opcode length
for loop assignment.
Bug=v8:6842,v8:6532
Change-Id: I306db704d8a0baa5d98c05702360e6dfae11cbfa
Reviewed-on: https://chromium-review.googlesource.com/699561
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48273}
This makes sure that helper methods on the {TranslatedState} class stick
to the counting scheme used by {OptimizedFrame::Summarize} within the
stack-walker. Both now treat {kJavaScriptBuiltinContinuation} as real
JavaScript frames.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-770543
BUG=chromium:770543
Change-Id: Icda65a7efb487470d39ebf648767a488ebf2e5f1
Reviewed-on: https://chromium-review.googlesource.com/695123
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48264}
This makes sure the deoptimizer properly materializes heap objects, even
when the top-most frame happens to be a stub-frame. Without this step
the {arguments_marker} would leak into user-land and most likely be
treated as an undefined value.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-769852
BUG=chromium:769852
Change-Id: I4ba17501c5d7e68d1f402b7c2cc5ccb0fb7bfb05
Reviewed-on: https://chromium-review.googlesource.com/691996
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48262}
Until now keyed accesses to properties with string or symbol keys were
only optimized properly while the IC was monomorphic and would go
megamorphic as soon as there's another receiver map, even if the name
was still the same (i.e. the same symbol or internalized string). This
was a weird performance-cliff, that'll hurt modern code especially
because for symbols you can only access them via keyed loads and stores.
This CL fixes the state machine inside the ICs to properly transition to
POLYMORPHIC state (and stay there) as long as the new name matches the
previously recorded name. The FeedbackVector and TurboFan were already
able to deal with this and didn't need any updates.
On the micro-benchmark from the tracking bug we go from
testStringMonomorphic: 429 ms.
testSymbolMonomorphic: 431 ms.
testStringPolymorphic: 429 ms.
testSymbolPolymorphic: 5621 ms.
to
testStringMonomorphic: 429 ms.
testSymbolMonomorphic: 429 ms.
testStringPolymorphic: 429 ms.
testSymbolPolymorphic: 430 ms.
effectively eliminating the overhead for symbols completely, and
yielding a 13.5x performance boost.
This also seems to yield a 1% improvement on the ARES6 ML benchmark,
because it eliminates the KEYED_LOAD_ICs for the Symbol.species lookups.
Bug: v8:6367, v8:6278, v8:6344
Change-Id: I879fe56387b4c56203c1ad8ef8cafb6cc4c32897
Reviewed-on: https://chromium-review.googlesource.com/695108
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48261}
The TypedArray.prototype[Symbol.toStringTag] getter is currently the best (and
as far as I can tell only definitely side-effect free) way to check whether an
arbitrary object is a TypedArray - either generally TypedArray or a specific
one like Uint8Array. Using the getter is thus emerging as the general pattern
to detect TypedArrays, even Node.js now adapted it starting with
https://github.com/nodejs/node/pull/15663
for the isTypedArray and isUint8Array type checks in lib/internal/util/types.js
now.
The getter returns either the string with the TypedArray subclass name
(i.e. "Uint8Array") or undefined if the receiver is not a TypedArray.
This can be implemented with a simple elements kind dispatch, instead of
checking the instance type and then loading the class name from the
constructor, which requires a loop walking up the transition tree. This
CL ports the builtin to CSA and TurboFan, and changes the logic to a
simple elements kind check. On the micro-benchmark mentioned in the
referenced bug, the time goes from
testIsArrayBufferView: 565 ms.
testIsTypedArray: 2403 ms.
testIsUint8Array: 3847 ms.
to
testIsArrayBufferView: 566 ms.
testIsTypedArray: 965 ms.
testIsUint8Array: 965 ms.
which presents an up to 4x improvement.
Bug: v8:6874
Change-Id: I9c330b4529d9631df2f052acf023c6a4fae69611
Reviewed-on: https://chromium-review.googlesource.com/695021
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48254}
In JS to Wasm wrappers, arguments have to be converted from JavaScript's
representation to Wasm's representation. Because of property accessors, this can
result in JavaScript or even asm.js/Wasm code being run. We were previously
setting this flag before doing the parameter conversions, and if these
conversions triggered a Wasm property getter then we would try to set the flag
twice.
With this change, we wait until after all argument conversions are done to set
the flag.
Bug: chromium:769846
R=bradnelson@chromium.org
Change-Id: Ia4b56df45619dcad69f3750bb33cacfedcaeb5b2
Reviewed-on: https://chromium-review.googlesource.com/693414
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48244}
This reverts commit 1f99c66b56.
Reason for revert: Test timeouts on Win64 Debug: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/19226
Original change's description:
> [wasm] always allocate memory when guard regions are needed
>
> When using trap handlers, memory references do not get any checks inserted. This
> means there is no check for a null memory as happens when the memory size is
> 0. Normally this would be correctly caught as an out of bounds access, since the
> low memory addresses are not normally mapped. However, if they were mapped for
> some reason, we would not catch the out of bounds access.
>
> The fix is to ensure WebAssembly instances always have a guard region even if
> the memory is size 0.
>
> Bug: chromium:769637
> Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
> Reviewed-on: https://chromium-review.googlesource.com/693137
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48240}
TBR=gdeepti@chromium.org,mtrofin@chromium.org,eholk@chromium.org
Change-Id: I4065b367c6cfffe8dd601b67cd53ad54759ae96a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:769637
Reviewed-on: https://chromium-review.googlesource.com/692918
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48242}
based on the existing Number.parseInt.
Bug: v8:6791
Change-Id: I9169a4695807a3e435e343d239431ae7f6ccf2a1
Reviewed-on: https://chromium-review.googlesource.com/685990
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48241}
When using trap handlers, memory references do not get any checks inserted. This
means there is no check for a null memory as happens when the memory size is
0. Normally this would be correctly caught as an out of bounds access, since the
low memory addresses are not normally mapped. However, if they were mapped for
some reason, we would not catch the out of bounds access.
The fix is to ensure WebAssembly instances always have a guard region even if
the memory is size 0.
Bug: chromium:769637
Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
Reviewed-on: https://chromium-review.googlesource.com/693137
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48240}
The WasmContext struct introduced in this CL is used to store the
mem_size and mem_start address of the wasm memory. These variables can
be accessed at C++ level at graph build time (e.g., initialized during
instance building). When the GrowMemory runtime is invoked, the context
variables can be changed in the WasmContext at C++ level so that the
generated code will load the correct values.
This requires to insert a relocatable pointer only in the
JSToWasmWrapper (and in the other wasm entry points), the value is then
passed from function to function as an automatically added additional
parameter. The WasmContext is then dropped when creating an Interpreter
Entry or when invoking a JavaScript function. This removes the need of
patching the generated code at runtime (i.e., when the memory grows)
with respect to WASM_MEMORY_REFERENCE and WASM_MEMORY_SIZE_REFERENCE.
However, we still need to patch the code at instance build time to patch
the JSToWasmWrappers; in fact the address of the WasmContext is not
known during compilation, but only when the instance is built.
The WasmContext address is passed as the first parameter. This has the
advantage of not having to move the WasmContext around if the function
does not use many registers. This CL also changes the wasm calling
convention so that the first parameter register is different from the
return value register. The WasmContext is attached to every
WasmMemoryObject, to share the same context with multiple instances
sharing the same memory. Moreover, the nodes representing the
WasmContext variables are cached in the SSA environment, similarly to
other local variables that might change during execution. The nodes are
created when initializing the SSA environment and refreshed every time a
grow_memory or a function call happens, so that we are sure that they
always represent the correct mem_size and mem_start variables.
This CL also removes the WasmMemorySize runtime (since it's now possible
to directly retrieve mem_size from the context) and simplifies the
GrowMemory runtime (since every instance now has a memory_object).
R=ahaas@chromium.org,clemensh@chromium.org
CC=gdeepti@chromium.org
Change-Id: I3f058e641284f5a1bbbfc35a64c88da6ff08e240
Reviewed-on: https://chromium-review.googlesource.com/671008
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48209}
This is a reland of 9d3c4b4b91
Original change's description:
> [turbofan] Implement lowering of {JSCreateClosure}.
>
> This adds support for inline allocation of {JSFunction} objects as part
> of closures instantiation for {JSCreateClosure} nodes. The lowering is
> limited to instantiation sites which have already seen more than one
> previous instantiation, this avoids the need to increment the respective
> counter.
>
> R=jarin@chromium.org
>
> Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b
> Reviewed-on: https://chromium-review.googlesource.com/594287
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48176}
Change-Id: I3ec3880bea89798a34a3878e6122b95db1014151
Reviewed-on: https://chromium-review.googlesource.com/686834
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48198}
There was an issue with passing float32 parameters, if the value was
spilled on the stack and passed as stack parameter.
First, we sometimes reduced the stack pointer by 8 bytes instead of 4,
and second, there was a mismatch between movsd and movss.
R=titzer@chromium.org
Bug: chromium:718858
Change-Id: Ia884df369ddd95adeff3733f9715f589996f0b65
Also-By: ahaas@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/684738
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48181}
This reverts commit 9d3c4b4b91.
Reason for revert: Breaks cctest/test-debug/NoBreakWhenBootstrapping in no-snap mode.
Original change's description:
> [turbofan] Implement lowering of {JSCreateClosure}.
>
> This adds support for inline allocation of {JSFunction} objects as part
> of closures instantiation for {JSCreateClosure} nodes. The lowering is
> limited to instantiation sites which have already seen more than one
> previous instantiation, this avoids the need to increment the respective
> counter.
>
> R=jarin@chromium.org
>
> Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b
> Reviewed-on: https://chromium-review.googlesource.com/594287
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48176}
TBR=mstarzinger@chromium.org,jarin@chromium.org
Change-Id: Id52281f6a3c0b7c2603053ecf002777d5b0d6f1f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/686534
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48178}
This adds support for inline allocation of {JSFunction} objects as part
of closures instantiation for {JSCreateClosure} nodes. The lowering is
limited to instantiation sites which have already seen more than one
previous instantiation, this avoids the need to increment the respective
counter.
R=jarin@chromium.org
Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b
Reviewed-on: https://chromium-review.googlesource.com/594287
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48176}
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}
This fixes the signature of "Math.abs" from "(signed) -> signed" to
"(signed) -> unsigned" and hence fixes cases where the absolute value
would overflow the range of signed 32-bit values. This is in sync with
spec erratas (and ECMAScript semantics).
Note that this also switches the underlying implementation of the above
absolute value function to a branch-free version.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-3
BUG=v8:6838
Change-Id: Ib13b7ecd336ae386cbde7c574e727bf52f841e00
Reviewed-on: https://chromium-review.googlesource.com/684181
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48169}
