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}
Reason for revert:
Speculative revert due to canary crashes.
BUG=chromium:708339,chromium:707790
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: dbb1cbe3a8TBR=mlippautz@chromium.org,hpayer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2800923004
Cr-Commit-Position: refs/heads/master@{#44459}
This fixes behavior for HeapNumber {index} arguments passed to
AdvanceStringIndex.
Previously, we'd blindly treat {index} as a Smi. Passing a HeapNumber instead
would result in a Smi addition on the tagged HeapNumber pointer.
BUG=chromium:709015
Review-Url: https://codereview.chromium.org/2798933003
Cr-Commit-Position: refs/heads/master@{#44458}
In predictable mode DoSync and DoAsync are only normal
function calls. Therefore I had to do some adjustments
to async compilation to make it work with --predictable:
* I moved all calls to DoSync and DoAsync out of
DisallowHandleAllocation and DisallowHeapAllocation
scopes.
* I turned off the use of the semaphore which
synchronizes the background compilation tasks with
the main thread. It caused a deadlock.
* Adjust when the AsyncCompileJob is deleted, namely
after the start function and not after the execution
of the last compilation task. The reason is that in
predictable mode all previous tasks are still on the
stack after the last compilation task.
Bug:
Change-Id: I2f96f64febeee6b8bd5f4da3cec882797d249400
Reviewed-on: https://chromium-review.googlesource.com/469610
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44456}
The actual value was always &-ed with 0 so technically correct. ASAN
rightfully complains when allocating an external bitmap though.
BUG=chromium:651354
R=ulan@chromium.org
Review-Url: https://codereview.chromium.org/2799283002
Cr-Commit-Position: refs/heads/master@{#44453}
This CL fixes two more cases in which a regexp could unintentionally transition
to slow mode while on the fast path, leading to possible OOB accesses of
lastIndex.
In both cases, the fix is to re-check the shape and possibly bail to runtime.
BUG=chromium:708247,v8:6210
Review-Url: https://codereview.chromium.org/2803603005
Cr-Commit-Position: refs/heads/master@{#44451}
This reverts commit 9461fe249e.
Reason for revert: Breaks a test in Node.js:
parallel/test-util-inspect
=== release test-util-inspect ===
Path: parallel/test-util-inspect
#
# Fatal error in , line 0
# unreachable code
#
==== C stack trace ===============================
Original change's description:
> [builtins] don't inline calls for common Promise ops in async builtins
>
> 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: I3349d0f0353a72270ae40b974312d64d1c8a9e46
> Reviewed-on: https://chromium-review.googlesource.com/461269
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44445}
TBR=mstarzinger@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,v8-reviews@googlegroups.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5855
Change-Id: Iabcdf8b025cc9b053a858f8e74389638ac000ba0
Reviewed-on: https://chromium-review.googlesource.com/469946
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44448}
Currently we initialize the allocated buffer to be full of 0s, which
adds significant overhead.
TypedArrayConstructByArrayLike will always either fully initialize the
buffer, or throw an exception, in which case the buffer will not be
leaked to user code.
The length of the new TypedArray (and thus the buffer) is derived from
the length of the source Array/TypedArray, so we know that we will
always set every byte of the new buffer, or throw trying.
Bug:v8:5977
Change-Id: I8ceaa883cfad85f8708a5bdaada3ce463d97e007
Reviewed-on: https://chromium-review.googlesource.com/469348
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44447}
To avoid running infinitely or hitting the stack size limit, bound the
number of steps to execute in the interpreter to 16k.
R=ahaas@chromium.org
BUG=chromium:708457
Change-Id: Ib101bbbc06627641dae2fd1cd1a8d950aa504eaf
Reviewed-on: https://chromium-review.googlesource.com/469609
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44446}
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: I3349d0f0353a72270ae40b974312d64d1c8a9e46
Reviewed-on: https://chromium-review.googlesource.com/461269
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44445}
Doing so will increase the likelyhood of getting the interesting code objects
into the mindump.
Change-Id: I6c6d06bbfe7ab8649139b1146bda0f9b3d679064
Reviewed-on: https://chromium-review.googlesource.com/468967
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44444}
The Run() method ran in chunks of {kRunSteps} steps till completion or
breakpoint, while Step() executed exactly one step.
This CL removes the {kRunSteps} concept, and instead allows to pass the
number of steps to run to the Run() method. Step() just calls Run(1).
R=ahaas@chromium.org
BUG=chromium:708457,v8:5822
Change-Id: I03f7f4da4e0d0e72337399206f1c49ff0f1f041a
Reviewed-on: https://chromium-review.googlesource.com/469846
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44443}
It's not necessary at finalization, and may be obtained from
the shared, native object.
BUG=
Review-Url: https://codereview.chromium.org/2804863002
Cr-Commit-Position: refs/heads/master@{#44441}
Make Ignition collect BinaryOperationFeedback on ToNumber, using the
shared type feedback slot with the following Inc/Dec bytecode, and use
this feedback in TurboFan to turn the ToNumber(x) operation into a
SpeculativeNumberMultiply(x,1) with the feedback hint.
R=jarin@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=v8:6214,v8:5267
Review-Url: https://codereview.chromium.org/2804813003
Cr-Commit-Position: refs/heads/master@{#44440}
