- 24 Mar, 2021 17 commits
-
-
Andreas Haas authored
LiftoffCompiler::ProcessParameter assumed that by processing parameters in the order of their index, register parameters get processed first, and that for processing stack parameters it can already use all registers as temp registers. This is not true with reference type parameters, because registers always first get assigned to value type parameters even when there is a reference type parameter with a lower index. Because of this incorrect assumption register parameters were overwritten by reference type parameters on the stack that got processed first. With this CL, only those registers get used as temp registers for reference type parameters that are not used for parameters. CC=jkummerow@chromium.org, clemensb@chromium.org R=thibaudm@chromium.org Bug: v8:11596 Change-Id: I30ed7f073147df0bd81b9ef4d2b2a54d7badc937 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784560 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#73635}
-
Milad Fa authored
memcpy might need the above header included to prevent compilation errors on gcc. Change-Id: Idfc901f160e051effb322d7da6ecc682b0fedb11 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2782486Reviewed-by:
-
Andreas Haas authored
By accident a "w"-register was used to push references on the stack instead of an "x"-register. This CL fixes the bug. CC=jkummerow@chromium.org R=thibaudm@chromium.org Bug: v8:11596 Change-Id: I5e0b6bebdc763f8d30fd2891786f6c82b9c1e7ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783038Reviewed-by:
-
Igor Sheludko authored
... of physical memory, since builtins re-embedding comes with a memory overhead. Bug: v8:11527 Change-Id: I24b77c3ab63e1891bd4c6134c3f3456921cc2a01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784564Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#73632}
-
Camillo Bruni authored
- Handle sparkplug code - Handle regexp code-creation events in the tick-processor, which have no valid state marker in the maybe_func data - Remove calls to print() that break the tick-processor web version Change-Id: Ic726d1ae3a41cd46f42cf5498e8463564d3b6b83 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784562Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#73631}
-
Milad Fa authored
This reverts commit 94272ea5. Reason for revert: original port was reverted Original change's description: > PPC/s390: [sparkplug][deoptimizer] Deoptimize to baseline. > > Port bdcd7d79 > > Original Commit Message: > > If we have baseline code, deoptimize to baseline instead of the > interpreter. The process is similar to deopting to the interpreter. > We just use different builtins > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that > patch an interpreter frame to a baseline frame and continue execution in > baseline code (based on the deopt type, at the current or next > bytecode). > > R=pthier@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com > BUG= > LOG=N > > Change-Id: I3230f3f3c6506230b2751a3389f10b022dec61a3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783022 > Reviewed-by: Junliang Yan <junyan@redhat.com> > Commit-Queue: Milad Fa <mfarazma@redhat.com> > Cr-Commit-Position: refs/heads/master@{#73618} Change-Id: I903ad90099c4dc5f153d28aea9246933ac69972b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784002 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#73630}
-
Sathya Gunasekaran authored
This reverts commit bc22fe45. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/b8851879177803719072/overview Original change's description: > Update V8 DEPS. > > Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/b43166a..23310ef > > Rolling v8/buildtools/third_party/libc++abi/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxxabi/+log/4e07843..731dd85 > > Rolling v8/third_party/aemu-linux-x64: osbsa1Jjgk8WbE3Ckv8288sgvejWZeAN8DB42wp0YV8C..oZxl99tyPs7o9Eq0hlPel1m4iyPu1Z92wj2Llb6HWwEC > > Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/e46359d..dbc2c42 > > Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/07f4869..1a8ecf1 > > Rolling v8/third_party/instrumented_libraries: https://chromium.googlesource.com/chromium/src/third_party/instrumented_libraries/+log/0964a78..6900bf4 > > Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:e1c81c53ccd0366e8fff438f89030043343d4d6b > > Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:e1c81c53ccd0366e8fff438f89030043343d4d6b > > Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:e1c81c53ccd0366e8fff438f89030043343d4d6b > > TBR=v8-waterfall-sheriff@grotations.appspotmail.com > > Change-Id: Id531aa3cc66535dacac78b11fcf50b0269e3e71a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2782609 > 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@{#73628} Change-Id: Ie710cc5ad17caf3ec4a5e38a48b938ef64cc1376 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784565 Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#73629}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/b43166a..23310ef Rolling v8/buildtools/third_party/libc++abi/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxxabi/+log/4e07843..731dd85 Rolling v8/third_party/aemu-linux-x64: osbsa1Jjgk8WbE3Ckv8288sgvejWZeAN8DB42wp0YV8C..oZxl99tyPs7o9Eq0hlPel1m4iyPu1Z92wj2Llb6HWwEC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/e46359d..dbc2c42 Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/07f4869..1a8ecf1 Rolling v8/third_party/instrumented_libraries: https://chromium.googlesource.com/chromium/src/third_party/instrumented_libraries/+log/0964a78..6900bf4 Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:e1c81c53ccd0366e8fff438f89030043343d4d6b Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:e1c81c53ccd0366e8fff438f89030043343d4d6b Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:e1c81c53ccd0366e8fff438f89030043343d4d6b TBR=v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Id531aa3cc66535dacac78b11fcf50b0269e3e71a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2782609Reviewed-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@{#73628}
-
Thibaud Michaud authored
Take into account that the implicit rethrow at the end of a try block might unpack the exception values, and reserve enough stack space for them. This is normally done for all throwing opcodes before the switch, but 'end' is not considered a throwing opcode, which is why it needs special handling. Also clean up by factorizing the rethrow logic. R=ahaas@chromium.org Bug: chromium:1186795 Change-Id: I6fde1b88085db95a9cab32c2c8e0ed1d28b64a32 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783024Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#73627}
-
Marja Hölttä authored
It needs to return the ToObject-converted receiver, not the original receiver. Bug: v8:11362 Change-Id: I6404122c91402ea58851238d074951f1b7f2a039 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783036Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#73626}
-
Niek van der Maas authored
toString on JS Proxies are leaking, see this sample code: undefined[Function.prototype.toString] undefined[new Proxy(Function.prototype.toString, {})] This change fixes the behavior. Patch credits to Yusif <yusif.khudhur@gmail.com> Change-Id: Id82a0a5c245469973452a3e6609cb91978274b8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739980 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73625}
-
Mythri A authored
Recently we changed feedback vector allocation to be based on the bytecode size of the function. The threshold at which the feedback vectors are allocated was set to 12 * bytecode size of the function. This caused a couple of regressions on IC:duration and some regressions on other benchmarks. To avoid these regressions this cl reduces the scale factor to 8 instead of 12. Bug: chromium:1187733 Change-Id: I0553d368434499cc52a6e786b5de6d6b954e6546 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778295 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#73624}
-
Omer Katz authored
Every page that can be accessed concurrently during marking needs to be synced to avoid data races with page alloation. TraceTrait for mixins uses the object start bitmap of a page and thus requires a sync. Bug: chromium:10561670 Change-Id: Ia26be973019dcd1d9f7650cc139b16369d515df6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783023Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#73623}
-
Manos Koukoutos authored
We are disabling loop unrolling for wasm until we find a solution to some stability problems. Bug: v8:11298, chromium:1184929 Change-Id: I21c66d37b1606175a5ed44b6db0269651da1f3c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2780298 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#73622}
-
Sathya Gunasekaran authored
This reverts commit bdcd7d79. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux%20Future/7996/blamelist Original change's description: > [sparkplug][deoptimizer] Deoptimize to baseline. > > If we have baseline code, deoptimize to baseline instead of the > interpreter. The process is similar to deopting to the interpreter. > We just use different builtins > (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of > InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that > patch an interpreter frame to a baseline frame and continue execution in > baseline code (based on the deopt type, at the current or next > bytecode). > > Bug: v8:11420 > Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591 > Commit-Queue: Patrick Thier <pthier@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73609} Bug: v8:11420 Change-Id: Ie8b936df343b9194c0a6e50e0c44b67c0d9a012d No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783030 Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#73621}
-
Sathya Gunasekaran authored
This reverts commit 0980c8da. Reason for revert: breaks mac64 Original change's description: > Update V8 DEPS. > > Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/b43166a..cb055e2 > > Rolling v8/buildtools/third_party/libc++abi/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxxabi/+log/4e07843..731dd85 > > Rolling v8/third_party/aemu-linux-x64: osbsa1Jjgk8WbE3Ckv8288sgvejWZeAN8DB42wp0YV8C..oZxl99tyPs7o9Eq0hlPel1m4iyPu1Z92wj2Llb6HWwEC > > Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/e46359d..25699ba > > Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/07f4869..1a8ecf1 > > Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:689d9817823a3bc34ff2b7a3c45c7e6b41a70ca2 > > Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:689d9817823a3bc34ff2b7a3c45c7e6b41a70ca2 > > Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:689d9817823a3bc34ff2b7a3c45c7e6b41a70ca2 > > TBR=v8-waterfall-sheriff@grotations.appspotmail.com > > Change-Id: I099d7793c63d11280691927b559065c96411a697 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2782606 > 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@{#73619} Change-Id: Ia59bf8d0786058114f70381342939fc9d623b7cb No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783029Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#73620}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/b43166a..cb055e2 Rolling v8/buildtools/third_party/libc++abi/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxxabi/+log/4e07843..731dd85 Rolling v8/third_party/aemu-linux-x64: osbsa1Jjgk8WbE3Ckv8288sgvejWZeAN8DB42wp0YV8C..oZxl99tyPs7o9Eq0hlPel1m4iyPu1Z92wj2Llb6HWwEC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/e46359d..25699ba Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/07f4869..1a8ecf1 Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:689d9817823a3bc34ff2b7a3c45c7e6b41a70ca2 Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:689d9817823a3bc34ff2b7a3c45c7e6b41a70ca2 Rolling v8/tools/luci-go: git_revision:edffd3478bb26469c614610d1a1c323b7e798b07..git_revision:689d9817823a3bc34ff2b7a3c45c7e6b41a70ca2 TBR=v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I099d7793c63d11280691927b559065c96411a697 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2782606Reviewed-by:
-
- 23 Mar, 2021 23 commits
-
-
Milad Fa authored
Port bdcd7d79 Original Commit Message: If we have baseline code, deoptimize to baseline instead of the interpreter. The process is similar to deopting to the interpreter. We just use different builtins (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that patch an interpreter frame to a baseline frame and continue execution in baseline code (based on the deopt type, at the current or next bytecode). R=pthier@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: I3230f3f3c6506230b2751a3389f10b022dec61a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783022Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#73618}
-
Frank Emrich authored
This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/2720300. As compared to the original version, it adds --no-stress-flush-bytecode to the const-dict-tracking.js test Original description: This CL is part of a series that implements Turbofan support for property accesses satisfying the following conditions: 1. The holder is a dictionary mode object. 2. The holder is a prototype. 3. The access is a load. This feature will only be enabled if the build flag v8_dict_property_const_tracking is set. This particular CL implements support for the case that the property in question is an accesor, meaning that the given PropertyAccessInfo has kind kAccessorDictionaryProtoConstant. Bug: v8:11248 Change-Id: I896e5dc59821f88abdb7a743e21ca3a700af9db2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2782280Reviewed-by:
-
Santiago Aboy Solanes authored
BUg: v8:6949 Change-Id: If2b144e189812b777dfa90b2ddc48ee525a37856 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778279Reviewed-by:
-
Santiago Aboy Solanes authored
We can keep the non-atomic accessors for read/write since we set the prototype on the map at initialization. Bug: v8:7790, chromium:1150811 Change-Id: Ied7763c87a71c6aa93099dec3405873ab7419643 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773052 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Michaël Zasso authored
Fixes Node.js builds with GCC 8. Change-Id: I3db574b48992f36ba42dec5c21d5c4b55dd7aa19 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2780297 Auto-Submit: Michaël Zasso <mic.besace@gmail.com> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Thibaud Michaud authored
R=ahaas@chromium.org Bug: v8:1189651 Change-Id: Ic414954101f99ac9d51af505f094cb03f0e85d29 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773810Reviewed-by:
-
Nico Hartmann authored
This reverts commit b1883dc3. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/17269/overview Original change's description: > [dict-proto] TF support for constants in dictionary mode protos, pt. 3 > > This CL is part of a series that implements Turbofan support for > property accesses satisfying the following conditions: > 1. The holder is a dictionary mode object. > 2. The holder is a prototype. > 3. The access is a load. > > This feature will only be enabled if the build flag > v8_dict_property_const_tracking is set. > > This particular CL implements support for the case that the property > in question is an accesor, meaning that the given PropertyAccessInfo > has kind kAccessorDictionaryProtoConstant. > > Bug: v8:11248 > Change-Id: Id082107edd45fa91a3f1d96aa9df345a60f46917 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720300 > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Frank Emrich <emrich@google.com> > Cr-Commit-Position: refs/heads/master@{#73607} Bug: v8:11248 Change-Id: Id753354a5ccddd1a05ecf9aec3267f152ef713c5 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2780299Reviewed-by:
-
Clemens Backes authored
The most common case is still one of the unconditionally supported (MVP) types. Hence avoid the switch and the flags / CPU features lookup in the hot function, and offload that to a rarely called function. The fast path is now just a bit check via an EnumSet. R=thibaudm@chromium.org Change-Id: I0cee94640bcc0e5e0fa636e23eb0ba5460d8b8fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778271Reviewed-by:
-
Jakob Kummerow authored
This is a reland of c4b44d5d Original change's description: > [bigint] Begin src/bigint refactoring > > This patch moves a first function, Compare, from src/objects/bigint.cc > to src/bigint/, to blaze the trail. More to follow! > > Bug: v8:11515 > Change-Id: Id7fa0b40ea852dbed1360f7ab439cb32d0c15762 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2737295 > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73511} Bug: v8:11515 Change-Id: I50a81593a8acaa91161bb01a445bddbb8e6315c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773804Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
-
Patrick Thier authored
If we have baseline code, deoptimize to baseline instead of the interpreter. The process is similar to deopting to the interpreter. We just use different builtins (BaselineEnterAtBytecode/BaselineEnterAtNextBytecode) instead of InterpreterEnterBytecodeDispatch/InterpreterEnterBytecodeAdvance, that patch an interpreter frame to a baseline frame and continue execution in baseline code (based on the deopt type, at the current or next bytecode). Bug: v8:11420 Change-Id: Iabaefb36c05155a435c7b380906a86d9b9d549fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695591 Commit-Queue: Patrick Thier <pthier@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#73609}
-
Seth Brenith authored
This is a reland of ef808d3b Original change's description: > [torque] Protect against printing Type* pointers > > I've noticed a frequent mistake within Torque is to use Type* pointers > with ostream's operator<<, which causes it to print a hex pointer rather > than a descriptive string. This can cause confusing error messages for > users of the Torque compiler. This change is an idea to prevent future > incidences of that problem by adding a template overload that will cause > a compilation failure if anybody tries to use Type* in this way. It > found two incorrect uses of Type*, which I've corrected. > > Bug: v8:7793 > Change-Id: I85fafb333a89f8a3fed4346bdd154d70846a63d1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748936 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#73574} Bug: v8:7793 Change-Id: Id775c88d67c2fb4fbef38ef889c39dff3b6ff6b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778727Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
-
Frank Emrich authored
This CL is part of a series that implements Turbofan support for property accesses satisfying the following conditions: 1. The holder is a dictionary mode object. 2. The holder is a prototype. 3. The access is a load. This feature will only be enabled if the build flag v8_dict_property_const_tracking is set. This particular CL implements support for the case that the property in question is an accesor, meaning that the given PropertyAccessInfo has kind kAccessorDictionaryProtoConstant. Bug: v8:11248 Change-Id: Id082107edd45fa91a3f1d96aa9df345a60f46917 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720300Reviewed-by:
-
Manos Koukoutos authored
A late optimization step is only needed if Allocate operators get expanded in MemoryOptimization, which is not the case for Webassembly. Bug: v8:11510 Change-Id: I0e1af9922704d6a51f1257861ecc1e8a8faccc72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2780295 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Milad Fa authored
`registers` is only used on platforms which support sparkplug. Bug: v8:11420 Change-Id: Ia08fb1b76194db222703a64618fc2dcb00f58c96 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2780013Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Manos Koukoutos authored
This is a workaround for not having escape analysis for wasm (machine-level) turbofan graphs. Additional change: Move IsFreshObject to NodeProperties. Bug: v8:11510 Change-Id: Ibd63f4352adaa58a25f07e025c9a2c395dc669b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773345Reviewed-by:
-
Frank Emrich authored
This CL is part of a series that implements Turbofan support for property accesses satisfying the following conditions: 1. The holder is a dictionary mode object. 2. The holder is a prototype. 3. The access is a load. This feature will only be enabled if the build flag v8_dict_property_const_tracking is set. This particular CL implements support for the case that the property in question is a data property, meaning that the given PropertyAccessInfo has kind kDataDictionaryProtoConstant. Support for accessor properties is added in a separated CL. Bug: v8:11248 Change-Id: I8794127d08c3d3aed6ec2a3eb19c4c82bdf2d1df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718229 Commit-Queue: Frank Emrich <emrich@google.com> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#73603}
-
Frank Emrich authored
This CL adds: a) Helper macros that access the meta table, used in follow-up CLs b) Infrastructure for building efficient accesses to the meta table Bug: v8:11330 Change-Id: I5494c3048a4f82f21871437dfe367d6a456c8257 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773004 Commit-Queue: Frank Emrich <emrich@google.com> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Patrick Thier authored
When GetBytecodeOffsetForBaselinePC() is called with a PC that is inside the baseline prologue, correctly return kFunctionEntryOffset now. Bug: v8:11420 Change-Id: I39cb96a04e7d92d0ba5dfcbcaeebd23144c9df05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773050 Auto-Submit: Patrick Thier <pthier@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Calculate the maximum call size in the bytecode pre-visit, and pass that (along with the bytecode's frame size) to the prologue to be included in the stack check. This avoids doing a stack check before each call, and mirrors a similar optimisation in TurboFan. Also, use StackGuardWithGap instead of StackGuard, to make sure that stack overflows in the prologue actually trigger stack overflows in the runtime. Bug: v8:11420 Fixed: chromium:1189890 Change-Id: I795c197c20f85611318ab09c7bca78ce40b64924 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778278 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Nico Hartmann authored
This reverts commit c85b7a44. This reland fixes missing serialization of objects stored in CallHandlerInfo::data by adding necessary handling of these objects in FunctionTemplateInfoRef::SerializeCallCode when running with direct heap access. Drive-by: Remove declaration of CallHandlerInfoRef::Serialize, which did not have a definition. Original change's description: > [TurboFan] Move FunctionTemplateInfo to never serialized > > This CL moves FunctionTemplateInfo to the list of never serialized > objects, allowing direct heap reads. To make this threadsafe, the CL: > - adds necessary atomic (relaxed/acquire-release) operations to the > accessors of FunctionTemplateInfo. > - changes FunctionTemplateInfoRef::LookupHolderOfExpectedType to be > usable from the background thread (e.g. no handle construction) with > the caveat of skipping optimization in some cases where necessary > JSObjects are not serialized. > > Drive-by: Add missing serialization of objects possibly reachable > through CallHandlerInfo::data. > > Bug: v8:7790 > Change-Id: I49cf4f328ecfab368dff9076fde8f5783ead3246 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679687 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73364} Bug: v8:7790, chromium:1188563 Change-Id: Ib43f1eaf0592d2565292e86dea5acfc41a58f637 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773807Reviewed-by:
-
Patrick Thier authored
If a bound function is passed as argument to d8.test.verifySourcePositions, unwrap the bound target function. Bug: chromium:1186491 Change-Id: I619cb27d19166e2dc59f3fda1e2324598640b04a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778275 Auto-Submit: Patrick Thier <pthier@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
-
Andreas Haas authored
Origin trials allow webpages to use experimental features even though the features are not yet enabled by default. These features will then get enabled per execution context: it is possible that the feature is enabled in one execution context but disabled in another execution context. In V8 we check for origin trials by calling a callback provided by the embedder that takes the context as a parameter and returns whether a feature is enabled in this context or not. This approach fails when a feature changes the context itself, e.g. by extending the global object. In that case the context is not available yet to check for the origin trial. To solve the problem this CL adds a new API function that can be called by the embedder to notify V8 that context with the origin trial information is finished. After that V8 can read the origin trial information from the context and extend e.g. the global object with the origin trial features. Additionally to the API this CL also adds code to enable the WebAssembly.Exception constructor conditionally, depending on whether it has been enabled by an origin trial or not. The Blink-side change: https://crrev.com/c/2775573 R=ulan@chromium.org, jkummerow@chromium.org Change-Id: Ic05c4a89eb3e0e31469e49da8767d630c43b2e00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773287Reviewed-by:
-
Clemens Backes authored
This happens flakily on ClusterFuzz. It might not be relevant for users, but fixing it will allow ClusterFuzz to make more progress. R=szuend@chromium.org Bug: chromium:1190898 Change-Id: I7d0b705ff66e80e17ffc322b5d5fd5eb252d5965 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2778174Reviewed-by:
-
