- 17 Feb, 2021 1 commit
-
-
Seth Brenith authored
This is a reland of cf93071c Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
-
- 16 Feb, 2021 2 commits
-
-
Leszek Swirski authored
This reverts commit cf93071c. Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72777}
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit This change adds 16 new interpreter opcodes, kStar0 through kStar15, so that we can use a single byte to represent the common operation of storing to a low-numbered register. This generally reduces the quantity of bytecode generated on web sites by 8-9%. In order to not degrade speed, a couple of other changes are required: The existing lookahead logic to check for Star after certain other bytecode handlers is updated to check for these new short Star codes instead. Furthermore, that lookahead logic is updated to contain its own copy of the dispatch jump rather than merging control flow with the lookahead-failed case, to improve branch prediction. A bunch of constants use bytecode size in bytes as a proxy for the size or complexity of a function, and are adjusted downward proportionally to the decrease in generated bytecode size. Other small drive-by fix: update generate-bytecode-expectations to emit \n instead of \r\n on Windows. Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72773}
-
- 10 Feb, 2020 1 commit
-
-
Santiago Aboy Solanes authored
FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206}
-
- 11 Nov, 2019 1 commit
-
-
Jakob Gruber authored
The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440Reviewed-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@{#64888}
-
- 18 Jul, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
Nop bytecodes are required only for break locations in debugger. Since nop bytecode doesn't change program state we can remove all of them. There are at least two changes which this CL produce: - we don't provide break position when we load local variable (still provide when load variable from global), - we don't provide break position for statements without actual break positions (e.g. "a;") - these expressions should be super rare and user always can set breakpoint before or after this statement. More details in one pager: https://docs.google.com/a/google.com/document/d/1JXlQpfMa9vRojbE272b6GMBbrfh6m_00135iAUOJEz8/edit?usp=sharing Bug: v8:6425 Change-Id: I4aee73d497a84f7b5d89caa6dda6d3060567dfda Reviewed-on: https://chromium-review.googlesource.com/543161Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46742}
-
- 14 Jul, 2017 1 commit
-
-
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}
-
- 06 Jun, 2017 1 commit
-
-
Mythri authored
Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole / ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks. In the bytecode-graph builder they are handled by introducing a deopt point instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant bytecodes are removed since they are no longer required. Bug: v8:4280, v8:6383 Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1 Reviewed-on: https://chromium-review.googlesource.com/509613 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45720}
-
- 30 May, 2017 1 commit
-
-
Aleksey Kozyatinskiy authored
This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. Benefits (see test for details): - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. TBR=dgozman@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org,devtools-reviews@chromium.org,v8-reviews@googlegroups.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:5909 Change-Id: Ie84fa79afeed09e28cf8478ba610a0cfbfdfc294 Reviewed-on: https://chromium-review.googlesource.com/518116 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45598}
-
- 29 May, 2017 1 commit
-
-
Michael Achenbach authored
This reverts commit 7a9cc704. Reason for revert: Changes layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/15882 This is about: inspector/sources/debugger/source-frame-inline-breakpoint-decorations.html Original change's description: > [inspector] moved var initialization break location before init expression > > This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. > Benefits (see test for details): > - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), > - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. > > Bug: v8:5909 > Change-Id: I039d911903a2826c9859710a63ab0462c992e11b > Reviewed-on: https://chromium-review.googlesource.com/513926 > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45530} TBR=dgozman@chromium.org,marja@chromium.org,kozyatinskiy@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:5909 Change-Id: Ibf84401e8050d3c84db219d983de2c6bba0f697f Reviewed-on: https://chromium-review.googlesource.com/518102Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#45547}
-
- 25 May, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
This CL improves break locations for expressions like 'var a = <expr>'. Without CL we use <expr> position as break location for initialization statement, with this CL we use position of first character after '=' as position. Benefits (see test for details): - only one break in expressions which includes mix of property lookup and calls, e.g. var p = Promise.resolve().then(x => x * 2), - removed redundant break location for expressions like: let { x, y } = { x: 1, y: 2}. Bug: v8:5909 Change-Id: I039d911903a2826c9859710a63ab0462c992e11b Reviewed-on: https://chromium-review.googlesource.com/513926 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#45530}
-
- 08 May, 2017 1 commit
-
-
Adam Klein authored
This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
-
- 03 May, 2017 1 commit
-
-
Ross McIlroy authored
We only need to materialize the existing output register for a given register transfer if it is in a different equivalence set, otherwise we already have the value we want in the output register. BUG=v8:4280 Change-Id: Ic4966590ac10445180aff353940d2c93e6a818aa Reviewed-on: https://chromium-review.googlesource.com/493168Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45051}
-
- 25 Jan, 2017 1 commit
-
-
leszeks authored
Because it was confusing seeing U8(negative value). Review-Url: https://codereview.chromium.org/2640273002 Cr-Commit-Position: refs/heads/master@{#42662}
-
- 20 Oct, 2016 1 commit
-
-
adamk authored
Move hole check logic from full-codegen into scope analysis, and store the "needs hole check" bit on VariableProxy. This makes it easy to re-use in any backend: it will be trivial to extend the use of this logic in, e.g., full-codegen variable stores. While changing the signatures of the variable loading/storing methods in Ignition, I took the liberty of replacing the verb "Visit" with "Build", since these are not part of AST visiting. BUG=v8:5460 Review-Url: https://chromiumcodereview.appspot.com/2411873004 Cr-Commit-Position: refs/heads/master@{#40479}
-
- 04 Oct, 2016 1 commit
-
-
neis authored
This removes the execute_ flag, which was always the negation of top_level_. R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2390163003 Cr-Commit-Position: refs/heads/master@{#39961}
-
- 30 Sep, 2016 1 commit
-
-
rmcilroy authored
There are only a few occasions where we allocate a register in an outer expression allocation scope, which makes the costly free-list approach of the BytecodeRegisterAllocator unecessary. This CL replaces all occurrences with moves to the accumulator and stores to a register allocated in the correct scope. By doing this, we can simplify the BytecodeRegisterAllocator to be a simple bump-pointer allocator with registers released in the same order as allocated. The following changes are also made: - Make BytecodeRegisterOptimizer able to use registers which have been unallocated, but not yet reused - Remove RegisterExpressionResultScope and rename AccumulatorExpressionResultScope to ValueExpressionResultScope - Introduce RegisterList to represent consecutive register allocations, and use this for operands to call bytecodes. By avoiding the free-list handling, this gives another couple of percent on CodeLoad. BUG=v8:4280 Review-Url: https://codereview.chromium.org/2369873002 Cr-Commit-Position: refs/heads/master@{#39905}
-
- 06 Sep, 2016 1 commit
-
-
leszeks authored
For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
-
- 19 Jul, 2016 1 commit
-
-
oth authored
Original issue's description: > [interpeter] Move to table based peephole optimizer. > > Introduces a lookup table for peephole optimizations. > > Fixes some tests using BytecodePeepholeOptimizer::Write() that should > have been update to use BytecodePeepholeOptimizer::WriteJump(). > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/f4234422b93b21a286b0f31799009bcbe8b90b9e > Cr-Commit-Position: refs/heads/master@{#37819} BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2164583002 Cr-Commit-Position: refs/heads/master@{#37866}
-
- 18 Jul, 2016 2 commits
-
-
oth authored
Revert of [interpeter] Move to table based peephole optimizer. (patchset #38 id:730001 of https://codereview.chromium.org/2118183002/ ) Reason for revert: Break MIPS port. Original issue's description: > [interpeter] Move to table based peephole optimizer. > > Introduces a lookup table for peephole optimizations. > > Fixes some tests using BytecodePeepholeOptimizer::Write() that should > have been update to use BytecodePeepholeOptimizer::WriteJump(). > > BUG=v8:4280 > LOG=N > > Committed: https://crrev.com/f4234422b93b21a286b0f31799009bcbe8b90b9e > Cr-Commit-Position: refs/heads/master@{#37819} TBR=rmcilroy@chromium.org,machenbach@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review-Url: https://codereview.chromium.org/2161563002 Cr-Commit-Position: refs/heads/master@{#37821}
-
oth authored
Introduces a lookup table for peephole optimizations. Fixes some tests using BytecodePeepholeOptimizer::Write() that should have been update to use BytecodePeepholeOptimizer::WriteJump(). BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2118183002 Cr-Commit-Position: refs/heads/master@{#37819}
-
- 09 Jun, 2016 1 commit
-
-
oth authored
With this change the bytecode array builder only emits expression positions for bytecodes that can throw. This allows more peephole optimization opportunities and results in smaller code. BUG=v8:4280,chromium:615979 LOG=N Review-Url: https://codereview.chromium.org/2038323002 Cr-Commit-Position: refs/heads/master@{#36863}
-
- 27 May, 2016 1 commit
-
-
oth authored
Online optimization stage for reducing redundant transfers between registers. BUG=V8:4280 LOG=N Review-Url: https://codereview.chromium.org/1997653002 Cr-Commit-Position: refs/heads/master@{#36551}
-
- 23 May, 2016 1 commit
-
-
oth authored
The original peephole optimizer logic in the BytecodeArrayBuilder did not respect source positions as it was written before there were bytecode source positions. This led to some minor differences to FCG and was problematic when combined with pending bytecode optimizations. This change makes the new peephole optimizer fully respect source positions. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1998203002 Cr-Commit-Position: refs/heads/master@{#36439}
-
- 11 May, 2016 1 commit
-
-
oth authored
Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
-
- 21 Mar, 2016 1 commit
-
-
oth authored
This change introduces wide prefix bytecodes to support wide (16-bit) and extra-wide (32-bit) operands. It retires the previous wide-bytecodes and reduces the number of operand types. Operands are now either scalable or fixed size. Scalable operands increase in width when a bytecode is prefixed with wide or extra-wide. The bytecode handler table is extended to 256*3 entries. The first 256 entries are used for bytecodes with 8-bit operands, the second 256 entries are used for bytecodes with operands that scale to 16-bits, and the third group of 256 entries are used for bytecodes with operands that scale to 32-bits. LOG=N BUG=v8:4747,v8:4280 Review URL: https://codereview.chromium.org/1783483002 Cr-Commit-Position: refs/heads/master@{#34955}
-
- 25 Feb, 2016 1 commit
-
-
ssanfilippo authored
Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
-