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>

Fixes: b/171897980
Change-Id: I3e2623bc05f1afc3c30b0f0c5fba18bdddf62e92
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/49968Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

Since vulkan.hpp was updated to do this for us, we should stop
outputting this number while in debug mode.

Bug: b/170962162
Change-Id: I1d813d69db4a73c71383fc54bc129e2768d5be60
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50309
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Android Cuttlefish x86 instances crashed with an execution privilege
access violation error, due to an R_386_PC32 relocation which is used
when calling a C function from Reactor code, who's address is not
associated with any symbol (since it's an absolute constant), but it
still invokes the symbol resolver for "".

Returning any address for this nameless symbol prevents the issue.

This is not a proper fix for the root cause, which is presumed to be a
bug in LLVM's handling of ELF::R_386_PC32 relocations not associated
with any symbol, but it enables us to make the switch from the
deprecated LLVM ORCv1 JIT API to ORCv2.

Bug: b/172974501
Change-Id: I2d1978fccd2365bd8837f6d2054f43792f61cf73
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50368
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

The rr::Print() functionality is intended for debugging, so it should
always be available in Debug builds without having to set the CMake
flag explicitly. This also helps us avoid inadvertently breaking it.

Also consistently use TRUE/FALSE for Boolean values instead of a string.

Bug: b/149328074
Change-Id: Iab7e0f230dcd5b42679d64ef75bf3c0a3809a0d0
Signed-off-by: Nicolas Capens <capn@google.com>
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50076
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Only the LLVM JIT supports MemorySanitizer instrumentation, so don't use
Subzero for MSan builds.

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

Includes update to to_string functionality that reports enum value in
case of "invalid".

https://github.com/KhronosGroup/Vulkan-Headers
revision 670ffea9d61b9f4b8f68c919dab7caf33dfd9718
tag v1.2.160

Bug: b/170962162
Test: build
Change-Id: I5ac872bdebd7f8898bda78a7b7f025da9e7cd21d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50348Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Sean Risser <srisser@google.com>

Reactor backend: Subzero

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

Android relies on VK_ANDROID_external_memory_android_hardware_buffer.

Bug: b/158094132
Change-Id: I75498d38fc1d3e5c3a2b21df35fdef32d9f597a0
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50248
Presubmit-Ready: Yiwei Zhang <zzyiwei@google.com>
Reviewed-by: David Turner <digit@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Yiwei Zhang <zzyiwei@google.com>

Some external device memories really represent existing images
with requirements and not just memory blobs. For AHB, we want
to use the stride from the gralloc buffer.

Bug: b/141698760
Bug: b/147316305
Test: launch_cvd && cts -m CtsDeqpTestCases
  dEQP-VK.api.external.memory.android_hardware_buffer.*
Change-Id: If657c91e458545b58d1d3b0f15f807ca9828b09c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50068
Presubmit-Ready: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Jason Macnak <natsu@google.com>

The LLVM MemorySanitizer pass was added for -fsanitizer=memory builds
when REACTOR_ENABLE_MEMORY_SANITIZER_INSTRUMENTATION is defined, but
LLVMJIT.cpp includes LLVMReactor.hpp, which in turn includes Reactor.hpp
which defines REACTOR_ENABLE_MEMORY_SANITIZER_INSTRUMENTATION to 0 if
not previously defined, which will always enable it.

Use #if instead of #ifdef to conditionally enable instrumentation based
on REACTOR_ENABLE_MEMORY_SANITIZER_INSTRUMENTATION's value.

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

MemorySanitizer checks for uninitialized memory and variable usage. It
instruments each instruction to update 'shadow' memory which indicates
which bits are 'poisoned', and inserts tests for dereferencing pointers
and conditional branching which makes use of not fully initialized data.

The instrumentation is done by the llvm::MemorySanitizerLegacyPass.
Functions must opt-in to the instrumentation with the 'SanitizeMemory'
attribute.

MemorySanitizer relies on several TLS variables for storing the shadow
value of function parameters and return values. The JIT makes calls to
__emutls_get_address() to obtain the address off these variables,
passing it the address of a __emutls_v.* control structure unique to
the TLS variable. We replace the former with our own function through
the symbol resolver, and the latter are represented by enum values, to
allow obtaining the real TLS variable's address in C++ code.

This is enabled behind a REACTOR_ENABLE_MEMORY_SANITIZER_INSTRUMENTATION
flag. For now, only enable CMake builds.

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

Bug: Not correctly rendered on GitHub
Change-Id: I58ce99ed2312f7a06c291a7369eac5ea8449cb75
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47908
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

This extension allows users to query and specify how the implementation
handles floats. SwiftShader does not allow users to modify floating
point behavior at this time, and its default behavior may be
inconsistent due to operating across several architectures.

Bug: b/171498580
Change-Id: I2926f015bdccad0ca2a4cfae195eeeba09781f07
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/49728
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Formatted using:

find ${DIR} -iname "*.cc" -o -iname "*.h" -o -iname "*.hpp" -o -iname "*.cpp" -o -iname "*.inl" | xargs ${CLANG_FORMAT} -i -style=file

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

Formatted using:

find ${DIR} -iname "*.cc" -o -iname "*.h" -o -iname "*.hpp" -o -iname "*.cpp" -o -iname "*.inl" | xargs ${CLANG_FORMAT} -i -style=file

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

llvm::orc::JITTargetMachineBuilder::detectHost() currently states:
// FIXME: getProcessTriple is bogus. It returns the host LLVM was compiled on,
//        rather than a valid triple for the current process.

This change uses LLVM_DEFAULT_TARGET_TRIPLE instead, which we define
based on the platform and predefined macros (see llvm-config.h).

This doesn't fix any known bugs, but it's good to not leave the triple
unknown, to avoid future issues. This change also refactors passing
the JITTargetMachineBuilder by rvalue reference and uses some less
cryptic variable names.

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

Since we track the SPV_ENV_... version with VkConfig.hpp, any other
directory that includes VkConfig has to have a dependency on SPIR-V
Tools.

Bug: b/172837769
Change-Id: I7962ee278c3240c9461acaedcd9cbbca0c08c0d6
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50208Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>

... to support a fresh merge into AOSP including
https://swiftshader-review.googlesource.com/c/SwiftShader/+/49688
to unblock ANGLE CI.

Introduces a libLLVM10_swiftshader_debug to handle
linker errors around LLVMJIT_ORCv1.cpp including
llvm/Support/Error.h and whether or not
LLVM_ENABLE_ABI_BREAKING_CHECKS is defined.

Bug: b/147316305
Test: TreeHugger build on aosp/1494218
Change-Id: I513cb76f03f49699e4a0e8b0c7d3e59a2baa3a86
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50148
Presubmit-Ready: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Jason Macnak <natsu@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>

This ReactorUnitTest fails if the fix made in swiftshader-cl/50008 is
reverted. Git hash of fix: 3476ca34

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

Multiple places in the codebase use SPV_VERSION_1_1, which makes
updating the SPIR-V version a nuissance. Now only VkConfig.hpp
tracks that information.

Bug: b/172837769
Change-Id: I9ba09b431e48e2205cf0d8b428417b72a3f514cb
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50128Reviewed-by: Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Sean Risser <srisser@google.com>

Add validateBufferSize and getTransportSize

Bug: b/131089111
Test: build, boot
Change-Id: Ie5ce20010c8a00eebde239d149faa1fb0fc07195
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50074Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

For DebugValue with index parameter, the debugger code does not use the
correct member index. It results in "undefined" value even when the
shader actually provide the value.

Bug: b/148401179
Change-Id: Ic563db74503200c1a6dc71a5e1744b75df63d610
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50072
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Tested-by: Jaebaek Seo <jaebaek@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

* changes:
  Update SPIR-V Tools to a61d07a72
  Squashed 'third_party/SPIRV-Tools/' changes from f7da52775..a61d07a72

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

See the first bug I fixed related to this: 7fefd483.

That bug fix ensured that arguments are accessed relative to 'ebp'
rather than 'esp' on Windows x86. However, when an arg Variable gets
split (see LocalVariableSplitter), the new Variable that's linked to the
original arg Variable must also use 'ebp' in the same way. This is now
fixed by making sure to set its "isArg" state to match that of the
"linked stack root" Variable at the same time as we set its
"stackOffset" in the same way. Thus, when stackVarToAsmOperand is called
during emitIAS, split Variables are properly addressed using the correct
frame pointer.

See the detailed design doc:
https://docs.google.com/document/d/1IBsWg2V9_arWGYkpuwlKdne4lkA6XwSQ8fp99l8BmnA

This fixes the intermittent crash reported here:
https://bugs.chromium.org/p/angleproject/issues/detail?id=4482#c15

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

Using std::unordered_set to hold unmaterialized variables meant that
when materializeAll was called, the order of variables would differ
between runs of the same executable on the same target.

Instead, we now use a map of Variable* to a monotonically increasing
counter, allowing us to not only guarantee order-consistency across
runs, but also means we can submit variables in the order they are
declared, which may be preferable by the JIT backend.

Note that this also affects LLVM; however, LLVM likely already performs
stack variable reordering, so the effects are minimized. Nonetheless,
this change likely also fixes determinism when using LLVM.

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

Changes:
    a61d07a72 spirv-val: Fix SPV_KHR_fragment_shading_rate VUID label (#4014)
    650acb575 spirv-val: Label Layer and ViewportIndex VUIDs (#4013)
    0c036df28 Add dead function elimination to -O (#4015)
    c2b2b5788 Add DebugValue for invisible store in single_store_elim (#4002)
    c74d5523b Fix SSA re-writing in the presence of variable pointers. (#4010)
    02195a029 spirv-fuzz: Fixes to pass management (#4011)
    bcf5b211d spirv-fuzz: Add support for reining in rogue fuzzer passes (#3987)
    7d250ed51 spirv-fuzz: Fix assertion failure in FuzzerPassAddCompositeExtract (#3995)
    f9937bcc8 spirv-fuzz: Fix invalid equation facts (#4009)
    aa6035f1c spirv-fuzz: Fix bugs in TransformationFlattenConditionalBranch (#4006)
    5735576f8 spirv-fuzz: Fix bug related to transformation applicability (#3990)

Commands:
    ./third_party/update-spirvtools.sh

Bug: b/123642959
Change-Id: I3c4f10f78f63a75dcec8036a6a9488a82aebf84c

a61d07a72 spirv-val: Fix SPV_KHR_fragment_shading_rate VUID label (#4014)
650acb575 spirv-val: Label Layer and ViewportIndex VUIDs (#4013)
0c036df28 Add dead function elimination to -O (#4015)
c2b2b5788 Add DebugValue for invisible store in single_store_elim (#4002)
c74d5523b Fix SSA re-writing in the presence of variable pointers. (#4010)
02195a029 spirv-fuzz: Fixes to pass management (#4011)
bcf5b211d spirv-fuzz: Add support for reining in rogue fuzzer passes (#3987)
7d250ed51 spirv-fuzz: Fix assertion failure in FuzzerPassAddCompositeExtract (#3995)
f9937bcc8 spirv-fuzz: Fix invalid equation facts (#4009)
aa6035f1c spirv-fuzz: Fix bugs in TransformationFlattenConditionalBranch (#4006)
5735576f8 spirv-fuzz: Fix bug related to transformation applicability (#3990)

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

An update to vulkan.hpp made it no longer provide the same default
arguments, leading to ambiguous calls.

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

This was tested by using __writeeflags(__readeflags() | 0x40000) to
enable alignment checks on x86.

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

https://llvm.org/docs/LangRef.html#alloca-instruction does not specify
the type of the 'NumElements' parameter explicitly, but it is multiplied
by sizeof(<type>), which itself is of type size_t and thus 64-bit on
a 64-bit platform. This assumption is made by MemorySanitizer when it
emits instructions corresponding to this multiplication, which get
constant folded and requires both operands to be of the same bit size.

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

Runtime symbols referenced by MemorySanitizer instrumentation (e.g.
__msan_warning_noreturn) reside in the executable and are exported from
it (i.e. __attribute__((visibility("default"))). They can be
resolved using dlsym(RTLD_DEFAULT). This works for either an executable
or shared library using Reactor.

Note that this differs from our regular symbol Resolver approach which
lists pairs of symbol names and addresses. There is no public header
which declares these MSan symbols, and if we list symbols only available
in a newer version of LLVM's compiler-rt, the executable won't link or
the shared library won't load.

This change has no effect at this point. A later change will enable
MemorySanitizer intrumentation for Reactor routines.

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

Most of Chromium uses Subzero as the JIT backend for Reactor, but
Fuchsia on ARM64 uses LLVM, which previously broke when switching to
ORCv2 due to LLVM_ENABLE_ABI_BREAKING_CHECKS being set inconsistently
https://swiftshader-review.googlesource.com/c/SwiftShader/+/49908

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

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

Reactor backend: LLVM

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

LLVM_ENABLE_ABI_BREAKING_CHECKS was disabled everywhere except for
Fuchsia. It triggered llvm::Error::assertIsChecked() in the new ORCv2
code because we're supposed to check Expected<> didn't return an error
by casting it to a bool, which we only do in Debug builds.

Since this option costs performance in Release builds and we don't want
to abort on errors (especially benign ones), it should only be enable
for Debug builds. This is also the default behavior for standalone
builds of LLVM:
https://llvm.org/docs/ProgrammersManual.html#abi-breaking-checks

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

Since there does not seem to be any elegant way of
checking whether a class is the first base class in
c++ (given that the 2009 c++ proposal n2965 was
rejected), this python script does it by scanning
all source files for illegal patterns.

The python file was implemented in a way to enable
easy addition of further checks, should need arise.

Bug: b/152253831
Change-Id: I25701a3302579700ccb6222141843d27f38d9069
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/49788
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Jari Komppa <jari@siru.fi>

The target triple is used by MemorySanitizer to determine where to map
the shadow and origin data, which is OS specific. When not set, the
MemorySanitizer::initializeModule() method, which inserts an __msan_init
call to the module's constructor list, produces an
"unsupported operating system" error.

Note that JITs like Reactor have no use for a module constructor list
(__msan_init gets called during executable startup), but there is
currently no way to skip this initialization. Leaving it unused is fine
though. Likewise, setting the target triple has not other known JIT uses
at the moment, but it can't hurt.

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

* changes:
  Update SPIR-V Tools to f7da52775
  Squashed 'third_party/SPIRV-Tools/' changes from 82b378d671..f7da527757