Also we're not creating these any more via StringUtil in blink,
so these two helpers can go.
Change-Id: Ifdf700171ebc46cfbd6ce0af9a6f6ba73419a5a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1887689
Auto-Submit: Johannes Henkel <johannes@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64626}
The new API with v8::BackingStore should be used instead as explained in
https://docs.google.com/document/d/1sTc_jRL87Fu175Holm5SV0kajkseGl2r8ifGY76G35k
This also relaxes the pre-condition for [Shared]ArrayBuffer::Detach to
not require externalization first.
Bug: v8:9380, v8:9908
Change-Id: Idd119fcd28be84a2fae74ae86f7381fd997766f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859628
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64625}
Changes introduced in 30ec6a8 generates compilation error in gcc 8.1.0:
8.1.0/include/c++/bits/stl_iterator_base_funcs.h:183:2:
error: no match for 'operator--' (operand type is
'v8::internal::HandlerTable::LookupReturn(int)::Iterator')
--__i;
Which maybe caused by the following change in stl_iterator_base_funcs:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=248875
Overloading the "--" operator fixes the compilation error.
Change-Id: I32f54ddd4993375bf905996b5b1e66cd005256da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1888190
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64624}
This flag would help customers understand why Liftoff bails out, thus
make it available also in release builds.
R=jkummerow@chromium.org
Change-Id: Ie2f69cbeaee617632f772030a3e03f052f688a10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1888071
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64622}
There are a couple of bugs here:
1. The immediate used for vinsertps is wrong when lane == 1, the first
two bits specify which element of the source is copied, and it should
always be 00, 01 to copy the first 2 lanes of source.
2. For both cases, the second insertps call should be using dst as the
src, since dst was already updated by the first insertps call, it was
incorrectly using the old value of src. This was probably working
correctly because in many cases dst and src happened to be the same
register.
3. rep cannot be same as dst, because dst is overwritten, and rep should
stay the same
I also modified the F64x2ReplaceLane to test separately for replacing
lane 0 and lane 1.
Fixed bug 3. for arm and arm64.
Bug: v8:9728
Change-Id: Iec6e48bcfbc7d27908dd86d5f113a8b5dedd499b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1877055
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64620}
New revision: d2fc9b958e1eeb1e956f3e2208afa9923bdc9b67
To roll this I need to update some call sites; this is because the
Serializable interface is changing.
Upstream change / review was here:
https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1879870
Change-Id: I93c4747609c6003baf1c160a68b8fb6bb07ac565
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879519
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64618}
CallDebugOnFunctionCall was always using Registers and not Immediates.
Then ParameterCount is not really needed. Since updating that, we
could update other functions, e.g InvokeFunction, to only use
registers too.
Also removed now irrelevant variables, e.g definitely_mismatches.
Bug: v8:9771
Change-Id: I83382c146dd47ccb8bb329f5becb5e941e4c3968
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871605
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64616}
Inlines UpdateEffectControlWith and AddClonedNode in GraphAssembler to address
a regression in some benchmarks caused by Add the ability for GraphAssembler
to update basic blocks.
BUG=chromium:1018661,v8:9684
Change-Id: I05513c13305465310552448192e0474f5aaa4a20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886917
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64615}
This adds some arguments to trace events to better see whether large
times spent in these events are reasonable.
R=mstarzinger@chromium.org
Change-Id: I6097d988875d4911aff9741a1ed16590a442f60b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886912
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64614}
When inlined allocations are disabled, the space->limit() does not point to the
end of the current page. Instead, it points to the current allocation pointer so
is the same as space->top().
See how the limit is computed, if heap()->inline_allocation_disabled(), then the
limit will be the same as the requested allocation area:
```
Address SpaceWithLinearArea::ComputeLimit(Address start, Address end,
size_t min_size) {
DCHECK_GE(end - start, min_size);
if (heap()->inline_allocation_disabled()) {
// Fit the requested area exactly.
return start + min_size;
} else if (SupportsInlineAllocation() && AllocationObserversActive()) {
// ...
} else {
// The entire node can be used as the linear allocation area.
return end;
}
}
```
If we want to simulate filling up a whole page in the new space, we can instead
look at the ToSpace's page_high() which will be the end of the current page in
which we're allocating.
Bug: v8:9906
Change-Id: I81113d151bc083cd22d17ea1a4fbae7fef9dff6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886914
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#64612}
1) don't print off-heap TypedArray elements with --mock-arraybuffer-allocator
2) print integer HeapNumbers in safe integer range with max precision:
as 9007199254740991.0 instead of 9.0072e+15
Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
Bug: v8:4153
Change-Id: Ie79fc08c44374981a840772fde4f414458d31c52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883565
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64609}
Remove serialized_ flags where there's only one thing to be serialized
and its pointer can be used instead.
Bug: v8:7790
Change-Id: I489bb3085cef574f81f417f950898d4348f8b9ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886911
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64608}
The {IsWasmFrame} check in {ComputeLocationFromStackTrace} only returned
true for compiled frames, but not for interpreted ones. Thus, for
interpreted frames we would run into the code for JS frames, which
assumes that a {JSFunction} is available.
This CL fixes this issue by renaming {IsWasmFrame} to
{IsWasmCompiledFrame}, and introducing a new {IsWasmFrame} method which
returns true for both compiled and interpreted frames.
R=mstarzinger@chromium.org
Bug: chromium:1018227
Change-Id: If83b4129edaad775a212ccb741f3c62eabc2addb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883892
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64607}
ClusterFuzzer found that a context can be created by
a call to the runtime when checking for context extensions
on the bytecode graph builder.
That happens in large contexts.
Bug: chromium:1019069
Change-Id: I7ab66dceedd56476ab972d7998ef4ca6896dc868
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886691
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64605}
In some places objects where allocated on the heap and stored
in a std::unique_ptr later. This CL changes this so that a
The std::unique_ptr<T>(new T(...)) construct is replaced with
std: :unique_ptr takes ownership of new objects immediately.
std: :make_unique<T>(...) where possible.
Change-Id: Icdb4c9e7536d2b437df1a5bb6c3ad94c97e1e4cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871916
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64603}
Follow up from https://crrev.com/c/1874378, declare these SSSE3
instructions using a separate macro that declares the right scope.
Bug: v8:9561
Change-Id: Ia4370a4dff9e9d13b08c5e95a45670556d6ff1e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1875657
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64601}
We know statically if a context has an extension slot or not, but that
was dynamically checked.
The CL lifts the ScopeInfo chain to the compiler and does the check
statically, it only generates the undefined check if the context
has an extension slot.
Bug: v8:9744
Change-Id: I169d05bb11b36501e97af00d30ae44bedcd6be83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876051
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64599}
This change begins making use of the fact that Torque now knows about
the relationship between classes and instance types, to replace a few
repetitive lists:
- Instance type checkers (single and range), defined in
src/objects/instance-type.h
- Verification dispatch in src/diagnostics/objects-debug.cc
- Printer dispatch in src/diagnostics/objects-printer.cc
- Postmortem object type detection in
tools/debug_helper/get-object-properties.cc
Torque is updated to generate four macro lists for the instance types,
representing all of the classes separated in two dimensions: classes
that correspond to a single instance type versus those that have a
range, and classes that are fully defined in Torque (with fields and
methods inside '{}') versus those that are only declared. The latter
distinction is useful because fully-defined classes are guaranteed to
correspond to real C++ classes, whereas only-declared classes are not.
A few other changes were required to make the lists above work:
- Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does
and avoid conflicts with the new macro-generated IsFiller method. This
is the part I'm most worried about: I think the new name is an
improvement for clarity and consistency, but I could imagine someone
typing IsFiller out of habit and introducing a bug. If we'd prefer to
keep the name IsFiller, my other idea is to rename FreeSpace to
VariableSizeFiller and Filler to FixedSizeFiller.
- Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is
expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE.
- Normalized the dispatched behavior for BigIntBase and HeapNumber.
- Added a few new object printers.
Bug: v8:7793
Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64597}
Add support to verify the update schedule after ScheduledEffectControlLinearization
and ScheduledMachineLowering phases. To do so, we need to recompute the immediate
dominator tree of the scheduled blocks.
BUG=v8:9684
Change-Id: I849fb7e3e699ca56c5115d90a53006d517cf3fe5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881160
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64596}
OrderedHashTableHandler::Delete was missed in the migration CL
crrev.com/c/1106160 because it had no callers. This CL also
migrates said function and adds usages in tests which force
instantiation (and ensure we catch these errors without MSVC).
Bug: v8:9905
Change-Id: Ieb1d1c89754f98e1d88d841d2933f46a6a4820d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883891
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64595}
Otherwise we might reuse a node that is scheduled later in the unchanged block.
BUG=v8:9684
Change-Id: I655b538384d5ed8782d3d9bbb883037462003693
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881155
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64594}
Since we only care about one bit in the lower 32 bits, we can always
perform smi checking while looking at the lower bits.
This improves pointer compression, since we wouldn't need to decompress,
while not affecting the non-pointer compression case.
Change-Id: Ic020fefcc92de0516148f34a3caacc60ff29556b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876050
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64593}
Otherwise the expression scope may be in a weird state and DCHECKs for valid
arrow functions in ValidateAndCreateScope willl unnecessarily fire.
Bug: chromium:1018611
Change-Id: I101b8902dce07c29aacba3e7a5e6f86d66505d5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879906
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64591}
... and let it gracefully crash with OOM.
Bug: v8:4153, chromium:1018598
Change-Id: I20dd9874cdbdf78665de3a83d0bc1611dc088c68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883551
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64589}
This reverts commit d7793c0684.
Reason for revert: This cl *will* cause regexp regressions. We are trying to gauge the real world impact.
Original change's description:
> Revert "[regexp] Clone match info for match indices."
>
> This reverts commit dfd9ceb984.
>
> Reason for revert: Regressions https://chromeperf.appspot.com/group_report?rev=64356https://crbug.com/1015749
>
> Original change's description:
> > [regexp] Clone match info for match indices.
> >
> > The current behavior for generating match indices simply stashes a
> > pointer to the match info and then constructs the indices lazily.
> > However, it turns out the match info object used to create the result
> > object is the regexp_last_match_info living on native context, and thus
> > it can change between the creation of the result object and the generation
> > of indices. This cl clones the match info which will be safer.
> >
> > Bug: v8:9548
> > Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585
> > Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#64356}
>
> TBR=jgruber@chromium.org,joshualitt@chromium.org
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> Bug: v8:9548, chromium:1015749
> Change-Id: I9c30b8fb459cf2aa89d920bf061614441250844d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870236
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64407}
TBR=jgruber@chromium.org,joshualitt@chromium.org
Bug: v8:9548, chromium:1015749
Change-Id: I151511307e3d8752fdbde4b8247514031b141b08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879587
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64587}
The `Printf()` macro-assembler method can be very useful as a debugging
tool. However, it's only available to the MacroAssembler making it impossible to
use in jitted code or builtins.
Change-Id: I0c1e6b98d5c6b7fc34990e87d0eb4e37f6322627
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879287
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64585}
The overload taking a `MicrotaskQueue*` was introduced in
cce33f3752 but never actually implemented.
This aligns the constructor signature to actually work, and
aligns it with e.g. `MicrotasksScope`. The previous signature
without an `Isolate*` argument would not work, because there’s
no pointer back from a MicrotaskQueue to the Isolate.
Refs: https://chromium-review.googlesource.com/c/v8/v8/+/1414950
Bug: v8:8124
Change-Id: I5dbaabef54c8de2b48f6172808825a186971524d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879901
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64584}
The `Context::SlowGetAlignedPointerFromEmbedderData()` method returns
a pointer, so the fact that it allocates handles is not obvious to
the caller.
Since this is the slow path anyway, simply add a handle scope inside
of it.
The tests are also modified to perform the same check for the
`Object` equivalent of this method.
Change-Id: I5f03c9a7b70b3a17315609df021606a53c9feb2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879902
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64583}
Now that all builtins are embedded, it is no longer needed to have a
fallback variant where WebAssembly runtime stubs tail-call existing
(non-embedded) builtins, just call the (embedded) builtin directly.
R=clemensb@chromium.org
BUG=v8:6666,v8:9810
Change-Id: Id8a2b2089cabc77f841f484986d8212ca2918ef4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883550
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64581}
When global object has proxies we should first call hasProperty and
then call GetProperty according to spec. This cl fixes both
LoadGlobal and LoadLookupGlobal to correctly handle these cases.
Also fixes tests that didn't expect hasProperty to be called.
Change-Id: I3a45df7ae24be74dd46cf04cafbf8c2d7018b3af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876059
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64580}
When rewiring a block to throw, we need to remove the current block from the list
of predecessors for all of our successors, as well as clearing our current successors.
BUG=v8:9684
Change-Id: I0da063b2ef707f07ea27a5f72cabd2ff9a91cc42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881154
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64579}
