- 21 Mar, 2019 21 commits
-
-
Sergiy Belozorov authored
R=machenbach@chromium.org, tmrts@chromium.org Bug: chromium:923304 Change-Id: I65898b7edea8d696d957a8ba19809484e663cb27 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533864 Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#60399}
-
Sergiy Belozorov authored
TBR=sergiyb@chromium.org No-Try: true Bug: chromium:923304 Change-Id: Ide9451848e227d27ba7d5b413649e50ce29bb586 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533870 Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org> Reviewed-by:
Sergiy Belozorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#60398}
-
Michael Achenbach authored
This reverts commit 7b896836. Reason for revert: Lots of test failures on current roll: https://chromium-review.googlesource.com/c/chromium/src/+/1534141 Original change's description: > Reland "[ptr-compr][x64] Temporarily enable pointer compression on x64" > > This is a reland of 4f051fd5 > > Relanding because last revert was caused by unrelated flakes. > > Original change's description: > > [ptr-compr][x64] Temporarily enable pointer compression on x64 > > > > ... and make sure that the x64 ptr-compr bots proceed testing V8 without > > pointer compression in order to keep testing the full pointer mode. > > > > Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng,v8_linux64_tsan_rel > > Bug: v8:7703 > > Change-Id: Ied4e7bacf99c9d63e0459613fec522273f595de8 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1523327 > > Commit-Queue: Igor Sheludko <ishell@chromium.org> > > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60339} > > Bug: v8:7703 > Change-Id: I9c588de77070d4fbf1bb1a21ae58c398a22eed9c > Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng, v8_linux64_tsan_rel, v8_mac64_gc_stress_dbg > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530819 > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60370} TBR=machenbach@chromium.org,ishell@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7703 Change-Id: I1c037470b5895c4269c9574e6c93d0eed6fe90d5 Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng, v8_linux64_tsan_rel, v8_mac64_gc_stress_dbg Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533867Reviewed-by:
-
Ben Smith authored
Most of the mjsunit/wasm/table-copy.js tests have been ported to cctests, so they can be tested with all execution tiers. Bug: v8:8965 Change-Id: I448719be30a4b2bddb9e2cffb4c74d3134db2f50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529548 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#60396}
-
Sergiy Belozorov authored
The original config will be removed after infra-side change will land and start using new configs. R=machenbach@chromium.org, tmrts@chromium.org Bug: chromium:923304 Change-Id: I5323f0d01724cef2472592bd8e5beb15de232346 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533863Reviewed-by:
-
Cliff Smolinsky authored
V8_libbase.dll, in a component build where the dll is created, statically links against shlwapi.dll. Shlwapi is only needed for a single use within the debug stacktrace code and is therefore not needed in most cases. Statically loading shlwapi also brings in user32.dll and gdi32.dll, so this is a decent perf hit which is generally unnecessary. This changes delayloads shlwapi so that is only loaded when actually used. Bug: v8:9024 Change-Id: Ib8842893a43cde4b1110a333ae07d861088ba829 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533145Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Cliff Smolinsky <cliffsmo@microsoft.com> Cr-Commit-Position: refs/heads/master@{#60394}
-
Santiago Aboy Solanes authored
Said instructions look like ChangeTaggedXXXToCompressedXXX and ChangeCompressedXXXToTaggedXXX for XXX in ("", "Pointer", "Signed"). This change only affects 64 bit architectures (both for x64 and arm64). Also added tests for the machine operators. Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng,v8_linux64_arm64_pointer_compression_rel_ng Bug: v8:8977 Change-Id: I239d9de7f214424852e75b5d56996e8dfdacd400 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526009 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#60393}
-
v8-ci-autoroll-builder authored
This is a reland of 477d88a5 Original change's description: > Update V8 DEPS. > > Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/e8b8ab7..9dba2d4 > > Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/a14f996..a2a4845 > > Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4e9bccd..bf564e0 > > Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/24b5f90..cf9613f > > Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/efecb0b..8b6d3f9 > > Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/8c67416..b10cc9f > > Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/3dd606a..2116ee9 > > Rolling v8/tools/swarming_client: https://chromium.googlesource.com/infra/luci/client-py/+log/7a61cf3..aa60736 > > TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org > > Change-Id: I333f64ffea36d3925757b7c97f425bfc6334f266 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529938 > Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> > Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> > Cr-Commit-Position: refs/heads/master@{#60366} Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng TBR=tmrts@chromium.org Bug: chromium:943614 Change-Id: Id1d875d9fd2b0022cfdf9ed7c97bea1b611fd05f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533859Reviewed-by:
Tamer Tas <tmrts@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#60392}
-
Igor Sheludko authored
Bug: v8:7703 Change-Id: Ic6cd8b337813ecff2a0d030aa3a57304e784378a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511486Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#60391}
-
Igor Sheludko authored
... for decompression because the former is not used by register allocator and therefore always available. Bug: v8:7703 Change-Id: I72d738be69c339444311d75c69f04c104e90bb90 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533857Reviewed-by:
-
Michael Achenbach authored
This adds missing configuration from: https://crrev.com/c/1518245 TBR=tmrts@chromium.org Bug: chromium:943614 Change-Id: I4a21616aa3180e8c1c5a90b21f1678e62ebcf14a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533837Reviewed-by:
-
Yun Liu authored
Bug: chromium:943614 Change-Id: I42fea5af3fdf040e5091f5342401c5e863e1b67e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533152 Commit-Queue: Tamer Tas <tmrts@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Above test passes on simulator but may take up to a few mintues. Test passes normally on native PPC. Change-Id: I89b8feca1f6f0da41a5aff7c004718f0b63f76ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532343Reviewed-by:
-
Mike Stanton authored
Main changes: ContextData class to hold a map of slots to ObjectData for known necessary lookups. LdaGlobal* and StaGlobal now receive an accumulator hint of the constant found at the lookup slot for immutable global context operations. Bug: v8:7790 Change-Id: I63dc9eb8ebbbdfa4ce3b71c6aba63b3c06a3da9b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532074Reviewed-by:Georg Neis <neis@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#60386}
-
Michael Lippautz authored
FixedArray object in LO space are processed incrementally in ranges of slots size kProgressBarScanningChunk to reduce latency when returning to the processing loop is critical. A progress bar stores how much slots have been processed already. In the case of regular concurrent marking there was a guarantee that the object was only processed by one thread (main *or* concurrent marking thread) at the same time. However, some optimizations that avoid write barriers for each individual write operation emit a batched write barrier that requires re-visiting the FixedArray for the marking barrier. In such cases, the progress bar would be reset using relaxed stores which is problematic as the concurrent marking thread could race on setting its own progress on the progress bar. As a result, the array would only be re-scanned partially. The fix involves using CAS to set the progress bar and bail out in the case an inconsistent state was observed. In the following: MT... main thread CM... concurrent marking thread The interesting cases are: 1. MT *or* CM processes the array without interfering: Progress bar is updated monotonically without failing. 3. MT interferes with itself: The progress bar is just reset and the main thread will restart scanning from index 0. The object is added twice to the marking worklist and processed each time one of the entries is retrieved from the worklist. 4. MT interferes with CM: 4.a.: CM processes a range of slots and re-adds the left overs by setting the progress bar and re-adding the array to the worklist. In this case CM *and* MT process the array from index 0. The first time the CAS for setting the progress bar fails on either of the threads, the looser will bail out and leave processing for the winner. 4.b.: CM is interrupted while processing a range of the array and fails in setting the progress bar for the left overs. In this case the CM bails out right away and the main thread starts processing from index 0. In addition, there is a transition from index 0 to the index of the first actual slot. This transition makes it possible to observe a reset while processing the first actual chunk of slots. Bug: chromium:942699 Change-Id: I0b06f47ee075030dadfc959528cd77b6b69bbec2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532325Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
This ensures that the actual instructions are in their final form when adding them to the NativeModule. R=titzer@chromium.org Change-Id: Ia20698823e5a18a3c3ef7d2370769b70addfc4e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532075 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60384}
-
Pierre Langlois authored
The `compiler-trace-flags.js` test just makes sure the various --trace-turbo* flags do not cause V8 to crash. However, on builds with no snapshot, they would generate a *lot* of output as they were tracing the compiler while generating the snapshot. Let's set the `--trace-turbo-filter` flag to make sure we only trace the test functions. Sadly, WASM functions do not have a name, just an index, so we have to split this test into two. Bug: chromium:943064 Cq-Include-Trybots: luci.v8.try:v8_win_nosnap_shared_rel_ng Change-Id: I30b3935f63d412ab8c96cc5156d342c428229865 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532078Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#60383}
-
Andreas Haas authored
The reason for the revert was that Liftoff did not bail out on indirect calls to tables other than table 0. Whenever the Liftoff code got executed, the test would fail. Original message: With this CL it is possible to use any anyfunc table in call-indirect, not just the first table. The current implementation is based on runtime calls. This is just an initial implementation which should be replaced by a dispatch-table-based eventually. However, this implementation allows us to move forward with the anyref proposal implementation. R=mstarzinger@chromium.org Bug: v8:7581 Change-Id: Iedd56ee7acb281441bca32ffd3dc7157203ee1ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532072 Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60382}
-
Sigurd Schneider authored
This reverts commit 1ca08865. Reason for revert: Regressions across the board Original change's description: > Reland "[regalloc] Introduce deferred fixed ranges" > > This is a reland of b1769313 > > Original change's description: > > [regalloc] Introduce deferred fixed ranges > > > > Fixed ranges are used to express register constraints in the > > allocator. This change splits these fixed ranges into one for > > normal code and deferred code. The former are handeled as before > > whereas the latter are only made visible while allocating > > registers for deferred code. > > > > This prevents forward looking decisions in normal code to be > > impacted by register constraints from deferred code. > > > > Change-Id: I67d562bb41166194e62765d5ab051bc961054fc7 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1477742 > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60322} > > Change-Id: I1a31150256eb5608db985b144aab7ea457169d0d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530810 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60364} TBR=jarin@chromium.org,sigurds@chromium.org,herhut@chromium.org Change-Id: Id8ad6c39774e38dd67decea997e08a4c58c452ec No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532327Reviewed-by:
-
Ben Smith authored
When running wasm tests, the interpreter previously used a static collection of function indexes stored in WasmTable to perform call_indirect calls internal to that module. This has the wrong behavior if the table is changed (via WasmTableObject::Set, `table.copy`, or `table.init`). This CL changes the cctests to always generate an intepreter entry for all functions, and stores those entries in the dispatch table. This allows us to use the same execution path as for non-testing code. The interpreter entry compiler needed to be changed to support multi-value returns too, since a 64-bit integer return value may be lowered to two 32-bit integer returns. Bug: v8:9016 Change-Id: I277df21ffde5c2eee0b691fcc9bab2b1a43eeffc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1531137 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Frank Tang authored
Bug: chromium:527926 Change-Id: I783ba59c6e4b117163e058032fb04283e1f43c46 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529260Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#60379}
-
- 20 Mar, 2019 19 commits
-
-
Simon Zünd authored
This CL changes ToString of stack frames to optionally take a IncrementalStringBuilder instance. Instead of using one instance per frame when serializing a stack trace, a single instance is now used. This improves local stack serialization micro benchmarks by ~6%. R=jgruber@chromium.org Bug: v8:8742 Change-Id: I067069f91919c167434979b4d9013019e46ed3b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532063 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#60378}
-
Igor Sheludko authored
This field's size is kIntSize but it was read as a 8-byte value in assembly code. Bug: v8:7703 Change-Id: I16e8c845c27b224b368c8888073cff6d53f28a54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532324 Auto-Submit: Igor Sheludko <ishell@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Suraj Sharma authored
Added a new Error Message for Missing Function Name. The program: function(){} ...now produces: SyntaxError: Function statements require a valid function name. ...instead of: SyntaxError: Unexpected Token ( Bug: v8:3698, v8:6513 Change-Id: I3c12dfcfe80b94209aa9af434ae1d212970cf362 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1500914 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#60376}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: Ie699372bd60fe6e78107cc2a53d90e8fe83a835e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532322 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60375}
-
Michael Starzinger authored
This has been functionally obsolete for a while now. From a performance point of view it also became obsolete, because the only on-heap {Code} object being generated within this scope is the start function wrapper. R=clemensh@chromium.org BUG=v8:6792 Change-Id: I978488fbd8d26b55d957d56449c5ff021b888ce1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532320Reviewed-by: -
Clemens Hammacher authored
In order to reduce lock contention in the NativeModule, to publish compiled code in batches. This is implemented via a new {NativeModule::AddCompiledCode} variant that takes a {Vector<WasmCompilationResult>}, allocates code space for all of the results, copies all code over and relocates it, and then publishes all of it. R=titzer@chromium.org Bug: v8:8916 Change-Id: I437bd222dc2471b89b114cdb42049991af36f1f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532062 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
Leszek Swirski authored
This reverts commit 3cda21de. Reason for revert: Breaks the roll on Windows (see https://cr-buildbucket.appspot.com/build/8918477701097622400) Original change's description: > V8 x64 backend doesn't emit ABI compliant stack frames > > On 64 bit Windows, the OS stack walking does not work because the V8 x64 > backend doesn't emit unwinding info and also because it doesn't emit ABI > compliant stack frames. See > https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit > for more details. > > This problem can be fixed by observing that V8 frames usually all have the same > prolog and epilog: > > push rbp, > mov rbp, rsp > ... > pop rbp > ret N > > and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows > should walk through V8 frames. Furthermore, since V8 Code objects are all > allocated in the same code-range for an Isolate, it is possible to register a > single PDATA/XDATA entry to cover stack walking for all the code generated > inside that code-range. > > This PR contains changes required to enable stack walking on Win64: > > EmbeddedFileWriter now adds assembler directives to the builtins > snapshot source file (embedded.cc) to emit additional entries in the .pdata and > in the .xdata section of the V8 executable. This takes care of stack walking > for embedded builtins. (The case of non-embedded builtins is not supported). > The x64 Assembler has been modified to collect the information required to emit > this unwind info for builtins. > > Stack walking for jitted code is handled is Isolate.cpp, by registering > dynamically PDATA/XDATA for the whole code-range address space every time a new > Isolate is initialized, and by unregistering them when the Isolate is > destroyed. > > Stack walking for WASM jitted code is handled is the same way in > wasm::NativeModule (wasm/wasm-code-manager.cpp). > > It is important to note that Crashpad and Breakpad are already registering > PDATA/XDATA to manage and report unhandled exceptions (but not for embedded > builtins). Since it is not possible to register multiple PDATA entries for the > same address range, a new function is added to the V8 API: > SetUnhandledExceptionCallback() can be used by an embedder to register its own > unhandled exception handler for exceptions that arise in v8-generated code. > V8 embedders should be modified accordingly (code for this is in a separate PR > in the Chromium repository: > https://chromium-review.googlesource.com/c/chromium/src/+/1474703). > > All these changes are experimental, behind: > > the 'v8_win64_unwinding_info' build flag, and > the '--win64-unwinding-info' runtime flag. > > Bug: v8:3598 > Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#60330} TBR=bbudge@chromium.org,ulan@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,gdeepti@chromium.org,jgruber@chromium.org,paolosev@microsoft.com Change-Id: If8470da94c58df8c800cbe8887f9f86236e43353 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:3598 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532321Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#60372}
-
Sigurd Schneider authored
This flag has been on, but was disabled for the reland of the control flow aware register allocator (currently behind a flag). Change-Id: I4a6aabd0c2a10160ef9bd96372fc5c72096d5369 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532079Reviewed-by:
-
Igor Sheludko authored
This is a reland of 4f051fd5 Relanding because last revert was caused by unrelated flakes. Original change's description: > [ptr-compr][x64] Temporarily enable pointer compression on x64 > > ... and make sure that the x64 ptr-compr bots proceed testing V8 without > pointer compression in order to keep testing the full pointer mode. > > Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng,v8_linux64_tsan_rel > Bug: v8:7703 > Change-Id: Ied4e7bacf99c9d63e0459613fec522273f595de8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1523327 > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60339} Bug: v8:7703 Change-Id: I9c588de77070d4fbf1bb1a21ae58c398a22eed9c Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng, v8_linux64_tsan_rel, v8_mac64_gc_stress_dbg Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530819 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
This prepares a refactoring to add and publish compilation results in batches. For this, we need to separate the two phases, so that we can lock the module, allocate all the code space, release the lock, copy the code, lock the module, publish the code, and release the lock again. In particular, this CL does the following: 1) It removes the {AddOwnedCode} method. The functionality of creating the {WasmCode} and memcpy'ing the instruction into that is done in the other {Add*Code} methods. Adding to {owned_code_} is done in {PublishCode}. 2) {PublishInterpreterEntry} is now functionally equivalent to {PublishCode}, so it's removed. 3) After {AddCode}, the caller has to call {PublishCode}. In a follow-up CL, this will be called in batches (first {AddCode} them all, then {PublishCode} them all). 4) {AddCompiledCode} now assumes that the {WasmCompilationResult} succeeded. Otherwise, the caller should directly call {SetError} on the {CompilationState}. 5) {PublishCode} is now the chokepoint for installing code to the code table, the owned code vector, the jump table, and setting interpreter redirections. It replaces previous direct calls to {InstallCode} or explicitly adding to {owned_code_}. 6) Increasing the {generated_code_size_} counter is now done in {AllocateForCode}, which is the chokepoint for allocating space for generated code. This way, we will only increase this counter once once we allocate in batches. R=titzer@chromium.org Bug: v8:8916 Change-Id: I71e02e3a838f21797915cee3ebd373804fb12237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530817 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
Leszek Swirski authored
This reverts commit 477d88a5. Reason for revert: https://crbug.com/943614 Original change's description: > Update V8 DEPS. > > Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/e8b8ab7..9dba2d4 > > Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/a14f996..a2a4845 > > Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4e9bccd..bf564e0 > > Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/24b5f90..cf9613f > > Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/efecb0b..8b6d3f9 > > Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/8c67416..b10cc9f > > Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/3dd606a..2116ee9 > > Rolling v8/tools/swarming_client: https://chromium.googlesource.com/infra/luci/client-py/+log/7a61cf3..aa60736 > > TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org > > Change-Id: I333f64ffea36d3925757b7c97f425bfc6334f266 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529938 > Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> > Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> > Cr-Commit-Position: refs/heads/master@{#60366} TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org,v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com Change-Id: I012896b00b4fdd593844cf74f076490af58c311e No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532077Reviewed-by:
-
Igor Sheludko authored
We also need to deoptimize the code if the embedded 32-bit map dies. Bug: v8:8982, chromium:943823 Change-Id: Iabeac5c943444a7b4d858704c3720228f3d74fe1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532073 Auto-Submit: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/e8b8ab7..9dba2d4 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/a14f996..a2a4845 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/4e9bccd..bf564e0 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/24b5f90..cf9613f Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/efecb0b..8b6d3f9 Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/8c67416..b10cc9f Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/3dd606a..2116ee9 Rolling v8/tools/swarming_client: https://chromium.googlesource.com/infra/luci/client-py/+log/7a61cf3..aa60736 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I333f64ffea36d3925757b7c97f425bfc6334f266 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529938Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#60366}
-
Michael Starzinger authored
This removes the special casing for the lazy compilation stub which used to have its own code kind, just so that the stack walker would properly recognize its frame. Also, by re-using the existing machinery for runtime stubs we no longer need to copy this stub into the native module and get all the niceties that come with embedded builtins for free. Thirdly this will make it easier to start lazy compilation from the background or to do it on a per-function basis without requiring yet more special machinery, since {NativeModule::SetLazyBuiltin} no longer requires access to the Isolate. Kudos for the inspiration for this cleanup go to Frederik, I merely did some of the legwork. R=clemensh@chromium.org BUG=v8:8834 Change-Id: Iac2b51a2e33fb0e88d25d3632fa18998123ee6c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532064Reviewed-by: -
Sigurd Schneider authored
This is a reland of b1769313 Original change's description: > [regalloc] Introduce deferred fixed ranges > > Fixed ranges are used to express register constraints in the > allocator. This change splits these fixed ranges into one for > normal code and deferred code. The former are handeled as before > whereas the latter are only made visible while allocating > registers for deferred code. > > This prevents forward looking decisions in normal code to be > impacted by register constraints from deferred code. > > Change-Id: I67d562bb41166194e62765d5ab051bc961054fc7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1477742 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60322} Change-Id: I1a31150256eb5608db985b144aab7ea457169d0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530810 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Tamer Tas authored
'third_party/android_tools/sdk' is being replaced with 'third_party/android_sdk/public'. This CL updates our DEPS pointing to the old path. Note: 'android_tools' dependency is duplicated with the new path since there are users of the old and new at the same time. R=machenbach@chromium.org CC=sergiyb@chromium.org Bug: chromium:943614 Change-Id: I9baa2b02900559e64d8f0f99161e23ad5acd0e05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532068Reviewed-by:
-
Andreas Haas authored
This reverts commit 9d167f57. Reason for revert: There is a crash on https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/20026 Original change's description: > [wasm][anyref] Add support of call-indirect for multiple tables > > With this CL it is possible to use any anyfunc table in call-indirect, > not just the first table. > > The current implementation is based on runtime calls. This is just an > initial implementation which should be replaced by a > dispatch-table-based eventually. However, this implementation allows > us to move forward with the anyref proposal implementation. > > R=mstarzinger@chromium.org > > Bug: v8:7581 > Change-Id: I57d09b18add7f525555bf7c949aef17a64b0e7c5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530801 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60360} TBR=mstarzinger@chromium.org,ahaas@chromium.org Change-Id: Iba4b84078aa070498be7e79212970b94595f5757 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7581 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532069Reviewed-by:
-
Sven Sauleau authored
Previously, the builtin BigIntToWasmI64 and its calling descriptor had an inconsistent name, not reflecting the signature which is i64 to BigInt. This CL removes BigIntToWasmI64 in favor of I64ToBigInt. Also for consistency the Wasm tranpoline has been renamed from BigIntToWasmI64 to WasmI64ToBigInt. Change-Id: I4125ee99a7358797181770f413db70affa657d5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532065 Auto-Submit: Sven Sauleau <ssauleau@igalia.com> Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Andreas Haas authored
With this CL it is possible to use any anyfunc table in call-indirect, not just the first table. The current implementation is based on runtime calls. This is just an initial implementation which should be replaced by a dispatch-table-based eventually. However, this implementation allows us to move forward with the anyref proposal implementation. R=mstarzinger@chromium.org Bug: v8:7581 Change-Id: I57d09b18add7f525555bf7c949aef17a64b0e7c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530801 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
