- 12 Aug, 2019 27 commits
-
-
Ross McIlroy authored
Also adds a NullContextScope for code which wants to ensure it is context independent. Removes a workaround in V8ProfilerAgentImpl::startProfiling which created a context due to CollectSourcePositions not being context indpendent. BUG=chromium:992063 Change-Id: I94c7eea6416dc64bc61fb8ff9cd945449a791a77 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748693 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63176}
-
Ross McIlroy authored
This requires a native context which might not be available when collecting source positions, and errors are cleared in any case. BUG=chromium:992063 Change-Id: Ie0b81f60debaaf9a7810a42f56de0c005a7fbe18 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745338 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63175}
-
Ross McIlroy authored
Create canonical ScopeInfos for the global this binding and empty function in the read only space, rather than creating them during bootstrapping for each native context. This saves some memory, and also means we don't need to access the native context to get the global this binding in when deserializing a scope info, which is important since parsing should be native context independent. BUG=chromium:992063 Change-Id: I800f576e8e9b95d46e043cba0c1a03ae19a683c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748690 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Mike Stanton authored
The BytecodeGraphBuilder still looks at the heap. This CL mostly eliminates heap lookups for: * CreateArrayLiteral * CreateObjectLiteral * CreateRegExpLiteral What remains is the lookup embedded in the creation of a VectorSlotPair, which will be addressed in a subsequent change. Bug: v8:7790 Change-Id: I5e4167f5542b84ed3684ad61f3dd1ef8ad84c96b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745482 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63173}
-
Zhi An Ng authored
This reverts commit 7cefcded. Reason for revert: ubsan failures, see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/7465 Original change's description: > Implement F64x2Div for x64 > > Bug: v8:8460 > Change-Id: I78cb2badab3f28621f91d6ff5f455967fdcbee44 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731782 > Reviewed-by: Bill Budge <bbudge@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63171} TBR=bbudge@chromium.org,mstarzinger@chromium.org,gdeepti@chromium.org,zhin@chromium.org Change-Id: I17db933763ba966a2d3f8be58e586b6a61f7995e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8460 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1749712Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#63172}
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: I78cb2badab3f28621f91d6ff5f455967fdcbee44 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731782Reviewed-by:
Bill Budge <bbudge@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#63171}
-
Z Nguyen-Huu authored
Bug: v8:8996 Change-Id: Ie21bf5b695370a89a2f1023cc14db8b7ff1a141e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1744641 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63170}
-
Mike Stanton authored
This CL eliminates managed heap reads from the ByteCodeGraphBuilder from constants. These reads and serializations are made at serialization time. Bug: v8:7790 Change-Id: I5c59ea1f097d11f48994f41ac296cfc64121db25 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746477 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
We were only considering eliminating Stores of size Tagged. There doesn't appear to be a reason why. This CL enables store store elimination for all sizes. For example, in pointer compression, it means that Compressed values can be targeted. In 32 bit versions, it means that doubles can now be targeted. This is safe under the assumption that every byte of a JS object is only ever accessed through one offset. For instance, byte 15 of a given object may be accessed using a two-byte read at offset 14, or a four-byte read at offset 12, but never both in the same program. Change-Id: I865d412ed5b4db53a0154cf4da6303c407fdbda7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746469Reviewed-by:
-
Milad Farazmand authored
Port 0aa204fe Original Commit Message: This CL unifies how stack checks are handled in the Turbofan pipeline across architectures, in preparation for properly handling stack overflows caused by deoptimization in follow-up work. It will also open up possibilities to simplify related logic. How this used to work: JSStackCheck was lowered to a UintLessThan with the stack pointer (sp) and stack limit as inputs. On x64 and ia32, this node pattern was later recognized during instruction selection and rewritten to dedicated operators. On other platforms, including arm and arm64, special logic exists to avoid useless register-to-register moves when accessing the sp. This CL introduces a new StackPointerGreaterThan operator, which takes the stack limit as its sole input. This is what JSStackCheck now lowers to. This is threaded through to code generation, where we emit the appropriate code (in the future, we will apply an additional offset to the sp here). In follow-up CLs, we can remove or replace remaining uses of LoadStackPointer in CSA, Wasm, and the interpreter; and then remove the LoadStackPointer operator, related node matchers, related register constraints, and the pseudo-smi stack limit roots. R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I175c110d30190bb543001b6fa77cd65cf22e5874 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748002Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#63167}
-
Jakob Gruber authored
Now that all uses of LoadStackPointer have been removed, this CL cleans up related code: - Removed LoadStackPointer. - Removed ArchStackPointer. - Removed IA32StackCheck. - Removed X64StackCheck. - Removed StackCheckMatcher. All stack checks now follow a simple path without matchers or special register constraints: they load the limit and pass it to StackPointerGreaterThan, which is finally handled by code generation. Bug: v8:9534 Change-Id: Ib1d7be1502a471541d6441f3261aac0c949525fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748737 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Jakob Gruber authored
The matcher used to be needed to avoid first moving rsp to an allocated register for LoadStackPointer. This is no longer the case with the new stack check structure based on StackPointerGreaterThan. This CL updates the wasm stack check and removes now-unneeded matchers. The generated stack check code remains unchanged from before: // Load the stack limit through the instance then compare against rsp. REX.W movq rcx,[rbp-0x10] REX.W movq rcx,[rcx+0x2f] REX.W cmpq rsp,[rcx] // And on ia32: mov ecx,[ebp-0x8] mov ecx,[ecx+0x17] cmp esp,[ecx] Bug: v8:9534 Change-Id: I9240ad922d19d498a2661c143b12d629ac14d093 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748733 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Jakob Gruber authored
This removes LoadStackPointer and its last remaining use in the interpreter assembler. Bug: v8:9534 Change-Id: I19aafb12c5fd50248841a3d92448e64243c723ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748729 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Jakob Gruber authored
CSA's stack checks (in CodeStubAssembler::PerformStackCheck) were previously carefully crafted to hit the stack check node pattern matchers later on during instruction selection (see StackCheckMatcher). This brittle mechanism is no longer needed now that stack checks use the new StackPointerGreaterThan machine operator. Bug: v8:9534 Change-Id: Idca169df1cadc6db237a8d36883ec1a79418f288 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748728 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Jakob Kummerow authored
Change-Id: I144217abfdcb16e4b9e90e5729fe0aa389945dfb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748691Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#63162}
-
Yang Guo authored
We assume that during bootstrapping, we won't create script contexts. This is wrong, since JavaScript code in extensions may introduce let/const variables. R=jgruber@chromium.org Change-Id: I02595abdbb65f41faffc90bde142849bbde6b554 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666994 Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by:
-
Jakob Gruber authored
IsolateData guarantees a fixed root-relative offset for its contents, thus allowing more efficient code generation for accesses to these addresses. The stack limit, located within the StackGuard, is used by all stack checks in CSA. This CL moves the StackGuard inside IsolateData to make such efficient loads of the limit possible. Bug: v8:9595,v8:9534 Change-Id: I9abe26b88952709c88bf625cc6c028497815a58c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741648Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63160}
-
Yang Guo authored
R=machenbach@chromium.org Bug: chromium:992584 Change-Id: I301013731a502689f2edd5c90e5e7bf2136198c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745337Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63159}
-
Jakob Gruber authored
Turbofan applies the following optimization to external reference loads on arm64 and x64: if the root-relative offset to an external reference's address is known to be constant (and the root register has been initialized), calculate the external reference as |kRootRegister + <offset>| instead of loading it from the external reference table. There are two main cases to consider: 1. External references to arbitrary addresses in the native address space, e.g. libc_memcpy. These kinds of external references have a fixed address within the same running process, but may (and likely will) change between processes (e.g.: mksnapshot and later chromium), and the root-relative offset is different for each Isolate within the same process. These kinds of external references can be optimized as above when *not* generating code which will later be serialized, and *not* generating isolate-independent code. 2. External references to addresses within the fixed-size region of the Isolate (essentially: within IsolateData). Since these move with the Isolate, their root-relative offset is guaranteed to be constant at all times. The optimization can always be applied to these cases as long as the root register has been initialized. Prior to this CL, we only recognized and optimized for case 1. This CL additionally adds support for 2. An example of improved code generated due to this CL: Before: // r13 is the kRootRegister on x64. // 0x3010 is the root-relative offset to Isolate::context_address. leaq rdx, [r13+0x3010] movq r8, [rdx] After: movq rdx, [r13+0x3010] Bug: v8:9534 Change-Id: Idfcca751e98a56c0e5ead2c701c12a677df75399 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748727 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Jakob Gruber authored
This adds two helper functions in code-generator-{ia32,x64}: - HasAddressingMode: is the addressing mode not equal to kNone? - HasRegisterInput: is the specified input in a register? Bug: v8:9534 Change-Id: I690ee52e247b347a7ef5ba0c98bba47c321ca6b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748726 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: -
Jakob Gruber authored
This CL unifies how stack checks are handled in the Turbofan pipeline across architectures, in preparation for properly handling stack overflows caused by deoptimization in follow-up work. It will also open up possibilities to simplify related logic. How this used to work: JSStackCheck was lowered to a UintLessThan with the stack pointer (sp) and stack limit as inputs. On x64 and ia32, this node pattern was later recognized during instruction selection and rewritten to dedicated operators. On other platforms, including arm and arm64, special logic exists to avoid useless register-to-register moves when accessing the sp. This CL introduces a new StackPointerGreaterThan operator, which takes the stack limit as its sole input. This is what JSStackCheck now lowers to. This is threaded through to code generation, where we emit the appropriate code (in the future, we will apply an additional offset to the sp here). In follow-up CLs, we can remove or replace remaining uses of LoadStackPointer in CSA, Wasm, and the interpreter; and then remove the LoadStackPointer operator, related node matchers, related register constraints, and the pseudo-smi stack limit roots. Bug: v8:9534 Change-Id: I0e3f1beeed65b163c4ee5787600bed8c3cc671e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738863Reviewed-by:
-
Mathias Bynens authored
Bug: v8:7834 Change-Id: I23d8d6f4b2d00f82f11615c5a17d29b24fdf3175 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748730 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
We weren't fully using InsertChangeCompressedToTagged and similar, which in turn made it so that we were using more NewNode. This CL unifies the way that we generate the insertion of Change nodes regarding decompressions. Dribe-by fix: make InsertChangeCompressedPointerToTaggedPointer actually use Pointer. Bug: v8:7703 Change-Id: I1d8835a54914cdab93f652ff17e39e8271a585df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741661Reviewed-by:
-
Santiago Aboy Solanes authored
The Osr context is a pointer, and we can make it clear in the Typer. Known pitfall: If we have a context within a context, the innner context pointer is typed as Any. Change-Id: Ia4d7e43ef42ef03f835e4b71d32d117ae835feee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741659Reviewed-by:
-
Tobias Tebbi authored
Bug: chromium:992783 Change-Id: I54ac01dfaa6717a2600cf40af95d6e74872ad2b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748731Reviewed-by:
Tamer Tas <tmrts@chromium.org> Commit-Queue: Tamer Tas <tmrts@chromium.org> Cr-Commit-Position: refs/heads/master@{#63152}
-
Ross McIlroy authored
We have already parsed a function when we call CollectSourcePositions, so we shouldn't update the parsing statistics again otherwise we will double-count. Also, CollectSourcePositions needs to be made native-context independent, and Blink's CountUsage counter requires a context to have been entered when it is called and so isn't context independent. BUG=chromium:992063 Change-Id: Idda50b98a8308f022cb90e1a18afb43982e95298 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746472 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Ana Peško authored
This CL implements a naive tiering-up strategy where the interpreter is used for the first execution for every regex, and the compiler is used for every execution after that. The only exception is if a global replace is being executed on a regex, we eagerly tier-up to native code right away. To use the tier-up logic --regexp-tier-up needs to be set. It is currently disabled by default. Bug v8:9566 Change-Id: Ib64ed77cbfcde10411161c0541dfa2501a0a93bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710661Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
- 09 Aug, 2019 13 commits
-
-
Ross McIlroy authored
We might have to collect source positions for existing functions when we start profiling, and doing so requires a context to be entered in V8. Ensure we always enter a context by creating a temporary context and entering it before starting profiling. BUG=chromium:992063 Change-Id: I72b259a3ad31b712b0475f7729fb4ffdab5cdd96 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745481 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
This reverts commit d1a4706a. Reason for revert: Experiment over. Original change's description: > Reland "[ptr-compr][arm64] Temporarily enable pointer compression on arm64" > > This is a reland of f5611402 > > Original change's description: > > [ptr-compr][arm64] Temporarily enable pointer compression on arm64 > > > > ... and make sure that the arm64 ptr-compr bots proceed testing V8 without > > pointer compression in order to keep testing the other config. > > > > Commented out the 'extra' variant since it was crashing. Opened a bug > > regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568 > > > > Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654 > > > > Bug: v8:7703 > > Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216 > > Reviewed-by: Tamer Tas <tmrts@chromium.org> > > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#63019} > > Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng > Bug: v8:7703 > Change-Id: I1a82b87bf6db4e6d100aeffc29dae60ba73d8119 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730998 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63043} TBR=machenbach@chromium.org,tmrts@chromium.org,solanes@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7703 Change-Id: I86a801d44ad4ea14b1388ad8ca6109cc8a57a7d7 Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746470Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#63148}
-
Jakob Kummerow authored
This contains the following upstream commits: 486d3fe: Rename DEBUG to WASM_API_DEBUG 8d8e37d: Explicitly number wasm_valkind_t 299ebe0: Fix underlying types for enums 70be7c6: Fix test Change-Id: I692fb6c909e5211920438740d2c57ea7ee74ab12 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745483Reviewed-by:
-
Mike Stanton authored
The BytecodeGraphBuilder still looks at the heap. This CL completely eliminates heap lookups for: * CreateBlockContext * CreateFunctionContext * CreateEvalContext * CreateCatchContext * CreateWithContext Bug: v8:7790 Change-Id: I8b88215ba14a11955729b33bd0ee57219719666d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745484 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
Joey Gouly authored
The operator== in RegisterBase only compares the reg_code. On arm64 we have another 'base', CPURegister. Before this change, registers from different classes but with the same register number would compare as equal. For example, x30 == d30 would be true, which is incorrect. Change-Id: I8f19139df3f041b07bfa0883ec5ca768ef540802 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745475Reviewed-by:
-
Yang Guo authored
R=szuend@chromium.org Bug: chromium:991217 Change-Id: Icf4d5522fe2a1d2400e6dd33744d6a60ab4e634c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745469 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#63144}
-
Santiago Aboy Solanes authored
Some of the Float(32|64) to CompressedSigned cases had their functions defined already so they are virtually free to implement. We are still missing the unsigned case so I am keeping the TODO. Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng Bug: v8:7703 Change-Id: Ibf40d5948226fd48aebe7f8e257c117d6a5ad478 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708483Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#63143}
-
Mythri A authored
Change-Id: I086c23a1aea8a3f8ff9d7e79ea73a69461366a8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743968 Auto-Submit: Mythri Alle <mythria@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63142}
-
Santiago Aboy Solanes authored
Bug: v8:9396 Change-Id: Ic5082b91cc61a286bd6a440009bf18202e853339 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730997Reviewed-by:
-
Michael Lippautz authored
- Adds regular native heap entries to the HeapObjectsMap. - Adds a side map for keeping a mapping of native objects to their canonical heap entry that they have been merged into. Change-Id: Ida00628126ded1948ceb2a0cbe14da817af7f361 Bug: chromium:988350 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720810 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63140}
-
Swapnil Gaikwad authored
This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
This is a reland of 11524453 Original change's description: > [wasm] Test concurrent code emission > > This extends the jump table stress test. Currently, we generate > different thunks (on the main thread) and then concurrently update the > jump table to jump to one of these thunks. > With this CL, we also generate the thunks concurrently. So this also > tests whether there is proper synchronization between code generation > and executing it in another thread. > > R=ahaas@chromium.org, mstarzinger@chromium.org > > Bug: v8:9477 > Change-Id: I3598329e37482ebd27a13acc752581c714226184 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735319 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63097} Bug: v8:9477 Change-Id: Iac696f1ff3cd5209231a8dd8d1500cf77c2777b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739370 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
This adds some documentation why concurrently emitting code, patching the jump table, and executing the jump table is safe. R=ahaas@chromium.org CC=mstarzinger@chromium.org, joey.gouly@arm.com Bug: v8:9477 Change-Id: Ibe295d538a1a330c6b1d94eb1f514d1078020754 No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738856 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
