- 07 Feb, 2020 19 commits
-
-
Ng Zhi An authored
We lower each op into num_lanes loads, and connecting up the effects in a chain. s64x2 is not implemented since we lowering for 64x2 generally doesn't work anyway. Load extends are a bit more complicated, so we'll do that in a separate change. Bug: v8:9886 Change-Id: I80096827bf8e8e0db1ef0ad1b76759ed1797ca5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031893 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#66183}
-
Seth Brenith authored
This change moves the definition of the bits stored in DebugInfo::flags to Torque, and updates the only Torque usage of that field to use more natural syntax. This is intended as an example of common patterns found in various other classes. Several supporting changes are required: 1. Add a new type representing a bitfield struct stored within a Smi. It is currently called SmiTagged, but I'm open to suggestions. 2. Add an enum-style output for Torque bitfield structs whose bitfields occupy only one bit each. 3. Add a new case to MachineOperatorReducer that makes the generated code for IncBlockCounter match with what was generated before this change. 4. Add support for reporting these bitfields in the postmortem debugging API. The format matches existing bitfields but with an offset value that includes the SMI shift size. Bug: v8:7793 Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#66182}
-
Ng Zhi An authored
Bug: v8:10115 Change-Id: If2ef0cd4bef9805dce3c9486d91385d0d40189fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2044650Reviewed-by:
-
Ng Zhi An authored
Mode has an underlying type of int8_t. When printing it we can end up with unprintable ascii values. This shows up with --trace-turbo, and the json file ends up with invalid bytes, and Turbolizer cannot preview. Change-Id: I6bc905416b6e6da35a259734233b366b858452e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031895Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Bill Ticehurst authored
Change-Id: I47c9211274cefd26bde6bd93aa7503e022df4357 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042874Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Bill Ticehurst <billti@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66179}
-
Ng Zhi An authored
These were not added in https://crrev.com/c/2026067 when we added similar tests for other lane sizes, since x64 had a completely different path for i8x16. But this tests are useful anyway for other archs, so add them in. Bug: v8:10115 Change-Id: I77ecca0cd9f4021c94f1538aa5635b5d54983207 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041708Reviewed-by:
-
Ng Zhi An authored
Bug: v8:10039 Change-Id: Ibb0fea59b180d8e015aeee6d6e211ef1f85b0c61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041698Reviewed-by:
-
Ulan Degenbaev authored
This restores ~4GB limit for 64-bit devices with 16GB physical memory running with pointer compression. Bug: chromium:1049816,chromium:1045034 Change-Id: I7946a4510f8aac2c71fb427776574adba5127cbd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043797 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66176}
-
Etienne Pierre-doray authored
GlobalSize will be used as a hint to schedule scavenger work in https://chromium-review.googlesource.com/c/v8/v8/+/2036661 This is implemented as an atomic variable that's updated when adding/removing segments. Bug: chromium:1012816 Change-Id: I8f6c3f10612f8febda9bfe640d91e235aa3c2f12 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043273Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#66175}
-
Ulan Degenbaev authored
Now ResourceConstraints::ConfigureDefaults sets the heap limit to 4GB if the physical memory size is greater or equal to 16GB on 64-bit platforms. This CL also adds tests for configuring heap limits from the physical memory size. Bug: chromium:1045034 Change-Id: If0d5a237b2db31309a9a2a6456d950ef70dc71af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043833 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Igor Sheludko authored
Bug: v8:10047 Change-Id: I140fcf453ce7dd6189e0f643f95570163b625456 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043831 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Mythri A authored
We used to optimize functions that are expected to executed only once by not allocating feedback slots for some of the bytecodes. This would help in reducing the memory and avoiding initializing feedback that would be never used. With lazy feedback allocation, we don't allocate feedback vectors for most of such functions anyway. The generated bytecode for oneshot optimized functions is different and if we don't properly track this information we might end up generating different bytecode for the same function. This could causes problems when there is a mismatch between the feedback slots used by the new bytecode and the old bytecode. Since we potentially get most of the benefits of this optimization with lazy feedback vector allocation we can simplify the code by disabling this optimization. Bug: chromium:1045824 Change-Id: Ib94605c8c766adc99f54c8333f780d2448caff5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030918Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#66172}
-
Emanuel Ziegler authored
Improve performance of switch statements by using constexpr lookup tables wherever possible. Bug: chromium:1042868 R=clemensb@chromium.org Change-Id: I8a44bd8022d1c4e3a74243e3657498a2bc49ff64 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041448 Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66171}
-
Igor Sheludko authored
... a Smi-looking type containing properly sign-extended int31 integer. The idea is to use this kind of tagged integers for the cases where the value is guaranteed to fit into int31. For example, feedback vector slots is one of the candidates for using TaggedIndex representation. Bug: v8:10047 Change-Id: Ifaa2978a5d42467578ff243dc44d327536efbe93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960292Reviewed-by:
-
Yu Yin authored
Change-Id: Ic18995af870c41852d5b10dbe5adead7bb36d37e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043611 Auto-Submit: Yu Yin <xwafish@gmail.com> Commit-Queue: Yu Yin <xwafish@gmail.com> Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Allow caching the result of allocating AstConsStrings, to allow sharing of inferred names between functions. This is a partial revert of https://crrev.com/c/2020953, with the observation that *some* AstConsStrings are always flattened, while others are only ever used as ConsStrings, so we want to allow the allocation to be lazy while still caching the result. As a drive-by, cleanup the old AstConsString linked list fields. Bug: chromium:1011762 Bug: chromium:1048082 Change-Id: Icc14342eb3f6f97359596b42b2c296cbc49fd791 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042093 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66168}
-
Clemens Backes authored
The functionality was not used since a long time, and was hence removed for the 8.1 branch, and the method was deprecated. This CL removed the deprecated method completely. R=adamk@chromium.org Bug: v8:10155 Change-Id: Iae299d64decb7230d38c2fda8d269a7b0387bb0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033169Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66167}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/c80cd76..68bdecf Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/1ffa053..8052d29 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/e868546..73c7670 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ic4628b14b96343bf2a9cacf07ecdde49b728dca7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042164Reviewed-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@{#66166}
-
Johannes Henkel authored
Upstream PR: "Implement crdtp::ErrorSupport, replacing the jinja2 template." https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2036608 In addition; this PR includes removal of now unused routines in string-util.h (StringBuilder and number conversions). New Rev: e4ffb7288a17b2bbe2f7b7cd62abcb1d1e55681a Change-Id: Iae14c001c1f468466a42cb1b842c0ded766fccc9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037959Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Johannes Henkel <johannes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66165}
-
- 06 Feb, 2020 21 commits
-
-
Z Nguyen-Huu authored
This is a reland of 410ca4c5 Skip new test for unsupported liftoff architecture. Previously, if there is some unsupported liftoff functions, it fall through Turbofan but recompilation didn't catch and count it. This CL fixes it by using requested_tier on finished units. Avoid to tier down asm.js. Introduce reached recompilation tier to monitor recompilation progress. Original change's description: > [wasm] Tierdown wasm module upon "Debugger.enable" > > Put a logic in Wasm Engine to tier down all existing modules per isolate > when debugger is enabled. This CL does not handle new module added after > debugger is enabled yet. > > Bug: v8:9654 > Change-Id: I87060f5c416506543fcaf231bff9999d06ba4c0d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013692 > Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66017} TBR=szuend@chromium.org,bmeurer@chromium.org Bug: v8:9654 Change-Id: I6014ae52d1e04726e64ee9267c5ce559090414d7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031744 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
-
Michael Achenbach authored
Roller broke after this flag was removed here: https://crrev.com/52969c9d1049ffc5daecdb9210ad29f13438449b TBR=mslekova@chromium.org No-Try: true Change-Id: Ic81b093ba28df8806938f4b1022330ce0eddc082 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042710 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#66163}
-
Ng Zhi An authored
Define a macro in code-generator-ia32 to help identify cases when the shift value is an immediate/constant. In those cases we can directly emit the shifts without any masking, since the instruction selector would have modulo-ed the shift value. We also don't need any temporaries in this case. Bug: v8:10115 Change-Id: I3cdef493fd7c365c733a85ad31b86e2d258b6429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037649Reviewed-by:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
