- 03 May, 2019 1 commit
-
-
Ross McIlroy authored
Bug: v8:8801, v8:8394 Change-Id: I6bb46ecafe1bd94adbf0409f13c9b2e558da0823 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594558 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#61200}
-
- 02 Jun, 2017 1 commit
-
-
jarin authored
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
-
- 31 May, 2016 1 commit
-
-
jarin authored
This prevents the compiler from optimizing f64-to-tagged(tagged-to-f64(x)) ==> x for non-number x (such as undefined). Review-Url: https://codereview.chromium.org/2027593002 Cr-Commit-Position: refs/heads/master@{#36613}
-
- 04 Apr, 2016 1 commit
-
-
mstarzinger authored
This fixes a corner case where the generator function of a suspended generator has been marked for optimization. We assume the optimization approach will cause a bailout because generators are not optimized. But resuming is more resilient by always activating the unoptimized code. R=neis@chromium.org,bmeurer@chromium.org TEST=mjsunit/regress/regress-crbug-513471 BUG=chromium:513471 LOG=n Review URL: https://codereview.chromium.org/1856683002 Cr-Commit-Position: refs/heads/master@{#35234}
-
- 03 Feb, 2016 1 commit
-
-
bmeurer authored
R=jarin@chromium.org BUG=chromium:582703 LOG=n Review URL: https://codereview.chromium.org/1664483003 Cr-Commit-Position: refs/heads/master@{#33693}
-
- 02 Feb, 2016 1 commit
-
-
caitpotter88 authored
Based on vogelheim's CL at https://codereview.chromium.org/1657783002/ BUG=chromium:582626, v8:2700 LOG=N R=adamk@chromium.org, rossberg@chromium.org, vogelheim@chromium.org Review URL: https://codereview.chromium.org/1656993002 Cr-Commit-Position: refs/heads/master@{#33651}
-
- 29 Jan, 2016 1 commit
-
-
littledan authored
Previously, String.prototype.normalize constructed its ICU input string as a null-terminated string. This creates a bug for strings which contain a null byte, which is allowed in ECMAScript. This patch constructs the ICU string based on its length so that the entire string is normalized. R=jshin@chromium.org BUG=v8:4654 LOG=Y Review URL: https://codereview.chromium.org/1645223003 Cr-Commit-Position: refs/heads/master@{#33614}
-
- 04 Jan, 2016 1 commit
-
-
jarin authored
BUG=572409 LOG=n Review URL: https://codereview.chromium.org/1555023002 Cr-Commit-Position: refs/heads/master@{#33078}
-