- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 17 May, 2019 1 commit
-
-
Yang Guo authored
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,verwaest@chromium.org Bug: v8:9247 Change-Id: I7ffc2bd4a5fdf7c20cc3283bb5545cbf9ffd4e53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617254Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61609}
-
- 16 May, 2019 3 commits
-
-
Maya Lekova authored
This reverts commit 9ac8b200. Reason for revert: Breaks CFI bot https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20cfi/20442 Original change's description: > Move API-related files > > NOPRESUBMIT=true > TBR=verwaest@chromium.org > > Bug: v8:9247 > Change-Id: I45bfe0782ba92aa7ed27a9e308d0aab9ba1bac7f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613988 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61579} TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,verwaest@chromium.org Change-Id: I28ee9174a1cbc1dae9711977bf9369253ef43058 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9247 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1615463Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#61583}
-
Yang Guo authored
NOPRESUBMIT=true TBR=verwaest@chromium.org Bug: v8:9247 Change-Id: I45bfe0782ba92aa7ed27a9e308d0aab9ba1bac7f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613988Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61579}
-
Jakob Gruber authored
Prior to this CL, call counts at function scope were taken from the FeedbackVector::invocation_count field. This had two major drawbacks: 1. for generator functions, these count the number of resumptions instead of the number of calls; and 2. the invocation count is not maintained in optimized code. The solution implemented here is to add a dedicated call counter at function scope which is incremented exactly once each time the function is called. A minor complication is that our coverage output format expects function-scope counts in the dedicated CoverageFunction object, and not as a CoverageBlock. Thus function-scope block counts are initially marked with magic positions, and later recognized and rewritten during processing. This CL thus fixes reported generator function call counts and enables optimizations in block coverage modes (more to come in a follow-up). Drive-by: Don't report functions with empty source ranges. Bug: v8:6000,v8:9148,v8:9212 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng Change-Id: Idbe5edb35a595cf12b6649314738ac00efd173b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613996 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61574}
-
- 13 May, 2019 1 commit
-
-
Joyee Cheung authored
Added null check when printing the brand with --print-ast. Bug: chromium:961507, chromium:961508 Original change's description: > [class] implement private method declarations > > This patch implements the declarations of private methods, the access > of private methods would be left to a future patch. > When a private methods declaration is encountered, we now: > > - Create a brand symbol during class evaluation and store it in the > context. > - Create the closures for the private methods > - Load the brand from the context and store it in the instance in the > constructor. > > Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit# > > Bug: v8:8330 > Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708 > Commit-Queue: Joyee Cheung <joyee@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61387} Change-Id: I3bf465f70c27914c9ec19f3f59ae018b28c9a866 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605521 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#61459}
-
- 10 May, 2019 2 commits
-
-
Santiago Aboy Solanes authored
Everything after UNREACHABLE is dead code, so it makes sense to remove them. Bug: v8:9183 Change-Id: If76468a73b926d74717cc2348fd5b36d30f680c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605727Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#61411}
-
Ross McIlroy authored
This reverts commit b9191bd3. Reason for revert: Clusterfuzz bugs BUG=chromium:961507,chromium:961508 Original change's description: > [class] implement private method declarations > > This patch implements the declarations of private methods, the access > of private methods would be left to a future patch. > When a private methods declaration is encountered, we now: > > - Create a brand symbol during class evaluation and store it in the > context. > - Create the closures for the private methods > - Load the brand from the context and store it in the instance in the > constructor. > > Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit# > > Bug: v8:8330 > Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708 > Commit-Queue: Joyee Cheung <joyee@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61387} TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8330 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#61406}
-
- 09 May, 2019 2 commits
-
-
Joshua Litt authored
Per 262, yield* for async generators is supposed to Await the input value. #sec-generator-function-definitions-runtime-semantics-evaluation Section 14.4.13, yield *, 7.c.iii.1 Bug: v8:9051 Change-Id: Ie1e829309fe78683a9ff0adf816208c2bf0bb524 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1600508 Commit-Queue: Joshua Litt <joshualitt@google.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#61390}
-
Joyee Cheung authored
This patch implements the declarations of private methods, the access of private methods would be left to a future patch. When a private methods declaration is encountered, we now: - Create a brand symbol during class evaluation and store it in the context. - Create the closures for the private methods - Load the brand from the context and store it in the instance in the constructor. Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit# Bug: v8:8330 Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#61387}
-
- 29 Apr, 2019 1 commit
-
-
Benedikt Meurer authored
This adds a new %_CopyDataProperties intrinsic, that reuses most of the existing machinery that we already have in place for Object.assign() and computed property names in object literals. This speeds up the general case for object spread (where the spread is not the first item in an object literal) and brings it on par with Object.assign() at least - in most cases it's significantly faster than Object.assign(). In the test case [1] referenced from the bug, the performance goes from objectSpreadLast: 3624 ms. objectAssignLast: 1938 ms. to objectSpreadLast: 646 ms. objectAssignLast: 1944 ms. which corresponds to a **5-6x performance boost**, making object spread faster than Object.assign() in general. Drive-by-fix: This refactors the Object.assign() fast-path in a way that it can be reused appropriately for object spread, and adds another new builtin SetDataProperties, which does the core of the Object.assign() work. We can teach TurboFan to inline Object.assign() based on the new SetDataProperties builtin at some later point to further optimize Object.assign(). [1]: https://gist.github.com/bmeurer/0dae4a6b0e23f43d5a22d7c91476b6c0 Bug: v8:9167 Change-Id: I57bea7a8781c4a1e8ff3d394873c3cd4c5d73834 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587376Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61100}
-
- 03 Apr, 2019 2 commits
-
-
Clemens Hammacher authored
Even though both are allowed in the style guide, it recommends to use 'using', as its syntax is more consistent with the rest of C++. This CL turns all typedefs in interpreter code to 'using' declarations. R=leszeks@chromium.org Bug: v8:8834 Change-Id: Ide1e8a35a56a840b36b3ceab1307df1bcab94acd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545900Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60609}
-
Simon Zünd authored
The native flag is a left-over from self-hosted JavaScript. Currently only the empty function and empty script are marked native. This CL removes the native flag from the ParseInfo, UnoptimizedCompilationInfo and its handling in the bytecode generator. R=leszeks@chromium.org Bug: v8:8834,v8:9043 Change-Id: I60726e28ce83cc84249e9c49bdc88d81f0a695c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545079Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60606}
-
- 12 Mar, 2019 1 commit
-
-
Hannes Payer authored
Bug: v8:8945 Change-Id: I14ca4b29f1b12ff95e718d431f65d88ab1238c53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511478Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60177}
-
- 11 Mar, 2019 2 commits
-
-
Mythri authored
This is a pre-work for allocating feedback vectors lazily. Feedback cells are required to share the feedback vectors across the different closures of the same function. Currently, they are held in the CreateClosureSlot in the feedback vector. With lazy feedback vector allocation, we may not have a feedback vector. However, we still need a place to store the feedback cells, so if feedback vector is allocated in future it can still be shared across closures. Here is the detailed design doc: https://docs.google.com/document/d/1m2PTNChrlJqw9MiwK_xEJfqbFHAgEHmgGqmIN49PaBY/edit BUG=v8:8394 Change-Id: Ib406d862b2809b1293bfecdcfcf8dea3127cb1c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1503753 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60147}
-
Clemens Hammacher authored
The {id_} stored in {ThreadId} should not be atomic. Only getting a new id for the current thread needs to be atomic. If any user of {ThreadId} needs atomicity, that user should wrap {ThreadId} in a {std::atomic} instead. Drive-by: Remove {Equals} method, use {operator==} instead. Drive-by: Move static methods after member methods. R=ishell@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Bug: v8:8834 Change-Id: Id0470eb2fa907948843ac1153e2dc5dcd9a8fbc8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1494006Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60146}
-
- 01 Mar, 2019 1 commit
-
-
Matt Gardner authored
The original was reverted for breaking webkit layout tests: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270 It also caused the following clusterfuzz failures: chromium:935832 This was a correctness bug due to not properly handling the case of arrays with prototypes other than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect both in access-assembler and in Turbofan. chromium:935932 This bug was that there was no handling for Has checks on the global object. Turbofan was emitting code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in debug builds but in release could show up in different places. This is the bug that caused the webkit layout test failure that led to the revert. Both bugs are fixed by in CL, and tests are added for those cases. Bug: v8:8733, chromium:935932, chromium:935832 Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925 Reviewed-on: https://chromium-review.googlesource.com/c/1493132Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Matt Gardner <magardn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59958}
-
- 28 Feb, 2019 1 commit
-
-
Leszek Swirski authored
Rather than manually tracking basic blocks in the bytecode array builder, use the existing dead code elimination to generate an implicit return iff the block ending the bytecode is not dead by the time all statements have been visited. Change-Id: I9520486a523ec4e01bc203e9a847eb1f57b130b6 Reviewed-on: https://chromium-review.googlesource.com/c/1494756Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59951}
-
- 26 Feb, 2019 1 commit
-
-
Sigurd Schneider authored
This reverts commit 32fc0acf. Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270 layout test breakage: https://test-results.appspot.com/data/layout_results/V8-Blink_Linux_64/30270/webkit_layout_tests%20%28with%20patch%29/layout-test-results/results.html There is a dead node arriving in representation selection, which might indicate that the problem is not in this CL, but that this CL stirs up the node soup in such a way that dead code elimination gets confused. Original change's description: > Optimize `in` operator > > This change implements optimizations for the `in` operator for packed array > elements and object properties. It adds a new feedback slot kind and an IC > path similar to KeyedLoadIC for handling the lookups. TurboFan uses the > feedback to optimize based on the maps and keys. > > For more details see: > https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig > > This can provide 10x performance improvements of on loops of the form: > > for (let i = 0; i < ary.length; ++i) { > if (i in ary) { > ... > } > } > > > Bug: v8:8733 > Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8 > Reviewed-on: https://chromium-review.googlesource.com/c/1432598 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Matt Gardner <magardn@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#59843} TBR=ulan@chromium.org,rmcilroy@chromium.org,jkummerow@chromium.org,jarin@chromium.org,ishell@chromium.org,bmeurer@chromium.org,verwaest@chromium.org,magardn@microsoft.com Change-Id: Ib2db974e5bed4c4a2b6b450f796bdc4b0b8fd562 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8733 Reviewed-on: https://chromium-review.googlesource.com/c/1488761Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59857}
-
- 25 Feb, 2019 2 commits
-
-
Matt Gardner authored
This change implements optimizations for the `in` operator for packed array elements and object properties. It adds a new feedback slot kind and an IC path similar to KeyedLoadIC for handling the lookups. TurboFan uses the feedback to optimize based on the maps and keys. For more details see: https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig This can provide 10x performance improvements of on loops of the form: for (let i = 0; i < ary.length; ++i) { if (i in ary) { ... } } Bug: v8:8733 Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8 Reviewed-on: https://chromium-review.googlesource.com/c/1432598Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Matt Gardner <magardn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59843}
-
Ross McIlroy authored
Template objects should be cached after they are first created and reused on subsiquent calls to tag functions. Currently these cached objects are stored on the feedback vector, which has appropriate lifetime, however with bytecode flushing the feedback vector could be cleared when the bytecode is flushed, causing the template object to be dropped. In order to retain the cached template objects in the face of bytecode flushing, this CL adds a weakmap for each native context that is (weakly) keyed by shared function info, and holds a linked list of cached template objects associated with that shared function info, indexed by feedback vector slot id. Misses will check this weakmap, and if no entry is found, a new template object is created and added into this weakmap alongside the feedback vector. BUG=v8:8799,v8:8799,v8:8395 Change-Id: Ia95d5cfc394ce58dc9fe6a1e49780f05299acc17 Reviewed-on: https://chromium-review.googlesource.com/c/1477746 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59818}
-
- 08 Feb, 2019 1 commit
-
-
Toon Verwaest authored
As requested in https://chromium-review.googlesource.com/c/v8/v8/+/1448313 Change-Id: I89e84600aa4cd3feef3dbf4f5acdaf377e3446f8 Reviewed-on: https://chromium-review.googlesource.com/c/1460463Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59449}
-
- 06 Feb, 2019 1 commit
-
-
Toon Verwaest authored
"this" is a very common expression. By using a single ThisExpression object we can both avoid allocating many unnecessary VariableProxies and specialize the resolution of this since we know where it's declared up-front. This also avoids having to special-case "this" reference handling in the paths that would behave differently for "this" than for regular references; e.g., with-scopes. The tricky pieces are due to DebugEvaluate and this/super() used as default parameters of arrow functions. In the former case we replace the WITH_SCOPE with FUNCTION_SCOPE so that we make sure that "this" is intercepted, and still rely on regular dynamic variable lookup. Arrow functions are dealt with by marking "this" use in ArrowHeadParsingScopes. If the parenthesized expression ends up being an arrow function, we force context allocate on the outer scope (and mark "has_this_reference" on the FUNCTION_SCOPE so DebugEvaluate in the arrow function can expose "this"). The CL also removes the now unused ThisFunction AST node. Change-Id: I0ca38ab92ff58c2f731e07db2fbe91df901681ef Reviewed-on: https://chromium-review.googlesource.com/c/1448313Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59393}
-
- 04 Feb, 2019 1 commit
-
-
Clemens Hammacher authored
The most common use of {SaveContext} is to allocate this object, then immediately set the context of the isolate to another Context. Thus introduce a second class called "SaveAndSwitchContext" which implements exactly that. R=mstarzinger@chromium.org Bug: v8:8562 Change-Id: I2fca1eadd909a7afe035316ded934624273f2e21 Reviewed-on: https://chromium-review.googlesource.com/c/1448319Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59323}
-
- 25 Jan, 2019 2 commits
-
-
Mythri authored
SetProperty now infers the language mode from the closure and the context So we no longer have to pass around the language mode. Cleanup by removing the parameter where it is no longer needed. Bug: v8:8580 Change-Id: I89452b5a762eb48a911f158d22c7bfa9e3bb1be4 Reviewed-on: https://chromium-review.googlesource.com/c/1421840 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59089}
-
Leszek Swirski authored
Declare Variables with a name and position, rather than by passing through a VariableProxy. This allows us to not create dummy proxies for things like function declarations, and allows us to consider those declarations unused. As a side-effect, we also have to check if a variable is unused in the bytecode generator (as it will no longer be allocated), and we end up skip generating code/SFIs for dead variables/functions. Change-Id: I4c2c872473f23e124f9456b4b92f87159658f8e0 Reviewed-on: https://chromium-review.googlesource.com/c/1414916 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#59088}
-
- 22 Jan, 2019 2 commits
-
-
Matt Gardner authored
V8 implements "delete this" as "LdaTrue", but an error needs to be thrown if done in a constructor before calling super. ThrowIfHole checks the accumulator, so we need to load 'this' into the accumulator. The check is inserted by the load since it has HoleCheckMode::kRequired Bug: https://bugs.chromium.org/p/v8/issues/detail?id=6711 Change-Id: I9f2ce4439505cec4327d88d1195898782edea721 Reviewed-on: https://chromium-review.googlesource.com/c/1419084Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Matt Gardner <magardn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59007}
-
Ross McIlroy authored
The decision as to whether to optimize an IIFE as oneshot depends on whether it's outer scope is the script scope. During lazy compile, we might have discarded scopes which don't need a context between the IIFE and the script scope, which means we might treat an IIFE as oneshot, even though initial eager compile treated it as non-oneshot. Both bytecode flushing and lazy source positions rely on us generating the same bytecode during lazy compile as eager compile, so we move the decision into the parser where it happens once and is then stored in the SFI for any future lazy compiles. BUG=v8:8395,v8:8510 Change-Id: I88f1e74ad95d47a2636c393ceb1318d7d610055d Reviewed-on: https://chromium-review.googlesource.com/c/1421841Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#58996}
-
- 16 Jan, 2019 2 commits
-
-
Toon Verwaest authored
That makes the declaration in sync with how dynamic references are resolved, avoiding duplicate variable creation in the likely case that the variable is also referenced within the eval. Bug: v8:5112, v8:5135, v8:8693 Change-Id: I0c55495f573fe8b5076b1627c139ff72d1adda74 Also-by: leszeks@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/1408890 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58850}
-
Leszek Swirski authored
Storing a VariableProxy in declarations means that a declaration and initialisation assignment are tightly coupled to use the same var. In particular, this means that Var declarations in with scopes have to clone the VariableProxy to split the declaration and initializer LHS lookup. This patch changes declarations to point directly to the Variable, not the VariableProxy. This will allow future refactoring to decouple declarations and initialisations. Change-Id: I0baa77bfd12fe175f9521d292740d7d712cffd37 Reviewed-on: https://chromium-review.googlesource.com/c/1406683Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58843}
-
- 15 Jan, 2019 1 commit
-
-
Leszek Swirski authored
Change-Id: Ia39d2157eb7c0c644348e1762ee32fef84c6b51d Reviewed-on: https://chromium-review.googlesource.com/c/1409428 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#58816}
-
- 14 Jan, 2019 1 commit
-
-
Leszek Swirski authored
This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
-
- 10 Jan, 2019 3 commits
-
-
Leszek Swirski authored
For desrtucturing assignments from null/undefined, we throw an error that references the destructuring object literal's property name, e.g. for var { x } = null; we report that we cannot destructure 'x' from null. Rather than calculating this property during bytecode generation (and including it in the bytecode as an argument to the type error constructor), we can calculate it at exception throwing time, by re-parsing the source in a similar way to the existing call site rendering. This slightly decreases bytecode size and slightly decreases the amount of work the bytecode compiler needs to do. In the future, it could also allow us to give more detailed error messages, as we now have access to the entire AST and are on the slow path anyway. Bug: v8:6499 Change-Id: Icdbd4667db548b4e5e62ef97797a3771b5c1bf72 Reviewed-on: https://chromium-review.googlesource.com/c/1396080Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58706}
-
Leszek Swirski authored
The 'done' setting dance in BuildFillArrayWithIterator turned out to not be useful, as the StoreInArrayLiteral call could not ever throw an exception. Since iterator exceptions count as done, we are guarnteed to be done as soon as we enter the loop. Change-Id: Ibe2ba1fcbe383bfcfedb185169890b6931cc7884 Reviewed-on: https://chromium-review.googlesource.com/c/1402792 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#58695}
-
Leszek Swirski authored
The IteratorClose spec specifies that exceptions in %GetMethod(iterator.return) are not suppressed by exceptions in the given continuation (body of a loop, assignments in destructuring), while exceptions in the execution of iterator.return() are. This means that we have to split out the property access + a typeof check to be outside the try-catch, and keep the call inside of it. The non-split version is only for cases when there is no 'throws' continuation (as is the case for yield* calling IteratorClose), so the existing BuildIteratorClose can be renamed to reflect this. Change-Id: Id71aea4fddd6ffb986bd9aaa09d29615a8800f71 Reviewed-on: https://chromium-review.googlesource.com/c/1402789Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58694}
-
- 09 Jan, 2019 1 commit
-
-
Leszek Swirski authored
Emit a single destructuring assignment for destructuring declarations, which can be desugared by the bytecode generator. This allows us to remove destructuring desugaring from the parser (specifically, the pattern rewriter) entirely. The pattern "rewriter" is now only responsible for walking the destructuring pattern to declare variables, mark them assigned, and potentially rewrite scopes for the edge case of parameters with a sloppy eval. Note that since the rewriter is no longer rewriting, we have to flip the VariableProxy copying logic for var re-lookup, so that we now pass the new VariableProxy to the variable declaration and leave the original unresolved (rather than passing the original through and rewriting to a new unresolved VariableProxy). This change does have some effect on breakpoint locations, due to some of the available information changing between the parser and bytecode generator, however the new locations appear to be more consistent between assignments and declarations. Change-Id: I3a58dd0a387d2bfb8e5e9e22dde0acc5f440cb82 Reviewed-on: https://chromium-review.googlesource.com/c/1382462 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58670}
-
- 08 Jan, 2019 1 commit
-
-
Toon Verwaest authored
Previously we'd always push variable proxies into the unresolved list of the current scope, and possibly delete them from the list later in case they end up being declarations. If variables become assigned, there were two ways to mark them as such: The preparser would marked the variables tracked on the PreParserExpression, and the parser would traverse the LHS AST to find and mark all variables. After this CL, if the scope already knows it's tracking declarations, the variables are never added to the unresolved list in the first place. If the scope is ambigous, it tracks the variable proxies on the side and only adds them to the unresolved list if they end up being references rather than declarations. The same list is now used to bulk mark all LHS variables as assigned; uniformely for both the parser and the preparser. In a next step we'll also use the scope to create declarations. That way we can stop tracking variables_ on PreParserExpression altogether. Change-Id: I6ada37006cc2e066731f29cd4ea314550fc7959f Reviewed-on: https://chromium-review.googlesource.com/c/1397669 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58629}
-
- 07 Jan, 2019 3 commits
-
-
Joyee Cheung authored
This patch sets the name slot of the private name symbols for private fields and display the names in error messages of invalid private field accesses. TBR: adamk@chromium.org Bug: v8:8144 Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76 Reviewed-on: https://chromium-review.googlesource.com/c/1374332Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58601}
-
Camillo Bruni authored
- Directly use VisitFunctionLiteral where possible - Take shortcut for StringLiterals in BuildLoadPropertyKey Change-Id: Ib5c3de3d2bdd354acbfeb607415854ba90622e89 Reviewed-on: https://chromium-review.googlesource.com/c/1382750Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#58595}
-
Clemens Hammacher authored
This reverts commit dcd75706. Reason for revert: Breaks layout tests, blocks roll, see https://crrev.com/c/1396602; there are wasm CLs in this range too, but this CL looks like the most likely culprit. Original change's description: > Reland: [Compiler] Ensure unoptimized code generation is context independent. > > Now that Asm.js code is also context independent, move code to ensure context independence > from BytecodeGenerator to FinalizeUnoptimizedCode. > > Reland of CL: https://chromium-review.googlesource.com/c/v8/v8/+/1349236 > > Change-Id: I718090850870c61733e0719d4091ec60bc080ebb > Reviewed-on: https://chromium-review.googlesource.com/c/1396201 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58558} TBR=rmcilroy@chromium.org,delphick@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: I5f547319f31f87777165361747dd42d223fc0b0e Reviewed-on: https://chromium-review.googlesource.com/c/1396427Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58564}
-