- 19 Jun, 2020 18 commits
-
-
Milad Farazmand authored
Port c6642b51 Original Commit Message: We rely on Liftoff for debugging, hence enable it everywhere by default. This follows a chromium finch experiment and a CL to enable it everywhere in chrome: https://crrev.com/c/2252100 R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I1a8e7a4acb9a5ce5a6d0ba96b105ba32e53f1b69 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253464Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#68438}
-
Mike Stanton authored
Formerly, we zapped a transition array when we replaced it with a larger one, but this is no longer necessary. Leaving those arrays in peace makes life easier for concurrent (racy) access from a background compilation thread. Design doc with more info about racy access to transition arrays between the main JavaScript thread and a background compilation thread here: https://docs.google.com/document/d/1ax2qyENdr50Qu9yur1qNu6_zRK0m6K2l7BLM_QDBFJM/edit?usp=sharing Change-Id: I4c2757945266d43d82ec157e0ff2b9208a8e4c63 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253840Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#68437}
-
Maya Lekova authored
Avoid possible use-after-free. Fixed: v8:10210 Change-Id: Id8bdf70804448b5b793d9d593374f4b588fe3e87 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253841 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Auto-Submit: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#68436}
-
Peter Marshall authored
Change-Id: I37e241d9c62f1a7fed438ee8717f02f5b4f51bea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253846 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#68435}
-
Almothana Athamneh authored
This CL migrates the bots v8_mac64_gc_stress_dbg and v8_mac64_asan_rel to the new format. Bug: v8:10445 Change-Id: I7520985499c91c6571ba93e1515223f57f0d38ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253839Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Cr-Commit-Position: refs/heads/master@{#68434}
-
Kim-Anh Tran authored
Until now the breakpointIdToDebuggerBreakpointIds was cleared on page reload. It keeps a map from breakpointIds to debuggerBreakpointIds, with the latter being necessary for removing breakpoints. If a breakpoint is set and we trigger a page reload, the information about that breakpoint will be removed from the map, even if it still exists. If we later want to remove the breakpoint we look into the map, but the meta data is no longer existing. Thus, reloading the page again will lead to hitting the breakpoint, even if we removed it in the front-end. This change keeps the map alive on page reset, so that we still keep track of set breakpoints after a page reload. Bug: chromium:1073071 Change-Id: I82192777bac7afc406245a5a1cff0620e8174499 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253842Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#68433}
-
Peter Marshall authored
evaluate() bypassed CSP for unsafe-eval by default. This is a useful option for debugging clients, but is not always what we want. e.g. in the devtools console we want to match the page's CSP settings to make debugging CSP issues on the page easier. Add a toggle that keeps the current behavior by default. Bug: chromium:1084558 Change-Id: Ia01142d5be00f8ef5f65e5eeba17549efc6f9120 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250245 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
Clemens Backes authored
We rely on Liftoff for debugging, hence enable it everywhere by default. This follows a chromium finch experiment and a CL to enable it everywhere in chrome: https://crrev.com/c/2252100 R=ecmziegler@chromium.org Bug: chromium:1040030 Change-Id: I3abbf915515883e6eb1f37501466290def57862d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2252196Reviewed-by:
Emanuel Ziegler <ecmziegler@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68431}
-
Maya Lekova authored
Bug: v8:10009 Change-Id: Iccc42a9b5f9f7340851542185473ac49683c838c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253843Reviewed-by:
-
Clemens Backes authored
Make sure that the workers do not start running before the main thread told them so by setting the memory to the first element in the sequence. Otherwise it can happen that the main thread resets the memory after the workers already started doing their updates, which results in a hang (see linked bug). R=marja@chromium.org Bug: v8:10625 Change-Id: I959018279e0049900d44457b72146bc37a12bcb4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2252191 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#68429}
-
Manos Koukoutos authored
Bug: v8:7748 Change-Id: I58e8216e3d51aa9da3e6a819cdf2614b4509e1a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250249 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#68428}
-
Dan Elphick authored
Bug: v8:10473 Change-Id: Ic53130ca5103ba219329f7b204b218bc021f07f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2252178Reviewed-by:
-
Michael Lippautz authored
This is a reland of e0c1a349 The issue was passing SentinelPointer (== +1) through T*. The fix is disabling cfi unrelated cast diagnostic for the bottlenecks (Get()). This means that nullptr is treated the same as kSentinelPointer. The alternative would be a DCHECK that Get() does not return kSentinelPointer and adjusting all Member and Persistent logic that uses Get() to work on void*. This is quite intrusive as it involves Swap(), heterogeneous assignments, comparisons, etc. Original change's description: > cppgc: Properly clear (Weak)Peristent and WeakMember pointers > > The CL addresses two issues with (Weak)Persistent and WeakMember: > 1. (Weak)Persistent pointers are cleared on heap teardown. Before this > CL the pointers would contain stale values which could lead to UAF. > 2. WeakPersistent and WeakMember are cleared using a combination of > internal clearing methods and mutable fields which avoids the use > of const_cast<>. > > Bug: chromium:1056170 > Change-Id: Ibf2b0f0856771b4f6906608cde13a6d43ebf81f3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2248190 > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Reviewed-by: Anton Bikineev <bikineev@chromium.org> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68394} Bug: chromium:1056170 Change-Id: I3d74b43464c2973df1956f51b1419d755dd9f519 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250240Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#68426}
-
Manos Koukoutos authored
This CL introduces one-letter shorthands to HeapTypes, and fixes signatures to be in sync with the ValueType and HeapType shorthands. Bug: v8:7748 Change-Id: I4cc8e26d6523074bc36bf2d29289e63a23e80ddc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249672 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Kim-Anh Tran authored
Increase TypedArray.kMaxLength by 1. Bug: chromium:1095721 Change-Id: Ic3668ff4e71cfd1289eda495333c4aae62c44795 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249668Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Manos Koukoutos authored
Bug: v8:7748 Change-Id: I6087c02aab93ba44b8029f3d1a0c99fd6a4da6f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250248 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Frank Tang authored
Bug: v8:10599 Change-Id: I1248d365576c0bc8c01d8ce07f0c49654fabfc52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2251173 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/78f36d4..3591130 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/3200e0f..1ed9957 Rolling v8/buildtools/linux64: git_revision:fbe7aec770944d17c9f3006f6cbb5c19e8cd43ea..git_revision:7d7e8deea36d126397bda2cf924682504271f0e1 Rolling v8/third_party/aemu-linux-x64: T98d0T9VlsHV98PPahwzBa8kF94z5dghLKOTUDCTmwYC..UoYLOT0X6577j70eB9nPqYQs9Z3Nh5lA4I-pRtTchO0C Rolling v8/third_party/android_sdk/public: CR25ixsRhwuRnhdgDpGFyl9S0C_0HO9SUgFrwX46zq8C..uM0XtAW9BHh8phcbhBDA9GfzP3bku2SP7AiMahhimnoC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/fbbd9ca..4ac015d Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/3eb899a..2410c84 Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/9e7dae8..79326ef Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/0d67b22..42b285f TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I3024219a33b862fef5e7393a3e18c88f46e29dc3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253105Reviewed-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@{#68421}
-
- 18 Jun, 2020 22 commits
-
-
Ng Zhi An authored
This was causing issues with strict mode when combined with fuzzers. See https://crrev.com/c/2173952/7/test/mjsunit/wasm/wasm-module-builder.js#471 Change-Id: I164b24c35d7ba7c53a550dc3649eb7268dfb30e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2252540Reviewed-by:
-
Ng Zhi An authored
Prototype f32x4.ceil on ARM for both ARM v7 and ARM v8. ARM v8 has support for vrintp, and for ARM v7 we fallback to runtime. Since ARM v8 uses vrintp, which is the same instruction used for F32 Ceil (scalar), wasm-compiler reuses the Float32Round check, rather than creating new F32x4Round optional operators. Implementation for vrintp (Advanced SIMD version that takes Q registers), assembler, disassembler support. Incomplete for now, but more will be added as we add other rounding modes. Bug: v8:10553 Change-Id: I4563608b9501f6f57c3a8325b17de89da7058a43 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2248779Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
-
Ng Zhi An authored
Similar to chromium side change: https://crrev.com/c/1961070. When checkout_clang_tidy is set, we will check out clang-tidy via clang/scripts/update.py. The goal is to be able to run clang-tidy using Tricium. Bug: chromium:1087565,v8:10488 Change-Id: I14ebaaca33ca20d59d9cc5e537826829608a1e6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2242257Reviewed-by:
-
Ng Zhi An authored
Bug: v8:10180 Change-Id: Ic341e0de315b7d7b33dbad265c8fda9145a669da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2243760Reviewed-by:
-
Ng Zhi An authored
Extend gm.py to support long flags (starting with --), which are treated as test runner flags, and passed unchanged. These flags must be as single word, '--progress=verbose' instead of '--progress verbose', as gm only does simple one-at-a-time args parsing. Change-Id: Icfa161ff231715d0b7eb3ba259fca35a65c68964 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250875 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Dan Elphick authored
When preparsing and detecting a sloppy block function redefinition then don't mark the variable as assigned to make it consistent with the eager parser. Bug: chromium:1053364 Change-Id: Iec7c24db80014bfe73ee41a4f3bb7a41a354cef2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241511 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
Change-Id: I2cc4126c63238ddbd4f8bd784e0f7b1322c003ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238028Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68414}
-
Clemens Backes authored
Instead of creating temporary {std::vector}s (which always allocate on the heap) create more vectors on the stack, via initializer lists. As this is "only" a fuzzer, performance is not really critical, but still has some impact on the efficiency of the whole fuzzer. That said, this CL is mostly a cleanup to replace unwanted code pattern by better code. R=jkummerow@chromium.org Change-Id: I924c15e5d64ed584fc96c85715eef1dca5aef150 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249928 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
zeynepCankara authored
Change-Id: I02baea85ff93683848f2f5a4571a0d94d3821f0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249673 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#68412}
-
Jakob Gruber authored
At this point in development, this is a reasonable config for the nci test variant. --turbo-nci currently disables some compiler phases and avoids embedded context-dependent constants. --turbo-collect-feedback-in-generic-lowering enables full feedback collection in generic lowering. I'm keeping the two as separate flags for now since it can be interesting to benchmark --turbo-nci both with- and without feedback collection. Bug: v8:8888 Change-Id: I678baeb0ed051b158ac0634f00de9b6a55f87e09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247770 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#68411}
-
Michael Achenbach authored
This changes PrepareFunctionForOptimization to have the same checks as OptimizeFunctionOnNextCall, as otherwise fuzzing runs into the DCHECK with a bad number of arguments. Bug: chromium:1094866 Change-Id: Ief7d428a12139c47a74607d39792276a2eae4ebf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250255Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I759ccce7fc8d0fa6742b11ce9c05a254bf0728ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250256Reviewed-by:
-
Manos Koukoutos authored
Motivation: Changes to the typed function references and gc proposals solidified the notion of heap type, clarified nullable vs. non-nullable reference types, and introduced rtts, which contain an integer depth field in addition to a heap type. This required us to overhaul our ValueType representation, which results in extensive changes. To keep this CL "small", we do not try to implement the binary encoding as described in the proposals, but rather devise a simpler one of our own (see below). Also, we do not try to implement additional functionality for the new types. Changes: - Introduce HeapType. Move heap types from ValueType to HeapType. - Introduce Nullability for reference types. - Rework ValueType helper methods. - Introduce rtts in ValueType with an integer depth field. Include depth in the ValueType encoding. - Make the constructor of ValueType private, instead expose static functions which explicitly state what they create. - Change every switch statement on ValueType::Kind. Sometimes, we need nested switches. - Introduce temporary constants in ValueTypeCode for nullable types, use them for decoding. - In WasmGlobalObject, split 'flags' into 'raw_type' and 'is_mutable'. - Change IsSubtypeOfRef to IsSubtypeOfHeap and implement changes in subtyping. - kWasmFuncRef initializers are now non-nullable. Initializers are only required to be subtypes of the declared global type. - Change tests and fuzzers as needed. Bug: v8:7748 Change-Id: If41f783bd4128443b07e94188cea7dd53ab0bfa5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247657 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Dan Elphick authored
This reverts commit f78d69fa. With https://chromium-review.googlesource.com/c/v8/v8/+/2243216, incorrect MemoryChunk::FromHeapObject uses are now fixed. Original change's description: > Revert "[heap] Make ReadOnlySpace use bump pointer allocation" > > This reverts commit 81c34968 and also > 490f3580 which depends on the former. > > Reason for revert: Break CFI tests in chromium https://ci.chromium.org/p/chromium/builders/ci/Linux%20CFI/17438 > Original change's description: > > [heap] Make ReadOnlySpace use bump pointer allocation > > > > This changes ReadOnlySpace to no longer be a PagedSpace but instead it > > is now a BaseSpace. BasicSpace is a new base class that Space inherits > > from and which has no allocation methods and does not dictate how the > > pages should be held. > > > > ReadOnlySpace unlike Space holds its pages as a > > std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses > > BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and > > cannot be held in a heap::List. This is desirable since with pointer > > compression we would like to remap these pages to different memory > > addresses which would be impossible with a heap::List. > > > > Since ReadOnlySpace no longer uses most of the code from the other > > Spaces it makes sense to simplify its memory allocation to use a simple > > bump pointer and always allocate a new page whenever an allocation > > exceeds the remaining space on the final page. > > > > Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060 > > Commit-Queue: Dan Elphick <delphick@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#68137} > > TBR=ulan@chromium.org,delphick@chromium.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Change-Id: I68c9834872e55eb833be081f8ff99b786bfa9894 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232552 > Commit-Queue: Dan Elphick <delphick@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68211} TBR=ulan@chromium.org,delphick@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: Id5b3cce41b5dec1dca816c05848d183790b1cc05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250254Reviewed-by:
Dan Elphick <delphick@chromium.org> Reviewed-by:
-
zeynepCankara authored
Change-Id: Icc37fc091086a3239a1b080ca2829efcda97f328 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245601 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
-
Ross McIlroy authored
When running in single-process mode for Webview, the stack limit is initialized from a point closer to the top of stack limit. This causes can cause crashes since the stack limit might be higher than the actual native stack limit (which is 1MB on Android). As such, use the same slightly lower stack limit on Arm64 as we do on Arm to give more slack. BUG=v8:10575 Change-Id: I0cdd0cb4b38aafcb4e158ed639ecf3bba2edb785 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250241 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Frank Tang authored
https://chromium.googlesource.com/external/github.com/tc39/test262/+log/f89ea875..8d3dd2d 8d3dd2d Sync the test w/ changes in intl-datetime-style 43 by Frank Tang · 15 hours ago master 2dcdba9 Simplify tests by Alexey Shvayka · 15 hours ago 23417d9 Test %TypedArray%.prototype.set with primitives by Alexey Shvayka · 15 hours ago Bug: v8:7834 Change-Id: I39b62aa1f4800349a009035e704bd4a93223174b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2251174Reviewed-by:
Mathias Bynens <mathias@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#68404}
-
Clemens Backes authored
Instead of having a loop with one big switch for handling the different opcodes, split the decoding into one handler per opcode and call them via an opcode handler table. The compiler will generate similar code for this new approach (the big switch is also compiled into a table lookup and an indirect jump). The main difference is that it's now calls instead of jumps. This has a slight performance impact, but allows to look at the decoding logic of individual opcodes in isolation and see optimization opportunities much easier. It also allows spot very easily in profilers on which opcodes most time is spent. The different opcode handlers are still implemented via the same switch as before, but since the opcode is a template argument (hence static) the compiler will eliminate the switch and generate the small handlers we want. I plan to actually remove the switch and break up the big generic {DecodeOp} method into one method per opcode. R=thibaudm@chromium.org Bug: v8:10576 Change-Id: Ic2c1e2fe5e98df52a7079ace305cf77340dcbf35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249664Reviewed-by:Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68403}
-
Jakob Gruber authored
Introduced in https://crrev.com/c/2250243. CONSTEXPR_DCHECK(cond) replaces the longer #if V8_HAS_CXX14_CONSTEXPR DCHECK(cond); #endif pattern. Change-Id: I636e5b4b40bffb29b2e82c81285b2ef78a822745 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250244Reviewed-by:
-
Michael Achenbach authored
This subsumes the old behavior of --allow-natives-for-fuzzing under --fuzzing as well. Both flags are used in a redundant way in fuzz configs. Only --allow-natives-for-fuzzing wasn't specified as a required argument, leading to the bug below. We still need the flag --allow-natives-for-differential-fuzzing to allow different functions when using differential fuzzing. Bug: chromium:1094866 Change-Id: I398791779e58ed4d80e896c1cfea343848159212 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2246568 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Jakob Gruber authored
... in regexp bytecode {length,name} accessors and in peephole optimization. Bug: chromium:1095866 Change-Id: I78c89d35d796776b61eabf82b921f7582e431be7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250243Reviewed-by:Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Clemens Backes authored
The {NextInstruction} method is quite hot, since it's called for every since Wasm instruction. It currently does several checks to figure out if - a breakpoint needs to be emitted, - extra source positions are needed, or - tracing is active. The first two can only happen if we are generating debug code, hence check for that first. The last can only happen in debug mode, so it's not an issue in production. Finally, outline the emission of debug information. This leads to inlining of the {NextInstruction} method into callers, where it is a single check followed by a call to {EmitDebuggingInfo} (in release mode). R=thibaudm@chromium.org Bug: v8:10576 Change-Id: I5047406f55cd14c6c639528ef6e3422af27d16b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2249671 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
