- 12 Aug, 2019 12 commits
-
-
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 <jgruber@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63161}
-
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: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63158}
-
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: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63157}
-
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: Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63156}
-
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: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#63155}
-
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: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#63154}
-
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 <tebbi@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#63153}
-
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: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63151}
-
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: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ana Pesko <anapesko@google.com> Cr-Commit-Position: refs/heads/master@{#63150}
-
- 09 Aug, 2019 16 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: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63149}
-
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: Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#63147}
-
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: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63146}
-
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: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com> Cr-Commit-Position: refs/heads/master@{#63145}
-
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: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63141}
-
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: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
-
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: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#63138}
-
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: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#63137}
-
Tamer Tas authored
TBR=machenbach@chromium.org Bug: chromium:883629 Change-Id: Ie9d4584f6fd2c59e51128b09df5de3fbf8cf8780 No-Try: True Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745468Reviewed-by: Tamer Tas <tmrts@chromium.org> Auto-Submit: Tamer Tas <tmrts@chromium.org> Commit-Queue: Tamer Tas <tmrts@chromium.org> Cr-Commit-Position: refs/heads/master@{#63136}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/c991845..f3d0ca5 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a01c121..30604c6 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/a110bf6..1b4c7e9 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ib4c6baf8106ef5051efeb986f7e78a154c4e1ef8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745270Reviewed-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@{#63135}
-
Yury Semikhatsky authored
Since the same value is also returned in 'result' field it is still populated in accord with 'returnByValue' parameter. This behavior is consistent with 'evaluate'. R=dgozman@chromium.org, lushnikov@chromium.org Bug: v8:9509 Change-Id: I9f72682f87492ce5cd0759dce75ab3d75a5fe31c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1707331Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Yury Semikhatsky <yurys@chromium.org> Cr-Commit-Position: refs/heads/master@{#63134}
-
- 08 Aug, 2019 12 commits
-
-
Ng Zhi An authored
Bug: v8:9608 Change-Id: I676fd49c35dd65d96f524a9b6e09722ff12d472e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1744910Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Auto-Submit: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#63133}
-
Jakob Kummerow authored
Change-Id: Ic5145b7ba15ae58d15e2cc4511afc2f8c6d42ea0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741654 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#63132}
-
Dominik Inführ authored
This reverts commit e2f98ec2. Reason for revert: Caused performance regression in ArrayLiteralInitialSpreadSmallHoley. Original change's description: > Use list of invalidated objects for old-to-new refs > > Instead of inserting "deletion" entries into the store buffer, keep > a list of invalidated objects to filter out invalid old-to-new slots. > > The first CL https://crrev.com/c/1704109 got reverted because both the sweeper and the main task were modifying the invalidated slots data structure concurrently. This CL changes this, such that the sweeper only modifies the invalidated slots during the final atomic pause when the main thread is not running. The sweeper does not need to clean this data structure after the pause, since the "update pointers" phase already removed all invalidated slots. > > Bug: v8:9454 > Change-Id: Iffb5bf96de2c89eee1ee1231a3414a0f2a155cbc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733081 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63087} TBR=ulan@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9454 Change-Id: I328b9f72df45fc9570d4a4d1b5389eac010638c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743970 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#63131}
-
Gus Caplan authored
Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
-
Joshua Litt authored
Bug: v8:9603 Change-Id: I7a36c97feedaccf81509aae579f1594a0e7b1019 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743527Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63129}
-
Ross McIlroy authored
If the function has been uncompiled (bytecode flushed) it will have lost any preparsed data. When we recompile the outer function we will regenerate this PreParseData but it wasn't being reattached to the inner function. This CL fixes this by checking for this case in Compiler::GetSharedFunctionInfo and creating a new NewUncompiledDataWithPreparseData to attach to the inner function. BUG=v8:9479 Change-Id: I5c0fc8251006f8f5c7c7f5f9dd17b2ecc671b672 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741655 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63128}
-
Peter Marshall authored
The spec says we have to insert some wrapper code with extra line breaks in it, but this confuses users when they see stack traces as the line numbers come from the code with the wrapper, instead of the original. This CL sets line_offset on the script to indicate that line numbers should be offset by the 2 extra line breaks when reading them out e.g. for the purpose of stack traces. Bug: chromium:109362 Change-Id: Ib608e1043c38b595b1466766f7592e993ee3b996 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741660Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#63127}
-
Patrick Thier authored
This CL changes the dispatch technique in the regex interpreter to token-threaded dispatch, if computed gotos are supported by the compiler. Otherwise old switch-based dispatch is still used (e.g. for MSVC). With computed gotos, less jumps will be emitted (no extra jump to single branch point/begin of switch) and branch prediction will be better because of no single branch point. This CL improves performance on the RexBench Benchmark suite by ~10%. Bug: v8:9575 Change-Id: I585ad824ff1cc595a5dfa8831ad66d6810d0119b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733073Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Patrick Thier <pthier@google.com> Cr-Commit-Position: refs/heads/master@{#63126}
-
Sathya Gunasekaran authored
Change-Id: I3768f2ca772d1ba60a5436a971c3f1966e8ab8f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741649Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#63125}
-
Mythri A authored
With lazy feedback allocation, we don't have feedback vectors when function starts executing. If we mark the function on the first execution we would be missing feedback for the initial part of the function and hence the optimized code will not be useful. This cl resets the optimization markers on OSR if the invocation count of the function is less than 1. We may still do wasted optimizations if the function is hot enough for optimizing but not for OSRing. In the long term we may want to fix it differently. This fix covers the most common cases in benchmarks. Bug: chromium:987523 Change-Id: I1cfe82e6b9f95278b77c99b77d4b981828b5c0ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739373 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63124}
-
Tamer Tas authored
TBR=machenbach@chromium.org No-Try: True Change-Id: Ie0a94f97989a6f5a7e0b68c733035e3dac264215 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743966Reviewed-by: Tamer Tas <tmrts@chromium.org> Auto-Submit: Tamer Tas <tmrts@chromium.org> Commit-Queue: Tamer Tas <tmrts@chromium.org> Cr-Commit-Position: refs/heads/master@{#63123}
-
Simon Zünd authored
This CL adds an access check for the arguments to all calls to {console} like {console.log}. This is needed since the DevTools protocol notificiation event does not contain the context in which the {console.log} call occurred. Only the context of the argument. When DevTools then reads properties for the preview of the argument, it uses arguments context, instead of the calling context, potentially leaking objects/exceptions into the calling context. Bug: chromium:987502, chromium:986393 Change-Id: I6f7682f7bee94a28ac61994bad259bd003511c39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741664 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63122}
-