- 01 Aug, 2017 1 commit
-
-
Caitlin Potter authored
Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:6187, v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org TBR=rmcilroy@chromium.org, neis@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48 Reviewed-on: https://chromium-review.googlesource.com/594500Reviewed-by:
Caitlin Potter <caitp@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#47058}
-
- 31 Jul, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit 409f84c9. Reason for revert: Breaks nosnap debug: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14288 Original change's description: > [async-iteration] implement spec-change to `yield` in async generators > > Per https://github.com/tc39/proposal-async-iteration/pull/102/files: > > AsyncGeneratorResolve no longer unwraps a value component. Instead, the > value is unwrapped before the builtin call via Await, allowing Promise > rejections to affect the generator control flow. > > Thus, all `yield <expr>` implicitly become `yield await <expr>`. > > Additionally, `return <expr>` becomes `return await <expr>`. Finally, when > the generator is resumed with `.return()`, the parameter passed to .return() > is awaited before generator execution properly continues). > > BUG=v8:5855 > R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org > > Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng > Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5 > Reviewed-on: https://chromium-review.googlesource.com/523844 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47011} TBR=rmcilroy@chromium.org,adamk@chromium.org,yangguo@chromium.org,neis@chromium.org,littledan@chromium.org,gsathya@chromium.org,caitp@igalia.com Change-Id: Ie6ad7e5410a3a89aab7a5dc68de36eb27b9354fe No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5855 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/593952Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47013}
-
Caitlin Potter authored
Per https://github.com/tc39/proposal-async-iteration/pull/102/files: AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is unwrapped before the builtin call via Await, allowing Promise rejections to affect the generator control flow. Thus, all `yield <expr>` implicitly become `yield await <expr>`. Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the generator is resumed with `.return()`, the parameter passed to .return() is awaited before generator execution properly continues). BUG=v8:5855 R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5 Reviewed-on: https://chromium-review.googlesource.com/523844 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#47011}
-
- 25 Jul, 2017 2 commits
-
-
Camillo Bruni authored
Empty Array literals are amongst the most commonly used literal types on our top25 page list. Using a custom bytecode we can drop the boilerplate for empty Array literals alltogether. However, we still need a proper AllocationSite to track ElementsKind transitions. Bug: v8:6211, chromium:746935 Change-Id: I891eaa778e4e81e138e483a65f04ae00ae30bd28 Reviewed-on: https://chromium-review.googlesource.com/580932Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#46875}
-
Ross McIlroy authored
Rather than using an ad-hock ownership model for ast_value_factory, use a shared_ptr. BUG=v8:5203 Change-Id: I5f2a573c8b175a3138ad8b01aa78bddadd16e6d3 Reviewed-on: https://chromium-review.googlesource.com/582628 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46874}
-
- 21 Jul, 2017 1 commit
-
-
Caitlin Potter authored
Simplify the model for generating Awaits, because the resume point is always immediately following the suspend point, and registers used are always the same for both operations. Includes a minor refactoring of BytecodeGenerator::VisitYield() to perform iterator result creation before the SuspendGenerator bytecode, rather than between SuspendGenerator and Return. This adds a small number of bytecodes for each yield. BUG=v8:2355, v8:5855 Change-Id: I4868b89a6bc1b251f887d2a45890c8fa19f7b089 Reviewed-on: https://chromium-review.googlesource.com/576286Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46820}
-
- 20 Jul, 2017 1 commit
-
-
Adam Klein authored
This reverts commit 4851745f. Reason for revert: Top crasher on Canary, see https://crbug.com/746935 Original change's description: > [literals] Introduce CreateEmptyArrayLiteral Bytecode > > Empty Array literals are amongst the most commonly used literal types on our > top25 page list. Using a custom bytecode we can drop the boilerplate for empty > Array literals alltogether. However, we still need a proper AllocationSite to > track ElementsKind transitions. > > Bug: v8:6211 > Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d > Reviewed-on: https://chromium-review.googlesource.com/567079 > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46752} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,cbruni@chromium.org,ishell@chromium.org,rmcilroy@google.com Bug: v8:6211, chromium:746935 Change-Id: Ibf19a923688c071d03bad8661a10e08f8414db56 Reviewed-on: https://chromium-review.googlesource.com/580193 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46804}
-
- 19 Jul, 2017 2 commits
-
-
Mythri authored
Inlining heuristics in Turbofan used ast node count. Bytecode size is a better approximation of the size of the graph than the ast node count. This cl changes the heuristics to use the bytecode size instead. Also removing the ast_node_count filed in the shared function info. It was used only for the inlining heuristics. Also removed the max_inlined_source_size flag which is no longer used. Bug: Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I8a2d2509c8e8d2779b33b817bb217de203d54ec3 Reviewed-on: https://chromium-review.googlesource.com/570055 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46771}
-
Camillo Bruni authored
Empty Array literals are amongst the most commonly used literal types on our top25 page list. Using a custom bytecode we can drop the boilerplate for empty Array literals alltogether. However, we still need a proper AllocationSite to track ElementsKind transitions. Bug: v8:6211 Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d Reviewed-on: https://chromium-review.googlesource.com/567079 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46752}
-
- 18 Jul, 2017 1 commit
-
-
Adam Klein authored
Change-Id: I091a1f4a1f2292b37a56520d0a5c46ac5781b459 Reviewed-on: https://chromium-review.googlesource.com/575515Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46725}
-
- 14 Jul, 2017 4 commits
-
-
Alexey Kozyatinskiy authored
Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
-
Ross McIlroy authored
Changes the ShouldUseFullCodegen to use the flags on the literal instead of the SharedFunctionInfo. Also moves the setting of the SFI flags based on the literal to be in the final stage of unoptimized compilation since they are no longer needed on the SFI during compilation. This is in preparation to enable shared function infos to be created after bytecode generation (to enable off-thread bytecode generation). BUG=v8:5203, v8:6409 Change-Id: I15754979a704123b56dad9e1dfd5c3bb468b85c7 Reviewed-on: https://chromium-review.googlesource.com/570249 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46684}
-
Caitlin Potter authored
SuspendFlags was originally used by the suspend operation to determine which field to record the bytecode offset of a suspended generator, and the value the generator was resumed with. For async generators, await operations would use a separate field, in order to preserve the previous yield input value. This was important to ensure `function.sent` continued to function correctly. As function.sent is being retired, this allows the removal of support for that. Given that this was the only real need for SuspendFlags in the first place (with other uses tacked on as a hack), this involves several other changes as well: - Modification of MacroAssembler AssertGeneratorObject. No longer accepts a SuspendFlags parameter to determine which type of check to perform. - Removal of `flags` operand from SuspendGenerator bytecode, and the GeneratorStore js-operator. - Removal of `flags` parameter from ResumeGeneratorTrampoline builtins. - Removal of Runtime functions, interpreter intrinsics and AccessBuilders associated with the [[await_input_or_debug_pos]] field in JSAsyncGeneratorObject, as this field no longer exists. - Addition of a new `Yield` AST node (subclass of Suspend) in order to prevent the need for the other SuspendFlag values. BUG=v8:5855 TBR=bmeurer@chromium.org Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487 Reviewed-on: https://chromium-review.googlesource.com/570485 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46683}
-
Caitlin Potter authored
This includes several changes. From most to least interesting: - No longer implement AwaitExpressions using a do-expression. - Reduces frame-size of async generators by not allocating temporary variables to hold results of Await epxressions. - Streamline and reduce generated bytecodes for Await. - Debugger no longer emits a debug::kCallBreakLocation breakpoint for the JS-builtin call performed for Await, and instead only emits such a breakpoint if the operand of Await is actually a call. - Push fewer parameters to Await* builtins, using the receiver for the first parameter (possible now that the CallRuntime invocation not part of the AST). - Adds a new Await AST node. No new members or anything, but it seemed palatable to avoid having `if (is_await())` in a number of VisitSuspend functions. BUG=v8:5855, v8:5099, v8:4483 R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org TBR=bmeurer@chromium.org Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf Reviewed-on: https://chromium-review.googlesource.com/558806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46666}
-
- 13 Jul, 2017 1 commit
-
-
Adam Klein authored
The tail call implementation is hidden behind the --harmony-tailcalls flag, which is off-by-default (and has been unstaged since February). It is known to be broken in a variety of cases, including clusterfuzz security issues (see sample Chromium issues below). To avoid letting the implementation bitrot further on trunk, this patch removes it. Bug: v8:4698, chromium:636914, chromium:724746 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c Reviewed-on: https://chromium-review.googlesource.com/569069 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46651}
-
- 12 Jul, 2017 2 commits
-
-
Camillo Bruni authored
By creating the boilerplate only on the second instantiation we cannot propagate back the elements transitions early enough. The resulting literals would change the initial ElementsKind one step too late and already pollute ICs that went to monomorphic state. - Disable lazy AllocationSites for literals containing arrays - Introduce new ComplexLiteral class to share code between ObjectLiteral and ArrayLiteral - RegexpLiteral now no longer needs a depth_ field Bug: v8:6517, v8:6519, v8:6211 Change-Id: Ia88d1878954e8895c3d00a7dda8d71e95bba005c Reviewed-on: https://chromium-review.googlesource.com/563305Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#46603}
-
jgruber authored
This CL moves collected source range information out of AST nodes and into a side table stored on ParseInfo. The side table is only created if block coverage is enabled, so there's almost no memory overhead in the standard case. Change-Id: I41871b8425ebbc6217d82d3ad26b5fc9e5d68ecb Reviewed-on: https://chromium-review.googlesource.com/566808 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46590}
-
- 11 Jul, 2017 2 commits
-
-
Georg Neis authored
yield* always has an argument. R=rmcilroy@chromium.org Bug: Change-Id: I5d14c0db05b1e1b873831e0f5a18ec479c1399c9 Reviewed-on: https://chromium-review.googlesource.com/566816Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46564}
-
jgruber authored
Switch statements generate a counter for each clause plus a continuation counter. Bug: v8:6000 Change-Id: Ic55a7efda54de1152bd5283d753119aa2764afbd Reviewed-on: https://chromium-review.googlesource.com/558249Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46550}
-
- 07 Jul, 2017 1 commit
-
-
jgruber authored
This adds support for exception control flow by adding a counter behind throw statements (never incremented), as well as a counter for catch and finally blocks. Bug: v8:6000 Change-Id: I3959772c889b543ab5e186ad7cd710e55a8aec23 Reviewed-on: https://chromium-review.googlesource.com/558993 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46476}
-
- 06 Jul, 2017 1 commit
-
-
Sathya Gunasekaran authored
Print the object that is being destructured and update the error message. Previously, d8> var [a] = {} (d8):1: TypeError: [Symbol.iterator] is not a function Now, d8> var [a] = {} (d8):1: TypeError: {} is not iterable Bug: v8:6513, v8:5532 Change-Id: I5cbfe7c7e20632bce1a48bd38a1b0c98d0ff0660 Reviewed-on: https://chromium-review.googlesource.com/557370 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46457}
-
- 05 Jul, 2017 1 commit
-
-
Caitlin Potter authored
Remove catch prediction tracking from AstNumbering, and replace it with a similar mechanism in the BytecodeGenerator visitor. BUG=v8:4483, v8:5855 Change-Id: I6351ba311716102fa55cd9ef29b9955ab4b11027 Reviewed-on: https://chromium-review.googlesource.com/559006Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#46419}
-
- 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}
-
- 26 Jun, 2017 3 commits
-
-
hans authored
This is towards closing the perf gap between the MSVC build (which uses link- time optimization) and Clang (where LTO isn't ready on Windows yet). We did a study (see bug) to see which non-inlined functions are hit a lot during render start-up, and which would be inlined during LTO. This should benefit performance in all builds which currently don't use LTO (Android, Linux, Mac) as well as the Win/Clang build. The binary size of chrome_child.dll increases by 2KB with this. BUG=chromium:728324 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng Review-Url: https://codereview.chromium.org/2950993002 Cr-Commit-Position: refs/heads/master@{#46229}
-
Michael Starzinger authored
R=marja@chromium.org BUG=v8:6408 Change-Id: Ied0c4d1aba18ec84d5feb02c3522b77759be216e Reviewed-on: https://chromium-review.googlesource.com/548636Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46226}
-
Georg Neis authored
R=mstarzinger@chromium.org Bug: Change-Id: Ica169da6e095abb79967687ae9a18db5c833f72e Reviewed-on: https://chromium-review.googlesource.com/546356Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46203}
-
- 25 Jun, 2017 1 commit
-
-
machenbach authored
Revert of Make some functions that are hit during renderer startup available for inlining (patchset #3 id:40001 of https://codereview.chromium.org/2950993002/ ) Reason for revert: Blocks roll: https://codereview.chromium.org/2954833002/ E.g.: https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_compile_dbg_ng/builds/449680 https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_compile_dbg_ng/builds/324953 Please include those chromium trybots on reland. Maybe missing symbol export? Original issue's description: > Make some functions that are hit during renderer startup available for inlining > > This is towards closing the perf gap between the MSVC build (which uses link- > time optimization) and Clang (where LTO isn't ready on Windows yet). We did > a study (see bug) to see which non-inlined functions are hit a lot during render > start-up, and which would be inlined during LTO. This should benefit performance > in all builds which currently don't use LTO (Android, Linux, Mac) as well as > the Win/Clang build. > > The binary size of chrome_child.dll increases by 2KB with this. > > BUG=chromium:728324 > > Review-Url: https://codereview.chromium.org/2950993002 > Cr-Commit-Position: refs/heads/master@{#46191} > Committed: https://chromium.googlesource.com/v8/v8/+/d00d52be1fce9c1bf5558c8b26bf984efd09e65b TBR=jochen@chromium.org,mstarzinger@chromium.org,rmcilroy@chromium.org,vogelheim@chromium.org,marja@chromium.org,mlippautz@chromium.org,thakis@chromium.org,hans@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=chromium:728324 NOTRY=true NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2955793002 Cr-Commit-Position: refs/heads/master@{#46195}
-
- 23 Jun, 2017 4 commits
-
-
hans authored
This is towards closing the perf gap between the MSVC build (which uses link- time optimization) and Clang (where LTO isn't ready on Windows yet). We did a study (see bug) to see which non-inlined functions are hit a lot during render start-up, and which would be inlined during LTO. This should benefit performance in all builds which currently don't use LTO (Android, Linux, Mac) as well as the Win/Clang build. The binary size of chrome_child.dll increases by 2KB with this. BUG=chromium:728324 Review-Url: https://codereview.chromium.org/2950993002 Cr-Commit-Position: refs/heads/master@{#46191}
-
jgruber authored
Drive-by-fixes: Singleton ranges past EOF, disable optimization for block count mode. Bug: v8:6000 Change-Id: I718891f8821285ce3d7d8360faaa91a43de5b93d Reviewed-on: https://chromium-review.googlesource.com/541300Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46168}
-
Michael Starzinger authored
This removes the --turbo flag and solely relies on the filter pattern provided via --turbo-filter when deciding whether to use TurboFan. Note that disabling optimization wholesale can still be done with --no-opt, which should be used in favor of --no-turbo everywhere. Also note that this contains semantic changes to the TurboFan activation criteria. We respect the filter pattern more stringently and no longer activate TurboFan just because the source contains patterns forcing use of Ignition via {AstNumberingVisitor::DisableFullCodegenAndCrankshaft}. R=rmcilroy@chromium.org BUG=v8:6408 Change-Id: I0c855f6a62350eb62283a3431c8cc1baa750950e Reviewed-on: https://chromium-review.googlesource.com/528121Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46167}
-
Tobias Tebbi authored
Async generator yield* is still desugared in the parser, to be moved to the BytecodeGenerator in a future CL. Bug: v8:6472 Change-Id: I8b33e2f9e931949f7375540099cd8ec3a6b27cf1 Reviewed-on: https://chromium-review.googlesource.com/539335 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46165}
-
- 22 Jun, 2017 3 commits
-
-
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}
-
Daniel Ehrenberg authored
In edge cases such as the following, sloppy-mode block-scoped function hoisting is expected to occur: eval(` with({a: 1}) { function a() {} } `) In this case, there should be the equivalent of a var declaration outside of the eval, which gets set to the value of the local function a when the body of the with is executed. Previously, the way that var declarations are hoisted out of eval meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL assignment. However, such a lookup mode meant that the object in the with scope received the assignment! This patch fixes that error by marking the assignments produced by the sloppy mode block scoped function hoisting desugaring so as to generate a different runtime call which skips with scopes. Bug: chromium:720247, v8:5135 Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748 Reviewed-on: https://chromium-review.googlesource.com/529230 Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46116}
-
Michael Starzinger authored
R=marja@chromium.org Change-Id: I8a1ad2e64f5ec755fe5ce5949bf9b455696bd3f4 Reviewed-on: https://chromium-review.googlesource.com/543056Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46115}
-
- 21 Jun, 2017 3 commits
-
-
Michael Starzinger authored
R=marja@chromium.org Change-Id: I3986d7a5627849ac09ff563fc57aac9bbaeaefa7 Reviewed-on: https://chromium-review.googlesource.com/543497 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#46102}
-
jgruber authored
This CL improves reported source range precision in a couple of ways: Source ranges are now standardized to consist of an inclusive start index and an exclusive end index (similar to what's reported for functions). For example: 0123456789 // Offset. { f(); } // Block represented as range {0,8}. Duplicate singleton ranges (i.e. same start and end offsets) are now merged (this only becomes relevant once jump statement coverage is added). For example: for (.) break; // Break- and loop continuation have same positions. SourceRangeScope incorrectly collected starting position (unconditionally) and end position (when no semi-colon was present). 01234567890123 // Offset. for (.) break // Loop body range is {8,13}, was {6,9}. Bug: v8:6000 Change-Id: I62e7c70cc894a20f318330a2fbbcedc47da2b5db Reviewed-on: https://chromium-review.googlesource.com/541358 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#46095}
-
Michael Starzinger authored
R=verwaest@chromium.org Change-Id: I39921052ddf0934f1a626f3e1e458280475ae265 Reviewed-on: https://chromium-review.googlesource.com/539515Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46083}
-
- 20 Jun, 2017 1 commit
-
-
Igor Sheludko authored
The initial implementation did not work in certain cases. For example, in the following case 'f' didn't have a shared name while it should have had an empty shared name: var f = (function() { return function() { return 42; } }(); The new implementation ensures that all anonymous functions have empty shared name and if any of them happen to be an object literal property value or an accessor function or a concise method then such a function is marked as having no shared name. Bug: v8:6459 Change-Id: I0f936afce0c152d91b2b41c1dc475a5ed841eca0 Reviewed-on: https://chromium-review.googlesource.com/538666Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#46026}
-
- 19 Jun, 2017 2 commits
-
-
jgruber authored
Track execution counts of the continuations of block structures (e.g. IfStatements) to capture cases in which execution does not continue after a block. For example: for (;;) { return; } // Never reached, tracked by continuation counter. A continuation counter only has a start position; it's range is implicitly until the next sibling range or the end of the parent range. Bug: v8:6000 Change-Id: I8e8f1f5b140b64c86754b916e626eb50f0707d70 Reviewed-on: https://chromium-review.googlesource.com/530846 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#46006}
-
Michael Starzinger authored
This removes both {BailoutId} as well as {TypeFeedbackId} numbers from almost all AST nodes. The only exception are {IterationStatement} nodes which still require an ID for on-stack replacement support. R=verwaest@chromium.org BUG=v8:6409 Change-Id: I5f7b7673ae5797b9cbc9741144d304f0d31d4446 Reviewed-on: https://chromium-review.googlesource.com/538792 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#45991}
-