Previously SIMD::Load would assume that all pointers are 4-byte aligned.
However, texel pointers generated by SpirvShader::GetTexelAddress are
not aligned for small formats.

Add an alignment parameter to SIMD::Load and use it in EmitImageRead.

Bug: b/135954761
Change-Id: I6a420049e98f42a68960d557dee933fee9487af3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33328Tested-by: Chris Forbes <chrisforbes@google.com>
Presubmit-Ready: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Use Memset<T> as the first base class of cache key types to ensure they
get initialized before any other base classes or members get
constructed.

Bug: b/134932616
Change-Id: I8f28252696d6e017db11da068180d2425cdf1d57
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33249Tested-by: Nicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

In particular this fixes Blitter::Options state having uninitialized
bits after the bitfield, and Blitter::State having uninitialized padding
bytes after Options so 'sourceFormat' is 32-bit aligned.

Defines a Memset<T> class to be used as the first base class of cache
key types, which makes it explicit that their underlying memory will be
fully initialized before any member constructors are run.

Also adds is_memcmparable<T> for checking if memcmp() can be used to
implement operator==() for cache keys. It's equivalent to
std::is_trivially_copyable except it provides a fallback for STL
implementations that don't support it.

Bug: b/134932616
Change-Id: I6569e78b380e67aee02d5bfd39d80d210bd225fd
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32929
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

These are used instead of the *f float forms on x86.
We should probably investigate why, but having LLVM attempting, failing and crashing to resolve functions under any circumstances is Not Good.

Bug: b/126873455
Change-Id: Ic31866ebea7deba2dc29a9a4fb54a457b13e622a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33214Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Fixes a number of dEQP tests that use over 4kB's of allocas on Win32.

Bug: b/135866359
Change-Id: I0e50eea6a70d284c8d653fb070f4ae982c02914c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33213Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

In MSVC 2019 __LINE__ is treated as a long, and will now error (C2397) if the literal is narrowed to the initializer type. Lots of people moaning that there's no way to disable this or treat it as a warning.

Another attempt at working around variadic macro bugs in MSVC. Previously, none of the RR_WATCH or RR_LOG macros would compile if used. They now work.

Change-Id: I05312df1d88167d44f2582eb6eb45a0085d09434
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33212Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

This was being allocated with no particular alignment, causing spurious crashes when vectors were loaded or stored in the stack frame.

Bug: b/135691587
Change-Id: I0240fdeb08df17dbbc156e508013376e15c514b4
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33211
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Verification can take upwards of 10% of a dEQP test's execution time.

Verification is enabled for Kokoro builds and unit tests as silently regressing would be a Bad Thing.

Verification is also enabled for debug (!NDEBUG) builds.

Bug: b/135609394
Change-Id: I6c354c40f524e1e8f3e08f24129b7e008163b4bd
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33215
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

The data layout was only being set right before lowering to machine
code. The optimization passes need accurate data layout info as well.

Bug: b/135691587
Change-Id: Ic1524d57bb6d8d0eb725e33d27e100a6286f1571
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33309Tested-by: Nicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

If a viewport is outside maximum bounds of the render buffer,
then there's nothing to render, unless transform feedback is active.
If transform feedback is active, then we zero out the viewport.

This is to prevent an overflow in viewport-dependent calculations.

Bug chromium:969353

Change-Id: Ibc65447ca2b46e942b9934304a56b90f261e2bf1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33068Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Sean Risser <srisser@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Change-Id: I798eaf42247e4bf326eb5ee75eb7ef2305342dfb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33208Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Bug: b/135609394
Change-Id: Ica8267cf4e2c09952282f0902c781c2544e4564c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33188
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Bug: b/135609394
Change-Id: I0e337f99dacc997685fab39183f902ca3d988492
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33170Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Has wider support than gather / scatter, and is faster.

Bug: b/135609394
Change-Id: Ib1435331f3130fbef7cbf9eaf1c0c2570a0ec2a1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33169Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

This wasn't considering that the offsets are bytes and not whole words.
Another bug that wasn't caught by dEQP (this would only affect atomic load / stores).

Bug: b/131224163
Change-Id: I6356da3ecb86cdbb7a25667fe617f650019950e2
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33168Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

This serves two purposes:
1. All rr::Variables held in these containers are destructed, preventing pointless materialization.
2. Frees memory that will never be used again.

Bug: b/135609394
Change-Id: Ia1e3e108d2594685320e9a1d96c1d47532f05c0c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33148Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Reduces the amount of LLVM IR produced when the limits are compile-time known.

Reduces full test execution time of dEQP-VK.ubo.random.all_out_of_order_offsets.45 by about half.

For dEQP-VK.ubo.random.all_shared_buffer.48:
• Reduces number of pre-opt LLVM IR instructions by about 40%.
• Reduces full test execution time by about 30%

Bug: b/135609394
Change-Id: I3c46d56910bb8373a355ab8d570d3093944afc84
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33053Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Currently does not do anything differently, but is a stepping stone to optimizations.

Bug: b/135609394
Change-Id: I9020d4819b0e6f4bdd9564c2407c1903b7f33f4f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33052Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

This should have been true for the constructor that takes a dynamic offset. Surprising that this hadn't caused any tests to fail.

Bug: b/131224163
Change-Id: I00fcfb99e265c7a378c40817ae8f84104e4a2a3d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33051Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Swiftshader is failing to compile in GCC with ARM32. There are several
build units mising.
../../../chromium-77.0.3824.6/third_party/swiftshader/third_party/llvm-7.0/llvm/lib/Target/ARM/ARMParallelDSP.cpp:296: error: undefined reference to 'llvm::isConsecutiveAccess(llvm::Value*, llvm::Value*, llvm::DataLayout const&, llvm::ScalarEvolution&, bool)'
../../../chromium-77.0.3824.6/third_party/swiftshader/third_party/llvm-7.0/llvm/lib/Target/ARM/ARMParallelDSP.cpp:192: error: undefined reference to 'llvm::LoopAccessInfo::LoopAccessInfo(llvm::Loop*, llvm::ScalarEvolution*, llvm::TargetLibraryInfo const*, llvm::AAResults*, llvm::DominatorTree*, llvm::LoopInfo*)'
../../../chromium-77.0.3824.6/third_party/swiftshader/third_party/llvm-7.0/llvm/lib/Target/ARM/ARMTargetMachine.cpp:386: error: undefined reference to 'llvm::createLowerAtomicPass()'
collect2: error: ld returned 1 exit status

Bug: chromium:972766
Change-Id: I639ea516de0fbfe43697c84aac1a67c40b9c4838
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33210Tested-by: José Dapena Paz <jose.dapena@lge.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

We were creating SpirvShader objects for every shader stage of the
pipeline, each with their own unique serial ID. This caused us to
compile the same SPIR-V code over an over again when multiple pipelines
are created from the same shader module(s).

This change essentially moves the serial ID to the shader module. Things
that still require us to recompile code from the same shader module are
the entry point specification, and specialization constants. The former
is taken into account by using a 64-bit ID consisting of the module ID
and entry point ID. For the latter we assume any use of specialization
constants will result in a unique SPIR-V binary. This is conservative
and may still lead to unnecessary recompiles.

This change also minimizes the state passed to SpirvShader, to prevent
specialization on state not taken into account by the routine caches.

Bug: b/135609394
Tests: dEQP-VK.pipeline.render_to_image.core.*.huge.*
Change-Id: I204e812265067462f8019af9f6b7b3067ef5dc7f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33109
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

A few things:
- The library wasn't located in the provided path
- The function pointers weren't using the convention call
- The libraries built from Visual Studio weren't taken into
  account (probably only those generated from the CMake
  generated project were loadable)

Change-Id: I7f9cc9aee920747b4bab77286ba811b33982cece
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33128Tested-by: Alexis Hétu <sugoi@google.com>
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Change-Id: Ide85746f57ff8b37aebd5d17fba4ad0fffc762ce
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33108Tested-by: Alexis Hétu <sugoi@google.com>
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Modified VkNonDispatchableHandle so that it's a plain old data type.
By making sure VkNonDispatchableHandle is POD, it may benefit from
the same rules and register usage as the default object handles.

Bug b/129979580

Change-Id: I8aea419df8a6ee2ff95717424f3344e1c317fb28
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32989Tested-by: Alexis Hétu <sugoi@google.com>
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Change-Id: Ibd89bd79fec1e9e83c1f4201f1e789e90f773f08
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33049
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

The previous traversal could create huge pending lists of duplicate-blocks, to just skip over them.
This was due a couple of factors, including BFS traversal and always appending the downstream blocks to the queue.

There's no particular reason to do BFS traversal, so perform DFS traversal instead, and check the downstream blocks haven't been processed already before enquing.

Fixes pending lists reaching counts as high as 1e7 for tests such as dEQP-VK.spirv_assembly.instruction.compute.opphi.nested -
making these tests much faster to pass and drastically reducing peak memory usage.

Bug: b/135512559
Change-Id: Ibbfa03e582f08d6b41e6c8496d05b8b4027b31b6
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32951Reviewed-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Change-Id: I07234873cb8b64a158cd777d231367d56daf4255
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33069Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Stuart Morgan <stuartmorgan@google.com>

We the WARNINGS_AS_ERRORS CMake flag to treat all warnings as errors.

This change demotes the cherry-picked warnings-as-errors to just regular warnings, which can be optionally treated as errors like every other warning (WARNINGS_AS_ERRORS defaults to enabled).

Based on the discussions:
https://swiftshader-review.googlesource.com/c/SwiftShader/+/29810/6#message-de0432365b25c83372bac2f6528c79174aef0f6b
and
https://swiftshader-review.googlesource.com/c/SwiftShader/+/30191/2/CMakeLists.txt#248

Bug: b/135472272
Change-Id: I8aa37d79b9263560f9ff55ad4817f66ded6960ee
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32953
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Only use the upper 8 bits of the 16 bit fields when reading
and outputting 8 bit values in order to get exact
representations of x/255 for each possible 8 bit value.

Bug: swiftshader:122
Bug: b/129523279

Change-Id: I0cd54eb325c24f2fc5a53f12a0b90696024ca9d1
Tests: dEQP-VK.memory.pipeline_barrier.all.*
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33028Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Clang 4.0.1 is less than two years old and still in widespread use.
It doesn't support some of the more recent diagnostic warnings.

Bug: b/130335507
Change-Id: I68c6270c2e90c50b1de1657e16e914c89b336952
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/30191Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

Bug: b/135298866
Change-Id: Ic8d2375ae7e7ee8c521f8c4c1ca6ec44db9fb8be
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32988Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

This should disable code generation of exception handling, which we do not require.

Bug: b/135298866
Change-Id: I081d4317d7cdad6a9101db026bb72e4a09fb874c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32949
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Change-Id: I90295a7fae4a22572fc3abd551f7bf0371a72603
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32950Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

- Simplified VkNonDispatchableHandle as much as possible so
  that it's just a wrapper over a uint64_t
- Centralized casting logic in vkObject.hpp
- Explicitly changed "Cast" to "vk::Cast" to differentiate
  from vk::<object>::Cast
- Moved VkDescriptorSet operators from VulkanPlatform.h to
  VkDescriptorPool.cpp

Bug b/129979580

Change-Id: I4fe5fcfe56029c21594088d274bae862999597ad
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32928Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Change-Id: I794938bed33ea09cee733b34b55b29f04ca2751d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32948Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Fixes most warnings using the Visual Studio C++ 64 bit compiler.
Should be noop

Bug b/132445520

Change-Id: I7844062244478b39299729cf4e4c0b647e2f5b14
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/31150Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Bug: b/125909515
Change-Id: I35e1c54590fadfe5fa49d33552e0a4b4f8c892ee
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32849
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

OpImageFetch/Read/Write can have an optional 'Sample' operand which
indicates the sample index to operate on. It is orthogonal to other
operands so it is indicated by a new Boolean field in
sw::SamplerFunction and SpirvShader::ImageInstruction. The offset
operand was also turned into a Boolean field / component count.

The sample index is not wired up to be taken into account by the Fetch
sampling routine yet. OpImageRead already had support for the Sample
operand, but OpImageWrite does not.

Bug: b/135265531
Tests: dEQP-VK.pipeline.multisample.sampled_image.*
Change-Id: I20f50a888436775b996221e8283a4c4ab7f28e17
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32908Tested-by: Nicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

This updates LLVMReactor to provide for PPC64 little endian support. It
also adds an #ifdef condition to an assert macro, since
llvm::sys::getHostCPUFeatures will always return false on non-x86 and
ARM Linux platforms per
'third_party/llvm-7.0/llvm/lib/Support/Host.cpp'.

Bug: b/135175069
Signed-off-by: Colin Samples <colin.samples+git@gmail.com>
Change-Id: Idcdafe2f1bd934317ca9da09c99132f814fcf160
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32811
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Adds support for PPC64 LLVM build to CMake and gn

Bug: b/135175069
Signed-off-by: Colin Samples <colin.samples+git@gmail.com>
Change-Id: I3123a6e1457d3a5b2528516dadc019617afa4988
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32810
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>