So far we didn't properly constant-fold JSToString operators in
JSTypedLowering where the input was a known number constant.
Bug: v8:6815
Change-Id: Iac87346b7d38f0f75461f285ea7daa2d5a5e1524
Reviewed-on: https://chromium-review.googlesource.com/663358
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47972}
When accessing elements of a global (constant) JSArray, whose backing
store is copy-on-write, we can just constant-fold the value and insert
a check that the backing store stays the same.
Bug: v8:6816, v8:6815
Change-Id: I090bcec7b1ce72a1f9ed8625680ed91e8c67f27f
Reviewed-on: https://chromium-review.googlesource.com/662757
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47963}
BigInt is a new primitive type of arbitrary precision integers,
proposed in https://tc39.github.io/proposal-bigint.
This CL introduces a corresponding instance type, map, and C++
class to V8 and adds BigInt support to a few operations (see the
test file). Much more is to come. Also, the concrete representation
of BigInts is not yet fixed, currently a BigInt is simply a wrapped
Smi.
Bug: v8:6791
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45
Reviewed-on: https://chromium-review.googlesource.com/657022
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47956}
The wasm valiation incorrectly allowed simd locals, even without the
experimental flag turned on. This was not noted in the generated code
because simd opcodes were forbidden, but the interpreter could not
handle these locals.
R=clemensh@chromium.org
Bug: chromium:763697
Change-Id: I11d924ac21e50bce81d0504c2c7b252105a89f80
Reviewed-on: https://chromium-review.googlesource.com/660117
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47946}
The Typer put the wrong type on String#index and String#lastIndexOf
builtins, with an off by one on the upper bound.
Bug: chromium:762874
Change-Id: Ia4c29bc2e8e1c85b6a7ae0b99f8aaabf839a5932
Reviewed-on: https://chromium-review.googlesource.com/660000
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47942}
TurboFan wasn't able to inline calls to Array.prototype.push which
didn't have exactly one parameter. This was a rather artifical
limitation and was mostly due to the way the MaybeGrowFastElements
operator was implemented (which was not ideal by itself). Refactoring
this a bit, allows us to inline the operation in general, independent
of the number of values to push.
Array#push with multiple parameters is used quite a lot inside Ember (as
discovered by Apple, i.e. https://bugs.webkit.org/show_bug.cgi?id=175823)
and is also dominating the Six-Speed/SpreadLiterals/ES5 benchmark (see
https://twitter.com/SpiderMonkeyJS/status/906528938452832257 from the
SpiderMonkey folks). The micro-benchmark mentioned in the tracking bug
(v8:6808) improves from
arrayPush0: 2422 ms.
arrayPush1: 2567 ms.
arrayPush2: 4092 ms.
arrayPush3: 4308 ms.
to
arrayPush0: 798 ms.
arrayPush1: 2563 ms.
arrayPush2: 2623 ms.
arrayPush3: 2773 ms.
with this change, effectively removing the odd 50-60% performance
cliff that was associated with going from one parameter to two or
more.
Bug: v8:2229, v8:6808
Change-Id: Iffe4c1233903c04c3dc2062aad39d99769c8ab57
Reviewed-on: https://chromium-review.googlesource.com/657582
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47940}
It's quite common today to use Function#apply together with typed
arrays, for example to construct a String from character codes (or code
points) within a Uint8Array or Uint16Array, i.e.
String.fromCharCode.apply(undefined, uint8array)
is seen quite often on the web. But there are other interesting cases
like
Math.max.apply(undefined, float64array)
to compute the maximum value in a Float64Array, which is definitely not
the fastest implementation, but quite convenient and readable.
Unfortunately these cases hit the super-slow-path of the Function#apply
machinery in V8 currently, because Function#apply doesn't have any
fast-path for TypedArrays.
This CL adds a proper fast-path to CreateListFromArrayLike to the
ElementsAccessor, which can be used as long as the typed array that's
passed wasn't neutered. With this fast-path in place, the performance on
the micro-benchmark mentioned in the issue improves from
stringFromCharCode: 6386 ms.
stringFromCodePoint: 8752 ms.
to
stringFromCharCode: 1932 ms.
stringFromCodePoint: 4262 ms.
which corresponds to a 2.0x-3.3x improvement.
Bug: v8:2435
Change-Id: I4d39666e53644b11d5856982b005928e26f296fe
Reviewed-on: https://chromium-review.googlesource.com/657405
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47936}
TSAN finds data races in generated JavaScript code that use
access the SharedArrayBuffer backing store racily. These are races, but
they are OK in the sense that the JavaScript memory model allows for the
potential bad behavior they could introduce (e.g. potentially tearing
reads). Relaxed atomics could be used here instead, but that could
introduce performance regressions.
This change adds TSAN annotations to the TypedArray reads/writes to
prevent TSAN from warning about them.
Bug: chromium:722871
Change-Id: I0776475f02a352b678ade7d32ed6bd4a6be98c36
Reviewed-on: https://chromium-review.googlesource.com/656509
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47929}
The previous %StringCharCodeAt runtime entry (and the inlined intrinsic)
are obsolete and not used anymore (except in dedicated tests for this
runtime function), so remove it. And rename the %StringCharCodeAtRT
function, which is actually used to %StringCharCodeAt instead to have
a consistent naming scheme for runtime fallbacks.
Bug: v8:5049
Change-Id: I619429ef54f6efea61fc51ab9ed1d5cfe4417f99
Reviewed-on: https://chromium-review.googlesource.com/657719
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47928}
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}
JavaScript is a dynamically typed language. But most code is
written with fixed types in mind. When debugging JavaScript,
it is helpful to know the types of variables and parameters
at runtime. It is often hard to infer types for complex code.
Type profiling provides this information at runtime.
Node.js uses the inspector protocol. This CL allows Node.js users
to access and analyse type profile for via Node modules or the
in-procress api. Type Profile helps developers to analyze
their code for correctness and performance.
Design doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
Add `takeTypeProfile` to the inspector protocol. It returns a list
of TypeProfileForScripts, which in turn contains the type profile for
each function. We can use TypeProfile data to annotate JavaScript code.
Sample script with data from TypeProfile:
function f(/*Object, number, undefined*/a,
/*Array, number, null*/b,
/*boolean, Object, symbol*/c) {
return 'bye';
/*string*/};
f({}, [], true);
f(3, 2.3, {a: 42});
f(undefined, null, Symbol('hello'));/*string*/
Bug: v8:5933
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I626bfb886b752f90b9c86cc6953601558b18b60d
Reviewed-on: https://chromium-review.googlesource.com/508588
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47920}
Add support to the JSCallReducer to recognize JSConstruct nodes where
the target is the Object constructor, and reduce them to JSCreate
nodes if either
(a) no value is passed to the Object constructor, or
(b) the target and new.target are definitely not identical, by checking
whether both target and new.target are different HeapConstants
(if they are not, then the JSCreateLowering will not be able to
do a lot with the JSCreate anyways).
This should cover the relevant cases for subclassing appropriately. It
fixes the 3-4x slowdown on the micro-benchmark mentioned in the linked
bug,
baseNoExtends: 752 ms.
baseExtendsObject: 752 ms.
baseExtendsViaFactory: 751 ms.
and thus removes the performance cliff.
R=jarin@chromium.org
Bug: v8:6801
Change-Id: Id265fd1399302a67b5790a6d0156679920c58bdd
Reviewed-on: https://chromium-review.googlesource.com/657019
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47913}
When the bailout triggered, we assumed we're generating data (i.e., we're inside
a non-arrow function). This is not true; it's possible that we're already inside
an arrow function and not generating data anyway.
BUG=v8:5516,chromium:761980
Change-Id: Iad9c8dde283031630953ef9a46c1e68bc0cee048
Reviewed-on: https://chromium-review.googlesource.com/655081
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47905}
The spec calls out to Promise.prototype.then and also passes around
the constructor of the receiver to Promise.prototype.finally.
Adds a new constructor slot to PromiseFinallyContext enum and this is
used to create a new promise in the thenFinally/catchFinally callbacks.
Created a new PromiseResolve TFS builtin refactored from
the existing PromiseResolve builtin. PromiseResolveWrapper
calls out to this TFS Builtin and is now exposed as Promise.resolve.
The thenFinally and catchFinally callbacks also call out to the
PromiseResolve TFS builtin.
Spec -- https://tc39.github.io/proposal-promise-finally/
Bug: v8:5967
Change-Id: I2ce89f14d3b149619d11e424b6e37062e466c4d5
Reviewed-on: https://chromium-review.googlesource.com/652026
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47898}
What happened:
- When rewriting in DoParseFunction, the relevant function scope is no longer in
the scope stack.
- The correct scope is given to the PatternRewriter.
- PatternRewriter called to Parser::BuildIteratorCloseForCompletion.
- BuildIteratorCloseForCompletion would just call NewTemporary (which creates
a new temporary in Parser's current scope) instead of using the scope passed to
it and calling NewTemporary on it.
- Normally this went unnoticed, since it doesn't matter that much where the
temporary is.
- But in the lazy arrow func case, the Parser's scope at that point was the
already-resolved outer scope, and a DCHECK detected this problem.
Kudos & thanks to verwaest@ for a debugging session :)
BUG=chromium:761831
Change-Id: I1e8474ce927be0330f4ba4efc0fc08fdcc328809
Reviewed-on: https://chromium-review.googlesource.com/650297
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47877}
When setting a typed array from an array like object, the
length of the source can only be converted to a unit32 if
it is not too large.
Bug: v8:6704, chromium:761654
Change-Id: I8f89aa348093d8bd4d54aa16d6b5f255d3cb7adc
Reviewed-on: https://chromium-review.googlesource.com/648976
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47798}
Prior to this, AllocateJSArray would go ahead and allocate an empty
FixedArray as elements if passed any capacity that is not a compile-time
constant 0.
Things break later on since we rely on the fact that empty fixed arrays
are always canonicalize, and we use
obj.elements == empty_fixed_array_constant
interchangeably with
obj.elements.length == 0.
This CL introduces two new branches in AllocateJSArray: one if the
capacity is known to be non-zero; and another that explicitly
distinguishes between 0 and non-zero capacities.
Bug: chromium:760790
Change-Id: I7c22b19ce9ce15a46f91b0f75e6b4a1ff3a29a0f
Reviewed-on: https://chromium-review.googlesource.com/645959
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47776}
We emitted rotation by 24 bits with bitwise and, but that is wrong
because the low 8 bits can wrap around and "leak" into the result.
Bug: chromium:739902
Change-Id: Id49251e89405afb1581b8c60cde808c2d8bf693d
Reviewed-on: https://chromium-review.googlesource.com/645848
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47746}
Use int instead of byte to store the source position when computing a
location based on the stack trace stored in an error object.
Also add tests, since this code path was not covered before (not even
for small position where it would have succeeded).
Also, add some comments about which positions are 0-based and 1-based.
R=titzer@chromium.org
Change-Id: I313dcd6c47b77093ced9bb687415715d04eafb97
Reviewed-on: https://chromium-review.googlesource.com/645527
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47739}
When calling
Object(value)
where the value is known to be a JSReceiver, we can just replace it with
value, as the Object constructor call is a no-op in that case. Otherwise
when value is known to be not null or undefined then we can replace the
Object constructor call with an invocation of ToObject.
This covers the common pattern found in bundles generated by Webpack,
where the Object constructor is used to call imported functions, i.e.
Object(module.foo)(1, 2, 3)
There's a lot of detail in https://github.com/webpack/webpack/issues/5600
on this matter and why this pattern was chosen.
Bug: v8:6772
Change-Id: I2b4f0b4542b68b97b337ce571d6d79946c73d8bb
Reviewed-on: https://chromium-review.googlesource.com/643868
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47728}
PreParser and Parser didn't agree whether a generator in a sloppy block is a
sloppy block function or not, and thus the data generated by PreParser was
inconsistent with what the Parser wanted to restore.
BUG=v8:5516, chromium:760116
Change-Id: I0fd3c267691b8afd63a1336774769caf551c143e
Reviewed-on: https://chromium-review.googlesource.com/642886
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47727}
This CL introduces two tests to verify that the correct memory is
accessed when a wasm module invokes an wasm function imported from a
second module that accesses its (i.e., second module's) memory.
The first test verifies that the second module's memory is accessed in
case the first module does not have memory. In the second test, both the
modules have memory.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I75c3a5335583a91af0e7e4179c482142165b1c01
Reviewed-on: https://chromium-review.googlesource.com/637837
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@{#47702}
This reimplements functionality that was present before the decoder
refactoring. It's implemented a bit differently though by generating
the code for re-throwing an uncaught exception earlier (when generating
code for the catch).
R=titzer@chromium.org, kschimpf@chromium.org
Bug: v8:6600
Change-Id: Ie2f11837851c0602ab31506fa63475fc2d0b5047
Reviewed-on: https://chromium-review.googlesource.com/641550
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47687}
This is a reland of 6b4dc039a6
Original change's description:
> [wasm] Refactor function body decoder
>
> This refactoring separates graph building from wasm decoding. The
> WasmGraphBuilder is just a consumer of the decoded information.
> Decoding without any consumer (i.e. just validation) gets 16% faster by
> this refactoring, because no TFNode* have to be stored in the value
> stack, and all dynamic tests to determine whether the graph should be
> build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
> 92.2 +- 3.1 ms).
>
> This new design will allow us to also attach other consumers, e.g. a
> new baseline compiler.
>
> R=titzer@chromium.org
>
> Bug: v8:6600
> Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
> Reviewed-on: https://chromium-review.googlesource.com/571010
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47671}
TBR=titzer@chromium.org
Bug: v8:6600
Change-Id: Idd867c5a1917437de5b6e3de5917cc1c9f194489
Reviewed-on: https://chromium-review.googlesource.com/640591
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47678}
This CL introduces 4 test that verify that the effects of a grow_memory
instruction executed in a function invoked inside a loop are visible
also when the loop is over. This is needed because the
AnalyzeLoopAssignment method in function-body-decoder.cc is creating Phi
nodes only for variables assigned inside the loop. The test cases
introduced by this CL verify that the mem_size and mem_start variables
are always correct.
The tests verify the output of the current_memory instruction and the
result of loading a variable stored in the grown memory inside the
loop in the following cases:
* the memory is grown in a directly called function inside a loop;
* the memory is grown in an indirectly called function inside a loop.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I2992bf4086b5eac9580c87e2e0ca06364b99714c
Reviewed-on: https://chromium-review.googlesource.com/637911
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47674}
This reverts commit 6b4dc039a6.
Reason for revert: Mips build failure: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/11749
Original change's description:
> [wasm] Refactor function body decoder
>
> This refactoring separates graph building from wasm decoding. The
> WasmGraphBuilder is just a consumer of the decoded information.
> Decoding without any consumer (i.e. just validation) gets 16% faster by
> this refactoring, because no TFNode* have to be stored in the value
> stack, and all dynamic tests to determine whether the graph should be
> build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
> 92.2 +- 3.1 ms).
>
> This new design will allow us to also attach other consumers, e.g. a
> new baseline compiler.
>
> R=titzer@chromium.org
>
> Bug: v8:6600
> Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
> Reviewed-on: https://chromium-review.googlesource.com/571010
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47671}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: I76a50e355f0390cc53a2da4ceedd8830ca20a9c6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6600
Reviewed-on: https://chromium-review.googlesource.com/640870
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47672}
This refactoring separates graph building from wasm decoding. The
WasmGraphBuilder is just a consumer of the decoded information.
Decoding without any consumer (i.e. just validation) gets 16% faster by
this refactoring, because no TFNode* have to be stored in the value
stack, and all dynamic tests to determine whether the graph should be
build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
92.2 +- 3.1 ms).
This new design will allow us to also attach other consumers, e.g. a
new baseline compiler.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
Reviewed-on: https://chromium-review.googlesource.com/571010
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47671}
