- 09 Feb, 2021 2 commits
-
-
Benedikt Meurer authored
BREAKING CHANGE: The values of Wasm locals, stack, and globals are now represented as objects instead of holding the (primitive) values directly, and SIMD128 values are no longer represented as Uint8Arrays. The DWARF extension has been prepared for this breaking change. The new `WasmValue` comes with `type` and `value` properties that hold its contents. The motivation here is that this is a more extensible approach. In case of SIMD128, the `value` property holds the canonical string representation, which has the additional advantage that these values can be compared with `===` (and `==`). This partially reverts https://crrev.com/c/2614428, the main difference here being that WasmValue is now a proper JSObject that can be exposed on the DebugEvaluate proxy API. Screenshot: https://imgur.com/rcahNKM.png Bug: chromium:1170282, chromium:1071432, chromium:1159402 Change-Id: Iea304e3680775123c41deb4c3d172ac949da1b98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643384Reviewed-by:
Philip Pfaffe <pfaffe@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72570}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/a2a1340..6408b07 Rolling v8/third_party/aemu-linux-x64: wSpywIGELAWo-KIDF77NMsedbTxiUN7DZUJS-hXiT1UC..BJKsuvEy1d1R4k1qe_4WGn47cAA9BDUVDaMnfbyiH-cC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ab8a40f..e6e7c93 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ac34821..79f916a Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/fae3adc..5798a76 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I79b3255135b8ac21ba92bbd4d0b92818045390e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683244Reviewed-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@{#72569}
-
- 08 Feb, 2021 12 commits
-
-
Michael Lippautz authored
Those references would be passed over to Blink via buffer and dropped after a virtual call. Bug: chromium:1056170 Change-Id: Idd02acce7a2d5c927dd9dc2415fe507b00ff3e58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682646 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72568}
-
Ng Zhi An authored
Prototype these 6 instructions on arm: - f64x2.convert_low_i32x4_s - f64x2.convert_low_i32x4_u - i32x4.trunc_sat_f64x2_s_zero - i32x4.trunc_sat_f64x2_u_zero - f32x4.demote_f64x2_zero - f64x2.promote_low_f32x4 For all these instructions we rely on having Q registers that map to S registers, which means we can only use q0 to q7. We fix the src/dst to q0 arbitrarily. Bug: v8:11265 Change-Id: Ied95f2dde9859a60fc216ed67615f80e9d795bb7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679842Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#72567}
-
Zhi An Ng authored
This reverts commit 00babf07. Reason for revert: Broke mac64 https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64/38510/overview Original change's description: > [wasm-simd][x64][liftoff] Implement i8x16.popcnt > > Extract i8x16.popcnt implementation into a macro-assembler function, and > reuse it in Liftoff. > > Bug: v8:11002 > Change-Id: I86b2f5322c799d44f584cac28c70e0e393bf114f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676280 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72565} TBR=gdeepti@chromium.org,clemensb@chromium.org,zhin@chromium.org Change-Id: I5795b71f65d59237db59907d40c34e4fa7779fe1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:11002 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682505Reviewed-by:
-
Ng Zhi An authored
Extract i8x16.popcnt implementation into a macro-assembler function, and reuse it in Liftoff. Bug: v8:11002 Change-Id: I86b2f5322c799d44f584cac28c70e0e393bf114f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676280Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#72565}
-
Junliang Yan authored
Change-Id: Ic973b6342a6b91fe9068ee1ffe4e83a138fb2fa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679269Reviewed-by:
Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#72564}
-
Santiago Aboy Solanes authored
Change-Id: Icd1d9fa59fac714673a264839006e74fc4dfeac3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676147Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72563}
-
Camillo Bruni authored
CSV Support: - Add import merged CSV from results.html - Aggregate multiple runs and calculate stddev on them Charts: - Defer rendering charts for responsive UI - Clean up chart rendering in general - Sort charts based on raw chart data for speedups - Show chart annotations - Add chart total, displaying the total value for the currently selected categories - Fix sorting by chart total - Add average row for all charts Change-Id: I1e542f319172ecf158dcb44f8da7ad6e81aafe41 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2675934Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#72562}
-
Clemens Backes authored
Update the wasm spec tests to include the memory64 proposal. Some tests are failing currently because of broken spec tests or missing v8 support. This will be addressed in follow-up CLs. R=ahaas@chromium.org CC=zhin@chromium.org Bug: v8:11401 Change-Id: I1a8f75e70f9d0828ad32c960c113f5e4c0d1a44b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679683 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#72561}
-
Michael Lippautz authored
This change avoid dispatching a write barrier during the atomic pause. The dispatch can generally be triggered through pre-finalizers. In future, further checks may be added to avoid mis-use of pre-finalizers. Bug: chromium:1056170, chromium:1175560 Change-Id: I119e18372633b2375f60e17b4c881f68bb20bf66 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679685Reviewed-by:
Omer Katz <omerkatz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#72560}
-
Jakob Kummerow authored
MacOS 11.2 refuses to set "no access" permissions on memory that we previously used for JIT-compiled code. It is still unclear whether this is WAI on the part of the kernel. In the meantime, as a workaround, we use madvise(..., MADV_FREE_REUSABLE) instead of mprotect(..., NONE) when discarding code pages. This is inspired by what Chromium's gin platform does. Fixed: v8:11389 Change-Id: I866586932573b4253002436ae5eee4e0411c45fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679688 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#72559}
-
Clemens Backes authored
For functions with a very large stack, the debug side table repeats a lot of information: Most values will be spilled to the stack, still every single entry in the debug side table repeats information about them (type, stack offset). This leads to the size of the debug side table to be quadratic in the size of the function. In the linked bug, the generation of the debug side table took ~400ms, whereas Liftoff compilation alone just took 16ms. This CL optimized the debug side table by delta-encoding the entries, i.e. only storing stack slots that changed. This reduces the size of the table significantly, at the cost of making lookup slower, since that now has to search the table backwards for the last entry that had information about a specific slot. For now, this seems like a good compromise. If it turns out to be a problem, we could speed up the lookup by either forcing a full dump of the stack state after N entries, or by dynamically inserting new entries during lookup, whenever we find that we had to search backwards more than N entries. That would speed up subsequent lookups then. On the reproducer in the linked bug, this change reduces the time to generate the debug side table from ~400ms to ~120ms. Before this CL, the debug side table has 13,314 entries with a total of 38,599,606 stack value entries. After this CL, it shrinks to 20,037 stack value entries in the 13,314 entries (average of ~1.5 instead of ~2,899). R=thibaudm@chromium.org Bug: chromium:1172299 Change-Id: Ie726bb82d4c6648cc9ebd130115ee7ab3d1d551b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676636Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72558}
-
Iain Ireland authored
Some of the DCHECK_LT assertions in GenerateBranches were generating signed-vs-unsigned comparisons in SM. While I was looking at this code, it seemed reasonable to just fix the whole thing to use uc32/uint32_t where appropriate. Bug: v8:11380 Change-Id: I7e27fb7e34ce962349d7204d6306217292746e33 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2666986Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72557}
-
- 07 Feb, 2021 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/aemu-linux-x64: UT48xoBffYP6u1cAu_aL71Lh18Z3xtRc7BJSyc_1csMC..wSpywIGELAWo-KIDF77NMsedbTxiUN7DZUJS-hXiT1UC Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/70dd9a6..12825ed TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I94b61291f41c646cd414b550131a2ef326869350 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681316Reviewed-by:
-
- 06 Feb, 2021 2 commits
-
-
Manos Koukoutos authored
In preparation of loop unrolling, we move some loop analysis infrastructure out of loop-peeling.{h, cc}, and implement some additional required functionality. Changes: - Implement inner_loops() in loop-analysis.h. Change some parameters in other functions from Loop* to (const Loop*) to accommodate this change. - Move Peeling class into loop-analysis, rename it to NodeCopier. - Simplify NodeCopier::CopyNodes(). - Allow NodeCopier to produce multiple copies of the targeted Nodes. - Introduce LoopFinder::HasMarkedExits(). Move the implementation of LoopPeeling::CanPeel() there. CanPeel() is now an alias for HasMarkedExits(). Bug: v8:11298 Change-Id: I245b2e937393e4a78ce4d355e1290aaf6e617114 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672019 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: -
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ee7e404..a2a1340 Rolling v8/third_party/aemu-linux-x64: rNvRFA3R0THFzCnDKyJfVyqZysmcZ_To-ZfvXMhYKw8C..UT48xoBffYP6u1cAu_aL71Lh18Z3xtRc7BJSyc_1csMC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/c8f9f36..ab8a40f Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/e342fb1..ac34821 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/f18ba70..fae3adc TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Iefb23fa4349bb8a4e4aaaa9f0335b4c2c7ff479d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2680328Reviewed-by:
-
- 05 Feb, 2021 16 commits
-
-
Bill Budge authored
- Reworks the code structure to break out 3 major cases: Immediate, MemoryOperand, and LocationOperand. - InstructionSelector passes an additional immediate operand, the push size in bytes, so we can generate correct code for the Immediate case. Bug: v8:9198 Change-Id: I86cd41826150aa84b158fdbb1d3e8f3e93755119 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673273 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
-
Clemens Backes authored
Those counters were interesting during the development of Liftoff, but they were never reported to UMA. Now that we have precise tracking of the Liftoff bailout reason in UMA, those counters are redundant. R=ahaas@chromium.org Bug: v8:11387 Change-Id: I4595414a0e3ff8bf9c954baa2317aa39af65b372 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2678163Reviewed-by:
-
Bill Budge authored
- Removes DCHECKs that will be incorrect when SIMD operands are intermixed. - Reworks the code structure to break out 3 major cases: Immediate, MemoryOperand, and LocationOperand. Bug: v8:9198 Change-Id: I1be426bc450dda0fd670a2483aae9afd2c96ce17 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673271 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
-
Michael Lippautz authored
Some types of supported low-level write barrier only requires passing a slot, which may not be even part of a heap object but stack. This complicates the situation, as even with caged heap, there's no way to distinguish a stack and heap slot. Solve this by passing an optional callback that can lazy be used to get the heap. This can be used by the embedder to retrieve the heap from e.g. TLS if needed. This aligns the barrier with Oilpan in Blink. Bug: chromium:1056170 Change-Id: I1e5d022ab17a2614a67b6ef39ed12691bcbd0ac6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2675924Reviewed-by:
-
Santiago Aboy Solanes authored
Also access the DescriptorArray through GetStrongValue concurrently if the FLAG_turbo_direct_heap_access is on. Bug: v8:7790 Change-Id: I7a36789b44e84988d498339312bf9fe92eab8e66 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653233Reviewed-by:
-
Ulan Degenbaev authored
A background thread can register a callback that is guaranteed to be invoked after each GC in a safepoint before background threads resume. This will be allow the background compiler and parser to keep raw pointers to frequently accessed objects and ensure that they are fixed up after GC. Note that the existing global GC epilogues are run after background threads resume, so they are unsafe for background threads. Change-Id: I1c782f912d63afc09c4982d393a6f3805a318962 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2675933 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#72548}
-
Clemens Backes authored
Avoid duplicating the list of parameter registers to push in the WasmCompileLazy builtin by reusing the existing arrays from wasm-linkage.h. Also verify the computed results against different constants. R=zhin@chromium.org Bug: v8:11377 Change-Id: I727d4dcd1f1a0d3ae0e1a6ec03f0fb40c08564ed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2668767 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#72547}
-
Junliang Yan authored
Change-Id: I372d3ef6806b001e45b5522e5a91f20393bf75bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676627Reviewed-by:
-
Benedikt Meurer authored
In JSStackFrame::GetMethodName() we try to infer a useful method name to show for the closure to which the stack frame belongs. This is done by first considering the functions name, and checking if the receiver has a property with that name and if that property's value is the closure. In case the function doesn't have a name or the property's value is not the closure itself, we fall back to a reverse lookup of the closure within the object (and its prototypes). This CL speeds up this logic by attacking two problems: 1. The reverse lookup was performed by first using the KeyAccumulator to extract the names of all enumerable properties, and afterwards using the LookupIterator on each name, and testing the resulting property value against the closure. This is fairly slow and creates a lot of temporary objects and handles. We now look into the descriptor arrays or dictionary backing stores of the objects directly instead, which is easily 2-10x faster. 2. For the common case of `o.foo = function() { ... }` the parser already places an "inferred name" of `o.foo` onto the SharedFunctionInfo, which we can use as a hint to infer the name of the function instead of immediately falling back to the expensive reverse lookup. This repairs the regression reported in http://crbug.com/1069425 and recovers most of the slowdown reported in http://crbug.com/1077657 (there's still some overhead left from the async stack trace tracking). Fixed: chromium:1069425 Bug: chromium:1077657 Change-Id: I88d23ccad123906df70c5217e815493106e03ccf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676635 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#72545}
-
Almothana Athamneh authored
Bug: v8:11385 Change-Id: Idbfafa2db7dd5a091796e7982c4181486dcc60fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2675928Reviewed-by:
Liviu Rau <liviurau@chromium.org> Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Cr-Commit-Position: refs/heads/master@{#72544}
-
Georg Neis authored
Change-Id: I6df71e7bbbcd726816826693b43d4acf30af21d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667186Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72543}
-
Georgia Kouveli authored
This requires a small fix in {Push,Pop}CalleeSavedRegisters, where the return address was signed/authenticated at the wrong point, which meant the stack pointer used as modifier was different from the one the StackFrameIterator expected. Bug: v8:10026 Change-Id: Idebd2ee8f07312b5e99dd2ea5181fc7a7e4a87bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667861 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by: -
Paolo Severini authored
This is a reland of 6ada6a90 - Fixed a GC issue https://bugs.chromium.org/p/v8/issues/detail?id=11335: GC expected all arguments on the stack from code with CodeKind::TURBOFAN to be tagged objects. This is not the case now with inlined Wasm calls, and this information can be passed in SafepointEntry for each call site. - Disabled JS-to-Wasm inlining for calls inside try/catch. For more details, see updated doc: https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit# Bug: v8:11092 Original change's description: > Reland "Faster JS-to-Wasm calls" > > This is a reland of 860fcb1b > > - Disabled the tests for this feature in V8-lite mode (the original > change broke V8-lite tests). > - Also modified test console-profile-wasm.js that was brittle with this > change because it assumed that there was always a JS-to-Wasm wrapper > but this is not the case when the TurboFan compilation completes before > the Liftoff-compiled code starts to run. > > More changes in Patchset 8: > > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering, > into a new phase, wasm-inlining that reuses the JSInliner reducer. > The doc > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit# > describes the new logic. > > - Fixed a couple of small issues in wasm_compiler.cc to make sure that > the graph "JSToWasm Wrapper" subgraph has a valid Control chain; > this should solve the problem we had inlining the calls in functions > that can throw exception. Original change's description: > Faster JS-to-Wasm calls > > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/. > > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on > the basis of the signature of a Wasm function to call, and whose task > is to: > - set "thread_in_wasm_flag" to true > - convert the arguments from tagged types into Wasm native types > - calculate the address of the Wasm function to call and call it > - convert back the result from Wasm native types into tagged types > - reset "thread_in_wasm_flag" to false. > > This CL tries to improve the performance of JS-to-Wasm calls by > inlining the code of the JS-to-Wasm wrappers in the call site. > > It introduces a new IR operand, JSWasmCall, which replaces JSCall for > this kind of calls. A 'JSWasmCall' node is associated to > WasmCallParameters, which contain information about the signature of > the Wasm function to call. > > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid > generating code to convert the types for the arguments > of the Wasm function, when the conversion is not necessary. > The actual inlining of the graph generated for this wrapper happens in > the simplified-lowering phase. > > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage > lazy deoptimizations that can happen if the Wasm function callee calls > back some JS code that invalidates the compiled JS caller function. > Bug: v8:11092 Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777 Commit-Queue: Paolo Severini <paolosev@microsoft.com> Reviewed-by:
-
Manos Koukoutos authored
The constructor_or_backpointer accessor of Map was not consistent with the torque-defined field constructor_or_back_pointer_or_native_context, leading to confusion. This CL brings them in sync, choosing the latter spelling. Change-Id: I3375c5f060bfd5e1e7cab195e3cca3d508c88154 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2674011 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/10e5511..ee7e404 Rolling v8/third_party/aemu-linux-x64: daCtImfwROvNf-7jcpyqZ6KMCGlIQv9BROkyXnulGioC..rNvRFA3R0THFzCnDKyJfVyqZysmcZ_To-ZfvXMhYKw8C Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/5c5a297..c8f9f36 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/6dc9cc3..e342fb1 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/4ee065a..f18ba70 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I8195fa46a4f6f0acd52e3fa4d60cf084c6c82d07 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2677053Reviewed-by:
-
Junliang Yan authored
Change-Id: I8d331992330eeabc9aae564e4467c95764d605f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676623Reviewed-by:
-
- 04 Feb, 2021 7 commits
-
-
Ng Zhi An authored
This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for arm64. Bug: v8:11297 Change-Id: Ib9be5086c8ea98340c9bb1980c319626d7072c1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664994Reviewed-by:
-
Ng Zhi An authored
The previous instruction selection was too loose, it only required registers for the inputs. The codegen also used Unpcklps(dst, mask), and failed to use src at all. The test case was accidentally passing because dst == src (xmm0) by chance. We fix this bug requiring that for AVX, any register is fine, but for SSE, require dst == src. Also redefine Unpcklps to check dst == src in the no AVX case. Bug: v8:11265 Change-Id: I1988b2d2da8263512bf6e675e6297c50f55663f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2668918Reviewed-by:
-
Ng Zhi An authored
Implement these 6 instructions: - f64x2.convert_low_i32x4_s - f64x2.convert_low_i32x4_u - i32x4.trunc_sat_f64x2_s_zero - i32x4.trunc_sat_f64x2_u_zero - f32x4.demote_f64x2_zero - f64x2.promote_low_f32x4 The code sequences are exactly the same as on x64. Needed to add some more instructions, and we don't have macro lists for these instructions yet, so individually define them for now. We can factor them into lists in a future change. Bug: v8:11265 Change-Id: I606e1226201e3c5ecdc7e3f611315437e917d77c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2668913Reviewed-by:
-
Toon Verwaest authored
Change-Id: I783c41ca4192d686454728b7c8356935bc67cc98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2675922 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72534}
-
Jakob Gruber authored
TranslationArrays (TA) are large and rarely used, thus could benefit from compression. This CL adds a --turbo-compress-translation-arrays flag (off by default) to experiment with that. Each optimized Code object has an associated translation array (Code->DeoptimizationData->TranslationArray). These translation arrays have roughly the same size as the Code object itself. They are used only rarely: when deoptimizing, and when traversing the stack and looking into optimized frames. Neither of these code paths are especially performance critical. TA's contain only immutable, untagged data. They are thus good candidates for compression. The trade-off is between TA memory consumption and time spent in decompression/compression. This CL keeps everything on the main thread, but it would also be possible to move compression (the more expensive operation by a factor of 5 to 10) to a worker thread. Numbers from a local Octane2 run: Sum of Code instructions sizes: 4.6MB Sum of uncompressed TA sizes: 4.1MB Sum of compressed TA sizes: 0.6MB Compression times depend on the selected compression quality, but roughly: Compression: 50ms (40us avg per compilation) Decompression: 7us avg per compilation Drive-by: Translation arrays currently use run-length encoding; I disabled this for when --turbo-compress-translation-arrays is enabled (no need to compress twice). Bug: v8:11354 Change-Id: I7828d7d91eb074816b383b02f883c5d7b7e318b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652497 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Michael Achenbach authored
We want to remove the gpu:none default as we want to switch to Mac Minis in the Mac pool that have gpus. This starts a 3-way change: 1. This CL: Add the gpu dimension for Mac source side. 2. Remove setting it as default for Mac in infra. 3. Flip the value for gpu source side. This requires merging to beta/stable. No-Try: true Bug: chromium:1174040 Change-Id: I81f2f5863593aa93fa668b4534d1116a11768f31 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673402 Auto-Submit: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#72532}
-
Thibaud Michaud authored
In the latest spec, catch_all is encoded as 0x05. This is the same opcode as "else", but they do not conflict because "else" is not valid in the context of a try block. The 0x0a opcode now corresponds to the "unwind" instruction, which currently has the same semantics as "catch_all". R=clemensb@chromium.org Bug: v8:11392 Change-Id: Ie9cd06c9a2001a02d8bea5be7a3c016e3a58ee3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2674007 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
