- 13 Aug, 2019 19 commits
-
-
Patrick Thier authored
When GC triggered while an exception is pending, a read to memory that was no longer valid could happen while backtracking in the regexp interpreter (introduced with commit fb0df2c8). This CL prevents this dirty read, that could have been a security issue. Bug: chromium:992389, v8:9575 Change-Id: Ie1acd6faa16665e211666c6a8dcf2a9d74e0c886 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751342 Commit-Queue: Patrick Thier <pthier@google.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63195}
-
Milad Farazmand authored
Port c4d31fea Original Commit Message: Stack limits were additionally maintained in pseudo-smi roots. "Pseudo", because we stored the raw limit pointers there, just making sure their values looked like smis by masking the least significant bits. This mechanism is no longer needed now that we can access the stack limit external references as efficiently as the smi roots. R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ida5c1fe10a494e9c6d665425bd464228978ecd1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752142Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#63194}
-
Milad Farazmand authored
Change-Id: If917f11f72d08e237fcb4ee43fabfc0c133dace6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752143Reviewed-by:
-
Ross McIlroy authored
Previously we only used this flag if asm_wasm instantiation failed, but we should avoid trying asm_wasm again if we failed during the initial parse/compile, in case we have to recompile due to bytecode flushing. This also avoids issues if there is a tranisent reason we fail asm_wasm compilation (e.g., stack overflow) and later recompilations succeed and cause inconsistencies like in the linked bug. BUG=chromium:991133 Change-Id: Id156efa9d8625ce3db2058cb279ea23aeb66052f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751784Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63192}
-
Santiago Aboy Solanes authored
We were going for 64 bits to go back to 32 bits. For example, TruncateInt64ToInt32(BitcastTaggedSignedToWord(ChangeCompressedToTagged(x))) when that doesn't modify the value at all. In order to keep the machine graph verifier happy two bitcast operations were introduced. As a drive-by nit cleanup, we were having two empty lines between some functions implementations in machine-operator-reducer.cc. Bug: v8:7703 Change-Id: Ifaa0d656010fe4f6f6f4581a2bb6633f060245b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1749383 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63191}
-
Ross McIlroy authored
When a RelocatingCharacterStream is Seeked, it's buffer_pos_ could be set a non-zero value. However, UpdateBufferPointers was assuming the position was zero to relocate the buffer_start_ and buffer_end_, which would lead to the stream becoming misaligned. Fix this and add a unittest and the clusterfuzz script which highlighted the issue. BUG=chromium:991133 Change-Id: I20dd510b3dcc5df6df058b7e06d2c8a838aef855 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751782Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63190}
-
cjihrig authored
Update postmortem metadata constants for V8 7.4 in Node.js. Change-Id: I7d248b345e0326dafb776e144a6a22a381a05fc1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1546049 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63189}
-
Michael Starzinger authored
This makes sure that the above predicate is independent of any global process-wide state. The state of enabled features is now passed in explicitly. R=thibaudm@chromium.org Change-Id: I5d44e2b0c0843d2e4f26aaf0d58d23afd5943726 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751348Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63188}
-
Jakob Gruber authored
In generated code, we access fields inside IsolateData through the root-register. On some platforms it is significantly cheaper to access things that are close to the root-register value than things that are located far away. The motivation for this CL was a 5% difference in Octane/Mandreel scores between // Part of the stack check. cmpq rsp,[r13+0x9ea8] and cmpq rsp,[r13-0x30] // Mandreel score improved by 5%. This moves the StackGuard up to fix Mandreel. As a drive-by, also move two more fields up that are accessed by each CallCFunction. Tbr: yangguo@chromium.org Bug: v8:9534,chromium:993264 Change-Id: I5418b63d40274a138e285fa3c99b96e33a814fb1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751345Reviewed-by:
-
Jakob Gruber authored
This reverts commit 47e077a2. Reason for revert: To avoid hard crashes on this CHECK until a proper fix has landed. Original change's description: > [deoptimizer] Check whether output frames fit into stack space > > Change-Id: I7af0fe843f73b702b03ffa50ecca19aabd7583b8 > Bug: chromium:983850 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701858 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62738} TBR=neis@chromium.org,sigurds@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:983850,chromium:987930,v8:9534 Change-Id: I1f1fe76c957e1f1cf2a117a5ddc7e62004497aeb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741665Reviewed-by:
-
Santiago Aboy Solanes authored
We were doing the SmiCheck in Compressed, but then using the Tagged one to go to Int32. Bug: v8:7703 Change-Id: Ib65084590eb611f9abea9383ee307d21959caa21 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748698Reviewed-by:
-
Milad Farazmand authored
Port 5b2ab2f6 Original Commit Message: 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. R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I68a66054dc1422e7fc0598ef4d112a031ba94cc1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1750223Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
-
Jakob Gruber authored
Stack limits were additionally maintained in pseudo-smi roots. "Pseudo", because we stored the raw limit pointers there, just making sure their values looked like smis by masking the least significant bits. This mechanism is no longer needed now that we can access the stack limit external references as efficiently as the smi roots. Bug: v8:9534 Change-Id: I37e78851c97aebc1012ea0e95075e56366a40a73 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745339 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Mathias Bynens authored
Bug: v8:7834 Change-Id: I739ceb9668732e382cedca4d1f61a1ccc0339f35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751344 Commit-Queue: Mathias Bynens <mathias@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Auto-Submit: Mathias Bynens <mathias@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
Bug: chromium:982969, chromium:983267 Change-Id: I8700a21020bc63caf537ca9f70f200eebde23dee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1749902 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Georg Neis authored
R=mvstanton@chromium.org Bug: chromium:992684, v8:7790 Change-Id: Ia5e77873f4b96d9f6d9a1468a83a64206f1498ee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748692Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63180}
-
Jakob Gruber authored
Previously these were called (real) stack limit on one end, (real) jslimit on the other. With this CL we consistently use jslimit everywhere. Tbr: tebbi@chromium.org Bug: v8:9534 Change-Id: I9f86ac113bb9682544c365d54f666c1312a073a6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748738 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/f3d0ca5..b5e8d0f Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/30604c6..1c632e3 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/1b4c7e9..3c81495 Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/682a230..9a5af81 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/3605577..a05d5ea TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: If39dec909344727bd2d2aa0f3ce7dfb64205f460 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1750585Reviewed-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@{#63178}
-
Irina Yatsenko authored
This allows us to keep v8 free of the dependency on the crash/base components. Second half of the change: https://chromium-review.googlesource.com/c/chromium/src/+/1690003. Bug: v8:9323 Change-Id: If35288e3916df951ae6e2ae39e1cb06fab5fbf8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699102 Commit-Queue: Irina Yatsenko <irinayat@microsoft.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#63177}
-
- 12 Aug, 2019 21 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:
-
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:
-
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:
-
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:
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:
-
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:
-
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:
-
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:
-
