- 06 Feb, 2020 21 commits
-
-
Johannes Henkel authored
Upstream: "Remove Parser_{h,cpp}.template as promised." https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2040571 New rev: 9fd0f91cc4331f931b7ac4040ceaa36de43937d0 Change-Id: Ie8df73e1fa898d4d46090fa6597548b2e1ca9a4e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039349Reviewed-by:Yang Guo <yangguo@chromium.org> Commit-Queue: Johannes Henkel <johannes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66161}
-
Milad Farazmand authored
With "Value::parseBinary" now being revamped by https://crrev.com/c/2020518 and making use of "cbor::ParseCBOR", the extra endianness check is not needed anymore as "ParseCBOR" already switches the byte order in this line: crdtp/cbor.cc void ParseUTF16String(CBORTokenizer* tokenizer, ParserHandler* out) { .... for (size_t ii = 0; ii < rep.size(); ii += 2) value.push_back((rep[ii + 1] << 8) | rep[ii]); ... "String16EndianTest" does not go through the newly added pipeline and "ParseUTF16String" is never used which makes the test redundant. Change-Id: I6ad59fef7036c70d475b492407fd394977ca98f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2038716 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#66160}
-
Ulan Degenbaev authored
A pointer-compressed heap has the same heap limit heuristics as a 32-bit heap. Specifically, the heap limit is restricted to 1GB due to scarce virtual addresses space on 32-bit platforms. That limitation does not apply for pointer-compressed heaps which can use 4GB. This CL changes the heap limit computation to use system the pointer size instead of the tagged pointer size. Note that the young generation limit continues to use the tagged pointer size. Bug: chromium:1045034 Change-Id: I9d5bb818c32a82322476e9c97feee331400ebe0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042102Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66159}
-
Omer Katz authored
This CL makes the following changes: 1) Size of allocated buffer is set by a template parameter (with a default value instead of hardcoded size) 2) Remove dynamic parameter for initializing number of tasks (see comment in scavenger.cc) This CL aligns the v8 and oilpan heaps so that they provide the same interface and functionality. Change-Id: I77d63793f0a54ea29198ddd6bd298eae2c15cf42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030920Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#66158}
-
Leszek Swirski authored
Allow HandleOrOffThreadHandle to implicitly convert to any of Handle, MaybeHandle, and OffThreadHandle, so that it can be used in Isolate-templated code with fewer 'get' calls. As a drive-by, allow OffThreadHandle to have an OffThreadIsolate parameter (so that HandleFor<Isolate, Foo>(x, isolate) works), and use a static_cast rather than a T::cast in the implicit upcast constructor of OffThreadHandle to prevent implicit down-casts. Bug: chromium:1011762 Change-Id: I226f3a48b0f3b5e0347e6325be1cbd482c9048ed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042100 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Add off-thread support for literals, including object/array boilerplates. Notably, this includes adding FixedArray and HeapNumber support to OffThreadFactory. As a drive-by, OffThreadHandle is redefined to store an Address rather than an Object, similar to Handle, so that it still works with forward definitions of types. Bug: chromium:1011762 Change-Id: I7c8452f450d8c57fe683a9e44532ce5647c84a11 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036084 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Thibaud Michaud authored
And fix a few issues that were already found. R=clemensb@chromium.org Change-Id: Ib93626751220dcdd2b9647a6e352bd86bd0ef1ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039053 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66155}
-
Steve Blackburn authored
Currently back references to regular objects are encoded in terms of a relative address, index by chunk index and chunk offset. This approach has the advantage of avoiding the need for a table of back-references at deserialization time, but makes strong assumptions about the way objects are organized in memory (for example, this will not work if the allocator uses a free list rather than a bump pointer). I did some quick measurements and found that the absolute number of objects and back-references is low, suggesting that simply indexing objects would work with little (or no) observable impact on peak memory use during deserialization. Indexing only back referenced objects is not implemented in this simple CL, but could fairly easily be added. Given that the existing mechanism will remain in place, I have implemented the object index by simply making chunk size one, so every object lives on its own chunk (with offset zero). This is the moral equivalent to indexing each object but is a more minimal change. Directly encoding an object index will be more efficient, the trade off made here is just to keep the change absolutely minimal. If using an object index becomes the default, this can be optimized first by only using an index for each object that is actually back- referenced (about half of all objects in my measurements), and more aggressively, a technique like register allocation could be used at serialization time to limit the number of indices to the maximum number of outstanding back-references at any time (basically a live- range analysis of back-references). Bug: v8:9533 Change-Id: I1b7ae87e954f67f6405c2bbdf3b4a4f385af8579 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030742 Commit-Queue: Steve Blackburn <steveblackburn@google.com> Reviewed-by:
-
Michael Lippautz authored
Instead of alternating V8 and embedder steps and trying to find a fixed point where both are empty, just run two phases and check whether both have been observed as empty individually. Bug: chromium:1044630, chromium:1049084 Change-Id: I7ffdca3086f1e7f772303272e370c4a6c1f83f24 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041437 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Steve Blackburn authored
Code ranges are currently accessed from outside the heap via an internal structure of the heap. This change lifts the accessor function a level higher. This should have no cost, but will maintain abstraction better and allow the TPH interface to work more readily. Bug: v8:9533 Change-Id: I154d93ce46f5137b3e3b7ecc6bed7e5b8b0343a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039351Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Steve Blackburn authored
Simple correction over prior commit since TPH no longer needs to depend on V8 read only heap. Bug: v8:9533 Change-Id: Icc72cdbb58fb3d9dc79573548cd9fe9cc88b2684 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039350Reviewed-by:
-
Steve Blackburn authored
These two checks should occur regardless of which allocator we're using, so move them above the TPH check. The check immediately following is V8-specific, so stays where it is. Bug: v8:9533 Change-Id: I127e39969f4aa39ef09ff7b0fdb5ed52b535ad43 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039434Reviewed-by:
-
Clemens Backes authored
The LOAD_RAW and LOAD_RAW_NODE_OFFSET macros just call method on the GraphAssembler now, hence we can remove the macros and just do the calls directly. This reduces code complexity. R=jkummerow@chromium.org, tebbi@chromium.org Bug: v8:10123 Change-Id: I1d779969a14a52256eecb33007564eb190bdcff2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039051 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66149}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/111e7f9..c80cd76 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f72ef2d..1ffa053 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/fff0fe4..e868546 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: If36c8015d0dba083c0bfafd5ee8139bfb1989b19 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041394Reviewed-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@{#66148}
-
Steve Blackburn authored
Bug: v8:9533 Change-Id: I8c8f6d7e2fddae13a9a01a77ac26b1f2ad338889 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039430Reviewed-by:
-
Yu Yin authored
port 59bda196 https://crrev.com/c/2036082 Original Commit Message: This CL adds the "WasmDebugBreak" builtin for x64, ia32, arm and arm64. It stores all wasm parameter registers to the stack and calls the respective runtime function. The runtime function does not do anything yet, but the inspector/debugger/wasm-set-breakpoint-liftoff test will already execute both the builtin and the runtime function. Change-Id: I7e74116f711d9d2599f6f1a6d47b972bad101f8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041214Reviewed-by:
-
Tobias Tebbi authored
- In log.cc, we used InstructionStart() for code create events, but the Code object address for code move events. Change to use InstructionStart() for both. - The symbol table contains some kind of virtual address, not file offsets. They happened to be identical in the past but are no longer, probably due to toolchain changes. Now we use objdump to figure out the difference between virtual addresses and file offsets. - When a new code object happened to be created at the same address as a previous one, we wouldn't update it. This is indeed wrong, as predicted in a TODO by Jaro. - For 64bit addresses, using >>> is wrong, now replaced with division. Change-Id: Ib23114ed736f98bfc33c65004a039a3fd04d3c49 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016586Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66145}
-
Clemens Backes authored
This rewrites the macros to use the GraphAssembler directly. As a next step we should explore if the macros are still worth having, or if they should be inlined everywhere. R=jkummerow@chromium.org Bug: v8:10123 Change-Id: Ia700e00af6a617c4d5a9e34f5be6cab098cd576a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037449Reviewed-by:
-
Yu Yin authored
also correct elf_machine for mips. Change-Id: I261d5bf54ec7ac88290141a4b4ec12e203c34155 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035515 Auto-Submit: Yu Yin <xwafish@gmail.com> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/base/trace_event/common: https://chromium.googlesource.com/chromium/src/base/trace_event/common/+log/bd79231..dab187b Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7dffbb7..111e7f9 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2e4a40a..f72ef2d Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/e931018..fff0fe4 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/847296c..4f24c2a Rolling v8/tools/luci-go: git_revision:8c17d4a7b01d6257e927c629cc623ebc6a6b3711..git_revision:bbda6f0d563b25ce0a25b147dec46e5815da5601 Rolling v8/tools/luci-go: git_revision:8c17d4a7b01d6257e927c629cc623ebc6a6b3711..git_revision:bbda6f0d563b25ce0a25b147dec46e5815da5601 Rolling v8/tools/luci-go: git_revision:8c17d4a7b01d6257e927c629cc623ebc6a6b3711..git_revision:bbda6f0d563b25ce0a25b147dec46e5815da5601 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ib36bbd2f1cb29c461b2aea9a0ed59582a59c94af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2040930Reviewed-by:
-
Clemens Backes authored
This reverts commit 44380f80. Reason for revert: Breaks tsan, msan and ubsan, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/30187 Original change's description: > Fix SEGMAP_ERR by rolling ICU? > > Fix Intl.ListFormat long strings cause SEGMAP_ERR > Add slow regression test. > > Bug: chromium:1044570 > Change-Id: I20e3523832ac3c69e88c11bd530122bbe782ad01 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2032712 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66140} TBR=machenbach@chromium.org,ftang@chromium.org,syg@chromium.org Change-Id: I079a675b754b413398d327c44bfeded9c7406333 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1044570 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039355Reviewed-by:
-
- 05 Feb, 2020 18 commits
-
-
Frank Tang authored
Fix Intl.ListFormat long strings cause SEGMAP_ERR Add slow regression test. Bug: chromium:1044570 Change-Id: I20e3523832ac3c69e88c11bd530122bbe782ad01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2032712Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#66140}
-
Andreas Haas authored
R=thibaudm@chromium.org Change-Id: I68688e9613a9af4091963175b041df82410bddc4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037446Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#66139}
-
Milad Farazmand authored
Port 59bda196 Original Commit Message: This CL adds the "WasmDebugBreak" builtin for x64, ia32, arm and arm64. It stores all wasm parameter registers to the stack and calls the respective runtime function. The runtime function does not do anything yet, but the inspector/debugger/wasm-set-breakpoint-liftoff test will already execute both the builtin and the runtime function. R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I881a22f1e7c8f9c0714caaa0de75e00177da51e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2038136Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66138}
-
Michael Lippautz authored
Delay completing marking (and thus the atomic GC pause) during JS executions, increasing the chance to finalize the garbage collection from a task. This is beneficial as it avoids stack scanning which is expensive and can keep alive outdated objects in case of unified heap. Completing will be delayed at most by some overshoot factor (10%). In addition, the GC keeps the weighted average of previously recorded time to incremental marking task invocations and bails out if the task is expected to arrive too late. Reland: Do not schedule a delayed task when marking has already been finalized. This reverts commit 1775684e. Bug: chromium:1044630, v8:10178 Change-Id: Ic46e9504ce7c200bd1d37ee8d0190fb8727a3f96 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037436Reviewed-by:
-
Clemens Backes authored
This makes the code more readable, and allows for easier future performance optimizations. R=jkummerow@chromium.org Bug: v8:10123, v8:10070 Change-Id: Ifd27f0c888da21bb7f5729c550e8993e793ae7d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037438Reviewed-by:
-
Georg Neis authored
Bug: v8:10101 Change-Id: If833324b1acebcde8a3bce8888d86c598ed14249 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037442 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
-
Michael Achenbach authored
The bug appears to be fixed. No-Try: true Bug: chromium:693426 Change-Id: Ibd029c906dca87a3fd0c3e00be0b795e87390bd4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037439Reviewed-by:
-
Peter Marshall authored
This reverts commit cf1fad58. Reason for revert: Breaks web tests: https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux%20Debug/2684 Original change's description: > [tooling] Keep track of idle state even when we aren't profiling > > It isn't expensive to set this enum on the isolate and we only call > this in chrome when the ThreadDebugger is enabled anyway. > > This means we have a correct idle state to use with the upcoming > CDP event which emits the thread state. > > Bug: chromium:1025490 > Change-Id: Ia555ac8c401d0ad7c72d4cbc442be388ce166131 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036087 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66125} TBR=yangguo@chromium.org,petermarshall@chromium.org Change-Id: I3823197974a2e683364f56819de6ea33dbb8b296 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1025490 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037441Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#66133}
-
Clemens Backes authored
When converting JS values to wasm, we have a fast path for smi inputs. This CL makes this fast path faster by making the alternative (calling ToNumber) deferred. That slow path will be slower then, especially since register allocation (in particular the spilling decisions) are less optimal. Bug: v8:10070 Change-Id: I633a32e85b5a32f490980351b258da8e7a32a9e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037435Reviewed-by:
-
Sathya Gunasekaran authored
The source position is set to the function call (console.log) not the spread (..x), in the bytecode generator, as the spread operation is done as part of the CallWithSpread bytecode. The CallPrinter stops at the function call and doesn't look at the arguments as well (in CallPrinter::VisitCall) to see if the error is from an incorrect spread operation. With this patch, we pass some state to the CallPrinter in the CallWithSpread error case and check that in CallPrinter::VisitCall before returning. For the given source string: ``` x = undefined; console.log(1, ...x); ``` Previously, the error was - ``` test.js:2: TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator)) console.log(1, ...x); ^ TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator)) at test.js:2:9 ``` Now, the error is - ``` _test.js:2: TypeError: x is not iterable (cannot read property undefined) console.log(1, ...x); ^ TypeError: x is not iterable (cannot read property undefined) at _test.js:2:9 ``` Bug: v8:10038 Change-Id: I199de9997f1d949c6f9b7b4f41d51f422b8b5131 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037431Reviewed-by: -
Dan Elphick authored
Fixes the one case after calling EnsureSourcePositionsCollected that we were still using the non-handle version of the SharedFunctionInfo. Bug: chromium:1048555 Change-Id: Iefd35fab13623a1f05212c98864be62c37463942 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037437 Commit-Queue: Dan Elphick <delphick@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
-
Clemens Backes authored
If new Liftoff code is generated but we already have either Liftoff or TurboFan code, we still want to install and use the new Liftoff code if we are in debugging. This logic can probably be simplified again when the "tier down to liftoff on Debugger.enable" logic is fully implemented. I left a TODO to revisit the logic later. R=thibaudm@chromium.org Bug: v8:10147 Change-Id: Ie3a6bdf1cde4f1af884edc8cf1f1b5a507283a5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036089 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Clemens Backes authored
This implements the runtime function for DebugBreak functionality in Liftoff code. We find the Liftoff frame on the stack, get the position within that frame, find breakpoints set at that position, and then call {OnDebugBreak} with these breakpoints. Note that one additional change is needed in order to make this actually hit the right breakpoints. Once everything is in place, we will see a change in the expected output in the wasm-set-breakpoint-liftoff test. R=thibaudm@chromium.org Bug: v8:10147 Change-Id: I5ca569a68aa436bbcf70739ea430efb9e459fad5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036086 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Andreas Haas authored
R=clemensb@chromium.org CC=zhin@chromium.org Bug: v8:10108 Change-Id: I68b81f46166d806ac0bc9bc7cc9ae9fcb4ea6d84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030729Reviewed-by:
-
Clemens Backes authored
This CL adds the "WasmDebugBreak" builtin for x64, ia32, arm and arm64. It stores all wasm parameter registers to the stack and calls the respective runtime function. The runtime function does not do anything yet, but the inspector/debugger/wasm-set-breakpoint-liftoff test will already execute both the builtin and the runtime function. R=thibaudm@chromium.org Bug: v8:10147 Change-Id: I445fdd7c202480ece951f5efbb4845cf21410d91 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036082Reviewed-by:
-
Peter Marshall authored
It isn't expensive to set this enum on the isolate and we only call this in chrome when the ThreadDebugger is enabled anyway. This means we have a correct idle state to use with the upcoming CDP event which emits the thread state. Bug: chromium:1025490 Change-Id: Ia555ac8c401d0ad7c72d4cbc442be388ce166131 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036087Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2283658..7dffbb7 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ebf2bec..2e4a40a Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/306f375..10b1902 Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/dbd3825..9f40209 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/9ce85c8..847296c TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I28cafd08fccb8d9549717d90c10d7da1948fdb72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035739Reviewed-by:
-
Ng Zhi An authored
These instructions were probably leftover from an earlier cleanup. We can move them into respective macro lists, then delete away the redundant declarations, definitions, disasm, and tests. We were missing disasm tests for SSE2_INSTRUCTION_LIST_SD, so add that in. Change-Id: I8f27beaf57e7a338097690073910a0863f00b26a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036833Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66123}
-
- 04 Feb, 2020 1 commit
-
-
Andreas Haas authored
The instruction selector assumed for Word32AtomicPairCompareExchange nodes that if there exists a Projection(1) user, then there also exists a Projection(0) user. This, however, is not the case, because TurboFan eliminates unreachable nodes. The missing projection node lead to a failed DCHECK in the register allocator. With this CL we allocate the right registers for the existing projections, and allocate the other needed registers as temp registers. R=gdeepti@chromium.org Bug: v8:10140 Change-Id: Id50768c3cb712db5e0eb3b9dcd0a8a479e20953a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030731Reviewed-by:
-
