- 30 Apr, 2019 1 commit
-
-
Mythri A authored
With bytecode flushing and lazy feedback allocation, we need to call %PrepareForOptimization before we call %OptimizeFunctionOnNextCall Bug: v8:8801, v8:8394 Change-Id: I81918f174b2f97cbaa8b8ef2e459080c2581f535 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588415 Commit-Queue: Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#61122}
-
- 11 Jan, 2018 1 commit
-
-
Caitlin Potter authored
https://github.com/tc39/ecma262/pull/988 gained concensus during the september 2017 TC39 meetings. This moves the load of the "next" method to the very beginning of the iteration protocol, rather than during each iteration step. This impacts: - yield* - for-of loops - spread arguments - array spreads In the v8 implementation, this also affects async iteration versions of these things (the sole exception being the Async-From-Sync iterator, which requires a few more changes to work with this, likely done in a followup patch). This change introduces a new AST node, ResolvedProperty, which can be used as a callee by Call nodes to produce the same bytecode as Property calls, without observably re-loading the property. This is used in several AST-desugarings involving the iteration protocol. BUG=v8:6861, v8:5699 R=rmcilroy@chromium.org TBR=neis@chromium.org, adamk@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b Reviewed-on: https://chromium-review.googlesource.com/857593 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50518}
-
- 09 Jan, 2018 2 commits
-
-
Michael Achenbach authored
This reverts commit bf4cc9ee. Reason for revert: Breaks windows with msvc and linux with gcc https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841 https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265 Original change's description: > [esnext] load `iterator.next` only once at beginning of iteration > > https://github.com/tc39/ecma262/pull/988 gained concensus during the > september 2017 TC39 meetings. This moves the load of the "next" method > to the very beginning of the iteration protocol, rather than during > each iteration step. > > This impacts: > > - yield* > - for-of loops > - spread arguments > - array spreads > > In the v8 implementation, this also affects async iteration versions of > these things (the sole exception being the Async-From-Sync iterator, > which requires a few more changes to work with this, likely done in a > followup patch). > > This change introduces a new AST node, ResolvedProperty, which can be used > as a callee by Call nodes to produce the same bytecode as Property calls, > without observably re-loading the property. This is used in several > AST-desugarings involving the iteration protocol. > > BUG=v8:6861, v8:5699 > R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b > Reviewed-on: https://chromium-review.googlesource.com/687997 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#50452} TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6861, v8:5699 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/857616Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#50454}
-
Caitlin Potter authored
https://github.com/tc39/ecma262/pull/988 gained concensus during the september 2017 TC39 meetings. This moves the load of the "next" method to the very beginning of the iteration protocol, rather than during each iteration step. This impacts: - yield* - for-of loops - spread arguments - array spreads In the v8 implementation, this also affects async iteration versions of these things (the sole exception being the Async-From-Sync iterator, which requires a few more changes to work with this, likely done in a followup patch). This change introduces a new AST node, ResolvedProperty, which can be used as a callee by Call nodes to produce the same bytecode as Property calls, without observably re-loading the property. This is used in several AST-desugarings involving the iteration protocol. BUG=v8:6861, v8:5699 R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b Reviewed-on: https://chromium-review.googlesource.com/687997 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50452}
-
- 20 Jun, 2017 1 commit
-
-
Peter Marshall authored
We can remove a lot of native code and rely on CallOrConstructVarargs to do the stack manipulation for us. This will also take advantage of the fast-path for double arrays in CallOrConstructDoubleVarargs. We can also remove Runtime_SpreadIterableFixed because it isn't used anymore. We just call directly into spread_iterable from CSA. Bug: v8:6488, chromium:704966 Change-Id: I81a18281f062619851134fff7ce88471566ee3b5 Reviewed-on: https://chromium-review.googlesource.com/535615Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#46038}
-
- 25 Jan, 2017 1 commit
-
-
petermarshall authored
We did not smi-check the spread argument here, meaning we tried to take the map of a smi, resulting in segfaults which clusterfuzz found. Also added tests that exercise this path. BUG=685086 Review-Url: https://codereview.chromium.org/2655013002 Cr-Commit-Position: refs/heads/master@{#42657}
-
- 15 Nov, 2016 1 commit
-
-
petermarshall authored
Avoid using the iterator for arrays with fast elements where the iterator has not been modified. Only deals with the case where there is a single spread argument. Improves the six-speed "spread" benchmark to 1.5x slower than baseline es5 implementation, compared to 19x slower previously. BUG=v8:5511 Review-Url: https://codereview.chromium.org/2465253011 Cr-Commit-Position: refs/heads/master@{#40998}
-
- 28 Oct, 2015 1 commit
-
-
adamk authored
These features shipped in M46 without issue. Review URL: https://codereview.chromium.org/1429653006 Cr-Commit-Position: refs/heads/master@{#31635}
-
- 28 Sep, 2015 1 commit
-
-
neis authored
R=rossberg BUG= Review URL: https://codereview.chromium.org/1371963002 Cr-Commit-Position: refs/heads/master@{#30970}
-
- 09 Apr, 2015 1 commit
-
-
caitpotter88 authored
BUG=v8:3018 R= LOG=N Review URL: https://codereview.chromium.org/938443002 Cr-Commit-Position: refs/heads/master@{#27714}
-