For compile time indices, we can do some basic sanity checking.

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

Dramatically speeds up builds when switching build flags.

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

Made the following changes:
 * Changed our multi-line strings to use C++11 raw string literals
 * Added argument-less macros for checking if GL or EGL had an error.
 * Made checkCompileFails return the error log, in case a test wants to
   ensure a specific failure is reported.
 * Made some more tests use the new MakeShader function.

Bug chromium:977665

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

This function behaved differently on different architectures. Reimplement using mostly integer arithmatic.

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

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

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

Change-Id: I4a1b1a981096fbda616101b7d47bf8f82481c64b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33509
Presubmit-Ready: Lingfeng Yang <lfy@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Lingfeng Yang <lfy@google.com>

b/135141616

Change-Id: Ia3c804c0bef7a000a54359d24dcd8bacc063a121
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33508Tested-by: Lingfeng Yang <lfy@google.com>
Kokoro-Presubmit: Lingfeng Yang <lfy@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

This texture format is needed to run the PowerVR Glass demo

Bug: b/136178423
Tests: dEQP-VK.*r8_srgb*

Change-Id: Ifff800e25db69daf099ce9c748a6c16de6d93db1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33449Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Hernan Liatis <hliatis@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

To still produce the class-memaccess diagnostic on unintended cases,
suppress it only for our Memset<T> case and LLVM.

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

The STANDALONE preprocessor macro is only for controlling the loading of
a delay loaded DLL, on Windows.

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

This is heavily used in dEQP-VK.ssbo.*. Avoiding generating the scatter
is profitable on all non-AVX512-capable targets;
ScalarizeMaskedMemIntrin is incredibly slow.

Reduces runtime on dEQP-VK.ssbo.layout.random.all_shared_buffer.5 from
24s to 14s on my threadripper (on top of stack of other optimizations).

Bug: b/135609394
Change-Id: I2d6840522a5bd30b4fd532b9c7e2a4712879caa9
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33289Tested-by: Chris Forbes <chrisforbes@google.com>
Presubmit-Ready: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

Change-Id: I79303a65a2f578164d36917b503a1aed188cd2a2
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33448Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

LLVM claims to support atomic loads and stores of integers, pointers and floating point types, but certain backends cannot deal with floats.

Mimic what Clang does - bitcast to/from an equal width integer.

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

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

Cache keys must be guaranteed to have no uninitialized bits so that they
can be compared with memcmpy() and hash values can be computed from
their raw memory representation. We do this by calling memset(this, ...)
in the Memset<T> class used as the first base class. This is safe since
no other constructor has run yet (similar to doing placement new in
zeroed out memory). GCC 8.2's class-memset warning should thus not be
treated as an error.

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

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

For LLVM, uses the debugtrap intrinsic which is more debugging specific
than the trap intrinsic. The Subzero implementationuses a Trap
intrinsic. Both translate to 'int 3' on x86.

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

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>