- 12 Mar, 2020 16 commits
-
-
Andreas Haas authored
On Windows in an asan build we have to reset the thread-in-wasm flag in the memory_init_wrapper, memory_copy_wrapper, and memory_fill_wrapper. Accidentally I removed this code for the memory_init_wrapper and the memory_copy_wrapper recently. This CL introduces the code again. R=clemensb@chromium.org Bug: v8:10281 Change-Id: If46def5cd64ac8cbff9b86108189462717961edd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098737Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#66686}
-
Andreas Haas authored
x64's cmpxchgl instruction does not zero-extend the register. The stale high word caused the difference in the results of the interpreter and Liftoff/TurboFan. R=clemensb@chromium.org CC=zhin@chromium.org Bug: chromium:1059529 Change-Id: I0fd440bee26e25b90b29533cfa9151e4d87754e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098726 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66685}
-
Georg Neis authored
... such that we have only a single representation for special constants such as undefined, namely the corresponding bitset. With this CL the following property holds: t1.IsSingleton() /\ t2.Is(t1) => t1.Is(t2) Also clean up the Type interface and improve test coverage a little. Change-Id: I074e20047c92e2c8215c2d438f2627f4ffdbc409 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096631 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66684}
-
Mike Stanton authored
In typed lowering, if our target is a CheckClosure or a CreateClosure node, we can extract a SharedFunctionInfo from the opcodes parameters in order to make calls a bit more efficient. Change-Id: Ib06dea2e8505bfeb984c4cefd5ad1bed0defa5f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087402 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66683}
-
Andreas Haas authored
R=clemensb@chromium.org Bug: v8:10281 Change-Id: I321e65f42fd68a3451b49881b04bfb38dd7ff8ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091469 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Steve Blackburn authored
Bug: v8:9533 Change-Id: Ida93a4a6dd5d25e78bb2bc113b869bc01cd7a650 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043808 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66681}
-
Georg Neis authored
Change-Id: I0dc2a198c412723933cb1bc259423ff241612fcc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098731 Commit-Queue: Georg Neis <neis@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#66680}
-
Leszek Swirski authored
The interpreter's finalization was accidentally double-counting compile finalizations, which manifested as a Compile count increase. As a side effect, this would also miscount off-thread finalizations as main-thread finalizations -- not a problem yet, but would be one in the future. Bug: chromium:1011762 Bug: chromium:1060927 Change-Id: I37232bbd46c8cba80c0b413638f43d83d5313e70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098727 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Some Scope methods were unnecessarily taking a ParseInfo, or using only a single field from it. We can avoid passing around ParseInfo in these cases, which will make splitting/removing it easier in the future. Bug: v8:10314 Change-Id: I5c60783d27581c4f7d8c709314bbfc72ac5bd0f6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096630 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66678}
-
Zhao Jiazhong authored
Port 485e66ba https://crrev.com/c/2094198 Change-Id: I4e3ce2a70f2ccf4e95b0fa69834522d988e00f9b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097895Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Iain Ireland authored
This is a grab-bag of small compatibility fixes to make it easier to import irregexp into SpiderMonkey. For changes where the commit message was longer than the change itself, it didn't seem worth opening a separate review. [regexp] Use uc16 in FilterOneByte SpiderMonkey uses char16_t instead of uint16_t for its two-byte strings. (This matches ICU. It looks like V8 considered making the same change, but decided against it: see https://bugs.chromium.org/p/v8/issues/detail?id=6487.) Fortunately, irregexp is careful about only using uc16, so SpiderMonkey can just define uc16 = char16_t and *almost* everything works out. This patch fixes the single place in irregexp where that is not true. [regexp] Remove unreachable return The return statement at the end of RegExpParser::ParseClassCharacterEscape is unreachable, because every branch of the switch returns. This triggered static analysis errors in SpiderMonkey. [regexp] Remove trivial assertion The assertion in BytecodeSequenceNode::ArgumentMapping cannot fail, because size_t is an unsigned type. This triggered static analysis warnings in SpiderMonkey. [regexp] Make RegExpStack constructor public In V8, the RegExpStack's private constructor is called from Isolate, which is a friend class. In SpiderMonkey, we use a wrapper around new to control where memory is allocated, so we need the RegExpStack constructor to be visible outside of Isolate. [regexp] Refactor Isolate::IncreaseTotalRegexpCodeGenerated The call-site of Isolate::IncreaseTotalRegexpCodeGenerated is the only place inside irregexp where HeapObject::Size is called. SpiderMonkey's heap-allocated objects live in arenas, and don't have a standardized way of finding the size. In this particular case it would be safe to hardcode a size of 0, but leaving HeapObject::Size undefined will ensure that SpiderMonkey doesn't silently do the wrong thing if somebody in V8 adds a new, more meaningful call to HeapObject::Size. R=jgruber@chromium.org Bug: v8:10303 Change-Id: I5b81e1a261fec8c85a63f71f34cd12d68f638334 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090191 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Andreas Haas authored
R=clemensb@chromium.org Bug: v8:10281 Change-Id: Icf7f8138d0acc172da6ff31935e50de3e4c79e10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096622Reviewed-by:
-
Iain Ireland authored
For a variety of reasons related to OOM handling and custom allocators, SpiderMonkey wants to be able to see all memory allocations. To enforce this, we have a static analysis that verifies that we don't link in malloc/new/etc in unexpected places. One consequence of this is that we can't use STL containers without a custom allocator, because they call operator new internally. This is mostly not an issue in irregexp, which makes heavy use of zone allocation. The main exceptions are a handful of uses of std::vector in regexp-compiler.* and regexp-parser.*. If these vectors are converted to ZoneVectors, then our static analysis is satisfied. R=jgruber@chromium.org Bug: v8:10303 Change-Id: I8b14a2eb54d3b20959e3fbe878f77effae124a2c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091402Reviewed-by:
-
Iain Ireland authored
Unlike the other RegExpTree types, RegExpCapture and RegExpGroup don't cache their min/maxMatch value. Instead, they compute it by recursing on the min/maxMatch of the body node. In pathological cases, with sufficiently small stacks, this can cause stack overflow. (In SpiderMonkey's case, it was a worker on 32-bit x86.) It's easy enough to just precompute the value when the body is set. R=jgruber@chromium.org Bug: v8:10303 Change-Id: I4ba3d301d9a4a3f3c0cb94966148b747a4092d26 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090192 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Iain Ireland authored
TextEmitPass uses a function pointer to determine which pass to call. This function pointer is only assigned inside TextEmitPass, and can easily be eliminated by moving the calls to each possible target inside the switch statement that assigns the function pointer. I made this change because SpiderMonkey uses a static analysis pass to verify that everything is rooted properly across calls that might GC, and that analysis is conservative when calling function pointers. We can white-list function pointers that are known to be safe, but the code being called through this function pointer is complex enough (and the function pointer is unnecessary enough) that it seemed best to just remove the function pointer entirely. R=jgruber@chromium.org Bug: v8:10303 Change-Id: I5fbb0df290a2288c4d3db6d43a563385337162ea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091398 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/3e21004..8a766f0 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a8e510a..786ed18 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/552ddbf..1ee78cd Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/0a95832..ca7cd9b TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I48f6192edf8a261dce59069cdf3aec227fe3875a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2099004Reviewed-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@{#66671}
-
- 11 Mar, 2020 18 commits
-
-
Andreas Haas authored
The return value of {memory_init_wrapper} was defined as {bool} in the original CL. When compiled with clang, the full return register is written when {true} or {false} is returned. With msvc, however, the return value is written as a single byte, without zero-extension. In generated code, the full return register is used and therefore stale bytes in the return register caused problems. With this CL the return value is changed to {uint32_t}. This enforces zero-extension of the return value and thereby fixes the issue. R=clemensb@chromium.org Bug: v8:10281 Change-Id: I1446e51d88a35def56bd39a8336baa81543497bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096627 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: -
Z Nguyen-Huu authored
Bug: v8:10242 Change-Id: Ie6583fe819de94185826dfd6a1b11870800847c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098216 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#66669}
-
Santiago Aboy Solanes authored
This CL is a step towards making StackChecks implicit. In a follow-up CL said StackChecks will become implicit within JumpLoops. Cq-Include-Trybots: luci.chromium.try:linux-rel Bug: v8:10149, v8:9960 Change-Id: I5ae247be3f7a58ccdf86398cace30724715767a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062391 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66668}
-
Z Nguyen-Huu authored
We want to be consistent with wasdk/wasmparser. Unnamed function's name would be func# Doc: https://docs.google.com/document/d/1XoXWONLBgZWQ9dhtoMpQPvD0fnnWA50OorsuSXfME3g Bug: v8:10242 Change-Id: I12222eef38a57242e9f606007d0ffa76b8e2a4af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084052 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
-
Andreas Haas authored
The return value of {memory_copy_wrapper} was defined as {bool} in the original CL. When compiled with clang, the full return register is written when {true} or {false} is returned. With msvc, however, the return value is written as a single byte, without zero-extension. In generated code, the full return register is used and therefore stale bytes in the return register caused problems. With this CL the return value is changed to {uint32_t}. This enforces zero-extension of the return value and thereby fixes the issue. R=clemensb@chromium.org Bug: v8:10281 Change-Id: I628d01cfd7193fa960a7ccdf0d9fd896f510cd3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096626 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: -
Milad Farazmand authored
Change-Id: I88c43793b82256e9f37ffd54468fd0374fedd164 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097025Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66665}
-
Jakob Kummerow authored
Because run-tests.py still requires it. No-try: true Change-Id: Ief1f3d7a93ba4c36232420ee9ab0a4ff3ea6739b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096628 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#66664}
-
Dominik Inführ authored
Instead of directly using the Heap class concurrent threads will use the LocalHeap class for all heap operations. Bug: v8:10315 Change-Id: Ie007abb5b914af7f2507c9e790f34baacbcdf588 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096620 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port 485e66ba R=fanchen.kong@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2e1b79a995661243ff05b3d13e310f6315de0c97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097450Reviewed-by:
-
Matheus Marchini authored
Node.js build fails on VS2017 without these headers, see the downstream issue (https://github.com/nodejs/node-v8/issues/128). Co-authored-by:
Ben Noordhuis <info@bnoordhuis.nl> Co-authored-by:
gengjiawen <technicalcute@gmail.com> Change-Id: I771eab435dce5cf548581f3acd78681180c77692 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093951Reviewed-by:
-
Milad Farazmand authored
Some wasm interpreter tests are failing since instructions generated by gcc such as *multiply and and* create intermediate results bigger than 8 bytes which doesn't match other architectures, hence the resulting output differs. Change-Id: I68cc58d01699bfe93051da693c4b7e819ffcc6eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095613 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
-
Georg Neis authored
Generalize the HeapConstant case to a Singleton case. Change-Id: Ief8c325a4326e02c8c361f3b41fc40ca398167ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096619 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Clemens Backes authored
This reverts commit c475e704. Reason for revert: Fails on MSVC: https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/12805 Original change's description: > [wasm] Do memory.copy bounds check in C++ code > > In the existing implementation we first did a bounds check in generated > code, and then called a simple C++ function to do the actual copying. > With this CL now we pass the WasmInstanceObject to the C++ function in > addition to the memory.copy parameters. Thereby we can do the bounds > check in C++, which is much easier, less error prone, and which also > speeds up code generation and reduces code size. Performance should not > be worse, because we were already doing the call to C++ anyways. > > R=clemensb@chromium.org > > Bug: v8:10281 > Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66655} TBR=ahaas@chromium.org,clemensb@chromium.org Change-Id: Ic2491f635a292e004f6c95498a045ba102138dc5 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10281 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096623 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Clemens Backes authored
This reverts commit c7a26b13. Reason for revert: Need to revert previous CL because it fails on MSVC: https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/12805 Original change's description: > [wasm] Do memory.init bounds check in C++ code > > In the existing implementation we first did a bounds check in generated > code, and then called a simple C++ function to do the actual copying. > With this CL now we pass the WasmInstanceObject to the C++ function in > addition to the memory.init parameters. Thereby we can do the bounds > check in C++, which is much easier, less error prone, and which also > speeds up code generation and reduces code size. Performance should not > be worse, because we were already doing the call to C++ anyways. > > R=clemensb@chromium.org > > Bug: v8:10281 > Change-Id: Ia86e1d08001a8bc7556277abeaa9208ec1128f89 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096621 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66656} TBR=ahaas@chromium.org,clemensb@chromium.org Change-Id: I1064113e7f1c445d04652a973c994317fd3e739a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10281 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096624Reviewed-by:
-
Andreas Haas authored
In the existing implementation we first did a bounds check in generated code, and then called a simple C++ function to do the actual copying. With this CL now we pass the WasmInstanceObject to the C++ function in addition to the memory.init parameters. Thereby we can do the bounds check in C++, which is much easier, less error prone, and which also speeds up code generation and reduces code size. Performance should not be worse, because we were already doing the call to C++ anyways. R=clemensb@chromium.org Bug: v8:10281 Change-Id: Ia86e1d08001a8bc7556277abeaa9208ec1128f89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096621 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Andreas Haas authored
In the existing implementation we first did a bounds check in generated code, and then called a simple C++ function to do the actual copying. With this CL now we pass the WasmInstanceObject to the C++ function in addition to the memory.copy parameters. Thereby we can do the bounds check in C++, which is much easier, less error prone, and which also speeds up code generation and reduces code size. Performance should not be worse, because we were already doing the call to C++ anyways. R=clemensb@chromium.org Bug: v8:10281 Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9b4e026..3e21004 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/abdb603..a8e510a Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/a12175c..552ddbf Rolling v8/tools/luci-go: git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6..git_revision:de73cf6c4bde86f0a9c8d54151b69b0154a398f1 Rolling v8/tools/luci-go: git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6..git_revision:de73cf6c4bde86f0a9c8d54151b69b0154a398f1 Rolling v8/tools/luci-go: git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6..git_revision:de73cf6c4bde86f0a9c8d54151b69b0154a398f1 Rolling v8/tools/swarming_client: https://chromium.googlesource.com/infra/luci/client-py/+log/0ac2847..cc95827 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I59b2eb12c51114c798fbbc9008952952736ebe7a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097639Reviewed-by:
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: I6766c1d0f347f8e0c8dea588e5984eb48ad18d5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2094198Reviewed-by:
-
- 10 Mar, 2020 6 commits
-
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: Ic309d394620ec17791bac2902116e15058b28a68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091634Reviewed-by:
-
Dominik Inführ authored
Report the allocated size of global handles in GetHeapStatistics as well, not including free handles. Bug: chromium:1060192 Change-Id: I1aedba36735f897cd8518edbb5ef2261cc348bff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093493 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Richard Townsend authored
Suffered from a confusion of masm/marmasm syntax for the x64 host and arm64 target (could only generate one syntax or ther other). Fixed by moving the compile-time flag to a runtime one. Bug: v8:10012 Change-Id: I34746a495b1881c1d0465995930979bb768b07e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962854Reviewed-by:
-
Leszek Swirski authored
Rather than having an optional script id during ParseInfo creation (which is either selected lazily on script creation, or eagerly if based on an existing Script), always eagerly get either the desired script id (either from the Script or Isolate::GetNextScriptId()). This has the side-effect that we will currently no longer need to get the script id on background threads, but I'm not reverting the thread-safety of Isolate::GetNextScriptId in case it's needed again in the future. Bug: v8:10314 Change-Id: I8f2dd962d3652b1a84a5d704a099e57a1679aba5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096616 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Previously, ParseInfo would create a script (with CreateScript) based on its flags, and then set its own flags based on that created script. This created a weird circular dependency for some of those flags, and sometimes we would have valid flags before script creation (main thread compile), while other times not (streaming compile). Now we set the ParseInfo flags manually and uniformly before script creation, and check that they match the created script after it has been created. Bug: v8:10314 Change-Id: Ife886c77727cd228c944a4f97369a3e6365d8219 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093433 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Victor Gomes authored
The arguments order in a JS stack is now controlled by V8_REVERSE_JSARGS macro. This CL creates two stubs that allow the order of the arguments to be reversed without changing CallStub. Bug: v8:10201 Change-Id: I8f70adf3ced1f45a00f5c4ddd47d5f604f2d3100 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093506 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
