Minor fixes:
- Fixed printing uint64_t type
- Added a few missing parentheses

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

These were used for platforms which don't have full C++11 support. We've
since moved on to requiring at least C++14.

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

With 2 Chromium builders: linux-swangle-try-tot-swiftshader-x64 and
win-swangle-try-tot-swiftshader-x86

Change-Id: Ie80b1d5001010caccfc739e2c4f16dffbbb00e48
Bug: chromium:1069673
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/43789Tested-by: Yuly Novikov <ynovikov@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Make ReactorUnitTests use C++17 so we can use std::filesystem.
Since ReactorUnitTests is also built in other build systems, this is
made optional by conditionally compiling based on the __cplusplus macro.

- CMake: ensure that __cplusplus is defined on MSVC
- Also replaced "swiftshader" with "reactor" in the assembly output
filename.
- Added run of unit test to Kokoro.

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

Also fix Windows build so that REACTOR_EMIT_PRINT_LOCATION is actually
enabled.

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

This is to be able to use C++17 std::filesystem in a future change.

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

level of indirection because STRINGIFY(X) produces "X" regardless of
what value X is defined to be.

Bug: b/174801963
Change-Id: I1b2c1c987417ee1a97e109b52f41bdc865db8c77
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50908Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

This removes the explicit mention of SwiftShader in Reactor's code,
while still allowing to set a name that identifies the usage precisely.

Bug: b/174801963
Change-Id: Ic6cdd9d36ef9093aea62f571ecd37334ec32d3f2
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50890Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

The use of named anonymous file mappings was only meant for the
allocation of executable memory by the Reactor JIT.

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

This change removes the virtual getType() function, and instead stores
the Type* as a member in Variable. This change is important for when
materialize() gets called from Variable constructors, such as in LValue,
so that we do not call a virtual function from the constructor. Note
that this is exactly what would happen when LValue's ctor calls
materialize(), but it so happened that the most overridden getType() is
in LValue, so it calls the correct version. However, if we ever override
getType() in a class derived from LValue, this would fail to work
properly.

As getType was the only virtual function in Variable, note that the
sizeof(Variable) does not change as we swapped the one vtable pointer
for a Type pointer.

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

Fixes crash when using rr::Array with ENABLE_RR_DEBUG_INFO. This is
because when the LValue ctor calls materialize, this would end up
calling the virtual allocate() function, which would not call the
overridden version in rr::Array as it was not fully constructed yet.
Instead, we go back to having the size stored in Value, and passing it up the
constructor chain.

Note that this effectively reverts "Eliminate the array size from rr::Variable"
(5e16bc45) with some modifications.

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

... to disable the extension on Cuttlefish in order
to pass dEQP-VK.api.info.android#no_unknown_extensions
on Cuttlefish.

Bug: b/174028661
Test: cts -m CtsDeqpTestCases
Change-Id: I9af0194e724a738491f6820eb2ca8947ac202e5a
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50688
Presubmit-Ready: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Jason Macnak <natsu@google.com>

Defining ENABLE_RR_EMIT_ASM_FILE will make it so that the LLVM backend
outputs a unique asm file per routine that is generated. This file is
further processed and updated so that each instruction is prefixed with
the final resolved memory location.

This is useful, for instance, when we get JIT callstacks and can't
easily figure out which code it maps to. Furthermore, when this feature
is coupled with ENABLE_RR_DEBUG_INFO, the emitted asm includes source
location (file and line) information, making it easy to correlate the
asm to the Reactor code.

For example, running ReactorUnitTests.Sample with both
ENABLE_RR_EMIT_ASM_FILE and ENABLE_RR_DEBUG_INFO enabled generates a
file named swiftshader_jit_llvm_0000_ReactorUnitTests_Sample.asm, with
partial output like so:

```
	.file	2 "C:\\src\\SwiftShader2\\tests\\ReactorUnitTests\\ReactorUnitTests.cpp\\<unknown>"
	.loc	2 53 0 prologue_end     # <unknown>:53:0
[0x2B9D3358004] 	mov	qword ptr [rsp + 64], rcx # encoding: [0x48,0x89,0x4c,0x24,0x40]
[0x2B9D3358009] 	mov	qword ptr [rsp + 72], rcx # encoding: [0x48,0x89,0x4c,0x24,0x48]
	.loc	2 54 0                  # <unknown>:54:0
[0x2B9D335800E] 	mov	eax, dword ptr [rcx - 4] # encoding: [0x8b,0x41,0xfc]
[0x2B9D3358011] 	mov	dword ptr [rsp + 8], eax # encoding: [0x89,0x44,0x24,0x08]
[0x2B9D3358015] 	mov	dword ptr [rsp + 16], eax # encoding: [0x89,0x44,0x24,0x10]
	.loc	2 55 0                  # <unknown>:55:0
[0x2B9D3358019] 	mov	dword ptr [rsp + 12], edx # encoding: [0x89,0x54,0x24,0x0c]
[0x2B9D335801D] 	mov	dword ptr [rsp + 20], edx # encoding: [0x89,0x54,0x24,0x14]
```

The "53", "54", and "55" are the line numbers of the respective Reactor
code in ReactorUnitTests.cpp.

CMake: enable REACTOR_EMIT_ASM_FILE to enable this feature.

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

Add an optional parameter to Coroutine::finalize() to give the underlying
routine a name. To support variadic args, we use a strongly-typed Name class.
Note that giving a name to Coroutines is optional, but we may decide to force
one to be given, as we do for Functions, as it's useful for debugging.

- ReactorUnitTests Coroutine tests now pass in the test name
- ComputeProgram now passes in "ComputeProgram" as a name

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

Rather than using "one" everywhere, we now use the test's name as the
Routine name. This will be used in a future change to generate useful
file names for JIT routine asm listings.

Note that Coroutine does not yet expose a way to pass in a Routine name,
so for now, they are still hard-coded to "coroutine". Will be fixed in a
future change.

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

This will be used in a future change to generate useful file names for
JIT routine asm listings.

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

The "name" paramter for a Routine supports format strings with varargs,
but FunctionT did not correctly forward the args.

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

Like the existing workaround, we need to add more source files to get class definitions required for UBSan Vptr.

Change-Id: I7d0abe2a7ee1b1d991ece36c508f235c50d7591e
Bug: chromium:1152803
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50748Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Arthur Eubanks <aeubanks@google.com>
Presubmit-Ready: Arthur Eubanks <aeubanks@google.com>

SwiftShader already extends unsigned texels with 0s and signed texels
with the sign bit. So all that's needed is for all operations to accept
the operands.

Unless a stakeholder specifies that dEQP is undertesting these
operands. This is tracked by b/174475384.

Tests: dEQP-VK.image.extend_operands_spirv1p4.*
Bug: b/173046235
Change-Id: Ib7024b533cefd52957bc7275a041e06ec179c829
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50768Tested-by: Sean Risser <srisser@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

OpGroupNonUniformBroadcast can be supplied either a constant value or an
intermediate. I've split this Op into a fast path for constants that use
the original code, and a slow path that handles intermediates.

Tests: dEQP-VK.subgroups.ballot_broadcast.*
Bug: b/169608683
Change-Id: Idc74f3fe7e906315c59cf5b3bf3a450046e37375
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50671
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Also remove unused `lane` parameter from `Shadow::get`

Fixes: b/173788646
Change-Id: I6797ccd471da4c5b639b2ae52d1a6d2ca9a56522
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50629Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Jaebaek Seo <jaebaek@google.com>

Squashed 'third_party/SPIRV-Headers/' changes from 7845730ca..104ecc356

104ecc356 Merge pull request #180 from dneto0/issue-179
93effe164 MeshShadingNV enables builtins PrimitiveId, Layer, and ViewportIndex
4de110ce1 Merge pull request #182 from dgkoch/khr_rt_final
632375607 de-alias/reassign OpIgnoreIntersectionKHR/OpTerminateRayKHR
928a192ee Raytracing and Rayquery updates for final
eb5e40912 Updated headers for new trace/executeCallable and acceleration structure cast.
5ab5c9619 Reserve additional loop control bit for Intel extension (NoFusionINTEL) (#175)
793f9199b Add EmbarkStudios/rust-gpu to vendor list. (#174)

git-subtree-dir: third_party/SPIRV-Headers
git-subtree-split: 104ecc356c1bea4476320faca64440cd1df655a3

Squashed 'third_party/SPIRV-Tools/' changes from a61d07a72..b0e22d28f

b0e22d28f spirv-fuzz: Fix facts arising from CompositeConstruct (#4034)
5ffa320fe spirv-fuzz: Do not flatten conditionals that create synonyms (#4030)
cd590fa33 Update MeshShadingNV dependencies (and land Ray tracing updates) (#4028)
671914c28 Fix buffer oob instrumentation for matrix refs (#4025)
1f2fcddd3 spirv-opt: Set parent when adding basic block (#4021)
f686518ce spirv-opt: properly preserve DebugValue indexes operand (#4022)
1cda49527 Use less stack space when validating Vulkan builtins (#4019)

git-subtree-dir: third_party/SPIRV-Tools
git-subtree-split: b0e22d28f5ec891d6b256703575d08fce4228bd9

BUG: b/174239232

Change-Id: I1973df95f38ce8d77d344dd43afa707588ab6dde
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50749Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ryan Harrison <rharrison@chromium.org>

Now that we have a workaround for the LargeStack test to run in a normal
amount of time (swiftshader-cl/50710), allow it to run again on all
platforms.

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

Disable the InstructionCombiningPass and O2 optimization level to make
ReactorUnitTests.LargeStack take only a few seconds to run. Otherwise,
it would take 6 minutes on my desktop workstation.

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

Before this change, REACTOR_DEFAULT_OPT_LEVEL was set to "Default" by
default, which would always define the REACTOR_DEFAULT_OPT_LEVEL macro
to this value. Because of this, the Optimization constructor would
forcibly set the Level member to this macro value. As a result, any
value we would try to set for Optimization in code (e.g. via
Optimization::Edit for a Routine generation) would be ignored.

With this change, only if the user sets the REACTOR_DEFAULT_OPT_LEVEL
CMake arg explicitly will it be used to override values in code.

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

Fixes ReactorUnitTests.FRem failing on Windows x86.

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

This method previously always recursively checked both the left-hand
side and right-hand side of binary operations for splatted (broadcast)
values to determine if the parent DAG node is a splat. For chained
operations, such as the 10,000 adds of the dEQP-VK.spirv_assembly.
instruction.graphics.spirv_ids_abuse.lots_ids_frag/vert tests,
very deep recursion could result in stack overflow.

Like several other SelectionDAG methods, limit the recursion depth to
MaxRecursionDepth (6).

Bug: b/173785481
Change-Id: I22ee0453db7cf1311267291a331ad8fa3b57b1d9
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50672
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Jason Macnak <natsu@google.com>

This operand was added in SPIR-V 1.4. It allows copying from similar,
but inequal types. Otherwise it functions identically as OpCopyObject.

Tests: dEQP-VK.spirv_assembly.instruction.spirv1p4.opcopylogical.*
Bug: b/173046235
Change-Id: Ibf46185c79dde05f52743425b570d5ef978830cf
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50508Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Sean Risser <srisser@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

This will help us detect issues with Windows x86 builds.

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

Will upstream same fix to marl project soon.

Bug: b/173784261
Change-Id: I8402ccd4f0379ea5d31155fe9aa0a81dc892ebee
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50669Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

Rather than load/unload the driver for each test run, only do so once
per suite. This is mainly a workaround for the memory leak bug
reported at b/173733181; however, it also speeds up running the tests.

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

Remove sw::TaskEvents and sw::WaitGroup, replace this with sw::CountedEvent.

See b/173784261 for details.

Fixes: b/173784261
Change-Id: I21fb69c810558a1929bba5cc46f106d9d4e51c4b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50628
Kokoro-Result: 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>
Presubmit-Ready: Ben Clayton <bclayton@google.com>

Subzero does not support aarch64, so we should not generate Reactor unit
test targets for Subzero on Fuchsia ARM64.

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

Bug: b/158094132
Test: comment out AHB def and test on Android.
Change-Id: Ibae7f50a861d1009be3eaa11067783bacacdee54
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50548Tested-by: Yiwei Zhang <zzyiwei@google.com>
Presubmit-Ready: Yiwei Zhang <zzyiwei@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Trevor Black <vantablack@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

This will enable running Reactor tests both with the LLVM and Subzero
backend for maximum coverage.

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

This initial implementation will only emit device memory report
callbacks upon vkAllocateMemory and vkFreeMemory.

This extension will be enabled on API 31 and above.

VkDeviceMemoryExternalAndroid.hpp is not needed in CMakeLists.txt since
Android uses build blueprint.

Bug: b/158094132
Test: dEQP-VK.memory.device_memory_report.create_and_destroy_object.*
Test: dEQP-VK.memory.device_memory_report.vk_device_memory.*
Test: dEQP-VK.memory.device_memory_report.external_memory.*
Change-Id: I519b8c7efed15924e2ac8dbb8ab806d44f4fc1ed
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50108Tested-by: Yiwei Zhang <zzyiwei@google.com>
Presubmit-Ready: Yiwei Zhang <zzyiwei@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

The large slowdown in codegen for MemorySanitizer instrumented Reactor
code only affects the LLVM backend, and the workaround of not performing
codegen optimizations is also LLVM specific. So only override the
optimization level for LLVM for MSan builds. Previously it was done in
Nucleus, but this abstract API affects other backends too, and this
depended on rr::Optimization::Level::None to correspond with
llvm::CodeGenOpt::None which might not always remain the case.

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

Halide users reported this here: https://llvm.org/pr46176
I reported the issue to MSVC here:
https://developercommunity.visualstudio.com/content/problem/1179643/msvc-copies-overaligned-non-trivially-copyable-par.html

This codepath is apparently not covered by LLVM's unit tests, so I added
coverage in a unit test.

If we want to support this configuration going forward, it means that is
in general not safe to pass a SmallVector<T, N> by value if alignof(T)
is greater than 4. This doesn't appear to come up often because passing
a SmallVector by value is inefficient and not idiomatic: it copies the
inline storage. In this case, the SmallVector<LLT,4> is captured by
value by a lambda, and the lambda is passed by value into std::function,
and that's how we hit the bug.

Differential Revision: https://reviews.llvm.org/D87475

NOTE from amaiorano@ : applied this LLVM patch (without the unittest) to SwiftShader.

Bug: b/173512119
Change-Id: If036f61386b51f9b4a20427812b4ac92d901244d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50469Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Bug: b/173422055
Change-Id: I5d3bbbd7c89771c3f4a4b0900e36eea971171c0f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50428
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Nicolas Caramelli <caramelli.devel@gmail.com>

LLVM intermediate code instrumented by MemorySanitizer can take an
inordinate amount of time to compile into machine code when using the
llvm::CodeGenOpt::Default optimization level.

While lower optimization levels can make the generated code slower to
execute, the 'None' level is just 5-20% slower, which is negligible
compared to the slowdown from the instructions added by the MSan
instrumentation itself.

llvm::CodeGenOpt::Default:

-------------------------------------------------
Benchmark                                    Time
-------------------------------------------------
ClearImage/VK_FORMAT_R8G8B8A8_UNORM      0.912 ms
ClearImage/VK_FORMAT_R32_SFLOAT           3.83 ms
ClearImage/VK_FORMAT_D32_SFLOAT          0.866 ms
Triangle/Hello                           0.996 ms
Triangle/Multisample                      4.63 ms

llvm::CodeGenOpt::None:

-------------------------------------------------
Benchmark                                    Time
-------------------------------------------------
ClearImage/VK_FORMAT_R8G8B8A8_UNORM      0.974 ms
ClearImage/VK_FORMAT_R32_SFLOAT           5.42 ms
ClearImage/VK_FORMAT_D32_SFLOAT          0.937 ms
Triangle/Hello                            1.16 ms
Triangle/Multisample                      4.70 ms

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