This reverts commit 6e27386d68.
Reason for revert: There will be another much simpler and
back-mergeable fix.
Original change's description:
> Reland "[runtime] Add shortcuts for elements kinds transitions."
>
> This is a reland of b90e83f5da
> Original change's description:
> > [runtime] Add shortcuts for elements kinds transitions.
> >
> > The shortcuts ensure that field type generalization is properly
> > propagated in the transition graph.
> >
> > Bug: chromium:738763
> > Change-Id: Id701a6f95ed6ea093c707fbe0bac228f1f856e9f
> > Reviewed-on: https://chromium-review.googlesource.com/567992
> > Commit-Queue: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#46622}
>
> Bug: chromium:738763, chromium:742346, chromium:742381, chromium:745844
> Change-Id: I93974e3906b2c7710bd525f15037a2dd97f263ad
> Reviewed-on: https://chromium-review.googlesource.com/575227
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46759}
TBR=ulan@chromium.org,jkummerow@chromium.org,ishell@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:738763, chromium:742346, chromium:742381, chromium:745844
Change-Id: I203dc748c47db554e0a86d61f0e2b7b8b96f2370
Reviewed-on: https://chromium-review.googlesource.com/581547
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46826}
This change gets the streaming compile APIs closer to their final shape,
by moving to a promise-based design.
Bug: chromium:747396
Bug: v8:6619
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ifd22ff83c79391a0f2a8ec2e5af39f71df1ea1c2
Reviewed-on: https://chromium-review.googlesource.com/581412
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46821}
Simplify the model for generating Awaits, because the resume point is
always immediately following the suspend point, and registers used are
always the same for both operations.
Includes a minor refactoring of BytecodeGenerator::VisitYield() to
perform iterator result creation before the SuspendGenerator bytecode,
rather than between SuspendGenerator and Return. This adds a small
number of bytecodes for each yield.
BUG=v8:2355, v8:5855
Change-Id: I4868b89a6bc1b251f887d2a45890c8fa19f7b089
Reviewed-on: https://chromium-review.googlesource.com/576286
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46820}
This refactors logic for handling IfStatement and Conditional nodes (including
block-coverage related slot and counter creation) into a new control-flow
builder.
Bug: v8:6000
Change-Id: Ib5b1724bdf8571fb55d310be79cc60dcf5473b81
Reviewed-on: https://chromium-review.googlesource.com/579509
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46818}
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}
when black allocation is on.
The scenario:
1) Incremental marking is off.
2) Partial deserialization starts and calls Heap::ReserveSpace.
2) ReserveSpace creates (white) reservations in old space.
3) ReserveSpace allocates map placeholders. One of these allocations
starts incremental marking, which starts black allocation (currently
when concurrent marking is on). Subsequent maps are black allocated.
4) ReserveSpace succeeds without triggering a GC.
5) Deserialization continues. Some maps are black. Note that
deserialization emits only old->new write barriers and skips
marking write barriers.
6) Deserialization finishes and re-visits the black allocated
reservations and large object. This misses black allocated maps.
7) There is black->white descriptor array pointer in one of these map.
BUG=chromium:723600
Change-Id: Ifffe46f22a7d7dbc5cff2e882190234fcc722ccb
Reviewed-on: https://chromium-review.googlesource.com/581187
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46816}
Removes the SharedFunctionInfo field from the ParseInfo structure. Instead
require a SharedFunctionInfo to be explicitly passed to ParseFunction.
Also renames GetUnoptimizedCode to CompileUnoptimizedFunction to make it
clear it should only be called for non-top-level code.
BUG=v8:5203
Change-Id: Ibce016e6a5290c3685f7f0a2f5fb1eb2df2ffc3b
Reviewed-on: https://chromium-review.googlesource.com/574589
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46814}
The Scavenger is the only consumer of free list entries besides MC
evacuation and pretenured allocations. Make use of all size classes for
allocation.
Bug: chromium:738865
Change-Id: Ieb62c01b41f2aa62222efac91dde4dce2127ff70
Reviewed-on: https://chromium-review.googlesource.com/580409
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46812}
The class Float32 stores the bit pattern of a float as uint32_t to
guarantee that the exact bit pattern of the contained value is
preserved. This is necessary because the bit pattern of a NaN may
change, e.g. when it is passed as a parameter.
For convenience the Float32 class provides a constructor with a float
parameter. Since this constructor cannot guarantee that the right bit
pattern will be stored for NaNs, this CL adds a DCHECK now to make
sure that the constructor is never used with a NaN.
R=mstarzinger@chromium.org
Change-Id: Iba85a5a1bb2778d5f8bdc1aad97524ef8369b73d
Reviewed-on: https://chromium-review.googlesource.com/579367
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46811}
After moving the shared function info creation to be during unoptmized
compile finalization the --print-bytecode flag caused a crash by trying
to access the shared function info before it was created. This CL fixes it.
BUG=v8:5203
Change-Id: I82c0431bace51aa44154c55ad4bebde897f7a39e
Reviewed-on: https://chromium-review.googlesource.com/579769
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46810}
Tracing block coverage prints raw generated slots in the format:
{start_source_position,end_source_position}
Slots are printed before being mutated during coverage collection.
Bug: v8:6000
Change-Id: I3423e226a124e00c6b13ccd8dddb13d00e4989c7
Reviewed-on: https://chromium-review.googlesource.com/579374
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46807}
Depending on the visitation order of the graph, we can have a dead
ArrayBufferWasNeutered check in the state table. This can only happen
when ArrayBuffers have been neutered in the isolate and there are loops
involved where the LoadEliminationPhase triggers revisitation in the
GraphReducer framework. With the most recent fix to the revisit queue
the original repro case no longer works, since it requires us to visit
an ArrayBufferWasNeutered node after a dominating one was killed.
Bug: chromium:741022
Change-Id: I3644bcf0ff7795289cc27d177ab5f6af32238a43
Reviewed-on: https://chromium-review.googlesource.com/579974
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46806}
This reverts commit 4851745fe3.
Reason for revert: Top crasher on Canary, see https://crbug.com/746935
Original change's description:
> [literals] Introduce CreateEmptyArrayLiteral Bytecode
>
> Empty Array literals are amongst the most commonly used literal types on our
> top25 page list. Using a custom bytecode we can drop the boilerplate for empty
> Array literals alltogether. However, we still need a proper AllocationSite to
> track ElementsKind transitions.
>
> Bug: v8:6211
> Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d
> Reviewed-on: https://chromium-review.googlesource.com/567079
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46752}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,cbruni@chromium.org,ishell@chromium.org,rmcilroy@google.com
Bug: v8:6211, chromium:746935
Change-Id: Ibf19a923688c071d03bad8661a10e08f8414db56
Reviewed-on: https://chromium-review.googlesource.com/580193
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46804}
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}
All of these were dead; many existed only on some platforms:
SlowTruncateToI
TestDoubleIsInt32
TestDoubleIsMinusZero
TruncateNumberToI
TruncateHeapNumberToI
TruncateDoubleToI
TryInt32Floor
Change-Id: Ic55fdadcfa851f5aa04dce8cacd5658d2d6315e8
Reviewed-on: https://chromium-review.googlesource.com/578674
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46800}
This reverts commit ae9a2d38f3.
Reason for revert: Regresses benchmarks related to maps and sets.
Regressions here: https://chromeperf.appspot.com/group_report?rev=46756.
In future when we move these builtins to CSA, we may still want to
remove this flag.
Original change's description:
> Remove SetForceInlineFlag from src/js/*
>
> Remove SetForceInlineFlag from the js builtins.
>
> Bug:
> Change-Id: I962982509c82e4baba8dc32a0f163147c47daf34
> Reviewed-on: https://chromium-review.googlesource.com/571803
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46756}
TBR=rmcilroy@chromium.org,jarin@chromium.org,mythria@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I96651aa9d6e91e593af8da1b531e9f7b0240088f
Reviewed-on: https://chromium-review.googlesource.com/579194
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46797}
marking visitors.
This makes incremental and concurrent visitors of share function infos
side-effect free.
BUG=chromium:694255
Change-Id: I85ee7bac17f17bdbc101ef64ecfb46020b5b3458
Reviewed-on: https://chromium-review.googlesource.com/574851
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46796}
This patch implements a recent spec change [1] which increases the
bounds of precision for toFixed, toExponential and toPrecision.
The bounds are a compromise between SpiderMonkey and the other
engines.
[1] https://github.com/tc39/ecma262/pull/857
Bug: v8:6539
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I877aa35e08f3dcda63f5f9181fdecf3c227f2c35
Reviewed-on: https://chromium-review.googlesource.com/553378
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46793}
Apparently the name float.h causes problems on Windows when V8 is
compiled with Visual Studio, see the bug description.
R=clemensh@chromium.org
Bug: v8:6588
Change-Id: Iaa9c1e93e62509a779f1a8ddecbb03a53981cf8a
Reviewed-on: https://chromium-review.googlesource.com/578029
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46791}
The size of parent function is not considered when taking decisions
on which functions to inline. This cl, includes the size of the
parent function to the cumulative count.
Bug:
Change-Id: Ib8f4ec684f8313f7c2e29237580bb3c0403930bd
Reviewed-on: https://chromium-review.googlesource.com/506205
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46789}
... between % and a function name.
Change-Id: I4d06e2623abb6fdd50af748649d0f8e9fae3897d
Reviewed-on: https://chromium-review.googlesource.com/575053
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46788}
The link between the JS weak collection object and its backing store
was missing.
Change-Id: If8293a8d43fb52bc4fc9f156ccda578233a1991c
Reviewed-on: https://chromium-review.googlesource.com/579267
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46787}
CSA::Print() is only used during development and can often be useful
in release builds.
Bug:
Change-Id: Ib6baf5f5275439a468a0f63a00ed446ae11a8de2
Reviewed-on: https://chromium-review.googlesource.com/579190
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46786}
Unscaled memory operations were missing disassembly output for vector registers,
so add support and rewrite as a macro.
Bug:
Change-Id: I6f388952dbe5a3b9f8a9b9c46e69ef63dc6655ba
Reviewed-on: https://chromium-review.googlesource.com/576177
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#46785}
This removes support for dropping arguments adaptor frames as part of
the JSFunction-to-JSFunction tail-call mechanism. The need for having
dedicated {kArchTailCallJSFunctionFromJSFunction} instructions is gone.
R=bmeurer@chromium.org
BUG=v8:4698
Change-Id: Id3d35d06800bee68e06b9554c4315e6ad304de5f
Reviewed-on: https://chromium-review.googlesource.com/575975
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46782}
Scavenger and full MC now rely on the same allocation behavior for their
evacuation.
Bug:
Change-Id: Iddb0affe171187308e5b77ab0d3cfa75211bd8b8
Reviewed-on: https://chromium-review.googlesource.com/575983
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46781}
This inlines the allocation of regexp literals when a boilerplate exists.
Bug: v8:6605,v8:6556
Change-Id: If0f1b9dedf8a7de1ec51c394fe39cf21d2413ac5
Reviewed-on: https://chromium-review.googlesource.com/575240
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46780}
In contrast to other internal fields (data, source, and flags), last_index is
an in-object property. But we can still use the standard accessor macros to
access it.
Bug:
Change-Id: If77f2bb01c6ddccebdde09d7a316c2ddaaf9b277
Reviewed-on: https://chromium-review.googlesource.com/577549
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46779}
It used to be that immortal immovable objects have to be on the first page to
not be moved. This is no longer true since we flag pages wrt whether they are
allowed to move.
R=mlippautz@chromium.org
Change-Id: I5c9c88fa358636df119108e16e871815b126ab27
Reviewed-on: https://chromium-review.googlesource.com/575976
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46777}
