This change set VkQueueFamilyProperties::timestampValidBits to non-zero
(64) to indicate support for timestamps.

It also enables the timestampComputeAndGraphics feature to indicate that
all graphics and compute queues (we only have a single one at the
moment) support timestamp queries. Note that applications often check
this aggregate flag instead of the individual queue family properties.

timestampPeriod was lowered from 60 to 1, since we're writing timestamps
with nanosecond granularity. Actually obtaining the time was already in
place, see QueryPool::writeTimestamp(), but it didn't put the query in
the 'available' state.

The clock was replaced with std::chrono::steady_clock, which typically
provides higher resolution than system_clock [1]. While it doesn't offer
wall clock related time, this is not a requirement of Vulkan timestamps.

Query::INVALID_TYPE was eliminated. Queries belong to a query pool which
takes a valid type at construction. This also allowed to eliminate
Query::prepare().

[1] https://www.modernescpp.com/index.php/the-three-clocks

Bug: b/142643809
Tests: dEQP-VK.pipeline.timestamp.*
Change-Id: Icb7c8c5ed78052eba9df630a4c1cb450bda7f85b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53488
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Also update the unittests to expect version 1.2.

Bug: b/147825369
Tests: dEQP-VK.*
Change-Id: Ib3bb07662140fa976ec2532124ab2d7337f34c55
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47348Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Sean Risser <srisser@google.com>
Commit-Queue: Sean Risser <srisser@google.com>

Vulkan 1.2 added several entry points, and even if SwiftShader doesn't
support the features that introduced them, dEQP requires they be
implemented regardless.

Test: dEQP-VK.api.version_check.entry_points
Bug: b/182287812
Change-Id: I0d90532e8e1508b71abc39c723167d9586d2cb84
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53468
Commit-Queue: Sean Risser <srisser@google.com>
Tested-by: Sean Risser <srisser@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Vulkan 1.2 requires that all implementations support all structs made
core by the extension.

Tests: dEQP-VK.api.info.get_physical_device_properties2.features
Bug: b/181875303
Change-Id: Ib9f307778f77c135bb7415231f7b152b2ea5b06a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53388
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>
Commit-Queue: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Reactor backend: Subzero

Change-Id: I7f1c4f5d40a5a3aec94b8b593da021faa52d5776
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53328
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

Timeline semaphores were added to all the VkPhysicalDevice.cpp case-
lists that needed it, but when users signaled they wanted the feature in
vkCreateDevice, they could get an assert from a missing feature.

Bug: b/147738281
Change-Id: I1871843d0b901347e9636e41e01c96e5e191fc8c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53408Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Sean Risser <srisser@google.com>
Commit-Queue: Sean Risser <srisser@google.com>

Timeline semaphores track a monotonically increasing uint64_t that
serves as a signal to any number of threads on the device or the host.
Threads and the host wait on the value of the payload to become a
specific value, then unblock. Or they can signal the semaphore and
update its value, unblocking all threads waiting on that value in the
process.

Clang's Thread Safety Analysis is not used for TimelineSemaphore as
it has a bug that prevents it from properly analyzing lambdas that access
guarded resources.

Change-Id: Iafd95b8eac11beea21c00df87ca7ca1e51c77c64
Bug: b/147738281
Test: dEQP-VK.api.info.vulkan1p2_limits_validation.timeline_semaphore
Test: dEQP-VK.synchronization.basic.timeline_semaphore.*
Test: dEQP-VK.synchronization.timeline_semaphore.*
Test: dEQP-VK.synchronization.op.single_queue.timeline_semaphore.*
Test: dEQP-VK.synchronization.cross_instance.*
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52148
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Sean Risser <srisser@google.com>

This CL adds support for checking if the status is InternalError
on deqp when run on regres. This CL also adds support for running
deqp-vk with --deqp-validation=enabled if needed. The status for
validation errors is InternalError.

Bug: b/181718332
Change-Id: I63196f6f6fb244551be8ed03cce7ed79be95ea38
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53268Tested-by: Venni Ihanakangas <venni.ihanakangas@siru.fi>
Reviewed-by: Paul Thomson <paulthomson@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Commit-Queue: Venni Ihanakangas <venni.ihanakangas@siru.fi>

Atomic instructions now take an alignment parameter.

llvm::MaybeAlign() means undefined alignment, which makes the compiler
emit atomic operations that can handle unaligned data. This is probably
overly conservative since our use cases typically ensure alignment. But
that's an optimization we can prudently make later if/when proven
useful.

Bug: b/165000222
Change-Id: I2d0f0f0b5ae8ca811e97c2f5e2f34cc06ca7ee09
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53308
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Commit-Queue: Nicolas Capens <nicolascapens@google.com>

... to use AHardwareBuffer Usage Equivalence Table from
the spec.

Bug: b/169439421
Test: launch Cuttlefish with SwANGLE
Test: dEQP-VK.api.external.memory.android_hardware_buffer.*
Change-Id: Iad6bf6424a1139c623b0fc664b949eb40bbb11bb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53148
Presubmit-Ready: Jason Macnak <natsu@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

This cl marks VK_KHR_xcb_surface as unsupported if we haven't
successfully loaded XCB. Also, an assert was added to make sure
vkCreateXcbSurfaceKHR is called with a valid connection.

Bug: b/139491466
Change-Id: Id4ed46102cd5c2535e38bf65dedbeea1cd252e6e
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53229Tested-by: Alexis Hétu <sugoi@google.com>
Commit-Queue: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

This cl marks VK_KHR_xlib_surface as unsupported if we haven't
successfully loaded X11. Also, an assert was added to make sure
vkCreateXlibSurfaceKHR is called with a valid display.

Bug: b/139491466
Change-Id: I6da3755a15e09320e5715b2036043acbb31c0c35
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53168Tested-by: Alexis Hétu <sugoi@google.com>
Commit-Queue: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

This cl adds a mechanism so that extension strings can easily be
marked as supported or unsupported base on a boolean value determined
at runtime.

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

optimizeSingleBasicBlockLoadsStores() supersedes both
eliminateLoadsFollowingSingleStore() and
optimizeStoresInSingleBasicBlock().

This was verified by adding asserts the latter when the delete more
instructions. They're never hit by dEQP-VK tests. Only the
PointerToPointer triggers an assert. It goes away when running
optimizeSingleBasicBlockLoadsStores() twice. Since it is very rare to
store the address of a pointer in another pointer, and before the new
optimization pass was implemented we also did not handle this case,
we're not going to pay the cost of running it twice.

eliminateUnitializedLoads() was moved earlier because we never produce
new loads of uninitialized values in the optimization passes and it's
best to eliminate these allocas early.

The late eliminateDeadCode() was also removed since we already run it
at the end of optimizeSingleBasicBlockLoadsStores().

TODOs for cases where the load/store sizes don't match have been removed
because propagating a different type causes issues.

Bug: b/179668593
Change-Id: I4b3533057423709cdaa8343301184d8225b0727b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53128
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

CMake's CMAKE_BUILD_TYPE variable is ignored for multi-config
generators,like Visual Studio. Instead, we must specify the config when
building.

For VulkanTester, needed to add "RelWithDebInfo" to search paths for
vk_swiftshader.dll as that's the "Release" config we use for Kokoro
builds.

Change-Id: I1fbfa3b179e9364462f4ea6e9704120d3a675b4d
Bug: b/181019484
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53188
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Kokoro-Result: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Meant to use an "#if" not "#if defined" for USE_HEADLESS_SURFACE. Before
this fix, we would always request the headless surface extension, which
would usually fail on Windows if no loader is installed since current
GPU drivers don't implement this extension yet.

Change-Id: I5bcf9e08f467fd85712d1bc3504e3f251e886664
Bug: b/176981107
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53208
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>

Also make the image not a solid color.

Bug: b/179897703
Change-Id: Ibe2084c4e9f0d9023269218df1ad467bb24a1ae3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52750
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

1D image sampling used to be treated as 2D image sampling with the
second coordinate being ignored. But a bug was causing us to use the
second component of the 'offset' parameter. This was worked around by
initializing all parameters provided to the sampling routine.

This costs some performance, and since we've fixed the 'offset' bug and
have specialized handling of 1D images now, the workaround can be
reverted.

Change-Id: Id69b68465d7755df35fe12619957971681e4c0b7
Fixes: b/136149446
Bug: b/134669567
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48930
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

When a store is propagated to all stores succeeding it in the same basic
block, and we encounter another store, we can delete the previous one.

This optimizes the StoresInMultipleBlocks test's generated code from:

 sub         rsp,38h
 mov         dword ptr [rsp],0Dh
 cmp         ecx,0
 je          a
 mov         dword ptr [rsp],4
 mov         eax,4
 add         eax,3
 mov         dword ptr [rsp],eax
b:
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret
a:
 mov         dword ptr [rsp],6
 mov         eax,6
 add         eax,5
 mov         dword ptr [rsp],eax
 jmp         b

Into:

 sub         rsp,38h
 mov         dword ptr [rsp],0Dh
 cmp         ecx,0
 je          a
 mov         eax,4
 add         eax,3
 mov         dword ptr [rsp],eax
 jmp         b
a:
 mov         eax,6
 add         eax,5
 mov         dword ptr [rsp],eax
b:
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret

Bug: b/179668593
Change-Id: I2036d7b7c97be17ce73ff32234fe51841409a20c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52568
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

For loads following stores in the same basic block, replace their result
with the data that was stored.

It transforms the output of the StoresInMultipleBlocks test from:

 sub         rsp,38h
 mov         dword ptr [rsp],0Dh
 cmp         ecx,0
 je          a
 mov         dword ptr [rsp],4
 add         dword ptr [rsp],3
b:
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret
a:
 mov         dword ptr [rsp],6
 add         dword ptr [rsp],5
 jmp         b

Into:

 sub         rsp,38h
 mov         dword ptr [rsp],0Dh
 cmp         ecx,0
 je          a
 mov         dword ptr [rsp],4
 mov         eax,4
 add         eax,3
 mov         dword ptr [rsp],eax
b:
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret
a:
 mov         dword ptr [rsp],6
 mov         eax,6
 add         eax,5
 mov         dword ptr [rsp],eax
 jmp         b

While at first this might seem like a regression, note that
`add [rsp],3` performs both a load and a store. The optimization pass
eliminated two load operations from this test. The redundant stores will
be eliminated by a subsequent change.

Also adds a unit test for the case where store-to-load propagation
should not be performed due to an indirect store through a pointer
happening in between.

Bug: b/179668593
Change-Id: I6ca133ac4e77bbbc3efd517dff6e8dee6d2dc147
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52533
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Previously we would append the 'begin' basic block with the conditional
branch only once we know whether or not there's a 'false' block separate
from the 'end' block (namely when executing the Else statement). We can
instead treat the 'false' block as the 'end' block itself when no Else
is encountered and simply continue emitting instructions in this block.

Note this removes the need to explicitly materialize all variables,
because that's taken care of by createCondBr().

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

Materializing all variables should be done prior to actual branches, not
when changing the insert point. The only reason we did it in the latter
too was due to changing insert point before creating the branch for an
If statement.

Bug: b/180131694
Change-Id: Ic755bf07a098bda4af7e4d5a7d22138bee37d0c6
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52968Tested-by: Nicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

This change implements the Scalar Replacement of Aggregates (SRoA)
optimization. Since Reactor only supports array aggregates, this
replaces arrays which are only indexed by static indices with individual
variables for each element.

The ReactorArray test is optimized from:

 sub         rsp,38h
 mov         dword ptr [rsp],1
 mov         dword ptr [rsp+4],2
 mov         eax,dword ptr [rsp]
 mov         ecx,dword ptr [rsp+4]
 mov         dword ptr [rsp],ecx
 mov         dword ptr [rsp+4],eax
 mov         eax,dword ptr [rsp+4]
 add         eax,dword ptr [rsp]
 add         rsp,38h
 ret

Into:

 sub         rsp,20h
 mov         eax,2
 add         eax,1
 add         rsp,20h
 ret

Which is identical to the CArray test's generated code.

Bug: b/179279298
Change-Id: Ie45261f2ac783bdc22fee06adf03ebd588f3ebc3
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52428
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

This change adds a callback mechanism to report how many instructions
of certain types are left after the optimization passes have been run.
This enables unit tests to check that the desired optimization actually
took place, instead of just checking correct execution results.

Bug: b/180665600
Change-Id: I3916d327138516a0a0778be2b3fdd5b000fc9bdb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52989
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

x86-64 does not support 64-bit immediates as absolute memory addresses.
They have to be stored in a register, which can then be used as [base].

Previously we addressed this at the SubzeroReactor level by emitting a
Bitcast from an Ice::Operand to an Ice::Variable, for which Subzero
already supported 64-bit constants as input.

This change implements X86OperandMem creation from a 64-bit constant
operand by letting legalize() move it into a GPR and using it as the
memory operand's base register.

A Reactor unit test is added to exercise this.

Another issue was that doLoadOpt() assumed all load instructions are
candidates for fusing into a subsequent instruction which takes the
result of the load. This isn't true when for 64-bit constant addresses
an instruction to copy it into a register is inserted.

For now this case is simply skipped. A future optimization could adjust
the iterators properly so the load from [base] can be fused with the
next instruction.

Lastly, it is possible for a 64-bit constant to fit within a 32-bit
immediate, in which case legalize() by default does not perform the copy
into a GPR (note this is to allow moves and calls with 64-bit
immediates, where they are legal), and simply returns the 64-bit
constant. So we must not allow legalization to an immediate in this
case. Note that while we could replace it with a 32-bit constant, it's
rare for absolute addresses to fit in this range, and it would be
non-deterministic which path is taken, so for consistency we don't
perform this optimization.

Bug: b/148272103
Change-Id: I5fcfa971dc93f2307202ee11619e84c65fe46188
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52768Tested-by: Nicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

SwiftShader has no use for this since shader execution with robustness
features enabled can not access memory outside of the graphics
resources. For Chromium it also runs in the GPU process, which isolates
it from browser-wide and even tab renderer data and code, and also has
its own sandboxing.

If we ever do need randomization to prevent attacks, and project Bunker
doesn't provide the needed site isolation, it should be implemented
either at the Reactor level or as separate transformation passes where
possible.

While previously this feature was already disabled, there might have
been inadvertent randomization which could explain our test time
variability. It may also improve code generation performance a bit to
not have this code around any more.

Bug: b/179832693
Change-Id: If1ccb54981edb61f443dd5949c56b75bab07c7c2
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52808
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

When vkGetPhysicalDeviceSurfaceCapabilitiesKHR is called, we now return
VK_ERROR_SURFACE_LOST_KHR on Windows if the window handle (hwnd) is no
longer valid.

The assert was being tripped by Chromium's compositor_unittests for test
LayerWithRealCompositorTest.BackgroundBlur. With this fix, instead of an
assert, the test now fails because eglQuerySurface fails with
EGL_BAD_SURFACE.

Bug: chromium:1174372
Change-Id: I71164c30bddaa41753472389e996cebbff7fbf77
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52928Tested-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

SPV_ENV_Vulkan_1_2 denotes support for all SPIR-V versions that are core
in Vulkan 1.2. This includes 1.4 and 1.5.

Tests: dEQP-VK.*
Bug: b/173046235
Change-Id: I7482d1bff6bf3b2c2291538517f6640647ab644c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50670Tested-by: Sean Risser <srisser@google.com>
Commit-Queue: Sean Risser <srisser@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Rather than assume success, allow WSI surface implementations to return
a VkResult for getSurfaceCapabilities.

Also, made VkSurfaceKHR::getSurfaceCapabilities pure virtual, and moved
its implementation to a protected static helper named
setCommonSurfaceCapabilities.

Bug: chromium:1174372
Change-Id: I75f5f5a30f786f0675d830e4e2a684a4cbcb149c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/53048
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>

We have fixed the original problem requiring the revert.

This reverts commit ed7c4d5c.

Bug: b/171498948
Change-Id: I02afbf9df677f6b691d0929a1f577ff355ef08e8
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52668Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Presubmit-Ready: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>

Optimizer::eliminateLoadsFollowingSingleStore() was only looking at a
single instruction following the store.

Subzero derives Ice::Inst from llvm::ilist_node<Inst>, making it a node
in a circular linked list. However, we can't iterate until the end
because by default ilist_node<> does not provide sentinel node tracking.
If the llvm::ilist_node<Inst, llvm::ilist_sentinel_tracking<true>> class
is used instead, we can use isSentinel(), but this comes at the cost of
each node itself having to indicate whether it's the sentinel, and
keeping that up to date.

This change instead obtains the basic block's instruction list from the
store instruction, to get the iterator of the end node.

Bug: b/179668593
Change-Id: I994a7b37d8872380d2668c098d85000120d3e47a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52753
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Pointers to the base address of arrays often get stored and then loaded
multiple time. This change adds an optimization pass to replace these
loads with the result of the alloca of the array, and eliminates the
allocas of the pointer variables.

The PropagateAlloca unit test without this optimization produces:

 sub         rsp,38h
 mov         dword ptr [rsp+8],16h
 cmp         ecx,0
 je          000002543C4E407E
 lea         rax,[rsp+8]
 mov         qword ptr [rsp],rax
 mov         rax,qword ptr [rsp]
 mov         eax,dword ptr [rax]
 add         rsp,38h
 ret

With the optimization pass it becomes:

 sub         rsp,38h
 mov         dword ptr [rsp],16h
 cmp         ecx,0
 jne         0000015DC3B33074
 mov         eax,dword ptr [rsp]
 add         rsp,38h
 ret

Also add a couple of unit tests for corner cases where the propagation
is not safe to perform.

Bug: b/179279298
Change-Id: I784899319bf5360f47c6fbc22fb82134d135dbfc
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52468
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

These cases were discovered through various attempts to elide more loads
and stores after a branch has already occurred.

Also implement operator!= for Pointer<T>, and remove the redundant
Nucleus:createPtrEQ() which both LLVM and Subzero support through
integer value comparison.

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

Prior to supporting MemorySanitizer instrumentation of Reactor routines,
false positives in C++ code were avoided by marking all memory that was
written to by the Reactor routines as unpoisoned.

Now this can be disabled to avoid false negatives, i.e. uses of
uninitialized data either in the Reactor routine or originating from it.

REACTOR_ENABLE_MEMORY_SANITIZER_INSTRUMENTATION controls whether we get
the new behavior or the old unpoisoning.

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

Bug: b/180494886
Change-Id: Ib1ddebce8a5679af46a4c8457373f66289df03e7
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52909Tested-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Reactor backend: Subzero

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

In DEBUG builds, enable validation layers: VK_LAYER_KHRONOS_validation
and VK_LAYER_LUNARG_standard_validation. Also register the debug utils
messenger ext callback for when validation layers report a problem. We
can force validation layers in non-DEBUG by defining
ENABLE_VALIDATION_LAYERS to 1.

In order to be able to use validation layers, load the Vulkan driver via
ICD, rather than directly. To load SwiftShader, generate a temp icd.json
file pointing at the driver path, and temporarily set the
VK_ICD_FILENAMES env var to point at it when we load the ICD. This also
allows us to load the native GPU driver by defining LOAD_NATIVE_DRIVER
to 1 (default is 0).

Fixed errors reported by enabling validation layers:
* TriangleSampleTexture had a mismatched binding number for the sampler2D
* Correctly set memoryTypeIndex for allocations instead of 0

Bug: b/176981107
Change-Id: I3c791086acea048b73d3568d6d7a45d8e0100c17
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52749
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>

These structures were zero-initialized to work around MSan false-
positives. Now that Reactor routines can be instrumented, we can omit
the initialization and detect whether they are properly set by the
normal code paths.

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

Reactor backend: Subzero

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

When using push constants, we end up having dynamic offsets on the
input parameter of the interpolation functions, so we need to be able
to handle this case. Since this is for push constants, we assume that
all dynamic offsets will be the same, for simplicity.

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