- 20 Jan, 2021 6 commits
-
-
Liviu Rau authored
Bug: chromium:1064551 Change-Id: I81935d9bfe7b779f6f33ae8afa54f5b86c6bd74e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637224Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Cr-Commit-Position: refs/heads/master@{#72184}
-
Jakob Gruber authored
This is a reland of 8703c38d The reland marks the new test as slow, skips all variants, and skips all non-release modes. Original change's description: > [compiler] Emit a function-entry stack check on OSR-entry > > This CL extends the smarter function-entry stack check logic (see > v8:9534) to OSR'd code. These smarter stack checks prevent > overflowing the stack during deoptimization. > > The challenge for both function-entry (FE) and OSR-entry (OE) stack > checks is that there is no dedicated physical StackCheck to > deoptimize into. For more context: the physical StackCheck bytecode > was removed in crrev.com/c/1914218. > > FE stack checks solve this by using a marker bailout id to signify > a deopt bytecode offset before the first bytecode. > > In this CL, OE stack checks take a similar approach by using the > OSR'd loop's JumpLoop bytecode, which is conceptually immediately > before the OSR'd loop header. > > When a stack overflow at an OE stack check occurs: %StackGuard > may cause a lazy deopt on return to the optimized OSR code, > causing re-execution of the JumpLoop handler in the > InterpreterEnterBytecodeAdvance builtin, ultimately continuing > execution the interpreter at the first bytecode of the OSR'd loop > header. > > Bug: chromium:1034322, v8:9534 > Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872 > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72153} Tbr: neis@chromium.org, solanes@chromium.org Bug: chromium:1034322 Bug: v8:9534 Change-Id: I28a23d0cc4b14d59c3d4a5dbadd5dab3ac31d442 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639753Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72183}
-
Maya Lekova authored
This reverts commit a8451683. Reason for revert: Breaks TSAN builds and closes the tree, see https://bugs.chromium.org/p/v8/issues/detail?id=11333 Original change's description: > Update V8 DEPS. > > Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/43dd249..781f002 > > Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/cf567b6..d168442 > > Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/dabd965..c3c15a1 > > Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/ba4ee03..683dad6 > > TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com > > Change-Id: I8c66185943738477e595672ba7d9efa243d062d3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2638915 > Reviewed-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@{#72181} TBR=machenbach@chromium.org,v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: If5905806b9cd0c8e033df8554edd9e01bca29e30 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639755Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#72182}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/43dd249..781f002 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/cf567b6..d168442 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/dabd965..c3c15a1 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/ba4ee03..683dad6 TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I8c66185943738477e595672ba7d9efa243d062d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2638915Reviewed-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@{#72181}
-
Zhi An Ng authored
The codegen for q15 rounding mul and dot incorrectly assumes that the second operand is always a register. For dot, we change the codegen to accept an Operand. For q15, we change the instruction-selector to always use register. Bug: v8:10971,v8:10993 Change-Id: I30a421de47ba61693ca73e616bcbc27ab01ac7bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626712Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#72180}
-
Zhi An Ng authored
Prototype load lane instructions on ia32 Liftoff. We generalize the pinsr* macro-assembler functions to take an extra input, following the 3 operand + 1 imm form of the AVX instructions. Bug: v8:10975 Change-Id: I3fa10d149b011b62edd58372148446b663f3dc3c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2619417Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
- 19 Jan, 2021 34 commits
-
-
Zhi An Ng authored
Bug: v8:10971 Change-Id: Ie2409df6909d3be40f998445ae9c9b35c96ef3a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632012Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#72178}
-
Zhi An Ng authored
This instruction has been merged into the proposal: https://github.com/WebAssembly/simd/pull/365 Bug: v8:10971 Change-Id: I4dcad343a99271e1af4a48497e9f4ecc20785dcf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632011Reviewed-by:
-
Milad Fa authored
Change-Id: I586f3331fc8f468f799915e02e5863310e98937c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2636843Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#72176}
-
Z Nguyen-Huu authored
Instead, use Is<NativeContext> then UnsafeCast. Bug: v8:9679 Change-Id: Id87a10fa66ff1c1e0ca0099b1938c72da2437832 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2631554 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
-
Zhi An Ng authored
Code sequence from https://github.com/WebAssembly/simd/pull/379. Bug: v8:11002 Change-Id: I47c1090d792f8cbb9d7846ace9a4f996d0c460b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626717Reviewed-by:
-
Milad Fa authored
Port 624030e9 Original Commit Message: This will allow us optimize the protector cell checks in the fast path from checking against the function object in every context to just doing a range check against the instance type. This patch adds new instance types for constructor functions that require such protector cell checks. R=gsathya@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: If5918721117e87579a3c6a2a4ed6245bd033a88e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2636840Reviewed-by:
Milad Fa <mfarazma@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#72173}
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I7900d041ff1331991d14e2766a6760b69f37622e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637230Reviewed-by:
-
Seth Brenith authored
This would be useful for ForInPrepare. Syntax is unchanged; Torque should now do the right thing for builtins that return a two-element struct. More elements than that is still not supported. Bug: v8:7793 Change-Id: Ic315699402203aba07e906ff6e029834ec0061c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596498Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72171}
-
Zhi An Ng authored
This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for the interpreter. This is the first instruction of its kind, a post-mvp, unary operation that takes one immediate. Which is why there are more changes to the decoder than usual. Bug: v8:11297 Change-Id: Ib5c58965e0cba8d7a395b0dc57673110bc60e87c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617385Reviewed-by:
-
Marja Hölttä authored
1) Computed property keys (esp functions in them) shouldn't be inside the object literal scope. 2) I was using an imprecise "maybe uses super" and storing it to preparse data. This won't fly, since it pollutes sister scopes and leads to confusion wrt whether an object literal needs a home object or not. Made it precise (mostly cancelling changes in the original CL). 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for this_function (which made it used) -> inconsistent scopes between parsing and preparsing. 4) MultipleEntryBlockContextScope was messing up the accumulator Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055 Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220Reviewed-by:
-
Liviu Rau authored
Bug: chromium:1166989 Change-Id: I6eca7745ee4457d86ecda65a3972011899bac9c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637219 Auto-Submit: Liviu Rau <liviurau@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
-
Sathya Gunasekaran authored
`last` indicates that it's the last element of the list but in reality this supposed to indicate the previous entry in the list. Rename this to something more clearer. Change-Id: I26c9a1fca02cf6b10d0447768da694d590a43932 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637229Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#72167}
-
Ross McIlroy authored
Moves the serialization of the initial set of maps read from the native context from the forground serialization phase to a new background serialization phase. BUG=v8:7790,v8:9684 Change-Id: Id408e5c3096e832cf30106eb8fb7d65518432e06 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613028 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Seth Brenith authored
On arm64, Windows Performance Recorder gets confused by the fact that fp in Builtins_JSEntry doesn't point to the saved {fp, lr} pair for the caller frame. The expected usage of fp is documented in [1]: The frame pointer (x29) is required for compatibility with fast stack walking used by ETW and other services. It must point to the previous {x29, x30} pair on the stack. In slightly more detail, the Windows function RtlWalkFrameChain is responsible for generating stack traces during profiling with Windows Performance Recorder, and that function relies on the rule quoted above. Notably, it does not make any effort to read the unwinding data that one could obtain with RtlLookupFunctionEntry. Stack walks using that data, such as those performed by WinDbg and the cctest StackUnwindingWin64, work fine. It would be convenient if we could use fp in a more standard way during JSEntry so that Windows profiling tools work correctly. (We can also reduce JSEntry by two instructions in doing so.) Both arm and arm64 currently put a -1 value on the stack at the location that fp points to. This could prevent accidental access during the epilog of JSEntry, where fp might be zero. However, we believe that this protection is no longer necessary, and any bug that causes a read from fp during the end of JSEntry would cause various CQ failures. [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160 Change-Id: Iece5666129b9188fc4c12007809b50f046f4044f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2607636 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72165}
-
Clemens Backes authored
The test was explicitly tiering up or down a module, without respecting other isolates. Thus it was failing in multi-isolate mode. This CL removes two runtime functions which do not make sense in a multi-isolate setting (and were only used in this one test), and replaces them with runtime functions that mimic what enabling/disabling the debugger domain does: As long as there is at least one isolate which needs modules to be tiered down, we keep them tiered down. R=thibaudm@chromium.org Bug: v8:10359, v8:10099 Change-Id: Ia85f4ea29ba6a6bb54aca54a48fadd351121d3eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637231Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72164}
-
Clemens Backes authored
The engine can be retrieved from the NativeModule, hence avoid passing it explicitly. R=ahaas@chromium.org Change-Id: I38f9bdb9624006da8311e57c3e53327654b6e85a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637855Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72163}
-
Georg Neis authored
Change-Id: Ifad7bbafc8b7c7ff8cf9140b9227cb9c67370fcf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637856 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72162}
-
Jakob Gruber authored
The helper encapsulates the `x - x` pattern to silence NaN `x`. Bug: v8:7519 Change-Id: Ia633272d7b7cc350c7e4db07e271e0192c68019f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637232 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
Junliang Yan authored
Change-Id: I3803e3f7916827b3b9853c8c3a3ce6806cc2daac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2636054 Commit-Queue: Junliang Yan <junyan@redhat.com> Reviewed-by:
-
Benedikt Meurer authored
This was originally proposed by yangguo@ on the original CL that introduced this, but back then it looked easier to put the map cache onto the global object than on the native context. However it turns out that this is indeed quite strange and also not necessarily supported (we got crashes from the wild indicating that the `Object::GetProperty()` might fail on the global object). So this CL simplifies the original design and just puts the map cache onto the native context like with do with other context specific maps. Fixed: chromium:1167399 Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241 Change-Id: Ie16f892dd19b55b4c49e9d4829cab3c24ae64ad3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637226 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72159}
-
Clemens Backes authored
This reverts commit 8703c38d. Reason for revert: New test is timing out on gc-stress (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/31726/overview) Original change's description: > [compiler] Emit a function-entry stack check on OSR-entry > > This CL extends the smarter function-entry stack check logic (see > v8:9534) to OSR'd code. These smarter stack checks prevent > overflowing the stack during deoptimization. > > The challenge for both function-entry (FE) and OSR-entry (OE) stack > checks is that there is no dedicated physical StackCheck to > deoptimize into. For more context: the physical StackCheck bytecode > was removed in crrev.com/c/1914218. > > FE stack checks solve this by using a marker bailout id to signify > a deopt bytecode offset before the first bytecode. > > In this CL, OE stack checks take a similar approach by using the > OSR'd loop's JumpLoop bytecode, which is conceptually immediately > before the OSR'd loop header. > > When a stack overflow at an OE stack check occurs: %StackGuard > may cause a lazy deopt on return to the optimized OSR code, > causing re-execution of the JumpLoop handler in the > InterpreterEnterBytecodeAdvance builtin, ultimately continuing > execution the interpreter at the first bytecode of the OSR'd loop > header. > > Bug: chromium:1034322, v8:9534 > Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872 > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72153} TBR=neis@chromium.org,jgruber@chromium.org,solanes@chromium.org Change-Id: Ie72f2e2927ffa83d595aad0d88c606d422f953a2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1034322 Bug: v8:9534 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637858Reviewed-by:
-
Junliang Yan authored
Change-Id: I42ff5501bec10ef5230ea06d5feb9adc5be0d875 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633731Reviewed-by:
-
Clemens Backes authored
The inspector fuzzer is terminating the isolate after two seconds. At this point, we can be in pretty much any state, and any further JS execution would fail. This CL fixes an issue where we got the termination signal when creating a context for a regexp (while installing extensions). There might be more places that need fixing, but with this CL the linked issue does not reproduce locally any more, so it's a step forward. R=szuend@chromium.org, bmeurer@chromium.org Bug: chromium:1166549 Change-Id: I33b48205b71877aca6cfe5267f353fa899bfa05c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2636153Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#72156}
-
Michael Lippautz authored
Termination GCs are used to destroy remaining C++ object on the managed heap to free potential off-heap memory. This is important for gracefully shutting down workers. Drive-by: Add guard prohibiting recursive sweeping calls on the mutator thread. Bug: chromium:1056170 Change-Id: I02ea3b632d38f5beab18cc8f077cf717ed877909 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2631504 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72155}
-
Milad Fa authored
Bug: v8:10972 Change-Id: Id7b17ad54f0a6a1a8b3eb04bb81b2ec94bca921b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2635796Reviewed-by:
-
Jakob Gruber authored
This CL extends the smarter function-entry stack check logic (see v8:9534) to OSR'd code. These smarter stack checks prevent overflowing the stack during deoptimization. The challenge for both function-entry (FE) and OSR-entry (OE) stack checks is that there is no dedicated physical StackCheck to deoptimize into. For more context: the physical StackCheck bytecode was removed in crrev.com/c/1914218. FE stack checks solve this by using a marker bailout id to signify a deopt bytecode offset before the first bytecode. In this CL, OE stack checks take a similar approach by using the OSR'd loop's JumpLoop bytecode, which is conceptually immediately before the OSR'd loop header. When a stack overflow at an OE stack check occurs: %StackGuard may cause a lazy deopt on return to the optimized OSR code, causing re-execution of the JumpLoop handler in the InterpreterEnterBytecodeAdvance builtin, ultimately continuing execution the interpreter at the first bytecode of the OSR'd loop header. Bug: chromium:1034322, v8:9534 Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Milad Fa authored
Bug: v8:10972 Change-Id: I76d795c1f4cf0fc39ca4b4f4ea72c8e817c17da5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632699Reviewed-by:
-
Sathya Gunasekaran authored
There's no need for these extra protector checks as the actual checks are now fast -- we don't have to compare against function objects in every context but instead just do a very quick instance type check. Bug: v8:11256 Change-Id: I40cdf40c8c85e39354bcbd32a7808cd083c8e45b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2598586 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
-
Andreas Haas authored
R=clemensb@chromium.org Bug: v8:11319 Change-Id: If24b1ba929bce2e4268a794930c325aaebcfa556 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637222Reviewed-by:
-
Ross McIlroy authored
If a register is used for both input and output by a SAME_INPUT_OUTPUT operand, then it represents a different virtual register for the end use-position of an instruction (since that will become the output's virtual register). It therefore can't be used to represent the input virtual register for any input operands that are USED_AT_END. BUG=chromium:1163715,v8:9684 Change-Id: I8dc0008ba81d5f1d0e38091b6dc013725c62b1b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632700Reviewed-by:
-
Z Nguyen-Huu authored
Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI Modify that C++ backend so that it can emit either runtime C++ or postmortem debugging code. When in postmortem debugging mode, the overall code structure would look similar with some difference: 1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor. 2. Instead of runtime class names like String, we use uintptr_t 3. When loading data from objects, instead of TaggedField<T>::load or Object::ReadField (which read from the current process), we use the MemoryAccessor and read data from the debuggee process. 4. Return values should be wrapped in the Value struct. Implement the debug accessors for complex length expressions and add test for such class (SmallOrderedHashSet). Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72148}
-
Paolo Severini authored
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 > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#71824} Bug: v8:11092 Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72147}
-
Sathya Gunasekaran authored
This will allow us optimize the protector cell checks in the fast path from checking against the function object in every context to just doing a range check against the instance type. This patch adds new instance types for constructor functions that require such protector cell checks. Bug: v8:11256 Change-Id: Iea722f9c6326dfa470149dd02e689a23942097f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595442Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
-
Jakob Gruber authored
StateValuesAccess iterates over actual (non-adapted) arguments, thus we must be careful not to iterate past their end when handling rest args and advancing through the initial non-rest-args. Tbr: neis@chromium.org Bug: chromium:1167709,chromium:1166136 Change-Id: If506050a5518f394e0dcdbf39840b99923d4cbae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637213 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
