Instead of storing {start} and {error_pc} we now store the
{error_offset}, which is anyways the only value we use.
R=clemensh@chromium.org
Change-Id: Ifd9791eff5c9efce2e7e2a1989bf3b5eaa464a02
Reviewed-on: https://chromium-review.googlesource.com/471527
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44510}
This is inital work in order to utilize CompilerDispatcher in parallel
parsing.
BUG=v8:6093
Change-Id: I6aae4f32ddb2314585d09039c1c5d7e658dc896f
Reviewed-on: https://chromium-review.googlesource.com/469709
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#44509}
The spec requires that we use IterableToList, which we skipped for
some arrays as an optimization. We can't skip this for arrays with
objects though, because the objects may mutate the array during
the copying step via valueOf side effects.
Also clean up the implementation to use a runtime function rather
than a builtin as the helper. Also reverses the result of the helper
because I think it is a bit more intuitive that way.
Bug: v8:6224
Change-Id: I9199491abede4479785df6d9068331bc2d6e9c5e
Reviewed-on: https://chromium-review.googlesource.com/471986
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44507}
The Generic access info was introduced to handle transitioning stores
that extend the properties backing store (by reusing the STORE_IC). But
since crrev.com/2778133003 TurboFan handles these by just inlining the
properties backing store (re)allocation, and thus this is now dead code.
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2811593002
Cr-Commit-Position: refs/heads/master@{#44505}
We don't need to do any kind of translation for non-wasm frames. And we need this knowledge for lazy symbolization.
Capturing stack trace is ~7% faster.
BUG=v8:6189
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2795103004
Cr-Commit-Position: refs/heads/master@{#44502}
On those architectures that do support unaligned memory access
there is no need to emit heap alignment code in TypedArrayInitialize.
BUG=chromium:708545
Review-Url: https://codereview.chromium.org/2802003003
Cr-Commit-Position: refs/heads/master@{#44501}
This revealed a bug in the TypedArray(typedArray) constructor when the arg is backed by a SharedArrayBuffer.
Also install the species getter and add a test, since it's not tested in
test262 presently.
BUG=v8:5983,v8:5984
R=adamk@chromium.org
Review-Url: https://codereview.chromium.org/2798403004
Cr-Commit-Position: refs/heads/master@{#44500}
TurboFan didn't support transitioning stores that also need to grow the
properties backing store so far. This CL adds support for re-allocating
the properties backing store in-place, so these stores can participate
properly in various optimizations like escape analysis and allocation
folding.
R=ishell@chromium.org
BUG=v8:5267,chromium:708339
Review-Url: https://codereview.chromium.org/2778133003
Cr-Original-Commit-Position: refs/heads/master@{#44183}
Committed: 88a7061a53
Review-Url: https://codereview.chromium.org/2778133003
Cr-Commit-Position: refs/heads/master@{#44499}
This reverts commit 88a7061a53 (with
one manually-resolved merge conflict).
It caused a spike of GC crashes on Canary.
TBR=bmeurer@chromium.org
Bug: chromium:708339, v8:5267
Change-Id: I8a5683bbdfb61c95d81a2ee7cdb913f39e553093
Reviewed-on: https://chromium-review.googlesource.com/471928
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44496}
Includes a drive-by fix to a couple of superficial Intl changes
With this roll, test262 starts to look at test262 feature
flags to determine which harmony flags to turn on. There's
still more to do, including adding feature flags to existing
upstream tests and taking advantage of more flags here.
Change-Id: I9cb813e0450be9dc7769ac9c601092bd3572556f
Reviewed-on: https://chromium-review.googlesource.com/471546
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44495}
This reverts commit 61df2d90a9.
The CL was speculatively reverted due to canary crashes, which turned
out to be caused by another CL.
Original issue's description:
> [heap] Remove size specializations in static object visitors.
>
> Apart from that this patch adds kVisitJSObjectFast for JSObjects that
> do not have any unboxed double fields and can be visited without
> run-time layout check.
>
> BUG=chromium:694255
>
> Review-Url: https://codereview.chromium.org/2763413007
> Cr-Commit-Position: refs/heads/master@{#44237}
> Committed: dbb1cbe3a8
Review-Url: https://codereview.chromium.org/2808533002
Cr-Commit-Position: refs/heads/master@{#44494}
The format of the name section changed recently. It now contains
subsections of different type (currently for function names or local
variable names).
This CL changes our internal wasm module builders (in JS and C++) to
emit this new format, and changes the decoder to understand it.
We currently only parse the function name section, and ignore names of
local variables. I will later extend this to parse local variable names
when needed for debugging.
R=ahaas@chromium.org, rossberg@chromium.org
BUG=v8:6222
Change-Id: I2627160c25c9209a3f09abe0b88941ec48b24434
Reviewed-on: https://chromium-review.googlesource.com/470247
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44492}
... by avoiding reads through timer objects allocated on stack of another thread and
explicitly maintaining current RuntimeCallCounter object in RuntimeCallStats instead.
Change-Id: I54eaf078dc1e77dc47ded963903d54ffb583f377
Reviewed-on: https://chromium-review.googlesource.com/471667
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44491}
Split TFS builtins into
* TFC: TF builtins with stub linkage that use a custom interface descriptor
(e.g. because of a non-standard return size or untagged arguments)
* TFS: the rest.
Automatically generate interface descriptors for TFS builtins to reduce
boilerplate involved in setting up stub calls. These are now as simple as
creating the TFS stub and using CSA::CallBuiltin, no extra work required.
BUG=v8:6116
Review-Url: https://codereview.chromium.org/2777203007
Cr-Commit-Position: refs/heads/master@{#44490}
and out of the main library. This saves about 5% of binary size
(800KB on x64, 373KB on android_arm).
Only the GN build is supported; the GYP build is maintained working
but does not support the feature.
Previously landed as 4782bc0df8 / r44412.
BUG=v8:6055
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel;
Review-Url: https://codereview.chromium.org/2760233005
Cr-Commit-Position: refs/heads/master@{#44489}
This reverts commit d3e9aade0f.
Reason for revert: Speculative for:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/4449
Bisect points to this CL.
Original change's description:
> [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator.
>
> Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi
> literals in the BytecodeGenerator. This enables us to perform the
> transformation for literals on either side for commutative operations, and
> Avoids having to do the check on every bytecode in the peephole optimizer.
>
> In the process, adds Smi bytecode variants for all binary operations, adding
> - MulSmi
> - DivSmi
> - ModSmi
> - BitwiseXorSmi
> - ShiftRightLogical
>
> BUG=v8:6194
>
> Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219
> Reviewed-on: https://chromium-review.googlesource.com/466246
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44477}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,ishell@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6194
Change-Id: If57dbdbe40be77804bf437463b855d3167e2d473
Reviewed-on: https://chromium-review.googlesource.com/471308
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44488}
The spec requires truncation while ToUint32 originally rounded down.
This also adds a bunch of test cases to check edge case behavior.
BUG=v8:6212
Review-Url: https://codereview.chromium.org/2805783003
Cr-Commit-Position: refs/heads/master@{#44487}
The LoadElimination (and potentially earlier passes too) might have
removed or lowered side-effecting operations, which allows for further
combining of check points in the graph, removing unnecessary StateValue
uses for the later truncation analysis.
BUG=chromium:709398
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2807563002
Cr-Commit-Position: refs/heads/master@{#44486}
The serializer already has code that special cases for some external
strings. We can handle all external strings in one place instead of
splitting the logic between the serializer and the object visitor.
The main benefit is that we remove two virtual functions from the
ObjectVisitor and thus simplify it for all other users.
BUG=chromium:709075
Review-Url: https://codereview.chromium.org/2799943002
Cr-Commit-Position: refs/heads/master@{#44485}
Add a dedicated operator for ToNumber(x) with feedback instead of
translating to SpeculativeNumberMultiply(x,1), which allows us to
treat the case where x is already a Number specially, ignoring the
feedback on the operator. This recovers most of the regression in
the crypto benchmark.
BUG=chromium:709398,v8:6214,v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2802113003
Cr-Commit-Position: refs/heads/master@{#44484}
InternalResolvePromise, InternalPromiseReject and
InternalPerformPromiseThen generate quite a lot of code.
This change adds 3 new TF stubs which inline calls to these builtins.
These stubs are invoked rather than inlining those operations listed
above directly. This is done for Async Iteration builtins, as well as
Async Function builtins. Promise builtins are left as they were, and
continue to inline these calls.
This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
release build.
BUG=v8:5855
R=gsathya@chromium.org, jgruber@chromium.org
Change-Id: I83e2f096782db685fe316dd071980cd8d696fe53
Reviewed-on: https://chromium-review.googlesource.com/469927
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44483}
To avoid the need for including list-inl.h when you include spaces.h
Review-Url: https://codereview.chromium.org/2806493002
Cr-Commit-Position: refs/heads/master@{#44481}
Reason for revert:
Doesn't really move the needle, but tanks Kraken/imaging-gaussian-blur (crbug.com/709396), so reverting for now.
Original issue's description:
> [turbofan] Better representation selection for comparison with Float64.
>
> For speculative number comparisons with SignedSmall feedback, we always
> enforce either TaggedSigned or Word32 comparisons. But this is not
> really beneficial if one of the inputs is already in Float64
> representation; in that case it's cheaper to just convert the other
> input to a Float64.
>
> R=jarin@chromium.org
>
> Review-Url: https://codereview.chromium.org/2790833004
> Cr-Commit-Position: refs/heads/master@{#44327}
> Committed: 8af394d6d3TBR=jarin@chromium.org
BUG=chromium:709396
Review-Url: https://codereview.chromium.org/2801233002
Cr-Commit-Position: refs/heads/master@{#44480}
Rather than doing nop elision in the peephole optimizer, be smarter about
emitting nops for elided register transfers in the bytecode optimizer.
BUG=v8:6194
Change-Id: Ib1a7168a0d143e4f2da7c6d43080998793c30822
Reviewed-on: https://chromium-review.googlesource.com/468929
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44479}
Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi
literals in the BytecodeGenerator. This enables us to perform the
transformation for literals on either side for commutative operations, and
Avoids having to do the check on every bytecode in the peephole optimizer.
In the process, adds Smi bytecode variants for all binary operations, adding
- MulSmi
- DivSmi
- ModSmi
- BitwiseXorSmi
- ShiftRightLogical
BUG=v8:6194
Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219
Reviewed-on: https://chromium-review.googlesource.com/466246
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44477}
This removes one virtual function from ObjectVisitor.
BUG=chromium:709075
Review-Url: https://codereview.chromium.org/2798923004
Cr-Commit-Position: refs/heads/master@{#44476}
The WebIDL spec expects iterator objects from interfaces that declare pair
iterators to ultimately inherit from %IteratorPrototype%. Expose the
intrinsic object in the public API so we can use it in Blink's bindings
code.
BUG=chromium:689576
R=caitp@igalia.com,jkummerow@chromium.org,jochen@chromium.org
Review-Url: https://codereview.chromium.org/2784543004
Cr-Commit-Position: refs/heads/master@{#44472}
This gives us more precise type information, so we can avoid some type
guards to refine the type information back.
The motivation for this is to help escape analysis by not introducing
redundant type guards (which escape analysis cannot handle yet even
though it could and should do).
Motivating example:
In the example below, the out-of-object property array for properties
fld5 and fld6 gets type Any when it is created by "o.fld5 = 5" (for
object literals, we store 4 properties in-objeca, the rest goes out
of object).
When we run load elimination for the load the out-of-object property
array (to store 6 into o.fld6), load elimination inserts TypeGuard to
enforce the Type::Internal() type. This makes escape analysis bail out
on this object, and we do not eliminate the object creation.
function f() {
var o = {};
o.fld1 = 1;
o.fld2 = 2;
o.fld3 = 3;
o.fld4 = 4;
o.fld5 = 5;
o.fld6 = 6;
}
f();
f();
%OptimizeFunctionOnNextCall(f);
f();
Review-Url: https://codereview.chromium.org/2797993006
Cr-Commit-Position: refs/heads/master@{#44470}
FinishCompilationUnits used the assumption that FinishCompilationUnit
only return null if there is no compilation unit left to be finished.
This assumption was wrong though, because also a compilation error can
cause the result to be null. Therefore I switched to use the function
index as a new indicator.
BUG=chromium:709174
Change-Id: I3e9689fd71b8364422e1c74404921df2799191aa
Reviewed-on: https://chromium-review.googlesource.com/471347
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44468}
This ensures that capture names containing surrogate pairs are parsed
correctly even in non-unicode RegExp patterns by introducing a new
scanning mode which unconditionally combines surrogate pairs.
BUG=v8:5437,v8:6192
Review-Url: https://codereview.chromium.org/2791163003
Cr-Commit-Position: refs/heads/master@{#44466}
Port of http://crrev.com/2805613002 in TurboFan to Crankshaft.
We have a weird performance cliff, where using an object literal for
allocation is way slower than using a constructor function, or starting
from the empty object literal and using transitioning stores. The reason
is that we limit the inlining of object literal nodes into Crankshaft
to max. 8 fast properties. So as soon as you get above 8, you'll get a
runtime function call to %CreateObjectLiteral, which is a lot slower
than the inlined allocation and initialization. Still not ideal, but
less unpredictable (hopefully).
TBR=jarin@chromium.org
BUG=v8:6211
Review-Url: https://codereview.chromium.org/2800053002
Cr-Commit-Position: refs/heads/master@{#44464}
