- 18 Oct, 2019 4 commits
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/60d20a7..6924ab4 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/8df31ad..c98b1ee Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/2a0049f..fcde3ba TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I4b049bcc3c296b756590faecb2c72ee8c14fc1c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868309Reviewed-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@{#64369}
-
Shu-yu Guo authored
DefineClass uses the ClassBoilerplate to directly construct the property descriptor array or dictionary for defining the class constructor and prototype, skipping use of the LookupIterator and the encapsulated protector update logic. This patch adds manual calls to UpdateProtector(), which is in particular relevant for the isConcatSpreadable protector. Bug: v8:9837 Change-Id: I7b9d8105d41f5f0f826ca2ce35d6bf3d1aeee6e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863644 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#64368}
-
Shu-yu Guo authored
Bug: v8:9837 Change-Id: Ib31f027f189017eab820b6eec2b7753e0bccdf82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864008 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
-
Shu-yu Guo authored
Split up the test so each test runs in a fresh Isolate with pristine protector state. Note that testArrayConcatES5 was not split out because it is a duplicate of mjsunit/array-concat.js, and testConcatRevokedProxy has already been split out as mjsunit/es6/array-concat-revocable-revoked-proxy-[12].js. Bug: v8:9837 Change-Id: I8f744b0263c82f1dae61a55032124d9129f8e6f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864007Reviewed-by:
-
- 17 Oct, 2019 26 commits
-
-
Ng Zhi An authored
This is a reland of 306bb635 Original change's description: > [wasm-simd] Implement F64x2ConvertI64x2 for x64 > > Bug: v8:8460 > Change-Id: Icefb90c67af77ac93bd75b4e452ba426232de83a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710332 > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Bill Budge <bbudge@chromium.org> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63627} Bug: v8:8460 Change-Id: I08d2c88e81ce51d3d1cfdf3d7d6ba34792e34e9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1793902Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#64365}
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: I9caa817ed1ab1f64984311d90f57ed779f15b225 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1850613Reviewed-by:
-
Ng Zhi An authored
In the non-avx case, we are incorrectly using DefineSameAsFirst, which is wrong, since operand0 is a 32-bit register, but the output should be a simd register. This error was caught by running the test with flag: --no-enable-avx, leading to a register allocator verifier failure. Drive by cleanup to remove duplicate cases for avx and see in i64x2 replace lane. Bug: v8:9728 Change-Id: I96490c82e13660fc41e72ac523e5be37b051b624 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866963 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port 3cad6bf5 Original Commit Message: This is a reland of c7c47c68. This makes TSAN happy in addition to: Previously I presumed that the context read from a frame in the profiler was a valid context. Turns out that on non-intel we're not guaranteed that the frame is properly set up. In the case we looked at, the profiler took a sample right before writing the frame marker indicating a builtin frame, causing the "context" pointer from that frame to be a bytecode array. Since we'll read random garbage on the stack as a possible context pointer, I made the code reading the native context from it a little more defensive. Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} R=verwaest@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I48b21f189e782a338eb2508edd57b7b2cf5ce240 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1865607Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#64362}
-
Z Nguyen-Huu authored
IsReceiverInitialRegExpPrototype, RegExpCreate Bug: v8:8976 Change-Id: If1d2598a2c2f302704c25aa65826fa442e6b79a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866015 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64361}
-
Toon Verwaest authored
This is a reland of c7c47c68. This makes TSAN happy in addition to: Previously I presumed that the context read from a frame in the profiler was a valid context. Turns out that on non-intel we're not guaranteed that the frame is properly set up. In the case we looked at, the profiler took a sample right before writing the frame marker indicating a builtin frame, causing the "context" pointer from that frame to be a bytecode array. Since we'll read random garbage on the stack as a possible context pointer, I made the code reading the native context from it a little more defensive. Bug: v8:9860 Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64360}
-
Ng Zhi An authored
Change-Id: I1c20a5c756394528af1e9f2bb720393d3045e926 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1865719 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64359}
-
Santiago Aboy Solanes authored
The DecompressionOptimizer aims to avoid adding the root in AnyTagged or TaggedPointer loads. For the TaggedSigned case, we already solve it in instruction selection. The new phase will run only when pointer compression is enabled. For the moment, it's also requires FLAG_turbo_decompression_elimination to be false. This latter flag is only temporary to test out the implementation. The phase needs to be run when Machine are present in the graph, i.e at the very end of the pipeline. Also, since this phase may change the load's MachineRepresentation from Tagged to Compressed, it's best to run it as late as possible in order to keep the phases that know about Compressed MachineRepresentation to a minimum. As an example, if we Load a Tagged value only to Store it back again (i.e Load -> Store nodes, with the Load being the Store's value) we don't need to fully decompress it since the Store will ignore the top bits. Bug: v8:7703 Change-Id: I6b4aec203ab8cbb540b2513cabb1e2a5691ce938 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859615 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64358}
-
Milad Farazmand authored
The calling conventions on AIX uses function descriptors, which means that pointers to functions do not point to code, but instead point to metadata about them. When calling JITed code, we must assure to use function descriptors instead of raw pointers when needed. Before this CL 213504b9, all CallCFunction on AIX were guaranteed to have function descriptors. Starting form the CL mentioned above, CallCFunction can also Jump to a Trampoline which does not have a function descriptor, hence a new "CallCFunctionWithoutFunctionDescriptor" method is proposed to deal with this issue. BUG= v8:9766 Change-Id: I9343c31c812f5d4dda8503a5adf024b24dbde072 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1825961 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
-
Joshua Litt authored
The current behavior for generating match indices simply stashes a pointer to the match info and then constructs the indices lazily. However, it turns out the match info object used to create the result object is the regexp_last_match_info living on native context, and thus it can change between the creation of the result object and the generation of indices. This cl clones the match info which will be safer. Bug: v8:9548 Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port f22837db R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Id1ee967a7e6d34715fe62abe21cee753bb8fd272 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1865678Reviewed-by:
-
Toon Verwaest authored
Previously ScrapeNativeContext was written quite defensively which could result in false positives and crashes. This CL makes the function always bail out when we're running on non-ia32/x64 since only those 2 properly verify whether the program is setting up a frame. If we are setting up a frame, the context will be garbage. This CL also disables profiler tests when TSAN is running since TSAN makes ScrapeNativeContext unsafe: it considers SIGPROF asynchronous and will run the handler after the program has already run further than the context that's passed into the handler. Bug: v8:9860, v8:9869 Change-Id: I5a08374feba2e0e77ddd59e02dc2d7e9c90c2e04 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866469Reviewed-by:
-
Clemens Backes authored
TBR=machenbach@chromium.org CC=hablich@chromium.org No-Try: true Change-Id: I19512e953adce96c5d559e4552543fe2c11042d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863937Reviewed-by:
-
Mike Stanton authored
The serializer doesn't correctly propagate environment information from try blocks into their catch handlers, and this impedes optimizations that fire when we compile concurrently. function bar(x) { try { boom(); // throws } catch(_) { return x.a; } } function foo() { return bar({a: 42}); } When foo is optimized, we can normally return the constant 42 directly. This CL makes that work for concurrent inlining. Bug: v8:7790 Change-Id: Id1c5fd06d51ec6fe69ab10fbd65afd6fa7e76820 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863193Reviewed-by:Maya Lekova <mslekova@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#64352}
-
Zhou, Zhiguo authored
This CL logs debug information of WASM in Intel VTune Amplifer via VTune's JIT Profiling API. With this CL, the profiling information of JITted code and its corresponding C/C++ source code is displayed optionally. To use this feature, a runtime flag "vtune_prof_annotat e_wasm" should be passed to the VTune-enabled V8 engine. Currently, the inline function in C/C++ is not well supported due to the limitation of source map. As a drive-by fix, the dynamically allocated event-specific data of JavaScript (src/third_party/vtune/vtune-jit.cc) is managed with C++ containers for safety. Change-Id: Ic27420fcdcd775bc5c7778abf5cff6edf0fb38b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782126Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Zhiguo Zhou <zhiguo.zhou@intel.com> Cr-Commit-Position: refs/heads/master@{#64351}
-
Milad Farazmand authored
LoadReverseSimd128 and StoreReverseSimd128 are implemented to support the above instruction selection. Change-Id: I5dcb30ce68b3478c69668b7589e77a52e77d9388 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846460 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#64350}
-
Georg Neis authored
Change-Id: I50e76ff32aae158dd05ae8d4a4633ab81e5c61d4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864946 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#64349}
-
Dominik Inführ authored
Add FLAG_always_promote_young_mc that always promotes young objects during a Full GC when enabled. This flag guarantees that the young gen and the sweeping remembered set are empty after a full GC. This CL also makes use of the fact that the sweeping remembered set is empty and only invalidates an object when there were old-to-new slots recorded on its page. Bug: chromium:1014943 Change-Id: Idfb13dfbe76bad5ec8b485a60bebc30531aec649 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863201 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
The top bar was being scrolled down since the whole viewpane was scrollable. It will now work in the way the "Dissasembly" tab works: the content is scrollable, but not the pane. This change makes Schedule and Sequence consistent within the other panels. As a drive-by fix, remove some unused constants. Bug: v8:7327, v8:9517 Notry: true Change-Id: I22f8abb6524cb297f43930fc8036b36b7ce59751 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863203 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#64347}
-
Sathya Gunasekaran authored
This reverts commit 97ed8b27. Reason for revert: breaks chromium roll https://chromium-review.googlesource.com/c/chromium/src/+/1864878 I bisected it down to this CL here: https://chromium-review.googlesource.com/c/chromium/src/+/1865346/6 https://ci.chromium.org/p/chromium/builders/try/linux-rel/219610 Original change's description: > [regexp] Guarantee an allocated regexp stack > > The regexp stack is used during execution of jitted regexp matcher > code. Previously, the stack was initially not present / nullptr, and > we had to explicitly check for this condition and bail out in builtin > code. > > This CL changes behavior to guarantee a present stack by adding a > statically-allocated area that is used whenever no > dynamically-allocated stack exists. > > Change-Id: I52934425ae72cf0e5d13fab2b9d63d37ca76fcf3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852126 > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64326} TBR=jgruber@chromium.org,petermarshall@chromium.org Change-Id: I085b7aebb513fdededda7631b06ff68e5ae5846e No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864945Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64346}
-
Igor Sheludko authored
The CL fixes the following builtins: %TypedArray%.prototype.join %TypedArray%.prototype.every %TypedArray%.prototype.find %TypedArray%.prototype.findIndex %TypedArray%.prototype.forEach %TypedArray%.prototype.reduce %TypedArray%.prototype.reduceRight %TypedArray%.prototype.some Bug: v8:4153 Change-Id: I39cdb1801949b1df9d221988b8ed4ed5b2de9341 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864941Reviewed-by:
-
Clemens Backes authored
"alternates" should be "alternatives". Drive-by: Rename "generate_fn" to "GenerateFn". R=ahaas@chromium.org Change-Id: I09de4678dddcc4a8949dd9589e4dddd0c1c0661c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866509Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64344}
-
Primiano Tucci authored
This catches up with recent changes. None of them should be relevant for v8. I am doing this mainly because I am going to refactor the proto generator for go/perfetto-libprotobuf and seems worth having a recent last-good checkpoint of perfetto before starting that. Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng Bug: v8:8339 Change-Id: Icfeb7bda3e01448f4db579a76b2cf8b61626b997 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863202Reviewed-by:
Tamer Tas <tmrts@chromium.org> Reviewed-by:
-
Gus Caplan authored
Change-Id: I828450704fdb74bc5ced0f8f85a0546672b4ff9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864571Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/082f11b..60d20a7 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b9fad2f..8df31ad Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ba97f60..2a0049f TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I5e121e66f76fee8a76a3dc17b9b0168ed9ebf0e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1865993Reviewed-by:
-
Milad Farazmand authored
Port 7d09b270 Original Commit Message: It turns out that because we are *subtracting* from fp, we need to *subtract less* to get a higher address. Who knew. R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ide47f62b5fbfd309a2892fcd934175db7e390a8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864586Reviewed-by:
-
- 16 Oct, 2019 10 commits
-
-
Ng Zhi An authored
Bug: v8:9813 Change-Id: I9ab0d0aafb0a2620a317d99c10f56dbcaa7fdf04 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1849206 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
David Benjamin authored
Bug: chromium:1014607 Change-Id: Ifcd1ce17fb1f95965355a4e3f63bdc78fa88042f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1865613 Auto-Submit: David Benjamin <davidben@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#64338}
-
Ng Zhi An authored
This introduces 2 new machine operators that are variants of I64x2Splat and I64x2ReplaceLane that takes two int32 operands instead of one i64 operand. Bug: v8:9728 Change-Id: I6675f991e6c56821c84d183dacfda96961c1a708 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1841242Reviewed-by:
-
Ng Zhi An authored
TBR=machenbach@chromium.org Bug: v8:9863 Change-Id: I5312e53eca73469b9a77ddb9232535591b8fdcb3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1865714Reviewed-by:
Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#64336}
-
Clemens Backes authored
The lookahead did not check whether there is actually a byte left to be read. So if the i32 comparison was the last byte in the function body, we would read out of memory. This CL fixes that by introducing a separate {lookahead} method which does the proper bounds check and the lookahead. R=jkummerow@chromium.org Bug: chromium:1014834, v8:9831 Change-Id: I6499ae3f2c57d38a8fcb587b99ae4a4a6c70e426 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864939Reviewed-by: -
Ng Zhi An authored
Bug: v8:9415 Change-Id: I6cd413117fc5c949ed668d2dff2bbfbbc880ebcb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863952Reviewed-by:
-
Thibaud Michaud authored
R=clemensb@chromium.org Change-Id: I061ca50c08cfa2bc60e74e4387e3e2933659202b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864655Reviewed-by:
-
Clemens Backes authored
Instead of spilling x0 and x1 to the stack, use temp registers which should always be available in this situation. This avoids the spill and load. Also, switch from holding {start} and {end} in the register to holding {start} and {count}. This make it easier to correctly initialize the registers. R=joey.gouly@arm.com Bug: v8:9830 Change-Id: I5fc8b8603afaf12fad2ba66cd7a75555ef31bd4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859618 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Seth Brenith authored
This change extends v8_debug_helper to export a new method that returns a list of all known heap object types. Why? We can substantially improve the user experience in our work-in- progress WinDbg extension if we register handlers not only for v8::internal::Object but for every specific HeapObject type. This has two benefits: - You save a click: if you're expanding a local variable of a more specific type than Object, you can see properties immediately rather than first needing to expand a sub-item that casts the variable to Object. - You retain the type hint: GetObjectProperties accepts a type hint string, and it's super important to pass it when working in a crash dump because the object's Map is probably inaccessible. If we have to cast to Object first, we lose this data. Bug: v8:9376 Change-Id: I4d635a1826574a3d08ac657e848e1fe7b83849fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822859Reviewed-by:
-
Clemens Backes authored
Most comparisons are followed by a br_if instruction. This CL detects that for i32 comparisons and folds them with a following br_if, avoiding to materialize the result of the comparison as 0 or 1 in a register. This saves three out of the five instructions generated for this pattern before. Plus some drive-by cleanup. R=jkummerow@chromium.org Bug: v8:9831 Change-Id: I7bed47f2523b60b2bf301f074fe3132aea9a0636 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862561 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
