An initial investigation of using GraphAssembler in JSCallReducer.
This CL ports two simple reductions (ReduceMathUnary,
ReduceMathBinary) as well as a slightly more involved reduction with
branching control flow (ReduceStringPrototypeSubstring). The graph
assembler abstracts away the details of maintaining effect and control
edges. Resulting code ends up looking very similar to CSA.
Newly introduced:
- Typing through TNode.
- IfBuilder1 for nicer if-then-else sequences that return exactly 1
value. Future CLs will add more convenience builders that follow this
pattern.
- Many small readability improvements through helper functions.
Bug: v8:9972
Change-Id: Iaa186b76c006e07c8d69a74f340a4912577a32a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914204
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65095}
It could also be a DeadValue.
A regression test will take a while but the fix is straightforward.
Bug: chromium:1027045
Change-Id: I49a66668b7189b7ea7d6d79d514b9e0de3edc966
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928853
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65094}
This is an unmodified reland of 3c98a2a36a.
The actual issue was fixed in https://crrev.com/c/1926769.
Original change's description:
> [wasm] Prevent breakpoints on nonbreakable positions
>
> If a breakpoint is set on a non-breakable position, the wasm interpreter
> just stores the value 0xFF (kInternalBreakpoint) in the function body
> (actually, a copy of the function body). This might overwrite immediates
> and cause subsequent failures in the wasm interpreter.
>
> In JavaScript, breakpoints are just forwarded to the next breakable
> position. This CL implements the same for WebAssembly.
> A cctest tests this behavior, and the existing
> wasm-stepping-byte-offsets.js inspector test is extended to also set the
> breakpoint within an i32 constant immediate.
>
> R=leese@chromium.org, mstarzinger@chromium.org
> CC=bmeurer@chromium.org
>
> Bug: chromium:1025184
> Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65070}
Bug: chromium:1025184
Change-Id: I5e16df645bbacf039b7a5e55a0c2a64cdb4c6a32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926152
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65093}
Follow-up to c968607e12 to make
LayoutTests happy.
Tbr: verwaest@chromium.org
Change-Id: I02758faa8ed1f06f1faf615047a40ec115887a4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928856
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65092}
&vector[i] is invalid unless 0 <= i < vector.size(). This means:
- &vector[0] is invalid if the vector is empty.
- &vector[vector.size()] is not a valid way to point past the end of the
vector.
Fix these to use vector.data() + vector.size() which is the defined to
get begin and end pointers for a vector.
Bug: chromium:1027059
Change-Id: Ife1f0e64807b32ebdca66dba8ffc206d90a0de75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929071
Auto-Submit: David Benjamin <davidben@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65091}
Hashing should ignore the signedness of the type, since different
platforms might define standard types like {char} as either signed or
unsigned. This leads to problems if hashes are included in test
expectations, see https://crrev.com/c/1926032 and
https://crbug.com/1025184#c26.
This CL avoid such problems by always treating the input as signed
values. This also reduces binary size, since the instantiations for
int8_t and uint8_t are identical now and are folded together by the
compiler / linker.
R=jkummerow@chromium.org
Bug: chromium:1025184
Change-Id: I3fee4d8662dd1c31cd6483639fe4edd4511662c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926769
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65090}
Also some cleanup reordering of instruction codes.
Bug: v8:9813
Change-Id: I35caad0b84dd5824090046cba964454eac45d5d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925613
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65088}
We now keep the same percentage of the window occupied by the panel
when toggling Maximize (both maximizing, or un-maximizing). This
also means that it no longer forces the side panels open when
toggling maximizing.
Also took the opportunity and cleaned up names and resizer.ts.
Bug: v8:7327
Change-Id: I60b574a833f3059e447aa17fae8a687d32ac29d5
Notry: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903970
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65085}
After searching now we are focused on the svg, which allows using
the keyboard shortcuts after searching.
Bug: v8:7327
Change-Id: I57f5490ecb9858971aefae66b9808460108dc936
Notry: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925147
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65084}
... by making explicit that the value is a Smi.
Bug: v8:9989
Change-Id: I9f65030cf665e16c2fb22f5f77e25daf3cfb1cf1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924260
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65081}
This reverts commit 2072772592.
Reason for revert: Many bugs/crashes, https://crbug.com/v8/9999https://crbug.com/1026500https://crbug.com/1026514
Original change's description:
> [liftoff] Use stack slot offsets instead of indices
>
> Spill/fill now take offsets instead of indices. We provide a
> helper, GetStackOffsetFromIndex, for callers. This is currently only
> useful while slot sizes are still fixed to 8 bytes.
>
> StackTransferRecipe's RegisterLoad now works in terms of offset.
>
> LiftoffStackSlots work in terms of offset as well.
>
> TransferStackSlot currently still works in terms of indicies, but can be
> converted to use offsets in a subsequent change.
>
> Bug: v8:9909
> Change-Id: If54fb844309bdfd641720d063135dd59551813e0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1922489
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65049}
TBR=clemensb@chromium.org,zhin@chromium.org
Change-Id: I972b72346c87d1d55488911938e3f3cdbe69abe5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9909
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925560
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65080}
This change defines a way that v8_debug_helper can describe object
fields which are packed structs, and uses it for the "descriptors" field
in DescriptorArray.
In more detail:
- debug-helper.h (the public interface for v8_debug_helper) adds a size
and an optional list of struct properties to ObjectProperty.
- debug-helper-internal.h mirrors those changes to the internal class
hierarchy which maintains proper unique_ptr ownership.
- In src/torque/class-debug-reader-generator.cc,
- Some existing logic is moved into smaller functions.
- New logic is added to generate the field list for structs. Example
output is included in a comment above the function
GenerateGetPropsChunkForField.
Bug: v8:9376
Change-Id: I531acac039ccb42050641448a4cbaec26186a7bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1894362
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65079}
They have to be in sync, so this patch updates both systems.
Bug: v8:4153
Change-Id: I09252e41a710e79f823fe6818c1c6c0038faeb31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903434
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65078}
It seems like they were originally added in https://crrev.com/23654026
(Sep 2013) to break dependences in the OOO pipeline. This code pattern
was then later copied for other instructions too
(https://crrev.com/1424333002).
The reason for the xorpd is not mentioned in the code though, and I
found no other compiler doing this. So maybe it's obsolete by now, and
only increases code size.
Let's remove them and see if we get any performance regressions.
R=ahaas@chromium.orgCC=yangguo@chromium.org
Change-Id: I0e6d65afa67f0ee286e5b0ba95c91092c5261c8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926427
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65077}
This reverts commit 3c98a2a36a.
Reason for revert: Fails on arm: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/12134
Original change's description:
> [wasm] Prevent breakpoints on nonbreakable positions
>
> If a breakpoint is set on a non-breakable position, the wasm interpreter
> just stores the value 0xFF (kInternalBreakpoint) in the function body
> (actually, a copy of the function body). This might overwrite immediates
> and cause subsequent failures in the wasm interpreter.
>
> In JavaScript, breakpoints are just forwarded to the next breakable
> position. This CL implements the same for WebAssembly.
> A cctest tests this behavior, and the existing
> wasm-stepping-byte-offsets.js inspector test is extended to also set the
> breakpoint within an i32 constant immediate.
>
> R=leese@chromium.org, mstarzinger@chromium.org
> CC=bmeurer@chromium.org
>
> Bug: chromium:1025184
> Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65070}
TBR=mstarzinger@chromium.org,clemensb@chromium.org,bmeurer@chromium.org,leese@chromium.org
Change-Id: I7468ea3b15fecccdea521308325cf4851e0a0396
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1025184
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926032
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65074}
This is necessary because the spec changed.
R=mstarzinger@chromium.org
Bug: v8:9865
Change-Id: Id8b4d85eafcf368d591666907036e6aa54664e63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921794
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65072}
Previously the fast path only asserted the correct instance types; but
when reading lastIndex we additionally rely on a specific object
shape. This is checked by HasInitialRegExpMap().
Bug: chromium:1024758
Change-Id: I0b401ffb246dd47153caf798446d8d41bc84bc8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924354
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65071}
If a breakpoint is set on a non-breakable position, the wasm interpreter
just stores the value 0xFF (kInternalBreakpoint) in the function body
(actually, a copy of the function body). This might overwrite immediates
and cause subsequent failures in the wasm interpreter.
In JavaScript, breakpoints are just forwarded to the next breakable
position. This CL implements the same for WebAssembly.
A cctest tests this behavior, and the existing
wasm-stepping-byte-offsets.js inspector test is extended to also set the
breakpoint within an i32 constant immediate.
R=leese@chromium.org, mstarzinger@chromium.org
CC=bmeurer@chromium.org
Bug: chromium:1025184
Change-Id: Ia2706f8f1c3d686cbbe8e1e7339d9ee86247bb4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925152
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65070}
That's possible because JS builtins are JSFunctions that embed a
NativeContext.
Bug: v8:7793
Change-Id: Id2bf7844fcfb53df733100f1e3e554f25a78482a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926150
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65068}
In {EmptyBackingStore}, the {free_on_destruct} flag was not set as an
optimization: Since there is no memory, it also does not have to be
freed. However, this flag has a side-effect: any backing store where
this flag is not set is considered {external}. The {external} flag is
mis-used by blink to indicate if ArrayBuffers need to be wrapped or not.
With this CL we set the {free_on_destruct} flag in {EmptyBackingStore},
but we change the ArrayBufferTracker to just ignore empty backing
stores.
R=ulan@chromium.org
Bug: chromium:1008840
Change-Id: I1552a6e013c8b23f39fba1c2d9d9c61dc30c0c74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924263
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65067}
Bug: v8:9989
Change-Id: I6923f99398c0a1c8b447e18e0416a2630a09ee5d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924259
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65065}
When importing a JS function, Wasm tries to guess the type of function
(parameters & strict/sloppy mode). This can sometimes fail which leads
to re-creation of the wrapper. With this change, the same wrapper can
be used for strict and sloppy mode requiring the re-creation only on
arity mismatch.
R=mstarzinger@chromium.org
Change-Id: I77ec2b853153dec0772873cfb60c064a74065732
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921793
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65064}
Don't overwrite WATCHLISTS each time with a checkout from the latest
release branch as that means it will never pick up changes from
master.
No-Try: true
Bug: chromium:832032
Change-Id: I3a9231369caa9a6591acb9b7f0c76dc031ab9178
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926029
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65063}
Bug: v8:9972
Change-Id: Ia85520eea8d3bcadc2573c16bf2778b1c3ff0c5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926028
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65061}
"preparser" is a legacy test-suite written in Python. "cctest/test-parsing"
provides the same coverage and more for the preparser.
This CL removes "preparser" stand-alone test-suite
R=verwaest@chromium.org
CC=machenbach@chromium.org
Bug: v8:10001
Change-Id: I1823967e654e8d6d9e42eadfd667f90074d57ba9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926027
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65059}
This reverts commit f2a74165bf.
Reason for revert: Clusterfuzz
Bug: chromium:1026479
Original change's description:
> [regexp] Re-execute regexp when '.indices' is accessed.
>
> Instead of storing a pointer to the last_match_info, which may
> change, this cl modifies JSRegExpResult to store a pointer to
> the original JSRegExp which generated it, as well as additional
> data needed to re-execute the match.
>
> Basically a straight copy and tidy off jgruber@'s prototype:
> https://chromium-review.googlesource.com/c/v8/v8/+/1876810
>
> Bug: v8:9548
> Change-Id: I11b7deae681b8287e41e8d0e342291ff484751fb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910129
> Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65053}
TBR=jgruber@chromium.org,joshualitt@chromium.org
Change-Id: I6294e3d7ac0b3e2bd9404697823b8d3cc2545c16
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9548
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925651
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65057}
Minor cleanup: some classes in Torque don't yet have any definitions for
their fields, so it doesn't make sense to emit field layout macros for
those classes.
Bug: v8:7793
Change-Id: Iee38aa3cbe684f4a63329a676e2e94944dc05de1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925010
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65054}
Instead of storing a pointer to the last_match_info, which may
change, this cl modifies JSRegExpResult to store a pointer to
the original JSRegExp which generated it, as well as additional
data needed to re-execute the match.
Basically a straight copy and tidy off jgruber@'s prototype:
https://chromium-review.googlesource.com/c/v8/v8/+/1876810
Bug: v8:9548
Change-Id: I11b7deae681b8287e41e8d0e342291ff484751fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910129
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65053}
These instructions should always treat inputs as signed, and saturate to
unsigned min/max values.
E.g. given -1, it should saturate to 0.
The spec text,
https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md#integer-to-integer-narrowing,
has been updated to describe this.
The changes here include codegen changes to ia32, x64, arm, and arm64,
changes to arm simulator, assembler, and disassembler to handle the case
of treating input as signed and narrowing to unsigned. The vqmovn
instruction can handle this case, our assembler wasn't allowing callers
to specify this.
The interpreter and scalar lowering are also fixed with this change.
Bug: v8:9729
Change-Id: I6f72baa825f59037f7754485df6a2964af59fe31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879423
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65051}
Spill/fill now take offsets instead of indices. We provide a
helper, GetStackOffsetFromIndex, for callers. This is currently only
useful while slot sizes are still fixed to 8 bytes.
StackTransferRecipe's RegisterLoad now works in terms of offset.
LiftoffStackSlots work in terms of offset as well.
TransferStackSlot currently still works in terms of indicies, but can be
converted to use offsets in a subsequent change.
Bug: v8:9909
Change-Id: If54fb844309bdfd641720d063135dd59551813e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1922489
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65049}
This is part 3 of Torquifying DescriptorArray: making it possible to use
the "descriptors" indexed field from code written in Torque. A small
macro EnsureArrayLengthWritable is converted to demonstrate the new
functionality.
This CL also introduces the arrow token `->` and desugars a->b to (*a).b
so that the new builtin looks a little cleaner.
Bug: v8:7793
Change-Id: I84eaa97f664aa67273866760e6ede4346a3ee2f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900332
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65046}
