- 25 Oct, 2017 1 commit
-
-
Marja Hölttä authored
- Make it possible to store quarter-bytes instead of full bytes. - Don't store is_used; it can be recovered correctly based on the actual full parse (when a lazy function is eventually called) and has_forced_scope_allocation. - With the is_used change, the old testing approach (which compared a scope for which we didn't do scope allocation to the baseline) no longer made sense. Replaced it with a new testing approach, which is also closer to the actual usage. - First version (reverted): https://chromium-review.googlesource.com/725422 BUG=v8:5516 Change-Id: I1468af6670b689a104bd867377caa1d236070820 Reviewed-on: https://chromium-review.googlesource.com/733123Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#48903}
-
- 23 Oct, 2017 2 commits
-
-
Marja Hölttä authored
This reverts commit 97ead433. Reason for revert: makes the PreParserScopeAnalysis test much slower. Original change's description: > [parser] Skipping inner funcs: Use less memory for variables. > > - Make it possible to store quarter-bytes instead of full bytes. > > - Don't store is_used; it can be recovered correctly based on the actual full > parse (when a lazy function is eventually called) and > has_forced_scope_allocation. > > - With the is_used change, the old testing approach (which compared a scope for > which we didn't do scope allocation to the baseline) no longer made > sense. Replaced it with a new testing approach, which is also closer to the > actual usage. > > BUG=v8:5516 > > Change-Id: I02bac24e482126689dcdbabe8b3a04977be29b0c > Reviewed-on: https://chromium-review.googlesource.com/725422 > Commit-Queue: Marja Hölttä <marja@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48828} TBR=marja@chromium.org,verwaest@chromium.org Change-Id: I8cb87bcd55462b1cef4444dabb5cbfa2ecb24c7c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5516 Reviewed-on: https://chromium-review.googlesource.com/732878Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#48829}
-
Marja Hölttä authored
- Make it possible to store quarter-bytes instead of full bytes. - Don't store is_used; it can be recovered correctly based on the actual full parse (when a lazy function is eventually called) and has_forced_scope_allocation. - With the is_used change, the old testing approach (which compared a scope for which we didn't do scope allocation to the baseline) no longer made sense. Replaced it with a new testing approach, which is also closer to the actual usage. BUG=v8:5516 Change-Id: I02bac24e482126689dcdbabe8b3a04977be29b0c Reviewed-on: https://chromium-review.googlesource.com/725422 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#48828}
-
- 30 Jun, 2017 1 commit
-
-
Marja Hölttä authored
This way, each lazy function needs to handle only the data relevant to itself. This reduced data handling overheads. Other changes: 1) Don't deserialize the data; once it's on the heap, it can stay there. Lazy function compilation is only done in the main thread. 2) Separate ProducedPreParsedScopeData and ConsumedPreParsedScopeData. It's clearer, because: - The data looks fundamentally different when we're producing it and when we're consuming it. - Cleanly separates the operations we can do in the "producing phase" and in the "consuming phase". Bug: v8:5516 Change-Id: I6985a6621f71b348a55155724765624b5d5f7c33 Reviewed-on: https://chromium-review.googlesource.com/528094 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46347}
-
- 22 Jun, 2017 1 commit
-
-
Marja Hölttä authored
let f = function g() { ... } declares "g" inside the function. This CL makes the preparser declare it too, and saves + restores the scope data for it. BUG=v8:5516 Change-Id: Id4c64f446d30f5252038cfb0f0f473b85ba24a9b Reviewed-on: https://chromium-review.googlesource.com/544816 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#46133}
-
- 17 May, 2017 1 commit
-
-
Marja Hölttä authored
Super calls need to refer to .this_function, .new.target and this, and super property references need to refer to .this_function and this, so that the is_used for those variables will be set and they will be allocated correctly. BUG=v8:5516 Change-Id: Idc58539fccad70c995e029051b59a67ea66bff91 Reviewed-on: https://chromium-review.googlesource.com/506094Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#45376}
-
- 16 May, 2017 1 commit
-
-
Marja Hölttä authored
These tests already pass. BUG=v8:5516 Change-Id: I7f4796cca98aa6c276143d83bcb018a67e0cbe55 Reviewed-on: https://chromium-review.googlesource.com/506193 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#45327}
-
- 07 Mar, 2017 1 commit
-
-
Marja Hölttä authored
This pretty much rewrites the preparsed scope data collection. We used to store the allocation result, but it's faster to just store the raw data which is needed for deciding it later. (This way we don't need to run the allocation algorithm for just getting this data.) For each variable: is_used, maybe_assigned, has_forced_context_allocation, and for each scope: inner_scope_calls_eval_. In addition, this CL moves data handling out of Scope and into PreParsedScopeData where it belongs and simplifies the API for PreParsedScopeData. BUG=v8:5516 R=vogelheim@chromium.org Change-Id: Ia5a4fa52f585cd4f483ce9a92f2dd7d9754f34ed Reviewed-on: https://chromium-review.googlesource.com/451273 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#43641}
-
- 28 Feb, 2017 1 commit
-
-
Marja Hölttä authored
With the params (a, b, ...c) the param / variable declaration order used to be "temp, temp, c, a, b". Now it is "temp, temp, a, b, c" as you'd expect. This makes it easier for PreParser to match the parameter order of Parser. R=verwaest@chromium.org BUG=v8:5516 Change-Id: I79da04ef3f812bf52c032bed6263c009fecb7988 Reviewed-on: https://chromium-review.googlesource.com/447677Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43490}
-
- 24 Feb, 2017 1 commit
-
-
Marja Hölttä authored
This is also needed so that PreParser doesn't need to gather more data for arrow function params in order to create the uninteresting varblock scopes matching the scopes created in Parser::BuildParameterInitializationBlock. This cancels the changes in https://chromium-review.googlesource.com/c/444747 which make PreParser create uninteresting scopes for the normal (non-arrow) function "eval in default param" case. R=vogelheim@chromium.org BUG=v8:5516 Change-Id: I8957ac0796d8738c63492f7928bca6f00e4b4241 Reviewed-on: https://chromium-review.googlesource.com/446339Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43411}
-
- 07 Feb, 2017 4 commits
-
-
hablich authored
Reland of [parsing] Fix maybe-assigned for loop variables. (patchset #1 id:1 of https://codereview.chromium.org/2679263002/ ) Reason for revert: False alarm, bot hiccup Original issue's description: > Revert of [parsing] Fix maybe-assigned for loop variables. (patchset #3 id:40001 of https://codereview.chromium.org/2673403003/ ) > > Reason for revert: > Speculative revert because of https://codereview.chromium.org/2679163002/. > > Original issue's description: > > [parsing] Fix maybe-assigned for loop variables. > > > > Due to hoisting, the value of a 'var'-declared variable may actually change even > > if the code contains only the "initial" assignment, namely when that assignment > > occurs inside a loop. For example: > > > > let i = 10; > > do { var x = i } while (i--): > > > > As a simple and very conservative approximation of this, we explicitly mark > > as maybe-assigned any non-lexical variable whose "declaration" does not > > syntactically occur in the function scope. (In the example above, it > > occurs in a block scope.) > > > > BUG=v8:5636 > > > > Review-Url: https://codereview.chromium.org/2673403003 > > Cr-Commit-Position: refs/heads/master@{#42989} > > Committed: https://chromium.googlesource.com/v8/v8/+/a33fcd663b28b8846e12b97c30d6e7d837767f86 > > TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5636 > > Review-Url: https://codereview.chromium.org/2679263002 > Cr-Commit-Position: refs/heads/master@{#43010} > Committed: https://chromium.googlesource.com/v8/v8/+/f3ae5ccf57690d8c2d87c4fe1d10b103ad6a4ab3 TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5636 Review-Url: https://codereview.chromium.org/2686663002 Cr-Commit-Position: refs/heads/master@{#43013}
-
hablich authored
Revert of [parsing] Fix maybe-assigned for loop variables. (patchset #3 id:40001 of https://codereview.chromium.org/2673403003/ ) Reason for revert: Speculative revert because of https://codereview.chromium.org/2679163002/. Original issue's description: > [parsing] Fix maybe-assigned for loop variables. > > Due to hoisting, the value of a 'var'-declared variable may actually change even > if the code contains only the "initial" assignment, namely when that assignment > occurs inside a loop. For example: > > let i = 10; > do { var x = i } while (i--): > > As a simple and very conservative approximation of this, we explicitly mark > as maybe-assigned any non-lexical variable whose "declaration" does not > syntactically occur in the function scope. (In the example above, it > occurs in a block scope.) > > BUG=v8:5636 > > Review-Url: https://codereview.chromium.org/2673403003 > Cr-Commit-Position: refs/heads/master@{#42989} > Committed: https://chromium.googlesource.com/v8/v8/+/a33fcd663b28b8846e12b97c30d6e7d837767f86 TBR=marja@chromium.org,adamk@chromium.org,neis@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5636 Review-Url: https://codereview.chromium.org/2679263002 Cr-Commit-Position: refs/heads/master@{#43010}
-
neis authored
Due to hoisting, the value of a 'var'-declared variable may actually change even if the code contains only the "initial" assignment, namely when that assignment occurs inside a loop. For example: let i = 10; do { var x = i } while (i--): As a simple and very conservative approximation of this, we explicitly mark as maybe-assigned any non-lexical variable whose "declaration" does not syntactically occur in the function scope. (In the example above, it occurs in a block scope.) BUG=v8:5636 Review-Url: https://codereview.chromium.org/2673403003 Cr-Commit-Position: refs/heads/master@{#42989}
-
marja authored
BUG=v8:5516 R=vogelheim@chromium.org Review-Url: https://codereview.chromium.org/2683573002 Cr-Commit-Position: refs/heads/master@{#42986}
-