- 29 Jul, 2022 22 commits
-
-
Matthias Liedtke authored
Table<any> is not allowed any more and may therefore not be generated by the fuzzer. Instead, the new type is table<externref>. Bug: chromium:1348437 Change-Id: Ibf788222fc777508e59178db48e6497a18b250d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793610 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Auto-Submit: Matthias Liedtke <mliedtke@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#82073}
-
Manos Koukoutos authored
This is required by the MVP spec. In the future, it might be possible to pass values for any immutable fields. Bug: v8:7748 Change-Id: Ie7705b48e9d6ebb87d5e1b0a2a10556302395db6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793383Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#82072}
-
Matthias Liedtke authored
Change-Id: I19105432a71b5850264624c23d7bb732193100f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791046Reviewed-by:
-
Clemens Backes authored
Many platform-dependent LiftoffAssembler methods do not use all parameters. Comment out the name of unused ones, to make it easier to see which implementation uses which parameters. Also, remove {is_load_mem} from arm's {LoadInternal}, because it is unused there. R=jkummerow@chromium.org Bug: v8:10949 Change-Id: I57281237c493cc35c3cd31d814bca9bef510fdd2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791049Reviewed-by: -
Tobias Tebbi authored
Bug: v8:13114 Change-Id: I69ec1cbc8021e4c86aec705466f028cc95a05261 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793395 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#82069}
-
Victor Gomes authored
Support slow path for the following bytecodes: - LdaLookupSlot - LdaLookupContextSlot - LdaLookupGlobalSlot - LdaLookupSlotInsideTypeof - LdaLookupContextSlotInsideTypeof - LdaLookupGlobalSlotInsideTypeof - DefineKeyedOwnPropertyInLiteral - CollectTypeProfile - Debugger Bug: v8:7700 Change-Id: Idf661ca739de184df2eb22e1fb7247c71c6dd438 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793393 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#82068}
-
Clemens Backes authored
If dynamic tiering or lazy compilation is enabled (which is the default), the initial code space needs to be big enough to also hold the lazy compilation jump table. Otherwise a CHECK will fail later when trying to allocate that table (in UseLazyStub). R=ahaas@chromium.org Bug: chromium:1348472, chromium:1348214 Change-Id: If7a091a5782f1b2099d35d1a06292dddbaeb0598 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793389 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#82067}
-
Leszek Swirski authored
If a value is expected to be in a particular register for a register merge, allow for it to be moved there from another register, without expecting it to be spilled. Bug: v8:7700 Change-Id: I9ef5e77b3a744a6284f4790ec9d5a7c60739a710 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793391Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#82066}
-
Dominik Inführ authored
In addition to the marking barrier we now also need the shared barrier for properly tracking the old-to-shared remembered set. So invoke the full write barrier for set_map and set_map_after_allocation. Bug: v8:11708 Change-Id: Ic234e7fad3733ab1348298f5fcc2b76e44cf4b8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793388Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#82065}
-
Manos Koukoutos authored
Currently, we canonicalize types for call_indirect by looking in the current module for a signature of the same shape. This is not enough as of wasm-gc. Instead, the canonical identifier representing a type has to be computed via isorecursive canonicalization. This change is implemented behind a flag for now. Future work: Also integrate export wrappers with isorecursive canonical types. We need to store wrappers in instance-independent storage. Drive-by: - Always emit type check for call_indirect. We did not emit a check only when typed-function-references was enabled, but not gc. This is not something that will be possible long-term. - Fix some wasm cctests. Bug: v8:7748 Change-Id: I7cced187009ac148c833dff5e720a8bb9a717e68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3784600Reviewed-by:
-
Lu Yahan authored
This is a reland of commit 859ff489 Original change's description: > [riscv][Cleanup] Use CmpInstanceTypeRange in MacroAssembler > > Bug: v8:11325 > > Change-Id: I2eae55b49ea01567460bd0adfbb819c893ce7cd7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793210 > Auto-Submit: Yahan Lu <yahan@iscas.ac.cn> > Reviewed-by: ji qiu <qiuji@iscas.ac.cn> > Commit-Queue: ji qiu <qiuji@iscas.ac.cn> > Cr-Commit-Position: refs/heads/main@{#82054} Bug: v8:11325 Change-Id: I9db48ed2783a875b617d4161ce7405c0c32bebbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793466 Commit-Queue: ji qiu <qiuji@iscas.ac.cn> Reviewed-by:
ji qiu <qiuji@iscas.ac.cn> Cr-Commit-Position: refs/heads/main@{#82063}
-
Victor Gomes authored
Bug: v8:7700 Change-Id: I51f3da86cb71ec5980c799a77ce280d83ca42cd7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793387 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Remove the return value from various UpdateSlot methods. These methods were always returning REMOVE_SLOT anyways. Bug: v8:11708 Change-Id: I5398f0df14e93e3e74a13aea42d7c422ffc100a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793384Reviewed-by:
-
Clemens Backes authored
We sometimes create jobs that initially hold no work. In those cases, use CreateJob instead of PostJob. New background threads will later be spawned when NotifyConcurrencyIncrease is called. R=etiennep@chromium.org Bug: v8:13096 Change-Id: Ieb9f9e03d01af6a72fe5785be72c523a553d0f1d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762578Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#82060}
-
Victor Gomes authored
Bug: v8:7700 Change-Id: Ifab7c3ba40e8dcb5e1811a239b4970c6763c9df2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793385Reviewed-by:
-
Clemens Backes authored
Embedders must override the method, because returning a nullptr will make V8 crash. Hence the method should be abstract. Bug: v8:12425 Change-Id: I79e1759acd2a5f41424145637ee1fbd161889ec1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779694Reviewed-by:
-
Peter Kasting authored
This eliminates some "bitwise operation between different enumeration types" warnings in c++20, where such ops are deprecated. Bug: chromium:1284275 Change-Id: Ie7f1d5e9430029bc694cef0358d217871670a8d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791964Reviewed-by:
-
Yahan Lu authored
This reverts commit 859ff489. Reason for revert: Assert Failed in debug Original change's description: > [riscv][Cleanup] Use CmpInstanceTypeRange in MacroAssembler > > Bug: v8:11325 > > Change-Id: I2eae55b49ea01567460bd0adfbb819c893ce7cd7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793210 > Auto-Submit: Yahan Lu <yahan@iscas.ac.cn> > Reviewed-by: ji qiu <qiuji@iscas.ac.cn> > Commit-Queue: ji qiu <qiuji@iscas.ac.cn> > Cr-Commit-Position: refs/heads/main@{#82054} Bug: v8:11325 Change-Id: I57caf4ca86ac1b8b3afa94650c156e375158a3e9 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793465 Auto-Submit: Yahan Lu <yahan@iscas.ac.cn> Commit-Queue: Yahan Lu <yahan@iscas.ac.cn> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#82056}
-
v8-ci-autoroll-builder authored
Rolling v8/buildtools/third_party/libunwind/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libunwind/+log/2a908ee..012c343 Rolling v8/third_party/fuchsia-sdk/sdk: version:9.20220727.1.1..version:9.20220728.1.1 R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com Change-Id: Ia1a09b06b140e7d670628d335882a0343210eda0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792172 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#82055}
-
Lu Yahan authored
Bug: v8:11325 Change-Id: I2eae55b49ea01567460bd0adfbb819c893ce7cd7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793210 Auto-Submit: Yahan Lu <yahan@iscas.ac.cn> Reviewed-by:
-
Lu Yahan authored
This very large changeset adds support for RISCV32. Bug: v8:13025 Change-Id: Ieacc857131e6620f0fcfd7daa88a0f8d77056aa9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736732Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Yahan Lu <yahan@iscas.ac.cn> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
-
Frank Tang authored
Bug: v8:7834 Change-Id: I79646de331fde36626dd5604b38ef8dc60dafc3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793003 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/main@{#82052}
-
- 28 Jul, 2022 18 commits
-
-
Milad Fa authored
Change-Id: I4bbe5be6c6f13ee5664fa231d8dd9d59aa0ef579 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792166Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/main@{#82051}
-
Frank Tang authored
This is a reland of commit 33043888 Original change's description: > [test262] Roll test262 > > https://chromium.googlesource.com/external/github.com/tc39/test262/+log/3ddfa0cd..e41d581c > > Bug: v8:7834 > Change-Id: Id1c5b07f109ab6f60498eb7185becc508d16af1e > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3786907 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81980} Bug: v8:7834 Change-Id: Ic7e0378b11a05161b69965cff06985b9a2d954fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788719Reviewed-by:
-
Frank Tang authored
Also need to change how we got the prototype of Intl.NumberFormat and Intl.PluralRules to install function in bootstrapper.cc code to avoid assertion in JSReceiver casting. For m106 Flag: harmony_intl_number_format_v3 https://chromestatus.com/feature/5707621009981440 Design doc: https://docs.google.com/document/d/19jAogPBb6W4Samt8NWGZKu47iv0_KoQhBvLgQH3xvr8 and https://docs.google.com/document/d/14zxGub6Os6nARzH6XstOZX05w2537sZo_ZSSlGjGpBM R2T: https://groups.google.com/a/chromium.org/g/blink-dev/c/vy6rCuh3r_0/m/1Q2FHx9hBAAJ I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/mN6o7uk2hjM/m/I6-C006lBwAJ LGTMs from API Owners: bratell.d@gmail.com, miketaylr@chromium.org, mkwst@chromium.org Bug: v8:10776 Change-Id: I2c11e1c53390bdc6246caf084661d82e08a4d94c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3790120 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
Manos Koukoutos authored
arrayref, dataref and i31ref get changed to (ref null t). Bug: v8:7748 Change-Id: Iae0e6969a1f71ccf1f193c267d761b7a1796f67b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788093 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Etienne Pierre-doray authored
CreateJob() doesn't schedule anything until Join() or Notify*() is called. CreateJob().Join() will thus schedule the right number of workers for the job right away (taking into account the main thread contributes), whereas PostJob().Join() schedules 1 worker that won't be necessary once doing Join() and the main thread kicks in. This has the effect of reducing 1 unnecessary context switch each time the jobs are schedule. Bug: chromium:1287665 Change-Id: Ie262f8904cc8ac78d9e5cbd23ef28dc5b013a625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3746080Reviewed-by:
-
Marja Hölttä authored
It was delegating to GetDerivedMap but not handling the possible error coming from it. Bug: v8:11111,chromium:1347722 Change-Id: I348ed721281d8edd324f0e364d8ed45602cb9f54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791063Reviewed-by:
-
Seth Brenith authored
This is a reland of commit e895b7af The unit test has been updated to work correctly when --stress-incremental-marking is enabled. Original change's description: > Background merging of deserialized scripts > > Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions > with which an embedder could request that V8 merge newly deserialized > script data into an existing Script from the Isolate's compilation > cache. This change implements those new functions. This functionality is > still disabled by default due to the flag > merge_background_deserialized_script_with_compilation_cache. > > The goal of this new functionality is to reduce memory usage when > multiple frames load the same script with a long delay between (long > enough for the script to have been evicted from Blink's in-memory cache > and for the top-level SharedFunctionInfo to be flushed). In that case, > there are two Script objects for the same script: one which was found in > the Isolate compilation cache (the "old" script), and one which was > recently deserialized (the "new" script). The new script's object graph > is essentially standalone: it may point to internalized strings and > readonly objects such as the empty feedback metadata, but otherwise > it is unconnected to the rest of the heap. The merging logic takes any > useful data from the new script's object graph and attaches it into the > old script's object graph, so that the new Script object and any other > duplicated objects can be discarded. More specifically: > > 1. If the new Script has a SharedFunctionInfo for a particular function > literal, and the old Script does not, then the old Script is updated > to refer to the new SharedFunctionInfo. > 2. If the new Script has a compiled SharedFunctionInfo for a particular > function literal, and the old Script has an uncompiled > SharedFunctionInfo, then the old SharedFunctionInfo is updated to > point to the function_data and feedback_metadata from the new > SharedFunctionInfo. > 3. If any used object from the new object graph points to a > SharedFunctionInfo, where the old object graph contains a matching > SharedFunctionInfo for the same function literal, then that pointer > is updated to point to the old SharedFunctionInfo. > > The document at [0] includes diagrams showing an example merge on a very > small script. > > Steps 1 and 2 above are pretty simple, but step 3 requires walking a > possibly large set of objects, so this new API lets the embedder run > step 3 from a background thread. Steps 1 and 2 are performed later, on > the main thread. > > The next important question is: in what ways can the old script's object > graph be modified during the background execution of step 3, or during > the time after step 3 but before steps 1 and 2? > > A. SharedFunctionInfos can go from compiled to uncompiled due to > flushing. This is okay; the worst outcome is that the function would > need to be compiled again later. Such a risk is already present, > since V8 doesn't keep IsCompiledScopes for every compiled function in > a background-deserialized script. > B. SharedFunctionInfos can go from uncompiled to compiled due to lazy > compilation. This is also okay; the merge completion logic on the > main thread will just keep this lazily compiled data rather than > inserting compiled data from the newly deserialized object graph. > C. SharedFunctionInfos can be cleared from the Script's weak array if > they are no longer referenced. This is mostly okay, because any > SharedFunctionInfo that is needed by the background merge is strongly > referenced and therefore can't be cleared. The only problem arises if > the top-level SharedFunctionInfo gets cleared, so the merge task must > deliberately keep a reference to that one. > D. SharedFunctionInfos can be created if they are needed due to lazy > compilation of a parent function. This change is somewhat troublesome > because it invalidates the background thread's work and requires a > re-traversal on the main thread to update any pointers that should > point to this lazily compiled SharedFunctionInfo. > > At a high level, this change implements three previously unimplemented > functions in BackgroundDeserializeTask (in compiler.cc) and updates one: > > - BackgroundDeserializeTask::SourceTextAvailable, run on the main > thread, checks whether there is a matching Script in the Isolate > compilation cache which doesn't already have a top-level > SharedFunctionInfo. If so, it saves that Script in a persistent > handle. > - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks > whether the persistent handle from the first step exists (a fast > operation which can be called from any thread). > - BackgroundDeserializeTask::MergeWithExistingScript, run on a > background thread, performs step 3 of the merge described above and > generates lists of persistent data describing how the main thread can > complete the merge. > - BackgroundDeserializeTask::Finish is updated to perform the merge > steps 1 and 2 listed above, as well as a possible re-traversal of the > graph if required due to newly created SharedFunctionInfos in the old > Script. > > The merge logic has nothing to do with deserialization, and indeed I > hope to reuse it for background compilation tasks as well, so it is all > contained within a new class BackgroundMergeTask (in compiler.h,cc). It > uses a second class, ForwardPointersVisitor (in compiler.cc) to perform > the object visitation that updates pointers to SharedFunctionInfos. > > [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit > > Bug: v8:12808 > Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#81941} Bug: v8:12808 Change-Id: Id2036dfa4eba8670cac899773d7a906825fa2c50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787266Reviewed-by:
-
Leszek Swirski authored
1. A remainder equal to zero means no deopt. 2. We need the input value in the input register, so we need to treat rax as a clobbered temporary instead of a fixed input. Bug: v8:7700 Change-Id: I9a7b7f3cc48e17b262aa7f9084fa864ad505be54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788099 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#82044}
-
Milad Fa authored
Port ec6368bf R=yahan@iscas.ac.cn, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: I268121f4b3ec66ca3b545551c337066ec5d7cdc5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791905 Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Reviewed-by:
-
Victor Gomes authored
Bug: v8:7700 Change-Id: Id5fddd337635b2932bb1ab0609db38ecc72d95b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3790961 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Victor Gomes authored
This is a reland of commit ef1e65d9 Original change's description: > [maglev] Inline allocation for heap numbers > > Bug: v8:7700 > Change-Id: I2ce46fcfaab6716e6a31167ed517d2e8d9e433d8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788094 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Cr-Commit-Position: refs/heads/main@{#82027} Bug: v8:7700 Change-Id: I3d86880c20ef4b5765a87d272f18cad9fac210fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3790971Reviewed-by:
-
Leszek Swirski authored
While marking uses, record what values are used inside a loop, but defined outside of it. Then, on the loop end, extend the lifetime of these values. Bug: v8:7700 Change-Id: I1bba037be760b4871673ecf0af584f5bf72fc35c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782797Reviewed-by:
-
Toon Verwaest authored
Label already supports forward references through the label itself, so we don't need to keep track of that separately. Change-Id: I16fd10888041c833e1c65ffdaaa985a7adf8c126 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3790975 Auto-Submit: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Clemens Backes authored
Memory64 currently does not use trap handling, so we should not allocate a guard region (10GB total reservation). This is implemented by adding a {WasmMemoryFlag} enum in the backing store header, which replaces the previous {MemoryIndexType}. The flag is not stored with the backing store, as the backing store does not care about the index type, and we might want to share the same backing store for memory32 and memory64 (if sizes permit this). Instead, we (still) store the flag with the WasmMemoryObject and pass it to the backing store methods. R=jkummerow@chromium.org Bug: v8:10949 Change-Id: I284b85b98d181ba5e8d454b24bfa48f6ac201be5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789506Reviewed-by: -
Victor Gomes authored
I forgot to remove the -1 when hoisting it. Bug: v8:7700 Change-Id: I407d387058ef476ae2359f8c3815d6a70fff1b97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791904 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Register merges participate in the same parallel gap move as phi inputs, but their allocation is not aware of the phis' existence (since the register merge allocation sees the register state _before_ phi input allocation, which is because that's what parallel move requires). This means that they might move into a register that is used by a Phi, and possibly will clobber its value. Avoid this by recording what registers phis move values into during code gen, and skipping register moves into those registers. Also DCHECK that the recorded gap moves can't clobber a target register from a previous gap move. Additionally, add printing for register merges (both in regalloc tracing and graph printing). Bug: v8:7700 Change-Id: I8bd4803a30a894c5654e33fc5657ef3fe6cf7a0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791062Reviewed-by:
-
Matthias Liedtke authored
Bug: v8:7748 Change-Id: Ifd4caec2015894f736dd94356298f6ee35ac852b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779911Reviewed-by:
Philip Pfaffe <pfaffe@chromium.org> Commit-Queue: Matthias Liedtke <mliedtke@chromium.org> Cr-Commit-Position: refs/heads/main@{#82035}
-
Leszek Swirski authored
This reverts commit ef1e65d9. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug/42329/overview Original change's description: > [maglev] Inline allocation for heap numbers > > Bug: v8:7700 > Change-Id: I2ce46fcfaab6716e6a31167ed517d2e8d9e433d8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788094 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Cr-Commit-Position: refs/heads/main@{#82027} Bug: v8:7700 Change-Id: I63ba2b1c879db652270fa1a83e32f6fec948333b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791064 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#82034}
-
