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}
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}
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}
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}
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}
SetForceInlineFlag is now only used in tests. Earlier, it was also used
in js builtins, because unless this flag was specified the js builtins
were not inlined. All the performance critical js builtins are moved
to turbofan builtins and SetForceInlineFlag is no longer used. We would
like to remove this flag completely to simplify inlining heuristics.
Also, this uses a bit on the SharedFuntionInfo.
Bug: v8:6682
Change-Id: I19afd27381afc212f29179f2c5477095c8174f39
Reviewed-on: https://chromium-review.googlesource.com/660739
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47997}
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}
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}
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}
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}
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}
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}
This change prevents constant folding of uninhabited RefenceEqual node
because that could widen a type (from None type to the type of the
boolean constant).
Hopefully, this is a temporary workaround that will be replaced
by a better dead code elimination.
Bug: v8:6631
Change-Id: Ie25e7d710aaf1d37c9adba60f92438570843dd5d
Reviewed-on: https://chromium-review.googlesource.com/627916
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47545}
This is in preparation to the removal of the FullCodeGenerator, we no
longer need the ability to stress the underlying implementation.
R=rmcilroy@chromium.org
BUG=v8:6409
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Iad3177d6de4a68b57c12a770b6e85ed7a9710254
Reviewed-on: https://chromium-review.googlesource.com/584747
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47276}
With TurboFan, there should no longer be any deopt loops (aside from
bugs). So, the "too many deopts" bailout is no longer needed, at least
in its current form.
This fixes an issue where deopt counts are leaked between native
contexts, resulting in optimization being disabled unnecessarily.
Bug: v8:6402
Change-Id: Ia06374ae6b5c2d473bcdd8eef1284bf02766c2fb
Reviewed-on: https://chromium-review.googlesource.com/588894
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46961}
Adding (very) small tests for deoptimization.
Some of these tests were failing when the safepoints were not found,
after setting the return address.
BUG=V8:6563
Change-Id: I3af36b193a5982cd73414cc1884c5f0a7a727f5a
Reviewed-on: https://chromium-review.googlesource.com/584751
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Cr-Commit-Position: refs/heads/master@{#46922}
Reland of https://chromium-review.googlesource.com/c/543042/.
Now the OSR phase is only used when OSRing from the ast graph builder.
When OSRing from Turbofan, the implementation is now in the graph
building phase, at the beginning of the VisitBytecode function.
We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
nor nodes for the possible code of the OSRed function which is before
the OSRed loops.
The trimming and reducing of the OSR phase is not done either. This
change in the way the way the OSR is done enabled to remove the
workaround to the bug mentioned below.
Bug: v8:6112
Bug: v8:6518
Change-Id: Ia02f2138f54fc79cab2f02fed68d9bb522d6ce14
Reviewed-on: https://chromium-review.googlesource.com/584756
Commit-Queue: Alexandre Talon <alexandret@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46899}
This reverts commit 69c8f16da7.
Reason for revert: Causing crashes on Clusterfuzz - http://crbug.com/747154
BUG=chromium:747154
Original change's description:
> [Turbofan] Merged the OSR phase into the graph building phase.
>
> Now the OSR phase is only used when OSRing from the ast graph builder.
> When OSRing from Turbofan, the implementation is now in the graph
> building phase, at the beginning of the VisitBytecode function.
> We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
> nor nodes for the possible code of the OSRed function which is before
> the OSRed loops.
>
> The trimming and reducing of the OSR phase is not done either. This
> change in the way the way the OSR is done enabled to remove the
> workaround to the bug mentioned below.
>
> Bug: v8:6112
> Bug: v8:6518
> Change-Id: I1c9231810b923486d55ea618d550d981d695d797
> Reviewed-on: https://chromium-review.googlesource.com/543042
> Commit-Queue: Alexandre Talon <alexandret@google.com>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46801}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,alexandret@google.com
Change-Id: Ifa9bf5d86e888a47cad7fb10446b36fda5029604
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6112, v8:6518
Reviewed-on: https://chromium-review.googlesource.com/581288
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46817}
Now the OSR phase is only used when OSRing from the ast graph builder.
When OSRing from Turbofan, the implementation is now in the graph
building phase, at the beginning of the VisitBytecode function.
We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
nor nodes for the possible code of the OSRed function which is before
the OSRed loops.
The trimming and reducing of the OSR phase is not done either. This
change in the way the way the OSR is done enabled to remove the
workaround to the bug mentioned below.
Bug: v8:6112
Bug: v8:6518
Change-Id: I1c9231810b923486d55ea618d550d981d695d797
Reviewed-on: https://chromium-review.googlesource.com/543042
Commit-Queue: Alexandre Talon <alexandret@google.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46801}
Inlining heuristics in Turbofan used ast node count. Bytecode size
is a better approximation of the size of the graph than the
ast node count. This cl changes the heuristics to use the bytecode
size instead. Also removing the ast_node_count filed in the shared
function info. It was used only for the inlining heuristics.
Also removed the max_inlined_source_size flag which is no longer used.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I8a2d2509c8e8d2779b33b817bb217de203d54ec3
Reviewed-on: https://chromium-review.googlesource.com/570055
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46771}
There remained a few of regressions and we didn't see any significant
improvement in the real world with this turned on. This CL reverts all the
StringConcat bytecode work which landed.
BUG=v8:6243
Change-Id: I832eb72e880ad41411dbec8fe29f71ef0f2025c8
Reviewed-on: https://chromium-review.googlesource.com/575130
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46769}
The tail call implementation is hidden behind the --harmony-tailcalls
flag, which is off-by-default (and has been unstaged since February).
It is known to be broken in a variety of cases, including clusterfuzz
security issues (see sample Chromium issues below). To avoid letting
the implementation bitrot further on trunk, this patch removes it.
Bug: v8:4698, chromium:636914, chromium:724746
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c
Reviewed-on: https://chromium-review.googlesource.com/569069
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46651}
These are no longer necessary since we only have one optimizing compiler.
Also avoid changing --turbo-filter when --no-opt is set, and instead
explicitly check both the FLAG_opt and FLAG_turbo_filter in
GetOptimizedCode to check whether optimization is disabled.
BUG=v8:6408
Change-Id: I0948f788e8ff111c08022270d86c22f848da300a
Reviewed-on: https://chromium-review.googlesource.com/568484
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46648}
Removes the --ignition flag which is now on by default. Adds a
--stress-fullcodegen flag which enables running all functions supported
by fullcodegen to be compiled by fullcodegen.
This will enable moving parser internalization later when we are not
stressing fullcodegen or compiling asm.js functions.
BUG=v8:5203, v8:6409, v8:6589
Change-Id: I7fa68016d4e734755434ec0b4e749ef65ffa7f4e
Reviewed-on: https://chromium-review.googlesource.com/565569
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46635}
By creating the boilerplate only on the second instantiation we cannot
propagate back the elements transitions early enough. The resulting literals
would change the initial ElementsKind one step too late and already pollute
ICs that went to monomorphic state.
- Disable lazy AllocationSites for literals containing arrays
- Introduce new ComplexLiteral class to share code between ObjectLiteral
and ArrayLiteral
- RegexpLiteral now no longer needs a depth_ field
Bug: v8:6517, v8:6519, v8:6211
Change-Id: Ia88d1878954e8895c3d00a7dda8d71e95bba005c
Reviewed-on: https://chromium-review.googlesource.com/563305
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46603}
Adds constant folding for the StringConcat bytecode to
NativeContextSpecialization. Can reduce operator to either a fully folded
constant string, or a JSAdd or a StringConcat with a reduced number of
operators.
BUG=v8:6243, chromium:738312
Change-Id: I6b2be6a3d95230a23f3c7390a4f7be5181c49a2a
Reviewed-on: https://chromium-review.googlesource.com/559146
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46461}
This mostly reverts commit c503b80595 but fixes
an issue where literals would always be pretenured on first instantiation.
As a cleanup we pass in a PretenureFlag instead of using the FeedbackVector as
indicator.
Bug: v8:6211
Change-Id: Id328552620e33f5083519bcba1e24396d162d516
Reviewed-on: https://chromium-review.googlesource.com/555670
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46342}
This adds support for lowering of nodes having the {JSToObject} operator
even if they have exceptional control projections (e.g. are inside of a
try-block).
R=bmeurer@chromium.org
TEST=mjsunit/compiler/optimized-with
Change-Id: I711ff4935db68c43243a971a8b21989487c86317
Reviewed-on: https://chromium-review.googlesource.com/554628
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46318}
This adds support for lowering of nodes having the {JSCreateArray}
operator even if they have exceptional control projections (e.g. are
placed inside a try-block).
R=mvstanton@chromium.org
TEST=mjsunit/compiler/array-constructor
Change-Id: I2fe34dbb3729b4763471f2638a960b01c531c038
Reviewed-on: https://chromium-review.googlesource.com/554732
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46315}
Adds a CheckString to all operand inputs of JSStringConcat. The operands are
already known to be strings, so this will get eliminated in almost all cases,
however, if there is a yield within the concatenation then we lose the
knowledge that the previous operands are strings since the values are loaded
from the generator object. Adds a test for this case.
BUG=v8:6243
Change-Id: I1601a316e6efbed1c53486f1027cb0ea023ff030
Reviewed-on: https://chromium-review.googlesource.com/549301
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46243}
This removes the --turbo flag and solely relies on the filter pattern
provided via --turbo-filter when deciding whether to use TurboFan. Note
that disabling optimization wholesale can still be done with --no-opt,
which should be used in favor of --no-turbo everywhere.
Also note that this contains semantic changes to the TurboFan activation
criteria. We respect the filter pattern more stringently and no longer
activate TurboFan just because the source contains patterns forcing use
of Ignition via {AstNumberingVisitor::DisableFullCodegenAndCrankshaft}.
R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I0c855f6a62350eb62283a3431c8cc1baa750950e
Reviewed-on: https://chromium-review.googlesource.com/528121
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46167}
Adds typed lowering of JSStringConcat to ConsString allocation if the
following conditions hold:
- All concatinations will result in a ConsString of >= ConString::kMinLength
- No concatinations will result in a empty string in the RHS unless there is
a sequential string in the LHS.
This also means JSStringConcat needs an eager checkpoint since it can
deopt if throwing a RangeError when the string length protector is valid.
BUG=v8:6243
Change-Id: I01ca79f884df467c10f2c032c72d51b5199c1a3c
Reviewed-on: https://chromium-review.googlesource.com/526636
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46093}
Add a new JSConstructWithArrayLike operator that is backed by the
ConstructWithArrayLike builtin (similar to what was done before
for the JSCallWithArrayLike operator), and use that operator to
optimize Reflect.construct inlining in TurboFan. This is handled
uniformly with JSConstructWithSpread in the JSCallReducer.
Also add missing test coverage for Reflect.construct in optimized
code, especially for some interesting corner cases.
R=petermarshall@chromium.org
BUG=v8:4587,v8:5269
Review-Url: https://codereview.chromium.org/2949813002
Cr-Commit-Position: refs/heads/master@{#46087}
Add a new JSCallWithArrayLike operator that is backed by the
CallWithArrayLike builtin, and use that operator for both
Function.prototype.apply and Reflect.apply inlining. Also unify
the handling of JSCallWithArrayLike and JSCallWithSpread in
the JSCallReducer to reduce the copy&paste overhead.
Drive-by-fix: Add a lot of test coverage for Reflect.apply and
Function.prototype.apply in optimized code, especially for some
corner cases, which was missing so far.
BUG=v8:4587,v8:5269
R=petermarshall@chromium.org
Review-Url: https://codereview.chromium.org/2950773002
Cr-Commit-Position: refs/heads/master@{#46041}
We can remove a lot of native code and rely on CallOrConstructVarargs
to do the stack manipulation for us.
This will also take advantage of the fast-path for double arrays in
CallOrConstructDoubleVarargs.
We can also remove Runtime_SpreadIterableFixed because it isn't used
anymore. We just call directly into spread_iterable from CSA.
Bug: v8:6488, chromium:704966
Change-Id: I81a18281f062619851134fff7ce88471566ee3b5
Reviewed-on: https://chromium-review.googlesource.com/535615
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46038}
Storing the boilerplate on the first run leads to memory ovehead for code
that is run only once. Hence we directly return the creating literal on the
first run and only start creating copies from the second run on.
Bug: v8:6211
Change-Id: I69b96d124a5b594b991fdbcc76dbf935d973ffad
Reviewed-on: https://chromium-review.googlesource.com/530688
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45975}
Port the baseline implementation of Object.prototype.isPrototypeOf to
the CodeStubAssembler, sharing the existing prototype chain lookup logic
with the instanceof / OrdinaryHasInstance implementation. Based on that,
do the same in TurboFan, introducing a new JSHasInPrototypeChain
operator, which encapsulates the central prototype chain walk logic.
This speeds up Object.prototype.isPrototypeOf by more than a factor of
four, so that the code
A.prototype.isPrototypeOf(a)
is now performance-wise on par with
a instanceof A
for the case where A is a regular constructor function and a is an
instance of A.
Since instanceof does more than just the fundamental prototype chain
lookup, it was discovered in Node core that O.p.isPrototypeOf would
be a more appropriate alternative for certain sanity checks, since
it's less vulnerable to monkey-patching. In addition, the Object
builtin would also avoid the performance-cliff associated with
instanceof (due to the Symbol.hasInstance hook), as for example hit
by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
The main blocker was the missing performance of isPrototypeOf, since
it was still a JS builtin backed by a runtime call.
This CL also adds more test coverage for the
Object.prototype.isPrototypeOf builtin, especially when called from
optimized code.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
BUG=v8:5269,v8:5989,v8:6483
R=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2934893002
Cr-Commit-Position: refs/heads/master@{#45925}
This takes into account the type of the type guard when choosing
representation for a node. To make the representation changes
unambiguous, we pass the restricted type to the changer.
BUG=chromium:726554
Review-Url: https://codereview.chromium.org/2920193004
Cr-Commit-Position: refs/heads/master@{#45734}
Previously Ignition would collect precise Number feedback for binary
operators, but TurboFan would just ignore that and treat it the same as
NumberOrOddball. That however generates a lot of unnecessary code, plus
it defeats redundancy elimination if the same input is also used by
compare operations, which do properly distinguish feedback Number and
NumberOrOddball.
This CL adds the missing bits to connect the existing functionality
properly, i.e. adding the missing BinaryOperationHint and using the
NumberOperationHint::kNumber in the representation selection for tagged
inputs.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2923543003
Cr-Commit-Position: refs/heads/master@{#45732}
Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole
/ ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks.
In the bytecode-graph builder they are handled by introducing a deopt point
instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant
bytecodes are removed since they are no longer required.
Bug: v8:4280, v8:6383
Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1
Reviewed-on: https://chromium-review.googlesource.com/509613
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45720}
When the input to Function.prototype.bind is a known function, we can
inline the allocation of the JSBoundFunction into TurboFan, which
provides a 2x speed-up for several hot functions in Node streams (as
discovered by Matteo Collina). One of example of this can be found in
https://github.com/nodejs/node/pull/13322, which can be optimized and
made more readable using bind instead of closures.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2916063002
Cr-Commit-Position: refs/heads/master@{#45679}
This fixes an issue with ful-codegen where code target entries for the OSR
check were being incorrectly shared. We now explicitly disable sharing of code
target constant pool entries for full-codegen and for calls to builtins from
WASM code, using a scope.
BUG=chromium:725743
Review-Url: https://codereview.chromium.org/2922433002
Cr-Commit-Position: refs/heads/master@{#45661}
Previously the inlining of accessors into try-blocks (i.e. try/catch,
try/finally, for-of, etc.) was disabled in JSNativeContextSpecialization,
which prevented a couple of interesting optimizations, i.e. we end up
with a LOAD_IC in optimized code for this simple example:
class A { get x() { return 1; } }
function foo(a) {
try {
return a.x;
} catch (e) {
return 0;
}
}
foo(new A)
This is now fixed and the accessors are properly rewired into the
handler chain.
BUG=v8:6278,v8:6344,v8:6424
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2902533003
Cr-Commit-Position: refs/heads/master@{#45485}
When a virtual object passes by a store node that updates a field to the existing value, then the object and its state were not copied, which lead to the original object being passed on.
If then later the store actually modifies and copies the virtual object, this new copy is not passed down the effect chain, so subsequent nodes still refer to the original virtual object and try to update it once new information flows in.
This conflicts with updates on the node that originally created the virtual object, leading to divergence.
Bug: v8:6345
Change-Id: Iab1ce98a60b48478b343eae765c80bdfcb8ba390
Reviewed-on: https://chromium-review.googlesource.com/496267
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45120}
1. Replaces --crankshaft with --opt in tests.
2. Also fixes presubmit to check for --opt flag when
assertOptimized is used.
3. Updates testrunner/local/variants.py and
v8_foozie.py to use --opt flag.
This would mean, nooptimize variant means there are
no optimizations. Not even with %OptimizeFunctionOnNextCall.
Bug:v8:6325
Change-Id: I638e743d0773a6729c6b9749e2ca1e2537f12ce6
Reviewed-on: https://chromium-review.googlesource.com/490206
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44985}
This also fixes incorrect type for fixed array accesses.
BUG=chromium:715651,v8:6309,chromium:715204
Review-Url: https://codereview.chromium.org/2848583002
Cr-Commit-Position: refs/heads/master@{#44926}
This still doesn't cover all the paths yet, since some paths are
impossible to trigger at this point due to the way the CanInlineCall
predicate works on the AllocationSite, which says multiple things:
- In case of Array(len), the len was always a Smi so far.
- In case of Array(...args), storing the args didn't change the
elements kind.
- In case of Array(len), the len was always less than the initial
maximum fast element array size.
These conditions are tailored towards Crankshaft and don't really
make a lot of sense in the TurboFan world. We'd need more fine
grained protections, which we will achieve by refactoring the Array
constructor.
BUG=chromium:715404,v8:6262
TBR=machenbach@chromium.org
Review-Url: https://codereview.chromium.org/2843033002
Cr-Commit-Position: refs/heads/master@{#44901}
Also add more local variables to regress-v8-6077 to force
register spill on platform with 32 float registers.
BUG=
Review-Url: https://codereview.chromium.org/2822073003
Cr-Commit-Position: refs/heads/master@{#44865}
We already have an optimization to constant-fold access to an object's
prototype via the special __proto__ accessor (specified in appendix B).
We can use the same optimization to also constant-fold accesses to an
object's prototype via the official Object.getPrototypeOf function.
Also add the optimization for Reflect.getPrototypeOf, which is
equivalent for object inputs.
This is commonly used by Babel to implement various new language
features, for example subclassing and certain property lookups.
R=yangguo@chromium.org
BUG=v8:6292
Review-Url: https://codereview.chromium.org/2841463002
Cr-Commit-Position: refs/heads/master@{#44788}
Move JSOrdinaryHasInstance lowering to JSNativeContextSpecialization,
which was previously mostly done in JSTypedLowering (for no reason).
Add new logic to the lowering to constant-fold OrdinaryHasInstance
checks when the map of the left-hand side and the "prototype" of the
right-hand side is known. This address the performance issue with the
(base) class constructors generated by Babel, i.e.:
function _classCallCheck(instance, Constructor) {
if (!(instance instanceof Constructor)) {
throw new TypeError("Cannot call a class as a function");
}
}
var C = function C() { _classCallCheck(this, C); };
for
class C {}
Also ensure that a known constructor being used inside an instanceof
get's a proper initial map on-demand.
BUG=v8:6275
R=mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2827013002
Cr-Commit-Position: refs/heads/master@{#44727}
Since we no longer support the ignition-staging configuration
any longer, we can retire the three tier pipeline and the
CompileBaseline functionallity.
We still need support for JSFunction self healing due to
liveedit (which for --no-turbo might end up replacing a
forced Ignition function with a FCG function) - we can
remove this once we remove --no-turbo support.
BUG=v8:4280
Change-Id: I5482abd17785324654e022affd6bdb555b19b181
Reviewed-on: https://chromium-review.googlesource.com/452620
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44141}
Test regress-694088.js is adapted for execution on big endian platforms.
TEST=test/mjsunit/compiler/regress-694088.js
BUG=
Review-Url: https://codereview.chromium.org/2739403002
Cr-Commit-Position: refs/heads/master@{#43746}
Now that the --turbo flag is on by default, this implication makes it
impossible to disable the runtime profiler to prevent functions from
being considered hot. Essentially the --nocrankshaft flag was borked.
R=machenbach@chromium.org
Change-Id: I698008b4b69038e8bfab6d8ec3ccf57e2fd71701
Reviewed-on: https://chromium-review.googlesource.com/452619
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43720}
The new NewUnmappedArgumentsElements node now takes two inputs:
- the frame holding the arguments (current frame or arguments adaptor frame)
- the length of the suffix of passed arguments to be copied into the backing store
These inputs are computed with two new node types:
ArgumentsFrame()
ArgumentsLength[formal_parameter_count,is_rest_length](Node* arguments_frame)
The node type NewRestParameterElements can now be expressed with NewUnmappedArgumentsElements and an appropriate length and is thus not needed anymore.
In escape analysis, we lower loads from the length field of NewUnmappedArgumentsElements with its length input and if we find out that no write access to the arguments elements exists, we replace element loads with direct stack access and replace the NewUnmappedArgumentsElements node with a node of the new node type ArgumentsElementsState. This corresponds to an ObjectState node and gets translated into a deoptimizer instruction to allocate the backing store. Together with the already existing deoptimizer support for the actual arguments object/rest parameters, this allows to remove all allocations for arguments objects/rest parameters in this case.
In the deoptimizer, we read the actual parameters from the stack while transforming the static deopt info into TranslatedValue objects.
If escape analysis cannot remove the backing store allocation, NewUnmappedArgumentsElements gets lo
BUG=v8:5726
Review-Url: https://codereview.chromium.org/2692753004
Cr-Commit-Position: refs/heads/master@{#43475}
If the RHS is 0 and we have Smi feedback, speculate that the result (the LHS)
will continue to be in the Unsigned31 range. This helps us avoid converting
the result to double when merging with Signed32.
R=jarin@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2709423002
Cr-Commit-Position: refs/heads/master@{#43415}
This implements the proposal at
https://github.com/tc39/proposal-template-literal-revision
staged behind a flag --harmony-template-escapes. The proposal allows
invalid octal, unicode, and hexadecimal escape sequences to appear in
tagged template literals, instead of being a syntax error. These have
a 'cooked' value of 'undefined', but are still accessible through the
'raw' property.
BUG=v8:5546
Review-Url: https://codereview.chromium.org/2665513002
Cr-Commit-Position: refs/heads/master@{#43384}
This CL includes runtime and IC parts of the tracking. It is controlled by
compile-time flag FLAG_constant_field_tracking and currently disabled.
Transition from kConst to kMutable still involves map deprecation.
BUG=v8:5495
Review-Url: https://codereview.chromium.org/2598543003
Cr-Commit-Position: refs/heads/master@{#43081}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
This avoids using kTaggedSigned and kTaggedPointer because the
semantic information of those type could be invalid in unreachable
code.
For example, SmiCheck(0.1) has representation TaggedSigned, but it is
later compiled to DeoptimizeUnless(ObjectIsSmi(0.1)) with the constant
0.1 directly connected to the uses. If the use is state-values, which
recorded the TaggedSigned representation of CheckSmi, the code
generator will be confused because it will see constant 0.1 that
claims to be TaggedSigned value.
BUG=chromium:675704
Review-Url: https://codereview.chromium.org/2656243004
Cr-Commit-Position: refs/heads/master@{#42756}
The mentioned asserts did not work properly with interpreted and turbofanned functions.
To fix this issue %GetOptimizationStatus() now returns a set of flags instead of a single value.
This CL also adds more helper functions to mjsunit, like isNeverOptimize(), isAlwaysOptimize(),
isOptimized(fun), etc.
BUG=v8:5890
Review-Url: https://codereview.chromium.org/2654733004
Cr-Original-Commit-Position: refs/heads/master@{#42703}
Committed: d1ddec7857
Review-Url: https://codereview.chromium.org/2654733004
Cr-Commit-Position: refs/heads/master@{#42731}
This CL adds --crankshaft and --no-always-opt flags to the tests that use
assertOptimized() and assertUnoptimized() respectively.
This CL also adds presubmit checks that ensure that tests have the proper
flags set.
BUG=v8:5890
Review-Url: https://codereview.chromium.org/2653753007
Cr-Commit-Position: refs/heads/master@{#42709}
The mentioned asserts did not work properly with interpreted and turbofanned functions.
To fix this issue %GetOptimizationStatus() now returns a set of flags instead of a single value.
This CL also adds more helper functions to mjsunit, like isNeverOptimize(), isAlwaysOptimize(),
isOptimized(fun), etc.
BUG=v8:5890
Review-Url: https://codereview.chromium.org/2654733004
Cr-Commit-Position: refs/heads/master@{#42703}
JSFrameSpecialization depends on the layout of the frame and doesn't work
with interpreted frames. Disable it since it is only used for OSR from asmjs code, which shouldn't go through the bytecode graph builder in many cases.
BUG=669517
Review-Url: https://codereview.chromium.org/2538823002
Cr-Commit-Position: refs/heads/master@{#41387}
For bound functions on the right-hand side of instanceof we can
constant-fold to the actual [[BoundTargetFunction]], actually
instance OrdinaryHasInstance. Move the Function.prototype[@@hasInstance]
reduction up to the JSCallReducer to allow this optimization to become
effective (and also enable other optimizations).
BUG=v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2537763002
Cr-Commit-Position: refs/heads/master@{#41352}
This introduces three new types OtherCallable, CallableProxy (and OtherProxy),
and BoundFunction to make it possible to express Callable in the Type system.
It also forces all undetectable receivers to be Callable, which matches the
use case for undetectable, namely document.all (guarded by proper checks and
tests).
It also uses these new types to properly optimize instanceof (indirectly via
OrdinaryHasInstance) based on the type of the constructor and the object. So
we are able to constant-fold certain instanceof expressions based on types
and completely avoid the builtin call.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2535753004
Cr-Commit-Position: refs/heads/master@{#41345}
The deprecated pipeline is used for asm.js only, where we forcibly
disable inlining anyways (for performance reasons), so inlining via
the AstGraphBuilder is essentially dead code by now, thus there's no
point in trying to keep that around in the code base.
Also nuke the test-run-inlining.cc file, which would require some heavy
surgery (for probably little benefit), and move the useful tests for
mjsunit tests instead.
BUG=v8:2206,v8:5657
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2527053002
Cr-Commit-Position: refs/heads/master@{#41245}
Adapted various tests to restrictions of inspector protocol:
* osr-typing-debug-change: Don't set function variable value.
* debug-evaluate-locals: Add variable introduced by eval, run typeof
inside evaluate().
* regress-419663: Don't set duplicate breakpoints.
* regress-crbug-465298: Compare against function name instead of value.
* regress-crbug-621361: Make evaluate return string results.
* debug-script: Various counts were off due to new way tests are called.
Added new inspector script type.
Breakpoints now contain the actual break position, and remote object
reconstruction has been extended a bit.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2505363002
Cr-Commit-Position: refs/heads/master@{#41129}
This is the TurboFan counterpart of http://crrev.com/2504263004, but it
is a bit more involved, since in TurboFan we always inline the appropriate
call to the @@hasInstance handler, and by that we can optimize a lot more
patterns of instanceof than Crankshaft, and even yield fast instanceof
for custom @@hasInstance handlers (which we can now properly inline as
well).
Also we now properly optimize Function.prototype[@@hasInstance], even if
the right hand side of an instanceof doesn't have the Function.prototype
as its direct prototype.
For the baseline case, we still rely on the global protector cell, but
we can address that in a follow-up as well, and make it more robust in
general.
TEST=mjsunit/compiler/instanceof
BUG=v8:5640
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2511223003
Cr-Commit-Position: refs/heads/master@{#41092}
Fixes a bug in ast-graph-builder added in r40965
BUG=chromium:665680
Review-Url: https://codereview.chromium.org/2509643002
Cr-Commit-Position: refs/heads/master@{#41034}
This CL further extends the debug wrapper, migrates around 60 tests, and
removes a few tests that use functionality we will not support anymore.
In more detail:
* Removed tests that use:
* enable/disable individual breakpoints
* invocationText()
* the ScriptCollected event
* showBreakPoints
* evalFromScript (and similar)
* mirror.constructedBy and mirror.referencedBy
* event_data.promise()
* Some frame.evaluate uses were adapted since due to differences between
remote objects (inspector) and mirrors. For instance, exceptions are
currently not recreated exactly, since the inspector protocol does not
give us the stack and message separately. Other objects (such as
'this' in debug-evaluate-receiver-before-super) need to be explicitly
converted to a string before the test works correctly.
* Ensure that inspector stores the script before sending ScriptParsed and
ScriptFailedToParse events in order to be able to use the script from
within those events.
* Better remote object reconstruction (e.g. for undefined and arrays).
* New functionality in wrapper:
* debuggerFlags().breakPointsActive.setValue()
* scripts()
* execState.setVariableValue()
* execState.scopeObject().value()
* execState.scopeObject().property()
* execState.frame().allScopes()
* eventData.exception()
* eventData.script()
* setBreakPointsActive()
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2497973002
Cr-Commit-Position: refs/heads/master@{#41019}
Reason for revert:
Seems to break GC stress.
Original issue's description:
> [turbofan] Fix deoptimization of boolean bit constants.
>
> BUG=chromium:664490
TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:664490
Review-Url: https://codereview.chromium.org/2502613002
Cr-Commit-Position: refs/heads/master@{#40961}
This adds a new NumberToUint8Clamped simplified operator that does the
round ties to even + clamping necessary to store to Uint8ClampedArrays.
BUG=v8:4470,v8:5267,v8:5615
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2489563004
Cr-Commit-Position: refs/heads/master@{#40861}
This moves all tests currently working with the inspector debugger wrapper to
test/debugger.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2480223002
Cr-Commit-Position: refs/heads/master@{#40824}
This moves all tests currently working with the inspector debugger wrapper to
test/debugger.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2480223002
Cr-Commit-Position: refs/heads/master@{#40804}
In Crankshaft we unconditionally assume that accesses to arguments[i] will
be in-bounds and don't take into account IC feedback that would eventually
teach us about out-of-bounds accesses that have happened in the past, so
there's no real guard to protect the bounds check in optimized code.
TEST=mjsunit/compiler/deopt-arguments-oob
R=jarin@chromium.org
BUG=v8:5606
Review-Url: https://codereview.chromium.org/2481053002
Cr-Commit-Position: refs/heads/master@{#40787}
For inputs to truncating binary operations like <<, | or >>>, support
all Oddballs not just undefined, true and false. This unifies treatment
of these truncations in Crankshaft and TurboFan, and is very easy
nowadays, since the memory layout of Oddball and HeapNumber is
compatible.
R=yangguo@chromium.org
BUG=v8:5400
Review-Url: https://codereview.chromium.org/2452193003
Cr-Commit-Position: refs/heads/master@{#40608}
We need to check the KeyedLoadIC state to guard against potential
deoptimization loops due to out-of-bounds accesses, because the IC
system uses the MEGAMORPHIC state to also signal that there was an
out-of-bounds access already.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2443893002
Cr-Commit-Position: refs/heads/master@{#40525}
Fixes:
- Remove OsrGuards on frame specialization (for asm.js).
- Handle the rename in the walk for native context.
- Fix LoadContext effect wiring for Osr context chains.
Review-Url: https://codereview.chromium.org/2388303006
Cr-Commit-Position: refs/heads/master@{#40021}
Reason for revert:
Tanks the world.
Original issue's description:
> [turbofan] Osr value typing + dynamic type checks on entry.
>
> This introduces a new OsrGuard node that is inserted during graph building
> to guard the inferred type of the OSR value.
>
> The type of the OSR value is inferred by running the typer before OSR
> deconstruction, and then taking the type from the phi that takes the
> OSR value. After the deconstruction, we throw the types away.
>
> At the moment we only support the SignedSmall OSR type and we always
> pick the tagged representation. Later, we might want to support more
> types (such as Number) and pick better representations (int32/float64).
>
> This CL also removes the OSR deconstruction tests because they build
> unrealistic graph (no effect chain, no loop termination). I considered
> adding the effect chains to the tests, but this would make the tests
> even more brittle.
>
> Committed: https://crrev.com/1f5dc90a900d222da44bee3eff171a2ba1e3c076
> Cr-Commit-Position: refs/heads/master@{#39971}
TBR=bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2395783002
Cr-Commit-Position: refs/heads/master@{#39985}
This introduces a new OsrGuard node that is inserted during graph building
to guard the inferred type of the OSR value.
The type of the OSR value is inferred by running the typer before OSR
deconstruction, and then taking the type from the phi that takes the
OSR value. After the deconstruction, we throw the types away.
At the moment we only support the SignedSmall OSR type and we always
pick the tagged representation. Later, we might want to support more
types (such as Number) and pick better representations (int32/float64).
This CL also removes the OSR deconstruction tests because they build
unrealistic graph (no effect chain, no loop termination). I considered
adding the effect chains to the tests, but this would make the tests
even more brittle.
Review-Url: https://codereview.chromium.org/2384113002
Cr-Commit-Position: refs/heads/master@{#39971}
This makes sure we only replace load operations for fields on virtual
objects. Even though data flow information for non-virtual (escaping)
allocations is available, it might be inaccurate in certain situations
where object state hasn't been cleared.
R=jarin@chromium.org
TEST=mjsunit/compiler/regress-escape-analysis-indirect
Review-Url: https://codereview.chromium.org/2369953002
Cr-Commit-Position: refs/heads/master@{#39776}
Reason for revert:
Tanks EarleyBoyer.
Original issue's description:
> [compiler] Properly guard the speculative optimizations for instanceof.
>
> Add a general feedback slot for instanceof similar to what we already have
> for for-in, which basically has a fast (indicated by the uninitialized
> sentinel) and a slow (indicated by the megamorphic sentinel) mode. Now
> we can only take the fast path when the feedback slot says it hasn't
> seen any funky inputs and nothing funky appeared in the prototype chain.
> In the TurboFan code we also deoptimize whenever we see a funky object
> (i.e. a proxy or an object that requires access checks) in the prototype
> chain (similar to what Crankshaft already did).
>
> Drive-by-fix: Also make Crankshaft respect the mode and therefore
> address the deopt loop in Crankshaft around instanceof.
>
> We might want to introduce an InstanceOfIC mechanism at some point and
> track the map of the right-hand side.
>
> BUG=v8:5267
> R=mvstanton@chromium.org
>
> Committed: https://crrev.com/a0484bc6116ebc2b855de87d862945e2ae07169b
> Cr-Commit-Position: refs/heads/master@{#39718}
TBR=mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2365223003
Cr-Commit-Position: refs/heads/master@{#39736}
Add a general feedback slot for instanceof similar to what we already have
for for-in, which basically has a fast (indicated by the uninitialized
sentinel) and a slow (indicated by the megamorphic sentinel) mode. Now
we can only take the fast path when the feedback slot says it hasn't
seen any funky inputs and nothing funky appeared in the prototype chain.
In the TurboFan code we also deoptimize whenever we see a funky object
(i.e. a proxy or an object that requires access checks) in the prototype
chain (similar to what Crankshaft already did).
Drive-by-fix: Also make Crankshaft respect the mode and therefore
address the deopt loop in Crankshaft around instanceof.
We might want to introduce an InstanceOfIC mechanism at some point and
track the map of the right-hand side.
BUG=v8:5267
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2370693002
Cr-Commit-Position: refs/heads/master@{#39718}
Extract String feedback on Add operation and utilize to lower ConsString
creation in JSTypedLowering when we know that a String addition will
definitely result in the creation of a ConsString.
Note that Crankshaft has to guard the potential length overflow of the
resulting string with an eager deoptimization exit, while we can safely
throw an exception in that case.
Also note that the bytecode pipeline does not currently provide the
String feedback for the addition, which has to be added.
BUG=v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2354853002
Cr-Commit-Position: refs/heads/master@{#39540}
This fixes the materialization of JSFunction objects to not rely on a
context being available. The context has been cleared because it might
be de-materiallized itself.
R=bmeurer@chromium.org
TEST=mjsunit/compiler/escape-analysis-materialize
BUG=chromium:644245
Review-Url: https://codereview.chromium.org/2320983002
Cr-Commit-Position: refs/heads/master@{#39277}
The trouble here is that the type of the induction variable might be
a bit ahead of the increment (JSAdd) operation's type. When we update
the type of the increment, we might only update the induction variable
type while the JSAdd type might be stale. If the induction variable typing
needs to fall back to normal phi typing (e.g., when the increment is not
an integer anymore), it might use the stale type.
To get around this, we fake monotonicity if we fallback to normal phi
typing. Another option would be to force re-typing of the increment
operation, but that seems to be harder to maintain.
BUG=chromium:644633
Review-Url: https://codereview.chromium.org/2320803002
Cr-Commit-Position: refs/heads/master@{#39261}
We were previously incorrectly changing:
sub r0, 0, r1
cmp r2, r0
b.cond <addr>
to:
cmn r2, r1
b.cond <addr>
for all conditions. This is incorrect for conditions involving the C (carry)
and V (overflow) flags, and in particular in the case where r1 = INT_MIN.
The optimization is still safe to perform for Equal and NotEqual since they
do not depend on the C and V flags.
BUG=
Review-Url: https://codereview.chromium.org/2318043002
Cr-Commit-Position: refs/heads/master@{#39246}
Migrate the isNaN, isFinite, Number.isFinite, Number.isInteger,
Number.isSafeInteger and Number.isNaN predicates to TurboFan
builtins and make them optimizable (for certain input types) in
JavaScript callees being optimized by TurboFan. That means both
the baseline and the optimized version is now always at maximum,
consistent performance. Especially TurboFan suffered from poor
baseline (and optimized) performance because it cannot play the
same weird tricks that Crankshaft plays for %_IsSmi.
This also adds a bunch of new tests to properly cover the use
of the Harmony predicates in optimized code.
R=franzih@chromium.org
BUG=v8:5049,v8:5267
Review-Url: https://codereview.chromium.org/2313073002
Cr-Commit-Position: refs/heads/master@{#39242}
Disable the propagation of truncations through Phi, Select or TypeGuard
if the output representation is tagged, because when the truncations are
taken we don't necessarily reflect this in the types and therefore we
might end up in a situation where we produce a word32 value, the type
says Number, and now we need to change that to tagged, which is not
possible since we don't know how to interpret the bits, i.e. whether the
value is Signed32 or Unsigned32.
BUG=chromium:644048
Review-Url: https://codereview.chromium.org/2311903002
Cr-Commit-Position: refs/heads/master@{#39186}
- Make constants more interesting.
- Add an addition to be done after the inlined call in the try-block.
- On command line, have a bit more output.
- New alternative that deopts from unoptimized code.
BUG=
R=jarin
Review-Url: https://codereview.chromium.org/2285743002
Cr-Commit-Position: refs/heads/master@{#38974}
These tests were spliced out of changelist 2216353002 and extended.
BUG=
Review-Url: https://codereview.chromium.org/2245263003
Cr-Commit-Position: refs/heads/master@{#38906}
Reason for revert:
Octane/Mandreel aborts with an exception now:
TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function
Original issue's description:
> [turbofan] Insert dummy values when changing from None type.
>
> Currently we choose the MachineRepresentation::kNone representation for
> values of Type::None, and when converting values from the kNone representation
> we use "impossible" conversions that will crash at runtime. This
> assumes that the impossible conversions should never be hit (the only
> way to produce the impossible values is to perform an always-failing
> runtime check on a value, such as Smi-checking a string). Note that
> this assumes that the runtime check is executed before the impossible
> convesrion.
>
> Introducing BitwiseOr type feedback broke this in two ways:
>
> - we always pick Word32 representation for bitwise-or, so the
> impossible conversion does not trigger (it only triggers with
> None representation), and we could end up with unsupported
> conversions from Word32.
>
> - even if we inserted impossible conversions, they are pure conversions.
> Since untagging, bitwise-or operations are also pure, we could hoist
> all these before the smi check of the inputs and we could hit the
> impossible conversions before we get to the smi check.
>
> This CL addresses this by just providing dummy values for conversions
> from the Type::None type. It also removes the impossible-to-* conversions.
>
> BUG=chromium:638132
>
> Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
> Cr-Commit-Position: refs/heads/master@{#38883}
TBR=mstarzinger@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:638132
Review-Url: https://codereview.chromium.org/2280613002
Cr-Commit-Position: refs/heads/master@{#38893}
Currently we choose the MachineRepresentation::kNone representation for
values of Type::None, and when converting values from the kNone representation
we use "impossible" conversions that will crash at runtime. This
assumes that the impossible conversions should never be hit (the only
way to produce the impossible values is to perform an always-failing
runtime check on a value, such as Smi-checking a string). Note that
this assumes that the runtime check is executed before the impossible
convesrion.
Introducing BitwiseOr type feedback broke this in two ways:
- we always pick Word32 representation for bitwise-or, so the
impossible conversion does not trigger (it only triggers with
None representation), and we could end up with unsupported
conversions from Word32.
- even if we inserted impossible conversions, they are pure conversions.
Since untagging, bitwise-or operations are also pure, we could hoist
all these before the smi check of the inputs and we could hit the
impossible conversions before we get to the smi check.
This CL addresses this by just providing dummy values for conversions
from the Type::None type. It also removes the impossible-to-* conversions.
BUG=chromium:638132
Review-Url: https://codereview.chromium.org/2266823002
Cr-Commit-Position: refs/heads/master@{#38883}
Unfortunately, I was unable to produce a repro without asm.js. In normal
JavaScript, the bounds check renaming saves us.
I have not done anything about the index variable aliasing and handling
of differently sized elements yet!
BUG=chromium:639210, v8:5266
Review-Url: https://codereview.chromium.org/2270793004
Cr-Commit-Position: refs/heads/master@{#38874}
Unify the representation selection rules for NumberAdd/Subtract and
SpeculativeNumberAdd/Subtract wrt. Int32Add/Sub selection. We can
safely use Int32Add/Sub as long as the inputs are in the safe additive
integer range and the output is either truncated to Word32 or provably
in Signed32 or Unsigned32 range.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2253293005
Cr-Commit-Position: refs/heads/master@{#38746}
At the moment, two NumberConstant nodes get different type even if their
value is the same because we always allocate a new heap number for
each number constant. This can lead to replacing a node with a node of
disjoint type in value numbering, which can result in incorrect code
down the line because of inconsistent types.
This fix makes sure that we only replace a node with a sub-type
node. Once we introduce a proper type for number constants, we can
move back to the intersection typing in value numbering.
Unfortunately, it is quite hard to write a repro for this because we cache NumberConstant nodes. We only throw away cached values that have too many conflicts (>5), so the test has to contain values that fall into the same bucket. That's where the magic floating point numbers in the test come from (they have the same low 8-bits of their hashes).
BUG=chromium:633497
Review-Url: https://codereview.chromium.org/2251833002
Cr-Commit-Position: refs/heads/master@{#38675}
This adds a very first version of inlined Array.prototype.pop into
TurboFan optimized code. We currently limit the inlining to fast
object or smi elements, until the unclear situation around hole NaNs
is resolved and we have a clear semantics inside the compiler.
It's also probably overly defensive in when it's safe to inline
the call to Array.prototype.pop, but we can always extend that
later once we have sufficient trust in the implementation and see
an actual need to extend it.
BUG=v8:2229,v8:3952,v8:5267
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2239703002
Cr-Commit-Position: refs/heads/master@{#38578}
This switches the interface of the runtime profiler to use frames as
opposed to functions for performing on-stack replacement. Requests for
such replacements need to target a specific frame. This will enable us
to activate bytecode as well as baseline code for the same function.
The existing %OptimizeOsr runtime function also had to adapted and now
takes an optional stack depth to target a specific stack frame.
R=bmeurer@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2230783004
Cr-Commit-Position: refs/heads/master@{#38548}
We now deopt when the lhs of a mod is negative and the rhs is 1 too (previously, we erroneusly returned 0 instead of -0).
BUG=v8:5278
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2233713002
Cr-Commit-Position: refs/heads/master@{#38525}
If we infer loop variable bounds, we need to insert a type rename node
(sigma) to make sure that simplified lowering can choose representations
consistently.
Review-Url: https://codereview.chromium.org/2222513002
Cr-Commit-Position: refs/heads/master@{#38391}
This introduces a bunch of new tests that test various aspects of
accessor inlining in TurboFan (without the actual inlining), and does
the appropriate fixes to the AstGraphBuilder. The actual inlining CL
will land separately (so we don't need to revert the tests and fixes
if the accessor CL has to be reverted).
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2197913002
Cr-Commit-Position: refs/heads/master@{#38191}
Drive-by fix: actually match the hint in the IsSpeculativeBinopMatcher.
Review-Url: https://codereview.chromium.org/2191883002
Cr-Commit-Position: refs/heads/master@{#38176}
This required the introduction of the CheckedNumberOrOddballAsWord32 use info, and a change in the RepresentationChanger to handle it.
BUG=
Review-Url: https://codereview.chromium.org/2184513003
Cr-Commit-Position: refs/heads/master@{#38086}
After multiplying two integers we emit code like:
if (result == 0) {
if (OR_OPERATION(rhs, lhs) < 0) {
DEOPT;
}
}
This CL allows us to eliminate the OR and comparison if either rhs or
lhs is a negative number, reducing the code to:
if (result == 0) DEOPT;
BUG=
Review-Url: https://codereview.chromium.org/2167643002
Cr-Commit-Position: refs/heads/master@{#38016}
Use the ForInFilterStub directly. Hence we will only jump to the runtime for
special receivers (instance_type <= LAST_SPECIAL_RECEIVER_TYPE) and for
converting element indices which are not in the string cache.
BUG=
Review-Url: https://codereview.chromium.org/2151773002
Cr-Commit-Position: refs/heads/master@{#37934}
This makes sure that we preserve call's tailness even if we have
introduced a loop exit between the call and the return.
BUG=chromium:628773
Review-Url: https://codereview.chromium.org/2155123002
Cr-Commit-Position: refs/heads/master@{#37832}
In int32 multiplication, if we have a positive integer as input, then we know we can't produce a -0 answer. The same is true if truncation is applied (x * y | 0). Without this information, we have to rather annoyingly check if the result of multiplication is 0, then OR the inputs to check for negativity, and possibly return -0. In TurboFan, we'll deopt in this case.
BUG=
Review-Url: https://codereview.chromium.org/2154073002
Cr-Commit-Position: refs/heads/master@{#37831}
Delaying for merges caused branch cloning using dummy effect phi inputs,
potentially splitting the effect chain at start.
We still have to delay the creation for loops because we need to break
cycles.
BUG=chromium:628403
Review-Url: https://codereview.chromium.org/2159603002
Cr-Commit-Position: refs/heads/master@{#37808}
This makes sure that the uses of PlainPrimitiveToNumber get a more
precise type (so that the uses know how to interpret the output
representation).
BUG=chromium:628516
Review-Url: https://codereview.chromium.org/2151223002
Cr-Commit-Position: refs/heads/master@{#37792}
Typed lowering now produces SpeculativeNumberShiftLeft for JSShiftLeft if the type feedback is kSignedSmall or kSigned32.
BUG=v8:4583
LOG=n
Review-Url: https://codereview.chromium.org/2150553002
Cr-Commit-Position: refs/heads/master@{#37762}
This drops the %_ValueOf intrinsic, but keeps the runtime entry
%ValueOf for now, by either migrating the functionality (mostly
Debug mirror or toString/valueOf methods) to C++ or TurboFan
builtins, or switching to the %ValueOf runtime call when it's
not performance critical anyways.
The %_ValueOf intrinsic was one of the last blockers for fixing
the unsound machine operator typing in TurboFan.
R=yangguo@chromium.org
BUG=v8:5049
Committed: https://crrev.com/293bd7882987f00e465710ce468bfb1eaa7d3fa2
Review-Url: https://codereview.chromium.org/2126453002
Cr-Original-Commit-Position: refs/heads/master@{#37512}
Cr-Commit-Position: refs/heads/master@{#37519}
Reason for revert:
[Sheriff] Breaks without i18n:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/8466
Original issue's description:
> [intrinsic] Drop the %_ValueOf intrinsic.
>
> This drops the %_ValueOf intrinsic, but keeps the runtime entry
> %ValueOf for now, by either migrating the functionality (mostly
> Debug mirror or toString/valueOf methods) to C++ or TurboFan
> builtins, or switching to the %ValueOf runtime call when it's
> not performance critical anyways.
>
> The %_ValueOf intrinsic was one of the last blockers for fixing
> the unsound machine operator typing in TurboFan.
>
> R=yangguo@chromium.org
> BUG=v8:5049
>
> Committed: https://crrev.com/293bd7882987f00e465710ce468bfb1eaa7d3fa2
> Cr-Commit-Position: refs/heads/master@{#37512}
TBR=yangguo@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2117273002
Cr-Commit-Position: refs/heads/master@{#37514}
This drops the %_ValueOf intrinsic, but keeps the runtime entry
%ValueOf for now, by either migrating the functionality (mostly
Debug mirror or toString/valueOf methods) to C++ or TurboFan
builtins, or switching to the %ValueOf runtime call when it's
not performance critical anyways.
The %_ValueOf intrinsic was one of the last blockers for fixing
the unsound machine operator typing in TurboFan.
R=yangguo@chromium.org
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2126453002
Cr-Commit-Position: refs/heads/master@{#37512}
The re-typer now only types a node if its inputs are all typed with the
exception of phi nodes. This works because all cycles in the graph have
to contain a phi node.
BUG=chromium:625558
Review-Url: https://codereview.chromium.org/2120243002
Cr-Commit-Position: refs/heads/master@{#37493}
Import fdlibm versions of acos, acosh, asin and asinh, which are more
precise and produce the same result across platforms (we were using
libm versions for asin and acos so far, where both speed and precision
depended on the operating system so far). Introduce appropriate TurboFan
operators for these functions and use them both for inlining and for the
generic builtin.
Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
to ensure that their behavior is always exactly the same as the inlined
TurboFan version (i.e. C++ truncation semantics for double to float
don't necessarily meet the JavaScript semantics).
For completeness, also migrate Math.sign, which can even get some nice
love in TurboFan.
Drive-by-fix: Some alpha-sorting on the Math related functions, and
cleanup the list of Math intrinsics that we have to export via the
native context currently.
BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
TBR=rossberg@chromium.orgR=franzih@chromium.org
Review-Url: https://codereview.chromium.org/2116753002
Cr-Commit-Position: refs/heads/master@{#37476}
The ARM64 instruction selector can generate code like this
negs w0, w1
b.vs deopt
but then reference the old value of w0 in the frame state, which will
obviously lead to wrong results.
R=jarin@chromium.org
BUG=v8:5158
Review-Url: https://codereview.chromium.org/2103793002
Cr-Commit-Position: refs/heads/master@{#37322}
This adds a dedicated test to make sure we don't try constant folding on
checks (in this case CheckTaggedPointer), which would generate invalid
code as we removing checks that guard the constant without knowing
whether it's safe to do so.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2087153002
Cr-Commit-Position: refs/heads/master@{#37168}
We cannot change x - y < 0 to x < y, because it would only be safe if
x - y cannot overflow, which we don't know in general.
R=jarin@chromium.org
BUG=v8:5129
Review-Url: https://codereview.chromium.org/2090493002
Cr-Commit-Position: refs/heads/master@{#37164}
This CheckBounds simplified operator is similar to the HBoundsCheck in
Crankshaft, and is hooked up to the new type feedback support in the
SimplifiedLowering. We use it to check the index bounds for keyed
property accesses.
Note to perf sheriffs: This will tank quite a few benchmarks, as the
operator makes some redundant branch elimination ineffective for
certain patterns of keyed accesses. This does require more serious
redundancy elimination, which we will do in a separate CL. So ignore
any regressions from this CL, we know there will be a few.
R=jarin@chromium.org
BUG=v8:4470,v8:5100
Committed: https://crrev.com/85e5567dae66a918500ae94c5568221137a0f5d4
Review-Url: https://codereview.chromium.org/2035893004
Cr-Original-Commit-Position: refs/heads/master@{#36947}
Cr-Commit-Position: refs/heads/master@{#37003}
This introduces SilenceNaN operator, which makes sure that we only
store quiet NaNs into holey arrays. We omit the NaN silencing code
at instruction selection time if the input is an operation that
cannot possibly produce signalling NaNs.
BUG=
Review-Url: https://codereview.chromium.org/2060233002
Cr-Commit-Position: refs/heads/master@{#36950}
This CheckBounds simplified operator is similar to the HBoundsCheck in
Crankshaft, and is hooked up to the new type feedback support in the
SimplifiedLowering. We use it to check the index bounds for keyed
property accesses.
Note to perf sheriffs: This will tank quite a few benchmarks, as the
operator makes some redundant branch elimination ineffective for
certain patterns of keyed accesses. This does require more serious
redundancy elimination, which we will do in a separate CL. So ignore
any regressions from this CL, we know there will be a few.
R=jarin@chromium.org
BUG=v8:4470,v8:5100
Review-Url: https://codereview.chromium.org/2035893004
Cr-Commit-Position: refs/heads/master@{#36947}
In Crankshaft we don't know reliably know that an HAdd might not turn
into a string addition later (via deoptimization), so we cannot set the
HValue::kAllowUndefinedAsNaN flag on the HAdd instruction in those
cases. It doesn't seem to affect performance if we just remove the flag
completely from the HAdd instruction, so let's stick to that approach
for now.
R=jarin@chromium.org
BUG=v8:5074
Review-Url: https://codereview.chromium.org/2048643002
Cr-Commit-Position: refs/heads/master@{#36805}
This introduces optimized number operations based on type feedback.
Summary of changes:
1. Typed lowering produces SpeculativeNumberAdd/Subtract for JSAdd/Subtract if
there is suitable feedback. The speculative nodes are connected to both the
effect chain and the control chain and they retain the eager frame state.
2. Simplified lowering now executes in three phases:
a. Propagation phase computes truncations by traversing the graph from uses to
definitions until checkpoint is reached. It also records type-check decisions
for later typing phase, and computes representation.
b. The typing phase computes more precise types base on the speculative types (and recomputes
representation for affected nodes).
c. The lowering phase performs lowering and inserts representation changes and/or checks.
3. Effect-control linearization lowers the checks to machine graphs.
Notes:
- SimplifiedLowering will be refactored to have handling of each operation one place and
with clearer input/output protocol for each sub-phase. I would prefer to do this once
we have more operations implemented, and the pattern is clearer.
- The check operations (Checked<A>To<B>) should have some flags that would affect
the kind of truncations that they can handle. E.g., if we know that a node produces
a number, we can omit the oddball check in the CheckedTaggedToFloat64 lowering.
- In future, we want the typer to reuse the logic from OperationTyper.
BUG=v8:4583
LOG=n
Review-Url: https://codereview.chromium.org/1921563002
Cr-Commit-Position: refs/heads/master@{#36674}
This prevents the compiler from optimizing
f64-to-tagged(tagged-to-f64(x)) ==> x
for non-number x (such as undefined).
Review-Url: https://codereview.chromium.org/2027593002
Cr-Commit-Position: refs/heads/master@{#36613}
Previously we first created a temporary graph for the inlinee and then
copied over all the nodes to the actual graph. This however introduces
unnecessary complexity, and we can instead just create the inlinee
inside the target graph.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2006353003
Cr-Commit-Position: refs/heads/master@{#36508}
This promotes the escape analysis from an experimental feature to be a
fully supported feature. The main goal is to unleach ClusterFuzz on the
implementation so that we can stabilize it.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1989833002
Cr-Commit-Position: refs/heads/master@{#36324}
This adds back the instanceof operator support in the backends and
introduces a @@hasInstance protector cell on the isolate that guards the
fast path for the InstanceOfStub. This way we recover the ~10%
regression on Octane EarleyBoyer in Crankshaft and greatly improve
TurboFan and Ignition performance of instanceof.
R=ishell@chromium.orgTBR=hpayer@chromium.org,rossberg@chromium.org
BUG=chromium:597249, v8:4447
LOG=n
Review-Url: https://codereview.chromium.org/1980483003
Cr-Commit-Position: refs/heads/master@{#36275}
We got the condition wrong and actually deoptimized when the typed array
was not neutered. This fixes the deopt loop in Math.random and actually
many programs that use typed arrays.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1970123002
Cr-Commit-Position: refs/heads/master@{#36194}
The flag in question used to fall-back to Crankshaft whenever an OSR
request couldn't be handled by TurboFan. By now OSR in TurboFan is
sufficiently stabilized that one single --use-osr flag should do it.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/1960043002
Cr-Commit-Position: refs/heads/master@{#36102}
The problem is actually not related to try-catch, so here is a test
without try-catch.
BUG=chromium:607493
LOG=n
Review-Url: https://codereview.chromium.org/1943883002
Cr-Commit-Position: refs/heads/master@{#35985}
This prefixes the escape analysis flag with "experimental", thereby
making sure the flag in question is not being fuzzed. It will reduce
noise levels on ClusterFuzz again.
R=jarin@chromium.org
BUG=chromium:603653
LOG=n
Review URL: https://codereview.chromium.org/1894513002
Cr-Commit-Position: refs/heads/master@{#35521}
Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.
In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.
Also gone are any tests which relied on legacy const declarations.
Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.
Review URL: https://codereview.chromium.org/1819123002
Cr-Commit-Position: refs/heads/master@{#35002}
This CL adds support for builtins with JavaScript linkage written using
the TurboFan CodeStubAssembler, but with a JSCall descriptor (which was
already supported thanks to a previous patch by Ben Smith). As a first
example, we convert the Math.sqrt builtin and thereby get rid of the
%_MathSqrt intrinsic, which causes trouble for the representation
selection pass in the JavaScript pipeline.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1824993002
Cr-Commit-Position: refs/heads/master@{#34989}
Moves the accumulator value on-heap to be restored in the
InterpreterNotifyDeopt handler rather than explicitly
setting the accumulator register. This allows it to be
materialized correctly if required.
BUG=v8:4678
LOG=N
Review URL: https://codereview.chromium.org/1707133003
Cr-Commit-Position: refs/heads/master@{#34113}
This removes support for the %Arguments and %ArgumentsLength runtime
entries and their intrinsic counterparts. If you need variable arguments
in any builtin, either use (strict) arguments object or rest parameters,
which are both compositional across inlining (in TurboFan), and not that
much slower compared to the %_Arguments hackery.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1688163004
Cr-Commit-Position: refs/heads/master@{#33943}
The idea here is to perform the handler lookup in the deoptimizer, and then take the information from the handler table to build the catch handler frame in the deoptimizer. Specifically, we use the pc offset, context location and stack height (in full-code) to tweak the output frame.
Sadly, this still requires nasty voodoo for the liveness analyzer so that it keeps variables alive if they are used in the catch handler.
Review URL: https://codereview.chromium.org/1416543006
Cr-Commit-Position: refs/heads/master@{#33936}
Reason for revert:
No fix needed, original CL was perfectly fine!
Original issue's description:
> Revert of [interpreter] Correctly thread through catch prediction. (patchset #1 id:1 of https://codereview.chromium.org/1690973002/ )
>
> Reason for revert:
> Depends on the reverted https://codereview.chromium.org/1691723002
>
> Original issue's description:
> > [interpreter] Correctly thread through catch prediction.
> >
> > This change correctly sets the {CatchPrediction} field in exception
> > handler tables for bytecode and optimized code. It also adds tests
> > independent of promise handling for this prediction, to ensure all our
> > backends are in sync on their prediction.
> >
> > R=rmcilroy@chromium.org,yangguo@chromium.org
> > TEST=mjsunit/compiler/debug-catch-prediction
> > BUG=v8:4674
> > LOG=n
> >
> > Committed: https://crrev.com/ba55f5594cb0b4a1a1e9b35d87fe54afe2d93f3b
> > Cr-Commit-Position: refs/heads/master@{#33906}
>
> TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4674
>
> Committed: https://crrev.com/c5229b311968fd638a6cd537c341b1055eb7be97
> Cr-Commit-Position: refs/heads/master@{#33922}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4674
Review URL: https://codereview.chromium.org/1689113004
Cr-Commit-Position: refs/heads/master@{#33933}
Reason for revert:
Depends on the reverted https://codereview.chromium.org/1691723002
Original issue's description:
> [interpreter] Correctly thread through catch prediction.
>
> This change correctly sets the {CatchPrediction} field in exception
> handler tables for bytecode and optimized code. It also adds tests
> independent of promise handling for this prediction, to ensure all our
> backends are in sync on their prediction.
>
> R=rmcilroy@chromium.org,yangguo@chromium.org
> TEST=mjsunit/compiler/debug-catch-prediction
> BUG=v8:4674
> LOG=n
>
> Committed: https://crrev.com/ba55f5594cb0b4a1a1e9b35d87fe54afe2d93f3b
> Cr-Commit-Position: refs/heads/master@{#33906}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4674
Review URL: https://codereview.chromium.org/1695613002
Cr-Commit-Position: refs/heads/master@{#33922}
This change correctly sets the {CatchPrediction} field in exception
handler tables for bytecode and optimized code. It also adds tests
independent of promise handling for this prediction, to ensure all our
backends are in sync on their prediction.
R=rmcilroy@chromium.org,yangguo@chromium.org
TEST=mjsunit/compiler/debug-catch-prediction
BUG=v8:4674
LOG=n
Review URL: https://codereview.chromium.org/1690973002
Cr-Commit-Position: refs/heads/master@{#33906}
This adds test cases for exception handlers that require a context
switch when entering the catch-block or the finally-block, triggered
through nested contexts within the try-block.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1681933002
Cr-Commit-Position: refs/heads/master@{#33845}
By now only the default %TypedArray%.prototype.sort compare function
and the JS implementation of SameValueZero were still using the odd
%_IsMinusZero intrinsic, whose semantics both included a number check
(actually HeapNumber test) plus testing if the heap number stores the
special -0 value. In both cases we already know that we deal with
number so we can reduce it to a simple number test for -0, which can
be expressed via dividing 1 by that value and checking the sign of
the result. In case of the compare function, we can be even smarter
and work with the reciprocal values in case x and y are equal to 0
(although long term we should probably rewrite the fast case for
the typed array sorting function in C++ anyway, which will be way,
way faster than our handwritten callback-style, type-feedback
polluted JS implementation).
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1680783002
Cr-Commit-Position: refs/heads/master@{#33833}
Avoid the hacking in JSIntrinsicLowering and provide a proper simplified
operator ObjectIsReceiver instead that is used to implement %_IsJSReceiver
which is used by our JavaScript builtins and the JSInliner.
R=jarin@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1657863004
Cr-Commit-Position: refs/heads/master@{#33675}
The previous versions of Math.max and Math.min made it difficult to
optimize those (that's why we already have custom code in Crankshaft),
and due to lack of ideas what to do about the variable number of
arguments, we will probably need to stick in special code in TurboFan
as well; so inlining those builtins is off the table, hence there's no
real advantage in having them around as "not quite JS" with extra work
necessary in the optimizing compilers to still make those builtins
somewhat fast in cases where we cannot inline them (also there's a
tricky deopt loop in Crankshaft related to Math.min and Math.max, but
that will be dealt with later).
So to sum up: Instead of trying to make Math.max and Math.min semi-fast
in the optimizing compilers with weird work-arounds support %_Arguments
%_ArgumentsLength, we do provide the optimal code as native builtins
instead and call it a day (which gives a nice performance boost on some
benchmarks).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1641083003
Cr-Commit-Position: refs/heads/master@{#33582}
This patch moves the semantics of 'const' in sloppy mode to match those
in strict mode, that is, const makes lexical (let-like) bindings, must
have an initializer, and does not create properties of the global object.
R=adamk
LOG=Y
BUG=v8:3305
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1571873004
Cr-Commit-Position: refs/heads/master@{#33218}
Adds support for the CallRuntimeForPair bytecode to the Bytecode Graph
Builder. Modifies the FrameState support to allow updating of output
registers.
Also adds Eval tests to test-run-bytecode-graph-builder since these are
enabled by CallRuntimeForPair support.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1570623007
Cr-Commit-Position: refs/heads/master@{#33186}
Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.
Two unittests test correctness of the IR level implementation.
Correctness for instruction selection / code generation
is tested by mjsunit tests.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1485183002
Cr-Commit-Position: refs/heads/master@{#33115}
Bugfixes and improvements in escape analysis include:
* Handling of ObjectIsSmi (non-escaping)
* Handling of nested phi replacements
* Handling of phis with arity > 2
* Resilience against effectful nodes dangling from start
* Allocations escape now, if non-const load/store is performed
* Fixed a bug where non-allocated objects where tracked
* Allow fixed double arrays to be tracked
R=mstarzinger@chromium.org
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1510973006
Cr-Commit-Position: refs/heads/master@{#32833}
This patch improves escape analysis and fixes bugs
triggered by clusterfuzz. Impovements include:
* Handling of LoadElement/StoreElement if index is a
constant
* Handling of JSStoreProperty: invalidate all information,
as the store could have altered any field.
* Treat phis that use an allocation as escaping
* Improve resolution of replacements
R=mstarzinger@chromium.org
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1499143002
Cr-Commit-Position: refs/heads/master@{#32656}
Reason for revert:
Blocks the roll:
https://codereview.chromium.org/1497763004/
Original issue's description:
> [es6] Correctify and unify ArrayBuffer and SharedArrayBuffer constructors.
>
> The ArrayBuffer and SharedArrayBuffer constructors should raise an
> exception when called with no arguments or undefined length. Also
> unified the ArrayBuffer and SharedArrayBuffer implementations as C++
> builtins, and removed some (now) obsolete runtime entries.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/3235ccbb7826ceec2188f6ebab98fc851b54f60e
> Cr-Commit-Position: refs/heads/master@{#32590}
TBR=yangguo@chromium.org,cbruni@chromium.org,adamk@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1501673002
Cr-Commit-Position: refs/heads/master@{#32606}
The ArrayBuffer and SharedArrayBuffer constructors should raise an
exception when called with no arguments or undefined length. Also
unified the ArrayBuffer and SharedArrayBuffer implementations as C++
builtins, and removed some (now) obsolete runtime entries.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1500543002
Cr-Commit-Position: refs/heads/master@{#32590}
* Add a sibling interface to InterpreterAssembler called
CodeStubAssembler which provides a wrapper around the
RawMachineAssembler and is intented to make it easy to build
efficient cross-platform code stubs. Much of the implementation
of CodeStubAssembler is shamelessly stolen from the
InterpreterAssembler, and the idea is to eventually merge the
two interfaces somehow, probably moving the
InterpreterAssembler interface over to use the
CodeStubAssembler. Short-term, however, the two interfaces
shall remain decoupled to increase our velocity developing the
two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
CodeStubAssembler. Replace and remove the old Hydrogen-stub
version.
* Remove a whole slew of machinery to support JavaScript-style
code stub generation, since it ultimately proved unwieldy,
brittle and baroque. This cleanup includes removing the shared
code stub context, several example stubs and a tangle of build
file changes.
BUG=v8:4587
LOG=n
Review URL: https://codereview.chromium.org/1475953002
Cr-Commit-Position: refs/heads/master@{#32508}
This is the first part of escape analysis for turbofan.
At the moment, there is no deopt support, and support
for loops is partial (only binary Phis are handled).
The CL includes 4 unittests.
There are also 8 new mjsunit tests, some of which are
skiped as they require features not yet implemented.
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1457683003
Cr-Commit-Position: refs/heads/master@{#32498}
If the input type does not help us, we are conservative and truncate (rather than guessing signed).
Review URL: https://codereview.chromium.org/1455103002
Cr-Commit-Position: refs/heads/master@{#32075}
The %_CallFunction doesn't implement the call sequence properly, it
doesn't do the receiver wrapping, nor does it check for
classConstructor. Also the eager deoptimization for %_CallFunction was
seriously b0rked (we must have been lucky with TurboFan so far).
R=yangguo@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1419813010
Cr-Commit-Position: refs/heads/master@{#31821}
TurboFan is actually able to generate property access to all prototypes
of all primitives, except the special Oddball primitives that have no
wrapper counterparts (namely null and undefined from the ES6 point of
view).
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1409163007
Cr-Commit-Position: refs/heads/master@{#31739}
This introduces a JSConvertReceiver operator to model the implicit
conversion of receiver values for sloppy callees. It is used by the
JSInliner for now, but can also be used to model direction function
calls that bypass call stubs.
Also note that a hint is passed to said operator whenever the source
structure constrains the receiver value type. This hint allows for
optimizations in the lowering of the operator.
The underlying specification in ES6, section 9.2.1.2 is the basis for
this implementation.
R=bmeurer@chromium.org
TEST=mjsunit/compiler/receiver-conversion
BUG=v8:4493, v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1412223015
Cr-Commit-Position: refs/heads/master@{#31598}
This makes sure that initializing assignments of let-declared variables
perform an environment lookup and hence keep the variable alive. This is
needed because full-codegen contains debug code verifying the variable
is still inside the TDZ at the initializing assignment.
R=jarin@chromium.org
TEST=mjsunit/compiler/regress-variable-liveness-let
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1420573002
Cr-Commit-Position: refs/heads/master@{#31437}
When calling into C++ builtins, we need to make sure that the argument
count register contains the correct number of arguments, otherwise the
CEntryStub will not be able to leave the stack in the correct state.
R=ishell@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1391543002
Cr-Commit-Position: refs/heads/master@{#31120}
Introduce %_ToNumber intrinsic, which just calls to the existing
ToNumberStub, and remove all uses of our custom JavaScript plus
intrinsics based ToNumber and friends.
Also replace the TO_NUMBER_INLINE macro with TO_NUMBER,
which is currently a wrapper for %_ToNumber. Newly written JS
code should use TO_NUMBER (similar to TO_STRING, TO_INT32,
and friends).
Also finally remove the DefaultString/DefaultNumber builtins, which
are basically the ES5 version of ToPrimitive. Now all code uses the
ES6 version, which is implemented in Object::ToPrimitive and
JSReceiver::ToPrimitive in C++.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=jarin@chromium.org
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1384443002
Cr-Commit-Position: refs/heads/master@{#31054}
Introduce a new macro TO_STRING that maps to %_ToString and use that
instead of calling into any of the ToString/NonStringToString JavaScript
builtins. Also remove the TO_STRING_INLINE macro, which is basically
obsolete with %_ToString. We still have a few uses of ToString left (via
the utils export mechanism), where we need to investigate whether we
will tank badly if we replace them with TO_STRING as well.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=yangguo@chromium.org
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1323543002
Cr-Commit-Position: refs/heads/master@{#30895}
Inner functions must be eagerly parsed for scope analysis, but the full AST is
also kept around even though it's not needed.
This CL mitigates this problem by allocating some AstNodes of the inner function
to a temporary Zone which is deallocated once the scope information has been
built. The remaining nodes (such as VariableProxy) must persist until scope
analysis actually happens, and have to be allocated to a parser-persistent Zone.
BUG=417697
LOG=N
Review URL: https://codereview.chromium.org/1304923004
Cr-Commit-Position: refs/heads/master@{#30685}
The HUnaryMathOperation cannot be eliminated in general, because the
spec requires a ToNumber conversion on the input, which is observable
of course.
BUG=v8:4389
LOG=y
Review URL: https://codereview.chromium.org/1307413003
Cr-Commit-Position: refs/heads/master@{#30343}
Until now, TF-generated code stubs piggy-backed off of the builtin
context. Since generation of code stubs is lazy, stubs generated at
different times in different native contexts would contain embedded
pointers different builtin contexts, leading to cross-context references
and memory leaks.
After this CL, all TF-generated code stubs are generated inside a
internal thinned-out, native context that lives solely for the
purpose of hosting generated code stubs.
Review URL: https://codereview.chromium.org/1213203007
Cr-Commit-Position: refs/heads/master@{#29593}
Optimize string "length" property access based on static type
information if possible, but also optimistically optimize the access
based on type feedback from the LoadIC.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1216593003
Cr-Commit-Position: refs/heads/master@{#29543}
- Add a TurboFanIC class, derived from TurboFanCodeStub, that
automatically distinguishes between versions of the IC called from
optimized and unoptimized code.
- Add appropriate InterfaceDescriptors for both the versions of the
stub called from unoptimized and optimized code
- Change the MathFloor TF stub generator to output either the
for-optimized or for-unoptimized version based on the minor_key
parameter.
Committed: https://crrev.com/8f13b655b8a10dae2116dd18b32f09337bb2d410
Cr-Commit-Position: refs/heads/master@{#29534}
Review URL: https://codereview.chromium.org/1225943002
Cr-Commit-Position: refs/heads/master@{#29539}
Reason for revert:
Failure on compiling runtime.js on windows
Original issue's description:
> Add unoptimized/optimized variants of MathFloor TF code stub
>
> - Add a TurboFanIC class, derived from TurboFanCodeStub, that
> automatically distinguishes between versions of the IC called from
> optimized and unoptimized code.
> - Add appropriate InterfaceDescriptors for both the versions of the
> stub called from unoptimized and optimized code
> - Change the MathFloor TF stub generator to output either the
> for-optimized or for-unoptimized version based on the minor_key
> parameter.
>
> Committed: https://crrev.com/8f13b655b8a10dae2116dd18b32f09337bb2d410
> Cr-Commit-Position: refs/heads/master@{#29534}
TBR=mvstanton@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1220783006
Cr-Commit-Position: refs/heads/master@{#29535}
- Add a TurboFanIC class, derived from TurboFanCodeStub, that
automatically distinguishes between versions of the IC called from
optimized and unoptimized code.
- Add appropriate InterfaceDescriptors for both the versions of the
stub called from unoptimized and optimized code
- Change the MathFloor TF stub generator to output either the
for-optimized or for-unoptimized version based on the minor_key
parameter.
Review URL: https://codereview.chromium.org/1225943002
Cr-Commit-Position: refs/heads/master@{#29534}
Currently we lower shifts directly to machine operators, and add an
appropriate Word32And to implement the & 0x1F operation on the right
hand side required by the specification. However for Word32And we assume
Int32 in simplified lowering, which is basically changes the right hand
side bit interpretation for the shifts from Uint32 to Int32, which is
obviously wrong. So now we represent that explicitly by proper
simplified operators for the shifts, which are lowered to machine in
simplified lowering.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1213803008
Cr-Commit-Position: refs/heads/master@{#29465}
ARM64's `fmin` and `fmax` instructions don't have the same behaviour as
TurboFan's Float(32|64)(Min|Max) functions.
BUG=4206
LOG=N
Review URL: https://codereview.chromium.org/1200123004
Cr-Commit-Position: refs/heads/master@{#29229}
This fixes the graph wiring of implicit JSToNumber nodes inserted by
JSTypedLowering, to be correctly hooked into a surrounding exceptional
continuation.
R=bmeurer@chromium.org
TEST=mjsunit/compiler/try-binop,test262
Review URL: https://codereview.chromium.org/1178153004
Cr-Commit-Position: refs/heads/master@{#28975}
This adds some basic tests of the interaction between try-catch and
try-finally statements and OSR in TurboFan. The try-osr test suite
follows the structure of try-deopt closely.
R=titzer@chromium.org
TEST=mjsunit/compiler/try-osr
Review URL: https://codereview.chromium.org/1165103003
Cr-Commit-Position: refs/heads/master@{#28855}
This allows try-catch and try-finally constructs to be separately
enabled and disabled. We plan to stage try-catch support soon.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1157863015
Cr-Commit-Position: refs/heads/master@{#28848}
First steps only, the TurboFan compilation is still triggered from C++ land.
Includes some simplifications/cleanups, too.
Review URL: https://codereview.chromium.org/1150263002
Cr-Commit-Position: refs/heads/master@{#28581}
This was already done for other binary operations, so it's basically
copying the existing functionality to shift left and shift right
logical/arithmetic.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1140883003
Cr-Commit-Position: refs/heads/master@{#28389}
Use these check points to optimize comparisons where we already know
that one side cannot be a String (or turn into a string via
ToPrimitive).
Also remove bunch of useless DoNotCrash tests for the scheduler that are
painful to maintain and add almost no value.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1140583004
Cr-Commit-Position: refs/heads/master@{#28383}
This stub will be used as the basis of a Math.floor-specific CallIC to
detect and track calls to floor that return -0.
Along the way:
- Create a TurboFanCodeStub super class from which the StringLength and
MathRound TF stubs derive.
- Fix the ugly hack that passes the first stub parameter as the "this"
pointer in the the TF-compiled JS function.
- Fix bugs in the ia32/x64 disassembler.
Review URL: https://codereview.chromium.org/1137703002
Cr-Commit-Position: refs/heads/master@{#28339}
The goal is to port all of error stack trace formatting to C++.
We will do this bottom up, by first porting helper functions.
Eventually, CallSite methods will only be used when a custom
error stack trace formatter is defined via Error.prepareStackTrace.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1060583008
Cr-Commit-Position: refs/heads/master@{#28095}
