AddToDictionaryTemplate in literal-objects.cc was missing several
cases when handling the overwriting between properties with statically
known and dynamically computed names. This led to wrong enumeration
orders in class prototypes created from class templates.
Bug: v8:11158
Change-Id: I7381b4680ec533bd307a6c32d75c8a66394869df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536464
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71266}
Megamorphic load builtins are a performance optimization when current
feedback is megamorphic. We can't make this assumption for shared NCI
code though, since feedback in other native contexts may *not* be
megamorphic, and we'd thus miss out on necessary feedback collection.
Bug: v8:8888
Change-Id: I2adc5ef9a6b021b35cf26f975c79228d556bf94f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546694
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71264}
... to --turbo-dynamic-map-checks. With the upcoming use in NCI code,
this feature is no longer used exclusively by Turboprop.
Bug: v8:8888
Change-Id: I61e01db086fd2e8566d2e2a09574be74b6e5a7bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546693
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71263}
There is a flag in the WebAssembly trap handler that is set whenever
WebAssembly code is entered, and that is reset when WebAssembly code is
left. In runtime functions we have DCHECKs in place that check the
value of this flag.
This flag is only needed when trap handlers are enabled though. When
trap handlers are disabled, the flag is not enabled and disabled
consistently. DCHECKs should therefore only check the flag value when
trap handlers are actually enabled.
R=manoskouk@chromium.orgCC=vkont@google.com
Bug: v8:10982
Change-Id: I3325f6057ff8d9c39d029ef04c55792162d927f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545708
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71261}
This has similar performance as the thread_id check. It removes the need
to get the isolate for this check though, so it's a net positive.
Bug: v8:7790
Change-Id: I329bb9d5fe695fb9ef4990ba3593703b1eedca0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546690
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71259}
Some tests explicitly set the --always-opt flag, but they are not
ignored when the testrunner is invoked with variant="jitless" or
variant="nooptimization".
This CL implies --opt from --always-opt and excludes
--always-opt when the testrunner is invoked with jitless or
nooptimization variants.
Change-Id: I49ebc3907666c462aa09a294a39a504a0c90de96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2544548
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71258}
AssembleCode used CcTest::i_isolate() to load the isolate, however this
might not be the isolate that should be used. Therefore take the isolate
as an explicit argument.
Note that this changes behavior of ExecuteMemoryAccess in
test-sync-primitives-arm.cc. I think this test inadvertently created
the assembly code in the isolate of another thread, while it didn't
use the isolate it sets the handle scope up for.
This change is required for relanding https://crrev.com/c/2543399.
Bug: v8:10315
Change-Id: I754f4b45cec93727309fa73723011afe976f3689
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546682
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71257}
Pointer compression is not supported in arm32 and we will not encounter
those MachineRepresentations.
Bug: v8:7703
Change-Id: I72c94d57b27710bdca54d649755a91e869b4947e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546686
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71256}
This CL fixes a spot (pointed out by Mythri) in which it was possible
to start running unoptimized bytecode even if cached NCI code was
present.
Previously, the CompileLazy builtin would skip the runtime and start
running bytecode immediately if the SharedFunctionInfo was already
compiled; any NCI code was ignored.
This CL changes the CompileLazy builtin to additionally check the
SFI::may_have_cached_code bit. If set, call into the (new) function
Runtime::kTryInstallNCICode to try and install NCI code.
Bug: v8:8888
Change-Id: Icbee9f0780f9b65e9339f1a958f5b28abe42c810
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546680
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71255}
This CL introduces a new fast_api_call_target field on the isolate,
which is set by Turbofan before making the fast call. It then uses
the field when creating a stack sample and stores it in the existing
external_callback_entry used for regular API callbacks. The CL also
adds a cctest with simple usage scenario and introduces a minor
refactoring in test-api.cc.
Design doc:
https://docs.google.com/document/d/1r32qlPzGz0P7nieisJ5h2qfSnWOs40Cigt0LXPipejE/edit
Bug: chromium:1052746
Change-Id: I2dab1bc395ccab0c14088f7c354fb52b08df8d32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2488683
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71254}
This removes the dependency on Lua for running gcmole, and Python's
expressiveness lets us clean up the code a bit, including getting rid
of global variables, embedding the multiprocessing (removing the need
for a separate `parallel.py`), and using difflib for printing the test
expectation diff.
Bug: v8:11169, v8:8590, chromium:1097212
Change-Id: If0ab5ea6f764864855d73cd0ba63cb37c1823955
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543927
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71253}
To be unskipped once root cause is fixed.
Bug: v8:11166
Change-Id: I03c3ac9a7e715fce7683d230965bd92a410c8f91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546681
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71248}
These are prototype instructions, and were missing validation checks for
lane immediates.
Bug: chromium:1149040
Change-Id: I22537061e26980a1aa0b3944839ab947e5351d9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543164
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71245}
In https://crrev.com/c/v8/v8/+/2536465 we added acquiring the lock in
WriteToFlat. Then, acquiring in TryStringToDouble not only is not
necessary but also has undefined behaviour.
This was causing timeouts and meant the tests were disabled in
https://crrev.com/c/v8/v8/+/2543398.
Bug: v8:7790, v8:11171
Change-Id: Iaab4e5079bac96786e536a2e4b766e93ea17e2c4
Fixes: v8:11171
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2544544
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71242}
Guard for extremely large and small values passed to
Isolate::AdjustAmountOfExternalAllocatedMemory from the embedder.
Bug: chromium:1147372
Change-Id: Ib1470bdf2dd16cbc6e61dd1bca97fa5a66f04c77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543925
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71241}
Use the recently added -mmark-bti-property Clang flag to add
GNU_PROPERTY_AARCH64_FEATURE_1_BTI to the ELF GNU program properties.
Bug: v8:10026
Change-Id: Id35a60c9f5a8b3019313d56a142ab8f481e095a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543934
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#71240}
It took me a while to figure out how to set up everything to run the
fuzzer locally. These improved error messages would have helped to find
errors earlier.
R=machenbach@chromium.org
Bug: chromium:1142437
Change-Id: I414de0a8448cd81fdbf999cc7c3c8cf9394354f6
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543397
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71239}
This reverts commit 800307f6a5.
Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release%20builder/1258
Original change's description:
> [wasm][memory64] Prepare Liftoff for ptrsize offsets
>
> This CL prepares the LiftoffAssembler interface for uintptr_t offsets.
> Many places can still only handle 32-bit values, but after this CL we can
> start storing the offsets as uintptr_t in the memory access immediates.
> Some TODOs are placed to extend code generation for 64-bit additions, if
> memory64 is enabled.
> All of this will be addressed in follow-up CLs.
>
> R=manoskouk@chromium.org
>
> Bug: v8:10949
> Change-Id: Id3b9b8aa555ab41f082ba012f4f8d80586c35b89
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529452
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71236}
TBR=clemensb@chromium.org,manoskouk@chromium.org
Change-Id: I6246d2f16bc44b328915c6a66e9933f516459038
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10949
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2544546
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71238}
Make the three map's bitfields use release/acquire semantics. This
ensures, for example, that when we set the number of own descriptors on
the map we will do so with a release store.
Also, start reading and writing said bitfields concurrently when
concurrent inlining is enabled. Note the BIMODAL_ACCESSOR_WITH_FLAG_B
macro which enables this.
Bug: v8:7790
Change-Id: I16561d8e065c50ce272b085d9606b98e37922633
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536640
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71237}
This CL prepares the LiftoffAssembler interface for uintptr_t offsets.
Many places can still only handle 32-bit values, but after this CL we can
start storing the offsets as uintptr_t in the memory access immediates.
Some TODOs are placed to extend code generation for 64-bit additions, if
memory64 is enabled.
All of this will be addressed in follow-up CLs.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: Id3b9b8aa555ab41f082ba012f4f8d80586c35b89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529452
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71236}
This CL increases the budget for the tiering strategy of the js-to-wasm
wrappers from 6 (which was initially picked at random, as the feature
was experimental) to 1000 calls (which is picked based on benchmarking).
The high-level rationale behind such a choice can be summarized in the
following:
- The generic wrapper is not that much slower than the specific
wrappers, so it can handle up to some thousands of calls quite well.
- After that, the generic wrapper starts lacking compared to the
specific wrappers, even if compiling a specific wrapper means blocking
the main thread.
- Real-life applications do call exported functions thousands of times,
so this is not an unrealistic choice.
Bug: v8:10982
Change-Id: I143dd11e535101fd24810f63ed8b987cd03c4326
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2539913
Commit-Queue: Vicky Kontoura <vkont@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71232}
Add a "combination" assert scope class, which combines multiple existing
assert scopes. This will allow scopes with functional overlap, e.g.
DisallowGarbageCollection and DisallowHeapAllocation, to share an assert
type rather than rather than requiring users to remember to set both. To
demonstrate this, this redefines DisallowGarbageCollection to a
combination of DisallowHeapAllocation and a new DisallowSafepoints, and
some of the DCHECKs checking both are simplified to only check one or
the other, as appropriate.
The combination classes become subclasses of the existing assert scopes,
so that they can be used in their place as e.g. a function parameter,
e.g. DisallowGarbageCollection can be passed to a function expecting
const DisallowHeapAllocation&.
As a drive-by, this also changes the per-thread assert scopes to use a
bitmask, rather than a bool array, to store their per-thread data. The
per-isolate scopes already used a bitmask, so this unifies the
behaviour between the two.
Change-Id: I209e0a56f45e124c0ccadbd9fb77f39e070612fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2534814
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71231}
Port the fix from https://crrev.com/c/1414858 to ia32. TL;DR, _xgetbv is
a reserved name.
Change-Id: I97cb90ea7d244c02326432cfbfd55419a0a9854a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543933
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71229}
This reverts commit e95e1b6234.
Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/23064
Original change's description:
> [heap] Introduce LocalIsolate for main thread
>
> Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
> kept alive during the whole lifetime of the Isolate. The main thread
> LocalIsolate starts in the Running state in contrast to the background
> thread LocalIsolates (those start in Parked).
>
> Code paths in Turbofan that used to create a LocalIsolate on the main
> thread can now simply use the main thread LocalIsolate.
>
> LocalIsolate for the main thread will help in reducing differences
> between the main and background threads. The goal is that the main
> thread behaves more like a background thread.
>
> The main thread LocalIsolate should also make it simpler to share code
> between main thread and background threads by using LocalIsolate for
> both.
>
> Bug: v8:10315
> Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71226}
TBR=ulan@chromium.org,yangguo@chromium.org,neis@chromium.org,leszeks@chromium.org,szuend@chromium.org,dinfuehr@chromium.org
Change-Id: Ia70b4bfe3b8fa26bf8d6a7dc612a310b0ed54073
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543937
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71228}
This CL adds a cctest to verify that the tiering strategy for the
js-to-wasm wrappers works for functions that are only indirectly
exported through exported tables.
Bug: v8:10982
Change-Id: I8eede14ab620dbadb75af42b78bfac88230a6dd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536644
Commit-Queue: Vicky Kontoura <vkont@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71227}
Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
kept alive during the whole lifetime of the Isolate. The main thread
LocalIsolate starts in the Running state in contrast to the background
thread LocalIsolates (those start in Parked).
Code paths in Turbofan that used to create a LocalIsolate on the main
thread can now simply use the main thread LocalIsolate.
LocalIsolate for the main thread will help in reducing differences
between the main and background threads. The goal is that the main
thread behaves more like a background thread.
The main thread LocalIsolate should also make it simpler to share code
between main thread and background threads by using LocalIsolate for
both.
Bug: v8:10315
Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71226}
This CL enables a first batch of feedback-based optimizations in NCI
code. Specifically, optimizations based on unary, binary, compare,
for-in-next, and for-in-prepare feedback are now enabled.
This has two main implications:
1. NCI code can now deopt. Deoptimized code is currently thrown away
permanently and cannot be reused. Now that shared/cached NCI code can
deopt, this leads to an interesting question of what should happen
with deoptimized NCI code. The answer in this CL is to remove the
cache entry (it may later be re-added).
2. Tiering up from NCI to TF still requires feedback; since NCI code,
starting with this CL, no longer collects full feedback, feedback must
be created in some other way. This is solved by sharing a
context-independent encoding of feedback across native contexts.
Feedback is shared through a new SerializedFeedback object type,
essentially a byte array of serialized feedback. Currently, only
smi-based feedback is shared, but map-based feedback will be added in
the future.
SerializedFeedback is kept in the NCI cache alongside NCI Code
objects. It is created on NCI cache insertion, and deserialized upon
NCI cache hits.
Bug: v8:8888
Change-Id: Ic0d5fbea3aa4d3b0a165624dab9d0283b07dcee7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2531775
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71224}
When a thread gets archived, we still need to scan and update debug
roots on GCs for it. Otherwise we restore stale references when the
thread becomes active again.
Bug: v8:11145
Change-Id: I88f4c1534e826aed222e7fb67bd82bb0a4758fab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2537691
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71221}
all_true, any_true, bitmask, and extract_lane all replace a simd type
with single scalar, so we don't need to set nullptr for the extraneous
lane, and can set num_lanes to 1.
So for a call node with any of the above nodes as one of its value, we
were incorrectly replacing the extract lane node with 4 nodes - it
should only be 1 scalar node.
Drive by fix for LowerShift, it needs to check if the shift value node
has replacement (e.g. if it is an extract lane node).
Also we weren't setting the lowered type of a kPhi node. This can be a
problem if the output of a Phi node is used by a F32x4ExtractLane and
I32x4ExtractLane, which is possible (and type correct since both take
v128). This will require that the output be both a float and a int,
which is impossible. So fix it to Int32x4, and the uses of the phi nodes
will convert appropriately.
Added a test for the call node. Also tested this code by running one of
our benchmarks, which exercises the Phi logic.
Bug: v8:10507
Change-Id: I01a76b349ba9d0e157b64e737bdb4c70f96aa954
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536952
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71218}
