This is a reland of 9c91b6877a after
fixing undefined behavior in numeric conversion that caused trouble
on arm32.
Original change's description:
> [turbofan] Use feedback when reducing global loads/stores.
>
> We already record the script context location or the property cell
> as feedback of the global load/store IC, so Turbofan doesn't need
> to do the lookups again.
>
> Change-Id: I6cbd2937de344729cd8e146b4ff85ddf3de6a56e
> Reviewed-on: https://chromium-review.googlesource.com/c/1335691
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57555}
Change-Id: Ic2d09025de02f92199755ac860bb9e91fa08f4ec
Reviewed-on: https://chromium-review.googlesource.com/c/1340043
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57649}
This cl updates:
1. Adds a new feedback cell map to specify that no feedback is
collected
2. Checks if feedback vectors are valid before using then when
creating closures
3. Runtime profiler to only tier up functions with feedback
4. Interpreter entry trampoline to check for feedback vector before
using it.
Bug: v8:8394
Change-Id: I0248c8cd35d841c2744b22f4c672fa2e82033f6e
Reviewed-on: https://chromium-review.googlesource.com/c/1339866
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57648}
This adds a {PrintRegister} method which prints the given register in a
readable way (e.g. "eax", ... on ia32).
This is currently only used in Liftoff. The {RegisterConfiguration}
class has the same functionality, and I plan to make
{RegisterConfiguration} also use the new {RegisterName} functions in a
follow-up CL.
R=mstarzinger@chromium.org
Bug: v8:8238, v8:8423, v8:6600
Change-Id: If03901f1d8c5b043e0097e63920ab711bd7e2d17
Reviewed-on: https://chromium-review.googlesource.com/c/1340041
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57646}
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
This is a reland of b146824207.
Bug: chromium:843903, chromium:903586
Change-Id: Ida59ba4efd3abae6956b99aa104bbc66a3f01fdc
Reviewed-on: https://chromium-review.googlesource.com/c/1342924
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57644}
Emitting unwinding info for builtins for perf to consume doesn't make sense with
embedded builtins so let's just remove the option.
The perf support is meant for code on the heap and the builtins are not there
anymore. If we want perf to be able to unwind through builtins we should emit
the unwinding DWARF information directly into the binary, using the dedicated
.eh_frame ELF section. This would also mean GDB would be able to unwind through
builtins as well which would be great.
Change-Id: I751cc5eb1e6f7c0eeae6b37a42986ae8ea47d6a0
Reviewed-on: https://chromium-review.googlesource.com/c/1340294
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#57641}
Just compute it from the number of outstanding units.
R=ahaas@chromium.org
Bug: v8:7921
Change-Id: I30db10accc032bc50e1bbeab599325e1e971972b
Reviewed-on: https://chromium-review.googlesource.com/c/1341953
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57640}
for storing embedder data in native context. We can't use FixedArray because
with enabled pointer compression it would not be possible to fit raw aligned
pointer into 32-bits of a tagged value so we will need to store both tagged
and raw data in this array and therefore custom visitor is required.
Bug: v8:7703
Change-Id: Iae23d9aa76c79a572d5f0f1f3c0f924e8e407dd0
Reviewed-on: https://chromium-review.googlesource.com/c/1340295
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57639}
The concurrent marker needs to access the kind_specific_flags to decide
whether an embedded object reference is weak or not.
This patch turns the Code::code_data_container() into an acquire/release
atomic accessor and makes CodeDataContainer::kind_specific_flags a
relaxed atomic accessor.
Bug: v8:8459
Change-Id: I5251fed4e7b3315f8e229dfcfe2c23f611f4b333
Reviewed-on: https://chromium-review.googlesource.com/c/1337746
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57638}
This has been on by default and the flag itself is no
longer useful.
R=jarin@chromium.org, mslekova@chromium.org
Bug: v8:7790
Change-Id: Icdf111b974a01953ea775ccb96d50217f3c8321b
Reviewed-on: https://chromium-review.googlesource.com/c/1342918
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57637}
In the chrome-side implementation I currently use the default
trap handlers of V8, see https://crrev.com/c/1290955
Bug: chromium:906565
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I74c5a18c479ad1c69303d104ad4f040de436c4e7
Reviewed-on: https://chromium-review.googlesource.com/c/1282960
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57636}
If we're hashing a single sequential string we don't need the state that the
string hasher itself tracks. This also drops first_char since we can simply
check that array_index is still 0.
Change-Id: Icb69709267426358f7c301eeb45936843ba261b0
Reviewed-on: https://chromium-review.googlesource.com/c/1340258
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57635}
Our toolchain fails to link unittests without this change.
Change-Id: I48cc61f45fe5d533ed207f987371893caf54a919
Reviewed-on: https://chromium-review.googlesource.com/c/1340293
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#57634}
Previously the simplified operation `Number.min(x,y)` would lower to
`Select(Float64LessThan(x, y), x, y)` which would yield `y` when both
`x` and `y` are zeros, specifically when `x` was -0 and `y` was +0.
For `NumberMin` we need to use `Float64LessThanOrEqual` since we
generally allow -0 on the left hand side (in SimplifiedLowering).
Bug: chromium:906870
Change-Id: I25ae8fb19608b77c90ed130e69d9d9fa93fcea9d
Reviewed-on: https://chromium-review.googlesource.com/c/1342920
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57633}
This change ensures that we do not try to check the conversion of a floating
point constant, but insert the floating point constant instead.
Change-Id: I1c65e3a69acaea2ff805ba10317f64c0ac0ba098
Reviewed-on: https://chromium-review.googlesource.com/c/1340257
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57630}
This CL extends the lifetime of the typer in the pipeline until after
load elimination. This is a two-line CL to make it easy to revert if
we missed necessary brokerization.
If the CL sticks, we can remove some SetType calls in optimizations.
Change-Id: I4f27bfcada5221b2bae81297cd6b606881a7ccb8
Reviewed-on: https://chromium-review.googlesource.com/c/1341952
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57629}
This is pre-work to extend the typer phase until after load elinination.
Load elimination uses maps from CheckMaps/MapGuard/CompareMaps/LoadField
and this CL ensures they are brokerized.
Bug: v8:7790
Change-Id: Ic04f9c374bc736f03abf2bc7d257deb268d723c8
Reviewed-on: https://chromium-review.googlesource.com/c/1341950
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57628}
These instructions aren't implemented yet in TF or in Liftoff, but they
are properly decoded.
The table instructions (i.e. `table.{init,drop,copy}`) are validated,
since the table and element sections occur before the code section. The
memory instructions (i.e. `memory.{init,drop,copy,fill}`) are not
validated because the data section occurs after the code section, so it
can't be verified in one pass (without throwing a validation error
later).
There is currently a discussion about whether to add a new section
(similar to `func`) that predefines the number of expected data
segments. If we add this, then we can validate in one pass. For now,
we'll leave it unimplemented.
Bug: v8:7747
Change-Id: I839edf51721105a47a1fa8dd5e5e1bd855e72447
Reviewed-on: https://chromium-review.googlesource.com/c/1339241
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57622}
Port 1952f92838
Original Commit Message:
The platform specific macro assembler headers can not be included
directly. They require symbols declared in macro-assembler.h.
We also cannot include macro-assembler.h from the platform specific
headers, because that would form a cycle, and the include in
macro-assembler.h would be skipped, which then also fails.
This CL documents and enforces this unfortunate situation.
This helps with further iwyu cleanups.
Note that current code which includes the platform specific headers
only works because we transitively included macro-assembler.h already
before.
R=clemensh@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Iff6217ccb961d009a31f6adc50a7ef77ca1c8b70
Reviewed-on: https://chromium-review.googlesource.com/c/1342977
Reviewed-by: Muntasir Mallick <mmallick@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#57618}
Port 6e5671e1cd
Original Commit Message:
This marks the InterpreterEntryTrampoline as isolate-independent. With
this change, all builtins are now embedded.
Slight changes were needed to how we deopt into the trampoline. We now
store the entry address within the Interpreter class instead of
embedding the builtin code target.
R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I88aa263793c38cb60300fd795c0bd7011f337739
Reviewed-on: https://chromium-review.googlesource.com/c/1342738
Reviewed-by: Muntasir Mallick <mmallick@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#57617}
It removes special handling for Cells and PropertyCells. That handling
was required before when new space objects were embedded in code objects
via Cells. Since code objects support direct embedding now, the handling
can be removed.
The patch also makes sure to load the map of the object once using
the synchronized accessor, which will be needed for concurrent visiting
of code object.
Bug: v8:8459
Change-Id: I83833e19ad1da4a92e1a9be60b7c1dcd05c2b2be
Reviewed-on: https://chromium-review.googlesource.com/c/1337745
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57616}
which will eventually replace kPointerSize[Log2] to make it explicit what kind
of values is expected. With enabled pointer compression these sizes will not
be equal anymore.
This CL starts an incremental migration to proper constants.
Bug: v8:8477, v8:8238
Change-Id: Ia134d5a1c0639d9f9103d7a88bf87211e353ad50
Reviewed-on: https://chromium-review.googlesource.com/c/1340298
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57614}
Do less work in MultipleProfilers. Reduces runtime from ~8 mins to ~40
seconds.
Bug: v8:8474
Change-Id: I72b3266941ce40c8d064deaf00fb06f8d9fa8a70
Reviewed-on: https://chromium-review.googlesource.com/c/1341956
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57613}
Windows MASM becomes extremely slow when given very large data streams.
Runtime behavior is super-linear, with compile times of
5s for 50 KLOC in embedded.S
15s for 100KLOC
40s for 150KLOC
Compilation of the 320KLOC file produced for debug builds took more than
5 minutes.
This CL reduces compile time by emitting QWORD directives instead,
which reduces the emitted debug embedded.S to around 120KLOC and
compile times to around 40s.
Bug: v8:8475,v8:6666
Change-Id: I19903cdf7d1b70a65c00ca67f40129847b17f386
Reviewed-on: https://chromium-review.googlesource.com/c/1341951
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57609}
So far, we always finished the baseline units before finishing any
tiering unit. This will be refactored to finish all units from the
background threads, so the finishing can happen in any order.
Thus refactor the counters to count both separately, and trigger the
right events.
R=ahaas@chromium.org
Bug: v8:7921
Change-Id: Ia2d8ab3f70f9bc3406eff428da5d22580558887b
Reviewed-on: https://chromium-review.googlesource.com/c/1333669
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57608}
That way we can also cache A-Z, 0-9, _, $ (and all others obviously).
Change-Id: I394001646c80bbabf9b09f66eddc1bef82ae91b3
Reviewed-on: https://chromium-review.googlesource.com/c/1341948
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57606}
This reverts commit f09bec92c1.
Reason for revert: This CL was reverted by accident.
Original change's description:
> Revert "[wasm] Open HandleScope in LogCode"
>
> This reverts commit 2035042e87.
>
> Reason for revert: Blocks the roll, see https://chromium-swarm.appspot.com/task?id=41356e9eff2a5010&refresh=10&show_raw=1 for error message
>
> Original change's description:
> > [wasm] Open HandleScope in LogCode
> >
> > In WasmCode::LogCode we allocate handles, but not all callers of LogCode
> > open a HandleScope. Since the handles do not escape LogCode, we can just
> > open a Handlescope in the function.
> >
> > R=herhut@chromium.org
> >
> > Bug: v8:8461
> > Change-Id: I2031b467f976a9af6f541b60af245573f33d9676
> > Reviewed-on: https://chromium-review.googlesource.com/c/1337736
> > Reviewed-by: Stephan Herhut <herhut@chromium.org>
> > Commit-Queue: Andreas Haas <ahaas@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#57550}
>
> TBR=ahaas@chromium.org,herhut@chromium.org
>
> NOTRY=true
>
> Bug: v8:8461
> Change-Id: I4c95c79c029f4eed2bbaf1fcf7ccb04203335659
> Reviewed-on: https://chromium-review.googlesource.com/c/1340287
> Commit-Queue: Michael Hablich <hablich@chromium.org>
> Reviewed-by: Michael Hablich <hablich@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57583}
TBR=hablich@chromium.org,ahaas@chromium.org,herhut@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8461
Change-Id: Ieaabde1c686505795e9059354573c38dd982c52a
Reviewed-on: https://chromium-review.googlesource.com/c/1340251
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Stephan Herhut <herhut@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57603}
This reverts commit 585b4eef6a.
Reason for revert: Speculative, crbug 906567.
Original change's description:
> [turbofan] Improve NumberMultiply typing rule.
>
> The NumberMultiply typing rule gave up in the presence of NaN inputs,
> but we can still infer useful ranges here and just union the result
> of that with the NaN propagation (similar for MinusZero propagation).
> This way we can still makes sense of these ranges at the uses.
>
> Bug: v8:8015
> Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92
> Reviewed-on: https://chromium-review.googlesource.com/c/1261143
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56539}
TBR=sigurds@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8015
Change-Id: I3c652bafbbc0e5d1ad4ff288264fd4f4cbf71330
Reviewed-on: https://chromium-review.googlesource.com/c/1340253
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57602}
{RegisterConfiguration} is not used inside assembler.h.
Instead, include it where needed.
R=mstarzinger@chromium.org
Bug: v8:8238, v8:7490
Change-Id: Ic1aca23e862c30f5b5c7d13b866a859f1a4d4803
Reviewed-on: https://chromium-review.googlesource.com/c/1340244
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57601}
