- 08 Sep, 2017 1 commit
-
-
Jaroslav Sevcik authored
The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
-
- 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}
-
- 03 Feb, 2017 1 commit
-
-
bmeurer authored
We cannot optimize global proxy access unless deoptimization is enabled. BUG=chromium:687990 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2675793002 Cr-Commit-Position: refs/heads/master@{#42928}
-
- 31 Jan, 2017 2 commits
-
-
bmeurer authored
We were missing a case for Tagged->TaggedSigned conversions when the input type is known to be Type::SignedSmall. BUG=chromium:687029 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2666863002 Cr-Commit-Position: refs/heads/master@{#42809}
-
bmeurer authored
We cannot eliminate unused CheckFloat64Hole nodes, since loading from a holey array can have side-effects, i.e. triggering getters in the prototype chain. R=mvstanton@chromium.org BUG=chromium:686737 Review-Url: https://codereview.chromium.org/2665123002 Cr-Commit-Position: refs/heads/master@{#42806}
-
- 27 Jan, 2017 1 commit
-
-
bmeurer authored
The StringIndexOf operation is pure on the JS level, but the actual stub call must be in the effect chain later so that the Scheduler doesn't place it inside some allocation region (The %StringIndexOf runtime function may trigger a GC for string flattening). BUG=chromium:685580 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2657243002 Cr-Commit-Position: refs/heads/master@{#42736}
-
- 16 Jan, 2017 1 commit
-
-
bmeurer authored
BUG=chromium:679378 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2634953002 Cr-Commit-Position: refs/heads/master@{#42365}
-
- 02 Jan, 2017 1 commit
-
-
bmeurer authored
When Crankshaft compiles a keyed load to arguments, it disabled optimization unless the KEYED_LOAD_IC for the access was monomorphic. But that's too restrictive, since it will also disable optimization for this function when the access is on a path that was never executed so far. This was spotted in the Node.js core function EventEmitter.prototype.emit, which was no longer optimizable with Crankshaft using latest V8. R=jarin@chromium.org BUG=v8:5790 Review-Url: https://codereview.chromium.org/2607303002 Cr-Commit-Position: refs/heads/master@{#42005}
-